Connect with us


EF-Supported Teams: Research & Development Roundup



EF-Supported Teams: Research & Development Roundup

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

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

As always, there’s much more progress being made by EF-supported projects and teams that help to improve our Ethereum experience. This roundup series is an opportunity to highlight their efforts to grow and improve Ethereum as a whole. Included in this edition are updates from many teams highlighted in the previous Supported Teams update, and more.


Ecosystem Support Program

Authored by ESP Team

Office hours

Road to Devcon Grants

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

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

Eth2 Research

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

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

Authored by Sam Richards

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

Greetings fellow Ethereans!

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

Content updates

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

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

Learn how to get involved

CLR funding round for Eth2 projects

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

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

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

Learn more, follow along & get involved

Translation Program

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

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

Learn how to get involved

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

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

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

How does that sound?

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

More on contributing

Ipsilon (previously Ewasm)

Authored by Alex Beregszaszi

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

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

Most of our content is published here.

EVM Object Format (EOF)

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

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

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

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

Address Space Extension (ASE)

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

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

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

Other research

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

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


  • 8.0.0 release
    • Berlin support, new callbacks to update global account/storage accessed list.
  • 9.0.0 release
    • London support and block_base_fee added to transaction context
    • evmc run with --bench


  • 0.7.0 release
    • Berlin support
    • Optimizations in Baseline interpreter’s jumpdest analysis
    • Improvements to the C++ API
  • 0.8.0 release
    • London support and BASEFEE instruction implementation
    • Instruction tracing following EIP-3155 format added to Baseline interpreter
    • Option to count the number of executed instructions in Baseline interpreter
    • More optimizations in Baseline interpreter and in intx and ethash libraries.
    • Improvements to benchmarking tools

Formal Verification

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


  • SMT backend rewrite
  • Pretty printed counterexamples


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


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


authored by Felix Lange

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

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

Javascript Team

Authored by Holger Drewes

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

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

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

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

Privacy & Scaling Explorations

Authored by Thore Hildebrandt

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


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

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

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

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

Perpetual Powers of Tau

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

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

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

MPC Phase 2 UI

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

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


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

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

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


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

Blind Find

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

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

Unirep & Unirep Social

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

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

Join the telegram channel to learn more and discuss!

BLS Sig Aggregation

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

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


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


Rollup Diff Compression

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

EVM Rollup Reviews

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


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

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

Join the Telegram group to learn more and discuss.


Authored by Rob Stupay

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

See more in our blog.

Snake Charmers [Python Ecosystem: PyEVM/Trinity/]


Authored by Grant Wuerker

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

Here are some development highlights from Q2:

  • Four more alpha releases (0.4.0 – 0.6.1).
  • Added Rust-style diagnostic messages.
  • More runtime checks.
    • ABI data validation
    • Arithmetic overflow checks
  • Support for custom error types and panic codes following Solidity.
  • Fixed bugs identified by compiler fuzzing.
  • Launched website with links to documentation and tutorials.
  • Regular development updates.


Authored by Keri Clowes

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

Stateless Ethereum

Authored by Piper Merriam

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

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

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

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

Security [Security / Consensus Tests]

Authored by Martin Holst Swende

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

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


Authored by Franziska Heintel

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

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

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

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

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


Authored by Thibaut Schaeffer

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


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


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

Standard Library

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


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

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

Source link

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published.


Finalized no. 36 | Ethereum Foundation Blog



Finalized no. 32 | Ethereum Foundation Blog


Merge sequence engaged 🚀

Mainnet Merge incoming

Yesterday on the Consensus Layer call, client engineers agreed on Mainnet parameters for the Merge – a Bellatrix epoch of 144896 and a Paris TTD of 58750000000000000000000 (tentative). The TTD is based on Proof-of-Work difficulty and is thus a bit hard to estimate precisely. The target date is September 15, 2022, but this estimate might have even a week of error. On this coming week’s All Core Dev call estimates will be re-checked, and the TTD will either be confirmed or a final adjustment will be made to better hit the target date.

Reminder💡: The Merge consists of a sequence of two upgrades – Bellatrix on the Consensus Layer followed by Paris on the Execution Layer.

