区块链分片权威指南

嗨,我是分片式区块链近协议的开发人员之一,在本文中,我们想谈谈什么是分片式分片,如何实现以及分片式分片设计中存在哪些问题。


众所周知,在撰写本文时,以太坊是最常用的通用区块链,每秒只能在主链上处理少于20笔交易。 这种限制,再加上网络的普及,导致高油价(在网络上执行交易的成本)和较长的确认时间。 根据ETH加油站的说法,尽管在撰写本文时大约每10–20秒就会产生一个新区块,但将交易添加到区块链的平均平均时间为1.2分钟。 低吞吐量,高价格和高延迟都使以太坊不适合运行需要随着采用而扩展的服务。


以太坊低吞吐量的主要原因是什么? 原因是网络中的每个节点都需要处理每个事务。 开发人员提出了许多解决方案来解决协议级别的吞吐量问题。 这些解决方案大部分可以分为将所有计算委托给一小组功能强大的节点的解决方案,而那些在网络中具有每个节点的解决方案仅占总工作量的一部分。 前一种方法的极端情况是Thunder ,它有一个单节点处理所有交易并声称达到1200 tx /秒,比以太坊提高了100倍(但是,我不认可Thunder或证明其声明的有效性) AlgorandSpaceMeshSolana都属于前一类,在共识和区块链本身的结构上进行了各种改进,以运行更多的交易,但仍然受单个(尽管功能非常强大)机器可以处理的限制。


将工作分配到所有参与节点之间的后一种方法称为分片。 这就是以太坊基金会目前计划扩展以太坊的方式。 在撰写本文时,完整规范尚未发布。 这里是对以太坊分片链信标链的详细概述的链接


在这篇文章中,我总结了区块链分片的核心思想,Near和大多数其他分片协议都基于此。 随后的文章将概述分片中的更多高级主题。


最简单的分片,又名豆茎


让我们从最简单的分片方法开始,在整个本文中,我们将其称为Beanstalk。 这也是Vitalik在演示文稿中所谓的“按千个山寨币缩放”。


在这种方法中,我们将运行多个,而不是运行一个区块链,并将每个这样的区块链称为“碎片”。 每个分片都有自己的一组验证器。 在此处及下文中,我们使用通用术语“验证器”来指代参与者,这些参与者通过挖掘(例如在工作量证明中)或通过基于投票的机制来验证交易并产生区块。 现在,让我们假设这些分片永远不会相互通信。


Beanstalk设计虽然简单,但足以概述分片中的一些主要挑战。


验证程序分区和信标链


第一个挑战是,每个分片都有自己的验证器,现在每个分片的安全性比整个链低10倍。 因此,如果具有X个验证程序的非分片链决定将硬分叉成一个分片链,并将X个验证程序分成10个分片,则每个分片现在仅具有X / 10个验证程序,而破坏一个分片只需破坏5.1%(51% / 10)验证者总数。


这使我们得出第二点:谁为每个分片选择验证器? 仅当所有5.1%的验证者都在同一分片中时,控制5.1%的验证者才具有破坏性。 如果验证者无法选择他们要验证的分片,则控制5.1%验证者的参与者极不可能将其所有验证者放在同一分片中,从而大大降低了他们破坏系统的能力。


图片


如今,几乎所有分片设计都依靠某种随机性来源来将验证器分配给分片。 区块链本身的随机性本身就是一个非常具有挑战性的话题,以后应该再发表一篇博客文章,但是现在让我们假设我们可以使用一些随机性来源。


随机性和验证者分配都需要不特定于任何特定碎片的计算。 对于该计算,几乎所有现有设计都具有单独的区块链,其任务是执行维护整个网络所需的操作。 除了生成随机数并为分片分配验证器外,这些操作通常还包括从分片接收更新并对其进行快照,在权益证明系统中处理赌注和大幅削减,以及在支持该功能时重新平衡分片。 这样的链在以太坊和附近称为信标链,在PolkaDot中称为中继链,在Cosmos中称为Cosmos Hub。


