如果希望能更完整吸收這篇文章的內容，可以先閱讀過以下關於 MEV 以及 PBS（MEV 供應鏈）的文章：

• MEV（一）：The Merge 後的 MEV
• MEV（二）：Proposer-Builder Separation

本文無使用 AI 進行或協助寫作。

Recap: 以太坊當前的產塊協議

以太坊致力於保持其去中心化的特性，其中一個重點在於避免驗證者們出現中心化的現象，而 MEV 的龐大利益就是一個不可忽視的誘因。因此社群討論出了將產生區塊內容的工作外包給更專業的產塊者（Builder）：當一個驗證者（Validator）獲得機會成為出塊者（Proposer）時，它只需要從眾多產塊者的區塊中選出一個來作為自己的區塊內容，並獲得該產塊者的競標費用，如此出塊者（也就是驗證者們）的角色就可以維持是一個低技術複雜度的工作，這就是 Proposer Builder Separation（PBS）。

Recap: 以太坊當前的產塊供應鏈

目前以太坊已經有一套完整成熟的產塊供應鏈：

1. 尋利者（Searcher）從使用者們的交易中尋找套利機會並製作出套利交易組合，接著競標請產塊者收入它的套利交易組合
2. 產塊者從眾多尋利者的競標和一般交易中組裝出收益最高的區塊內容，然後向 Relay 競標，Relay 會從蒐集到的競標中選出最高價的競標提交給出塊者
3. 最終由出塊者決定要採用哪個 Relay 的競標，也就決定下個區塊的區塊內容

Relay 的中心化與信任問題

Relay 作為產塊者與出塊者之間的橋樑，手中握有產塊者的區塊內容，產塊者必須要信任 Relay 不會竊取它的區塊內容；而出塊者則必須要對產塊者的競標簽名，Relay 才會釋出（廣播）區塊內容，由此來避免出塊者竊取區塊內容。產塊者與出塊者雙方都必須要相信 Relay 的公正性。

另外由於拍賣是實時在發生，而且競爭非常激烈，產塊者們會隨時動態調整自己的競標價格，所以網路延遲對產塊者的獲利影響甚鉅。Relay 除了要投入不少硬體資本保持競爭優勢外，產塊者們也會採取 Co-locate（主機共置）的方式，部署到離 Relay 越近、網路延遲越低的地方越好。這些都會驅使供應鏈上的角色積極投資在網路速度的軍備競賽上，導致非常容易中心化而對網路造成風險。

註：Relay 作為一個必要的中間人，但其實他們很難找到獲利模式：他們既要投入硬體資本以提供足夠穩固快速的服務來確保自己提交的競標保有優勢，也要避免自己的抽成影響競標優勢或甚至失去產塊者的支持。歷來已經有不少 Relay 經營不下去而關閉。

ePBS：以協議取代 Relay 的角色

ePBS 的全名為 enshrined-PBS，也就是將 PBS 機制寫進以太坊協議裡：
在 ePBS 以前，以太坊協議本身只知道有出塊者這樣的角色，它完全不知道產塊者或 Relay 的存在；在 ePBS 之後，以太坊協議多了產塊者這樣的角色，而 Relay 這個中心化的存在則直接由協議本身接手它的任務 — 確保產塊者與出塊者雙方的權益都可以被保障。

注意：雖然 ePBS 中看似已不再需要 Relay 這樣的角色，但其實它只取代了一部分 Relay 這個角色在做的事。Relay 在 ePBS 後仍然會繼續存在並提供高效且低延遲的競標服務。後面的段落會再介紹產塊者與出塊者之間的競標方式。

如果產塊者作惡

產塊者產出區塊內容並透過競標來讓它的區塊被收入，如果有任何變數導致它產出的區塊內容的預估獲益突然減少，導致它最終可能會賠錢，那產塊者就有動機不釋出區塊內容，而這時出塊者原本承諾要收入該區塊，卻因為區塊內容沒有公布導致區塊直接被視為不合法，等同於被視為完全沒有出塊，失去出塊獎勵。

在 ePBS 之前，產塊者要先將區塊內容交給 Relay 保管，如此就可以確保如果出塊者承諾收入該區塊，該區塊的內容一定會被釋出。

在 ePBS 之後，沒有 Relay 這樣的角色，所以協議沒辦法確保產塊者一定會釋出區塊內容，因此改為實行「如果產塊者有競標，且競標被出塊者選中，那產塊者就一定要支付競標費給出塊者」，如此出塊者就不用擔心會因為區塊內容沒釋出而導致無法出塊，出塊者不但會拿到出塊獎勵，還會拿到產塊者的競標費。

如果出塊者作惡

出塊者從眾多競標中決定要收入哪一個區塊。惡意的出塊者可以簽名承諾要收入哪個區塊但最終不讓區塊成功被收入，以竊取產塊者的區塊內容。例如出塊者可以同時承諾不同 Relay 的競標，獲得多個區塊內容；或是故意延後廣播或甚至不廣播自己的區塊，導致自己的區塊被重組（Reorg）掉。

在 ePBS 之前，出塊者在簽名承諾收入後要將承諾交給 Relay，而且 Relay 並不會把區塊內容交給出塊者來發佈，而是直接拿著出塊者的承諾和產塊者的區塊內容直接廣播，如此惡意出塊者就不能控制區塊內容的發布，或甚至想要即時發佈另一個不一樣的區塊內容也會比 Relay 的發布時間來得晚。

在 ePBS 之後，出塊者的承諾與區塊內容的發布會被分為兩步驟：(1) 出塊者對競標簽完名後直接廣播，(2) 等到足夠多的驗證者看到並承認出塊者的承諾後，產塊者就可以放心廣播它的區塊內容，因為此時如果惡意出塊者再廣播另一組承諾也很難推翻已經被其他驗證者承認的承諾。

將共識層區塊與執行層區塊分開驗證

在 ePBS 以前，共識層區塊會綁定執行層區塊，如果執行層區塊無效或是不存在，那該共識層區塊也會視為無效；在 ePBS 之後，共識層區塊與執行層區塊的有效性將各自獨立驗證：共識層區塊一樣會綁定一個執行層區塊，但驗證者們在投票時不再考慮該執行層區塊是否有效或是否存在，而是單看該共識層區塊的有效性。因此如果一個惡意產塊者釋放無效的執行層區塊或是乾脆不釋放區塊，它一樣要付競標費給出塊者，因為它的競標資料已經被出塊者收入在共識層區塊裡，且驗證者們都已經投票認同該共識層區塊。

Payload Timeliness Committee (PTC)

雖然協議可以確保出塊者無論如何都可以拿到產塊者的競標費，但產塊者釋出區塊內容與否卻仍然會影響鏈的穩定性 — 到底驗證者們看到的是有釋出區塊內容的區塊還是沒有釋出的？如果結果不一致那就容易導致鏈產生分叉。

在 ePBS 之前，區塊內容是否釋出會直接影響到共識層區塊的有效性，驗證者的投票內容就是單純的「有效」與「無效」；在 ePBS 之後，產塊者可以選擇不釋出區塊內容，但共識層區塊還是要是有效的，因此投票的內容會變成「有效且區塊內容有釋出」、「有效但區塊內容沒釋出」與「無效」三種，因此「區塊內容有無釋出」就會造成兩種投票結果，導致鏈容易產生分叉。

為了避免容易產生分叉，協議在每個區塊都會隨機選出一個新的委員會，稱為 Payload Timeliness Committee（PTC），它們的責任就是對「區塊內容是否有及時釋出」進行投票：PTC 成員有看到區塊內容，那就會投給「有釋出」，反之則投「沒釋出」。過半數 PTC 成員的投票結果就會決定該區塊的內容是否有釋出。

競標與支付方式

在 ePBS 以前，產塊者都是透過執行層的轉帳來支付競標費給出塊者，出塊者要自己模擬執行層的區塊來確保自己會收到錢。但在 ePBS 之後，出塊者與產塊者都是存在於共識層的角色，而共識層區塊的有效性又不再綁定執行層區塊的有效性，協議要怎麼確保出塊者一定會獲得產塊者的競標費呢？答案是：產塊者也要像出塊者（即驗證者）一樣，質押到共識層，並以質押的 ETH 作為競標費。共識層會為產塊者建立專屬的質押與解質押通道，而不是和一般的驗證者們共用同一個通道，畢竟他們的角色不一樣。

產塊者質押後便可以透過 p2p 網路公布自己的競標，得標後協議便會從產塊者的質押餘額裡扣除競標費，並轉移給出塊者。

ePBS 競標缺點與 Relay 的價值

只不過雖然協議的規定是產塊者要質押並透過 p2p 公開競標，但這些方式都有其缺點，例如：

1. 質押/解除質押的等待期（庫存風險）
2. 要競標多少就一定要預先質押多少，不能進行無風險套利（無風險套利例如：產塊者可以收入一筆 100 ETH 的套利交易，並且競標 99 ETH，淨收益為 1 ETH。如果競標失敗，它也不必付出任何成本或風險，因為區塊或交易沒有被收入就等於沒有發生）
3. p2p 競標不能調整出價或取消出價。在 ePBS 以前的競標機制（例如最普及的 MEV-Boost）中，產塊者或 Relay 都可以隨時更改或取消自己的競標

這些缺點都會造成產塊者的風險與成本提高，或是獲利機會減少（例如因為質押金額不夠）。因此有不小機率產塊者將繼續依賴於既有的（也就是協議外的）競標方式與管道：非公開、可調整出價、可取消出價、高速低延遲的競標，也就是 Relay 已經搭建起來，無法被輕易取代的服務。

但當然使用 Relay 的缺點就是產塊者與出塊者雙方要繼續相信 Relay。

除了解決目前 PBS 中 Relay 的中心化風險之外，ePBS 帶來更重要的影響是它將執行層區塊與共識層區塊拆開來驗證 — 出塊者及驗證者們不必再趕在「短短的 4 秒內」將執行層區塊廣播出去並讓驗證者們完成區塊的驗證，而是可以有充足的 12 秒來驗證執行層區塊。這也代表我們可以更放心地提高區塊的 Gas Limit，而不用擔心會有驗證者的驗證速度無法跟上出塊的速度。

ePBS：優化出塊流程的利用率=解鎖吞吐量的大幅提升

以太坊目前每 12 秒出一個塊，但不代表出塊者有 12 秒的時間可以慢慢組出區塊再廣播，也不代表驗證者有 12 秒的時間可以慢慢驗證區塊再廣播自己的投票。當出塊者越慢廣播它的區塊，越有可能造成驗證者之間投票的分歧（有些驗證者接受該區塊，但有些驗證者很晚才看到區塊所以拒絕該區塊），進而造成鏈的不穩定；同樣地，驗證者們越晚投票，越容易造成鏈的不穩定，攻擊者也能更輕易地對網路進行攻擊。

如果一個區塊（包含共識層區塊和執行層區塊）成功在每個 Slot（每 12 秒）開始後的 4 秒內完成驗證的話，該區塊會有較高機率被收入（稱作 Proposer Boost）。這代表驗證者要在四秒內：收到共識層區塊並驗證、收到執行層區塊並驗證、收到區塊所包含的 Blob 資料。

其中區塊本身的執行驗證並不是目前的瓶頸，瓶頸是 Blob 的傳遞：一個 Blob 約 128 KB，一個區塊最多可以收入 21 個 Blob，也就是 2.6 MB 左右的資料，如果有其中一個 Blob 沒有及時傳到驗證者手上，該區塊就會直接被當作不合法，數據也顯示 Blob 的傳遞延遲造成平均約 1% 左右的區塊被判定為不合法：

註：在 Fusaka 後，驗證者們和節點採用 PeerDAS 的技術，就不必每個人都再下載完整的 Blob 資料，而是隨機指定一小部分的 Blob 資料來下載，如果這一小部分的資料都下載得到，該節點就會將該 Blob 資料視為合法的（即「下載的到的」的意思）。在 PeerDAS 中，如果一個區塊包含 21 個 Blob，那一個驗證者大約會下載 360 KB 左右的資料來驗證。

ePBS 將共識層區塊與執行層區塊分開驗證

在 ePBS 後，共識層區塊的有效性不再綁定執行層區塊的有效性以及 Blob 是否下載的到。共識層區塊只驗證出塊者所收入的「產塊者的競標」是否有效，例如產塊者的簽章以及產塊者是否有足夠多的質押來支付。剩下的時間都留給驗證者去驗證執行層區塊內容與 Blob 資料們的有效性。

註：共識層區塊其實不大也很好驗證，所以在 ePBS 後共識層區塊的驗證時間上限會從 4 秒縮短為 3 秒。

節點有了更多時間驗證區塊就代表區塊的資料大小以及 Gas Limit 都可以再提高：（如果測試和運行順利）共識是在 Glamsterdam 後將 Gas Limit 一路從 60M 調升至 200M；而 Blob 的數量調整則是在上一次升級後已經獨立出去，稱為 BPO 升級。BPO 2 於 2026/01 執行，目前則無 BPO 3 的規劃。

註：BPO3 的規劃由 EIP-8138 進行追蹤。

總結

ePBS 將 PBS 機制寫進以太坊的協議裡，除了取代 Relay 這樣的中心化角色，並提供產塊者與出塊者更好的保障之外，ePBS 帶來的更大好處是透過「將共識層區塊與執行層區塊的驗證拆分」，來完整利用一個 Slot 12 秒的時間驗證執行層區塊，這代表我們可以放心地提高區塊的 Gas Limit，而不必擔心會有節點跟不上導致去中心化程度下降。Glamsterdam 升級預計會將 Gas Limit 從 60M 提高為 200M。

但 ePBS 的影響和成效仍然有待觀察，例如：

• Gas Limit 真的提高到 200M 後對鏈的穩定性的影響、對節點成本的影響、對鏈的狀態膨脹（State Bloat）的影響
• 質押與公開競標機制的不便是否會影響產塊者的使用意願，使得中心化的 Relay 與原有的 PBS 機制最終仍然持續存在

參考資料與相關資源

• https://eips.ethereum.org/EIPS/eip-7732
• https://www.mevwatch.info/
• https://collective.flashbots.net/t/disclosure-mitigation-of-block-equivocation-strategy-with-early-getpayload-calls-for-proposers/1705
• https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710
• https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/
• https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054
• https://www.youtube.com/watch?v=0qdciLzKMiM
• https://x.com/ready4merge/status/2108560842098897344
• https://ethresear.ch/t/epbs-distilled/25800
• https://hackmd.io/@thUuBZa2ScW2i3kFbsrOFA/S1XTQgR_Ge
• https://terencechain.com/writing/epbs-changes-how-ethereum-scales/
• https://terencechain.com/writing/how-epbs-resolves-payload-ambiguity
• https://terencechain.com/writing/how-epbs-changes-builder-selection/
• https://x.com/luca_zanolini/status/2062531898749137314
• https://ethcc.io/archives/epbs-what-ethstakers-need-to-know
• https://www.youtube.com/watch?v=0qdciLzKMiM

TEM Medium 2026 有獎徵稿

TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 2026有獎徵稿

Special thanks to Peter Lai , Chang-Wu Chen and Kimi Wu for reviewing and improving this post

ePBS — 解鎖以太坊的效能 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part1:

Proposer Commitment Protocol Part1

本文無使用 AI 進行或協助寫作。

第一篇文章介紹了什麼是出塊者承諾協議、不同的承諾種類以及目前市面上有哪些協議。這一篇將深入到技術層面，介紹出塊者承諾協議需要哪些元件、遇到的挑戰，還有現有的解法與實作。

Recap: 出塊者承諾協議

目前的 MEV 供應鏈中皆是以整個區塊為單位去販售：由產塊者決定好它的區塊裡包含哪些交易以及交易的順序之後再向出塊者競標。過去社群已有設計提出要讓出塊者能將其區塊內容進行更豐富、更細緻的商品化販售，不過直到最近才因「交易預先確認」這個需求而有契機落地並逐步實現成更通用、更完整的設計。除了較知名的「交易預先確認」例子外，還有像是進階交易或避險用的「區塊期貨市場」，以及能優化交易競標效率的「State Lock」等等。

如何建立一個出塊者承諾的規範

一個出塊者承諾協議最基本需要

1. 一個「註冊表（Registry）」來登記有哪些出塊者（也就是驗證者）和相關角色加入這個協議，以及
2. 訂立「押金與懲罰判斷標準」讓買賣雙方清楚知道其獲得的保障及相對應的風險

1. 註冊表

出塊者承諾協議的相關參與者包含出塊者、產塊者等等，要到註冊表合約來簽名註冊，讓大家知道有誰可以提供承諾，以及什麼時候會輪到這些註冊的出塊者出塊。

如果註冊的出塊者太少，那使用者的交易或承諾就會需要等比較久才能被收入或履行，這對於沒有時效性的交易例如一般的轉帳不會有什麼差別，但對於有時效性的交易例如 Swap 或清算交易等等就會有影響。

像是 MEV-Commit 這個出塊者承諾協議就將承諾區分為 Credible 及 General 兩種：Credible 是由已註冊的「出塊者」提供承諾，而 General 只是由已註冊的「產塊者們」提供。General 承諾不會是最可靠的保障，因為它們只是產塊者，不是有 100% 區塊內容決定權的出塊者。

2. 押金與懲罰判斷標準

承諾的提供者，包含出塊者、產塊者等等，需要將押金鎖進合約，當使用者提供承諾未被履行的證據時，合約將判斷誰該負起責任並燒毀其押金，或是拿押金來賠付給受害者。不過有些承諾未履行的情況未必是承諾提供者作惡，而是單純出塊者機器當機（導致沒有出塊）或是網路出現問題（導致太慢出塊而被其他驗證者拒絕），這些情況會屬於 Liveness Failure，罰則會比較低，畢竟不是惡意的；相對地，如果是有正常出塊但承諾卻還是被違反了，那就屬於 Safety Failure，罰則就會高上許多。

註：L2 排序器也可以是承諾的提供者，它一樣也要鎖押金進合約，才能提供承諾給它的 L2 使用者們。

Liveness Failure 通常比較好判斷，因為沒出塊就是沒出塊；而 Safety Failure 就會按照不同承諾種類有不同的判斷標準，例如「交易預先確認」的承諾就會需要檢查使用者指定的條件，例如「區塊的第一筆」、「區塊最後的十筆之一」，或是「排在哪一筆交易之前/後」等等不同條件。或例如「區塊期貨」的承諾可能會檢查「區塊第 100~500 萬的 Gas 消耗是不是由買家所使用」。在承諾被違反時，使用者都要提供具體證據來證明，而協議也要為這些條件設計好清楚明確的程式碼來進行檢查，否則就有可能會導致有人被冤望而喪失押金，或是有人違反承諾卻還能逃過懲罰。

不同承諾種類如何判斷承諾是否履行

承諾種類 1：「交易預先確認」

「交易預先確認」的承諾又可以分為兩種：交易「收入」的確認或是交易「執行結果」的確認。「交易收入確認」比較簡單，只要交易有在指定區塊、指定的位置被收入即可，不管交易執行結果，適合不會被時間因素或交易順序影響結果的交易，例如一般的轉帳；「交易執行結果確認」則要求交易執行的結果必須符合指定條件，例如「交易不能失敗」、「必須 emit 特定 event」、「某個合約的某個變數必須是某個值」等等。通常「交易執行結果確認」的承諾困難許多，收費也因此比較貴。

以較簡單的「交易收入確認」承諾為例：假設使用者 Alice 希望她的交易 X 能在第 10000 個 Slot 之前被收入，而 Slot 9998 的出塊者或產塊者模擬完交易後決定將 Alice 的交易收入在第 123 筆的位置，因此將交易順序的資訊包含在其承諾中：「在我產出的 Slot 9998 的區塊中，我會收入交易 X ，且會安插在第 123 筆的位置」。在這個簡單的承諾中，有哪些可能出意外的地方？承諾是否履行的判斷標準該怎麼設計來應對不同情境？

