Discover more from The Vagabond Way
Part 2: Introduction to Rollups - The Power of the zkEVM
Part 2 of a 2 part series discussing rollups, with an emphasis on the zero knowledge Ethereum virtual machine, and its role in scaling blockchains
Before reading this article, it’s recommended you read: Part 1: Introduction to Rollups - The Future of Scaling Blockchains
Part 1: Introduction
The zkEVM has been touted by many as the holy grail of scaling Ethereum and blockchains.
However, many market participants do not fundamentally understand why this innovation will be a key pillar in scaling the Ethereum network, helping to onboard the next billion users onto the Ethereum network.
Starting off, it’s important to understand what virtual machines are, and why the Ethereum virtual machine is one of the most powerful tools in the Ethereum ecosystem.
A virtual machine (VM) is a complete computer system that is emulated by software. It behaves like a physical computer but executes code more slowly due to the overhead of running on top of a real machine.
Part 1.1: Crash Course on Virtual Machines
VMs are often used to run different operating systems on the same hardware or to provide an isolated environment for testing or development. There are three main components to a VM: the VM Monitor, the VM Shell, and the VM Executable (VMX).
The VM Monitor is the hardware emulation layer that abstracts the hardware away from the VM. The Virtual Machine Shell is a user interface that allows users to interact with the VM. The VMX is the actual software that runs on top of the hardware, and it is where the code is executed.
Virtual machines are typically created using a hypervisor, which is a piece of software that allows users to create and manage VMs. Hypervisors can be either bare-metal or host-based. Bare-metal hypervisors run directly on the hardware, while host-based hypervisors run on top of an existing OS.
Virtual machines have a number of advantages over physical machines. They are more flexible because they can be easily created and destroyed as needed. They are also more portable because they can be moved from one physical machine to another with ease. Finally, they are more isolated, because each VM is completely separate from the others. This allows end users to test and deploy software on different VMs to isolate risk from the entire system as a whole.
Further, the EVM makes it possible to create decentralized applications (dApps) on the Ethereum blockchain. Every Ethereum node runs an EVM instance, so that they may all agree on the same set of instructions that need to be executed by the network.
The EVM bytecode is executed by the EVM and is used to create contracts on the Ethereum blockchain. The bytecode is compiled from source code written in high-level programming languages like Solidity. The compiled bytecode can be deployed to the Ethereum blockchain and it will be executed by the EVM. The EVM uses gas as a way to limit the amount of work that a transaction can do. This is important because it prevents transactions from taking an excessively long time to execute, or from doing too much work and thereby taking up too much space on the blockchain.
The EVM is a stack-based machine. The bytecode instructions are executed one after another. The instructions can pop values from the stack and push values onto the stack. The instructions can also modify the state of the EVM. The state of the EVM is stored in a global state trie (yes, it is spelled “trie”, not “tree”). The global state trie is a mapping between addresses and account states. It can be seen as a global state that is constantly updated by transaction executions.
The main disadvantage of the Ethereum Virtual Machine is that it is extremely resource-intensive. In order to run a single transaction, the EVM requires a large amount of memory and processing power. This makes it difficult to run large-scale applications on the Ethereum network. Additionally, the EVM is not well suited for handling complex applications.
All Ethereum clients currently used include an EVM implementation. There are many different standalone implementations, in different programming languages, These include:
Pantheon — Java client by PegaSys
Geth — Go client
Parity — Rust client
Aleth — C++ client
Ethereumj — Java client by the Ethereum Foundation
Harmony — Java client by EtherCamp
Seth — Seth is an Ethereum client tool — like a “MetaMask for the command line”
Mustekala — Ethereum Light Client project of Metamask.
Exthereum — Elixir client
EWF Parity — Energy Web Foundation client for the Tobalaba test network
Mana — Ethereum full node implementation written in Elixir.
Hence, the EVM is an extremely powerful tool that serves as one of the major backbones of crypto. Many networks outside of Ethereum use some version of the EVM. This includes networks like Avax, Binance Smart Chain, Polygon, Fantom and so forth. However, it is not yet perfected, resulting in some considerable downsides that engineers continue to attempt to solve.
Part 2: Understanding the zkEVM
The zero-knowledge Ethereum Virtual Machine (zkEVM) is a modification to the standard Ethereum Virtual Machine that allows for heightened privacy and security when executing smart contracts. In particular, the zkEVM utilizes zero-knowledge proofs to obscure the contents of transactions and smart contracts from observer nodes on the network. In contrast to the standard EVM, a zkEVM proves the correctness of program execution, including the validity of inputs and outputs used in the operation.
This makes it more difficult for malicious actors to gain insights into the inner workings of Ethereum-based applications and potentially exploit vulnerabilities. Furthermore, as part of rollup technology, it allows for exponentially increased scaling potential by transferring computation and state storage off-chain.
In general, a VM can be considered EVM compatible if it can execute dApps created to run in the EVM environment. These VMs must be able to execute smart contracts written in high-level programming languages like Solidity or Vyper. What makes zkEVMs compatible with the EVM is the fact that they can execute smart contracts without large changes required to the underlying opcodes used in the EVM. An opcode is simply an instruction processed by the EVM.
Part 2.1: The zkEVM Architecture
The zkEVM transitions between states as a result of operations occurring when programs execute. However, the zkEVM goes further by creating a proof to prove the correctness of every part of the computation.
The proofs created are used to verify three different components of the zkEVM. These include:
Bytecode Access: A read-only view of the contract's code that allows verification without having access to the private keys. In this section, a check is run to ensure the correct code was run from the correct address.
Computation: Simply checks if the opcodes were run correctly, without any faults.
Read-write operations: Read-write operations in the zkEVM are those that allow modifications to be made to the underlying data structures. Computations ensure the program fetches the correct values from the stack and checks if it wrote the correct values from the stack post-execution.
Further, The zkEVM is divided into three unique parts, each important in the architecture of the entire system. An execution environment, a proving circuit, and a verifier contract.
An execution environment is a program that provides the runtime support for a piece of software or code to run. The zkEVM execution environment takes the initial state and current transaction to output the new state.
The proving circuit is used to verify the execution of a smart contract on the zkEVM. It consists of two parts: a pre-compiled verification contract that is used to check the validity of the smart contract's execution, and a verifier that checks the validity of the proof generated by the verification contract.
A verifier contract is a smart contract that is used to verify the correctness of computations in the zkEVM.
These three components all come together to form the bedrock architecture of the zkEVM, ensuring the correctness of each output.
In summary, a zkEVM can be described as a virtual machine that runs on a zk-rollup, is EVM-compatible and is zk-proof friendly.
Part 2.2: ZkEVM Implementations
When it comes to implementing the zkEVM, there are generally two strategies:
Directly supporting the established set of EVM opcodes, which are already fully compatible with the set of Solidity opcodes. Polygon Hermez, Polygon’s implementation of the zkEVM, currently is utilising this implementation.
Designing a new virtual machine that is solidity compatible and zk-proof friendly, then adapting EVM development tools to fit this new architecture. Another leader in the zkEVM race, zkSync, is using this strategy.
Both of these solutions have their respective advantages and disadvantages, these include:
Fully compatible with the current set of developer tools due to being compatible with standard EVM opcodes as well as using the same compiler.
Higher security due to better inheriting the base layers security model.
Overall a faster deployment of dApps on the zkEVM, with reduced resources and expertise required.
Does not require intensive work in order to be compatible with EVM opcodes.
Much more flexibility due to not being bound by the original set of EVM opcodes.
Requires less work on the actual zkEVM architecture to allow the use and adoption of zero-knowledge technology faster.
As highlighted above, both different implementations have both advantages and disadvantages depending on how they are implemented. Depending on the use cases and the situation, both can be effective at scaling dApps to accommodate a large number of users.
Part 3: Summary
The zkEVM is a powerful innovation that will help scale the underlying Ethereum blockchain. Currently, many alternative layer 1 networks have appeared to try and solve the trilemma, a problem plaguing blockchains since their invention.
However, as these layer 1 networks continue to operate and state bloat increases, a need for scaling solutions is created. Furthermore, these layer 1 networks need to bootstrap security, which is extremely difficult, especially as more of these novel networks appear.
Rollups solve the trilemma by processing all the costly work on a separate chain. Moreover, rollups do not need to worry about bootstrapping security since they inherit the security of the layer 1 they sit on top off. This effectively allows users to enjoy high speeds, without compromising on security and decentralisation.
As rollups become more dominant and the technology more robust, alternative layer 1 networks will find it much harder to compete with the superior technology, making them obsolete in the long term.
🗡️Thank you for reading our work and supporting our message🗡️