乐观（Optimist）离链数据的可用性

乐观模式允许将繁重的计算从EVM(网络中每个节点执行的所有内容)转移到一个受激励的中继器，该中继器提交确定性或纯函数的结果。但是，为了假设结果是合法的，必须公开函数的输入数据(不仅仅是它的哈希值)，这样任何观察者都可以以非交互式的方式在链上挑战结果。

这对于输入负载大小较小(计算第N个最小素数，其中N是唯一的输入)但计算量大(计算大素数在计算上确实很昂贵)的函数很有效。但是，如果Optimist函数需要一个大的输入blob，那么它很快就会成为扩展的瓶颈。在我们实现Optimist投票计数的实验中，输入数据大小成为了限制因素，使得系统只能在每个块上中继~1000张选票(与当前的Aragon投票实现相比，仅改进了10.72倍)。

在这篇文章中，我们提出了一种设计，确保输入数据的数据可用性，而不需要在链上提交数据，同时维护尽可能多的Optimist属性。

保证数据链上可用性的成本

发送以太坊事务会给网络中的每个现有节点以及进行完全同步的每个未来节点增加成本。发送以太坊事务的基本成本是2.1万gas，但是必须为事务中发送的每个字节的事务数据付费(此外还要为数据可能触发的计算付费)。

每个非零字节的事务数据花费68个gas，而字节(0)花费4个gas。

在乐观输入有效载荷的情况下，完整的输入数据必须链上提交，在最坏的情况下每字节承担68个gas的成本。还必须对数据进行哈希值的记录，将每个字节的输入数据的总成本计算为:

事务数据成本:每字节68个gas

哈希输入数据:每字节3/16gas (加上一个常数30gas)

记录输入数据:每个字节8个gas(加上一个常量750 gas，用于包含两个主题的日志)

因此，每字节输入负载的边际成本为76.1875 gas。假设一个常数提交乐观的100000年gas成本计算,最大可以传递的数据量作为输入,如果提交只能占用80%的屏蔽gas限制(6.4gas)离开一些喘息的空间挑战处理是82.69 KB /块。

智能合约的数据可用性问题

一般的乐观主义者，像乐观的DNSSEC，允许任何人提交绑定的计算结果，并且由于输入数据对任何潜在的挑战者都是可用的，任何看到从中获利机会的人都可以挑战计算。

如果我们只是取消了提交者将完整输入数据发送到链并提交到其哈希表的要求，提交者就不会有动机将输入数据发布到任何地方，因此没有人能够验证计算或提交挑战。

智能合约无法知道提交者是否在不依赖可信的或主观的oracle的情况下实际发布了数据。还允许潜在的挑战者请求提交者将数据发布到链中，这将给提交者带来无法解决的悲哀攻击，因为智能合约无法证明提交者确实发布了数据。

为了在不将输入数据全部发布到区块链的情况下实现类似的属性，提出了以下协议，该协议存在一个主要的权衡:乐观计算只能由一组有限的、有些静态的绑定参与者提交和挑战。

确保可用性与一组激励继电器和挑战者

系统至少指定了三个同等大小的确认器作为下一个xblock的确认器集。可以选择这些验证器:

· 在存款拍卖中:验证器候选者向系统发布一个报价，其中包含他们希望锁定的代币数量作为存款以便工作。第n个最高出价作为发出最高出价的Nvalidator候选人必须支付的定金价格。一旦所有存款都得到了担保，系统就会启用。

· 以一种完全独裁的方式，虽然他们应该被信任，但是实体有某种竞争的动机(如苹果，谷歌，和微软)，但又有合作的动机，使系统工作(如互联网)。存款规模由中央决定，当事各方按选定的数额存款时，系统就开放了。

验证器应该建立一个公共或私有的P2P八卦网络来分别向组和彼此发送消息。

当用户希望执行一些乐观计算时，他们必须与其中一个验证器建立连接，并将输入数据发送给它们。此时，用户和验证器还可以为计算的执行协商费用，但是这些费用超出了这个建议的范围。

确认器在确保费用支付后(可以与确认器集共享)验证计算，并将其发送给其他确认器进行验证。其他验证器也应该独立地验证计算。当验证器从输入数据哈希值的2/3验证器和输出哈希值的2/3验证器接收到有签名的承诺时，它们向用户发送一个有签名的收据，作为一个承诺，即它们的计算将以最多Y块的形式中继。

每个Z阻塞一个提交窗口，在此窗口中，只有一个验证器被指定为中继器(以一种随机的、不可预测的方式选择)，并且具有提交计算的唯一权利和责任。为了提交计算，他们必须从2/3的验证器发送有效的签名，以便合约接受提交(验证器集大小成为可伸缩性瓶颈)。

其他验证器应该保留输入数据，以防它们自己成为中继器，并因中继而获得奖励。他们所拥有的输入数据需要为无效的中继计算提交挑战。

如果其中一个中继器诚实地行事并决定发布数据以提供透明性，那么它们就可能成为用户向其发送中继请求的默认网关(这个验证器还可以获得一笔特殊费用，而且不仅因为中继消息而获得奖励)。

乐观元事务:一个离线执行引擎

对于执行计算密集型事务，乐观是一种非常强大的可伸缩性构造。部署到EVM的大多数合约不是计算密集型的，而是存储密集型的，乐观主义者不会直接提供帮助。尽管可以想像，只需将整个合约状态的merkle根存储在存储中，类似于rollup，并在乐观的zkSNARK证明中执行状态转换。

有了这个中继模型，用户自己就不需要直接支付他们的计算费用，也不需要拥有任何ETH。不需要大量存储的事务可能非常便宜，以至于项目可以自己开始运行验证器并有效地赞助使用费用。

香草与乐观主义相比

优点

更便宜的gas，因为它使用更少的链资源。

用户自己不需要为了执行乐观的计算而存钱。

输入数据大小是伸缩性瓶颈的用例的主要可伸缩性。

缺点

如果2/3的验证器串通(并且不与诚实的验证器通信)，那么它们可能会提交恶意结果，并且没有明显的方法来检测此类行为。

1/3的验证器可以检查用户是否提交乐观计算(用户应该有可能进行非乐观计算或一般的乐观计算，以避免检查)

未来的工作和正在进行的研究

如果验证器停止签名以审查中继计算，则活动性会得到保证。如果验证器无法达到quorum，则可能要求它们将更多资金置于风险中，并要求它们在链上随机发布输入数据。

在树中聚合中继计算，因此只需要将一个哈希值放入存储中，并且可以中继许多计算，只需添加一个存储槽。

通过使用BLS签名，验证器集的大小可以大幅增加，因为对任意数量的验证器执行签名检查将花费大约16万美元的开销。