我已经和我的一些同事谈过Etalum2.0碎片,我的问题是:
鉴于切分的定义:
分片是一种划分方法,以分散计算和存储工作负载。
Etalum2.0碎片是不是为了支持代码执行。 (至少在短期内是这样,但我将在下面解释为什么我对长期支持…有很多疑问)。,这意味着它们不计算和维护全局roll 2.0状态的一部分(它们必须同步到信标链,定期提供卷起,并且信标链运行代码执行)。
现在,我想提出第二个问题:
使用智能契约,有效的状态/计算分片实际上是可能的吗?(不依赖信标/骨干链,因为如果碎片能够执行代码和维护状态,它将变得无用)
在我看来,有两个主要问题:
当涉及到智能契约时,事务的“复杂性”就会成倍增加。它不再是发送者和接收者之间相对简单的关系。智能合同内部可以调用许多其他地址..。要决定合同是否会发出交叉碎片交易(如果应该在该特定的碎片中执行),则需要执行合同,至少可以说,这是适得其反的…。
为了盈利,切分设计必须尽可能减少交叉碎片事务,因为它们需要相关碎片之间的状态同步,并行化丢失。现在,我不知道如何用聪明的合同.
没有正确的方法来决定如何解决我所知道的“真实”碎片之间的状态不一致。因为他们应该处理大部分独立的交易集,因此持有不同的状态.在碎片之间插入共识机制也部分地违背了碎片的目的。
发布于 2022-05-27 15:27:03
L2现在更像是核心架构的一部分,而不是真正的切分.你觉得呢?我漏掉了什么吗?
不,这不是L2。在每个时代,将碎片链同步到信标链并不能使其成为L2解决方案。L2解决方案是那些在链外进行处理并保持对链上处理的证明的解决方案.在Etalum2.0切分中,情况并非如此。ETH2.0碎片是一组单独执行协商一致的节点,每个碎片都表现为一个单独的块链。
有几种执行跨碎片事务的方法,它们在一个碎片中调用智能契约,然后在另一个碎片中调用另一个契约。阅读一些研究出版物会给你一个想法。一种天真的方法是将受抚养人事务分配给同一个碎片。例如,最近有人提出了一种称为基于应用程序的切分方法.其想法是将依赖的DApps (智能契约)分配给相同的碎片。请注意,在编写本报告时,Etalum2.0仍在开发中,处理交叉碎片事务的方法可能会发生变化。
没有正确的方法来决定如何解决我所知道的“真实”碎片之间的状态不一致。因为他们应该处理大部分独立的交易集,因此持有不同的状态.在碎片之间插入共识机制也部分地违背了碎片的目的。
切分的目的并不是在碎片之间具有相同的状态。每个碎片将根据它们处理的事务具有不同的状态。全局状态将只保留在信标链中,这将使状态与每个时代的所有碎片链同步(一个碎片链委员会执行的一段时间)。请注意,Etalum2.0将有固定数量的碎片(64个碎片),因此不需要合并两个碎片链。
https://ethereum.stackexchange.com/questions/112608
复制相似问题