EOS EVM Architecture Deep Dive
Please note that this article was first published on March 24, 2023 and some of the information presented in this piece may have changed since then.
The EOS Ethereum Virtual Machine (EVM) has become a much anticipated release within the EOS community. It’s been in the works for over a year and was a massive undertaking, involving contributors from across the ecosystem. Development is in the final stretch before launch, with the mainnet beta (0.4), set to launch on April 14, 2023.
Once EOS EVM is live, EOS will be exposed to a slew of new developers and projects from other ecosystems. EOS EVM is positioned to be one of the most performant EVMs on the market, while maintaining compatibility and feature parity with traditional Solidity environments. In this article, we’ll be diving into what makes this critical piece of infrastructure so powerful and explaining some of the architecture behind it.
Check out the recent discussion with the EVM Developers for more information on this critical piece of ecosystem infrastructure.
EOS EVM in a Nutshell
EVM stands for Ethereum Virtual Machine. In the Ethereum ecosystem it is a series of smart contracts that allow developers to deploy and run decentralized applications (dApps) that are written in Solidity. The EOS EVM is an emulation of the Ethereum EVM, housed within an EOS smart contract.
It offers feature parity to other EVMs in the space but with unmatched speed, performance and compatibility. This is all thanks to the architecture of the design and the powerful nature of EOS native.
EOS EVM: The Ethereum Enabler
When EOS first launched, many referred to it as an Ethereum killer, but this has never been the purpose of EOS and that doesn’t change with the launch of EOS EVM. Instead, EOS EVM will be an Ethereum enabler, allowing Solidity developers to access unmatched scalability within their projects.
The full functionality of EOS native, powered by Antelope.io, has barely been explored. So, there are many new development opportunities to build the next generation of Web3 applications on that layer. But this opportunity for growth is a double edged sword. There is currently a lack of proper tooling, educational resources and infrastructure that could allow dApp developers to get up and running quickly on the native layer.
On the other hand, Ethereum’s native language, Solidity, has become a cornerstone of the Web3 industry. There are a large number of open source tools, tutorials, projects and developers that have been growing within the Ethereum ecosystem ever since its initial release in 2015. So, it’s very easy for a new developer to learn the ropes of Web3 development and get building as soon as possible by accessing Solidity libraries.
With the launch of EOS EVM, developers are given the best of both worlds, combining the powerful performance of the EOS tech stack, with the accessible resources of the Ethereum community. Because of this, enabling Solidity development on EOS is the next major step to mass adoption of the network.
The Role of EOS Native in Mass Adoption
Despite the current focus on EOS EVM, the native layer of EOS remains a flagship product of the ecosystem. With the upcoming release of Leap v4.0.0, EOS native is going to continue to be innovated upon in tandem with the EOS EVM.
EOS native is written in C++, a popular language amidst traditional developers due to its speed and robust libraries. It is often used in technical projects that have strict performance requirements, such as operating systems and games.
Because of this underlying architecture, the smart contracts built on EOS native are much more efficient, powerful and often favored by developers entering the space from Web2 or other traditional areas of computer science. With GameFi on the rise, EOS native remains a strong vector for adoption by enabling game developers that were already building in a Web2 environment to seamlessly integrate Web3 elements as needed.
As infrastructure work continues on EOS native and current tooling from the Ethereum ecosystem launches on EOS EVM, opportunities for innovation will emerge that won’t be possible in any other ecosystem. With this in mind, EOS is positioning itself as a positive sum development environment. The perfect place for Web3 veterans or those just entering the space to coordinate resources and innovate collaboratively.
Technical Subtleties of the EOS EVM
There’s a lot going on under the hood of the EOS EVM in order to ensure that it maximizes performance and ease of use. Here are just a few of the innovative design choices that were implemented over the past year.
Silkworm Architecture
A major architectural augmentation that contributed to the shifting launch timeline was the implementation of Silkworm as the EOS EVM’s execution client. Silkworm is a C++ implementation of an Ethereum node, under the specification of Erigon. It’s being used to support the RPC and increase compatibility in this area.
The goal of its design is to be the fastest Ethereum client, without sacrificing the performance or readability of its code. Below are key highlights that contribute to the power of Silkworm, as presented in an article by EtherWorld:
- Silkworm is easier to understand as the code base is new and doesn’t contain any major legacy features.
- It has a neutral sentiment in the developer community.
- Silkworm is licensed under the Apache-2.0 License. This license is Permissive, meaning it has the least restrictions and can be used in the most projects.
- Silkworm uses evmone as its EVM interpreter, which is already known to be the fastest, fully compatible EVM implementation.
- Silkworm uses MDBX, which is the fastest embedded key-value store, with fully ACID transactions.
One of the primary reasons for this architectural design is to serve the RPC requests in a way that is scalable and fully compatible with other areas of the ecosystem. Developers and users require methods to access the latest state of the EVM environment in order to query on-chain data or to generate new transactions. This is where the RPC comes into play.
An EVM transaction is first processed on the EOS blockchain by the EVM contract. Afterwards, it is extracted from the EOS blockchain by a separate Silkworm-based EVM node to be reprocessed so that the node keeps its view of the state of the EVM environment in sync with what the contract should see. This state is what then allows the RPC node to serve standard RPC requests from clients such as a MetaMask wallet.
By keeping the RPC nodes separate from the Leap nodes that process the EOS blockchain, new instances of the RPC nodes can be spun up as a means to scale to meet the demands of client RPC requests. Each additional RPC node, which only needs to track EVM state, can simply be fed EOS blocks from a far fewer number of Leap nodes, which are responsible for tracking all EOS state.
Additionally, a major benefit with using Silkworm, as opposed to an alternative node implementation, in EOS EVM is that it enables a lot of core code to be shared between the EVM contract and the nodes serving RPC requests. This reduces the risk of incompatibility between the two environments. Since Silkworm is implemented in C++, it was trivial to compile into a WebAssembly and run within the EVM contract. Maintaining compatibility between the two environments inherently by sharing the same code has especially been an important advantage as further changes have been needed to be made to the Silkworm code to support custom functions within EOS EVM such as the trustless bridge.
With all of this in mind, despite the delays it caused, the migration to Silkworm has become an important aspect of the EOS EVM.
Crypto Primitives
An important discussion in the current Web3 landscape is that of user privacy. As more enterprise applications enter the space, implementing privacy preserving tech becomes even more necessary. This has led to a rise in popularity around tooling such as zk-SNARKS, which could not be executed on EOS until recently.
When the Leap 3.1 hard fork took place, the Crypto Primitives feature was introduced to the Antelope protocol to enable new functionality that could support this and other complex operations. The feature makes new host functions available to all EOS contracts, while mapping 1-to-1 with the Ethereum cryptography precompiles.
The Ethereum ecosystem already has a lot of these functions in place and they could be executed in theory. However, expensive gas fees and slow transactions can lead to both technical and economical roadblocks. With EOS EVM, these barriers go away and developers are able to experiment with libraries that would be difficult to execute in other environments.
In addition to bringing functionality for zk-SNARKS to the EOS EVM, developers can now take advantage of the same primitives on the native EOS layer. This will again play an important role in the adoption of EOS native, alongside EOS EVM.
1 Second Block Times
As previously noted, performance and compatibility were important considerations in the development of the EOS EVM. Both of these came into play when making a decision on how fast the EVM block times should be. While EOS native boasts half second block times, EOS EVM block times are one second. This is much faster than Ethereum block times of ~12 seconds and it maintains compatibility that could be lost if the design was any shorter than one second.
Half second block times are faster than one second in theory, but in practice it’s more complicated. First, the metric discussed here is latency not throughput. EOS EVM benefits from the high throughput enabled by the EOS blockchain regardless of what block times were chosen. Second, in practice, the actual latency observed from sending a transaction to getting confirmation that it is included in a block does not simply halve by reducing the block time from one second to a half second; the reduction in latency is less significant than that. So dropping the block time from one second to a half second has small performance gains but it does come with potentially significant losses on the compatibility side of the design.
This is due to the Ethereum specifications, regarding what the block time interval is, the EVM opcode to return the current block timestamp only has a resolution of seconds. This means that in order to have a one-to-one block mapping, where every EOS block corresponds to an EVM block, it’s necessary to truncate the timestamp and send an identical timestamp over two distinct consecutive blocks.
While duplication of the timestamp across distinct blocks might not cause too much damage, it would be a design risk because it is a break in how traditional Solidity contracts expect to interface with an EVM. In developing the EOS EVM, it was important to ensure that developers coming from Ethereum would have as similar an experience as possible to their native chain. So the choice was made to go with a block time that would have the least damage to compatibility.
Additionally, the design makes it possible to decouple both the native and EVM block times. This means that in the future, if the EOS Network decided to change the block frequency, it wouldn’t impact the EVM runtime. While there are no plans to make any upgrades in this regard, developers can rest assured that dApps built on the EOS EVM will be compatible with any future changes to the network architecture of EOS.
Access Funding, Get Building & Get Ready for Launch!
EOS EVM is positioned to become one of the most widely adopted EVMs and enable a new wave of Ethereum developers on EOS. This is largely thanks to the architectural choices explained in this article, including:
- The C++ implementation of Silkworm to support the RPC, allowing nodes to scale to meet the RPC demands of clients.
- Crypto Primitives architecture introduced with Leap 3.1, enabling zk-SNARKS and other complex computations on both EOS EVM and EOS native.
- One second block times, which enables great performance while still maintaining maximum compatibility between EOS EVM and the traditional Ethereum EVM
This week, the EOS EVM reached code complete and the new testnet is slated for launch on March 27th. With mainnet going live on April 14th there’s never been a better time to start building on EOS.
Despite all of the advancements that EOS EVM has undergone, work is not slowing down on EOS native. In fact, with less resources needed on EVM at this point, core protocol developers can devote more of their attention to EOS native. This will ensure that EOS native continues to serve as a flagship product of the EOS Network, while still allowing Solidity projects to take advantage of all the benefits that EOS has to offer.
Whether someone is building on EOS EVM or EOS native, there are plenty of resources and funding available to help projects get up and running quickly. Learn more about the funding opportunities in the EOS Ecosystem here. Check out the last article on the EOS EVM for details on how to connect to the current testnet. Then head over to the EOS Documentation and EOS Learn Portal for guidance on how to build and deploy dApps on EOS.
EOS Network
The EOS Network is a 3rd generation blockchain platform powered by the EOS VM, a low-latency, highly performant, and extensible WebAssembly engine for deterministic execution of near feeless transactions; purpose-built for enabling optimal Web3 user and developer experiences. EOS is the flagship blockchain and financial center of the Antelope framework, serving as the driving force behind multi-chain collaboration and public goods funding for tools and infrastructure through the EOS Network Foundation (ENF).
EOS Network Foundation
The EOS Network Foundation (ENF) was forged through a vision for a prosperous and decentralized future. Through our key stakeholder engagement, community programs, ecosystem funding, and support of an open technology ecosystem, the ENF is transforming Web3. Founded in 2021, the ENF is the hub for EOS Network, a leading open source platform with a suite of stable frameworks, tools, and libraries for blockchain deployments. Together, we are bringing innovations that our community builds and are committed to a stronger future for all.
