热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

万向年度回顾|技术篇:突破公链不可能三角的努力

如何突破不可能三角?撰文:崔晨,万向区块链首席经济学家办公室审核:
如何突破不可能三角?

撰文:崔晨,万向区块链首席经济学家办公室

审核:邹传伟,万向区块链首席经济学家

2022 年接近尾声,驻足回看行业这一年的跌宕起伏,无论是技术的突破,应用的创新,还是生态的兴衰,皆成为了行业发展的历史注脚。如往年一样,万向区块链于年末推出重磅年度回顾系列文章:《公链技术篇》、《应用篇》和《监管篇》,以期记录当前行业发展的缩影。 

公链的不可能三角问题一直是制约公链技术发展的阻碍,进而影响到链上应用的性能。一直以来,公链的发展目标都集中在如何突破不可能三角的问题上,或者在不可能三角中找到最佳平衡。公链的创新体现在以太坊更新的路线图、EVM 兼容公链和模块化公链、Solana 和 Aptos 为代表的高性能公链等。下文将针对不可能三角和交易流程角度,解读不同不可能三角解决方案的区别。

对不可能三角的理解

不可能三角的概念

公链最基本的功能是在链上记录信息且维护信息安全,即在开放的网络中(无信任)防止信息被篡改(回滚),依赖的是密码学、共识机制、分布式网络等底层组件。密码学包括公私钥密码学和哈希函数等,保证验证签名的正确性和链式结构规则。

以太坊创始人 Vitalik Buterin 在 2017 年的一篇博客文章中提出:在可扩展性、安全性和去中心化这 3 个特征中,区块链系统最多同时具备两个。在讨论不可能三角对公链影响以及公链在不可能三角上的突破时,我们需要理解这三者的定义和对系统的影响。

可扩展性衡量公链支持交易速度和规模的能力,体现在交易从提出到被确认的时间。交易处理速度慢的公链难以实现很多应用功能,例如即时支付,这会限制应用的范围并影响用户体验。

安全性衡量系统抵御攻击的能力,代表系统在面对故障时的可靠性,主要体现在容错性和修改共识的难度。系统容错性低会让系统易于攻击,修改共识会改变已确认的交易,相当于篡改过去的交易记录。

去中心化衡量公链节点的分散程度,由于公链不是通过可信第三方建立的,只能由分布式的点对点网络维持网络系统运营,在此基础上,公链节点的分散性提供了系统的信任基础。结合密码学和共识机制,公链才能发挥正常的功能。去中心化同时代表了用户参与交易验证的权力,也体现出用户在公链系统中的话语权。

去中心化体现为两个层次:第一以节点数量衡量,节点的准入门槛越低,数量越多,分散程度越高;第二以实际控制者衡量,如果公链中存在例如矿池类的角色,实际上一个角色控制多个节点,会给系统带来中心化的交易审查等问题。

总的来说,公链不可能三角所衡量的指标和具体含义如下表所示。

表 1:不可能三角衡量的指标和具体含义

从交易流程角度理解不可能三角及优化

区块链上的交易流程可以简化成以下四步:

①使用者签署交易并广播给节点,添加到未确认交易池;

②共识节点验证和执行交易,并将这些交易打包成区块;

③区块广播给网络中的其他节点;

④其他节点验证区块,并储存添加到区块链后。

这几步骤从不同角度影响公链的三种指标。

1、可扩展性

可扩展性会受到第②③④步的影响。在第②步中,交易的验证、执行和共识速度会影响到可扩展性。区块链的账户模型、虚拟机和共识机制等因素都会影响完成第②步的速度。以更改共识为例,如果以减少共识节点的方式缩短共识时间,就会影响系统的去中心化程度。

在第③步中,如果节点数量多,那么在各节点中同步的速度也会变慢。以扩大区块容量的思路提高可扩展性时,很难在原计划的时间内将区块广播给所有节点。在没有网络完全同步的情况下,在不同的区块后共识处理交易,会导致分叉出现,进而影响网络的安全性。而如果通过减少节点数量加快同步速度的话,会影响系统的去中心化。

