解析以太坊即將到來的硬分叉 - Pectra 升級

介紹

在我們之前的文章中，我們詳細回顧了以太坊驗證者的生命週期，討論了與即將到來的 Electra 硬分叉相關的多個方面。現在，是時候關注即將到來的 Electra 和 Prague 升級中的變化，並詳細解釋它們。

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

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

Pectra 的更高層次概述

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

• 允許驗證者的有效餘額在 32 至 2048 ETH 之間變化（而不是固定的 32 ETH）。
• 允許驗證者通過二級「提款」憑證發起退出（不再需要活躍驗證者密鑰）。
• 更改信標層處理 Eth1 存款的方式（不再從存款合約解析事件）。
• 為在信標層上處理來自常規 Eth1 合約的請求添加新的通用框架（類似於 Electra 前存款的管理方式）。

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

• 一個新的預編譯合約，支持 BLS12-381 曲線以驗證 zkSNARK 證據（除了流行的 BN254 曲線）。
• 一個新的系統合約，用於存儲和訪問多達 8192 個歷史區塊哈希（對無狀態客戶端非常有用）。
• 增加 calldata gas 成本，以減少區塊大小並鼓勵項目將 calldata 密集型操作（如 rollup）遷移到 Dencun 中引入的 blobs。
• 支持每個 Eth1 區塊數量更多的 blobs，並提供 API 以讀取這些數量。
• 允許 EOA（外部擁有賬戶）擁有自己的賬戶代碼，極大地擴展了 EOA 可以執行的操作，如執行 multicalls 或將執行委託給其他地址。

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

• EIP-7251: 增加 MAX_EFFECTIVE_BALANCE
• EIP-7002: 執行層可觸發的退出
• EIP-6110: 鏈上提供驗證者存款
• EIP-7549: 將委員會索引移出證明
• EIP-7685: 通用執行層請求
• EIP-2537: BLS12-381 曲線操作的預編譯
• EIP-2935: 在狀態中保存歷史區塊哈希
• EIP-7623: 增加 calldata 成本
• EIP-7691: blob 吞吐量增加
• EIP-7840: 向 EL 配置文件添加 blob 調度
• EIP-7702: 設置 EOA 賬戶代碼

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

EIP-7251: 增加 MAX_EFFECTIVE_BALANCE

參考: EIP-7251

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

這個可變的有效餘額現在將被用於：

• 增加 成為區塊提議者的概率，與有效餘額成正比
• 增加 成為同步委員會成員的概率，與有效餘額成正比
• 作為計算相對削減和不活躍處罰金額的基礎

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

另一個影響與削減有關。所有削減罰金與驗證者的有效餘額成正比：

• 「立即」和「延遲」的削減罰金對高額質押的驗證者來說更大。
• 與有高額質押的被削減驗證者一起的「延遲」削減罰金也更大，因為總質押中的「被削減」部分變得 更大。
• 報告有效餘額較高的驗證者的舉報者 獲得 更大比例的被削減的質押。

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

接下來是無效性影響。當驗證者在活躍時（證明或提議）離線時，無效性分數會累積，導致每個週期施加無效性懲罰。這些懲罰也與驗證者的有效餘額成比例關係。

由於有效餘額的增加，驗證者的「更換限制」也發生了變化。在「Electra 之前」的以太坊中，驗證者通常具有相同的有效餘額，退出更換限制定義為「在一個週期內，最多不能有 1/65536（spec.churn_limit_quotient）的總質押可以退出。」這創建了一個「固定」的具有相同質押的驗證者退出數量。然而，在「Electra 之後」，可能出現只有少數「鯨魚」退出的情況，因為它們代表了總質押的一個重要部分。

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

聚合驗證者的餘額的能力增加了一種新的執行層請求類型。之前，我們有存款和取款。現在，將會有另一種類型：聚合請求。它將兩個驗證者合併為一個。該操作請求將包括源驗證者的公鑰和目標公鑰，並將類似於存款和取款進行處理。聚合也將有待處理的請求和餘額更換限制，就像存款和取款一樣。

總結如下：

• 對於小型的獨立驗證者，Electra 引入了自動增加其有效餘額（和獎勵）的能力。之前，任何超出 32 ETH 的盈餘只能提取，但在 Electra 之後，這一盈餘最終將貢獻於其有效餘額。然而，有效餘額只能按照 spec.effective_balance_increment（1 ETH）的倍數增加，這意味著增加僅在達到下一個「1 ETH 界限」後發生。
• 對於大型獨立驗證者，Electra 通過允許將多個活躍驗證者密鑰整合為一個，提供了顯著的管理簡化。雖然這並不會改變遊戲規則，但經營一個 1x2048 質押無疑比管理 64x32 質押要簡單得多。
• 對於流動質押提供者，他們從用戶那裡收集小額質押並在驗證者之間分配，Electra 在質押分配方案中增加了更多靈活性，但同時也需要對基於固定 32 ETH 有效餘額的驗證者會計進行嚴重重構。

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

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

