文档章节

区块链100讲:UTXO 和 Account 模型对比

HiBlock
 HiBlock
发布于 10/17 22:52
字数 2499
阅读 10
收藏 0

image

在当前区块链世界中,主要有两种记录保存方式,UTXO 模式(Unspent Transaction Output) 和 Account 模式。Bitcoin 采用的是 UTXO 模型,Ethereum 采用的 Account 模型,同样 CITA 也采用了 Account 模型。

Bitcoin 的设计初衷是点对点的电子现金系统,在比特币中,每个交易消耗之前交易生成的 UTXO 然后生成新的 UTXO,账户的余额即所有属于该地址的未花费 UTXO 集合,Bitcoin 的全局状态即当前所有未花费的 UTXO 集合。Ethereum 意图创建一个更为通用的协议,该协议支持图灵完备的编程语言,在此协议上用户可以编写智能合约,创建各种去中心化的应用。由于 UTXO 模型在状态保存以及可编程性方面的缺陷,Ethereum 引入了 Account 模型。下面我们对两种模型的优缺点做进一步展开。

1

UTXO 模型

UTXO 模型中,交易只是代表了 UTXO 集合的变更。而账户和余额的概念是在 UTXO 集合上更高的抽象,账号和余额的概念只存在于钱包中。

image

优点:

  • 计算是在链外的,交易本身既是结果也是证明。节点只做验证即可,不需要对交易进行额外的计算,也没有额外的状态存储。交易本身的输出 UTXO 的计算是在钱包完成的,这样交易的计算负担完全由钱包来承担,一定程度上减少了链的负担。

  • 除 Coinbase 交易外,交易的 Input 始终是链接在某个 UTXO 后面。交易无法被重放,并且交易的先后顺序和依赖关系容易被验证,交易是否被消费也容易被举证。

  • UTXO 模型是无状态的,更容易并发处理。

  • 对于 P2SH 类型的交易,具有更好的隐私性。交易中的 Input 是互不相关联的,可以使用 CoinJoin 这样的技术,来增加一定的隐私性。

缺点:

  • 无法实现一些比较复杂的逻辑,可编程性差。对于复杂逻辑,或者需要状态保存的合约,实现难度大,且状态空间利用率比较低。

  • 当 Input 较多时,见证脚本也会增多。而签名本身是比较消耗 CPU 和存储空间的。

2

ACCOUNT 模型

对于 Account 模型,Account 模型保存了世界状态,链的状态一般在区块中以 StateRoot 和 ReceiptRoot 等形式进行共识。交易只是事件本身,不包含结果,交易的共识和状态的共识本质上可以隔离的。

image

优点:

  • 合约以代码形式保存在 Account 中,并且 Account 拥有自身状态。这种模型具有更好的可编程性,容易开发人员理解,场景更广泛。

  • 批量交易的成本较低。设想矿池向矿工支付手续费,UTXO 中因为每个 Input 和 Out 都需要单独 Witness script 或者 Locking script,交易本身会非常大,签名验证和交易存储都需要消耗链上宝贵的资源。而 Account 模型可以通过合约的方式极大的降低成本。

缺点:

  • Account 模型交易之间没有依赖性,需要解决重放问题。

  • 对于实现闪电网络/雷电网络,Plasma 等,用户举证需要更复杂的 Proof 证明机制,子链向主链进行状态迁移需要更复杂的协议。

3

UTXO VS ACCOUNT

对于以上几个优点和缺点,我们再做一些分析和对比。

第一,关于计算的问题的。

UTXO 交易本身对于区块链并没有复杂的计算,这样简单的讲其实并不完全准确,原因分有两个,一是 Bitcoin 本身的交易多为 P2SH,且 Witness script 是非图灵完备的,不存在循环语句。而对于 Account 模型,例如  Ethereum,由于计算多在链上,且为图灵完备,一般计算较为复杂,同时合约安全性就容易成为一个比较大的问题。当然是否图灵完备对于是否是账户模型并没有直接关联。但是账户模型引入之后,合约可以作为一个不受任何人控制的独立实体存在,这一点意义重大。

第二,关于 UTXO 更易并发的问题。

