区块链 101：智能合约背后的架构

• 原文链接：medium.com/@francomango...
• 译者：AI翻译官，校对：翻译小组
• 本文链接：learnblockchain.cn/article…

这是有关区块链的一系列文章的一部分。如果这是你看到的第一篇文章，我强烈建议从系列的开始开始阅读。

在我们讨论过的以太坊存储之后，现在是深入探讨现代区块链中最核心的主题之一：智能合约的时刻了。

正如我们之前在系列中提到的，这些是用户提交的程序，直接在区块链上运行——在以太坊的情况下，它们被存储在合约账户中。

不仅如此，它们还管理着一个独立的状态，这个状态只能通过合约本身定义的规则进行更改。

听起来很棒，对吧？然而，实现这样的功能面临着一系列挑战：我们如何建模一个可定制、灵活的状态？我们如何定义与合约相关联的操作——或者状态转换？

我们今天的计划是尝试解释以太坊如何回答这两个问题。它们的解决方案已经变得非常流行——以至于许多其他区块链努力与它们兼容。

你可能听说过 EVM 兼容的区块链。这正是它们的意思：它们以与以太坊相同的方式处理智能合约的状态和逻辑。

有趣的内容即将来临！

状态建模

让我们从上一篇文章结束的地方继续。我们谈到了状态是如何存储在一个简单的键值数据库中，但它通过使用（修改过的）帕特里夏默克树得以巩固。

表示账户是一个相对简单的任务，因为完全定义一个账户所需的属性集是静态的。智能合约则不同——每个合约都定义了自己的状态，这意味着我们不再拥有一个静态的属性集。

因此，首先要做的就是制定一个机制来组织状态。换句话说：

我们需要一些规则来正确定义状态

大多数编程语言也有这些“规则”——它们就是我们所称的类型，或者像数组这样的内置构造。为了实现可编程性的承诺，智能合约也需要提供一些这些。

从本质上讲，我们只需要弄清楚三件事：

• 我们想支持哪些类型
• 我们将如何在键值存储中存储这些信息
• 一种确定性计算标识符的策略，用于将数据放置在帕特里夏默克树中

考虑到这一点，看看以太坊可以处理哪些类型。

原始类型

在类型系统的核心，有一个非常基本的构建块：256 位字。

撇去说唱笑话，计算机科学中的一个 字是计算机处理器在单个操作中能够处理的数据基本单位。它通常也是可以适配到一个寄存器中的最大数据量。

但我们这里并不涉及物理计算机。我们为什么要关心物理硬件的架构决策？

我们的智能合约本质上是计算机程序，因此我们需要设计一个可以执行它们的架构。

如果我们可以构建出与计算机完全相同的软件，并且能在任何硬件上运行智能合约，那么无论它在哪里执行，给定相同的输入，结果都会一致。

从这个意义上说，以太坊就像一个巨大的分布式计算机——虚拟机。这就是 EVM 代表的意思：以太坊虚拟机！

决定字大小在所述虚拟机的设计中是重要的。

选择256位与存储大数字（如余额）和地址的必要性很好地对齐。它还与以太坊中使用的 哈希函数：Keccak-256相一致。我们稍后会详细讨论这个选择。

这个选择也导致了一系列基于该字大小的原始类型。

我在脑海中想到的“原始类型”

这些原始类型包括：

• 整数：我们可以在可用的256位中存储有符号和无符号整数。有符号整数使用一个位来指定符号，而无符号整数总是正值。我们可以表示的最大整数是2²⁵⁶ - 1。超出该范围的值将会有麻烦，并需要巧妙的解决方法。
• 地址：由于地址在以太坊中占用160位（20字节），它们可以适配到一个字中！
• 布尔值：一个1或0，分别表示真或假。它们占用一个完整的字，尽管只使用1位的空间。
• 字节：简单的字节值，没有明确的含义。

我们可以使用这些来定义变量。它们将表示智能合约状态的一部分——这意味着它们需要存储在合约的帕特里夏默克树中。

决定树位置

到目前为止，撰写 EVM 智能合约的最流行的领域特定语言（DSL）是 Solidity。还有一些替代方案，比如 Vyper——但我将出于舒适理由选择 Solidity 作为我们接下来的示例。

这是一个简单合约的片段：

contract SimpleStorage {  
    uint256 first;  
    address second;  
    bool third;  

    // ...  
}

如你所见，我们定义了一些变量（first，second和third），每个变量都被类型化为原始类型。

类型对于正确评估操作至关重要，但要记住，这些仅仅是 256 位大小的值。

我们需要从中实际构建一个树结构，这意味着每一个变量都需要与树中的一条路径关联。并且这个计算需要是确定性和可重复的。

策略是使用插槽。每个插槽的大小与我们的字相同（256位），并由一个256位的键标识。在我们简单的情况下，插槽是*顺序...