The State of Blockchain
Blockchain offers us the key to transforming our digital world. Put simply, blockchains give us the ability to reach consensus in a decentralized digital environment. We reach consensus all the time in our physical world: when we vote, when we use centralized currencies, and when we agree upon laws. Consensus is simply the ability for a group of people to agree on some particular state — who owns what, who makes what decision. In the digital world, reaching consensus is far more challenging. The historical standard was to just let a centralized entity manage everything. It’s simple when Facebook or Amazon or Google makes all the decisions and stores the state. But one must simply look at the history of hacks and frauds to understand why we need a better solution.
Decentralized Consensus by Blockchain
Blockchains are the better solution. By enforcing a set of economic incentives that reward agreement on the true network state (state as in its current mode of existence) and punish fraud, blockchains allow a decentralized network to achieve consensus. Then, through cryptography, each new state is built upon past states, cementing them for future reference. Early blockchains required that every participant store the same thing. This was the most secure way since it ensured that everyone knew and could validate which transactions were honest. Making every single person remember the same history is a pretty secure way of ensuring that history is maintained truthfully.
Unfortunately, this reality (commonly referred to as a global state) is at the root of most blockchain scaling issues. As the blockchain grows, it becomes inordinately expensive for everyone to store the same thing. A universally replicated state (replicated because everyone maintains the same state history) has led to enormous fees and unrealistically long confirmation times.
We’re not the first to recognize this problem. Many have tried to solve it and many have failed. We can break these efforts down into two categories: Layer-1 and Layer-2. Layer-1 solutions address the core blockchain protocol while Layer-2 solutions work on top of the core protocol. Think of Layer-1 as the city roads and Layer-2 as highways that are built on top of those streets. Highways don’t replace city roads, they simply reduce congestion by directing some types of traffic away from them.
Classic Layer-1 solutions include things like new protocols (e.g. proof of stake, sharding, or block size increases). Layer-2 solutions include things like Plasma, state channels (the Lightning Network), or TrueBit.
The ideal scenario is one employing both models. Core protocols (Layer-1) generally provide the best security since it’s always safest when every node stores the same history. With a global state, anyone can reference it and challenge false operations. So we leave high value, important tasks to the first layer. Other applications that are either low-value enough (thus they’re able to compromise slightly on security), or ones that don’t rely on the history stored in other parts of the blockchain, can be relegated to Layer-2. For example, your local grocery store doesn’t need to keep a transaction history of a store in Japan. What happens in your local store is independent of most other stores. The same could be said of decentralized applications. Many applications only need to store their own history independent of other applications. Layer-2 is perfect for these situations. It shifts the majority of data and computations off-chain and only brings the data on-chain at certain intervals or to resolve disputes.
Consistency: the key to success
If we’re to achieve decentralized consensus, it’s critical that all computations be reproducible. In a blockchain, where any change to any step in the computation fundamentally changes the outcome, it’s important that every step be reproducible by any other machine. Otherwise, there’s no way of verifying that the party performing the computation performed it correctly. In order for the computation to be reproducible, aspects such as the code, the current state, and the execution behavior must be agreed upon as a prerequisite. The problem is, with modern hardware and software, there’s very little consistency. This poses a problem for blockchains.
How do current blockchains solve the reproducibility problem? They do it by removing all the unpredictable variables. They use custom Virtual Machines (VMs) (e.g. the Ethereum Virtual Machine (EVM) or the Bitcoin script) for contract execution. These virtual machines define all the prerequisites and provide a reproducible environment. They are predictable boxes in which to run smart contracts. But there’s a huge trade-off.
Developers are accustomed to developing with a wide range of tools — file systems, libraries, and other software. For example, decompressing files is simply a matter of calling on the appropriate library. These tools all run on the operating system, which serves as the tool-bag. If VMs want to provide these features, they have to run an OS. However, modern operating systems were developed to run on hardware and they rely on the hardware to enable crucial operations. For example, a critical element for an OS is virtual memory, something supported by the hardware. But because of the reproducibility problem of hardware, blockchains replaced the hardware with custom VMs. The issue is that these VMs were not developed to support an OS. They serve as poor substitutes for hardware; they ultimately fail to provide those elements that an OS needs to successfully run programs
What does all this mean? It means blockchain developers are crippled. They can’t use the tools they normally use. Instead, they’re stuck with what these VMs support directly. This means that the last 30 years of software standards and tools are essentially off-limits to blockchain devs — the tools they take for granted in standard development work. This is like asking a developer to work with both hands tied behind their back. All those unpredictable variables that VMs remove? Well getting rid of those meant getting rid of what’s really important to developers. They’re throwing the baby out with the bathwater. And people wonder why we have not yet seen the killer app.
Imagine normal operating systems as a box of legos. They’re not assembled yet, but you can pretty easily create anything you want with them. Included are blocks of various sizes and colors, window and door blocks, and flat building plates to construct on. Now imagine that with a blockchain, you still need lego bricks to build with, but there is no lego kit. Any brick that you want you need to mold out of plastic. Now you might know what block you need, but you’ve never molded blocks before — you just know how to assemble them once they’re molded. This is the challenge blockchain devs face today. They might know what libraries and tools they need (they’ve been using them for years), but building them from scratch is either outside their ability or extremely cumbersome and demanding.
Blockchain VMs can support simple smart contract operations such as token issuance, but give them multi-task computation or other complex challenges, and they fail mightily.
Modern software and hardware development has brought us enormous capabilities. New hardware chips and storage methods allow us to process data far faster while software modules bring efficiency and standardization to programming. Unfortunately, these developments haven’t reached the blockchain. The limitations of blockchain VMs and the lack of a reproducible runtime environment restrict the benefits promised by hardware advancements and software modules. We can’t fulfill the potential of decentralized applications with such limited technology. We’re trying to drive a Tesla over a cobblestone road.
TLDR: Blockchains depend on reaching consensus in a decentralized environment in a reproducible manner. They use a combination of Layer-1 and Layer-2 solutions for reaching consensus and a VM to ensure that computations are reproducible. However, current options are inefficient, inconvenient, and severely limit developers.
So..what now?
Enter Cartesi
Cartesi is our response to blockchain’s problems. Our vision was to bring operating systems to blockchains — to untie the hands of blockchain developers. To do this we needed to create a reproducible environment that ran beneath an operating system so that devs could build applications with the tools they know and love. We decided to use Linux as our operating system of choice (read more about that decision here). However, we also needed the Cartesi platform to be just as reproducible as blockchain VMs. We made this possible by designing our own VM, the Cartesi Machine, on top of the RISC-V Instruction Set Architecture (ISA). This gave us a stable and reproducible environment with convenient Linux ports so that devs could develop with all the capabilities of the Linux OS: compilers, tools, libraries. You can read more about this in our recent blog post.
Applications and computationally intensive tasks can be executed in the secure and efficient Cartesi Machine. This gives devs all the flexibility they need and want. Any dispute over the results of the computation is resolved through a verification game in a low cost and computationally efficient manner. We’re paving the road for real, powerful decentralized applications.
The advantages of working off-chain are huge. It reduces on-chain bottlenecks, keeps fees low, and makes it possible for developers to use their favorite tools — whether development languages, tools, libraries, software, or services. With Cartesi, the goal is to allow developers to publish on any blockchain platform and even release their Dapp on multiple underlying blockchains. Essentially, Cartesi creates the ability for developers to develop like they always have, with few restrictions or limitations, while still benefiting from the immutability and security of the underlying blockchain. The best of both worlds.
Cartesi v. TrueBit
TrueBit has a similar vision as Cartesi. Both want to provide a layer-2 solution to reduce the load on the main blockchain. However, several key differences exist.
First, TrueBit was created to increase the scope of blockchain computational power. In simpler terms, TrueBit wants to enable blockchains to perform more advanced computations. Their system is built with this goal in mind. They don’t provide OS tools for developers and there’s a reason for this. They run on a WebAssembly (WASM) virtual machine — the W3C Community Group’s IISA for web applications. The issue is that WASM was also not designed to support an operating system. Instead, it was designed to run in a VM, supported by a host program (typically a browser) that runs inside a host operating system. Because TrueBit uses WASM, supporting an OS would mean adding many unnecessary layers. To add an OS, TrueBit would need to run it inside a realistic VM like ours, compiled to run on WASM, which runs inside the host program, running inside the host operating system, which finally runs on hardware.
It’s like computer Inception. Instead of dreams within dreams like in the movie, it’s hardware emulation within programs within programs within hardware. We like to use this metaphor because the physics in the movie correlates closely with the realities of computer science. In Inception, as they reach lower level dreams, dream time passes slower. In computation, as we add new layers of simulation, the processing gets orders of magnitude slower. Adding extra layers makes for an inefficient and unnecessarily complicated system. That’s why we simplified it. Less inception!
The Cartesi Machine emulator runs directly under the host operating system. One day, it will be implemented directly as hardware. It was designed to run a real operating system in order to provide all the support developers might ever want. That’s why Cartesi isn’t just about extending the computational scope of smart contracts. It is about making blockchain dev friendly. That’s about much more than just computing power.
TrueBit also differs in which party does the actual computations. TrueBit simply puts the computation into a marketplace for anyone to compute. The issue is, because anyone can do the computation, trusting the result is impossible without third-party verification. So TrueBit rewards people for finding bad results and reporting them. This, unfortunately, misaligns incentives. Since users are rewarded for finding errors, if there aren’t frequent errors to find, then there is no incentive to verify. This is why TrueBit and other similar systems introduce random errors to act as incentives for verifiers. This is obviously inefficient.
The Cartesi system aligns incentives. Only those parties interested in the result of the computation perform the computation. No verification is required unless there’s a dispute. This means that Cartesi has no need for artificial errors, no need for lots of verifiers, and no need for many extraneous computations. Cartesi is simple, secure, and efficient.
Cartesi v. Layer 1 Solutions
Layer 1 solutions work by directly impacting the core blockchain protocol. The following are a few of the most common Layer 1 proposals:
- Delegated Proof of Stake (DPoS) or varieties of BFT: Allows a small selection of supernodes to verify all transactions. These nodes are elected democratically. DPoS sacrifices on decentralization for the sake of efficiency.
- Sharding: Sharding organizes nodes into various distinct “shards.” Each shard can process transactions as a normal blockchain would. These independent shards can connect through the main-chain for cross-shard settlement. Sharding sacrifices security for efficiency since each independent shard is far easier to compromise than the entire main-chain.
- Block-size increases: Increasing the block-size greatly contributes to scalability by reducing fees and transaction times. The issue is that it also rapidly increases the size of the global blockchain. Ultimately this can centralize nodes as far fewer people have the hardware necessary to support the larger and more computationally demanding blockchain.
Current Layer 1 solutions necessarily result in tradeoffs — decentralization or security for scalability and efficiency. It’s also a reality that as the transactions and number of accounts increase on the blockchain they cause bottlenecks on the main-chain; no matter how many Layer-1 modifications are made, eventually bottlenecks will occur. Like other Layer-2 solutions, Cartesi is much more effective as it only requires local consensus.
Cartesi v. Layer 2 Solutions
Layer-2 solutions are frequently trumpeted as the answer to blockchain’s scalability problems. Proposals like plasma and state channels (Lightning Network is Bitcoin’s state channel solution) are supposed to relieve on-chain pressure by moving transactions “off-chain” and then only moving groups of these transactions on-chain for settlement. The issue with these Layer-2 solutions is that they require disputes to be settled on-chain. While some work similar to Cartesi and only necessitate dispute resolution or verification under rare circumstances, most layer-2 solutions require the main-chain to perform complex computations as part of the resolution process. Or these solutions require that computations be repeated by validators as part of the verification process — an extremely inefficient requirement. This limits the maximum transaction volume or computational complexity that can happen off-chain, since the main-chain would be unable to settle them efficiently. Essentially, while these layer-2 solutions promise solutions to main-chain congestion, they neither solve the bottleneck and nor are they free of the associated consequences.
The best aspect of Cartesi is that these Layer-2 solutions could potentially use the Cartesi Machine. They can take advantage of the full computational power of Cartesi while not overwhelming the main-chain with disputes.
Cartesi v. Secure Enclaves
Enclaves are enclosed hardware environments that use a protected hardware environment to guarantee privacy and integrity. Sounds good right? The problem is that these environments aren’t necessarily reproducible. They also require placing your trust in the hardware manufacturers, a decision that hasn’t proven wise given some of the recently discovered vulnerabilities. Regardless, if devs want to trust hardware providers, they can run the Cartesi Machine inside the enclaves to make them reproducible environments. Best of both worlds.
Cartesi v. ZKP
One exciting innovation for decentralized technology are systems based on zero-knowledge proofs (ZKPs) such as Zk-Snarks. Zero-knowledge proofs allow for certain factors to be mathematically proven without revealing their specific details. For example, with Zk-Snarks, one could prove that a user has a certain amount of funds without publicly revealing the actual amount. They could become the privacy standard for decentralized technology.
Unfortunately, zero-knowledge proofs aren’t Turing complete (meaning they can’t support advanced operations like smart contracts) and suffer from efficiency limitations. However, by moving these proofs off-chain to Cartesi, Cartesi benefits from advanced privacy while ZKPs benefit from the increased efficiency, especially given that more mature versions of ZKPs already exist on Linux. Cartesi makes blockchain ZKPs compatible with Linux-based ZKPs.
The Decentralized Future
Blockchains are not flexible or efficient enough to support the kind of applications our future decentralized economy will need. The inefficiency is due in part to the difficulties of balancing scalability with the security of a global state and the difficulty of achieving a reproducible environment in a decentralized network. Cartesi solves both of these problems.
First, Cartesi’s innovations will bring on-chain computations off-chain in a cheaper and more effective way. This will reduce the load on the main-chain, keep costs low, and increase scalability. Second, the Cartesi Virtual Machine is entirely reproducible, and by supporting Linux, Cartesi allows devs to use the tools they know and like. Cartesi was built with developers in mind.
Cartesi can also cooperate and benefit other innovative blockchain scalability efforts. Sharding, DPoS, Secure Enclaves, Plasma, State Channels and ZKP can all work with and benefit from the reproducibility and efficiency of Cartesi. Cartesi believes that collaboration rather than competition is the way of fulfilling the ultimate vision of blockchain. Only when devs can use their favorite tools, work across protocols, and integrate the best aspects of the technology, can we expect to finally see blockchain’s killer app. Cartesi has the tools to make it happen.
