Ethereum Pectra 硬分叉介紹
作者：NICLin，Medium
Pectra硬分叉預計于2025年3月啟動主網部署。Pectra升級包含11個技術協議（EIP），它們分別是：
EIP-2537: BLS12-381曲線操作預編譯
EIP-2935: 在State中保存歷史區塊哈希值
EIP-6110: 提供鏈上 validatordeposits
EIP-7002: 執行層觸發退出
EIP-7251: 增加theMAX_EFFECTIVE_BALANCE
EIP-7549: 將 committee 索引移至驗證之外
EIP-7623:增加calldata成本
EIP-7685:通用執行層請求
EIP-7691:增加Blob吞吐量
EIP-7702:設置EOA帳戶代碼
EIP-7840: 在EL 配置文件中添加Blob計劃 質押相關的技術協議
EIP-6110:BLS12-381曲線操作預編譯
簡化用戶參與質押的處理流程，讓等待時間大幅縮短。
用戶參與質押的方式是在執行層上存入32個ETH并由事件日志（EventLog）記錄，接著共識層執行解析事件日志來判斷是否有人參與質押，然后參與質押的用戶就成為驗證者。
不過，共識層的驗證者首先需要針對哪一個時間點存入達成共識，否則，會發現有些驗證者看到5個新的存入，而有些驗證者只看到3個，因此共識層驗證者們會對要參考哪一個執行層區塊（eth1data）進行投票，確保大家看到的是一樣的執行層區塊。
不過，一開始設計時為了避免執行層出現重大錯誤導致鏈分叉，所以參考的執行層區塊（eth1data）會是一個約10多個小時以前的執行層區塊，確保當重大錯誤發生時，共識層的開發者們有足夠的時間反應處理，不過這也導致參與質押最快也要等上10多個小時才會生效。
△每一個區塊都會指向一個母區塊，所以可以一路往前證明歷史中的任何一個區塊。
假設目前是編號為10000的內存塊，詐欺挑戰要提供編號9000的內存塊存在某筆交易X的證明，則挑戰者需要從內存塊10000的哈希值開始，先證明內存塊 10000所連接的母內存塊9999的哈希值，然后再證明內存塊9998…直到內存塊9000，最后再提出內存塊9000的內容里包含該筆交易X。
EIP-2935之后，會有個系統合約（部署在0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC），它的Storage會儲存最多8192個以前的內存塊的哈希值。每當個新的內存塊產時，這個系統合約就會自動更新，將前個內存塊的哈希值寫進系統合約中（會復寫掉8192個以前的內存塊的哈希值）。
如此在OptimismticRollup欺詐挑戰的例中，挑戰者就不必再往前個內存塊個內存塊慢慢證明，是可以直接證明內存塊10000當下的鏈的狀態中，該系統合約的某個Storage（對應到內存塊9000）的值是內存塊9000的哈希值。如果范圍超過8192，例如內存塊1000，那頂多就是多步，先證明內存塊1808（=10000-8192）的哈希值，然后再證明內存塊1808當下的鏈的狀態中，系統合約里的內存塊1000的哈希值。
這也為未來的無狀態客端（StatelessClient）鋪路：未來的輕節點就不需要再儲存著歷史中所有的內存塊的頭文件（BlockHeader），是當有需要用到歷史中某個內存塊的哈希值或是內存塊內容時，再請其他用前面欺詐挑戰例中的證明式提供證明即可。
EIP-7623::增加calldata成本
調高利用calldata來發布數據的本，以挪出夠的安全空間來調高BlockGasLimit和Blob數量。
隨著Rollup的數據發布需求越來越高，在EIP-4844中引Blob來讓Rollup以非常便宜的式放數據之后，調Blob數量便直是社群所期待的個升級，或像是最近社群在推動的調高BlockGasLimit，都反應態對提高資源的需求。
△越來越多的驗證者表示支持調高BlockGasLimit。
但不管是調BlockGasLimit或是Blob數量，都會因為交易的數據量變得更大而對Ethereum的p2p網絡造成更多壓，這會使得攻擊者攻擊的效率提，除非將發布數據的成本也提。
EIP-7623協議發布之后，calldata的成本將會從原本的「ZeroByte:4Gas、Non-ZeroByte:16Gas」調2.5倍為「ZeroByte:10Gas、Non-ZeroByte:40Gas」。
原本如果攻擊者將全部的BlockGasLimit（30M）都拿來放垃圾數據的話，內存塊的數據小約會是1.79MB（30M/16），相比于平均內存塊小只有約100KB；而如果BlockGasLimit調到40M的話，攻擊者可以產約2.38MB大小的內存塊。當calldata成本調高為2.5倍，攻擊者的效率會因此下降，變為30M最0.72MB、40M最0.95MB，如此就可以更放地調高BlockGasLimit和Blob數量。不過這個技術協議也不想因此影響到「不是將calldata拿來發布數據」的般用戶，所以它會以兩種式計算交易的總Gas用量，再取較高的：
原本的交易Gas用量計算式，搭配舊的calldata成本來計算：也就是將calldata以「ZeroByte:4Gas、Non-ZeroByte:16Gas」的式計算，并加上交易執所消耗的Gas及部署合約所消耗的Gas。
單純計算calldataGas用量，但是是用新的成本來計算：也就是將calldata以「ZeroByte:10Gas、Non-ZeroByte:40Gas」的式計算，但不計入執所消耗的Gas或部署合約所消耗的Gas所以對般「不是將calldata拿來發布數據」的用戶來說（例如去Uniswap兌換），本來主要的Gas消耗就是在執的部分，即便calldata以新的成本計算也不會超過執所消耗的Gas，因此般用戶將不會受影響。
真正受影響的會是規模還小的Rollup，因為Blob是固定小、固定費用，所以小Rollup使用Blob效率低，使用calldata還比較劃算，但在EIP-7623之后，等于這些小Rollup的成本都會提升2.5倍，它們可能得因此轉為使用Blob或想辦法聯合起來共同分擔個Blob。
EIP-7691:增加Blob吞吐量
提Blob數量，增加更多資料發布的空間給Rollup。
EIP-7691將Blob的數量由「目標：3Blob，上限：6Blob」調為「目標：6Blob、上限：9Blob」，增加更多資料發布的空間給Rollup。
注：另外Blob續費市場還有些設計需要微調，例如續費調整的速度不夠即時及續費底限太低，但這不在這個技術協議要解決的問題里。其他技術協議
EIP-7549:將committee索引移至驗證之外
調整驗證者投票的內容，讓選票更便被聚合起來，降低p2p網絡的壓。
驗證者們每個Epoch都會被隨機分到組組的委員會（Committee）并對
內存塊投票，每個委員會的驗證者們的選票可以被聚合在起，如此可以降低選票在p2p網絡中傳遞的數量，但驗證者的選票里會包含「該驗證者屬于第幾個委員會」的信息，這導致不同委員會的選票不能被聚合在起，即便他們都對相同的內存塊投票。
EIP-7549將「該驗證者屬于第幾個委員會」的信息移出投票內容，使得不同委員會的驗證者在投票內容樣的情況下可以被聚合在起，進步降低選票在p2p網絡中傳遞的數量，降低p2p網絡的壓。
EIP-7840:在EL配置文件中添加Blob計劃
在執行層為Blob參數建立份設定檔，省去執行層節點要去詢問共識層節點Blob相關參數的麻煩。
Blob相關參數目前都是儲存在共識層節點，但執行層節點在某些情況還是需要這些參數（例如RPCeth_feeHistory），所以都必須去向共識層節點詢問。
EIP-7840在執行層為Blob相關參數建立份設定檔，執行層節點都可以直接透過這份設定檔讀取Blob相關參數，不需要再向共識層節點詢問。