UTXO和Account模型一个都不能少
UTXO对于非区块链从业人员来说可能比较陌生,UTXO的全称是Unspent Transaction Output,这中本聪在比特币中的一个天才设计。而Account模型就很常见,也很容易理解,你银行账户里面有多少钱,就是账户模型。
关于UTXO的详细探讨,我比较推荐孟岩的一篇文章《其实并没有什么比特币,只有 UTXO》,这里比较详细的讲解了UTXO的原理,以及与Account模型的对比。总的来说UTXO和Account模型比起来有以下优势:
1.UTXO数据库只保留有用数据。
UTXO中的Unspent很重要,也就意味着如果一个UTXO被一笔交易花费掉后,那么这条记录就不是Unspent的,也就没必要存在于UTXO数据库中。而Account数据库则不同,对于每个使用过的账户,都得一直保留,不管这个账户还有没有钱,会不会被再次使用。
在比特币中,为了提高匿名性和抗量子攻击,我们可以大量生成地址,每个地址只使用一次,一旦该地址付出过比特币,那么公钥就暴露了,也就不抗量子攻击了,所以找零不会回到付款地址,而是一个新地址。如果采用Account模型,那么必然会在数据库中存放大量余额为0的账户地址。
2.UTXO支持并行的记账操作。
在账户数据库中,张三要转20元给李四,需要进行一个数据库事务,在张三账户里减20,在李四账户里加20。如果与此同时,王五要转30元给张三,那这个交易就得排队,无法并行。之所以这样,归根结底是因为这两笔交易都需要跟“张三的账户余额”这个共享状态打交道。而在 UTXO 中,数据库跟踪的是比特币的所有权转移,而不是账户的状态。不管张三本人正在发生多少收支交易,这些收支交易都是发生在不同的比特币上的,更重要的是这些交易之间并不共享任何状态,因此不会相互干扰,所有这些交易可以并发执行。这带来好处不光是快,更重要的是可扩展,可分布。
3.UTXO模型天然就能够抵御重放攻击。
比如A用户有100,现在给B用户转10,如果是Account模型,那么操作就是:
Tx: A.Balance-=10; B.Balance+=10;
如果我们将这个交易在打包到区块链后又再广播到网络中,A用户又会再次向B转10,这就是重放攻击。Account模型要解决重放攻击,以太坊采用的是唯一的Nonce值的方法,每个交易Tx中有一个Nonce字段,对于每个用户来说,这个Nonce都不能重复,从而避免了重放攻击。
如果是UTXO模型,同样是A转账10给B,那么A的操作就是:
Tx:Input A.UTXO 100 -> Output[0] B.UTXO 10; Output[1] A.UTXO 90
这笔交易会花费掉100这个UTXO,所以在该交易打包后,如果我们再次广播该交易到网络,会找不到Input里面对应的UTXO,从而避免重放攻击。
前面说的都是优点,我们也应该意识到UTXO的不足之处:
4.UTXO比Account难于理解和操作
UTXO毕竟概念较新,对于普通用户和刚入行的程序员来说毕竟难于理解,所以也更难于接受。相反Account模型却很简单,很容易理解。在代码实现上也是,对于比特币钱包来说,如果有多个UTXO,在支付时,还需要通过一定的算法选择合适的多个UTXO进行组合,构建交易。而Account模型时,支付就简单很多,所以大部分智能合约在操作时都是向开发人员提供Account模型,这也是量子链的一个功能亮点,在底层用UTXO模型,在合约上提供Account模型,而这中间的复杂转换,就由量子链AAL抽象账户层来完成。
5.UTXO碎片化问题
关于碎片化问题,在Account模型中根本不存在,因为只需要一个Balance字段即可,没有碎片一说。而UTXO不同,比如有个慈善组织,有一个小额募捐地址,大家捐款数额不大,基本都是0.1个,0.05个比特币,慈善组织看到钱包里有10个比特币,但是这背后其实是有几百个UTXO组成的。当这个慈善组织要发起一笔10比特币的转账交易时,Input方放入几百条UTXO,并逐一进行签名,最终使得这个交易体积举到,交易手续费及高。
另外一种UTXO碎片化的场景就是挖矿奖励。在比特币的设计中,区块的第一笔交易叫Coinbase交易,是矿工的挖矿奖励,在每10分钟出一个块的情况下,UTXO碎片化问题还不容易暴露。我们如果发行自己的公链,出块速度调整为1秒,那么一天就会产生24*60*60=86400个块,对应的UTXO也会有86400个,如果挖矿的账户有20个,那么一个矿工一天就会收到4320个UTXO,每个UTXO的金额很小,但是数量特别多,使用起来很麻烦,而且也让UTXO数据库膨胀很快。
如何结合UTXO和Account模型的优点?
既然两种账户模型各有优缺点,那么我们在公链中能不能扬长避短,结合两者的优势呢?PalletOne就是结合了两者的有点,在不同的情况使用不同的模型。
普通Token的流转采用UTXO模型,这样可以充分利用UTXO的并行能力提高性能,抵御重放攻击的特性提升安全性。由于PalletOne采用的是DPOS共识机制,出块时间短,每一块的奖励额度小,所以如果在Coinbase采用UTXO模型必然会导致碎片化。所以PalletOne在Coinbase交易上采用了UTXO和Account相结合的模式。在一般情况下,我们采用Account模型,在状态数据库中记录下每一个矿工应该得到的奖励,在满足某一结算条件时(比如到了某一时间点、到了某区块高度,或者到了换届时刻)就将Account模型中每个矿工应该得到的奖励变成UTXO,同时将Account的账户余额清零。这样做的优势就是避免了UTXO碎片化。由于UTXO难于操作,所以在对智能合约提供操作接口时,PalletOne也采用了类似量子链AAL的设计,对合约来说,只提供Account模型的操作,在执行时,会由中间层实现UTXO和Account的互换,从而降低了合约开发人员的开发难度。
其实除了Coinbase和智能合约支持外,PalletOne还在Token发行和投票选举中结合了两者的优势。
在Token发行(也就是以太坊上的ERC20)时,PalletOne上所有发行的Token都是和平台币PTN同等地位的使用UTXO模型,只是发行的Token和PTN的AssetID不一样罢了。而现在大部分其他链发行Token都是基于合约,基于账户模型来实现。使用UTXO模型发行Token的优点除了前面提到的几点外,还有就是更高的安全性,使用合约和账户模型发行的Token,如果一时疏忽就很容易造成大数溢出之类的漏洞,而采用UTXO模型后检查变得更简单,要求SUM(Input)>=SUM(Output)即可。
在投票选举上,因为PalletOne采用的是DPOS共识,所以需要社区对节点进行投票。而如果基于UTXO来进行唱票会导致效率低下,所以针对每个账户持有的PTN数量,PalletOne在状态数据库中缓存了其余额,当用户进行收付款时,同步更新Account模型中的余额,这样可以保证超级节点换届时,投票结果能够快速统计出来。
UTXO和Account模型一个都不能少的更多相关文章
- 安卓开发经验分享:资源、UI、函数库、测试、构建一个都不能少(转)
除了高超的武艺,每位黑忍者还需要装备最好的武器.在软件开发的世界里,好的工具能让我们的生活变得更轻松,在更短的时间里写出更棒的代码. 时光回到2008年,那时安卓还很年轻.只有几个相关的博客和谷歌官方 ...
- 【转】安卓开发经验分享:资源、UI、函数库、测试、构建一个都不能少
本文由 ImportNew - 唐尤华 翻译自 gigavoice.如需转载本文,请先参见文章末尾处的转载要求. 除了高超的武艺,每位黑忍者还需要装备最好的武器.在软件开发的世界里,好的工具能让我们的 ...
- Ubuntu13.04安装历险记--Mono,Nginx,Asp.Net一个都不能少
----Ubuntu13.04安装历险记--新人新手新作------------------------------------------------- 注:以下操作均省略权限获取操作,如有需要,请 ...
- 一个都不能少: DevOps的3大核心基础架构
DevOps的涵盖面非常广,因为这个概念的火热,又有很多文章和技术都在把DevOps的帽子扣在自己头上,让很多人迷惑不解.其实,DevOps的知识体系如果从顶层上来分解,只有2块:方法论和工具链.方法 ...
- JVM04——七个GC垃圾收集器,一个都不能少
了解了JVM内存区域与垃圾回收算法,今天将为各位带来关于垃圾收集器的知识.关注我的公众号「Java面典」了解更多 Java 相关知识点. Java 堆内存被划分为新生代和老年代两部分,因此 JVM 通 ...
- 4. Validator校验器的五大核心组件,一个都不能少
困难是弹簧,你弱它就强.本文已被 https://www.yourbatman.cn 收录,里面一并有Spring技术栈.MyBatis.JVM.中间件等小而美的专栏供以免费学习.关注公众号[BAT的 ...
- Ethereum Learning Materials
Home 注:本页为 EthFans 站内文章精选集.鉴于文章的采集范围较广,我们无法保证文章内容没有重复,也不能保证排列的顺序实现了最优的认识路径.我们只能说,这些文章是我们精挑细选后,确认可以长期 ...
- 比原链设计思考: 扩展性UTXO模型
用户模型是比原链在最初就需要确定的重要数据结构, 团队的选择还是聚焦在两种典型的模型系统中,Account模型和UTXO模型,和其他大多数区块链设计一样, 选择了模型就决定了协议层的重要实现,两种模型 ...
- Windows 驱动模型的发展历史
直接从win95/98说起,因为之前的系统基本上没有保护模式的概念,程序员可以直接修改任意内存的数据.在95/98中采用的内核开发模型是VxD(虚拟设备驱动),在dos时期,程序认为它们拥有系统的一切 ...
随机推荐
- python爬虫--爬虫与反爬
爬虫与反爬 爬虫:自动获取网站数据的程序,关键是批量的获取. 反爬虫:使用技术手段防止爬虫程序的方法 误伤:反爬技术将普通用户识别为爬虫,从而限制其访问,如果误伤过高,反爬效果再好也不能使用(例如封i ...
- 时间轮算法(TimingWheel)是如何实现的?
前言 我在2. SOFAJRaft源码分析-JRaft的定时任务调度器是怎么做的?这篇文章里已经讲解过时间轮算法在JRaft中是怎么应用的,但是我感觉我并没有讲解清楚这个东西,导致看了这篇文章依然和没 ...
- js中的对象知识总结
文章目录: 1. 比较两个对象是否相等 1. 比较两个对象是否相等 通过===运算符,只有在两个变量指向同一个对象时才返回true,否则返回false.要想比较两个对象中的内容是否相等,需要利用遍历对 ...
- var和let部分浅析
ES6中新增了let命令,用于声明变量,但所声明的变量只在let命令的代码块内有效. 举个例子: var a = []; for(var i=0;i<10;i++){ a[i] = functi ...
- Openresty快速安装
1. 场景描述 软件老王帮同事初始化服务器,需要安装下Openresty,安装过好多次,但是命令还是记不住,这次又安装记录了下,直接按下面的命令next-next就行了,2-3分钟左右就ok了. 2. ...
- orleans 2.0 进阶之自定义持久化储存
一丶简单介绍下目录结构和项目依赖,如图 二丶主要核心自定义代码 1. 添加自定义实现类 CustomProvider public class CustomProvider : IGrainStora ...
- 微信小程序—支付宝小程序与微信小程序的不同点对比
支付宝小程序语法 http://caibaojian.com/aliapp-wxapp.html https://www.cnblogs.com/bgwhite/p/9447639.html http ...
- everspin自旋转矩MRAM技术
MRAM的主体结构由三层结构的MTJ构成:自由层(free layer),固定层和氧化层.自由层与固定层的材料分别是CoFeB和MgO.MRAM 是一种非易失性的磁性随机存储器.它拥有静态随机存储器( ...
- Linux修改History历史命令数量
****打开 vim /etc/profile vim /etc/profile 追加配置 # /etc/profile: system-wide .profile file for the B ...
- Linux下执行脚本文件出现-bash: ./startup.sh: /bin/sh^M: 坏的解释器: 没有那个文件或目录
原因:脚本文件是在Windows环境下编辑的,windows环境下,每一行的结尾是\n\r,而Linux环境下,每一行结尾是\n.使用cat -A filename 可以看到每行的结尾后面多出了一 ...