第④步意味着网络交易的最终确认,如果在收到区块后节点能够快速验证,那么可以提高可扩展性,但面临损害安全性和中心化的问题是类似的。

2、安全性

在第②③④步中被攻击的难度,也就是被恶意节点控制的难度会影响系统的安全性。尤其是在第②步中体现为共识机制的性能,如果共识机制容错率低,或者容易被恶意者操纵,就会降低系统安全,或者导致节点趋于中心化。

3、去中心化

分布式的节点是公链底层基础,越多节点加入代表越多节点认同公链,并且避免单点故障带来的风险,也能提高恶意者的攻击成本,因为在相同容错率的情况下恶意者需要控制节点数量变多了。扩大区中心化程度要求节点的进入成本更低,但像上文提到的,在相同安全条件下提高节点数量会降低系统的可扩展性。

从节点的实际控制者方面理解去中心化时,重点关注的是「审查交易」的问题。节点负责打包交易时,如果按照自己喜好挑选交易和排序,会导致一些交易在提出之后很难执行以及得到链上确认。也就是影响第①步提出的交易难以在第②步中被挑选验证。

总的来说,公链在交易流程的几步中都可以做出改善和优化,但碍于不可能三角的影响,在某一方面进行优化时,总会伴随着至少另一方面的负面影响。公链需要在不可能三角中找到平衡点,以满足更多应用场景。下文就是在各环节不同公链的优化尝试,包括以太坊的最新路线、以太坊同质公链和高性能公链。

以太坊:应用新技术和新框架优化不可能三角

在以太坊最近公布的路线图中,可以看出一些在不可能三角以及用户体验方面的改善。

图 1:以太坊最新路线图

Merge:共识机制由 PoW 转化为 PoS

共识机制主要影响区块的产生和验证同步过程,在以太坊在转化为 PoS 后,采用的是 LMD GHOST + Casper FFG 公式机制,实现了两个目标:在每个 slot(12 秒)内产生一个区块,并进行相应的见证投票,在两个 epoch(一个 epoch 包括 32 个 slot)后被确认最终性,回滚区块需要销毁至少三分一的链上质押的 ETH 数量。

在以太坊的 Merge 阶段规划中,以太坊还计划将最终行确认时间缩短到单个 slot,交易确认不再需要几分钟的等待时间,这会达到更高效率,提升用户体验。但达成单个 slot 确认需要改善共识算法,可能会减少降低攻击链(改变共识)的成本,以及减少验证的节点数,影响公链的安全性和去中心化。

Surge:Rollup 和 Danksharding 配合提高交易处理速度

以太坊通过 Layer 2 手段进行扩容,特指 Rollup 的扩容方式,二层网络将主网上的内容放在链外执行,再将可验证的结果传回到链上。目前以太坊中的 Rollup 仍以 Optimistic 和 ZK 两个路线为主。

在 Optimistic Rollup 中,由于通用性的设定,在用户数量和整体锁定价值占据了先发优势。Optimistic 在排序器方面有很多争议,因为目前 Arbitrum 和 Optimism 的排序器都是以中心化方式的方式出块,很可能造成交易审查问题。ZK Rollup 重点专注两个问题,第一是 zkEVM 的构建,在兼容 EVM 和完全独立构建虚拟机之间做选择,也是在实用性和性能做选择。第二是加速零知识证明的速度,通过硬件设备生成零知识证明也是一种选择。为了进一步降低链上的数据可用成本,这两类 Rollup 都出现了链下数据存储的模式,适用于需要高频交互的场景,不过提高了对节点的信任成本。

Rollup 看似解决了公链的不可能三角问题,但 Rollup 存在两个固有问题。第一,Rollup 的信息处理能力存在上限,尤其是 Rollup 依赖底层网络实现,底层网络的承载能力决定了 Rollup 中的运行能力;第二,链上的不同 Rollup 会带来互操作问题。

