The roadmap for The OS explained
The official release of our HTTP API, properly documented and tested.First exercise for our economic incentive for validators using a Cartesi validator node that will be paid using CTSI. (In Progress)Support for packaging and deploying DApps to local and remote networks.Comprehensive SDK documentation.Final tests.Auditing.Mainnet deployment.
Once the tests have been entirely conducted and their issues duly fixed, we will offer a clear way to deploy Cartesi Rollups DApps, opening its doors for the broader community of developers.
It is important to note that “Milestone I”, released in December 2021, already allows developers to implement and test applications using a local development environment.
Several ecosystem contributors are currently proposing and coding various simple applications that aim to test and showcase different uses of our technology. That includes Dakai, Webchefs, Aetheras, Scalac, Sotatek, UFF, Locus Software, and Productive-e.
The OS is the future, and we want to share what we see on our magnificent horizon with our community. The main objective of our new roadmap is to clearly and openly improve the information flow between Cartesi’s primary contributors and the community.
We divide our roadmap into three main components that make up The OS:
The Cartesi Machine is Cartesi’s deterministic virtual machine that emulates a RISC-V architecture and can run a full-fledged Linux OS. The Cartesi Machine is Cartesi’s groundbreaking technology that offers a runtime for decentralized applications built with mainstream software.Cartesi Rollups is Cartesi’s optimistic rollup Layer-2 system relying on the Cartesi Machine to allow developers to create scalable decentralized applications with mainstream software components. It consists of on-chain and off-chain components that allow the to provide data availability, order input data, bridge tokens between Layer-1 and Layer-2, and serve as a referee in case of disputes.Noether is Cartesi’s side chain for data availability. It is the part of Cartesi’s solution that will enable applications to use much more data than would be possible with Ethereum or other base layers.
Each component is comprised of projects that the core team is currently working on, which we describe below.
As an essential part of Cartesi Rollups’ road to Mainnet, we allocate significant R&D resources to further develop the Cartesi Machine (CM). As we know, the CM is responsible for running the Layer-2 computations in The OS. It needs to be simple enough so that a perfectly equivalent implementation can exist in the and off-chain. At the same time, the off-chain implementation needs to be both general and fast enough to run DApps under Linux. These two goals are often at odds.
The Microarchitecture
The Microarchitecture is a new design for the CM that effectively decouples its two uses: execution off-chain and verification on-chain. Only the microarchitecture emulator will be implemented in the . Meanwhile, the off-chain emulator will be free to grow in generality and improve performance without impacting auditability. Its code (the same code!) will be compiled to run directly in an off-chain host as well as on the implementation of the microarchitecture emulator.
The microarchitecture allows us to add three features to the CM that would otherwise significantly increase the complexity of the on-chain emulator:
The TLB has the potential to make the emulator (and thus the CM) several times faster, particularly in memory-intensive applications. Likewise, floating-point instructions can cause the emulator to be several times faster in numerical applications.
Moreover, the Compressed and Floating-Point instruction extensions are part of the standard set of extensions (RV64G) widely adopted by most of the RISC-V industry. Adding support for them in the CM will increase the compatibility with existing systems and software.
Self-Hosted Distributions
The Cartesi Machine engineers are also working to enable self-hosted distributions. Let’s briefly explain what that is:
The OS intends to be as convenient and inclusive as possible. One of the inconveniences of our current architecture is that DApps need to be cross-compiled. Cross-compilation means creating executable code for a platform other than the one in which the compiler is running. For example, a compiler runs on a laptop but creates an application to be run on a smartphone.
Cross-compiling would no longer be necessary by enabling this form of distribution, making it simpler for developers to build in the Cartesi Machine. While the Microarchitecture is not necessarily needed for that, the C, F, and D extensions will make our emulator directly compatible with existing self-hosted Linux distributions. That will significantly increase convenience and efficiency for DApp developers.
New Features’ Documentation
We are developing the proper documentation for new features of our emulator used in Cartesi Rollups’ dispute resolution solution. With that, our tech community can expect to better understand how they all work and even help with bugs and enhancements.
Cartesi Rollups is a Layer-2 solution that does not limit itself to scaling transactions and reducing fees. We want to go further. The OS is enabling DApps to be built on systems such as Linux while still preserving their integration with an underlying Layer-1 and being secured by it. All developments related to our Rollups solution and the road towards deploying DApps are in this component.
Road to Mainnet
It’s very difficult and prone to mistakes to make an estimate for something as large as readiness for Mainnet. In order to avoid making any promises we cannot keep, we do not wish to provide any specific dates. We do, however, promise to provide regular updates and openness which will show how we are constantly adapting to a quickly changing environment. The decision to include new features into Cartesi Rollups (e.g. HTTP API), is an example of that.
As explained above, we need to complete the pending steps before Cartesi Rollups can be deployed on Mainnet. As previously stated, Cartesi’s infrastructure is awaiting the refactoring of some features and tests. After that, we need to go through a period on Testnet where we will thoroughly test and ensure the system is secure and ready.
However, at this point, developers are already coding for Cartesi Rollups. The Echo DApp demonstrated the basic Cartesi Rollups’ features. The expanded logic, voucher execution, and asset withdrawals/deposits are a few more that need to be shown to our community members. To help our community’s developers better understand these functionalities, we’re working on more basic DApp examples and SDK documentation. It will also be easier for developers to build their DApps on Cartesi infrastructure by introducing our HTTP API.
Parallel to Cartesi’s infrastructure upgrades, there is an ongoing implementation of economic incentives for validators utilizing Cartesi nodes. This allows validators to receive CTSI from applications and users when they provide their service for Cartesi Rollups applications.
DApp Validator Nodes
An essential part of the general decentralization of Cartesi’s ecosystem will be the configuration of its network of nodes. The more participants you have acting as contributors to block validation, the larger the security and level of decentralization in the web. In this sense, parallel to the improved availability of Cartesi’s infrastructure for DApp development, the implementation of validator nodes for these DApps is also expected to undergo significant advancements.
Milestone I. The first infrastructure will be minimalistic. The objective is to provide the simplest setup allowing developers to publish their DApps to Cartesi Rollups without the need to run nodes themselves.
Developers will be welcome to solicit a deployment of a DApp on Cartesi Rollups at this stage. For this minimalistic set up, developers will need to fill out a form requesting the deployment of their DApp to the Cartesi team.
Milestone II. The second milestone enables an infrastructure that is unpermissioned for developers. Any developer will be able to publish DApps themselves by a simple procedure, such as running a command line.
Milestone III. At this stage, third-party node runners will run Cartesi Rollups validator nodes, earning CTSI for providing their service to the network.
Rollups Enhancements
Several features are necessary to solidify the system and amplify its adoption, through more convenience for developers. With that goal in mind, we are currently working on the following:
Supporting Libraries. Although not necessarily fundamental for the deployment of Cartesi Rollups on Mainnet, some libraries will still have to be developed to provide an adequate level of convenience for Cartesi developers. These libraries will be destined to improve the user’s interface (frontend), the verifying logic to run inside the rollup (backend), or the rollup environment itself, according to what our developers’ experiences identify over the subsequent trials.
Data Availability Solutions Integration. Data availability is one of the requirements needed to enable what now seems like impossible DApps. Since The OS is here to change this, we need to integrate our Data availability solution with our Rollups. Initially, this will be done through two fronts: developing support for Logger and IPFS data.
Supporting Material. Example applications, documentation, videos, and tutorials on how to code Cartesi Rollups DApps.
Support for Computational Oracles
The objective of this feature is to migrate Cartesi’s computational oracle (previously called Descartes) to Cartesi Rollups’ infrastructure and codebase. Unlike traditional rollups applications, the computational oracle executes a single computational task formulated by the . More precisely, while rollups applications can evolve and preserve their state on Layer-2, computational oracle applications are stateless. Thus, they can be regarded as a simpler case scenario of full stateful (rollups) systems.
By allowing both to work together, we will maintain a single code base for both use cases, which means less code to audit and thus increased security overall. Moreover, we would also be providing more flexibility for DApps, which could, for example, allow user interaction over a certain period before computing a final result.
To learn more about the computational oracle, check our documentation here.
Arbitration for Rollups
Cartesi’s interactive dispute resolution is a fundamental pillar of Cartesi’s technology. It gives the system and DApps the ability to rely on a set of validator nodes with very strong security guarantees. A single honest validator is able to present and enforce a correct state to the , even if all other nodes are presenting a false claim. In effect, this is an algorithm for arbitration, in which the is the referee.
Since Cartesi’s inception, we designed, implemented, and tested with success our interactive dispute resolution with Creepts (2020) and with Descartes (2021).
As we take our leap to Cartesi Rollups, implementing this arbitration system becomes slightly more complex. Furthermore, with the introduction of the microarchitecture, the arbitration’s on-chain code needs to be rewritten to reap improved security and auditability benefits.
We are currently reimplementing the algorithm to make it compatible with Cartesi Rollups. This is a security-critical development that requires extensive testing and auditing.
In order to expedite Cartesi Rollups on Mainnet, we are breaking down arbitration into two milestones:
Milestone I, in which validator nodes work as a quorum and a majority of nodes need to agree on the state for Cartesi Rollups DApps to advance and present vouchers to the .
Milestone II, where interactive dispute resolution is back in place, allows for superior security guarantees.
The DApps developed and deployed for “Milestone I” don’t need to change their codebase as “Milestone II” becomes available. They will seamlessly become more secure and decentralized as we upgrade the system.
Automatic Voucher Execution Incentivized by CTSI
Cartesi Rollups DApps use vouchers to respond and interact with layer-1 smart contracts. Vouchers can be anything from providing liquidity in a DeFi protocol to withdrawing funds from Cartesi Rollups.
Cartesi Rollups DApps will generate vouchers, and those vouchers must be executed on the . This need comes with a game-theoretical problem: what incentive do people have to execute the vouchers, and how to prevent race conditions if incentives are presented?
This problem is solved by using Noether’s Scheduler, presented in the next section. With the scheduler and the use of financial incentives with CTSI, vouchers can be automatically executed without race conditions.
We have been successfully running our PoS system for over a year now. It has proven to be a robust and stable infrastructure holding millions of USD worth of CTSI. We will extend this system to select the sequencer randomly, out of all the stakers and their node runners. With the random selection in place, users will pay CTSI to the sequencer to submit their transactions.
Transaction Sequencer Incentivized by CTSI
Another important component of Rollups solutions is the aggregation of transactions. This greatly reduces the cost of each individual transaction. Using a peer-to-peer network, the system builds an aggregated batch of transactions, which is then submitted to Layer-1 in a single operation, thus reducing the total cost.
Despite the simplicity of this principle, there is a problem with incentives, similar to the one we described above. Who is allowed to submit a batch of transactions on behalf of other users? Is this costly service going to be incentivized in any way? And how do we select who will benefit from these fees?
As explained above, we will also solve this problem by using Noether’s Scheduler.
With The OS, we unleash mainstream software stacks to build smart contracts. Cartesi Rollups is the main component of the OS, allowing for unprecedented computational scalability and convenience for developers.
Noether complements The OS as a high-performance side-chain designed for temporary data availability. The Noether side-chain uses Cartesi’s Proof of Stake system.
Upgrade from PoS to PoS 2.0
In 2021, Cartesi’s core team built the second version of our Proof of Stake system. From now on, the focus is to deploy PoS 2.0 and migrate the existing system to Mainnet.
This upgrade enables a variety of important possibilities. For instance, this upgrade will allow the current PoS contract to access the core data structure of the side-chain. It will also enable our contracts to hold metadata (data about other data) of the sidechain blocks. In other words, we are enabling more functionalities and easing DApp development.
The Scheduler
The Scheduler is a mechanism that enhances the roles and capabilities of block producers. With the migration to PoS 2.0, it will allow network participants to make much more than simply produce blocks to Noether, but actually, enhance the services of Cartesi Rollups while keeping the same level of decentralization offered by Noether.
This system allows for the selection of validators from a pool, considering the amount of CTSI that is staked through them. It offers block validators the incentives required for them to participate in the network, while also preventing race conditions in the network.
The Scheduler will be used in various parts of our technology as we explained earlier, from the automatic execution of vouchers to providing incentives to block sequencers.
Explorer
The Cartesi Explorer, which is the main entry point for CTSI delegators and node runners, will be updated to be compatible with the upcoming protocol update. Additional information about the produced blocks will be displayed.
We will also streamline the user experience for both delegators and node runners, bringing a new design and facilitating the understanding of how the system works.
We see a bright future for The OS. Cartesi’s revamp of its roadmap is entering its third and final stage. The first stage was outlined in Cartesi’s latest Medium article, “Hello, new roadmap.” Make sure to take a look. For our second stage, we’ve presented an overview of what exactly we expect the future roadmap to be. The current focus is making it even more accessible, clear, and engaging.
Our roadmap’s third and final stage will be implementing the roadmap’s new format. While, through the second stage, we’ve been able to convey a good idea of the level of information accessibility we will be developing from now onwards, the final step will officially apply new ways in which content will be communicated and accessed by our community.
As already mentioned, frequent updates will be made to the roadmap. Instead of these being done through new sequential articles or posts, we intend to enable community members to keep track of these new releases by making the roadmap itself updatable. Doing so, interested parties should be able to actively go after updated information on The OS’s development on demand.
By accessing the roadmap, community members will get updated information from the tech developments and the ecosystem’s desired and proposed features to be developed. As a result, we expect to gather valuable feedback from the community through Cartesi Improvement Proposals (CIP’s) and different communication channels (Cartesi’s website, Medium, Twitter, Telegram, Discord, and Reddit), helping us evaluate and determine priorities, as well as contributing to the roadmap’s collaborative development.
Our path is not static; thus, we should not have a static roadmap. It is two-way, dynamic, and cooperative communication. We hear and value your feedback. Let’s build The OS together.