EF-Supported Teams: Research & Development Update

Friends,

The year ahead will be filled with upgrades and big ideas from across the Ethereum ecosystem. Since our last Supported Teams post (which followed the launch of the beacon chain), the network has seen 3.8+ million Ether staked, and 120K+ active validators online across multiple clients.

In recent days, the launch of the Berlin network upgrade was completed, and since there’s always progress being made by other EF-supported projects, these updates are an opportunity to highlight more efforts to grow and improve Ethereum as a whole. Included in this edition are updates from many teams highlighted in the previous Supported Teams update, and more.

Enjoy!

Applied ZKP

Authored by Thore Hildebrandt

Zkopru

Wanseob, Chance, Geoff, Rachel, Jin

Zkopru is an optimistic rollup that is private. It supports transfers and atomic swaps. We have completed an audit with Least Authority and started a trusted setup which will end on April 16th. As a next step we are starting a testnet and building a wallet and block explorer.

Hubble

CC, Vaibhav, Jake

Hubble is an optimistic rollup that is transfer specific. We have completed an audit and are now working on client improvements and are onboarding an additional engineer to expedite development.

BLS Global Wallet

James

Optimistic rollups (like Optimism) that use ecdsa signatures as default have an upper limit of ~500 tps because the signatures need to go on-chain. We use BLS signatures to reduce the on-chain storage, which can increase throughput to ~3000 tps. Learn more here. The original contracts have been updated to smart contract wallets with meta transactions, and the aggregator is in the process of being updated to match. Further work includes adding token rewards, speccing out social recovery features and to organise an audit. You can catch James at the upcoming Scaling Ethereum Hackathon where he will act as a tech mentor.

Blind find

Kevin

Use MPC to privately search for peers in a social graph and use ZKP to prove that the path exists. The first version has been completed, we are defining features for the next iteration and starting to grow the team to build a user interface.

MACI

WeiJie, Corey, Han

The goal of MACI is to make collusion among participants difficult, while retaining the censorship resistance and correct-execution benefits of smart contracts. We are currently applying it in the context of clr.fund. MACI has evolved beyond a minimal viable product, and version 1.0 will be launched soon. New features include reusable voting contracts, lower gas usage, and higher capacity, which can support a greater range of quadratic voting use cases.

MicroMix v2

Jerome

MicroMix is a mixer for ETH and ERC20 tokens. It is built on Semaphore, a base layer for privacy dApps. We are now supporting the latest version of node and ethers, and handling multiple networks and tokens. We updated Surrogeth for multiple networks and tokens with simplified configuration. We are finalizing work on the UI, fixing last bugs and working on arbitrum compatibility. Future improvements include removing the need for a surrogate for transaction fees, faster zkp generation in the browser, increasing security for private keys and automatically setting fee values.

Social Media Platform on Unirep

Ya-wen (Vivian), Doris, Rachel

We use Unirep to build a private decentralised social network like reddit. It allows the user to privately accumulate and prove reputation. Contract spec has been defined and we have completed contract functions including upvote, downvote, post, and comment. We added a reputation nullifier scheme to prevent double a spending issue. Next step is to start work on the front end with the help of a designer.

MPC Phase 2 User Interface

Goeff, Rachel

The goal of the MPC Phase 2 UI project is to provide an user-friendly way for everyone to perform a trusted setup. The website is done and we are currently using it to run a trusted setup for the Zkopru. We are collecting feedback and learnings from the live ceremony and exploring features for the next iteration.

Forum Moderation with Prediction Markets

Liam

Use the prediction market for moderation. Every post creates a prediction market over whether the mods will mark it as a violation of community standards. Liam is leaving the project and we are looking for someone to take it over, see the “curatem” repos on Liam’s Github if this sounds interesting to you.

Reputation Proving Service

Jay, Raphael

Export cryptographic proofs of user attributes from existing sites where users have accrued reputation (i.e. Github, Twitter, etc.). These proofs can then be verified by sites or decentralized applications.
A first basic version is deployed and the service can now be queried directly through an API to check the reputation of a Twitter account. The next milestone will allow users to connect with an Ethereum account and authenticate with Twitter.

QDHP Quadratic Dollar Homepage

Raman

The Quadratic Dollar Homepage is a spin on the Million Dollar Homepage. While it also features a space for images on a webpage, it allows users to vote on how much space each image takes up. Moreover, it employs a quadratic and collusion-resistant voting mechanism on Ethereum called Minimal Anti-Collusion Infrastructure (MACI) to prevent bribery and scale images quadratically https://quadratic.page/. Implementation is finished and we are planning to do some test rounds soon.

