以太坊 2.0「權(quán)益證明」硬分叉的歷史是復(fù)雜的。它始于向現(xiàn)有執(zhí)行層添加信標(biāo)層，在信標(biāo)層啟動權(quán)益證明共識的同時，執(zhí)行層仍然維持工作量證明（Phase0 和 Altair 硬分叉）。隨后，在 Bellatrix 硬分叉中完全激活 PoS（盡管未啟用提款）。接著，Capella 硬分叉允許提款，完成了驗證者生命周期。最近的硬分叉 Deneb（Dencun（Deneb/Cancun）升級的一部分）對信標(biāo)鏈參數(shù)進行了小幅修訂，例如包含證明的時間窗口、處理自愿退出和驗證者更換限制。Dencun 中的主要變化發(fā)生在執(zhí)行層，推出了 blob 交易、blob gas、用于 blob 的 KZG 承諾，并廢棄了 SELFDESTRUCT 操作。

現(xiàn)在，Prague/Electra （即 Pectra）硬分叉為執(zhí)行和共識層引入了重要的升級。作為 Lido 項目的審計員，我們主要關(guān)注此硬分叉中的共識和質(zhì)押相關(guān)的變化。不過，我們無法忽視 Prague 中的執(zhí)行層變化，因為它們包括影響以太坊網(wǎng)絡(luò)及驗證者的重要特性。讓我們深入這些變化的細節(jié)。

Pectra 的更高層次概述

Electra 為信標(biāo)層引入了眾多功能。主要更新包括：

• 允許驗證者的有效余額在 32 至 2048 ETH 之間變化（而不是固定的 32 ETH）。

• 允許驗證者通過二級「提款」憑證發(fā)起退出（不再需要活躍驗證者密鑰）。

• 更改信標(biāo)層處理 Eth1 存款的方式（不再從存款合約解析事件）。

• 為在信標(biāo)層上處理來自常規(guī) Eth1 合約的請求添加新的通用框架（類似于 Electra 前存款的管理方式）。

與此同時，Prague 對執(zhí)行層引入了以下變化：

• 一個新的預(yù)編譯合約，支持 BLS12-381 曲線以驗證 zkSNARK 證據(jù)（除了流行的 BN254 曲線）。

• 一個新的系統(tǒng)合約，用于存儲和訪問多達 8192 個歷史區(qū)塊哈希（對無狀態(tài)客戶端非常有用）。

• 增加 calldata gas 成本，以減少區(qū)塊大小并鼓勵項目將 calldata 密集型操作（如 rollup）遷移到 Dencun 中引入的 blobs。

• 支持每個 Eth1 區(qū)塊數(shù)量更多的 blobs，并提供 API 以讀取這些數(shù)量。

• 允許 EOA（外部擁有賬戶）擁有自己的賬戶代碼，極大地擴展了 EOA 可以執(zhí)行的操作，如執(zhí)行 multicalls 或?qū)?zhí)行委托給其他地址。

讓我們參考相關(guān)的以太坊改進提案 (EIP)，以便進一步討論：

• EIP-7251: 增加 MAX_EFFECTIVE_BALANCE

• EIP-7002: 執(zhí)行層可觸發(fā)的退出

• EIP-6110: 鏈上提供驗證者存款

• EIP-7549: 將委員會索引移出證明

• EIP-7685: 通用執(zhí)行層請求

• EIP-2537: BLS12-381 曲線操作的預(yù)編譯

• EIP-2935: 在狀態(tài)中保存歷史區(qū)塊哈希

• EIP-7623: 增加 calldata 成本

• EIP-7691: blob 吞吐量增加

• EIP-7840: 向 EL 配置文件添加 blob 調(diào)度

• EIP-7702: 設(shè)置 EOA 賬戶代碼

這些 EIP 中有些主要涉及共識（信標(biāo)）層，而其他與執(zhí)行層有關(guān)。有些跨越兩個層，因為某些操作（如存款和提款）需要在共識和執(zhí)行層之間進行同步變化。由于這種相互依賴性，將 Electra 和 Prague 分開是不切實際的，因此我們將依次回顧每個 EIP，并指定每種情況下受影響的以太坊組件。

EIP-7251: 增加 MAX_EFFECTIVE_BALANCE

參考: EIP-7251

