In June 2020, Compound issued its token COMP, igniting a yield-farming mania. DeFi users flooded Ethereum with transactions, and the network quickly reached capacity, leading to skyrocketing fees and, consequently, a process of gentrification. For weeks, the blockchain was unusable for most DApps, making it clear one more time that fixing scalability is urgent for the sustainability of Ethereum’s ecosystem.
Meanwhile, the Ethereum Foundation has been hard at work to make sharding available on Serenity (Eth 2.0) and, through that, raise the transaction throughput to higher levels. However, due to a hefty technological challenge, full-fledged sharding with support to smart contracts isn’t coming anytime soon.
As the scalability improvements on layer-1 cannot match Ethereum’s user base and the DApp ecosystem’s vigorous growth, Vitalik has been keen to propose rollups as the weapon developers need to defeat massive gas fees and perform better.
Rollups came out recently as a more promising approach to scaling than plasma, an earlier notorious layer-2 approach to scale Ethereum. The reason is that rollups solve a fundamental problem of data availability inherent to plasma and other layer-2 designs. With rollups, all transaction data is bundled up (rolled up) and made available on Ethereum itself in a cheaper way than they would typically be for a regular transaction on the blockchain. Besides, the bulk of the computational load goes off-chain, making for large gains in throughput and transaction cost-efficiency.
Why Cartesi Rollups is unique
Cartesi’s core technology relies on its virtual machine that emulates a RISC-V ISA, called the Cartesi Machine. It has been designed to run computationally-intensive decentralized logic off-chain, on a Linux environment. Cartesi Machines are self-contained and reproducible. They are also transparent, meaning that they expose their state for external inspection through succinct Merkle tree proofs.
The Cartesi team is currently working on an update of its system to support Optimistic Rollups with interactive dispute resolution. Our implementation contributes directly to smart contract scalability’s pressing issue, especially by running off-chain heavy computation that would be impossible to run on-chain. One can expect million-fold computational scaling without loss to the strong security guarantees of Ethereum.
On its own, that would be useful enough. But something else makes Cartesi’s system remarkable. With Cartesi Rollups, smart contracts run off-chain on Cartesi Machines. Since these support Linux, developers have the option to dispense with Solidity and the limitations of the EVM to create smart contracts with myriad mainstream software stacks, toolchains, standard libraries, file systems, and other OS resources. Running smart contracts on a deterministic Linux runtime has never before been possible. For the first time, developers will have an entire operating system for smart contracts.
We believe this represents more than an incremental improvement to decentralized applications. Instead, we see it as a necessary step toward the maturity of the whole blockchain ecosystem. Allowing mainstream programmability means that DApp developers have an entirely new expressive power to create from simple to rather complex smart contracts. It also means opening the doors for extensive adoption of regular developers who have never programmed for blockchain, as they will create decentralized applications with a coding experience similar to desktop or web.
A quick introduction to optimistic rollups
Rollups are a class of Layer-2 solutions initially proposed to scale Ethereum. Transactions are aggregated and cheaply submitted in batches inside a smart contract while all processing they entail goes off-chain. The results of such transactions are later settled on-chain, with virtually no loss to the strong security guarantees of the blockchain.
There are two classes of rollups. On one side, we have the ones based on validity proofs (ZK-rollups). On the other, the ones based on fraud proofs (optimistic rollups). In this article, we describe a variant of optimistic rollups with interactive dispute resolution. In particular, we dive into Cartesi Rollups and its ability to support complex smart contracts running directly on a Linux runtime environment.
Let’s start with an overview of optimistic rollups’ design. At runtime, users of a rollups application initially deposit their cryptoassets on a particular smart contract on layer-1 (henceforth called portal), giving them an initial state and funds on layer-2. With that done, they can begin to send messages to the layer-2 contract, advancing its state accordingly.
From time to time, the layer-2 contract state must be reflected and finalized on layer-1, typically implying a redistribution of tokens among the involved users. For that, one of the validator nodes places a state claim on-chain, with all involved parties remaining optimistic, hoping that the claim is true. When the claim is placed, a challenge period starts, allowing enough time for any other validator node to verify it and send a fraud proof on layer-1 in case of disagreement. If no other validators submit any challenge, the blockchain takes the original claim as finalized.
However, if a transaction containing a fraud proof is submitted, the blockchain adjudicates the dispute and ensures the correct claim is unequivocally finalized on-chain.
Cartesi is implementing a variant of optimistic rollups featuring interactive dispute resolutions. Here, the blockchain mediates a verification game between the claimer and challenger nodes until it finally reveals one of them as deceitful. The verification game algorithm itself is outside this article’s scope, but you can read about it in Cartesi’s tech paper.
Optimistic rollups with interactive disputes allow for immense scalability gains, as an application-specific set of validators can execute heavy computational tasks. That is the opposite of what happens on a blockchain. On the blockchain, each node needs to emulate the state transitions of all existing applications. In effect, moving smart contracts to layer-2 on optimistic rollups is akin to having an application-specific layer-2 shard.
Notice that some rollup implementations would typically support a multi-application shard. In the case of Cartesi, each smart contract running on layer-2 does it on its own shard, not only for performance but also for security reasons. We will have a dedicated piece about security, to be published in the near future.
There is one caveat. The scalability gain of optimistic rollups, be it with or without interactive disputes, comes at the cost of delayed finality on layer-1. Such delay to finality brings about a problem of capital efficiency, as users need to deal with long settlement times on the blockchain, which can last for several weeks when disputes happen.
Notice that the layer-1 settlement latencies do not impair users’ experience as they interact with the system on the second layer. The reason is that honest validator nodes can keep advancing the contract state despite the latencies on layer-1, knowing that the system will finalize correct state transitions on-chain, given enough time.
In any case, capital efficiency on layer-1 remains an important problem that needs to be addressed and, fortunately, some strategies do mitigate the problem. One possibility is to use liquidity providers. Another one is through a specific node setup trade-off that virtually eliminates the problem, which we discuss in more detail below.
Application shards
On Ethereum, the EVM is meant to process all transactions involving every smart contract deployed on the network. This is fundamentally different from Cartesi Rollups, in which Cartesi Machines are meant to specify and execute individual layer-2 contracts independently. It means that each machine validates a single contract, and each contract has its exclusive set of validators, effectively creating a single-application layer-2 shard.
This design allows for massive gains of smart contract scalability. We can have orders of magnitude of higher computational throughput without compromising the strong security guarantees of Ethereum, provided that at least one validator is honest and available to engage in disputes in the face of false claims.
Cartesi Machines running separate layer-2 contracts can interact with each other only through regular inputs and outputs, with these interactions being mediated by a special hub which we will discuss in detail in a future publication.
Contract execution
On Cartesi Rollups, contracts run on an environment that is as non-opinionated as it gets. The Cartesi Machine is a general-purpose VM that emulates an open-standard hardware architecture and runs the most pervasive open-source OS in the world. It doesn’t force developers to use any particular language, software stack, or a specific API, for that matter. Instead, they are free to make their choices of design and software components when they code their layer-2 smart contracts.
This has profound implications. Cartesi releases Ethereum smart contracts from the idiosyncrasies of Solidity and the limits of the EVM, granting mainstream productivity to DApp developers.
At this point, it is useful to reframe the term “layer-2 contract”. Whereas, in the context of the EVM, smart contracts have a well-defined and widely-understood meaning, here “layer-2 contract” means any program that processes input and creates output. This program can be even implemented as one or many processes involving multiple servers and services running on the Cartesi Machine. Even with the use of software threads and highly complex logic involving floating-point, the reproducibility of the program is ensured because Cartesi Machines are deterministic.
With that distinction clear, let’s get back to how the protocol works. Users begin by sending messages to the layer-2 contract, either by pushing them directly on the blockchain or using an aggregator service. In any case, the messages get to a definite order and remain available on-chain.
From time to time, validators retrieve a batch of such messages and send them to the Cartesi Machine, via an input “flash drive”. The layer-2 contract then reads the input payload, parsing and processing it according to syntactic and semantic choices determined by the developer. It’s also up to the developer to adopt their preferred API standards. For example, a group of developers may choose to encode messages directly in HTTP requests to be processed by a web server running in the Cartesi Machine. Another group may prefer to encode messages as gRPC calls to another server. Both groups of developers would have access to all support software that runs on Linux when implementing these transport mechanisms.
The processing of each message advances the layer-2 contract’s state and at each of these state transitions, the layer-2 contract may write data to the machine’s output “flash drive.” As the machine runs all the messages in the batch, the machine state at the end of processing and corresponding outputs are summarized in a Merkle tree, and its root hash is sent to the blockchain.
As explained above, at any state transition when the layer-2 contract processes a message, it may write data to the machine’s output “flash drive.” The data may contain logs as well as layer-1 bytecodes.
Logs correspond to any data that is relevant to client applications but do not have any effect on-chain. In contrast, layer-1 bytecodes are EVM bytecodes that the client application or some user needs to execute on-chain at some point in the future. In the simplest scenario, the bytecode can perform simple asset transfers, but they can also call other layer-1 smart contracts and be as complex as the application requires. It’s through layer-1 bytecodes that layer-2 states are reflected and finalized on-chain.
This means validators themselves do not release funds on the blockchain. Instead, users send a request to the layer-2 contract, the layer-2 contract decides if the withdrawal is warranted and, if so, outputs the corresponding bytecode. Then users send a transaction themselves on Ethereum to the I/O Manager, which is Cartesi Rollup’s layer-1 contract responsible for executing a bytecode.
For example, a user that wishes to withdraw ERC20 tokens to their wallet would send the I/O Manager a bytecode that performs the token transfer. Along with the bytecode, they would also send the Merkle proof that such bytecode is part of the Merkle tree represented by the output hash finalized on-chain.
Notice that the party trying to execute the bytecode must wait for the output hash to be considered final by the blockchain, or the I/O Manager rejects the attempt to execute the transfer.
To better understand the whole process on a timeline, we describe how the system schedules different rollups’ phases.
Cartesi splits the execution timeline of layer-2 contracts into epochs. On a given epoch N, the involved validator nodes batch all the input messages that were enqueued on-chain from the beginning of the previous epoch’s processing slot until the beginning of the current epoch’s processing slot.
The nodes then process every message of the batch through the Cartesi Machine, producing an output hash that summarizes the state transition of the entire epoch. Then, one of the validators, henceforth called claimer, places on-chain the hash representing the layer-2 contract state at the end of epoch N, S(N).
After a challenge period is over, if there was no dispute, S(N) is assumed final by the system. Otherwise, disputes will follow until the correct state claim represented by its output hash is enforced. The settlement period displayed on the diagram above accounts for a challenge period, with or without disputes.
To guarantee a minimum duration for each epoch, the rollups protocol also requires an accumulation slot. This is a minimal latency imposed on on-chain finalization to prevent frequent claims being sent to layer-1, for the sake of Ethereum fee cost-effectiveness. It is up to the rollup developer to set the accumulation slot period, depending on how they want to balance latency to finality and security.
Committee of validators
In later versions, Cartesi Rollups will allow for any number of validator and non-permissioned nodes, with more details to be released in a future article.
In its first version, Cartesi Rollups will allow developers to select a committee of validator nodes. They define the node-running organizations they prefer and pay a fee to each of them to provide the service. Selected organizations then instantiate a validator node and download a Cartesi Machine template that has all the environment, configuration and the software that comprises the layer-2 contract. With the validators ready with their contracts and online, they will work proactively to ensure correct state transitions to their users. The committee of validators provides any-trust guarantee, meaning that as long as at least one validator is honest and vigilant, correct state transitions and asset withdrawals are finalized on-chain.
In fact, the committee of validators brings exciting advantages compared to the original optimistic rollups setup. First, a committee-based contract can have all its validators proactively submit their claims as soon as possible. Once all the nodes immediately place the same claim, they render the rest of the challenge period unnecessary, eliminating the long latencies to finality and the problem of capital efficiency.
In the worst-case scenario, there will be up to N-1 disputes for N validators disagreeing with each other, potentially taking weeks to settle. However, for practical purposes, this situation should rarely (if ever) happen if the selected node runners care about their money and reputation.
Therefore, in exceedingly rare circumstances, contracts suffer from delayed finality. That could be attributed to technical difficulties, such as due to offline nodes that cannot confirm a claim in time. Or to malicious operation, which would end up cleared throughout the dispute resolution protocol, with the dishonest node runner identified and penalized.
In any case, Cartesi Rollups do not depend on subjective reputation systems. The system itself always identifies malicious nodes. The transparency provided by the system makes the node runners accountable for any wicked behavior or poor performance. Wrongdoers can be just filtered away from front-end applications like the Cartesi Explorer. Thus, the incentive validator institutions have to act maliciously or negligently tends to be low due to reputation or legal risks.
The second positive aspect relates to privacy. Governments and enterprises can set up permissioned networks with Cartesi Rollups, holding the benefit of concealing sensitive data from the rest of the world, as Cartesi Contracts only expose to layer-1 the information they want. That is because Cartesi Machines can use cryptographic keys that allow them to read encrypted input messages that are sent to the blockchain. From the outside, nothing is leaked other than the side effects in layer-1. Only authorized parties would have access to the layer-2 contract, given that the set of validator nodes is permissioned.
Now, we see in more detail how the behavior of validator nodes impacts the settlement period. The most efficient setup eliminates the long finality delays involved in optimistic rollups designs. All validators proactively place their claims, and they all agree with each other. That can happen quickly, with all claims possibly entering the same block on layer-1, adding no delay to finality.
However, one or more validators may eventually fail to submit their claim promptly. In that case, the portal needs to wait long enough to either collect the missing claims or expire the challenge period. Let’s say one or more validators fail to present their claims, but at least all the submitted claims match. After the challenge period is over, the portal takes the claim as final.
Yet, another possibility is that the portal collects one or more conflicting claims during the challenge period. In that case, If we have N claims, in the worst-case scenario, we would have N-1 disputes to be executed in series. In that case, the honest claimer would win any verification game against any other node and have its claim finalized on-chain.
Still in the context of the validator committees, Cartesi Rollups will support two classes of nodes: validators and observers. We explained in this section that contracts would run on a small set of validators, which are the nodes that must send outputs back to layer-1, making claims or initiating disputes. In contrast, observer nodes participate in the layer-2 consensus by sending or reading messages and advancing their contract state but have no permission to place claims or initiate disputes. Observer nodes exist for the convenience of client applications and their users and can be directly run by users or by third-party.
Collaterals and node marketplace
When considering validator committees, institutional validators that don’t run their nodes correctly can be penalized in several ways.
First, they would have their reputation tarnished by a permanent record of their misbehavior. Since this information is publicly available throughout the blockchain network, legal action might be taken in some instances, using blockchain historical trace as proof in court.
Additionally, Cartesi Contract developers can define an arbitrary collateral amount that nodes must deposit when they are hired. When nodes enter into a dispute, whoever loses it has their collateral seized by the portal. This is yet one more mechanism available to disincentivize misconduct, which developers are encouraged to use.
Cartesi is creating a marketplace for node runners. Node runners can determine and charge a fee in CTSI to validate computation and produce claims at each epoch. Developers also express the maximum they are willing to pay for each of their validators besides the required collateral deposit.
We will elaborate on the full economy governing collaterals and the validator marketplace in a separate article.
Want to discuss Cartesi Rollups? We highly encourage any developer willing to use or collaborate with Cartesi to contact us on Discord. See you there!
Cartesi’s Ecosystem Links:
Website: https://cartesi.io
Explorer: https://explorer.cartesi.io
Discord (Development Community): https://discordapp.com/invite/Pt2NrnS
Twitter: https://twitter.com/cartesiproject
Telegram: https://t.me/cartesiproject
Telegram Announcements: https://t.me/cartesiannouncements
GitHub: https://github.com/cartesi
