2017-08-01
YOURChain’s platform architecture is a decentralized, economically sustainable public compute infrastructure. The platform design results from the inspirations of earlier blockchains and builds on top of the shoulders of giants in the disciplines of mathematics and programming language design.
Intended audience: This document is primarily written for developers and other community members who want further refine the platform design and help construct it and who want to build applications and protocols on top of it.
The YOURChain and its partners are building a public, Sybil-resistant, and censorship-resistant computing utility. This is an open source project. It will be a blockchain-based platform for specifying, verifying, building, and running decentralized protocols (“smart contracts”) that form the base for decentralized applications. On top of this technology platform, a broad array of solutions can be built, including financial services, monetized content delivery networks, marketplaces, governance solutions, DAOs, and YOURChain’s own flagship decentralized social platform.
The decentralization movement is ambitious and will spawn solutions that provide awesome opportunities for new social and economic interactions. Decentralization also provides a counter-balance to abuses and corruption that occasionally occur in some organizations where power is concentrated, including large corporations and governments. Decentralization supports self-determination and the rights of individuals to self-organize. Of course, the realities of a more decentralized world will also have its challenges and issues, such as how the needs of international law, public good, and compassion will be honored.
We admire and respect the awesome innovation and intentions of the Bitcoin and Ethereum creators, and other platforms that dramatically advanced the state of decentralized systems and ushered in this new age of cryptocurrency and smart contracts. However, we also see symptoms that those projects didn’t use the best engineering and mathematical models for scaling and correctness in order to support mission-critical solutions. The ongoing debates about Bitcoin scaling and the June 2016 issues with The DAO smart contract are symptomatic of foundational architectural issues. As an example question: Is it scalable to insist on an explicit serialization order for all transactions conducted on planet earth?
YOURChain’s requirements, originating from YOURChain’s decentralized social product and its attention & reputation economy, are to provide content delivery at the scale of Facebook along with support for transaction volume and speed at the scale of Visa. After due diligence on the current state of many blockchain projects, after deep collaboration with Ethereum developers, and after understanding their respective roadmaps, the YOURChain leadership concluded that the current and near-term Blockchain architectures cannot meet these requirements. Therefore, YOURChain and partners resolved to build a better blockchain architecture. Together with the blockchain industry, we are still at the dawn of this decentralized movement, and it is now the time to lay in a more correct architectural foundation.
The journey ahead for those who share this ambitious vision is as challenging as it is worthwhile, and this document summarizes that vision and how we seek to accomplish it. We compare the blockchains of Bitcoin and Ethereum, outline the YOURChain architecture, rationale for its creation, and pointers to initial specifications.
This document assumes the reader is familiar with the basics of Bitcoin and Ethereum. As one approach to introducing the architecture let’s compare the characteristics of Bitcoin, Ethereum, and YOURChain as currently planned.
The primary components of the architecture are depicted below:
Like all “layer cake” views of architecture, this diagram is a simplification of the actual architecture. At first glance, you’ll notice there are components expected in blockchain architectures, but also components that might not be as expected All data managed by the platform requires some associated payment. Of course, an application could also manage its own data, and that data could be referenced via a pointer stored on the blockchain.
In addition to the datastore at the base of the architecture, a consensus protocol and peer-to-peer gossip network form the foundation.
Above that, the SpecialK Data & Continuation Access and Cache layer is an evolution of the existing SpecialK technology (including its decentralized content delivery, key-value database, inter-node messaging, data access patterns, and privacy protecting agent model).
The Casper consensus protocols assure that nodes reach agreement about the contracts, contract state, and transactions for which each node is interested.
Blockchain contracts (aka smart contracts, protocols, or programs) will be written in a new domain-specific language for contracts called URlang (or in contract languages that compile to URlang) and then executed on the Universal Redundant Virtual Machine on a number of native platforms.
Smart Contracts include some essential system contracts as well as those providing capabilities for tokens and application-supplied contracts.
A metered and monetized content delivery network (CDN) is enabled through token and micro-payment contracts, accessing a mix of blockchain and off-chain data.
The Attention & Reputation Economy provides a model and set of interactions for motivating respectful and economic creation and dissemination of information within social networks.
In the architecture, there will be several APIs, especially at the top layers. Typed APIs will provide access to the URVM, Contract Services, and individual contracts. In addition other APIs (including RESTful APIs) will be provided for accessing the CDN, and the Attention & Reputation Economy.
We'll detail these components in the sections below, from the bottom-up. But first, let’s discuss the requirements and software architecture approach motivating this platform solution.
Let’s look at the requirements for the platform from the vantage point of the developers building applications on top of it. Then, let’s look at what is required of the platform itself in order to achieve those requirements.
There is a long list of items the architecture will not address, but let’s list a few to dispel what might otherwise be common misperceptions. For example, the architecture will not address:
Building quality software is challenging. It is easier to hand-craft clever software; however, the resulting software is often of poor quality, riddled with bugs, difficult to maintain, and difficult to evolve. Inheriting and working on such software can be hellish for development teams. Some project leaders are perfectly fine with this approach and even define “optimal” project success as one that minimally solves requirements and that believe doing more is a waste. We reject that methodology and minimal-success mindset when building a system as important as a public computing utility which will serve as the basis for currencies and other applications that are critical for society.
Therefore, we resolved to meet the requirements stated in the earlier section, and to:
Like other Blockchains, YOURChain will use elliptic curve cryptography (ECC). The exact curve and address formats have not yet been selected.
There are several areas in which cryptography is employed, including:
Like Ethereum, the YOURChain blockchain will store contracts and their serialized state. UTXO-style transactions will be implemented with simpler system-level contracts. Like Bitcoin and Ethereum, tamper-proof blockchain semantics will be used to create a history of blocks. The blockchain’s main purpose is to efficiently store essential state, any necessary sequencing, and timestamping.
Note that the math underlying this blockchain semantic structure is known as a Traced Monoidal Category. For more detail see Masahito Hasegawa's paper on this topic, Recursion from Cyclic Sharing: Traced Monoidal Categories and Models of Cyclic Lambda Calculi.
The YOURChain design considers all storage “conserved”, although not all data will be conserved forever. Instead, data storage will be leased and will cost producers of that data in proportion to its size, contract complexity, and lease duration. Unlike Bitcoin and Ethereum, immutable data is not promised to be truly forever; however, a very long lease duration is equivalent.
The simple economic reason justifying leasing is that storage must be paid by someone or it cannot be maintained. We’ve chosen to make the economic mechanism direct. It is really an environmentally unfriendly idea that storage is made "free" only to subsidize it by an unrelated process. A small part of the real cost is measurable in the heat signatures of the data centers that are growing to staggering size. This charging for data as it is accessed also helps reduce "attack" storage, the storage of illegal content to discredit the technology.
A variety of data is supported, including public unencrypted json, encrypted blobs, or a mix. This data can also reference off-platform data stored in private, consortium, public, or obscure locations and formats.
Data will be accessed using the SpecialK semantics and physically stored in a key-value database. A given node can choose which address namespaces it cares about, so not all data needs to be replicated in every node.
In contrast to other blockchains, where addresses are public keys (or hashes thereof), YOURChain’s address space will be structured. This is similar to how both the Internet and the web works, with IP addresses and URLs, respectively. A structured addressing approach allows programs to talk about “location” in a much more nuanced and fine-grained way. This design choice enables fast datalog queries based on those namespaces and better system performance by analyzing communication patterns to optimize the sharding solution.
For additional information, see Linear Types Can Change The Blockchain (pdf, lex, hangout video), which describes the inspirational math and thinking in this area. Linear Types provide a nice way to decompose the blockchain in a scalable fashion. It already has sharding semantics in it, that is in the type system.
In order to support many of the use cases that users of Bitcoin find valuable as well as broader use cases, namespace definitions will have a corresponding policy set that constrains its use, for example by setting:
With policies such as these, a namespace can be defined to provide better guarantees of fast transaction speed and immutability, for example.
YOURChain’s contract accounts, transactions, and messages are analogous to those in Ethereum.
YOURChain’s VM will implement a rate-limiting mechanism that is related to some calculation of processing, memory, storage, and bandwidth resources. This mechanism is needed in order to recover costs for the hardware and related operations. Although Bitcoin and Ethereum (gas) have similar needs, the mechanisms are different. Specifically, the metering will not be done at the VM level, but will be injected in the contract code (via source-to-source translation that is part of the compilation process).
Somewhat similar to Omni Layer, multiple types of tokens will be supported. These tokens will have different properties depending on their type, including parameters such as:
For each type of token, there will be a link between its class (i.e., its set of distinguishing properties) and the rate-limiting mechanism.
An YOURChain contract is a well-specified and well-behaved program that interacts with others. Contract interaction with clients or other contracts is via transactions.
When the contract at a given state needs to be evaluated, it is read from the blockchain and deserialized into URVM intermediate representation (IR) of the contract with its state parameters. This is via a delimited continuation pattern. The URVM IR is compiled into another VM format that is then executed. After the contract is run to its next transaction state, the resulting state is serialized and again stored on the blockchain.
This section describes the essential requirement for decentralized concurrency in Internet-scale applications, along with the compute models and programming languages that best suit that requirement. URlang is introduced, which is a behaviorally typed, reflective, higher-order process language.
A platform supporting a global, decentralized compute utility that supports a wide variety of applications must scale, and concurrency is essential to achieve that. Transactions that do not interact must be able to complete at the same time, because to enforce a sequencing constraint forces all nodes to process all transactions. Such a sequencing constraint is essentially what causes blockchains in their current form to be fundamentally unscalable.
When we say “concurrency”, we’re not just talking about multi-threaded implementation of functions, but handling of non-blocking I/O and concurrent processes within and across nodes. The Internet itself is built out of billions of autonomous computing devices each of which is executing programs concurrently with respect to the other devices, but also concurrently on the devices themselves, as most modern hardware supports native multi-threading capability. Decentralization places special emphasis on the autonomy and independence of devices and programs running on them. The APIs of centralized trusted third parties, which programmers could pretend were part of a giant sequential computer, will become a thing of the past. Even inside those organizations sequential architecture is giving way to lots and lots of autonomously executing microservices.
There are relatively few programming paradigms and languages that handle concurrent processes in their core model. Instead, they bolt some kind of threading-based concurrency model on the side to address being able to scale by doing more than one thing at a time. Mobile process calculi provides one model, which we’ve chosen. They provide a fundamentally different notion of what computing is. In these models, computing arises primarily from the interaction of processes.
The family of mobile process calculi provides an optimal foundation for a system of interacting processes. Among these models of computation, the applied π-calculus stands out. It models processes that send queries over channels. This approach maps very well onto today’s Internet and has been used as the tool of choice for reasoning about a wide variety of concerns essential for distributed protocols.
Beyond this basic fit with the way the Internet computes, the mobile process calculi have something else going for them: behavioral types. Behavioral types represent a new kind of typing discipline that constrains not only the shape of input and output, but the permitted order of inputs and outputs among communicating processes. Getting concurrency right is hard, and support from this kind of typing discipline will be extremely valuable to ensure end-to-end correctness of a large system of communicating processes.
Even a model based on the applied π-calculus and equipped with a behavioral typing discipline is still not quite the best fit for a programming language for the decentralized Internet, let alone a contracting language for the blockchain. There’s another key ingredient: The UR-calculus, a variant of the π-calculus, was introduced in 2004 and provided the first model of concurrent computation with reflection. Reflection is now widely recognized as a key feature of practical programming languages. Java, C#, Scala, have eventually adopted reflection as a core feature, and even OCaml and Haskell have ultimately developed reflective versions. The reason is simple: at industrial scale, human agency is at the end of a very long chain of programs operating on programs. Programmers use programs to write programs, because without the computational leverage it would take too long to write them at industrial scale. Reflection is one of the key features that enables programs to write programs, providing a disciplined way to turn programs into data that programs can operate on and then turn the modified data back into programs. Lisp programmers have known for decades how powerful this feature is and it took the modern languages some time to catch up to that understanding. The UR-calculus is the first computational model to combine all of these core requirements: behaviorally typed, fundamentally concurrent, message-passing model, with reflection. For details, see A Reflective Higher-order Calculus.
URlang is a fully featured, general purpose, Turing complete programming language built from the UR-calculus. URlang is YOURChain’s smart contract language. To get a taste of URlang, here’s a contract named Cell that holds a value and allows clients to get and set it:
data Request[a] = Get(Ch[a])
| Set(a)
contract Cell(client: Ch[Request[a]], state: Ch[a]) = {
select {
case(Get(rtn) << client; value := state) {
rtn!(value)
}
case(Set(newValue) << client; value <- state) {
state!(newValue)
}
}
}
The language is concurrency-oriented, with a focus on message-passing through channels. Channels are statically typed and can be used as single message-pipes, streams or used to store data. Similarly to typed functional languages, it supports algebraic data types and deals with immutable values. It supports formal verification through the use of behavioral types.
A document introducing URlang in more detail is being produced.
The compiled URlang contract is executed in a universal redundant virtual machine (URVM). This virtual machine is derived from the computational model of the language, similar to other programming languages such as Scala and Haskell. In other words, there will be a tight coupling between URlang and its VM, ensuring correctness. This VM is the machine that will be executed by the compute utility, and we call it URVM. To allow clients to execute the VM, we’ll build a compiler pipeline that starts with VM code that is compiled into intermediate representations (IRs) that are progressively closer to the metal, with each translation step being either provably correct, commercially tested in production systems, or both. This pipeline is illustrated in the figure below:
Let’s describe these steps in more detail:
For more details see the #URlang channel on the YOURChain Slack (here or join). Early compiler work can be seen on GitHub and discussion on Gitter.
URlang will be formally specified, and we are investigating a few frameworks such as K-Framework to achieve this.
In the URVM and potentially in upstream contracting languages, there are a variety of techniques and checks that will be applied during compile-time and runtime. These help address requirements such as how a developer and the system itself can know a priori that contracts that are well-typed will terminate.
Formal verification will assure end-to-end correctness via model checking (such as in SLMC) and theorem proving (such as in Pro Verif). Additionally, these same checks can be applied during runtime as newly proposed assemblies of contracts are evaluated.
An advanced discovery feature that will ultimately be implemented enables searching for compatible contracts and assembling a new composite contract from of other contracts. With the formal verification techniques, the author of the new contract can be guaranteed that when working contracts are plugged together they will also work together.
Nodes that take on the validation role have the function to achieve consensus on the blockchain state. Validators also assure a blockchain is self-consistent and hasn’t been tampered with and protect against Sybil attack.
The Casper consensus protocol includes stake-based bonding, unbonding, and betting cycles that result in consensus. The purpose of a decentralized consensus protocol is to assure consistency of blockchains or partial blockchains (based on shards), across multiple nodes. To achieve this any consensus protocol should produce an outcome that is a proof of the safety and termination properties of class of consensus protocols, under a wide class of fault and network conditions.
YOURChain’s consensus protocol uses stake-based betting, similar to Ethereum’s Casper design. This is called a “proof-of-stake” protocol by the broader blockchain community, but that label leads to some misperceptions including overstated centralization risks. Validators are bonded with a stake, which is a security deposit placed in an escrow-like contract. Unlike Ethereum’s betting on a whole blocks, YOURChain’s betting is on logical propositions. A proposition is a set of statements about the blockchain, for example: which transactions (i.e. proposed state transitions) must be included, in which order, which transactions should not be included, or other properties. A concrete example of a proposition is: “transaction t should occur before transaction s” and “transaction r should not be included”. For more information, see the draft specification Logic for Betting on Propositions (v0.7).
At certain rendezvous points validators compute a maximally consistent subset of propositions. In some cases, this can be computationally hard and take a long time. Because of this a time-out will exist, which, if reached forces validators to submit smaller propositions. Once there is consensus among the validators on the maximally consistent subset of propositions, the next block can easily be materialized by finding a minimal model under which the propositions are valid.
Because of this design and because of the concurrency enabled by sharding of the address space, consensus can be reached for a huge number of transactions at a time.
Let’s walk through the typical sequence:
For additional information, see:
Similar to other decentralized implementations, this component handles node discovery, inter-node trust, and communication.
A number of other platform-level protocols will be developed, such as those related to security, node trust, and communications.
The current "YOURChain 1.0" technology stack delivers a decentralized CDN. Its primary component is SpecialK, which sits on top of MongoDB and RabbitMQ to create the decentralized logic for storing and retrieving content, both locally and remotely.
SpecialK implements distributed data-access patterns in a consistent way, as shown below.
With the YOURChain platform, the implementation of the CDN will also evolve, although not in its fundamental design.
This layer will track access and storage of content. Software clients will be required to pay for creation, storage, and retrieval of all content delivered to/from the CDN, via microtransactions. Since storing and retrieving content is not free, why should a technical solution make it free to users like centralized solutions that subsidize the cost in indirect ways? With the promise of micropayments, the YOURChain platform can more directly charge for the storage and retrieval of content.
From a user-centric perspective, this economy aims to directly but unobstructedly allow value to be placed on the content’s creation, consumption, and promotion. This applies to many types of content. For example, a short textual post is created, sent to an initial distribution list, read, promoted (liked), and made available to even more readers. Or, a short movie can go through the same workflow. Along these paths, attention is given, and rewards can flow back to the content originator and to promoters. Based on one’s own engagement with the content exchanged to/from one’s connections, each connection’s reputation is computed. The reputation rank can be used subsequently to present content in a manner consistent with how the user has demonstrated attention in the recent past.
Any number and variety of applications can be built on top of the YOURChain Platform that provide a decentralized public compute utility. These include, for example:
The purpose of this next discussion is to illustrate how namespaces allow for heterogeneous deployment of contracts and contract state. Namespaces is one of the crucial features for sharding, and with that we get the benefits analogous of sidechains, private chains, consortium chains, as well as the distinction between test and production, all under one rubric.
For example, the following diagram depicts some of the possible development, test, and deployment configurations and considerations, and how release management is enabled using namespaces and sharding.
We’ll collaborate with IDE tool vendors to integrate URlang and validation tools.
Governance
Like other open source and decentralized projects, and especially those involving money and blockchains, the YOURChain Platform components will require they be created, tested, released, and evolved with great care. YOURChain’s leadership fully intends to help define these governance processes and to empower a public community to enforce them.
The YOURChain roadmap is currently being developed. Major milestones may include the following:
Programming model and execution
URlang 1.0
URVM 1.0
Blockchain I
Blockchain II
Content delivery
Attention economy
We invite you to participate in YOURChain's Slack channels, joining via http://YOURChain.slack.com.
We need a variety of talent, but most urgently programmers with solid computer science, formal methods, and ideally experience with mobile process calculi and functional programming. Or, individuals who can demonstrate their ability to quickly learn these disciplines.
We need investors to help fund the building out this architecture. Note that there are many forward-looking statements in this document, and are subject to many risks. Contact the YOURChain team at [email protected] for more information.
This document is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0)
https://creativecommons.org/licenses/by/4.0/
The technology stack has a variety of licenses as visible in GitHub. These are primarily Apache 2.0.
