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