感谢 Mustafa Al-Bassam (musalbas)、James Prestwich (prestwich) 和 Sam Wilson (SamWilsn) 的审阅。
HackMD 镜像在此: https://hackmd.io/KOJdKANHSvaGC_8IugEAJA 20
时至今日,有关 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 数据模式和带有严格访问列表的账户数据模式是等价的。
(完)
(文内有许多超链接,可点击左下 ”阅读原文“ 从 EthFans 网站上获取)
原文链接 :
https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37
作者 : John Adler
翻译 : 阿剑
你可能还喜欢:
观点 | 状态膨胀和无状态性
Echo | 以太坊的设计理念,Part-2
科普 | 比特币的 UTXO 模型