Vitalik：以太坊應該要將哪些功能固化到協議層

作者：Vitalik，以太坊創辦人；翻譯：金色財經0xjs

以太坊專案一開始，就存在著一種強烈的理念，即盡量使以太坊核心盡可能簡單，並透過在其上建立協議來完成盡可能多的工作。在區塊鏈領域，「在L1上執行」與「專注於L2」之爭通常被認為主要涉及擴展，但實際上，類似的問題存在於為許多以太坊用戶需求提供服務的情況下：數字資產交換、隱私、使用者名稱、進階密碼、帳戶安全、抗審查、搶跑保護等等。然而，最近一些人對謹慎將更多這些功能正式寫入以太坊核心協議的興趣正在增加。

本文將探討早期的以太坊協議最小化理念背後的一些哲學推理，以及我對這些想法的更近期的看法。目標是逐漸建立一個更好地識別在協議中形成某些功能可能值得考慮的目標的框架。

早期的協議最小化哲學

在「以太坊2.0」（當時稱為）歷史的早期，有一種強烈的願望，即創建一個乾淨、簡單且美觀的協議，盡量少地完成自己的工作，幾乎一切都留給用戶在其上構建。理想情況下，該協議將只是一個虛擬機，驗證一個區塊只需調用一次虛擬機。

2015年初，我和Gavin Wood製作的一個白板圖的非常粗略的重建，當時我們討論了以太坊2.0將會是什麼樣子。

「狀態轉換函數」（處理區塊的函數）將只是一個虛擬機器調用，所有其他邏輯都將透過合約實現：一些系統層級的合約，但主要是用戶提供的合約。這個模型的一個非常好的特性是，即使整個硬分叉也可以描述為對區塊處理合約的單一交易，該交易將透過鏈下或鏈上治理獲得批准，然後以升級的權限運行。

這些2015年的討論特別適用於我們關心的兩個領域：帳戶抽象和擴充。在擴容的情況下，想法是嘗試創造一種最大程度抽象的擴容形式，使其感覺像是上述圖表的自然延伸。合約可以調用大多數以太坊節點未儲存的某些數據，協議將檢測到這一點，並透過某種非常通用的擴容運算功能解決該呼叫。從虛擬機器的角度來看，呼叫將進入某個單獨的子系統，然後在一段時間後以正確的答案神奇地返回。

這種思考方式曾經短暫地被探討過，但很快就被放棄，因為我們過於專注於驗證任何形式的區塊鏈擴容是否可能。然而，正如我們後來將看到的，數據可用性採樣和ZK-EVM的結合意味著以太坊擴容的一個可能未來實際上可能看起來令人驚訝地接近這個願景！對於帳戶抽象，另一方面，我們從一開始就知道某種實現是可能的，因此立即開始研究如何使「交易只是呼叫」的純粹起點盡可能接近現實。

在這裡，存在著許多在處理交易並使發送地址的底層EVM呼叫之前的程式碼之間以及之後發生的程式碼。我們如何將此程式碼減少到盡可能接近零的程度？

其中一段程式碼中的一項主要工作是validate_transaction(state, tx)，其中包括檢查交易的nonce和簽名是否正確。帳戶抽象的實際目標從一開始就是允許用戶用自己的驗證邏輯替換基本的nonce遞增和ECDSA驗證，以便用戶更容易使用諸如社交恢復和多重簽名錢包之類的東西。因此，重塑apply_transaction，使其成為簡單的EVM調用，不僅僅是為了「使程式碼乾淨而使程式碼乾淨」的任務；相反，它是為了將邏輯移動到用戶的帳戶程式碼中，以給予需要靈活性的用戶。

然而，對盡量使apply_transaction包含盡可能少的正式邏輯的堅持最終引入了許多挑戰。為了了解原因，讓我們深入研究早期的帳戶抽象提案之一，即EIP 86：

規範