在 UTXO 模型中,世界状态即为 UTXO 的集合,节点为了更快的验证交易,需要在内存中存储所有的 UTXO 的索引,因此 UTXO 是非常昂贵的。对于长期不消费的 UTXO,会一直占用节点的内存。所以对于此种模型,理论上应该鼓励用户减少生产 UTXO,多消耗 UTXO。但是如果要使用 UTXO 进行并行交易则需要更多的 UTXO 作为输入,同时要产生更多的 UTXO 来保证并发性,这本质上是对网络进行了粉尘攻击。并且由于交易是在钱包内构造,所以需要钱包更复杂的设计。反观 Account 模型,每个账户可以看成是单独的互不影响的状态机,账户之间通过消息进行通信。所以理论上用户发起多笔交易时,当这些交易之间不会互相调用同一 Account 时,交易是完全可以并发执行的。

第三,关于 Account 模型的交易重放问题。

Ethereum 使用了在 Account 中增加 nonce 的方式,每笔交易对应一个 nonce,nonce 每次递增。这种方式虽然意在解决重放的问题,但是同时引入了顺序性问题,同时使得交易无法并行。例如在 Ethereum中,用户发送多笔交易,如果第一笔交易打包失败,将引起后续多笔交易都打包不成功。在 CITA 中我们使用了随机 nonce 的方案,这样用户的交易之间没有顺序性依赖,不会引起串联性失败,同时使得交易有并行处理的可能。

第四,存储问题。

因为 UTXO 模型中,只能在交易中保存状态。而 Account 模型的状态是在节点保存,在 Ethereum 中使用MPT 的方式存储,Block 中只需要共识 StateRoot 等即可。这样对于链上数据,Account 模型实际更小,网络传输的量更小,同时状态在节点本地使用 MPT 方式保存,在空间使用上也更有效率。例如 A 向 B 转账,如果在 UTXO 中假设存在 2 个 Input 和2个 Output,则需要 2 个 Witness script 和 2 个Locking script;在 Account 模型中则只需要一个签名,交易内容只包含金额即可。在最新的隔离见证实现后,Bitcoin的交易数据量也大大减少,但是实际上对于验证节点和全节点仍然需要针对 Witness script 进行传输和验证。

第五,对于轻节点获取某一地址状态,UTXO 更复杂。

例如钱包中,需要向全节点请求所有关于某个地址的所有 UTXO,全节点可以发送部分 UTXO,钱包要验证该笔 UTXO 是否已经被消费,有一定的难度,而且钱包很难去证明 UTXO 是全集而不是部分集合。而对于 Account 模型则简单很多,根据地址找到 State 中对应状态,当前状态的 State Proof 则可以证明合约数据的真伪。当然对于 UTXO 也可以在每个区块中对 UTXO 的 root 进行验证,这一点与当前 Bitcoin 的实现有关,并非 UTXO 的特点。

4

总结

综上来看,Account 模型在可编程性,灵活性等方面更有优势;在简单业务和跨链上,UTXO 有其非常独到和开创性的优点。对于选择何种模型,要从具体的业务场景进行出发。

5

参考资料

houghts on UTXOs by Vitalik Buterin: 

https://medium.com/@ConsenSys/thoughts-on-utxo-by-vitalik-buterin-2bb782c67e53

What are the pros and cons of Ethereum balances vs. UTXOs?:  https://ethereum.stackexchange.com/questions/326/what-are-the-pros-and-cons-of-ethereum-balances-vs-utxos

Mastering Bitcoin 2nd Edition - Programming the Open Blockchain:  https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc

Accounts and not UTXOs:  https://github.com/ethereum/wiki/wiki/Design-Rationale#accounts-and-not-utxos

交易中的nonce的作用是什么?: https://docs.nervos.org/cita/#/reference/faq?id=%E4%BA%A4%E6%98%93%E4%B8%AD%E7%9A%84nonce%E7%9A%84%E4%BD%9C%E7%94%A8%E6%98%AF%E4%BB%80%E4%B9%88%EF%BC%9F

Why is EVM-on-Plasma hard?: https://medium.com/@kelvinfichter/why-is-evm-on-plasma-hard-bf2d99c48df7

---岗位招聘---