自第一次 Phase0 硬分叉以來，為了準(zhǔn)備以太坊的權(quán)益證明，直到 Electra 之前，驗證者的最大有效余額固定為 32 ETH。激活驗證者 要求 至少為 spec.min_activation_balance（32 ETH）。激活后，驗證者從這個最大有效余額開始，但可以將其有效余額減少到 spec.ejection_balance（16 ETH），并在達到該閾值時 被驅(qū)逐。這種「最小」邏輯在 Electra 中保持不變，但現(xiàn)在 spec.max_effective_balance 已增加到 2048 ETH。因此，驗證者可以在 32 到 2048 ETH 之間存款以激活，所有這些金額都將貢獻其有效余額。這一轉(zhuǎn)變標(biāo)志著從「32ETH- 權(quán)益證明」轉(zhuǎn)向「權(quán)益證明」 :)

這個可變的有效余額現(xiàn)在將被用于：

• 增加 成為區(qū)塊提議者的概率，與有效余額成正比

• 增加 成為同步委員會成員的概率，與有效余額成正比

• 作為計算相對削減和不活躍處罰金額的基礎(chǔ)

前兩個活動是驗證者最有回報的操作。因此，在 Electra 之后，大額質(zhì)押的驗證者將更頻繁地參與區(qū)塊提議和同步委員會，其頻率與他們的有效余額成正比。

另一個影響與削減有關(guān)。所有削減罰金與驗證者的有效余額成正比：

• 「立即」和「延遲」的削減罰金對高額質(zhì)押的驗證者來說更大。

• 與有高額質(zhì)押的被削減驗證者一起的「延遲」削減罰金也更大，因為總質(zhì)押中的「被削減」部分變得 更大。

• 報告有效余額較高的驗證者的舉報者 獲得 更大比例的被削減的質(zhì)押。

Electra 還提出了對削減比例的更改，定義了被削減的驗證者余額的一部分，并由舉報者接收。

接下來是無效性影響。當(dāng)驗證者在活躍時（證明或提議）離線時，無效性分?jǐn)?shù)會累積，導(dǎo)致每個周期施加無效性懲罰。這些懲罰也與驗證者的有效余額成比例關(guān)系。

由于有效余額的增加，驗證者的「更換限制」也發(fā)生了變化。在「Electra 之前」的以太坊中，驗證者通常具有相同的有效余額，退出更換限制定義為「在一個周期內(nèi)，最多不能有 1/65536（spec.churn_limit_quotient）的總質(zhì)押可以退出?！惯@創(chuàng)建了一個「固定」的具有相同質(zhì)押的驗證者退出數(shù)量。然而，在「Electra 之后」，可能出現(xiàn)只有少數(shù)「鯨魚」退出的情況，因為它們代表了總質(zhì)押的一個重要部分。

另一個考慮是單個驗證者實例上許多驗證者密鑰的輪換。大型驗證者目前被迫在一個實例上運行數(shù)千個驗證者密鑰，以適應(yīng)大額質(zhì)押，將其拆分為 32 ETH 部分。隨著 Electra，這種行為不再是強制性的。從財務(wù)角度來看，這一變化影響不大，因為獎勵和概率與質(zhì)押金額線性縮放。因此，100 個每個 32 ETH 的驗證者等同于一個 3200 ETH 的驗證者。此外，多個活躍的驗證者密鑰可以具有相同的 Eth1 取款憑證，允許所有獎勵提取到單個 ETH 地址，從而避免與獎勵合并相關(guān)的 gas 成本。然而，管理大量密鑰會產(chǎn)生額外的管理成本。

聚合驗證者的余額的能力增加了一種新的執(zhí)行層請求類型。之前，我們有存款和取款?，F(xiàn)在，將會有另一種類型：聚合請求。它將兩個驗證者合并為一個。該操作請求將包括源驗證者的公鑰和目標(biāo)公鑰，并將類似于存款和取款進行處理。聚合也將有待處理的請求和余額更換限制，就像存款和取款一樣。

總結(jié)如下：

• 對于小型的獨立驗證者，Electra 引入了自動增加其有效余額（和獎勵）的能力。之前，任何超出 32 ETH 的盈余只能提取，但在 Electra 之后，這一盈余最終將貢獻于其有效余額。然而，有效余額只能按照 spec.effective_balance_increment（1 ETH）的倍數(shù)增加，這意味著增加僅在達到下一個「1 ETH 界限」后發(fā)生。

• 對于大型獨立驗證者，Electra 通過允許將多個活躍驗證者密鑰整合為一個，提供了顯著的管理簡化。雖然這并不會改變游戲規(guī)則，但經(jīng)營一個 1x2048 質(zhì)押無疑比管理 64x32 質(zhì)押要簡單得多。

• 對于流動質(zhì)押提供者，他們從用戶那里收集小額質(zhì)押并在驗證者之間分配，Electra 在質(zhì)押分配方案中增加了更多靈活性，但同時也需要對基于固定 32 ETH 有效余額的驗證者會計進行嚴(yán)重重構(gòu)。

