This document reflects our initial planning for the respective year and represents the roadmap we have submitted internally within the EF.
Things in the Ethereum ecosystem move quickly, so please note that we will likely deviate substantially from this initial roadmap throughout the year.
See our "live" roadmap document for an up-to-date overview on what we are currently up to.
The roadmap is divided into the following "tracks", identifying our main focus areas for the year.
The EthereumJS libraries are often used in a development context, serving e.g. as an integral part of main Ethereum developer tools or as building blocks for browser UIs of decentralized applications (dApps). Improving the experience when working with our libraries is therefore a crucial part of our work, with the VM playing a special role here due to the central place it takes in development tools like Hardhat, Truffle or Remix.
This includes updating the JavaScript EVM to support the latest hardfork specification changes to provide respective early-on access for tools and in browser applications.
The JavaScript team takes part in Ethereum protocol-related research and actively supports developer testnets by providing early implementations of EIPs, contributing to and verfying the spec compliance of cross browser test cases (execution-specs and ethereum/tests suites). We use our EthereumJS client implementation as a research leveraging tool for early-on EIP testing in a multi-client context. The same client code base can serve later on as the basis for a lightweight browser based light client implementation integrating Verkle and/or Portal Network.
The research on verkle is nearing completion and it is expected that 2024 will be the year where parts of an integration/transition to a verkle tree based Ethereum network will happen. The JavaScript team is actively participating in the verkle testnet iteration runs like Condrieu or Kaustinen and we have started a TypeScript Verkle Trie implementation to make available to the TypeScript development community. 2024 will likely get a larger focus on the broader structural integration like Verkle based VM/client runs and implementations realizing the Merkle -> Verkle transition.
With the Ultralight client and networking library stack the JavaScript team maintains one of the three leading client implementations for the Portal Network, a protocol for a set of p2p networks that provide lightweight user access to protocol data and solutions for the challenges that L1 and L2 Ethereum clients face. Ultralight implements a Node.js client serving the Portal-JSONRPC specs, as well a React-based client that runs in a Browser or on a Mobile device. The Ultralight repository also includes an Browser based interface for exploring and interacting with locally running JSON-RPC clients of any kind.
Development of the Portal Network is ongoing, with Javascript team members taking leading roles in the research and development of current and future Portal Network specifications. Ultralight is one of three Portal Network client implementations involved in Portal-Hive interoperability testing, with Javascript team members contributing to the Hive test suites as well.
The PortalNetwork teams are currently overseeing the testing and deployment of the first networks. In 2024 we will focus on observing the behavior and performance of these early networks and finding solutions issues that arise, as well as developing the Portal Network project towards full State access and other goals. The Ultralight team will also continue to develop the Ultralight client and networking stack, while addressing the security and technical challenges of running a client in a browser environment as well as on mobile devices.
We have tested an early-on prototype connecting the Lodestar consensus client to the Portal beacon network with Ultralight, which might lead to a new light client architecture for the beacon chain. We will continue and broaden experiments here as a focus for 2024. In parallel other Portal-based network applications are continued to evolved and tested regarding production feasibility.
The Ethers.js library is one of the most popular tooling libraries used to interact with the Ethereum network. Primarily maintained by Richard Moore the library is downloaded by far over 1 million users and developers each month and is among the top 500 packages on NPM (by dependents). To further develop and maintain the library is therefore crucial to support the large community which has grown around the library over the years.
The following planning is based on the following theoretical assumptions on an outer timeline (note that there is no evidence or public statements that these dates will happen to any extend):
- Dencun HF happening very early in 2024
- Another more community-focused feature based HF happening sometime during 2024
- First stages of Verkle (transition) preparation reaching HF deployment stage
- Finalization of EIP-4844, Dencun HF deployment alignment, post production support
- Refactoring of the devp2p library to encompass also the high-level data handling to improve (re-)usability
- Refactoring/generalization of the blockchain to allow for storing "incomplete" blockchains (skeletons) (new usage contexts like beacon sync, generally expanded (re-)usability here as well)
- Production release of
SNAPsync (non-performant edition 😋) to allow for easier client testnet synchronization - Continued EVM profiling and per-opcode performance optimizations
- Successful WASM compilation of a suitable KZG implementation (e.g. c-kzg)
- Client: structural multi-threading integration, vm execution thread separation (performance)
- Own verkle package providing a functionally complete implementation (no TypeScript-written cryptography yet), see EIP-6800
- Verkle Kaustinen testnet syncing, see Verkle testnets
- Expand stateless statemanager (e.g. allow building state over time, handle incoming proofs), unified stated access API
- Improve portal-network-specs based on feedback and analysis of early network use
- Maintain Ultralight public bootnodes and bridge nodes
- Update Ultralight code base with latest portal-network-specs changes
- Develop solutions for browser and mobile client security and connection issues
- Implement merkle-trie research and draft prototype of Merkle based state client
- Largely development of Ethers v7
- Account Abstraction EIP-4337 as a first-class citizen, refactoring Runner
- Large focus on backwards compatibility; the migration from v5 to v6 was painful for many, but necessary, but with v7 the API changes must remain minimal
- Testing import times; using c4 create a test suite to test performance of common function and general import time
- Help major projects with any migration
- Updating existing tools, such as the Playground and release the Toolbox
- Burn down older issues
- 2-3 functional EIP implementations for anticipated feature HF
- VM/EVM: performance-driven structural local refactorings
- Browser based Verkle trie demo (for Ethereum community / research)
- Bootnode services for feature HF EIP devnets by providing early-on EIP implementations
- Contributing and feedback on cross-client test suites (ethereum-specs and/or ethereum/tests)
- Flat database backend for statemanager (performance/state serving)
- Client
SNAPsync release Part II (performance edition, build upon flat DB) (potentially allowsmainnetsync) - Client: networking/devp2p thread separation (performance)
- Improve and expand verkle trie implementation
- Analyze and eventually integrate TypeScript-written Verkle cryptography (browser usage)
- Early implementation of logic related to the Merkle->Verkle transition, see here for discussion and here for a technical analysis
- Implement verkle-related cryptography (proof verification, proof creation and related helpers)
- Maintain Ultralight public bootnodes and bridge nodes
- Update and improve Ultralight UI
- Integrate mobile and browser solutions
- Test and improve Merkle-based state network specs and state client prototype
- Multi-language documentation support; Academy WTF has helped a lot, so better tooling for them to more tightly integrate their Chinese translations with the documentation
- Establish better tutorials and demo projects via Bounties
- More extension packages; react, react native, etc.
- General support for Ethers and expanding support team
- Burn down older issues
- Implementation finalizations and testing for 2-3 functional EIP implementations for anticipated feature HF
- Production-ready EthereumJS Verkle-integrated stack (Verkle based execution, Verkle statemanager)
- Revisited L2 support analysis (based on stack maturation + adoption, e.g. OP Stack)
- Continued devnet feature HF bootnode participation, late stage integration testing
- Verkle
SNAPProtocol snap/2 support, see draft specification - Structural client modularization Part I for future light client support (sync/work mode abstraction)
- Functional/isolated implementation of logic related to the Merkle->Verkle transition
- Sync with future testnet iterations and participate in Merkle->Verkle transition testing
- R&D towards portalnetwork support of Merkle->Verkle transition
- Maintain Ultralight public bootnodes and bridge nodes
- Observe, analyze, and debug early portal network behavior
- Continue performance improvments, reducing code size where possible
- Continue burning down old issues
- Better GitHub tools to help triage old issues and properly mark issues
- PR tool to validate when only docs are changed, to allow UI merging
- Post-feature HF community support
- Integrate Verkle Transition into EthereumJS stack / API design
- Client UX evolution / robustness & resilience improvements
- Structural client modularization Part II for future light client support (browser)
- Participate in Verkle transition testnets and be "verkle-ready".
- Implementation and testing of Verkle solutions in parallel with L1 testnets
- Functional integration of portal clients with light clients
- Maintain Ultralight public bootnodes and bridge nodes
- Update Ultralight client and networking stack with latest portal-network-specs changes
- Preparing for v8 in the following quarter
- reaching out to teams to find new requests
- reviewing notes, PRs and issues
- Tutorials and documentation