Original Author: AllCoreDevs Updates
Original compilation: H.Forest Ventures, 0x123
Recommended reason:
Recommended reason:
first level title
TL;DR👀
A lot has happened since January and I've been trying to find the time to write it down. Here are the main highlights of this article:
The latest merged testnet Klin has been launched. The Pos transition on top of it exposed some implementation issues, and now the merge tests are all in place.
The next Ethereum upgrade called "Shanghai" is being planned. Including EVM upgrades, beacon chain withdrawals, lower layer 2 fees, and more planned.
Work on the executable specification of the Ethereum execution layer is progressing well. The next step is to coordinate the upgrade process of EL+CL (execution layer + consensus layer).
first level title
Kiln 🔥🧱
Following Kintsugi, the Klin testnet has also recently launched. It makes changes to The Merge spec based on edge cases found on Kintsugi, and some renaming. While it currently looks like The Merge's run spec is almost final, during the transition to run on Klin, some implementation issues arose in several clients. The relevant teams are doubling down on testing to ensure that all implementations are safe and stable. Danny in his latestFinalized postsThis is introduced in .
Beyond that, we're asking the wider developer community to use Klin and make sure their products work as expected. Kudos to Kurtosis, Tenderly, Lido, Uniswap, EthStaker, Infura and Blockdaemon for trying out Klin.
Assuming no critical issues are found, Klin is expected to be the last public testnet to be released. Once we are satisfied with client implementation and infrastructure/tooling readiness, the next step will be to run The Merge on existing testnets (Ropsten, Goerli, Sepolia, etc.).
Like every upgrade, we will maintain continuous testing after the testnet upgrade to ensure the stable operation of the testnet. When we are sure that the testnet is working as expected, we will arrange the transition to the Ethereum mainnet.
While we're getting close to a time that's very exciting for the entire community, a safe transition is The Merge's number one priority, more than running on the target date. This is the most complex upgrade of Ethereum to date. We hope to get it done.
After the specific update timeline of the testnet and mainnet is determined, it will be disclosed through community publications, such as Week in Ethereum, What's New in Eth2, the EF blog, etc. Any currently advertised target date is wrong, as no exact date has been set. In the coming months, please be extra vigilant for potential scams and false announcements.
A note about the difficulty bomb 💣
The difficulty bomb, which was delayed in the Arrow Glacier upgrade (Arrow Glacier) last year, is expected to be able to reflect its impact on the speed of block production around June (click here to viewlatest progress). While it would be ideal to transition to POS before delaying the difficulty bomb upgrade, the following three points are still worth noting:
The impact of the difficulty bomb on block times is gradual. This means that once users feel the impact of the bomb on the network, the block production speed will continue to decrease within 4-8 weeks, but it will not be too slow (probably 14-17 seconds).
Historically, when a bomb is delayed, we choose to delay it for at least 6 months, as we usually plan to do another network upgrade by then. In other words, there are no strict regulations on the delay time of the bomb. It is entirely possible to delay the bomb for one or two months, as long as it is more appropriate than delaying the bomb for more than 6 months.
first level title
"Shanghai" upgrade 🌃
click hereclick here. It is tentatively planned to make three major changes in this upgrade, as well as improve some details. Read on to learn more about this update with us!
EVM (Ethereum Virtual Machine) object format
Over the years, researchers and client developers have worked hard to improve the EVM without breaking current contracts. Last year, the Ipsilon team came up with a really clever idea: provide new functionality to contracts deployed with specific identifiers, but keep existing contracts executing as-is. This is what is now known as the EVM Object Format, or EOF for short.
In the "London" upgrade, we preserved part of this identifier by disabling the deployment of new contracts starting with the 0xEF byte. Before the "London" upgrade went live, a small number of contracts starting with 0xEF were deployed, but now this does not work, we can add a second byte (we call it the "magic" byte) to the 0xEF prefix, and Get a sequence that we can guarantee not to be used by any contract.
EIP-3540 elaborates on this point and highlights the first tangible benefit of this approach: the separation of code and data to facilitate on-chain code verification. This also lays the groundwork for the introduction of new types of parts of contract code that can help enable today's complex functionality, such as abstract accounts, control flow in the EVM, and EIP-3074.
As a companion protocol to EIP-3540, EIP-3670 will enable code verification when EOF contracts are deployed.
Beacon Chain Withdrawal 🏧
Another major feature of the “Shanghai” upgrade is the activation of beacon chain withdrawals. After many proposals, the EIP-4895 protocol we designed has been able to satisfy the client team: the beacon chain can use withdrawal as a push operation.
The meta specification outlines how the whole process works. At a high level, in each slot, the beacon chain can handle a certain number of full or partial withdrawals. Every withdrawal is tracked by a receipt that includes the withdrawal amount, destination address, and a unique index. These withdrawals are then credited to the execution layer as part of the block creation and validation process, similar to how proof-of-work issuance is credited to miners today. Issues tracking the various changes required for the consensus layer can be found in the consensus specification repository. The partial withdrawal option will allow validators to withdraw their accumulated rewards, but will still need to secure a stake of 32 ETH to maintain validation and continue to earn rewards.
Lower Layer 2 Fees📉
In the "Shanghai" upgrade, the last major update we want to accomplish is the lower tier 2 cost. Because from the transaction data or proofs published on the first layer by the second layer, a large part of the end user's transaction fees comes from the amortized gas cost of the data storage on the first layer. Sharding provides a cheaper option for publishing data at the second layer, and while the specification seems to be settled, a full sharding implementation is not ready yet.
In the meantime, there are two options for reducing these costs: reduce the cost of CALLDATA on mainnet, or implement "raw sharding", possibly by introducing a new transaction type on Ethereum called Shard Blob Transactions.
REDUCING COSTS WITH CALLDATA
The easiest way to reduce transaction fees on the second layer is to reduce storage costs on the first layer. EIP-4488 proposes to do so, reducing the cost of CALLDATA from 16 gas per byte to 3 gas per byte. Reduced storage costs at Tier 1 in turn reduce costs at Tier 2 [1].
While reducing gas costs is a simple change, it also has some second order effects. First, adding CALLDATA to a block makes the block larger. To balance this, EIP proposes to limit the number of CALLDATA in each block. Second, even if an upper limit is set, this EIP will increase the growth rate of data on the historical chain at the execution layer. To address the above issues, EIP-4444 proposes that out-of-band historical data retrieval needs to be developed, and that guarantees about historical data on the Ethereum peer-to-peer network need to be changed.
Although the data on the historical chain is gradually increasing, running this EIP means that we need to deal with this issue more urgently after it goes online. Besides that, a small part of this EIP will be reused in the full sharding implementation. It's mostly a temporary solution. In other words, EIP-4488 is a relatively simple update, but it does have a significant effect on reducing the cost of the second layer.
Shard Blob Transactions
Another proposal, EIP-4844[2], introduces Shard Blob Transactions, which brings us closer to a complete sharding deployment solution. As with beacon chain withdrawals, the proposal has a meta specification that links to the consensus layer specification and other resources.
On a deeper level, this new transaction type will consist of a commitment to a block of data propagated on the beacon chain. This proposal can be viewed as "mini-sharding", and instead of relying on data availability sampling, every node in the network needs to validate all data in the blob. Just like in the case of full sharding, the data in these bolbs is only guaranteed to be available on the network for a certain period of time, not permanently stored. To keep the manageability of node requirements, blob data is limited to 1MB/socket, while full shards are 16mb/socket.
EIP-4844 will lay the groundwork for full sharding. It is worth noting that all future changes will be limited to the consensus layer. From the perspective of the execution layer, the shards are up and running.
Note:
Note:
click hereclick here。
[2] EIP-4488 and EIP4844 have very similar numbers in competing proposals, which is very frustrating.
detail improvement
In addition to the above three major improvements, some minor improvements have also been considered in the "Shanghai" upgrade, namely:
EIP-3651, reducing the gas cost of accessing Coinbase addresses, and fixing the vulnerability in EIP-2929.
EIP-3860, limits the size of inicode and introduces gas metering for fields.
EIP-3855, adds a new opcode PUSH0 which, as you might expect, pushes a "0" onto the EVM stack.
click hereclick here). EOF, beacon chain withdrawals, and layer 2 fee reductions have made the "Shanghai" upgrade one of the biggest updates to date, so we need to work really hard right now to prioritize what to upgrade.
first level title
Ethereum Execution Layer Specification (EELS) 📜
As you noticed in reading above, several proposals for the "Shanghai" upgrade span the executive and consensus layers. As a rule of thumb, we use different processes to introduce changes at each layer.
At the executive level, the core EIP contains improved specifications. The Ethereum Yellow Paper is the reference specification for the network, but it is usually updated accordingly after the upgrade goes online, and sometimes there is even a significant delay. This means that for the execution layer, the Yellow Book plus the corresponding EIP protocol is the effective specification for the execution layer.
At the consensus layer, an executable specification is used as a reference, in which changes are directly specified, which can then be used to generate tests for the changes.
Therefore, although the community can understand the execution layer process well (and we also provide easy-to-reference data descriptions), it is still not ideal from a technical point of view. Conversely, while the consensus layer process is technically greener, it is harder for large communities to follow. Fortunately, work on EELS (Executable Specification for the Ethereum Execution Layer) has already begun.
Having executable specifications at both the execution and consensus layers allows us to coordinate the change process on both layers. While there are still many kinks to be ironed out, discussions have begun on how best to accomplish the migration. The Ethereum Magicians thread is now devoted to this very topic. While EELS is still under development, we may be able to use it in parallel to the current process during the "Shanghai" upgrade.
first level title
Agreement union 💰
I'd like to end by talking about the also important Protocol Guild, which now has a full interpreter website. Compensation for protocol maintainers has been a hot topic lately, and the protocol union wants to be part of the solution to this problem. Disclosure Statement: I am a member of, and receive funding from, the Pact Union.
You can break down compensation into three areas: base salary, aligned incentives, and potential upside. Currently, the base salaries of client developers and researchers are paid by their respective employers. While some of this may be in the form of equity incentives, the Ethereum Foundation announced a customer incentive plan of 39,000 ETH last year to ensure that all client teams have a large stake in Ethereum.
The protocol union differs from the basic compensation and incentive plan in that it aims to provide its members with tokens for various projects built on top of ethereum, rather than ethereum itself. The protocol union is made up of protocol engineers, researchers, and a small number of people like me who are engaged in protocol coordination. Currently has about 100 members.
In short, unions allow sponsors to donate tokens, which are then transferred to recipients over time. The list of recipients can be updated, thus allowing new contributors to be added and previous contributors to be removed on a regular basis.
Protocol unions are still in an early experimental stage, but if successful, they could complement grassroots-focused initiatives such as Gitcoin and Retroactive Public Goods Funding.
After successfully securing Gitcoin funding, the next step for the protocol union is to test the smart contract architecture. At the same time, outreach to initial donors will begin. The plan is to run the protocol union on a limited donation basis for approximately 1 year to ensure that both technical and governance components are running smoothly. Hopefully this pilot demonstrates that we can create new mechanisms for coordinating public goods funding on Ethereum.
Next step plan ✅
Our main priority remains merging, with a renewed focus on testing. Over the next month, we hope to finish the implementation, run multiple short-term development networks, and gather feedback from application, infrastructure, and tooling providers. Everything else ("Shanghai" upgrades, enforcing norms, negotiating unions) will continue as well.
We expect another update in a month or two. At the same time, we can alsoDevconnectTranslator's note:
Translator's note:
Official account: H Forest
Follow us:
Our Twitter: @Forest_Ventures
Our mirrors:H.Forest
Official account: H Forest