另一個重要話題是驗證者的歷史數(shù)據(jù)和利潤估算，對新參與者尤其相關(guān)，他們試圖評估風(fēng)險和回報。在 Electra 之前（截至本文撰寫時），32 ETH 上限（無論是最小還是最大，實際上）在歷史數(shù)據(jù)中創(chuàng)造了均勻性。所有驗證者的有效余額、獎勵、個體削減懲罰、區(qū)塊提議頻率和其他指標(biāo)都相同。這種均勻性使以太坊能夠在沒有統(tǒng)計異常值的情況下測試其共識機制，從而收集有價值的網(wǎng)絡(luò)行為數(shù)據(jù)。

在 Electra 之后，質(zhì)押的分布將發(fā)生重大變化。大型驗證者在區(qū)塊提議和同步委員會中的參與將更頻繁，在削減事件中將面臨更大的懲罰，并對延遲削減、激活隊列和退出隊列有更大的影響。雖然這可能在數(shù)據(jù)聚合中造成挑戰(zhàn)，但以太坊的共識確保非線性計算是最小的。唯一的非線性組件使用 sqrt(total_effective_balance) 來計算基本獎勵，這適用于所有驗證者。這意味著驗證者獎勵和削減仍然可以在「每 1 ETH」基礎(chǔ)上（或更準(zhǔn)確地說，根據(jù) spec.effective_balance_increment，這可能在未來發(fā)生變化）進行估算。

有關(guān)更多詳細信息，請參閱我們之前關(guān)于驗證者行為的文章 。

EIP-7002：可觸發(fā)的執(zhí)行層退出

參考：EIP-7002

以太坊中的每個驗證者都有兩個密鑰對：一個活躍密鑰和一個取款密鑰。活躍的公共 BLS 密鑰作為驗證者在信標(biāo)鏈中的主要身份，該密鑰對用于簽署區(qū)塊、證明、削減、同步委員會聚合，以及（在此 EIP 之前）自愿退出（以在延遲后啟動驗證者的共識退出）。第二個密鑰對（「取款憑證」）可以是另一個 BLS 密鑰對或常規(guī)的 Eth1 賬戶（私鑰和地址）?，F(xiàn)在，提取到 ETH 地址需要由活躍 BLS 私鑰簽名的取款消息。這一 EIP 進行了更改。

實際上，這兩個（活躍和取款）密鑰對的所有者可以是不同的。驗證者的活躍密鑰負責(zé)驗證職責(zé)：運行服務(wù)器、保持其正常運行等，而取款憑證通常由質(zhì)押所有者控制，質(zhì)押所有者接收獎勵并負責(zé)資金。目前，只有控制取款憑證的質(zhì)押所有者無法啟動驗證者的退出，只能提取獎勵。這種情況允許驗證者的活躍密鑰所有者有效地將驗證者的余額作為「人質(zhì)」握在手中。驗證者可以「預(yù)簽」退出消息并將其交給質(zhì)押所有者，但這種變通方法并不理想。此外，目前提取和退出都需要通過專門的 API 與信標(biāo)層驗證者進行交互。

最佳解決方案是允許質(zhì)押所有者通過常規(guī)智能合約調(diào)用同時執(zhí)行退出和取款操作。這涉及標(biāo)準(zhǔn)的 Eth1 簽名檢查，大大簡化了操作。

這一 EIP 允許質(zhì)押所有者通過從他們的 ETH 地址向?qū)Ｓ弥悄芎霞s發(fā)送標(biāo)準(zhǔn)交易來觸發(fā)取款和退出（類似于現(xiàn)有的使用「存款」合約的存款過程）。提?。ɑ蛟谝瞥銐蛸|(zhì)押時進行的退出）過程如下：

• 質(zhì)押者向系統(tǒng)的「取款」合約發(fā)送取款請求（「in」請求）。

• 合約收取特定的費用（以 ETH 計）以減輕潛在的惡意攻擊，并類似于 EIP-1559，在請求隊列繁忙時費用會增加。

• 合約將「in」取款 / 退出請求保存到其存儲中。

• 當(dāng)一個區(qū)塊被提議到信標(biāo)層時，隊列中的「in」取款 / 退出請求會從存儲中檢索。

• 信標(biāo)層處理「in」請求，與活躍驗證者的余額交互，安排驗證者退出，并形成「out」取款請求。

• 「out」取款請求在執(zhí)行層處理，質(zhì)押者接收他們的 ETH。

