zoukankan      html  css  js  c++  java
  • 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模型中的余额,这样可以保证超级节点换届时,投票结果能够快速统计出来。

  • 相关阅读:
    形象理解ERP(转)
    禁用windows server 2008 域密码复杂性要求策略
    How to adding find,filter,remove filter on display method Form
    Windows Server 2008 R2激活工具
    How to using bat command running VS development SSRS report
    Creating Your First Mac AppGetting Started
    Creating Your First Mac AppAdding a Track Object 添加一个 Track 对象
    Creating Your First Mac AppImplementing Action Methods 实现动作方法
    Creating Your First Mac AppReviewing the Code 审查代码
    Creating Your First Mac AppConfiguring the window 设置窗口
  • 原文地址:https://www.cnblogs.com/studyzy/p/11007342.html
Copyright © 2011-2022 走看看