EN
什么样的UTXO可以支持所有以太坊智能合约？
时至今日，有关 UTXO 模式的局限性，仍有许多误解广为流传；人们声称，UTXO 是不可能实现 以太坊 那样的智能合约的（或者即使能也非常难）。我们在此提供出一种基于 UTXO 的执行模式，可以支持所有的以太坊智能合约功能模块（取决于虚拟机的规范）。这些想法都不是全新的，只不过都散落在各种在线聊天里。对于尚不熟悉这种模型的人来说，这篇文章可以作为介绍和讨论这个模型的资源汇总。
背景
前置读物
-
Bitcoin : A Peer-to-Peer Electronic Cash System, Nakamoto
-
( Ethereum Design Rationale) Accounts and not UTXOs, Buterin
-
(Bitcoin Stack Exchange) UTXO model vs. account/balance model, Wuille
-
The Stateless Client Concept, Buterin
-
EIP-648: Easy parallelizability 25, Buterin
-
Practical parallel transaction validation without state lookups using Merkle accumulators, Adler
-
Intro to CKB Script Programming 1: Validation Model, Xiao
额外读物
-
State Provider Models in Ethereum 2.0 , Dietrichs et al.
-
Automated Detection of Dynamic State Access in Solidity, Wilson
-
The “Direct Push” model can’t handle stale witnesses, Cloutier
-
Optimizing sparse Merkle trees, Buterin
-
Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities 33, Al-Bassam et al.
-
Zexe: Enabling Decentralized Private Computation 4, Bowe et al.
在 UTXO 模式中实现以太坊式的执行
数据模式
除了我们在传统的基于 UTXO 的系统里面熟悉的 coin UTXO（原生货币 UTXO）以外，我们定义一种新的 UTXO 类型， contract UTXO（合约 UTXO）。
Coin UTXO 有如下字段：
-
Coin 的数量
-
使用脚本的哈希值（定义了该 UTXO 的所有者）或者所有者
Contract UTXO 由以下字段组成：
-
Coin 的数量
-
合约 ID
-
合约代码哈希值
-
存储根
在实践中，除了这些字段，肯定还会增添字段或优化这些字段，比如存储代码或脚本默克尔树的树根（BIP-016），而不是存储哈希值。我们在这里仅列举最基础的字段，以简化分析、集中在所需的核心特征上。
合约的代码哈希值和存储根只有使用无状态执行模式才会用得上。在具有状态的执行模式中可以省略，但因此需要一个专门用于存储的 UTXO 类型。
UTXO ID（即每个 UTXO 的唯一标识符，可以在基于键值对的数据库中用作 key）是这个 UTXO 的 outpoint（生产该 UTXO 的交易的 ID 以及该 UXTO 在输出中的位置索引），或者某种变种（例如，outpoint 及其字段的哈希值）。
注意，在这个模式中，合约 UXTO 没有定义 “所有者”（即对此 UTXO 具有排他控制权的私钥），就像以太坊当前的合约一样。也就是说，合约的代码要来定义其内部的所有权概念，例如 使用
onlyOwner()
方法。因此，合约 UTXO 是 任何人都可以花费的 。
执行模式
以太坊虚拟机（EVM）中的智能合约，有三大区别于 比特币 脚本的本质特征：
-
状态元素可以定义自身的修改规则。这个区别是众所周知的，只不过被不精确地表达为以太坊可以上传持久的代码，但这只是一个手段，而非目的。
-
用户可以与合约交互。这就意味着以太坊式的合约没有固有的所有权概念。
-
合约可以与其它合约交互。
那我们如何能在 UTXO 模式上实现这些特征呢？
第一点很简单：我们可以使用 covenants 来强制执行合约 UTXO：当合约 UXTO 在一笔交易中使用时，必须创建一个新的、带有特定花费条件的 UTXO（且只能创建一个）；具体来说，就是合约代码相同，但是状态根更新了（取决于交易执行的结果）的 UTXO。一个例外是合约的销毁，如果需要这个功能的话。
用了 covenants，用户自然而然可以跟合约交互，因为合约 UTXO 是人人可用的，任何用户单独与任意数量的合约交互。
然后，还得让合约能够跟其它合约交互（结果是，用户可以同时与许多合约交互）。这个也简单，只需让多个合约的 UTXO 都能在同一笔交易中使用，即可。从另一个角度看，交易声明了自己将触及哪些合约（且，在账户模型中，还可额外声明将触及哪些状态对象）。这就是所谓的 “严格访问列表”。
最后，我们需要讨论如何生成合约和更新合约。合约 UTXO 可以使用一个操作码来创建，创建时会确定性地分配一个密码学上唯一的合约 ID，例如类似于以太坊 CREATE2 这样的操作码。作为一个合约 UTXO，在使用和重生时，其合约 ID 保持不变，但其 UTXO ID 将变化，而且每次交易后都会不同，因为 UTXO 的 ID 是由 outpoint 决定的。
交易格式
交易是一个包含下列内容的元组：
-
输入：一些唯一标识符，表明要消耗哪些 UTXO，并提供不可变形（non-malleable）的数据来解锁 coin 或者与合约交互。
-
输出：定义创建哪些 UTXO。
-
Gas Price 和 Gas Limit。
-
Witness：额外的元数据，包括赋予交易合法性的数字签名以及无状态的默克尔树分支。
交易由自身的输入和输出来唯一标识，也即签名的对象仅包括输入和输出。Witness 数据是区块生产者可以改变的。
要让一个区块里面可以多次使用同一个合约，关键是合约 UTXO 可以由其合约 ID 来唯一标识（加上其 UTXO ID），即在任何时候，使用某个 ID 的合约都只有一个。因此，用户只需提供自己的交易会访问的所有合约的 ID，而不需要提供 UTXO ID。区块组装者会提供具体的 UTXO ID，放在 witness 中。Coin UTXO 的花费则与我们今天的用法无二。
最后一件事
精明的读者可能注意到了，在本文提供的方案中，某些只引用合约 UTXO 作为输出但不执行操作（也即不消耗 gas）的交易，可能会遇到交易 ID 重合问题。为了避免这一点，一笔交易至少要消耗一个 coin UTXO。
更一般地来说，这个规则也可以放得宽松一些，只要求交易至少一个输入需要用 UTXO ID 来显式地指定，这样只提供合约 UTXO 有时也行。这样做就支持原生的 账户抽象（EIP-2938）。
还有其它重要的理由支持实施这条规则，包括通过最基本的手续费来实现 DoS 保护，并以动态比例的手续费燃烧的方式实现弹性的区块大小（EIP-1559）。
UTXO 对比账户模式的好处
相比账户模式，使用 UTXO 有许多好处，最主要的是通过并行化来创建更高吞吐量工程实现的潜能
-
交易指定了自己会触及哪个合约，因此不相关的交易就可以并行执行（连生产区块的节点都可以）。这个在账户数据模式下使用 “严格访问列表” 也可以实现。
-
UTXO 数据模式下的交易显式地说明了其状态转换。因此，在非区块生产者这边，交易可以并行地验证，即使它们读取或者写入了同一个合约。在本文提出的方案中，生产区块的节点仍然需要用重叠的访问列表，按顺序地执行交易。
-
UTXO 数据模式的 nonce（交易流水号）以 outpoint 的形式呈现，所以无需显式地跟踪零余额地址的 nonce，但当前的账户数据模式就需要。
直觉
我们注意到，UTXO 没有提供任何本质上与账户不同的功能，也没有缺失任何基础功能。这一点可能并不让人惊讶，因为它们都可以在一个统一的模式下得到描述。不过，UTXO 数据模式提供的内置访问列表功能可以实现更大的可扩展性。
一个关键的直觉是，底层的数据模式与执行模式没有绝对的关联，执行模式既可以是具状态的，也可以是无状态的；跟合约是否能与另一个合约互动也没有绝对的关联。
结论
我们在此提出了一种用 UTXO 数据模式实现通用的、以太坊式富状态智能合约的方案。这是用 covenants 以及允许合约彼此交互（在同一笔交易中声明）来实现的。我们注意到，UTXO 数据模式和带有严格访问列表的账户数据模式是等价的。
原文链接:
https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37
作者: John Adler
翻译: 阿剑
感谢 Mustafa Al-Bassam (musalbas)、James Prestwich (prestwich) 和 Sam Wilson (SamWilsn) 的审阅。
HackMD 镜像在此：https://hackmd.io/KOJdKANHSvaGC_8IugEAJA 20