雖然存款是在 Eth1 區(qū)塊中觸發(fā)的操作，然后通過「待處理」存款隊列「移動」到信標(biāo)層，但取款則遵循了不同的方案。它們在信標(biāo)層（通過 CLI）上觸發(fā)，然后「移動」到 Eth1 區(qū)塊?，F(xiàn)在，兩種方案將通過相同的通用框架（如下所述）進行操作：在 Eth1 層創(chuàng)建請求，處理「待處理」存款 / 取款 / 合并隊列，并在信標(biāo)層處理。對于像取款這樣的「輸出」操作，輸出隊列也會被處理，結(jié)果將在 Eth1 區(qū)塊中「結(jié)算」。

通過此 EIP，質(zhì)押者可以使用常規(guī) ETH 交易提取并退出他們的驗證者，而無需直接與驗證者 CLI 交互或訪問驗證者的基礎(chǔ)設(shè)施。這大大簡化了質(zhì)押操作，特別是對于大型質(zhì)押提供者。驗證者的基礎(chǔ)設(shè)施現(xiàn)在幾乎可以完全隔離，因為只需維護活躍驗證者的密鑰，而所有質(zhì)押操作可以在其他地方處理。它消除了獨立質(zhì)押者等待活躍驗證者動作的需求，并顯著簡化了像 Community Staking Module 這樣的 Lido 服務(wù)的鏈外部分。

因此，此 EIP 「完成」了質(zhì)押操作，完全將其遷移到 Eth1 層，顯著降低了基礎(chǔ)設(shè)施安全風(fēng)險，并增強了獨立質(zhì)押倡議的去中心化。

EIP-6110：在鏈上供應(yīng)驗證者存款

參考：EIP-6110

目前，存款是通過系統(tǒng)「存款」合約中的事件實現(xiàn)的（如在之前的文章中詳細討論）。合約接受 ETH 和驗證者憑證，發(fā)出「Deposit()」事件，這些事件隨后被解析并轉(zhuǎn)換為信標(biāo)層上的存款請求。該系統(tǒng)有許多缺點：它要求對信標(biāo)鏈層的 eth1data 進行投票，這增加了顯著的延遲。此外，信標(biāo)層需要查詢執(zhí)行層，進一步增加了復(fù)雜性。這些問題在 EIP 中進行了詳細討論。一種更簡單的方法，無需處理許多這些問題，是直接在指定位置將存款請求包括在 Eth1 區(qū)塊中。該機制類似于在之前 EIP 中描述的取款處理流程。

此 EIP 中提出的變化很有前景。eth1data 處理現(xiàn)在可以完全移除，不再需要在 Eth1 側(cè)的事件與信標(biāo)層上存款包含之間進行投票或長時間延遲（當(dāng)前大約為 12 小時）。它還移除了存款合約快照的邏輯。此 EIP 簡化了存款處理，并使其與上述取款處理方案對齊。

對于質(zhì)押者和驗證者來說，這些變化顯著減少了存款與驗證者激活之間的延遲。當(dāng)驗證者被削減時，必要的補充也會更快。

關(guān)于此 EIP 沒有什么更多要說的，除了它移除了過時的邏輯，簡化了流程并為所有相關(guān)人員創(chuàng)造了更好的結(jié)果。

EIP-7685：通用執(zhí)行層請求

參考：EIP-7685

這個 EIP 本應(yīng)在前三個與存款 / 取款 / 合并相關(guān)的 EIP 之前提出，因為它為這些 EIP 打下了基礎(chǔ)。然而，在此處介紹是為了強調(diào)在 Eth1（執(zhí)行）和信標(biāo)（共識）鏈塊（層）之間一致性移動專用數(shù)據(jù)的日益增長的需求。此 EIP 影響兩個層，使通過常規(guī) ETH 交易觸發(fā)的請求處理更高效。目前，我們觀察到：

• Eth1 區(qū)塊中的存款事件被「移動」到信標(biāo)塊進行處理。

• 信標(biāo)塊中的取款請求（使用 CLI）被「移動」到 Eth1 塊進行處理。

• 需要處理驗證者合并，這也是 Eth1->信標(biāo)請求。

這三項操作表明了在執(zhí)行層與信標(biāo)層之間轉(zhuǎn)換時，各種類型請求的一致處理的必要性。此外，我們需要僅使用 Eth1 層觸發(fā)這些操作的能力，因為這將使我們能夠?qū)Ⅱ炞C者的基礎(chǔ)設(shè)施與質(zhì)押管理基礎(chǔ)設(shè)施隔離，從而提高安全性。因此，管理此類請求的通用解決方案既是實際的也是必要的。

此 EIP 為至少三種主要情況建立了框架：存款、取款和合并。這就是為什么早期 EIP 引入了像 WITHDRAWAL_REQUEST_TYPE 和 DEPOSIT_REQUEST_TYPE 這樣的字段，現(xiàn)在合并將添加另一個字段，CONSOLIDATION_REQUEST_TYPE。此外，此 EIP 還可能包括處理此類請求的限制的通用機制（參考常量：PENDING_DEPOSITS_LIMIT，PENDING_PARTIAL_WITHDRAWALS_LIMIT，PENDING_CONSOLIDATIONS_LIMIT）。