如果block.number >= METROPOLIS_FORK_BLKNUM，則：1、如果交易的簽名為(0, 0, 0)（即v = r = s = 0），則將其視為有效，並將寄件者地址設為2 ** 160 – 1。2、將透過建立交易創建的任何合約的地址設定為sha3(0 +初始化代碼)％2 ** 160，其中+表示連接，替換先前的地址公式sha3(rlp.encode([sender, nonce]))3、建立一個新的opcode，為0xfb，CREATE_P2SH，該opcode將創建地址設為sha3(sender + init code)％2 ** 160。如果該位址處已經存在合約，則失敗並傳回0，就像初始化程式碼用盡了Gas一樣。

基本上，如果將簽名設為(0, 0, 0)，那麼交易實際上就變成了「只是一個呼叫」。帳戶本身將負責具有解析交易、提取和驗證簽名和nonce以及支付費用的代碼，點擊此處查看此代碼的早期版本，點擊此處查看此帳戶代碼將要替換的validate_transaction代碼，一度簡單地將apply_transaction縮減為僅是一個EVM調用的過程。換句話說，以太坊的協議會執行交易驗證，將具體的交易邏輯留給用戶自己的帳戶代碼，以提供彈性。

然而，嘗試使apply_transaction包含盡可能少的正式邏輯最終引入了許多挑戰。要了解為什麼，讓我們詳細查看早期的帳戶抽象提案之一，即EIP 86。

請注意，礦工需要製定一種接受這些交易的策略。這種策略需要非常具有辨別力，否則他們可能會接受不支付任何費用的交易（對於將被替換為預賬戶代碼的validate_transaction代碼），甚至可能是沒有效果的交易（例如，因為交易已經被包含，所以nonce不再有效）。一個簡單的方法是對它們接受交易發送到的帳戶代碼的codehash設定白名單；經過批准的代碼將包括支付礦工交易費用的邏輯。然而，這可能過於限制；一種更寬鬆但仍然有效的策略是接受任何符合上述相同一般格式的代碼，僅消耗有限數量的gas執行nonce和簽名檢查，並保證交易費用將支付給礦工。另一種策略是在其他方法之外，嘗試處理任何請求少於250,000 gas的交易，並僅在執行交易後礦工的餘額適當地增加時包含它。

如果EIP-86按原樣被納入，它將減少EVM的複雜性，但以極大的代價增加以太坊堆疊的其他部分的複雜性，要求基本上在其他地方編寫完全相同的程式碼，同時引入了完全新的奇怪可能性，例如相同的交易具有相同的哈希可能會多次出現在鏈上，更不用說多次失效問題了。

帳戶抽像中的多次失效問題。鏈上包含的一個交易可能會使記憶體池中的數千個其他交易失效，使記憶體池易於被廉價地淹沒。

帳戶抽像是從那裡逐漸演變的。 EIP-86成為EIP-208，後來成為ethresear.ch上關於「帳戶抽象提案中的權衡」的帖子，然後在半年後成為ethresear.ch上的這篇帖子。最終，這一切產生了實際上相當可行的EIP-2938。

然而，EIP-2938並不是最小化的。該EIP包括：

• 一個新的交易類型

• 三個新的交易範圍全域變數

• 兩個新的操作碼，包括非常笨重的PAYGAS操作碼，處理gas價格和gas限制檢查，作為EVM執行斷點，並同時暫時儲存ETH以用於費用支付。

• 一套複雜的挖礦和重播策略，包括驗證交易的階段的一系列禁止的操作碼

為了在不牽涉到正在忙於優化以太坊客戶端並實施合併的以太坊核心開發人員的情況下推動帳戶抽象，EIP-2938最終被重新設計為完全協議外的ERC-4337。

ERC-4337。它確實完全依賴EVM 調用來完成所有事情！

因為它是一個ERC，它不需要硬分叉，從技術上講「在以太坊協議之外」。所以…問題解決了嗎？嗯，事實證明，還沒有完全解決。 ERC-4337的當前中期路線圖實際上涉及最終將ERC-4337的大部分內容轉變為一系列協議功能，這是一個有用的示例，可以了解為什麼正在考慮採用這種路徑的原因。

協議層固化ERC-4337

對於最終將ERC-4337引入協議中，已經討論了一些關鍵原因：

