爲什麼 「合併」是我們刪掉一些東西的最後機會?

原文標題:《引介 | 值得考慮刪除的 EVM 功能》
撰文:Vitalik Buterin
翻譯 & 校對:戡亂 & 阿劍
來源:以太坊愛好者

到 2020 年,我們對如何設計智能合約和區塊鏈協議的理解已經遠超 2013-15 年。因此,如果我們在 2021 年從頭開始搭建以太坊,我們就不會引入很多早期添加的功能了。然而從一條正在運行的、擁有活躍生態的區塊鏈中移除功能,遠比在一個新系統中不添加它們要難得多。

有些 「缺陷功能」 是無害的。有些可以安全而緩慢地移除或改進。還有些已經深深地嵌入到了太多的應用中,以至於根本改不動(例如 EVM 的 256 位字長)。另一方面,也有一些功能要麼已經被移除,要麼已經被改進,要麼即將被移除(例如對狀態樹格式的改進、用 SSZ 編碼規則代替 RLP 等)。

但是還有一些中間情況:有些功能過於複雜,對生態的發展造成了中等程度的傷害,我們可以移除它們,但是需要冒一點風險。如果我們移除這些功能,可能會有少量的應用被破壞。但是不移除的話,它們會繼續拖累生態。

就跟別的 「長痛短痛」 抉擇情形一樣,人們很容易低估短痛帶來的長期收益。特別是在我們的情況中,由於解決複雜情況的代碼已經寫好了,所以感覺保留它們不需要付出任何成本。但實際上有兩個重要的成本要考慮:

  1. 爲協議開發新實現的成本
  2. 若要改變功能 B,但 B 會跟沒必要存在的複雜功能 A 交互,可能會產生 「交互 bug」

以重新設計狀態樹爲例:若以太坊的狀態越是遵循一些簡單的恆常性質(invariants),那麼替換更高效的雙層十六進制 Patricia 樹就會越容易。然而在現實情況中,因爲 SELFDESTRUCT 操作碼可以在單筆事務中不受限制地刪除大量存儲插槽,這給改良狀態樹帶來了很大的困難。另一個例子是 2300 gas 津貼機制(見下文)使 gas 重新定價變得更復雜。

「合併」(放棄 eth1 的 PoW 鏈,並將其狀態導入 eth2 的 PoS 信標鏈的事件)可能是我們扯掉一些痛苦繃帶的最後機會,這篇文章就是解釋這樣做的理由。

合併是進行最後一輪不兼容更新的一個非常自然的時間節點,有以下幾個理由:

  1. 合併後構建的客戶端很可能不處理 PoW 鏈,而是專門驗證 PoS 信標鏈。因此,如果在合併時或合併前去除不必要的複雜功能,客戶端最容易從中受益,因爲它們根本不需要實現這些功能。(從技術上講,即使是在合併前建立的客戶端也可以設計成只處理最近 1-2 個硬分叉之後的數據,但是 「PoS 信標鏈作爲一條獨立的鏈而不需要處理 PoW 鏈上過於久遠的數據」 的說法更容易讓人接受)
  2. 以太坊已經發生了很大的改變,社區對這將是 「以太坊的一次重大升級」 達成了共識。特別是 「在分片和合並完成之前會出現快速的進化,但合併之後就會趨於穩定」 的觀點也得到了社區的一致認可。
  3. 必要的向後不兼容的改變(例如,BLOCKHASH 操作碼不再是一個好的隨機性來源)已經發生了。

這篇文章將介紹一些可以考慮刪除的功能的例子。

功能列表

2300 gas 津貼

這是什麼?

當一個合約調用另一個合約時,被調用的合約會得到 2300 gas 用於執行非常有限的操作(足夠做一點計算和生成一條日誌,但不夠寫滿一個存儲槽)

爲何引入?

最初是爲了讓智能合約錢包在收錢時能自動生成一條日誌。後來還被用於實現 「守衛」 功能以防止合約收到 ETH。

