感谢 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 有如下字段:

  1. Coin 的数量

  2. 使用脚本的哈希值(定义了该 UTXO 的所有者)或者所有者

Contract UTXO 由以下字段组成:

  1. Coin 的数量

  2. 合约 ID

  3. 合约代码哈希值

  4. 存储根

在实践中,除了这些字段,肯定还会增添字段或优化这些字段,比如存储代码或脚本默克尔树的树根(BIP-016),而不是存储哈希值。我们在这里仅列举最基础的字段,以简化分析、集中在所需的核心特征上。

合约的代码哈希值和存储根只有使用无状态执行模式才会用得上。在具有状态的执行模式中可以省略,但因此需要一个专门用于存储的 UTXO 类型。

UTXO ID (即每个 UTXO 的唯一标识符,可以在基于键值对的数据库中用作 key)是这个 UTXO 的 outpoint (生产该 UTXO 的交易的 ID 以及该 UXTO 在输出中的位置索引),或者某种变种(例如,outpoint 及其字段的哈希值)。

注意,在这个模式中,合约 UXTO 没有定义 “所有者”(即对此 UTXO 具有排他控制权的私钥),就像以太坊当前的合约一样。也就是说,合约的代码要来定义其内部的所有权概念,例如 使用 onlyOwner() 方法。因此,合约 UTXO 是 任何人都可以花费的

**

**

执行模式

以太坊虚拟机(EVM)中的智能合约,有三大区别于比特币脚本的本质特征:

  1. 状态元素可以定义自身的修改规则。这个区别是众所周知的,只不过被不精确地表达为以太坊可以上传持久的代码,但这只是一个手段,而非目的。

  2. 用户可以与合约交互。这就意味着以太坊式的合约没有固有的所有权概念。

  3. 合约可以与其它合约交互。

那我们如何能在 UTXO 模式上实现这些特征呢?

第一点很简单:我们可以使用 covenants 来强制执行合约 UTXO:当合约 UXTO 在一笔交易中使用时,必须创建一个新的、带有特定花费条件的 UTXO (且只能创建一个);具体来说,就是合约代码相同,但是状态根更新了(取决于交易执行的结果)的 UTXO。一个例外是合约的销毁,如果需要这个功能的话。

用了 covenants,用户自然而然可以跟合约交互,因为合约 UTXO 是人人可用的,任何用户单独与任意数量的合约交互。

然后,还得让合约能够跟其它合约交互(结果是,用户可以同时与许多合约交互)。这个也简单,只需让多个合约的 UTXO 都能在同一笔交易中使用,即可。从另一个角度看,交易声明了自己将触及哪些合约(且,在账户模型中,还可额外声明将触及哪些状态对象)。这就是所谓的 “严格访问列表”。

最后,我们需要讨论如何生成合约和更新合约。合约 UTXO 可以使用一个操作码来创建,创建时会确定性地分配一个密码学上唯一的合约 ID,例如类似于以太坊 CREATE2 这样的操作码。作为一个合约 UTXO,在使用和重生时,其合约 ID 保持不变,但其 UTXO ID 将变化,而且每次交易后都会不同,因为 UTXO 的 ID 是由 outpoint 决定的。

 

交易格式

交易是一个包含下列内容的元组:

  1. 输入:一些唯一标识符,表明要消耗哪些 UTXO,并提供不可变形(non-malleable)的数据来解锁 coin 或者与合约交互。

  2. 输出:定义创建哪些 UTXO。

  3. Gas Price 和 Gas Limit。

  4. 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 有许多好处,最主要的是通过并行化来创建更高吞吐量工程实现的潜能

  1. 交易指定了自己会触及哪个合约,因此不相关的交易就可以并行执行(连生产区块的节点都可以)。这个在账户数据模式下使用 “严格访问列表” 也可以实现。

  2. UTXO 数据模式下的交易显式地说明了其状态转换。因此,在非区块生产者这边,交易可以并行地验证,即使它们读取或者写入了同一个合约。在本文提出的方案中,生产区块的节点仍然需要用重叠的访问列表,按顺序地执行交易。

  3. 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 模型