EIP-7805：分叉選擇強制的包含列表 (FOCIL)

這是由 Ethereum Cat Herders 製作的 PEEPanEIP 第 141 集。主持人 Pooja Ranjan 邀請到以太坊基金會穩健激勵小組 (Robust Incentives Group) 的研究員暨 EIP-7805 (在新分頁開啟) 共同作者 Thomas Thiery 與 Julian Ma，來解釋分叉選擇強制的包含列表 (FOCIL)：為什麼以太坊需要協定層級的抗審查性、該機制的運作方式，以及目前的實作進度。

本逐字稿是 Ethereum Cat Herders 所發布之原始影片逐字稿 (在新分頁開啟)的無障礙副本。為提升閱讀體驗，內容已進行了適度編輯。

簡介 (0:35)

Pooja Ranjan： 大家好，歡迎來到 PEEPanEIP，這是唯一一個深入探討以太坊改進提案並探索其對生態系影響的節目。這是第 141 集，由 Ethereum Cat Herders 為您帶來。我是主持人 Pooja Ranjan，今天我們要討論的是 EIP-7805：分叉選擇強制的包含列表 (Fork-choice enforced Inclusion Lists)。

EIP-7805 於 2024 年 11 月記錄，是一項目前處於草案狀態的標準跟蹤核心提案。該提案旨在允許一個驗證者委員會在每個區塊中強制包含一組交易。該提案由 Thomas Thiery、Francesco D'Amato、Julian Ma、Barnabé Monnot、Terence Tsao、Jacob Kaufmann 和 Jihoon Song 共同撰寫，目前正為未來的升級進行積極討論。

在本集節目中，我們將探討 EIP-7805 的細節、其含義以及它對以太坊生態系的潛在影響。為了進一步討論這個提案，我們邀請到了 Thomas Thiery 和 Julian Ma。歡迎來到 PEEPanEIP。

Thomas Thiery： 感謝邀請。

Julian Ma： 是的，非常感謝邀請我們。

Pooja Ranjan： 我們很期待能了解該提案的概述、目前的進展，以及我們多快能在以太坊主網上看到它。但在我們開始之前，我們的社群很喜歡認識這些工作背後的研究人員和開發人員。你們能分享一下關於你們自己、目前參與的專案，以及你們在以太坊生態系中的旅程嗎？

來賓介紹 (2:14)

Julian Ma: 沒問題，我先開始吧。我是 Julian，和 Thomas 一樣，是以太坊基金會穩健激勵小組 (Robust Incentives Group) 的研究員。穩健激勵小組廣泛關注協定的經濟學。我們之中有些人一直在研究交易手續費機制，例如 EIP-1559，而其他人則在研究共識層攻擊，主要是那些受經濟激勵驅動的攻擊。

就我而言，我一開始是實習生，研究基礎費用衍生品，之後便轉為全職。我主要致力於提案者與建構者分離 (PBS) 以及與 MEV 相關的主題，現在我則專注於透過這個 EIP 以 FOCIL 實現包含列表 (inclusion lists)，並期待未來能實現證明者與提案者分離 (attester-proposer separation)。我會說，最讓我感到興奮的是將研究投入實際生產的過程：從較為理論的工作開始，將其發展成一個 EIP，並希望能成功在以太坊中提案與實作。

Thomas Thiery: 我是 Thomas。我也在以太坊基金會的穩健激勵小組從事研究工作。我的背景其實是神經科學博士，這與現在的領域截然不同。但我對區塊鏈和分散式系統產生了好奇，想嘗試一些不同的事物，於是加入了一家名為 Dune 的加密貨幣數據公司。我在那裡待了一陣子，但後來開始懷念做研究的日子，很幸運地能夠加入以太坊基金會 (EF) 和穩健激勵小組，到目前為止一切都很棒。

我研究過類似的主題。我剛加入時，MEV 是一個相當熱門的話題。有趣的是，我最初發表的研究文章篇幅很短，但主題正是關於包含延遲 (inclusion delays) 和抗審查性 (censorship resistance)。直到最近，我才真正深入探討這個領域。在過去半年到一年的時間裡，我更積極地參與抗審查性和交易包含 (inclusion) 方面的工作。能夠從研究想法出發，改進過去那些非常有趣但缺乏我們即將討論的細節的想法，提出一個提案，到現在有了實作和開發網，而且與我交談過的大多數人都認為這對以太坊來說會是一個很好的補充，這感覺真的很棒。

Pooja Ranjan: 感謝你們的分享。了解開發人員的背景總是令人深受啟發。看到他們來自不同的領域，最終卻都為以太坊生態系做出貢獻，這非常有趣。我知道我們今天準備了一份簡報。那麼事不宜遲，讓我們開始吧。

簡報：FOCIL 的目標 (5:16)

Julian Ma: 太好了，非常感謝。我想先做個簡短的簡報，介紹 EIP-7805（或稱 FOCIL）的運作方式，以及我們究竟為什麼要實作它。這主要是為了開啟話題，所以不會講得太深入，以便為後續的討論留出空間。

FOCIL 的主要目標是提高以太坊的可靠中立性 (credible neutrality)。FOCIL 的做法是消除目前單一提案者或區塊構建者在一個時槽內所擁有的包含壟斷權 (inclusion monopoly)。相反地，FOCIL 允許多個驗證者透過在每個區塊中包含交易，來共同參與區塊的構建。

更高層次的目標是追求一種我們稱之為「鏈中立性 (chain neutrality)」的特性，這意味著任何待處理且支付費用的交易，只要是有效的且鏈上有空間，就應該被包含進去。我們相信，如果這個特性得到充分滿足，就能提高以太坊的可靠中立性。

為什麼我們需要 FOCIL？為什麼是現在？ (6:09)

Julian Ma： 為什麼我們需要這樣的機制？目前幾乎所有的驗證者都將區塊建構外包給 MEV-Boost，這是一個協定外的市場，建構者在其中競標區塊建構權。在這個市場中，只有兩個實體真正佔據主導地位，這意味著 90% 的區塊僅由兩個實體建構。

我們在這裡看到，以太坊已經無法再從本地區塊建構中獲得其可信中立性。它曾經可以。最初，位於世界各地的提案者各自在本地建構他們的區塊，這意味著所有交易都會被包含在內。但現在區塊建構被外包給了這些複雜的實體，這已經不夠了。因此，有必要實施更強大的抗審查措施，而 FOCIL 是目前已知最好的方法。