在交易收入確認中，使用者只要求在什麼時間點（或之前）被收入，通常不會指定交易要放在第幾筆，因為這種交易不管放在哪個位置都會執行成功，例如一般轉帳。而出塊者或產塊者的承諾中可能會額外包含「交易會放在區塊的哪一個位置」，畢竟它已經模擬完交易，交易順序已經確定。當然出塊者或產塊者也可以不將交易位置的資訊包含在承諾中，反正只要交易有收入在該區塊即可。不過以下介紹會假設承諾中有包含這個資訊，增加一點挑戰性。另外我們會假設是由出塊者來給出承諾。

如果承諾沒有被履行，那首先要先證明「有承諾被打破了」。要證明有承諾被打破，要先檢查最基本的：

• 驗證出塊者對承諾的簽名：證明承諾真的存在
• 驗證出塊者有註冊：證明出塊者真的有加入該出塊者承諾協議
• 驗證該出塊者是 Slot 9998 的出塊者：證明出塊者真的是合法的出塊者

接著再按不同情況進行驗證：

情況 1. 出塊者當機或網路出問題導致最終沒有出塊或出的塊被遺棄
也就是 Liveness Failure。這時候要證明 Slot 9998 是一個 Missed Slot，也就是沒有出塊的狀態。這需要透過 EIP-4788 在智能合約中讀取共識層的資訊，並提供 Merkle Proof 來證明共識層的 Slot 9998 真的是 Missed Slot 的狀態。當 Missed Slot 證明成功了，該出塊者就會直接被以 Liveness Failure 罰則懲罰。

情況 2. 有正常出塊，但交易在 Slot 9998 之前就被收入
其實如果 Alice 有指定一定要在 Slot 9998 被收入，那交易在 Slot 9998 之前被收入就可能會被視為違反承諾。不過通常使用者都不會介意交易提早被收入（假設交易都執行成功且符合指定條件），且很難避免交易因為公開洩露而導致被其他出塊者或產塊者提早收入，所以協議基本上不會將「交易提早被收入」視為違反承諾。
但因為交易提早被收入代表出塊者沒辦法在 Slot 9998 再次收入該交易，所以 Alice 有可能可以藉此陷害出塊者，畢竟交易 X 就是沒有被收入在 Slot 9998 中。因此如果要能區分到底是「出塊者違反承諾沒收入」還是「使用者想要陷害出塊者」，我們需要使用者去證明「使用者的交易在 Slot 9998 當下是可以被收入的」：如果證明為真，那就是出塊者違反承諾 — 沒有收入該交易；如果無法提出證明，表示交易不可被收入（例如使用者的 Nonce 已經改變或他的餘額不足），那就代表出塊者其實是不得已而不收入該交易。

情況 3. 有正常出塊且該交易在 Slot 9998 可以被收入，但交易沒有被收入，
也就是 Safety Failure。這時候使用者要提供什麼證據呢？

使用者提供的零知識證明除了要包含「交易在 Slot 9998 可以被收入」之外，又分為兩種情況：

1. 第一種可能是區塊交易總數其實少於 123 筆（例如只有 87 筆），所以無法直接證明「X 不是第 123 筆的交易」，這時候要證明「出塊者承諾的交易順位大於 Slot 9998 區塊的交易總數」
2. 第二種是交易總數大於 123 筆，那這時候就直接證明「X 不是第 123 筆的交易」即可

以上是以「交易收入確認」承諾為例，展示其實光要證明在這種簡單的承諾中「有錯發生」就已經相當複雜、有許多例外需要考慮。而除了證明「有錯發生」以外，還要再接著「指出到底是誰的錯」，這是以太坊複雜的出塊流程所導致。

如果以太坊單純只有出塊者負責產塊並出塊，那就簡單許多 —就是出塊者一個人的鍋。但因為以太坊出塊流程背後其實運行著 PBS 機制，讓咎責變得更為複雜 — 區塊內容的產出牽涉到產塊者、Relay 以及出塊者三方。後面會介紹如何咎責。

承諾種類 2：Top-of-block or Bottom-of-block

Top-of-block 或 Bottom-of-block 和「交易收入確認」其實差不多，只是在 Top-of-block 或 Bottom-of-block 中使用者「指定了交易該被收入的位置」。因此它們除了最基本的的「出塊者及承諾的有效性」的驗證，也是要處理前述的幾種會出錯情況，剩下的差別在：相比於證明「交易 X 是否在第 123 筆的位置」，Top-of-block 或 Bottom-of-block 要檢查的可能會是「交易是否是收入在前十筆或最後五十筆之一」等等複雜一點的條件。

註：當然也可能是簡單的「交易是否是收入在第一筆或是最後一筆」檢查，就看 Top-of-block 或 Bottom-of-block 販售者提供的選項。

承諾種類 3：State Lock

State Lock 的承諾例如「在 Alice 的交易之前，Uniswap V3 ETH-USDT 池子的狀態都沒有改變」或「在執行 Alice 的交易之前，Uniswap V3 ETH-USDT 池子的狀態是如何如何」等等，因此使用者要證明 State Lock 承諾被違反時，會需要證明「某合約變數在區塊初始到交易 X 執行之前的值都是 Y」或是「某合約變數在交易 X 執行之前的值是 Y」，但因為現在的以太坊已經為了效能而不再記錄每筆交易執行後的狀態根（State Root），因此要證明某合約變數在任意時間點的值並不容易。

EIP-98 將「執行後的狀態樹根」從交易收據裡移除，否則 State Lock 承諾便可利用收據裡的狀態樹根來證明那當下的任何合約變數。

一個方式是透過挑戰機制讓雙方攻防，直到範圍縮小到一個特定時間點再去執行，得到執行後的狀態樹根。另一個方式是直接以零知識證明的方式證明「某合約變數在時間點 T 的值是 Y」。目前 zkVM 協議像是 Succinct SP1 或 Boundless Steel 其實都可以證明任意的交易執行，或甚至是任意的 EVM 執行結果。

不過在 Glamsterdam 硬分叉中會引入 Block-level Access List（BAL）的設計，在 BAL 中，區塊內容裡就會直接包含每一筆交易所修改到的變數以及修改後的值，用來證明 State Lock 承諾就會非常方便，不再需要用挑戰機制或是零知識證明。

如何咎責？

前面例子提到在 PBS 環境底下，出塊的過程牽涉到多個參與者，每個參與者都有可能導致最終承諾被打破。首先，一個承諾是如何被傳遞給不同參與者呢？社群目前制定了兩套 API：「Commitments API」及「Constraints API」。

• Commitments API 是給使用者請求承諾用的，而 Constraints API 則是 Relay 與產塊者之間溝通承諾用的
• 一個 Commitment（承諾）會有相對應的 Constraints，也就是對區塊內容的要求。例如 Alice 「指定她的交易要是區塊第一筆交易」是 Commitment，而相對應的「Alice 的交易必須要放在區塊的最前面」就是要履行這個承諾所要達成的要求
• Relay 透過 Constraints API 收到 Constraints 請求後，會把它記錄下來，然後產塊者會透過 Constraints API 從 Relay 那得知目前這個區塊有哪些要求必須要被遵守
• 當產塊者產完區塊交給 Relay 後，Relay 也會檢查該區塊是否有符合要求

註：上圖中的 Gateway 是出塊者的代理人，由它來為出塊者代為接受承諾，避免出塊者因為各種不同承諾請求而導致工作量太多。

而目前 PBS 機制中，其實出塊者和產塊者雙方都是需要信任 Relay 的 — 相信 Relay 會公平的主持競標並保護雙方不被傷害。因此我們可以沿用這一個信任，由 Relay 來作為承諾被違反時的仲裁者：如果 Relay 有確實告知產塊者相關 Constraints 但最後卻有承諾被打破，那就是產塊者的問題；如果 Relay 把一個符合要求的區塊交給出塊者，但最後上鏈的區塊卻是一個有承諾被打破的區塊，那就是出塊者的問題。至於接下來 ePBS 上線後不再有 Relay 這樣的角色，這整套機制該如何調整，稍後會介紹。

MEV-Commit：MEV-Commit 鏈作為仲裁者

其他出塊者承諾協議也一樣會面臨當承諾被打破時，要如何咎責、誰來做仲裁的問題。而前一篇文章提到的 MEV-Commit 便起了一條自己的鏈來做這件事：所有承諾的「（使用者）請求」和「（產塊者或出塊者）接受」都會記錄在 MEV-Commit 鏈上，一切以鏈上資訊為準。使用者請求沒有被記錄在鏈上就不會被兌現；產塊者或出塊者接受請求後就要兌現承諾，否則押金就會被沒收。

出塊者承諾工具 — Commit Boost

Commit Boost 是一個開源、社群共同維護的出塊者承諾協議，目的是透過建立一套公開的標準，讓大家都能輕鬆且無准入地（Permissionlessly）在這套出塊者承諾協議上搭建各式各樣的承諾，避免這個市場因為缺乏競爭和高門檻而被少數人把持。

Commit Boost 制定了前面提到的 Commitments API 及 Constraints API，並基於目前 PBS 和共識層裡 Sidecar* 的設計，將出塊者承諾變成一個通用的 Sidecar。未來出塊者想要提供承諾服務，它只需要安裝 Commit Boost 的 Sidecar，就能在裡面選擇各式各樣的承諾模組來下載，而不會像現在 PBS 生態裡，如果一個出塊者要接入 Flashbot 就要下載 Flashbot 的 Sidecar，如果要接入 MEV-Commit 就要下載 MEV-Commit 的 Sidecar。

註：共識層 Sidecar 是為了避免直接修改共識層規則（例如新增或刪減某個欄位），而將資料以類似「掛載」的方式和共識層區塊並行傳輸的方式。

ePBS 對以太坊上出塊者承諾的影響

前面提到 Relay 做為被產塊者與出塊者共同信任的對象，也方便地解決了該如何咎責的問題 — 一切以 Relay 看到的為準。而 ePBS 上線（預計 2026 Q3）後，這個中心化的 Relay 角色將會消失，改為由一群被選出的驗證者（稱為 Payload-Timeliness Committee，簡稱 PTC）一起來負起 Relay 這個角色的責任。PTC 負責用投票來決定得標的產塊者是否有兌現它的承諾，也就是產塊者是否有在時限內廣播出它的區塊內容，如果廣播晚了或根本沒有廣播，那產塊者一樣要被收取它所競標的金額。

但 PTC 只負責確保「以區塊為單位」的履行，即「這個得標的區塊是否有即時被釋出」，它們不知道一個區塊裡是否有任何出塊者承諾要被履行，例如「Alice 的交易要被收入在第一個位置」。沒有一個中心化的 Relay 角色來把關，出塊者要怎麼相信產塊者競標的區塊內容真的有符合 Constraints 的要求？

幸運的是產塊者可以利用前面提到的 Block-level Access List（BAL）來產生證明，證明一筆交易的收入，或甚至是一筆交易的執行結果。而且 BAL 也包含在產塊者的簽名內容裡，所以出塊者可以相信當產塊者提供了 BAL 證明一筆交易的收入或執行，該筆交易的承諾會獲得履行，否則它可以拿著 BAL 和產塊者簽章去罰沒產塊者的押金。如果產塊者沒辦法提供 BAL 來證明 Constraints 要求有被實現，出塊者就會直接忽略該區塊。

但這個驗證管道仍然如同當前的出塊者承諾協議，都是屬於以太坊協議之外的機制，這表示產塊者除了因為參與 ePBS 而必須在以太坊協議抵押一份押金外，它還要在其參與的出塊者承諾協議中也抵押一份押金，兩邊的押金不能共用。要等到未來像是 Protocol-Enforced Proposer Commitment（PEPC）設計被實現後，以太坊協議才會內建出塊者承諾機制，這時產塊者才不需要在多個地方都去抵押押金。想了解更多關於產塊者怎麼利用 BAL 產生證明給出塊者的設計，可以參考這篇。

以太坊協議內的出塊者承諾方式

以上的例子都是屬於以太坊協議外（Out-of-Protocol）的出塊者承諾設計，也就是以太坊本身並不知道有這些出塊者承諾機制存在，沒有參與到這些出塊者承諾機制的驗證者也不知道他們的存在，例如當前（ePBS 之前）的 PBS 機制。協議外機制的優點是更彈性、變化改動更快，不必等半年一次的升級節奏，但缺點是要維持機制公平性和可信度，就會需要仰賴並信任中心化角色，例如 PBS 中的 Relay 角色。

那有哪些設計是可以實現「協議內」的出塊者承諾？

Inclusion List (IL)

IL（交易強制收入清單）設計的目的是用來增加協議的抗審查能力：每 12 秒都會有數個驗證者被賦予提出自己的 IL 的權利，這些驗證者可以將任意（還未被收入的）交易放入自己的清單中，下一個出塊者必須要將這些交易收入在自己的區塊中，除非總消耗 Gas 已經超過區塊上限。

因此 IL 也可以作為一個實現出塊者承諾協議的工具，但因為目前的 IL 設計並沒有辦法保證清單內的交易一定會被收入，所以這個工具的承諾並沒有辦法被 100% 保證。想了解更多 IL 的機制可以參考 EIP-7805。

註：其實 IL 可能只能算是一半「協議內」、一半「協議外」的機制，IL 本身是協議內機制，但驗證者和使用者還是要仰賴於協議外的機制來溝通並懲罰。

Protocol Enforced Proposer Commitment (PEPC)

PEPC 則是更進一步直接把出塊者承諾協議寫進以太坊協議中，由以太坊協議本身來當仲裁者。即將在 Glamsterdam 升級中上線的 ePBS 就是一個例子，由以太坊協議本身紀錄產塊者的競標、出塊者是否履行承諾，並在產塊者作惡時強制沒收押金，以及避免出塊者惡意改出另一個不同區塊。又或是像 MEV-Commit 跑一條自己的鏈來作為自己出塊者承諾協議的仲裁者一樣。

EIP-7805 比較有希望在 2026 年底或 2027 年的升級中上線；PEPC 則是對以太坊協議有更多更深層的改動，所以未必能真的實現。或至少先看看 ePBS 運行地如何，再看看是否有機會把 ePBS 的區塊內容承諾升級為更通用的承諾內容。對 PEPC 有興趣的話可以參考這篇 Ethresearch 文章。

TEM Medium 2026 有獎徵稿

TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 2026有獎徵稿

Special thanks to Kimi Wu and Kevin Chia for reviewing and improving this post

Proposer Commitment Protocol Part2 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

如果希望能更完整吸收這篇文章的內容，可以先閱讀過以下關於 MEV 以及 MEV 供應鏈的文章：

• MEV（一）：The Merge 後的 MEV
• MEV（二）：Proposer-Builder Separation

本文無使用 AI 進行或協助寫作。

Recap: 以太坊當前的產塊協議

以太坊致力於保持其去中心化的特性，其中一個重點在於避免驗證者們出現中心化的現象，而 MEV 的龐大利益就是一個不可忽視的誘因。因此社群討論出了將產生區塊內容的工作外包給更專業的產塊者（Builder）：當一個驗證者（Validator）獲得機會成為出塊者（Proposer）時，它只需要從眾多產塊者的區塊中選出一個來作為自己的區塊內容，並獲得該產塊者的競標費用，如此出塊者（也就是驗證者們）的角色就可以維持是一個低技術複雜度的工作，這就是 Proposer Builder Separation（PBS）。

Recap: 以太坊當前的產塊供應鏈

目前以太坊已經有一套完整成熟的產塊供應鏈：尋利者（Searcher）從使用者們的交易中尋找套利機會並製作出套利交易組合，接著競標請產塊者收入它的套利交易組合。產塊者從眾多尋利者的競標和一般交易中組裝出收益最高的區塊內容，然後向出塊者競標，最終由出塊者決定採用哪個產塊者的區塊內容，也就決定下個區塊會收入哪些交易。

註：其實產塊者和出塊者之間還有另一個角色 — Relay — 負責公平主持拍賣。

以上 Recap 為讀者複習目前以太坊的產塊流程，基本上也是使用者交易的生命週期。這和出塊者承諾協議息息相關，因為使用者和出塊者之間的承諾都必須經過這些流程來實現。接下來將介紹最常聽到，也是最先被推廣的出塊者承諾協議的例子 — 交易預先確認。

交易預先確認（Transaction Preconfirmation）

「交易預先確認」指的是產生區塊內容的角色（例如以太坊的產塊者或是 L2 的排序器）在收到使用者的交易後，就向使用者承諾會在下一個區塊或第幾個區塊之前收入他的交易。例如目前的 L2，包含 Arbitrum、Base、ZKsync 等等，它們的排序器在收到使用者交易後都能立即通知使用者交易會被收入，而不像在以太坊上是使用者交易送出後就只能乖乖等待，並在看到交易被收入在區塊時才收到通知。

不過這些 L2 排序器給出的承諾背後，其實仰賴的是運行排序器的團隊的誠信。如果不幸地使用者交易其實最終沒有被收入，或是並非當初排序器承諾的執行結果（例如交易最終竟然失敗了），那使用者也無計可施。而這篇文章要介紹的出塊者承諾協議則是屬於「由經濟誘因驅動的承諾」，也就是當產出區塊的角色違背承諾時，它的押金將會被奪走，或甚至拿去補償受害者。

而以太坊則因為實行 PBS 機制，導致其承諾協議在設計上會比 L2 上的承諾協議更為複雜，在第二篇文章中會再更詳細介紹。

其他出塊者承諾的應用場景

除了保證使用者交易會被收入之外，出塊者還可以按照不同需求提供不同服務或商品。

Protocol Maintenance

協議可以向出塊者請求在有需要的時候（或是定時）幫忙執行某些操作，例如更新協議參數、清算倉位避免壞賬、暫停協議避免被攻擊等等。當然使用第三方的自動化服務例如 Keeper 等等也可以達成一樣的目的，只是第三方服務最終一樣是要去向出塊者競標請求收入它的交易，而且在緊急情況時常常要和攻擊者的交易競爭手續費高低，不像出塊者承諾是可以提供更直接且穩妥的保障，例如「我會預留多少 Gas 給你的交易」或是「我會將你的交易收入在區塊最前面」等等。

Top-of-Block and Bottom-of-Block

通常尋利者會競爭讓自己的套利交易能排在區塊最前面或最後面：擺在區塊最前面所套的利是「前一個區塊執行完所產生的新的套利機會」；擺在區塊最後面則通常是套「去中心化交易所（DEX）與中心化交易所（CEX）的利差」。出塊者可以將區塊的最前面或最後面保留給特定的人或特定的交易。

註 1：DEX 與 CEX 利差所產生的利潤非常可觀。在以太坊上，由於產塊者有最大的權力，所以通常都是產塊者自己吃下這一塊的利潤，不然就是產塊者和某些尋利者進行合作。而這也導致產塊者變得中心化：有能力吃下這些利潤的產塊者更常在競標中贏過其他產塊者，導致大者恆大。

註 2：以前的 Eden Protocol 就是一個這樣的出塊者承諾協議，它會要求加入到 Eden 的出塊者要保留其區塊的最前面給 Eden 的使用者，並由 Eden 的競標結果來決定誰的交易可以放在區塊最前面。

Blockspace Futures

「保障未來的區塊內容」也可以更進一步發展成「區塊內容的期貨市場」。對區塊內容有需求的買家可以提前確定未來某個時間點可以獲得多少區塊容量或甚至指定使用區塊裡的哪一個區間，或是買家因為擔心未來某個時間點手續費飆高所以透過期貨市場提前鎖定成本來避險，或是將之視為單純的商品投資也可以。

State Lock

如果有尋利者想要確保他的交易是該區塊第一筆執行 Uniswap ETH-USDT 池子兌換的交易，與其競標讓他的交易成為該區塊第一筆交易，他也可以改成尋求這樣的承諾：「他的交易只要是第一筆碰到 Uniswap ETH-USDT 池子的交易就好，前面可以有其他交易沒關係，只要那些交易都不會碰到 Uniswap ETH-USDT 池子即可」。相比於迫使所有人都去爭搶成為區塊的第一（也是唯一）筆交易，State Lock 競標讓出塊者或產塊者可以為更多的交易提供承諾，以及有更大的彈性去對交易排序進行優化。

以上介紹了幾個出塊者承諾的例子，接下來會分享市場上目前有哪些出塊者承諾相關的協議。