Data Publishing Marketplace

Jacksoom

The project creates a place to trustlessly publish data after crowdsourcing funds. The user shares an encrypted dataset (e.g. picture our audiofile) that is trustlessly revealed under the condition that a certain crowdfunding goal has been reached. The project is moving quickly, contracts have been implemented and a first version of the website is live, next up is circuit implementation.

Rollup Diff Compression

Blagoj

Rollups require you to publish a diff between the state before and state after. This project investigates ways of reducing that diff in order to reduce rollup costs for the case of airdrops specifically. Currently we are at the final stages of experimenting with different data compression approaches/algorithms and benchmarking their performance. Next steps are choosing the optimal data compression approach for an iterative multi-stage retrospective airdrop and implementing the algorithm so it can be tested and used in practice on L2. The implementation will be on top of the BLS Global Wallet project above.

CLR.Fund Deployer

Spencer Graham, anonymous contributor

The goal of the clr fund-deployer is to make it as easy as possible for anybody (project, protocol, community, etc.) to create their own instance of clr.fund to fund public goods for their domain. Clrfund-deployer has 3 planned releases:

Foggy – basically, a web UI from which to deploy all the dependencies and then configure the contracts

Translucent – extending that web UI to deploy and configure the user and recipient registries and also start a funding round!

Transparent – from that same web UI, deploy (and customize!) a new web UI to host their instance of clrfund

We just released Foggy, and are getting started on Translucent, and also starting on some UX design.

Ecosystem Support Program

Authored by ESP Team

We recently published our Q4 Allocation Update with details on the grants awarded in the last quarter of 2020, with over $4 million distributed across all categories.

Meanwhile on the support side, we’ve mixed things up a bit! We’re processing inquiries through our website as always, but over the past few months we’ve explored some different ways of delivering support:

Office hours

We’ve found that an informal conversation can be a surprisingly powerful tool. Starting in February we piloted “office hours”, where teams or individuals can sign up for one-on-one calls with the ESP team on topics like project feedback, exploring whether ESP is a good fit, or help navigating the Ethereum ecosystem. We held our first rounds with a limited time window, but we’ve been happy with the outcome and we’ll be keeping signups open consistently from now on! If you’re interested to chat with us, you can submit a request here.

Focused grant rounds

We have also recently hosted two grant waves targeting specific areas for R&D. These rounds let us spotlight areas that are particularly timely or high priority, and might also have slightly different goals or selection criteria from ESP’s standard grants.

• Staking Community Grants, held in December, awarded over 25 grants for efforts to improve the Ethereum staking experience. The results of this round have now been published – check out the announcement post for more details and to explore some of the resources produced by the amazing Ethereum staking community!
• Rollup Community Grants invited proposals to grow the rollup community ecosystem, from developer tools to infrastructure, interoperability, educational resources and more. Applications for this wave have now closed and we’re in the process of evaluating submissions; keep an eye out for a post announcing the grantees soon.

Eth2 Research

Much of what the research team is up to is covered in the Finalized and “State of Eth2” updates. Beyond the very public items that make it in there, we have been digging more into stateless research, proofs of custody for EVM execution, sharding specs and prototypes, and other scaling/security research. Most of our progress can be found on posts on ethresear.ch.

Find a few of our recent posts below:

Ethereum.org

Authored by Sam Richards

New homepage

We launched a fresh new homepage! As the biggest entry point for ethereum.org, we wanted to make sure our homepage did a better job of explaining Ethereum by showing off what it enables and by helping users start their journey down the rabbit hole. Let us know what you think:
https://ethereum.org/en/

Launchpad improvements and localization

To promote a healthier, more accessible, more decentralized network, the launchpad is now available in 15 different languages (more coming soon). Alongside this localisation effort, we also rolled out some content changes and UX improvements to help users set up their beacon chain validators.
https://launchpad.ethereum.org/en/

Have ideas for improvements? We welcome collaborators. Here’s the repo:
https://github.com/ethereum/eth2.0-deposit

Translate more recent content

We rolled out translations for some of our newest content in 8 of our 33 total languages (more coming soon):
https://ethereum.org/en/languages/

Learn how to get involved.

Use case pages

Things like DeFi and the recent boom in digital art NFTs are driving users to investigate Ethereum. They’re also compelling reasons to join in. We want to make sure we cover these topics, in the beginner-friendly way you just can’t get on Crypto Twitter, so new users can learn more about the most concrete use cases of Ethereum.

We launched 3 new pages:

Know a great Ethereum use case that’s missing? Let us know!

Take a look at ethereum.org and our previous updates to see what else we’ve worked on since you last visited. To make our work more accessible and to foster more community collaboration, we’ve also started sharing an overview of our quarterly roadmap goals, which you can find on Github (see Q1 and Q2).

If you want to contribute, you can find ways to get involved, stop by our Discord or raise an issue/PR in GitHub. Special thanks to all the incredible people who have helped so far!

Ewasm

Authored by Alex Beregszaszi

EVM384

The work on EVM384 has continued and we released update 5 in late January. In this update, we proposed two different models for pricing the new instructions, and shared estimated costs of BLS12-381 operations using these models. Additionally, the update provided a brief overview of further potential improvements to the EVM.

Besides the earlier released partial BLS12-381 implementation (evmcurves), new work exploring the applicability of EVM384 to MiMC hashing was also published. MiMC is one of the zk-SNARKs friendly hashing algorithms. We were able to show a substantial gas reduction using EVM384 (including in the example use case of Tornado Cash).

Important to mention is that the work on MiMC showed some limitations of the interfaces (EVM384-v7 and EVM384-v9) proposed in update #5 and sparked subsequent work for a modified interface.

Updates about EVM384 can be followed on the appropriate EthMagicians topic.

EVM

EVMC 7.5.0 has been released, improving the evmc CLI tool and the utility libraries (new addition is evmc::hex). See the complete changelog for more detail.

The Baseline interpreter has landed in the evmone project. It provides a relatively straightforward EVM implementation with performance competitive with the older Advanced interpreter. See the evmone 0.6.0 release notes and PR#261 for additional details.