為什麼我們現在應該實施 FOCIL？你可能認為建構者現在並沒有進行太多審查，但他們隨時可能開始審查，無論是出於監管原因還是經濟原因。而且經濟審查絕對是不容誤解的問題。在審查相對較少的時候引入 FOCIL 也是一件好事，因為這樣你就可以將其作為基準和預設機制來引入。所有驗證者都會製作包含清單，無論其司法管轄區或經濟誘因如何，這幾乎不會造成市場不穩定。反之，如果你在所有建構者都在進行審查時引入 FOCIL，也許會更加困難。

此外，基礎匯總（Based rollups）如今變得越來越普遍，它們將依賴以太坊的區塊建構來承載運作。如果我們想提供以太坊所具備的排序功能，就有必要透過 FOCIL 在此實現可信中立性。

而且，FOCIL 潛在地可能有助於擴容，這取決於你問的是誰。如今，以太坊仍然從本地區塊建構中獲得其抗審查性。如果以太坊可以從其他地方獲得抗審查性（例如透過 FOCIL），那麼也許我們可以提高對區塊構建者的期望，並允許（例如）更多的資料塊。但這潛在地也可能在沒有 FOCIL 的情況下完成。因此，有人提議在富薩卡（Fusaka）升級中實施 FOCIL。

FOCIL 的運作方式 (8:10)

Julian Ma： 現在我將為大家講解 FOCIL 的運作方式。我們將從基礎開始，逐步深入，直到掌握完整的機制，然後探討這個完整機制如何滿足我們想要的特性。

包含清單 (inclusion list) 的基本概念（Mike Neuder 之前也曾提出過）是，存在一個交易清單，以某種方式對區塊進行約束。舉例來說，有一個包含交易 A 和 B 的包含清單，它由協定認可的某人簽署，然後這些交易就必須被包含在某個區塊中。FOCIL 並沒有改變這一點。它以此為基礎，更多的是關於誰來建立這個清單，以及如何強制執行這個清單。

那麼，誰來建立這個清單呢？這是 FOCIL 協定運作方式的第一步。在每個時槽中，會選出 16 名驗證者作為包含清單委員會成員。這些委員會成員各自觀察記憶體池，並建構自己的包含清單。一個包含清單的大小約為 8 KB，大約是 20 筆平均大小的交易，這意味著總共大約有 320 筆平均大小的交易。

第二步是散佈這些包含清單。包含清單委員會成員透過全域主題 (global topic) 散佈他們的包含清單，而他們自己不會將其包含在區塊中。他們必須在該時槽的第 9 秒之前完成此操作，此時證明者 (attester) 會凍結他們對本地包含清單的視圖。正如我們將在下一步中看到的，證明者才是實際強制執行這些包含清單的人，顧名思義：分叉選擇強制執行的包含清單 (fork-choice enforced inclusion lists)。他們在第 9 秒凍結他們將強制執行的包含清單視圖，這可以防止視圖分割攻擊 (split-view attacks)。區塊生產者仍然有幾秒鐘的額外時間來觀察包含清單，並確保它不會因為遺漏任何包含清單而受到負面影響，因此在這種設定下，區塊生產者沒有任何風險。

接著我們進入最後一步，也就是強制執行。正如我所說，強制執行是透過分叉選擇來完成的。證明者只有在區塊滿足包含清單條件時，才會對該區塊進行投票。他們透過觀察在全域主題上發送的包含清單，將他們在這些包含清單中看到的交易彙整成一個清單，然後檢查這些交易是否都在區塊中。如果檢查通過，他們就會對該區塊進行投票。也可能出現包含清單中的交易並非全部都在區塊中，但區塊已經滿了的情況。在這種情況下，證明者也會對該區塊進行投票。因此，除非區塊既沒有包含這些交易，也沒有滿載，否則證明者都會對該區塊進行投票。

總結一下完整的機制：在每個時槽中，會選出 16 名委員會成員作為包含清單委員會成員。他們觀察記憶體池並建構包含清單物件，在截止時間（在此情況下為第 9 秒）之前透過全域主題進行散佈。建構者觀察這些包含清單，並將其看到的所有交易包含在其區塊中。然後，證明者會檢查他們在第 9 秒之前在包含清單中看到的所有交易是否確實都在區塊中。如果檢查通過，他們就會對該區塊進行投票，然後我們進入下一個時槽，再次進行相同的設定。

IL Boost 與不可擁擠性 (11:07)

Julian Ma：關於包含清單（inclusion list）的一個主要擔憂，在 Mike 提出的前一個 EIP 以及隨後的開發過程中都有被提及，那就是「IL Boost」或不可擁擠性。這指的是包含清單提案者可能會想要出售他們建立包含清單的權利。這是一個非常合理的擔憂，因為我們在區塊建構中看到了這種情況：出售這種權利會導致一個由複雜建構者組成的中心化市場。

我們認為，基於以下特性，FOCIL 能夠有效抵禦這些類似 MEV-Boost 的市場（俗稱 IL Boost）。FOCIL 不保證任何交易的排序。無論你將交易放在包含清單中的哪個位置，區塊構建者都會以他們認為合適的方式對其進行排序。舉例來說，如果你在清單中包含了一筆套利交易，建構者極不可能將你的套利交易放在區塊的頂部以便實際執行該套利。相反地，建構者可能會自己執行套利。

此外，私有訂單流（private order flow）是不可能的。這些包含清單會透過全域主題（global topic）進行散佈，因此在建構者建構區塊之前，你的交易是公開的。私有訂單流不可能透過包含清單進入區塊。

第三，每個時槽有多個包含清單提案者。即使有有價值的東西可以出售，所有 16 名包含清單委員會成員都有相同的可能性來建構這個包含清單，因此這些包含清單提案者之間的競爭會將價值壓低至零。

最後，這些包含清單是在區塊生產者行動前 3 秒建立的。在提交包含清單之後、區塊生產者行動之前，會有 3 秒鐘的額外資訊到達，這對於 MEV 類型的交易通常極為相關，這意味著資訊優勢非常小。實際上，對於那些試圖將包含清單作為 MEV 工具的人來說，反而處於資訊劣勢。

基於這些原因，我們認為沒有任何單一的包含清單提案者擁有包含、排序或排除的權力，而這正是 MEV 的基本定義。因此，包含清單不應受到 MEV 的影響。

簡報總結 (13:09)

