zoukankan      html  css  js  c++  java
  • 区块链: 跨分片需要解决的问题

    同步跨分片消息将如何工作?

    如果您将历史交易记录视为已经结算,并且只是试图计算状态转换函数,则该过程变得更容易。有几种方法;一个相当简单的方法可以描述如下:

    一个交易可以指定一个可以在其中操作的一组分片为了使交易有效,它必须在所有分片上被打包在相同块高处。块中的交易必须按照它们的散列顺序(这确保了规范的执行顺序),如果分片X上的客户端看到带有分片(X,Y)的交易,则请求分片Y中的Merkle证明,以验证(i)分片Y上存在该交易,以及(ii)分片上的前置状态Y表示交易需要访问的那些数据位。然后执行交易并提交执行结果。请注意,如果很多交易有许多不同的“块对”,那么这个过程可能是非常低效的;由于这个原因,只需要简单的要求块来指定姐妹分片就可能是最佳的,然后可以在每块级别更有效地进行计算。这是该方案如何运作的基础;人们可以想象更复杂的设计。但是,在进行新的设计时,确保低成本的拒绝服务攻击不能任意拖慢状态计算总是非常重要的。

    那么半异步消息呢?

    Vlad Zamfir创建了一个方案,异步消息仍然可以解决“预订火车和旅馆”的问题。这工作如下。状态记录了最近所做的所有操作,以及任何给定操作(包括跨分片操作)触发哪些操作的图谱。如果操作被还原,则创建收据,然后可以使用该收据来回滚该操作对其他分片的任何影响;这些回滚可能会触发他们自己的回滚之类。这个论点是,如果一个偏好系统使得回滚消息可以像其他类型的消息一样快地传播两次,那么一个在K个回合中完成执行的复杂跨分片交易可以在另外的K个回合中完全回滚。

    这个方案引入的开销可以说是没有得到充分的研究;可能存在触发二次执行漏洞的最坏情况。很显然,如果交易具有更加孤立的影响,这种机制的开销较低;也许可以通过有利的gas成本规则激励孤立执行。总而言之,这是高级分片更有前途的研究方向之一。

    什么是保证跨分片调用?

    分片中的挑战之一是,在进行调用时,默认情况下没有硬协议提供,保证由该调用创建的任何异步操作都将在特定的时间范围内完成,甚至完全没有;而是由某方在目的地分片中发送触发收据的交易。这对于许多应用程序来说是可以的,但是在某些情况下,由于以下几个原因可能会有问题:

    可能没有任何明确的激励措施来触发给定的收据。如果一个交易的发送给多方带来了好处,那么在各方试图等待更长时间直到其他人发送交易(即玩“鸡”)或者简单地决定发送一个交易交易是不值得单独交易的。
    跨分片的gas价格可能会波动,在某些情况下,执行前半部的操作会迫使用户“坚持到底”,但用户可能不得不以更高的gas价格来追踪。这可能会由于DoS攻击和相关的恶意破坏形式而加剧。
    一些应用依赖于跨分片消息的“等待时间”上限(例如火车和旅馆示例)。由于缺乏硬性保证,这些应用程序将必须具有无效率大安全边界。
    人们可以试着想出一个系统,在某些分片中生成的异步消息在一定数量的块之后自动触发目标分片中的结果。然而,这要求每个分片上的每个客户端在计算状态转换函数的过程中主动检查所有其他分片,这可能是低效率的来源。最为人所知的折衷方法是:当高度为height_a的分片A的收据包含在高度为height_b的碎片B中时,如果块高度的差异超过MAX_HEIGHT,则碎片B中的所有验证人都从height_a + MAX_HEIGHT + 1创建块到height_b - 1是受到惩罚的,这个惩罚成倍增加。这些处罚的一部分给予最终包括该块作为奖励的确认者。这使状态转换功能保持简单,同时仍强烈激励正确的行为。

    等等,但是如果攻击者同时从每一个分片向分片X发送一个跨分片调用呢?在数学上不能及时包含所有这些调用吗?
    正确;这是个问题。这是一个建议的解决方案。为了从分片A到分片B进行跨分片调用,调用者必须预先购买“冻结分片B的gas”(这是通过分片B中的交易完成的,并记录在分片B中)。冻结分片B的gas具有快速滞期费率:一旦排序,每块失去1 / k的剩余效能。分片A上的交易随后可以将冻结的分片B gas与其创建的收据一起发送,并且可以在分片B上免费使用。分片B的块专门为这些交易分配额外的gas空间。请注意,由于滞期规则,对于给定的分片,在任何时候都可以获得最多GAS_LIMIT * k的冻结gas,当然可以在k个块内填充(事实上,由于滞期造成的速度更快,但是我们可能由于恶意验证人需要这个松散的空间)。假如太多的验证人恶意地不包括收据,我们可以通过免除验证者来公平惩罚,尽可能多地从最旧的收据开始填充更多收据到“收据空间”。

    在此预购机制下,想要进行跨分片操作的用户将首先预先购买所有将要进行操作的分片的gas,过度购买以考虑滞期费用。 如果操作会创建一个收据,触发在B分片中消耗100000gas的操作,那么用户将预先购买100000 e(如271818)分片B冻结的gas。 如果该操作反过来在分片C中花费100000gas(即,两个间接级别),则用户将需要预先购买100000 e^2(如738906)分片C冻结的gas。 注意,一旦购买被确认,并且用户开始主要操作,用户可以确信他们将与gas价格市场的变化隔离,除非验证者自愿地从收据不包含惩罚中失去大量的资金。

    冻结gas? 这听起来很有趣,不仅是跨分片操作,还有可靠的分片内调度
    确实; 您可以购买分片A中的冻结分片A gas,并从分片A向其自身发送保证的跨链分片调用。 虽然注意到这个方案只支持在很短的时间间隔内进行调度,并且调度对于这个块是不准确的; 只能保证在一段时间内发生。

    是否内分片和跨分片有保证的调度,有助于抵制试图审查交易的大多数共谋?
    是。 如果用户未能获得交易,因为共谋验证者正在过滤交易并且不接受任何包含该交易的块,则用户可以发送一系列消息来触发一系列有保证的预定消息,最后一个消息在EVM内部重建交易并执行它。 如果不彻底关闭有保证的调度功能,并严重限制整个协议,防止这种规避技术实际上是不可能的,因此恶意的验证者将无法轻易做到。

    分片区块链可以更好地处理网络分区吗?

    本文档中描述的方案不会改进非分片区块链; 实际上,每个分区最终都会在分区两侧有一些节点。 有人(例如来自IPFS的Juan Benet)建立了可扩展的网络,其具体目标是网络可以根据需要切分成分片,从而在网络划分的条件下尽可能地继续运行,但是存在不寻常的加密经济挑战来做好这项工作。

    一个主要的挑战是,如果我们想要基于位置的分片,那么地理网络划分最低限度地阻碍了分片内聚合(具有非常低的分片内延迟和因此非常快的分片内块时间的副作用),那么 我们需要有一种方法让验证者选择他们正在参与的分片。这是很危险的,因为它允许在诚实/不协调的多数模型中有更多类别的攻击,和Zamfir模型中更高作恶因子更低成本的攻击。 地理切分分片的安全性和通过随机抽样来分片效率是两个完全不同的事情。

    其次,如何组织应用程序需要更多的思考。 上面描述的分片区块链中的一个可能的模型是每个“app”在某个分片上(至少对于小规模的应用程序)。 但是,如果我们希望应用程序本身具有分区防护功能,则意味着所有应用程序都需要在某种程度上进行跨分片。

    解决这个问题的一个可能途径是创建一个提供两种分片的平台 - 一些分片是随机抽样的高安全性“全局”分片,而其他碎片则是较低安全“本地”分片,可能具有属性的如超快的块时间和更便宜的交易费用。 非常低的安全性碎片甚至可以用于数据发布和消息传递。

    通过 n = O(c^2)推动扩展的独特挑战是什么?

    有几个考虑因素。首先,需要将算法从双层算法转换为可堆叠的n层算法;这是可能的,但是很复杂。其次,n / c(即网络的总计算负荷与一个节点的容量之间的比率)恰好是接近两个常数的值:首先,如果以块为单位测量,则几个小时的时间跨度,这是一个可以接受的“最大安全确认时间”,其次是奖励和存款之间的比率(早期计算表明Casper的存款大小为32ETH,块奖励为0.05ETH)。后者的后果是,如果一个分片上的奖励和惩罚升级到验证者存款的规模,持续攻击分片的成本将是O(n)大小。

    高于c^2可能会导致进一步削弱系统所能提供的安全保障类别,并允许攻击者以中等成本长时间周期以某种方式攻击某个碎片,尽管仍有可能防止无效状态被最终确定,并防止最终状态被回滚,除非攻击者愿意支付O(n)的成本。然而,回报是巨大的 - 一个超级分割的区块链可以用作几乎所有去中心化应用程序的通用工具,并且可以承担交易费用,使其几乎免费。

    这篇文章来源于以太坊分片的FAQ,非常感谢toxotguo翻译。

    BTC钱包地址:3DBVvAdAdmUEpxyfeEXT8s77QVNtCVcAQt
    ETH钱包地址:0xc2ee48e1c0b2993413ead7aaf274669954f50fbf
    bu钱包地址:buQc1xgKuvtUpAEUP4szYPEkSh3ENh8pBm1a

  • 相关阅读:
    Spring注解(环境)
    Spring注解(赋值相关)
    C#:关联程序和文件
    C#: 获取执行程序所在路径和启动资源管理器
    C#:WPF绘制问题
    WPF:窗体置顶
    C#:屏幕显示区域问题
    C#:文件、文件夹特别操作
    C#:插件、框架
    WPF:MenuItem样式
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13313184.html
Copyright © 2011-2022 走看看