---
title: 区块链交易的并行执行
date: '2022-07-22 12:50:19'
draft: false
summary: 借公链扩容问题，讨论并行执行的意义和边界。
slug: parallel-execution-in-blockchains
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/4794135871490516
- platform: X / Twitter
  url: https://x.com/jolestar/status/1550463248574853121
tags:
- blockchain
- execution
- scaling
topics:
- crypto
type: post
---

前阵子和朋友讨论区块链交易的并行执行，这也是 Aptos 和 Sui 这类新 Move 链重点强调的特性之一。

我所了解的比较早的一次工程实践，是 2018 年左右在 Khipu 这个用 Scala 实现的 Ethereum 节点里做过并行执行的尝试。

这里顺着这个话题，把并行执行以及它和公链扩容的关系一起理一理。

很多人的理解的区块链只能按顺序逐个执行交易，每个交易都要修改状态树，后一个交易只能依赖前一个交易的状态执行，那怎么实现交易的并行执行呢？其实大多数区块链的状态树的根只在区块头中记录一次，也就是说，区块内的交易执行顺序变化，并不会影响最终的结果，除非多个交易之间有依赖或者冲突。

那怎么知道交易有没有冲突呢？

可以先假设它们互相不冲突，然后一起执行，执行后再根据执行结果计算交易之间有没有冲突。把没有冲突的结果直接写到存储，有冲突的再按顺序重新执行。

这种并行的效果取决于两方面：1. 区块内交易数，交易数越高并行度越高。2. 交易间状态的冲突概率，概率越小并行度越高。逻辑上讲，只要区块足够大，CPU 足够多，TPS 就可以无限高，当然前提是网络同步得能跟得上。

而 Move 在这方面能提供的改进主要是它的状态存储机制，可以将合约的全局状态拆分到用户账户下面，这样就降低了冲突的概率。

那能不能在执行前就知道交易有没有冲突呢？有的读者估计已经想到了，那就是 UTXO 模型。UTXO 模型里，每个交易的输入都是需要在交易里明确表明，执行的时候就可以通过静态方式分析出是否有冲突。

而 Sui 对 Move 的状态存储机制做了一些改变，所有的状态都必须表达为 Object，每个 Object 有个唯一 ID，每个交易都必须在交易的参数中表明合约里要操作的 Object ，有点像 UTXO 的模式了。当然，这要求操作的状态必须在构造交易时就是确定的，对合约的表达能力有一定的限制。

就着这个话题继续说说公链扩容的路线问题。当前公链扩容无非高 TPS 扩容，分片或多链扩容，分层扩容三个大方向。而到底哪个方向最终可行，不同的人有不同的看法，不同的方向也各有各的难题。

1. 高 TPS 扩容：所有的应用都在同一层不靠谱吧？跑个步把银行的清算程序给堵了，破产了找谁说理去。

2. 分片或多链（子链子网）扩容：分了还怎么吹可组合性？一个应用一个链？花这么多钱跑个链出来做应用，应用做不起来咋整？

3. 分层扩容：Layer2 还不够吧？这跨个层貌似和跨个链也区别不大。

软件世界没有银弹，只有取舍和折中。很多人看公链项目看的眼花缭乱，共识，智能合约语言，计算以及网络模型等各有特点，不知如何取舍。其实扩容就三个大方向，剩下的就是各种改进的排列组合探索。如果你发现了一种新的排列组合，现在还没有项目，那恭喜你，你发现了新公链的机会，可以去拉投资了