雖然此框架的詳細實施細節(jié)仍不可用，但它肯定將包括關(guān)鍵請求類型、完整性機制（例如，哈希和默克爾化請求）以及待處理隊列處理和速率限制。

此 EIP 具有架構(gòu)意義，使 Eth1 能夠通過統(tǒng)一框架觸發(fā)信標(biāo)層中的關(guān)鍵操作。對于最終用戶和項目來說，這意味著在 Eth1 層觸發(fā)的所有請求將在信標(biāo)層上更高效地傳遞和處理。

EIP-2537：BLS12-381 曲線操作的預(yù)編譯

參考：EIP-2537

如果你不想深入了解，可以將 BLS12-381 的預(yù)編譯視為一種復(fù)雜的加密「哈?！共僮?，現(xiàn)在可以在智能合約中使用。對于那些感興趣的人，讓我們進一步探討。

對橢圓曲線如 BLS12-381（及其對應(yīng)的 BN-254）進行的數(shù)學(xué)運算目前主要用于兩個目的：

• BLS 簽名，其中使用一種特殊操作稱為「配對」來驗證這些簽名。BLS 簽名被驗證者廣泛使用，因為它們使多個簽名聚合為一個。驗證者依賴基于 BLS12-381 曲線的 BLS 簽名（盡管它們也可以使用任何支持配對的曲線實現(xiàn)，如 BN254）。

• zkSNARK 證明的驗證，其中配對用于驗證證明。此外，由 Dencun 硬分叉引入的對大塊的 KZG 承諾也使用配對來驗證塊承諾。

如果你想在智能合約中驗證 BLS 簽名或 zkSNARK 證明，你必須計算這些「配對」，這在計算上是非常昂貴的。以太坊已經(jīng)有一個用于 BN254 曲線操作的預(yù)編譯合約（EIP-196 和 EIP-197）。然而，BLS12-381 曲線（現(xiàn)在被認(rèn)為更安全且在今天更廣泛使用）尚未實現(xiàn)為預(yù)編譯。在沒有這樣的預(yù)編譯的情況下，在智能合約中實現(xiàn)配對和其他曲線操作需要大量計算，如 這里 所示，并消耗巨大的 gas（約 ~10^5 到 10^6 gas）。

這個 EIP 為許多潛在應(yīng)用打開了大門，特別是在基于 BLS12-381 曲線的便宜的 BLS 簽名驗證中。這使得實現(xiàn)各種目的的門限方案成為可能。如前所述，以太坊驗證者已經(jīng)使用基于 BLS12-381 的簽名。通過這個 EIP，標(biāo)準(zhǔn)智能合約現(xiàn)在可以高效地驗證聚合的驗證者簽名。這可以簡化共識證明和跨網(wǎng)絡(luò)資產(chǎn)的橋接，因為 BLS 簽名在區(qū)塊鏈中被廣泛使用。門限 BLS 簽名本身允許構(gòu)建許多高效的門限方案，用于投票、去中心化隨機數(shù)生成、多簽等。

更便宜的 zkSNARK 證明驗證反過來將解鎖大量應(yīng)用。許多基于 zkSNARK 的解決方案目前受到高證明驗證成本的阻礙，這使得某些項目幾乎變得不切實際。這個 EIP 有潛力改變這一點。

EIP-2935：在狀態(tài)中保存歷史區(qū)塊哈希

參考：EIP-2935

這個 EIP 提議在區(qū)塊鏈狀態(tài)中存儲 8192 個（約 27.3 小時）歷史區(qū)塊哈希，為無狀態(tài)客戶端（如 rollup）和智能合約提供擴展歷史。它建議保留 BLOCKHASH 操作碼的當(dāng)前行為，維持對 256 個區(qū)塊的限制，同時引入一個專門設(shè)計用于存儲和檢索歷史哈希的新系統(tǒng)合約。這個合約在執(zhí)行層處理區(qū)塊時執(zhí)行 set() 操作。其 get() 方法可供任何人訪問，從環(huán)形緩沖區(qū)中檢索所需的區(qū)塊哈希。

目前，在 EVM 中引用歷史區(qū)塊哈希是可能的，但訪問限制在最近的 256 個區(qū)塊（約 50 分鐘）。然而，有些情況下訪問較舊的區(qū)塊數(shù)據(jù)是至關(guān)重要的，特別是對于跨鏈應(yīng)用（需要證明先前區(qū)塊的數(shù)據(jù)）和無狀態(tài)客戶端，它們定期需要訪問早期區(qū)塊哈希。

