剖析六種 EVM 語言：優秀的語言要如何設計

發表於 2023-03-19 15:40 作者： 區塊鏈情報速遞pro

以太坊虛擬機 (EVM) 是一個 256 位、基於堆棧、全球可訪問的圖靈機。由於架構與其他虛擬機和物理機的明顯不同，EVM 需要領域特定語言 DSL（注：領域特定語言指的是專注於某個應用程序領域的計算機語言）。

在本文中，我們將研究 EVM DSL 設計的最新技術，介紹六種語言 Solidity、Vyper、Fe、Huff、Yul 和 ETK。

語言版本

• Solidity: 0.8.19 

• Vyper: 0.3.7

• Fe: 0.21.0

• Huff: 0.3.1

• ETK: 0.2.1

• Yul: 0.8.19

閱讀本文，需要你對 EVM、堆棧和編程有基本的了解。

以太坊虛擬機概述

EVM 是一個基於 256 位堆棧的圖靈機。然而，在深入研究它的編譯器之前，應該介紹一些功能特性。

由於 EVM 是「圖靈完備」的，它會受到「停機問題」的困擾。簡而言之，在程序執行之前，沒有辦法確定它未來是否會終止。EVM 解決這個問題的方法是通過「Gas」計量計算單位，一般來說，這與執行指令所需的物理資源成比例。每個交易的 Gas 量是有限制的，交易的發起者必須支付與交易消耗的 Gas 成比例的 ETH。這個策略的影響之一是，如果有兩個功能上相同的智能合約，消耗更少 Gas 的合約將被更多採用。這導致協議競爭極端的 Gas 效率，工程師努力最小化特定任務的 Gas 消耗。

此外，當調用一個合約時，它會創建一個執行上下文。在這個上下文中，合約有一個堆棧用於操作和處理，一個线性內存實例用於讀寫，一個本地持久性存儲用於合約讀寫，並且附加到調用的數據「calldata」可以被讀取但不能被寫入。

關於內存的一個重要說明是，雖然它的大小沒有確定的「上限」，但仍然是有限的。擴展內存的 Gas 成本是動態：一旦達到閾值，擴展內存的成本將呈二次方增長，也就是說 Gas 成本與額外內存分配的平方成正比。

合約也可以使用一些不同的指令來調用其他合約。 「call」指令將數據和可選的 ETH 發送到目標合約，然後創建自己的執行上下文，直到目標合約的執行停止。 「staticcall」指令與 「call」相同，但增加了一個檢查，即在靜態調用完成之前，斷言全局狀態的任何部分都未被更新。最後， 「delegatecall」指令的行爲類似於 「call」，只是它會保留先前上下文的一些環境信息。這通常用於外部庫和代理合約。

爲什么語言設計很重要

在與非典型架構交互時，特定領域語言（DSL）是必要的。雖然存在諸如 LLVM 之類的編譯器工具鏈，但是依賴它們來處理智能合約，在程序正確性和計算效率至關重要的情況下，不太理想。

程序正確性非常重要，因爲智能合約默認是不可變的，並且鑑於區塊鏈虛擬機（VM）的屬性，智能合約是金融應用程序的熱門選擇。雖然存在針對 EVM 的升級性解決方案，但它充其量只是一個補丁，最壞的情況是任意代碼執行漏洞。

計算效率也非常關鍵，因爲最小化計算具有經濟優勢，但不能以安全爲代價。

簡而言之，EVM DSL 必須平衡程序正確性和 Gas 效率，在不犧牲太多靈活性的情況下通過做出不同的取舍來實現其中之一。

語言概覽

對於每種語言，我們將描述它們的顯着特性和設計選擇，並包括一個簡單的計數功能智能合約。言語流行度是根據 Defi Llama 上的總鎖定價值 (TVL) 數據確定的。

Solidity

Solidity 是一種高級語言，其語法類似於 C、Java 和 Javascript。它是按 TVL 計算最受歡迎的語言，其 TVL 是第二名的十倍。爲了代碼重用，它使用面向對象模式，智能合約被視爲類對象，利用了多重繼承。編譯器採用 C++ 編寫，計劃在將來遷移到 Rust。