現有的出塊者承諾協議

MEV-Commit 和 ETHGas 是最先進到市面的出塊者協議，MEV-Commit 在以太坊上提供「交易預先確認」服務；ETHGas 則是提供「區塊期貨市場」及「交易預先確認」服務。

MEV-Commit

MEV-Commit 專注在為區塊市場的買賣雙方提供隱私媒合的服務：買家可以為自己的需求加密，而且只有指定的賣家可以解密，而當賣家簽名給出承諾後，也只有買家可以解密承諾，確保整個合約從簽訂到履約過程都是保持隱私的。MEV-Commit 也正在和提供安全多方計算服務的 Shutter Network 積極合作，為 MEV 供應鏈提供「交易內存池加密」的服務，提供更全面的隱私保護。

註：Shutter Network 使用的是 Threshold Encryption（門限加密）的加密技術。

不過要注意的是 MEV-Commit 有自己的一條鏈，目的是作為一個公正第三方來在交易失敗時（也就是承諾被違反時）作為仲裁者判定誰該為此付出代價。這也代表買賣雙方必須先將 ETH 跨到該條鏈上才能進行交易，不能直接在自己買賣區塊內容的那條鏈上（例如以太坊）進行交易。

ETHGas

透過 ETHGas 的區塊期貨平台，買家可以提前 64 個區塊的時間就預先下訂區塊內容。

ETHGas 也在近期推出了「交易預先確認」的服務。

註：ETHGas 目前操作的體驗比較適合專業交易員，不適合一般使用者。如果一般使用者想試用「交易預先確認」的服務，可以使用 MEV-Commit 的 RPC — 使用者只需要把 RPC 換掉就可以將交易都送往 MEV-Commit 進行預先確認。

第二篇文章將聚焦在技術上如何實現一個出塊者承諾協議。

TEM Medium 2026 有獎徵稿

TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 2026有獎徵稿

Special thanks to Kimi Wu and Juno Chiu for reviewing and improving this post

Proposer Commitment Protocol Part1 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

TEM 信箱：eth.taipei@gmail.com

徵稿內容

主題只要是和 Ethereum 相關都可以，例如：

• 密碼學/零知識證明
• 隱私
• L2、執行層/共識層
• 開發者工具
• 錢包
• 或比較 general 的主題例如 EIP 等等

投稿方式

來信至 TEM 信箱，標題為「TEM 專欄投稿：你的文章標題」。內文包含：

• 作者資訊
• 文章連結（Medium 文章的草稿連結），請記得不要先發布文章在 Medium 才投稿至 TEM！如果文章已先透過其他渠道發布，請順便附上連結
• 錢包地址和聯絡方式，方便領取獎品。如果你想樂捐稿費，請在信件結尾附註，我們會將稿費捐獻給 TEM 財庫
• AI 使用揭露：請說明在撰寫過程中使用 AI 協助的程度（例如：完全無使用、僅用於文法校正、用於大綱建議、用於部分內容生成等）

重要提醒：

1. Medium 記得打開 Private Note 功能讓審稿人可以留言
2. 過去已經發布在其他地方的文章也歡迎投稿，但已發布過的文章恕將無法計入有獎徵稿
3. 再次提醒，請記得不要先發布文章在 Medium 然後才投稿至 TEM！

審稿規則

每篇文章會有一位聯繫人負責更新審稿進度。聯繫人會為該文章找到審稿人，並透過信件回覆審稿進度：In Review、Accepted 或 Delayed。

如果遇到找不到審稿人或聯繫人剛好忘記或沒空，導致聯繫人三天都沒有回覆的話，請再寄送一次信件或到 TEM 的 Telegram 群組詢問。

寫作指南（New）

專欄價值與品管哲學

Taipei Ethereum Meetup 專欄是一個當地技術社群專欄，目的是幫助讀者或寫作者了解以太坊生態系的技術細節。

核心價值排序：親身經歷 > 作者福利 > 讀者福利

專欄重視分享「親身經歷」。我們希望文章是作者親自看過的程式碼、研究過的專案和升級提案、讀過的論文、實際操作過的體驗、蒞臨過的研討會與得到的互動。因為親身經歷，作者對議題有第一手的了解，讀者也認識了作者與其介紹的主題。

撰文建議

呈現親身經歷

• 主觀經驗很重要：開發體驗走過的彎路、讀過論文遇到的困惑、使用應用程式遇到的挫折、研討會遇到的有趣軼事，這些都是對讀者大有幫助的內容，鼓勵提及

重現與驗證

• 文章所提的客觀內容，請考慮讓讀者在合理的限制下是有辦法重現和驗證的
• 例如原始碼分析，讀者應該要能找到文章所提原始碼

管理複雜

• 建議撰稿方向上以單一專案為主，避免一開始進行多專案分析
• 如果單一專案已經複雜，可以縮小範圍，考慮寫某一個小元件的運作方式

管理 AI 品質

• 我們不反對 AI 使用，但當 AI 影響文章品質時，AI 使用的痕跡會讓審稿者傾向認為文章品質不好
• 專欄重視親身經歷，不以追求可讀性與文字完美為目標
• 建議文章以自己的話呈現
• 建議 AI 以編輯回饋或文法編輯為主
• 對自己文字能力沒有信心時，使用 AI 生成文字或大幅修改文章反而有反效果

管理中文品質

• 作者能以英文或作者熟悉的語言撰文，專欄不做語言限制
• 文章讀者主要來自台灣，因此建議以台灣熟悉的技術語言行文
• 以台灣繁體中文撰文時：
• 避免無意識使用中國詞彙，這會是審稿者判斷文章品質的參考
• 避免中英夾雜，盡量使用全中文
• 鼓勵作者創造新詞，專欄鼓勵作者直接把新技術名詞翻成中文

拒稿情況

審稿人擁有最後判斷的裁量權。拒稿在極端情況時可能發生，包含並不限於：

• 嚴重離題
• 涉及傷害
• 過分的企業宣傳
• 撰文品質低落
• 偏離事實太遠

文章編輯、匯入技巧

• 在進階設置中為文章設置客製化的連結，避免 Medium 用預設的方式將文章標題編碼當作連結
• CC0 圖檔庫，無需 attribute：https://www.flickr.com/photos/vintage_illustration/albums/72157717023082312/page3
• 建議內文上下標可以用 unicode，latex 不要拆開寫否則會斷行（例如 $x$, $y$ 這樣寫會分成兩行）

獎品

徵稿獎品是 DAI 稿費。如果你有什麼對獎品的建議，歡迎來信或是在文章留言處回覆。

註：稿費會在文章發布後一到兩週內送出

文章發布後

歡迎作者自己到 TEM 臉書群組為自己的文章寫個簡單的介紹並附上連結，讓文章能更多人看見。

如果有任何疑問，請來信 TEM 信箱。

TEM Medium 2026有獎徵稿 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Fusaka 硬分叉已於 2025/12/03 於主網部署。Fusaka 包含 13 個 EIP，

• EIP-7594: PeerDAS — Peer Data Availability Sampling
• EIP-7823: Set upper bounds for MODEXP
• EIP-7825: Transaction Gas Limit Cap
• EIP-7883: ModExp Gas Cost Increase
• EIP-7917: Deterministic proposer lookahead
• EIP-7918: Blob base fee bounded by execution cost
• EIP-7934: RLP Execution Block Size Limit
• EIP-7939: Count leading zeros (CLZ) opcode
• EIP-7951: Precompile for secp256r1 Curve Support
• EIP-7892: Blob Parameter Only Hardforks
• EIP-7642: eth/69 — Drop pre-merge fields
• EIP-7910: eth_config JSON-RPC Method
• EIP-7935: Set default gas limit to 60M

接下來會將相關的 EIP 一起介紹，不會按照 EIP 號碼大小或以上順序介紹。

先備知識：

• Ethereum 區分為共識層（Consensus Layer，CL）及執行層（Execution Layer，EL）

擴容相關 EIP

EIP-7594: PeerDAS — Peer Data Availability Sampling

PeerDAS 是 Fusaka 升級中最重要的改動：將 Blob 資料進行分片儲存，正式踏上資料擴容之路。如果要了解資料擴容以及 DAS（Data Availability Sampling）可以參考這系列文章：

Data Availability Sampling（一）：為什麼會需要 DAS？

2024 年的 Dencun 升級中引入了 EIP-4844 Proto-Danksharding，開啟資料擴容的大門，也就是引入了 Blob 資料格式，讓 Rollup 們可以將各自的資料存放在便宜又大碗的 Blob 資料裡。如果要複習 EIP-4844 和 Blob 可以參考這一篇：

Rollup 的大補帖：Proto-Danksharding（一）

不過 EIP-4844 並還沒有真的開啟資料擴容，而是單純鋪好地基，引入 Blob 資料格式。怎麼樣才算真的開啟資料擴容？答案是網路要能隨著節點數量增加而處理更多的資料。如果每個新加入的節點都和舊節點一樣要「保存所有資料」，那網路就沒辦法真的擴容。而在 EIP-4844 中，其實所有節點都還是保存著所有資料，並沒有真的將資料進行分片。

EIP-7594 PeerDAS 正式將資料進行分片，節點不再需要下載並保管每一個完整的 Blob 資料，而是只需要保管其中的 1/8 份。只要由四個節點者拿著各自的 1/8 份資料拼湊成 1/2 份，就可以完整還原出原始資料。每個節點該保管第幾份則由它的 p2p 網路 ID 所決定，節點們會透過 p2p 網路以及節點網路 ID 去向彼此索取和提供資料。

註：驗證者要保管比一般節點更多的分片（> 1/8），數量和驗證者質押金額成正比，達到質押金額上限（2048 ETH）的驗證者就會需要保管完整資料。

另外要注意的是資料分片發送後，接收方必須要有方式可以驗證「這真的是屬於原本 Blob 資料的第 X 份」，否則惡意人士就可以往 p2p 網路塞入一堆垃圾資料，騙其他節點們這些是有效的分片資料。在 EIP-4844 中我們引入了對 Blob 資料進行 KZG 承諾的運算，因此透過 KZG 承諾我們可以很方便快速地透過一個 KZG 證明來驗證「這真的是屬於原本 Blob 資料的第 X 份」，這個證明被稱作 Cell Proof。

未來的 DAS 設計會再進一步降低每個節點保管的資料大小，代表擴容進一步提升。不過這也考驗網路的韌性以及還原機制的設計，因為每個節點保管的資料變少表示需要更多節點參與才能合力還原出原始資料。要考量的除了節點數量之外，還有時機點（什麼時候要觸發大家一起合力還原？要避免隨便就能被觸發，否則分片就等於白做工）、溝通管道（效率、頻寬）和誰來負責還原（因為這可能需要硬體資源足夠的節點來做）。

EIP-7825: Transaction Gas Limit Cap

在 EIP-7825 以前，每筆交易可以消耗的 Gas 值（Gas Limit）是無上限的，只要使用者付得出手續費。如果一筆交易的 Gas Limit 值設得特別大會有幾個缺點：

• 排擠其他交易被收入的權利
• 潛在 DoS 攻擊風險：交易的 Gas Limit 設得很高但實際執行時只消耗一點點，讓區塊瞬間空了一大塊用不到
• 不利未來平行化交易驗證：平行化驗證將交易們分散成多個序列並同時進行驗證，但如果交易的 Gas Limit 都設成和區塊的 Gas Limit 一樣高，那其實平行化驗證就沒什麼意義了，因為每個序列都只能執行一筆交易

EIP-7825 將交易的 Gas Limit 設了一個上限：2²⁴ Gas（約為 16.78 M）。降低 DoS 攻擊風險外，也避免未來平行化驗證在使用者惡意或無意情況下做白工。

EIP-7935: Set default gas limit to 60M

目前節點預設的區塊 Gas Limit 值是 36M，之後驗證者們可以在每個區塊逐步調升區塊的 Gas Limit（每次增加不得超過 1/1024）。像是投票一樣，當驗證者們都有共識要將區塊 Gas Limit 調升至 45M 的話，那整個網路就會慢慢往目標前進。

但這個共識需要許多社交網路層面的大力宣傳，達成的速度也比較緩慢。某些驗證者背後的使用者未必有從社交網路上得知大家有這個目標，所以沒有一起參與。因此這個 EIP 便是藉由 Fusaka 升級來綁定調升區塊 Gas Limit 的目標，讓（預設的）區塊 Gas Limit 一次調升至 60M。

EIP-7892: Blob Parameter Only Hardforks

EIP-7892 將「每個區塊的 Blob 數量控制」從正式、大規模的升級（例如 Dencun、Pectra、Fusaka 等等）獨立出來。

Blob 資料格式在 Dencun 升級中引入，一開始定訂的目標 Blob 數量與上限數量分別是 3 與 6，接著在 Pectra 升級中調升至 6 與 9。雖然協調整個網路調整 Blob 數量並不會很困難，但其實它並不需要和正式、大規模的升級綁在一起，而是可以在社群經過壓力測試並達成共識的前提下一起進行調整，就像調整 Transaction Gas Limit 那樣。

EIP-7892 訂定「Blob 數量控制」自己的升級規則：所有客戶端只要一起更改「Blob 數量控制」的參數值即可，不需要配合一起升級客戶端，所以基本上不會有出錯的可能。不過因為是一個升級，所以還是要定訂一個生效時間點並要求所有客戶端在該時間點以前配合設置好參數及生效時間，否則網路一樣會出現硬分叉。

優化相關 EIP

EIP-7917: Deterministic proposer lookahead

EIP-7917 將共識層未來幾個 Epoch 的出塊者（Proposer）預先計算出來並儲存在共識層狀態裡，為出塊者名單提供可預測性，降低攻擊者影響出塊者名單的機會。

目前在共識層中下一個 Epoch 的出塊者名單都是在當前 Epoch 結束時才接著馬上計算，這是因為當初在設計時考量到驗證者在當前 Epoch 都有可能因為獎賞或懲罰而改變它們的押金數量，而押金數量會影響到一個驗證者被選為出塊者的機率，所以統一在一個 Epoch 結束後再按照所有驗證者最新的押金數量去選出下一個 Epoch 的出塊者。但這也給攻擊者一個潛在的攻擊向量：在最後一刻透過改變押金餘額的方式影響下一個 Epoch 的出塊者名單，藉此獲得優勢（如果沒優勢攻擊者就選擇不發動），這讓安全性分析變得更複雜。

因此 EIP-7917 規定要提前計算出未來 MIN_SEED_LOOKAHEAD 個 Epoch 的出塊者名單（MIN_SEED_LOOKAHEAD 是可調整的參數）並儲存在共識層狀態中，如此攻擊者就無法在最後一刻透過操控驗證者押金數量的方式去影響出塊者名單並獲得優勢。另外這對 Based Rollup 也有很大幫助。

Based Rollup
Based Rollup 沒有一個中心化的排序器（Sequencer），而是由 Ethereum 出塊者們輪流擔任該 Rollup 的出塊者，藉此增加抗審查能力以及讓 Rollup 的部分獲利能回流到 Ethereum 上。而 Based Rollup 的合約中需要有機制能驗證 Ethereum 出塊者的身份，才能允許其擔任 Rollup 的出塊者，因此 EIP-7917 將未來數個 Epoch 的出塊者資訊寫入共識層狀態中後，Based Rollup 合約就能透過 EIP-4788 去讀取共識層狀態並解析出接下來的出塊者名單，如此就可以基於這個名單來驗證誰才有資格為其 Rollup 出塊。

EIP-7823: Set upper bounds for MODEXP

MODEXP 是一個預編譯合約，用來對模數做指數運算。相比於使用 EVM 位元組碼（Bytecode）來進行模數的指數運算，用 MODEXP 會更為便宜。不過當初在新增 MODEXP 預編譯合約時並沒有對輸入值的大小做限制，因此過去在許多測試案例中常常導致不同客戶端產出不一樣的結果，這在實際的鏈上發生的話會直接導致鏈的分叉。

EIP-7823 將 MODEXP 輸入值的大小限制在 8192 位元（Bits），8192 位元的大小涵蓋所有常見用例，也避免了可能的惡意輸入值導致非預期結果。

EIP-7883: ModExp Gas Cost Increase

EIP-7883 調高 MODEXP 預編譯合約的執行成本，因為原本的執行成本定價過低，被利用的話會導致對網路的 DoS 攻擊。

EIP-7934: RLP Execution Block Size Limit

EIP-7934 為執行層（Execution Layer）的區塊大小加了一個上限，避免攻擊者刻意產生很大的區塊導致效能較弱的節點跟不上驗證速度，或是因為區塊太大導致某些節點拒收（共識層的客戶端有對從 p2p 網路接收的區塊大小設一個 10 MiB 上限，避免被 DoS 攻擊）。

在 EIP-7934 之後，執行層的區塊大小最大為 8 MiB，超過就會直接被視為不合法的區塊。

註：這 EIP 保留一個 2 MiB（2 = 10 - 8）的空間給共識層區塊，因為共識層傳遞的內容是包含共識層區塊加上執行層區塊，而共識層 p2p 網路本身又有 10 MiB 大小上限，所以不能10 MiB 都給執行層區塊，否則共識層區塊加上去會超過 10 MiB。

EIP-7939: Count leading zeros (CLZ) opcode

EIP-7939 新增一個 CLZ 操作碼（Opcode），用來方便計算一個 256 位元的值的前面有多少個零。

計算「一個值前面有多少個零」是一個基本常見的運算功能，而 EVM 本身不支援這個原生運算，所以合約開發者或編譯器必須要用 SHR（Shift Right）這個操作碼來做這件事。有了 CLZ 這個操作碼之後，合約可以省下 Gas，本身的合約大小也可以減少。

EIP-7918: Blob base fee bounded by execution cost

EIP-7918 為 Blob 資料的成本設一個下限，避免 Blob 成本在總成本由「非 Blob 成本」所主導的情況下讓 Blob 的供需機制失靈。

Blob 資料的手續費和一般 Gas 的手續費一樣會在用量超過目標值時指數上升；在用量低於目標值時指數下降。但如果一般 Gas 的成本（即上述「非 Blob 成本」）遠大於 Blob 成本，例如市場熱絡導致 Gas Fee 大幅提升，此時 Rollup 們就會降低發佈資料的頻率，導致 Blob 需求降低及 Blob 手續費驟降，也就是 Blob 的供需機制反而被「非 Blob 成本」所影響而失靈。

EIP-7918 新增了一個 Blob 資料成本的下限：如果一般 Gas 消耗的成本大過於 Blob 資料成本的話，就不調降 Blob 手續費。判斷式如下：

if (
  BLOB_BASE_COST * parent.base_fee_per_gas # 1
  >
  GAS_PER_BLOB * get_base_fee_per_blob_gas(parent) # 2
) 

• #1: BLOB_BASE_COST 是這個 EIP 所新增的參數，是一個用來計算「Blob 對應到一般 Gas 」用的常數，所以它是乘上 base_fee_per_gas（也就是一般 Gas 手續費）
• #2: 是原本 Blob 成本計算的方式，所以是乘上 base_fee_per_blob_gas

如果 #1 > #2 就表示一般 Gas 成本高於 Blob 成本，那就不會扣掉「累積的 Blob 使用數」（稱為 excess_blob_gas），等同於 Blob 越用越多，所以即便實際上每個區塊的 Blob 使用數持續低於目標值，Blob 手續費也不會降低，甚至會緩慢上升。如果 #2 > #1，那就會按照原本 Blob 供需機制去調整「累積的 Blob 使用數」和 Blob 手續費。以下是計算「累積的 Blob 使用數」的函式，Blob 手續費會參考這個值來計算：

def calc_excess_blob_gas(parent: Header) -> int:
    target_blob_gas = GAS_PER_BLOB * blobSchedule.target # 每個區塊的 Blob 使用數目標值
    if parent.excess_blob_gas + parent.blob_gas_used < target_blob_gas:
        # 累積的 Blob 使用數本來就沒超過目標值，所以維持為零
        return 0

    if BLOB_BASE_COST * parent.base_fee_per_gas > GAS_PER_BLOB * get_base_fee_per_blob_gas(parent):
        #1 > #2，持續維持並累積 Blob 使用數
        return parent.excess_blob_gas + parent.blob_gas_used * (blobSchedule.max - blobSchedule.target) // blobSchedule.max
    else:
        #2 > #1，按照原本 Blob 供需機制新增或減少累積 Blob 使用數
        return parent.excess_blob_gas + parent.blob_gas_used - target_blob_gas

