L1/L2互操作性


L1/L2互操作性

虽然大部分的执行会发生在L2上,但有些用例需要与L1链互通。主要的用例是建立复杂的桥梁,在一条链上维护治理智能合约,治理其他链上的合约,等等。

此外,L2的抗审查能力来自于底层链,所以从以太坊向zkSync发送消息的能力是称为优先级队列的抗审查机制的重要组成部分。

从以太坊向zkSync发送交易是通过zkSync智能合约完成的。它允许发送方直接从L1请求交易。因此,允许无权限地将任何数据从以太坊传递到zkSync。 阅读更多 关于从L1到L2的消息传递。

优先级队列

优先级队列的目标是提供一种抗审查的方式,以便在运营商变得恶意或不可用的情况下与zkSync互动。 优先级队列在zkSync Era中的工作方式与它在以前的zkSync版本中的工作方式非常接近。 为了了解全貌,我们首先介绍优先级队列在zkSync Lite上的工作方式。 这就为zkSync Era的优先级队列的新设计提供了依据。

它在zkSync Lite中是如何工作的

在以前的zkSync版本中,我们只有两个操作可以从L1发送到zkSync。

  • Deposit将资金从Ethereum转移到zkSync。
  • FullExit将资金从Ethereum桥接回来(这与zkSync Era中的Withdraw基本相同)。

如果用户想向zkSync存入资金或从zkSync提取资金,他们必须向智能合约发送一个交易请求,然后将被附加到优先交易队列中。该队列有以下规则。

  • 所有交易都是按顺序处理的。
  • 每个优先操作必须在提交给合约后的X天内由操作者处理。

第一条规则是由智能合约严格执行的。如果操作员变得恶意或不可用,第二条规则可能会被违反。在这种情况下,系统会进入 "流亡模式",没有新的区块可以被处理,用户可以在没有运营商的合作下提取他们的资金。

需要什么改变?

上面描述的过程对于一个有一小部分相对较轻的支持操作的系统来说是很好的。 zkSync Era支持一般的智能合约计算,因此必须改变一些原则,以保持网络的稳定性。

首先,所有交易都需要得到优先队列的支持。用户的资金可能被锁定在L2智能合约上,而不是自己的L2账户上。因此,在将他们的资金转移到L1之前,他们需要向zkSync网络发送一个`执行'交易,以首先释放该智能合约的资金。

其次,优先级队列需要保持抗审查。但想象一下,如果用户开始发送大量的交易,占用了整个区块气体的限制,会发生什么?需要有一种方法来防止对系统的垃圾邮件攻击。 这就是为什么向优先队列提交交易不再是免费的。 用户需要向运营商支付一定的费用来处理他们的交易。在无权限的情况下,确实很难计算出准确的费用。 因此,一个交易的费用等于txBaseCost * gasPricegasPrice是用户交易的天然气价格,而txBaseCost是交易的基本费用,这取决于其参数(例如Execute交易的gas_limit)。

第三,运营商不能承诺在X天内处理每笔交易。同样,这也是为了防止对优先级队列的垃圾邮件攻击。我们把这个规则改成了下面这个。

  • 操作员必须在优先级队列上做至少X量的工作(见下文),否则优先级队列应该是空的。

换句话说,我们要求操作者尽力而为,而不是要求有严格的最后期限。衡量 "工作 "的标准仍有待开发。最有可能的是优先操作使用的 "气体 "数量。

在未来,我们还将增加 "优先处理 "L1->L2交易的能力,允许用户加速包含他们的交易,以换取向运营商支付更高的费用。

优先模式

如果运营商未能处理所需的L1交易,系统将进入 "优先模式"。在这种模式下,每个人都可以通过押注代币成为运营商。优先模式的确切细节仍在开发中,并将在接近主网启动时进行更详细的描述。

为了减少风险,阿尔法主网开始时将有一个即时停止和升级网络的机制,这与优先模式的目的相矛盾。优先模式将在以下版本中逐步引入。

L2 -> L1通信

与L1->L2通信相比,L2->L1通信只基于信息的传输,而不是在L1上执行交易。它是一个内置功能,由两部分组成:从L2发送信息和在L1上读取信息。第一个被实现为对L2系统智能合约的调用。而第二个是在zkSync L1智能合约上实现的,作为一个getter函数。

发送消息

每个从L2发送到L1的消息都包含发件人的地址和消息本身。消息的长度可以任意大,但消息越长,发送费用就越高。操作者必须包括相应Merkle根的所有消息(见下一段)。因此,所有的消息都是公开的,人们不必依靠操作者来揭示它们。

读取消息

发送的每条消息都可以在链上读取。此外,有可能证明一个消息是在一个特定的L2块中发送的。为了使这种证明对用户和运营商来说都尽可能便宜,我们把每个L2区块的所有消息都存储在一个merkle树中。因此,任何L1智能合约都可以通过提供包含在某个L2区块中的证明来消费所发送的消息。证明可以只根据运营商发送给zkSync L1智能合约的数据来生成。证明也可以通过API获得。

关于L2->L1消息传递的总结

  • L2->L1通信需要在L2和L1上各进行一次交易。
  • 消息的长度可以是任意的。
  • 证明消息包含在L2区块中所需要的所有数据总是可以从Ethereum恢复。然而,最简单的方法是通过API向运营商请求证明。