可變的合約字段存儲在持久性存儲中，除非它們的值在編譯時（常量）或部署時（不可變）已知。合約內聲明的方法可以聲明爲 pure、view、payable，或默認情況下是 non-payable 但狀態可修改。pure 方法不會從執行環境中讀取數據，也不能讀取或寫入持久性存儲；也就是說，給定相同的輸入，pure 方法將始終返回相同的輸出，它們不會產生副作用。view 方法可以從持久性存儲或執行環境中讀取數據，但它們不能寫入持久性存儲，也不能創建副作用，例如附加事務日志。payable 方法可以讀寫持久性存儲，從執行環境中讀取數據，產生副作用，並且可以接收附加在調用中的 ETH。non-payable 方法與 payable 方法相同，但具有運行時檢查，以斷言當前執行上下文中沒有附加 ETH。

注意：將 ETH 附加到交易中與支付 Gas 費用是分开的，附加的 ETH 由合約接收，可以通過恢復上下文選擇接受或拒絕它。

在合約的範圍內聲明時，方法可以指定以下四種可見性修飾符：private、internal、public 或 external。private 方法可以通過當前合約內的「jump」指令在內部訪問。任何繼承的合約都不能直接訪問 private 方法。internal 方法也可以通過「jump」指令在內部訪問，但繼承的合約可以直接使用內部方法。public 方法可以通過「call」指令由外部合約訪問，創建一個新的執行上下文，並在直接調用方法時通過跳轉進行內部訪問。public 方法也可以通過在方法調用前加上「this.」來在新的執行上下文中從同一合約中訪問。external 方法只能通過「call」指令訪問，無論是來自不同的合約還是在同一合約內，都需要在方法調用前加上「this.」。

注意：「jump」指令操作程序計數器，「call」指令爲目標合約的執行期間創建一個新的執行上下文。在可能的情況下，使用「jump」而不是「call」更加節約 Gas。

Solidity 還提供了三種定義庫的方式。第一種是外部庫，它是一個無狀態的合約，單獨部署到鏈上，在調用合約時動態鏈接，並通過「delegatecall」指令訪問。這是最不常見的方法，因爲外部庫的工具支持不足，「delegatecall」很昂貴，它必須從持久存儲中加載額外的代碼，並且需要多個事務進行部署。內部庫的定義方式與外部庫相同，只是每個方法必須定義爲內部方法。在編譯時，內部庫被嵌入到最終合約中，並且在死代碼分析階段，庫中未使用的方法將被刪除。第三種方式與內部庫類似，但不是在庫內定義數據結構和功能，而是在文件級別定義，並且可以直接導入和在最終合約中使用。第三種方法提供了更好的人機交互性，可以使用自定義數據結構，將函數應用於全局作用域中，並一定限程度上將別名運算符應用於某些函數。

編譯器提供兩個優化通道。第一個是指令級優化器，對最終的字節碼執行優化操作。第二個是近期增加使用 Yul 語言（稍後詳細介紹）作爲編譯過程中的中間表示（IR），然後對生成的 Yul 代碼進行優化操作。

爲了與合約中的公共和外部方法交互，Solidity 規定了一種應用程序二進制接口（ABI）標准來與其合約交互。目前，Solidity ABI 被視爲 EVM DSL 的事實標准。指定外部接口的以太坊 ERC 標准都按照 Solidity 的 ABI 規範和風格指南來執行。其他語言也遵循 Solidity 的 ABI 規範，很少出現偏差。

Solidity 還提供了內聯 Yul 塊，允許對 EVM 指令集進行低級別訪問。Yul 塊包含 Yul 功能的子集，詳細信息請參見 Yul 部分。這通常用於進行 Gas 優化，利用高級語法不支持的功能，並自定義存儲、內存和 calldata。

