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.

The Ethereum Foundation (EF) merged its protocol research and development units under a single banner, called Protocol, on June 2.

The new initiative focuses resources on three technical priorities: scaling the base layer, expanding blob capacity for layer-2 networks, and enhancing the user experience.

The three-track plan

Protocol will steer code writers, researchers, and project coordinators toward a shared roadmap that treats those priorities as the sole benchmarks for funding and staffing. 

Tim Beiko and Ansgar Dietrichs will guide work on the base-layer scale, Alex Stokes and Francesco D’Amato will oversee layer-2 throughput and blob design, and Barnabé Monnot and Josh Rudolf will direct user-experience projects. Additionally, Dankrad Feist will advise each track.

The foundation framed the restructure as a response to rapid progress in zkEVM rollups, hardened layer-2 systems, and broader demand for Ethereum as a settlement engine. 

By grouping teams under a single roof, Protocol intends to shorten the path from research papers to production code and to create tighter feedback loops across client, cryptography, and interface efforts.

Leaner teams and clear accountability

Protocol now operates with fewer staff members. The foundation confirmed that some researchers and engineers departed during the reorganization and encouraged other Ethereum companies to recruit them. 

Team leads carry explicit responsibility for code quality and peer review, and they must demonstrate measurable progress on the three priorities at regular checkpoints. 

The new structure also adjusts Ethereum’s internal governance forums. Protocol will rework meeting schedules and propose new venues for community input on hard-fork timing, security reviews, and blob pricing policy. 

Foundation managers said the goal is to translate on-chain signals and developer feedback into releases without drift.

Protocol opened searches for a user-experience lead and a performance-engineering lead while inviting additional applicants with expertise in kernel-level or cryptography. 

The group plans joint workshops with external client teams and layer-2 builders to refine execution-layer changes and blob-compression techniques before the next network upgrade.

Protocol begins operating under the new framework immediately.

Mentioned in this article

Over the past year, the Ethereum Foundation has significantly grown its team of dedicated security researchers and engineers. Members have joined from a variety of backgrounds ranging from cryptography, security architecture, risk management, exploit development as well as having worked on red and blue teams. The members come from different fields and have worked on securing everything from the internet services we all depend on each day, to national healthcare systems and central banks.

As The Merge approaches, a lot of effort from the team is spent analyzing, auditing and researching the Consensus Layer in various ways as well as The Merge itself. A sample of the work is found below.

Client Implementation Audits

Team members audit the various client implementations with a variety of tools and techniques.

Automated Scans

Automated scans for codebases aim to catch low hanging fruit such as dependency vulnerabilities (and potential vulnerabilities) or improvement areas in code. Some of the tools being used for static analysis are CodeQL, semgrep, ErrorProne and Nosy.

As there are many different languages used between the clients, we use both generic and language specific scanners for the codebases and images. These are interconnected through a system that analyzes and reports new findings from all tools into relevant channels. These automated scans make it possible to quickly get reports about issues that potential adversaries are likely to easily find, thus increasing the chance of fixing issues before they can be exploited.

Manual Audits

Manual audits of components of the stack are also an important technique. These efforts include auditing critical shared dependencies (BLS), libp2p, new functionality in hardforks (eg. sync committees in Altair), a thorough audit into a specific client implementation, or auditing L2s and bridges.

Additionally, when vulnerabilities are reported via the Ethereum Bug Bounty Program, researchers can cross-check issues against all clients to see if they are also affected by the reported issue.

Third Party Audits

At times, third party firms are engaged to audit various components. Third party audits are used to get external eyes on new clients, updated protocol specifications, upcoming network upgrades, or anything else deemed high-value.

During third party audits, software developers and our team’s security researchers collaborate with the auditors to educate and assist throughout.

Fuzzing

There are many ongoing fuzzing efforts led by our security researchers, members of client teams, as well as contributors in the ecosystem. The majority of tooling is open source and runs on dedicated infrastructure. The fuzzers target critical attack surfaces such as RPC handlers, state transition and fork-choice implementations, etc. Additional efforts include Nosy Neighbor (AST based auto fuzz harness generation) which is CI based and built off of the Go Parser library.

Network level simulation and testing

Our team’s security researchers build and utilize tools to simulate, test, and attack controlled network environmets. These tools can quickly spin up local and external testnets (“attacknets”) running under various configurations to test exotic scenarios that clients must be hardened against (eg. DDOS, peer segregation, network degradation).

