EF-Supported Teams: Research & Development Roundup

Welcome to London! This is an exciting time for the Ethereum ecosystem, and the pace will only pick up further as we approach Altair [1] [2] and the Merge in the months ahead.

The Beacon Chain now has 6.5+ million Ether staked, and 200K+ active validators online across five clients, and the network is now burning Ether as part of the changes made with the London update.

As always, there’s much more progress being made by EF-supported projects and teams that help to improve our Ethereum experience. This roundup series is an opportunity to highlight their 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!

Ecosystem Support Program

Authored by ESP Team

Office hours

Road to Devcon Grants

We’re collaborating with the Devcon team on a round of small grants and other support for community event organizers. Organizers of virtual and in-person events can apply directly for grants of $500-1500 to cover costs like space or equipment rental, swag, snacks or other incidentals. Learn more and apply here. Lee esta página en español; 用中文阅读本页.

We also recently published our Q1 Allocation Update, with details of 47 grants awarded in Q1 totaling $5,341,000.

Eth2 Research

Beyond the content that makes it into Danny Ryan’s Finalized series, the research team has continued into areas including stateless research, proofs of custody for EVM execution, sharding specs and prototypes, and other scaling/security research. Most of their progress can be found on posts on ethresear.ch.

Additionally, find a few of their recent posts and other content below:

Ethereum.org

Authored by Sam Richards

To make our work more accessible and to foster more community collaboration, our team publishes an overview of our quarterly roadmap goals. See last quarter’s roadmap here: #2849.

Greetings fellow Ethereans!

Happy L2 summer 😎 (or winter for our friends in the southern hemisphere)! Hope you’re enjoying your time in this space – we know we are! As always, our vision with ethereum.org is to create the best portal for Ethereum’s growing community, and to serve as the front door to Ethereum for the millions of new visitors each month.

Content updates

In Q3 our ethereum.org product focus will be to keep pace with all the incredible progress in the space so that our broader community can stay informed on developments on Ethereum network upgrades, Layer 2 projects, developer tooling, user applications and more.

Thank you to the hundreds of folks who have contributed content so far ❤️

Learn how to get involved

CLR funding round for Eth2 projects

New funding mechanisms for public goods offer massive potential for the Ethereum ecosystem and the world beyond crypto. While not directly related to ethereum.org, our team is part of the Ethereum Foundation, which is one of the largest funders of grants and public goods within the ecosystem. We want to increase the cultural momentum around ecosystem funding for public goods as well as experiment with mechanisms in which support is allocated to the ecosystem.

We’ll continue our work from Q2 with teams in the space, aiming to launch a CLR.fund round for Eth2 projects on an L2 mainnet by the end of Q3.

This work will also allow our team to stay on top of the latest tools, technologies, and best practices involved with dapp development, from testing and deployment tools to identity solutions and Layer 2 technologies. We plan to to bring these first-hand insights back into our developer resources.

Learn more, follow along & get involved

Translation Program

Thanks to our >1,400 volunteer translators over the past couple years, ethereum.org now supports 35 languages! Yet as the website has grown & is constantly updated to keep pace with the developments in the space, many of our languages have fallen somewhat out of date. We’ll be making a push in Q3 to update 20+ of our translations to more recent versions of our website content.

With our new Translation Program Lead, @lukassim, we also plan to improve our supporting documentation & improve use of our translation tools to improve consistency and quality throughout the translation process.

Learn how to get involved

As you can see from all our goals above, our success is driven by our open source community of collaborators. Contributors come in many shapes & sizes – translators, developers, copywriters, designers, experts & amateurs. We want to continue to educate & empower folks who are curious to get involved in the Ethereum ecosystem & our ethereum.org community.

Our new Community Lead, @minimalsm, will be leading efforts to support & empower our growing ethereum.org community. Stay tuned for the specific initiatives we plan to roll out this quarter!

Have ideas? Reach out on our Discord server or here on GitHub.

How does that sound?

We appreciate feedback on our roadmap. Our guiding principles are based on delivering the most value in the shortest time, so if there’s something you think we should work on, please let us know! We welcome ideas and PRs from anyone in the community.

More on contributing

Ipsilon (previously Ewasm)

Authored by Alex Beregszaszi

The Ewasm team has rebranded to a new name: Ipsilon. It is a reference to the state transition function defined in the Yellow Paper. We want to signal that our work for a long time has been more broad than only Ewasm.

