区块链扩容方案之“分片技术”

区块链扩容方案之“分片技术”

根据全球审计四巨头之一的德勤(Deloitte)搜集的数据显示,2016年GitHub上创建了超过26000个区块链相关的新项目,而2017年仅半年时间,已经创建了近25000个GitHub项目。区块链项目发展势头锐不可当,然而底层技术研发却迟迟未有实质性进展。

在兼顾安全、去中心化和扩容性三方面特性,达成最优解决方案,扩容问题成为困扰区着块链由稚嫩期过渡到成长期一大技术难点,对此,业界提出诸多解决策略,包括闪电网路、分片技术(shapping)、Plasma、Casper、雷电网络等。

事实上,当今的比特币网络平均每秒可以处理7-10笔交易,公共以太坊网络能处理20笔交易。这一数字远低于像Visa这样的集中支付处理器,后者平均每秒能处理约8000笔交易。为了运行一个能够处理实际吞吐量需求的DApp,区块链就必须具有可扩展性。而分片网络执行“水平”扩容方案,网络的吞吐量随着挖矿网络的扩展而增加,能够适应如今类似以太坊这样的高吞吐量平台。

分而治之成为关键

“分而治之”是分片技术的支撑性设计理念,目前区块链中的的容量机制,以比特币为例,每10分钟产生一个区块,并且每个区块大小限定为1MB,容纳的交易数平均大概3000笔,显然无法应对日益扩增的交易频次。

在交易过程中,如果每笔交易都需要网络中的每个节点进行确定,必然造成交易阻塞。分片即将网络、交易、状态进行分片,对节点由随机序列分配成多个碎片,当网络当中接收到待确定的交易,系统随机分配给各个碎片,这些碎片呈现独立状态,可以完成区块链信息确立。

分而治之的理念相当于处理交易数据时,同时开通多个通道同步进行,而仅仅是对节点进行简单随机分配,还无法真正实现水平扩容,在运作过程中存在攻击隐患,所以,需再进一步分片处理,包括网络分片、交易分片以及交易状态分片。

网络分片:实现区块分散

实际上,在区块链网络(比特币、以太坊)当中,区块与区块之间都会建立强连接,也即是,在确认每一笔交易的同时,彼此区块之间也会建立通信,这就造成了区块当中的交易无法在短时间内得到确认,网状般的连接架构,在保证安全性能以及去中心化过程中,也降低了交易释放效率,从而导致网络堵塞。

网络分片,使得区块以随机性形成各个碎片,由于区块链中用于记录数据的默克尔树,支持公共随机性区块当中提取,而且形成后的碎片之间不必形成强连接,在不必通信条件之下,由于随机成分居多,最大限度保障网络节点的忠诚度。

从理论上而言,网络分片用随机分配机制来平衡过度中心化与交易效率,但也存在恶意节点掌控大部分算力节点,由于网络节点被分割成多个碎片,包容的节点越少,恶意节点占的权重就越高,网络中一部分交易掌握在恶意节点手中,存在一定安全隐患,此时,区块链安全性取决于节点的数量以及网络分片的数量大小。

交易分片:拆解交易

交易属于对于UTXO(比特币)机制与账户机制(以太坊)影响有很大不同。关于两者的区别可以查看之前“以太坊账户机制VS比特币UTXO”一文,两者在关于交易之间主体设计架构上有很大不同。

对于使用UTXO的区块链设计模型,交易分片涉及到问题较为复杂,在发生交易过程中,UTXO中会有输入、输出两个不同地址,若是对两个地址进行分离,货币转移无法统一,若想实现正常转移而避免“双花问题”,碎片之间必须建立通信,这样一来,分片没有意义了,违背最初分片为了提升交易效率的愿景。

然而对于如以太坊一样的账户机制,一个用户对应一个地址,不需要考虑一笔费用别多次消费,对交易拆分,每一笔交易将会有一个发送者的地址,然后系统可以根据发送者的地址分配一个碎片,这确保了两笔双花交易将在相同的碎片中得到验证,因此系统可以很容易地检测到双花交易,而不需要进行任何跨碎片的通信。

状态分片:缩减存储负担

在数字资产转移过程中,每笔交易存在多个状态,如果让每个碎片节点保留一笔交易的不同状态,对于处理同一笔交易的不同节点必须处于相同碎片当中,这势必会使得节点之间的通信更加紧密。

另外,由于网络分片的缘故,各个节点以随机性分配独立单元,一个节点可能负责存储多个交易状态,保存部分交易的部分节点一旦遭受攻击,交易信息部分缺失,将导致与该节点有关的交易无法进行。

针对状态分片提出解决方案,为了避免过分集中化,需重新调整网络节点,也即是,在某一段时间后节点将重新进行分配,避免遭受恶意攻击,但调整需要分时段进行,不能在同一时间将所有节点调整,保障正在交易的节点正常运作。

而这也是状态分片的难点,由于每个片区里的数据是分开更新的,在设计应用逻辑时必须确保在平衡效率的前提下,对信息进行成功更新,同时也需要预留出一定的空间来应对一个达成最终一致性过程中可能出现的不一致性。

分片技术确实给予区块链扩容问题提供了解决思路,但目前仍处于概念模型,距离真正能够场景落地还存在一定距离,分片技术对于安全性、可拓展性、稳定性要求极高,面临带宽的限制,需要充分考虑到延迟带来的不一致性导致的性能和安全性问题。

本文由 链码笔记 作者:Vcode 发表,其版权均为 链码笔记 所有,文章内容系作者个人观点,不代表 链码笔记 对观点赞同或支持。如需转载,请注明文章来源。