7-1 基础性能优化
7-1-1 区块链性能瓶颈
总述
区块链性能指标
区块链的性能指标主要包括:
吞吐量:在固定时间内处理的交易数量
延时:对交易的响应和处理时间
主流区块链与中心化平台TPS对比

区块链与传统计算的对比
区块链可信且中立,通过账本方式记录资产的所有权、合约状态或原始数据。
具体体现在
- 可信且中立
区块链没有中心化的管理员或特殊的网络权限,任何人都可以提交交易,无需担心被操控或差别对待
- 终端用户进行验证
任何用户都可以审核区块链账本的历史和当前状态
- 计算具有高的确定性
传统方式的计算没有确定性要求,而区块链是按照预定义的代码逻辑严格执行,具有确定性要求
正因如此,区块链的性能与传统计算存在较大差距。差距的来源根本在于区块链节点的扩展性不足。
区块链的链式结构限制了交易的执行必须满足世界状态的一致性和交易执行的顺序性:

三阶段的相互依赖阻碍了交易的执行效率,也造成了巨大资源的浪费,严重影响了商业场景下的响应时间。
利用机器多核或多机并行,可打破三阶段的顺序依赖,提升区块链节点的可扩展性。
共识性能
回顾:区块链的共识算法

区块链的不可能三角
根据共识算法的特性,利用不可能三角进行分析:

区块链的共识性能挑战与尝试
性能挑战
POW:比特币10分钟出1个区块,1笔交易确认的时延高达1小时
尝试探索
POW+BFT算法解决性能问题(学术界)
POW算共识节点,BFT完成共识过程
存储性能
存储性能与成本挑战

联盟链的业务场景对交易吞吐量和响应时间有很高的要求:

存储性能与成本主要面临以下挑战:
规模
性能
成本
易用性
Tips:在联盟链的普及过程中,规模、成本、效率已成为应用场景关心的主要问题,降低区块链存储成本、提升区块链存储访问性和易用性势在必行。
网络传输性能
网络是区块链系统正常运行的基础设施,交易内容、数据的转发,共识一致性都需要依赖节点间安全可靠的网络传输能力和传输效率。
传统的区块链网络架构是采用节点间直连的方式实现数据交互,这种网络架构增加了带宽成本,增大交易扩散和共识协议的耗时,导致交易吞吐量降低。
建设高性能区块链网络基础设施,提升区块链通信效率,突破区块链应用规模瓶颈,提供可靠的网络质量是区块链网络未来发展的重要方向。
传输性能对共识性能的影响
以PBFT共识算法为例,通信复杂度为O(n^2),节点规模翻倍,为保证相同的共识性能,带宽需增加4倍。实际应用中,带宽是有限的,节点规模的增加将增加共识消息的时延,制约了共识的性能。
传输性能对业务应用的影响
受公网通信时延及抖动的影响,业务应用会出现不稳定、服务质量差等问题,如何支撑大规模、稳定、高吞吐的商业服务是目前区块链发展所面临的挑战。
交易执行性能
在比特币体系中,在考虑TPS的影响因素时,基本不会考虑比特币执行脚本的时间。因为比特币的脚本是非状态的(UTXO模型),且非图灵完备,与10分钟的出块及网络同步时间相比,脚本的执行时间很短。在考虑执行性能时,重点说关于智能合约的执行:
以太坊执行智能合约性能
以太坊是图灵完备的,通过智能合约来执行交易,合约复杂程度可以较高。随着交易量的增大,以太坊执行合约性能下降较快。
执行性能低的主要因素
- 交易顺序执行
以太坊的智能合约是由发送以太坊交易来驱动的,交易的顺序会影响交易的结果,为保证系统的一致性,所有交易必须串行处理,交易需顺序发送,节点也需次序处理。
- 状态的读取(世界状态)
以太坊使用世界状态记录以太坊状态的变迁,随着交易量的增大,每读取一个特定的值产生访问数据库的次数会以log(n)的次数增加,执行合约的速度会越来越慢。
7-1-2 基础性能优化
回顾:区块链性能瓶颈
回顾:共识------执行------数据持久化,三段式的相互依赖阻碍了交易的执行效率,需进行区块链扩容
优化策略:共识算法优化、交易并行执行、存储优化
交易并行执行
什么是执行层?优化什么?
区块链执行层:指执行交易和状态变更。交易执行包括查看交易的有效性(如:验证签名和通证余额),执行链上逻辑并计算状态变更;状态变更指全节点更新账本的副本,以反映新的转账、合约代码更新及数据存储。
区块链交易执行优化:通常解决如何在每秒内,能够处理更多的计算量(提升每秒处理的交易量TPS),同时无需大幅提升节点验证交易的硬件要求。
交易执行优化主要方法:
分片与并行执行
蚂蚁自研并行执行引擎
支付和状态通道
Rollup
分片
分片扩容方法:将一条区块链分成很多片,并行执行。每个分片都是一个区块链,另外还存在一个主链,去保持所有分片同步。与多链生态不同的是,分片之间共享同一节点池,也会共享同样的安全机制。
分片执行时的节点池:会分散到各个分片上去执行交易,节点会定期随机轮转,不会总执行或验证同一分片上的交易。
分片并行执行
优势:无需建立新的安全机制,因为共享同一节点池,所以每个执行环境可达到同样的安全水平。
劣势:
- 由于采用共享安全模式,所有分片都可能会出现同样的安全漏洞;
- 主链计算需求越来越大,每个分片上分到的节点数量可能不够,因此一条区块链可以支持的分片数量会存在上限。
蚂蚁自研并行执行引擎
并行共识+执行流水策略

