Chain Communication

A bridge is a system that allows communication between two contracts deployed on different layers (L1 and L2) using L1/L2 interoperability. Developers can create their own bridge for any token, but default bridges (one for ETH and one for ERC20 tokens) are provided for basic bridging.

To deposit tokens from L1 to L2, users must call the deposit method on the L1 bridge contract. This triggers the following actions:

1. The user's L1 tokens will be sent to the L1 bridge and locked there.

2. The L1 bridge initiates a transaction to the L2 bridge using L1/L2 communication.

3. Within the L2 transaction, tokens are minted and sent to the specified address on L2.

4. If the token does not exist on zkSync yet, a new contract is deployed for it. Since the L2 token address is deterministic (based on the original L1 address, name, and symbol), it doesn't matter who bridges it first, the new L2 address will be the same.

5. For every executed L1 -> L2 transaction, there will be an L2 -> L1 log message confirming its execution.

6. Finally, the finalizeDeposit method is called, which finalizes the deposit and mints funds on L2.

To withdraw tokens from L2 to L1, users must call the withdraw method on the L2 bridge contract, which triggers the following actions:

1. An L2 -> L1 message with the withdrawal information is sent.

2. The withdrawal action is then available to be finalized by anyone in the L1 bridge by proving the inclusion of the L2 -> L1 message when calling the finalizeWithdraw method on the L1 bridge contract.

3. After the method is called, the funds are unlocked from the L1 bridge and sent to the withdrawal recipient.

The transaction fee in AVIVE is composed of two parts: the "baseFee" and the "layer2 tip". The "baseFee" is the minimum amount that the user needs to pay to the operator for the transaction to be included. This fee is calculated based on the l2gasLimit and the gas price on L1. Any additional fee paid by the user above the "baseFee" is considered the "layer2 tip" and will be used to sort the transactions by the provided L2 fee.

To sort transactions, a "priority heap" mechanism is used for all L1 -> L2 transactions. The basic cost of the transaction is defined in gas and not in ETH, so the actual amount of ether required to submit the transaction will depend on the transaction's gas price.

To call any of these methods, the recommended flow is to first fetch the gas price that will be used to send the transaction, then get the base cost for the transaction, and finally send the transaction including the necessary value.

Unlike L1 -> L2 communication, it is impossible to directly initialize transactions from L2 to L1 on AVIVE. However, you can send an arbitrary-length message from AVIVE to Ethereum, and then handle the received message on an L1 smart contract. To send a message from the L2 side, you should call the sendToL1 method from the messenger system contract on AVIVE. It accepts only the bytes of the message that is sent to the AVIVE smart contract on Ethereum.

From the L1 side, the AVIVE smart contract provides the method proveL2MessageInclusion to prove that the message was sent to L1 and included in an AVIVE block.