在整个这篇文章中,我们将这样的链称为信标链 。 信标链的存在将我们带入下一个有趣的话题,即二次分片。


二次分片


分片通常被宣传为一种解决方案,可以随着参与网络运营的节点数量的增加而无限扩展。 从理论上讲,可以设计这样的分片解决方案,但是任何具有信标链概念的解决方案都不会具有无限的可扩展性。 要了解原因,请注意,信标链必须进行一些簿记计算,例如将验证程序分配给分片或对分片链块进行快照,这与系统中的分片数量成比例。 由于信标链本身就是单个区块链,计算受到操作它的节点的计算能力的限制,因此分片的数量自然受到限制。


但是,分片网络的结构确实会对其节点的任何改进产生乘法效果。 考虑一种情况,其中对网络中节点的效率进行了任意改进,这将使它们能够更快地进行事务处理。


如果操作网络的节点(包括信标链中的节点)变得快四倍,则每个分片将能够处理四倍的事务,并且信标链将能够维护四倍的分片。 整个系统的吞吐量将增加4 x 4 = 16倍-因此称为二次分片。


很难准确衡量今天有多少个分片可用,但是在任何可预见的将来,区块链用户的吞吐量需求不太可能会超过二次分片的限制。 安全地操作如此大量的分片所必需的节点数量比当今操作所有区块链的节点数量高出几个数量级。


但是,如果我们要构建将来的证明协议,那么今天就有必要开始研究此问题的解决方案。 到目前为止,最成熟的建议是指数式分片,其中分片本身形成一棵树,每个父分片都编排一系列子分片,而其本身可以是其他分片的子分片。


以太坊基金会(Ethereum Foundation)的弗拉德·扎姆菲(Vlad Zamfir)正在研究一种不涉及信标链的分片设计。 我与他合作开发了其中一个原型,其详细概述在此处


状态分片


到现在为止,我们还没有很好地定义将网络划分为碎片时究竟是什么和没有分离的东西。 具体来说,区块链中的节点执行三个重要任务:它们不仅执行1)处理交易,还执行2)将经过验证的交易和已完成的块中继到其他节点,以及3)存储整个网络分类帐的状态和历史记录。 这三个任务中的每一个都对运行网络的节点提出了越来越高的要求:


  1. 随着交易数量的增加,处理交易的必要性需要更多的计算能力。
  2. 中继事务和块的必要性需要更多的网络带宽,同时中继的事务数量也随之增加。
  3. 随着状态的增长,存储数据的必要性需要更多的存储空间。 重要的是,与处理能力和网络不同,即使事务速率(每秒处理的事务数)保持恒定,存储需求也会增加。

在上面的列表中,似乎存储需求是最紧迫的,因为即使每秒事务数没有变化,它也是随时间增加的唯一需求,但实际上,这是当今最紧迫的需求是计算能力。 截至撰写本文时,以太坊的整个状态为100GB,可由大多数节点轻松管理。 但是以太坊可以处理的交易数量约为20个,比许多实际用例所需数量少几个数量级。


Zilliqa是最知名的项目,它分片处理而不是存储。 分片是一个比较容易的问题,因为每个节点都具有整个状态,这意味着合约可以自由调用其他合约并从区块链读取任何数据。 需要进行一些仔细的工程设计,以确保来自多个分片的更新(更新状态的相同部分)不会冲突。 在这些方面,Zilliqa采取了非常简单的方法,对此的批评可以在本文中找到。


虽然提出了不进行处理分片的存储分片的建议,但我不知道有任何项目正在对其进行处理。 因此,在实践中,存储分片或状态分片几乎总是意味着处理分片和网络分片。


实际上,在状态分片下,每个分片中的节点都在构建自己的区块链,其中包含的事务仅影响分配给该分片的全局状态的本地部分。 因此,分片中的验证器仅需要存储其全局状态的局部部分,并且仅执行(因此仅中继)影响其状态部分的事务。 该分区线性地减少了对所有计算能力,存储和网络带宽的需求,但是引入了新问题,例如数据可用性和跨分片事务,我们将在下面介绍这两个问题。