可同时完成多批次的共识提议,而执行阶段采用执行------状态提交------数据持久化流水线模式
并行问题:对于并行处理的方式,区块链交易之间可能存在读写数据的相关性会影响并行执行结果的一致性。
蚂蚁链采用预执行的方式提前获取交易读写集信息,并基于读写集信息完成交易分组,去保证并行处理的一致性。
支付和状态通道
支付和状态通道实现区块链扩容:用户将交易锁定在多签合约中,发起链下交换签名的信息,消息加密,代表了资产所有权转让或状态变更信息。整个过程无需发起任何链上交易。
优势:低成本、低延迟,交易确认速度快
劣势:适用于小额支付;对所有权确认不如传统链上交易。
Rollup方法
优化区块链的交易性能,一方面是直接对区块链本身进行优化改造,提升链的处理效率;另一方面,是将交易和执行放到链下,区块链仅仅做交易有效性验证。
- layer2扩容方案,通过链下对大量的数据进行处理,极大提高了区块链的整体效率。
- Rollup是layer2方案中经过多次优化和改进后,现在较为主流的技术方案。
Rollup的本质
将原本分布在区块中的大量交易数据打包成一笔集合的交易,发布到链上。
Rollup方法原理
Rollup通过额外部署一条子链的方式,来实现对数据交易的处理和执行。这条子链可以和主链拥有不同的共识机制,也可以有不同的节点,有着极高的自主性。

Rollup可以理解为是一种侧链的处理形式。因此它会生成区块,并且将这些区块的快照发送到主链上。

