This repository has been archived by the owner on Oct 3, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 809
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* estimate gas skeleton * placeholder headers * L2-L2 & L1-L1? * first draft of how to * Update docs/dev/how-to/estimate-gas.md Co-authored-by: Stanislav Bezkorovainyi <[email protected]> * updates after first review * pushing latest wip * additions from comments * a few more updates * DOC-301 addition * Estimate gas how to drafted * more updates and l1 to l2 * check deploy * draft l1 to l2 plus edits * send message l2-l1 draft * tweaks to L2-L1 * more tweaks * after last chat with stas * Update docs/dev/developer-guides/bridging/l1-l2-interop.md Co-authored-by: barakshani <[email protected]> * Update docs/dev/developer-guides/bridging/l1-l2-interop.md Co-authored-by: barakshani <[email protected]> * present tense * add permissionless * Update docs/dev/developer-guides/bridging/l1-l2-interop.md Co-authored-by: barakshani <[email protected]> * Update docs/dev/developer-guides/bridging/l1-l2-interop.md Co-authored-by: barakshani <[email protected]> * Update docs/dev/developer-guides/bridging/l1-l2-interop.md Co-authored-by: barakshani <[email protected]> * Update docs/dev/developer-guides/bridging/l1-l2-interop.md Co-authored-by: barakshani <[email protected]> * permissionless change * Update docs/dev/how-to/send-message-l2-l1.md Co-authored-by: barakshani <[email protected]> * remove and more * clarifying PQ * more clarifications * move section * remove lite content * typo * Update docs/dev/how-to/estimate-gas.md Co-authored-by: barakshani <[email protected]> * remove sentence * redirects * Update docs/dev/how-to/estimate-gas.md Co-authored-by: Stanislav Bezkorovainyi <[email protected]> * Update docs/dev/how-to/estimate-gas.md Co-authored-by: Stanislav Bezkorovainyi <[email protected]> * Update docs/dev/how-to/estimate-gas.md Co-authored-by: Stanislav Bezkorovainyi <[email protected]> * changes from review * remove minimum and section on no gas est * more updates * update * resolving get_gasPrice issue * remove lite mentions * more adjustments to conceptual content * adding sentence back * Update docs/dev/developer-guides/bridging/l1-l2-interop.md Co-authored-by: barakshani <[email protected]> * Update docs/dev/developer-guides/bridging/l1-l2-interop.md Co-authored-by: Stanislav Bezkorovainyi <[email protected]> * Update docs/dev/how-to/send-transaction-l1-l2.md Co-authored-by: Stanislav Bezkorovainyi <[email protected]> * Update docs/dev/how-to/send-message-l2-l1.md Co-authored-by: Stanislav Bezkorovainyi <[email protected]> * more updates * updates --------- Co-authored-by: Stanislav Bezkorovainyi <[email protected]> Co-authored-by: barakshani <[email protected]>
- Loading branch information
3 people
authored
May 29, 2023
1 parent
0cb1eac
commit 7d8ff2a
Showing
19 changed files
with
749 additions
and
606 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,72 +1,42 @@ | ||
| # L1 / L2 Interoperability | ||
| # L1 / L2 interoperability | ||
|
|
||
| While most of the execution will happen on L2, some use cases require interoperability with the L1 chain. The main use cases are building complex bridges, maintaining governance smart contracts on one chain that govern contracts on other chains, etc. | ||
| ## Common use cases | ||
|
|
||
| In addition, the L2 censorship resistance is derived from the underlying chain, so the ability to send messages from Ethereum to zkSync is an important part of the censorship-resistance mechanism called the [priority queue](#priority-queue). | ||
| Many use cases require multi-layer interoperability, such as: | ||
|
|
||
| Sending transactions from Ethereum to zkSync is done via the zkSync smart contract. It allows the sender to request transactions directly from L1. Thereby allowing the permissionless passing of any data from Ethereum into zkSync. | ||
| [Read more](../bridging/l1-l2.md) about messaging from L1 to L2. | ||
| - The network's censorship resistance. | ||
| - Custom bridges. | ||
| - Multi-layer governing smart contracts. | ||
| - Multi-layer transfers. | ||
|
|
||
| ## Priority queue | ||
|
|
||
| The goal of the priority queue is to provide a censorship-resistant way to interact with zkSync in case the operator becomes malicious or unavailable. | ||
| The way the priority queue works in zkSync Era is very close to how it worked in the previous version of zkSync. | ||
| For the full picture, we first present how the priority queue works on zkSync Lite. | ||
| This gives the rationale for the new design of the priority queue for zkSync Era. | ||
|
|
||
| ### How it works in zkSync Lite | ||
|
|
||
| In the previous version of zkSync, we only had two operations that could be sent to zkSync from L1: | ||
|
|
||
| - `Deposit` to bridge funds from Ethereum to zkSync. | ||
| - `FullExit` to bridges the funds back from Ethereum (this is essentially the same as `Withdraw` in zkSync Era). | ||
|
|
||
| If users wanted to deposit funds to or withdraw funds from zkSync, they would have to send a transaction request to the smart contract which will then get appended to the queue of priority transactions. The queue has the following rules: | ||
|
|
||
| - All transactions are processed sequentially. | ||
| - Each priority operation must be processed by the operator within `X` days since it was submitted to the contract. | ||
|
|
||
| The first rule is strictly enforced by the smart contract. The second rule may be violated if the operator becomes malicious or unavailable. In case that happens, the system enters 'exodus mode', where no new blocks can be processed and users can withdraw their funds without cooperation from the operator. | ||
| ## L1 to L2 communication | ||
|
|
||
| ### What changes are needed? | ||
| L1 to L2 communication is governed by the [`IZkSync.sol`](https://github.com/matter-labs/v2-testnet-contracts/blob/b8449bf9c819098cc8bfee0549ff5094456be51d/l1/contracts/zksync/interfaces/IZkSync.sol#L4) inherited interfaces. | ||
|
|
||
| The process described above works well for a system with a small set of relatively light supported operations. zkSync Era supports general smart contract computation, and thus some principles had to be changed in order to preserve the stability of the network. | ||
| :::tip | ||
| - If you prefer to learn-by-doing, the [cross chain governance tutorial](../../tutorials/cross-chain-tutorial.md) is a practical example of layer interoperability. | ||
| ::: | ||
|
|
||
| Firstly, all transactions need to be supported by the priority queue. Users may have their funds locked on an L2 smart contract, and not on their own L2 account. Therefore before moving their funds to L1, they need to send an `Execute` transaction to the zkSync network to release the funds from that smart contract first. | ||
| ### Gas estimation | ||
|
|
||
| Secondly, the priority queue needs to stay censorship-resistant. But imagine what will happen if users start sending a lot of transactions that take the entirety of the block gas limit? There needs to be a way to prevent spam attacks on the system. | ||
| That's why submitting transactions to the priority queue is no longer free. | ||
| Users need to pay a certain fee to the operator for processing their transactions. It is really hard to calculate the accurate fee in a permissionless way. | ||
| Thus, the fee for a transaction is equal to `txBaseCost * gasPrice`. The `gasPrice` is the gas price of the users' transaction, while `txBaseCost` is the base cost for the transaction, which depends on its parameters (e.g. `gas_limit` for `Execute` transaction). | ||
| The SDK processes gas estimation for transactions implicitly. However, it is also possible to implement the gas estimation processes explicitly. | ||
|
|
||
| Thirdly, the operator can not commit to processing every transaction within `X` days. Again, this is needed to prevent spam attacks on the priority queue. We changed this rule to the following one: | ||
| :::tip L1 to L2 gas estimation for transactions | ||
| - Basic costs are measured in the amount of gas, and so the final cost depends on the gas price that the transaction assigns. | ||
| - The transaction process requires the current L1 gas price, transaction base cost, and transaction gas limit which defines the maximum amount of gas a transaction can consume. | ||
| ::: | ||
|
|
||
| - The operator must do at least `X` amount of work (see below) on the priority queue or the priority queue should be empty. | ||
| - Find out [how to estimate gas](../../how-to/estimate-gas.md) for different scenarios. | ||
| - Find out [how to send a transaction from L1 to L2](../../how-to/send-transaction-l1-l2.md) with zkSync Era. | ||
|
|
||
| In other words, we require the operator to do its best instead of requiring a strict deadline. The measure of "the work" is still to be developed. Most likely it will be the number of `gas` the priority operations used. | ||
| ## L2 to L1 | ||
|
|
||
| In the future, we will also add the ability to "prioritize" L1->L2 transactions, allowing users to speed up the inclusion of their transactions in exchange for paying a higher fee to the operator. | ||
| L2 to L1 communication is based on transferring the data as a message, and not on L1 transaction execution. | ||
|
|
||
| ## Priority mode | ||
| - Find out [how to send a message from L2 to L1](../../how-to/send-message-l2-l1.md) with zkSync Era. | ||
|
|
||
| If the operator fails to process the needed L1 transactions, the system enters in 'Priority mode'. In this mode, everyone can become an operator by staking tokens. The exact details of the priority mode are still under development and will be described in more detail closer to the mainnet launch. | ||
|
|
||
| To reduce risks, the alpha mainnet will start with a mechanism to instantly stop and upgrade the network, which contradicts the purpose of the priority mode. Priority mode will be gradually introduced in the following releases. | ||
|
|
||
| ## L2 -> L1 messaging | ||
|
|
||
| The [L2 -> L1 communication](./l2-l1.md), in contrast to L1 -> L2 communication, is based only on transferring the information, and not on the transaction execution on L1. It is a built-in feature, which is made up of two parts: sending a message from L2 and reading it on L1. The first is implemented as a call to an L2 system smart contract. And the second is implemented on the zkSync L1 smart contract as a getter function. | ||
|
|
||
| ### Sending messages | ||
|
|
||
| Each message sent from L2 to L1 contains the sender's address and the message itself. The length of the message can be arbitrarily large, but the longer the message, the more expensive it will be to send. The operator must include all messages for the corresponding merkle root (see next paragraph). Hence, all the messages are publicly available, and one does not have to rely on the operator to reveal them. | ||
|
|
||
| ### Reading messages | ||
|
|
||
| Every message sent can be read on-chain. Moreover, it is possible to prove that a message has been sent in a specific L2 block. To make such proof as cheap as possible for both the user and the operator, we store all messages, for each L2 block, in a merkle tree. Accordingly, any L1 smart contract can consume the message sent by providing proof of inclusion in some L2 block. Proof can be generated based only on the data that the operator sent to the zkSync L1 smart contract. The proof can also be obtained via [the API](../../../api/api.md#zks-getl2tol1msgproof). | ||
| ## Priority queue | ||
|
|
||
| ### Summary on L2->L1 messaging | ||
| 1. All transactions types are supported by the priority queue. | ||
|
|
||
| - L2 -> L1 communication requires one transaction on L2 and one on L1. | ||
| - Messages can be of arbitrary length. | ||
| - All the data needed for proving message inclusion in an L2 block can always be restored from Ethereum. However, the easiest way is to request proof from the operator via API. | ||
| 2. The priority queue must be fully permissionless to prevent malicious activity. For example, malicious users might send multiple transactions which push up the block gas limit to unworkable levels. To mitigate against this, submitting transactions to the priority queue is no longer free and users must pay a fee to the operator. To obtain the cost for sending an L2 to L1 message, please refer to [step 5 of how to send an L1 to L2 transaction](../../how-to/send-transaction-l1-l2.md#step-by-step). |
Oops, something went wrong.