长推:深入浅出理解“UTXO” 和 “Account”

原文作者:AurtrianAjian

原文来源:Twitter

链协议的研究者,在开展研究的时候会不断回访 “UTXO” 和 “Account” 这两个概念。因为它们几乎关联了一切:交易的格式(用户交互的方式)、编程模型、经济模型(资源消耗计量、状态膨胀),还有隐私性、可扩展性。

在这里,“UTXO” 和 “Account” 都不必作狭义的理解。它们的核心区别在于,一个是对钱编程(“某一笔钱有某一个所有者”),一个是对账户编程(“某一个账户有某一些状态”)。因此 Nervos 的 Cell 模型,也算作 UTXO。(还有没有人记得 “可编程货币” 这个 meme?把它用在账户模型上是一种事实性的错误)

在这个领域,给我留下最深刻印象的是 John Adler 在 2020 年 9 月发表的一篇短文,题为 “Accounts, Strict Access Lists, and UTXOs(账户、严格访问列表与 UTXO)”。在这篇文章中他得出了一个令人有些震惊乃至怀疑的直觉:https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37

“与账户模型相比,UTXO 并没有提供任何根本上不同的功能,也没有缺失任何基础功能。”,也包括 “可编程性”,因为这篇文章就提出了一种可以实现以太坊富状态式智能合约的 UTXO 模型。作者还认为,UTXO 对比账户模式的好处,主要在于它显式地指明要访问的状态(UTXO),因此允许并行执行(高吞吐量)。

但是,“这在账户模式下也可以通过 ‘严格访问清单(strict access lists)’” 来实现。意思是让交易严格指明自己要访问哪个账户。顺带说一句,“访问清单” 这种技术在以太坊上也已经有了,就是 2020 年柏林分叉中纳入的 EIP-2930—— 提前说好自己要访问哪些账户,可以获得 Gas 节省。

这个 EIP 不是强制的;但可能用户要享受到其中的好处也不容易,它需要全节点通过解析交易的内容构造出访问清单,再返回完整的交易给用户签名。(另:也正是这个 EIP,让许多因为 EIP-1884 而死掉的合约账户起死回生。也是以太坊的著名公案。)(不知跟各应用争相做钱包有无关系)

那么,UTXO 又如何获得跟账户模式比肩的可编程性呢?作者引用了两篇文献,一篇是 Nervos 开发者 Xuejie Xiao 的 “Intro to CKB Script Programming 1”:https://medium.com/nervosnetwork/intro-to-ckb-script-programming-1-validation-model-9a7d84679266

另一篇文献名为 “Bitcoin Covenants”,所涉及到的概念正是比特币社区长期以来讨论的 “covenant(限制条款)”:https://fc16.ifca.ai/bitcoin/papers/MES16.pdf…118

作者还说:“一个关键的直觉是,底层的数据模式与执行模式没有绝对的关联,执行模式既可以是具状态的,也可以是无状态的;跟合约是否能与另一个合约互动也没有绝对的关联。”

我一直记得这篇文章,时时回味。并不是说作者已经说服了我。按我今天的理解,我认为这些结论也许谈得太粗糙了。比如,在比特币 UTXO 上,你无法编程出 “无主的合约”(因此不可能实现 Uniswap v1),这可能跟使用了 UTXO 模型无关,而主要是因为它的编程模型是验证范式的。

我的理解:验证的意思是你把数据输进去,它给你一个 0 或 1(通过或者不通过)。而以太坊这种计算范式,则意味着你把数据输进去,它可以给你另一个有意义的数据。这种区别也许更大地影响了编程。(我不确定 Nervos 上能否实现 Uniswap v1,请方家不吝赐教)

除此之外,更为根本但常常被忽略的话题(也是我一直记得这篇文章的原因)是:为什么要使用 UTXO/账户?显然这并不只跟编程有关,因此作者只讨论了一个方面。前段时间人们热议以太坊上提出的各种账户抽象方案,最后也会回到这个问题。

如果我们想要实现账户抽象,是否 UTXO 模式更好?如果我们想要实现分层,是否 UTXO 模式更好?如果我们要让区块链进入金融场景,账户模式更好吗?这些问题也许显得虚无缥缈,而且事实上很可能需要逐个逐个案例的研究,才能拼凑出足够有意义的答案。但这些问题不重要吗?

对从业者而言,这些问题决定了你的工作建立在怎样的基础上;决定了吸引你进入这个行业的承诺是否真的有可能实现;同样,可能也决定了未来某个人希望参与这个世界的时候,决定把心思放在哪里。它们可能比如何编程更重要,重要得多。因为程序是价值中立的,但程序员不是。

John Adler 文章的中文译本: https://mp.weixin.qq.com/s?__biz=MzIwODA3NDI5MA==&mid=2652532990&idx=1&sn=414b9616bc1890d36be5dcdeff0bbff8&chksm=8ce673a3bb91fab5b0de969ac15823fea387d7f4f470674da59bfd4daabc1f227891e45ef5f7#rd…

BTCStudy 的 “covenant” 标签: https://btcstudy.org/tags/covenant/

转载声明:本文 由CoinON抓取收录,观点仅代表作者本人,不代表CoinON资讯立场,CoinON不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。若以此作为投资依据,请自行承担全部责任。

