Connect with us


Secured no. 1 | Ethereum Foundation Blog



Secured no. 1 | Ethereum Foundation Blog

Earlier this year, we launched a bug bounty program focused on finding issues in the beacon chain specification, and/or in client implementations (Lighthouse, Nimbus, Teku, Prysm etc…). The results (and vulnerability reports) have been enlightening as have the lessons learned while patching potential issues.

In this new series, we aim to explore and share some of the insight we’ve gained from security work to date and as we move forward.

This first post will analyze some of the submissions specifically targeting BLS primitives.

Disclaimer: All bugs mentioned in this post have been already fixed.

BLS is everywhere

A few years ago, Diego F. Aranha gave a talk at the 21st Workshop on Elliptic Curve Cryptography with the title: Pairings are not dead, just resting. How prophetic.

Here we are in 2021, and pairings are one of the primary actors behind many of the cryptographic primitives used in the blockchain space (and beyond): BLS aggregate signatures, ZK-SNARKS systems, etc.

Development and standardization work related to BLS signatures has been an ongoing project for EF researchers for a while now, driven in-part by Justin Drake and summarized in a recent post of his on reddit.

The latest and greatest

In the meantime, there have been plenty of updates. BLS12-381 is now universally recognized as the pairing curve to be used given our present knowledge.

Three different IRTF drafts are currently under development:

  1. Pairing-Friendly Curves
  2. BLS signatures
  3. Hashing to Elliptic Curves

Moreover, the beacon chain specification has matured and is already partially deployed. As mentioned above, BLS signatures are an important piece of the puzzle behind proof-of-stake (PoS) and the beacon chain.

Recent lessons learned

After collecting submissions targeting the BLS primitives used in the consensus-layer, we’re able to split reported bugs into three areas:

  • IRTF draft oversights
  • Implementation mistakes
  • IRTF draft implementation violations

Let’s zoom into each section.

IRTF draft oversights

One of the reporters, (Nguyen Thoi Minh Quan), found discrepancies in the IRTF draft, and published two white papers with findings:

While the specific inconsistencies are still subject for debate, he found some interesting implementation issues while conducting his research.

Implementation mistakes

Guido Vranken was able to uncover several “little” issues in BLST using differential fuzzing. See examples of those below:

He topped this off with discovery of a moderate vulnerability affecting the BLST’s blst_fp_eucl_inverse function.

IRTF draft implementation violations

A third category of bug was related to IRTF draft implementation violations. The first one affected the Prysm client.

In order to describe this we need first to provide a bit of background. The BLS signatures IRTF draft includes 3 schemes:

  1. Basic scheme
  2. Message augmentation
  3. Proof of possession

The Prysm client doesn’t make any distinction between the 3 in its API, which is unique among implementations (e.g. py_ecc). One peculiarity about the basic scheme is quoting verbatim: ‘This function first ensures that all messages are distinct’ . This was not ensured in the AggregateVerify function. Prysm fixed this discrepancy by deprecating the usage of AggregateVerify (which is not used anywhere in the beacon chain specification).

A second issue impacted py_ecc. In this case, the serialization process described in the ZCash BLS12-381 specification that stores integers are always within the range of [0, p - 1]. The py_ecc implementation did this check for the G2 group of BLS12-381 only for the real part but did not perform the modulus operation for the imaginary part. The issue was fixed with the following pull request: Insufficient Validation on decompress_G2 Deserialization in py_ecc.

Wrapping up

Today, we took a look at the BLS related reports we have received as part of our bug bounty program, but this is definitely not the end of the story for security work or for adventures related to BLS.

We strongly encourage you to help ensure the consensus-layer continues to grow safer over time. With that, we look forward hearing from you and encourage you to DIG! If you think you’ve found a security vulnerability or any bug related to the beacon chain or related clients, submit a bug report! 💜🦄

Source link

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published.


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


Goerli/Prater Merge Announcement | Ethereum Foundation Blog



Finalized no. 32 | Ethereum Foundation Blog

  • For the last testnet proof-of-stake transition, Goerli will merge with Prater. The combined Goerli/Prater network will retain the Goerli name post-merge.
  • Bellatrix, the Prater upgrade readying it for The Merge will happen at epoch 112260, expected at 12:24PM UTC on August 4, 2022.
  • After Bellatrix is activated, the Goerli/Prater merge will happen when Goerli hits a total difficulty of 10790000, expected between August 6-12, 2022.
  • Post-merge, Goerli’s validator set will remain open for individual stakers to run testnets validators. Stakers who wish to start a Goerli/Prater validator can do so at the Prater Launchpad.


