分析以太坊虚拟机各语言设计

发表评论
65,995 views

A+

所属分类：oracle

以太坊虚拟机（EVM）是一台 256 位、基于堆栈、全局可访问的图灵机。由于其与其他虚拟和物理机器架构存在明显差异，领域特定语言（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、堆栈机器和编程的基本理解。

如前所述，EVM 是一台 256 位基于堆栈的图灵机。然而，在深入讨论针对其的编译器之前，应介绍一些功能。

由于 EVM 是“图灵完备”的，它受到“停机问题”的困扰。简而言之，这意味着在执行程序之前无法确定程序将来是否会终止。在 EVM 中解决这个问题的方法是通过“gas”来计量计算单元，通常与执行指令所需的物理资源成正比。每个交易的 gas 数量是有限的，交易发起者必须支付与交易期间消耗的 gas 成比例的以太币。这个决定的许多影响之一是，如果有两个功能上相同的智能合约，但其中一个在执行相同任务时的 gas 消耗较少，那么有经济激励使用更有效率的合约。这导致协议竞争极致的 gas 效率，工程师围绕最小化特定任务的 gas 消耗形成个人品牌（包括我自己）。

此外，当调用合约时，它会创建一个执行上下文。在此上下文中，合约有一个堆栈用于操作，一个线性内存实例用于读写，一个本地持久存储用于读写，以及附加到调用的数据“calldata”，可以读取但不能写入。

关于内存的一个重要说明是，尽管其大小不是确定性“上限”，但仍然是有限的。扩展内存的 gas 成本是动态的；一旦达到阈值，扩展内存的成本是二次的，也就是说，gas 成本与额外内存分配的平方成正比。

合约还可以使用几种不同的指令调用其他合约。“call”指令将数据发送到目标合约，可选择发送以太币，然后目标合约创建自己的执行上下文，该上下文持续到目标合约的执行停止。“staticcall”指令与“call”相同，但增加了一个检查，确保全局状态在静态调用完成之前不会更新。“delegatecall”指令的行为类似于“call”，但保留了先前上下文的一些环境信息。通常用于外部库和代理合约。

为什么语言设计很重要

智能合约 DSL 对于与非典型架构交互是必不可少的，虽然存在编译器工具链（如 LLVM），但依赖它们进行智能合约编程，其中程序正确性和计算效率至关重要，不是最理想的选择。

程序正确性至关重要，因为智能合约默认是不可变的，鉴于区块链虚拟环境（VM）的特性，智能合约是金融应用的热门选择。虽然在 EVM 内存在升级性解决方案，但这只是一个权宜之计，最坏情况下可能存在任意代码执行漏洞。

如上所述，计算效率也至关重要，因为最小化计算具有经济优势，但不能以牺牲安全性为代价。

简而言之，EVM DSL 必须在程序正确性和 gas 效率之间取得平衡，每种都做出不同的权衡，以实现其中一种而不牺牲太多灵活性。

语言概述

对于每种语言，我们将描述显著特性和设计选择，并包括一个简单的智能合约，用于跟踪和增加可在外部读取的“计数”值。在适用的情况下，语言流行度是根据 Defi Llama 的总锁定价值（TVL）统计确定的。

Solidity

Solidity 是一种高级语言，其语法类似于 C、Java 和 Javascript。它是 TVL 最高的语言，比下一个 EVM DSL 领先了十倍。为了代码重用，它使用面向对象的模式，其中智能合约被视为利用多重继承的类对象。编译器是用 C++编写的，计划在未来版本中迁移到 Rust。

合约变量字段存储在持久存储中，除非它们的值在编译时（常量）或部署时（不可变）已知。方法在合约范围内定义，可以声明为 pure、view、payable(可支付方法)，或默认为非支付但修改状态。pure 方法不从执行环境中读取，也不读取或写入持久存储；也就是说，给定相同的输入，pure 方法将始终返回相同的输出，并且永远不会产生副作用。view 方法可以从持久存储或执行环境中读取，但不能写入持久存储，也不能产生附加事务日志等副作用。可支付方法可以读取和写入持久存储，从执行环境中读取，产生副作用，并可以接收可选附加到调用的以太币。非支付方法与可支付方法相同，但运行时检查以确保当前执行上下文中没有附加以太币。

注意：将以太币附加到交易与支付 gas 费用是分开的，附加的以太币由合约接收，可以选择接受或拒绝通过还原上下文。