Julian Ma： 總結這份簡短的簡報：FOCIL 允許多個驗證者參與區塊構建，防止單一提案者壟斷交易打包，並提升以太坊的可信中立性。我們認為現在有必要實施 FOCIL，因為目前只有兩個佔主導地位的建構者，他們隨時可能開始進行審查，而這可能是出於他們能從中獲益的經濟原因。區塊構建可能會變得更加吃重，因為基礎匯總 (based rollups) 會想要使用以太坊的排序特性。當審查方較少時，FOCIL 的推出會順利得多：首先，這意味著驗證者建立包含清單會成為預設行為；其次，這意味著在進行審查的建構者和不進行審查的建構者之間，市場的不穩定性會較低。最後，FOCIL 潛在有助於擴容，這或許是我們可以進一步深入探討的主題。

感謝大家撥冗聆聽這份簡短的簡報。我只想展示一下這個 QR code，它會連結到該 EIP，供有興趣的人參考。

Pooja Ranjan： 非常感謝您帶來這份簡短的簡報以及對該提案的概述。

問與答：EIP-7805 與 EIP-7547 有何不同？ (14:17)

Pooja Ranjan： 我想以第一個問題來開始問與答環節，這是有關您在簡報中也提到的早期提案：由 Mike Neuder 提出的提案 7547（包含清單）。我想了解該提案與我們在 7805 中的 FOCIL 之間的基本差異。您在簡報中確實部分提到了 IL Boost 和不可擁擠性（uncrowdability）。您是否願意再多解釋一點？

Julian Ma： 也許 Thomas 最適合回答 7805 與 7547 有何不同，但我可以稍微談一下。首先，FOCIL 是針對同一個時槽，而 7547 則是針對下一個時槽。同一個時槽的特性讓一些事情變得更容易，因為這意味著包含清單不需要儲存在鏈上。

關於不可擁擠性的特性，這是一個非常有趣且微妙的點。在 7547（這是一個很棒的提案，我們的提案也是建立在它之上）中，包含清單會無條件地附加在區塊的底部，並且由單一個人製作。這與我們的提案有幾個不同的特性。首先，交易是有序的。未來，區塊底部的套利可能會非常有價值，事實上，Thomas 的一些研究已經強調這可能是一個有價值的位置。擁有建立包含清單的權利，意味著你是區塊中最後一個採取行動的人，在某些情況下這可能很有價值。其次，它是由單一個人製作的，因此在包含清單委員會成員之間不會有這種競爭效應。只有一個人的委員會擁有在區塊底部包含交易的完全權利，這也可能使其更有價值。第三，它具有這種無條件的特性，這意味著無論區塊生產者做什麼，你的交易無論如何都會被包含在鏈上。因此，除了包含所需的最低限度之外，它還有一些額外的保證，這在某種程度上可能使其具有價值。

Thomas Thiery： 另一個很大的差異是我們擁有的包含清單提案者數量。在先前的提案中，有一種機制是時槽 n 的提案者製作包含清單，而時槽 n+1 的提案者需要強制執行它。這裡有兩件大事：第一，有一個時槽的延遲，因此包含清單中的交易只需要由下一個提案者在下一個時槽中包含。而且實際上只有一個提案者製作包含清單。在 FOCIL 中，我們有 16 個。這產生了巨大的差異，因為現在我們只需要 16 名包含清單（IL）委員會成員中有一名是誠實的，整個機制就能按預期運作。這成倍增加了你實際擁有良好抗審查機制的機會，而以前你只能依賴單一方。

然後是一些更技術性的細節：與帳戶抽象化存在一些不相容性，而且很難處理 IL 模稜兩可的問題，也就是有人發送了兩個不同的包含清單。區塊模稜兩可是一件已知的事情，並且會受到協定的懲罰，但由於在先前的提案中所有東西都上鏈了，你還必須處理奇怪的邊緣情況，而且要適應它們並不容易。在 FOCIL 中，包含清單不會上鏈。它們只是透過 P2P 共識層網路進行廣播。這有點技術性，但在處理由帳戶抽象化引起的這些邊緣情況，或者透過 IL 模稜兩可將網路分裂成兩種視角的攻擊時，它確實產生了很大的差異。

Pooja Ranjan： 非常感謝。對於想了解更多關於提案 7547 的人，我們確實有一集與 Mike Neuder 錄製的節目，即 PEEPanEIP 的第 130 集，其中提供了高階的概述。我總是喜歡看到競爭性的提案，因為我知道這是為了生態系和鏈的更好發展。我看到聊天室裡有幾個問題。也許我想邀請 Kataya 分享她的問題。

提案者必須包含所有 16 份清單嗎？ (19:05)

Kataya： 你好，謝謝。我的問題是：區塊提案者會收到 16 份包含清單（每份來自一名委員會成員）嗎？而且它必須包含這些清單中的所有交易嗎？

Thomas Thiery： 是的，沒錯。你要取所有清單（在我們的例子中是 16 份清單）中所有交易的聯集。顯然可能會有重疊，所以你要取聯集並刪除重複項，但是的，所有清單中的所有交易都需要被包含在區塊中，證明者才會認為該區塊是有效的。

Pooja Ranjan： 聊天室裡的下一個問題來自 Justin。Justin，你想為來賓唸出你的問題嗎？

包含清單中的私有記憶體池交易 (19:55)

Justin: 我問了好多問題。我想問的是，有什麼機制能防止將私有記憶體池中的交易放入包含清單中，而我認為這個問題已經得到了很好的解答。聽起來這樣做完全沒問題，考慮到建構者基本上還是會按照他們認為合適的方式對這些交易進行排序，而且當你的交易進入包含清單 (IL) 時，它也會被公開。所以我認為這很合理。謝謝。

Thomas Thiery: 就像 Julian 提到的，這是其中一個考量點。我們真的不希望 FOCIL 和包含清單被用來納入 MEV 交易、私有訂單流或預先確認，因為我們最終想要的是抗審查性，如果不小心的話，一個機制很容易就會變成納入高價值交易的工具。事實上，當你將交易放入包含清單時，它會自動公開，每個人都能看到，它沒有排序保證，而且建構者可以將其放在區塊中的任何位置，這使得它非常不適合用於高價值交易。

因此，你要麼有一筆公開交易，並可能只是將其提交到公開記憶體池，以便將其納入包含清單中；要麼你擁有高價值的私有交易，那樣你就不會透過 FOCIL，因為有更好的方法可以做到這一點。你會直接聯繫建構者，並透過私人管道發送。

