链协议的研究者，在开展研究的时候会不断回访“UTXO”和“Account”这两个概念。因为它们几乎关联了一切：交易的格式、编程模型、经济模型，还有隐私性、可扩展性。
在这里，“UTXO”和“Account”都不必作狭义的理解。它们的核心区别在于，一个是对钱编程，一个是对账户编程。因此Nervos的Cell模型，也算作UTXO。
在这个领域，给我留下最深刻印象的是JohnAdler在2020年9月发表的一篇短文，题为“Accounts,StrictAccessLists,andUTXOs”。在这篇文章中他得出了一个令人有些震惊乃至怀疑的直觉：https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37
“与账户模型相比，UTXO并没有提供任何根本上不同的功能，也没有缺失任何基础功能。”，也包括“可编程性”，因为这篇文章就提出了一种可以实现以太坊富状态式智能合约的UTXO模型。作者还认为，UTXO对比账户模式的好处，主要在于它显式地指明要访问的状态，因此允许并行执行。
但是，“这在账户模式下也可以通过‘严格访问清单(strictaccesslists)’”来实现。意思是让交易严格指明自己要访问哪个账户。顺带说一句，“访问清单”这种技术在以太坊上也已经有了，就是2020年柏林分叉中纳入的EIP-2930——提前说好自己要访问哪些账户，可以获得Gas节省。
这个EIP不是强制的；但可能用户要享受到其中的好处也不容易，它需要全节点通过解析交易的内容构造出访问清单，再返回完整的交易给用户签名。
那么，UTXO又如何获得跟账户模式比肩的可编程性呢？作者引用了两篇文献，一篇是Nervos开发者XuejieXiao的“IntrotoCKBScriptProgramming1”：https://medium.com/nervosnetwork/intro-to-ckb-script-programming-1-validation-model-9a7d84679266
另一篇文献名为“BitcoinCovenants”，所涉及到的概念正是比特币社区长期以来讨论的“covenant”：https://fc16.ifca.ai/bitcoin/papers/MES16.pdf…118
作者还说：“一个关键的直觉是，底层的数据模式与执行模式没有绝对的关联，执行模式既可以是具状态的，也可以是无状态的；跟合约是否能与另一个合约互动也没有绝对的关联。”
我一直记得这篇文章，时时回味。并不是说作者已经说服了我。按我今天的理解，我认为这些结论也许谈得太粗糙了。比如，在比特币UTXO上，你无法编程出“无主的合约”，这可能跟使用了UTXO模型无关，而主要是因为它的编程模型是验证范式的。
我的理解：验证的意思是你把数据输进去，它给你一个0或1。而以太坊这种计算范式，则意味着你把数据输进去，它可以给你另一个有意义的数据。这种区别也许更大地影响了编程。
除此之外，更为根本但常常被忽略的话题是：为什么要使用UTXO/账户？显然这并不只跟编程有关，因此作者只讨论了一个方面。前段时间人们热议以太坊上提出的各种账户抽象方案，最后也会回到这个问题。
如果我们想要实现账户抽象，是否UTXO模式更好？如果我们想要实现分层，是否UTXO模式更好？如果我们要让区块链进入金融场景，账户模式更好吗？这些问题也许显得虚无缥缈，而且事实上很可能需要逐个逐个案例的研究，才能拼凑出足够有意义的答案。但这些问题不重要吗？
对从业者而言，这些问题决定了你的工作建立在怎样的基础上；决定了吸引你进入这个行业的承诺是否真的有可能实现；同样，可能也决定了未来某个人希望参与这个世界的时候，决定把心思放在哪里。它们可能比如何编程更重要，重要得多。因为程序是价值中立的，但程序员不是。
JohnAdler文章的中文译本：https://mp.weixin.qq.com/s?__biz=MzIwODA3NDI5MA==&mid=2652532990&idx=1&sn=414b9616bc1890d36be5dcdeff0bbff8&chksm=8ce673a3bb91fab5b0de969ac15823fea387d7f4f470674da59bfd4daabc1f227891e45ef5f7#rd…
BTCStudy的“covenant”标签：https://btcstudy.org/tags/covenant/
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。