As blockchain projects mature and our understanding of the technology progresses, it becomes ever more clear what challenges impede its mainstream adoption:
- Convenience — developing and using a blockchain application is still an overwhelming task, involving a very difficult learning curve and consequently significantly reducing general interest in the technology;
- Scalability — Blockchains need to perform as well as centralized technology in order to be able to compete with it.
Cartesi is a project that attacks these two problems at once, by creating an infrastructure that is at the same time scalable and compatible with battle-tested technologies.
In our article On Linux and Blockchains, we explain in detail how Cartesi will make blockchain infrastructure compatible with the industry standards of software development, onboarding experienced developers into the decentralized world, without the need to learn idiosyncratic processes and programming languages.
Let us explain below how we tackle the second problem, namely the scalability issues faced by blockchains.
Pick as an example any important centralized application, such as Uber, Tweeter, Spotify, or Fortnite. They all involve a large number of powerful servers, receiving millions of messages every minute and storing/processing hundreds of terabytes of data. Meanwhile, decentralized solutions such as Augur, Decentraland, or Cryptokitties are limited to very few expensive transactions per minute, dealing with limited computational capabilities and reduced storage. There is no question that blockchain technology cannot compete on equal grounds with their centralized counterparts.
In order to understand what we propose as a solution to this challenge, we need first to break the problem into smaller pieces, since in fact scalability is composed of many parts:
- Computation — How complex can the logic of a program be? This is analogous to the CPU power of a server;
- Transactions — How many messages can we send and confirm into the system per unit of time? This is analogous to the bandwidth of the network;
- Storage — How many terabytes of data can we store in our server?
Looking at current figures, blockchains struggle to keep up with centralized servers. A very good guideline to measure this problem is the “rule of one million”. This essentially says that blockchains have a one-million-fold disadvantage in each of the above items when compared with their centralized analogues. This is obviously not sustainable in a competitive environment, where every little improvement can make the difference between success and failure.
Although oftentimes the three issues mentioned above are treated as a single problem, under the umbrella of “scalability”, each requires its own technological solution. To understand this, recall how these problems were tackled in the centralized world at the end of the last century: fast CPUs, broadband modems, and large-capacity disks. In the blockchain world, this could not be different: we need to treat these issues separately because they are of very different natures.
We have already addressed the computational limitations of blockchains. This is explained in great detail in our piece On Linux and Blockchains. There we give a brief overview of how we put some beautiful theoretical Computer Science to work and give the blockchain the analogous of a super-computer. With the Cartesi Core, instead of being one million times slower than centralized solutions, dapp can now run at lightning speeds, while maintaining all the security and decentralization guarantees of a blockchain. Our computation solution is already available for developers on our public Github repositories and we have already shown how it can be used in practice by developing a fully decentralized and computational intensive game on Ethereum.
Having solved the limitations of blockchains in terms of computation, our next step is to unleash its power in terms of transactions. This will be done in our upcoming project: the Cartesi Side Chain, which we describe in the remainder of this piece.