跨分片交易


Beanstalk作为模型并不是一种非常有用的分片方法,因为如果单个分片无法彼此通信,那么它们就不会比多个独立的区块链更好。 即使到了今天,当分片不可用时,各种区块链之间的互操作性仍然有巨大的需求。


现在让我们只考虑简单的支付交易,其中每个参与者在一个分片上都拥有一个帐户。 如果一个人希望在同一分片中将钱从一个帐户转移到另一个帐户,则交易可以完全由该分片中的验证者处理。 但是,如果驻留在1号分片上的爱丽丝想寄钱给驻留在2号分片上的Bob,则既不能使用1号分片上的验证程序(他们将无法记入Bob的帐户),也不能使用2号分片上的验证程序(他们将无法借记爱丽丝的帐户)可以处理整个交易。


交叉分摊交易有两种方法:


  1. 同步 :每当需要执行跨分片事务时,多个分片中包含与事务相关的状态转换的块都会同时产生,并且多个分片的验证程序会协作执行这些事务。 我所知道的最详细的建议是合并块, 在此进行描述。
  2. 异步 :影响多个分片的跨分片事务在这些分片中异步执行,一旦有足够的证据表明“借方”分片已执行了该部分,则“信用”分片将执行其一半。 由于其简单性和协调性,这种方法趋于流行。 今天在波斯菊,以太坊宁静,附近,卡德纳等地提出了该系统。 这种方法的问题在于,如果块是独立生成的,则多个块中的一个将被孤立的可能性不为零,从而使事务仅部分应用。 考虑下图,该图描述了两个分片都遇到了一个分叉,以及相应地记录在块A和X中的交叉分片事务。 如果链AB和V'-X'-Y'-Z'最终在相应的分片中是规范的,则交易已完全完成。 如果A'-B'-C'-D'和VX变为规范,则交易被完全放弃,这是可以接受的。 但是,例如,如果AB和VX成为规范,则事务的一部分将最终确定而一部分被放弃,从而导致原子性失败。 在第二部分中,当涉及对分片协议建议的fork-choice规则和共识算法的更改时,我们将在第二部分中讨论如何解决此问题。

图片


请注意,链之间的通信在分片式区块链之外也很有用。 链之间的互操作性是许多项目试图解决的复杂问题。 在分片式区块链中,这个问题要容易一些,因为分片中的块结构和共识是相同的,并且有一个信标链可用于协调。 但是,在分片的区块链中,所有分片链都是相同的,而在全球区块链生态系统中,有许多不同的区块链,具有不同的目标用例,去中心化和隐私保障。


建立一个系统,在该系统中一组链具有不同的属性,但使用足够相似的共识和区块结构,并具有一个通用的信标链,可以使具有互操作子系统的异构区块链生态系统成为可能。 这种系统不太可能具有验证程序轮换功能,因此需要采取一些额外的措施来确保安全性。 CosmosPolkaDot都是有效的此类系统。 Cosmos的Zaki Manian撰写的这篇文章提供了两个项目关键方面的详细概述和比较。


恶意行为


您现在已经很好地了解了分片的实现方式,包括信标链,验证器轮换和跨分片事务的概念。


有了所有这些信息,最后一件事要考虑。 具体来说,恶意验证者可以行使何种对抗行为。


恶意叉子


一组恶意验证程序可能会尝试创建一个fork。 请注意,基础共识是否为BFT无关紧要,破坏足够数量的验证程序将始终使创建分叉成为可能。


