Ed(Arbitrum)(00:48:13):

因此，您把这些输入链接在一起，然后简单地对累加器进行签名。这样，只需要发布最后一个累加器。同样，这是一个工程问题。这不是这些系统的基本限制。

Eli(Starkware)(00:48:28):

不，一个……等下，等下。有人讨论到这个观点了，即存在多少信息的理论下限。这就是您在 Optimistic roll-ups 中所需要的。这是理论上的限制。有了有效性证明，您就可以做到这一点。您不需要任何信息，即理论信息。您可以在突破这个理论下限。

Ed(Arbitrum)(00:48:52):

您会有一个新的下限。所有这些系统都有局限性。在 Layer 1 上需要发布足够的信息，以便人们知道发生了什么，并且不同的系统具有不同的工程约束。并不是说一种类型就一定比另一种类型有效得多。

Eli(Starkware)(00:49:11):

不，是这样。抱歉。确实是这样。我再举一个例子。假设爱丽丝（Alice）和鲍勃（Bob）在一个小时内，只是来回发送签名作为单笔付款。然后有一百万这样的用户。爱丽丝付给鲍勃。鲍勃付给爱丽丝。爱丽丝付给鲍勃。鲍勃付给爱丽丝来回循环。在 Optimistic roll-up 中，为了使系统正常工作，您需要放置一百万个签名。这是由方案本身就决定的事情。如果我们使用 ZKroll-up 时，您不需要这样做。您可以给出一个简洁的证明，即一百万个签名，包括一系列签名。它们从本质上就不一样。我认为一个从根本上要优于另一个。他们不一样。

Ed(Arbitrum)(00:49:53):

和刚才一样，这只是一个工程难题，对不对？

Eli(Starkware)(00:49:56):

不，不。这是个理论难题，这不是工程难题。

Ed(Arbitrum)(00:50:03):

你可以将大量交易汇总到一个签名中。

Eli(Starkware)(00:50:10):

那不是工程。不，不，这不是工程难题。不。

Ed(Arbitrum)(00:50:16):

这些限制，这些并不是这些系统的真正限制。这只是您使用哪种方法的问题。如果支持 BLS 签名，则每批次事务仅需要一个签名，并且一个批次可能很大。

Eli(Starkware)(00:50:33):

不，爱丽丝和鲍勃 ... 不，不。还是爱丽丝和鲍勃来回交流的例子，我不知道您使用的是哪个 BLS 签名。我目前没听说过，也许有些东西……而且不只是……我讲的是两天前发生在生产系统中的一个故事。这是一个本质问题，而不仅仅是理论上的。正如我两天前演示的那样，它也是非常实际的问题。现在，我不是说 ... 关于 Optimistic roll-up，很多事情都很好，但是很抱歉，这一切没有本质区别，我不买账。

Ed(Arbitrum)(00:51:15):

让我再试一次。所有这些系统都会定期发布一批交易，对吗？和-（被打断）

Eli(Starkware)(00:51:25):

不必要。不不不。我们不。现在，在我们的系统中，我们不会发布批交易。 (责任编辑：admin)