Pooja Ranjan: 感謝你的分享。我看到下一個問題是 Ladislaus 提出的。

FOCIL 與擴容 (21:41)

拉迪斯勞斯： 大家好。這與你們剛才提到關於 FOCIL 和擴容的觀點有關。最近我看到了一些關於以太坊擴容的討論（大家應該也都看到了），正如你們所說，目前存在著少數幾個建構者造成的瓶頸。我個人傾向將 FOCIL 視為重新賦權本地構建，並且我認為在我們提高頻寬要求或整體的節點要求之前，將其納入協定中是必要的。也許你們可以詳細說明一下對此的看法，以及正如你們提到的，在沒有 FOCIL 的情況下，其他潛在的擴容方式。

朱利安·馬： 感謝你的提問。首先，關於透過 FOCIL 進行擴容的情況。目前有 90% 的驗證者透過 MEV-Boost 將區塊構建外包，而這些技術成熟的實體顯然擁有超過最低硬體要求的頻寬。例如，他們可以在其區塊中包含更多的資料塊，而不會引發任何問題。然而有趣的是，以太坊依賴本地區塊構建來實現可信中立性或抗審查性，因為這兩個技術成熟的實體並不能作為以太坊建立抗審查性的基礎。

因此，以太坊協定的設計仍必須保留進行本地區塊構建的可能性，事實上，我們的設計確保了與 MEV-Boost 相比，它並非無利可圖。這存在於以太坊的設計中，但在實務上，MEV-Boost 當然要有利可圖得多：首先是因為這些技術成熟的區塊構建者擁有更複雜的演算法，其次是因為他們擁有更多的私人訂單流。Data Always 最近的一項研究顯示，MEV-Boost 區塊包含的交易數量要多得多。單憑這一點就能帶來更多利潤。

儘管如此，協定的設計確保了協定規則內部沒有任何力量會使某個驗證者的利潤低於另一個驗證者。如果我們想保留這項規則，那麼 FOCIL 就是必要的，因為這樣本地區塊構建者就可以為包含清單做出貢獻，從而維持抗審查性。不過，我們也可以廢除這項規則，基本上就是說本地區塊構建者可以包含一定數量的資料塊，但更成熟的區塊構建者可以包含更多的資料塊，其程度甚至會讓本地區塊構建者在自行創建區塊時無法處理該負載。因此，如果我們想保留將最大值設定為最低硬體要求的規則，那麼我們就需要 FOCIL。如果我們覺得放寬這項規則也無妨，那麼我們可能就不需要為了擴容而使用 FOCIL。

湯瑪斯·提里： 我想這非常相似，但目前在以太坊上，我們處於一個奇怪的境地，因為我們依賴技術成熟的建構者來構建大部分區塊，但這對抗審查性來說並不好，因為這只涉及兩方。如果他們出於某些任意原因決定審查交易或某些地址，那麼基本上我們就失去了抗審查性或無須許可性，而這也是非常重要的。這意味著他們可以審查或限制任何他們想要限制的參與者在鏈上參與，這是非常糟糕的。

而且我們保留的抗審查屬性並不理想，對吧？由於大多數區塊都是由這兩個建構者構建的，你基本上需要等到一個本地區塊構建者被選中，並提出一個包含所有這些通常被審查的交易的區塊，這感覺並不好。這意味著這些使用者將需要等待 10 個、12 個，我不知道，總之是很多個區塊，直到他們的交易真正被包含在鏈上。

因此，我們真的希望保留家庭質押者和本地區塊構建者，因為他們是維護抗審查性的人。同時，在今天，即使使用他們也不是很理想，因為如果你的交易被這兩個建構者審查，你仍然需要等待很長時間才能讓你的交易被包含進去。有了 FOCIL，你將進入這樣一個世界：保證抗審查性的參與者（在我們的例子中是包含清單委員會成員）可能與構建區塊的人不同。我認為這開啟了一個非常有趣的前景，因為現在我們不必依賴完全相同的參與者來同時構建有價值的區塊並為抗審查性做出貢獻。FOCIL 也可以被視為朝著這個重要方向邁出的第一步，因為你有兩個非常不同的職責，而今天我們要求完全相同的驗證者節點同時執行這兩項職責，這兩者之間存在著很大的衝突。

普賈·蘭詹： 非常感謝。我想下一個問題是路易斯提出的。

選擇交易的標準 (26:46)

Luis Pinto： 我在開始幾分鐘後才加入，但對我來說，這似乎是在將整個網路中的交易選擇去中心化。我認為這非常好；它能對抗 MEV 和審查制度。而且我非常喜歡讓證明者來做這項工作的部分，因為未來他們的硬體要求會比建構者更低，在實現無狀態性和無狀態客戶端後更是如此。既然你能夠以非常低的硬體要求來運行它，這會讓事情變得非常去中心化。我想這裡的主要挑戰是定義這些包含清單的交易選擇標準，無論你是根據優先費用還是資料塊的數量；變數實在太多了。你們是否已經決定了一套打算強制執行的標準？

Thomas Thiery： 這是個好問題。這可以分為兩個層面。第一個層面非常重要，關於試圖將證明者與建構或提案區塊的人分開。這就是整個證明者與提案者分離 (APS) 的研究方向；Julian 在這方面做了很多工作。我們稱之為角色解綁，這樣它們就能更緊密地符合協定的職責。我寫了一篇文章（剛剛分享了），探討一種可能的分離方式，這是一個非常開放的議題，我很希望能聽到更多人的意見。在這篇文章中，我將證明者、包含者（即現在的 IL 委員會成員）以及執行提案者（或建構者）區分開來。我認為這些是根本上不同的職責，也許我們應該為它們設定不同的角色。

其次，關於包含規則，這是一個非常好的問題。我們確實對此思考了很多，我想我們得出了兩點結論。第一點是我們希望規則具有多樣性。我們不希望只有單一規則，例如所有客戶端都按優先費用遞減排序，因為這樣你實際上可以玩弄手段，試圖重新排序記憶體池，使得只有你的交易被包含在 IL 中。但如果你有多樣化的規則，包括一項同時考慮交易在記憶體池中等待時間的規則，並且不同的客戶端實作不同的規則（風格大致相同，主要圍繞優先費用和在記憶體池中的等待時間），那麼這將非常、非常難以被操縱，並使協定變得更加穩健。我認為，這也是一個好方法，可以利用當今以太坊上客戶端的多樣性，並讓客戶端做出有主見的選擇。我們心中有一些規則，但我們認為客戶端也可以選擇最適合他們的規則。只要不是每個人都使用完全相同的按優先費用排序的規則，我們就不會有問題。