单个碎片中有50%以上的数据被破坏的可能性要比整个网络中50%以上的数据被破坏的可能性更大(在第二部分中,我们将更深入地探讨这些可能性)。 如上所述,跨分片事务涉及多个分片中的某些状态更改,并且应用了这种状态更改的此类分片中的相应块必须全部完成(即出现在其相应分片上的所选链中),或者全部孤立(即未出现在所选链上的相应分片上)。 由于分片被破坏的可能性通常不可忽略,因此即使分片验证程序达成拜占庭共识,或者状态改变后在该块的顶部生成了许多块,我们也不能假设不会发生分叉。


这个问题有多种解决方案,最常见的解决方案是偶尔将最新的分片链块与信标链进行交叉链接。 然后将分片链中的分叉选择规则更改为始终首选交联的链,并且仅将分片特定的分叉选择规则应用于自上一个交链以来发布的块。


批准无效块


一组验证器可能会尝试创建一个错误地应用状态转换功能的块。 例如,从一个状态开始,在这个状态中,爱丽丝有10个令牌,而鲍勃有0个令牌,该块可能包含一个事务,该事务将10个令牌从爱丽丝发送给鲍勃,但最终以一个状态,在这个状态中,爱丽丝有0个令牌,而鲍勃有1000个令牌令牌。


图片


在经典的非分块区块链中,这种攻击是不可能的,因为网络中的所有参与者都将验证所有块,并且具有这种无效状态转换的块将被其他块生产者和网络参与者拒绝。不会创建块。 即使恶意验证者继续在这种无效块之上创建块的速度要比诚实验证者建立正确链的速度快,从而使无效块的链更长,这也没关系,因为每个使用区块链的参与者任何目的都会验证所有块,并丢弃在无效块之上构建的所有块。


图片


上图中有五个验证器,其中三个是恶意的。 他们创建了一个无效的块A',然后继续在其之上构建新块。 两个诚实的验证器将A'视为无效,并在它们已知的最后一个有效块的顶部进行构建,从而创建了一个分叉。 由于诚实分支中的验证者较少,因此其链节较短。 但是,在经典的非分块区块链中,将区块链用于任何目的的每个参与者都有责任验证他们收到的所有块并重新计算状态。 因此,对区块链有任何兴趣的任何人都会发现A'是无效的,因此也立即丢弃了B',C'和D',因此将链AB作为当前最长的有效链。


但是,在分片的区块链中,没有参与者可以验证所有分片上的所有交易,因此他们需要某种方式来确认在区块链的任何分片的历史上都没有包含无效的区块。


请注意,与叉子不同,交叉链接到信标链不是一个足够的解决方案,因为信标链没有能力验证区块。 它只能验证该分片中是否有足够数量的验证器对块进行签名(并以此证明其正确性)。


我知道只有两个解决方案可以解决这个问题,但今天都不能令人满意:


  1. 有一些合理的机制会在尝试错误地应用状态转换时提醒系统。 假设每个分片都在运行某种BFT共识,只要特定分片中的恶意验证程序的数量小于1,则至少一个诚实验证程序将需要证明一个块,并验证状态转换函数是否为正确应用。 如果超过三分之二的节点是恶意的,它们可以在没有单个诚实节点参与的情况下完成一个块。 假设分片中的至少一个节点不是恶意的,则需要某种机制来允许此类节点监视正在生成的块,并具有足够的时间来挑战具有无效状态转换的节点。
  2. 在块中有一些信息足以证明状态转换已正确应用,但比状态转换函数的实际应用便宜得多。 最接近的机制是zk-SNARK (尽管我们实际上并不需要“ zk”或零知识部分,非zk SNARK就足够了),但是众所周知,zk-SNARK的计算速度很慢这一点。

如今,许多协议都假设通过正确的验证器旋转和拜占庭式的容错共识,不可能产生分叉或无效的状态转换。 该假设不合理的原因是另一篇文章的主题。


奥托罗


我写了很多关于区块链和分片的文章,我们还有一个视频系列,我们通过技术深入探讨了可扩展协议的创始人,例如Cosmos和Solana。 您可以在Twitter上关注我。

Source: https://habr.com/ru/post/zh-CN437926/


All Articles