为了让 Rollup 发挥更大功能,以太坊的 EIP 4844(proto-danksharding)提出将区块容量扩大出 blob 数据块,以承接 Rollup 传回主链上的数据。扩大区块容量虽然提高了扩展性,但大数据的共识和同步同样会带来问题。因此在 Surge 阶段,还计划上线 DAS(数据可用性抽样,Data Availability Sampling)。

DAS 可以让节点无需下载和验证全部数据,而是将数据分成几块,节点只需要随机下载其中的一部分来验证数据是否丢失即可。DAS 的检测准确度将通过纠删码提高,纠删码能够扩充额外数据用以恢复丢失的原始数据,是一种数据冗余机制,纠删码扩充数据的有效性由密码学机制 KZG 承诺保证。

假设共有 4 个数据块等待验证,节点有 25% 的概率发现原始数据块丢失了 1 个。使用纠删码将数据扩充一倍至 8 个数据块后,超过 50% 的数据丢失则无法恢复原始数据,也就是节点发现数据丢失的概率超过了 50%。随着验证节点数量的增加,发现数据丢失的概率也会增加。假设共有 n 个节点进行随机抽样,数据丢失 50% 时,只有 1/2n的可能性恰好所有节点都抽取了未丢失的数据块。因此在大量节点存在的情况下,DAS 的验证方式足以保证数据安全。

所以综合来说,以增加区块容量的方式提高整体区块的可扩展性,就会同步效率降低影响系统安全性。而为了提高同步的速度,减少节点存储量,保证足够的去中心化,只能做出机制上密码学的改善,但整体上还是影响了网络的安全性。

节点的角色提议者和构建者分离

以太坊使用 PBS(提议者和构建者分离,Proposer/Builder Separation)的方式,将节点的工作任务分成两个角色,分别是提议者(Proposer)和构建者(Builder)。构建者负责构建区块主体和提交出价,提议者只需要执行出价最高的区块,并且不知道区块内的交易内容,以减少审查交易。

Danksharding 的实施会对构建者有更高带宽资源的要求,构建者会因为专业化的要求成为中心化组织,而提议者是一个广泛的去中心化群体,用以平衡中心化风险,只要有一个诚实的构建者存在,以太坊区块就能正常出块。为了防止构建者审查交易,提议者会传递 crList 代表提议者要求打包的交易列表,构建者需要使用 crList 中的交易填满区块。这是一种削弱 MEV 的机制,同时在大区块模式下,让节点分成两种角色,保证足够的去中心化。

Verkle 树、历史过期和多维度费用市场

庞大的历史数据会影响以太坊的去中心化,尤其是日益增长的状态数据会导致各种效率低下的问题。为了不影响去中心化,同时实现上文提到的可扩展计划,需要一些机制保证能够达到同样的安全标准,以及实现系统更有效率的运行。

Verkle 树是一种更简单的数据存储模式,相对于现有的 Merkle 树来说所需要的证明空间更少,这是由密码学技术做出的改善,配合历史数据过期机制减少节点的存储压力,继续降低节点门槛。

历史数据过期机制可以解决数据膨胀的问题,客户端无需储存超过一定时间后的数据。Proto-Danksharding 也可以实现在一段时间后自动删除 blob 数据的独立逻辑,因此大区块不再成为扩容的阻碍。这不意味着区块数据永久丢失,在数据删除之前,已经留给足够多的时间给需要数据的用户备份。网络中也存在保存全部历史数据的节点,这些角色包括专门的协议,以太坊 Portal Network、区块浏览器和数据服务商、个人爱好者和数据分析的学者会保存全部节点数据。

在多维度费用市场中,每种资源都规定目标值和容量上限,正如 EIP 1559 实施对 gas 的要求一样,资源的使用程度关系到资源的定价。以太坊将要从 EVM 执行、交易 calldata、见证数据和存储容量这几方面开始进行更细分的定价和收费,包括 Proto-Danksharding 中即将上线的 blob 区块。最终目标是实现每个单独操作码的定价,将提高费用统计时的用户体验。