Luis Pinto： 好的，所以你們也將這個標準分散化，讓建構包含清單的人擁有自己的標準。還是說這將成為協定的一部分？

Julian Ma： 包含規則不會成為協定的一部分。首先，這很難強制執行；其次，實際上最好不要強制執行任何東西。如果我們允許委員會成員自行決定，或者讓客戶端團隊代表他們決定如何包含交易，那麼我們就能在網路中創造一些穩健性。具有不同偏好的人會以不同的方式包含交易，這意味著攻擊系統會變得更加困難。

Luis Pinto： 好的，謝謝。

與 EIP-7702、ePBS 和 PeerDAS 的相容性 (30:43)

Pooja Ranjan： 非常感謝。據我了解，這項提案已經被提議用於佩克特拉之後的升級，即富薩卡。考慮到富薩卡可能會或可能不會包含其他正在進行中的 EIP，我想知道 FOCIL 與其他提案（例如用於帳戶抽象化的 7702、ePBS 和 PeerDAS）的相容性狀態如何。

Thomas Thiery： 很好的問題。因為包含清單的歷史，我們在這裡有一點優勢。正如我們所提到的，7547 曾被考慮納入，但後來因為相容性問題而被拒絕。因此，在提出新提案之前，我們非常謹慎地解決了這些問題，因為我們知道人們會帶著同樣的問題來看待它，這是很合理的。

我們非常有信心，因為我們也與帳戶抽象化團隊進行了交談，並且與 Potuz 和 Terence 進行了大量討論。Terence 一直在積極幫助我們，他同時參與了 ePBS 和 FOCIL 的工作，因此我們很容易檢查這兩者是否相容。我真的不認為與任何其他 EIP 存在相容性問題。對於 ePBS，你必須小心處理時間安排，因為你將執行負載與共識區塊分開，所以整個時槽的時間安排都會改變，而且現在你還增加了在提案負載之前需要建立的 ILs。所以你需要注意時間安排，但如果我沒記錯的話，從我們上次與 Potuz 和 Terence 討論的情況來看，根本沒有任何關鍵的相容性問題。我認為在相容性方面，我們的情況看起來很好。

Pooja Ranjan： 很高興知道這一點。我注意到 Jihoon 也分享了一份 HackMD，我們將其加入到資源中，供那些想專門了解與 ePBS 相容性的人參考。是的，我記得上次與 Mike 交談時，我猜該提案沒有被納入是因為帳戶抽象化的不相容性。所以很高興知道這個問題已經被解決了。

FOCIL 與多時槽 MEV (33:04)

Pooja Ranjan: 我在瀏覽 FOCIL 網站 (meetfocil.eth.limo) 上新增的文件與詳細資訊時，了解到一個稱為「多時槽 MEV (multi-slot MEV)」的術語。Julian 也提到，儘管開發人員希望並努力使其保持平衡，但 MEV-Boost 整體而言是有利可圖的。我想知道 FOCIL 將如何防止這種情況。

Julian Ma: 謝謝妳的提問。首先，讓我談談關於 FOCIL 與 MEV 的事，然後我們再繼續討論多時槽 MEV。FOCIL 不一定會防止 MEV，這正是因為我們希望將 MEV 部分與包含 (inclusion) 部分解綁。在我們看來，這樣做很重要，因為否則就會出現類似 IL Boost 這樣的市場。基於這個理由，如果包含清單能夠限制可提取的 MEV 數量，那麼建立包含清單就會變得非常有價值，人們就會圍繞它建立市場。我們的設計實際上是為了提供最低限度的包含保證，這意味著成為包含清單委員會成員並沒有那麼高的價值，而且委員會共有 16 名成員，這代表不會出現由專業生產者組成的市場。

接著，繼續討論多時槽 MEV：FOCIL 緩解了部分問題，但並沒有徹底解決。這同樣是因為同時提供抗審查性與 MEV 解決方案之間存在不相容性。FOCIL 的作用是允許任何交易被包含在內，只要它支付了費用，這在某種程度上解決了多時槽 MEV 的問題。這裡的多時槽 MEV 是指，如果某一方連續控制兩個區塊，就能夠提取更多的 MEV。

FOCIL 緩解了部分問題，因為它允許你插入你的交易。舉例來說，如果你需要插入一筆交易來清算某處部位的壞帳，即使提案者試圖審查你，並打算在下一個區塊從你身上提取 MEV，你仍然能夠這麼做。

它之所以沒有解決所有問題，是因為逆向選擇 (adverse selection)——這是一種一方比另一方擁有更多資訊的經濟特性。多時槽 MEV 的一個例子是跨兩個區塊提取套利，區塊構建者不在第一個區塊提取套利，而是在第二個區塊才這麼做。一些理論結果顯示，對區塊構建者而言，這可能比在兩個時槽中都提取套利更有利可圖。你可能會認為 FOCIL 在這裡有所幫助，因為套利者原則上可以將他們的交易放入包含清單中，從而強制發生某種套利。雖然情況確實如此，但套利者將交易提交給 FOCIL 並不符合誘因相容 (incentive-compatible)，因為從他們提交交易到區塊構建者能夠採取行動之間，仍然有 3 秒鐘的時間差。如果你試圖進行套利，而外部市場的價格不斷波動，你不會想提前 3 秒做出承諾，因為你擁有的資訊遠少於比你晚行動的區塊構建者。逆向選擇之所以發揮作用，是因為建構者擁有更多資訊：如果情況對你不利（例如外部市場的價格在那額外的 3 秒內朝著對你不利的方向變動），它就會讓你贏；如果對它自己有利，它就會讓自己贏。

因此，FOCIL 解決了多時槽 MEV 中交易不會遭受逆向選擇的部分。對於存在逆向選擇的交易，情況稍微複雜一些，但它在某種程度上緩解了這個問題。原則上，它讓情況比現在更好，但仍有一些工作需要完成。

Pooja Ranjan: 很好，非常感謝你的分享。我了解目前有許多正在進行的研究旨在解決 MEV 問題，所以很高興知道至少在原則上，它會比目前的情況更有幫助。

權衡與挑戰 (36:44)

