The theoretical architecture of the WeaveVM network has evolved in various stages since we began speccing back in December 2023. In this blog post, we’ll discuss the technical architecture and key insights from our initial build of the WeaveVM protocol, and how we came to settle on an alternative – a full network.
📚 TL;DR – During R&D for testnet v0, WeaveVM transitioned from an EVM bytecode machine with lazy evaluation on top of Arweave into a fully-fledged network built on reth. Arweave connectivity is achieved with a custom Execution Extension that removes the need for on-node storage while retaining full compatibility with Solidity and the full ecosystem of EVM tooling.
Lazy evaluated WeaveVM: a VACP framework implementation
Coming from the Verifiable Atomic Computing Paradigm (VACP)design while working on MEM inspired us to attempt building an EVM protocol with the same underpinning architecture. In this section, we will outline how we specced the initial lazy-eval feature and why we decided to go after a more effective approach.
Challenges with Lazy-Evaluated WeaveVM
Originally, the lazy-evaluated WeaveVM was not intended to serve as a full EVM network, but rather as a bytecode machine that evaluates state transitions (transactions) on-demand. This design offers high transaction throughput and low latency for medium-sized applications.
However, as the global state size increases, the system will encounter scaling issues. Additionally, achieving complete backward compatibility with the existing EVM stack—including RPCs, APIs, and tools like MetaMask and Remix—proved difficult. These issues resulted in a predictably poor user and developer experience.
A RESTful EVM Bytecode Machine
Lazy WeaveVM was designed as the first RESTful EVM bytecode machine, composed of two main components: a bytecode executor and a sequencer. The sequencer orchestrates and indexes transactions, while the bytecode executor has been made open-source. The MEM sequencer can be used as a sequencer for a Lazy WeaveVM instance as both MEM and Lazy WVM are implemented on top of the VACP framework. You can explore the codebase here.
Explore the architecture behind Lazy WVM, based on the VACP framework, in our detailed research article: WeaveVM and VACP.
WVM Testnet v0: a network
After our RnD led us to sunset the development of WVM as a lazy evaluated bytecode machine, we started looking into developing a complete WVM network, instead of a protocol.
After careful research we decided to use reth as a basis for the WVM network. Reth, developed by Paradigm, is a new Ethereum full-node implementation focused on being user-friendly, modular, fast, and efficient. Reth is an execution client compatible with all Ethereum consensus client implementations that support the Engine API. As a full Ethereum node. (source)
Technical approach
WeaveVM is a fork of reth. Custom network configurations have been made on the WVM fork such as gas limit, block time and mempool parameters. The node for WeaveVM is referred to as wvm-reth. To add Arweave storage and data indexing, wvm-reth will rely on a custom Execution Extension that adds a data pipeline between BigQuery and Irys.
wvm-reth BigQuery ExEx
What are ExExes?
Execution Extensions (ExExes) are post-execution hooks for building real-time, high performance and zero-operations off-chain infrastructure on top of reth.
WeaveVM BigQuery ExEx
The wvm-reth node features an Execution Extension (ExEx) designed to transfer full node storage crate data to Google BigQuery. This process facilitates the indexing of data on Arweave.
Data Pipeline From WeaveVM to Arweave
The ExEx implements a data pipeline specifically designed to perform Extract and Load (EL) actions on WVM network data. This pipeline extracts data from BigQuery, conducts minimal data transformation, and then loads it into Arweave using Irys.
The ExEx will be open source and usable as a template for any reth client aiming to push EVM data, OOTB, to Arweave.
The state of WeaveVM now
Due to the shift in architecture design and approach, the WeaveVM testnet (consistent across all releases) maintains 1:1 compatibility with the existing EVM ecosystem tech stack.
What’s Next
In our next blog article, we will discuss the R&D developments of tWVM gaseconomics, including the dynamic pricing of Arweave data storage combined with an EVM fee market.