上週，Vitalik Buterin 發表一篇有關「封裝功能」的文章，講述其中的利與弊。本文源自 Vitalik Buterin 所著文章 《Should Ethereum be okay with enshrining more things in the protocol?》，由 Odaily星球日報 編譯、整理。
（前情提要：V神警告：流動性質押池以 DAO 治理節點營運商，恐構成「系統性風險」！ ）
（背景補充：V神開炮CBDC發展：犧牲用戶隱私是錯誤，淪為傳統銀行前端 ）
從以太坊專案開始，就有一個強烈的理念，即試圖使核心以太坊儘可能簡單，並通過在其上構建協議來儘可能實現這一點。
在區塊鏈領域，「在 L1 上構建」 與 「專注於 L2」 的爭論通常被認為主要是關於擴容的，但實際上，在滿足多種以太坊使用者的需求方面存在類似的問題：數位資產交換、隱私、使用者名稱、高階加密、帳戶安全、抗審查、搶先交易保護，等等。然而，最近有一些謹慎的想法願意將更多這些功能封裝（enshrine）進核心以太坊協議中。
這篇文章將深入探討最初的最小封裝哲學背後的一些哲學推理，以及一些最近思考這些想法的方法。目標將是開始建立一個框架，以便更好地確定可能的目標，在這些目標中，封裝某些功能可能值得考慮。
關於協議極簡主義的早期哲學
在當時被稱為 「以太坊 2.0」 的早期歷史中，人們強烈希望建立一個乾淨，簡單和美觀的協議，該協議儘可能少地嘗試通過自身來構建，並將幾乎所有這類工作都留給使用者。理想情況下，協議只是一個虛擬機器，而驗證一個區塊只是一個虛擬機器呼叫。
「狀態轉換函式」（處理區塊的函式）將只是單個 VM 呼叫，所有其他邏輯將通過合約發生：一些系統級合約，但主要是由使用者提供的合約。這個模型的一個非常好的功能是，即使是整個硬分叉也可以被描述為對於區塊處理器合約而言的單筆交易，該交易將通過鏈下或鏈上治理進行批准，然後以升級的許可權執行。
2015 年的這些討論特別適用於我們考慮的兩個領域： 帳戶抽象和擴容 。在擴容的情況下，我們的想法是嘗試建立一個最大程度的抽象形式的擴容，感覺就像上面圖表的自然擴容。
合約可以呼叫大多數以太坊節點未儲存的資料，協議將檢測到這一點，並通過某種非常通用的擴容計算功能來解決呼叫。從虛擬機器的角度來看，該呼叫將進入某個單獨的子系統，然後一段時間後神奇地返回正確的答案。
延伸閱讀：條列式解說》Web3的帳戶抽象，簽名抽象、費用抽象是什麼？
我們對這種思路進行了簡短的探索，但很快就放棄了，因為我們太專注於驗證任何型別的區塊鏈擴容都是可能的。儘管我們稍後會看到，資料可用性取樣和 ZK-EVM 的結合意味著以太坊擴容的一個可能的未來實際上看起來非常接近這個願景！
另一方面，對於帳戶抽象，我們從一開始就知道某種實現是可能的，因此研究立即開始嘗試使一些儘可能接近 「交易只是一個呼叫」 的純粹出發點的東西變為現實。
這裡的主要程式碼之一是 validate_transaction (state, tx)，它負責檢查交易的 nonce 和簽名是否正確。從一開始，帳戶抽象的實際目標就是允許使用者用自己的驗證邏輯替換基本的非增量驗證和 ECDSA 驗證，這樣使用者就可以更輕鬆地使用社交恢復和多簽名錢包等功能。
因此，找到一種方法將 apply_transaction 重新架構為一個簡單的 EVM 呼叫，這不僅僅是一個 「為了使程式碼乾淨而使程式碼乾淨」 的任務；相反，它是關於將邏輯移動到使用者的帳戶程式碼中，為使用者提供所需的靈活性。
然而，堅持讓 apply_transaction 包含儘可能少的固定邏輯的做法最終帶來了很多挑戰。我們可以看下最早的帳戶抽象提案之一 EIP-86。
延伸閱讀：深度探究｜對以太坊網路 TPS 造成影響的 5 個方面
如果按原樣包含 EIP-86，它將降低 EVM 的複雜性，代價是大量增加以太坊堆疊其他部分的複雜性，需要在其他地方編寫本質上完全相同的程式碼，除了引入全新的怪異類別之外，例如具有相同hash值的同一交易可能會在鏈中多次出現，更不用說多重失效問題了。
帳戶抽象中的多重失效問題。在鏈上包含的一筆交易可能會使記憶體池中的數千筆其他交易無效，從而使記憶體池很容易被廉價地充斥。
從那時起，帳戶抽象分階段發展。EIP-86 後來變成了 EIP-208，最終出現了實際可行的 EIP-2938。然而，EIP-2938 一點也不簡約。其內容包括：
- 新的交易型別
- 三個新交易範圍的全域性變數
- 兩個新的操作碼，包括非常笨拙的 PAYgas 操作碼，用於處理 gas 價格和 gas 限制檢查，作為 EVM 執行斷點，以及臨時儲存 ETH 以一次性支付費用
- 一組複雜的挖礦和轉播策略，包括交易驗證階段禁止的操作碼列表
為了在不涉及以太坊核心開發人員（專注於優化以太坊客戶端和實現合併）的情況下實現帳戶抽象，EIP-2938 最終被重新架構為完全是協議外的 ERC-4337。
因為這是一個 ERC，它不需要硬分叉，並且在技術上存在於 「以太坊協議之外」。所以…… 問題解決了嗎？事實證明並非如此。ERC-4337 當前的中期路線圖實際上涉及最終將 ERC-4337 的大部分轉變為一系列協議功能，這是一個有用的指導示例，可以瞭解為什麼要考慮這條路徑。
封裝 ERC-4337
有幾個關鍵原因討論了最終將 ERC-4337 重新納入協議：
- gas 效率： 在 EVM 內部進行的任何操作都會導致一定程度的虛擬機器開銷，包括在使用諸如儲存槽之類 gas 費昂貴的功能時效率低下。目前，這些額外的低效率加起來至少要消耗 2 萬 gas，甚至更多。將這些元件放入協議中是消除這些問題的最簡單方法。
- 程式碼 bug 風險： 如果 ERC-4337 「入口點合約」 有一個足夠可怕的 bug，所有與 ERC-4337 相容的錢包都可能看到他們所有的資金枯竭。用協議內功能取代合約會產生一種隱含的責任，即通過硬分叉修復程式碼錯誤，從而消除使用者的資金枯竭風險。
- 支援 EVM 操作碼， 如 txt.origin。ERC-4337 本身使 txt.origin 返回將一組使用者操作打包到交易中的 「捆綁器（bundler）」 的地址。原生帳戶抽象可以解決這個問題，方法是使 txt.origin 指向傳送交易的實際帳戶，使其運作方式與 EOA 相同。
- 抗審查： 提議者 / 構建者分離的挑戰之一是審查單筆交易變得更容易。在以太坊協議可以識別單筆交易的世界中，包含列表可以極大地緩解這個問題，該列表允許提議者指定在幾乎所有情況下必須包含在接下來兩個插槽中的交易列表。但是協議外的 ERC-4337 將 「使用者操作」 封裝在單筆交易中，使得使用者操作對以太坊協議不透明；因此，以太坊協議提供的包含列表將無法對 ERC-4337 使用者操作提供審查阻力。封裝 ERC-4337，並使使用者操作成為一種 「適當的」 交易型別，將解決這個問題。
延伸閱讀：V神大推的「以太坊帳戶抽象」是什麼？ ERC-4337 實用案例說明
值得一提的是，在目前的形式下，ERC-4337 比 「基本」 以太坊交易要貴得多：交易成本為 21,000 gas，而 ERC-4337 的成本約為 42,000 gas。
理論上，應該有可能對 EVM gas 成本系統進行調整，直到協議內成本和協議外訪問儲存的成本相匹配；當其他型別的儲存編輯操作更便宜時，轉移 ETH 沒有理由需要花費 9000 gas。
事實上，與即將到來的 Verkle 樹轉換相關的兩個 EIP 實際上試圖做到這一點。但是，即使我們這樣做了，有一個顯而易見的原因可以解釋為什麼無論 EVM 變得多麼高效，封裝的協議功能都將不可避免地比 EVM 程式碼便宜得多：封裝程式碼不需要為預載入支付 gas。
功能齊全的 ERC-4337 錢包很大，編譯並放到鏈上的這個實現佔用了約 12,800 位元組。當然，你可以一次部署這段程式碼，並使用 DELEGATECALL 來允許每個單獨的錢包呼叫它，但是仍然需要在使用它的每個區塊中訪問該程式碼。在 Verkle 樹 gas 成本 EIP 下，12,800 位元組將組成 413 個 chunk，訪問這些 chunk 將需要支付 2 倍的 witness branch_cost（總共 3,800 gas）和 413 倍的 witness chunk_cost（總共 82,600 gas）。這甚至還沒有開始提到 ERC-4337 入口點本身，在 0.6.0 版本中，鏈上有 23,689 位元組（根據 Verkle 樹 EIP 規則，約有 158,700 個 gas 要載入）。
這就導致了一個問題：實際訪問這些程式碼的 gas 成本必須以某種方式在交易中分攤。ERC-4337 使用的當前方法不是很好：bundle 中的第一筆交易消耗了一次性儲存 / 程式碼讀取成本，使其比其他交易昂貴得多。協議內封裝將允許這些公共共享庫成為協議的一部分，所有人都可以免費訪問。
我們能從這個例子中學到什麼，什麼時候更普遍地進行封裝？
在這個例子中，我們看到了在協議中封裝帳戶抽象方面的一些不同的基本原理。
當固定成本較高時，「將複雜性推向邊緣」 的基於市場的方法最容易失敗。事實上，長期的帳戶抽象路線圖看起來每個區塊都有很多固定的成本。244,100 gas 用於載入標準化錢包程式碼是一回事；但是聚合可能會為 ZK-SNARK 驗證增加數十萬的 gas，以及證明驗證的鏈上成本。沒有一種方法可以在不引入大量市場低效率的情況下向使用者收取這些成本，而將其中一些功能轉化為所有人都可以免費訪問的協議功能則可以很好地解決這個問題。
社群範圍內對程式碼 bug 的響應。如果一些程式碼片段被所有使用者或非常廣泛的使用者使用，那麼區塊鏈社群承擔硬分叉的責任來修復出現的任何錯誤通常更有意義。ERC-4337 引入了大量的全域性共享程式碼，從長遠來看，通過硬分叉修復程式碼中的錯誤無疑比導致使用者損失大量 ETH 更合理。
有時，可以通過直接利用協議的功能來實現其更強形式。這裡的關鍵例子是協議內的抗審查功能，如包含列表：協議內的包含列表可以比協議外的方法更好地保證審查阻力，為了使使用者級操作真正受益於協議內的包含列表，單個使用者級操作需要對協議 「易讀」。另一個鮮為人知的例子是，2017 年時代的以太坊權益證明設計對權益金鑰進行了帳戶抽象，這被放棄了並轉而支援封裝 BLS，因為 BLS 支援一種 「聚合」 機制，必須在協議和網路層面實現，這可以使處理大量簽名的效率更高。
但重要的是要記住，與現狀相比，即使是封裝協議內帳戶抽象，仍然是一種巨大的 「去封裝化」。如今，頂級以太坊交易只能從外部擁有的帳戶（EOA）發起，這些帳戶使用單個 secp256k1 橢圓曲線簽名進行驗證。帳戶抽象消除了這一點，並將驗證條件留給使用者自行定義。因此，在這個關於帳戶抽象的故事中，我們也看到了反對封裝的最大理由：靈活地滿足不同使用者的需求。
讓我們通過檢視最近被考慮封裝的其他幾個特徵示例來進一步充實這個故事。我們將特別關注： ZK-EVM，提議者 – 構建者分離，私有記憶體池，流動性質押和新的預編譯。
封裝 ZK-EVM
讓我們把注意力轉移到以太坊協議的另一個潛在封裝目標：ZK-EVM。目前，我們有大量的 ZK-rollup，它們都必須編寫相當相似的程式碼來驗證 ZK-SNARK 中類似以太坊區塊的執行。有一個相當多樣化的獨立實現生態系統：PSE ZK-EVM、 Kakarot 、 Polygon ZK-EVM、 Linea 、Zeth 等等。
延伸閱讀：從Type1到Type4，各類型ZK-EVM的差異在哪？
EVM ZK-rollup 領域最近的一個爭議與如何處理 ZK 程式碼中可能出現的 bug 有關。目前，所有這些正在執行的系統都有某種形式的 「安全理事會」 機制，可以在出現 bug 的情況下控制證明系統。去年，我試圖建立一個標準化的框架，以鼓勵專案明確他們對證明系統的信任程度，以及對安全理事會的信任程度，並隨著時間的推移，逐漸減少對該組織的權力。
從中期來看，rollup 可能依賴於多個證明系統，而安全理事會只有在兩個不同的證明系統產生分歧的極端情況下才有權力。
然而，有一種感覺是，其中一些工作感覺是多餘的。我們已經有了以太坊基礎層，它有一個 EVM，我們已經有了一個處理實現中 bug 的工作機制：如果有 bug，客戶端將進行更新來修復，然後鏈繼續運作。從有 bug 的客戶端角度來看，似乎已經最終確認的區塊將不再確認，但至少我們不會看到使用者損失資金。同樣，如果 rollup 只是想保持與 EVM 等同的作用，那麼它們需要實施自己的治理來不斷更改其內部 ZK-EVM 規則以匹配對以太坊基礎層的升級，這感覺是錯誤的，因為最終它們是在以太坊基礎層本身之上構建的，它知道何時升級以及根據什麼新規則。
由於這些 L2 ZK-EVM 基本上使用與以太坊完全相同的 EVM，我們能否以某種方式將 「驗證 EVM 在 ZK 中的執行」 納入協議功能，並通過應用以太坊的社會共識來處理異常情況，如 bug 和升級，就像我們已經為基礎層 EVM 執行本身所做的那樣？
這是一個重要而富有挑戰性的話題。
關於原生 ZK-EVM 中資料可用性的一個可能的爭論主題是有狀態性（statefulness）。如果 ZK-EVM 不需要攜帶 「見證（witness）」 資料，它們的資料效率就會高得多。也就是說，如果某個特定的資料已經在之前的某個區塊中被讀取或寫入，我們可以簡單地假設證明者可以訪問它，並且不必再次使它可用。這不僅僅是不重新載入儲存和程式碼；事實證明，如果一個 rollup 正確地壓縮了資料，那麼與無狀態壓縮相比，有狀態壓縮最多可以節省 3 倍的資料。
這意味著對於 ZK-EVM 預編譯，我們有兩個選項：
- 預編譯要求所有資料在同一區塊中可用。 這意味著 prover 可以是無狀態的，但也意味著使用這種預編譯的 ZK-rollup 比使用自定義程式碼的 rollup 要昂貴得多。
- 預編譯允許 pointer 指向先前執行使用或生成的資料。 這使得 ZK-rollup 接近最優，但它更復雜，並引入了一種必須由 prover 儲存的新狀態。
我們能從中學到什麼？以某種方式將 ZK-EVM 驗證封裝有一個很好的理由：rollup 已經在構建自己的自定義版本，並且以太坊願意將其多個實現和鏈下社會共識的權重置於 L1 上執行 EVM，這感覺是錯誤的，但是做完全相同工作的 L2 必須實現涉及安全理事會的複雜小工具。但另一方面，細節中有一個大問題：有不同版本的 ZK-EVM，它們的成本和收益不同。有狀態和無狀態的區分只是觸及了表面；嘗試支援 「近 EVM（almost-EVM）」，這些訂製程式碼已經被其他系統證明，這可能會暴露出更大的設計空間。因此，封裝 ZK-EVM 既帶來了希望，也帶來了挑戰。
封裝提議者與構建者分離（ePBS）
MEV 的興起使區塊生產成為一種大規模經濟活動，複雜的參與者能夠生產出比預設演算法產生更多收入的區塊，而預設演算法只是觀察交易的記憶體池幷包含它們。到目前為止，以太坊社群試圖通過使用 MEV- Boost Boost BOOST 是一個去中心化的應用程式平臺，旨在通過增加現有工具的功能並使其更加健壯來增強其體驗。 BOOST 是用於解鎖高階和可升級功能、治理活動中的未來投票以及未來產品功能的支付處理的原生實用代幣。即將推出的 BOOST 產品包括 BoostSWAP、BoostFARM 和 BoostNFT。這些創新產品將改進現有的 DeFi 基礎設施，並有助於擴容去中心化的網際網路社群。 BOOST Coin 於 2021 年 8 月 9 日推出，有 10 億個代幣在流通。 Boost 目前可以在 Uniswap 上交易，很快就會在 BoostSwap 上可用。 檢視更多 等協議外的提議者 – 構建者分離（proposer-builder separation）方案來解決這個問題，該方案允許常規驗證者（「提議者」）將區塊構建外包給專門的參與者（「構建者」）。
然而，MEV-Boost 在一個新的參與者類別中進行了信任假設，稱為中繼（relay）。在過去的兩年裡，有很多人提議建立 「封裝 PBS」。這樣做的好處是什麼？在這種情況下，答案非常簡單：通過直接使用協議功能構建的 PBS 比不使用它們構建的 PBS 更強大（在具有更弱的信任假設的意義上）。這與封裝協議內價格預言機的情況類似 —— 儘管在這種情況下，也存在強烈的反對意見。
封裝私有記憶體池
當用戶傳送交易時，該交易立即公開並對所有人可見，甚至在它被包含在鏈上之前。這使得許多應用程式的使用者容易受到經濟攻擊，例如搶先交易。
最近，有許多專案專門致力於建立 「私有記憶體池」（或 「加密記憶體池」），它將使用者的交易加密，直到它們被不可逆轉地被接受到一個區塊中。
然而，問題是，這樣的方案需要一種特殊的加密：為了防止使用者湧入系統並率先進行解密，加密必須在交易確實被不可逆轉地被接受後自動解密。
為了實現這種形式的加密，有各種不同權衡的技術。Jon Charbonneau 曾做過很好的描述：
- 對中心化運營商進行加密， 例如 Flashbots Flashbots Flashbots 是一家專注於礦工可提取價值 (MEV) 的研發公司，旨在減輕 MEV 對智慧合約區塊鏈帶來的負面外部性和存在風險。 檢視更多 Protect。
- 時間鎖加密， 該加密形式經過一定的順序計算步驟後，任何人都可以解密，並且不能並行化；
- 閾值加密， 信任一個誠實的多數委員會來解密資料。具體建議請參見封閉信標鏈概念。
- 可信硬體， 如 SGX。
不幸的是，每一種加密方式都有不同的弱點。雖然對於每個解決方案，都有一部分使用者願意信任它，但沒有一個解決方案的信任程度足以讓它實際上被 Layer1 接受。因此，至少在延遲加密得到完善或其他一些技術突破之前，在 Layer1 封裝反提前交易功能似乎是一個困難的命題，即使它是一個足夠有價值的功能，許多應用程式解決方案已經出現。
封裝流動性質押
以太坊 DeFi 使用者的一個共同需求是能夠同時使用他們的 ETH 進行質押和作為其他應用程式中的抵押品。另一個常見的需求僅僅是為了方便：使用者希望能夠在沒有執行節點並保持其始終線上的複雜性的情況下進行質押（並保護線上質押金鑰）。
到目前為止，滿足這兩種需求的最簡單質押 「介面」 只是一種 ERC20 代幣：將你的 ETH 轉換為 「質押 ETH」，持有它，然後再轉換回來。事實上， Lido 是一種流動性池質押解決方案。Lido 允許使用者在參與鏈上活動（如借貸、交易）的同時，以複合回報的方式在 PoS 公鏈上下注，而無需最低存款或維護基礎設施。目前已支援 ETH2.0 、Terra、Solana，未來有可能擴展到其他 POS 公鏈。 Rocket（ROCKET）是 2021 年推出的一種加密貨幣，在 BNB 智慧鏈（BEP20）平臺上執行。 Pool 支援使普通人能夠通過資料獲利和共享資料的組織 檢視更多 等流動性質押提供商已經開始這樣做了。然而，流動性質押有一些自然的中心化機制在起作用：人們自然會進入最大版本的質押 ETH，因為它是最熟悉和最具流動性的。
延伸閱讀：Lido不甩！Rocket Pool等多家LSD協議「自我約束」持有ETH不高於總質押22％
每個版本的質押 ETH 都需要有一些機制來確定誰可以成為底層節點運營商。它不能是無限制的，因為這樣攻擊者就會加入並利用使用者的資金擴大攻擊。目前，排名前兩位的是 Lido 和 RocketPool 是以太坊 PoS 基礎設施服務。所有想通過定期質押的方式獲取以太坊利息的個人和組織都可以通過使用 RocketPool 的去中心和的節點執行網路來參與 staking。 檢視更多 ，前者擁有 DAO 白名單節點運營商，後者允許任何人在存入 8 枚 ETH 的情況下執行一個節點。這兩種方法有不同的風險：Rocket Pool 方法允許攻擊者對網路進行 51% 的攻擊，並迫使使用者支付大部分成本；至於 DAO 方法，如果某質押代幣占主導地位，就會導致一個單一的、可能受到攻擊的治理小工具控制所有以太坊驗證者的很大一部分。值得肯定的是，像 Lido 這樣的協議已經實施了防範措施，但一層防禦可能還不夠。
在短期內，一種選擇是鼓勵生態系統參與者使用多樣化的流動性質押提供商，以減少一家獨大帶來系統性風險的可能性。然而，從長期來看，這是一種不穩定的平衡，過度依賴道德壓力來解決問題是危險的。一個自然的問題出現了： 在協議中封裝某種功能以使流動性質押不那麼中心化是否有意義？
這裡的關鍵問題是：什麼樣的協議內功能？簡單地建立一個協議內可替代的 「質押 ETH」 代幣存在一個問題，即它要麼必須有一個封裝以太坊範圍內治理來選擇誰來執行節點，要麼是開放的，但這會把它變成攻擊者的工具。
一個有趣的想法是 Dankrad Feist 關於流動性質押最大化的文章。首先，我們咬緊牙關，如果以太坊受到 51% 攻擊，可能只有 5% 的攻擊 ETH 被罰沒。這是一個合理的權衡；目前有超過 2600 萬枚 ETH 被質押，其中三分之一（約 800 萬枚 ETH）的攻擊成本是過度的，特別是考慮到有多少種 「模型外」 攻擊可以以更低的成本完成。事實上，類似的權衡已經在 「超級委員會」 關於實施 single-slot finality 的提案中進行了探討。
如果我們接受只有 5% 的攻擊 ETH 被罰沒，那麼超過 90% 的質押 ETH 將不會受到罰沒的影響，因此它們可以作為協議內可替代流動性質押代幣，然後被其他應用程式使用。
這條路徑很有趣。但它仍然留下了一個問題：具體封裝什麼？Rocket Pool 的運作方式與此非常相似：每個節點運營商提供一些資金，流動性質押者提供其餘的資金。我們可以簡單地調整一些常量，將最大罰沒懲罰限制為 2 枚 ETH，Rocket Pool 現有的 rETH 將變得無風險。
通過簡單的協議調整，我們還可以做其他聰明的事情。例如，假設我們想要一個系統，有兩種 「層」 的質押：節點運營商（高抵押品要求）和儲戶（沒有最低抵押品要求，可以隨時加入和離開），但我們仍然希望通過賦予一個隨機抽樣的儲戶委員會權力來防止節點運營商的中心化，比如建議必須包括的交易列表（出於抗審查的原因），在不活動洩漏期間控制分叉選擇，或者需要在區塊上簽名。這可以通過一種基本上脫離協議的方式來實現，方法是調整協議，要求每個驗證器提供（i）一個常規的質押金鑰，以及（ii）一個 ETH 地址，該地址可以在每個槽間被呼叫以輸出二級質押金鑰。該協議將賦予這兩項金鑰權力，但在每個槽中選擇第二個金鑰的機制可以留給質押池協議。直接封裝一些功能可能仍然更好，但值得注意的是，這種 「包含一些東西，把其他東西留給使用者」 的設計空間是存在的。
封裝更多預編譯
預編譯（或 「預編譯合約」）是實現複雜加密操作的以太坊合約，其邏輯在客戶端程式碼中原生實現，而不是 EVM 智慧合約程式碼。預編碼是以太坊開發之初採用的一種折衷方案：由於虛擬機器的開銷對於某些非常複雜和高度專業化的程式碼來說太大了，我們可以在原生程式碼中實現一些對重要應用程式有價值的關鍵操作，以使其更快。如今，這基本上包括一些特定的雜湊函式和橢圓曲線運算。
目前有人在推動為 secp256r1 新增預編譯，這是一種與用於基本以太坊帳戶的 secp256k1 略有不同的橢圓曲線，因為它得到了可信硬體模組的良好支援，因此廣泛使用它可以提高錢包安全性。近年來，社群還推動為 BLS-12-377、BW6-761、廣義配對和其他功能新增預編譯。
對這些要求更多預編譯檔案的反駁是，之前新增的許多預編譯（例如 RIPEMD 和 BLAKE）最終的使用量遠低於預期，我們應該從中吸取教訓。與其為特定操作新增更多的預編譯，我們也許應該專注於一種更溫和的方法，該方法基於 EVM- MAX 和休眠但始終可恢復的 SIMD 提案等思想，這將使 EVM 實現能夠以更低的成本執行廣泛的程式碼類。也許即使是現有的很少使用的預編譯也可以被刪除，並用相同函式的 EVM 程式碼實現（不可避免地效率較低）代替。也就是說，仍然有可能存在特定的加密操作，這些操作的價值足以加速，因此將它們作為預編譯新增是有意義的。
我們從這一切中學到了什麼？
儘可能少封裝的願望是可以理解的，也是好的；它源自 Unix 哲學傳統，即創建極簡的軟體，可以很容易地適應使用者的不同需求，避免軟體膨脹的詛咒。然而，區塊鏈不是個人計算作業系統，而是社會系統。這意味著在協議中封裝某些功能是有意義的。
在許多情況下，這些其他的例子與我們在帳戶抽象中看到的類似。但我們也學到了一些新的教訓：
封裝功能可以幫助避免堆疊中其他區域的中心化風險：
通常，保持基本協議的最小化和簡單性會將複雜性推到一些協議之外的生態系統。從 Unix 哲學的角度來看，這很好。然而，有時存在協議外生態系統將中心化的風險，通常（但不僅僅是）因為高固定成本。封裝有時可以減少事實上的中心化。
封裝太多內容，可能會過度擴大協議的信任和治理負擔：
這是前一篇關於 「不要讓以太坊共識過載」 文章的主題：如果封裝一個特定的功能削弱了信任模型，並使以太坊作為一個整體變得更加 「主觀」，這就削弱了以太坊的可信中立性。在這些情況下，最好將特定功能作為以太坊之上的機制，而不是試圖將其引入以太坊本身。在這裡，加密記憶體池是最好的例子，它可能有點難以封裝，至少在延遲加密技術改進之前是這樣。
封裝太多內容可能會使協議過於複雜：
協議複雜性是一種系統性風險，在協議中新增太多功能會增加這種風險。預編譯就是最好的例子。
長期來看，封裝功能可能會適得其反，因為使用者的需求是不可預測的：
一個很多人認為很重要並且會被很多使用者使用的功能，很可能在實踐中並沒有被經常使用。
此外，流動性質押、ZK-EVM 和預編譯案例顯示了一條中間道路的可能性：最小可行封裝（minimal viable enshrinement）。協議不需要封裝整個功能，而可以包含解決關鍵挑戰的特定部分，使該功能易於實現，而不會過於偏執或過於狹隘。這樣的例子包括：
與其封裝一個完整的流動性質押系統，不如改變質押懲罰規則，讓去信任流動性質押更可行；
與其封裝更多的預編譯器，不如封裝 EVM-MAX 或 SIMD，以使更廣泛的操作類別更容易有效地實現；
可以簡單地封裝 EVM 驗證，而不是封裝 rollup 的整個概念。
我們可以將前面的圖表擴展如下：
有時候，去封裝一些東西是有意義的，去除很少使用的預編譯就是一個例子。帳戶抽象作為一個整體，正如前面提到的，也是一種重要的去封裝形式。如果我們想支援現有使用者的向後相容性，那麼該機制實際上可能與去封裝預編譯的機制驚人地相似：其中一個提案是 EIP-5003，它將允許 EOA 將其帳戶轉換為具有相同（或更好）功能的合約。
哪些功能應該被引入協議，哪些功能應該留給生態系統的其他層，這是一個複雜的權衡。隨著我們對使用者需求的理解以及可用想法和技術套件的不斷改進，這種權衡有望隨著時間的推移而繼續改進。
