除了 Solidity，還有哪些值得關注的 EVM 語言？_LID:DIT

作者：jtriley.ethjtriley.eth

編譯：0x11?，ForesightNews

以太坊虛擬機(EVM)是一個256位、基于堆棧、全球可訪問的圖靈機。由于架構與其他虛擬機和物理機的明顯不同，EVM需要領域特定語言DSL。

在本文中，我們將研究EVMDSL設計的最新技術，介紹六種語言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」，只是它會保留先前上下文的一些環境信息。這通常用于外部庫和代理合約。

為什么語言設計很重要

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

DeFIL社區聯合發起人：DeFIL2.0除了部署以太坊外，還將部署BSC鏈:據官方消息，6月30日21時，《DeFIL——去中心化的Filecoin借貸金融服務平臺》AMA直播結束。在一個小時的直播過程中，Marvin圍繞“DeFIL項目1.0的成就回顧、DFL二級市場的表現、DeFIL2.0的重大升級、標準算力通證FILST及應用場景、未來技術升級路線”等方面做了詳盡闡述。Marvin還表示，DeFIL2.0除了部署以太坊外，還將部署BSC鏈，未來會陸續部署于多鏈，在不同生態為用戶獲取價值。[2021/6/30 0:18:02]

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

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

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

語言概覽

對于每種語言，我們將描述它們的顯著特性和設計選擇，并包括一個簡單的計數功能智能合約。言語流行度是根據DefiLlama上的總鎖定價值(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.」。

王純：比特幣減半除了挖礦收益，也需要關注網絡安全性:在今日金色財經聯合魚池舉行主題為《算力變動下如何尋找更多收益》的線上直播中，F2Pool聯合創始人、stakefish創始人兼CEO王純指出，5月份的減半將讓存量比特幣進一步減少，目前挖出的幣超過87%，隨著此后更次的區塊獎勵減半，礦工幣本位收益繼續減小，更擔心這對比特幣網絡安全方面的影響。比如在挖礦收益今后進一步減小。應對大額手續費區塊，網絡是否會存在反復打包區塊的情況。減半的同時，比特幣網絡安全性也值得我們關注。[2020/4/15]

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

Solidity還提供了三種定義庫的方式。第一種是外部庫，它是一個無狀態的合約，單獨部署到鏈上，在調用合約時動態鏈接，并通過「delegatecall」指令訪問。這是最不常見的方法，因為外部庫的工具支持不足，「delegatecall」很昂貴，它必須從持久存儲中加載額外的代碼，并且需要多個事務進行部署。內部庫的定義方式與外部庫相同，只是每個方法必須定義為內部方法。

在編譯時，內部庫被嵌入到最終合約中，并且在死代碼分析階段，庫中未使用的方法將被刪除。第三種方式與內部庫類似，但不是在庫內定義數據結構和功能，而是在文件級別定義，并且可以直接導入和在最終合約中使用。第三種方法提供了更好的人機交互性，可以使用自定義數據結構，將函數應用于全局作用域中，并一定限程度上將別名運算符應用于某些函數。

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

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

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

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

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

Vyper

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

CCN分析師：“ETH不是證券”的決定消除了行業的不確定性:CCN分析師轉發scalar capital聯合創始人Jordan Clifford消息——很高興看到ETH不是證券。這消除了行業的不確定性, 為更多的金融產品鋪平了道路。與傳統金融系統友好的做法并不受加密貨幣愛好者的歡迎，但必須要達到一定規模。[2018/6/15]

存儲在持久性存儲器中的變量是在文件級別聲明的。如果它們的值在編譯時已知，可以將它們聲明為「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編寫的一個簡單合約：

以太坊經典已經正式移除了所謂的“難度炸彈”:以太坊經典已經正式移除了所謂的“難度炸彈”，即旨在隨著時間推移增加挖礦難度的代碼。根據網絡數據和參與項目開發人員的聲明，ETC這次成功網絡更改發生于區塊高度5900000。這次升級預計將減少創建區塊所需的時間。[2018/5/30]

Fe

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

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

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

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

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

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

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

Huff

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

遠望資本田鴻飛：除了比特幣，我還沒看到任何成功的區塊鏈商業應用:田鴻飛：我覺得現在大量區塊鏈應用不是大規模商用的問題，除比特幣之外我還沒看到任何一個區塊鏈應用有商業價值，大家都在講故事。大多數All in區塊鏈的人還處于「覺得這東西真好」的階段，也許過了今年，等到今年底或者明年初，對于投資可能是一個不錯的進入時間點，因為今年底可能大多數All in區塊鏈的人就會沒信心了。[2018/4/21]

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

外部函數也是高級語言引入的抽象，因此在Huff中沒有外部函數的概念。但是，大多數項目在不同程度上遵循其他高級語言的ABI規范，最常見的是Solidity。一個常見的模式是定義一個「調度程序」，加載原始調用數據并使用它來檢查是否匹配函數選擇器。如果匹配，則執行其后續代碼。由于調度程序是用戶定義的，因此它們可能遵循不同的調度模式。

Solidity按名稱字母順序對其調度程序中的選擇器進行排序，Vyper按數字順序排序并在運行時執行二進制搜索，大多數Huff調度程序按預期的函數使用頻率排序，很少使用跳轉表。目前，跳轉表在EVM中不被原生支持，因此需要使用類似「codecopy」的內省指令才能實現。

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

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

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

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

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

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

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

ETK

EVM工具包是一種具有手動堆棧管理和最小化抽象的匯編語言。代碼可以通過「%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編寫的一個簡單合約：

優秀EVMDSL的特性

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

在EVM這樣的資源受限環境中，效率很重要。效率通常通過提供低成本的抽象來實現，如通過宏進行編譯時代碼執行，豐富的類型系統來創建設計良好的可重用庫以及常見的鏈上交互包裝器。宏在編譯時生成代碼，這對于減少常見操作的樣板代碼非常有用，在像Huff這樣的情況下，它可用于在代碼大小與運行時效率之間進行權衡。

豐富的類型系統允許更具表現力的代碼、更多的編譯時檢查以在運行時之前捕獲錯誤，并且當與類型檢查的編譯器內部函數結合使用時，可能會消除大部分內聯匯編的需求。泛型還允許可空值被包裝在「選項」類型中，或者易出錯的操作被包裝在「結果」類型中。這兩種類型是庫編寫者如何通過定義代碼路徑或恢復失敗結果的事務來強制開發人員處理每個結果的示例。然而，請記住，這些是編譯時抽象，會在運行時解析為簡單的條件跳轉。強制開發人員在編譯時處理每個結果會增加初始開發時間，但好處是運行時的意外情況要少得多。

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

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

結論

EVMDSL設計任重而道遠。每種語言都有自己獨特的設計決策，我期待看到它們在未來如何發展。作為開發人員，學習盡可能多的語言符合我們的最大利益。首先，學習多種語言并了解它們的不同之處和相似之處將加深我們對編程和底層機器體系結構的理解。

其次，語言具有深遠的網絡效應和強大的保留特性。毫無疑問，大型參與者都在構建自己的編程語言，從C#、Swift和Kotlin到Solidity、Sway和Cairo。學習在這些語言之間無縫切換為軟件工程職業提供了無與倫比的靈活性。最后，重要的是要了解每一種語言背后都需要付出大量的工作。沒有人是完美的，但無數有才華的人付出了大量努力，為像我們這樣的開發者創造安全愉快的體驗。

Tags：LIDSOLSOLIDDITVSolidusSOLR幣WeSendit

酷幣下載