有何問題?

  • 由於它設置的是固定的 gas 數量,因此只要 gas 價格可以調整,人們就沒有辦法確定這些 gas 到底能支持什麼類型的計算。

  • 它並沒有很好地滿足設計意圖,有兩個原因。首先,很多用戶仍然在使用外部賬戶,而外部賬戶並不會生成日誌。其次,SELFDESTRUCT 操作碼繞過了津貼機制。從長遠來看,通過賬戶抽象化,外部賬戶的作用將被弱化,並且 SELFDESTRUCT 操作碼可能將被移除,但是在這兩件事完成之前,它都只是一個不充分的解決方式。

如何移除?

有兩種可能 —— 要麼將 2300 改成 0 (不支持子執行(child execution))要麼不限制數量(子執行可以從父執行中獲得全部的 gas 可用額度)

移除有何副作用?

  • 如果我們移除子執行,那麼這將需要在合約調用中添加一個笨拙的二分處置(two-clause mechanic),即 0 gas 解釋爲 0,任何其他數字解釋爲 「發送所有的 gas」。它還會破壞反接收守衛功能和日誌記錄。

  • 如果我們在執行中允許子執行獲得全部的 gas,那麼通過調用發送 ETH 會變成一個需要信任的操作,惡意合約可能會藉此擾亂一些應用。不過,Solidity 文檔已經建議大家用 withdrawal 模式代替 transfer,這樣就不會有任何風險了。

如何消除顧慮?

  • 讓所有的 ETH 轉賬,無論是來自調用還是 SELFDESTRUCT(如果保留的話),都生成一條日誌,這樣錢包就不需要生成日誌了

  • 增加一條規則,對於提供 0 gas 的調用,可看做是一個 「可以生成日誌的 STATICCALL」。這樣就複製了在 gas 津貼的執行環境裏實際做到的功能。

剩餘 Gas 額度可見性

這是什麼?

GAS 操作碼允許合約查看當前的執行環境中還剩多少 gas 可用。CALL 允許調用者爲子上下文提供固定數量的 gas。

爲何引入?

反對讓 CALL 將父環境中剩餘的全部 gas 都交給子環境的最主要原因是避免 「不可信任的調用」:即發送者不信任接受者的調用。一個簡單的例子是發送 ETH 給參與方的金融機制。另一個例子是 M-of-N 外部價格信息的輸入機制(oracle),通過調用一些合約,在獲得所有合約回覆後取中位數作爲輸出。

有何問題?

  • 其實絕大多數不可信任調用的用例都可以通過其他方式繞過去。對於轉賬,Solidity 文檔已經建議大家用 withdrawal 模式代替 transfer。M-of-N 外部價格信息的輸入機制可以很容易地通過爲每一個外部輸入單獨創建一筆交易實現。

  • 這會讓 gas 重定價變得很難做,當操作碼的 gas 消耗量發生變化,固定 gas 數量的調用可能會不夠用。

如何移除?

  • CALL 可以自動將父環境的所有可用 gas 額度都交給子環境。GAS 操作碼只需簡單地返回交易的初始 gas 數量。

移除有何副作用?

  • 我們知道的 「不可信任調用的合法用例」 主要是第三方贊助調用(譯者注:即元交易)。第三方發佈一筆事務,事務中包含你希望的調用,當調用發生後,可以自動地向你扣費(你會公佈授權他們這樣做的簽名)。這對用戶沒有任何 ETH 的智能合約錢包、混幣者的隱私保護以及其他一些用例都很有用。我們需要一個有限 gas 數量的調用以確保最終的支付語句真正被調用,而不會因爲 gas 不足而被回退。

如何消除顧慮?

  • 礦工可以直接充當中介,如果交易最終沒有付錢給他們,他們就可以直接丟棄事務。參見 Phil Daian 的工作,他創建了一個由第三方機器人構成的生態,礦工可以自動產生 「安全」 的批量交易。

  • 在協議內增加一個明確的 「第三方付款人」 的交易類型。參見 EIP 2711 的例子。