方法还可以在声明为合约范围内时指定四种可见性修饰符之一；它们可以是 private、internal、public 或 external。私有方法通过当前合约内部的“跳转”指令进行访问。任何继承的合约都不能直接访问私有方法。内部方法也可以通过跳转指令在内部访问，但继承的合约可以直接使用内部方法。公共方法可以通过“call”指令由外部合约访问，创建一个新的执行上下文，当直接调用方法时，可以通过跳转访问内部。公共方法也可以通过在方法调用前加上“this.”来在新的执行上下文中从同一合约访问“call”调用的方法。外部方法只能通过“call”指令访问，无论是从不同合约还是同一合约内部，都需要在要调用的方法前加上“this.”。

注意：“跳转”指令操作程序计数器，“call”指令为目标合约的执行持续创建一个新的执行上下文。在可能的情况下，使用跳转而不是调用更加节省 gas。

Solidity 还提供了可以以三种方式定义的库。首先是外部库，这是一个无状态合约，单独部署到链上，动态链接到调用合约，并通过“delegatecall”指令访问。这是最不常见的方法，因为外部库周围的工具不足，由于必须从持久存储加载额外代码，“delegatecall”是昂贵的，并且需要多个交易进行部署。内部库的定义方式与外部库相同，只是每个方法必须定义为内部方法。在编译时，内部库嵌入到最终合约中，并且在死代码分析阶段删除了库中未使用的方法。第三种方式类似于内部库，但不是在库块中定义数据结构和功能，而是在文件级别定义，并且可以直接导入和在最终合约中使用。第三种方法提供更好的人机工程学，具有自定义数据结构，将函数应用于全局范围内的结构，并且在一定程度上，将别名操作符用于某些函数。编译器提供了两种优化流水线。首先是指令级优化器，它对最终的字节码执行优化传递。第二种更近期的添加使用 Yul 语言（稍后详细介绍）作为编译过程中的中间表示（IR），然后对生成的 Yul 代码执行优化传递。

为了与合约中的公共和外部方法进行交互，Solidity 为与其合约进行交互指定了一个应用二进制接口（ABI）标准。在撰写本文时，Solidity ABI 被视为 EVM DSL 的事实标准。以 Solidity 的 ABI 规范和样式指南为依据，规范了指定外部接口的以太坊请求评论（ERC）标准。其他语言往往遵循 Solidity 的 ABI 规范，很少有细微的偏差。

Solidity 还提供了内联的 Yul 块，允许对 EVM 指令集进行低级访问。Yul 块包含 Yul 部分详细介绍的 Yul 功能的子集。这通常用于 gas 优化，利用高级语法不支持的功能，并自定义存储、内存和 calldata 的布局。

由于 Solidity 的流行，开发者工具非常成熟且设计良好。Foundry 是一款在这方面特别突出的工具。

在 Solidity 中，一个简单的合约可以定义如下：

// SPDX-License-Identifier: MIT
pragma solidity 0.8.19;

contract CountTracker {
   uint256 public count;

  function increment() external {
    count += 1;
  }
}

Vyper

Vyper 是一种具有类似 Python 语法的高级语言。它几乎是 Python 的子集，只有少数几个细微的例外。在撰写本文时，Vyper 是第二受欢迎的 EVM DSL。Vyper 优化了安全性、可读性、可审计性和 gas 效率。它放弃了面向对象的模式、内联汇编，并且在撰写本文时不支持代码重用。编译器是用 Python 编写的。

存储在持久存储中的变量在文件级别声明。如果它们的值在编译时已知，可以将它们声明为“constant”，如果它们的值在部署时已知，可以将它们声明为“immutable”，如果它们标记为 public，则最终合约将为该变量公开一个只读函数。通过它们的名称在内部访问常量和不可变值，但是持久存储中的可变变量可以通过在变量名前加上“self.”来访问。这对于防止存储变量、函数参数和局部变量之间的命名空间冲突非常有用。

函数的定义方式与 Solidity 类似，但采用 Python 风格的语法，选择使用函数属性来指示可见性和可变性。标记为“@external”的函数可以通过“call”指令从外部合约访问。标记为“@internal”的函数只能从同一合约内部访问，并且必须以“self.”为前缀。标记为“@pure”的函数不得从执行环境或持久存储中读取，也不得写入持久存储或创建任何副作用。标记为“@view”的函数可以从执行环境或持久存储中读取，但不得写入持久存储或创建副作用。标记为“@payable”的函数可以读取或写入持久存储，创建副作用，从执行环境中读取，并且可以接收附加在调用中的以太币。没有可变性属性的函数是不可支付的，也就是说，它们与可支付函数相同，但没有接收以太币的能力。

