Ethereum Core Developer Conference Update 007

90% merger, 10% difficulty bomb?

As promised in the last update, this update will introduce the merged Ethereum client architecture in depth . With the progress made in Amphora’s interoperability activities, the merged specification is now close to being finalized?

Before we dive into the content of the merger, let’s briefly introduce the latest situation of the difficulty bomb!

Arrow Glacier ??

In the 124th core developer meeting (video, tweet), we reached a consensus on two times for the difficulty bomb: the upgrade will be carried out in December 2021, and it will be postponed to June 2022. For this, we need a network upgrade-Arrow Glacier, which will only include EIP-4345 on the delayed difficulty bomb.

Arrow Glacier plans to activate at block 13,773,000, and it is expected to be activated on December 8, 2021.

At the core developer meeting, we discussed multiple options postponed during the Ice Age. The reason for choosing June is that we are confident that the “merger” can be achieved before, and we want to avoid organizing another difficulty bomb to postpone it.

Of course, mergers and difficulty bombs are separate: it requires a separate network upgrade, and is based on the PoW total difficultythreshold to activate. This means that we don’t need to “wait” for the difficulty bomb to explode to transition from Ethereum to Proof of Stake. Similarly, if we encounter problems with the transition, we can decide to postpone the difficulty bomb again.

Hope Arrow Glacir will be PoW Ethereum?? The last network upgrade before the merger!

The merged architecture?

The merged architecture utilizes Ethereum’s well-proven clients for execution chain (Eth1) and beacon chain (Eth2). Since they already exist, it is reasonable to continue to use them.

In a nutshell, during the merger process, the client will switch from the PoW chain to the PoS chain to determine the latest valid block of Ethereum. In addition, most of the client’s functions, and more importantly the EVM, its state, and how it executes transactions, remain unchanged.

After the merger, the current Eth1 and Eth2 clients become the execution layer and consensus layer (or engine) of Ethereum respectively. This means that the node operator of the Eth1 or beacon chain client will need to run the “other half” of the stack to have a complete verification node. Danny Ryan made a very good chart to illustrate it. They have all been minted into NFTs, and all proceeds will be used to reward engineers and researchers for the combined work.

Ethereum Core Developer Conference Update 007

The merged client architecture. NFT Artist: Danny Ryan

The picture above shows what a complete Ethereum client looks like after the merger. Let’s use this as a starting point and dive into each component.

Beacon node?

Now, beacon nodes reach a consensus on empty blocks (from the perspective of end users). These blocks include information related to consensus, called operations, such as attestations, deposit contract roots, and verifier’s forfeiture/exit, but do not include transaction information in the Eth1 sense (for example, sending ETH or Smart contract interaction). The merger will change this situation.

When the merger occurs, the beacon node will monitor the current PoW chain and wait for it to reach the preset total difficulty(total difficulty) threshold, which is called TERMINAL_TOTAL_DIFFICULTY(total difficulty at the end). Once a block is out total difficulty >= TERMINAL_TOTAL_DIFFICULTY, the block will be regarded as the last PoW block. Subsequent blocks are all started to be constructed and certified by verifiers on the beacon chain.

To do the above, beacon nodes will need to communicate with their execution engine (formerly Eth1 client) and request it to generate or verify ExecutionPayloads(execution data). These data are the equivalent of the merged Eth1 block. They contain this information: the parent’s hash, the state root, the base fee, and the list of transactions that need to be executed. Once this information is generated or verified, the beacon node will share it with other nodes on the p2p network.

Ethereum Core Developer Conference Update 007

The merged block: the consensus layer (ie, the beacon node) verifies all the fields that are now part of the beacon chain block. When it receives ExecutionPayloads on the network, it transmits it to the execution layer for verification.

In order to establish communication between the consensus layer and the execution layer, a new set of JSON RPC endpoints will be introduced: Engine API (Engine Application Program Interface).

Engine API ⚙️

Engine API is the communication interface between the consensus layer and the execution layer. It is not in the public JSON RPC API of the execution layer, but in a separate port. For simplicity, calls to the API layer is always initiated by consensus, and the API only introduced three methods: engine_executePayloadengine_forkchoiceUpdatedand engine_getPayload. Let’s see what they do one by one:

engine_executePayload(Data execution engine) requires executives to verify ExecutionPayloadcompliance with all the rules of the agreement.