• Gas效率：在EVM內部執行的任何操作都會產生一定程度的虛擬機器開銷，包括在使用諸如儲存槽等昂貴的gas功能時的效率低下。目前，這些額外的低效性至少會增加到~20,000 gas，而且通常更多。將這些元件推入協定中是消除這些問題最簡單的方法。

• 代碼錯誤風險：如果ERC-4337的「entry point合約」有足夠可怕的錯誤，所有相容ERC-4337的錢包可能會看到其所有資金被清空。透過將合約替換為協議功能，可以建立修復程式碼錯誤的隱含責任，並消除用戶資金風險。

• 支援EVM操作碼，如tx.origin。 ERC-4337本身就使tx.origin傳回將一組使用者操作打包成交易的「捆綁程式」所發送的位址。原生帳戶抽象化可以透過使tx.origin指向實際發送交易的帳戶來解決此問題，使其與EOA的工作方式相同。

• 抗審查：在PBS的情況下，一個挑戰是更容易審查個別交易。在每個交易對以太坊協議可見的世界中，透過包含清單（ inclusion lists），可以大大減輕此問題，該清單允許提議者在幾乎所有情況下指定必須在接下來的兩個插槽中包含的交易列表。但是，協議外ERC-4337將「用戶操作」包裝在單一交易內，使用戶操作對以太坊協議不可見；因此，以太坊協議提供的包含清單將無法為ERC-4337用戶操作提供抗審查性。正式化ERC-4337並將使用者操作作為「正式」交易類型將解決此問題。

值得進一步深入研究gas效率問題。在其當前形式中，ERC-4337比「基本」以太坊交易顯著更昂貴：交易成本為21,000 gas，而ERC-4337成本約為42,000 gas。該文件列出了其中一些原因：

• 需要支付許多單獨的儲存讀取/寫入成本，對於EOA而言，這些成本被捆綁成單一21000 gas的支付：

• 編輯包含pubkey+nonce的儲存槽（〜5000）

• UserOperation calldata成本（〜4500，透過壓縮可減少到〜2500）

• ECRECOVER（〜3000）

• 預熱錢包本身（〜2600）

• 預熱接收方帳戶（〜2600）

• 將ETH轉移到接收方帳戶（〜9000）

• 編輯儲存以支付費用（〜5000）

• 存取包含代理程式的儲存槽（〜2100），然後是代理本身（〜2600）

• 除了上述儲存讀取/寫入成本之外，合約還需要執行「業務邏輯」（解壓縮UserOperation，對其進行哈希處理，洗牌變數等），而EOA交易則由以太坊協議「免費」處理。

• 需要花費瓦斯來支付日誌費用（EOA不發出日誌）

• 一次性合約建立成本（基礎成本為〜32000，代理程式中的程式碼每位元組增加200個gas，加上設定代理位址的20000 gas）

理論上，應該可以透過操縱EVM gas成本系統，使協議內成本和額外協議成本的儲存存取匹配；轉移ETH為何需要花費9000 gas，而其他儲存編輯操作要便宜得多，沒有理由。事實上，與即將推出的Verkle樹過渡相關的兩個EIP 實際上嘗試做到這一點。但即使我們這樣做，有一個巨大的原因導致正式協議特性不可避免地會比EVM程式碼便宜得多，無論EVM變得多麼有效率：正式化的程式碼不需要為預先載入而支付gas。

完全功能的ERC-4337錢包很大。此實現，編譯並放在鏈上，佔用約12800位元組。當然，你可以部署該龐大的程式碼一次，並使用DELEGATECALL允許每個單獨的錢包呼叫它，但程式碼仍然需要在每個使用它的區塊中存取。根據即將推出的Verkle樹gas成本EIP，12800位元組將佔據413個chunk，存取這些chunk將需要支付2x WITNESS_BRANCH_COST（3,800 gas總計）和413x WITNESS_CHUNK_COST（82,600 gas總計）。這甚至沒有提及ERC-4337入口點本身，版本0.6.0中在鏈上有23689位元組（根據Verkle樹EIP規則，載入需要~158700 gas）。

