Blockchain technology is on the verge of revolutionizing applications. More and more projects are now familiar with the need for modularity and specialization. Various types of Layers emerging in an endless stream are shifting their focus to the availability of data, with the purpose of supporting data of higher order of magnitude.
At the same time, the execution environment and computing layer that plan to expand computing power through Rollups (Optimistic, ZK, or Sovereign) have the responsibility to match the increased data capacity and provide a sufficiently powerful infrastructure to develop practical applications.
The setting that brings the most gains in terms of computational scalability can be given by Optimistic Rollups for a specific class of applications with interactive dispute resolution. At the same time, computational scalability can greatly increase the programmability and the possibility of improving tools.
Cartesi has chosen this path to provide developers with a more convenient way to develop and potentially build powerful smart contracts using real-world operating systems running existing open-source libraries and components.
Status of the Rollups system
The multiple technical challenges faced by blockchain DApps come to the fore when we analyze their code bases from a software engineering perspective. Some well-designed projects like Uniswap balance several competing goals: monetary value to users, minimal gas consumption, and security. Applications that fail to meet these criteria limit their usage base, put users at risk, or lose out in the fierce competition for blockchain interaction. This situation is not suitable for applications and hinders innovation.
Additionally, the user experience of coding smart contracts is significantly limited compared to traditional Web 2.0 backend services. It is true that there is a considerable generational gap between the functionality of traditional web servers and blockchain smart contracts.
Ethereum and EVM Rollups are decentralized computers that force you to deal with the above aspects. They are extremely slow and "specialized computers" that require developers to code in specific programming languages.
In this odd setup, developers focus on overcoming these limitations instead of optimizing their core solutions. The result is usually unnecessary, very complex code around simple and limited functionality.
Scalability Concerns: Securing Specific Application Rollups
Everyone needs to validate all networks, which is not sustainable for mass adoption. In the global consensus, the increase in demand inevitably leads to an increase in block space, which in turn leads to vicious competition among various applications. This situation will instead generate high costs, which constitute more and more entry costs for project parties and users. In order to solve this problem, Ethereum has undergone a transformation and proposed a roadmap centered on Rollups.
The scalability issues mentioned in the new plan include two main aspects: data scalability and computing scalability. The difference between the two is often overlooked because they are currently at the same gas cost. However, it is by differentiating them that Ethereum has its current roadmap.
Post-merger, with the development of EIP-4844 and sharded Ethereum, the cost of adding data to its blockchain will be orders of magnitude lower. Meanwhile, computing scaling has been entrusted to the Rollups project (named rollup-centric).
The relationship between the Ethereum protocol and the Rollups solution hides an underappreciated problem. EVM-compatible Rollups are not the best design for improving computational scalability to match Ethereum's implementation of data availability.
EVM-based Rollups can be described as computing shards. As more and more applications are gradually deployed and share the same virtual machine, this design flaw will appear. A zero-sum game of competing for virtual machine CPU capacity leads to high-end problems. Only a small fraction of applications are available on each shard, and other users are phased out. These networks can become extremely congested and expensive.
Fortunately, Rollups can now be understood and used differently. You can forego shared virtual machines and let applications have their own CPUs and ultra-high-performance computing available. Asset settlement, composability between applications, and dispute resolution can be delegated to a common base layer. This design is called application-specific Rollups.
Application-specific Rollups’ private consensus pegs into the base layer, allowing its validating nodes (whether allowed or not) to preserve the security guarantees of its settlement layer. In other words, having a base layer enables a 1-of-N security model where any honest verifier can, with the help of the base layer, execute the correct outcome independently of cooperation. At the same time, application-specific consensus enables applications to enjoy the full capabilities of the (non-shared) hardware. Not only avoiding the problem of network gentrification, but also providing significant gains in computational scalability.
The move from shared consensus to application-specific consensus is not without its downsides. While this design implies greater entanglements in composability between applications, we believe this is a less relevant problem for most applications. Having to wait for their communications to be verified or rely on soft finalization techniques (i.e. liquidity providers) is not a huge compromise in exchange for the vast improvements in computing power and predictability that application-specific chains provide.
In particular, Optimistic Rollups with Interactive Fraud Prevention provide decentralized applications with computing resources comparable to mainstream ones (e.g. involving billions of instruction steps and large memory address spaces) without requiring special hardware to achieve consensus . This is only possible because interactive fraud proofs allow arbitrators with limited computational resources to adjudicate disputes between provers with infinite computational resources. In particular, our arbiter is a settlement layer with limited resources, and our prover is a Rollups validator with relatively unlimited computing resources. For a better understanding of how this is achieved, see Section 5.2 of the Cartesi Core technical paper.
In the quest for maximum scalability and customizability, application and protocol developers are turning their attention to different forms of application-specific chains. Some examples are: Axie Infinity's Ronin sidechain, dYdX's sovereign chain, Starkware's fractal scaling design, Celestia's modular execution layer.
Application-specific Rollups chains can fulfill this need, with the advantage of not causing dangerous fragmentation of the verification of sovereign (layer 1) application-specific chains. Instead, application-specific Rollups chains inherit the strong security properties of the underlying base layer without relying on cross-chain bridging that has proven to be dangerous.
The technical advantage of application Rollups chains stems from the fact that they are secure to 1 in N honest parties, not from the necessity of an honest majority. All in all, application-specific Rollups are just as good as application-specific sidechains without seriously compromising security.
With the help of the above figure, you can better demonstrate the effect of visually expanding data and data availability capacity.
The graph is divided into several main areas that represent the scaling solutions being combined and how they behave in terms of compute and data capacity. As we moved from Ethereum Layer 1 to EVM Rollups and eventually to private application chains, computing power increased, while data also increased with the addition of EIP-4844 and sharding. The blue cones show which applications become progressively possible as the two dimensions are scaled. We refer to the blue area as the cone of innovation for web3.
The gray area outside the cone is where the full benefits of data availability cannot be enjoyed because the solution lacks computing power. The opposite is also true. The small white squares are examples of applications that start to become possible as we reach these milestones, and the ones that are unmarked remind us that we don't know what cool new applications will emerge once the environment becomes more robust.
Innovation cones do not fully represent precise data. The directions and angles drawn are not to be taken literally. Also, each region has possible applications easily into different fields. The graph just provides a visual outlook on the growing horizon of innovation in decentralized applications.
The Programmability Problem: In Defense of Better Abstractions
In addition to the aforementioned computational constraints, developers of DApps face another huge burden: the lack of a mature environment, manifested in the inadequacy of software tools and libraries.
To better illustrate the point, let’s mention Topology, the most impressive decentralized game we’ve come across in recent days. This ambitious project combines strategic infrastructure building and planetary dynamics! crazy thing. However, just by looking at their source code, we see the beast they have to slay. As one example, they had to develop a classical algorithm for simulating planetary dynamics from scratch. Behind the impressive talent displayed by the Topology team, there is a worry: Only good developers can bring their ideas to life in such an immature environment.
The above example does not stand alone. So many libraries (eg: 1, 2, 3, 4, 5, 6, 7) are written in Solidity to help in the development of smart contracts and DApps. But the current state of the language is still very immature, and some basic tasks still require people to turn to the forum for help.
This is not the reality of the traditional software industry. For example, the game Angry Birds requires the same library as Topology (after all, planets and birds obey the same laws of physics). However, the developers behind Angry Birds weren't forced to write every line of code they needed from scratch. There are mature libraries for basically every language imaginable.
In order for traditional developers to have access to all these libraries, which is also the gold standard for solving programmability problems, a mature operating system is required. Developers in everything from Web2 to traditional gaming to satellite launches rely on operating systems to give them the support they need. The languages and libraries they need to implement their ideas allow them to focus on what they really want to build, rather than the underlying infrastructure that makes it possible.
This is why we chose the RISC-V architecture to build the Rollups solution. It can port Linux or other operating systems into Rollups. In this way, developers can use the language and library they are most familiar with and bring their ideas to life without giving up the solid security guarantees of the blockchain, as described in previous articles (1, 2, 3).
Linux has been the focus so far, and it's an operating system that can run anything that can be compiled to RISC-V, such as some very secure microkernels.
Cartesian Rollups
We first discuss the importance of a modular rollup execution layer that truly scales computation and prevents DApps from engaging each other in a zero-sum game of computing resources. We then elaborate on the importance of developers relying on the abstraction capabilities of the operating system as mainstream developers do.
It is with these two requirements in mind that we design and build Cartesi Rollups as a modular execution layer, providing the following scaling advantages for DApps:
- Each DApp has its own high-performance aggregate application chain and dedicated CPU;
- The resources of other DApps in the Cartesi ecosystem will not be encroached;
- Significantly increased computational scalability outside of zero-sum gaming environments;
- Preserve the strong security guarantees of the underlying blockchain;
- A mature operating system that provides developers with industrial-grade tools.
The Cartesi Rollups application can be used as a second layer (i.e. on top of Ethereum), third layer (i.e. on top of Arbitrum or ZK-EVM chains) or as Sovereign Rollups (i.e. on top of Celestia). Developers can port their applications from one platform to another with minimal code changes.
final words
Cartesi allows developers to focus on what they're building without putting them in inconvenient constraints during the build or when they need to deal with issues.
This way, innovation can drive innovation without popular apps cannibalizing less established ones. Decentralized applications can have all the computing power they need while keeping costs predictable. Developers can leverage battle-tested programming libraries and create decentralized MMORPGs that are actually fun.
From the point of view of customizability, Cartesi Rollups application chain provides DApp with the possibility to charge different prices for different operations. For example, they could waive gas fees for market makers on a decentralized exchange, or increase the cost of predatory fishing on an ocean simulator DApp.
Cartesi has a very clear vision of the upcoming revolution in decentralized technology. Cartesi Rollups are being developed as a focused solution to the needs of this new environment.
About Cartesi
Blockchain OS is building Cartesi Rollups, a modular execution layer that lifts simple smart contracts to run in a decentralized Linux operating system. It allows developers to launch highly scalable Rollups chains and write decentralized logic using their favorite languages and software components.
- Each DApp has its own high-performance Rollups chain;
- The resources of other DApps in the Cartesi ecosystem will not be encroached;
- Did not raise the threshold of the network;
- Can enable a whole new category of DApps that cannot currently run on the EVM chain;
- Preserve the strong security guarantees of the underlying blockchain
Welcome to the blockchain operating system, you can learn about the next step.
