Comrades,
The upcoming year promises a wealth of enhancements and grand visions emerging from the Ethereum landscape. Since our last Endorsed Teams announcement (which followed the debut of the beacon chain), the system has witnessed over 3.8 million Ether staked and more than 120,000 active validators operational across several clients.
Recently, the Berlin network upgrade has been successfully executed, and as progress continues within various projects supported by the EF, these updates present a chance to showcase further initiatives aimed at expanding and refining Ethereum as a unified entity. This edition encompasses updates from numerous teams featured in the last Endorsed Teams report, among others.
Enjoy!
Implemented ZKP
Written by Thore Hildebrandt
Zkopru
Wanseob, Chance, Geoff, Rachel, Jin
Zkopru operates as a private optimistic rollup. It facilitates transfers and atomic swaps. We have completed an audit with Least Authority and initiated a trusted setup that will conclude on April 16th. Our next step involves launching a testnet and developing a wallet along with a block explorer.
Hubble
CC, Vaibhav, Jake
Hubble serves as a transfer-focused optimistic rollup. We have finalized our audit and are now advancing client enhancements while bringing on an additional engineer to accelerate development.
BLS Global Wallet
James
Optimistic rollups (such as Optimism) that default to ecdsa signatures face a throughput limitation of approximately 500 transactions per second because signatures require on-chain storage. We utilize BLS signatures to minimize on-chain storage needs, potentially enhancing throughput to around 3000 tps. Discover more here. The initial contracts have been upgraded to smart contract wallets featuring meta transactions, and the aggregator is currently being modified to comply. Ongoing tasks include integrating token incentives, detailing social recovery features, and organizing an audit. You can meet James at the forthcoming Scaling Ethereum Hackathon, where he will serve as a technical mentor.
Blind Find
Kevin
Utilize MPC to discreetly locate peers within a social graph and employ ZKP to validate the existence of the path. The initial version has been completed. We are outlining features for the next version and expanding the team to construct a user interface.
MACI
WeiJie, Corey, Han
The objective of MACI is to hinder collusion among participants while preserving the censorship resistance and accurate execution advantages of smart contracts. We are presently leveraging it in the context of clr.fund. MACI has progressed beyond a minimal viable product, with version 1.0 slated for imminent release. New functionalities encompass reusable voting contracts, reduced gas consumption, and enhanced capacity that can accommodate a broader spectrum of quadratic voting scenarios.
MicroMix v2
Jerome
MicroMix operates as a mixer for ETH and ERC20 tokens. It is constructed on Semaphore, a foundational layer for privacy dApps. We are currently facilitating the latest version of node and ethers, managing various networks and tokens. We have updated Surrogeth for multiple networks and tokens with a simplified setup. Work on the user interface is nearing completion, addressing final bugs and ensuring compatibility with Arbitrum. Future upgrades encompass eliminating the necessity for a surrogate for transaction fees, enhancing zkp generation speed within the browser, bolstering security for private keys, and automatically adjusting fee parameters.
Social Media Platform on Unirep
Ya-wen (Vivian), Doris, Rachel
Utilizing Unirep, we are establishing a private decentralized social network akin to Reddit. It enables users to discreetly build and demonstrate their reputation. The contract specifications have been outlined, and functions such as upvote, downvote, post, and comment have been implemented. We have introduced a reputation nullification strategy to mitigate double spending concerns. The next phase involves commencing work on the front end in collaboration with a designer.
MPC Phase 2 User Interface
Geoff, Rachel
The ambition of the MPC Phase 2 UI initiative is to provide an intuitive method for anyone to conduct a trusted setup. The website has been finalized, and we are currently utilizing it for running a trusted setup for Zkopru. We are gathering feedback from the live ceremony and investigating features for the subsequent iteration.
Forum Moderation using Prediction Markets
Liam
Utilize the prediction market for moderation. Each submission generates a prediction market over whether the moderators will flag it as a breach of community guidelines. Liam is departing from the project and we are seeking someone to take over, check out the “curatem” repositories on Liam’s Github if this piques your interest.
Reputation Verification Service
Jay, Raphael
Export cryptographic verifications of user characteristics from existing platforms where users have built a reputation (i.e. Github, Twitter, etc.). These verifications can subsequently be authenticated by sites or decentralized applications.
An initial basic version is now live, and the service can now be accessed directly via an API to verify the reputation of a Twitter account. The next goal will enable users to link with an Ethereum account and verify their identity with Twitter.
QDHP Quadratic Dollar Homepage
Raman
The Quadratic Dollar Homepage is inspired by the Million Dollar Homepage. While it also provides a space for images on a webpage, it lets users cast votes on how much space each image should occupy. Furthermore, it implements a quadratic and collusion-resistant voting framework on Ethereum called Minimal Anti-Collusion Infrastructure (MACI) to avert bribery and expand images quadratically https://quadratic.page/. The implementation is complete, and we are preparing for some test rounds soon.
Data Publishing Marketplace
Jacksoom
The project establishes a space to publish data trustlessly after raising funds. The user submits an encrypted dataset (e.g. image or audio file) that is trustlessly disclosed once a specific crowdfunding goal has been achieved. The project is progressing rapidly, contracts have been executed, and an initial version of the website is operational, with circuit implementation next on the agenda.
Rollup Difference Compression
Blagoj
Rollups necessitate publishing a difference between the state prior and state following. This initiative explores methods to minimize that difference in order to lower rollup expenses specifically for airdrops. We are currently in the final phases of testing various data compression techniques/algorithms and assessing their performance. Next steps include selecting the most effective data compression technique for an iterative multi-stage retrospective airdrop and implementing the algorithm for testing and practical application on L2. The implementation will build upon the BLS Global Wallet project mentioned above.
CLR.Fund Creator
Spencer Graham, anonymous contributor
The objective of the clr fund-deployer is to simplify the process for anyone (project, protocol, community, etc.) to establish their own instance of clr.fund to finance public goods within their domain. Clrfund-deployer has three planned releases:
Foggy – essentially a web UI designed to deploy all dependencies and subsequently configure the contracts
Translucent – enhancing that web UI to deploy and set up the user and recipient registries and also initiate a funding round!
Transparent – from that same web interface, deploy (and customize!) a new web UI to host their instance of clrfund
We have just launched Foggy and are commencing work on Translucent, as well as initiating some UX design.
Ecosystem Assistance Program
Authored by ESP Team
We recently released our Q4 Allocation Update detailing the grants awarded in the final quarter of 2020, with over $4 million distributed across all categories.
In the meantime, on the support front, we’ve shaken things up a bit! We are processing inquiries via our website as usual, but over the past few months, we have explored various ways to provide support:
Consultation Hours
Our experience has shown that informal discussions can be unexpectedly effective. Starting in February, we initiated “office hours,” where teams or individuals can schedule one-on-one calls with the ESP team regarding topics such as project feedback, assessing if ESP is a suitable fit, or guidance navigating the Ethereum ecosystem. We conducted our first rounds within a limited timeframe, but we have been pleased with the results and will keep the signups open consistently from now on! If you’re interested in conversing with us, you can submit a request here.
Targeted Grant Rounds
We have also recently hosted two grant rounds focused on specific areas for R&D. These cycles allow us to highlight areas that are especially timely or of high priority, and may also have slightly distinct aims or selection criteria from ESP’s regular grants.
- Staking Community Grants, conducted in December, awarded over 25 grants aimed at enhancing the Ethereum staking experience. The outcomes of this round have now been published – check out the announcement post for further details and to explore some of the resources generated by the remarkable Ethereum staking community!
- Rollup Community Grants encouraged submissions to enhance the rollup community ecosystem, from development tools to infrastructure, interoperability, educational materials, and additional resources. Applications for this phase have now concluded and we are currently assessing the entries; stay tuned for a post announcing the recipients shortly.
Eth2 Research
Much of the research team’s activities are detailed in the Finalized and “State of Eth2” updates. In addition to the public information included there, we have been delving deeper into stateless research, custody proofs for EVM execution, sharding specifications and prototypes, along with various scaling/security studies. Most of our advancements can be found in posts on ethresear.ch.
Check out a few of our recent articles below:
Ethereum.org
Written by Sam Richards
New homepage
We unveiled a brand new homepage! As the principal entry point for ethereum.org, we aimed to enhance our homepage to better convey what Ethereum offers and assist users in commencing their exploration. We would love to hear your thoughts:
https://ethereum.org/en/
Launchpad enhancements and localization
To foster a healthier, more accessible, and more decentralized ecosystem, the launchpad is now available in 15 different languages (with more on the way). Accompanying this localization initiative, we also implemented some content modifications and user experience enhancements to assist users in establishing their beacon chain validators.
https://launchpad.ethereum.org/en/
Have suggestions for improvements? We invite collaborators. Here’s the repository:
https://github.com/ethereum/eth2.0-deposit
Translate more recent content
We have launched translations for some of our latest content in 8 of our total 33 languages (with more forthcoming):
https://ethereum.org/en/languages/
Use case pages
Topics such as DeFi and the recent surge in digital art NFTs are motivating users to explore Ethereum. These are also enticing reasons to get involved. Our aim is to ensure we address these subjects in a beginner-friendly manner that you simply can’t find on Crypto Twitter, enabling new users to learn about the most tangible use cases of Ethereum.
We launched 3 new pages:
Know of a fantastic Ethereum use case that we haven’t included? Let us know!
Check out ethereum.org and our prior updates to see what else we’ve accomplished since your last visit. To enhance the accessibility of our work and encourage broader community collaboration, we’ve also begun sharing an overview of our quarterly roadmap objectives, which you can find on GitHub (see Q1 and Q2).
If you’re interested in contributing, you can find ways to get involved, visit our Discord or submit an issue/PR in GitHub. Special thanks to all the amazing individuals who have assisted thus far!
Ewasm
Written by Alex Beregszaszi
EVM384
Development on EVM384 continues, and we released update 5 at the end of January. In this update, we introduced two distinct models for costing the new instructions and shared estimated expenses of BLS12-381 operations using these models. Furthermore, the update included a brief summary of additional potential enhancements to the EVM.
In addition to the previously unveiled partial BLS12-381 implementation (evmcurves), new exploration of the applicability of EVM384 to MiMC hashing was also published. MiMC stands as one of the zk-SNARKs compatible hashing algorithms. We demonstrated a significant gas reduction using EVM384 (including in the example case of Tornado Cash).
It’s worth noting that the work on MiMC unveiled some restrictions of the interfaces (EVM384-v7 and EVM384-v9) suggested in update #5 and triggered further work on a revised interface.
Updates on EVM384 can be tracked on the designated EthMagicians topic.
EVM
EVMC 7.5.0 has been launched, enhancing the evmc CLI tool and the utility libraries (with a new addition being evmc::hex). See thedetailed changelog for further information.
The Baseline interpreter has been introduced into the evmone project. It offers a fairly uncomplicated EVM implementation with performance that rivals the previous Advanced interpreter. Refer to the evmone 0.6.0 release notes and PR#261 for supplementary details.
Both EVMC and evmone are progressing with support for the Berlin hard fork, featuring EIP-2929 implementation (evmc#571 and evmone#289). These modifications and associated changes will be featured in the forthcoming releases.
A series of synthetic benchmarks has been incorporated into the evmone project. These benchmarks focus on specific low-level computational EVM instructions. We aim to expand this further and utilize it in an upcoming report.
We have also published a document titled EVM Object Format. The aspiration is to enhance the architecture of EVM bytecode. This will facilitate the simpler implementation of various enhancements and features in the future. Stay tuned for future updates here.
Code Merkleization
While it was initially suggested to employ RLP, we have shifted to utilizing SSZdue to demand for the code tree. Proof generation and verification functionality has been added to fastssz (an SSZ library for Go), along with experimentation of proof compression techniques.
Additionally, we have implemented code merkleization logic in geth, including hooks to compute code proof sizes (for various encoding formats and compression techniques; such as RLP and SSZ encoding, Snappy compression) for historical blocks. Refer to these lab notes regarding the changes in go-ethereum for guidance.
Alongside our efforts on the SSZ approach, we have commenced contributions to go-verkle to gain understanding of the viability of code verkleization.
Fizzy
The 0.6 and 0.7 releases of Fizzy were centered on implementing a C and Rust API, along with providing support for WASI. As we prepare for the 0.8 release, we are integrating user-suggested improvements.
In line with our objectives stated in the previous update, we have been assessing effective runtime metering techniques and have developed an implementation with minimal overhead.
We have also continued the upstreaming of testing enhancements to the official WebAssembly test suite, with numerous changes merged this year.
Formal Verification
The Formal Verification Team shared their own quarterly update at the conclusion of Q1 (31 March, 2021). This post highlights work on Act, hevm, and SMTChecker, and you can read it here!
Geth
Version 1.10.0 of Geth was released on 3 March, 2021 in advance of the Berlin network upgrade. A comprehensive announcement post detailing updates and new features (authored by Péter Szilágyi) is accessible here.
Javascript Team
Authored by Holger Drewes
Berlin was approaching quickly and occupied our focus. We released a VM v5.2.0 in mid-March with complete Berlin support, followed by VM v5.3.0 shortly after that added EIP-2930 Access List generation capabilities. Ethers became prepared for Berlin with the v5.1.0 release which included typed transaction support as the primary change (and challenge). Meanwhile, Chris dedicated substantial effort to assist HardHat with the VM v5 upgrade. While HardHat should have a Berlin-capable release shortly after integration, we generallyrealized that the general developer ecosystem preparedness for forthcoming HFs is a structural vulnerability (where we claim our portion). We will give this some further contemplation on how we might assist with coordination moving forward.
Regarding the future: what’s happening with our client? To summarize: we will remain modest in our approach. We will probably be able to execute a preliminary alpha release within the next 2-3 weeks, enabling passive full synchronization across the primary networks. Nevertheless, the principal purpose of this client will still primarily be to assist us internally with development. We have initiated the EIP-1559 implementation (which has already progressed quite well 😀) and our client will play a significant role in helping us test this under real-world conditions early on.
We will also begin preparations for “The Merge” [tm] relatively soon (within weeks), and you can track the progress here. Although we likely won’t be able to participate in the Rayonism hackathon, our client will permit us to connect to an ETH2 node via RPC early and assess our technology stack against the merge criteria.
Lastly: our client has greatly contributed to fortifying our devp2p implementation and a first truly production-ready release is approaching (also: within a few weeks at the most). We will persist in evolving in this area and soon tackle a wit/0 protocol implementation for witness synchronization recently announced by Jason Carver from the Python team, which particularly thrilled us, and we will be able to integrate it alongside our own Beam Sync experiments.
Remix
Authored by Yann Levreau
The quarterly update from the Remix Team is now live! Discover updates concerning the team and its members, React, VSCode extension, Matomo, Workspace, and additional details on the Remix Medium page.
Snake Charmers [Python Ecosystem: PyEVM/Trinity/Web3.py/Fe-lang]
Authored by Grant Wuerker
Fe-lang is a high-level programming language crafted using Rust. The team is dedicated to supplying the community with language functionalities and tools that simplify the creation of dependable smart contracts. Here are some advancements in development from the initial portion of 2021:
- Monthly releases: We commenced producing releases every month starting in January, and we will persist in doing so.
- Additional features: We are consistently adding beneficial functionalities to the language. Here are some notable additions:
- structs
- external contract types
- integrated safe-math
- Uniswap-V2 core demo: We aimed to support a basic implementation of the Uniswap protocol by April. We accomplished this by the start of March.
- External contributions: We’ve seen contributions from five individuals outside of the EF.
The team will continue to focus on the following tasks:
- Delivering a stable release to users.
- Enhancing type support and more comprehensive validation.
- Introducing a module system and standard library.
- Refining error messages.
- Conducting differential contract fuzzing.
- Implementing advanced language features.
Web3py
Authored by Keri Clowes
The two primary features that the web3py team has been concentrating on are the Eth2 Beacon API and progressing toward asynchronous support. We’re pleased to announce that the Beacon API is now available for use! Our documentation and support guides have also received significant updates recently, and we have begun planning the v6 release, which is expected to occur later this year! Naturally, addressing community support and bug fixes remains a top priority as they arise.
Stateless Ethereum
Authored by Piper Merriam
The Stateless Ethereum initiative is ongoing, with statelessness being a major focus for the Eth2 merge. The main challenge for statelessness presently is the size of witnesses, which can easily reach tens or hundreds of megabytes under the current protocol. Our original strategy centered around switching to a binary trie, which was anticipated to shrink witness sizes down to merely a few megabytes. Recent research on Kate commitments and the creation of the Verkle Trie has altered the roadmap somewhat. The current solution provides us a definitive upper limit of 800Kb, with an expected average witness size of 200Kb, marking a significant reduction in size. Efforts are underway to implement proof of concept models of the unified Verkle trie within the go-ethereum codebase.
Additionally, we are making strides on EVM alterations that would impose firm economic constraints.on the overall dimension of the state through “state expiration”. Instead of erasing state, “state expiration” transitions segments of the state that haven’t been interacted with for a period into an “inactive” condition. Any element that is inactive can be reactivated by supplying the protocol with proof, restoring it to an “active” status.
Additionally, the EF has created a new fund for developing Stateless Client Architecture to guarantee that we not only enable the protocol to function with statelessness but also allow clients to deliver the advantages of statelessness to end users through more lightweight clients.
Security [Security / Consensus Evaluations]
Written by Martin Holst Swende
The foundation’s security initiatives encompass a broad spectrum, from cross-client fuzz testing to high-level protocol and structural modifications within the Ethereum ecosystem.
Since the previous update, two significant adjustments have been implemented in the consensus layer:
- EIP 2929, offering a backward-compatible method to modify gas prices for trie-dependent opcodes. Adjusting opcodes according to actual resource usage is crucial to prevent DoS vulnerabilities in the core platform and has been previously carried out, for instance, in EIP 1884. The “new angle” with 2929 is that the modification is backward-compatible, allowing all “failures” resulting from the increased cost to potentially be “undone”, via:
- EIP 2930, enabling callers to specify and prepay for certain slots accessed later during execution. By charging this cost upfront, it becomes possible to make the increased cost unnoticeable during the execution phase.
On the protocol front, the ETH-66 protocol has been integrated into go-ethereum, and it is anticipated that other clients will take a similar approach. ETH-66 incorporates request identifiers at the protocol level. Why does this hold significance from a security standpoint?
Currently, as clients operate, whenever a client dispatches a request to a peer and receives a response, they must engage in speculation to discern which request an incoming packet corresponds to. This approach works “as long as it functions”, but it is vulnerable to errors; for instance, in scenarios where peers disconnect and reconnect, or respond slowly enough for the request to time out.
Due to the intrinsic unreliability of the current protocol, it is challenging for any client to be stringent regarding response verification and to establish any rules for managing misbehaving peers — it is simply extremely tricky to ascertain if the reason for a discrepancy stems from a malicious peer or if it is due to network latency.
With request identifiers, the pathway is clear to implement a significantly more advanced and efficient networking architecture.
From the fuzz testing perspective, we discovered one ‘crasher’ related to Besu, which could have been exploited on mainnet, along with one consensus issue related to Besu’s berlin upgrade with Yolov3, and two consensus issues involving Nethermind. Additionally, the standard reference tests conducted on Hive uncovered an issue in OpenEthereum, which was exploitable with specific versions of the Rust compiler.
Much of the recent fuzz testing work has been carried out by Marius van der Wijden, who has recently completed his Master’s Thesis on fuzz testing Ethereum virtual machines. Congratulations and commendable work, Marius 🎉!
Solidity
Written by Franziska Heintel
0.8.0 Disruptive Release and New Features
As an early holiday gift, we launched Solidity 0.8.0 in the middle of December 2020. v0.8.0 is a disruptive release that prominently introduces checked arithmetic operations by default. This functionality can be disabled locally by utilizing an unchecked block. Moreover, ABI coder v2 is now enabled by default. The previous coder can be activated using pragma abicoder v1. You can read all specifics regarding Solidity 0.8.0 in the release announcement and find a compilation of breaking changes in the documentation.
We subsequently rolled out Solidity versions 0.8.1, 0.8.2, and 0.8.3:
- v0.8.1 introduces several new functionalities for the SMTChecker and allows for the detection of panic errors. Further details.
- v0.8.2 incorporates an optimization stage that can inline small code segments to conserve gas and offers additional methods to handle code documentation by exporting inline remarks and permitting custom natspec tags. Further details.
- v0.8.3 rectifies the Keccak Caching Bug in the Solidity Optimizer, which is present in all earlier versions of Solidity, and also includes two enhancements to the optimizer that can yield significant gas savings when handling structs that occupy an entire storage slot. It additionally adds new SMTChecker documentation and a tutorial. Further details.
Numerous enhancements to the still experimental functionality for compiling through our intermediate language Yul are not reflected in the changelog because the feature is not officially launched yet. Nevertheless, we encourage everyone to give it a try via solc –experimental-via-ir and provide feedback!
Solidity Developer Survey 2020 Findings
We released the outcomes of the Solidity Developer Survey 2020. If you’re seeking a summary, you can find highlight threads with key points here and here. We extend our heartfelt gratitude to all the Solidity developers who took part!
Ecosystem Outreach
We are consistently striving to enhance our outreach and interactions with the Solidity ecosystem. Below are a few initiatives we launched in Q1.
More Inclusive Language Design
As part of our endeavor to promote information exchange, encourage additional developers to provide feedback about Solidity, and engage in discussions regarding language design and future compiler directions, we initiated the Solidity forum. The Solidity forum is now the dedicated space for discussing topics & inquiries related to the design of the Solidity programming language. For a brief guide on utilizing the forum and its categories, refer to the announcement. If you wish to understand more about participating in the language design, also explore this Contributing 101.
Closer Exchange with Tooling Developers
We introduced the solc-tooling chat, designed to provide a quick & efficient communication line between Solidity tooling developers and the Solidity compiler team. This chat room is public and hosted on Matrix, with a bridge to Telegram.
Regular AMAs
We persist in hosting regular AMAs with the Solidity team. Check the outcomes from the latest AMA here.
Localization of Solidity Documentation
We established a new workflow and a base for translations of the Solidity documentation. We are currently in search of language maintainers who can coordinate translation efforts for their specific language, ensure quality and precision, and keep the translations synced and up-to-date, as well as experts who can assist with some automation. These translations aim to lower the entry barriers for developers who do not speak English, thereby allowing a wider range of developers from across the globe to become familiar with Solidity. Please help disseminate information about this initiative within your local communities!
If you wish to assist with this monumental task by translating or aiding in organizing the procedure, please join us at the new Solidity docs GitHub organization and in the forum.
Please note that the English reference version is and will continue to be the only officially supported version by the Solidity team, and will always be the most precise and updated. When in doubt, always consult the English (original) documentation.
ZoKrates
Authored by Thibaut Schaeffer
In the previous quarter, the ZoKrates team concentrated on a new major release of the toolbox. This latest version has been launched with support for new powerful constructs:
- constant generics
- support for the keccak family of hashing functions
- inference on integer literals
- and more!
These enhancements enable a significantly more compact implementation of a broad array of algorithms without any trade-off.
Additionally, numerous internal optimizations were made to reduce the proving and compilation footprint of ZoKrates programs. For a comprehensive list of changes, check the changelog.
At last, a closer collaboration with the ZKP Research team commenced, aiming to support zk-SNARK schemes with universal setups.