由於 Solidity 的流行，开發人員工具非常成熟且設計精良，Foundry 是在這方面突出的代表。

以下是用 Solidity 編寫的一個簡單合約：

Vyper

Vyper 是一種語法類似於 Python 的高級語言。它幾乎是 Python 的一個子集，只有一些小的不同。它是第二受歡迎的 EVM DSL。Vyper 針對安全性、可讀性、審計能力和 Gas 效率進行了優化。它不採用面向對象模式、內聯匯編，並且不支持代碼重用。它的編譯器是用 Python 編寫的。

存儲在持久性存儲器中的變量是在文件級別聲明的。如果它們的值在編譯時已知，可以將它們聲明爲「constant（常量）」；如果它們的值在部署時已知，則可以將它們聲明爲「immutable（不變量）」；如果它們被標記爲 public，則最終合約將爲該變量公开一個只讀函數。常量和不變量的值通過它們的名稱在內部訪問，但是持久性存儲器中的可變量可以通過在名稱前面添加「self.」來訪問。這對於防止存儲變量、函數參數和局部變量之間的命名空間衝突非常有用。

和 Solidity 類似，Vyper 也使用函數屬性來表示函數的可見性和可變性。被標記爲「@external」的函數可以通過「call」指令從外部合約訪問。被標記爲「@internal」的函數只能在同一合約中訪問，並且必須以「self.」爲前綴。被標記爲「@pure」的函數不能從執行環境或持久存儲中讀取數據，也不能寫入持久存儲或創建任何副作用。被標記爲「@view」的函數可以從執行環境或持久存儲中讀取數據，但不能寫入持久存儲或創建副作用。被標記爲「@payable」的函數可以讀取或寫入持久存儲，創建副作用，接受收 ETH。沒有聲明這個可變性屬性的函數默認爲 non-payable，也就是說，它們和 payable 函數一樣，但不能接收 ETH。

Vyper 編譯器還選擇將局部變量存儲在內存中而不是堆棧上。這使得合約更加簡單和高效，並解決了其他高級語言中常見的「堆棧過深」的問題。但是，這也帶來了一些折衷。

另外，由於內存布局必須在編譯時知道，因此動態類型的最大容量也必須在編譯時知道，這是一個限制。此外，分配大量內存會導致非线性的 Gas 消耗，正如 EVM 概述部分中提到的。但是，對於許多用例來說，這個 Gas 成本可以忽略不計。

雖然 Vyper 不支持內聯匯編，但它提供了更多內置函數，以確保幾乎每個 Solidity 和 Yul 中的功能在 Vyper 中也可以實現。通過內置函數可以訪問低級位運算、外部調用和代理合約操作，通過編譯時提供覆蓋文件可以實現自定義存儲布局。

Vyper 沒有豐富的的开發工具套件，但它有更緊密集成的工具，並且也可以插入到 Solidity 开發工具中。值得關注的 Vyper 工具包括 Titanaboa 解釋器，它具有許多與 EVM 和 Vyper 相關的內置工具，可用於實驗和开發，以及 Dasy，一種基於 Vyper 的 Lisp，具有編譯時代碼執行功能。

下面是用 Vyper 編寫的一個簡單合約：

Fe

Fe 是一種類似 Rust 的高級語言，目前正在積極开發中，大部分功能尚未推出。它的編譯器主要用 Rust 編寫，但使用 Yul 作爲其中間表示形式（IR），依賴於用 C++ 編寫的 Yul 優化器。隨着 Rust 原生後端 Sonatina 的加入，這一點有望改變。Fe 使用模塊進行代碼共享，因此不使用面向對象的模式，而是通過基於模塊的系統重用代碼，在模塊內聲明變量、類型和函數，可以以類似於 Rust 的方式進行導入。

持久存儲變量在合約級別聲明，如果沒有手動定義的 getter 函數則不可公开訪問。常量可以在文件或模塊級別聲明，並且可以在合約內部訪問。當前不支持不可變的部署時變量。