這導致了一個問題：實際上存取此代碼的gas成本必須以某種方式在交易之間分配。 ERC-4337目前使用的方法不太好：捆綁中的第一筆交易吸收了一次性儲存/代碼讀取成本，使其比其餘交易顯然更昂貴。在協議中使這些常用的共享庫成為協議的一部分，可供所有人訪問而無需支付費用，是解決此問題的方法。

關於何時更普遍地固化進協議，我們可以從這個例子中學到什麼？

在這個例子中，我們可以學到一些有關何時總結事物的更普遍原則的經驗。

• 將複雜性移到邊緣是個好主意，尤其是當存在高固化成本時。這在「去中心化帳戶抽象」路線圖中變得明顯，因為加載標準化錢包代碼需要244,100 gas，而聚合（查看我今年夏天的演講以獲取更多細節）可能需要數十萬gas進行ZK-SNARK驗證，再加上證明驗證的鏈上成本。對用戶付出這些成本幾乎是不可能的，因為這會引入許多市場效率低下的問題，而將某些功能作為協議功能，無需費用地為所有用戶提供訪問，可以清晰地解決這個問題。

• 社區對程式碼錯誤的共同回應。如果一組程式碼片段被所有用戶或廣泛的用戶類使用，通常更合理的做法是由區塊鏈社群承擔透過硬分叉修復可能出現的錯誤的責任。 ERC-4337引入了大量的全球共享程式碼，從長遠來看，修復程式碼中的錯誤最好透過硬分叉，而不是導致用戶損失大量ETH。

• 有時，直接利用協議的權力可以實現更強大形式的功能。例如，協議內的審查制度可以更好地保證抗審查，而使用戶級操作真正從協議中受益，個體用戶級操作需要對協議「可讀」。另一個較少為人所知的例子是2017年的以太坊權益證明設計具有權威抽象的權威，而這被放棄，採用BLS進行總結，因為BLS支持“聚合”機制，必須在協議和網絡級別實施，可以使處理大量簽章更加有效率。

但是重要的是要記住，即使在協議中確立的帳戶抽象，相對於現狀仍然是一種巨大的「反確立」。今天，以太坊的頂層交易只能由外部擁有帳戶（EOA）發起，這些帳戶使用單一secp256k1橢圓曲線簽名進行驗證。帳戶抽象反映了這一點，並且為使用者定義驗證條件提供了開放性。因此，在這個關於帳戶抽象的故事中，我們也看到了反對封存的最大論點：滿足不同使用者需求的彈性。

讓我們嘗試透過查看最近考慮確立的一些功能來進一步完善這個故事。我們將特別關注：ZK-EVMs、提議者-建構者分離、私有mempools、流動權益和新的預編譯。

固化ZK-EVMs

讓我們把注意力轉向以太坊協議中另一個可能的確立目標：ZK-EVMs。目前，我們有大量ZK-rollup，它們都必須編寫相當相似的程式碼來驗證ZK-SNARK中執行類似以太坊的區塊。有一個相當多樣化的獨立實現生態系統：PSE ZK-EVM、Kakarot、Polygon ZK-EVM、Linea、Zeth等等。

在EVM ZK-rollup領域的最近爭議之一涉及如何處理ZK程式碼中存在錯誤的可能性。目前，所有正在運行的系統都有某種形式的「安全理事會」機制，可以在發生錯誤時覆蓋證明系統。在去年的一篇文章中，我嘗試創建一個標準化框架，以鼓勵計畫明確他們在證明系統和安全理事會之間的信任級別，並朝著隨時間減少對安全理事會的權力的方向發展。

中期來看，rollups可以依賴多個證明系統，而安全理事會在兩個不同的證明系統彼此不同意的極端情況下才會有任何權力。

