一文盤點6種EVM編程語言

作者：jtriley.ethjtriley.eth

編譯：0x11，Foresight News

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

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

語言版本

1、Solidity: 0.8.19

2、Vyper: 0.3.7

3、Fe: 0.21.0

4、Huff: 0.3.1

5、ETK: 0.2.1

6、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。學習在這些語言之間無縫切換為軟件工程職業提供了無與倫比的靈活性。最後，重要的是要了解每一種語言背後都需要付出大量的工作。沒有人是完美的，但無數有才華的人付出了大量努力，為像我們這樣的開發者創造安全愉快的體驗。