Attacknets provide an efficient and safe environment to quickly test different ideas/attacks in a private setting. Private attacknets cannot be monitored by potential adversaries and allow us to break things without disrupting the user experience of public testnets. In these environments, we regularly utilize disruptive techniques such as thread pausing and network partitioning to further expand the scenarios.

Client and Infrastucture Diversity Research

Client and infrastructure diversity has received a lot of attention from the community. We have tools in place to monitor the diversity from a client, OS, ISP and crawler statistics. Additionally we analyze network participation rates, attestation timing anomalies and general network health. This information is shared across multiple locations to highlight any potential risks.

Bug Bounty Program

The EF currently hosts two bug bounty programs; one targeting the Execution Layer and another targeting the Consensus Layer. Members of the security team monitor incoming reports, work to verify their accuracy and impact, and then cross-check any issues against other clients. Recently, we published a disclosure of all previously reported vulnerabilities.

Soon, these two programs will be merged into one, the general platform will be improved, and additional rewards will be provided for bounty hunters. Stay tuned for more information on this soon!

Operational Security

Operational Security encompasses many efforts at the EF. For example, asset monitoring has been setup which continually monitor infrastructure and domains for known vulnerabilities.

Ethereum Network Monitoring

A new Ethereum network monitoring system is being developed. This system works similar to a SIEM and is built to listen to and monitor the Ethereum network for pre-configured detection rules as well as dynamic anomaly detection that scans for outlier events. Once in place, this system will provide early warnings about network disruptions in progress or coming up.

Threat Analysis

Our team conducted a threat analysis focuse on The Merge to identify areas that can improved with respect to security. Within this work, we collected and audited security practices for Code Reviews, Infrastructure Security, Developer Security, Build Security (DAST, SCA and SAST built into CI, etc.), Repository Security, and more from the client teams. Additionally this analysis surveyed how to prevent misinformation, from which disasters may strike, and how the community might recover in various scenrios. Some efforts related to disaster recovery exercises are also of interest.

Ethereum Client Security Group

As The Merge approaches, we formed a security group that consists of members of client teams working on both the Execution Layer and the Consensus Layer. This group will meet regularly to discuss matters related to security such as vulnerabilities, incidents, best practices, on-going security work, suggestions, etc.

Incident Response

Blue Team efforts help bridge the gap between the Execution Layer and the Consensus Layer as The Merge moves closer. War rooms for incident response has worked well in the past where chats would spring up with relevant people during incidents, but with The Merge comes new complexity. Further work is being done to (for example) share tooling, create additional debug and triage capabilities and create documentation.

Thank you and get involved

These are some of the efforts currently taking place in various forms, and we’re looking forward to share even more with you in the future!

If you think you’ve found a security vulnerability or any bug, please submit a bug report to the execution layer or consensus layer bug bounty programs!

May 15 is Global Accessibility Awareness Day, and Apple always uses the occasion to highlight some of the new accessibility features coming to iPhones and Macs. This year, Apple’s got another announcement to share: three new Sound Therapy playlists on Apple Music available now.

The South Therapy experience consists of three playlists—Focus, Relax, and Sleep—that play music from UMG artists including Imagine Dragons, Katy Perry, Kacey Musgraves, and others. The songs are special versions, often extended, instrumental, or rearranged to be more soothing. Those songs are then blended seamlessly with specific sound waves that are said to help you get into a particular mental state.

Gamma waves and white noise are supposed to help with focus, theta waves are to help you relax, and delta waves and pink noise are said to help you sleep.

Apple has partnered with Universal Music Group and its music therapy science project, the Sollos initiative, on the feature. Apple’s press release says the feature is “Backed by scientific research and powered by UMG’s proprietary audio technologies,” but the science here is not by any means conclusive. Apple uses words like “could” and “might” in its press release whenever making a claim of effect, and includes a footnote that the feature is designed to “support a person’s overall wellbeing” rather than treat any specific medical condition.

Similar claims have been made about similar therapies, such as “binaural beats,” for years, but research into the effects is often criticized for its lack of rigor or for making grandiose claims not supported by the evidence. Critics often point out that such therapies, when properly studied, show results no better than a placebo, or no better than using any other regular sounds to block out bothersome background noise.

Still, there’s no harm in it, and it’s a new feature included with your existing Apple Music subscription. Regardless of whether there are special sound waves helping you achieve the focus or sleep you desire, you can give the playlists a listen the next time you can’t focus, relax, or sleep, and see if they work for you.