如果你对创造未来的加密经济感兴趣,对自己的能力有自信,欢迎投简历到 join@cryptape.com 加入我们:

  • Appchain Team - Appchain 是 Nervos Network 的 Layer 2 方案之一,以 CITA 为核心,包含 Neuron 钱包和 Microscope 浏览器。无论你是移动应用高手,Web 应用高手,还是有特殊技能的产品小王子,Appchain Team 都欢迎!

  • CITA Core Team - CITA 是世界上第一个使用微服务架构的许可链项目,用 Rust 实现,追求高性能与高稳定性。CITA 与大多数许可链不同,不是 Ethereum 或者 Fabric 的 fork,而是一个从零开始设计的项目,这给我们带来了许多挑战,也带来了许多乐趣。这里隐藏大佬很多哦~

  • CKB Core Team - CKB 是 Nervos Network 的 Layer 1, 是一条公有链,用 Rust 实现,追求安全性与稳定性。这里隐藏大佬也很多哦~

  • Cryptape Research

内容来源:NervosNetwork

技术工坊|如何降低区块链应用的使用门槛(上海)

时间:2018年10月20日9:00-11:30

地点:上海市黄浦区柳泉弄1号2楼(P2·露香园)

报名方式:识别下图二维码或者点击“阅读原文"即可报名。

image

本文转载自:https://mp.weixin.qq.com/s?__biz=MzA5NDAxNzIzNg==&mid=2450006355&idx=2&sn=8543d5687018cceac66b22f...

共有 人打赏支持
HiBlock
粉丝 14
博文 329
码字总数 451443
作品 0
私信 提问
区块链100讲:10分钟教会你深挖以太坊数据层

在当下数据爆炸的信息时代,凭借区块链去中心化、点对点和防篡改的特性,“区块链+大数据”已成为研究的热门,可以说,区块链与大数据的结合为今后区块链应用的大规模落地奠定了基础。 那么,...

HiBlock
09/16
0
0
区块链 100 讲:UTXO-你的比特币钱包里永远没有钱

比特币交易,是比特币系统中最重要的部分,在比特币交易过程中,有一个词经常被提及“UTXO”,有一种说法:你的比特币钱包里永远没有钱,但能拥有支配钱的权力。 如果有人告诉你,比特币世界...

yanyan
07/10
0
0
Bytom Blockchain/node-sdk

Bytom Node.js SDK Terminology Keys Cryptographic keys are the primary authorization mechanism on a blockchain. To create accounts or assets, xpub of keys are required. With this......

Bytom Blockchain
07/23
0
0
深入浅出区块链教程——16.UTXO与普通账户模型

UTXO与普通账户模型 区块链到底是怎么运行一文中,提到了村长给张三转账的例子,那里村长的例子就是 UTXO 模型的一个简化版本。 区块链网络中有两种记账模式,除了 UTXO 模型还有 Account Ba...

纳兰少
08/06
0
0
浅谈量子链(Qtum):区块链3.0的一种探索

之前写过一次量子链《看完,立刻又研究了一下量子链:真的是笑来说的空气吗?》,这次在研究一下量子链,当然,本系列主要是纯分析公链技术的视角分析币种。 前言 区块链3.0的公链的定位是能...

陈天宇123
09/26
0
0

没有更多内容

加载失败,请刷新页面

加载更多

安卓的切图规范

Android UI 切图命名规范、标注规范及单位描述 很多UI设计师做APP切图都会有两套,一套是Android的,一套是IOS的。IOS我这边暂不作讲解,因为我本人也不是开发IOS。这里整理一下我在Android...

mo311
30分钟前
2
0
深度剖析阿里巴巴对Flink的优化与改进

摘要: 作者 | 阿里巴巴实时计算团队 导读:随着人工智能时代的降临,数据量的爆发,阿里巴巴的商品数据处理就经常需要面对增量和全量两套不同的业务流程问题,所以阿里巴巴就在想:能不能有...

阿里云官方博客
31分钟前
2
0
Dubbo基础介绍

Dubbo是一个常用的分布式服务框架, 它致力于提供高性能、透明化的RPC远程服务方案。 学习Dubbo有助于提高企业级应用的开发效率,以及可通过简单的配置就可以实现负载均衡,提高服务的效率。...

Java搬砖工程师
42分钟前
4
0
VBS 自动登陆

1.关于网页元素属性 IE浏览器打开网页时,有很多元素,比如说一个文本框,一个按键等。每个元素都会有对应的“name”、“ID”,“style”,“class”等属性。 其中的“ID”和“name”属性是我...

宝贝女儿
47分钟前
1
0
GO 文件相关操作

package mainimport("fmt""os""bufio""io""io/ioutil")type ChartCount struct{Chct intSpacect intNumberct intOtherct int}func main() {file,err := os.Open......

汤汤圆圆
48分钟前
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部