使用體驗相關 EIP

EIP-7951: Precompile for secp256r1 Curve Support

EIP-7951 將許多 L2 已經支援的預編譯合約 — secp256r1（或稱 P256）橢圓曲線的 ECDSA 簽章驗證 — 新增到 Ethereum 上。

secp256r1 橢圓曲線的 ECDSA 簽章驗證是目前越來越常見的 Passkey 的簽章演算法，使用者透過 Passkey 可以直接以硬體裝置（例如手機或電腦）本身的安全晶片裡的私鑰進行數位簽章。透過 Passkey，錢包可以提供非常流暢的上手體驗 — 使用者只需要掃臉或指紋即可創建錢包，不必再記下並保管好助記詞或私鑰。

註：Ethereum 和 Bitcoin 一樣最初都只有支援 secp256k1 橢圓曲線的 ECDSA 簽章驗證。

現在有 L2 都已遵循 RIP-7212 的標準將這個預編譯合約新增到本身的鏈上，增進使用者體驗。而 Ethereum 則因為需要更久的社群共識才有辦法新增，所以直到此次升級才完成。在這之前開發者只能直接寫一個智能合約來實作相關的驗證邏輯，但缺點是 Gas 消耗非常高。在這次升級之後，Ethereum 上的錢包也都能以相當便宜的方式驗證 Passkey 簽章，讓更多使用者體驗到流暢的錢包創建過程。

EIP-7951 在地址 0x100 上新增一個預編譯合約用來驗證 secp256r1 橢圓曲線的 ECDSA 簽章，每次呼叫會消耗 6900 Gas（不管驗證成功或失敗）。

註 1：0x100 地址是遵循既有的 RIP-7212 內容，讓所有鏈都能統一將這個預編譯合約部署在同一個地址。

註 2：常見的 ECRECOVER 預編譯合約（sepc256k1 的 ECDSA 簽章驗證）消耗 3000 Gas。

客戶端規則相關 EIP

EIP-7642: eth/69 — Drop pre-merge fields

EIP-7642 減少節點同步時所需的資料量以及支援「歷史資料刪減（History Pruning）」在 p2p 層所需要的功能。

1. 不再同步交易收據（Transaction Receipt）的 Bloom Filter 資訊
新的節點在加入後會從 p2p 網路同步所有歷史交易的收據的 Bloom Filter 資訊。Bloom Filter 資訊用來快速篩選出特定交易，但實際上節點同步完後並不會儲存 Bloom Filter 資訊，所以 EIP-7642 將 Bloom Filter 資訊的同步需求移除，當有使用者想要查訊特定交易時，節點再實時計算出 Bloom Filter 資訊即可。如此可為新節點所需的同步資料量節省約 530 GB。

2. p2p 節點支援告知、通知自己「儲存哪個範圍的歷史區塊資料」
在 Pectra 升級後，規定節點可以不再儲存 The Merge 前的歷史資料，因此 p2p 網路層也會需要相對應的改動來支援向 p2p 節點索取歷史資料。EIP-7642 規定 p2p 節點在告知其他節點自己的資訊時，要額外附上自己所儲存的歷史資料範圍（earliestBlock(Number) 及 latestBlock(Number)），避免其他節點來向自己查詢自己沒有的資料而浪費時間。另外自己的儲存資料範圍有更新時也可以透過新增的通知格式去通知和自己有連結的 p2p 節點。

EIP-7910: eth_config JSON-RPC Method

EIP-7910 新增一個 JSON-RPC 接口供查詢一個節點的升級相關設定值，讓社群可以更好地在升級前掌握節點們及驗證者們是否都已經升級到正確的版本。

二月在 Holesky 測試網上的 Pectra 升級遭遇多數客戶端錯誤的升級參數設置，導致升級時多數錯誤的客戶端的驗證者們竟然分叉錯誤的鏈出去而且還成功完成區塊最終敲定（Finalize）。整個測試網最終花了兩週左右完成復原，將大多數驗證者們切換回正確的鏈，但也因此導致 Pectra 測試被延宕，最終社群決定下線 Holesky 並新起一個 Hoodi 測試網。

EIP-7910 為每個節點新增一個 eth_config 的 JSON_RPC 接口，讓別人可以查詢一個節點的「當前升級版本」、「下一次升級」及「最新已知升級」的相關設定值。每個升級的設定值包含：該鏈/升級的 ID、啟用時間或排定啟用時間、Blob 資料設定值、預編譯合約們及系統合約們。將預編譯合約與系統合約包含在內方便大家一起比對節點是否有為這些合約設定正確的地址，這也是 Holesky 的 Pectra 升級出錯主因。

參考資料與推薦延伸閱讀

• 介紹 Fusaka 升級的 thread 和文章
• EIP-7594 共同作者介紹 PeerDAS 的影片
• EIP-7825 介紹影片
• 區塊 Gas Limit 變化與驗證者們投票
• EIP-7917 共同作者介紹及社群其他人的介紹
• 二月 Holesky 的 Pectra 升級事故

TEM Medium 2025 有獎徵稿

TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 有獎徵稿

Special thanks to Kimi Wu and Kevin Chia for reviewing and improving this post

Ethereum Fusaka 升級介紹 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

如果希望能更完整吸收這篇文章的內容，可以先閱讀過以下主題：

• Rollup 和 L2
• 跨鏈橋
• Data Publication

注意：本篇文章參考的是 2025/04 的 L2Beat 網站介面，網站未來可能會新增或刪去資訊導致看起來和文章裡的截圖不一樣。

L2s Summary

主頁 Summary 可以看到不同 L2 的排名，上圖中上方的三個標籤頁「Rollups」、「Validiums & Optimiums」、「Others」分別代表不同 Data Publication 設計的 L2。

• Rollup 將 L1 作為資料發佈層
• Validiums & Optimiums 採用 L1 以外的方案作為資料發佈層
• Others 裡的 L2 則是因為缺乏證明系統（ZK 或 OP 的挑戰機制）或足夠安全的資料保障，而被歸類在這

如上圖中所示，L2Beat 為 L2 列出的屬性包含 「RISKS」、「TYPE」及「STAGE」。「STAGE」目前是 Rollup 才有，非 Rollup 則是顯示其「DA LAYER」

1. RISKS：包含一個 L2 在不同功能上的安全程度
2. TYPE：這個 L2 是 ZK 還是 OP
3. STAGE：這個 Rollup 成熟的程度，總共三個階段
4. DA LAYER：這個 L2 將資料發佈到哪

1. RISKS

RISKS 裡共分為五個面向「STATE VALIDATION」、「DATA AVAILABILITY」、「EXIT WINDOW」、「PROPOSER FAILURE」及「SEQUENCER FAILURE」。如果點進去可以看到更完整的資訊。

STATE VALIDATION
“該 L2 的狀態有效性是如何被確保的”。可以是密碼學的 ZK Proofs 或挑戰機制的 Fraud Proofs。ZK Proofs 有分 ST(ARK) 或是 SN(ARK)；Fraud Proofs 有分 1R 或是 INT，代表一回合或多回合制的挑戰機制。如果發起挑戰機制有白名單限制的話評分會被降級（降為黃色或紅色）。

註：挑戰機制的設計會同時附註挑戰期（challenge period）的長度。

DATA AVAILABILITY
“該 L2 的資料發佈到哪”。Rollup 都是綠色的（顯示為 Onchain），代表資料沒有額外的信任假設；非 Rollup 則是紅色的（顯示為 External）。

另外 Onchain 有分是否有「（SD）」的備注：

• 有（SD）備註代表該 Rollup 上傳的資料是每個區塊壓縮過後的狀態差異（State Diff）
• 沒有（SD）備註代表上傳的是每個區塊的每一筆交易資料

註：ZK Rollup 才可以在不影響安全性的前提下選擇資料上傳是否要用 State Diff。

EXIT WINDOW
“如果該 L2 進行一個使用者不喜歡的版本升級，則使用者有多少時間可以退出該 L2”。

• 如果升級生效的時間足夠長到讓使用者成功發起離開請求並成功在 L1 取回該取得的資產的話，那就是綠色的，並顯示升級生效時間
• 如果有緊急保護措施例如安全委員會（Security Council）可以讓升級馬上生效的話就會降級為黃色
• 如果升級本來就會馬上生效的話那就是紅色的。

如果為綠色或黃色，則鼠標移到天數上時 L2Beat 還會詳細列出「升級生效時間」、使用者「發起退出請求」及「完成退出」最長各需要多少天。如果該 L2 合約為不可升級，則 EXIT WINDOW 會是無限（因為就不需要擔心合約被惡意升級）。

SEQUENCER FAILURE
“如果負責排序交易並出塊的排序器（Sequencer）下線了或在審查某些使用者的交易時，使用者可以怎麼繞過排序器並自行插入交易”。

• 如果使用者可以自行從 L1 插入交易並在延遲結束後自行完成插入，那就是綠色的（Self sequence）
• 如果使用者只可以插入交易但是不能自行「完成」插入的話，那就是橘色的（Enqueue via L1）
• 如果使用者完全沒辦法自行插入交易的話，那就是紅色的（No mechanism）。

像 ZKsync 目前就屬於 Enqueue via L1：使用者可以自行插入交易，但延遲結束後排序器可以選擇不處理，導致用戶的交易一樣無法被收入區塊中。不過排序器只能全都處理或全都不處理，不能單獨不處理某些使用者。

另外還有少數 L2 是屬於 Force via L1 的設計。在這種設計中，使用者可以自行插入交易，而如果排序器沒有在時限內收入使用者交易的話，使用者就可以觸發 L2 的暫停程序，該 L2 將完全停止並讓使用者各自提供資產證明來將資產退出 L2，這個機制稱為 Escape Hatch。

註：自行插入交易到完成插入之間會需要一段延遲是因為要避免惡意使用者透過直接在 L1 插入交易來影響或打亂排序器出塊的過程。想了解更多自行插入交易（Force Inclusion）的細節可以參考這篇文章：

Rollup 的 Force Inclusion 機制介紹

PROPOSER FAILURE
“如果負責提交 L2 最新狀態的 Proposer 下線了該怎麼辦”。

• 如果任何人都能接替成為 Proposer 或是有 Escape Hatch 機制來暫停 L2 並讓所有人撤離的話，那就是綠色的（Self propose 或 Use escape hatch）
• 如果只有白名單的人可以擔任 Proposer，但治理機制可以替換 Proposer 的話，那就是橘色的（橘色的 Cannot withdraw）
• 如果 Proposer 是白名單且沒辦法替換的話，那就是紅色的（紅色的 Cannot withdraw）。

2. TYPE

TYPE 有分「ZK Rollup」、「Optimistic Rollup」、「Validium」、「Optimium」四種。

• 把資料發佈到 L1 的是 Rollup。按照 State Validation 機制可分為用 ZK 或 Optimistic 兩種，例如 ZK Rollup 或 Optimistic Rollup。
• 如果是 ZK 機制但把資料發佈到 L1 以外的地方的話，會變成 Validium
• 如果是 Optimistic 機制但把資料發佈到 L1 以外的地方的話，會變成 Optimium

註：Validium 把資料發佈到其他地方並不會影響它的安全性，但 Optimium 的安全性和 Optimistic Rollup 相比則是大打折扣。想了解更多細節可以參考

Validity(ZK) Rollup 在上傳資料類型上的選擇

3. STAGE

STAGE 則是 Rollup 專屬，分為 STAGE 0~2。要成為至少 STAGE 0 得要符合以下條件：「定義自己為一個 Rollup」、「Rollup 的狀態根（State Root）要上傳至 L1 上」、「輸入到 State Transition Function 的資料要發佈至 L1 上」、「至少要有一個開源的軟體可以從發佈至 L1 的資料推導計算出該 Rollup 最新的狀態」，這幾個條件是為了要確保一個 Rollup 有最基本的安全性：

• Rollup 的狀態根（State Root）要發佈至 L1 上：狀態根要發佈到 L1 上，使用者才能透過狀態樹（State Tree）的 Merkle Proof 證明自己在 Rollup 上的資產多寡，或是證明自己在 Rollup 上發起的提款請求。否則只能仰賴中心化角色批准提款，沒辦法讓使用者自己證明的話，那安全性就會變得和 Side Chain 一樣低
• 輸入到 State Transition Function 的資料要發佈至 L1 上：「輸入到 State Transition Function 的資料」指的是例如 Rollup 交易資料，如果這些資料沒有發佈到 L1，那使用者就沒辦法推導計算出最新的 Rollup 狀態，也就沒辦法產生狀態樹的 Merkle Proof
• 至少要有一個開源的軟體可以從發佈至 L1 的資料推導計算出該 Rollup 最新的狀態：有了資料也仍然需要一個軟體可以推導計算出最新狀態，如果沒有一個開源軟體讓大家能下載使用，那等到出事時再寫可能就來不及了

STAGE 0：Full training wheel
當一個 Rollup 提供了最基本的安全性保障，但因為還在開發初期，所以沒有資源設置一個安全委員會來應付重大 Bug 或攻擊的發生，或 ZK/Fraud Proof 機制的運作仍然掌握在中心化角色手上，或甚至 ZK/Fraud Proof 還未上線。

要前進到 STAGE 1，Rollup 必須要達成「ZK/Fraud Proof 要上線並正常運作」、「如果是採用 Fraud Proof 機制，則至少要有五名開發團隊以外的角色可以發起挑戰或防禦」、「使用者可以自行退出 Rollup，不需中心化角色協助」、「需設立安全委員會，且至少要有 8 名成員與 75% 以上的執行同意門檻」及「如果是比安全委員會更中心化的角色啟動了一個異常升級，則使用者必須要有至少七天的窗口能退出該 Rollup」，這幾個條件是為了要確保一個 Rollup 足夠去中心化，讓使用者的安全性至少掌握在像安全委員會而非中心化角色手上。

• ZK/Fraud Proof 要上線並正常運作：如果沒有正常運作的 ZK/Fraud Proof，那該 Rollup 的安全性基本上就和 Side Chain 一樣
• 如果是採用 Fraud Proof 機制，則至少要有五名開發團隊以外的角色可以發起挑戰或防禦：確保發起挑戰或防禦的權利不會只落在開發團隊手上，在攻擊發生時有人能跳出來保障使用者
• 使用者可以自行退出 Rollup，不需中心化角色協助：即便 ZK/Fraud Proof 可以確保使用者安全性，但如果退出 Rollup 還把持在中心化角色手上，則還是有被審查的風險
• 需設立安全委員會，且至少要有 8 名成員與 75% 以上的執行同意門檻：安全委員會是在緊急狀況發生時能直接介入啟動立即升級的角色，主要是確保 ZK/Fraud Proof 機制或 L1 合約出問題可以及時修補漏洞，但也因此它的去中心化及執行同意門檻要求也特別高
• 如果是比安全委員會更中心化的角色啟動了一個異常升級，則使用者必須要有至少七天的窗口能退出該 Rollup：確保如果安全委員會不存在或安全委員會無法正常運作，則在 L1 合約出現漏洞或中心化角色作惡導致觸發惡意升級時，使用者要有足夠時間可以退出該 Rollup

STAGE 1：Limited training wheel
進到 STAGE 1 後 Rollup 已經有基本的去中心化程度 — 安全委員會可以及時介入或是使用者有足夠多的時間在無退路的情況下退出 Rollup，剩下的就是再進一步降低信任需求。

要進到 STAGE 2，Rollup 必須要達成以下條件：

1. 「如果是採用 Fraud Proof 機制，則任何人都要可以發起挑戰或防禦」：也就是真正實現 Fraud Proof 的 1-of-N 安全假設 — 只要該 Rollup 有至少一個人在監督就可以確保所有人的安全，不需仰賴白名單裡的人去監督
2. 「如果使用者不喜歡最新的升級改動，他是否有至少 30 天的時間可以退出該 Rollup」：當一個 Rollup 決議進行升級後，讓使用者們有充足的時間決定是否要留下或退出該 Rollup
3. 「安全委員會能立即升級的權力是否能限縮於出現漏洞的情況」：如果 安全委員會立即升級的操作能限縮在 ZK/Fraud Proof 或 L1 合約出現漏洞的情況，使用者們就不需擔心安全委員會如果作惡可以突然進行升級

這幾個條件是為了要確保一個 Rollup 足夠成熟能讓不認同該 Rollup 的使用者在充足的時間下決定是否要留下或退出，以及更進一步限縮關鍵角色的權力和中心化程度。

STAGE 2：No training wheel
STAGE 2 已盡可能降低信任需求，且使用者有充足的時間可以退出，不過目前只有少數 Rollup 達到 STAGE 2。

想了解更多關於 Rollup Stage 的介紹可以參考 L2Beat 的文章：

Introducing Stages — a framework to evaluate rollups maturity

註：但仍然有些人覺得可升級合約和安全委員會是安全隱患，所以提出了叫 Unstoppable Rollup 的概念。

4. DA LAYER

Validiums & Optimiums 因為不是將資料發佈到 L1 上，所以 L2Beat 會記錄它們將資料發佈到哪。除了有額外的信任需求（例如發佈到 Celestia 就要額外相信 Celestia 的安全性），Validiums & Optimiums 還需要額外煩惱跨鏈橋的安全性，因為 Validiums & Optimiums 的 L1 合約沒辦法知道資料到底發佈了沒、發佈的到底是不是正確的，所以合約必須仰賴一個跨鏈橋將訊息從資料發佈層（例如 Celestia）帶過來驗證。以 Manta 為例，它將資料發佈到 Celestia 上，它在 L1（Ethereum）的合約就會需要有人將 Celestia Validator 們的簽名帶過來驗證，以確保它預期的資料真的有發佈到 Celestia 上、被 Celestia Validator 們所保管著。但因為這通常牽涉到一次驗證數百、數千個簽章且頻率很高，所以目前基本上大部分的 Validiums & Optimium 都不支援 DA 跨鏈橋，因為成本划不來。

另外還需要考慮的是如果資料發佈層的保管者沒有確實下載資料並保管呢？該資料發佈層是否有機制能懲罰它們？在下方的「Data Availability 章節」會再深入介紹資料發佈層的安全性分級。

Project Detail

每個 L2 點擊進去都有更完整的資訊，除了基本的 TVL、TPS、L1 合約之外，從技術架構介紹到風險分析，甚至項目的里程碑及重大事件都有記錄。

以 Arbitrum 為例：

Risk Summary

• 如果 L1 合約進行惡意升級的話，則使用者資產有可能被全部盜走。升級除了由安全委員會執行是立即生效之外，都會有 17 天 8 小時的延遲（點擊連結的話會進到技術及天數計算的解釋）
• 如果攻擊者在 Arbitrum 的 Fraud Proof 機制中透過和守護者打消耗戰的方式拖過挑戰期的話，則使用者資產有可能被全部盜走
• 如果挑戰機制設計或實作有誤，則使用者有可能遺失資產
• 如果排序器作惡，則可以從使用者交易中套取 MEV

L2Beat 也為每個 L2 紀錄相當完整的技術和架構細節，如果該 L2 提供的文檔和開源程式碼越多，L2Beat 就能記錄得越詳盡。

State derivation & validation

State derivation 及 validation 介紹 L2 的狀態是如何推導計算而來、採用的交易格式及資料壓縮技術，以及如何進行驗證（ZK 或 Fraud Proof），甚至不同 Fraud Proof 機制也一樣有圖片搭配簡介：

Operator & Sequencing

Operator 及 Sequencing 的部分介紹排序器是否中心化、使用者是否有權力自行安插交易，以及如何自行安插交易：

• Arbitrum Operator（即排序器）為中心化，所以如果作惡的話可以榨取使用者交易的 MEV
• 使用者可以到 L1 自行安插交易，排序器必須要在最晚一天等待期內收入使用者交易，否則使用者在等待期結束後可以自己完成安插