Vyper 编译器还选择将本地变量存储在内存中，而不是堆栈上。这使得合约更简单、通常更高效，并修复了其他高级语言中常见的错误，“堆栈过深”错误。然而，这也带来了一些权衡。

首先，由于内存布局必须在编译时知道，动态类型的最大容量也必须在编译时知道。此外，大内存分配会导致非线性的 gas 消耗，如 EVM 概述部分所述。然而，对于许多用例来说，这种 gas 成本仍然可以忽略不计。

虽然 Vyper 不支持内联汇编，但它通过内置函数实现了更多功能，以确保几乎所有 Solidity 和 Yul 中的功能在 Vyper 中也是可访问的。通过内置函数和提供编译时覆盖文件，可以访问低级位操作、外部调用和代理合约操作，并且可以自定义存储布局。

虽然 Vyper 没有如此广泛的开发者工具套件，但 Vyper 具有更紧密集成的工具，并且也可以插入到 Solidity 的开发者工具中。值得注意的 Vyper 工具包括 Titanaboa 解释器，其中包含许多用于 EVM 和 Vyper 相关实验和开发的内置工具，以及 Dasy，一个建立在 Vyper 之上的 Lisp，具有编译时代码执行功能。

在 Vyper 中，一个简单的合约可以定义如下：

# @version 0.3.7

counter: public(uint256)

@external
def increment():
  self.counter += 1

Fe

Fe 是一种具有类似 Rust 语法的高级语言。目前正在积极开发中，大多数功能尚未推出。编译器主要用 Rust 编写，但它使用 Yul 作为其 IR，依赖于目前用 C++ 编写的 Yul 优化器。随着包含其 Rust 本机后端 Sonatina 的加入，这种情况有望改变。Fe 使用模块进行代码共享，因此不使用面向对象的模式，而是通过基于模块的系统重用代码，其中变量、类型和函数在模块内声明，并且可以以类似 Rust 的方式导入。

持久存储变量在合约级别声明，没有手动定义的 getter 函数，无法公开访问。常量可以在文件或模块级别声明，并且在合约内部可访问。目前不支持不可变、部署时变量。

方法可以在模块级别或合约内声明。默认情况下，它们是纯的和私有的。要使合约方法公开，其定义必须以“pub”关键字为前缀。这使其可以从外部访问。要从持久存储变量中读取，方法中的第一个参数必须是“self”，这使方法通过在变量名前加上“self.”来访问任何本地存储变量。要读取和写入持久存储，第一个参数必须是“mut self”。"mut" 关键字表示合约的存储在方法执行期间是可变的。通过传递方法“Context”参数来访问环境变量。通常命名为“ctx”，上下文类型实现了读取执行环境值的方法。

函数和自定义类型可以在模块级别声明。默认情况下，模块项都是私有的，除非以“pub”关键字为前缀才能访问。这不应与合约级别的“pub”关键字混淆。模块的公共成员只能在最终合约或其他模块内部访问。

在撰写本文时，不支持内联汇编，而是通过编译器内部函数包装指令，或者在编译时解析为指令的特殊函数。Fe 打算遵循 Rust 的语法以及其类型系统，实现类型别名、具有子类型的枚举、特征和泛型。目前，Fe 的这些功能还有限，但正在开发中。特征可以为不同类型定义和实现，但不支持泛型，也不支持特征约束。枚举支持子类型，并且可以在其上实现方法，但无法在外部函数中对其进行编码。尽管 Fe 的类型系统仍在发展中，但它显示出为开发人员编写更安全且在编译时检查的代码的潜力。

在 Fe 中，一个简单的合约可以定义如下：

contract CountTracker {
    count: u256

    pub fn count(self) -&gt; u256 {
        return self.count
    }

    pub fn increment(mut self) {
        self.count += 1
    }
}

Huff

Huff 是一种汇编语言，具有手动堆栈控制和对 EVM 指令集的最小抽象。通过“#include”指令启用代码重用，该指令在编译时解析任何包含的 Huff 文件。最初由 Aztec 团队编写，用于极其优化的椭圆曲线算术，后来编译器被用 Typescript 重写，然后再次用 Rust 重写。