Bellatrix upgrades the Beacon Chain to be “Merge aware”, embedding the Beacon Chain with the Merge logic as validators begin dilligently monitoring the Proof-of-Work chain to initiate the Merge transition. Bellatrix is activated at the chosen epoch.

Paris is the Merge transition itself, in which Ethereum Mainnet hot-swaps its consensus from Proof-of-Work to the Beacon Chain’s Proof-of-Stake. The Paris upgrade activates at the chosen Terminal Total Difficulty (TTD).

⚠️ All hands on deck ⚠️

Stakers, infrastructure providers, users, and community members – this is your warning. The Merge mainnet sequence is engaged. For the next ~5 weeks, stay tuned, watch for updates, remain agile, and be ready for anything. The following is the high level of dates and events expected to unfold:

  • [2022/08/18] – TTD reassessed and finalized on All Core Devs call
  • [2022/08/18 to 2022/8/22] – EL and CL teams cut Mainnet software releases
  • [2022/08/23] – Client resources, EF blog, and other community and infrastructure announcements of final parameters and releases
  • [2022/09/06 11:34:47am UTC] – Bellatrix Mainnet upgrade
    • All stakers must upgrade to EL+CL Merge-ready nodes before this time
    • All infrastructure providers, users, and community members should upgrade PoW nodes to EL+CL Merge-ready nodes before this time
  • [Estimated: 2022/9/15] – Paris Mainnet Merge transition
    • All infrastructure providers, users, and community members must upgrade to EL+CL Merge-ready nodes before this time. Plan on configuring systems at least one week in advance and ideally before Bellatrix

Between initial mainnet release announcements and the final Merge transition, users must remain diligent – monitoring client channels, the EF blog, and other public resources for any new information. Specifically, client teams might release final hardened versions of their software in this time frame and, if possible, users should upgrade.

Huge shout-out to the engineers, researchers, and community members that have worked tirelessly, putting countless hours into this. Merge sequence engaged 🚀

Source link

Continue Reading


Sepolia Post-Merge Upgrade Announcement | Ethereum Foundation Blog



Finalized no. 32 | Ethereum Foundation Blog

  • The Sepolia testnet will undergo a post-merge execution layer (EL) upgrade at block 1735371, expected on August 17, 2022
  • The upgrade will cause EL clients on the network to disconnect from peers which have not transitioned to proof-of-stake. It does not add additional functionality beyond this.
  • Sepolia node operators must upgrade their execution layer client prior to block 1735371.
  • A similar upgrade is expected on Goerli and the Ethereum mainnet once these networks have transitioned to proof-of-stake


In order to maintain a healthy peer list, nodes on Ethereum’s execution layer will automatically disconnect peers who do not have the same upgrade sequence as them. On the Ethereum mainnet, this means checking whether a peer upgrded to Frontier Thawing at block 200,000, then Homestead at block 1,150,000, and so on all the way to the latest upgrade, Gray Glacier, which happened at block 15,050,000. EIP-2124 specifies how this is handled. In typical network upgrades, which are triggered by a block height, this happens automatically as nodes use the block height of upcomming upgrades to filter peers.

For The Merge, this was not possible because the upgrade was triggered using a total difficulty value rather than a block number. The rationale for this choice is explained in EIP-3675:

Using a pre-defined block number for the hardfork is unsafe in this context due to the PoS fork choice taking priority during the transition.

An attacker may use a minority of hash power to build a malicious chain fork that would satisfy the block height requirement. Then the first PoS block may be maliciously proposed on top of the PoW block from this adversarial fork, becoming the head and subverting the security of the transition.

To protect the network from this attack scenario, difficulty accumulated by the chain (total difficulty) is used to trigger the upgrade.

To minimize changes to the protocol during its most complex upgrade since launch, the design for The Merge excluded EIP-2124 compatibility. This means an additional upgrade must now be done to add this. It is important to note that the only change introduced as part of this upgrade is specifying a block number that nodes can use to identify peers who have gone through The Merge. No other functionality is introduced or deprecated as part of this upgrade.