這個 EIP 擴展了 rollup 和跨鏈應(yīng)用可用的時間范圍，允許它們在 EVM 中直接訪問歷史數(shù)據(jù)，而無需在外部收集。因此，這些解決方案變得更加穩(wěn)健和可持續(xù)。

EIP-7623：增加 calldata 成本

參考：EIP-7623

calldata 成本調(diào)節(jié)了交易有效負載的可用大小，在某些情況下可能很大（例如，當(dāng)作為參數(shù)傳遞大型數(shù)組或二進制緩沖區(qū)時）。顯著的 calldata 使用主要歸因于 rollup，它們通過包含當(dāng)前 rollup 狀態(tài)的 calldata 發(fā)送有效負載。

將大型、可證明的二進制數(shù)據(jù)引入?yún)^(qū)塊鏈對 rollup 至關(guān)重要。Dencun（Deneb-Cancun）升級為此類用例引入了一項重要創(chuàng)新——blob 交易（EIP-4844）。blob 交易有自己專門的「blob」gas 費用，雖然其主體是暫時存儲的，但其加密證明（KZG 承諾）連同其哈希被整合到共識層中。因此，與使用 calldata 存儲數(shù)據(jù)相比，blob 為 rollup 提供了更好的解決方案。

鼓勵 rollup 將其數(shù)據(jù)轉(zhuǎn)移到 blob 可以通過「胡蘿卜加大棒」的方式實現(xiàn)。降低的 blob gas 費用作為「胡蘿卜」，而這個 EIP 通過增加 calldata 成本作為「杠桿」，從而抑制交易中過度的數(shù)據(jù)存儲。這個 EIP 補充了下一個 EIP-7691（Blob 吞吐量增加），后者提高了每個區(qū)塊允許的 blob 最大數(shù)量。

EIP-7691：blob 吞吐量增加

參考：EIP-7691

在之前的 Dencun 硬分叉中引入了 blob，且「每區(qū)塊」blob 的最大和目標(biāo)數(shù)量的初始值是保守的估計。這是由于預(yù)測 p2p 網(wǎng)絡(luò)將如何處理大型二進制對象在驗證者節(jié)點之間傳播的復(fù)雜性。先前的配置已證明良好，這使得這是測試新值的合適時機。之前，每個區(qū)塊的目標(biāo) / 最大 blob 數(shù)量設(shè)置為 3/6。這些限制現(xiàn)在分別提高到 6/9。

結(jié)合之前的 EIP-7623（增加 calldata 成本），這一調(diào)整進一步激勵了 rollup 將其數(shù)據(jù)從 calldata 轉(zhuǎn)移到 blobs。尋找最佳 blob 參數(shù)的工作仍在繼續(xù)。

EIP-7840：將 blob 調(diào)度添加到 EL 配置文件

參考：EIP-7840

這個 EIP 提議將目標(biāo)和最大「每區(qū)塊」blob 數(shù)量（前面討論過）以及 baseFeeUpdateFraction 值添加到以太坊執(zhí)行層（EL）配置文件中。它還使客戶端能夠通過節(jié)點 API 檢索這些值。此功能對于估算 blob gas 費用等任務(wù)特別有用。

EIP-7702：設(shè)置 EOA 賬戶代碼

參考：EIP-7702

這是一個非常重要的 EIP，將為以太坊用戶帶來重大變化。如我們所知，EOA（外部擁有賬戶）不能有任何代碼，但可以提供交易簽名（tx.origin）。相比之下，智能合約有字節(jié)碼，但不能主動提出「它」的直接簽名。任何需要額外、自動和可驗證邏輯的用戶交互目前只能通過調(diào)用外部合約來執(zhí)行所需的操作。然而，在這種情況下，外部合約成為后續(xù)合約的 msg.sender，使得調(diào)用「來自合約的調(diào)用，而不是用戶」。

這個 EIP 引入了一種新的 SET_CODE_TX_TYPE=0x04 交易類型（我們之前有舊的 0x1 交易、來自柏林和 EIP-1559 升級的新 0x02 交易，以及在 Dencun 中引入的 0x03 blob 交易）。這種新交易類型允許為 EOA 賬戶設(shè)置代碼。實際上，它允許 EOA 「在其自己 EOA 賬戶的上下文中」執(zhí)行外部代碼。從外部視角看，在交易過程中，EOA 好像「借用」來自外部合約的代碼并執(zhí)行它。技術(shù)上，這通過將特殊授權(quán)數(shù)據(jù)元組添加到 EOA 地址的「代碼」存儲中實現(xiàn)（在這個 EIP 之前，這個「代碼」存儲對 EOA 始終是空的）。