高性能共识算法
共识层优化不仅为提高速度,还要考虑提升准确性、稳定性及安全性。可考虑以下几个方面进行优化:
提升执行和存储能力
减少网络带宽使用
降低网络延迟
设置经济激励
对于联盟链来说,更加注重隐私、安全及执行效率,对节点规模要求不高,根据区块链"不可能三角",联盟链根据节点的准入,赋予了节点更多的信任。联盟链常用的共识算法主要倾向于拜占庭类共识(CFT)。
蚂蚁链同样也选择了兼顾安全和性能的BFT类共识算法,自研了MyBFT和MyTumble共识。
MyBFT共识:
功能:与传统的PBFT相比,MyBFT增加了共识窗口流水线功能,以及状态持久化等功能,不仅可容忍不超过三分之一的拜占庭节点,还能容忍任意数量的诚实节点同时宕机后重启。
适用环境:网络环境稳定、高性能的场景
性能:可适配4-100共识节点的规模,共识TPS达10w笔/s
MyTumble共识:
功能及优势:由蚂蚁链自主研发的高吞吐、低延迟的纯异步共识协议,相较于PBFT、Hotstuff等半同步共识协议,纯异步共识协议在网络情况不稳定时表现出更强的鲁棒性。
适用场景:更适用于开放网络和广域网的部署。
蚂蚁链的共识优势:
- 支持对共识参与方的增加、删除,修改这里面的修改是指参与方共识身份的切换;
- 支持对不同共识算法的切换,商业场景中可根据业务节点规模、交易规模等情况的调整实时切换,同时,蚂蚁链采用服务化的系统架构,在未来共识算法的演进中,可以方便地集成新共识算法,而不涉及到系统结构的变化;
- 支持共识参数的修改,如共识提议的交易数量、共识超时检测的时间等,确保可根据交易规模、网络环境实时调整;
存储优化
存储层指全节点维持和存储账本副本,区块链的存储功能通常分为两类:
- 历史数据:包括所有原始交易和区块数据。历史数据通常无需快速访问,只需要至少一个诚实节点就可以下载。
- 全局状态:全部数据的快照,智能合约可以对其进行读写,比如所有合约的账户余额及变量。
区块链存储层优化:通常解决如何让区块链既能处理并验证更多数据,又不用提高对全节点的存储要求。
数据分片技术
数据分片扩容方法:将账本数据或重建账本所使用的数据分成不同分片,降低对每个节点的存储要求。
优势:提升区块链的存储能力并降低存储成本。
劣势:区块链承载的分片数量存在上限;数据分片会产生更高的通信成本,当节点轮转到其他分片时需要相互交换存储数据。
蚂蚁链的存储引擎
蚂蚁链自研了存储引擎Letus,Letus主要优势如下:
- 大规模&高性能优势:
4个共识节点下,20亿账户规模下,转账能达到10w,实测为20个worker支持20亿账户规模,最高TPS为12.2w。

- 极大地降低区块链节点成本
- Letus在区块链数据的空间放大在1倍左右,状态数据在2倍左右,相比于传统MTP+RocksDB动辄几十倍的放大而言有了质的提升。

- 支持数据的冷热划分,可以将不常用并且时间相对久远的区块保存在低价冷介质中,但是可以支持低频的访问。
- 可以通过裁剪算法后台将不需要历史版本的状态数据删除,不影响正常出块的运行。

蚂蚁链自研了存储引擎Letus支持冷热分层能力:
针对历史区块的低频访问特性,实现热点区块数据保存在高性能存储介质中,满足业务读取以及节点数据同步的高频需求,而历史区块存在在廉价介质中降低成本,同时提供可靠访问能力。

7-2 区块链扩容技术
7-2-1 区块链扩容方案
扩容方案简介
为什么要扩容
比特币和以太坊作为区块链1.0和2.0的代表,早期的比特币区块大小为1M,每秒大约只能处理7个交易,性能为7TPS。
以太坊每秒只能处理15个交易,性能为15TPS。
缓慢的交易处理速度会造成大量冗余,降低整体网络性能。
扩容的主要目标是提升交易速度(更快确定交易)和交易吞吐量(提高每秒交易量),而不影响去中心化或安全性。
链下扩容
链下扩容(off-chain scaling)也称Layer2(简称L2)扩容,将区块链上的部分运算任务放到链下(以太坊之外的第二层网络)进行,并将计算结果传回链上,从而实现区块链运算能力的提升。

侧链技术
以太坊侧链是一个独立的区块链网络,与以太坊主链并行运行。侧链通过双向挂钩系统与主链连接,允许资产在侧链之间进行交换。
侧链有两种基本类型,一种是相互依赖的,另一种是相互独立的。

