首頁 > 熱點新聞 > EF-Supported Teams: Research & Development Roundup
EF-Supported Teams: Research & Development Roundup
  • Rory
  • 2022-12-30
  • 2902
  • 熱點新聞
廣告 廣告

Consensus R&D (aka EF Research Team)

Authored by Danny Ryan and Hsiao-Wei Wang

This was an extraordinary year. With the magic of client teams, DevOps wizards, testers, stakers, and the community at large, we successfully merged !

THANK YOU ALL for contributing to The Merge, massively reducing energy consumption, and making Ethereum a more secure and sustainable protocol. Switching Ethereum mainnet consensus mechanism to Proof-of-Stake (PoS) was a significant milestone the Consensus R&D team has been working on for many years -- but this is not the full story!

Additionally, the Consensus R&D team has been tackling emergent problems in the MEV domain (e.g. proposer builder separation (PBS), MEV smoothing/burning), pondering security improvements to the beacon chain (e.g. single slot finality (SSF), single secret leader election (SSLE)), and a whole host of other consensus research – multi-dimensional EIP-1559, better aggregation techniques, optimized applied cryptography, and more.

Next year, our team will continue working on, but not limited to, the following:

  • Scheduled and tentative protocol upgrades

    • Continued refinement of the EIP-4844 consensus-layer specs. At the same time, we are collaborating with developer teams on the CL+EL clients interop and devnets.

    • To use KZG polynomial commitments in EIP-4844, we need to generate the "trusted setups" via KZG Ceremony with public participants. You can find more progress updates in the recent KZG Ceremony Grant Round RfP blog post.

    1. Withdrawals functionality: this feature will enable stakers to withdraw their balances from the beacon chain to their execution layer accounts. The consensus-layer core specs are nearing completion, and client teams are actively implementing and testing the functionality.

    2. EIP-4844 aka proto-danksharding:

  • Other post-merge research topics, e.g., proposer/builder separation (PBS), Verkle trie/statelessness, single slot finality (SSF), data availability sampling (DAS), fee market refinement, single secret leader election (SSLE), and more.

Cryptography Research

Authored by Dankrad Feist

The cryptography team has taken an initiative to make Ethereum secure against quantum computers. Our team members have contributed to a post-quantum signature scheme that is to be standardized by NIST (National Institute of Standards and Technology). We continue to work in this direction and build a signature scheme that scales better via aggregations. Further down the road, we may improve the scalability via better aggregation techniques, or via different hardness assumptions.


Authored by Grant Wuerker

The Fe team aims to provide the Ethereum community with a safe and effective smart contract programming language. The team is responsible for the design of Fe-lang and the development of its core components, including the compiler, standard library, and tooling.

Over the past year, the team has been focused on adding language features and preparing for our first beta release. Below are the highlights from 2022:

Notable language features:

  • Low-level intrinsic functions (0.12.0).

  • Nested structs in memory (0.13.0).

  • Std library with evm and context modules (0.14.0).

  • Nested structs in storage (0.14.0).

  • const folding (0.14.0).

  • Function argument labels (0.15.0).

  • Nested structs can be returned and passed into functions (0.19.1).

  • Braces! (0.19.1).

  • Traits and generic function parameters (0.19.1).

  • Enums and match statements (0.20.0).

  • mut keyword (0.20.0).

Please see the releases page for a complete list of changes.


  • @zjhmale developed a Hardhat plugin.

  • A couple contributors developed VS Code plugins:

    • @vuvoth's

    • @zjhmale's


  • Hosted Fe Day, presented at Solidity Summit, and sat in on a languages panel at Secureum TrustX in Amsterdam for Devconnect 2022.

  • Participated in the Language Tug of War panel in Bogotá for Devcon 2022.

  • Launched Bountiful and got hacked by @plotchy.

  • Received contributions from a total of 12 contributors.


  • Yoshi has been working on a compiler backend specialized for smart contracts named Sonatina.

  • A few simple contracts were verified using K.