然而，有一種感覺，覺得有些工作是多餘的。我們已經有了以太坊基礎層，其中有一個EVM，而且我們已經有了處理實作中的錯誤的工作機制：如果有錯誤，具有錯誤的客戶端將更新以修復錯誤，鏈將繼續進行。從有錯誤的客戶端的角度來看，從以太坊社群的多個實現和鏈下社會共識的角度來看，區塊似乎最終確定了，但至少我們不會看到用戶失去資金。同樣，如果一個rollup只想成為並保持等同於EVM，那麼當他們內部的ZK-EVM規則需要匹配以太坊基礎層的升級時，他們不應該實現自己的治理，而應該直接構建在以太坊基礎層上，這一層基礎層知道何時進行升級以及升級到什麼新規則。

由於這些L2 ZK-EVM基本上使用與以太坊相同的EVM，我們不能以某種方式將「在ZK中驗證EVM執行」變成協議功能嗎？在出現錯誤和升級的情況下，我們是否可以透過應用以太坊的社交共識，與我們已經為基礎層EVM執行本身所做的一樣，來處理這個問題？

這是一個重要而具挑戰性的主題。有一些微妙之處：

1.我們希望與以太坊的多客戶端哲學保持相容。這意味著我們要允許不同的客戶端使用不同的證明系統。這反過來意味著對於任何使用一個ZK-SNARK系統進行證明的EVM執行，我們希望確保底層資料可用，以便可以為其他ZK-SNARK系統產生證明。

2、雖然技術還不成熟，我們可能希望進行審計。實際上，這意味著完全相同的事情：如果任何執行得到證明，我們希望底層資料可用，以便如果出現問題，使用者和開發人員可以檢查它。

3、我們需要更快的證明時間，以便如果生成了一種證明，其他類型的證明可以迅速生成，以便其他客戶可以驗證它們。可以透過建立在某個時間視窗內（例如3小時）之後具有非同步回應的預編譯來解決此問題，但這會增加複雜性。

4、我們希望不僅支援EVM的副本，還支援「幾乎-EVMs」。在執行層面進行創新並對EVM進行擴展是L2的吸引力的一部分。如果給定L2的VM與EVM只有很小的不同，那麼如果L2的VM在與EVM相同的部分使用本地的協定ZK-EVM，而僅依賴自己的程式碼來處理不同的部分，這將是很好的。這可以透過設計ZK-EVM預先編譯，以使其允許呼叫者指定由外部提供的表處理的一組操作碼或位址的位元字段或列表，而不是EVM本身。我們也可以在有限程度上使gas成本可自訂。

在使用原生ZK-EVM時，與資料可用性的一個可能的爭議主題是狀態性。如果ZK-EVMs無需攜帶「見證」數據，它們將更加數據高效。也就是說，如果在某個先前區塊中已讀取或寫入了特定數據，我們可以簡單地假設證明者可以存取它，我們不必再次提供。這不僅限於不重新加載存儲和代碼；事實證明，如果一個rollup正確地壓縮數據，使壓縮是有狀態的，相比於無狀態的壓縮，這將節省多達3倍的數據。

這意味著對於ZK-EVM預編譯，我們有兩個選擇：

1.預編譯要求所有資料在同一個區塊中可用。這意味著證明者可以是無狀態的，但也意味著使用這樣的預編譯的ZK-rollup比使用自訂程式碼的rollup更昂貴。

2、預編譯允許指向先前執行中使用或產生的資料的指標。這允許ZK-rollup幾乎是最優的，但這更加複雜，並引入了必須由證明者儲存的新類型狀態。

從這中我們可以學到什麼教訓？有一個相當好的爭論，可以以某種方式確立ZK-EVM驗證：rollup已經在構建自己的自定義版本了，而且感覺不對的是以太坊願意將其多個實現和鏈下社交共識的重量放在L1上的EVM執行後，而做完全相同的工作的L2卻必須實現涉及安全理事會的複雜小工具。但另一方面，細節中存在著一個大的麻煩：有不同版本的確立的ZK-EVM，具有不同的成本和收益。有狀態與無狀態只是冰山一角；嘗試支援具有其他系統證明的自訂程式碼的「幾乎-EVMs」可能會顯示出更大的設計空間。因此，確立ZK-EVMs既有希望也有挑戰。

固化提案者-建構者分離（ePBS）