侧链实现的技术基础是双向锚定(Two-wayPeg)
通过双向锚定技术,可以实现将数字资产在主链中锁定,同时将等价的数字资产在侧链中释放
将等价的数字资产在侧链中被锁定,同时将主链的数字资产释放
双向锚定实现的最大难点是协议改造需兼容现有主链,即不能对现有主链的工作造成影响
其具体实现方式可以分为以下几类:
- 单一托管模式
通过将数字资产发送到一个主链单一托管方,当单一托管方收到相关信息后,就在侧链上激活相应数字资产。
本方案最大问题是过于中心化
- 联盟模式
是使用公证人联盟来取代单一的保管方
利用公证人联盟的多重签名对侧链数字资产流动进行确认
在这种模式中,如果要想盗窃主链上冻结的数字资产就需要突破更多的机构,但是侧链安全仍然取决于公证人联盟的诚实度。
- SPV模式
SPV(Simplified Payment Verification)模式是最初的侧链白皮书《Enabling Blockchain Innovations with Pegged Sidechains》中的去中心化双向锚定技术最初设想。
SPV是一种用于证明交易存在的方法,通过少量数据就可以验证某个特定区块中交易是否存在。
主要原理:
- 用户在主链上将数字资产发送到主链的一个特殊地址,锁定主链的数字资产
- 创建一个SPV证明并发送到侧链
- 一个对应的带有SPV证明的交易会出现在侧链上,同时验证主链上的数字资产是否已经被锁住
- 若已被锁住,此时可以在侧链上打开具有相同价值的另一种数字资产
SPV模式存在的问题是需要对主链进行软分叉。
- 驱动链模式
驱动链概念是由Bitcoin Hivemind创始人Paul Sztorc提出。
在驱动链中,矿工作为"算法代理监护人",对侧链当前的状态进行检测。
矿工本质上就是资金托管方,驱动链将被锁定数字资产的监管权发放到数字资产矿工手上,并且允许矿工们投票何时解锁数字资产和将解锁的数字资产发送到何处。矿工观察侧链的状态,当他们收到来自侧链的要求时,他们会执行协调协议以确保他们对要求的真实性达成一致。
诚实的矿工在驱动链中的参与程度越高,整体系统安全性也就越大。
如同SPV侧链一样,驱动链也需要对主链进行软分叉。
状态通道
状态通道是通过在不同用户之间或用户和服务之间建立一个双向通道,为不同实体之间提供状态维护服务。
允许把区块链上的许多操作在链外进行管理,等完成链外操作后多方签名确认后,才将最终结果上链。

举例说明:
小明经常去自助餐厅吃饭,每次除了支付0.1eth餐费之外,还需要支付一笔小费给处理付款的服务员。
如果小明与餐厅有一个直接的支付通道,可以重复安全地转移金额,小明就不需要服务员来协助处理付款,从而节省下小费的开支。
利用区块链技术,可以设计如下:
创建一个支付通道智能合约,并存入100元(链上)
每次就餐时签名一条交易信息给老板(链下)。交易信息包含:第几次购买、共要支付多少钱、签名信息。
餐厅随时可以把签名信息发送给链上支付通道智能合约,取回资金。
小明不想再去该餐厅就餐,可以取回支付通道的余额。
优点
- 具有良好的隐私性
不管在状态通道上发生了多少的瞬时交易,这些交易都是在通道内部发生的,并没有广播和记录在链上,其他人不会知道,所以具有非常好的隐私性。
- 即时终结性
只要状态双方都签署了状态更新,这个状态就可以被认为是最终状态,大家可以随时退出。
- 适合长时间多状态更新
状态通道特别适合那些需要长时间交换许多状态更新的参与者,因为在部署合约的时候,创建的状态通道有一个初始成本,而一旦部署完毕,状态通道的边际成本就接近于零。
缺点
- 不适合低频操作
每打开和关闭一个状态通道都需要一个链上交易。打开状态通道如果只给发1笔交易,还需要在链上做其他的两笔交易,支付额外手续费。因此它不适合低频操作。
- 双方随时保持在线
由于挑战期的存在,状态通道的参与者需要一直在线,如果不在线,资产就可能损失掉,需要一直在线对于参与者来说确实是一件不友好的事情。
- 确定的参与者
因为状态通道的法官合约始终需要知道作为通道的一部分的实体(地址),当需要添加和删除成员的时候,每次都需要更改合约,重新建一条通道,过程繁琐。
Rollup
Rollup工作原理
Rollup方案的核心思想是将打包后的交易数据区块发布在链上,从而降低交易有效性验证的难度。
操作者收集不同参与者提交的一批链下交易,在链上执行Rollup智能合约提供的脚本,将打包后的交易数据区块作为参数提交给合约。
实现链上一个交易完成链下一批交易。
Rollup两种主流方案:
- Optimistic Rollup
Optimistic Rollup假定所有交易从一开始就是有效的。为了确保这些交易的安全,Optimistic Rollup网络提供了一个挑战期(challenge period),网络验证者可以通过父链(比如以太坊)上一个欺诈证明(fraud proof)来质疑某笔交易的合法性。通过仅在怀疑存在欺诈时执行证明,Optimistic Rollup显著提高了吞吐量并减少了延迟(交易确认时间)。挑战期通常为7天。