常量必须在编译时定义，不支持不可变量，持久性存储变量在语言中没有明确定义。由于命名存储变量是高级抽象，因此在 Huff 中写入持久性存储是通过使用存储操作码“sstore”进行的写入，使用“sload”进行读取。自定义存储布局可以由用户定义，也可以遵循从零开始并使用“FREE_STORAGE_POINTER”编译器内在函数递增的约定。使存储变量可在外部访问需要手动定义一个能够读取并将变量返回给调用者的代码路径。

外部函数也是高级语言引入的抽象，因此在 Huff 中没有外部函数的概念。然而，大多数项目在很大程度上遵循其他高级语言（最常见的是 Solidity）的 ABI 规范。一个常见模式是定义一个“调度器”，加载原始调用数据并使用它来检查匹配的函数选择器。如果匹配，则执行其后续代码。由于调度器是用户定义的，它们可能遵循不同的调度模式。Solidity 按名称按字母顺序排列其调度器中的选择器，Vyper 按数字顺序排列选择器，并在运行时执行二进制搜索，大多数 Huff 调度器按预期的函数使用频率排序，很少使用跳转表。在撰写本文时，EVM 不原生支持跳转表，因此需要使用“codecopy”等内省指令才能实现这一点。

内部函数使用“#define fn”指令定义，可以接受模板参数以提高灵活性和函数开始和结束时的预期堆栈深度。由于这些函数是内部的，因此无法从外部访问，并且使用“jump”指令与其内部交互。

诸如条件和循环之类的其他控制流可以使用跳转目标定义。跳转目标由标识符后跟冒号定义。可以通过推送标识符并执行跳转指令来跳转到它们。这在编译时解析为字节码偏移量。

宏使用“#define macro”指令定义，除了在语法上与内部函数相同之外。关键区别在于宏不会在编译时生成“jump”指令，而是宏的主体直接复制到文件中的每个调用中。

这样做会在运行时的Gas成本和调用超过一次时的代码大小方面产生权衡。将“MAIN”宏视为合约的入口点，其主体内的第一条指令将成为运行时字节码中的第一条指令。

其他内在编译器内在函数包括用于日志记录的事件哈希生成，用于调度的函数选择器生成，用于错误处理的错误选择器生成以及用于内部函数和宏的代码大小检查器的内省内在函数。

#define constant COUNT_SLOT = FREE_STORAGE_POINTER()

#define macro MAIN() = takes (0) returns (0) {
    0x00 calldataload 0xe0 shr
    dup1 __FUNC_SIG("count") eq is_count jumpi
    dup1 __FUNC_SIG("increment") eq is_increment jumpi
    pop 0x00 dup1 revert

    is_count:
        [COUNT_SLOT]    // [count_slot]
        sload           // [count]
        0x00            // [pointer, count]
        mstore          // []
        msize           // [size]
        0x00            // [pointer, size]
        return          // return to caller

    is_increment:
        [COUNT_SLOT]    // [count_slot]
        sload           // [count]
        0x01            // [one, count]
        add             // [count_plus_one]
        [COUNT_SLOT]    // [count_slot, count_plus_one]
        swap1           // [count_plus_one, count_slot]
        sstore          // []
        stop            // halt execution
}

ETK

EVM 工具包（ETK）是一种具有手动堆栈管理和最小抽象的汇编语言。代码可以通过“%include”和“%import”指令进行重用。编译器是用 Rust 编写的。

Huff 和 ETK 之间的一个显著区别是，Huff 为 initcode（也称为构造函数代码）添加了轻微的抽象，可以通过定义特殊的“CONSTRUCTOR”宏来覆盖它。在 ETK 中，这些不会被抽象化，initcode 和运行时代码必须一起定义。

与 Huff 类似，ETK 通过“sload”和“sstore”指令读取和写入持久性存储。没有常量或不可变关键字，但是在 ETK 中，常量可以通过两种类型的宏之一来模拟，即表达式宏。表达式宏不会解析为指令，而是可以在其他指令中使用的数值。例如，它可能不会完全生成“push”指令，但可能生成一个数字，以便包含在“push”指令中。

如前所述，外部函数是高级语言概念，因此要将代码路径暴露给外部，需要创建一个函数选择器调度器。