MEV的崛起使區塊生產成為一項規模經濟活動，精明的參與者能夠產生比預設演算法更多收入的區塊，這些演算法只是監視記憶體池中的交易並包括它們。以太坊社區迄今嘗試透過使用類似MEV-Boost的協議外的提議者-構建者分離方案來處理這個問題，該方案允許常規驗證者（「提議者」）將區塊構建外包給專門的參與者（ 「建構者」）。

然而，MEV-Boost對一個新類別的參與者，稱為中繼，提出了信任假設。在過去的兩年裡，有許多提案創建「固化PBS」。這樣做的好處是什麼？在這種情況下，答案非常簡單：透過直接使用協議的權力建構的PBS在信任假設方面更強大（以信任假設較弱的意義而言），而不是在沒有它們的情況下建構的PBS。這與協議中確立價格預言機的情況類似，儘管在那種情況下，還有一個強有力的反論。

確立私有記憶體池

當用戶發送交易時，該交易立即變為公共並對所有人可見，即使在被包含在鏈上之前也是如此。這使得許多應用程式的用戶容易受到經濟攻擊，例如搶跑：如果用戶在Uniswap上進行大額交易，攻擊者可能會在他們之前放入一個交易，增加他們購買的價格，並收取套匯利潤。

最近，有一些專門創建「私人記憶體池」（或「加密記憶體池」）的項目，這些記憶體池使用戶的交易在被不可逆地接受到區塊之前一直保持加密狀態。

然而，這種方案需要一種特定類型的加密：為了防止用戶淹沒系統並在交易實際上被不可逆地接受時進行前運行解密過程本身，必須使加密能夠在交易實際上被不可逆地接受時自動解密。

要實施這種形式的加密，有各種不同的技術，具有不同的權衡，由Jon Charbonneau在一篇文章（以及這個影片和幻燈片中）中很好地描述：

• 加密到中心化運營商，例如Flashbots Protect。

• 時間鎖加密，一種可以在一定數量的順序計算步驟之後由任何人解密的加密形式，這不能被並行化。

• 閾值加密，信任大多數委員會以解密資料。請參閱shutterized信標鏈概念，以取得一個具體的提案。

• 受信任的硬件，如SGX。

不幸的是，這些都具有各種不同的弱點。出於明顯的原因，中心運營商不可接受用於包含在協議中。傳統的時間鎖加密運行成千上萬的交易的公共記憶體池太昂貴。一種更強大的稱為延遲加密的原語允許在一定數量的消息上進行有效解密，但在實踐中構建它很難，現有構建的攻擊有時仍然會被發現。與雜湊函數一樣，我們可能需要進行更多年的研究和分析，然後延遲加密才能足夠成熟。閾值加密要求信任大多數委員會不串通，在可以不可檢測地串通的設置中（不同於51％的攻擊，其中立即可以知道誰參與了），這是不可接受的。 SGX為單一受信任製造商引入了一個依賴性。

儘管對於每種解決方案，都有一些使用者子集願意信任它，但目前尚無一種解決方案足夠值得信賴，可以實際上被接受到第1層。因此，在至少等到/除非延遲加密技術得到改進或有其他技術突破之前，將搶跑納入第1層看起來是一個困難的建議，即使它是一個非常有價值的功能，許多應用解決方案已經出現。

固化流動抵押

以太坊DeFi用戶的一個共同需求是能夠將他們的ETH同時用於抵押和在其他應用程式中作為抵押品。另一個常見的需求只是為了方便：用戶希望能夠在不運行節點並且始終在線的複雜性的情況下抵押，（以及保護他們現在在線的抵押密鑰）。

到目前為止，滿足這兩種需求的最簡單的質押“界面”就是一個ERC20 代幣：將你的ETH 轉換為“質押的ETH”，持有它，然後再轉換回來。事實上，像Lido和Rocketpool這樣的流動性質押提供商已經出現來做到這一點。然而，流動性質押有一些自然的中心化機制在發揮作用：人們自然而然地進入最大版本的質押ETH，因為它是最熟悉和最具流動性的（並且得到應用程序的最良好支持，而應用程序反過來又支持它，因為它更熟悉，因為它是大多數用戶都聽說過的一種）。