- ZK-Rollup
ZK-Rollup并不是假设所有交易在被证明有效之前是有效的,而是使用有效性证明(validity proofs)来立即验证交易。
这些有效性证明和压缩数据被提交至以太坊L1进行链上验证。
有效性证明是非常复杂和耗时的,因此与Optimistic Rollup相比,ZK-Rollup存在较大延迟。
由于生成密码证明(有效性证明)需要大量的计算,需要高规格的硬件,从而使得普通用户难以参与。
Optimistic Rollup对比ZK-Rollup
| 特性 | Optimistic Rollup | ZK-Rollup |
| 每batch的固定gas消耗 | 约40,000(轻量交易,主要只是改变状态根的值) | 约500,000(验证ZK-SNARK所需计算量较大) |
| 提款期 | 约一周 | 极快(到下一个批次交易) |
| 技术复杂度 | 低 | 高(基于ZK-SNARK,数理复杂) |
| 通用性 | 易达成 | 难达成(使用ZK-SNARK证明的通用EVM计算证明难度大) |
| 每笔链上交易的gas消耗 | 较高 | 较低(仅发布引起状态改变的数据,省略仅用作验证的数据) |
链下计算成本 | 较低(需大量全节点计算) | 高(针对通用计算的ZK-SNARK证明比直接运行计算贵数千倍) |
---|
链上扩容
链上扩容(on-chain scaling)也称layer1(简称L1)扩容,是指为了提高区块链的吞吐量而对以太坊协议进行直接修改。

数据层扩容方案
SegWit(隔离见证)
被打包进区块的交易数据包括数字签名(scriptSig)和其他交易信息,数字签名便占用了全部交易数据60-70%的空间,但是数字签名仅仅在验证阶段需要。
隔离见证即隔离(segregate)数字签名(witness)与其他交易数据,提升单个区块所能容纳的交易数量,通过"缩小"交易数据变相扩大了区块大小,BTC采用了隔离见证的扩容方式。
举例:客车容量不变的情况下,将乘客的行李全部放到车厢顶部,从而能运载更多的乘客。