内部函数不像其他语言那样明确定义，而是可以为跳转目标指定用户定义的别名，并通过其名称跳转。这也允许其他控制流，如循环和条件。如前所述，ETK 支持两种宏。第一种是表达式宏，可以接受任意数量的参数并返回一个数值，该数值可与其他指令一起使用。表达式宏不生成指令，而是生成立即值或常量值。然而，指令宏接受任意数量的参数，并在编译时生成任意数量的指令。ETK 中的指令宏的行为类似于 Huff 宏的行为。

一个简单的 ETK 合约可以定义如下：

// initcode.etk
%push(end - start)
dup1
%push(start)
returndatasize
codecopy
returndatasize
return

start:
%include(“main.etk”)
end:

// main.etk

%def slot()
    0x00
%end

start:
    push1 0x00
    calldataload
    push1 0xe0
    shr
    dup1
    push4 selector("count()")
    eq
    push1 is_count
    jumpi
    push4 selector("increment()")
    eq
    push1 is_increment
    jumpi
    push1 0x00
    dup1
    revert
    is_count:
        jumpdest
        push1 slot()
        sload
        push1 0x00
        mstore
        msize
        push1 0x00
        return
    is_increment:
        jumpdest
        push1 slot()
        sload
        push1 0x01
        add
        push1 slot()
        sstore
        stop
end:

Yul

Yul 是一种具有高级控制流和大量抽象堆栈管理的汇编语言。它是 Solidity 工具链的一部分，可以选择在 Solidity 编译流程中使用。在 Yul 中不支持代码重用，因为它旨在作为编译目标而不是独立语言。编译器是用 C++编写的，计划随着 Solidity 流水线的其余部分迁移到 Rust。

在 Yul 中，代码被分成可以包含代码、数据和嵌套对象的对象。因此，没有常量或外部函数。需要定义一个函数选择器分发器来公开外部代码路径。

大多数指令，不考虑堆栈和控制流指令，都被公开为 Yul 中的函数。例如，弹出两个值并推送一个值的指令将被包装在一个函数中，该函数接受两个参数并返回一个值。指令可以嵌套以缩短代码，或者可以分配给临时变量，然后传递给其他指令。条件分支可以使用“if”块执行，如果值为非零，则执行，但没有“else”块，因此处理多个代码路径需要一个“switch”，可以处理任意数量的情况和一个“default”备用选项。循环可以使用“for”循环执行；虽然其语法与其他高级语言不同，但提供了相同的基本功能。内部函数可以使用“function”关键字定义，并且类似于高级语言的函数定义。

大多数 Yul 中的功能都可以在 Solidity 中使用内联汇编块暴露出来。这使开发人员可以打破抽象并编写自定义功能或在高级语法中可用之前使用 Yul 中的功能。然而，使用此功能需要深入了解 Solidity 在 calldata、memory 和 storage 方面的行为。

还有一些独特于独立 Yul 方言的函数。“datasize”、“dataoffset”和“datacopy”函数通过它们的字符串别名操作 Yul 对象。“setimmutable”和“loadimmutable”函数允许在构造函数中设置和加载不可变参数，尽管它们的使用受到限制。“linkersymbol”函数允许动态外部库链接。“memoryguard”函数指示编译器只会分配给定内存范围，从而使编译器能够执行更多的内存优化。最后，“verbatim”允许使用 Yul 编译器未知的指令。

一个简单的 Yul 合约可以定义如下：

object "CounterTracker" {
    code {
        let runtimesize := datasize("runtime")
        datacopy(0x00, dataoffset("runtime"), runtimesize)
        return(0x00, runtimesize)
    }
    object "runtime" {
        code {
            switch shr(0xe0, calldataload(0x00))
            case 0x06661abd {
                count()
            }
            case 0xd09de08a {
                increment()
            }
            default {
                revert(0x00, 0x00)
            }

            function count() {
                mstore(0x00, sload(0x00))
                return(0x00, 0x20)
            }

            function increment() {
                sstore(0x00, add(0x01, sload(0x00)))
            }
        }
    }
}

优秀的 EVM DSL 特性

