“`html
Greetings from London! This is a thrilling moment for the Ethereum ecosystem, and the momentum will only accelerate further as we near Altair [1] [2] and the Merge in the upcoming months.
The Beacon Chain currently has over 6.5 million Ether staked, with more than 200K active validators operating across five clients, and the network is now burning Ether as part of the modifications introduced with the London upgrade.
As always, significant advancements are being made by EF-supported initiatives and teams that contribute to enhancing our Ethereum experience. This roundup series provides a chance to showcase their endeavors aimed at expanding and refining Ethereum as a whole. Featured in this edition are updates from several teams spotlighted in the preceding Supported Teams update, among others.
Enjoy!
Ecosystem Support Program
Written by ESP Team
Office hours
Path to Devcon Grants
We are partnering with the Devcon team on a round of small grants and additional support for community event organizers. Organizers of both virtual and in-person events can directly apply for grants ranging from $500-1500 to cover expenses such as venue or equipment rental, promotional items, snacks, or other incidental costs. Discover more and apply here. Lee esta página en español; 用中文阅读本页.
We also recently revealed our Q1 Allocation Update, detailing 47 grants awarded in Q1 amounting to $5,341,000.
Eth2 Research
Aside from the material featured in Danny Ryan’s Finalized series, the research team has continued exploring areas such as stateless research, proofs of custody for EVM execution, sharding specifications and prototypes, and various other scaling/security research. Most of their advancements can be found in posts on ethresear.ch.
Additionally, find a selection of their recent posts and other content below:
Ethereum.org
Written by Sam Richards
To enhance accessibility and encourage more community involvement, our team shares an overview of our quarterly roadmap objectives. View last quarter’s roadmap here: #2849.
Salutations fellow Ethereans!
Wishing you a fantastic L2 summer 😎 (or winter for our counterparts in the southern hemisphere)! Hope you’re enjoying your journey in this realm – we certainly are! As always, our mission with ethereum.org is to establish the premier portal for Ethereum’s expanding community, serving as the welcoming gateway to Ethereum for millions of new visitors each month.
Content updates
In Q3 our ethereum.org product focus will be to match the astonishing progress in the field, enabling our wider community to stay updated on advancements in Ethereum network upgrades, Layer 2 initiatives, developer tools, user applications, and beyond.
Thank you to the numerous individuals who have contributed content to date ❤️
CLR funding round for Eth2 projects
Innovative funding methods for public goods offer tremendous potential for the Ethereum ecosystem and beyond the crypto world. Although not directly linked to ethereum.org, our team is part of the Ethereum Foundation, one of the largest funders of grants and public goods within the ecosystem. We are eager to enhance the cultural momentum surrounding ecosystem funding for public goods as well as experiment with allocation mechanisms for ecosystem support.
We’ll continue our initiatives from Q2 with teams in the sector, aiming to introduce a CLR.fund round for Eth2 projects on an L2 mainnet by the conclusion of Q3.
This endeavor will also permit our team to stay abreast of the latest tools, technologies, and best practices associated with dapp development, ranging from testing and deployment tools to identity solutions and Layer 2 technologies. We plan to integrate these first-hand insights back into our developer resources.
Discover more, stay informed & get involved
Translation Program
Owing to our over 1,400 volunteer translators over recent years, ethereum.org now accommodates 35 languages! Yet as the website has expanded & is continuously refreshed to remain aligned with developments in the space, many of our languages
“`have become a bit outdated. We will be making an effort in Q3 to refresh over 20 of our translations to align with the latest versions of our website content.
With the addition of our new Translation Program Lead, @lukassim, we also intend to enhance our support documentation and optimize our use of translation tools to elevate consistency and quality throughout the translation process.
As evident from all the objectives outlined above, our achievements are fueled by our open-source community of contributors. Contributors come in various forms—translators, developers, writers, designers, professionals, and enthusiasts. We aspire to continue educating and empowering individuals eager to engage with the Ethereum ecosystem and our ethereum.org community.
Our new Community Lead, @minimalsm, will spearhead initiatives to support and uplift our expanding ethereum.org community. Stay tuned for the specific projects we plan to launch this quarter!
Have suggestions? Connect with us on our Discord server or here on GitHub.
What do you think of that?
We value input on our roadmap. Our guiding principles focus on delivering maximum value in the least amount of time, so if you have thoughts on what we should prioritize, please share! We welcome suggestions and PRs from any member of the community.
Further details on contributing
Ipsilon (formerly Ewasm)
Written by Alex Beregszaszi
The Ewasm team has undergone a rebranding to a new name: Ipsilon. This name references the state transition function outlined in the Yellow Paper. We wish to convey that our efforts have long encompassed more than just Ewasm.
The primary focus of the team is the execution environment / engine of Ethereum (also known as the EVM or any forthcoming versions or alternatives). We conduct analysis and implementation of both our own and third-party proposals (i.e., new EIPs advocating changes to the EVM), provide tools (evmc, evmone, fizzy), and assist existing teams (e.g., Solidity, go-ethereum, Silkworm) with implementation and analysis.
Most of our content is available here.
EVM Object Format (EOF)
In the previous update we mentioned the EVM Object Format (EOF) as an upcoming proposal. Significant progress has been made in the past three months. The initial step, EIP-3541, has been integrated into the London update—this only reserves a starting byte which can be utilized to incorporate EOF in a future protocol update.
A concrete proposal, EIP-3540, which presents the container format and code-and-data separation has been unveiled. Additionally, an explanatory document providing background and a roadmap (which will be updated as we progress) has been issued, and we also conducted a PEEPanEIP presentation (video and slides).
Both EIP-3541 and EIP-3540 have been executed in geth and evmone.
Lastly, we presented a brief proposal to modernize EIP-2938 using EOF and other teams exploring development on EOF.
Address Space Extension (ASE)
The second major topic on our agenda has been the address space extension, a necessity for the state expiry roadmap.
It was initially outlined in an Ethereum Magicians post and various discussions on the Eth R&D discord. Our specification builds upon all existing work and strives to provide a cohesive overview of how to execute this modification. An additional document detailing a comprehensive set of test scenarios has also been published.
While the essence of the proposal is not overly complex, there are numerous implications. This discussion document serves as the foundation for the ongoing Address Space Extension Working Group, which has already conducted three calls (recordings: “`html
#1, #2, and #3).
Additional research
Regarding the subject of code merkleization / code chunking, we published an extensive evaluation of the implications of code chunking expenses. The updated version of the verkle tree proposition reassessed costs informed by these findings.
The concept of an MCOPY instruction was inspired by the investigations on EVM384. We released a brief overview outlining this proposal, including a price estimation, and assessing the advantages for standard contracts apart from its application in EVM384.
EVMC
- 8.0.0 release
- Berlin support, new callbacks to refresh global account/storage accessed list.
- 9.0.0 release
- London support and block_base_fee incorporated into transaction context
- evmc run with –bench
evmone
- 0.7.0 release
- Berlin support
- Enhancements in Baseline interpreter’s jumpdest analysis
- Upgrades to the C++ API
- 0.8.0 release
- London support and BASEFEE instruction implementation
- Instruction tracing according to EIP-3155 format added to Baseline interpreter
- Ability to tally the number of executed instructions in Baseline interpreter
- Further optimizations in Baseline interpreter and in intx and ethash libraries.
- Enhancements to benchmarking utilities
Formal Verification
The Formal Verification Team will share their own updates (relating to Act, hevm, SMTChecker and more) here, and in recent months, various notes have also shown enhancements.
Act
- SMT backend overhaul
- Well-formatted counterexamples
hevm
- Testing invariants
- Berlin support
- Solidity 0.8 support
- Symbolic constructor parameters
- Sourcemap support for Solidity immutables
SMTChecker
- Support for Solidity free functions/constants
- External calls to known code
- Trusted mode
- Report contract invariants to the user
Geth
authored by Felix Lange
In Q2, we released four updates of Geth. The team was primarily focused on executing the London fork modifications, particularly EIP-1559. Additionally, we performed extensive testing of the new snap sync, which is now activated by default in Geth.
As is customary, ensure to retrieve the latest version of Geth!
Javascript Team
Authored by Holger Drewes
In Q2, we substantially expanded our team with three new members joining to focus on the EthereumJS libraries – Andrew, Emmett, and Gabriel. Our efforts concentrated mainly on preparing EIP-1559 for release and generally ensuring our libraries were ready for the London HF. The most recent series of releases (VM v5.5.0, Tx v3.3.0, among others) from early July now includes finalized London support encompassing all hardfork block numbers and is primed to transmit EIP-1559 style transactions over the wire.
The update to the 1559 transaction library incorporated numerous community suggestions and feedback, and we took this opportunity to assess the usability of the library closely. As a result, we improved much of the documentation and instituted several significant usability enhancements, which should make the library more user-friendly. We also aligned with the recent broader trend of Ethereum activity shifting
“`to side chains and L2, and our transaction library is now more equipped to send transactions to networks such as Arbitrum, Polygon, or xDaiChain. For further information, please refer to the tx README.
And it’s worth mentioning this once more: although the release itself occurred some time ago (late April), extensive live testing throughout our EthereumJS client development has led to the devp2p library finally being ready for use in production. We are excited to explore your use cases while delving deeper into the Ethereum devp2p networking stack.
Looking ahead: we have recently combined our initial PR on “The Merge,” enabling our client some initial interaction with an Eth 2.0 PoS client via RPC. This is expected to be followed by significant additional work, which will become a primary focus for the upcoming quarter.
Privacy & Scaling Investigations
Authored by Thore Hildebrandt
The Privacy & Scaling Investigations team aims to connect advanced research in zero-knowledge proofs with application development on Ethereum.
zkEVM
The objective of zkEVM is to execute smart contracts within a zk-rollup. Unfortunately, the EVM was not crafted to operate in a zk circuit, which presents a challenge. Initiatives like zksync approach this issue by recompiling to an alternative virtual machine. Our intention is to incorporate the entire set of EVM opcodes directly into zk circuits so that a smart contract deployed on L1 can seamlessly transition to L2 with minimal alterations. This will ensure complete compatibility with existing tools and enable us to utilize the EVM insights that the ecosystem has developed over preceding years.
Over the last few months, we have assembled a team, resolved many of the challenging research issues, and are in the midst of designing and constructing the initial prototypes.
We have outlined two snarks to verify the validity of EVM computations: a state proof and an EVM proof. The former safeguards the read-write consistency of the stack, memory, and storage, while the latter confirms execution integrity of opcodes.
We have defined a method for performing common arithmetic on 256-bit words within the circuit. Basic EVM opcodes have been specified and are in the implementation phase. Test cases for observing EVM execution have been established, and we are currently developing a protocol for cross-contract message calls.
Perpetual Powers of Tau
In September 2019, we initiated the Perpetual Powers of Tau ceremony (PPOT). The purpose of PPOT is to support the zero-knowledge ecosystem, particularly zk-SNARK projects established on Ethereum, by partially alleviating the demands of trusted setup ceremonies. Numerous zk-SNARK initiatives necessitate two phases of parameter generation, and PPOT replaces the initial phase, which can be utilized by all circuits. Individual teams can select any contribution from the ceremony to develop their own phase-2 setup.
This ceremony accommodates circuits with up to 2 ^ 28 constraints, meaning each contribution necessitates a 97G download, a single day of computation, and a 49G upload. As of this writing, we have accumulated 71 contributions, and all contribution files are available for download and can be independently verified against a public ceremony transcript.
Projects intending to utilize or that have utilized the ceremony consist of tornado.cash, Semaphore, Hermez, MACI, and zkopru. The simplest way to contribute is to contact Wei Jie via Telegram @weijiek. Tune into this podcast to hear Wei Jie discuss the ceremony.
MPC Phase 2 UI
The objective of a trusted setup is to securely generate zk-SNARK parameters. Provided that at least one party in the ceremony acts honestly and remains uncompromised, the entire setup is reliable. The computation can be divided into two phases. In the initial phase (see Perpetual Powers of Tau), participants continuously produce powers of a secret (tau). In the second phase, participants take the output from the first phase and apply it to a specific circuit. Projects that aim to carry out a trusted setup can diminish their workload as only the (circuit-specific) second phase is required.
Our ambition with the MPC Phase 2 UI project was to facilitate an easy, user-friendly public phase 2 trusted setup for projects without requiring them to develop their own infrastructure. We successfully conducted a ceremony for zkopru using the first version of the UI and incorporated experiences from this process in the most recent release. If you wish to learn more, please check out the repository and join our Telegram channel.
Hubble
Optimistic Rollups (OR) enable enhancedlayer 2 scalability through the utilization of on-chain data accessibility and fraud proofs. Hubble enables the development of optimistic rollup chains with a consistent interface, allowing users to enter the rollup ecosystem once and seamlessly transition between chains with minimal costs, effectively eliminating the need to “exit” the low-cost rollup environment.
Key characteristics encompass mass migrations and a worldwide account registry. Burn auctions will be implemented to decentralize the coordinator and to allocate MEV to CLR’s. Transfers to fresh accounts can be executed directly from L2 without the necessity to deposit on L1. With the aid of BLS signatures, the team accomplished ~2700 tps. The Hubble BLS wallet aspires to accommodate additional OR’s like Arbitrum, Optimism, and Fuel.
Hubble’s code is accessible on Github. We have a stable devnet operational, having finalized database tasks and multi-token transaction pool. The upcoming step involves refining clients, with a testnet launch aimed for the near future.
Zkopru
Zkopru (zk-optimistic-rollup) serves as a layer-2 scaling solution for confidential transactions through zk-SNARK and optimistic rollup technology. It facilitates private transfers and atomic swaps within the layer-2 network among ETH, ERC20, and ERC721 at a low cost. Additionally, it offers immediate withdrawals featuring pay-in-advance options and compliance compatibility through spending keys and viewing keys. Wanseob demonstrated the system at the zk-summit.
We have successfully completed a trusted setup for the initiative (one of the largest ever conducted). Furthermore, we finalized an audit with Least Authority and are undergoing a second audit. Within the next couple of weeks we anticipate launching Zkopru on the public testnet, and, if everything proceeds smoothly, also on the mainnet. Stay tuned for updates via our medium blog and join the telegram group.
Blind Find
Blind Find is a peer-to-peer network enabling users to locate others without disclosing their identity. After a successful search, users can verify the existence of the search path within the network through an MPC-based construction, without revealing the path itself. The v1.5 search protocol is now operational.
For the upcoming edition of Blind Find, we are shifting our focus to develop a privacy-preserving reputation system in a peer-to-peer network, based on EigenTrust. To find out more and engage in discussions, please join the telegram group.
Unirep & Unirep Social
UniRep is a confidential and non-repudiable reputation system. Users have the ability to receive both positive and negative reputation from validators and voluntarily prove they possess a minimum level of reputation without disclosing the exact amount. Additionally, users cannot decline to accept reputation from a validator. We are utilizing Unire to construct Unirep Social: a reddit-like platform that permits users to privately amass karma.
We have finalized the core functionalities in Unirep and Unirep Social, and have commenced building and designing the Unirep Social frontend. Future steps include establishing a website and deploying Unirep on the testnet.
Join the telegram channel to discover more and engage in discussions!
BLS Sig Aggregation
The initiative seeks to enhance layer 2 transaction expenses through a smart contract wallet. Smart contract wallets provide users with additional security mechanisms independent of any wallet user interface they may utilize, yet deploying (and using) them on Ethereum’s layer 1 is costly. Layer 2 solutions such as Optimism and Arbitrum significantly reduce this cost barrier, enabling additional users to take advantage of smart contract wallets. This majorly results from these being general-purpose computational solutions. DApps transitioned to layer 2 will be more efficient than those confined to layer 1 due to quicker transactions at lower costs, in addition to further gas savings for both DApps and users. We utilize BLS signatures to decrease on-chain storage, potentially increasing throughput to ~3000 tps. You can monitor the project’s current progress on Github. The next steps involve deploying to optimistic-kovan and assessing gas costs/estimation alongside social recovery functionality.
CLR.fund for Everyone
The objective of the project is to facilitate any community in conducting their own CLR round using clr.fund. We have paused some pending tasks to concentrate on a clr.fund instance for cryptorelief. We encountered some scaling limits with that instance, thus redirected our focus to upgrading clr.fund’s core contracts to incorporate new x32 MACI circuits and MACI 0.9.4. Part of clr.fund-deployer’s commitment is to facilitate the seamless rollout of the clr.fund application, which drove our participation in recent efforts to merge selected features from the ETH2 clr.fund instance’s app into the primary clr.fund front end.
Our next focus is to organize trusted ceremonies for the new x32 circuits, finalize the clr.fund subgraph, and initiate the next round of“`html
clr.fund. Explore the initiative on Github.
InterRep
Reputation serves as the foundation of trust. Individuals invest years in cultivating their reputation on centralized social platforms, yet they must start from scratch when they switch to a different application. InterRep seeks to render reputation transferable, thereby amplifying the compounding advantages of dependable human interactions across the internet. Explore this article for the initial announcement. We are in the process of developing the project’s next phase.
Research
Rollup Diff Compression
We have examined how the data footprint of a rollup can be further minimized for the airdrop scenario. We used Reddit’s airdrop as a reference. Check our article for additional details.
EVM Rollup Reviews
We are executing a series of security evaluations on EVM Optimistic rollups, starting with Optimism. The review is now complete and will be accessible shortly; in the meantime, we have published this descriptive article about the system. The review for Arbitrum is currently underway.
MACI
Initially suggested by Vitalik Buterin in an ethresear.ch article, frameworks constructed with MACI complicate collusion among participants while maintaining the advantages of censorship resistance and accurate execution provided by smart contracts. Although MACI can offer collusion resistance only if the coordinator acts honestly, an untrustworthy coordinator cannot censor nor interfere with its execution. Watch Wei Jie describe how MACI functions on Youtube. You can utilize the MACI command-line interface to conduct a demonstration.
The team has reached a significant milestone (version 1.0 of the smart contracts and zero-knowledge circuits), and we are finalizing comprehensive test suites. Additionally, we have begun collaborating with an auditor to challenge the security and functional assumptions of the framework. We are still closely partnering with the EF team working on an ETH2 funding round and a Covid relief funding round. Furthermore, we have initiated development on an extra feature that enables negative voting.
Join the Telegram group to discover more and participate in discussions.
Remix
Written by Rob Stupay
During Q2, Remix focused on enhancing its ability to collaborate with other tools within the ecosystem.
Discover more in our article.
Snake Charmers [Python Ecosystem: PyEVM/Trinity/Web3.py/Fe]
Fe-lang
Written by Grant Wuerker
Previously, Fe development concentrated on facilitating the necessary features to compile specific demo contracts, with the most developed demo being the Uniswap V2 core contracts. In Q2 of 2021, the development focus shifted from demos to preparing for a release that can be safely utilized in production (i.e., MVP release). We intend to produce an MVP release by the year’s end.
Below are some notable development progress from Q2:
- Four additional alpha releases (0.4.0 – 0.6.1).
- Incorporated Rust-style diagnostic messages.
- Enhanced runtime checks.
- ABI data validation
- Arithmetic overflow checks
- Introduced support for custom error types and panic codes following Solidity.
- Resolved bugs identified by compiler fuzzing.
- Launched website featuring links to documentation and tutorials.
- Provided regular development updates.
Web3py
Written by Keri Clowes
In Q2, the primary focus of the web3py team has been ensuring compatibility with EIP-1559 and supporting asynchronous JSON-RPC calls. Async work will continue into Q3. Documentation was also prioritized in Q2, with numerous clarifications and examples added from frequently asked questions.
Stateless Ethereum
Written by Piper Merriam
The Stateless Ethereum initiative is ongoing. Over recent months, we have addressed the remaining roadmap elements required to achieve the ultimate goal of protocol-level support for stateless block execution.
The Verkle Trie represents a new data structure for retaining the Ethereum state that mitigates the challenges of reducing block witnesses to a manageable size. Our strategy for “State Expiry” provides a streamlined and straightforward approach to transition the existing hexary Patricia trie to the new Verkle trie format. This will also address the “state rent” dilemma,
“`establishing fiscal limits on the overall state size.
The verkle trie transition also streamlines the method of setting fiscal limits on the dimensions of block witnesses, a task that was notably more challenging with the hexary patricia trie. The final significant component that requires resolution is how to implement “Address Space Extension” commonly referred to as ASE.
These elements encompass all that is necessary to facilitate stateless block execution within our protocol, but perhaps more crucially, they are important enhancements to our protocol that rectify numerous persistent and challenging issues.
Security [Security / Consensus Evaluations]
Written by Martin Holst Swende
The second quarter predominantly revolved around the London hardfork, the execution of EIP 1559, and cross-client evaluations. An exploitable vulnerability was discovered within the specification that could result in maliciously inflated transactions/blocks. Erigon has also been incorporated into the fuzzing framework.
The Hive testing framework detected problems within the ENR compatibility between Besu and other clients, leading to ENR exchanges failing.
Solidity
Written by Franziska Heintel
In the second quarter, we launched Solidity versions 0.8.4., 0.8.5, 0.8.6, and 0.8.7:
- Solidity 0.8.4 introduces custom structured errors, bytes.concat(…), enhances flexibility in the SMTChecker configuration, and rectifies a bug in the Solidity ABI decoder v2.
- Solidity 0.8.5 permits conversions from bytes to bytesNN values, incorporates the verbatim built-in function to inject arbitrary bytecode in Yul, and resolves multiple smaller defects.
- Solidity 0.8.6 addresses several non-critical yet annoying bugs, notably a warning regarding unreachable code that is, in fact, reachable.
- Solidity 0.8.7 rolls out support for the London upgrade, incorporates various advancements in Yul to EVM code transformation, the SMTChecker, along with some bug fixes. Support for London includes compatibility with the BASEFEE opcode (EIP-3198 and EIP-1559) which reveals the block’s base fee. This can be accessed through the global block.basefee or by employing basefee() in inline assembly or Yul.
Additionally, the optimizer documentation section has been enriched with further content and we clarified the soliditylang.org domain umbrella and the whereabouts of binaries on the blog.
Several members of the Solidity team delivered presentations at EthCC. You can view their lectures on YouTube:
Finally, we are in search of a new team member! Please connect with us if you are a C++ engineer interested in developing and managing the Solidity language and compiler and participating in discussions and decisions regarding language design!
ZoKrates
Written by Thibaut Schaeffer
This quarter, the ZoKrates team achieved advancements on all fronts.
Language
Regarding language functionalities, ZoKrates has enhanced support for constant generics, user-defined, and low-level constants. This facilitates clearer code that operates across a variety of inputs, proof systems, and curves. The u64 type has also been introduced.
Runtime
Runtime efficiency has been boosted due to less expensive conditionals and random array access as well as optimized comparison evaluations. These changes result in fewer generated constraints, thereby decreasing the costs associated with proof generation. Furthermore, an optional branch isolation feature has been added to simulate short circuiting during execution.
Standard Library
The standard library has received enhancements to include the SHA3 family of hash functions, along with the SNARK-friendly Poseidon hash function. Another significant enhancement is the support for recursive proof composition.
Targets
Lastly, ZoKrates now accommodates the Marlin universal SNARK as a target, which minimizes trust requirements to a sole trusted setup phase.
For a complete overview of the modifications, please check the changelog
