http://www.7klian.com

V神: 在 Layer-2 和 Layer-1 上异曲同工的技能

它答允网络环绕办理方案去组织基本设施,譬喻,为响应新的区块,自动地更新证明;生意业务可抵挡 DoS 进攻;等等

在 Layer 1 上实现有以下优势:

需要衡量的时候,它为 应用 提供了更多的选择自由,应用可以按本身的需要挑选方案。一些应用可以在链上运行,而另一些可以在 rollup 中运行

它对链 “保存可识别性”,因为默认的基本设施可以或许领略可扩展性办理方案,而且表明产生了什么(固然通用的 Layer-2 技能的尺度化在某种水平上也可以提供这个)

像 BLS signature aggregation (BLS 签名聚合)这样的技能可以让许多签名被压缩成一个,极大地节减了数据和一些计较开销(相对付计较,数据存储上的庞大节减使其与错误性证明相结适时可以有很是强大的机能)。这些技能可以用在链上,将一个区块内的所有生意业务组合成一笔生意业务。这些技能也可以用在应用层,通过生意业务打包机制,让很多生意业务打包成一个包来提交,一个签名查抄器按照所有生意业务的哈希值和生意业务中声称的发送方的公钥来验证签名,然后再独立执行生意业务。

SNARK / STARK

从依赖于沟通底层行为的 Layer 1 和 Layer 2 上得到的可扩展性增益一般是不能团结的。譬喻,利用错误性证明获得的可扩展性增益与利用 rollups 获得的可扩展性增益不会互相叠加,因为他们基础上是实现了沟通的机制,因此假如利用 rollups 在基本层获得了 10000 tx/sec,利用错误性证明到达 1000 tx/sec 是安详的,只利用错误性证明在沟通的基本层上获得 10000 tx/sec 也是安详的。在 Layer 1 和 Layer 2 上做沟通的事会导致不须要的基本设施膨胀,因此常常在两者中选择一个是较量公道的。譬喻,假如不管掉臂地利用 Layer 2 的无状态合约,那么这也会使 Layer-1 的状态极其昂贵,而不能去有效地实施 layer-2 的方案,因此,要保持较小的状态,省得 layer 1 也需要构建无状态客户端。同样的需要留意的是,数据可用性是独一一件可以在 Layer 1 上可以办理、但在 Layer-2 上则只能依靠大幅放松的安详假设(譬喻:假设另一组参加者中厚道方占大大都)来提供的事。这是因为在数据可用性证明可能其它可用此外块和纠删码来重构一个块的替代性系统中,区块重构在很洪流平上依赖于客户端一侧的随机性,而对付差异的客户端这个随机性又是纷歧样的,且在链上不能反复。

在 Layer 2 举办一连创新的愿望是一个很重要的论点,这差遣我本身倾向于对 eth2 提供一个重量级的 Layer-2 设计,即最小化 Layer 1 提供的特性(譬喻:保持较小的状态,这样一来,就不需要无状态客户端,而在 L2 上则强制利用无状态合约)。然而,因为一些需要,,我们想在 Layer 1 提供一个显式的东西。按照前述来由,最重要的一件事应该就是在通用可扩展区块链的 Layer 1 中的数据可用性,这也是为什么要完全实现 eth2, 而不是对已存的 eth1 链构建一个重量级 Layer-2 的蹊径图的主要原因。

SNARK 和 STARK 可以清除客户端从头执行长时间计较的需要,因为其验证只需一个简朴的证明。这个同样可以在 layer 1 上(譬喻:见 Coda)可能在 layer 2 上(譬喻:ZK Rollup)完成。

在很多环境下,为了晋升可扩展性而提议的 Layer-1 改造方案(也就是说,对区块链协议或对客户端事情方法的修改)和 Layer-2 改造方案(暂时用这个广为流传的术语吧;所有从应用层设计模式上去改造可扩展性的,都可以算作此类),其实都在做沟通的事。这篇帖子将通过一些例子和直觉常识来思量这些案例。


可以最小化共鸣层的巨大性,尤其是在差异场景需要多种方案时,这是很大的优势

Optimistic rollup 的事情方法是:让系统存储一系列的汗青状态根;添加了一个新的状态的一段时间(譬喻:1 周)后才将新状态最终敲定。当一个新的、包括一些生意业务的 “包” 被提交至 rollup 合约,(这些刷新 Layer-2 状态的)生意业务不会在链上被验证(尽量这些生意业务的可用性会被隐式地验证,因为它们都得打包在这笔上链生意业务里);相反,只是把状态根添加到列表中。然而,假如外部调查者发明有的包是无效的(也就是说,这些包中声称的状态根,与基于前一个状态并厚道地执行区块后应该生成的状态不匹配),他们可以提交一个挑战。当且仅当如此,包才会在链上实际执行;假如包被证明是无效的,那么这个包及其后头的状态城市回滚。上述模式等于所谓的 “错误性证明”(Fraud proofs)。错误性证明的事情方法是:默认环境下,客户端不验证状态(尽量它们依旧需要下载所有的区块去验证可用性),而是去接管区块;只有当客户端收到网络中的动静,个中包括默克尔证明,表白特定的某个区块是无效的时候,才会拒绝区块。显然,沟通的机制(默认环境下,下载区块可是不查抄内容,只有或人发送警报时才查抄)可以在 Layer-2 方案中利用,也可以在 Layer1 中作为对客户端效率的改造。然而要留意一点:想让 Layer-1 的错误性证明和 rollup 拥有一样的特性,对数据的共鸣和对状态的共鸣需要是疏散的进程。不然,缔造区块的节点在宣布其区块之前,需要本身验证最近的所有区块(因为大概没有足够的时间获得错误性证明),这大概会限制可扩展性的增益。

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。