综上所述,以太坊迫切需求性能提升,提出了 Rollup 和 Danksharding 的思路提高性能。同时又为了让更多 Rollup 数据能廉价、不臃肿地存储,提出了数据可用性的解决方案,并弱化它带来的安全性降低的问题。以太坊仍然要修补自己的技术债,通过 PBS、历史和状态过期等规划,继续保护节点的去中心化。以太坊借助新技术和新框架的引入,在保证去中心化和安全性的前提下,实现最大化的可扩展性。

以太坊同质公链:在不同层解决不同的不可能三角

EVM 兼容链

在过去的几年中,以太坊牺牲了可扩展性来换取安全和去中心化,表现为以太坊是全世界拥有节点数量最多的公链项目,并且在运行的这几年过程中没有经历过大规模的网络中断事件,网络不会因为个别节点的故障和退出而中断,证明了网络拥有足够的冗余备份。与此同时,节点需要很长时间的共识同步时间,交易的处理速度较慢并引起了交易手续费的上升。

简单区分,以太坊主网的结构包括执行层和共识层,执行层指的是节点在以太坊中执行用户指令的过程,包括转账和 EVM。在大量节点存在的情况下,共识及同步势必会受到影响。因此最简单的提升以太坊性能的方式就是修改其共识层,减少共识同步的速度以实现更快的效率。

这一点从以太坊同质公链(即各类 EVM 兼容链)的竞争中就能看出这一点。尤其是在执行环境相同时,应用的迁移更为容易。因此可以看到采用以太坊架构的同质化公链采取了这样的方式,它们修改了以太坊的共识方式,减少了节点数量并缩短共识时间,但保留了执行层的功能。虽然可能带来中心化的问题,但由于迅速承接以太坊上应用的外溢需求,替代以太坊成为应用类项目的发行地。比如 BSC、Polygon 和 Avalanche,都是 EVM 兼容链的代表公链,它们的共同点都是大幅减少了网络中参与共识的节点数。

模块化公链

以太坊的竞争公链中出现了「模块化公链」,将以太坊的功能分层,以模块化的方式运营。这其实也是一个代表性思路,不可能三角虽然存在,但是可以在其中找到了一个折中点。

不同侧重的应用会选择不同侧重的公链,因为它们对性能、安全和去中心化的需求是不同的。例如隐私公链不允许交易审查存在,它愿意付出额外的成本去保护它的去中心化。承载金融应用的公链对于安全性重视更高,而游戏类公链会要求极高的性能体验,会放低对去中心化的要求。

因此模块化公链将需求的每一层抽象出来,将区块链分为:共识层、执行层、结算层、数据层,不同层都可以有多种解决方案,而又根据链的不同需求,直接整合这些解决方案,这样实现最佳的效果。同时各层方案是模块化的供公链切换,以此平衡应用需求,变相突破了不可能三角的限制。

以太坊非同质化公链:重新思考不可能三角中的侧重方向

由于以太坊的性能瓶颈问题,新的非同质化公链几乎所有都选择了性能优先的规划,配合 PoS 类共识,又引入新技术强化它的性能优势或者弥补安全性的缺陷。

Solana 首先提高了区块的容量,区块承载的数据量扩大了十倍。其次,为了减少每次同步的节点数,Solana 会提前公布负责的节点名单,每次交易只需要传输给负责人(Leader),其他验证者只需验证自己负责的部分,也不需要验证整个区块。

除此之外,Solana 在执行交易前会预先判断,如果满足条件会采用并行计算来提高交易的处理速度,如果是必须串行处理的,会转为比以太坊效率更低的运行方式。可以看出,Solana 为了追求可扩展性,牺牲了安全和去中心化,当领导人节点故障,或者在判断是否要并行处理失误时,就会造成网络中断的问题。

