Below is described the mechanics of how the ZK bridge from the Settlement Layer to our system works, but the bridge in the opposite direction works in a similar way.
General description of the bridge workflow.
- Users deposit funds into the smart contract on the Settlement Layer. A deposit request is created in the contract with all the necessary information: id, asset, amount, account_id. In the final steps, when the funds are deposited in our system, this Deposit Request will be confirmed with a ZK proof and removed from the contract.
- There is a centralized operator/indexer that monitors new deposit requests. Anyone can become such an operator. Upon discovering a new deposit request, they send a transaction to mint the required amount of funds for a specific user.
- The transaction is processed like any regular transaction in the system, meaning a ZK proof is created that needs to be verified on the Settlement Layer. Additionally, we need to notify the Settlement Layer that the deposit request has been successfully processed and remove it from the smart contract on the Settlement Layer.
There is a significant limitation to this approach. Such a bridge system can work with one and only one network. This means that if Ethereum is used as a Settlement Layer, the bridge can only be used with Ethereum.
FAQ
Isn't a centralized operator/indexer a security vulnerability in this system, just like in regular bridges?
From a security standpoint, this system is 100% secure. There is one caveat, though. If we allow anyone to process deposit requests, it would be very easy to disrupt the system, as unscrupulous operators could send fake or altered requests to our system. Due to this, the final verification on the Settlement Layer would not match, and the entire system would be suspended. To avoid this, it is necessary to have multiple operators that must reach a consensus on how much and to whom money should be minted in our system. However, even if malicious actors take control of the majority of these operators, **all funds will be secure**. This is the main difference and advantage of ZK bridges over regular bridges.
What will happen if operators somehow manage to execute a non-existent deposit in our system?
This transaction will be executed in our system. During the pre-finalization stage, the individual will receive these funds. However, during the finalization of this transaction on the Settlement Layer, an error will occur, and the system will pause, awaiting a rollback. The error will occur because, in addition to verifying the proof for validity in the smart contract, there will be additional checks to compare the deposits received in the smart contract on the Settlement Layer with the deposits actually processed by our system.
Since operators are fully off-chain services, what will happen to the funds if, for some reason, no operator is monitoring deposit requests and sending transactions to our system?
Anyone can set up their own operator, process their own deposit or withdrawal request, and thereby receive their money into their wallet. If no one processes requests for an extended period of time (~2 weeks), it is possible to retrieve the funds by directly calling force transactions in the smart contract on the Settlement Layer.
Wait, where does ZK come into play in the bridge?
ZK is involved in the bridge flow in the same way as in any other transaction in our system. If a transaction is tampered with at the node level, the final block proof will not match, just like with the tampering of any other transaction.