Both EVMC and evmone have work in progress support for the Berlin hardfork, in the form of EIP-2929 implementation (evmc#571 and evmone#289. These and related changes are going to be included in the upcoming releases.

A set of synthetic benchmarks has been added to the evmone project. They target individual low-level computational EVM instructions. We plan to further extend this and use it in an upcoming report.

We have also released a write up called EVM Object Format. The goal is to improve the structure of EVM bytecode. This will allow for easier introduction of various improvements and features going forward. Follow upcoming updates here.

Code Merkleization

While initially proposed to use RLP, due to demand we pivoted to using SSZ for the code tree. Added proof generation and verification support to fastssz (an SSZ library for Go), and experimented with proof compression approaches.

Also implemented code merkleization logic in geth, as well as hooks which compute code proof sizes (for different encoding formats and compression methods; i.e. RLP and SSZ encoding, Snappy compression) for historical blocks. See these lab notes about the go-ethereum changes as a guide.

In parallel to the work on the SSZ approach we have also started contributing to go-verkle in order to gain insights into the feasibility of code verkleization.

Fizzy

The 0.6 and 0.7 releases of Fizzy focused on introducing a C and a Rust API, as well as adding support for WASI. Preparing for the 0.8 release we are incorporating improvements suggested by users.

Following the goals set in our previous update, we have been evaluating efficient runtime metering approaches and have an implementation with a small overhead.

We also continued upstreaming testing improvements to the official WebAssembly test suite, with a dozen changes merged this year.

Formal Verification

The Formal Verification Team posted their own quarterly update at the end of Q1 (31 March, 2021). The post covers work on Act, hevm, and SMTChecker, and you can see it here!

Geth

Version 1.10.0 of Geth was released on 3 March, 2021 ahead of the Berlin network upgrade. A detailed announcement post, which covers updates and new features (authored by Péter Szilágyi) is available here.

Javascript Team

Authored by Holger Drewes

Berlin was knocking at the door and kept us occupied. We had a VM v5.2.0 release out mid March with full Berlin support and a VM v5.3.0 soon after adding EIP-2930 Access List generation functionality. Ethers became Berlin-ready with the v5.1.0 release with the addition of typed tx support being the major change (and challenge). On the sideline Chris put some significant effort to help HardHat on the VM v5 upgrade. While HardHat should have a Berlin-ready release out soon after integration, we generally realized that the overall dev ecosystem readiness for upcoming HFs is a systemic weak spot (where we take our share). We will give this some additional thinking if we can help here on coordination in the future.

Speaking about the future: what’s going on with our client? To make it short: we will still play modest here. We will likely be able to do a first alpha release within the next 2-3 weeks being capable to do passive full-syncing on the major networks. Major role of this client will nevertheless remain for now to help us internally on development. We have started with the EIP-1559 implementation (actually this progressed already pretty well 😀) and our client will help us significantly to test this under real world conditions early on.

We’ll also start preparing for “The Merge” ™ relatively soon (weeks), you will be able to follow the progress here. And while we’ll likely not quite make it to join the Rayonism hackathon our client will enable us to connect to an ETH2 node via RPC early on and test our tech stack against the merge requirements.

Last but not least: our client significantly helped to harden our devp2p implementation and a first really production-ready release is imminent (also: few weeks at most). We will continue to evolve here and next tackle a wit/0 protocol implementation for witness syncing recently announced by Jason Carver from the Python team which particularly excited us and which we can then integrate along our own Beam Sync experiments.

Remix

Authored by Yann Levreau

The quarterly Remix Team update is also live! Find updates on the team and members, React, VSCode extension, Matomo, Workspace, and more 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 language implemented in Rust. The team is focused on providing the community with language features and tooling that make it easy to create reliable smart contracts.
Here are some development highlights from the first part of 2021:

• Monthly releases: We began cutting releases every month starting in January and will continue to do so.
• More features: We continue to add useful features to the language. Here are some worth noting:
  
  • structs
  • external contract types
  • integrated safe-math

• Uniswap-V2 core demo: We set a goal to support a basic implementation of the Uniswap protocol by April. We finished this by the beginning of March.
• External contributions: We’ve received contributions from five people outside of the EF.
  
  • Many people get excited about writing Rust. Naturally, a number of Rustaceans have emerged to help with development.
  • We’ve also received help fuzzing the compiler from agroce. For more info, read his post.

The team will continue working on the following things:

• Getting a stable release to users.
• Expanding type support and more thorough checking.
• Adding a module system and standard library.
• Improving error messages.
• Differential contract fuzzing.
• Advanced language features.

Web3py

Authored by Keri Clowes

The two major features that the web3py team has been focused on are the Eth2 Beacon API, and making progress toward async support. We’re proud to report that the Beacon API is ready for use! Our documentation and help guides have also seen a lot of love lately, and we’ve started to plan the v6 release which will likely be coming later this year! And of course, community support and bug fixes always take priority when they come up.

Stateless Ethereum

Authored by Piper Merriam

The Stateless Ethereum effort continues on with statelessness a high priority for the Eth2 merge. The primary blocker for statelessness is currently witness sizes, which can easily be 10’s or 100’s of megabytes under the current protocol. Our original plans focused on converting to a binary trie, which was projected to reduce witness sizes down to just a few megabytes. The recent research on Kate commitments and the development of the Verkle Trie has shaken up the roadmap a bit. The c gives us a firm upper bound of 800Kb with an expected average witness of 200kb which is a massive reduction in size. Work is underway on POC implementations of the unified Verkle trie in the go-ethereum codebase.

We are also making progress on EVM changes that would place firm economic bounds on the total size of the state via “state expiry”. Rather than deleting state, “state expiry” instead moves pieces of the state that haven’t been touched for a while into an “inactive” state. Anything that is inactive can be activated by providing the protocol with a proof, elevating it back to being “active”.

In addition, the EF has established a new fund for building out Stateless Client Infrastructure to ensure that we are not only able to make the protocol support statelessness, but that clients will be able to bring the benefits of statelessness to end users via lighter weight clients.

Security (Security / Consensus Tests)

Authored by Martin Holst Swende

The foundation security efforts covers a wide range, from cross-client fuzzing to high level protocol and architectural changes to the Ethereum stack.

Since the last update, two important changes were introduced to the consensus layer:

• EIP 2929, which provides a backwards-compatible way to adjust gas pricings for trie-dependent opcodes. Adjusting opcodes according to the actual resource consumptions is important to avoid DoS vulnerabilities in the platform core, and has previously been performed e.g. in EIP 1884. The “new twist” with 2929 is that the adjustment is backwards-compatible, making all “breakage” which occurs due to the raised cost possible to “unbreak”, via:
• EIP 2930, which allows callers to specify, and pre-pay for, certain slots that are accessed later during execution. By charging this cost up front, it is possible to make the raised cost un-noticeable during the execution.

On the protocol side, the ETH-66 protocol has been implemented in go-ethereum, and it’s expected that other clients will follow the same path. ETH-66 adds request identifiers to the protocol level. Why is this important from a security perspective?

As clients work right now, any time a client sends a request to a peer and gets a response, they need to do some guesswork to determine which request a given incoming packet is in response to. This works “as long as it works”, but is error-prone; e.g. in cases where peers drop off and reconnect, or respond slow enough that the request times out.

Because of the inherent lossiness of the current protocol, it’s hard for any client to be strict about response checking, and implement any kind of rules for how to treat misbehaving peers — it’s simply very difficult to pinpoint if the cause of a mismatch is due to a malicious peer, or if it’s caused by network lag.
With request identifiers, the road is open to implement a lot more sophisticated and efficient networking stack.

From the fuzzing side, we identified one ‘crasher’ concerning Besu, which could have been exploited on mainnet, one Besu berlin-related consensus issue with Yolov3, two consensus issues related to Nethermind. Aside from that, the standard reference-tests executed on Hive found an issue in OpenEthereum, which was exploitable with particular versions of the Rust compiler.

A lot of the fuzzing work lately has been performed by Marius van der Wijden, who recently finished his Master Thesis about fuzzing ethereum virtual machines. Congratulations and well done Marius 🎉!

Solidity

Authored by Franziska Heintel

0.8.0 Breaking Release and New Features

As an early Christmas present, we released Solidity 0.8.0 mid of Dec 2020. v0.8.0 is a breaking release and most notably introduces checked arithmetic operations by default. This feature can be disabled locally by using an unchecked block. Furthermore, ABI coder v2 is now activated by default. You can activate the old coder using pragma abicoder v1. Read all details about Solidity 0.8.0 in the release announcement and find a list of breaking changes in the documentation.

We subsequently released Solidity versions 0.8.1., 0.8.2 and 0.8.3:

• v0.8.1 introduces many new features for the SMTChecker and allows to catch panic errors. More details.
• v0.8.2 adds an optimizer stage that can inline small amounts of code to save gas and provides more means to work with code documentation by exporting inline comments and allowing custom natspec tags. More details.
• v0.8.3 fixes the Solidity Optimizer Keccak Caching Bug, which is present in all prior versions of Solidity, and, in addition, includes two improvements to the optimizer which can provide a big gas benefit when writing structs that cover a full storage slot to storage. It also adds new SMTChecker docs and a tutorial. More details.

The many improvements to the still experimental support to compile via our intermediate language Yul are not visible in the changelog because the feature is not officially released yet. Still, we encourage everyone to try it out through solc –experimental-via-ir and provide feedback!

Solidity Developer Survey 2020 Results

We published the results of the Solidity Developer Survey 2020. If you’re looking for a digest, you can find summary threads with highlights here and here. We want to extend a big thank you to all of the Solidity developers that participated!

Ecosystem Outreach

We are constantly working on improving our outreach to and interactions with the Solidity ecosystem. Below you can find a few initiatives we launched in Q1.

More Inclusive Language Design

In our effort to foster exchange of information, encourage more developers to give feedback about Solidity and join the discussions on language design and future direction of the compiler, we launched the Solidity forum. The Solidity forum is now the dedicated place to discuss topics & questions related to the design of the Solidity programming language. For a quick guide on how to use the forum and its categories, see the announcement. If you’d like to learn more about how to participate in the language design, also have a look at this Contributing 101.

Closer Exchange with Tooling Developers

We launched the solc-tooling chat, which is meant to serve as a short & easy communication line between Solidity tooling devs and the Solidity compiler team. The chat room is public and lives on Matrix, with a bridge to Telegram.

Regular AMAs

We continue to host regular Solidity team AMAs. Check out the results from the latest AMA here.

Localization of Solidity Documentation

We set up a new workflow and home for translations of the Solidity documentation.
Now, we are looking for language maintainers who will organize the translation efforts for their respective language, assure quality and accuracy and make sure translations are kept in sync and are on an up-to-date level and bot experts who can help with some automation. The translations are meant to lower the entry barriers for non-English speaking developers and hence will allow a broader set of developers from all over the world to get to know Solidity. Please spread the word about this initiative in your local communities!

If you want to contribute to this mammoth task by translating or helping organize the process please join us in the new Solidity docs GitHub org and in the forum.

Note that the English reference version is and will remain the only officially supported version by the Solidity team and will always be the most accurate and up-to-date one. When in doubt, always refer to the English (original) documentation.

ZoKrates

Authored by Thibaut Schaeffer

In the past quarter, the ZoKrates team focused on a new breaking release of the toolbox. This new version is now released with support for new powerful constructs:

• constant generics
• support for the keccak family of hash functions
• inference on integer literals
• and more!

These additions enable a much more compact implementation of a wide range of algorithms, at no cost.

On top of that, a lot of internal optimisations reducing proving and compilation footprint of ZoKrates programs were introduced. For a complete list of the changes, check out the changelog.

Finally, closer exploration with the ZKP Research team was started with the goal of supporting snarks schemes with universal setups.