每個版本的質押ETH都需要有一個機制來確定誰可以成為基礎節點運營商。它不能是不受限制的，因為攻擊者將加入並用用戶的資金放大他們的攻擊。目前，排名前兩位的是Lido，它有一個DAO白名單節點運營商，並且Rocket Pool，它允許任何人在放下8 ETH（即1/4的資本）作為存款的情況下運行節點。這兩種方法都有不同的風險：Rocket Pool方法允許攻擊者發動51%攻擊網絡，並迫使使用者支付大部分成本。透過DAO方法，如果一個單一的質押代幣占主導地位，那將導致一個單一的，潛在的可攻擊的治理小工具控制所有以太坊驗證者的很大一部分。對於諸如Lido的協議，他們已經實施了防範措施，但一層防禦可能不夠。

在短期內，一種選擇是社會上鼓勵生態系統參與者使用多樣化的流動抵押貸款提供者，以減少任何一個變得過大以至於成為系統風險的機會。然而，從長遠來看，這是一個不穩定的平衡，過度依賴道德壓力來解決問題也存在危險。一個自然的問題出現了：是否有意義在協議中固化某種功能以減少流動抵押的集中？

在這裡，關鍵問題是：固化哪種協定功能？僅創建一個協議中的可替換“抵押ETH”代幣的問題是，它要么必須具有固化的以太坊全球治理來選擇誰運行節點，要么是開放的，將其變成攻擊者的工具。

一個有趣的想法是Dankrad Feist關於流動性抵押極端主義的文章。首先，我們得接受的事實是，如果以太坊遭到51%攻擊，只有可能有5%的攻擊ETH會被懲罰。這是一個合理的權衡；現在有超過2600萬ETH被抵押，而攻擊成本的1/3（約800萬ETH）完全過剩，特別是考慮到有多少種用更少成本實施的「超出模型」攻擊。實際上，類似的權衡已經在「超級委員會」提案中探討過，該提案用於實施單插槽最終確定性。

如果我們接受只有5%的攻擊ETH會被罰沒，那麼超過90%的抵押ETH將免受罰沒，因此90%的抵押ETH可以放入一個協議中的可替換的流動抵押代幣中，然後可以被其他應用程式使用。

這條道路很有趣。但它仍然留下一個問題：什麼是具體的東西會被固化？ Rocket Pool的運作方式與此非常相似：每個節點業者都要投入一些資本，而流動抵押者則投入其餘的資本。我們可以簡單地調整一些常數，將最大的懲罰限制為2 ETH，Rocket Pool現有的rETH將變成無風險。

透過簡單的協議調整，我們可以做一些聰明的事情。例如，想像我們想要一個系統，其中有兩個「層次」抵押：節點運營商（高抵押品要求）和存款人（沒有最低要求，可以隨時加入和退出），但我們仍然想要透過給存款人的隨機抽樣委員會授予權力，如建議必須包括的交易清單（出於反審查原因）、在不活動洩漏期間控制分叉選擇，或需要簽署區塊。這可以透過在協定中調整每個驗證者必須提供（i）一個常規抵押金鑰和（ii）每個插槽都可以呼叫以輸出次要抵押金鑰的ETH位址的機制。協定將授予這兩個金鑰權力，但每個插槽中選擇第二個金鑰的機制可能留給抵押池協定。直接固化某些東西可能仍然是更好的選擇，但值得注意的是這種「固化某些東西，將其他東西留給使用者」的設計空間是存在的。

固化更多的預編譯

預編譯（或稱「預編譯合約」）是以太坊合約，實現了在客戶端程式碼中原生實現的複雜的加密操作，而不是在EVM智能合約程式碼中。預編譯是以太坊發展初期採用的一種妥協：由於VM的開銷對於某些類型的非常複雜和高度專業化的程式碼來說太大，我們可以在原生程式碼中實現一些對於重要類型的應用程式有價值的關鍵操作，以使它們更快。今天，這基本上包括了一些特定的雜湊函數和橢圓曲線操作。