Pooja Ranjan： 我有一個問題，與 Thomas 稍早提到關於 IL 模稜兩可（equivocation）的內容有關。我注意到在提案的安全考量章節中，提到了不少重點，像是共識活躍度（consensus liveness）、IL 模稜兩可，以及負載建構（payload construction）。您認為最大的權衡是什麼？或者有什麼可能需要更多研究，並可能阻礙這個提案以現狀進入下一次升級？

Thomas Thiery： 老實說，我認為安全考量章節主要是為了表明我們已經思考並解決了有關安全的疑慮。這更多是為了展示這一點，而不是說我們對未知的安全問題還有什麼懸而未決的疑問。我不認為在安全考量方面有任何重大的阻礙或問題。

至於權衡：如果從非常狹隘的角度來看，FOCIL 確實為驗證者增加了一些任務，無論是當他們必須提出包含清單（inclusion list）時，還是對於證明者（attesters）來說，當他們必須多檢查一個條件以確保區塊根據包含清單是有效的時候。這也為提案者增加了一項小任務，因為現在它需要確保其負載確實包含了 IL 中的交易。對我來說，這是唯一的權衡，而且這些任務並不繁重或複雜。IL 委員會成員只需監控公開的記憶體池，並將交易包含在他們發送的清單中。這不需要任何特殊的技能或複雜的操作，我認為這點很好。另一方面，正如我們所說，它可能會解鎖一些重大的擴展性改進，並在協定內的參與者和職責之間實現更好的分離。

我可能有偏見，但我沒有看到什麼重大的權衡。我確實認為，在抗審查性方面，它徹底顛覆了現狀。現在你基本上只需要網路中有 15% 的誠實節點，就能讓所有交易（包括可能被建構者審查的交易）被包含在下一個區塊中，這是一個非常大的進步。老實說，我不認為你在這方面犧牲了太多東西。

Pooja Ranjan： 很高興知道這一點。在大多數提案中，我們發現安全考量章節要麼沒有資訊，要麼資訊很少，所以很高興知道這部分已經進行了研究，而且我們也意識到了可能的安全考量。很高興知道這不會成為未來實作和採用的阻礙或潛在挑戰。

包含清單的交易手續費機制 (39:50)

Pooja Ranjan： 我有一個關於我在網站上發現的一些未解決問題的疑問，是關於交易手續費機制的。我想知道是否有任何更新，或者你們是否願意分享更多關於收取手續費以及分配這些手續費以納入包含清單的最佳方式。

Thomas Thiery： 我們有一項正在進行的資助計畫，專門研究這個問題以及獎勵包含清單（IL）委員會成員的激勵機制。這並不容易。這很棘手，而且無論你如何處理，這些都是非常大的改變。改變以太坊上的手續費，無論是更改手續費、增加手續費，還是增加新的發行，所有這些都是需要大量考慮和謹慎對待的重大改變。但這正在探索中，而關於在（例如）包含某筆交易的委員會成員之間分配手續費的想法，似乎是不錯的主意。它在某種程度上具有我們想要的特性，因為我們希望獎勵那些包含其他人可能不想包含的交易的人。因此，我們正在非常深入地思考這個問題，並且我們有一項正在進行的資助計畫。

還有一個問題是，我們是否真的想向 IL 委員會成員支付手續費，因為要獎勵分佈在世界各地的小型參與者顯然非常困難。你不希望發生女巫攻擊，也不希望擁有大量質押的大型參與者排擠 IL 委員會的成員。你該如何防止這種情況？這非常困難。因此，你需要考慮許多設計上的因素。

我最近的一個想法是：如果我們為 FOCIL 增加一些很酷的功能（例如隱私），讓你無法真正知道是誰提案了特定的交易清單呢？你知道那是某個實際被選為 IL 委員會成員的人，但你不知道具體是誰提案了哪個清單，因此你無法將 IL 委員會成員與其 IL 中的交易集連結起來。如果我們能做到這一點，並讓 IL 委員會的角色變成某種選擇性加入的形式，那麼我們可能會在協定中擁有誠實的參與者，依賴利他行為，也許我們根本不需要建立手續費機制。這是一個非常近期且帶有個人主見的想法，目前正在積極探索中。所有這些都是「FOCIL 的未來」討論；它們不應該被包含在當前的 EIP 中。

Julian Ma： 補充一點，最後一部分也非常重要：EIP-7805 不包含任何交易手續費機制，以使其更容易實作。這基本上是我們能夠提供抗審查特性的最小可能方式，但它非常具有擴展性。我們正在研究這個問題。Thomas 已經做了相當多的工作，研究為包含者和提案者分別設定交易手續費。然後，正如 Thomas 所提到的，我們與奈瑟邁（Nethermind）的一位優秀研究員有一項正在進行的資助計畫，他正在研究為 FOCIL 建立交易手續費機制，這非常有前景。最後，還有一項針對 FOCIL 變體（稱為 AUCIL）的交易手續費機制的研究，這是一種基於拍賣的包含清單設計，由 Sarisht Wadhwa、Fan Zhang 和 Kartik Nayak 以及幾位 FOCIL 作者共同提案，該設計探討了激勵包含清單委員會成員的方法。

就 Luis 稍早的觀點而言，激勵機制在很大程度上與包含清單的建立方式有關。這意味著協定希望對包含清單委員會成員應如何表現提供某種觀點。通常歸根結底，這意味著它希望某些參與者做不同的事情。例如，它可能會對委員會成員進行排序，並透過相關均衡為他們分配特定的交易，以便在委員會成員之間仍然保持一些不同的行為。因此，這不是當前提案的一部分，但我們絕對正在研究它，而且它符合 FOCIL 的擴展性方向。

Pooja Ranjan： 喔，這很有趣。所以我們應該期待未來會有一些補充提案，以增強當前的 FOCIL 功能。

包含清單大小 (44:16)

Pooja Ranjan: 我還有一個問題。我不確定這是否應該是目前提案的一部分，但我很好奇想了解關於 IL 大小是否有任何更新。包含清單 (IL) 可能必須限制大小，以防止過度消耗頻寬。關於如何決定包含清單的最佳大小，我們有任何進一步的研究或更新嗎？

Thomas Thiery: 我們現在在規格中有一個固定的大小，而且已經存在一段時間了：8 KB。我們以 KB 為單位，因為 FOCIL 和 IL 真正消耗的是頻寬，差不多就是這樣。如果以交易大小中位數來看，每個 IL 大約有 40 筆交易，如果所有交易都是唯一的，那麼在所有 16 名委員會成員中，大約可以組合出 640 筆交易。