扩块
每一个区块里面都承载着某一个时间段的数据。以比特币为例,每个区块包含着全球十分钟内所有比特币交易。当区块大小设定为1MB时,最多只能包含2000多笔交易。
扩块基本原理是提升单个区块内的交易数,每秒打包的交易就会增加,从而提升TPS。
众多扩块方案中提及比较多的是2MB区块扩块方案,比特币社区的另外一部分人希望硬分叉直接把区块大小限制从1M改到2M
举例:从普通公交车变成双层公交车,提升了容量,载客量变大。
网络层扩容方案
网络层扩容理念及背景
在交易过程中,如果每笔交易都需要网络中的每个节点进行确定,必然造成交易阻塞。分片即将网络、交易、状态进行分片,对节点由随机序列分配成多个碎片,当网络中接收到待确定的交易,系统随机分配给各个碎片,这些碎片呈现独立状态,可以完成区块链信息确立。
"分而治之"是分片技术的支撑性设计理念,相当于处理交易数据时,同时开通多个通道同步进行,而仅仅是对节点进行简单随机分配,还无法真正实现水平扩容,在运作过程中存在攻击隐患,所以,需再进一步分片处理,包括网络分片、交易分片以及交易状态分片
网络分片
网络分片是指将区块链分成不同部分,即多个分片,分片可以并行处理事务,从而提升了单位时间内处理交易的数量。假设网络存在1000个节点,将网络划分成10个分片(每个分片100节点)。若1组分片能在一定时间内验证400笔交易,那么10组分片便能在同样时间内验证4000笔交易。
举例:超市里有100个收银员,但只有1个收银台,分片后增加9个收银台,每个收银台分别有10个收银员负责结账。
交易分片
将交易按某种规则分配到不同的分片。其思路为,按一定的规则将交易分配到同一个分片处理,则既能够达到并行处理的目的又能避免双花问题的出现。
账户/余额模式
由于一笔交易只有一个输入,因此只要将交易按照发送者地址进行分片,就可以保证同一个账户的多笔交易在同一个分片处理,有效防止双花。
UTXO模型
一笔交易可能包括多个输入和多个输出,仅仅按照地址分片无法避免双花问题,分片之间不得不进行通信,如果限制跨分片交易将限制平台的可用性,而允许跨分片交易则不得不权衡跨分片通信的成本和性能提升带来的收益。
状态分片
状态分片技术的关键是将整个存储区分开,让不同的碎片存储不同的部分;
每个节点只负责托管自己的分片数据,而不是存储完整的区块链状态。
面临挑战
- 跨分片交易通讯的效益平衡
- 分片动态刷新和节点状态更新之间的平衡
- 全网数据备份与中心化风险之间的平衡
共识层扩容方案
非BFT类共识
通过降低共识算法复杂度和减少传播节点数量等方式减少验证时间、传播时间及形成共识时间,能够显著提升处理效率。
PoS(Proof of Stack,权益证明)
相比于PoW(Proof of Work,工作量证明),PoS以权益(持有通证数量*通证持有时间)代替算力决定区块记账权,减少了PoW工作量证明过程的能源消耗,在一定程度上解决了可扩展性问题。但是又带来了马太效应、记账激励、无利害关系攻击(Nothing-at-stake attack)等新的问题。
DPoS(Delegated Proof of Stack,委托权益证明)
DPoS在PoS的基础上将记账人的角色专业化,通证持有人通过权益选出多个授权代表(EOS有21个"超级节点",Bitshares有101位代表,理论上单数节点均可),授权代表轮流记账。这种共识下效率得到了明显提升,但是牺牲了非中心化。
BFT类共识
不同于非BFT共识的间接达成共识(即参与者并非直接决定共识的具体内容),BFT类共识下,参与者通过投票决定共识内容直接达成共识,在参与者数量不是很多的情况下(一般BFT网络直接参与共识的节点在100个以内),TPS可以达到10000。
非BFT类共识下存在分叉可能,以BTC为例,通常需要6个区块才能以很高的概率确认某个交易被网络确认,而在BFT共识下,达成一致的共识不会被丢弃,因此BFT的响应时间(交易从提出到被确认的时间)也明显优于非BFT类共识。
BFT类共识的主要问题在于网络规模、容错率等方面。
混合共识
出现原因:任何单一的共识机制均有各自优势及缺点。
方案:采取混合共识机制,指结合了多种不同的共识机制,结合各自的优点相互配合达到更好的实际效果
案例:
Casper采用PoW+PoS
EOS采用DPoS+BFT
7-2-2 区块链扩容典型项目
闪电网络
闪电网络通过建立状态通道的方式,将部分频繁的小额交易放在链下完成,从而减轻主链的交易压力。
闪电网络技术的核心是建立一个安全、可行的链下支付通道,同时结合多重签名地址技术、RSMC序列到期可撤销合约、HTLC哈希时间锁定合约等技术完成支付的结算与确认,进而提高用户支付的效率。
举例说明

支付通道创建
创建一个序列到期可撤销合约(RSMC),Alice和Bob是合作方,经常有比特币往来,所以他们决定各自拿出0.5BTC放入通道中,便于业务往来。

交易更新
- Alice转账0.1BTC给Bob

