Ringkasan mesyuarat terbaharu pembangun teras Ethereum: Pelancaran peningkatan Pectra, perbincangan kemajuan pelaksanaan PeerDAS

.

Nota editor:

Ether The All Core Developers Consensus Call (ACDC) diadakan setiap dua minggu untuk membincangkan dan menyelaraskan perubahan pada Lapisan Konsensus Ethereum (CL). Ini adalah panggilan persidangan ACDC ke-138 Persidangan ini merangkumi pelancaran Pectra Devnet 1, perubahan pada badan blok suar dan struktur API enjin, dan kemasukan Cadangan Penambahbaikan Ethereum (EIP) kontena yang stabil ke dalam Pectra, iaitu EIP 7688 dan EIP 7495. dan kemas kini PeerDAS dan topik lain. Semasa mesyuarat itu, pemaju menyemak kesediaan untuk naik taraf Pectra dan membincangkan beberapa soalan terbuka dan cadangan mengenai pelaksanaan PeerDAS. Di samping itu, pemaju Nimbus Etan Kissling turut berkongsi kemajuan kerja pelaksanaan EIP 7688 dan EIP 7495, dengan menekankan kepentingan cadangan ini untuk menaik taraf kaedah siri data Ethereum. Christine Kim, Naib Presiden Penyelidikan di Galaxy Digital, merekodkan perkara penting mesyuarat ini secara terperinci, dan BlockBeats menyusun teks asal seperti berikut: Pada 25 Julai 2024, pemaju Ethereum mengadakan Konsensus Pembangun Semua Teras ke-138 (ACDC ) melalui Zoom )Mesyuarat. Persidangan ACDC ialah siri mesyuarat dua minggu sekali di mana pembangun membincangkan dan menyelaraskan perubahan kepada Lapisan Konsensus Ethereum (CL), juga dikenali sebagai Rantaian Beacon. Sesi minggu ini dihoskan oleh penyelidik Yayasan Ethereum (EF) Alex Stokes. Pemaju membincangkan perkara berikut: ·Pelancaran Pectra Devnet 1
·Perubahan pada badan blok suar dan struktur API enjin·Penyertaan Cadangan Penambahbaikan Ethereum Kontena Stabil (EIP) ke dalam Pectra, dikenali sebagai EIP 7689 dan EIP 7689 · Kemas kini kepada PeerDAS dan jadual pelaksanaannya di mainnet
Pectra Devnet 1 Pectra Devnet 1 disiarkan secara langsung pada hari Selasa, 23 Julai. Walau bagaimanapun, rangkaian tidak stabil. Parithosh Jayanthi, seorang jurutera DevOps di Yayasan Ethereum, berkata pelanggan Erigon menghadapi masalah sejurus selepas devnet dilancarkan. Kemudian, transaksi EIP 7702 yang disiarkan di devnet menyebabkan rangkaian itu berpecah kepada tiga keadaan. Pembangun sedang menyahpepijat klien dan menyelesaikan isu perpecahan rantaian.
Memperkenalkan ExecutionPayloadEnvelope
Pemaju Prysm Potuz mencadangkan penambahbaikan besar pada struktur beban pelaksanaan blok beacon, serta pelarasan yang sepadan dengan API enjin. Cadangan ini bertujuan untuk memudahkan proses menyimpan dan memproses data peralihan keadaan oleh pelanggan Lapisan Konsensus (CL). Dengan pelaksanaan peningkatan Pectra, pelanggan CL memerlukan akses kepada bahagian tertentu beban pelaksanaan untuk melaksanakan peralihan keadaan dengan betul. Walau bagaimanapun, reka bentuk sedia ada menyebabkan pelanggan ini mengabaikan beberapa maklumat yang tidak penting dalam beban pelaksanaan.
Peningkatan Pectra memerlukan pelanggan CL sama ada meminta data peralihan keadaan yang diperlukan daripada Lapisan Pelaksanaan (EL) atau menyimpan bahagian kritikal blok secara setempat. Untuk meningkatkan kecekapan pelanggan CL selepas naik taraf Pectra, Potuz mencadangkan untuk memperkenalkan struktur baharu yang dipanggil "bind_execution_payload_envelope" untuk menyimpan maklumat penting yang diperlukan secara berpusat untuk peralihan keadaan pelaksanaan. Penambahbaikan sedemikian akan meningkatkan kelajuan dan kecekapan pelanggan CL dengan ketara dalam mengira peralihan keadaan. Beliau juga menekankan bahawa pelarasan ini akan memastikan keserasian dengan naik taraf rangkaian masa hadapan seperti format Simple Serialization (SSZ).

Mark Mackey, the developer of the Lighthouse project, warned that if these changes are not implemented, the performance of the CL client on the Pectra testnet may be affected. Mikhail Kalinin, a developer on the Teku project, expressed caution, questioning whether protocol changes were really necessary to address the complexity of implementing EIPs in Pectra. Potuz insists that there are fundamental problems with the existing protocol design and needs to be corrected. He pointed out: "The current design is conceptually flawed. It mixes data that is critical to CL state transitions with completely unrelated data at the same level and in the same message. Therefore, I think the current design is wrong, We are working hard to correct this error."

Stokes encourages developers to continue discussing this proposal on GitHub.

Engine API update for Devnet 2

Related to the above discussion, Geth developer "Lightclient" proposed another change to the engine API. This change is intended to make block conversion easier for EL clients. EL clients determine the block version by interpreting null and void fields in the block. However, due to Prague's EIP 7685, without a fork schedule, EL clients will not be able to differentiate block versions based on these fields. To avoid the overhead of referencing a schedule of past upgrades, Lightclient proposes to unify all requests into a single type in the engine API, which EL can pass to CL for interpretation.

