New VMs in rollups will solidify Ethereum's lead

For Ethereum to keep its lead, it’s not enough to be the most secure, decentralized, and scalable. What is a programmable blockchain without the programmer? In order to keep and attract new developers, Ethereum must find an outlet for rapid innovation on the protocol level.

Fortunately, rollups bringing scale is only half of the story; rollups are excellent grounds for experimentation. Alternate VMs in Arbitrum, zkSync, and StarkNet will empower developers to build more robust and versatile applications than ever before, with industrial grade tooling. And the upcoming mass migration to these rollups is the perfect opportunity to move past the weaknesses of the EVM and solidify Ethereum’s lead as the number one platform for blockchain development.

Now I know what you’re thinking:

​

https://i.redd.it/18p54ajghvq71.gif

But hear me out.

Last weekend I was able to port my smart contracts from Ethereum to Arbitrum using ethers.js and HardHat, with no code changes. And after asking around, this seems to be the typical case. In fact, Anton spent more time getting ETH bridged to Arbitrum than actually deploying Opyn. True, there are changes in gas accounting, but this arises from a fundamental difference in the scarcity of resources between L1 and L2. So what’s going on behind the scenes?

> Arbitrum's AVM:

The AVM keeps the EVM's uint256 data type and its instructions, but made some changes to fit the needs of a Layer 2 and a multi-round challenge protocol:

• Arbitrum separates execution and proving, so aggressive optimization can be applied to local execution (the common case) and proving can be done in constant time and space.
• The AVM uses ArbOS to track resource usage and turn L1 smart contract work into L2 code, significantly reducing the cost of computation and storage at Layer 2.
• Because Layer 2's must post a Merkle hash of the full state with each block, the AVM opted for a different memory model with immutable memory objects to make merklization much cheaper.

Downstream of these changes, and when developers aren't just porting their code but actually developing on Arbitrum, I think they will realize that it's actually better. Arbitrum offers a much higher gas transaction limit than Ethereum and no limit on contract size. And what about the developer tooling? The "monopolies" Chainlink, Etherscan, Infura, and The Graph were live from Day 1. And I would argue Ethereum's other developer tooling is actually not as sticky as Solidity is: most early developers made the transition from truffle, to hardhat, and now to dapptools.

​

When it comes to ZK Rollups, due to fundamental differences between the EVM and proof systems, the design philosophy trends toward preserving the Solidity language rather than the EVM bytecode and construction itself.

> zkSync's zkEVM:

zkSync uses a compiler-based approach to strike the perfect balance between creating a circuit friendly and CPU-like VM that can efficiently execute operations over 256 bit integers. Breaking this down into 2 critical design decisions:

1. Circuit friendliness is a priority, but remaining reasonably close to current computer architectures makes things easier for developers, developer tools, compilers, and debuggers.

The zkEVM uses a read-write RAM memory model so anyone familiar with x86 or ARM assembly can easily write code for the zkEVM and build compilers and other toolchain technologies (using LLVM). This memory model also allows for a future extension of copy-on-write to reduce explicit copies that arise in some popular Solidity programming patterns.

1. Instead of paying for EVM bytecode execution simulation inefficiencies at runtime, the compiler performs all the necessary transformations during an O(1) offchain computation step.

Consider the MSTORE8 opcode, which does a 1 byte memory write. To support this, memory must be aligned and readable by a single byte, which would be highly inefficient because MLOAD needs 32 bytes at once. Or, MSTORE8 could be simulated as a couple of MLOADs, bit manipulations, and MSTOREs after. In the second case, a cost (in constraints) to execute the “simulation” would be indirectly paid on every cycle of the VM even though MSTORE8 is a rarely used opcode, since in circuit environments, all branches are executed.

This inefficiency is bypassed by the compiler, which outputs the sequence (read - update - write), and this cost is only paid when the user indeed needs to address a single unaligned byte in memory.

The compiler-based approach comes with 2 major benefits: developers only pay for what they use, and the VM can focus on working with the uint256 as efficiently as possible. This approach is especially favorable for cases when smart contracts are programmed in languages outside of Solidity, such as Zinc (their Rust-based circuit friendly language), Vyper, and in the future, Rust.

On top of this, zkSync is building industrial grade developer infrastructure. They chose to use LLVM, a set of compiler and toolchain technologies started at Apple and an integral part of development tools for macOS and iOS. With LLVM, any language can be easily supported by developing a front end: Vyper is already in progress and Rust is planned. LLVM also sets a strong foundation for a debugger, linker, assembler, disassembler, and binary utilities, which will be shipped one day.

Familiar languages, developer tools, and architectures will lower the barrier for traditional developers to get started programming smart contracts on Ethereum. And I don’t see why support for Rust wouldn’t trigger many Solana projects to port over!

> StarkNet's Cairo VM:

Solidity is supported via Yul+AST transpilation to Cairo, but the Cairo VM completely rejects any notion of EVM in favor of high performance in a truly native zk VM:

In modern CPUs, the basic data type is 64-bit integers, but proof systems use fields.

So,

The EVM's basic data type is uint256.

Cairo's basic data type is an integer in the range 0 ≤ x < P where P is a prime number (e.g. 2251+ 17⋅2192 + 1) and all computations are done modulo P.

The EVM uses deterministic computation, but because the goal of a proof system is to prove that some computation is correct, it is much easier to use "nondeterministic computation", where you start from the solution instead of operating on the inputs.

So,

The EVM uses a read-write memory model.

Cairo uses read-only nondeterministic memory or "write-once memory", where the value of each memory cell is chosen by the prover and cannot change during program execution. Values that may change are held within the registers.

StarkNet introduces a new programming model for building on the full stack for STARKs. They are inventing and defining the developer experience for proof systems, and just today, released an alternative to human audits: a formal mathematical proof that proves code is error-free.

​

Arbitrum's AVM is Ethereum development unlimited.

zkSync's zkEVM enables circuit friendly programming with familiar languages and architectures.

And StarkNet's Cairo VM places the power of STARKs in the hands of all blockchain developers.

We are no longer building in a desert. Oceans are here.