Upgrade Information


This upgrade will happen on Sepolia at block 1735371, expected on August 17, 2022.

Note that a similar upgrade will be announced for Goerli and mainnet after these networks have transitioned to proof-of-stake.

Ropsten will not be upgraded since it is now considered deprecated, along with Rinkeby and Kiln. See this post for more details on their deprecation schedule.

Client Releases

Only execution layer clients need to be updated for this upgrade. Node operators can keep running their current consensus layer client release on Sepolia through the transition.

Note that client releases used for the Goerli/Prater merge all support this upgrade on Sepolia. In other words, if you already downloaded a release for the Goerli/Prater merge, you can use that same version on Sepolia for this upgrade.

Execution Layer

Upgrade Specifications

The specification for this change is tracked as part of the Paris specifications, under the FORK NEXT Upgrade section.


As a node operator, what should I do?

You should upgrade your execution layer client to one of the versions listed above before August 16, 2022. Your consensus layer client does not need to be upgraded.

As a staker, what do I need to do?

The validator set on Sepolia is permissioned. If you are part of the current Sepolia validators, you must update your execution layer client to one of the versions listed above on August 16, 2022 at the latest.

If you are not part of the current Sepolia validator set, you do not need to do anything at this time.

Goerli/Prater and mainnet validators will need to follow the same steps when this upgrade is announced on those networks.

As an application or tooling developer, what should I do?

Nothing, unless you are also running a node. If so, please upgrade your execution layer client to one of the versions listed above before August 16, 2022.

As an Ethereum user or Ether holder, is there anything I need to do?

No. The Ethereum mainnet is not affected by this upgrade. Even when this upgrade will be applied to mainnet, there won’t be any action needed.

Thank you to Justin Chrn for the original cover image and Tomo Saito for the modifications.

Source link

Continue Reading


Academic Grants Round grantee announcement



Finalized no. 32 | Ethereum Foundation Blog

We are thrilled to announce the 39 grantees selected for the recent Academic Grants Round. This grants round invited researchers, think-tanks, Ph.D. students, and all those interested in advancing knowledge around the Ethereum ecosystem to submit academic proposals.

Thank you to all those who submitted proposals, and congratulations to all the grantees. We are pleased with the number of quality applications that we received, which surpassed our initial expectations. Given the extraordinary potential of many project proposals, we have more than doubled the initial budget from $750,000 to $2 million.

The granted projects vary broadly in scope and geographic representation with research teams from Australia, Canada, China, Costa Rica, Germany, Greece, Hungary, Nepal, Pakistan, Romania, Singapore, South Korea, Spain, Switzerland, The Netherlands, the United Kingdom the United States and Vietnam.

We look forward to the results from the many academic projects supported in this round! If you missed this round and are researching something in this space, consider submitting a project inquiry to the Ecosystem Support Program.

More than $2 million has been allocated across 39 grants in 7 different categories:

Category # of projects amount (USD)
Economics 9 $ 222,067.00
Consensus Layer 9 $ 483,477.81
P2P Networking 5 $ 386,592.00
Maximum Extractable Value 5 $ 351,659.00
Formal Verification 4 $ 283,165.51
Cryptography and zero knowledge proofs 2 $ 120,000.00
Other domains 5 $ 194,807.00