還請注意,如果我們想要走得更遠,我們還需要調整 63/64 規則使得如果子調用失敗,父調用也徹底失敗(所以連 1/64 都不剩)。這可能會破壞更多的用例(「如果子調用失敗就僅執行一個簡單的操作」),但它將確保當 gas 消耗量發生變化時只會引起一種類型的行爲變化(原本成功的交易現在會失敗)。

SELFDESTRUCT

請看這篇文章。

Gas 退款

這是什麼?

調用 SELFDESTRUCT 銷燬一個合約,或者將一個存儲槽設置爲零,會退回 15000-25000 gas。退款會在事務執行的最後觸發,並抵扣發送者需要支付的費用。

爲何引入?
激勵應用開發者踐行 「良好的狀態衛生」,清除不再需要的存儲插槽和合約。

有何問題?

  • 在實踐中,幾乎沒有人真正踐行良好的狀態衛生。這是因爲激勵不夠高,不值得爲此增加代碼的複雜度甚至帶來安全風險。

  • 退費機制使得 GasToken 興起。GasToken 有利於將低費率時期的 gas 調配到高費率時期使用,但是它不利於網絡,特別是加重了狀態規模的膨脹,並使低效的 gas 使用方法阻塞了區塊鏈。

  • 它加劇了區塊大小的波動,使一個區塊實際上的理論最大 gas 消耗量幾乎是字面意義上區塊 Gas 上限的兩倍。這並不致命,但仍然不可取,特別是考慮到,在 EIP-1559 實施後,退款機制可以使網絡的實際 Gas 使用量長期維持高水平,阻礙 1559 機制的運行。

如何移除?

只要把退款功能從協議中完全刪除。

移除有何副作用?

  • 我們可以相當確信,沒有任何應用會因此無法使用,因爲退款只在執行結束後觸發,所以取消退款並不會改變任何執行的可用 gas 數量。

  • GasToken 將變得毫無用處

  • 在 gas 價格反常時,應用失去了降低費用的能力。好在這個功能目前最主要的用戶是 defi 的套利機器人,而套利機器人之間的 gas 價格競爭是一種零和活動,不過還不清楚移除這個它們用於競爭的武器會造成什麼全局性的不利影響。

如何消除顧慮?

  • Gastoken 在他們的網站上已經警告過,未來的協議變更可能會使 GasToken 無效,所以用戶不會覺得驚訝

  • 我們可以提前公佈變更時間

其他候選功能(推測)

相比上面列舉的,我對移除以下功能會帶來多少價值缺乏信心,不過還是值得列出一個清單。

RIPEMD160 預編譯:這是一個非標準的哈希函數,很少有項目使用(除了與比特幣交互的應用)。我們可以用鏈上部署的合約進行替換,對於真正需要高效驗證的項目,可以直接使用 ZK-SNARK。

動態跳轉:使用變量作爲跳轉目標會使代碼的分析和操作變得更加困難(例如,無法簡單地替換操作碼序列,或者預置一些代碼)。去掉動態跳轉,只允許相對偏移的靜態跳轉,並且爲子程序提供一些專用的指針方案(指針不作爲整型暴露)可以解決這個問題。然而,這將是一個底層的改變,可能會破壞許多自定義的合約,所以其收益 / 成本比似乎不如這個列表中的其他項目。

MODEXP 預編譯:對於大整數計算來說,這顯然是一個錯誤的 「基本元件」,並且其 gas 消耗的計算方案也相當複雜。更好的選擇是:(i) 用預編譯的 ADD、MUL 和 MOD 作爲替代的基本原語,並用這些預編譯的指令編寫用於替代 MODEXP 的實現,或者 (ii) 將 EVM384 擴展到更多的長度(256,384,512,768,1024 ... 8192)

特別感謝 Micah Zoltu 提出的一些建議

來源鏈接:hackmd.io