方法可以在模塊級別或合約內聲明，默認是 pure 和 private。要使合約方法公开，必須在定義前加上「pub」關鍵字，這使得它可以在外部訪問。要從持久化存儲變量中讀取，方法的第一個參數必須是「self」，在變量名前加上「self.」，使該方法具有只讀訪問本地存儲變量的權限。要讀取和寫入持久化存儲，第一個參數必須是「mut self」。「mut」關鍵字表示合約的存儲在方法執行期間是可變的。訪問環境變量是通過將「Context」參數傳遞給方法來完成的，通常命名爲「ctx」。

函數和自定義類型可以在模塊級別聲明。默認情況下，模塊項都是私有的，除非加上「pub」關鍵字才能訪問。但是，不要和合約級別的「pub」關鍵字混淆。模塊的公共成員只能在最終合約或其他模塊內部訪問。

Fe 暫時不支持內聯匯編，相反，指令由編譯器內部函數或在編譯時解析爲指令的特殊函數包裝。

Fe 遵循 Rust 的語法和類型系統，支持類型別名、帶有子類型的枚舉、特徵和泛型。目前這方面的支持還有限，但正在進行中。特徵可以針對不同類型進行定義和實現，但不支持泛型，也不支持特徵約束。枚舉支持子類型，並可以在其上實現方法，但不能在外部函數中對其進行編碼。盡管 Fe 的類型系統仍在發展中，但它在爲开發人員編寫更安全、編譯時檢查的代碼方面顯示出了很大的潛力。

下面是用 Fe 編寫的一個簡單的合約：

Huff

Huff 是一種匯編語言，具有手動堆棧控制和對 EVM 指令集的最小化抽象。通過「#include」指令，編譯時可以解析任何包含的 Huff 文件，從而實現代碼重用。最初由 Aztec 團隊編寫用於極度優化的橢圓曲线算法，編譯器後來被用 TypeScript 重寫，然後又被用 Rust 重寫。

常量必須在編譯時定義，目前不支持不可變量，並且語言中沒有顯式定義持久性存儲變量。由於命名存儲變量是高級抽象，因此在 Huff 中寫入持久性存儲是通過操作碼 「sstore」 寫入和 「sload」讀取。自定義存儲布局可以由用戶定義，也可以按照慣例從零开始並且每個變量遞增使用編譯器內在的「FREE_STORAGE_POINTER」。使存儲變量外部可訪問需要手動定義一個可以讀取並返回變量給調用者的代碼路徑。

外部函數也是高級語言引入的抽象，因此在 Huff 中沒有外部函數的概念。但是，大多數項目在不同程度上遵循其他高級語言的 ABI 規範，最常見的是 Solidity。一個常見的模式是定義一個「調度程序」，加載原始調用數據並使用它來檢查是否匹配函數選擇器。如果匹配，則執行其後續代碼。由於調度程序是用戶定義的，因此它們可能遵循不同的調度模式。Solidity 按名稱字母順序對其調度程序中的選擇器進行排序，Vyper 按數字順序排序並在運行時執行二進制搜索，大多數 Huff 調度程序按預期的函數使用頻率排序，很少使用跳轉表。目前，跳轉表在 EVM 中不被原生支持，因此需要使用類似「codecopy」的內省指令才能實現。

內部函數使用「#define fn」指令定義，可以接受模板參數以提高靈活性，並指定函數开始和結束時的預期堆棧深度。由於這些函數是內部的，因此無法從外部訪問，在內部訪問需要使用「jump」指令。

其他控制流程，例如條件語句和循環語句可以使用跳轉目標定義。跳轉目標是由標識符後跟冒號定義的。可以通過將標識符壓入堆棧並執行跳轉指令來跳轉到這些目標。這在編譯時解析爲字節碼偏移量。

宏由「#define macro」定義，其他方面與內部函數相同。關鍵區別在於宏不會在編譯時生成「jump」指令，而是將宏的主體直接復制到文件中的每個調用中。

