比原链设计思考: 扩展性UTXO模型

用户模型是比原链在最初就需要确定的重要数据结构, 团队的选择还是聚焦在两种典型的模型系统中,Account模型和UTXO模型,和其他大多数区块链设计一样, 选择了模型就决定了协议层的重要实现,两种模型各有利弊,不同区块链针对想聚焦的场景自身会有判断。

UTXO 的起源(来自高明的中本聪)

中本聪对比特币的设计,让整个世界进入了数字货币时代。比特币起源于中本聪,UTXO出自比特币。自然,UTXO来自高明的中本聪。UTXO的优点:

  • 在版本控制方面的考虑,svn 是中心化的数据库保持一份账本,这和区块链的设计自然是相违背的,git 是去中心化的数据库,但会保存太多冗余数据,对于分布式性能肯定是要大打折扣。UTXO数据库是抛弃了历史包袱的git, 只存储了最后一个版本。简易实用。

  • UTXO 具有天然的匿名效果,一个账户所对应的未花费交易是难以发现的,如门罗币就是采用混币的方式实现隐私的。
  • 在性能方面,由于UTXO是独立的数据记录, 那么就存在极大的并行性可以提升区块链交易验证速度。

设计的易实现性 — 以太坊 弃UTXO用账户模型

以太坊黄皮书的设计者Gavin Wood 对UTXO的理解,十分深刻, 既然UTXO有这么多的优点,他为什么弃用UTXO了? 这时你应该提出个问题,以太坊的最大亮点是什么?你肯定会回答:智能合约。正是因为智能合约的考虑,Gavin Wood要基于UTXO去实现图灵完备的智能合约(功能多样性的超级电脑)是困难的。而账户模型是天然的面向对象的,对每一笔交易,都会在相对应账户上进行记录(nonce++)。为了易于管理账户,而引入了世界状态,每一笔交易都会改变这个世界状态。这和现实世界是相对应的,每一个微小的改变,都会改变这个世界。

追求更高的性能

以太坊的账户模型很容易的实现了超级电脑模型。然而,性能一直是一道难以逾越的坎。在性能方面,utxo天然的可以并行运行,而基于世界状态的以太坊难以扩展。Gavin Wood当然是认识到这一点的,但要去改变,很难。那到不如用带有函数式编程特点的rust 去重写以太坊,也算是一种折中方案。

比原链的思考

马克思哲学的否定之否定规律,事物的发展变化是螺旋式上升的。在区块链领域也是适合的,前进一步,也需要后退半步。基于UTXO模型去实现堆栈式虚拟机, 那还是会失去灵活性,用UTXO去结合以太坊EVM, 难度极大,也是不太实用的,这好比用haskell语言,去实现cpp风格的面向对象编程, 看不到有什么实际的意义。世界上没有银弹,比原链必须舍弃部分,妥协部分才能更好地适应场景。

我们在采用了比特币UTXO的易于并行运算的模型前提下,还做了针对性的改进,加了个资产号字段,使不同的资产可以在同一笔交易中处理转换,只要满足总输入等于总输出就可以。

但为了数据易于管理,易于编程, 我们引入以太坊的世界状态的概念,每一种资产都维持一个全局世界状态,该全局世界状态具有快速可查找,不可更改,简单易提供证明的特性。它的具体实现会参考以太坊的PAT树(一种扩展的基数树),比特币的merkle树,以及cosmos的IAVL树(一种不可更改的平衡二叉树)。每一种资产的所有outputs在一个全局的UTXO数据库中会有一个索引计数(每一个output的计数不能超过1,保持并行计算时,一个output最多能被一个BVM实例所使用,确保了数据一致性)。BVM是比原链实现的智能合约虚拟机模型, 每一笔交易的的执行,都会实例化一个BVM实例,只有在BVM实例中,各资产的世界状态才能在保持有效性,一致性的前提下更新状态。BVM可以并行创造多个”合约沙盒”实例, 在沙盒中合约的运行不受外界影响。

比原链创造的初衷是解决数字资产登记流转的问题, 对于公有链项目,保持简洁,保持高效,保持专注,就是保障安全, 新的扩展型UTXO模型正是基于这种场景实现的融合和改进。

原文地址:https://www.cnblogs.com/bytom/p/9372089.html

时间: 2024-10-01 22:31:59

比原链设计思考: 扩展性UTXO模型的相关文章

社区观点 | 理解比原链MOV链上交换协议

去中心化交换协议的发展 从Bitshare,Stellar到以太坊上的Etherdelta,Bancor,0x协议,去中心化交换协议也经过了好几代发展和很多模式的探索,每一代都通过前面的协议的痛点来进行改进和深化, 主要分为: 链上orderbook,链上结算; 链下orderbook,链上结算; 基于智能合约管理的资金池; 链上orderbook,链上结算 最早的 基于以太坊的去中心化交换协议的成功探索非Etherdelta莫属,曾一度占据去中心化交换市场的半壁江山.Etherdelta是较为

在设计IOSapp时为了代码的扩展性可可维护性需要遵守的原则

作为软件工程范畴的iosApp,为了保持代码的可维护性和扩展性,必然要遵守软件的基本特性,众所周知高内聚低耦合的程序才能具备这样的特性. 首先,不能依赖于storyboard和xib,原显而易见.第一点是,在源代码管理方面,在团队项目中,一旦有人改变了一点内容storyboard就会显示modify的样子,所以让人看起来很不安,其实带着M的原因很可能就是其他团队成员鼠标手点击了一下而已,最新的源代码管理工具在Xcode中的集成基本上解决了这个问题,但是依然还是会产生严重的代码冲突,这不是团队人员

《.NET 设计规范》第 6 章:扩展性设计

第 6 章:扩展性设计 6.1 扩展机制 考虑用不包含任何虚成员或受保护的成员的非密封类来为框架提供扩展性.这种方法所提供的扩展性广受用户欢迎,而且它的开销也不高. 考虑将受保护的成员用于高级的定制方案. 要在对安全性.文档及兼容性进行分析时,把非密封类中受保护的成员当做公有成员那样来对待. 考虑使用回调函数来允许用户向框架提供自定义的代码供框架执行. 考虑使用事件来允许用户对框架的行为进行定制,这样就不需要用户对面向对象设计有深入的了解. 要优先使用事件,而不是简单的回调函数,其原因在于广大开

数据库扩展性设计:使用二进制解决一条记录关联多个状态的问题

程序开发中,经常遇到一条记录有多个状态位,比如一条商品,他属于热门,新品,特卖.我们的数据库如何设计呢? 一般有几种方法 (1)建立关联表 关联表字段:关系Id,商品Id,属性Id 查询:使用关联表的方式,查询某属性的商品. 程序:写入时,写商品表和关联表: (2)将多个属性存在一个字段中,用|分割 状态存储在一个字段中,比如某条商品属于热卖,新品和特卖,则字段存储的值:01|02|03 SQL查询:使用like 程序处理:(1)取值需要先将01,02,03分割,再处理.(2)写入需要先将01,

深入NGINX:我们如何设计它的性能和扩展性

英文原文:Inside NGINX: How We Designed for Performance & Scale 为了更好地理解设计,你需要了解NGINX是如何工作的.NGINX之所以能在性能上如此优越,是由于其背后的设计.许多web服务器和应用服务器使用简单的线程的(threaded).或基于流程的(process-based)架构, NGINX则以一种复杂的事件驱动(event-driven)的架构脱颖而出,这种架构能支持现代硬件上成千上万的并发连接. Inside NGINX info

Atitit.软件架构高扩展性and兼容性原理与概论实践attilax总结

1. 什么是可扩展的应用程序?1 2. 松耦合(ioc)2 3. 接口的思考 2 4. 单一用途&模块化,小粒度化2 5. 组合(Composition),而不是继承(inheritance) 2 6. Ocp原则开闭原则2 7. Plugin系统2 8. 流程扩展工作流系统,流程自定义2 9. Ui扩展 html53 10. 数据独立性3 11. 脚本与hotdeploy3 12. 表处理扩展if else (数据与数据处理相互分离)3 13. 系统被扩展的几种形式(方法级别,模块级别)3 1

链圈的朋友们值得收藏!腾讯首席架构师教你两种区块链设计思路

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由敖萌发表于云+社区专栏 区块链发展到了现在,产生了很多不同形式的区块链技术.随着技术的发展,目前比较公认的看法是区块链已经走进了2.0时代.区块链1.0是以比特币为代表的去中心化数字货币区块链系统,而2.0则是引入了智能合约的区块链系统. 在支持智能合约的区块链系统中,Linux基金会所属的Hyperledger Fabric(由IBM贡献)和Vitalik Buterin所领导的以太坊基金会所创造并管理的Ethereum(以太坊

浅析Facebook LibraBFT与比原链Bystack BBFT共识

如果说什么是区块链的灵魂,那一定是共识机制. 它是区块链的根基.无论公链或是联盟链,共识机制都从基础上限制了区块链的交易处理能力和扩展性. 2019年6月18日,Facebook 发布了自己 Libra 项目的白皮书,引发广泛关注.作为 Facebook 试图创造国际流通数字货币的重要项目,Libra 区块链采用的是 LibraBFT 共识机制,是一个为 Libra 设计的鲁棒的高效的状态复制系统.它基于一种新型的 BFT 共识算法,HotStuff. 就在 Facebook Libra 项目白

服务的扩展性

在编写一个应用时,我们常常考虑的是该应用应该如何实现特定的业务逻辑.但是在逐渐发展出越来越多的用户后,这些应用常常会暴露出一系列问题,如不容易增大容量,容错性差等等.这常常会导致这些应用在市场的拓展过程中无法快速地响应用户的需求,并最终失去商业上的先机. 通常情况下,我们将应用所具有的用来避免这一系列问题的特征称为非功能性需求.相信您已经能够从字面意义上理解这个名词了:功能性需求用来提供对业务逻辑的支持,而非功能性需求则是一系列和业务逻辑无关,却可能影响到产品后续发展的一系列需求.这些需求常常包