There is much to appreciate this festive season, from the inaugural anniversary of the beacon chain, to the successful enhancements throughout the past year and the remarkable advancements across the entire Ethereum ecosystem.
As an exceptionally fruitful year comes to an end, we have a few final presents to share in the shape of updates from numerous (15+!!) EF-backed teams that are consistently striving to enhance the network. And there’s a wealth of substantial content here, so take a moment to sift through the table of contents, and delve in!
As always, this compilation series centers on EF-backed teams whose members are dedicated to expanding and refining Ethereum as a whole. Featured in this edition are updates from various teams noted in the last report, along with other new and rotating groups.
Enjoy! 🦄
Consensus R&D (also known as EF Research Team)
Written by Hsiao-Wei Wang
In the latter half of this year, the accomplishments in Ethereum consensus R&D encompassed:
In alignment with The Great Renaming, we transitioned components to “Consensus Layer” from “Eth2” for clearer long-term communication.
In early 2022, our team will concentrate on facilitating the delivery of “The Merge”, the most monumental consensus protocol enhancement ever. Luckily, we have tremendous backing from client teams, and others in the community striving to realize this! In the interim, we will continue our research on data availability, L1 scaling, and the aspects of the “clean up” fork post-The Merge.
Ecosystem Support Program
Written by ESP Team
We released our Q2 Allocation Update with grants totaling $7,794,000 for the quarter – and Q3 is swiftly approaching! You can also discover recent monthly roundups here and here for comprehensive progress updates from some of our outstanding grantees.
Behind the scenes, we’re engaged in a significant website overhaul that should simplify the understanding of ESP’s mission and priorities, and enable eligible builders to apply for funding or additional support. We can’t wait to unveil the new site in early 2022!
Ethereum.org
Written by Sam Richards
To enhance our work’s accessibility and encourage greater community collaboration, our team publishes an outline of our quarterly roadmap objectives. See our Q4 product roadmap here.
Happy holidays to everyone from the ethereum.org team 😀🎄 As always, our vision with ethereum.org is to establish the premier portal for Ethereum’s expanding community and to serve as the initial access point to Ethereum for millions of new visitors each month.
Content updates
Ethereum progresses quickly! In addition to updating countless pages to maintain accurate and current information, we’ve also introduced a variety of new content:
Ethereum.org thrives due to the contributions of hundreds in terms of content and code from the community. In Q3/Q4, we focused on enhancing contribution opportunities and acknowledging the community for their efforts:
Some statistics (Aug – Dec)
- Our GitHub contributors grew by 57%, from 396 to 621 😲
- Our Discord community nearly doubled, going from 6,500 to 12,200 members 🎉
- We’ve conducted two community calls and initiated office hours for contributors
- We added 3 new community guides (trusted members addressing inquiries and moderating discussions) 😎
- We introduced tiered POAPs to gamify contributions for content, code, and translations
Translation Program
Since appointing our new Translation Lead in July, the Translation Program has truly accelerated!
Some statistics:
- From July to November, the community collectively translated 1,373,046 words for ethereum.org, more than 10 times the amount from the same timeframe last year! To put this into perspective, this is like translating nearly 20 entire books 📚!
- We’ve had translation assistance from over 2,500 community contributors 🤯
- We currently have 37 languages live on ethereum.org 🌍
- We initiated a project to better “`html
recognize our translators, encompassing a leaderboard and translator certificates!
CLR funding
We are backing a clr.fund round on Layer 2! Following over 6 months of contributions to clr.fund’s quadratic funding stack, we have integrated our modifications into the upstream repo, which enables L2 network support and a range of web app improvements.
clr.fund intends to initiate a funding round on Arbitrum One focused on the staking ecosystem in January, and the EF is thrilled to provide matching funds to this round. We invite you to participate! Keep an eye out for more information. Hooray for public goods!
We have been building on the foundations laid by pioneers. Our gratitude goes to the clr.fund team, the MACI team, and the clr.fund’s community of contributors who consistently drive advancements in the ZKP & quadratic funding domain.
What lies ahead?
- establishing a learning platform to enable non-technical users to become adept Ethereum users
- developing additional materials on node operation and staking for enhanced accessibility
- further streamlining our translation processes to expedite the release of translated content
- broadening the Translation Program beyond ethereum.org
- refreshing content to shift away from the Eth2 terminology as the merge draws near
How does it sound?
We value your insights regarding our roadmap. Our core principles focus on generating the highest value in the shortest timeframe, so if you have suggestions on what we should prioritize, do not hesitate to share! We encourage input and contributions from everyone in the community.
Ipsilon
Written by Alex Beregszaszi
We have launched a team website to offer a clear explanation and to thoroughly list our ongoing and previous projects.
It’s apparent from the subsequent headers that during the latter half of the year, the team’s primary focus was on the EVM. Additionally, it is worth noting that we have collaborated with the Geth Team to enhance the performance of the EVM interpreter.
EVM Object Format (EOF)
The initial phase of this, EIP-3541, went into effect with London, and we have conducted a survey across various testnets and EVM chains to discover a suitable prefix for EOF.
Further clarifications have been made to EIP-3540 (including the selected prefix), and we have also suggested additional work building on it:
- EIP-3670 to implement code validation at deployment time
- EIP-3690 to substitute JUMPDEST opcodes with a JUMPDEST-table
- EIP-4200 to introduce two new opcodes, RJUMP and RJUMPI, enabling static jumps
In October, we showcased EOF at Liscon (slides here, but the recording is not available) and at the Ethereum Meetup in Berlin (slides, recording).
Other EIPs
EIP-2681 (Limit account nonce to 2^64-1)
One of our earlier proposals, EIP-2681, was approved during ACD#120. It formalizes a limitation that had already been (partially) applied in practice in many clients. Following its acceptance, we extended the Ethereum State Tests suite and modified the geth implementation.
EIP-3855 (PUSH0 instruction)
EIP-3855 aims to introduce a PUSH0 instruction that places 0 onto the stack. This feature is commonly utilized, currently achieved through inefficient or repurposed instructions.
Our analysis determined that significant resources
“`could have been conserved with this opcode:
To illustrate the “waste,” across current accounts, 340,557,331 bytes are squandered on PUSH1 00 instructions, resulting in a consumption of 68,111,466,200 gas for their deployment.
EIP-3860 (Limit and measure initcode)
EIP-3860 represents a suggestion to set a limit and establish metering for initcode. This would facilitate more efficient analysis and execution, as implementations would confront fewer uncertainties.
geth
In partnership with the Geth Team, we initiated efforts to assess and enhance the performance of the EVM interpreter within geth.
From an analytical standpoint, two reports stand out:
- Geth vs evmone contrasts the performance speeds of Geth and evmone via the benchmarking suite in evmone.
- Geth & Go compiler investigates the influence of the Go compiler version on the operational speed of geth.
Following these preliminary outcomes, we have pursued profiling geth to ultimately provide various enhancements to the codebase, most of which have already been merged. A non-exhaustive enumeration of significant PRs: 23952, 23970, 23974, 23977, 24017, 24026, 24031, 24120.
Visit this link for a comprehensive view of all PRs. We intend to persist in this work during the forthcoming quarter.
evmone
Two bugfix releases of evmone have been launched: 0.8.1 and 0.8.2.
ethash
The team also operates a C++ ethash/keccak256 library, utilized by evmone and Silkworm.
The recent 0.8.0 release introduces an additional method for confirming the final Ethash hashes against the block difficulty. This represents both a usability and efficiency enhancement. The method has been shared on Ethresear.ch.
Moreover, ProgPoW has been phased out in the library.
Fizzy
The team also engaged in the Wasm in Web3 conference last September. We conducted two presentations:
- Fizzy — A deterministic interpreter (slides) offered an extensive overview of what Fizzy is, its comparisons with other engines, and elaborated on many design choices made.
- Weird quirks while testing WebAssembly showcased a good variety of edge cases encountered during Fizzy’s development. The discussion also proposed potential solutions and clarified these edge cases, as well as how the official WebAssembly test suite was extended to account for them.
Formal Verification
Written by Leo Alt
In the latter half of the year, the FV team continued to concentrate on our existing tools:
Act:
- We finally launched Act 0.1! You can explore the incredible tutorial at https://fv.ethereum.org/2021/08/31/act-0.1/ to learn about the current possibilities and how to utilize it.
- We are presently overhauling error handling to enhance usability.
Hevm:
SMTChecker:
- Accurately monitor the balances of contracts, including msg.value being sent to and from the evaluated contracts.
- Additionally, accommodate the low-level call function as an insecure external call.
- Enhance counterexamples by notifying block.*, msg.* and tx.* values that are essential for targets that failed verification.
- Inform the user about contract and reentrancy inductive invariants.
Geth
Written by Felix Lange
In the latter half of 2021, we released 9 versions of geth. As always, our time was divided among EIP assessment/implementation, client optimization/maintenance, and reviewing code modifications suggested by the community.
In July, the London hard fork, incorporating EIP-1559, went live. The novel gas pricing framework established by this EIP necessitated numerous modifications throughout all components of geth. Even now, six months post-launch, we are still uncovering and resolving corner-case problems associated with EIP-1559.
During the past six months, two security weaknesses were uncovered. For each, we adhered to our security advisory protocol: a CVE number was promptly assigned to the issue, followed by the release of a hotfix. Comprehensive technical information regarding the vulnerabilities was disclosed 6-8 weeks later.
In the final quarter of 2021, our efforts predominantly transitioned towards the implementation and testing of The Merge. We are on course to transform geth into the ‘execution layer client’ for the merged execution+consensus (formerly “eth1+eth2”) layers. To prepare for The Merge, a significant portion of our sync code has been restructured to function under the governance of the consensus layer. Geth is also participating in Merge testnets.
Furthermore, the geth team has been engaged in several long-term initiatives, including the implementation of Verkle Trees, a light client for the beacon chain, and a new database storage architecture for the Ethereum state.
JavaScript Team
Written by Holger Drewes
In the last two quarters of 2021, preparations for “the significant transitions” on the Ethereum network were a primary area of focus. We took part in the Merge Interop event in Greece and launched the first Merge-testnet-ready versions of our client, VM, and associated libraries (see for example the EthereumJS client v0.2 release). We also commenced an intriguing experiment in collaboration with the Go-Ethereum Verkle/Stateless team to natively test stateless block execution utilizing a verkle proof served alongside a modified block header through devp2p within our client. If you’re curious, you can track our progress by viewing the following tracking issue.
More relevant for the end user at this moment: we’ve enhanced our libraries’ support for emerging L2 networks such as Polygon, Arbitrum, and Optimism. These and several other networks can now be directly referenced to, for instance, send a transaction to a specific L2 network. Refer to the Common v2.6.0 release for the latest integration of the Optimism L2 network.
Lastly, there is a VM ArrowGlacier release that is available, along with updates on the Ethers.js front. Richard just shared an exciting summary of the forthcoming Ethers.js v6 library modifications and updates on his blog.
Privacy & Scaling Explorations
Written by Thore Hildebrandt
The Privacy & Scaling Explorations team aims to connect pioneering research in zero-knowledge proofs with application development on Ethereum.
zkEVM
The objective of zkEVM is to execute smart contracts in a zk-rollup. Unfortunately, the EVM was not designed for zk circuits, which presents a challenge. Our goal is to embed the complete set of EVM opcodes directly into zk circuits so that a smart contract on L1 can be transitioned to L2 with minimal alterations. This will enable full compatibility with existing tools and allow us to utilize the knowledge of the EVM that the ecosystem has developed over the years. We are making significant strides in specifying the opcodes and implementing the circuits, with early benchmarks and a crucial objective moving forward to reduce prover time.
ZKOPRU
ZKOPRU (zk-optimistic-rollup) is a layer-2 scaling solution aimed at private transactions utilizing zk-SNARK and optimistic rollup. It facilitates private transfers and private atomic swaps within the layer-2 network for ETH, ERC20, and ERC721. Additionally, it offers instant withdrawal with pay-in-advance capabilities and compliance compatibility through spending and viewing keys. ZKOPRU recently launched on testnet – feel free to explore it. We are focused on enhancing sync times and developing a private exchange feature.
Unirep & Unirep Social
UniRep represents a private and non-repudiable reputation system. Users can receive positive and negative reputation from attestors, allowing them to voluntarily prove they possess at least a certain quantity of reputation without disclosing the exact number. Furthermore, users cannot deny receiving reputation from an attester. We are leveraging Unirep to create Unirep Social: a Reddit-like platform that enables users to privately amass karma. Developing the Unirep Social website has been our primary focus over the last few months. Proofs in Unirep are now indexed to allow multiple references and prevent the same proof from being submitted repeatedly. Unirep can now manage an initial reputation airdrop and user state transition airdrop. We are also enhancing theefficiency in producing user states and Unirep states.
Fundamental functionalities, user interface design, and both frontend and backend of Unirep Social are finalized, and we are organizing a closed pre-alpha launch. Explore this blog post if you wish to discover additional details.
CLR.fund for Everyone
The aim of the initiative is to simplify the process for any community to conduct their own CLR round utilizing clr.fund. This project has been highly active. You can now launch your own quadratic funding application with the clr.fund Deployer. Enable your community to select and finance its own future in a completely decentralized way. Explore our Subgraph and Documentation.
InterRep
Reputation is vital for establishing trust. Individuals invest years cultivating their reputation on centralized social networks, yet they must start anew whenever using a new application. InterRep seeks to render reputation transferable to enhance the cumulative advantages of trusted human interactions across the internet. Discover this blog post for the initial announcement and the repository. Over the last quarter, we have broadened the spectrum of social proof sources, adding POAP and email, and creating curated groups: both on-chain and off-chain through a Telegram bot. We are undertaking a UI overhaul, enhancing interaction with client applications, and preparing for a live launch.
Semaphore / ZK-Keeper
Semaphore is a zero-knowledge framework that enables users to demonstrate their membership of a group without disclosing their original identity. Simultaneously, it allows users to express their support for an arbitrary string. It is intended to serve as a straightforward and versatile privacy layer for Ethereum decentralized applications (dApps). Possible applications include private voting, whistleblowing, mixers, and anonymous authentication. With ZK-Keeper, we are concentrating on keeping Semaphore current with the latest zk tools and integrating it into other projects such as InterRep. We have developed new libraries for processing semaphore proofs and identities. Implementation is now completed on top of Halo2, and we are preparing it for browser use.
RLN
RLN (Rate Limiting Nullifier) is a construct based on zero-knowledge proofs that facilitates spam prevention in decentralized, anonymous environments. In anonymous settings, the identities of the participants remain concealed. We have recently published an informative blog post to generate more interest in the concept. We have completed research regarding the “Feasibility analysis for ETH2 Validator privacy using RLN”. We are advancing towards the production of the “Private instant chat application using RLN and Interrep” project. Additionally, we are assisting in the integration of the ZK-Keeper plugin into the RLN initiatives.
Protocol Support
Written by Tim Beiko
The Protocol Support (PS) team was established in 2021 to enhance the various ways in which teams constructing or engaging with the Ethereum base layer receive assistance. The primary focus of the team is to empower core developers to implement network upgrades on Ethereum’s execution layer.
In pursuit of this goal, Berlin, London and Arrow Glacier were launched this year. Beyond these milestones, the PS team dedicated significant resources toward The Merge, initially with Rayonism, then the Amphora workshop, and currently the Kintsugi Devnet!
This rapid pace and breadth of change has necessitated increased outreach to the Ethereum community, prompting our team to arrange regular Community Calls. During these sessions, application, infrastructure, and tool developers were invited to discuss optimal ways to assist protocol upgrades and ensure a seamless transition for their users. Alongside these calls, the team has delivered several presentations and published various articles concerning the evolving Ethereum roadmap, including this recent update for all core developers, this piece in Bankless, and this recent article on the Merge and its implications for the application layer in the EF Blog.
In addition to protocol upgrades, the PS team has undertaken two major projects to guarantee that client teams receive ample support. Firstly, a Client Incentive Program was introduced to provide teams with long-term incentives aligned with Ethereum’s goals. This initiative offers client teams a set of 144 validators that they are required to operate using their software. Assuming teams continue to fulfill specific performance standards on the mainnet, these validators gradually vest to the teams, which can choose to either liquidate them or continue operating to earn rewards and fees. This program aligns teams with Ethereum’s objectives, guarantees they are utilizing their clients on the mainnet, and ensures they consistently deliver effectivesoftware.
Secondly, a Core Developer Apprenticeship Initiative was initiated. This initiative offered stipends and guidance to self-motivated individuals eager to delve into protocol development. CDAP was started as a trial that turned out to be exceptionally effective! Two cohorts were conducted, including over 25 participants. From this group, no fewer than 5 are now employed full-time within the ecosystem. These early cohorts have enlightened us significantly on what was successful and what areas could see enhancements within the program. Anticipate an upgraded CDAP in 2022!
Finally, the team ventured into offering infrastructure to client teams and the larger community. To this end, crawler.ethereum.org was launched and made open source. We hope that the existence of an additional crawler, available for community improvement, modification, or forking, contributes toward a better understanding of the network’s topology.
Remix
Written by Rob Stupay
In the past 6 months, the Remix team has disassembled the back of our application to carry out significant rewiring. The foremost of these alterations was the ongoing migration of our code to React. Additionally, we broadened our outreach by fine-tuning effective channels to new communities, and assisting new users with a simple product “tour” of our IDE. We’ve integrated projects into our “experience,” incorporating Slither, and Hardhat, along with upgrading the Remix VSCode extension.
Moreover, we collaborated on tools for cooperative coding, advancing Decentralized GIT and linking with Github. Finally, we’ve refreshed our current plugins. In summary, we’ve cranked it up to 11.
Discover more details in our article.
Robust Incentives Group
Written by Barnabe Monnot
The RIG (Robust Incentives Group) welcomed several new members and was engaged in numerous significant milestones for the Ethereum protocol. For a brief recap of what the RIG signifies and our focuses, you can view Protocol cryptoeconomics with the RIG, presented by Barnabé at EthCC in July.
Regarding the Proof-of-Stake consensus, Caspar, who joined us as a full-time research scientist earlier this year, identified a problem with the existing fork choice, documented as Three attacks on Proof-of-Stake Ethereum. Luckily, there is a robust candidate fix that was recently integrated into the consensus specifications, following many fruitful discussions with Stanford’s Tse Lab, who co-authored the “Three attacks” paper. Caspar and others also suggested an alternative mitigation (“proposer view merge“), which remains under investigation. Watch Caspar at Liscon presenting his findings!
Shyam, who initially joined us as a research intern last summer and is currently a research assistant at the RIG, released a collection of notebooks analyzing beacon chain statistics from various unique perspectives, including oceanic games and inequality. Shyam has also been enhancing an extension to our Beacon runner PoS simulation engine that incorporates reinforcement learning. Check out his presentation at EDCON!
Block 12,965,000, August 5th, 12:33:42 PM UTC, marked a significant milestone for us: the London hard fork was initiated, bringing with it EIP-1559. Throughout the past year, we’ve released a series of notebooks detailing various simulations of the new fee market system, laying the groundwork for further evaluations post-launch. Barnabé shared some findings shortly thereafter, and co-authored (alongside Shyam) a detailed paper, Transaction Fees on a Honeymoon: Ethereum’s EIP-1559 One Month Later. The paper is driven by the behavior of the 1559 update rule in practice, and opens new avenues for research aimed at enhancing the rule.
The RIG also collaborated closely with the cadCAD Edu group to prepare an online masterclass in validator economics, supported by a fully extensible model of Ethereum economics (in Python).
Snake Charmers [Python Ecosystem]
Composed by Keri Clowes
In the latter part of 2021, the Snake Charmers group finalized the modifications required across the ecosystem to facilitate the London hard fork. This encompassed extensive, fundamental adjustments throughout our architecture, particularly in Py-EVM, Ethereum Tester, Web3.py, and eth-account. Additionally, two bug bounties were submitted for Py-EVM, which have since been resolved. We have intensified our initiatives to produce educational material and have placed a greater focus on developer relations. As always, community assistance, issue management, and bug fixing are ongoing across our Python utilities.
Fe-lang
Composed by Grant Wuerker
Over the last 6 months, the Fe team has released the following versions:
0.11.0-alpha “Karlite” (2021-12-02)
- support for multiple files
- function definitions within structures
v0.10.0-alpha “Jade” (2021-10-32)
- module-level constants and procedures
- support for unsafe practices
v0.9.0-alpha “Iridium” (2021-9-29)
- self declarations within function signatures
v0.8.0-alpha “Haxonite” (2021-8-31)
- analysis based on queries utilizing Salsa
0.7.0-alpha “Galaxite” (2021-07-27)
- checks for Solidity ABI decoding
0.6.0-alpha “Feldspar” (2021-06-10)
If you wish to gather further details about our advancements over the past 6 months, you can explore the following materials:
Portal
Composed by Piper Merriam
This year has been a significant period for the Portal Network. We commenced this year with a concept and a rough outline for establishing a peer-to-peer network capable of providing lightweight access to the Ethereum protocol. We now have three autonomous teams and implementations on track to launch the initial testnet, which is expected to develop into a fully operational network by the end of 2022.
The EF Portal team has been diligently working on Trin, a portal client developed in Rust. Meanwhile, the EF Javascript team has been focused on Ultralight, a portal client crafted in Typescript designed to be operable in a web browser. The team from Status.im has also been developing Fluffy, a portal client aimed at integrating with the Status Ethereum client and wallet solutions.
Throughout this year, we have addressed the previously unresolved challenge of how to disseminate the current Ethereum State in a way that promotes efficient storage and retrieval. We established the Portal Wire Protocol, a versatile foundational protocol that serves as the cornerstone for all networks comprising the Portal Network. We also had the privilege of collaborating with several participants from the Core Developer Apprenticeship Program who utilized the Portal Network projects as a launchpad for engaging in Core Protocol development.
Security [Security / Consensus Tests]
Composed by the Security (Security / Consensus Tests) Team
Regarding security and testing, significant focus has been directed towards the London upgrade and the forthcoming merge. We have improved tools for test composition and continued enhancing the reference tests.
Solidity
Composed by Franziska Heintel
In the latter part of this year, we introduced Solidity versions 0.8.8, 0.8.9, 0.8.10, and 0.8.11:
- Solidity 0.8.8 brings you user-defined value types as a notable new feature. It also enhances the overriding of interface functions, reading from immutable fields, among others.
- Solidity 0.8.9 is solely a bugfix release and addresses two significant, albeit low severity, issues:
- Solidity 0.8.10 features optimizations for external function calls, activates the new EVM code generator for pure Yul mode, and can report contract invariants and reentrancy characteristics using the SMTChecker.
- Solidity 0.8.11 introduces a preliminary implementation of a Language Server and provides a more secure method for ABI-encoding.
Furthermore, several members of the Solidity team presented at ETHGlobal’s Developer Tool Summit:
The Solidity documentation received several enhancements, most significantly, we…
- enhanced the resources section with comprehensive materials, Ethereum IDEs, editor integrations, Solidity utilities, Solidity parsers, and grammars.
- incorporated the capability to launch code examples within the documentation directly in Remix.
Finally, we introduced our annual Solidity Developer Survey. If you are involved in Solidity development, kindly take 10 minutes to provide your insights and participate in the survey here. The survey will remain open until December 31st, 2021.
Additionally, we’re recruiting! Check out our C++ Engineer Solidity vacancy.
ZoKrates
Written by Thibaut Schaeffer
In the latter half of 2021, ZoKrates made progress across various areas:
Language
- Type aliasing, along with the ability to execute function calls in constant declarations
- Support for the ternary expression syntax
- Allow constant generics on structures
Proof systems
- Reduction of the deployment expenses for several Solidity verifiers
- Expose recursive verification within the standard library
- Introduce support for Groth16 MPC ceremonies (coming soon)
Compiler performance
- Significant efforts on minimizing memory and time requirements of the compiler (coming soon with metrics!)
For a complete overview of the modifications, refer to the changelog