Other considerations

L2Beat 也會紀錄一些 L2 標準技術以外，但值得留意的事情，例如：

• Arbitrum 同時支援 EVM 及 WASM VM，開發者可以利用 Solidity 或 Stylus 語言開發智能合約，不過這也增加了其挑戰機制的複雜度，如果挑戰機制設計或實作出了問題，使用者可能會因此遺失資產
• Arbitrum DAO 可以對 L2 & L1 合約進行升級：Arbitrum DAO 的治理發生在 L2，每次治理通過 L2 合約升級會首先有一個 8 天的延遲，接著升級 L1 合約會再經過 3 天延遲，然後因為升級 L1 合約是由 L2 所發起，所以和一般 L2->L1 交易一樣會經過 6天 8 小時挑戰期，所以一共需 17 天 8 小時來完成 L2 & L1 合約升級

Upgrades & Governance

L2Beat 也詳盡地列出 L2 治理的執行過程，包含整體架構、牽涉到的合約，以及參與的角色等等：

Data Availability

Data Availability 頁面紀錄每個 L2 在資料發佈方面的技術方案及相關的安全等級，包含「DA LAYER」、「DA BRIDGE」、「RISKS」、「TYPE OF DATA」。

DA LAYER

L2 將資料發佈到哪？（對 Ethereum L2 來說）最安全的是發佈到 Ethereum，就完全不需要額外的信任假設，而 Rollup 都是發佈到 Ethereum。而屬於 Validiums & Optimiums 的 L2 就會發佈到其他地方，例如 EigenDA、Celestia、Avail、DAC，這些資料發佈解決方案有各自的安全假設及不同的經濟安全性，另外也要注意是否有 DA BRIDGE 來讓 L2 驗證 DA LAYER 的驗證者簽章，而不是單純相信 DA LAYER 會保管好資料。

DA BRIDGE

如果資料並非發佈在 Ethereum 上，那就需要一個橋來讓部署在 Ethereum 上的 L2 合約知道「資料是否已被正確發佈」，通常會包含驗證該 L2 使用的 DA LAYER 的驗證者的簽章，例如 Manta 將資料發佈到 Celestia 上，那 Manta 在 Ethereum 的合約就會需要透過 Celestia 提供的 DA BRIDGE 去驗證 Celestia 驗證者們的簽章，確保 Celestia 驗證者們真的有好好保管這些資料。不過單純驗證簽章也仍然不夠安全，因為這代表驗證者們欺騙該 L2 是沒有成本的，更可靠的做法是在驗證者們說謊時能懲罰他們。

TYPE OF DATA

L2 發佈的是「交易資料（Transaction data）」還是「區塊的前後狀態差異（State diff）」，以及這些資料是否有經過壓縮再發佈。採用 State diff 在某些假設下可以產生更少的資料，資料發佈的成本也就越低，但相對地在鏈下網路要去同步交易資料就會比較複雜。

RISKS

如果點進一個 L2 的 RISKS 圖示，會跳轉到更詳細的 Data Availability 分析頁面，分析不同 DA LAYER 及 DA BRIDGE 的風險：

L2Beat 將資料發佈風險的考量分為 DA LAYER 及 DA BRIDGE 兩類。

• DA LAYER 有兩點風險考量：「ECONOMIC SECURITY」、「FRAUD DETECTION」
• DA BRIDGE 有三點風險考量：「COMMITTEE SECURITY」、「UPGRADEABILITY」、「RELAYER FAILURE」

DA LAYER — ECONOMIC SECURITY
如果 DA LAYER 驗證者說謊的話，他們會不會付出代價？如果說謊會導致他們質押的代幣被銷毀，那就是綠色的（Staked assets）；如果是影響他們的聲譽，那就是橘色的（Public committee）；如果什麼代價都不必付出，那就是紅色的（No slashing）。

DA LAYER — FRAUD DETECTION
那要怎麼知道驗證者們說謊？要看該資料發佈解決方案的設計，像是 Celestia 或 Avail 就有提供 Data Availability Sampling（DAS）技術，來讓使用者可以透過鏈下節點「偵測」驗證者們是否有真的保管好資料，或甚至是讓使用者們可以合力「還原」出完整資料，進一步提高驗證者們作惡的難度。更多關於 DAS 的介紹可以參考：

Data Availability Sampling（一）：為什麼會需要 DAS？

如果有提供 DAS 並支援「還原」資料的能力，那就是綠色的（DAS）；如果只有支援「偵測」資料發佈不完整的能力，但不支援還原的話，那就是橘色的（DAS）；如果不提供 DAS，那就是紅色的（None）。

不過要特別注意，這些「偵測」與「還原」能力僅只限於鏈下的使用者才能使用，Ethereum 上的 L2 合約無法自己運行節點並執行 DAS，它只能仰賴別人告訴它，而鏈上最可靠的資訊來源就是透過 DA BRIDGE 傳來的驗證者們的簽章，如果超過一定數量的驗證者簽名表示資料已發佈，那 L2 合約就相信資料已發佈。這表示如果驗證者們說謊，它們是可以騙過 L2 並造成傷害的，這時會需要仰賴鏈下使用者們發現驗證者們說謊並透過 Slashing、治理或硬分叉機制去懲罰驗證者們。

DA BRIDGE — COMMITTEE SECURITY
要說服 L2 合約「資料已發佈」，會需要超過一定數量的驗證者的簽名，這個門檻的選擇會影響該 L2 的安全性及活性（Liveness）：如果門檻越高（例如 2/3），那就越安全，但也表示只要超過 1/3 驗證者不在線、不簽名，那該 L2 就會停擺；如果門檻越低（例如 1/2 或 1/3），那就能容忍越多驗證者不在線或不簽名，越不容易停擺，但相對的要騙過 L2 合約就變得越容易。

目前 L2Beat 定義如果「驗證者數量太少」、「驗證者同不夠多樣化」、「門檻定義的不夠嚴謹」或其他原因例如「資料發佈仰賴該 L2 的中心化排序器在線」，那 COMMITTEE SECURITY 就會是紅色的；如果驗證者夠多樣化且門檻夠高，使得只要少數（< 33%）驗證者是好的就能防止 L2 合約被騙，那就是橘色的；如果驗證者的組成不是由中心化角色所決定，那就能從橘色變成綠色的。

DA BRIDGE — UPGRADEABILITY
如果用來通知 L2 合約「是否有足夠多的驗證者已簽名」的 DA BRIDGE 合約是可被立即升級的，那就有可能被攻擊者替換掉並欺騙 L2 合約，那 UPGRADEABILITY 就是紅色的（No delay）；如果升級有延遲，但延遲不夠久或有安全委員會可以執行立刻升級，那就是橘色的；如果升級延遲久到讓 L2 使用者有足夠時間退出，那就是綠色的（但目前沒有 DA BRIDGE 達成綠色的 UPGRADEABILITY）。

DA BRIDGE — RELAYER FAILURE
負責將驗證者帶到 DA BRIDGE 合約的 Relayer 角色是否是中心化的？如果是中心化且沒有機制可以替換掉 Relayer，那就表示 Relayer 一但下線，L2 就會停擺，那就是紅色的（No mechanism）；如果有機制（例如 Governance）可以替換 Relayer，那就是橘色的；如果任何人都可以當 Relayer，那就是綠色的（Self propose）。

DA Layer Detail

每個 DA LAYER 點擊進去都有更完整的資訊，有基本的 Total Value Secured（TVS）、經濟安全性（Economic security）、資料頻寬（Max throughput）、資料保存時間（Duration of storage）、被哪些 L2/L3 所使用，另外像技術架構介紹到風險分析，甚至項目的里程碑及重大事件也一樣都有記錄。

• Total Value Secured：所有使用該 DA LAYER 的 L2/L3（但不包含 Sovereign Rollup）的總 TVL
• 經濟安全性：該 DA LAYER 的驗證者們說謊時是否會受到經濟上的懲罰，而這懲罰金額有多少
• 資料頻寬：該 DA LAYER 每秒可以發佈多少 MiB 的資料上去
• 資料保存時間：資料發佈到該 DA LAYER 後，它的驗證者們會保管資料多久（這段時間是用來確保資料有正確被發佈、可被檢驗，不是用來確保資料「永遠可取得」，永遠可取得的特性是 L2/L3 要自己確保的，例如 Archive 節點）

以 EigenDA 為例，它細分為「No DA Bridge」與「有 DA Bridge（Service Manager）」兩種分析：

以下以「有 DA Bridge（Service Manager）」為例。

Risk Summary

• EigenDA 負責處理資料發佈的 Disperser 角色可以審查、不處理使用者的交易。目前 Disperser 是由 Eigen Labs 營運，如果未來由 L2 自己營運且能去中心化的話，那就能免去使用者交易被審查的風險
• 如果 EigenDA 的 DA Bridge 合約、Eigen DA 仰賴的 EigenLayer 合約、提供經濟安全性的 EIGEN 代幣合約，任一個合約進行惡意升級導致 L2 上當相信一個其實沒有被正確發佈的資料，那就會導致資料不可得，使用者可能沒辦法獲得 L2 最新的狀態來證明自己的資產
• 如果 EigenDA 的驗證者們被惡意踢除，或 DA Bridge 合約因技術問題導致可以被惡意驗證者欺騙，那一樣會導致資料不可得，使用者可能沒辦法獲得 L2 最新的狀態來證明自己的資產
• 如果中心化 Relayer 下線或 DA Bridge 合約被暫停，那 L2 就會停擺，使用者無法提取資產

L2Beat 也會介紹每個 DA Layer 的技術架構和合約細節。

Technology

Architecture 介紹 DA Layer 的架構。以 EigenDA 為例，L2 排序器將交易排序好後，交給 Disperser 進行資料發佈的準備，準備完後將不同段的資料交給不同 EigenDA 節點（即驗證者）保管。另外有一個 Retriver 角色是代為需要資料的使用者去向節點請求不同資料片段並進行組裝與還原。

每一個 DA LAYER 的架構和技術方案都不一樣，不像 Rollup 有許多共同的基礎元件可以互相比較不同 Rollup 設計，但 L2Beat 仍然非常詳盡地記載這些 DA LAYER 的技術細節。

參考資料與推薦延伸閱讀

• https://l2beat.com/scaling/summary
• https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe
• https://l2beat.com/scaling/projects/arbitrum
• https://l2beat.com/scaling/data-availability
• https://l2beat.com/data-availability/projects/celestia/no-bridge#da-layer

TEM Medium 2025 有獎徵稿

TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 有獎徵稿

Special thanks to Chih-Cheng Liang and Chang-Wu Chen for reviewing and improving this post

L2Beat 解析 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pectra 硬分叉預計於 2025/03 於主網部署。Pectra 包含 11 個 EIP，

• EIP-2537: Precompile for BLS12–381 curve operations
• EIP-2935: Save historical block hashes in state
• EIP-6110: Supply validator deposits on chain
• EIP-7002: Execution layer triggerable exits
• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
• EIP-7549: Move committee index outside Attestation
• EIP-7623: Increase calldata cost
• EIP-7685: General purpose execution layer requests
• EIP-7691: Blob throughput increase
• EIP-7702: Set EOA account code
• EIP-7840: Add blob schedule to EL config files

接下來會將相關的 EIP 一起介紹，不會按照 EIP 號碼大小介紹。

先備知識：

• Ethereum 區分為共識層（Consensus Layer，CL）及執行層（Execution Layer，EL）

質押（Staking）相關 EIP

EIP-6110: Supply validator deposits on chain

EIP-6110 簡化使用者參與質押的處理流程，讓等待時間大幅縮短

使用者參與質押的方式是在 EL 上透過一個 Deposit 合約存入 32 ETH 並由事件日誌（Event Log）記錄，接著 CL 節點會去解析 EL 區塊裡的 Deposit 合約的 Event Log 來判斷是否有人質押並登錄其質押資料，然後質押的使用者就可以成為驗證者。

不過 CL 驗證者們首先要針對哪一個時間點的 Deposit 去解析達成共識，否則會發生有些驗證者看到有 5 個新的 Deposit，而有些驗證者只看到 3 個，因此 CL 驗證者們會對「要參考哪一個 EL 區塊（稱為 eth1data）」進行投票，確保大家看到的是一樣的 EL 區塊。不過一開始設計時為了避免 EL 出現重大錯誤導致鏈分叉，所以參考的 eth1data 會是一個約 10 多個小時以前的 EL 區塊，確保當重大錯誤發生時，CL 的開發者們有足夠的時間反應。不過這也導致現在參與質押最快也要等上 10 多個小時才會生效。

EIP-6110 之後，使用者在 Deposit 合約上的質押資料會直接變成 EL 區塊的一部分。而因為 CL 區塊本身就會包含 EL 區塊（但不是 eth1data），所以 CL 驗證者們就不用再煩惱「要確認參考的 EL 區塊是一樣的」的問題，只要 CL 區塊獲得超過 2/3 驗證者們投票並 Finalized，就可以相信大家看到的是同一個 EL 區塊。因此使用者參與質押後，最快約 13 分鐘等 EL 區塊 Finalized 之後就可以生效，而且 CL 客戶端也可以移除原本用來處理質押資料相關的複雜邏輯。

EIP-7002: Execution layer triggerable exits

EIP-7002 改善驗證者退出質押或提領押金和收益的流程，降低驗證者的風險

當一個使用者參與質押，他需要有兩把鑰匙：(1) Validator Key 及 (2) Withdrawal Credential。Validator Key 用於他擔任驗證者的工作內容，而 Withdrawal Credential 則是他退出質押時，他的押金及收益會提取到的地址，另外目前退出質押必須要用 Validator Key 操作。遺失這兩把鑰匙可能導致的風險：

• Validator Key：若遺失則無法執行驗證者工作，且無法退出質押，只能慢慢被罰錢直到押金太低被強制退出
• Withdrawal Credential：若遺失則等同於喪失所有押金及收益

另外許多使用者會使用第三方質押驗證服務，像是 Lido。使用這種服務時，使用者會自己保管 Withdrawal Credential，而 Validator Key 則是由服務提供商保管並代為執行驗證者的工作，這表示即便服務提供商不能直接拿走使用者的所有押金及收益，但退出質押的控制權還是掌握在它手上，它可以藉此威脅使用者付出贖金。

EIP-7002 之後，使用者就可以自己用 Withdrawal Credential 去呼叫「Withdraw 合約」（部署在 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA）來退出質押（Exit）或提領押金和收益（Partial Withdrawal），不再需要擔心被第三方質押驗證服務提供商威脅，進一步降低使用這類服務的風險。如果使用者是自己質押但遺失 Validator Key 的情況，他也能藉此退出質押。

• 發起請求的參數包含 validator_pubkey及 amount ：validator_pubkey 是驗證者的 Validator (Public) Key，amount 是要提領的數量
• 發起請求的 Withdrawal Credential 必須是 validator_pubkey 驗證者的 Withdrawal Credential
• 呼叫 Withdraw 合約去發起請求時要附上手續費（ETH），手續費會按照當前的提領請求數量計算，如果請求數量很多，手續費就會上升
• 如果使用者的 Withdrawal Credential 是一個合約的話，那可以先去 Withdraw 合約取得當前手續費金額，然後再發起請求並附上手續費；但如果 Withdrawal Credential 是一個 EOA 的話，就沒辦法取得精準的手續費，只能事先鏈下模擬並付超額手續費（不會退還），確保請求發起會執行成功

註：如果你的 Withdrawal Credential 還是 BLS 公鑰格式，記得要先進行切換，將它換成 EL 地址的格式。

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

EIP-7251 大幅提高質押金額上限來減少驗證者數量，且未達上限的驗證者可以自動享受複利

使用者質押成為驗證者要提供 MAX_EFFECTIVE_BALANCE 數量的 ETH，不能更少也不能更多（目前 MAX_EFFECTIVE_BALANCE 是 32 ETH）。如果你有 1024 ETH 要質押，你要自己分 32 次質押、啟用 32 個驗證者，運行 32 個驗證者節點。而大家積極參與質押也導致目前已有約 1M 個驗證者並持續增加，這除了讓 CL 的狀態資料變得更大更多，對 CL p2p 網路層的負荷更為顯著，因為每一個 Slot（每 12 秒）都有數萬個驗證者的簽名要在 p2p 網路層裡不斷傳遞並聚合。

EIP-7251 之後，質押下限（MIN_ACTIVATION_BALANCE）仍然是 32 ETH，但上限（MAX_EFFECTIVE_BALANCE）大幅調高為 2048 ETH，你可以質押 32~2048 之間任何數量的 ETH，而且只要沒有達到上限，你都會自動享受到複利，不需要再像原本要主動操作才能獲得複利的效果，不再需要定期取出收益、累積 32 ETH 後再繼續新質押。

目前已存在的驗證者也不需要特別先退出質押再合併一起重新加入質押，而是可以直接利用 EL 上新增的「合併押金用的合約」（部署在 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb），由驗證者的 Withdrawal Crendential 去呼叫合約發起合併押金的請求。

• 合併押金請求的參數包含 source_pubkey 及 target_pubkey：這兩個 key 都是驗證者的 Validator Key，source 驗證者會合併到 target 驗證者
• 發起請求的 Withdrawal Credential 必須是 source 驗證者的 Withdrawal Credential
• 呼叫合併押金合約去發起請求時要附上手續費（ETH），手續費會按照當前的請求數量計算，如果請求數量很多，手續費就會上升
• 如果使用者的 Withdrawal Credential 是一個合約的話，那可以先呼叫合併押金合約取得當前手續費金額，然後再發起請求並附上手續費；但如果 Withdrawal Credential 是一個 EOA 的話，就沒辦法取得精準的手續費，只能事先鏈下模擬並付超額手續費（不會退還），確保請求發起會執行成功

註：如果你的 Withdrawal Credential 還是 BLS 公鑰格式，記得要先進行切換，將它換成 EL 地址的格式。

EIP-7685: General purpose execution layer requests

EIP-7685 建立一個正式的 EL -> CL 訊息管道，方便使用者及質押服務能直接送出請求給 CL

讓使用者能直接從 EL 送請求給 CL，質押服務（例如 Lido）就可以以更去中心化的方式運行，例如前面提到的 EIP-7002 的退出質押的請求，以及 EIP-7251 的合併押金的請求。如果沒有這個 EIP，那 Lido 使用者就必須要相信 Lido 節點服務提供商會如實在 CL 去執行退出質押或是合併押金；有了這個 EIP，Lido 使用者就可以在 EL 上直接透過治理合約去送出請求，不需相信 Lido 節點服務提供商。

這些請求會有 Request Type 來區分不同類型的請求，以及透過不同合約發起請求，最後這些請求都會被寫入到 EL 區塊裡，因此 CL 可以直接透過 EL 區塊獲得這些資訊，不必再寫個別的解析邏輯。

EIP-6110、EIP-7002 及 EIP-7251 都是以 EIP-7685 定義的標準來制定請求：

• EIP-6110 加入質押請求：Request Type=0，透過 Deposit 合約（0x00000000219ab540356cbb839cbe05303d7705fa）發起請求
• EIP-7002 退出質押請求：Request Type=1，透過 Withdraw 合約（0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA）發起請求
• EIP-7251 合併押金請求：Request Type=2，透過 Consolidation 合約（0x00431F263cE400f4455c2dCf564e53007Ca4bbBb）發起請求

改善使用體驗 EIP

EIP-7702: Set EOA account code

EIP-7702 讓 EOA 帳戶能任意變身成合約帳戶，大幅提升使用體驗

EOA 帳戶有不少缺點：

• 需要記錄和保管私鑰或助記詞，提高新使用者的 Onboarding 門檻
• 一筆交易只能執行一個操作，例如要去 Uniswap 將 USDT 兌換為 ETH，要先發起一筆交易 Approve USDT，然後才能送另一筆交易執行兌換
• 沒辦法有細化的權限控管，像是將帳戶的某些操作交給第三方代為操作，使用者必須要親自處理每一件雜事且每一個操作都要簽名發交易一次
• 沒辦法有 Recovery 機制，只能自己保管好私鑰或助記詞，如果遺失了就再也拿不回帳戶的資產