Lightclient points out that the interpretation of chunks differs between EL and CL, and that in this case CL is better suited to represent the request data. "When we're dealing with the blocks themselves, there's no concept of, 'This is a Bellatrix block,' like on CL. I think you guys did a good job of distinguishing between different types of forked blocks. But in On EL, I think this is how almost all clients are implemented, we have a block that represents all block types, and we use the presence of, say, a null value to determine whether that [fork] is active."

Nimbus developer "Dustin" opposed this proposal, saying that Lightclient's proposal did not fully address the complexity of block interpretation on EL and CL. "It just moves the complexity and confusion from the EL to the CL, and both places are viable. Moving it to the CL doesn't solve the problem. ... It just moves the problem," Dustin said.

Stokes asserts that CL is better suited to handle the interpretation of requests and recommends that developers take a closer look at the engine API changes proposed by Potuz and Lightclient on GitHub.

EIP 7688 and 7495 in Pectra

Nimbus developer Etan Kissling has been pushing for an update to the Ethereum serialization method to SSZ. For Pectra's purposes, he identified two intermediate EIPs, 7688 and 7495, to introduce data structures that smart contract developers can rely on to be compatible with future SSZ-related changes. Kissling noted that he already has support from liquid staking pools like Rocketpool, as well as other client teams like Teku and Lodestar.

Stokes warns CL client team not to add new EIPs in Pectra. "Pectra is already very big, especially if we end up with PeerDAS in the fork. At some point we need to be very realistic about the size of the fork and the risks it poses. Again, I agree with Etan's There are reasons for this feature to be valuable in a vacuum, but I think this is one of the biggest hard forks we've ever done, or the biggest, and that shouldn't be taken lightly," he said.

Developers have raised some concerns about when these EIPs can actually be added to the Pectra devnet, as Pectra devnet s have not yet incorporated many EIPs such as PeerDAS and EOF. In this regard, Jayanthi recommends first clearly deciding whether developers should include these EIPs in upgrades. Jayanthi also warned that there is a bottleneck when testing CL and EL EIP together on a devnet. He wrote in a Zoom chat: "Shipping 10 direct EIPs together would make it very complicated to fork and test in combinations. And we don't just have direct EIPs."

Mackey shared that like the EigenLayer team of application developers are trying to figure out what is planned to be activated in Pectra, and the continued lack of clarity on these two EIPs is an impediment to their efforts. Lighthouse developer Sean Anderson recommends getting more input from application developers on Ethereum about these EIPs to determine how critical they are to the application.

Stokes suggests revisiting this discussion at a later date so that developers can focus on resolving Pectra Devnet 1 issues.

PeerDAS Update

Developers had an in-depth discussion on the latest progress of PeerDAS. Anderson reports that the Consensus Layer (CL) client team is actively fixing issues discovered in the previous round of PeerDAS’s devnet and ensuring the stability of the implementation before launching a new devnet. Lodestar and EthereumJS developer Gajinder Singh said that based on feedback from a recent PeerDAS implementers meeting, the community is interested in integrating PeerDAS in the next Pectra devnet.

Stokes proposed that based on discussions with the Ethereum Foundation (EF) research team and other developers, the sampling function may need to be omitted when initially activating PeerDAS on the main network to reduce the complexity of the implementation. He explained that the complete implementation of PeerDAS involves three key functions: distribution, sampling and reconstruction. "Currently, the PeerDAS specification in Pectra covers these three tasks. My intuition tells me that the sampling function is probably the biggest point of complexity in the implementation. If sampling does pose an insurmountable challenge, we could consider implementing it in Pectra Increase the number of blobs while reducing or adjusting the scope of PeerDAS," Stokes explained.

Stokes promised that he would develop a formal proposal on the idea and explore it further with the developer community. Singh supports this. Stokes also recommended that PeerDAS be formally included in the Pectra upgrade. In response, Jayanthi asked if this meant redefining the PeerDAS specification based on the Pectra specification, noting that merging PeerDAS and Pectra devnets might complicate debugging efforts as both are unstable. He suggested that the independence of the two workflows should be maintained until the specification is stable. Teku developer Enrico Del Fante agrees with Jayanthi.

Stokes noted that many developers focused on PeerDAS implementation were unable to attend the meeting. He proposed to continue discussing future steps for PeerDAS at the next PeerDAS implementers meeting.

Added BeaconBlocksByRange V3

The developer of the Lighthouse project "Dapplion" has proposed an improvement plan to help clients synchronize to the main chain more effectively in the event of a long-term chain split. He pointed out that the existing [BeaconBlocksByRange V2] RPC protocol has certain limitations: "When you need to synchronize a long-forked block and are not sure which branch is the main chain, according to the current protocol, you only need to submit A slot range, the node will return the block it thinks is correct. Although you can query this information through status messages, this process is asynchronous and may cause some problems. Although there are currently no serious forks on the mainnet. situation, but if a similar incident occurs in the future, this will be an issue that needs to be solved."

Dapplion further explained that the solution he proposed is relatively simple and may even be included in the upcoming Pectra upgrade. Although these improvements are not imminent, Stokes encouraged developers in attendance to carefully review the proposal and share their thoughts and suggestions on GitHub.

Atas ialah kandungan terperinci Ringkasan mesyuarat terbaharu pembangun teras Ethereum: Pelancaran peningkatan Pectra, perbincangan kemajuan pelaksanaan PeerDAS. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!