[General] On bridging from Ethereum-L1 to zkSync Era network, the funds are available immediately on zkSync Era network.

[SyedAsadKazmi]

It's mentioned in the Instant Confirmations section of ZKsync Finality docs:

This feature enables a seamless user experience, although more cautious users may opt to wait for the transaction to reach full finality or pass any intermediate steps before fully trusting the transaction's completion.

So, my question is:

On bridging, a user receives funds immediately on L2 (without having the finality being achieved on L1), now suppose the user moves or uses those funds immediately since the funds are allowed to be moved, and during the ~24 hours of time (i.e., required to achieve full finality), one can make a ton of transactions, and that too from various wallets/keys.

But, what if the finality for the initial bridging transaction would never be achieved on L1 and the transaction gets rolled back, then how zkSync will cover up those funds or rollback all the subsequent transactions in that case?

[gleenai[bot]]

The scenario you've described touches on the core aspects of transaction finality and the security mechanisms in place within the zkSync Era network. Here's how zkSync handles such situations:

Immediate Usability vs. Finality

• Immediate Usability: As you noted, when funds are bridged from Ethereum L1 to the zkSync Era L2 network, they are available for use on L2 almost immediately. This feature is designed to enhance user experience by allowing seamless transactions without waiting for full finality on L1.
• Finality on L1: The full finality of the transaction on Ethereum (L1) can take up to 24 hours. During this period, the transaction undergoes various stages until it is fully confirmed.

Handling Non-Finality

• Security Measures: zkSync inherits the security properties of Ethereum. If a transaction that has been executed on L2 fails to achieve finality on L1, zkSync has mechanisms to handle such discrepancies. This is crucial because it ensures that the integrity and trust of the network are maintained.
• Rollback Mechanisms: In the unlikely event that the initial bridging transaction is not finalized on L1 and needs to be rolled back, zkSync can revert the transactions on L2. This rollback would also include any subsequent transactions that were performed using the funds from the initial bridging transaction.
• Data Availability: zkSync ensures that all data necessary to reconstruct the state is available on-chain. This means that even in the case of disputes or the need for rollbacks, the network can restore the correct state without loss of data integrity.

Recommendations for Users

• Cautious Approach: While funds are available immediately on L2, cautious users may opt to wait until the transaction achieves full finality on L1 before making significant transactions with the bridged funds. This approach minimizes the risk of complications arising from a delayed finality.

Conclusion

The design of zkSync is such that it balances between immediate usability of funds and the robustness of transaction finality. The system's ability to rollback transactions in the event of non-finality is a critical aspect that ensures the security and reliability of the network. Users are advised to consider their risk tolerance and possibly wait for L1 finality for large or critical transactions.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[gleenai[bot]]

Yes, in the zkSync Era network, the costs associated with reverting transactions due to issues like non-finality on L1 are typically borne by the network itself. Here’s a detailed explanation of how this works:

Handling of Reversion Costs

• Network Responsibility: The zkSync network is designed to handle the operational aspects of transaction reversions, including any associated costs. This is part of the network's infrastructure to ensure security and trust.
• Gas Costs: The gas costs incurred during the process of reverting transactions are managed by the network. This includes the computational resources required to execute these reversions on the blockchain.

System Design and Efficiency

• Efficient Reversion Mechanisms: zkSync employs efficient mechanisms to manage and execute reversions, minimizing the need for excessive gas usage. This efficiency helps in reducing the overall impact of such operations on the network’s resources.
• Automated Processes: The reversion process is automated, which helps in reducing manual overhead and the potential for errors. This automation also contributes to the cost-effectiveness of handling rollbacks.

User Impact

• No Direct Cost to Users: Users are not directly charged for the gas costs associated with the rollback of transactions. This policy helps in maintaining a user-friendly environment, encouraging participation and trust in the network.
• Transparency: The zkSync network strives to maintain transparency regarding its operations, including how it handles the costs of transaction reversions. This transparency is crucial for user trust and network integrity.

Network Support and Sustainability

• Protocol Subsidies: Some of the operational costs, including those associated with transaction reversions, may be subsidized by the protocol itself as part of its commitment to security and stability.
• Community and Governance: The zkSync community and governance structures play a role in deciding and supporting the financial strategies of the network, including how it handles exceptional operational costs.

Conclusion

In summary, the zkSync network is designed to absorb the costs associated with the gas required for reverting transactions due to issues like non-finality on L1. This approach ensures that the network remains secure and user-friendly, without imposing additional financial burdens on its users for such operations.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[bxpana]

I'm going to also double check with the team to make sure the responses from the bot are correct

[EvolOfThings]

So all the gas costs are covered by the network itself.

However, I'm wondering about the gas burnt during each transaction on the L2 network (zkSync). Although it's a very small amount, it still contributes to wasteful burning of gas (ETH).

If such transactions were to happen on a large scale, over time it could contribute to an increase in ETH price, not due to good design but rather due to an inefficient mechanism.

I understand this scenario is hypothetical, but it is possible if I have not misunderstood this mechanism.

[bxpana]

A few updates here, from what I've gathered the bot responses are correct. The costs of the reorg would be handled by the operator. However deposits from L1 are not available on ZKsync until they are finalized on L1 (takes ~15 minutes to deposit). If using a third party bridge that will change things a bit which is why it's always more secure to use the canonical bridge.