Aptos 号称是新一代高性能公链的代表,它以不同方法延续了以太坊公链上的各种功能。Aptos 采用 AptosBFT 共识机制,这是一种基于 BFT 的共识机制,只需两次网络往返即可验证和提交区块,无需多轮投票,并且可以快速实现最终确认性。Aptos 区块只包括交易记录的摘要,不会包含所有交易记录信息,因此每个区块中包含的交易数量会更多。它将交易分组为批次,并在达成共识后合并进区块,在后续的执行和存储中都是批量处理的,这个过程中可以提高效率。

Aptos 同样采用了并行处理的方式,采用了 Block-STM 引擎,默认对所有事务采用并行处理的方式,发生冲突时不成功的交易会重新执行,这需要依靠调度程序,防止同一事务被同时执行,以及重新执行事务后获得更多安全确认。除此之外,快速的状态同步也是 Aptos 考虑的问题。

状态同步指的是在交易完成进行状态转化后,将状态后的结果同步给其他节点的过程。状态同步的低效会导致大多数节点无法同步到最新的状态信息,因此影响用户体验,并且新节点难以加入共识过程,影响网络的去中心化。Aptos 提供了多种状态同步方式,包括使用 RocksDB 或者节点通过验证者产生的状态变化的默克尔证明,跳过交易执行阶段来同步状态。这种方式减少了节点同步时所需要的大量计算资源,但需要建立在使用大量网络资源的基础之上,Aptos 建议共识节点在云服务器上运行,个人电脑很难达到其要求。

Aptos 认为以太坊的虚拟机也是它的瓶颈,以太坊没有办法再大规模更新它的语言,但是 Aptos 没有这样的技术包袱。Aptos 和 SUI 都采用了 Move 语言,Move 的创新在于将资产作为资源处理。在创建、使用和销毁资源时有一定限制,因此不会发生以太坊中常见的重入攻击问题,能够让更安全地构建智能合约,并且让虚拟机并行处理多个事务,根据存储资源收取租金也成为可能。

总结来说,新公链认为可扩展性优先于安全性和去中心化,这和以太坊是不同的。因此,它们重新选择了不可能三角中的侧重方向,这样的改动对于用户的感受是非常明显的,Solana 上发生的宕机问题也是不可避免的。

思考与总结

共识机制和分布式的节点网络从两方面保证了公链的可靠运转:

第一,保证系统的容错性:共识机制有一定的容错性,也就是故障节点占比在一定比例之下时,系统依然可以验证信息。自由加入的分布式节点能够补充新的正常节点。

第二,提高系统的攻击成本:共识机制代表节点对已有区块状态达成一致意见的方式,掌握共识机制的控制权的一方代表作恶者拥有修改共识(修改账簿记录)和审查交易(决定交易排序和是否打包上链)的权力。共识机制和分布式节点能够从规则上增加攻击的难度和成本。

在此基础上,区块链的不可能三角问题可以这样理解:

以太坊本身已经基本成型,较难另起炉灶做出改变,因此以太坊在尽最大努力引入新的技术(密码学技术、单槽最终性算法)和新的框架(Rollup、数据可用性)来优化它的性能瓶颈,希望凭借新技术和新框架,使其在去中心化和安全性变大不大的基础上,大幅提升性能,进而优化不可能三角。

以太坊同质化公链, EVM 公链和模块化公链则灵活得多。对以太坊层级的拆分,可以让它们寻找自己的「社会分工」来匹配不同的应用,例如承载金融、游戏、隐私等等。根据应用的需求,反推出不同层技术框架的需求,这帮助它们在不可能三角中找到了新的平衡点。

以太坊的非同质化公链,因为没有技术包袱,则可以彻底另起炉灶,使用全新的架构和技术手段。与以太坊在足够去中心化和安全的前提下追寻性能不同(以太坊同质化公链介于两者之间,但是也更多地倾向于性能),它们不约而同地都选择了性能优先的路径。这样的好处是用户非常直观地感受到了它们的进步(TPS 方面),但是其中的安全和去中心化问题也是一种隐患。


推荐阅读
author-avatar
as1dzx
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有