Ed(Arbitrum)(00:44:03):

这涉及到如何进行公平排序以及如何以（我认为您是在假设）比以太坊出块时间快得多的速率来解决这个问题。这完全是一个新的讨论课题了，据我所知，就这个问题，任何一种系统都没有固有的优势或劣势。

Eli(Starkware)(00:44:28):

我不同意这一点，但这是另外一个观点。我认为只要有 proof，您就可以拥有更好的份额……但是，是的。

Ed(Arbitrum)(00:44:37):

是的。因此，您在这里所说的基本上是关于数字签名大小的声明，或者你到底指的是什么？

Eli(Starkware)(00:44:46):

我给出的是两天前我们系统中出现的一种非常实际的情况。市场出现价格大幅度下降，您想为客户进行正确的清算。为了使系统能够大幅度发挥作用，您希望报价及其签名的更新率很高。因此，在有效性证明系统中，您可以拥有一个证明这些价格正确完成的证明。

Eli(Starkware)(00:45:50):

实际上，我们谈论的是在非常短的时间内提供数百种交易报价，这些供稿已签名，您希望计算它们的平均值等等。因此，有很多信息需要进入流程。我想知道您打算如何处理？

Ed(Arbitrum)(00:46:08):

好吧，所以我想我不明白的是为什么您假设这些 Oracle 报价规模会变得如此之大。因为在我看来，它们不需要那么大。它们可以非常有效地编码。所有需要放在链上的基本上都是它们的压缩版本，足以重建它们的信息。

Ed(Arbitrum)(00:46:31):

而且，围绕数据压缩和数字签名有一些非常明显的方案可以解决此问题。

Eli(Starkware)(00:46:40):

但是，如果您压缩信息，您如何运用 Optimistic 的方法，证明清算是在正确的时间以正确的价格完成的？如果您采用过去的平均值 ... 平均值和变异之类的东西，您将如何证明-您将如何证明它？您需要完整的序列。至少，我们就是这样做的。我们采用完整的序列，然后我们将对其进行实际处理，并在所有清算发生时进行所有清算。但是它不会出现在 Layer 1 上，因为您可以证明这一点。

Ed(Arbitrum)(00:47:11):

答案是无损压缩。这些东西很容易压缩。您无需每次都签名。您无需为每个更新都发布签名。您无需保留每次更新的全部内容。如果这些事情（如果是非常频繁的话）以无损方式进行的话，则是超级可压缩的。这是一个工程问题。并不是这类系统的根本问题。

Eli(Starkware)(00:47:42):

还有签名呢？假设它在五分钟内，每秒总是减一。因此，我同意您可以说，在这五分钟内它按照每秒减一速度变化。但是，每个减号都需要由 Oracle 提要签名。这些是不同的签名，并且它们具有几乎完全的熵。因此，您谈论的是很多签名。您是什么……无法压缩，因为它们是 [多人对话，听不清 00:48:09]。 (责任编辑：admin)