如果是一個合約帳戶（例如 Safe），那以上的問題都可以被解決：

• 使用者可以用手機（或電腦）的安全晶片裡的私鑰來簽名授權，不用記任何私鑰或助記詞，或是用 Email 來簽名授權也可以，或其他各式各樣的授權方式
• 可以將多個操作 Batch 起來在同一筆交易內一起執行，原先複雜的 DApp 操作都可以只用一次簽名授權、一次交易就可完成
• 可以有非常細化的權限控管，使用者可以授權第三方來控制自己的帳戶，但同時指定「可以和什麼合約互動」、「不可以執行什麼操作」、「牽涉到資產轉移最多只能動用多少資產」或「每個禮拜最多不能超過多少次操作」等等限制
• 可以新增 Recovery 機制，在自己遺失助記詞或手機或 Email 時還能透過 Recovery 機制將帳戶的資產轉移至新的帳戶

EIP-7702 便是賦予 EOA 變身成為合約的能力。使用者用 EOA 私鑰對變身的訊息簽名，簽名內容包含「Chain ID」、「想變身成的合約地址」及「EOA 的 Nonce 值」：

• Chain ID：用來防止 A 鏈的簽名被拿到 B 鏈重放，不過如果 Chain ID 填 0 則表示願意在每條鏈都變身
• 想變身成的合約地址：如果你填一個 Safe 合約地址，那你的 EOA 就會變身成為一個 Safe 合約；如果填空地址（address(0)），那就表示要取消變身，變回單純的 EOA
• EOA 的 Nonce 值：用來防止簽名被重放。如果 Nonce 值增加了，那原本的簽名就會失效

不過有幾點需要注意：

1. EOA 私鑰一樣可以繼續使用
即便使用者的 EOA 變身成一個合約，他還是可以繼續以原本 EOA 的方式使用他的帳戶，例如假設你的 EOA 變身成一個 Safe 合約，則你可以使用 Safe 介面、走 Safe 交易流程，也可以繼續用原本的 EOA 錢包簽名送交易。不過這也表示帳戶的安全性還是侷限在那把私鑰。

2. 仍然是 EOA 私鑰的安全性
即便使用者的 EOA 變身成一個多簽，只要他沒有把 EOA 私鑰丟掉，他的帳戶安全性永遠都是 EOA 私鑰的安全性：他仍然要好好保管他的私鑰或助記詞，他的帳戶不會因此變得和多簽一樣安全。

3. EOA 的 Storage 不會格式化
當一個 EOA 變身成合約並寫入資料到其 Storage，除非明確執行刪除資料的動作，否則這些寫入到 Storage 的數據並不會因為 EOA 變身成其他合約或取消變身而格式化，所以開發者要注意 Storage 不要讀取到以前變身合約留下的數據，可以參考 ERC-7201。

4. EIP-7702 的流程不包含初始化
一般合約帳戶都會需要一個初始化的步驟，在帳戶部署時同步寫入帳戶擁有者的資訊（例如他的公鑰或地址），避免部署步驟被搶跑（Frontrun）導致失去帳戶擁有權。這通常是由部署合約帳戶的 Factory 合約來執行「部署 + 初始化」，但因為 EIP-7702 是直接變身，而不是由一個 Factory 來部署合約到 EOA 身上，所以攻擊者可以抄走使用者的變身簽名並搶先發送交易上鏈去替使用者變身但將帳戶初始化為攻擊者可控制的，因此開發者需要留意 EIP-7702 變身可能被搶跑的風險，可能的防範方法例如在初始化函式內檢查 EOA 的簽名，如此即便被搶跑，攻擊者也沒辦法產生該 EOA 的簽章來完成初始化。

5. 錢包要把關變身的請求
錢包需要替使用者做好把關，在惡意的 DApp 網站請求使用者簽一個變身的交易時把請求攔下來並警告使用者，否則如果使用者簽了惡意的變身交易，將導致資產瞬間被轉走。

以下是一些變身合約的實作範例：

• Modified Safe
• Ithaca Account

DApp 開發者相關 EIP

EIP-2537: Precompile for BLS12–381 curve operations

EIP-2537 讓基於 BLS 曲線的零知識證明應用的成本降低，變得更可行

EIP-2537 新增數個預編譯合約（Precompile）來提供便宜的 BLS 曲線運算，如此基於 BLS 曲線來開發零知識證明的應用將變得更可行。

EIP-2935: Save historical block hashes in state

EIP-2935 讓開發者或節點可以直接從系統合約的 Storage 中讀取過去區塊的雜湊值（Block Hash）

如果開發者需要證明某個以前區塊的內容，例如假設 Optimismtic Rollup 的詐欺挑戰中要證明 1000 個以前的區塊存在某筆交易，挑戰者沒辦法直接說「請相信我 1000 個區塊以前真的存在這筆交易」，他必須要提出證據，但沒有一個直接的證據可以直接證明「1000 個以前的區塊裡包含這些內容」，因此他必須以區塊「鏈」的方式，一個區塊一個區塊往前證明，直到達到 1000 個以前的區塊，然後再證明該區塊裡存在該筆交易。

假設目前是編號為 10000 的區塊，而詐欺挑戰要提供編號 9000 的區塊存在某一筆交易 X 的證明，則挑戰者需要從區塊 10000 的雜湊值開始，先證明區塊 10000 所鏈結的母區塊 9999 的雜湊值，然後再證明區塊 9998… 直到區塊 9000，最後再提出區塊 9000 的內容裡包含該筆交易 X。

EIP-2935 之後，會有一個系統合約（部署在 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC），它的 Storage 會儲存最多 8192 個以前的區塊的雜湊值。每當一個新的區塊產生時，這個系統合約就會自動更新，將前一個區塊的雜湊值寫進系統合約中（會覆寫掉 8192 個以前的區塊的雜湊值）。如此在 Optimismtic Rollup 詐欺挑戰的例子中，挑戰者就不必再往前一個區塊一個區塊慢慢證明，而是可以直接證明區塊 10000 當下的鏈的狀態中，該系統合約的某一個 Storage（對應到區塊 9000）的值是區塊 9000 的雜湊值。如果範圍超過 8192，例如區塊 1000，那頂多就是多一步，先證明區塊 1808 (= 10000 - 8192)的雜湊值，然後再證明區塊 1808 當下的鏈的狀態中，系統合約裡的區塊 1000 的雜湊值。

這也為未來的無狀態客戶端（Stateless Client）鋪路：未來的輕節點就不需要再儲存著歷史中所有的區塊的標頭檔（Block Header），而是當有需要用到歷史中某個區塊的雜湊值或是區塊內容時，再請其他人用前面詐欺挑戰例子中的證明方式提供證明即可。

EIP-7623: : Increase calldata cost

EIP-7623 調高利用 calldata 來發佈資料的成本，以挪出足夠的安全空間來調高 Block Gas Limit 和 Blob 數量

隨著 Rollup 的資料發佈需求越來越高，在 EIP-4844 引入 Blob 來讓 Rollup 以非常便宜的方式放資料之後，調高 Blob 數量便一直是社群所期待的一個升級，或像是最近社群在推動的調高 Block Gas Limit，都反應生態對提高資源的需求。

但不管是調高 Block Gas Limit 或是 Blob 數量，都會因為交易的資料量變得更大而對 Ethereum 的 p2p 網路造成更多壓力，這會使得攻擊者攻擊的效率提高，除非我們將發布資料的成本也提高。

EIP-7623 之後，calldata 的成本將會從原本的「Zero Byte: 4 Gas、Non-Zero Byte: 16 Gas」調高 2.5 倍為「Zero Byte: 10 Gas、Non-Zero Byte: 40 Gas」。原本如果攻擊者將全部的 Block Gas Limit（30M）都拿來放垃圾資料的話，區塊的資料大小約會是 1.79 MB（30M / 16），相比於平均區塊大小只有約 100 KB；而如果 Block Gas Limit 調高到 40M 的話，攻擊者可以產生約 2.38 MB 大小的區塊。當 calldata 成本調高為 2.5 倍，攻擊者的效率會因此下降，變為 30M 最大 0.72 MB、40M 最大 0.95 MB，如此就可以更放心地調高 Block Gas Limit 和 Blob 數量。

不過這個 EIP 也不想因此影響到「不是將 calldata 拿來發佈資料」的一般使用者，所以它會以兩種方式計算交易的總 Gas 用量，再取較高的：

1. 原本的交易 Gas 用量計算方式，搭配舊的 calldata 成本來計算：也就是將 calldata 以「Zero Byte: 4 Gas、Non-Zero Byte: 16 Gas」的方式計算，並加上交易執行所消耗的 Gas 及部署合約所消耗的 Gas
2. 單純計算 calldata Gas 用量，但是是用新的成本來計算：也就是將 calldata 以「Zero Byte: 10 Gas、Non-Zero Byte: 40 Gas」的方式計算，但不計入執行所消耗的 Gas 或部署合約所消耗的 Gas

所以對一般「不是將 calldata 拿來發佈資料」的使用者來說（例如去 Uniswap 兌換代幣），本來主要的 Gas 消耗就是在執行的部分，即便 calldata 以新的成本計算也不會超過執行所消耗的 Gas，因此一般使用者將不會受影響。

真正受影響的會是規模還小的 Rollup，因為 Blob 是固定大小、固定費用，所以小 Rollup 使用 Blob 效率低，使用 calldata 還比較划算，但在 EIP-7623 之後，等於這些小 Rollup 的成本都會提升 2.5 倍，它們可能得因此轉為使用 Blob 或想辦法聯合起來共同分擔一個 Blob。

EIP-7691: Blob throughput increase

EIP-7691 提高 Blob 數量，增加更多資料發佈的空間給 Rollup

EIP-7691 將 Blob 的數量由「目標：3 Blob、上限：6 Blob」調高為「目標：6 Blob、上限：9 Blob」，增加更多資料發佈的空間給 Rollup。

註：另外 Blob 手續費市場還有一些設計需要微調，例如手續費調整的速度不夠即時及手續費底限太低，但這不在這個 EIP 要解決的問題裡，更多資訊可以參考這篇分析文章。

Miscellaneous EIP

EIP-7549: Move committee index outside Attestation

EIP-7549 調整驗證者投票的內容，讓選票更方便被聚合起來，降低 p2p 網路的壓力

驗證者們每個 Epoch 都會被隨機分到一組一組的委員會（Committee） 並對區塊投票，每個委員會的驗證者們的選票可以被聚合在一起，如此可以降低選票在 p2p 網路中傳遞的數量，但驗證者的選票裡會包含「該驗證者屬於第幾個委員會」的資訊，這導致不同委員會的選票不能被聚合在一起，即便他們都對相同的區塊投票。

EIP-7549 將「該驗證者屬於第幾個委員會」的資訊移出投票內容，使得不同委員會的驗證者在投票內容一樣的情況下可以被聚合在一起，進一步降低選票在 p2p 網路中傳遞的數量，降低 p2p 網路的壓力。

EIP-7840: Add blob schedule to EL config files

EIP-7840 在 EL 層為 Blob 參數建立一份設定檔，省去 EL 節點要去詢問 CL 節點 Blob 相關參數的麻煩

Blob 相關參數目前都是儲存在 CL 節點，但 EL 節點在某些情況還是需要這些參數（例如 RPC eth_feeHistory），所以都必須去向 CL 節點詢問。

EIP-7840 在 EL 層為 Blob 相關參數建立一份設定檔，EL 節點都可以直接透過這份設定檔讀取 Blob 相關參數，不需要再向 CL 節點詢問。

參考資料與推薦延伸閱讀

• https://pectra.wtf
• https://x.com/binji_x/status/1874422557992263720
• https://www.galaxy.com/insights/research/pectra-upgrade-and-other-eth-catalysts/
• https://gaslimit.pics/
• https://x.com/spire_labs/status/1881445292815597913

TEM Medium 2025 有獎徵稿

TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 有獎徵稿

Special thanks to Chih-Cheng Liang and Kimi Wu for reviewing and improving this post

Ethereum Pectra 硬分叉介紹 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

先備知識：

• 知道 Rollup 的運作方式以及「資料發布」（aka Data Publication、Data Availability）的問題
• 知道 Optimism Rollup 與 Validity Rollup 的不同
• 知道用來儲存區塊鏈狀態的「狀態樹」與「狀態根」是什麼
• 知道 Merkle Proof 與 Commitment 的意義與用途

關於 EIP-4844、Blob 的介紹可以參考：

Rollup 的大補帖：Proto-Danksharding（一）

為什麼會需要煩惱交易的真實性？

在 EIP-4844 之後，Rollup 可以選擇將交易資料寫在 Blob 裡，Rollup 合約沒辦法直接存取到 Blob 的內容，但使用 Blob 比使用 Calldata 還便宜非常多。

對 Rollup 來說，將交易上傳至 L1 的目的就是藉由 L1 來確保「交易資料已發佈」。如果是 Optimistic Rollup，它只需要將交易資料丟到一個大家都可以存取到的地方，確保未來如果需要利用交易資料來發起挑戰時，有人手上有這些資料即可。所以不管交易資料是放在 Calldata 還是 Blob，對 Optimistic Rollup 來說都沒有差別。

但如果 Validity Rollup 將交易資料放到 Blob 裡，它就需要額外確認 Blob 裡的交易資料的真實性，為什麼呢？

Validity Rollup

在 EIP-4844 以前，Validity Rollup 將交易資料及 Validity Proof 都放在 Calldata 裡，因此 Validity Rollup 在 L1 上的合約可以同時存取到交易資料與 Validity Proof，便可以輕鬆確認「這個 Proof 驗證的是這些交易執行完的結果」。

但在 EIP-4844 後，如果 Validity Rollup 將交易放在 Blob，Validity Rollup 合約就存取不到完整的交易資料，只能存取到交易資料的 Commitment，那 Validity Rollup 要怎麼知道 Commitment 背後所代表的交易真的和 Validity Proof 所要證明的交易是同樣一批交易？

惡意的 Sequencer 可以在 Blob 裡放 tx1 與 tx2，但實際上 Validity Proof 是在驗證 tx3 與 tx4 執行完的結果，如果沒有加入檢查機制，那就會發生除了惡意 Sequencer 之外沒人有 tx3 與 tx4 的資料，所以沒有人能夠算出tx3 與 tx4 執行後的最新狀態（他們只知道 tx3 與 tx4 執行完的狀態「根」，不知道完整的狀態「樹」）。

解法一：在 Validity Rollup 的電路裡也加入 Blob Commitment 的計算過程

這是最直接的解法，Validity Rollup 配合 EIP-4844 修改其 ZK 電路，將計算 Blob Commitment 的步驟也加入其中，如此 Validity Proof 驗證時雖然只有 Commitment，但它知道這個 Commitment 背後是它處理過的交易，所以便不需擔心 Blob 裡可能放的是不一樣的交易。

但計算 Blob 裡資料的 Commitment 是使用 KZG 這個 Polynomial Commitment 設計來計算，而某些 Validity Rollup 要在其電路裡做 KZG 運算會遇到產生零知識證明成本會提高的缺點。

註：Polynomial Commitment 是另外一種 Commit 的方式。相較於 Merkle Tree 是將分段資料視為葉節點並做出一棵 Merkle Tree 得到 Merkle Tree Root 作為 Commitment 值，Polynomial Commitment 則是將分段資料先轉換成一個 Polynomial（多項式），再對這個多項式進行 Commit 得到 Commitment。和 Merkle Tree Root 搭配 Merkle Proof 可以驗證那棵 Merkle Tree 某個葉節點的值一樣，Polynomial Commitment 中透過 Commitment 和 Proof 也可以驗證這個多項式在不同點上的取值。

解法二：Proof of Equivalence

因此 Vitalik 提出了 Proof of Equivalence 機制讓 Validity Rollup 用不同的（成本較低的） Polynomial Commitment 去 Commit 資料的同時，一樣能證明「雖然 KZG Commitment 值和我的 Polynomial Commitment 算出來的值不一樣，但背後所 Commit 的資料是一樣的」。

如此 Validity Rollup 就能各自用自己適合的 Polynomial Commitment 設計去 Commit 交易資料，不影響產生零知識證明的成本，然後在 L1 上的 Validity Rollup 合約裡透過 Proof of Equivalence 去證明「Blob 裡的交易資料真的是我這次零知識證明所驗證的交易」。

Proof of Equivalence 包含一個 Proof，用來證明 Equivalence，即 「Commitment X 裡的內容和 Commitment Y 裡的內容一樣」。要怎麼證明這件事呢？我們不能單純將交易資料直接做兩次 Polynomial Commitment（一次是 KZG），然後產出一個零知識證明來證明這件事，因為這就等價於解法一：在 ZK 電路裡直接做 KZG 運算。因此我們用另外一個方式來證明 — 利用隨機數與機率。

隨機取值

對兩個不同的 Polynomial 來說，「隨機」挑一個點去對它們分別取值，「得到一樣的值」的機率非常非常低。以下圖為例，這兩個多項式相交的點是 (x=0, y=0) 及 (x=2, y=8)，在 x=0 與 x=2 之外的地方兩個多項式的 y 值都不會是一樣的，也就是不會取到一樣的值的意思。

所以當我們隨機挑選一個點去對兩個 Polynomial 分別取值，如果這兩個值不一樣，那就表示這兩個 Polynomial 是不一樣的，在我們的情境裡這就代表兩組交易資料是不一樣的；如果這兩個值一樣，那這兩個 Polynomial 是不一樣的機率非常非常非常低，低到我們可以相信它們是一樣的，也就是兩組交易資料是一樣的。

那這個「隨機挑選的點」是怎麼決定的？因為如果攻擊者可以決定或猜到這個「隨機」的點，那他就只需要確保兩組交易資料的 Polynomial 在那個點的值是一樣的就可以騙過 Proof of Equivalence 機制。

Fiat-Shamir Transformation

Proof of Equivalence 利用 Fiat-Shamir Transformation 來挑選要取哪個點的值，而不是交由某個人來選擇。Fiat-Shamir Transformation 透過密碼學雜湊函式來算出隨機數，而函式的輸入就是交易資料。假設由交易資料組成的 Polynomial 為 P(x)，以下是產生 Proof of Equivalence 的大致步驟：

1. Validity Rollup 以自己的 Polynomial Commitment 算出交易資料的 Commitment 值（這裡稱為 Commitment X）
2. 接著同樣以 KZG 算出交易資料的 Commitment 值（這裡稱為 Commitment Y）
3. 然後將 Commitment X 與 Y 丟進雜湊函式，得到隨機數（稱為 z），假設 P(z) = a
4. 最後生成一個 Proof π 用來證明「 a 為 Commitment Y 的 Polynomial 在 z 點的值」

步驟 1 與 3 會在電路裡運算；步驟 2 則不會在電路裡運算，而是由 Rollup Sequencer 算好再餵給電路，作為綁定 Commitment Y 的用途；步驟 4 也是 Sequencer 產生，只是不是給電路，而是送到鏈上驗證 Proof of Equivalence。

註：不管 Sequencer 塞什麼 KZG Commitment 值給電路都不影響交易正確性，因為電路已經有它所需的所有資料來驗證交易，而且電路裡本來不會進行 KZG 運算或驗證。因此步驟 2 的 Commitment Y 只是作為綁定用途：如果 Sequencer 偷偷把Commitment Y換成 Commitment W ，到時候到鏈上驗證 Proof of Equivalence 時會失敗。

上鏈證明

接著就可以將 Rollup State 的 Validity Proof 及 Proof of Equivalence 帶上鏈去驗證：

這裡為了方便解釋所以將合約分開成 Proof of Equivalence Contract 和 Rollup State Verifier Contract，但實際上兩個部分是合併在一起的，而不是分開驗證。只有一起驗證通過才能證明 Proof of Equivalence，即

• 電路裡驗證「P 的 Polynomial Commitment 是 X，且 P(z) = a」
• 然後再透過 π 驗證「P 的 KZG Commitment 是 Y，且 P(z) = a」

如此便能相信 X 與 Y 所 Commit 的資料是同一份。

如果餵不同的 KZG Commitment 值