核心技术
多重签名地址
原因:比特币多重签名地址是为了实现比特币资产的多方管理的一种技术。最初版本的比特币签名机制是单一地址管理的,即地址的持有人单独管理,只有本人拥有私钥。如果持有者丢失了私钥,将直接失去该笔链上资产。
方案:为了规避丢失私钥而丢币的风险,提出了多重签名的技术解决方案。即N个用户分别持有N个私钥,只要其中M个用户拿出私钥就可以动用某个多重签名地址里的比特币。这里的M需大于等于2,小于等于N。
RSMC合约
RSMC(Recoverable Sequence Maturity Contract)即"序列到期可撤销合约"。
假定交易双方之间存在一个"微支付通道"(资金池)。交易双方预先存一部分资金到"微支付通道"里,初始情况下双方的分配方案等于预存的金额。每次交易发生,双方需对交易后产生资金分配结果共同进行确认,同时签字作废旧版本分配方案。任何一方需要提现时,将双方签署过的交易结果写到区块链网络中,从而被确认。只有在提现时才需要通过区块链。
任何一个版本的方案都需要经过双方的签名认证才合法。任何一方在任何时候都可以提出提现。提现时需要提供一个双方都签名过的资金分配方案(意味着肯定是某次交易后的结果,被双方确认过,但未必是最新的结果)。在一定时间内,如果另外一方拿出证明表明这是一个作废方案(非最新的交易结果),则资金罚没给质疑方;否则按照提出方的结果进行分配。欺诈验证消除了任何一方拿旧的交易结果用以提现的风险。
对于双方确认的某次提现,首先提出一方的资金到账时间要晚于对方。此设计鼓励参与者在链外完成交易。
通过RSMC,可以实现大量中间交易发生在链外。
HTLC合约
Hashed Timelock Contract,哈希时间锁合约,主要过程如下:

HTLC合约主要由2部分构成:
哈希值锁定:确保仅获取到最终接收方生成的密码方可解锁,并获得冻结的资产;
时间锁定:
确保转账方在一定时间内(最终接收方解锁取走比特币前)无法取走冻结款项
确保在一段时间后如果最终接收方没有提现,转账方可以取回冻结款项
Plasma
Plasma链是一个树状区块链结构,用以太坊为例:
以太坊是树根,称之为根链;
以太坊Plasma链是树干,并有父链及子链两种形式:
- 树干Plasma链可以衍伸出树枝Plasma链
- 父链(Parent Chain)与子链(Child chain)是相对的
- 树干Plasma链是树枝Plasma链的父链
- 树干Plasma链同时是以太坊的子链

优点
- 规模化
具备高可扩展性
根链最大延伸一百个Plasma链
每个Plasma链可延伸一百个Plasma子链
以太坊网络吞吐量增加一万倍
- 信任最小化
子链定时而非实时上传区块哈希至父链
父链缺省认定子链交易无问题
父链仅在子链主动提出审查请求方介入
子链关系人需主动检查自己的资产,对普通使用者体验不佳
- 全新的应用开发方式
每条Plasma链均可由去中心化应用开发商或其他项目方开发与维护
项目方可以自行制定该Plasma链上应用规范,增加开发灵活性
工作流程
进场机制
将资产从以太坊转移到Plasma链需将资产转入以太坊相应Plasma智能合约,即可获得相应的token,用于在该Plasma链上进行交易。
退场机制
申请退出Plasma需要接受七天的挑战期
挑战期内,挑战者可向父链智能合约提出欺诈证明
欺诈证实,则意味着挑战者挑战成功。该退出请求会被取消且挑战者获得一笔奖励。
退出申请在父链受理有优先顺序。优先度由申请退出时间距离上一笔交易时长决定,时长越长优先度越高。用以防止作弊者采取作弊行为后迅速退出Plasma链。

系统角色
用户(client)
参与Plasma系统的普通用户,期望通过Plasma子链完成高效低成本转账
子链矿工(operator)
Plasma系统的维护者,负责将子链区块信息打包到主链
主链智能合约
负责保存子链少量数据,验证子链操作的正确性合理性。
局限
难以拥有完整的EVM
存在大量复杂的技术性问题:如智能合约的所有权性质,导致Plasma短期内难以完整实现EVM所具备的功能。如果子链上的"状态"出现混乱,缺乏EVM能力难以复原。
目前大多数研究聚焦于Plasma链实现UTXO模型
大规模退出风险
大规模退出会导致以太坊需要在短时间内处理大量交易,导致验证时间拉长及gas费剧增问题并带来用户资金风险。
目前尚无完美的解决方案。
Rollup
工作原理
Rollup方案的核心思想是将打包后的交易数据区块发布在链上,从而降低交易有效性验证的难度。
操作者收集不同参与者提交的一批链下交易,在链上执行Rollup智能合约提供的脚本,将打包后的交易数据区块作为参数提交给合约。实现链上一个交易完成链下一批交易。
Rollup有多种方案,具体实现不同,均需要解决三个共性的问题:
- 如何实现交易压缩
- 如何将二层的状态转换同步到一层
- 如何保证二层运营者真实提交了二层的全部状态转换
如何实现交易压缩
Rollup压缩主要是对交易消耗gas数的压缩,兼顾交易字节数压缩。
以太坊上的区块限制以gas为限制,非字节数限制
小的字节数不等同于小的gas消耗
Rollup方案通过压缩减少交易执行的计算量降低gas消耗
Rollup方案针对交易字节数的压缩的方式主要包括:
- 效率更高的编码方式
- 缩减交易占用字节数
- 减少需要上传的数据
交易发生在以太坊一层与Rollup方案对比:

