Introduction
Public blockchains are mechanisms through which networks can maintain decentralized consensus over a shared state. Typically, this state holds, among other data, a payment system. The stake held by participants in the resulting economy works as their incentive for making the state widely available to others and for rejecting invalid transactions. In this virtuous cycle, the payment system is built on top of the decentralized consensus, which only functions due to incentives created by the payment system itself. Both the payment system and the consensus can then be used for other purposes.
As new applications for blockchain technology are envisioned, the demands on the underlying infrastructure are constantly increasing. At the moment, the two major obstacles to widespread adoption of blockchain technology are its poor scalability and lack of a solid development environment. The main contribution of Cartesi to the blockchain ecosystem is overcoming both these issues.
Scalability Currently deployed consensus mechanisms are based on full redundancy [Nakamoto 2009; Wood 2018]. They require every transaction to be stored permanently and to be validated by every participant. This inefficiency is the key limiting factor to the growth of the transaction rate, the amount of data involved, and the intensity of computations within transactions. High transaction costs and increased latency have become a barrier to many innovative applications that would otherwise benefit from the flexibility that smart contracts bring to the blockchain.
Attempts to improve blockchain scalability can be divided into layer 1 and layer 2 solutions. Layer 1 scalability solutions change the underlying blockchain infrastructure itself. Examples include the optimization of block sizes, sharding, and Delegated Proof of Stake (DPoS). Because they operate at the infrastructure level, these solutions are burdened by the requirement of preserving global consensus. Certain aspects of the state, such as the payment system, are of critical importance to all parties and therefore require global consensus. Otherwise, for most interactions mediated by the blockchain, it is perfectly safe to limit access and verification responsibility to the few parties that can potentially be affected. The blockchain can then be used to provide finality and to guarantee local consensus in the rare occasions where a dispute arises between these parties. In other words, global consensus is a precious resource that should be used with parsimony. In recognition of this fact, layer-2 scalability solutions such as plasma, side chains, TrueBit, or state channels move as much data and computation as possible off-chain. Layer-1 and 2 scalability solutions are discussed at some depth in section 2.
Computation environment Every computation that can influence a transaction, whether performed on-chain or off-chain, must be reproducible by all parties playing a validating role. Reproducible computational models must be self-contained and deterministic. In other words, the complete state for the computation and the entire sequence of modifications to this state must be fully specified and agreed upon. Sadly, real computing architectures were not designed with these constraints in mind, and therefore are not reproducible. Blockchain platforms solve this problem by employing custom virtual machines (VMs) when processing smart contracts. These VMs are reproducible, but also domain specific. On the one hand, they offer native support for features useful to smart contracts (e.g., accounting, rollback, associative memory, authentication, cryptography etc). On the other hand, they lack valuable features found in general-purpose architectures (e.g., floating-point arithmetic, virtual memory, interrupts etc).
The revolution in software capability the world experienced over the last few decades can be attributed to two key factors. The first is an exponential increase in the speed at which modern hardware platforms can process vast amounts of data. The second, and equally important, is the ever-increasing expressive power of software development environments. Indeed, general purpose computations do not happen in isolation. Rather, they are assembled from inter-dependent building-blocks created by a worldwide collaboration of software developers. These components and services rely on standard-library facilities hosted by an underlying operating system (memory management, process management, file systems, networking, etc). It is the operating system that ties everything together. Such facilities are not available from the free-standing programming languages and compilers that typical blockchains offer to smart contract developers.
Reproducibility and scalability concerns have made on-chain computation environments very restrictive. To boost productivity and widen the scope of blockchain development, we need a reproducible computation model that supports modern operating systems.
The work most closely related to Cartesi is TrueBit [Teutsch and Reitwießner 2017]. The connection between Cartesi and Truebit comes from the fact that both technologies move intensive computations off-chain and then, within the blockchain, use a verification game [Feige and Kilian 1997] to efficiently settle disputes regarding the results of these computations. Despite this similarity, many other design decisions set these two technologies apart.
TrueBit is based on WebAssembly [2018], a VM ISA designed by a W3C Community Group to support efficient web applications.1 In contrast, Cartesi is based on RISC-V [Waterman and Asanovic´ 2017a,b], an open ISA designed in UC Berkley for implementation by native hardware. The WebAssembly and RISC-V ISAs are of similar complexity. The key difference is their position in relation to applications and the operating system. WebAssembly was designed to sit between applications and the underlying operating system. RISC-V is instead meant to sit under the operating system and the applications it supports. TrueBit’s choice is consistent with a focus on extending the computational power of smart contracts, which tend to operate under severely restricted environments. Real-world applications, however, cannot exist in isolation. They depend on rich, complex run-time environments that are invariably built on top of a modern operating system. To give developers of decentralized 1It was originally based on the LLVM back-end for an obscure Myricom NIC embedded processor design used internally at Google applications access to the tools, libraries, services, and software they are already familiar with, Cartesi chose to support Linux. A realistic ISA, such as RISC-V, is much better suited for this purpose.
One of the differences of greatest consequence is in how Cartesi aligns the interest in off-chain computations with the responsibility for their execution. In TrueBit, there is no such alignment. A smart contract posts the computation to a pool of untrusted parties and waits for one of them to perform it off-chain and post the result back. In this sense, TrueBit can be seen as a means for increasing the computational power of individual smart contracts. Cheating is prevented with a complex incentive layer that rewards pool members for successively disputing incorrect results. To keep the members engaged, computations with incorrect results must be artificially injected by the incentive layer. This inefficiency is a fundamental part of the design of TrueBit. Conversely, Cartesi can be seen as a way for off-chain computations to be endorsed by a smart contract. All parties that could be affected by this endorsement are responsible for performing the computation off-chain and, if needed, starting a dispute. Although the ensuing verification can be outsourced to a dispute resolution market (see section 6.2), there is no built-in inefficiency and no need for an incentive layer.
The large storage requirements of real-world computations pose a significant challenge that TrueBit does not address. Explicit representations of code and data do not fit within the blockchain. Instead, a Cartesi Machine, together with its code and data, are represented on-chain by a hash of its state. This arrangement allows for complex transactions built from several rounds of off-chain computations to be fully specified. The states themselves are only ever known explicitly off-chain, by interested parties. Some applications can face data availability issues to which Cartesi offers a range of original solutions [Teixeira and Nehab 2019a]. Finally, Cartesi is committed to making off-chain computations portable across different blockchain platforms.
Real world computations meet the blockchain.
Intensive computations require a realistic platform. Cartesi enables external computations to run on a RISC-V processor under a deterministic Linux operating system. Developers can use all the tools, libraries, and services they are already familiar with.
Portable across multiple blockchains.
Smart contracts running on different blockchains can formulate external computations in the exact same way in the Cartesi Node. This isolates complex computations from the details of specific blockchains, making them portable and providing security, immutability, and a payment system.
Guaranteed consensus.
External computations can be verified externally by all involved parties. Disputes are settled automatically by Cartesi. This requires negligible computation inside the blockchain, regardless of the size of the external computation.
How Cartesi Can Help Change the World
Truly Own Your Game.
Cartesi will unleash vast new possibilities for blockchain games. Developers will be able to use the tools, libraries, and engines that can be compiled for Linux. Additionally, game processing will be free from the limits of blockchains without the need to sacrifice decentralization. Envision trustless global participation across multiple games.
Discovering the Unknown.
Outsourced computation will allow for millions of users to lend their idle computing power. This will benefit scientific research, 3d rendering, video transcoding, and many other computationally intensive tasks in a totally trustless way, without reputation systems.
Decentralized Data Science
Cartesi's verifiable computation paves the way for decentralized data scientist marketplaces. Businesses can outsource optimization tasks to experts whose jobs will be compensated if and only if they are computationally proven to be correct. Imagine optimizing the use of transport based on packages to deliver, their sizes and where they have to go.
Finance. The Next Level.
Cartesi applications will be able to read and do complex calculus involving data from multiple blockchains. This will enable interoperability between blockchains and services such as futures and insurance markets.
Efficient AI, by AI.
A trustless marketplace for AI and computational tasks. With the power of Cartesi’s decentralized automated verification, developers will be able to create services that allow new DApps to outsource and distribute work. These include machine learning, data analysis, or computationally intensive tasks that require experts in the field. This opens new possibilities for lower cost AI, developed by outsourced experts and bots.
Cartesi Machines In The Blockchain
Recall that Cartesi is a platform for the development of decentralized applications. Cartesi DApps enable parties that do not trust each other to enter into a binding contract in the blockchain that depends on the results of off-chain computations. It is convenient to use the characters Alice and Bob to represent these parties. Note that Alice and Bob are roles, not people. They may even represent competing collective interests. In fact, both roles will be played automatically by Cartesi Nodes that defend the interests of whomever controls the off-chain computer where the node runs. Cartesi DApps are therefore a collaboration between a set of smart contracts running in the blockchain, and the off-chain software running on Alice’s and Bob’s nodes. As a general rule, the same DApp developer is responsible for the smart contracts and the Dapp specific off-chain software. The role of DApp developer will be played by Charlie. Alice and Bob trust Charlie, otherwise they would not engage with his DApp. Charlie, however, trusts neither Alice nor Bob. Naturally, Alice and Bob do not trust each other either.
Cartesi’s role is to support Charlie’s work. To that end, Cartesi offers a variety of primitives that Charlie uses to mediate the potentially adversarial interactions between Alice and Bob. Some primitives require no interaction, and can be evaluated autonomously in the blockchain from their inputs. The interesting primitives, however, are those that, though completely defined by their inputs, can only be evaluated off-chain. By construction, when using a Cartesi DApp, Alice and Bob always agree on the inputs to such primitives. Without loss of generality, Bob evaluates the primitive off-chain and submits the result. Alice is then given the chance to accept or reject Bob’s result. Undisputed results can be used by Charlie’s DApp for the purpose of his choice. In case of rejection, Cartesi engages with Alice and Bob in a dispute resolution protocol that arbitrates in favor of the party with just cause. This adjudication always completes within a few interactions and at a negligible computational cost to the blockchain. Cartesi automates most of this process in a way that is extremely convenient to Charlie.
The most important of these primitives is the Cartesi Machine. Smart contracts cannot afford to store the states for a Cartesi Machine within the blockchain, let alone perform the implied computations. After all, the costs in terms of processing power and storage capacity would both be prohibitive. To solve these problems, Cartesi uses cryptographic hashes to concisely represent machine states in the blockchain. From the blockchain’s perspective, a computation is simply a pair of hashes corresponding to the initial and final states of the machine. The contents of the memory subtended by such hashes are known only off-chain. Cartesi defines a variety of additional primitives that allow smart contracts to conveniently manipulate the contents of the states corresponding to these hashes.
Future Work
The focus of this document on the core functionality, and on the interfaces DApps use to directly specify, control, and verify off-chain computations. The Cartesi platform will offer several additional components built over the core, or extending its reach. These will be described in more detail in future publications [Teixeira and Nehab 2019a,b].
Data availability Cartesi remedies the severe storage limitations of the blockchain by keeping on-chain only Merkel tree hashes of off-chain data. As mentioned in section 5.2, Cartesi assumes that all parties involved in a verification role have access to these data. In certain applications, this is difficult to guarantee. In particular, the risk for data withholding attacks, where one of the parties submits a hash to the blockchain while refusing to make this data available to others, must be mitigated.
The problem of data availability is a major concern in the design of blockchain consensus algorithms [Buterin 2012]. However, the issue becomes much simpler in the context of local consensus. Teixeira and Nehab [2019a] provide several design patterns for dealing with data availability during verification. Data channels, device encryption, and the data ledger ensure availability in all scenarios likely to be encountered by Cartesi DApps.
Usability One of the key barriers to the wide adoption of blockchain technology is the inconvenience experienced by DApp users. Although the literature on usability of centralized applications still applies to decentralized ones, blockchain idiosyncrasies have not yet been fully addressed from the perspective of user experience. Teixeira and Nehab [2019a] describe several design patterns for the development of simple and intuitive DApps.
As an example, Cartesi will offer an automatic infrastructure for trading tokens. This will free the users from concerns over the different tokens used inside each DApp. A system for outsourcing deferred actions will also be provided. This will enable users to turn their machines off even when engaged in a protocol that requires interacting with the blockchain within strict deadlines. In this situation, a proxy party will act on the users’ behalf in exchange for a fee. (Much like the dispute delegation market described in section 6.2.) The use of cryptographic time-locks [Rivest et al. 1996] will also accommodate situations in which the user must reveal a secret in the future that should not be immediately passed to the proxy party. Other usability constructs will be described to facilitate file transfers and reduce gas costs. Together, these facilities will bring the user experience of Cartesi DApps closer to that of current centralized solutions.
The Cartesi SDK A variety of higher-level APIs that encapsulate typical uses for the core will be available with the release of the Cartesi SDK. These will include the usability and data availability solutions described above, as well as the containers for the Cartesi Node and for the development of Cartesi Machines. In time, the APIs available within the SDK will greatly reduce the size and complexity of DApps blockchain components. In turn, this will significantly increase the portability of DApps to multiple blockchains. The Cartesi SDK will be distributed in open source and extensively documented [Teixeira and Nehab 2019b].
Extensions to the Cartesi Machine Cartesi Machines can be extended with two exciting new devices. The dehashing device gives applications the power to traverse hash pointer data structures. Programs running inside a Cartesi Machine can use the dehashing device to read the contents of a block given only its hash. Although this operation is impossible in general, it becomes possible when the universe of allowed blocks is known by all parties in advance. The most direct application is to blockchains themselves. When a Cartesi Machine is running, the dehashing device queries a hash table, preloaded in the host, for the block that matches the hash. If a dispute arises, any party can propose the block as proof it matches the required hash. In this way, the dehashing device enables blockchain introspection. Parties can enter into contracts that depend on the entire state of the blockchain where the contracts are themselves defined. This has a variety of valuable applications, notably in futures markets.
Another planned device is the timely data port. The port enables reproducible communication between Cartesi Machines by tying the data packets entering or leaving the machine to the value of mcycle at the event. DApps can schedule packet delivery to happen at a given future mcycle. Cartesi Machines can also be rolled back to the mcycle for delivery. The timely data port breaks new ground in the progress towards the Web 3.0. It will enable DApps that involve the direct collaboration between multiple Cartesi Machines.
Crowd disputes It is possible to envision applications that involve many independent participants, each with some stake in the results of an off-chain computation. In such cases, it is vital to prevent a coordinated crowd of dishonest participants from using sequential disputes over an honest result as a denial-of-service attack on the contract. We have developed a variant of the verification game that enables any honest participant to defend his result against an entire crowd at negligible cost. When demand becomes apparent, the Cartesi platform will be extended to support this variant.
Cartesi Roadmap
The Road to Cartesi
Reproducibility
Our MVP is a state of the art deterministic VM. It enables smart-contracts to specify complex computations that run off-chain on a Linux OS in a reproducible way.
Verifiability
The complete Cartesi Core allows these complex computations to be adjudicated for correctness on the blockchain, at negligible cost, in a safe and decentralized way.
Infrastructure
Cartesi will publish and maintain an open source SDK for the world to use. Create your own decentralized applications without knowledge of blockchain languages and deploy them to the growing network of Cartesi Nodes.
Conclusions
This paper laid the foundations on which the Cartesi platform stands. Cartesi’s mission is to help DApp developers build ever more compelling products to their clients. As any paradigm shift, the blockchain brings both opportunity for real innovation and the risk of “wheel reinvention”. In a direct application of the principle of least astonishment, Cartesi’s core enables developers to leverage preexisting knowledge and tools to boost their productivity. The remaining components of the Cartesi platform, described in a future document [Teixeira and Nehab 2019a], will help developers unleash their creativity when taking advantage of the blockchain’s unique potentials.
Author: Kevin Park
My Email: vanhoenhaim99@gmail.com