声明:图文来源于网络,如有侵权请联系删除

风险提示:投资有风险,入市需谨慎。本资讯不作为投资理财建议。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 2023年3月30日 下午7:26
下一篇 2023年3月30日 下午7:26

相关推荐

长推:深入浅出理解“UTXO” 和 “Account”

星期四 2023-03-30 19:26:37

链协议的研究者,在开展研究的时候会不断回访 “UTXO” 和 “Account” 这两个概念。因为它们几乎关联了一切:交易的格式(用户交互的方式)、编程模型、经济模型(资源消耗计量、状态膨胀),还有隐私性、可扩展性。

在这里,“UTXO” 和 “Account” 都不必作狭义的理解。它们的核心区别在于,一个是对钱编程(“某一笔钱有某一个所有者”),一个是对账户编程(“某一个账户有某一些状态”)。因此 Nervos 的 Cell 模型,也算作 UTXO。(还有没有人记得 “可编程货币” 这个 meme?把它用在账户模型上是一种事实性的错误)

在这个领域,给我留下最深刻印象的是 John Adler 在 2020 年 9 月发表的一篇短文,题为 “Accounts, Strict Access Lists, and UTXOs(账户、严格访问列表与 UTXO)”。在这篇文章中他得出了一个令人有些震惊乃至怀疑的直觉:https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37

“与账户模型相比,UTXO 并没有提供任何根本上不同的功能,也没有缺失任何基础功能。”,也包括 “可编程性”,因为这篇文章就提出了一种可以实现以太坊富状态式智能合约的 UTXO 模型。作者还认为,UTXO 对比账户模式的好处,主要在于它显式地指明要访问的状态(UTXO),因此允许并行执行(高吞吐量)。

但是,“这在账户模式下也可以通过 ‘严格访问清单(strict access lists)’” 来实现。意思是让交易严格指明自己要访问哪个账户。顺带说一句,“访问清单” 这种技术在以太坊上也已经有了,就是 2020 年柏林分叉中纳入的 EIP-2930—— 提前说好自己要访问哪些账户,可以获得 Gas 节省。

这个 EIP 不是强制的;但可能用户要享受到其中的好处也不容易,它需要全节点通过解析交易的内容构造出访问清单,再返回完整的交易给用户签名。(另:也正是这个 EIP,让许多因为 EIP-1884 而死掉的合约账户起死回生。也是以太坊的著名公案。)(不知跟各应用争相做钱包有无关系)

那么,UTXO 又如何获得跟账户模式比肩的可编程性呢?作者引用了两篇文献,一篇是 Nervos 开发者 Xuejie Xiao 的 “Intro to CKB Script Programming 1”:https://medium.com/nervosnetwork/intro-to-ckb-script-programming-1-validation-model-9a7d84679266

另一篇文献名为 “Bitcoin Covenants”,所涉及到的概念正是比特币社区长期以来讨论的 “covenant(限制条款)”:https://fc16.ifca.ai/bitcoin/papers/MES16.pdf…118

作者还说:“一个关键的直觉是,底层的数据模式与执行模式没有绝对的关联,执行模式既可以是具状态的,也可以是无状态的;跟合约是否能与另一个合约互动也没有绝对的关联。”

我一直记得这篇文章,时时回味。并不是说作者已经说服了我。按我今天的理解,我认为这些结论也许谈得太粗糙了。比如,在比特币 UTXO 上,你无法编程出 “无主的合约”(因此不可能实现 Uniswap v1),这可能跟使用了 UTXO 模型无关,而主要是因为它的编程模型是验证范式的。

我的理解:验证的意思是你把数据输进去,它给你一个 0 或 1(通过或者不通过)。而以太坊这种计算范式,则意味着你把数据输进去,它可以给你另一个有意义的数据。这种区别也许更大地影响了编程。(我不确定 Nervos 上能否实现 Uniswap v1,请方家不吝赐教)

除此之外,更为根本但常常被忽略的话题(也是我一直记得这篇文章的原因)是:为什么要使用 UTXO/账户?显然这并不只跟编程有关,因此作者只讨论了一个方面。前段时间人们热议以太坊上提出的各种账户抽象方案,最后也会回到这个问题。

如果我们想要实现账户抽象,是否 UTXO 模式更好?如果我们想要实现分层,是否 UTXO 模式更好?如果我们要让区块链进入金融场景,账户模式更好吗?这些问题也许显得虚无缥缈,而且事实上很可能需要逐个逐个案例的研究,才能拼凑出足够有意义的答案。但这些问题不重要吗?

对从业者而言,这些问题决定了你的工作建立在怎样的基础上;决定了吸引你进入这个行业的承诺是否真的有可能实现;同样,可能也决定了未来某个人希望参与这个世界的时候,决定把心思放在哪里。它们可能比如何编程更重要,重要得多。因为程序是价值中立的,但程序员不是。

John Adler 文章的中文译本: https://mp.weixin.qq.com/s?__biz=MzIwODA3NDI5MA==&mid=2652532990&idx=1&sn=414b9616bc1890d36be5dcdeff0bbff8&chksm=8ce673a3bb91fab5b0de969ac15823fea387d7f4f470674da59bfd4daabc1f227891e45ef5f7#rd…

BTCStudy 的 “covenant” 标签: https://btcstudy.org/tags/covenant/