The team’s core concern is the execution environment / engine of Ethereum (aka the EVM or any future versions or replacements of it). We provide analysis and implementation of own and third party proposals (i.e. new EIPs proposing changes to the EVM), provide tooling (evmc, evmone, fizzy), and support existing teams (e.g. Solidity, go-ethereum, Silkworm) with implementation and analysis.

Most of our content is published here.

EVM Object Format (EOF)

In the previous update we have mentioned the EVM Object Format (EOF) as a new proposal. In the last three months a lot of progress has been made. The first step, EIP-3541, has been accepted into the London update — this only reserves a starting byte which can be used to introduce EOF in a future protocol update.

A concrete proposal, EIP-3540, which introduces the container format and code-and-data separation has been published. Furthermore there is an explainer document giving background and a roadmap (this will be updated as we go), and we also gave a PEEPanEIP presentation (video and slides).

Both EIP-3541 and EIP-3540 have been implemented in geth and evmone.

Lastly, we shared a short proposal to revamp EIP-2938 using EOF and other teams considered building on EOF.

Address Space Extension (ASE)

The second big topic for us has been the address space extension, which is a requirement for the state expiry roadmap.

It was first described in an Ethereum Magicians post and various discussions on the Eth R&D discord. Our specification builds on all this prior work and aims to give a coherent overview of how to implement this change. An additional document listing a comprehensive set of test cases was also released.