Project Research Team Institution Description
Analysis of the Dynamic Interplay between Ethereum and Ethereum Rollups: Transaction Fees and Demand Trends Aysajan Eziz; Guneet Kaur Nagpal Independent To research the dynamic interplay of transaction fees and demand trends between base layer and layer 2 rollups.
Equilibrium staking rewards: Implications for POS blockchain security Prof Talis Putnins; Tra Nguyen, Ph.D. candidate; Lecky Lao, Ph.D. candidate Independent To research and propose economic modeling of “opportunity costs of capital”, the dynamics of how capital flows between staking opportunities, and what that implies for the security of Ethereum (and other POS blockchains) as it transitions to POS and the optimal design of the staking incentive mechanisms.
Monetary Policy in the Age of Cryptocurrencies Prof. Thai Nguyen; Prof. Tra Pham; Dr. Binh Nguyen Thanh; Dr. Linh Nguyen Thi My; Dr. Tuan Chu; Dr. Seng Kok; Dr. Phong Nguyen RMIT Vietnam To shed light on the possible economic development of countries when cryptocurrencies are used as legal tender, particularly in light of the fact that the central banks would lose most of the monetary policy tools.
Time series analysis for transaction fee market Huisu Jang YunYoung Lee, Ph.D; Seongwan Park, Ph.D; Seungju Lee Woojin Jeong; Advisor: Jaewook Lee Soongsil University and Seoul National University To perform a time series analysis of the Ethereum gas fee market after the introduction of EIP-1559.
The Influence of Transaction Costs on Economic Activity on the Ethereum Network Dr. Lennart Ante Blockchain Research Lab gGmbH To investigate the extent to which transaction costs interrelate with different economic activities on the Ethereum network.
The Market for Music Non-Fungible Tokens (NFTs): Price, Volume, and Risk Danling Jiang, Ph.D.Keli Xiao, Ph.D. Lolita Nazarov, B.S Haixiang (Diego) Zhu, MS Stony Brook Foundation To understand the market for the music content non-fungible tokens (music NFTs) and the determinants of price, volume, and risk dynamics of such NFTs traded on OpenSea, powered by the Ethereum blockchain.
The Microeconomic Foundation of DAO David Yang, Ph.D Independent To understand the economic conditions that justify the emergence of a DAO structure in governing community decisions.
Towards scalable incentive machines: attributing value to individual agents in multi-player games Tal Kachman Donders Institute of Brain and Cognition To bridge coalitional game theory with the approximation power of deep learning to construct payoff machines: large-scale estimators capable of measuring every agent’s contribution to a multi-agent system according to different underlying principles.
Understanding Waiting Time in Transaction Fee Mechanisms Prof Luyao Zhang, Ph.D; Prof Fan Zhang, Ph.D. SciEcon CIC To systematically study and then develop a practical policy that can further reduce the users’ waiting time in Ethereum TFM.

Consensus Layer

Project Research Team Institution Description
(Danksharding + PBS) Builder centralization: Is it really safe? Huisu Jang; YunYoung Lee, Ph.D candidate; Seongwan Park; Seungju Lee; Woojin Jeong; Advisor: Jaewook Lee Statistical Learning & Computational Finance Lab, Seoul National University To explore two potential risks of centralizing block production in PBS and propose proper modifications to the current PBS scheme to ensure safety against the suggested risks.
Amplification Messaging for Short-Term Slot Finality and Improved Reorg-Tolerance Hammurabi Mendes, Ph.D.; Jonad Pulaj, Ph.D. Davidson College To formalize and evaluate relatively unobtrusive changes in GASPER for shorter-term finality and decreased likelihood of reorgs.
Analyzing and Securing Ethereum PoS in the Fully Asynchronous Network Dr. Qiang Tang; Zhenliang Lu, Ph.D.; Dr. Yuan Lu The University of Sydney To study the security of Ethereum PoS in the fully asynchronous network, in which there is no guaranteed delivery time, and to make design suggestions on how to make Ethereum PoS more secure in an asynchronous network.
Combining Accountability and Game Theory to Strengthen Blockchain Security Prof. Vincent Gramoli The University of Sydney To design novel algorithms that we will implement and evaluate in a large-scale distributed environment to demonstrate that blockchains can be made more secure with a practical combination of accountability and game theory.
Disentangling Transaction Privacy and Consensus in Ethereum Prof. Kartik Nayak; Prof. Fan Zhang Duke University To study the dilemma between desirable properties such as (pre and failed trade) transaction privacy and the properties of the underlying consensus mechanism provided by Ethereum.
Improving Ethereum Communication Efficiency through Accountability and Flexible Quorums Prof. Kartik Nayak Duke University To analyze 2 possible avenues to still obtain the same desirable security guarantees while improving efficiency. Firstly, using smaller quorums with accountability to obtain a more communication efficient protocol; and secondly using flexible quorums to obtain stronger security guarantees (of up to ⅔ fraction rational corrupt validators).
PoS Ethereum Agent-Based Model Prof. Claudio J. Tessone; Nicolò Vallarano, Ph.D. University of Zurich To provide an abstract Agent Based Model to simulate Ethereum Proof-Of-Stake consensus.
REVOKE: Consensus-layer mitigations for validator ransomware attacks Dr. Dan O’Keeffe; Dr. Darren Hurley-Smith; Alpesh Bhudia, Ph.D. candidate Royal Holloway University of London To explore consensus protocol adaptations to mitigate the risks of ransomware attacks on Ethereum 2.0 validators. It will aim to design a new revocation mechanism that will allow validators to improve their operational security by quickly changing their signing key without having to withdraw their stake.
Staking Mechanism Design: Ethereum 2.0 for Good Dr. Luyao Zhang; Dr. Yulin Liu; Research Fellows: Xinyu Tian; Tianyu Xin; Zesen Zhuang SciEcon CIC To investigate the impact of the Ethereum 2.0 upgrades, mainly including its policy upgrade and the switch from proof of work to proof of stake, on its overall security, degree of decentralization, and scalability.