Our top priorities moving into 2023 are: first beta release (see: Fe's path to production), better generic support, better constant support, and improvements to the standard library. We are especially excited about future Bountiful challenges.

Formal Verification

Authored by FV team


We’ve spent most of this year rewriting the symbolic execution engine in hevm. This rewrite decompiles EVM into a custom intermediate representation and then issues SMT queries based on the structure of the terms in this IR. This architecture gives us significantly more control over the details of the SMT encoding and makes the implementation of custom simplification and static analysis stages much easier.


In the past months we focused on bug fixing and UX improvements. One important new feature that was added is the possibility to use the Horn solver Eldarica when using the CLI or JSON interface from solc.


A few months ago we started Yools as a proof of concept, testing the idea that verifying Yul instead of both Solidity and EVM bytecode has a lot of advantages. The preliminary results are quite promising, and we’re excited to continue working on it in 2023.

PolySolver, a solver for generalized polynomials

We started this research branch with the goal of verifying properties of polynomials from ZK apps/circuits. We recently started applying it to R1CS circuits in collaboration with 0xPARC and other organizations.


Authored by Péter Szilágyi

2022 was a tad slower year when it came to shipping Geth features, but that is primarily due to the Ethereum Merge, which took up most of the team's time for testing, tweaking and generally making sure everything ticks. That said, we do have a number of interesting things we've been working on in between.

Path-based trie storage

Perhaps the highlight upcoming feature - at least for us as maintainers - is Gary's path-based trie storage. We figured out (a few years back) how to do state pruning, but needed to get rid of one blocker: fast sync. That meant shipping a new sync protocol (snap) not only for Geth, but also helping other clients get it out the door. With fast sync murdered, we can finally change the state-trie storage model in Geth from hash keys to path keys. Whilst this is an insanely invasive change in Geth, it will finally allow us to do full, real-time historical state pruning during block processing. The cherry on top is that full sync actually gets faster. :)

TL;DR A small teaser from a while back.

Light clients

One victim of The Merge was light clients. Previously, they only needed to follow the chain of headers, check the PoW, and download Merkle proofs to access the Ethereum state. In a post-merge world, however, PoW is gone, and thus light clients cannot rely on execution layer headers alone to follow the chain. The only viable solution is to follow the beacon chain headers, at least some parts of it. Zsolt has been working full-time on reproducing the bare minimum beacon data structures in Geth and exposing them in the LES protocol to make light clients workable again. This also requires collaborating with consensus client teams to have access to the needed data in the first place, so it takes a while. The upside is, however, that this work might not only fix light clients, but also enable full (but non-block-producing) nodes to follow the chain without a consensus client attached! Wouldn't that be amazing, to only babysit one program again!


We're barely past the merge, but protocol dev never stops. The Shanghai hard fork is already semi-scheduled (exact contents still a bit debated), and Matt has been working tirelessly on the two main features: withdrawals and Ethereum Object Format. The former is already being deployed on cross client testnets. Withdrawals will finally complete The Merge, enabling staked ether and accumulated rewards to be collected, while the EOF work will enable a cleaner internal organization of smart contracts, simplifying compiler work and also enabling a few more advanced features to be implemented. After the year's #TestingTheMerge, Marius is currently helping in a similar role getting Shanghai ready and out faster and better.

Blob transactions

Possibly delayed until the Cancun hard fork, but already in full development is the support for blob transactions (aka 4844), which would allow the Ethereum network to create huge transactions (128KB a pop) that only have an ephemeral lifespan (2-4 weeks). The purpose of these transactions would be to allow layer 2 solutions to commit to and prove large batches of data very cheaply, without incurring an indefinite storage cost on all full nodes. This should make L2s significantly cheaper and thus allow Ethereum to - hopefully - onboard the next stream of users. This work has been pioneered by Coinbase's Jessie and team and is currently being picked up by Peter to integrate where possible and reimplement where Geth's DoS requirements require a different approach from the original PoC work.

Verkle trees

Looking even further out, Guillaume has been working on replacing Ethereum's Merkle trees with Verkle trees. This could end up being the most invasive change ever done to the Ethereum execution layer, with implications across pretty much every aspect of the network. The advantage of Verkle trees would be greatly simplified state proofs, which might just enable stateless clients. This year, he put together a functional PoC, originally running in a PoW testnet and currently a PoS testnet. For now, performance-wise, there's still work to be done as it's about 2.5x slower than Merkle trees, but we'll get there. A lot of research and development is being done trying to figure out how to do the transition from Merkle to Verkle without pausing the entire network (converting the data structures takes over a week currently).


Over the years we've had our ups and downs with using go-leveldb as our storage engine. We're forever grateful to Suryandaru Triandana for creating it and helping us out now and again! However, the project being unmaintained for many years now left us without a viable upgrade path: we couldn't get our optimizations in and some upstream changes even introduced DoS vectors, unfixed to this very day. We've tried out many alternative databases (RocksDB, BoltDB, Badger, Postgres) and converged on Pebble, a relatively new - but actively maintained - port of RocksDB in Go. Jared is currently pioneering the integration works - which primarily consists of getting that one or two missing features that we rely on accepted in the upstream Pebble projects. Switching out LevelDB to Pebble, we don't expect performance to change, just for us to sleep better at night :P.

Built-in transaction tracers

Perhaps not the most visible feature, but we've worked a lot on tweaking and extending Geth's built-in transaction tracers - which, if you missed the memo - now all run natively in Go and are quite speedy. Sina's been the primary contributor on this front, also making some of the tracers configurable. A large feature we've been planning and are currently working on is live-tracing, which would allow Geth to be started with some tracers explicitly requested on startup, which would run along with normal block processing, storing the tracing results on disk. This should allow users relying on traces to not have to have the brittle 128 block window to quickly trace something before the state is pruned.

Docs & Website

Perhaps as surprising to you as to us ( :D ), this year we've started putting some effort into getting our online docs in a somewhat better shape. Shoutout to Joseph for going through our hot mess of pages and trying to make heads or tails of them. Within the same effort - with full thanks to the ethereum.org team - we've also been working on a new website for Geth. Don't expect all of a sudden to have more - or different kinds of - information published, so our new website will mostly follow the old architecture, but should be a welcome refresher compared to the stock bootstrap template we threw together ages ago just to have a downloads page. Contributions are welcome!

Aaand, that's a wrap :)

Javascript Team

Authored by Holger Drewes

The EthereumJS libraries date back to as early as 2014 and represent a continued effort to both modernize and keep an uncluttered code base. In 2022, we did a big round of breaking releases:

  • Introducing native JavaScript BigInt support

  • Making larger structural changes such as extracting a "pure" EVM from the historically grown VM package code, and also…

  • Preparing the libraries for the Merge.

For 2023, there is a lot around the corner. We are actively working on an implementation of sharding (to be precise: EIP-4844 "Shard Blob Transactions"), we’ve merged EIP-4895 "Beacon Chain Withdrawals" code, and plan to complete the 5 Ethereum Object Format (EOF) EIPs that are being considered for mainnet by building on top of the initial EIP-3540 implementation, enabling us to join an early EOF-focused testnet (likely in January 2023).

Our EthereumJS (execution) client continues to mature. We recommend listening to the PEEPanEIP podcast episode in which our team member Gajinder talks about how our client went through the Merge and a potential future light client.

The client is now able to serve a full Ethereum testnet along with a Lodestar consensus client instance. These efforts have culminated in the launch of an early Pre-Shanghai testnet called Shandong later in the year, which activated various EIPs being considered for Shanghai and was well perceived by the community and other client teams.

We will build upon these experiences and launch a continued series of dedicated "Community Testnets" throughout 2023 which will be HF-independent and iterate quickly with early EIP integrations and a strong focus on (dev) community needs. Stay tuned for an announcement here!

On Ultralight, our Portal Network implementation has significantly improved throughout 2022, and we have now started working on PoCs that use an Ethers provider, swapping out the classic 3rd party RPC provider (e.g. Infura) and already successfully serving (parts of) the JSON RPC calls in a purely decentralized fashion by using a distributed Portal Network (!!). Continued results are promising, but we still need to collect more data on "soft" factors such as performance, scalability, and network resilience. There also are networking questions being addressed regarding a pure browser usage of the developed solution.

And, regarding Ethers: Ethers v6 is just around the corner. Stay tuned for an announcement in the coming weeks!