After years of work to bring proof-of-stake to Ethereum, we are now well into the final testing stage: testnet deployments!

After several devnets, shadow forks and merges on deprecated testnets, Sepolia was recently transitioned to proof-of-stake. Now, only one more testnet remains: Goerli, and its associated Beacon Chain, Prater.

The Merge is different from previous Ethereum upgrades in two ways. First, node operators need to update both their consensus layer (CL) and execution layer (EL) clients in tandem, rather than just one of the two. Second, the upgrade activates in two phases: the first, named Bellatrix, at an epoch height on the Beacon Chain and the second, named Paris, upon hitting a Total Difficulty value on the execution layer.

Upgrade Information


The Merge is a two-step process. It starts with a network upgrade, Bellatrix, on the consensus layer, triggered by an epoch height. This is followed by the execution layer’s transition from proof-of-work to proof-of-stake, Paris, triggered by a specific Total Difficulty threshold, called the Terminal Total Difficulty (TTD).

The Bellatrix upgrade is scheduled for epoch 112260 on the Prater Beacon Chain, expected at 12:24PM UTC on August 4, 2022. Paris, the execution layer’s portion of the transition, will trigerred by reaching a Terminal Total Difficulty (TTD) of 10790000 on Goerli, expected between August 6-12, 2022.

Once the execution layer has exceeded the TTD, the next block will be solely produced by a Beacon Chain validator. We consider The Merge to have been completed once the Beacon Chain has finalized this block. Assuming normal network conditions, this should happen 2 epochs, or approximately 13 minutes, after the first post-TTD block is hit!

A new JSON-RPC block tag, finalized, returns the latest finalized block or an error if no such post-merge block exists. This tag can be used for applications to check if The Merge has been completed. Similarly, smart contracts can query the DIFFICULTY opcode (0x44), renamed to PREVRANDAO post-merge, to determine if The Merge has happened. We recommend infrastructure providers monitor overall network stability in addition to finalization status.

Client Releases

The following client releases support The Merge across the Goerli & Prater testnets. Node operators must run both an execution and consensus layer client to remain on the network during and after The Merge.

When choosing which client to run, validators should be especially mindful of the risks of running a majority client on both the EL and CL. An explainer of these risks and their consequences can be found here. An estimate of current EL and CL client distribution and guides for switching from one client to another can be found here.

Consensus Layer

Execution Layer

Upgrade Specifications

Consensus-critical changes for The Merge are specified in two places:

  • The consensus layer changes, under the bellatrix directory of the consensus-specs repository
  • The execution layer changes, under the Paris spec in the execution-specs repository

In addition to these, two other specifications cover how the consensus and execution layer clients interact:

  • The Engine API, specified in the execution-apis repository, is used for communication between the consensus and execution layers
  • Optimistic Sync, specified in the sync folder of the consensus-specs repository, is used by the consensus layer to import blocks as the execution layer client is syncing and to provide a partial view of the head of the chain from the former to the latter


As a node operator, what should I do?

Post-merge, an Ethereum full node will combine a consensus layer (CL) client, which runs the proof-of-stake Beacon Chain, and an execution layer (EL) client, which manages the user-state and runs the computations associated with transactions. These communicate over an authenticated port using a new set of JSON RPC methods called the Engine API. The EL and CL client authenticate each other using a JWT secret. Node operators should refer to their clients’ documentation for instructions about how to generate and configure these.

In other words, if you were already running a node on the Beacon Chain, you now also need to run an execution layer client. Similarly, if you were running a node on the current proof-of-work network, you will need to run a consensus layer client. For them to communicate securely, a JWT token must be passed to each client. Summary instructions for running a node on the Goerli/Prater network can be found here.

It is worth emphasizing that while they are both part of consensus layer client releases, running a Beacon Node is distinct from running a Validator Client. Stakers must run both, but node operators only need the former. This post explains the difference between both components in more detail.

Also, note that each layer will maintain an independent set of peers and expose its own APIs. The Beacon and JSON RPC APIs will both continue working as expected.

As a staker, what do I need to do?

The Goerli/Prater Merge is your last opportunity to ensure that your validators are correctly configured before the mainnet transition. Running through the transition now is strongly recommended to avoid any unexpected issues on mainnet.