目前，這個 EIP 提議的新 0x04 交易類型包含一個數(shù)組：

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

每個元素允許賬戶使用來自指定地址的代碼（來自最后一個有效授權(quán)項）。處理此類交易時，將給定的 EOA 的代碼設(shè)置為特殊的 0xef0100 || 地址值（23 字節(jié)），其中地址指向具有所需代碼的合約，|| 表示連接，0xef0100 表示常規(guī)智能合約無法包含的特殊魔法值（根據(jù) EIP-3541）。這個魔法值確保這個 EOA 不能被視為常規(guī)合約，也不能像常規(guī)合約一樣進行調(diào)用。

當(dāng)這個 EOA 發(fā)起交易時，指定的地址將被用于在該 EOA 的上下文中調(diào)用相應(yīng)的代碼。雖然這個 EIP 的完整實現(xiàn)細節(jié)尚不清楚，但可以確定它將帶來重大變化。

一個主要影響是能夠直接從 EOA 進行多重調(diào)用（multicall）。多重調(diào)用是 DeFi 中的一種持續(xù)趨勢，許多協(xié)議提供了這一特性作為強大的工具（例如 Uniswap V4、Balancer V3 或 Euler V2）。有了這個 EIP，現(xiàn)在可以直接從 EOA 發(fā)起多重調(diào)用。

例如，這一新特性解決了 DeFi 中一個常見問題：approve() + anything() 需要兩筆獨立交易的低效率。這個 EIP 允許通用的「預(yù)授權(quán)」邏輯，使得像 approve(X) + deposit(X) 可以在單筆交易中完成。

能夠「代表」 EOA 委托交易執(zhí)行的另一個優(yōu)勢是贊助的概念。贊助是經(jīng)常討論和高度渴望的特性，以幫助新用戶進入以太坊。

與 EOA 關(guān)聯(lián)的可編程邏輯解鎖了許多可能性，例如實施安全限制、設(shè)置支出上限、強制 KYC 要求等。

當(dāng)然，這一轉(zhuǎn)變也提出了許多設(shè)計問題。一個問題是 chain_id 的使用，它決定了同一簽名是否可以在多個網(wǎng)絡(luò)之間有效，具體取決于其包含或不包含在簽名中。另一個復(fù)雜的問題是使用目標(biāo)代碼的地址與嵌入實際字節(jié)碼之間的選擇。這兩種方法各有獨特的特點和局限性。此外，nonce 的使用在定義權(quán)限是「多用途」還是「單一用途」方面發(fā)揮了關(guān)鍵作用。這些元素影響功能和安全問題，包括批量失效簽名和易用性等方面。Vitalik 在一個討論中提出了這些問題（ 這里 ），值得進一步探索。

值得注意的是，這一變化將影響以太坊的一個安全機制，tx.origin。關(guān)于此 EIP 實施的更多細節(jié)是必要的，但看起來 require(tx.origin == msg.sender) 的行為將會改變。這個檢查一直是確保 msg.sender 是 EOA，而不是合約的最可靠方法。其他方法，例如檢查 EXTCODESIZE（以檢查它是否是一個合約），通常會失敗并且可以被規(guī)避（例如，通過調(diào)用構(gòu)造函數(shù)或在交易后在預(yù)定義地址部署代碼）。這些檢查用于防止重入和閃電貸攻擊，但遠非理想，因為它們還妨礙與外部協(xié)議的集成。在這個 EIP 之后，即使是可靠的 require(tx.origin == msg.sender) 檢查似乎也變得過時。協(xié)議必須通過移除這些檢查來適應(yīng)，因為「EOA」和「合約」之間的區(qū)別將不再適用——現(xiàn)在每個地址都可能有相關(guān)代碼。

傳統(tǒng)的 EOA 和智能合約的分離繼續(xù)模糊。這一 EIP 使以太坊更接近于像 TON 這樣的設(shè)計，在那里每個賬戶本質(zhì)上都是可執(zhí)行代碼。隨著與協(xié)議的交互變得越來越復(fù)雜，使用可編程邏輯來改善最終用戶體驗是這一演進的自然過程。

以上就是解讀以太坊即將到來的硬分叉 Pectra 升級的詳細內(nèi)容，更多關(guān)于Pectra 的更高層次概述的資料請關(guān)注腳本之家其它相關(guān)文章！

你可能感興趣的文章