P2P Networking

Project Research Team Institution Description
Coded Transaction Broadcasting for High-throughput Blockchains Prof. Mohammad Alizadeh; Lei Yang, Ph.D. student Massachusetts Institute of Technology (MIT) To design and build a new scheme for broadcasting new pending transactions in a blockchain network, with the goal to reduce the bandwidth usage and the latency to propagate transactions.
DoS-secure transaction propagation on Ethereum: Exploit generation and attack detection Prof. Yuzhe Tang; Kai Li, Ph.D. student; Jiaqi Chen, Ph.D. student; Yibo Wang, Ph.D. student; Jack Willis; Nicholas P. Sweet; Mingyan Zhang Syracuse University To research and build an automated exploit generator to systematically evaluate the security/insecurity of current and future Ethereum clients under the low-cost DoS attacks as well as build DoS-secure mempool and transaction propagation protocols. Particularly, we will present a two-buffer mempool mechanism to support different transaction admission priorities.
Eclipse and DoS-Resilient Overlays for High-Performance Block Dissemination Prof. Spyros Voulgaris; Evangelos Kolyvas, Ph.D.; Alexandros Antonov, Ph.D. Athens University of Economics and Business To design, implement, and evaluate a fully decentralized, self-organizing, self-healing, resource conservative, and dependable dissemination mechanism that delivers messages faster than is currently planned to be employed, while guaranteeing high reliability even in the case of failures or high node churn; and to shield our proposed protocol from Eclipse and DoS attacks, such that it becomes too hard for an attacker to obstruct message dissemination.
Privacy-enhanced and efficient P2P routing algorithms for the Ethereum network István András Seres, Ph.D. student; Domokos Kelen, Ph.D. student; Ferenc Béres, Ph.D. student; András A. Benczúr, Ph.D Independent To design, implement and evaluate a privacy-enhanced routing algorithm for the Ethereum network that provably outperforms state-of-the-art proposals.
Tikuna: an Ethereum blockchain network security monitoring system Dr. Andres Gomez Ramirez, Ph.D.; Loui Al Sardy, Ph.D. candidate Sistemas Edenia Internacional To build a proof-of-concept P2P network security monitoring system for the Ethereum blockchain for early detection of relevant incidents.
Project Research Team Institution Description
Battle of the Bots: Miner Extractable Value and Efficient Settlement Prof. Alfred Lehar; Prof. Christine Parlou University of Calgary To examine how MEV and private transactions change blockchain economics, and impact socially desirable arbitrage such as loan liquidations and the alignment of DEX prices.
Catching the ephemeral: Understanding blockchains through mempool data Prof. Fan Zhang; Prof. Kartik Nayak Yale University To empirically study critical aspects of the Ethereum blockchain such as the fee markets and ordering fairness, by using mempool data.
M2EV: Multi-block MEV games Bruno Mazorra, Ph.D. student; Prof. Vanesa Daza Pompeu Fabra University To formalize the Reorg MEV game through a game theoretical perspective and understand the negative externalities induced by rational validators.
Mechanism Design and Empirical Analysis of MEV Prevention Mechanisms Prof. Agostino Capponi Columbia University To study the design of Maximum Extractable Value (MEV) prevention mechanisms, such as relay and sequencing service, develop an econometric analysis of MEV prevention mechanisms, and quantify their impact on gas fees and value of ecosystem participants.
Optimal Design of Miner Extractable Value Auctions Dr Peyman Khezr; Dr Vijay Mohan Royal Melbourne Institute of Technology (RMIT University) To investigate the optimal design of auctions that, first, allocate the block space to potential transactions, and second, provide an efficient transaction ordering in a Miner Extractable Value Auction (MEVA).