目前正在推動添加secp256r1的預編譯，這是一個與用於基本以太坊帳戶的secp256k1稍有不同的橢圓曲線，因為它得到了受信任的硬體模組的廣泛支持，因此廣泛使用它可能會提高錢包安全性。近年來，還有推動添加BLS-12-377、BW6-761、廣義配對等功能的預編譯的努力。

對於增加更多預編譯的這些請求的反駁是，以前添加的許多預編譯（例如RIPEMD和BLAKE）最終被使用得比預期的要少，我們應該從中吸取教訓。與其為特定的操作添加更多的預編譯，我們可能應該專注於基於EVM-MAX和休眠但始終可喚醒的SIMD提案之類的想法的更溫和的方法，這將允許EVM實現更便宜地執行廣泛類別的代碼。甚至可能刪除並用相同功能的EVM程式碼實現替換現有但很少使用的預編譯。也就是說，仍然可能存在一些特定的加密操作非常有價值以加速，從而有理由將它們作為預編譯添加。

從所有這些我們可以學到什麼？

希望盡量少固化是可以理解和好的；它源自於Unix哲學傳統，即創建最小化的軟體，使用者可以輕鬆地透過其使用者進行不同的需求適應，避免軟體膨脹的詛咒。然而，區塊鏈不是個人運算作業系統；它們是社會系統。這意味著存在將某些功能在協​​議中固化的原因，這些原因超出了純粹的我個人考慮的上述原因。

在許多情況下，這些其他例子重新介紹了在帳戶抽像中看到的相似的教訓。但也有一些新的教訓已經學到：

• 在堆疊的其他區域幫助避免中心化風險。通常，保持基礎協議簡單和簡單將複雜性推到協議之外的生態系統。從Unix哲學的角度來看，這是好的。然而，有時，協議之外的生態系統的風險是它可能會中心化，通常（但不僅）是由於高固定成本。固化有時可能會減少實際上的中心化。

• 過多固化會過度增加協議的信任和治理負擔。這是有關“不要讓以太坊共識過載”（請參閱金色財經先前翻譯文章）的早期文章的主題：如果固化了某個特定功能會削弱信任模型，並使以太坊整體變得更加“主觀”，從而削弱了以太坊的可信中立性。在這些情況下，最好將該特定功能保留為以太坊之上的機制，而不要嘗試將其帶入以太坊本身。在這裡，加密記憶體池是可能過於難以固化的最好的例子，至少在/除非延遲加密技術改進。

• 過多固化會過於複雜化協議。協議複雜性是系統風險，過多地在協議中添加功能會增加該風險。預編譯是這一點的最佳例子。

• 固化可能會在長期內適得其反，因為用戶的需求是不可預測的。許多人認為重要並將被許多用戶使用的功能實際上可能在實踐中使用得不多。

此外，流動性抵押、ZK-EVM和預編譯案例顯示了一種中庸的可能性：最小可行的固化。與其固化整個功能，不如固化解決實現該功能的關鍵挑戰的特定部分，而不過於主觀或狹隘。這包括：

• 與其固化整個流動性抵押系統，不如更改懲罰規則以使無信任的流動性抵押更為可行。

• 與其固化更多的預編譯，不如固化EVM-MAX和/或SIMD以使更寬類別的操作更簡單地有效實施。

• 與其固化Rollups的整個概念，我們可以簡單地固化EVM驗證。

我們可以將本文前面的圖表擴展如下：

有時甚至可能有道理去除一些東西的固化。去除很少使用的預編譯就是一個例子。作為前向相容現有用戶的支持，該機制實際上可能與去除預編譯的機制驚人地相似：其中之一是EIP-5003，它將允許EOA將其帳戶就地轉換為具有相同（或更好）功能的合約。

應該將哪些功能帶入協議，哪些功能留給生態系統的其他層面是一種複雜的權衡，並且我們應該期望這種權衡隨著我們對用戶需求的理解以及我們的可用思想和技術套件的不斷改進而隨時間演變。