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