The Ideal Blockchain Virtual Machine

As a developer one of the most exciting aspects of working on blockchains is getting to reconsider all the layers of abstraction in computing of the last few decades. A blockchain reaches consensus on a virtual machine. Developers could have used an existing architecture like the x86 or RISC, but these are too complex and not quite domain specific enough for the use cases people will want in the application layer of smart contracts. Therefore new VMs are built like Ethereum’s EVM. A new VM needs new languages on top of it to express the underlying nuances. It often feels like we are in the 80s again, with an explosion of novel languages for newly designed machines.

Within such a freedom to design, one must ask what goals we have in mind for these blockchain VMs. Historically the Ethereum answer has been simple; a VM should be simple enough to safely estimate gas fees, but complex enough to express any program you want to execute. Turing completeness has been a selling point for the EVM although as I mentioned in a previous post, gas limits actually block Turing-completeness in reality. The Themelio blockchain benefits from pre-estimated gas fees by making the non-Turing-complete feature explicit, effectively increasing security and reliability in the network. This is an example of how blockchain protocols can benefit from VMs which are custom designed for the intended use case.

So what is the intended use case of a blockchain? One might argue that it is to host a general execution environment in which we can trustlessly execute arbitrary logic. But in practice we know that running just any contract is not actually scalable or even necessary. Most major blockchains (Ethereum, Polkadot, Solana, Cosmos) are becoming very simple base layers on which layer 2 protocols like rollups in Ethereum or parachains in Polkadot, which scale computation, are hosted. We are seeing the base layer separate from the application layer. The base provides security with a massive consensus/mining community, and layer 2 platforms provide execution environments backed by the base security. Ultimately you see the blockchains being used for their trust preservation properties (see Trust is the Core Value Proposition of a Blockchain).

If we can rely on layer 2 environments for complex code execution, what properties do we really need at the base? Obviously the base execution environment needs to support layer 2 technologies, as Vitalik points out in his post on base layers. Some layer 2 technologies are easy to support, like optimistic rollups which don’t require computationally complex proof verifiers. But if the core purpose of a blockchain is to preserve trust and security then a better blockchain execution environmet will support layer 2 technologies which require less trust, like zero-knowledge rollups.

Again Ethereum unfortunately fails to deliver in practice what it offers in theory here. While zk-snark proof verifiers can theoretically be implemented in EVM contracts, in practice it is prohibitively expensive. Zk-rollup technologies like AZTEC protocol and Zk-Sync are using the bn128 elliptic curve precompile (EIP-196) to effectively bypass the EVM. There are also precompiles for sha-256 and the blake2 hash’s compression function (EIP-152), making proof verifiers with Bitcoin and Zcash relays possible. Ethereum is creating adhoc solutions to meet real use cases on the platform. We can see that a general purpose VM doesn’t mean it practically covers its use cases.

Zk-rollups are not the only applications that rely on cryptographic verifiers in the base layer. In fact it turns out that for a platform whose purpose is to preserve trust, cryptographic proofs and verifications are the primary application. Consider the wide ecosystem of blockchains that exist today, all of which build bridges to Ethereum to transfer assets and access the massive liquidity. An ideal bridge does not require trust in more than the two blockchains which it connects. Because such trustless bridges require cryptographic proofs, and such proofs in practice are prohibitively costly, we often see projects sacrificing security to be economical. Wrapped Bitcoin (WBTC), with a market cap currently of $12B, is an example of a trusted bridge where instead of submitting a cryptographic proof to Ethereum that X amount of Bitcoin has been locked to an address, there is a legal entity which does the verification itself and administrates new WBTC tokens. Bitcoin is unfortunately another difficult network to bridge as it is hard to prove ownership of a UTXO to a light client. But even modern networks with a full range of VM expressivity are using trusted bridges. Parachains on Polkadot, such as Moonbeam and Centrifuge are relying on a trusted bridge provider called Chainbridge to connect with Ethereum. It is an unfortunate reality that while these parachains are fully capable of introducing trustless bridge proof verification systems into their protocols, the cost of doing the same on Ethereum is much less realistic. As a result the ecosystem suffers in security and relies on trusted parties.

An ideal execution environment for a blockchain will not just include a list of current cryptographic primitives, because cryptography tools are always changing. The ideal environment will make implementing cryptographic primitives cheap and efficient so that as our cryptography evolves the blockchain doesn’t have to. Cryptography is an application layer concern on top of a blockchain-as-a-trusted-execution-environment.

Fortunately we are not at a complete loss with Ethereum at the ecosystem’s core. One can imagine this ideal cryptographic VM as a zk-rollup on Ethereum. External blockchains can bridge assets to the efficient rollup, and the rollup can “wrap” those assets for transfer to other layer 2s, or even to the Ethereum base layer, using cryptographic proofs. Although those proofs are still subject to the inefficiency of the EVM, in practice batching transactions can make transfers much more economical. The cryptographic VM being a zk-rollup with proper liveness, does not compromise on security. This is something I hope to see implemented soon as it would improve the security of the entire ecosystem.

It is important to keep in mind as we are building virtual machines and their surrounding blockchain protocols what the use cases are. If the application is a rollup to host a decentralized exchange then general cryptography capabilities may not be relevant. But as a base layer protocol, implementing cryptographic tools is the most important application. In a future post I will investigate what properties a virtual machine would have in order to effeciently execute a wide range of hashes, curves, circuits and verifiers within it.