有關更多詳細信息，請參閱我們之前關於驗證者行為的文章 。

EIP-7002：可觸發的執行層退出

參考：EIP-7002

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

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

最佳解決方案是允許質押所有者通過常規智能合約調用同時執行退出和取款操作。這涉及標準的 Eth1 簽名檢查，大大簡化了操作。

這一 EIP 允許質押所有者通過從他們的 ETH 地址向專用智能合約發送標準交易來觸發取款和退出（類似於現有的使用「存款」合約的存款過程）。提取（或在移除足夠質押時進行的退出）過程如下：

• 質押者向系統的「取款」合約發送取款請求（「in」請求）。
• 合約收取特定的費用（以 ETH 計）以減輕潛在的惡意攻擊，並類似於 EIP-1559，在請求隊列繁忙時費用會增加。
• 合約將「in」取款 / 退出請求保存到其存儲中。
• 當一個區塊被提議到信標層時，隊列中的「in」取款 / 退出請求會從存儲中檢索。
• 信標層處理「in」請求，與活躍驗證者的餘額交互，安排驗證者退出，並形成「out」取款請求。
• 「out」取款請求在執行層處理，質押者接收他們的 ETH。

雖然存款是在 Eth1 區塊中觸發的操作，然後通過「待處理」存款隊列「移動」到信標層，但取款則遵循了不同的方案。它們在信標層（通過 CLI）上觸發，然後「移動」到 Eth1 區塊。現在，兩種方案將通過相同的通用框架（如下所述）進行操作：在 Eth1 層創建請求，處理「待處理」存款 / 取款 / 合併隊列，並在信標層處理。對於像取款這樣的「輸出」操作，輸出隊列也會被處理，結果將在 Eth1 區塊中「結算」。

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

因此，此 EIP 「完成」了質押操作，完全將其遷移到 Eth1 層，顯著降低了基礎設施安全風險，並增強了獨立質押倡議的去中心化。

EIP-6110：在鏈上供應驗證者存款

參考：EIP-6110

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

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

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

關於此 EIP 沒有什麼更多要說的，除了它移除了過時的邏輯，簡化了流程併為所有相關人員創造了更好的結果。

EIP-7685：通用執行層請求

參考：EIP-7685

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

• Eth1 區塊中的存款事件被「移動」到信標塊進行處理。
• 信標塊中的取款請求（使用 CLI）被「移動」到 Eth1 塊進行處理。
• 需要處理驗證者合併，這也是 Eth1->信標請求。

這三項操作表明了在執行層與信標層之間轉換時，各種類型請求的一致處理的必要性。此外，我們需要僅使用 Eth1 層觸發這些操作的能力，因為這將使我們能夠將驗證者的基礎設施與質押管理基礎設施隔離，從而提高安全性。因此，管理此類請求的通用解決方案既是實際的也是必要的。

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

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

此 EIP 具有架構意義，使 Eth1 能夠通過統一框架觸發信標層中的關鍵操作。對於最終用戶和項目來說，這意味著在 Eth1 層觸發的所有請求將在信標層上更高效地傳遞和處理。

EIP-2537：BLS12-381 曲線操作的預編譯

參考：EIP-2537

如果你不想深入瞭解，可以將 BLS12-381 的預編譯視為一種複雜的加密「哈希」操作，現在可以在智能合約中使用。對於那些感興趣的人，讓我們進一步探討。

對橢圓曲線如 BLS12-381（及其對應的 BN-254）進行的數學運算目前主要用於兩個目的：

• BLS 簽名，其中使用一種特殊操作稱為「配對」來驗證這些簽名。BLS 簽名被驗證者廣泛使用，因為它們使多個簽名聚合為一個。驗證者依賴基於 BLS12-381 曲線的 BLS 簽名（儘管它們也可以使用任何支持配對的曲線實現，如 BN254）。
• zkSNARK 證明的驗證，其中配對用於驗證證明。此外，由 Dencun 硬分叉引入的對大塊的 KZG 承諾也使用配對來驗證塊承諾。

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