• 

  穩(wěn)定幣發(fā)行商Triple-A確認(rèn)國庫錢包嚴(yán)重違規(guī)致1180萬美元虧損，內(nèi)控缺陷

  穩(wěn)定幣發(fā)行商Triple-A近日確認(rèn)其國庫錢包存在嚴(yán)重合規(guī)違規(guī)，導(dǎo)致高達1180萬美元的資產(chǎn)虧損,事件暴露出其資金管理與內(nèi)控機制的重大缺陷，引發(fā)市場對穩(wěn)定幣儲備透明度的質(zhì)疑,…

  2026-07-27
• 

  Garden Finance屢遭攻擊禁用官方應(yīng)用，Blockaid報告45萬美元智能合約漏

  Garden Finance因?qū)以夤粜冀霉俜綉?yīng)用，超七成鏈上交易涉被盜資金,同期Blockaid報告45萬美元智能合約漏洞被利用,兩起事件疊加敲響DeFi安全警鐘，用戶須警惕授權(quán)風(fēng)險、…

  2026-07-27
• 

  受歐盟監(jiān)管升級與DMA落地影響，幣安（binance）應(yīng)用在多個歐盟國家Goog

  幣安應(yīng)用在部分歐盟國家Google Play悄然下架,因未獲MiCA牌照，幣安7月起已暫停歐盟服務(wù),疊加歐盟對谷歌DMA重罰8.9億歐元，應(yīng)用商店審核趨嚴(yán)，合規(guī)壓力與渠道收窄雙重夾擊下…

  2026-07-27
• 

  香港加密龍頭HashKey戰(zhàn)略整合：將多家區(qū)域性 交易所合并為統(tǒng)一平臺加速

  香港加密龍頭HashKey宣布戰(zhàn)略整合，將旗下多家區(qū)域性 交易所合并為統(tǒng)一平臺，集中資源強化競爭力,此舉旨在優(yōu)化運營效率、擴大市場覆蓋，加速全球化布局，鞏固其在亞洲加密…

  2026-07-27
• 

  監(jiān)管迷霧籠罩加密行業(yè)：BitMEX業(yè)務(wù)關(guān)閉多起訴訟逼近，《霍德勒文摘》7

  《霍德勒文摘》7月26日聚焦加密行業(yè)監(jiān)管不確定性：市場清晰預(yù)期減弱，BitMEX關(guān)閉相關(guān)業(yè)務(wù)，多起訴訟逼近,監(jiān)管風(fēng)暴加劇行業(yè)合規(guī)壓力，法律風(fēng)險成為當(dāng)前市場焦點，投資者信心…

  2026-07-27
• 

  Coinbase CEO力推AI代理金融新時代，Base鏈AI支付額突破1億美元大關(guān)

  Coinbase CEO Brian Armstrong力推AI代理金融，稱AI代理需專屬金融體系,Base鏈AI支付額突破1億美元，超九成鏈上AI交易在此完成，x402協(xié)議處理逾億筆，USDC為核心結(jié)算工具，…

  2026-07-27
• 

  巴西警方跨國加密貨幣調(diào)查破獲可走 私案，凍結(jié)數(shù)億美元涉毒加密資產(chǎn)

  巴西警方在一項跨國加密貨幣調(diào)查中成功查獲可卡 因 走 私團伙，凍結(jié)數(shù)億美元涉毒資產(chǎn),販 毒集團利用加密貨幣及空殼公司洗錢，涉案規(guī)模龐大,此次行動彰顯巴西打擊加密洗錢與…

  2026-07-27
• 

  傳統(tǒng)金融加速入場：BNY Mellon注冊MiCA，ESMA擴容15家機構(gòu)

  全球托管巨頭BNY Mellon旗下單位正式注冊MiCA合規(guī)框架，傳統(tǒng)金融加速入局,同期ESMA新增15家加密服務(wù)提供者，歐盟持牌機構(gòu)擴容,MiCA全面落地后，合規(guī)競爭加劇，推動加密行業(yè)…

  2026-07-27
• 

  Strategy雙軌資本運作：出售MSTR股票募資數(shù)億，同步回購2500萬美元STRC

  Strategy（MSTR）近期通過ATM計劃出售MSTR普通股募資約5.45億美元，同步斥資2500萬美元回購STRC優(yōu)先股,此舉優(yōu)化資本結(jié)構(gòu)、增強流動性，核心比特幣持倉84.38萬枚未減，戰(zhàn)略…

  2026-07-27
• 

  穿越周期的確定性：火幣 HTX 構(gòu)建 C2C 全生命周期資產(chǎn)服務(wù)體系的過程

  C2C 市場從來不缺流動性，不缺價格競爭,它真正缺的，是一個讓人放心的答案：這筆錢，能安全到賬嗎？火幣 HTX 給出的答案，是行業(yè)里第一個經(jīng)過驗證的“是”…

  2026-07-27