While the core of the proposal is not too complicated, there are many implications. This discussion document is the basis of the ongoing Address Space Extension Working Group, which already had three calls (recordings: #1, #2, and #3).

Other research

On the topic of code merkleization / code chunking, we published a thorough analysis of the impact of code chunking costs. The new version of the verkle tree proposal reconsidered costs based on the results.

The idea of an MCOPY instruction was prompted by the research on EVM384. We published a short writeup detailing this proposal, providing a pricing, and evaluating the benefits for regular contracts besides the use in EVM384.

EVMC

• 8.0.0 release
  
  • Berlin support, new callbacks to update global account/storage accessed list.

• 9.0.0 release
  
  • London support and block_base_fee added to transaction context
  • evmc run with –bench

evmone

• 0.7.0 release
  
  • Berlin support
  • Optimizations in Baseline interpreter’s jumpdest analysis
  • Improvements to the C++ API

• 0.8.0 release
  
  • London support and BASEFEE instruction implementation
  • Instruction tracing following EIP-3155 format added to Baseline interpreter
  • Option to count the number of executed instructions in Baseline interpreter
  • More optimizations in Baseline interpreter and in intx and ethash libraries.
  • Improvements to benchmarking tools

Formal Verification

The Formal Verification Team will post their own updates (covering Act, hevm, SMTChecker and more) here, and in recent months, some of the notes saw improvement as well.

Act

• SMT backend rewrite
• Pretty printed counterexamples

hevm

• Invariant testing
• Berlin support
• Solidity 0.8 support
• Symbolic constructor arguments
• Sourcemap support for Solidity immutables

SMTChecker

• Support to Solidity free functions/constants
• External calls to known code
• Trusted mode
• Report contract invariants to the user

Geth

authored by Felix Lange

In Q2, we shipped four releases of Geth. The team was mostly busy implementing
the London fork changes, especially EIP-1559. We also conducted a lot of testing of
the new snap sync, which is now enabled by default in Geth.

And as always, make sure to download the latest version of Geth!

Javascript Team

Authored by Holger Drewes

In Q2 we substantially grew our team and had three team members joining to work on the EthereumJS libraries – Andrew, Emmett and Gabriel. Our work itself largely concentrated on getting EIP-1559 ready to ship and overall make our libraries ready for the London HF. The latest round of releases (VM v5.5.0, Tx v3.3.0 and others) from early July now come with finalized London support including all hardfork block numbers and are ready to send EIP-1559 style txs over the wire.

The 1559 tx library update brought in a lot of community requests and responses and we took the occasion to have a closer look at the usability of the library. As some follow-up we improved a lot on documentation and also made several substantial usability improvements which should make the library easier to use. We also caught up with the recent broader trend of Ethereum activity moving to side chains and L2 and our tx library is now better prepared to send txs to networks like Arbitrum, Polygon or xDaiChain, see tx README for details.

And, worth to mention this again, though the release itself is already some while ago (late April): due to a lot of live testing we did along our EthereumJS client development, our devp2p library is now finally ready to be used in production and we are eager to see your use cases along digging deeper into the Ethereum devp2p networking stack.

Some outlook: we recently merged our first PR on “The Merge” allowing our client some first interaction with an Eth 2.0 PoS client via RPC. This will likely be followed by a lot of additional work and be a main work emphasis for the upcoming quarter.

Privacy & Scaling Explorations

Authored by Thore Hildebrandt

The Privacy & Scaling Explorations team works to bridge the gap between cutting-edge research in zero-knowledge proofs, and application development on Ethereum.

zkEVM

The goal of zkEVM is to run smart contracts in a zk-rollup. Unfortunately, the EVM was not designed to run in a zk circuit which makes it a challenge. Projects like zksync tackle this problem by recompiling to some other vm. We want to implement the full set of EVM opcodes directly into the zk circuits so a smart contract running on L1 can be deployed to L2 with minimal modifications. This will allow full compatibility with existing tooling and enable us to leverage knowledge of the EVM that the ecosystem has built up over the past years.

We have put together a team over the past couple of months, got many of the hard research problems out of the way, and are in the process of designing and building the first prototypes.

We’ve defined two snarks to check the computation validity of the EVM, a state proof and an EVM proof. The former protects the read-write consistency of the stack, memory, and storage. The latter checks the execution integrity of opcodes.

We’ve specced out a way to do common arithmetics on 256 bit word in the circuit. We specified basic EVM opcodes and in the progress of implementation. We have test cases for witnessing EVM execution created. And we are in the process of specifying the way to do cross contract message calls.

Perpetual Powers of Tau

In September 2019, we launched the Perpetual Powers of Tau ceremony (PPOT). PPOT aims to benefit the zero-knowledge ecosystem, particularly zk-SNARK projects built on Ethereum, by partially easing the burden of trusted setup ceremonies. Many zk-SNARK projects require two phases of parameter generation, and PPOT replaces the first phase, which can be shared by all circuits. Individual teams can choose any contribution from the ceremony to branch out and perform their own phase-2 setup.

This ceremony supports circuits up to 2 ^ 28 constraints, which means that each contribution requires a 97G download, a 1-day computation, and a 49G upload. At the time of writing, we collected 71 contributions and all contribution files can be downloaded and independently verified against a public ceremony transcript.

Projects that are planning to use or have used the ceremony include tornado.cash, Semaphore, Hermez, MACI and zkopru. The easiest way to contribute is to reach out to Wei Jie via Telegram @weijiek. Listen to this podcast to hear Wei Jie speak about the ceremony.

MPC Phase 2 UI

The goal of a trusted setup is to securely generate zk-SNARK parameters. As long as one party in the ceremony behaves honestly and is not compromised, the entire setup is trustworthy. The computation can be split up into two phases. In the first phase (see Perpetual Powers of Tau) participants generate powers of a secret (tau) on an ongoing basis. In the second phase, participants take the output of phase one and apply it to a specific circuit. Projects that want to conduct a trusted setup can reduce their work as only the (circuit specific) second phase needs to be performed.

Our goal with the MPC Phase 2 UI project was to make it easy for projects to run a user-friendly public phase 2 trusted setup without having to develop their own infrastructure. We successfully performed a ceremony for zkopru with a first version of the UI and applied learnings from this process in the latest release. If you want to learn more check out the repo and join our telegram channel.

Hubble

Optimistic Rollups (OR) allows greater layer 2 scalability with the use of on-chain data availability and fraud proofs. Hubble allows for the creation of optimistic rollup chains with the same interface so that people can enter the rollup space once and then move between chains instantly at negligible costs and remove the need to ever “exit” the low cost rollup world.

Key features include mass migrations and a global account registry. Burn auctions will be used to decentralise the coordinator and to distribute MEV to CLR’s. Transfers to new accounts are possible directly from L2 without having to deposit on L1. With the help of BLS signatures the team was able to achieve ~2700 tps. The hubble BLS wallet aims to support other OR’s such as Arbitrum, Optimism and Fuel.

Hubble’s code is available on Github. We have a stable devnet up and running, completed database work and multi-token tx pool. Next step is polishing clients and we are targeting a testnet release soon.

Zkopru

zkopru (zk-optimistic-rollup) is a layer-2 scaling solution for private transactions using zk-SNARK and optimistic rollup. It supports private transfer and private atomic swap within the layer-2 network between ETH, ERC20, ERC721 at a low cost. It also provides instant withdrawal with pay-in-advance features and compliance compatibility using spending key and viewing keys. Wanseob presented the system at zk-summit.
We have completed a trusted setup for the project (one of the largest ever conducted). We also completed an audit with Least Authority and are in the process of doing a second one. Within the next couple of weeks we will launch Zkopru on public testnet and, if all goes well, also on mainnet. Stay tuned for updates on our medium blog and join the telegram group.

Blind Find

Blind Find is a p2p network allowing users to search for others without revealing their identity. After a successful search, the user can prove the search path exists in the network with a MPC-based construction, without revealing the path itself. The v1.5 search protocol now works.

For the next version of Blind Find, we are changing our direction to build a privacy-reserved reputation system in a peer-to-peer network, based on EigenTrust. To learn more and discuss, please join the telegram group.

Unirep & Unirep Social

UniRep is a private and non-repudiable reputation system. Users can receive positive and negative reputation from attesters, and voluntarily prove that they have at least a certain amount of reputation without revealing the exact amount. Moreover, users cannot refuse to receive reputation from an attester. We are using Unire to build Unirep Social: a reddit-like platform that allows users to privately accumulate karma.

We finished the core functions in Unirep and Unirep Social, started building and designing the Unirep Social frontend. Next steps are setting up a website and deploying Unirep on testnet.

Join the telegram channel to learn more and discuss!

BLS Sig Aggregation

The project aims to tower layer 2 transaction cost via a smart contract wallet. Smart contract wallets give users additional safety mechanisms independent of any wallet UI they may use, but are expensive to deploy (and use on) on Ethereum’s layer 1. Layer 2 solutions like Optimism and Arbitrum greatly lower this cost-barrier, and allow more users to benefit from smart contract wallets. This is primarily due to these being general purpose computation solutions. DApps bridged to layer 2 will be more usable than those only on layer 1 thanks to faster transactions at lower-cost, but there are further gas savings to be had by DApps and users. We use BLS signatures to reduce the on chain storage which can increase throughput to ~3000 tps. You can check the project’s current status on Github. Next steps are to deploy to optimistic-kovan and gas cost/estimation as well as social recovery functionality.

CLR.fund for Everyone

The goal of the project is to make it easy for any community to run their own CLR round with clr.fund. We paused some backlog work to focus on an instance of clr.fund for cryptorelief. We ran into some scale limits for that instance, so refocused around upgrading clr.fund core contracts to use new x32 MACI circuits and MACI 0.9.4. Part of clr.fund-deployer’s promise is to enable easy deployment of the clr.fund app, so we also participated in the recent work to coordinate merging select features from the ETH2 clr.fund instance’s app into the canonical clr.fund front end.
Next focus it to coordinate trusted ceremonies for the new x32 circuits, to finalize the clr.fund subgraph and to deploy the next round of clr.fund. See the project on Github.

InterRep

Reputation is the key to trust. People spend years building up their reputation on centralized social platforms, but they have to start from nothing whenever they start using a new app. InterRep aims to make reputation portable to expand the compounding benefits of trusted human interactions across the web. Check out this blogpost for the initial announcement. We’re working on the next iteration of the project.

Research

Rollup Diff Compression

We have investigated how the data footprint of a rollup can be further compressed for the airdrop use case. We used Reddit’s airdrop as an example. Check out our blogpost for more info.

EVM Rollup Reviews

Were conducting a series of security reviews on EVM Optimistic rollups starting with Optimisim. The review is completed and will be available soon, in the meantime we published this explanatory blogpost on the system. A review for Arbitrum is currently in the process.

MACI

Originally proposed by Vitalik Buterin in an ethresear.ch post, systems built with MACI make collusion among participants difficult, while retaining the censorship resistance and correct-execution benefits of smart contracts. Although MACI can provide collusion resistance only if the coordinator is honest, a dishonest coordinator can neither censor nor tamper with its execution. See Wei Jie explaining how MACI works on Youtube. You can use the MACI command-line interface to run a demo.

The team has completed a major milestone (version 1.0 of the smart contracts and zero-knowledge circuits), and we are completing end-to-end test suites. Furthermore, we have started working with an auditor to challenge the security and functional assumptions of the system. We are still working closely with EF folks working on an ETH2 funding round and also a Covid relief funding round. We have also begun work on an additional feature that allows for negative voting.

Join the Telegram group to learn more and discuss.

Remix

Authored by Rob Stupay

In Q2 Remix worked on its ability to interoperate with other tools in the ecosystem.

See more in our blog.

Snake Charmers [Python Ecosystem: PyEVM/Trinity/Web3.py/Fe]

Fe-lang

Authored by Grant Wuerker

In the past, Fe development has focused on supporting the features needed to compile certain demo contracts. The most advanced demo being the Uniswap V2 core contracts. In Q2 of 2021, development focus was shifted from demos to preparing for a release that can be used in production safely (aka MVP release). We plan on cutting an MVP release before the end of the year.

Here are some development highlights from Q2:

• Four more alpha releases (0.4.0 – 0.6.1).
  
  
• Added Rust-style diagnostic messages.
• More runtime checks.
  
  • ABI data validation
  • Arithmetic overflow checks

• Support for custom error types and panic codes following Solidity.
• Fixed bugs identified by compiler fuzzing.
  
  
• Launched website with links to documentation and tutorials.
  
  
• Regular development updates.
  
  

Web3py

Authored by Keri Clowes

The main focus of the web3py team in Q2 has been EIP-1559 compatibility and support for asynchronous JSON-RPC calls. Async work will continue into Q3. Documentation was a priority in Q2 as well, adding many clarifications and examples from commonly asked questions.

Stateless Ethereum

Authored by Piper Merriam

The Stateless Ethereum effort continues. In the last months, we have filled in the last remaining roadmap items needed to deliver on the end goal of protocol level support for stateless block execution.

The Verkle Trie is a new data structure for storing the Ethereum state which solves the problems of reducing block witnesses down to a manageable size. Our plans for “State Expiry” give a clean and easy way to migrate the existing hexary patricia trie onto the new verkle trie structure. This will also solve the “state rent” problem, establishing economic bounds to the total state size.

The verkle trie migration also simplifies the process of establishing economic bounds on the size of block witnesses, something that was previously much more difficult under the hexary patricia trie. The last major puzzle piece which needs to be figured out is how to execute on “Address Space Extension” aka ASE.

These items represent everything necessary to support stateless block execution in our protocol, but maybe more importantly, they are significant upgrades to our protocol which address multiple long standing and difficult to fix issues.

Security [Security / Consensus Tests]

Authored by Martin Holst Swende

Q2 was mainly focused on the London hardfork, implementation of EIP 1559 and cross client testing. An exploitable flaw was found in the specification which could cause maliciously bloated transactions/blocks. Erigon has also been added to the fuzzing framework.

The Hive testing framework identified issues in the ENR interoperability between Besu and other clients, causing ENR exchange to fail.

Solidity

Authored by Franziska Heintel

In Q2, we released Solidity versions 0.8.4., 0.8.5, 0.8.6 and 0.8.7:

• Solidity 0.8.4 adds custom structured errors, bytes.concat(…), allows more flexible configuration of the SMTChecker and fixes a bug in the Solidity ABI decoder v2.
• Solidity 0.8.5 allows conversions from bytes to bytesNN values, adds the verbatim builtin function to inject arbitrary bytecode in Yul and fixes several smaller bugs.
• Solidity 0.8.6 fixes some non-critical but annoying bugs, especially a warning about unreachable code that is in fact reachable.
• Solidity 0.8.7 introduces support for the London upgrade, includes various improvements to Yul to EVM code transformation, the SMTChecker and some bugfixes. London support means support for the BASEFEE opcode (EIP-3198 and EIP-1559) which exposes the block’s base fee. This can be accessed via the global block.basefee or using basefee() in inline assembly or Yul.

Moreover, the optimizer documentation section has been expanded with more material and we explained the soliditylang.org domain umbrella and location of binaries on the blog.

Several Solidity team members presented at EthCC. You can watch their talks on YouTube:

Last but not least, we are looking for a new team member! Please reach out if you are a C++ engineer and are keen on developing and maintaining the Solidity language and compiler and contributing to language design discussions and decisions!

ZoKrates

Authored by Thibaut Schaeffer

This quarter, the ZoKrates team made progress on all fronts.

Language

When it comes to language features, ZoKrates now has improved support for constant generics, user-defined and low level constants. This enables clearer code which works on a variety of inputs, proof systems and curves. The u64 type was also added.

Runtime

Runtime performance was improved thanks to cheaper conditionals and random array access as well as optimised comparison checks. They translate into fewer generated constraints, which in turn reduces the cost of proof generation. In addition, an optional branch isolation feature was added to simulate short circuiting at execution.

Standard Library

The standard library gained support for the SHA3 family of hash functions, as well as the SNARK-friendly Poseidon hash function. Another major addition is the support for recursive proof composition.

Targets

Finally, ZoKrates now supports the Marlin universal SNARK as a target, which reduces the trust requirements to a single trusted setup phase.

For a full list of the changes, check out the changelog