如果 Sequencer 餵 Commitment Y 給電路，但實際上 Blob 裡放不一樣的交易資料，那就會產生不一樣的 Commitment：

這樣 Validity Proof 就會驗證失敗，因為 Commitment W 不是當初 Sequencer 給它的 Commitment：

如果試圖想騙過 Proof of Equivalence 機制

那 Sequencer 是否可以保持 P(z) = a 不變，但是不斷微調 P 裡其他的值，反正只要 P(z) = a 驗的過就能說服 Rollup 交易資料是一樣的？

不過因為 z 這個值是 Commitment X 和 Commitment Y 一起算出來的，所以當 Y 的值改變了，算出的值也不會再是 z，因此 Sequencer 原本保持 P(z) = a 就沒有意義了。而且即便只修改 P 裡的一個值也會導致 P 變成完全不一樣的多項式 P’，而如同最前面所述，兩個不同的多項式所相交的點數量非常非常少，因此 P(k) 的值幾乎不可能等於 P’(k)的值。

Sequencer 這時必須重新再來一次，只是這次變成要維持 P(k) = b 不變，看新算出來的隨機數會不會剛好等於 k。他可以一直不斷重複嘗試，但成功機會渺茫，因為要破解密碼學雜湊函式的難度太高了。

註：在 L1 合約裡驗證 Proof of Equivalence 實際上會透過 Point Evaluation Precompile 來驗證 P(z) = a，透過 Precompile 的運算成本會低很多。

以上就是 Validity Rollup 如何將交易資料放在 Blob 節省成本的同時，利用 Proof of Equivalence 這個技巧證明 Blob 裡的交易資料真的和 (State) Validity Proof 所處理的交易資料是一樣的。只需要在電路及 L1 合約裡多做一些處理和運算就可以享受到大幅降低資料成本的優點。

總結

• Validity Rollup 如果將交易放在 Calldata，讓合約可以存取得到，那就可以自然地相信 Validity Proof 證明的真的是這批交易的結果。只是交易資料放 Calldata 的成本很高
• 如果改成把交易資料放在 Blob，成本很低但是合約存取不到，這時候要怎麼知道 Validity Proof 證明的是不是 Blob 裡放的交易？
• 最直接的解法是在 Validity Rollup 的電路裡直接做一次 Blob 裡的 Commitment 運算，也就是 KZG Commitment，但 KZG 對某些零知識證明系統來說成本太高
• 透過 Proof of Equivalence，我們可以以很便宜的方式驗證 Validity Rollup 的 Commitment 和 Blob 裡的 KZG Commitment 是不是對同一批交易資料所做的 Commitment。如此 Validity Rollup 就不需要在電路裡做 KZG 運算，而是可以用適合自己的 Commitment 方式
• L1 合約只需要再多驗證 P(z) = a 就能被說服兩個 Commitment 是對同樣的資料做 Commit，但是 z 是怎麼決定的？如果攻擊者可以任意挑選 z，那他用不同資料 Commit 來騙過 L1 合約就變得非常簡單
• 因此我們透過 Fiat-Shamir Transformation 並搭配交易資料當 Input 來決定 z 的值，如果攻擊者修改了任意一丁點的交易資料內容，都會得到完全不一樣的隨機值，因此他要想騙過 L1 合約得先破解密碼學雜湊函式，而這基本上是不可能的

參考資料與推薦延伸閱讀

• https://consensys.io/blog/ethereum-evolved-dencun-upgrade-part-5-eip-4844
• https://ethresear.ch/t/easy-proof-of-equivalence-between-multiple-polynomial-commitment-schemes-to-the-same-data/8188
• https://eips.ethereum.org/EIPS/eip-4844#point-evaluation-precompile
• StarkNet 介紹 4844 與 Proof of Equivalence 實作設計
• ZKSync 的 4844 技術文件與實作程式碼：1、2、3
• https://github.com/taikoxyz/raiko/issues/47

TEM Medium 2024 有獎徵稿

TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 有獎徵稿

Special thanks to Anton Cheng and Cyan Ho for reviewing and improving this post

EIP-4844 的 Proof of Equivalence 機制介紹 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

先備知識：

• 知道 Rollup 的運作機制及 Force Inclusion 機制

Rollup 的 Force Inclusion 機制介紹

L2 幾乎都會發行自己的代幣，但絕大多數的實際用途都只是用來參加治理（Arbitrum、Optimism）。有些 L2 會提供質押 L2 代幣的功能，例如 Mantle 及 Manta。這些質押可以用來「決定誰可以排序交易的權力」、「決定生產零知識證明的權力」，或是用來「確保 L2 資料的資料發佈特性（Data Publication）有被保障」，詳細可參考官方文章或文件：StarkNet、zkSync、Mantle、Manta。

註：不過要注意「資料是否正確發佈」是沒辦法被客觀證明的，因此也就沒辦法進行懲罰，所以我個人對「為了資料發佈特性而質押 L2 代幣」的設計仍然存疑。資料發佈特性的介紹可參考：

資料可得性重新命名：用 Data Publication 取代 Data Availability

那 L2 代幣可以用來支付使用者的交易手續費嗎？這麼做有什麼樣的優點和缺點？

優點

增加代幣用途，讓 L2 代幣不是只有單純治理功能。甚至可以搭配 EIP-1559 機制去銷毀 L2 代幣，讓 L2 代幣成為通縮代幣增加價值。

缺點

L2 的資料成本還是以 L1 代幣計價

Rollup Sequencer 在上傳資料到 Ethereum 上時，還是得以 ETH 支付手續費，所以 Sequencer 得要承擔風險 Rollup 代幣及 ETH 之間的價格波動風險。如果它在「收到 Rollup 代幣」到「將 Rollup 代幣兌換成 ETH」的期間，Rollup 代幣價格相對 ETH 價格下跌，那就表示賠錢；當然反之則是賺錢，不過 Sequencer 未必會想再多承擔一層風險。

註：如果該 L2 不是 Rollup、不是上傳資料到 Ethereum 而是改成上傳到其他 DA 層的話，一樣會遇到這個問題，只是 ETH 換成了該 DA 層的代幣。像是 Mantle 或 Manta 都是將資料上傳到其他 DA 層。

影響使用體驗

如果 L2 只能使用自己的代幣來支付手續費，會造成使用者的使用體驗變差，因為使用者進到該 L2 就得想辦法再換成該 L2 的代幣。例如 Polygon PoS，如果使用者第一次使用 Polygon PoS，以為把 ETH 存進去就可以開始使用，使用者會發現 ETH 沒辦法用來支付手續費，而且他也沒有用來付手續費的 Matic 代幣，因此也不能把 ETH 換成 Matic，所以他必須再一次在 L1 先換到 Matic 然後再把 Matic 存進 Polygon PoS才能正常使用。

註：嚴格來說 Polygon PoS 是屬於安全性較低的側鏈（Sidechain）而不是 L2，不過不影響這裡舉的使用體驗的例子。

如果每個 L2 都這麼做，那 N 個 L2 就會造成使用者 N 次麻煩。

L2 互通多一層阻礙

如果 L2 都用自己的代幣支付手續費，那 L2 之間的互通性（Interoperability）將會變得很差。例如單純的 L2 跨鏈轉帳，使用者不能單純地把 ETH 跨過去就可以順利在目標 L2 上開始交易，他會遇到和前面 Polygon 一樣的問題，所以他必須換成目標 L2 的代幣，例如（假設）從 ARB 換成 OP，而這還會受到 ARB <-> OP 的流動性所影響。如果有 N 條 L2，那流動性就要分割到 N-1 個池子，使用者也要兌換 N 次才能在 N 條 L2 上開始交易。更複雜的操作例如跨鏈借貸、跨鏈開倉、跨鏈清算，都隱含著要先跨手續費過去，等於每次都要支付一定成本在這上面。

或例如 Optimism 為互通性而打造的 Superchain，如果 Superchain 生態裡的每個 Rollup 都用自己的代幣支付手續費，那就等於直接牴觸 Superchain 的目的和願景。

不過以上「使用體驗變糟」及「L2 互通性變差」的前提都是 L2 都「只」接受用自己 L2 代幣來支付手續費。如果 L2 都開放讓使用者可以選擇以 ETH 或是 L2 代幣支付的話，就不會有上述這兩個缺點：使用者在做跨鏈操作時就以 ETH 為媒介，在 L2 上獨立操作的話就以 L2 代幣支付手續費。而 StarkNet 便是即將成為同時提供 ETH 或 STRK 來支付手續費的 L2。

STRK 做為交易手續費

StarkNet 去年底宣布將會支援「以 STRK 代幣支付手續費」的選項，使用者將可以選擇以 ETH 或 STRK 來支付手續費，Sequencer（StarkNet 稱為 Operator）會承擔 ETH <-> STRK 匯率變化的風險。那 Sequencer 要怎麼決定一筆原本是 0.1 ETH 手續費的交易如果改成 STRK 支付的話要收多少 STRK？

Sequencer 的權力

不管在 L1 還是 L2 中，使用者的交易基本上都是指定一個他願意付出手續費的最大值，例如在 Ethereum、Arbitrum 或 Optimism 等採用 EIP-1559 機制的鏈上，使用者都需要指定一個 maxFeePerGas 值，maxFeePerGas 乘上 gasLimit 就代表這筆交易的手續費最大值。如果是在非 EIP-1559（例如 Bitcoin 或是以前的 Ethereum）的鏈上，使用者就是指定一個固定的手續費。

註：StarkNet 雖然還沒有 EIP-1559，但一樣也是指定一個 maxFee 值。

不管在哪一條鏈上，有權排序、收入交易的人（礦工、驗證者、Sequencer 等等）都有權力可以審查交易、不收入特定交易，但只要某筆交易被收入了，那筆交易最多就是被徵收使用者指定的手續費最大值。

公開 Oracle 提供 ETH <-> STRK 報價？

有些人會覺得要有一個公開 Oracle 來提供 ETH <-> STRK 報價，這樣在把 0.1 ETH 的手續費轉換成 STRK 數量時才有一個公開公正的轉換匯率。不過如同前面一段提到的，Sequencer 可以不收入特定交易，但只要收入了，最多就是收取使用者指定的手續費最大值，所以重點是使用者指定了願意付出的手續費最大值（不管單位是 ETH 還是 STRK），剩下就是等交易被收入。ETH <-> STRK 的匯率是否公開根本沒有影響，只要 Sequencer 想要，他都有手段可以將使用者的交易手續費收到滿。

所以就不需要 Oracle 了嗎？

Off-chain Oracle for StarkNet Sequencer

實際上還是需要 Oracle，而且 StarkNet 也宣布會有 Oracle 來提供 ETH <-> STRK 報價，只是這個 Oracle 會是在鏈下專為 StarkNet Sequencer 提供報價的服務。但我覺得 Oracle 不應該用在這個場景，後面會說明。

如果 Oracle 是在鏈下去提供報價給 Sequencer，要怎麼說服社群 Sequencer 真的是照著 Oracle 報價來計算 STRK 手續費？Oracle 至少得公佈他們的報價，讓社群能比對 Sequencer 是否有如實按照報價計算，如果發現 Sequencer 沒有如實參考報價，那社群至少可以提出證據來譴責 Sequencer️。‍🤷‍♂️

如果 Oracle 的報價能寫到鏈上或是整合進協議裡，就能免除 Sequencer 作惡或失誤的可能，不過這得牽涉到協議層的改動，所以或許目前這個作法是以盡力取信於社群的最大折衷做法了，畢竟 StarkNet 其實是可以完全讓 Sequencer 自己決定的。反正如前述，使用者指定 maxFee 後剩下就是交由 Sequencer 決定了。

那 Oracle 在哪才會真的派上用場？

Force Inclusion 機制

為什麼 Force Inclusion 機制會需要 Oracle？先不論 StarkNet 目前還沒有實作出 Force Inclusion 機制，其他 L2 像是 Optimism 或 zkSync 都會在使用者在 L1 上執行 Force Inclusion 函式時，先向使用者收取 L2 的手續費。例如 Optimism 的 depositTransaction 函式會按照使用者指定的 L2 gas limit 去燒毀（消耗掉）相對應的 gas，也就是收取 L1 ETH 的意思；zkSync 的 requestL2Transaction 函式會算出 L2 交易的基本成本並要求 L1 交易要帶上足夠的 ETH 來支付基本成本。如果今天 Optimism 或 zkSync 也推出自己的代幣支付手續費的功能，那 Force Inclusion 機制會有什麼影響？

假設使用者從 L1 請求強制收入他的 L2 交易，但是 L1 收取的是 ETH 而 L2 手續費是用 OP 支付的話，要怎麼計算該在 L1 收他多少 ETH？如果沒有公正的匯率，就有可能造成使用者付出超額手續費，等於是懲罰 Force Inclusion 使用者；或是造成攻擊者濫用低廉手續費，都從 L1 去送交易而不是從 L2。而這才是我覺得 Oracle 該派上用場的場景：讓 L1 合約可以公正地計算 Force Inclusion 交易要收取的手續費。

不過 L2 可以規定 Force Inclusion 交易和 L2 交易都以 L2 代幣計價（例如都收取 OP），這樣就不需要煩惱 L1 與 L2 手續費單位換算的問題。但要注意的是，仍然有一個成本是無可避免要以 ETH 計價的 — 資料上傳的成本，所以使用者的 Force Inclusion 交易會變成要同時支付 ETH 以及 OP，這可能造成一些使用體驗上的摩擦，但這也是 L2 用自己代幣支付手續費本來就需要面對的挑戰。

總結

• L2 發行自己的代幣可以有不同用途，但如果將 L2 用於支付 L2 手續費會有什麼樣的優缺點？
• 優點很簡單：L2 代幣會有一個明確實際的用途，如果搭配 EIP-1559 燒毀代幣，可以進一步提升幣價
• 但缺點也不少：Sequencer 承擔風險變大、使用者的使用體驗變差、尤其跨 L2 的使用體驗會糟上許多
• 不過如果 L2 保持 ETH 和 L2 代幣都能用來支付手續費，那就不會影響到使用體驗（單 L2 或跨 L2）太多
• StarkNet 是幾個較知名 L2 中第一個計畫開放以 STRK 支付手續費的 L2，並會引進第三方 Oracle 項目來為 ETH <-> STRK 匯率進行報價
• 而這篇文章的重點是放在介紹「Sequencer 權力」及「Oracle 真正適合的場景」
• 「Sequencer 權力」：Sequencer 在收入及排序交易這件事上的權利是非常大的，使用者沒辦法去挑戰 Sequencer 的公平性，因為公平這件事是沒辦法在鏈上去證明的
• 使用者能做的就是指定好他願意為他這筆交易付出多少手續費（maxFee、maxFeePerGas），剩下就是交給 Sequencer 並相信他了
• 「Oracle 真正適合的場景」：正因為「只要 Sequencer 想要，它就可以將使用者手續費收到滿」，所以 L2 交易引進一個 Oracle 來報價並沒有太大用途，更多是讓社群和使用者安心
• 真正有 Oracle 適合的場景應該是在 L1 上的 Force Inclusion 機制，因為 Force Inclusion 交易收取的手續費如果和 L2 手續費單位不同，且沒有公正的匯率的話，就會造成無辜使用者付出超額 Force Inclusion 手續費，或是攻擊者濫用低廉手續費，都從 L1 送交易
• 如果 L2 規定 Force Inclusion 手續費和 L2 手續費都用 L2 代幣的話，就不需要煩惱匯率的問題，不過使用者的 Force Inclusion 交易就要同時支付「交易資料上傳到 L1 的成本」及「L2 手續費」，分別是以 L1 代幣及 L2 代幣計價。這會影響到使用體驗，不過這本來就是 L2 使用自己代幣支付手續費就必須面對的挑戰

參考資料與推薦延伸閱讀

• https://docs.starknet.io/documentation/architecture_and_concepts/Economics-of-Starknet/#purpose_of_the_token
• https://docs.mantle.xyz/governance/parameters/tokenomics
• https://docs.mantle.xyz/network/introduction/concepts/data-availability#mantle-da-powered-by-eigenda-technology
• https://docs.manta.network/docs/mantaToken/
• https://mantanetwork.medium.com/manta-tokenomics-b226f911c84c
• https://twitter.com/KAndrewHuang/status/1694002513534660747
• https://community.starknet.io/t/starknet-v0-13-0-support-for-fee-payment-in-strk-reduced-transaction-fees/109608
• https://community.starknet.io/t/snip-strk-fee-token/101924
• https://book.starknet.io/ch03-01-02-fee-mechanism.html

TEM Medium 2024 有獎徵稿

TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 有獎徵稿

Special thanks to Kevin Mai-Hsuan Chia and Chang-Wu Chen for reviewing and improving this post

用原生 L2 代幣來支付交易手續費 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

先備知識：

• 知道 Rollup 的運作機制以及為什麼 Rollup 會需要把交易上傳到 L1 上

交易的抗審查能力

交易抗審查（Censorship Resistance）的能力對一條區塊鏈來說非常重要，如果一條區塊鏈能夠任意審查使用者交易，那這條區塊鏈就和一個 Web2 伺服器沒有兩樣。Ethereum 目前的交易抗審查能力來自於它為數眾多的驗證者們，如果 Alice 想要審查 Bob 的交易、不讓他的交易上鏈，那 Alice 要不得嘗試買通網路中每一個驗證者，要不得 Spam 整個網路、不斷送出手續費比 Bob 交易高的垃圾交易來塞滿區塊。不管是哪一個方式，她的成本都會非常高。

註：在 Ethereum 目前的 PBS 架構中，審查的成本其實降低不少，可以參考配合 OFAC 審查 Tornado Cash 交易的區塊比例。當前的抗審查能力仰賴在 OFAC 及政府管轄範圍之外的獨立驗證者及 Relay。

但 Rollup 呢？Rollup 不需要一大堆的驗證者來確保它的安全性，即便 Rollup 只有一個中心化的角色（Sequencer，稱為排序者或排序器）來產出區塊，它也和 L1 一樣安全。但安全和抗審查能力是兩回事，即便一個 Rollup 和 Ethereum 一樣安全，卻只有一個中心化 Sequencer，那該 Sequencer 想要審查任何使用者的交易都行。

Force Inclusion 機制

與其要求 Rollup 要有和 L1 一樣多的驗證者來確保抗審查能力，還不如直接利用 L1 的抗審查能力：Sequencer 也是要將交易資料打包送到 L1 的 Rollup 合約上，不如在 Rollup 合約裡加入一個機制讓使用者也可以插入交易到排序之中，這樣的機制就稱為 Force Inclusion。只要 Sequencer 沒辦法審查使用者的「L1 交易」，它就沒辦法阻止使用者透過 L1 強制插入 Rollup 交易，而 Rollup 的運作及安全性正是奠基於 L1 的抗審查能力。

註：Force Inclusion 機制是要該 Rollup 有設計才會有，使用者並不是一定可以透過 L1 強制插入 Rollup 交易。如果 Rollup 沒有提供 Force Inclusion 機制，那使用者就只能祈禱 Sequencer 不會審查自己交易。

交易立即生效 vs. 延遲生效

如果我們允許透過 Force Inclusion 插入的交易可以直接寫入到 Rollup 的交易歷史中（也就是立即生效），那 Rollup 的狀態就會馬上被改變，例如 Bob 透過 Force Inclusion 機制插入一筆「他轉 1000 DAI 給 Carol」的交易，如果這筆交易立即生效，那最新的狀態中 Bob 的餘額就會少 1000 DAI 而 Carol 會多 1000 DAI（當然前提是 Bob 餘額超過 1000 DAI）。

如果此時 Sequencer 也在鏈下搜集交易，等著把下一批交易送到 Rollup 合約上，那就有可能被 Bob 強制插入並立即生效的交易給影響到。例如 Bob 其實事先送了一筆「他轉 1000 DAI 給 Alice」的交易到 Sequencer 那，Sequencer 當下驗證沒問題並承諾會收入，Alice 和 Bob 都可以向 Sequencer 查詢交易是否會被收入並且計算出最新狀態（Alice 多 1000 DAI，Bob 少 1000 DAI）。但等到 Sequencer 發現 Bob 搶先一步去強制插入交易後，它手上的交易的執行狀態都已改變，原本那筆「Bob 轉 1000 DAI 給 Alice」的交易已經變成會執行失敗，Alice 也拿不到 1000 DAI。