這種設計權衡了減少任意跳轉與運行時 Gas 成本之間的關系，代價是調用多次時代碼的大小增加。「MAIN」 宏被視爲合約的入口，並且其主體中的第一條指令將成爲運行時字節碼中的第一條指令。

編譯器內置的其他特性還包括爲日志記錄生成事件哈希、爲調度生成函數選擇器、爲錯誤處理生成錯誤選擇器以及內部函數和宏的代碼大小檢查器等。

注意：「// [count]」之類的堆棧注釋不是必需的，它們只是用於指示該行執行結束時的堆棧狀態。

下面是用 Huff 編寫的一個簡單合約：

ETK

EVM 工具包（ETK）是一種具有手動堆棧管理和最小化抽象的匯編語言。代碼可以通過「%include」和「%import」指令進行重用，編譯器是用 Rust 編寫的。

Huff 和 ETK 之間的一個顯着區別是，Huff 爲 initcode 添加了輕微的抽象，也稱爲構造函數代碼，這些代碼可以通過定義特殊的「CONSTRUCTOR」宏來覆蓋。在 ETK 中，這些不會被抽象化，initcode 和運行時代碼必須一起定義。

與 Huff 類似，ETK 通過「sload」和「sstore」指令讀寫持久性存儲。然而，沒有常量或不可變關鍵字，但是可以使用 ETK 中的兩種宏之一來模擬常量，即表達式宏。表達式宏不會解析爲指令，而是生成可用於其他指令中的數字值。例如，它可能不會完全生成「push」指令，但可能會生成一個數字以包含在「push」指令中。

如前所述，外部函數是高級語言概念，因此在外部公开代碼路徑需要創建函數選擇器調度程序。

內部函數不像其他語言那樣可以顯式定義，而是可以爲跳轉目標指定用戶定義的別名，並通過其名稱跳轉到它們。這也允許其他控制流，例如循環和條件語句。

ETK 支持兩種宏。第一種是表達式宏，可以接受任意數量的參數並返回可用於其他指令的數字值。表達式宏不生成指令，而是生成立即值或常量。然而，指令宏接受任意數量的參數，並在編譯時生成任意數量的指令。ETK 中的指令宏類似於 Huff 宏。

下面是 ETK 用編寫的一個簡單合約：

Yul

Yul 是一種具有高級控制流和大量抽象的匯編語言。它是 Solidity 工具鏈的一部分，並可以選擇在 Solidity 編譯通道中使用。 Yul 不支持代碼重用，因爲它旨在成爲編譯目標而不是獨立語言。它的編譯器是用 C++ 編寫的，計劃將其與 Solidity 通道的其余部分一起遷移到 Rust。

在 Yul 中，代碼被分成對象，這些對象可以包含代碼、數據和嵌套對象。因此，Yul 中沒有常量或外部函數。需要定義函數選擇器調度程序才能將代碼路徑公开到外部。

除了堆棧和控制流指令外，大多數指令在 Yul 中都作爲函數公开。指令可以嵌套以縮短代碼長度，也可以分配給臨時變量，然後傳遞給其他指令使用。條件分支可以使用「if」塊，如果值爲非零，則執行該塊，但沒有「else」塊，因此處理多個代碼路徑需要使用「switch」處理任意數量的情況和「default」後備選項。循環可以使用「for」循環執行；雖然其語法與其他高級語言不同，但提供了相同的基本功能。可以使用「function」關鍵字定義內部函數，並且與高級語言的函數定義類似。

Yul 中的大多數功能在 Solidity 中使用內聯匯編塊公开。這允許开發人員打破抽象，編寫自定義功能或在高級語法中不可用的功能中使用 Yul。但是，使用此功能需要深入了解 Solidity 在 calldata、memory 和 storage 方面的行爲。

還有一些獨特的函數。 「datasize」，「dataoffset」和「datacopy」函數通過其字符串別名操作 Yul 對象。 「setimmutable」和「loadimmutable」函數允許在構造函數中設置和加載不可變參數，盡管它們的使用受到限制。 「memoryguard」函數表示只分配給定的內存範圍，從而使編譯器可以使用超出保護範圍的內存進行附加優化。最後，「verbatim」允許使用 Yul 編譯器不知道的指令。