我不知道是否還需要對確切的最佳大小進行太多研究。我們的考量是：16 乘以 8 KB 基本上就是一個資料塊的大小，所以加總起來並不是非常龐大的頻寬。而且，由於跨 IL 組合的交易量大於一個區塊，我不認為我們在那裡會遇到問題。

未來，你可以增加 IL 的大小，但也可以考慮增加 IL 委員會成員的數量。如果網路上的多數決定開始進行審查，這能讓你更有機會獲得一名誠實的 IL 委員會成員。所以這也是我們可以做的事情。目前看來，16 名成員應該完全沒問題且足夠了，但如果未來審查變得非常瘋狂，或者我們需要採取更多行動，你絕對可以調整這些參數。

追蹤採用情況的指標 (46:39)

Pooja Ranjan: 這裡有一個後續問題：您心裡是否有任何指標，可以讓我們用來追蹤並了解這項提案的採用情況或成功與否？

Julian Ma: 這是個好問題。讓我快速回答一下，然後把發言權交給 Thomas。一些簡單的指標就是有多少被提出的包含列表（inclusion list）是非空的。你可以想像一些儀表板，像是 Toni Wahrstätter 的「.pics」系列，那裡可能會有更豐富的資訊，為這些包含列表分配一些品質衡量標準。不過原則上，每個時槽只需要有一個人製作適當的包含列表，就能提供抗審查性。

我認為這是非常重要的一點，盡快實作 FOCIL 很重要，因為我們現在處於一個神奇的狀態：區塊構建者沒有進行太多審查，驗證者也沒有進行太多審查。我會說這種狀態非常脆弱。到目前為止，區塊構建者已經審查很長一段時間了，如果我們現在引入 FOCIL，我們就有可能讓所有這些驗證者預設採用它，並建立有意義的包含列表。因為區塊構建者沒有在審查，所以這裡不會產生市場不穩定。如果我們等到構建者之間出現審查時才行動，那麼引入 FOCIL 就會困難得多，而且我可以想像所有用來衡量採用情況的指標都會變得更糟。

Thomas Thiery: 另一個需要關注的關鍵指標，就是公共記憶體池交易的包含延遲（inclusion delay）。你可以查看公共記憶體池中所有待處理的交易，看看它們被包含的速度有多快。如果 FOCIL 發揮作用，它們都會被包含在下一個區塊中。如果沒有，這意味著很大一部分的驗證者正在進行審查。因此，我們可以觀察的另一個指標是誰在審查，以及網路中有多少比例在審查。我們將會有儀表板和非常透明的指標來追蹤這一點，因為這基本上就是 FOCIL 應該做的事。如果公共交易沒有被包含在下一個區塊中，這意味著網路中很大一部分實際上正在審查這些交易。

Pooja Ranjan: 非常有趣。所以這或許是給研究人員的建議：一個可能的升級願望清單，也就是每當一項提案被包含在網路升級中時，開發人員應該分享該提案的儀表板和指標追蹤工具。

客戶端實作狀態 (49:11)

Pooja Ranjan：正如 Julian 所提到的，這個提案可能需要盡快實作。我很好奇我們目前在客戶端實作方面的進度，因為我記得在上次的測試網通話中，Paritosh 提到要在開發網中加入一些支援。那麼我們目前的進度如何？

Thomas Thiery：我們進展得相當順利。首先，看到大家如何投入 FOCIL 的實作部分真的非常棒，因為我不是開發人員，我是一名研究員。我從一開始就與開發人員合作，但我不是在客戶端中實作這些東西的人。

帶頭進行這項工作的主要有三位：我們有來自普萊斯姆 (Prysm) 的 Terence，以及在普萊斯姆 (Prysm) 上幫了 Terence 很多忙、同時也參與了 Geth 開發的 Jihoon。所以現在我們已經有了一個適用於普萊斯姆 (Prysm) 和 Geth 的運作中開發網，這非常棒，而且目前正在進行大量的測試。我們現在也正努力讓 FOCIL 能夠在 Dora 瀏覽器上顯示並被看見。接著是 Jacob，他參與了萊特豪斯 (Lighthouse) 和瑞斯 (Reth) 的工作，我知道那邊還有一些工作正在進行中。洛德斯塔 (Lodestar) 最近非常活躍；我想他們已經非常接近完成一個可運作的開發網了。我們今天也收到了來自奈瑟邁 (Nethermind) 的消息，他們已經有了一個原型，這真的太棒了。我覺得我好像忘記了其中一些……Jihoon 說寧布斯 (Nimbus) 也加入了。這真的很棒。

整體而言，我們有越來越多的開發網準備就緒並上線，包括本地開發網，以及越來越多執行層與共識層客戶端之間的組合。目前已經取得了一些非常好的進展，這令人感到高興，因為我們都知道開發人員現在因為即將到來的佩克特拉 (Pectra) 升級而非常忙碌，而且已經在進行 PeerDAS 和其他專案的工作。看到以太坊上的大家整體而言都非常關心抗審查性，這真的很棒。大多數我沒有特別聯繫的團隊都主動加入了這項工作，現在正朝著開發網和測試的方向努力。

Pooja Ranjan：感謝你的分享。我很期待能持續關注開發網的最新動態。我不確定這個開發網會進行多少次迭代，但我很高興看到它的出現。我看到 Justin 這裡有一個問題。Justin，請說。

FOCIL 在富薩卡還是格蘭斯特丹？ (52:07)

Justin: 好的，準備好迎接這個問題。你提出了一個非常好的觀點，那就是解決審查制度的最佳時機是在審查發生之前，對吧？那麼：FOCIL 應該在富薩卡中實行，還是可以等到格蘭斯特丹？身為一名開發者，我應該提倡哪一個？

Thomas Thiery: 我們已經開啟了 PR，並且已經合併，FOCIL 被提議納入富薩卡。我們認為它應該進入富薩卡。部分原因是某些客戶端已經開始著手處理，而且他們沒有遇到太多障礙。它不像其他提案那樣難以實作且需要大量工作。而且它也沒有太大的爭議。我不認為有任何人會反對抗審查性，大家基本上都同意需要盡快將其納入。所以我會選擇富薩卡。

