“It won’t be EVM that beats EVM”
After Bitcoin’s November Taproot update, smart contracts on Bitcoin are starting to catch everyone’s attention. The Taproot update brought new features such as Merklized abstract syntax trees and Schnorr signatures to Bitcoin, making transactions on the Lightning Network now look the same as regular transactions, which not only improved Bitcoin’s security and privacy, but also brought Bitcoin’s smart contract functionality to more people’s attention.
In fact, bitcoin already supports “smart contracts”, which are not as complete as Ethereum’s smart contracts, but can still be used to make a complete application by combining various functional modules. In the early years of Bitcoin, developers have been exploring the possibilities of DApps using Bitcoin’s rudimentary scripting language.
It is this “rudimentary and incomplete” condition that has allowed developers to use their imagination and come up with a myriad of ideas, and has allowed the “storage-based smart contracts” discussed in this article to take shape on Bitcoin and grow on Arweave.
Storage-based consensus smart contracts are perhaps the optimal solution for decentralized applications in the Web3 era, providing high performance with near-unlimited TPS, while ensuring data traceability and monopoly-free access.
According to Nick Szabos’ definition when he coined the term of “smart contracts” in 1996, a smart contract should have the following characteristics: a set of promises, specified in digital form, containing an agreement, and the fulfillment of the promises by the people involved in the contract.
The Holy Roman Empire was neither holy, nor Roman, nor an empire. A smart contract is neither smart nor a contract. The “smart” in a smart contract is not the kind of intelligence found in AI and machine learning, but rather means that the contract will mechanically execute a prescribed algorithm. At the same time, a smart contract is not really a “contract” in the sense of law.
When we talk about smart contracts nowadays, we are usually talking about smart contracts on Ethereum or similar architectures.
A smart contract in this context is a program that runs on the Ethereum blockchain, also a set of code(functions) and data(state) located at a specific address on the Ethereum blockchain. Usually these smart contracts are written in a Turing-complete programming language such as Solidity, run in a virtual machine such as EVM to get the final state data. Smart contracts on Ethereum meet the definitions and characteristics of smart contracts through the openness of on-chain data and the specific unified computing environment of smart contracts.
This overall network design has major problems. It is very difficult to upgrade the EVM to upgrade the execution performance of smart contracts, which requires long development and testing time (although the progress of ETH 2.0 is already considered really fast). At the same time, the in-chain and off-chain interaction of an EVM fixed on chain is very cumbersome, relying on oracles and so on. In addition, the EVM’s overly simple design also limits its functionality to complex data computation, and even computing a trigonometric function is a pain. Finally, it is also difficult to upgrade the EVM, which after all is constantly running on the Ethereum nodes, and fixing and upgrading it is like fixing the engine of an airplane while it is flying. However, these problems are double-edged swords, and to solve them more or less requires sacrificing security and other factors.
Writing a smart contract in EVM using Turing-complete Solidity can realize very complete applications like AMM except for some complex operations. There is no such Turing-complete programming language on the Bitcoin or Arweave.
What about outside the chain? We have countless Turing-complete programming languages off-chain, so we don’t even have to customize one, we can just grab one and use it. You may wonder, what is the point of blockchain if the computation is done off-chain? But in fact, Ethereum’s Layer2 also relies on various off-chain upgrades to optimize the efficiency of the network. Instead of creating countless Layer2 off-chain solutions to gradually increase the TPS over the years, it is better to directly increase the TPS to the upper limit of the physical level and let the blockchain become a storage layer with the guarantee of computation and storage trustworthiness. After all, in StarkWare and other solutions, Ethereum is basically just a place to store data. So this solution is actually what we are going to discuss in this article: smart contracts based on storage consensus.
Web3.0 should first be the Web. Best of all, the native solution has the same performance as Web2.0 (like @muneeb said: if you like the EVM solution, then go ahead and make a new Ether , then go ahead and make a new ethereum. Instead of stuffing an EVM on top of a Bitcoin that follows Occam’s Razor design), it shouldn’t have to go back to Web 2.0 after all the patchwork to have Web 2.0 performance.
Currently the only decentralized application that can achieve the same performance as traditional applications is using a storage-based design. Such a decentralized application uses the blockchain as a paper tape for the Turing machine, storing state and state changes on the blockchain, while the latest state computation of the contract can be performed within the user’s client off-chain. This design allows decentralized applications to increase their performance directly to the bandwidth of the network or the performance of the user’s own hardware, which is currently the most efficient solution.
A typical application that has been an early adopter of the storage-based design idea is Colored Coin.
As we mentioned before, Satoshi designed Bitcoin with the idea of perhaps making a global ledger. A ledger typically doesn’t require a Turing-complete language and language runtime environment (Satoshi Nakamoto is not an idiot, and I’m sure he knew that an Ethereum-like design could be made). As a currency, Bitcoin’s rudimentary scripting language can store some simple Metadata on the chain, such as Bitcoin’s block 0 with Satoshi’s famous “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”.
Since Bitcoin’s scripting language allows for a small amount of Metadata to be stored, this Metadata can be used to represent real-life objects, linking real-life objects to certain blocks on the Bitcoin chain that contain specific Metadata. For example, if we write in the Metadata of block 6324: “This block generated 100 shares of Starbucks stock”, then we can say that this block is the first block of the colored coin of Starbucks stock, and this block containing the Metadata is “colored” by the colored coin. After that, all other blocks that contain the Starbucks stock transactions (e.g. “Alice sells Bob 10 shares of Starbucks stock”) are colored, and are blocks that store information about the colored coin transactions.
In 2021, many of the links we see on the wiki of the colored coins are no longer accessible, so it is safe to say that the activity of the colored coins has faded (of course we can still look at the pitch deck). Colored coins’ pioneering attempts with off-chain computing, a rudimentary bitcoin scripting language, and storage-based consensus inspired RGB and Arweave’s SCP, which we’ll mention later.
RGB is a Layer2 and Layer3 client-verified smart contract system running on the Bitcoin and Lightning networks. RGB is inspired by colored coins, using Bitcoin as a state commitment layer, taking a storage-based design paradigm, proposed by Giacomo Zucco and Peter Todd in 2016, and supported by Tether, Bitfinex in early 2019.
RGB represents “post-blockchain”, Turing’s complete form of trustless distributed computing. RGB isolates the issuer, state owner, and state change of a smart contract from each other. At the same time, RGB adopts a scheme that places smart contract code and data operations off-chain. RGB uses the blockchain as the state commitment layer, bitcoin scripts as the ownership control system, and smart contract updates are defined off-chain.
In short, RGB is an enhanced version of colored coins. RGB is like a very complete Layer2, using the blockchain as a commitment layer, performing computation and state management off-chain, greatly improving the performance of smart contracts and decentralized applications. The design of off-chain computation for smart contracts allows the Bitcoin scripting language to do the state commitment operations it can and should do, while allowing the off-chain Turing-complete programming language to do the complex state management and computation.
What Taproot does is reduce the complexity of some complex operations, and improve the privacy of those complex operations. Taproot does not bring fully expressive quasi-Turing-complete smart contracts like those available on Ethereum, and the limitations of the Bitcoin scripting language remain.
RGB itself does not have to rely on Taproot, but with Taproot in place, many of RGB’s operations can be implemented more simply, which may actually be a helpful upgrade for RGB.
After talking about colored coins and RGB, we can talk about the more novel design of storage-based smart contracts on Arweave. We can finally introduce a more official and standardized term: Storage-based Consensus Paradigm. We will discuss in depth the advantages and potential problems of this design paradigm in this section.
Arweave is a blockchain built for storage, in contrast to Bitcoin, which is positioned slightly away from the storage based consensus. From the bottom up, Bitcoin can be said to have an architecture: Bitcoin (ledger record layer) → Lightning Network (application runtime layer), while Arweave has a similar architecture: Arweave (storage layer) → Permaweb (application runtime layer). On Arweave, we can focus more on keeping the smart contracts in state, and Arweave acts as a paper tape for the Turing machine, recording these states and the individual transactions that modify them at the bottom. Interestingly, Vitalik’s latest blog post also shows an interest in becoming a Web3 paper belt. And in the EIP-4444 discussion post, one of the users commented on the storage of old data in Ethereum with that.
The store consensus-based design paradigm was proposed by everFinance’s Founder outprog, inspired by Arweave’s SmartWeave and Ethereum’s Layer 2 Rollup. It is described in everPay’s white paper as follows: In Ethereum, computations are performed by all nodes in the blockchain network. All nodes generate and store global state for query. Unlike the Ethereum model, SCP separates computation and storage, the blockchain does not perform any computation but only stores data. All computations are performed by off-chain user clients or servers, and the generated state is stored by off-chain clients or servers. SCP uses off-chain smart contracts, which can be written in any language, and all input parameters of these programs come from the stored blockchain. In the paradigm, the blockchain is more like a computer’s hard drive, and off-chain smart contracts can be performed on any machine even with minimal computing power.
In short, SCP is a high-performance Layer2 network layered with the underlying blockchain using Bitcoin or Arweave to store the results of state, or to store the content of off-chain smart contracts, to ensure that the storage is trusted. This Layer2 can actually be considered as Layer1, because there is no smart contract computing layers in the Bitcoin or Arweave chains, they can be considered as the lower Layer0.
Needless to say, such an SCP is very different from the traditional smart contract as we understand it, and there are certainly many potential problems.
As I mentioned before, SmartWeave is a concrete implementation of SCP, so any project that uses SmartWeave on Arweave is also part of the SCP smart contract ecosystem.
In addition to the above mentioned aspects, the SCP on Arweave also has unique advantages.
1. Arweave can not only store data and transactions, but can also host front-end pages in a trusted manner.
The recent theft of BadgerDAO and the previous Uniswap downgrades of certain tokens from the front end were due to the centralization of the front end, which led to front end pages being tampered with or forced to be modified by censorship and regulatory pressure (e.g. Chainnews, fortunately we have its archive on Arweave). In this case, a decentralized application is not fully decentralized, only the smart contract is decentralized, and the front-end is centralized.
Arweave’s front-end hosting can solve this problem. By hosting the front-end of an application on Arweave, the browser can render the entire page while accessing the source file of the transaction. This ensures that the page cannot be easily tampered with, since a transaction is stored permanently and immutably on the blockchain.
This ensures decentralization, tamper-evident, and censorship avoidance of front-end pages. Hosting the front-end on Arweave makes a decentralized application a truly fully decentralized application. Currently you can host front-end projects easily through Argoapp on Arweave.
2. Only using SCP on Arweave can get the maximum performance and decentralization.
According to outprog, the inventor of SCP: “TPS blocking is mainly in L1, even if L2 is fast. The performance can’t be improved. Multiple L2s will homomorphically compete for the same resource. This is the endgame of on-chain computation and verification, which cannot scale, at best, to 10,000 TPS. The reason for this is that the our thinking is limited to on-chain computation and verification. It is difficult to make a real Web3. “ The decentralized application of SCP on a Layer0 Arweave with permanent storage is not subject to such limitations. This is a performance consideration.
The various Rollup schemes of Ethereum Layer2 can also be considered as a kind of implementation of SCP. The rapid progress of Ethereum Layer2 has raised expectations for ETH 2.0. However, the current situation of Ethereum Layer2 is worrying, whether everything is moving so fast that Ethereum now has a high-performance Layer2 along with: a commercial Layer2 company StarkWare (compared to the zkSync team), a StarkWare “dedicated” Layer2 wallet, Optimism without the fraud proof system (it used to have one, but it’s now getting a new one). These situations are becoming more and more like a falling back to the Web2 era. To achieve Web3, we have to start over. Technical debt is a scary thing, and it will get scarier.
From Bitcoin to Arweave, SCP employs off-chain smart contracts with off-chain validation, enabling truly unrestricted performance, uncensored and fully decentralized applications with security. This may be a better way to build a Web3 with open source data and user-owned data and applications.
When faced with the proposition that “the Byzantine General Problem in asynchronous networks is insoluble”, Satoshi did not dwell on the Byzantine General Problem itself, but instead thought outside of the box and came up with the solution of a blockchain with PoW, aka Bitcoin. When we think about optimizing smart contracts, we don’t need to dwell on Layer2 encryption and proofs, but rather think outside the block and boldly put smart contracts off-chain, so that the storage consensus is satisfied, and at the same time, the data is open source and supervised and trusted, and the performance is exactly the same as that of Web2, which is SCP.
Finally, Messari’s 2022 annual report includes this statement, “Development on Bitcoin is like building a rocket, while development on Ethereum has historically been more similar to building a Silicon Valley startup.” Development on Bitcoin (or Arweave) is like building a rocket, because they are much more low-level and don’t have a smart contract execution environment, which is the reason why you need to build a rocket with a sickle and a hoe, like with the colored coins; Ethereum is a complete computer, with all the software development capabilities and tools, and development on it is just like software development. So the final question of this article is do you want to build a startup on Ethereum, or do you want to build a rocket on Bitcoin or Arweave for Web3, and then go to the moon? Think outside the block.
General:
Smart Contracts:
Colored Coins:
RGB:
Taproot:
SCP:
Arweave: