05-账本模型

1 账本模型

1.1 传统线性增长模型

传统的 MySQL 等系统采用线性增长的日志模型，通过一个 Leader 和多个 Follower 进行状态同步。这种方式有单点的带宽瓶颈问题。

1.2 区块链共享账本模型

共享账本：树形增长。在去中心化网络中，可能同时选出多个合法的记账节点，导致分叉现象。通过默克尔树支持路径计算，轻节点可以查证交易是否存在于链上。P2P分散传播（Push和Pull有机结合）。

共享账本：树形增长（分支后续可能长成主干，所以分支Block也要存储）。

要支持路径计算，如：Block是否在主干上

2 事务解决方案

区块链采用两大流派解决双花问题：

1. 账户模型：类似银行账户，通过版本号防止重放攻击。
2. UTXO 模型：未花费的交易输出，类似现金支付，每个交易的输出来自之前某些交易的输入。

Xuper Chain 采用优化的 UTXO 模型，支持更广泛的数据领域，提升并发性能。

2.1 账户模型咋实现事务？

用递增的版本号检测冲突，本质串行。

由于版本号冲突，这两个交易只能有一个成功。

2.2 UTXO模型咋实现事务?

通过判断交易的输入引用是否有冲突，并发性能更好。

两笔交易都能成功，执行顺序还可以乱序。

案例

奶奶给孙子50，让他买东西吃，然后孙子去小卖部花了0.5买了一根棒棒糖，剩下49.5，变成私房钱。小卖部收到小孩儿的0.5。

另一个小孩0.8买了两根棒棒糖，一根0.5，两根0.8，然后收到另一个小孩的那个钱，买了一根辣条0.3。然后它现在就有0.5，0.8和0.3。

然后他现在要把钱给自己的两个孙子，说你们一人八毛，一人八毛，拿去买买买，这就是一个UTFO过程。Xuper chain对ut so模型做了一些优化

3 优化

构造一个更通用的事务模型。

当前，以太坊、EOS（一个拥有特别快的速度优势以及无限的可扩展性的智能合约平台）只能串行验证区块中的智能合约，因其底层模型无法支持并行化的确定性验证。

但经典的UTXO模型虽并发性能好，只用于转账场景，能否用UTXO模型支持通用的智能合约？

• 普通UTXO模型：一个交易花的币一定来自早先某些交易赚的币
• 扩展UTXO模型：一个事务读取的数据一定来自早先某些交易的写入数据

T2和73可并行执行、即使不同节点乱序执行，得到D的结果也一致。

4 事务引擎架构图

通过客户端向这个全节点，它的一个utxo的这个引擎啊，发送一个交易，然后交易首先。它要进行一些缓存管理，然后去执行这个交易，然后做一个交易的预执行，然后假如说有冲突的话啊。怎么办？做一个冲突处理，如果说没问题的话呢，它就把它这个广播给这个就返回这个。读写即给这个客户端，

然后客户端就发起一笔交易，然后呢？交易交易如果没冲突的话，就通过这个共识算法选出一个记账节点，然后记账节点广播。广播之后，其他全节点去验证，验证没问题的话就落块。

获取更多干货内容，记得关注我哦。