下面是用 Yul 編寫的一個簡單合約：

優秀 EVM DSL 的特性

一個優秀的 EVM DSL 應該從這裏列出的每種語言的優缺點中學習，還應該包括幾乎所有現代語言中的基礎，如條件語句、模式匹配、循環、函數等等。代碼應該是明確的，爲了代碼美觀或可讀性而添加最少的隱式抽象。在高風險、正確性至關重要的環境中，每行代碼都應該是明確可解釋的。此外，一個定義良好的模塊系統應該是任何偉大語言的核心。它應該清楚地說明哪些項定義在哪個作用域中，以及哪些可以訪問。默認情況下，模塊中的每個項都應該是私有的，只有顯式公共項才能在外部公开訪問。

在 EVM 這樣的資源受限環境中，效率很重要。效率通常通過提供低成本的抽象來實現，如通過宏進行編譯時代碼執行，豐富的類型系統來創建設計良好的可重用庫以及常見的鏈上交互包裝器。宏在編譯時生成代碼，這對於減少常見操作的樣板代碼非常有用，在像 Huff 這樣的情況下，它可用於在代碼大小與運行時效率之間進行權衡。豐富的類型系統允許更具表現力的代碼、更多的編譯時檢查以在運行時之前捕獲錯誤，並且當與類型檢查的編譯器內部函數結合使用時，可能會消除大部分內聯匯編的需求。泛型還允許可空值（例如外部代碼）被包裝在「選項」類型中，或者易出錯的操作（例如外部調用）被包裝在「結果」類型中。這兩種類型是庫編寫者如何通過定義代碼路徑或恢復失敗結果的事務來強制开發人員處理每個結果的示例。然而，請記住，這些是編譯時抽象，會在運行時解析爲簡單的條件跳轉。強制开發人員在編譯時處理每個結果會增加初始开發時間，但好處是運行時的意外情況要少得多。

靈活性對於开發人員也很重要，因此，雖然復雜操作的默認情況應該是安全且可能不那么高效的路线，但有時需要使用更高效的代碼路徑或不支持的功能。爲此，應該向开發人員开放內聯匯編，而且沒有護欄。Solidity 的內聯匯編爲了簡單和更好的優化器傳遞設置了一些護欄，但是當开發人員需要完全控制執行環境時，他們應該被授予這些權利。

一些可能有用的功能包括可以在編譯時操作函數和其他項的屬性。例如，「inline」屬性可以將簡單函數的主體復制到每個調用中，而不是爲了效率創建更多的跳轉。而「abi」屬性可以允許手動覆蓋給定外部函數生成的 ABI，以適應不同代碼風格的語言。此外，還可以定義一個可選的函數調度器，允許在高級語言內進行定制，以便對預期更常用的代碼路徑進行額外的優化。例如，在執行「name」之前檢查選擇器是否爲「transfer」或「transferFrom」。

結論

EVM DSL 設計任重而道遠。每種語言都有自己獨特的設計決策，我期待看到它們在未來如何發展。作爲开發人員，學習盡可能多的語言符合我們的最大利益。首先，學習多種語言並了解它們的不同之處和相似之處將加深我們對編程和底層機器體系結構的理解。其次，語言具有深遠的網絡效應和強大的保留特性。毫無疑問，大型參與者都在構建自己的編程語言，從 C#、Swift 和 Kotlin 到 Solidity、Sway 和 Cairo。學習在這些語言之間無縫切換爲軟件工程職業提供了無與倫比的靈活性。最後，重要的是要了解每一種語言背後都需要付出大量的工作。沒有人是完美的，但無數有才華的人付出了大量努力，爲像我們這樣的开發者創造安全愉快的體驗。

來源：DeFi之道

標題：剖析六種 EVM 語言：優秀的語言要如何設計

地址：https://www.coinsdeep.com/article/11527.html

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。