這個 EIP 為許多潛在應用打開了大門，特別是在基於 BLS12-381 曲線的便宜的 BLS 簽名驗證中。這使得實現各種目的的門限方案成為可能。如前所述，以太坊驗證者已經使用基於 BLS12-381 的簽名。通過這個 EIP，標準智能合約現在可以高效地驗證聚合的驗證者簽名。這可以簡化共識證明和跨網絡資產的橋接，因為 BLS 簽名在區塊鏈中被廣泛使用。門限 BLS 簽名本身允許構建許多高效的門限方案，用於投票、去中心化隨機數生成、多籤等。

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

EIP-2935：在狀態中保存歷史區塊哈希

參考：EIP-2935

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

目前，在 EVM 中引用歷史區塊哈希是可能的，但訪問限制在最近的 256 個區塊（約 50 分鐘）。然而，有些情況下訪問較舊的區塊數據是至關重要的，特別是對於跨鏈應用（需要證明先前區塊的數據）和無狀態客戶端，它們定期需要訪問早期區塊哈希。

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

EIP-7623：增加 calldata 成本

參考：EIP-7623

calldata 成本調節了交易有效負載的可用大小，在某些情況下可能很大（例如，當作為參數傳遞大型數組或二進制緩衝區時）。顯著的 calldata 使用主要歸因於 rollup，它們通過包含當前 rollup 狀態的 calldata 發送有效負載。

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

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

EIP-7691：blob 吞吐量增加

參考：EIP-7691

在之前的 Dencun 硬分叉中引入了 blob，且「每區塊」blob 的最大和目標數量的初始值是保守的估計。這是由於預測 p2p 網絡將如何處理大型二進制對象在驗證者節點之間傳播的複雜性。先前的配置已證明良好，這使得這是測試新值的合適時機。之前，每個區塊的目標 / 最大 blob 數量設置為 3/6。這些限制現在分別提高到 6/9。

結合之前的 EIP-7623（增加 calldata 成本），這一調整進一步激勵了 rollup 將其數據從 calldata 轉移到 blobs。尋找最佳 blob 參數的工作仍在繼續。

EIP-7840：將 blob 調度添加到 EL 配置文件

參考：EIP-7840

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

EIP-7702：設置 EOA 賬戶代碼

參考：EIP-7702

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

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

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

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

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

當這個 EOA 發起交易時，指定的地址將被用於在該 EOA 的上下文中調用相應的代碼。雖然這個 EIP 的完整實現細節尚不清楚，但可以確定它將帶來重大變化。

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

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

能夠「代表」 EOA 委託交易執行的另一個優勢是贊助的概念。贊助是經常討論和高度渴望的特性，以幫助新用戶進入以太坊。

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

當然，這一轉變也提出了許多設計問題。一個問題是 chain_id 的使用，它決定了同一簽名是否可以在多個網絡之間有效，具體取決於其包含或不包含在簽名中。另一個複雜的問題是使用目標代碼的地址與嵌入實際字節碼之間的選擇。這兩種方法各有獨特的特點和侷限性。此外，nonce 的使用在定義權限是「多用途」還是「單一用途」方面發揮了關鍵作用。這些元素影響功能和安全問題，包括批量失效簽名和易用性等方面。Vitalik 在一個討論中提出了這些問題（ 這裡 ），值得進一步探索。

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

傳統的 EOA 和智能合約的分離繼續模糊。這一 EIP 使以太坊更接近於像 TON 這樣的設計，在那裡每個賬戶本質上都是可執行代碼。隨著與協議的交互變得越來越複雜，使用可編程邏輯來改善最終用戶體驗是這一演進的自然過程。

結論

布拉格 /Electra（Pectra）升級定於 2025 年 3 月。其最顯著的計劃變更包括：

• 可變驗證者有效質押，最高可達 2048 ETH，這將顯著改變質押分佈、驗證者時間表，並通過整合較小的質押簡化大型質押提供者的管理
• 改進執行層與共識層的交互，簡化 Eth1 執行塊與信標鏈塊之間的數據交換。這將大大簡化存款、激活、提取和退出，加快這些過程，為共識層與執行層之間的進一步交互奠定基礎
• 在智能合約中支持通過新的「配對友好」BLS12-381 預編譯直接進行更便宜的 BLS 簽名和 zkSNARK 驗證
• 鼓勵 Rollups 通過增加 blob 交易閾值和提高 calldata 成本採用 blob 交易
• 使 EOA 充當可編程賬戶，賦予其多重調用、贊助和其他高級功能

正如你所看到的，Pectra 將對質押和共識層，以及執行層的最終用戶體驗產生重大影響。雖然我們無法在此階段通過代碼詳細分析所有這些變化，因為開發仍在進行中，我們將在未來的文章中涵蓋這些更新。