一个优秀的 EVM DSL 应该吸取这里列出的每种语言的优缺点。基础知识包括几乎所有现代语言中的特性，如条件语句、模式匹配、循环、函数等。代码应该明确，最小化隐式抽象通常是为了代码美学或可读性而添加的。在高风险、正确性关键的环境中，每一行代码都应该明确可解释。此外，一个良好定义的模块系统应该是任何优秀语言的核心。应该清楚地知道哪些项目在哪个作用域中定义，以及可以访问哪些项目。默认情况下，模块中的每个项目都应该是私有的，只有明确公开的项目才能在外部访问。在单个项目中重用代码是一个开始，但还应该有一个紧密集成的包管理器，用于使用外部定义的代码。

如前所述，在像 EVM 这样资源受限的环境中，效率很重要。通过提供低成本的抽象，如通过宏实现的编译时代码执行、用于创建设计良好、可重用库的丰富类型系统以及常见链上交互的包装器，可以实现效率。宏在编译时生成代码，这对于减少常见操作的样板代码以及在 Huff 等情况下进行代码大小与运行时效率的权衡非常有用。丰富的类型系统允许更具表现力的代码，更多的编译时检查以在运行时之前捕获错误，并且当与类型检查的编译器内置函数配合使用时，可能会消除大部分内联汇编的需求。泛型还允许将可为空值（例如外部代码）包装在“option”类型中，或将可能失败的操作（例如外部调用）包装在“result”类型中。这两种类型是库编写者如何强制开发人员处理每个结果的示例，通过定义两个代码路径或在失败的情况下回滚交易。然而，请记住，这些是编译时的抽象，会在运行时解析为简单的条件跳转。在编译时强制开发人员处理每个结果会增加初始开发时间，但有助于减少运行时的惊喜。

灵活性对于开发人员的人体工程学也很重要，因此对于复杂操作，默认情况下应该是安全且可能效率较低的路线，有时需要使用更有效的代码路径或不支持的功能。为此，应该向开发人员公开内联汇编，但不设防护栏。Solidity 的内联汇编有一些防护栏，是为了简单起见和更好的优化器传递，但当开发人员需要完全控制执行环境时，他们应该得到确切的授权。杂项功能，如果能包括函数和其他项目在编译时可操作的属性将会很好。一个“inline”属性可以获取一个简单函数的主体并将其复制到每次调用中，而不是为了效率而创建更多跳转。一个“abi”属性可以允许手动覆盖为给定外部函数生成的 ABI，以适应具有不同代码风格约定的语言。一个可选定义的、可配置的函数分发器，允许在高级语言中进行定制，可以为预计更常用的代码路径提供额外的优化，例如，在“name”之前检查选择器是否为“transfer”或“transferFrom”将是一个很好的补充。

结论

EVM 智能合约 DSL 设计已经取得了长足的进步，但还有很长的路要走。每种语言都做出了自己独特的设计决策，我期待看到它们在未来的发展。作为开发人员，学习尽可能多的语言对我们有好处，原因有几个。首先，学习多种语言并了解它们的差异和相似之处将加深我们对编程和底层机器架构的理解。其次，在技术社区中广泛认识到，语言具有深远的网络效应和强大的保留特性。毫无疑问，大规模的参与者都在构建自己的编程语言，从 C#、Swift 和 Kotlin 到 Solidity、Sway 和 Cairo。学会在这些语言之间无缝切换，将为软件工程职业提供无与伦比的灵活性。最后，重要的是要理解每种语言背后所做的大量工作。虽然没有一种是完美的，但无数才华横溢的人已经付出了巨大的努力，为像我们这样的开发人员创造了一个安全而愉快的体验。

希望你喜欢这篇简要介绍 EVM DSL 设计现状的文章，如果你喜欢这篇文章并想看到更多，请订阅下方并在 Twitter 上关注我，以获取定期更新。下次再见，祝你编程愉快

免责声明

免责声明：

本文不代表知点网立场，且不构成投资建议，请谨慎对待。用户由此造成的损失由用户自行承担，与知点网没有任何关系；

知点网不对网站所发布内容的准确性，真实性等任何方面做任何形式的承诺和保障；

网站内所有涉及到的区块链（衍生）项目，知点网对项目的真实性，准确性等任何方面均不做任何形式的承诺和保障；

网站内所有涉及到的区块链（衍生）项目，知点网不对其构成任何投资建议，用户由此造成的损失由用户自行承担，与知点网没有任何关系；

知点区块链研究院声明：知点区块链研究院内容由知点网发布，部分来源于互联网和行业分析师投稿收录，内容为知点区块链研究院加盟专职分析师独立观点，不代表知点网立场。