After receiving the data through this call, the execution layer will return VALIDINVALID(valid/invalid) or, if it has not finished synchronizing the chain head, it will return SYNCING(synchronizing). Because the validity of a block depends on the validity of its parent block, if the execution layer lacks historical data to evaluate the validity of the data, it will obtain these data from the network.

engine_forkchoiceUpdated(Engine fork selection update) is the way that the consensus layer informs the execution layer of the new chain head and final block on the network. If the consensus layer needs the execution layer to generate a new one on the latest chain head block ExecutionPayload, it will send a payloadAttributes  field along with this call .

payloadAttributesField contains the execution engine generates a ExecutionPayloadrelevant information, in particular timestamp(time stamp), random(random number) and feeRecipient(equivalent to the previous coinbase) value. Upon receiving the call, perform the update its link layer header, synchronization, and, if necessary, as required by the start payloadAttributesvalue of a build ExecutionPayload.

engine_getPayload(Engine data acquisition) requested execution level returns its best ExecutionPayload, it has been in the construction process before engine_forkChoiceUpdatedstarting the time-related calls.

This is how the verifier obtains a valid block from its execution engine when it must produce a block. Calling other nodes after receiving the block from the layer to the p2p engine_executePayloadto assess their effectiveness.

……That’s it! With these three new endpoints, the consensus layer and the execution layer can communicate about the state of the chain and transaction data. Now, let us take a deeper look at how the execution engine works.

Execution engine?

As mentioned above, the execution engine is the merged Eth1 client. At this point, any content related to the consensus is removed from their authority. Their main focus becomes state management, block construction, and verification, all of which have been slightly modified. Most of the changes are written in EIP-3675.

First, the merger will require some modifications to the block format. Some fields that are only related to PoW and not PoS will be set 0(or their data structure equivalents). These fields are not and mining ( difficultymixHashnonce) is the ommers ( ommersommersHash) related, they are not present on the PoS. The main line extraDatalength will be limited to 32 bytes.

Second, since the additional issuance of tokens after the merger will only occur on the beacon chain, the execution layer will no longer process block and uncle block rewards. In other words. The execution engine will still be responsible for processing transaction fees. In fact, when it is created ExecutionPayload, the execution engine will ensure that all transactions sender can pay at least the current baseFeePerGas(base cost per unit of gas), and any additional costs will be sent to feeReceipient(the cost of the receiver). Note that this feeReceipientrefers to the “traditional” Ethereum address, not the beacon chain verifier.

Third, when PoS replaces PoW, the execution engine will no longer broadcast blocks. This means abandoned on the p2p networks NewBlockHashes (0x01)and NewBlock (0x07)handlers. Similarly, the executive layer will still be responsible for synchronizing network state, broadcasting transactions and maintaining its transaction pool.

The following figure is also produced by Danny Ryan, which shows the process of the execution layer abandoning PoW and relying on the beacon chain when the merger occurs.

Ethereum Core Developer Conference Update 007

The PoW block is no longer generated, and the beacon chain block starts to include ExecutionPayloads after the merger.

The PoW block is no longer generated, and the beacon chain block starts to include ExecutionPayloads after the merger.

We have now introduced how the client handles blocks and the core components for internal communication after the merger. Now, let us briefly talk about the various relatively “edge” components of the system.

P2P network, user API and synchronization?

As shown in the first chart of this article, after the merger, the execution and beacon chain layers are all in the p2p network. Except that block broadcasting on the execution layer is abandoned, everything on the p2p network remains unchanged: on their respective independent p2p networks, beacon nodes will broadcast proofs, penalties, etc., while the execution layer will share transactions and synchronization status Wait.

Similarly, the user APIs on the beacon chain and the execution layer will remain independent, except for the newly created Engine API.

One component that spans two layers is synchronization. We are developing various synchronization strategies for all possible edge cases before and after the merger. They are still being refined and tested, and may become the subject of in-depth research in the future?

Follow-up?

After the Amphora workshop, the focus of work has been on the improvement of the specifications and the testing of the development test network. In the next few weeks, it is expected that the specifications will be finalized, that is, we do not expect major revisions.

At the same time, the Pithos test network is built and running. There are multiple client combinations to test on it every day. A community meeting is planned for next week to let infrastructure and tool providers quickly understand the merger. see you then??

Ethereum Core Developer Conference Update 007

Various client combinations running on the Pithos testnet

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/ethereum-core-developer-conference-update-007/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Leave a Reply