我不知道它是否能等。提案和升級總是可以等待的。我只是想避免陷入一個不容易實作這些變更的世界。情況可能會迅速逆轉。正如我們所見，事情走向了另一個方向：幾個月前，其中一個主要的建構者突然停止了審查。我們問為什麼，他們的回應像是：「對，我們只是決定不這麼做了。」在那個情況下是件好事，因為它是往好的方向發展，但情況完全有可能再次逆轉，然後我們可能會面臨兩個建構者審查某些交易的情況，那我們就會回到非常糟糕的處境。

我想提的另一件事，因為我確實認為這很重要：如果我們朝著我們討論過的一些方向發展，例如 APS，在我們研究的一些設計中，你可以實際將證明者和提案者分開，我們需要在此之前引入 FOCIL，並且我們需要知道 FOCIL 是有效運作的。我們需要 FOCIL 在主網上運行六個月、一年，以真正確定它正在實現其目的，也就是維持並改善以太坊的抗審查特性。因此，至少對我來說，另一個急迫性是，如果我們想保護證明者免受時間博弈以及我們希望透過 APS 解決的其他問題的影響，我們需要盡快引入 FOCIL。

Pooja Ranjan: 有時候看到提案沒有被選入下一次或最近的升級中會令人感到遺憾，但一次升級只能包含有限數量的提案。我非常感謝在提出提案、準備提案以及進行測試背後所付出的所有辛勤工作。非常感謝你們為以太坊生態系統所做的一切努力。

快問快答 (55:18)

Pooja Ranjan: 在我們結束之前，我們有一個簡短的快問快答環節。唯一的條件是答案必須是一個詞或一句話，我們會盡量計時，每題大約 30 秒。如果你們準備好了，我們就從 Julian 開始。目前區塊鏈研究中最困難的問題是什麼？

Julian Ma: 我不會太愛玩梗（meme-y），所以我會認真回答。我認為最困難的問題是質押的未來：質押的未來意味著什麼、哪些服務提供者扮演什麼角色、他們如何獲得報酬，以及他們之間的關係。

Pooja Ranjan: 有哪個區塊鏈使用案例還沒有被充分探索？

Julian Ma: 我會說是 FOCIL。

Pooja Ranjan: 今天以太坊面臨的最大安全風險是什麼？

Julian Ma: 老實說，我認為抗審查性在這裡非常關鍵，因為像多區塊 MEV 這樣的事情可能會帶來巨大的安全風險，例如對第二層 (L2) 而言。

Pooja Ranjan: MEV 應該被最小化、被接受，還是介於兩者之間？

Julian Ma: 我在很大程度上同意 Flashbots 的觀點，即它應該被民主化，這意味著在必要的地方應該將其最大化，而在應用層則將其最小化。

Pooja Ranjan: 去中心化總是值得我們做出權衡嗎？

Julian Ma: 通常是值得的。

Pooja Ranjan: 以太坊為世界帶來的最大創新是什麼？

Julian Ma: 在這裡我想引用 Mike Neuder 在 Devcon 上關於數位財產權的演講。我會說是抗審查的數位財產權，這真的正在改變世界。

Pooja Ranjan: 非常感謝，回答得很好。我的下一組問題是給 Thomas 的。那麼，如果以太坊不存在，你會在哪個區塊鏈上工作？

Thomas Thiery: 我想我會非常愛玩梗，而且 Julian 稍微坑了我一下（rugged me），因為我以為他也會這麼做。這個區塊鏈會是 FOCIL。

Pooja Ranjan: 區塊鏈最被過度炒作的使用案例是什麼？

Thomas Thiery: 沒有 FOCIL，任何使用案例都不值得炒作。

Pooja Ranjan: 以太坊需要盡快改進的一件事是什麼？

Thomas Thiery: 透過 FOCIL 實現抗審查性。

Pooja Ranjan: 用一個詞來形容去中心化？

Thomas Thiery: FOCIL。

Pooja Ranjan: 你認為以太坊能完全解決可擴展性問題嗎？

Thomas Thiery: 擁有 FOCIL 的以太坊，可以。

Pooja Ranjan: 第一層 (L1) 擴展還是第二層 (L2) 擴展，哪個會贏？

Thomas Thiery: 無限層，全部都帶有 FOCIL。

Pooja Ranjan: 做得非常好，非常感謝你，Thomas。感謝你回答所有這些問題。在我們即將結束之際，我想把這個機會交給你們：關於這個提案，或者對整個以太坊社群，你們有什麼想對社群說的話嗎？

給社群的訊息 (58:08)

湯瑪斯·提耶里： 實際上，這是非常重要的一點，因為我們一直都有活躍的討論，而且全都在 Discord 上公開進行。一開始有人推動將這一切公開，而大家也確實這麼做了，所以我非常高興。你可以在公開的 Eth R&D Discord 上的 inclusion-list 頻道中，關注討論與進度。這基本上就是目前所有事情發生的主要地點。然後你可以在推特、Telegram 或任何地方聯絡我們。請隨時與我們聯繫。

我們與越多人交流並讓他們參與其中，設計就會越好，實作也會越完善。因此，如果你能在任何方面提供協助，請聯絡我們，我們很樂意在各方面提供幫助，甚至在研究方面也是如此。我想，這甚至更適合我們與那些想為 FOCIL 的未來努力的人合作。我們提到了隱私，我們提到了交易手續費機制，我們也將把重點放在針對資料塊的 FOCIL 上。所有這些事情都需要人力與研究心力。如果你感興趣，請聯絡我們。非常感謝你們邀請我們，也感謝你們為以太坊所做的一切努力。

朱利安·馬： 補充一點，我希望我們能讓一些人對 FOCIL 充滿熱情。如果你充滿熱忱，請告訴我們。如果你還有一些疑問，我們很樂意為你解答，並希望能說服你 FOCIL 確實是未來的發展方向。非常感謝。很高興能來到這裡，感謝你們主持這場會議。當然，也感謝所有參與的人。

結語 (59:52)

Pooja Ranjan： 謝謝大家。今天的節目就到此結束。非常感謝 Thomas 和 Julian 今天加入我們，並分享他們對 EIP-7805 的見解。感謝所有參與者；你們的問題非常令人鼓舞且資訊豐富。感謝您的收看。如果您喜歡這次的對話，請務必按讚、訂閱，並與您的以太坊愛好者朋友們分享這一集。我們將在 PEEPanEIP 上為您帶來更多 EIP 與研究進展。我們下次見，請繼續帶著知識發出呼嚕聲，並與 Ethereum Cat Herders 一起在以太坊中探索。祝您有美好的一天。