流動性質押、ZK-EVM 和預編譯案例展示了一條中間道路：最小可行封裝。
原文：Should Ethereum be okay with enshrining more things in the protocol？（vitalik.eth）
編譯：念銀思唐，Odaily 星球日報譯者
封面：Photo by Shubham’s Web3 on Unsplash
特別感謝 Justin Drake， Tina Zhen 和 Yoav Weiss 的反饋和審查。
從乙太坊項目開始，就有一個強烈的理念，即試圖使核心乙太坊盡可能簡單，並通過在其上構建協定來儘可能實現這一點。 在區塊鏈領域，「在 L1 上構建」與「專注於 L2」的爭論通常被認為主要是關於擴展的，但實際上，在滿足多種乙太坊使用者的需求方面存在類似的問題：數位資產交換、隱私、使用者名、高級加密、帳戶安全、抗審查、搶先交易保護，等等。 然而，最近有一些謹慎的想法願意將更多這些功能封裝（enshrine）進核心乙太坊協定中。
這篇文章將深入探討最初的最小封裝哲學背後的一些哲學推理，以及一些最近思考這些想法的方法。 目標將是開始建立一個框架，以便更好地確定可能的目標，在這些目標中，封裝某些功能可能值得考慮。
關於協定極簡主義的早期哲學
在當時被稱為「乙太坊 2.0」的早期歷史中，人們強烈希望創建一個乾淨，簡單和美觀的協定，該協定盡可能少地嘗試通過自身來構建，並將幾乎所有這類工作都留給使用者。 理想情況下，協定只是一個虛擬機，而驗證一個區塊只是一個虛擬機調用。
“狀態轉換函數”（處理區塊的函數）將只是單個 VM 調用，所有其他邏輯將通過合約發生：一些系統級合約，但主要是由使用者提供的合約。 這個模型的一個非常好的功能是，即使是整個硬分叉也可以被描述為對於區塊處理器合約而言的單筆交易，該交易將通過鏈下或鏈上治理進行批准，然後以升級的許可權運行。
2015 年的這些討論特別適用於我們考慮的兩個領域：帳戶抽象和擴容。 在擴容的情況下，我們的想法是嘗試創建一個最大程度的抽象形式的擴容，感覺就像上面圖表的自然擴展。 合約可以調用大多數乙太坊節點未存儲的數據，協定將檢測到這一點，並通過某種非常通用的擴展計算功能來解決調用。 從虛擬機的角度來看，該調用將進入某個單獨的子系統，然後一段時間後神奇地返回正確的答案。
我們對這種思路進行了簡短的探索，但很快就放棄了，因為我們太專注於驗證任何類型的區塊鏈擴容都是可能的。 儘管我們稍後會看到，數據可用性採樣和 ZK-EVM 的結合意味著乙太坊擴容的一個可能的未來實際上看起來非常接近這個願景！ 另一方面，對於帳戶抽象，我們從一開始就知道某種實現是可能的，因此研究立即開始嘗試使一些盡可能接近 “交易只是一個調用” 的純粹出發點的東西變為現實。
在处理交易和从发送方地址发出实际的底层 EVM 调用之间，会出现大量的样板代码，之后还会出现更多的样板代码。我们如何将这些代码尽可能减少到接近于零？
這裡的主要代碼之一是 validate_transaction（state， tx），它負責檢查交易的 nonce 和簽名是否正確。 從一開始，帳戶抽象的實際目標就是允許使用者用自己的驗證邏輯替換基本的非增量驗證和 ECDSA 驗證，這樣使用者就可以更輕鬆地使用社交恢復和多簽名錢包等功能。 因此，找到一種方法將 apply_transaction 重新架構為一個簡單的 EVM 調用，這不僅僅是一個「為了使代碼乾淨而使代碼乾淨」的任務; 相反，它是關於將邏輯移動到使用者的帳戶代碼中，為使用者提供所需的靈活性。
然而，堅持讓 apply_transaction 包含盡可能少的固定邏輯的做法最終帶來了很多挑戰。 我們可以看下最早的帳戶抽象提案之一 EIP-86 。
如果按原樣包含 EIP-86 ，它將降低 EVM 的複雜性，代價是大量增加乙太坊堆棧其他部分的複雜性，需要在其他地方編寫本質上完全相同的代碼，除了引入全新的怪異類別之外，例如具有相同哈希值的同一交易可能會在鏈中多次出現，更不用說多重失效問題了。
帳戶抽象中的多重失效問題。 在鏈上包含的一筆交易可能會使記憶體池中的數千筆其他交易無效，從而使記憶體池很容易被廉價地充斥。
從那時起，帳戶抽象分階段發展。 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 ，並使用戶操作成為一種「適當的」交易類型，將解決這個問題。
值得一提的是，在目前的形式下，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）發起，這些帳戶使用單個 secp 256 k 1 橢圓曲線簽名進行驗證。 帳戶抽象消除了這一點，並將驗證條件留給使用者自行定義。 因此，在這個關於帳戶抽象的故事中，我們也看到了反對封裝的最大理由：靈活地滿足不同使用者的需求。
讓我們通過查看最近被考慮封裝的其他幾個特徵示例來進一步充實這個故事。 我們將特別關注：ZK-EVM，提議者-構建者分離，私有記憶體池，流動性質押和新的預編譯。
封裝 ZK-EVM
讓我們把注意力轉移到乙太坊協定的另一個潛在封裝目標：ZK-EVM。 目前，我們有大量的 ZK-rollup，它們都必須編寫相當相似的代碼來驗證 ZK-SNARK 中類似乙太坊區塊的執行。 有一個相當多樣化的獨立實現生態系統：PSE ZK-EVM、 Kakarot 、 Polygon ZK-EVM、 Linea 、Zeth 等等。
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 預編譯，我們有兩個選項：
1.預編譯要求所有數據在同一區塊中可用。 這意味著 prover 可以是無狀態的，但也意味著使用這種預編譯的 ZK-rollup 比使用自定義代碼的 rollup 要昂貴得多。
2.預編譯允許 pointer 指向先前執行使用或生成的數據。 這使得 ZK-rollup 接近最優，但它更複雜，並引入了一種必須由 prover 儲存的新狀態。
我們能從中學到什麼？ 以某種方式將 ZK-EVM 驗證封裝有一個很好的理由：rollup 已經在構建自己的自定義版本，並且乙太坊願意將其多個實現和鏈下社會共識的權重置於 L1 上執行 EVM，這感覺是錯誤的，但是做完全相同工作的 L2 必須實現涉及安全理事會的複雜小工具。 但另一方面，細節中有一個大問題：有不同版本的 ZK-EVM，它們的成本和收益不同。 有狀態和無狀態的區分只是觸及了表面; 嘗試支援「近 EVM（almost-EVM）」，這些定製代碼已經被其他系統證明，這可能會暴露出更大的設計空間。 因此，封裝 ZK-EVM 既帶來了希望，也帶來了挑戰。
封裝提議者與構建者分離（ePBS）
MEV 的興起使區塊生產成為一種大規模經濟活動，複雜的參與者能夠生產出比預設演算法產生更多收入的區塊，而默認演算法只是觀察交易的記憶體池並包含它們。 到目前為止，乙太坊社區試圖通過使用 MEV- Boost 等協定外的提議者-構建者分離（proposer-builder separation）方案來解決這個問題，該方案允許常規驗證者（“提議者”）將區塊構建外包給專門的參與者（“構建者”）。
然而，MEV-Boost 在一個新的參與者類別中進行了信任假設，稱為中繼（relay）。 在過去的兩年裡，有很多人提議創建「封裝 PBS」。 這樣做的好處是什麼？ 在這種情況下，答案非常簡單：通過直接使用協定功能構建的 PBS 比不使用它們構建的 PBS 更強大（在具有更弱的信任假設的意義上）。 這與封裝協定內價格預言機的情況類似——儘管在這種情況下，也存在強烈的反對意見。
封裝私有記憶體池
當用戶發送交易時，該交易立即公開並對所有人可見，甚至在它被包含在鏈上之前。 這使得許多應用程式的使用者容易受到經濟攻擊，例如搶先交易。
最近，有許多專案專門致力於創建「私有記憶體池」（或」加密記憶體池 “），它將使用者的交易加密，直到它們被不可逆轉地被接受到一個區塊中。
然而，問題是，這樣的方案需要一種特殊的加密：為了防止用戶湧入系統並率先進行解密，加密必須在交易確實被不可逆轉地被接受後自動解密。
為了實現這種形式的加密，有各種不同權衡的技術。 Jon Charbonneau 曾做過很好的描述：
- 對中心化運營商進行加密，例如 Flashbots Protect。
- 時間鎖加密，該加密形式經過一定的順序計算步驟后，任何人都可以解密，並且不能並行化;
- 閾值加密，信任一個誠實的多數委員會來解密數據。 具體建議請參見封閉信標鏈概念。
- 可信硬體，如 SGX。
不幸的是，每一種加密方式都有不同的弱點。 雖然對於每個解決方案，都有一部分用戶願意信任它，但沒有一個解決方案的信任程度足以讓它實際上被 Layer 1 接受。 因此，至少在延遲加密得到完善或其他一些技術突破之前，在 Layer 1 封裝反提前交易功能似乎是一個困難的命題，即使它是一個足夠有價值的功能，許多應用程式解決方案已經出現。
封裝流動性質押
乙太坊 DeFi 使用者的一個共同需求是能夠同時使用他們的 ETH 進行質押和作為其他應用程式中的抵押品。 另一個常見的需求僅僅是為了方便：使用者希望能夠在沒有運行節點並保持其始終在線的複雜性的情況下進行質押（並保護線上質押密鑰）。
到目前為止，滿足這兩種需求的最簡單質押「介面」只是一種 ERC 20 代幣：將你的 ETH 轉換為 “質押 ETH”，持有它，然後再轉換回來。 事實上， Lido 和 Rocket Pool 等流動性質押供應商已經開始這樣做了。 然而，流動性質押有一些自然的中心化機制在起作用：人們自然會進入最大版本的質押 ETH，因為它是最熟悉和最具流動性的。
每個版本的質押 ETH 都需要有一些機制來確定誰可以成為底層節點運營商。 它不能是無限制的，因為這樣攻擊者就會加入並利用使用者的資金擴大攻擊。 目前，排名前兩位的是 Lido 和 Rocket Pool ，前者擁有 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 智能合约代码。预编码是以太坊开发之初采用的一种折衷方案：由于虚拟机的开销对于某些非常复杂和高度专业化的代码来说太大了，我们可以在本地代码中实现一些对重要应用程序有价值的关键操作，以使其更快。如今，这基本上包括一些特定的散列函数和椭圆曲线运算。
目前有人在推动为 secp 256 r 1 添加预编译，这是一种与用于基本以太坊账户的 secp 256 k 1 略有不同的椭圆曲线，因为它得到了可信硬件模块的良好支持，因此广泛使用它可以提高钱包安全性。近年来，社区还推动为 BLS-12-377、BW 6-761、广义配对和其他功能添加预编译。
对这些要求更多预编译文件的反驳是，之前添加的许多预编译（例如 RIPEMD 和 BLAKE）最终的使用量远低于预期，我们应该从中吸取教训。与其为特定操作添加更多的预编译，我们也许应该专注于一种更温和的方法，该方法基于 EVM- MAX 和休眠但始终可恢复的 SIMD 提案等思想，这将使 EVM 实现能够以更低的成本执行广泛的代码类。也许即使是现有的很少使用的预编译也可以被删除，并用相同函数的 EVM 代码实现（不可避免地效率较低）代替。也就是说，仍然有可能存在特定的加密操作，这些操作的价值足以加速，因此将它们作为预编译添加是有意义的。
我们从这一切中学到了什么？
尽可能少封装的愿望是可以理解的，也是好的；它源自 Unix 哲学传统，即创建极简的软件，可以很容易地适应用户的不同需求，避免软件膨胀的诅咒。然而，区块链不是个人计算操作系统，而是社会系统。这意味着在协议中封装某些功能是有意义的。
在许多情况下，这些其他的例子与我们在帐户抽象中看到的类似。但我们也学到了一些新的教训：
- 封装功能可以帮助避免堆栈中其他区域的中心化风险：
通常，保持基本协议的最小化和简单性会将复杂性推到一些协议之外的生态系统。从 Unix 哲学的角度来看，这很好。然而，有时存在协议外生态系统将中心化的风险，通常（但不仅仅是）因为高固定成本。封装有时可以减少事实上的中心化。
- 封装太多内容，可能会过度扩大协议的信任和治理负担：
这是前一篇关于 “不要让以太坊共识过载” 文章的主题：如果封装一个特定的功能削弱了信任模型，并使以太坊作为一个整体变得更加 “主观”，这就削弱了以太坊的可信中立性。在这些情况下，最好将特定功能作为以太坊之上的机制，而不是试图将其引入以太坊本身。在这里，加密内存池是最好的例子，它可能有点难以封装，至少在延迟加密技术改进之前是这样。
- 封装太多内容可能会使协议过于复杂：
协议复杂性是一种系统性风险，在协议中添加太多功能会增加这种风险。预编译就是最好的例子。
- 长期来看，封装功能可能会适得其反，因为用户的需求是不可预测的：
一个很多人认为很重要并且会被很多用户使用的功能，很可能在实践中并没有被经常使用。
此外，流动性质押、ZK-EVM 和预编译案例显示了一条中间道路的可能性：最小可行封装（minimal viable enshrinement）。协议不需要封装整个功能，而可以包含解决关键挑战的特定部分，使该功能易于实现，而不会过于偏执或过于狭隘。这样的例子包括：
- 与其封装一个完整的流动性质押系统，不如改变质押惩罚规则，让去信任流动性质押更可行；
- 与其封装更多的预编译器，不如封装 EVM-MAX 和/或 SIMD，以使更广泛的操作类别更容易有效地实现；
- 可以简单地封装 EVM 验证，而不是封装 rollup 的整个概念。
我们可以将前面的图表扩展如下：
有时候，去封装一些东西是有意义的，去除很少使用的预编译就是一个例子。帐户抽象作为一个整体，正如前面提到的，也是一种重要的去封装形式。如果我们想支持现有用户的向后兼容性，那么该机制实际上可能与去封装预编译的机制惊人地相似：其中一个提案是 EIP-5003 ，它将允许 EOA 将其帐户转换为具有相同（或更好）功能的合约。
哪些功能应该被引入协议，哪些功能应该留给生态系统的其他层，这是一个复杂的权衡。随着我们对用户需求的理解以及可用想法和技术套件的不断改进，这种权衡有望随着时间的推移而继续改进。
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