Formal Verification

Project Research Team Institution Description
Bounded Model Checking for Verifying and Testing Ethereum Consensus Specifications Dr. Youcheng Sun; Dr. Lucas C. Cordeiro University of Manchester To verify and test Ethereum consensus specifications, i.e., the Python reference implementation, by applying Bounded Model Checking (BMC).
Formally verified Ethereum 2.0 Beacon Chain Hamra Afzaal; Muhammad Umar Janjua; Muhammad Imran Information Technology University of the Punjab To find and correct bugs in the Beacon Chain using model checking technique.
FORVES (FORmally VErified block optimizationS) Prof. Elvira Albert; Prof. Samir Genaim; Prof. Enrique Martin-Martin University Complutense of Madrid To develop a fully automated and formally verified tool, in Coq, that is able to verify the semantic equivalence of two loop-free fragments of EVM code.
Trustworthy Formal Verification for Ethereum Smart Contracts via Machine-Checkable Proof Certificates Prof. Grigore Rosu; Xiaohong Chenm, Ph.D. student University of Illinois Urbana-Champaign To study trustworthy formal verification for smart contracts via machine-checkable proof certificates.

Cryptography and zero knowledge proofs

Project Research Team Institution Description
Efficient Private Information Retrieval for Ethereum Light Clients Prof. Xun Yi; Prof. Son Hoang Dau; Nhat Quang Cao, Ph.D. student; Prof. Chen Feng Independent To develop cryptographic solutions that allow Ethereum light clients to perform data acquisition in a way that is not only efficient but also private.
ZK-SNARKs as a Service Prof. Abhishek Jain Johns Hopkins University To design secure protocols that can be executed by a group of servers to jointly compute ZK-SNARG proofs.

Other domains

Project Research Team Institution Description
Cross chain authenticated queries Dr. Damiano Di Francesco Maesa University of Pisa & University of Cambridge To study how it is possible to adopt, and adapt, authenticated query protocols for blockchains to allow for cross chain communication between different Ethereum side chains (and the main net).
Feasibility Study of Pipelining in Ethereum Virtual Machine Architecture Gopal Ojha Independent To research and develop for optimization of Ethereum network by increasing transaction throughput in the EVM.
Governance Based On Preferences, Incentives, and Information Prof. Bo Waggoner University of Colorado, Boulder To investigate governance methods of making collective decisions as a group.
Rollups as Subsidiary Political Units – A Diversity of Layer 2 Networks Subject to Layer 1’s Constitutional Authority Eric Alston; Prof. Bo Waggoner University of Colorado, Boulder To research the ways in which networks subsidiary to a given primary blockchain network share features with subsidiary political units in national constitutional orders.
S-CCSC: Security of Cross-chain Smart Contract Prof. Yang Xiang; Dr. Ziyuan Wang; Dr. Lin Yang; Dr. Sheng Wen; Dr. Donghai Liu Swinburne University of Technology To safeguard cross-chain smart contracts by investigating existing or potential security risks and corresponding solutions of cross-chain smart contracts.

We’re excited to follow these research teams and see the broad impact they have in expanding academic knowledge throughout the Ethereum ecosystem!

The diversity and quality of this round of grants reflects the interest of Academia in catalyzing our shared knowledge in helping solve major problems and advancing the Ethereum ecosystem.

Source link

Continue Reading