将二层的状态转换同步到一层
批次交易发生前后的状态转移示意如下图所示:
二层交易相关账户状态改变,引起叶子节点信息变动,导致根哈希值的变动
二层运营者在本地维护二层账户状态树,记录并上传批次交易发生前后的根哈希值

防止二层运营者欺诈
Optimistic Rollup
Optimistic Rollup方案承袭闪电网络及Plasma采用的欺诈证明方式,主要步骤:
- 运营者提交信息时不做关于状态转换合法性的校验,为交易的提交预留挑战期。
- 挑战期内,无人对其合法性做出挑战则交易被确认。
- 挑战期内,有人对其合法性做出挑战,则挑战者需提供欺诈证明。
Optimistic Rollup相对闪电网络及Plasma方案在欺诈证明方式的改进:
- 欺诈证明方式的主要缺点是用户体验差和资金效率低
- 闪电网络及Plasma方案无法保证链上数据有效性:
- 必须依靠用户活性(一定的在线频率)来防止欺诈
- 用户资金无法及时取出,必须等待挑战期结束
- Optimistic Rollup方案保证数据上链,欺诈证明可由第三方提交,有效降低对用户活性的要求
- Optimistic Rollup方案对资金效率进行如下提升:
- 对于非欺诈的交易,交易的最终性可提前预期
- 使用者可自行搭建验证节点快速验证交易合法性而不必等到挑战期结束
- 交易需等待挑战期结束后方能被主链确认,但最终性可以被快速确认的特性,流动性提供商可以提前为用户释放资金
- 此提升需依赖应用解决方案
ZK Rollup
ZK Rollup采用二层运营者提供有效性证明方式防止欺诈,特点包括:
二层运营者提供有效性证明:即二层运营者需直接证明其提交的状态转换正确有效
提交即正确,无挑战期设置,无欺诈风险,提取资金无冻结期
相比于欺诈证明,此方式技术挑战性更大。目前仅针对一些特定的操作生成证明,无法通用
随着密码学技术理论和实践的突破(PLONK、多项式承诺等),向通用解决方案方向演进
方案对比
Optimistic Rollup | ZK Rollup |
---|---|
* 解决方案为欺诈证明(fraud proofs) * 追踪所有历史状态根以及每个批次交易提交的哈希值 * 任何人发现某个batch的后状态根不正确,均可以向区块链发布一个证明,证明该批次交易计算错误。合约会对证明进行验证,并且对该batch及其之后的批次交易进行回滚 | * 解决方案为有效性证明(validity Proofs) * 每个批次交易都包含ZK-SNARK的密码学证明(例如使用PLONK协议) * 可有效证明后状态根是正确执行批次交易的结果 * 计算量大但证明能在链上得到极速验证 |
Layer2技术演进

Rollup方案演进之路
侧链 | 闪电网络 | Plasma | Rollup |
---|---|---|---|
基于信任 | 基于信任 | 不基于信任 | 不基于信任 |
无需向主链同步状态 | 需向主链同步状态 | 需向主链同步状态 | 需向主链同步状态 |
交易发送给运营商 | 交易发送给对手方 | 交易发送给运营商 | 交易发送给运营商 |
运营商存储交易 | 用户自行存储交易 | 运营商存储交易,用户存储部分数据 | 运营商存储交易 |
交易存储在侧链 | 交易存储在链下 | 交易存储在链下 | 交易存储在链上和链下 |