As explained above, validators on the Beacon Chain will need to run an execution layer client after The Merge, in addition to their consensus layer clients. Pre-merge, this was strongly recommended, but validators could have outsourced these functions to third-party providers. This was possible because the only data required on the execution layer were updates to the deposit contract.

Post-merge, validators need to ensure that transactions in blocks that they create and attest to are valid. To do this, each beacon node must be paired with an execution layer client. Note that multiple validators can still be paired to a single beacon node & execution layer client combo. While this expands validators’ responsibilities, it also gives a validator who proposes a block the right to its associated transaction priority fees (which currently go to miners).

While validator rewards accrue on the Beacon Chain and will require a subsequent network upgrade to be withdrawn, transaction fees will continue to be paid, burned, and distributed on the execution layer. Validators can specify any Ethereum address as a recipient for transaction fees.

After updating your consensus client, be sure to set the fee recipient as part of your validator client configurations to ensure transaction fees are sent to an address you control. If you have staked using a third-party provider, it is up to your selected provider to specify how these fees are allocated.

The Prater Staking Launchpad has a Merge Readiness Checklist that stakers can use to ensure they have gone through each step of the process. The EthStaker team is also hosting a Merge Validator Preparation Workshop on July 29.

Why is the estimate for the Terminal Total Difficulty date so broad?

The volatility in incremental difficulty per block makes estimating a window for the TTD harder than with a block or epoch height, hence the wider expected range. Users should note that this will also be the case for mainnet’s transition due to changes in proof-of-work hash rate.

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

With The Merge going live on Goerli, now is your last chance to ensure that your product works as expected through the proof-of-stake transition and in a post-merge context. As explained in a previous post, The Merge will have only minimal impact on a subset of contracts deployed on Ethereum, none of which should be breaking. Additionally, the lion’s share of user API endpoints remain stable (unless you use proof-of-work specific methods such as eth_getWork).

That said, most applications on Ethereum involve much more than on-chain contracts. Now is the time to ensure that your front-end code, tooling, deployment pipeline and other off-chain components work as intended. We strongly recommend that developers run through a complete testing & deployment cycle on Sepolia, Ropsten or Kiln and report any issues with tools or dependencies to those projects’ maintainers. If you are unsure where to open an issue, please use this repository.

Additionally, you should note that all testnets aside from Sepolia and Goerli will be deprecated post-merge. If you are a user of Ropsten, Rinkeby or Kiln, you should plan to migrate to Goerli or Sepolia. More information about this can be found here.

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

No. The Ethereum mainnet is not affected by this testnet. Subsequent announcements will be made on this blog before mainnet’s transition.

As a miner, is there anything I need to do?

No. If you are mining on the Ethereum mainnet, you should be aware that the network will operate entirely under proof-of-stake after The Merge. At that point, mining will no longer be possible on the network.

As a validator, can I withdraw my stake?

No. The Merge is the most complicated upgrade to Ethereum to date. To minimize risks of network disruptions, a minimal approach was taken which excluded any non-transition changes from this upgrade.

Withdrawals from the Beacon Chain will likely be introduced in the first upgrade after The Merge. Specifications for both the consensus and execution layers are in progress.

I have more questions, where can I ask them?

The EthStaker community has set up a discord channel to answer staker and node operator questions. You can join their discord here and then use the #goerli-prater channel for assistance. As mentioned above, EthStaker will also host a Merge Validator Preparation Workshop on July 29.

Additionally, a Merge Community Call is scheduled for August 12, 14:00 UTC. Client developers and researchers will be available to answer questions from node operators, stakers, infrastructure & tooling providers and community members. Note that this community call is expected to happen after the Goerli/Prater merge.

wen merge?

As of the publication of this post, the time for the Ethereum mainnet proof-of-stake transition has not been set. Any source claiming otherwise is likely to be a scam. Updates will be posted on this blog. Please stay safe!

Assuming no issues are found during the Goerli/Prater merge, once clients have feature-complete releases, a slot height will be chosen for the Bellatrix upgrade on the mainnet Beacon Chain and a total difficulty value will be set for the mainnet transition. Clients will then make releases that enable The Merge on mainnet. These will be announced on this blog and in other community publications.

However, if issues are found at any point in the process or test coverage is judged to be insufficient, these things will be addressed before continuing with the deployment process.

Only then will it be possible to estimate the exact date for The Merge.

In other words, 🔜.

Source link

Continue Reading