這可不是一個好的使用者體驗，因此 Rollup 一般都不會讓 Force Inclusion 交易立即生效，而是讓交易先進到一個「準備中」的狀態。Sequencer 可以在打包交易送上來時選擇是否要順便塞入這些「準備中」狀態的交易到批次的最後面，如果 Sequencer 一直都沒有想要處理這些「準備中」的狀態，那這些交易在過了一段時間後就可以被強制插入到交易歷史中。

如果 Sequencer 一直沒有收入等待隊列中的交易，在一段時間後使用者（或是任何人）就可以自己去強制收入。

接下來將依序介紹 Optimism、Arbitrum、StarkNet 及 zkSync 等四個較有名的 Rollup 的 Force Inclusion 機制實作。

Optimism 的 Force Inclusion 機制

首先先介紹 Optimism 的 Deposit 流程，這個 Deposit 不單是指把存錢進 Optimism 的意思，而像是更一般的「把給 L2 的訊息」存進去 L2。L2 節點在接收到新存入的訊息後就會將訊息轉換成一筆 L2 交易去執行，送到訊息指定的接收方。

L1CrossDomainMessenger 合約

當一個使用者要把 ETH 或 ERC-20 代幣存進 Optimism 時，他會（透過前端網頁）和 L1 上的 L1StandardBridge 合約互動，指定要存多少數量以及由哪個地址接收等等。接著 L1StandardBridge 會將訊息傳遞至下一層的 L1CrossDomainMessenger 合約，這個合約主要是作為一般通用的 L1 與 L2 之間互相通訊的合約，L1StandardBridge 便是使用這個通用的通訊合約來和 L2 上的 L2StandardBridge 溝通，決定誰可以從 L2 鑄造代幣或是誰可以從 L1 提領代幣。如果開發者需要開發一個 L1 與 L2 之間互通、同步狀態的合約，那他就可以搭建在 L1CrossDomainMessenger 合約之上。

OptimismPortal 合約

L1CrossDomainMessenger 合約會再將訊息送至最底層的 OptimismPortal 合約，OptimismPortal 合約處理完後會 emit 一個 TransactionDeposited event，event 參數包含「送訊息的人」、「接收訊息的人」，以及相關的執行參數。

接著 L2 的 Optimism 節點會監聽 OptimismPortal 合約所 emit 的 TransactionDeposited event，並把 event 裡的參數轉換為一筆 L2 的交易，這個 L2 交易的發起者就會是 TransactionDeposited event 裡的「送訊息的人」、交易的接收者就會是 event 裡的「接收訊息的人」，其他執行參數也是由 event 參數而來。

例如這一筆是某個使用者透過 L1StandardBridge 合約 Deposit 0.01 ETH 的交易，這個訊息及 ETH 一路傳到 OptimismPortal 合約（地址是 0xbEb5…06Ed），然後幾分鐘後轉換成 L2 交易：訊息發起者是 L1CrossDomainMessenger 合約；接收者是 L2 上的 L2CrossDomainMessenger 合約；附帶 0.01 ETH。

Force Inclusion

當使用者想要強制收入他的交易進 Optimism 執行時，他並不是想要從 L1 送訊息至 L2，所以他不會去使用 L1CrossDomainMessenger 合約。他要達到的效果是讓一筆原本「他從他的 L2 地址在 L2 上送出並要執行的交易」能順利執行，所以他會直接去和 OptimismPortal 合約互動，而且是以他 L2 地址去呼叫 OptimismPortal 合約，如此到時候 TransactionDeposited event 轉換成的 L2 交易的「交易發起者才會是他的 L2 地址」，才能重現原本那筆交易。

我做了一個簡單的 Force Inclusion 交易：以我 L2 的地址（0xeDc1…6909）轉錢給我自己，並附帶一個 “force inclusion” 的文字訊息。這是我透過 OptimismPortal 合約執行 depositTransaction 函式的 L1 交易，可以看到在 emit 的 TransactionDeposited event 中，from 和 to 都是我自己，剩下的 opaqueData 欄位裡的值（000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000015BE000000000000C35000666F72636520696E636C7573696F6E）則是編碼了「呼叫 depositTransaction 的人附帶了多少 ETH」、「L2 交易發起者要附帶多少 ETH 給 L2 接收者」、「L2 交易 Gas Limit」及「給 L2 接收者的 Data」等等資訊。

將 opaqueData 值的這幾個資訊解碼後分別會得到：

• 「呼叫 depositTransaction 的人附帶了多少 ETH」：0，因為我沒有要從 L1 Deposit ETH 進到 L2
• 「L2 交易發起者要附帶多少 ETH 給 L2 接收者」：5566（wei），因為我要轉錢給我自己
• 「L2 交易 Gas Limit」：50000
• 「給 L2 接收者的 Data」：0x666f72636520696e636c7573696f6e，也就是 “force inclusion” 這個字串的 hex 編碼

接著沒多久就出現轉換後的 L2 交易：一筆我轉錢給自己的 L2 交易，金額是 5566，Data 是 “force inclusion” 字串。而且可以注意到在圖中倒數第二行的 Other Attributes 中 Txn Type（交易類型）是系統交易 126(System)，表示不是我自己在 L2 發起的交易，是由 L1 TransactionDeposited event 轉換而來。

如果使用者要呼叫其他合約、帶不同 Data，那一樣就是將參數一一填入 depositTransaction 函式，只要記得是要用 L2 地址來去 L1 上執行，如此到時候 L2 交易發起者才會是該 L2 地址。

Sequencer Window

前面提到的 Optimism L2 節點將 TransactionDeposited event 轉換成 L2 交易，其實這個 Optimism 節點指的是 Sequencer 節點，畢竟這攸關交易排序，所以只有 Sequencer 可以決定何時要轉換成 L2 交易。在監聽到 TransactionDeposited event 時，Sequencer 並不一定會馬上將 event 轉換成 L2 交易，而是可以有一段時間決定要何時轉換，這段時間稱為 Sequencer Window，目前 Optimism 主網上的 Sequencer Window 為 12 小時（3600 個 L1 區塊的時間），也就是當使用者從 L1 Deposit 一筆錢或一個訊息，或是 Force Include 一筆交易時，最糟情況會是 12小時後才被正式收入進 L2 交易歷史中，不過至少這勝過交易永遠沒辦法被收入的結果。

Arbitrum 的 Force Inclusion 機制

在 Optimism 中 L1 的 Deposit 操作會 emit 一個 TransactionDeposited event，剩下的就是等待 Sequencer 收入這個 Deposit 操作；但在 Arbitrum 中 L1 的操作（存錢或傳訊息給 L2 等等）會被存在 L1 合約的一個 Queue 裡，而不是單純只 emit event。而 Sequencer 會被給予一段時間來將這個 Queue 裡的 L1 操作放進交易歷史中，如果時間到了 Sequencer 都沒有作為，那任何人都可以去替 Sequencer 完成。

L1 操作都要經由稱為 Delayed Inbox 的合約，顧名思義這裡的操作都會延遲生效；另一個合約則是 Sequencer Inbox，是給 Sequencer 上傳 L2 交易的介面。Sequencer 上傳的交易會直接寫進交易歷史中，而每次 Sequencer 上傳時都可以選擇要順便從 Delayed Inbox 拿多少個 L1 操作一起寫進交易歷史中，讓這些 L1 操作生效。

複雜的設計以及凡善可陳的文件

如果讀者直接參考 Arbitrum 官方關於 Sequencer 及 Force Inclusion 的章節，會看到裡面提到了 Force Inclusion 大致如何運作，以及一些參數名稱和函式名稱：使用者先去 Inbox 合約呼叫 sendUnsignedTransaction 函式，如果 Sequencer 沒在約 24 小時內收入，那使用者就可以去呼叫 Sequencer Inbox 合約的 forceInclusion 函式。就這樣，連連結也沒有附在裡面，只能自己去看合約程式碼裡相對應的函式。

當找到 sendUnsignedTransaction 函式後，你發現竟然要自己填 nonce 值還有 maxFeePerGas 值。是哪個地址的 nonce？是哪個網路上的 maxFeePerGas 值？要怎麼填比較好？沒有文件紀錄，連 Natpsec 都沒有。然後你還順便發現一堆看似相似的函式：sendL1FundedUnsignedTransaction、sendUnsignedTransactionToFork、sendContractTransaction、sendL1FundedContractTransaction，一樣沒有文件告訴你這些函式的區別、該怎麼用、參數該怎麼填，連 Natpsec 都沒有。

你抱著姑且一試的心態來試填參數並送出交易，想用 trial and error 的方式看能不能找出正確的用法，但發現這些函式全都會把你的 L1 地址做 Address Aliasing，導致最終 L2 上的交易發起人根本是不一樣的地址，於是你的 L2 地址一動也不動。

sendL2Message

後來偶然點開 Google 搜尋頁面中的某個連結才發現原來 Arbitrum 自己有一個 Tutorial 程式庫，裡面有腳本示範怎麼從 L1 送 L2 交易（也就是 Force Inclusion 的意思），然後它戳的函式完全不是上面提到的任何一個，而是一個叫 sendL2Message 的函式，而且 message 參數要帶入的竟然是簽完名的 Arbitrum L2 交易？？？誰會知道要「送給 L2 的訊息」竟然會是一筆「簽完名的 L2 交易」？？而且再一次，沒有任何文件及 Natspec 解釋什麼時候用及如何使用這個函式。

結論：要手動產生一個 Arbitrum 的強制收入交易比較麻煩，建議就照著官方 Tutorial 跑 Arbitrum SDK 唄。Arbitrum 不像其他 Rollup 有清楚的開發者文件及程式碼附註，許多函式的用途和參數缺乏說明，導致開發者得花費比預期多更多的時間來接入和使用。我也在 Arbitrum Discord 上詢問 Arbitrum 的人，但並沒有得到令人滿意的答案。

註：在 Discord 上詢問，對方也只會叫我去看 sendL2Message，沒有想要解釋其他函式（甚至是 Force Inclusion 文件裡提到的 sendUnsignedTransaction）是什麼用途、怎麼用、什麼時候用。

StarkNet 的 Force Inclusion 機制

很遺憾地，StarkNet 目前還沒有 Force Inclusion 機制。只有兩篇在官方論壇上討論到 Censorship 及 Force Inclusion 的文章。

無法證明失敗的交易

原本是因為 StarkNet 的零知識證明系統沒辦法證明一筆失敗的交易，所以不能允許 Force Inclusion。因為如果有人惡意（或無意） Force Include 一筆失敗、無法被證明的交易，那 StarkNet 就會直接卡住：因為交易被強制收入後，Prover 就必須證明該筆失敗交易，但它卻沒辦法證明。

而 StarkNet 預期在 v0.15.0 版引入證明失敗交易的功能，之後應該就可以進一步實現 Force Inclusion 機制。

zkSync 的 Force Inclusion 機制

zkSync 的 L1->L2 訊息傳送以及 Force Inclusion 機制都是透過 MailBox 合約的 requestL2Transaction 函式進行，使用者指定要呼叫的 L2 地址、call data、帶上的 ETH 數量、L2 Gas Limit 值等，requestL2Transaction 會將這些參數組合成一個 L2 交易然後放進優先佇列（Priority Queue） 中，Sequencer 會在交易打包上傳到 L1 時（commitBatches 函式）指定要順便從優先佇列中拿出多少筆交易一起收入。

zkSync 在 Force Inclusion 介面上和 Optimism 很像，都是以使用者的 L2 地址去呼叫，並填入相關資料（被呼叫者、call data 等等），而不是像 Arbitrum 一樣是填一筆簽完名的 L2 交易；但在設計上則是和 Arbitrum 一樣都是在 L1 維護一個實體的 Queue，並由 Sequencer 從 Queue 中拿出交易寫入交易歷史中。

如果你透過 zkSync 的官方橋去 Deposit ETH，像是這筆交易，它便是去呼叫 MailBox 合約的 requestL2Transaction 函式，它會將這個 Deposit ETH 的 L2 交易放進優先佇列 中並 emit 一個 NewPriorityRequest event。因為合約把 L2 交易資料編碼成一串 bytes 字串所以不易讀，改成看這筆 L1 交易的參數的話，會看到參數中 L2 的接收方也是交易的發起人（因為是 Deposit 給自己），所以過一陣子這筆 L2 交易被 Sequeuncer 從優先佇列拿出並收入進交易歷史中時，它會在 L2 上被轉換成一筆自己轉帳給自己的交易，而轉帳的金額就是交易發起人在 L1 的 Deposit ETH 交易所帶上的 ETH 金額。

接著我直接照本宣科呼叫 requestL2Transaction 函式，送了一筆自己呼叫自己的交易：沒有帶任何 ETH，call data 帶入「force inclusion」字串的 HEX 編碼。 接著它被轉換成 L2 上一筆自己呼叫自己的交易，call data 裡是「force inclusion」字串：0x666f72636520696e636c7573696f6e。

透過 requestL2Transaction 函式，使用者可以以 L2 地址在 L1 請求 L2 交易，指定 L2 接收方、帶上的 ETH 金額以及 call data。如果使用者要呼叫其他合約、帶不同 Data，那一樣就是將參數一一填入 requestL2Transaction 函式，只要記得是要用 L2 地址來去 L1 上執行，如此到時候 L2 交易發起者才會是該 L2 地址。

還沒有讓使用者強制收入的功能

雖然 L2 交易放到優先佇列中會順便計算出這筆 L2 交易要被 Sequencer 收入的期限，但目前 zkSync 設計中並沒有讓使用者能自己執行的 Force Inclusion 相關函式，等於是做半套。也就是雖然有「收入有效期限」，但實際上還是「看 Sequencer 要不要收入」：Sequencer 可以等到過期後才收入，也可以永遠不再收入優先佇列中任何交易。未來 zkSync 應該要加入相關函式，讓使用者可以在收入有效期過了但都還沒被 Sequeuncer 收入時，能強制收入，如此才是真正有效的 Force Inclusion 機制。

[2024/07/07 更新] zkSync 的 Force Inclusion 機制目前沒辦法讓使用者轉出 L2 地址的 ETH！

可以注意到 requestL2Transaction 函式，它的參數 _l2Value 指的是要從 L1 儲值到 L2 的 ETH，如果要從 L1 儲值到 L2 地址就是填這個 _l2Value，並且 msg.value 要帶上足夠的 ETH。但如果使用者是要從 L2 地址轉出 ETH 到其他地址呢？要填哪個參數？

答案是沒辦法！像是 Optimism 的 depositTransaction 函式的 _value 參數指的就是 L2 地址要轉出的 ETH 數量，而 msg.value 則是要從 L1 儲值到 L2 的 ETH 數量，因此使用者可以透過這兩個方式決定要儲值多少或提走多少 ETH。但 zkSync 的 requestL2Transaction函式則只有一個參數：儲值多少 ETH，因此使用者沒辦法透過 Force Inclusion 機制從 L2 地址提走 ETH！

目前 zkSync 已經在著手修復這個問題。

總結

• L1 靠為數眾多的驗證者們來確保網路的「安全性」及「抗審查能力」，而 Rollup 則是靠「L1 的抗審查能力」來獲得「和 L1 一樣的安全性」，但不包含 Rollup 的抗審查能力
• 相反地，Rollup 因為都是由少數或甚至單一的 Sequencer 來寫入交易，抗審查能力反而更弱。因此 Rollup 需要有 Force Inclusion 機制來讓使用者可以繞過 Sequencer，將交易寫入歷史中，避免被 Sequencer 審查而無法使用也無法離開該 Rollup
• Force Inclusion 讓使用者可以強制將交易寫入歷史中，但在設計上需在「交易是否能立即插入歷史、立即生效」上做選擇。如果允許交易立即生效，那就會造成 Sequencer 的麻煩和使用體驗上的困難，因為 L2 上等待被收入的交易都可能會被 L1 強制收入的交易所影響
• 因此目前 Rollup 的 Force Inclusion 機制都會先讓 L1 上插入的交易先進到一個等待狀態中，並讓 Sequencer 有一段時間窗口來反應、來選擇要不要收入這些等待中的交易
• zkSync 和 Arbitrum 都是在 L1 維護一個實體的 Queue，用來管理使用者從 L1 送出的 L2 交易或給 L2 的訊息。Arbitrum 稱為 Delayed Inbox；zkSync 稱為 Priority Queue
• 但 zkSync 送出 L2 交易的方式和 Optimism 比較像，都是以 L2 地址去 L1 上發送，如此 L2 交易的發起人才會是該 L2 地址。Optimism 送 L2 交易的函式稱為 depositTransaction；zkSync 稱為 requestL2Transaction。而 Arbitrum 則是製作一筆完整的 L2 交易並簽名，然後透過 sendL2Message 函式送出，Arbitrum 在 L2 上會透過簽名還原簽章者來作為 L2 交易的發起人
• StarkNet 目前還沒有 Force Inclusion 機制；zkSync 則是像做了半套的 Force Inclusion — 有 Priority Queue 且每個 Queue 裡的 L2 交易都有收入有效期限，但這個有效期限目前只是裝飾用，實際上 Sequencer 可以選擇完全不再收入任何 Priority Queue 裡的 L2 交易

參考資料與推薦延伸閱讀

Optimism Force Inclusion

• https://docs.optimism.io/stack/protocol/outages#bypassing-the-sequencer
• https://docs.optimism.io/stack/protocol/deposit-flow#l2-processing
• https://specs.optimism.io/protocol/deposits.html#user-deposited-transactions
• https://github.com/ethereum-optimism/optimism/blob/v1.7.3/packages/contracts-bedrock/src/L1/OptimismPortal.sol

Arbitrum Force Inclusion

• https://docs.arbitrum.io/sequencer
• https://docs.arbitrum.io/arbos/l1-to-l2-messaging#address-aliasing
• https://docs.arbitrum.io/tx-lifecycle
• https://github.com/OffchainLabs/nitro-contracts/blob/399790bb6660486fadf958017efc4eec99be3dd2/src/bridge/AbsInbox.sol#L161
• https://github.com/OffchainLabs/nitro-contracts/blob/v1.2.1/src/bridge/SequencerInbox.sol#L284
• https://github.com/OffchainLabs/arbitrum-tutorials/blob/master/packages/delayedInbox-l2msg/scripts/normalTx.js#L78-L82
• https://github.com/OffchainLabs/arbitrum-sdk/blob/01af6ef017e164bb7cb7febf7026ce60af76a112/src/lib/inbox/inbox.ts#L355-L369
• https://github.com/OffchainLabs/nitro-contracts/blob/399790bb6660486fadf958017efc4eec99be3dd2/src/bridge/AbsInbox.sol#L150

StarkNet Force Inclusion

• https://community.starknet.io/t/censorship-resistance/196
• https://community.starknet.io/t/starknet-escape-hatch-research/1108
• https://medium.com/@trinattapong/future-starknet-and-dawn-of-version-0-15-0-transition-roadmap-93c455570686

zkSync Force Inclusion

• https://l2beat.com/scaling/projects/zksync-era?ref=bankless.ghost.io#force-transactions
• https://docs.zksync.io/zk-stack/concepts/transaction-lifecycle.html#overview
• https://docs.zksync.io/build/developer-reference/l1-l2-interop.html
• https://github.com/matter-labs/era-contracts/blob/4aa7006153ad571643342dff22c16eaf4a70fdc1/l1-contracts/contracts/zksync/facets/Mailbox.sol#L192
• https://github.com/matter-labs/era-contracts/blob/4aa7006153ad571643342dff22c16eaf4a70fdc1/l1-contracts/contracts/zksync/facets/Executor.sol#L193-L196
• https://github.com/zkSync-Community-Hub/zksync-developers/discussions/523#discussioncomment-9886147

TEM Medium 2024 有獎徵稿

TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 有獎徵稿

Special thanks to Chih-Cheng Liang and Kimi Wu for reviewing and improving this post

Rollup 的 Force Inclusion 機制介紹 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.