本文将初步讨论数据可用性问题的背景以及不同的二层网络方案是如何解决这个问题的，包括：Plasma，状态通道，以及弹性侧链。
在 2017 年，区块链的一切活动都向以太坊看齐，以太坊的价格飙升，人们蜂拥而至来创建应用（那是在 “buidl” 运动之前)，而且大企业开始参与其中。但是这种史无前例的成功超过了以太坊的处理能力。
-没错… 以那个 gas 费完成交易需要花费好几天-
以太猫是第一个获得大规模成功的分布式应用。但是它（以及其它应用）抢占了以太坊网络的所有资源 —— 导致链的待打包交易池（mempool）以一个前所未有的速率增长。一夜之间，人们开始讨论起 Plasma 和状态通道，认为这些会是解决我们扩展问题的方法。但是，除开那些讨论和激动的情绪，这些解决方案的开发过程却步履维艰，一些社区成员因此开始怀疑这些方案的可行性。但是现在，随着这些方案逐步上线，人们意识到困扰了开发者很长时间的真正问题是一个很显然的数据可用性问题。
本文将初步讨论数据可用性问题的背景以及不同的二层网络方案是如何解决这个问题的，这些方案包括：Plasma，状态通道，以及弹性侧链。
数据可用性问题
就像 Vitalik 之前解释过的一样，数据可用性问题的由来，是恶意矿工会试图发布一个存在区块头，却丢失部分或全部数据的区块至链上。这种攻击行为会造成：- 欺骗网络来接受一个无效的区块，而且也没有方法来证明此区块的无效性。
- 阻止节点获得当前状态。
- 阻止节点创建区块或转账，因为他们缺少相应的信息来构建证明。
显然，对于真正的去中心化网络而言，这是不可持续的。随着区块链规模的不断增长，有能力参与网络并担当节点的电脑的数量会不断减少。那么我们怎么应对这种情况呢？
很简单！在链上开始和结束事件，但是仅让客户端处理此过程中发生的所有事件。实际上，这就是所有 执行层/第二层 扩展解决方案的核心。我们从在链上处理所有事到只用底层链作为链下交易的结算层。但是这会带来一个问题：参与二层网络的客户端需要维护所有与它们关联的链下交易，不然就只能听凭别人的支配。例子
假设你去赌场玩扑克，一开始，你到柜台去把美元兑换扑克筹码（可以把这个过程想象成链上交易)。然后，你开始坐在桌边玩了几个小时扑克（这些就是所谓的链下交易）—— 有些时候你能赢钱，有些时候却只能输钱。在赢得一手大牌之后，你告诉赌场你要兑现筹码。但是在你起身之后，有人给你脑后来了一闷棍——醒来后你的记忆有些模糊，记不起来扑克牌局的细节（这就是 “数据不可用”）。当你不在时，扑克牌桌上的人决定假装最后一手牌没有发生，并且在那手牌发生之前的的当口上继续玩牌——也就是骗走你本应赢得的钱。如果类似情形发生在区块链上，那么这种作弊是不可能的，因为全世界都会知道什么发生过和什么没发生。但是因为这都是链下活动，而且你丢失了你的交易历史，你必须接受周围的对等节点告诉你的历史。在实践中
在 Plasma中，每个参与者必须保留完整的交易历史以及足够的见证数据，来证明其密码资产在每个 Plasma 区块中是否被交易过。这就使得每个参与者都成为该 Plasma 系统中的一个节点但是其仅存储自身的交易数据。作出这种要求是由于在 Plasma 上，任何人都能够与该链的运营者串通，提交无效交易来窃取其他人的资产。参与者防止这种情况发生的唯一方法是确保他们拥有所有资产的完整有效的交易记录。状态通道对于数据的要求较低，因为所有参与方仅就当前状态来达成一致，而不是就状态更新（比如：交易）来达成一致。这样就可以仅通过一个交易来让合约结算，而不需要重算任何的交易历史。而且，由于每个状态都有一个自动递增的流水号（nonce），并且除非由双方的签名，智能合约不会将其视为有效状态，所以参与者仅需存储最新的状态。注意：状态通道中的参与者也可能会想要存储历史状态，以便在对方丢失其状态历史时以更早、更有利的状态来进行结算（参与者仍可能想通过保存历史来作弊）。解决方案
现在，相关团队正在竭尽所能，以减少需要由客户端维护或通过 ZK-SNARKS 或 RSA 累加器等方式提交到主网的数据所占用的空间，这虽然是很大的改进，但他们无法解决数据可用性问题。实际上，我们不能真正针对单个客户端解决此问题，因为这将要求该客户端 100％ 的时间在线并且永远不会丢失存储在其上的数据（听起来很像区块链，不是吗？）。但是，鉴于能达到这种要求的硬件并不存在，大家普遍认为解决数据可用性问题的办法是一个受到激励的瞭望塔网络（例如 PISA）或类似的构造。这些受到激励的网络实际上是由一群质押了权益的瞭望塔组成的，它们为付费的用户备份数据，并在这些用户无法提出异议（即下线）时代表用户去质疑可疑的交易。如果他们在一定时间内未能对挑战提出异议，则他们将失去权益，并且这些权益将被授予网络中参与这项质疑活动的新瞭望塔（假定它确实提交了质疑)。这种 报错/预约 协议具有多个层次，因此用户可以确保在脱机或丢失 事务/状态 历史记录时不会受到欺骗。这些解决方案之所以花了这么长时间才出现的原因，是因为社区成员过去常常嘲笑信任某个第三方的想法，并想提出一些无需第三方即可解决问题的方案。随着这种想法的不现实性变得越来越清楚，人们开始提出各种密码学经济模型（例如上述模型）来减轻信任这些第三方的必要性。SKALE 的方案
SKALE 的弹性侧链通过区块提案流程解决了数据可用性问题。验证者创建区块提案后，它将使用下面描述的数据可用性协议将其传达给其他验证者。该协议会确保将区块提议传输到绝大多数（>⅔）的验证者中。五步协议描述如下：- 发送区块的验证者 A 向其所有对等节点发送区块提案以及构成提案 P 的所有交易的哈希值。
- 接收到 P 及相关哈希值之后，每个对应节点将哈希值与本地待打包交易队列中的转账进行匹配，以重构出 P。对于在队列中找不到的转账，节点们将向发送转账的验证者 A 发送查找请求。然后，发送方验证者 A 将这些交易的主体发送给接收方验证者，从而允许对等方重构区块提案并将该提案添加到其提案存储数据库 PD 中。
- 在此之后，节点们会向 A 发送一个带有门限签名的收据。
- 在从节点处收集了绝对多数（大于三分之二）节点的签名之后（包括 A 自己），A 将创建一个绝对多数签名 S。这个签名会作为绝大多数验证者都拥有 P 的一个证明。
- A 会向其他所有验证者广播这个绝对多数签名 S。
总结
总而言之，如果您想知道在过去的 18 个月中那些致力于执行层解决方案的开发人员都在忙什么，那么很可能他们的大部分时间最初都花在了解决这个问题上。尽管还没有针对所有扩展问题的完美解决方案，还是有许多新的令人兴奋的工作正在进行，我们对未来所能达到的高度充满信心！了解更多
如果您有兴趣尝试 SKALE，请加入 Discord 上的 SKALE 社区，并查看开发人员文档！另外，还可以随时查看 SKALE 的技术概述和共识概述，以深入了解 SKALE 的工作原理以及能提供 20,000 TPS 的原因。（完）原文链接:https://medium.com/skale/the->作者:Artem Payvin 翻译&校对:TrumanW & 阿剑（本文来源于以太坊爱好者 EthFans，未经作者许可严禁转载，违者法律必究）
