Friends,

Over the last year, developers and researchers supported by Ethereum Foundation have kept their heads down and continued to produce at a staggering pace.

Their focus has remained on their work, and together we’re all building a more complete Ethereum. Today, our regular all-team update series is relaunching in a changed and ever growing ecosystem. Ethereum features larger dApp, developer and user communities than ever before, the network has continued to improve, and steady progress has been made on initiatives large and small.

While many teams do release their own well-rounded updates, we thought it appropriate to bring the community the latest from many of the teams (some of whom are softer spoken) supported by the Foundation. Enjoy!

Aleth / C++ Ethereum

In preparation for the Constantinople / Petersburg upgrade Aleth had a number releases – starting from 1.5.x series and ending with the latest 1.6.0. Aleth received a lot of p2p network level improvements including a standalone devp2p discovery client called aleth-bootnode, and is compatible with the latest Ethereum revision.

Changelog: https://github.com/ethereum/aleth/blob/master/CHANGELOG.md

The EVMC project continues to advance by receiving new language bindings and other improvements while remaining ABI compatible with version 6.

Changelog: https://github.com/ethereum/evmc/blob/master/CHANGELOG.md

FInally, the ethash library (https://github.com/chfast/ethash) has received ProgPoW support and some integration fixes and improvements.

Changelog: https://github.com/chfast/ethash/blob/master/CHANGELOG.md

DevOps

There are five main areas where devops resources are used: Websites, Bootnodes, Geth, Swarm, and Testing. Devops continues to improve our process for deploying infrastructure, mainly with Ansible and Terraform but also with Kubernetes. We are also doing a better job documenting and tracking how infrastructure is used by all of the development teams.

One mini-project which recently came to completion is collecting together recent code forks of EthStats and creating a release and new repo which we call “EthStats Classic” (https://github.com/ethereum/eth-netstats). Alethio EthStats is the 2.0 and will be maintained by the Alethio team (https://github.com/Alethio/ethstats-network-dashboard).

From within the Swarm team: We are building tools with Kubernetes that help us quickly provision a variety of Swarm deployments with up to 1000 Swarm nodes, out-of-the-box configured with tracing, monitoring and data visualization tools, which helps our development and testing efforts. These tools allow us to run a number of end-to-end tests as well as mock different network scenarios and simulations. We also run periodic integration tests on larger deployments in addition to our go-test test suite prior to every release, making sure we don’t introduce regressions or performance degradation in Swarm.

DevP2P Design

In early 2019, DevP2P Design completed work on a few key tasks:

• EIP-778 (Ethereum Node Records) was approved in the allcoredevs call.

• Protocol specifications of eth/63 and les/2 have been moved to the https://github.com/ethereum/devp2p repository from GitHub wiki pages.

• Initial drafts of Node Discovery v5 spec have been published.

Meanwhile, we are hard at work on finishing the Node Discovery v5 specification.The “par”, “pip” and “shh” protocol specs are being adapted for publishing in the devp2p repo and implementation of EIP-868 and Node Discovery v5 in Geth. We are also working on an EIP for RLPx v6, which will fix some crypto issues and on integrating EIP-778 node records into the handshake.

ENR extensions and supporting development tools have been added to Geth, both as an extension to v4 and as part of v5. Discovery v5 protocol and Geth implementation is nearing a completed state as refinements are made, and external auditors are now being introduced to the protocol for a security audit. Discovery v5 is receiving a lot of interest from the Eth 2.0 implementers community, and Felix has attended meetings with them to help answer questions on where the protocols complement each other.

The devp2p repo continues to gain traction as the home for Ethereum communication protocols, with a number of interesting proposals under review, and documentation such as LES and PIP completed. Much behind-the-scenes work and discussion has been going on regarding LES and its future direction. A number of improvements to LES code structure and robustness are in the Geth pull-request pipeline (big shout out to Gary Rong) addressing immediate concerns, while the long term direction is being researched and established. In the coming weeks the Geth team will meet to consolidate the ideas and make a decision on the direction of LES and its implementation.

EF Grants

Through the first quarter of 2019, we publicly announced Wave 5 and released more recipients on stage at Ethereal. It has been an extremely exciting time for the program as we have quietly expanded our scope to encompass different project types and explored more ways in which we can support the community.

While we continue to accept new applications, we are also actively sourcing high affinity applications from core devs and researchers. Additionally, we will (in the coming months) publish a Grantee Retrospective highlighting the impact of past grants and the great teams behind the projects.

The goal for the program is to not only provide financial support, but to provide more bespoke support for high potential teams including research support, connections, communications, and more. By increasing the support system and incorporating more voices, we stay true to the mission of decentralizing the decision making process as well as truly doing everything in our power to advance the ecosystem. Stay tuned for more!

EthereumJS

Our focus within the EthereumJS team is to serve the community with high-quality and robust JavaScript/TypeScript implementations of base-layer Eth 1.0 and increasingly Eth 1.x technologies and protocols. Please have a look at our organizational documentation at ethereumjs.readthedocs.io for an introduction on what we are doing and some key entry points to our work.

TypeScript

The center of attention in the early part of the year was the transition of our code base to TypeScript and we are nearing completion on our most used libraries. We have released TypeScript versions of core building blocks like our blockchain and transaction libraries (the latter also now with full hardfork and EIP-155 replay protection support);here is an open PR with a complete rewrite of the devp2p library in TypeScript waiting to be merged (kudos to Dmitriy Ryajov from MetaMask/Mustekala); and – probably the most exciting piece – the transition of our VM implementation to TypeScript has now been completed and is already merged into the master branch. Watch out for a beta release to follow within the coming days!

VM

We know the importance of a well-structured, modular and expandable JavaScript VM for the realization of powerful analysis and debugging functionality within development tools like Remix, Truffle and others. To this end, one other current focus of the last months was to make strong moves toward these goals and do significant refactoring work on the VM. Mainly realized by our new employee Sina Mahmoodi, the upcoming v4 VM release will ship with much more explicit and readable memory and stack handling, code modernization with the introduction of ES6 classes and async/await usage as well as a general refactoring and modularization of the EVM specific code structure. The latter –  together with some newly introduced EEI-like environment interface for accessing blockchain data – is in preparation for an already-in-the-works eWASM integration within the VM.

Other Research

We are also dedicated to continue supporting and maintaining our existing code base to keep our libraries secure, robust and performant. The latest experimentation following these goals touches on using WASM modules for cryptographic primitives, BigInt usage in JavaScript/TypeScript together with fixed-width number handling as well as less error-prone handling and conversion of hexadecimal and buffer values. We’ll let you know once we have concrete results to share on these various fronts.

Ewasm

The past months have been really busy and fruitful. To ensure Ewasm is well-designed as an execution layer, the design process is driven by prototypes, analysis and benchmarking. In Q1 we began extensive benchmarking studies of both WebAssembly engines and EVM engines. In Q2 we released Scout, a prototype execution engine for Ethereum 2.0. Our focus in Q3 will be continued iteration on prototypes, informed by analysis and benchmarking.

Ewasm during Q1 2019

Benchmarking

As benchmarking progressed, new questions arose which required more detailed benchmarks and sometimes new infrastructure. Benchmarking aims to answer open questions, including those related to:

* different WebAssembly engines (including interpreters and various types of compilers)

* various implementations of Ethereum precompiles

* implementation of the same contracts in WebAssembly and EVM

* different metering strategies

Benchmarked WebAssembly (Wasm) engines include a significant number of standalone engines, as well as the Wasm engines we have integrated into Ewasm clients (via Hera).

For the precompiles comparison, we have used go-ethereum, native-compiled Rust implementations and Wasm-compiled Rust implementations. The Rust implementation of every Constantinople precompile can be found at ewasm-precompiles. We have also used various manually optimised C versions.

For the EVM comparison we have selected optimised EVM implementations of contracts and implemented counterparts in WebAssembly. The EVM bytecodes were benchmarked using go-ethereum, parity-ethereum and evmone. These comparisons have been especially fruitful, revealing new goals and requirements for our design.

The structure of WebAssembly is well-suited for metering optimizations. Several metering prototypes were developed and benchmarked, with attention to common classes of contracts and types of WebAssembly engines.

Results on EVM were published in Q2 (see below). Reporting on further results, including in-depth analysis of WebAssembly engines, is a work-in-progress and will be forthcoming in future publications.

Precompiles

Implementation of all the Constantinople as well as four newly proposed precompiles (blake2, ed25519, bls12-381, sha1) were completed and are available in the ewasm-precompiles repository.

We were successful at syncing the entire Rinkeby chain using these implementations in go-ethereum.

Eth 1.x

Some members of the team participated in the Eth1.x / Istanbul meetups in San Francisco and Berlin. We gave updates on our progress and presented some of the EIP proposals for Istanbul, which have a significance for Ewasm. Three notable areas of change are better protocol limits, separation of init and runtime code and account versioning.

Eth 2.0

The Ewasm team has had ongoing discussions with the Eth 2.0 research team about Phase 2. We shared open questions, design considerations, and ideas. The Ewasm team participated — mostly remotely — in the Eth 2.0 research meeting prior to EDCON in April. The goal was to discuss execution engine requirements for Eth 2.0.

Our proposals are tracked on our design repository (https://github.com/ewasm/design/issues).

Testnet

The testnet is actively maintained at ewasm.ethereum.org. Contracts can be written in Rust using Rust tooling (ewasm-rust-api and chisel), which has been improved. Contracts can also be written in C, which has a less developed toolchain.

Ewasm during Q2 2019

Eth 1.x

We have published a subsection of the benchmarking report: EVM benchmarks. The results demonstrate potential for significantly reducing the gas cost of computational opcodes in EVM, motivating us to propose EIP-2045: Particle gas costs for EVM opcodes.

The EVM benchmarks highlight new speed records set by the optimized EVM implementation: evmone. Created in a joint effort of the Ewasm and Aleth/C++ teams, evmone is designed to be imported as an execution module by any Ethereum client. Further analysis of the speedup attained by evmone and potential gas cost reductions in EVM is ongoing.

Eth 2.0

We released Scout, a prototyping tool for Wasm execution scripts on Ethereum 2.0. Scout’s release was announced on ethresearch here and was presented at the Scaling Ethereum conference in Toronto (video here).

Scout is a prototype of a new approach to execution on Ethereum 2.0 based on “execution environments”. Further experimentation and analysis is needed to determine if execution environments can meet the requirements of Ethereum 2.0, and Scout is designed for running such experiments. A number of researchers and developers are excited about this new approach (see the update on Serenity from the Research team, below).

Wasm on the Blockchain

The Ewasm team gave four presentations in Berlin at the inaugural Wasm on the Blockchain workshop. Videos from the event have not yet been uploaded, but slides are available:

Some members of the Ewasm team also participated in the June meeting of WebAssembly’s Community Group. This has allowed us to understand and discuss upcoming proposals for WebAssembly, many of which are relevant to Ewasm. Notes from the Community Group meeting are available in the WebAssembly/meetings repo.

Geth

The Geth team has been working on the next major release, v1.9.0, which has been in the works for the better part of 4 months now. Some teasers that we’ve dropped along the way revolve around significant performance improvements for archive nodes and significant storage reductions for full nodes. These seem to be confirmed by external entities too, so we’re really happy about them. We’ve also been working on a new database format that permits moving a large chunk (estimated at ⅔, per a recent benchmark) of the data of a full node (not archive) onto a HDD, making it easier and more cost efficient to run Ethereum nodes.

Lower level networking: the team’s been focusing on the new discovery specs (ENR and company), with the aim to replace both the old v4 (used by full node) as well as the hacky v5 (used by Geth light clients). This will be the first real upgrade of this infrastructure in the last 4 years, so we have a lot of lessons to incorporate. The aim is to build a much more robust system that can support coexistence of higher level protocols (les) and multiple Ethereum networks (mainnet, testnets, etc).

Higher level networking: the light client protocol sports transaction lookups by hash and new RPC APIs to support priority service to paying customers. The team reviewed directions for the LES and PIP protocols, and have agreed to start to establish common directions between Geth and Parity. The first cross-team meeting is coming up in May.

We’ve also focused on separating account management out of Geth into its own signer application called Clef. The first release will be CLI only, but we’ve been working on multiple proof of concept UIs to make sure we and others can build on top of the building blocks Clef provides. Clef’s goal is to provide a secure way to manage your Ethereum accounts that can handle both keys as well as hardware wallets; but most importantly, one that can be used by all DApps on your system without each having to roll their own accounts handling!

Other smaller features we’ve been working on include a GraphQL-based API for querying chain data, built in support for smart card wallets, updated Ledger support, Prometheus monitoring support (in addition to InfluxDB which we’ve already rolled out), BlockScout integration into Puppeth, and more.

As we’re drawing eerily close to the 1.9.0 release, we’ve kept this section shorter and will do an expanded blog post in the following couple of weeks!

Grid

The Mist Browser was sunset, but Ethereum Grid was born. Grid is a desktop application that allows users to securely download, configure and use various clients and tools in the Ethereum ecosystem. Among its potential benefits, Grid can:

1. allow a less technical audience to safely interact with technical tools

2. help projects in the ecosystem reach wider audiences

3. provide a platform to accelerate hacking on Ethereum.

The Grid team would love your feedback on the alpha software and to hear from projects interested in building a plugin on the platform!

Moon

Our recent accomplishments are available on our roadmap as an early year written post! Check it out on github: https://github.com/moonad/roadmap.

Play

Meet Play: Tooling for decentralized education

Play launched our first tool a month ago – an embeddable Solidity editor. You can paste in solidity code and get a live preview which allows you to publish the contract and interact with it on chain. Play can be embedded in any site or app – to demo your smart contract, teach, you name it! Try it out at https://play.ethereum.org/editor-solidity/

We also just launched our second tool, a static workshop/tutorial generator.

Stay tuned and connect with Play team https://twitter.com/play_ethereum

Python Ecosystem [PyEVM/Trinity/Web3.py/Vyper]

Web3.py

Web3.py has been working toward a v5 beta release. Version 5 includes work to standardize the supported RPC APIs based on EIP-1474, a new API to read from deployed contracts, implementing signing standards like EIP-712 and EIP-191, as well as many bug fixes. Web3.py v5 also includes a new experimental package manager API. See the release notes for more info.

Vyper

Vyper has benefited from a number of internal cleanup tasks. Examples of this included things such as a thorough lint check, the addition of type annotations to certain code modules and automated checking of those annotations, overall improvements to Vyper’s test rigging and continuous integration pipeline, and various code refactors. All of this was part of an ongoing, project-wide push for improved maintainability and readability. The long term goal of this push is to make it easier for new contributors to join the project.

Vyper also continues to add planned features. For more information, visit Vyper’s github issues and pull requests pages.

Trinity

Trinity has continued to improve with lots of bug fixes, performance improvements and Constantinople support. We’ve also been working on making the code base more modular to increase maintainability and code reuse between the Ethereum 1.0 and 2.0 parts of the code base. Trinity continues to improve its event-driven architecture and extensibility support.

Additionally, Trinity has received many updates working towards a first Ethereum 2.0 testnet. We continue to collaborate with the research team to integrate Eth2 into Trinity.

In Eth1.0 news: we’re currently experimenting with a new feature we call Beam Sync. Imagine starting a Trinity node and having it start processing the latest blocks and serving RPC requests within minutes. Beam Sync will verify blocks as they’re mined by prioritizing sync of the state used in the latest blocks.

And finally on the Eth1.x front, we’ve been working on the Firehose Sync protocol, a new state sync protocol which will radically decrease the amount of time it takes to start a node and download all the data needed to be a first-class node on the Ethereum network. Firehose and Beam Sync enhance each other. Beam Sync is possible with the current network, but will be dramatically improved with the Firehose Sync protocol.

eWASM

We have also been laying some groundwork for eWASM in the last months. The py-wasm library now has a fully functional implementation of the WebAssembly interpreter and we’ve begun preliminary work to integrate this into Py-EVM to implement an EWASM based execution environment for smart contracts.

EthPM

EthPM is now fully integrated in Web3.py v5. ERC 1319 has been updated to include some useful events and functions. A registry explorer was built to provide an interface for interacting with various EthPM Registries. A CLI utility is in the works for downloading EthPM packages to disk.

Remix

We finally released Remix 0.8 which comes with a massive UX redesign and the integration of a more stable version of the remix plugin API. The documentation has been improved, and will continue to be improved with future updates. Check out the 0.8.0 release on Github, updated app and our Medium post.

We are regularly updating https://remix-alpha.ethereum.org with the latest progress!

We’ve also seen the integration of remix-tests and remix-debug in Embark and EtherAtom, started to migrate the remix code base to TypeScript and the long awaited support of the new AST .

From the 0.8 release on, we will be putting in more effort into writing and promoting educational content, first for the Remix stack and then more broadly for the Ethereum ecosystem.

We plan to release patch versions of Remix more regularly now, and to kickstart a Remix website soon.

The desktop version (usable offline) will hopefully land soon (some of the work has already been done with the Grid integration and we need to check how we can merge efforts here).

We will continue to polish the remix-plugin API and improve the dev UX during the next weeks. Now that the base layer is done, we need to leverage decentralized storage for hosting plugins. This will probably take a few months.

Beside that we want to continue writing tutorials, workshops and do the necessary for onboarding beginners.

Research [CBC]

Goals for 2019:

1. Produce liveness proofs for a variety of synchrony assumptions, and for probabilistic and deterministic liveness requirements.

2. Produce a sharding specification by Devcon 5, complete with cross-shard messaging fork choice rule and (possibly) a load balancer.

Work Completed in January-June 2019:

1. Finality Inspector – Stanford Research Workshop, February 2019

• The Finality Inspector is an algorithm that finds the finality score of a given block (weight of validators that need to equivocate in order for the given block to be reverted) by searching for a finality criterion in the message DAG. The algorithm is quite efficient — it runs in polynomial time in the number of total validators.

2. Documentation for Finality Inspector – ETHParis, March 2019

• We made an informational blog post that describes the Finality Inspector and shows an execution of the protocol (for binary consensus) and the level of finality on proposed values.

3. Liveness Strategies – May 2019

• So far we have come up with 3 liveness strategies for the CBC Casper family of protocols.

4. LMD GHOST fork choice algorithms – IC3 Boot Camp, June 2019

• We described an efficient algorithm for maintaining the winning LMD GHOST tip of the blockchain. Upon seeing a new block, it updates the LMD GHOST tip in O(V^2) time (without any additional data stored in blocks), or O(V*log(V)) time (if blocks store a skip list of their ancestor blocks). This algorithm can be also used for executing the LMD GHOST section of the Eth 2.0 fork choice.

Community Outreach in January-June 2019:

1. Vlad @ Stanford Blockchain Conference, February 2019

2. Vlad, Aditya @ ETHCC, March 2019

3. Vitalik, Aditya @ EDCON, April 2019

4. Vlad @ CryptoChicks, June 2019

Research [Plasma]

Shipping an end to end implementation of Plasma provided perspective which was critical in coming up with generalized plasma. This insight came from the fact that our testnet was far too special purpose & realizing we needed the ability to upgrade. We wouldn’t have come to this if we hadn’t been faced with the hard truth that taking our current implementation to production would be severely limited. Instead, a relatively small time investment in a redesign aided in our future proof design.

Announcements from the first part of the year include:

Ongoing work focuses on Production Payments Plasma. In the couple months we will be taking Generalized Plasma into production with a fully audited & scalable payments network. Next steps will be to tackle:

Plapp Plapp.

Research [Serenity]

tldr; it’s happening

Phase 0

The beacon chain has gone through a number of iterative releases, and is largely stable as client teams implement. Much work is targeted toward testing and auditing as we near the end of June Phase 0 spec freeze. There now exist a broad array of consensus test vectors that are being passed by client teams, and there is a now a fuzzing effort underway, fuzzing the python spec and the go spec with the intention of fuzzing clients soon. Runtime Verification has also begun formally specifying the beacon chain in K and formally verifying the Vyper deposit contract.

There are a few single-client testnets with public participation. Over the coming months, we expect to see short-lived, and then long-lived, multi-client public testnets.

Much of the Phase 0 work is now in the client teams’ hands to bring the beacon chain to production. The client to do list includes: consensus tests, optimizations, efficient aggregation, stable p2p networks, state sync, validator UI/UX, security reviews, visualizations tools… Thank (or fund!) your local client team next time you get a chance. They are the unsung heroes in this process and deserve much more support and praise.

Phase 1

The Phase 1 spec on shard data chains is primarily in place and has gone through many simplifications the past few months. Most of these simplifications manifest in the “custody game“, reducing the complexity of computation and the complexity of the challenge games when unavailable data. The custody game is now more multi-party computation friendly to help encourage decentralized staking pools.

Recently Phase 1 was made executable and has been integrated into the spec test suite. This specification is to be iterated upon, simplified, and prototyped in the coming months.

Phase 2

Phase 2 has some exciting research underway. There has been much effort in simplifying and abstracting the execution consensus layer through a new path called “execution environments“. Execution environments open up a world of possibility in how the highly scalable data layer of Eth 2.0 might be used. In particular, it might allow us to slot Eth1 into Eth2 to enable a more seamless transition for the community. Much of the research and debate on Phase 2 is happening on http://ethresear.ch/ so check it out!

Light clients

A light client specification relying upon Phase 1 exists and will be iteratively worked on in the coming quarter. We hope to see a couple of light client implementations being worked on in Q3 or Q4 after the core beacon chain implementations stabilize.

Security [Security / Consensus Tests]

We have performed quite extensive metering of the execution of opcodes within Geth, to provide background and analysis for https://eips.ethereum.org/EIPS/eip-1884, which aims to rebalance opcodes that will otherwise lead to severe degradation of the Ethereum network.

The hive framework has been updated, and is again running on https://hivetests.ethstats.net/, and we have also re-launched a libfuzzer-based geth/parity differential fuzzer in a production environment. We plan to publicly release this fuzzer in the mid-term future.

Retesteth stability has been restored. We’ve also fixed bugs when running StateTests and BlockchainTests via test* RPC interface on aleth. Retesteth could now be built on docker and run against any client that support test* RPC interface. Geth + retesteth support has now been enabled.

Special Projects

• Collaborations with Microsoft to build us a superior Integrated Development Environment, such as the Azure Blockchain Workbench.

• Ether’s Shariah Compliance is completed. Details of the fatwa from Amanie Advisors to be announced. Hopefully, this will bring more users and applications from the Islamic world. Hurray financial inclusion and new markets.

• Launching the Ethereum OASIS Open Project to attempt to battle harden and bring a little more structure to our standards process.

• Launched new wiki: eth.wiki (still a work in progress).

• Working with Santa Fe Institute to develop a cryptoeconomics research program. We recently sent Consensys’s Shruti Appiah to Santa Fe to speak on token economics.

• Explorations into upping Ethereum’s game in the enterprise space. Ergo we’ve been chatting more with Ethereum Enterprise Alliance and Hyperledger. So far Ethereum Foundation has joined both organizations and we’re figuring out plausible next steps.

• Ongoing collaboration explorations with:

  
  

• A lot of new swag on the Ethereum swag store!

Solidity

The current focus points for Solidity development are as follows:

• polishing the ABIEncoderV2 for a non-experimental release,

• increasing the coverage of the SMT checker module,

• work on the Yul Optimizer and code generator from Solidity to Yul (simple contracts like an ERC20 token already work)

• code generation from Yul to eWASM assuming all types or 64 bits wide

• syntactic and semantic fuzz testing of various components

• planning changes for the upcoming breaking release 0.6.0

During the previous weeks, we enabled access to the Yul compiler and optimizer via standard-json. It is also possible to access the Solidity to Yul code generator using the –ir switch. For security reasons, you have to compile this yul code again to bytecode manually. Please try this out but keep in mind that both parts are still experimental! Furthermore, we are adding more checks to the decoder part of the ABIEncoderV2 component that prevents invalid data from getting through the decoding process.

Swarm

Swarm saw significant stability improvements, notably hardening network connectivity code as well as the integration of the new LocalStore with reliable garbage collection. Our devops infrastructure and cluster provisioning graduated and allows testing complex network behaviour in a cluster of up to 1000 nodes.

Improvements in debugging, tracing, metrics and network simulation testing are now complemented by end-to-end smoke tests. Such tests are run regularly on deployments and allow continuous monitoring of performance. Since they closely match actual use, they model user perception and will be used to justify implementation changes or catch regressions.

Release v0.4 recently brought a much more reliable testnet. The 0.4 release now officially introduces ACT (Swarm’s access control module) that enables users to control access to shared content or developers to offer authenticated protected areas/functions of dapps. It will also include improved Swarm Feeds.

We continue restructuring working methods, more principled engineering work, clean code principles.

Swarm now launched a product subteam and consolidated our roadmap adopting a more user-centered MVP approach to milestones.

Other recent updates are captured here: https://github.com/ethersphere/swarm/blob/master/CHANGELOG.md\
Finally, we had the Swarm Orange Summit in Madrid and that was very successful and well received!

Web3.JS

The newly introduced architecture (1.0.0-beta.38) of Web3.js is under active development and is improving day by day. We have implemented the possibility to pass a custom transaction signer, to configure the transaction confirmation workflow, new modules (Admin, TxPool, Miner, Debug), and some new methods for the Eth module (getChainId, requestAccounts, getPendingTransactions). To allow the new architecture to succeed, we’re allowing breaking changes by moving this work to a 2.0-alpha version of Web3.js. Because version 1.0.0-beta.37 is widely used and to allow bug fixes for them, we’ve decided to define beta.37 as 1.0 stable. This gives us the possibility to enable bug fixes for the old architecture of Web3.js while coexisting peacefully with the new and exciting 2.0-alpha architecture.

In Numbers:

1486 commits

244 fixed issues

~135000 lines of code added and ~165000 removed

17 Releases

The next steps of the Web3.js project will be explained in the coming announcement.

Whisper

We are improving compatibility with Parity’s version of Whisper. Our goal is to have a fully compatible WASM version of this, to simplify the usage of Whisper in Dapps.

Some discrepancy between the implementation and the spec has been found by status and has been fixed.

The documentation effort is well underway, and is available in the geth pages repository. The protocol details are to be moved to the Devp2p spec repo.

ZKSnarks Research

We are moving forward with zkrollup implementations, and we’re becoming more confident in using zkp (zero knowledge proofs) to scale arbitrary dapps to millions of users. Our goal is to provide zkrollup as a proof of concept and then start to explore scaling other kinds of dapps in this way.

High level languages are starting to mature which allow developers to build scalable dapps using snarks with less ramp up time. We are excited by these developments and excited to see developer adoption.

On the privacy front, we have built a generic zcash style circuit which can be used for coin mixing, voting, anonymous DAOs, anonymous social media, and in other cool privacy focused areas. Our next deliverable in this direction will be a mixer for erc20 tokens. From there comes the potential for more cool privacy projects like, anonymous journalism and voting.

ZoKrates

Over the last months, we’ve worked to achieve three main goals: to make ZoKrates more efficient, more powerful, and even easier to use.

We introduced support for Elliptic Curve Cryptography in ZoKrates programs and provided primitives leveraging EC cryptography, for example EdDSA verification, to developers. Together with other useful building blocks, these are now available as part of the ZoKrates standard library. This is accompanied by a new Python library called pycrypto which contains application code that makes it easy to interact with provable ZoKrates programs.

To make the most of these building blocks, we’ve improved optimizations for the ZoKrates compiler and started refactoring the module system to better support composition.

We have also specified the ZoKrates DSL grammar formally and are currently working on a more efficient parser implementation based on that specification.

As a step towards our goal of a Rust-only codebase, we added support for Bellman which enabled Mac OS X native builds as well as efficiency gains.

Finally, we extended our documentation (e.g., tutorial on how to proof pre-images of hashes) and released a blogpost which discusses the challenges of using zkSNARKs in dApps. For developer education, we conducted a workshop at the 2nd ZKProof Workshop, Berkeley. Further workshops are taking place in London and Split in June.

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” [tm] 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.

Friends,

As the year of the Merge ends, we wanted to share updates from many of the Ethereum gardeners and EF-supported teams that achieved long sought accomplishments, both big and small, alongside the rest of the ecosystem in 2022. We all have a lot to be thankful for, from the new communities we’ve come to know, to having each other through it all!

As always, this roundup series focuses on EF-supported teams whose members are working to grow and improve Ethereum as a whole. Included in this edition are updates from many teams highlighted in the previous report, and other new and rotating groups.

Enjoy!

Consensus R&D (aka EF Research Team)

Authored by Danny Ryan and Hsiao-Wei Wang

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

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

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

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

• Scheduled and tentative protocol upgrades
  
  1. Withdrawals functionality: this feature will enable stakers to withdraw their balances from the beacon chain to their execution layer accounts. The consensus-layer core specs are nearing completion, and client teams are actively implementing and testing the functionality.
  2. EIP-4844 aka proto-danksharding:

  
  

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

Cryptography Research

Authored by Dankrad Feist

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

Fe-lang

Authored by Grant Wuerker

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

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

Notable language features:

• Low-level intrinsic functions (0.12.0).
• Nested structs in memory (0.13.0).
• Std library with evm and context modules (0.14.0).
• Nested structs in storage (0.14.0).
• const folding (0.14.0).
• Function argument labels (0.15.0).
• Nested structs can be returned and passed into functions (0.19.1).
• Braces! (0.19.1).
• Traits and generic function parameters (0.19.1).
• Enums and match statements (0.20.0).
• mut keyword (0.20.0).

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

Tooling:

• @zjhmale developed a Hardhat plugin.
• A couple contributors developed VS Code plugins:
  
  

Other:

• Yoshi has been working on a compiler backend specialized for smart contracts named Sonatina.
• A few simple contracts were verified using K.

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

Formal Verification

Authored by FV team

hevm

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

SMTChecker

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

Yools

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

PolySolver, a solver for generalized polynomials

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

Geth

Authored by Péter Szilágyi

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

Path-based trie storage

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

TL;DR A small teaser from a while back.

Light clients

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

Shanghai

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

Blob transactions

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

Verkle trees

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

Go-leveldb

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

Built-in transaction tracers

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

Docs & Website

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

Aaand, that’s a wrap

Javascript Team

Authored by Holger Drewes

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

• Introducing native JavaScript BigInt support
• Making larger structural changes such as extracting a “pure” EVM from the historically grown VM package code, and also…
• Preparing the libraries for the Merge.

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

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

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

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

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

And, regarding Ethers: Ethers v6 is just around the corner. Stay tuned for an announcement in the coming weeks! You can catch up on what will be included by watching this YouTube Devcon talk from Richard.

Ipsilon (Execution Environment research)

Authored by Alex Beregszaszi

Last year we finally launched our “website”, where most of our work can be observed. This year we were also active on Twitter.

EIPs

This has been the “Year of EIPs” for Ipsilon. We have worked on and published a large number of them. In order of maturity:

PUSH0 and Initcode metering

EIP-3855: PUSH0 (providing a nice gas improvement) and EIP-3860: Initcode metering (reducing DoS risks) are accepted for the Shanghai upgrade.

EOF

The group of EIPs called EVM Object Format (EOF). This includes EIP-3540, EIP-3670, EIP-4200, EIP-4750 and EIP-5450. The work on EOF started early 2021 and the steps were split, because initially we did not anticipate to launch them together. Today this group, colloquially called “big EOF”, is considered for inclusion in Shanghai (or Cancun).

Twitter had a number of good threads (1 2 3) about EOF, its features and benefits to the ecosystem. To name a few:

• Large gas savings with the reworked control flow system (static jumps provided by RJUMP and RJUMPI).
• Useful new instructions, such as RJUMPV to efficiently handle switch/jump-tables.
• Structured contracts (separation of various code sections and data) makes analysis (both automated and manual) easier, and thus can reduce security risks.
• This structure also allows for validation of contracts at deployment time, which reduces runtime overhead and risks.
• The format is extensible and allows introduction of features, which were not possible until now (an example is EIP-663 and evmmax).

The current work can be followed on the EOF1 Checklist page.

Unlimited SWAP/DUP

Connected to EOF is EIP-663 introducing long awaited swaps and dups accessing greater stack depth — this could remove those feared “Stack too deep” errors Solidity is outputting. This change is proposed for Cancun.

Others

Besides these we worked on a number of other proposals:

• EIP-5000 (in collaboration with Solidity) introduces a MULDIV instruction, which would significantly reduce the cost of fixed point math, a cornerstone of many (DeFi) applications.
• EIP-5656 (in collaboration with Vyper) introduces a MCOPY instruction, which can provide cheap memory copying at a 2-5x reduction in cost compared to today. This also “deprecates” the identity precompile.
• EIP-6046 is our (not very well developed) attempt to solve the “SELFDESTRUCT-problem”.
• evmmax (in collaboration with geth), the continuation of the evm384 project, introduces a small number of instructions, which can be used as building blocks to replace several current and future proposed “precompiles”.

These are not yet proposed for any upgrade, but perhaps some could make it into Cancun.

evmone and fizzy

On the software front, EVMC 10.0.0 and evmone 0.9.0 were released, which support Paris (Merge) and among other changes rearchitect gas accounting of refunds. These releases are used by Silkworm and by Solidity’s testing infrastructure. Accompanying, a number of releases of intx were made, mostly to improve speed of arithmetic operations in evmone.

We have also made a long delayed release of Fizzy v0.8.0, which contains the majority of planned features. This includes built-in runtime metering. The work is paused on Fizzy, for now.

Portal

Authored by Piper Merriam

The Portal Network is a multi team project being led by Piper Merriam that aims to deliver lightweight protocol access for the Ethereum network. Portal Network is a new set of distributed peer-to-peer storage networks that are designed for verifiable storage and retrieval of all of the data that makes up the execution chain and which is required for interacting with the Ethereum network.

The Portal team has been working all year on trin our client for the Portal Network. The Portal Network project as a whole has been quietly working towards building out this entirely new special purpose storage network and is on track to deliver the first version of this new protocol to the Ethereum community during 2023. We are currently focused on delivering the “History” protocol which will provide access to all of the block headers and bodies from the history of the Ethereum execution chain. All of the three independent client implementations have matured this year to fully implement the base functionality needed to launch healthy live networks.

In the last month, we deployed our first version of “Portal Hive”, a “black box” testing tool that verifies the different client implementations are all compliant with the protocol specifications. We also deployed the first iteration of “glados”, our network health monitoring tool which actively audits the network to check the availability of content. These are big milestones for the project, marking the point where we transition into having live networks with real data.

The next few months will see the history network coming online with more and more of the historical data becoming available for retrieval. Our next focus will be on implementing the Beacon chain light protocol and serving the corresponding data. Following that will be the Ethereum State data, the canonical transaction index, and the transaction gossip network.

Privacy & Scaling Explorations

Authored by PSE Team

The PSE team has been hard at work on an ever-expanding list of projects this year. Below is a sample of what PSE team members have been working on – you can find a more complete list of ongoing projects at appliedzkp.org.

We’ve been fascinated with the possibilities of privacy-preserving social applications enabled by a decentralized ecosystem of composable infrastructure. We’ve built and experimented with tools such as:

• Semaphore for creating anonymous identities to interact within customized groups.
• Unirep for private non-repudiable reputation.
• Interep, ZK-Chat for private communication, RLN for anonymous spam protection.
• Crypt-Keeper for ZK identity management and proof generation.
  Proof of concept applications like Zkitter and UniRep Social have let us bring these experiments to life and see how people interact in environments that feel familiar, but operate in fundamentally different ways.

On the scaling front, we’re exploring how succinct proofs can offer improved efficiency in a variety of areas, from gas costs to throughput and even validating Ethereum itself:

• BLSWallet provides components for an L2 smart contract wallet with BLS signatures and aggregated transactions for reduced gas costs.
• Zkopru combines using zk-SNARKs and optimistic rollups for low-cost private transactions on L2.
• The zkEVM Community Edition is one of many zkEVM efforts putting zk-SNARKs to work to make verifying L1 transactions easier and cheaper.

We’ve also broken new ground in anonymous voting and Public Goods funding. We supported several teams adopting MACI (Minimal Anti-Collusion Infrastructure) for customized quadratic voting and quadratic funding rounds. Thanks to help from teams from ESP, Devcon, EcoDev, and more, we’ve supported local leaders in the Ethereum community adopting [zk]Quadratic Funding around the world; each iteration was an opportunity to improve the tools and process, with the goal being more grassroots, privacy-first, quadratic funding operators that create value for their community.

Many team members showcased their work at Devcon VI in Bogotá. Over a dozen PSE projects presented, as well as an all-team effort to organize the Temporary Anonymous Zone community hub, with an accompanying demo app where attendees interact anonymously as part of a Devcon VI Semaphore group.

PSE is a growing community and we invite contributors and experimenters of all kinds! You can follow us on Twitter and Mirror, or join our Discord to get involved.

Protocol Support

Authored by Tim Beiko

The Merge was, by far, the most important thing for Protocol Support to get right in 2022. The team helped with coordination, community awareness and a long list of miscellaneous tasks, from launching bordel.wtf to publishing the Merge Manual. On September 15th, we celebrated Ethereum’s successful transition to proof-of-stake! A few weeks later, we highlighted the work of merge contributors by signing them a song at Devcon.

Since then, we’ve been working on both Shanghai/Capella, which is focused on Beacon Chain withdrawals, as well as the next upgrade, centered around EIP-4844, a.k.a. protodanksharding. This should keep us busy for at least the first half of 2023. The two first things you can expect are devnets (and tutorials!) for Beacon Chain withdrawals, and the launch of the KZG Ceremony, for which we just announced a grants round! For more on these protocol upgrades, see the latest AllCoreDevs update.

Beyond upgrades, the team focused on two other major initiatives in 2022. The first was launching Protocol Guild. The guild, whose design was birthed in a tweet, is a collective of over 120 Ethereum L1 maintainers to which DAOs and individuals can donate as a way of supporting the protocol. Unlike typical grants, focused on organizations, funds sent to PG are routed to individual contributors directly. To test the idea, a one year pilot was launched in May. Six months in, PG has published a mid-pilot update, as well as its plans for 2023. Expect a new, governance-minimized version of PG, deployed to both L1 & L2s, with a much longer vesting period.

The second big initiative PS undertook was (re)launching the Ethereum Protocol Fellowship (f.k.a. Core Dev Apprenticeship Program, or CDAP). EPF provides participants with stipends and mentorship to allow them to dive deep in the “core dev” rabbit hole with the goal of onboarding proficient contributors to client and research teams. This third cohort has over 20 participants, including a handful that participate permissionless-ly, working on various projects including MEV, light clients, account abstraction and sharding. Once it wraps up, around ETHDenver, we’ll take time to reflect on how it went and how it can be improved. We expect to run another cohort that will begin over the summer.

Last but not least, contributors to the Ethereum Execution Layer Specification, a.k.a. EELS, have recently joined the PS team. The work on EELS will provide Ethereum’s EL with a more accessible spec, from which it’s easy to generate test vectors. It’s also a significant step in aligning how changes are specified across the execution and consensus layer, given the latter already has a similar spec. If you were thinking of writing an EIP, it’s worth giving EELS a look as well — it might be easier to use a Python diff than reimplementing a large chunk of Ethereum in markdown pseudocode!

Remix

Authored by Rob Stupay and Yann Levreau

IDE Updates:

We began the year at v0.21.0 and have just released v0.29.0. For all the details about what has been updated on the IDE please check our end of year article.

Process

The Remix team has been integrating User Centered Design methodologies into our workflow. We’ve sought user feedback through our “Ask Remix Anything” calls, individual user interviews, from our support channels and through social media outreach. We’ve also incorporated beta testers into our release process. These new channels of feedback have been very helpful.

Dogfooding

We dogfooded the IDE on a few projects. At ETHDenver we hacked a token-curated, upgradable playlist and song minting dApp for Rocky Mountain Public Media. Then we developed Remix Rewards, an ongoing program to reward Remix contributors, beta testers, and UX research participants with NFT badges. Finally, we created Remix Challenges, quizzes that use ZK proofs. We then began using the Remix Challenge quizzes in our workshops; they make an excellent demo project for introducing Remix’s capabilities. Through using Remix in all of these demo projects, we were able to find some areas where we could improve the tool and then… we did.

Workshops & Talks

Throughout 2022, Remix team members gave workshops and talks at: ETHDenver, Devconnect, Solidity Summit, Kuala Lumpur Ethereum Meetup, EthCC, SmartCon, EThSafari, Devcon (one of which was in Spanish), ETHVietnam, and ETHIndia.

A preview of 2023

Here are some highlights from our 2023 Roadmap:

• Improving Remix’s performance with a slow internet connection
• Improving Remix’s overall performance
• Remix for “low code” use cases
• Adding new features and building requested features
• Giving more workshops

Robust Incentives Group

Authored by Barnabé Monnot

This year, our team participated in multiple conversations on the economics of Ethereum with industry partners as well as academic grantees and collaborators. We organized ETHconomics in April during Devconnect, a gathering of industry researchers and academics who discussed all facets of protocol economics for the Ethereum base layer and rollups. In December, we co-organized the first Columbia Cryptoeconomics Workshop. We also recently released RIG Open Problems, an initiative to decentralize our research process.

Among other works and talks listed on our homepage, here are other topics that kept us busy this year:

Snake Charmers [Python Ecosystem]

Authored by Keri Clowes

In 2022, we made many exciting changes across our libraries. We released our first beta versions of web3.py v6, which opened the door for many long-awaited breaking changes throughout our stack. Those breaking changes included:

• Streamlining the eth-abi API
• Dropping support for deprecated Python versions (3.5 and 3.6)
• Deprecating camelCase syntax in favor of snake_case (and lots more)

Of particular note, robust asynchronous support is now available via the AsyncHTTPProvider. A full list of changes to web3.py can be found on the release notes page of the documentation.

The middle of the year brought us The Merge and so eth-tester, web3.py, and py-EVM all got updates to support the Paris hard fork. Additionally, we shipped some new features to our ENS module, including support for ENSIP-10 and the Cross-Chain Interoperability Protocol.

We’ve also been focused on making web3.py as extensible as possible, so we added APIs for custom modules and methods. This enables users to easily handle non-standard JSON-RPC methods, or even add a full L2 API. We’ve also spent time modernizing our libraries this year, including adding support for Python 3.10 and 3.11, and modernizing our release processes.

We put an emphasis on developer relations this year, as Marc continues to prioritize educational content mainly focused on web3.py patterns and internals, geared at a wide range of developer abilities. These blog posts at snakecharmers.ethereum.org.

He also spoke at Devcon VI and at the inaugural Pychain conference.

We launched a developer survey to gain insight into the types of users that we have, and the ways in which they use web3.py and our supporting libraries. Participate in the survey here.

In 2023, our team plans to:

• Refine the asynchronous providers in web3.py, and release a stable web3.py v6.
• Implement changes to our stack of libraries to support the Shanghai and other network upgrades that follow in 2023, including changes to clients and smart contract languages.
• Integrate the user feedback gained from the survey and other feedback channels into our roadmap.
• Continue to prioritize users by producing educational blog posts, and presenting at various events.

Security [Security / Consensus Tests]

Authored by Fredrik Svantes

We started this year with the clear objective to make The Merge a success from a security perspective, so in the first half of the year and up until The Merge, our efforts were primarily aimed towards testing and improving security wherever possible in the protocol and clients. At The Merge, no major issues were spotted and everything appeared to go very smoothly.

During this year we have worked on many things leading up to and beyond The Merge. Some of our work started with a merge threat assessment, and has been related to fuzzing using tools such as Antithesis, Nosy Neighbor, Beacon Fuzz, Engine API Fuzzer, EL fuzzers and other fuzzers.

We have also manually audited clients, libp2p, L2s, Bridges, validator appliances, mev, worked with external auditing companies for some audits, researched ways to reduce DDoS risks of validators, and more.
One of the perhaps more publicly seen improvements was our significantly increased bounties (4x), but we have also released tools such as Nosy Neighbor and Secure Drop.

The security team also closely worked with the protocol support team and the client teams in a weekly merge testing call and has been running its own validators for the testnets.

Lastly, the team has given several talks and published several posts about security, such as

Continue keeping an eye out for our “Secured” blog posts if you want to learn more about what we’re up to.

In 2023, the team will focus on:

• Internal security audits of Capella/Shanghai
• Further improving our testing capabilities
• Coordinating an external security audit of Account Abstraction
• Coordinating and communicating vulnerability reports through the Bounty program
• Internal manual spec and client audits
• Running and improving fuzzing infrastructure
• Internal security audits of Layer 2/Bridges
• Holding client security calls to further collaborate on security
• Coordinating external security audits

Solidity

Authored by Franziska Heintel

Throughout 2022, we published 6 Solidity releases with the following highlights:

Besides the ongoing work on the compiler and language, we also engaged with the ecosystem:

• We organized the Underhanded Solidity Contest 2022, which was a great success. The goal of the ontest is to write seemingly innocent and straightforward-looking Solidity code that actually contains malicious behavior or backdoors. Check out the Board of Fame for all winning submissions!
• In April, we hosted the Solidity Summit, a one-day conference, as part of Devconnect in Amsterdam. The Solidity Summit is a collaborative event focusing on the future of Solidity. Find a recap of the event with full agenda and links to all talk recordings here.

If you want to get up to speed with recent Solidity developments, here is a selection of talks the Solidity core team members gave in 2022:

In December, we shared “Solidity Core Team Updates” on the Solidity blog, summarizing the most important events in the core team.

Last but not least: The Solidity Developer Survey 2022 launched on December 7! If you are a Solidity developer, please support us by providing your insights and take 10 minutes to take part in the survey here. The survey closes on January 7, 2023.

ZoKrates

Authored by Thibaut Schaeffer

2022 was a good year for ZoKrates:

• It started with the implementation of a Solidity verifier for the Marlin proving scheme by Nirvan Tyagi, a great first contribution to the project.
• A lot of new functionality was added to the language throughout the year, such as shadowing of variables, a wider range of complex types, as well as easier conversion tools between numeric types.
• In the summer, ZoKrates was upgraded to a more modern syntax. No more endif and other vintage language constructs.
• The rest of the year was spent focusing on the introduction of assembly blocks to ZoKrates. Historically known for being higher level, ZoKrates will very soon give developers the power (and responsibility) to write low-level constraints by hand.
• Finally, Georg Wiese wrote an integration of ZoKrates with a variant of the Plonk proof system, which is also being finalized.

The ZoKrates team is looking forward to welcoming more developers in the ZK world in 2023!