In this entry, we would like to discuss the process of signature validation. As mentioned before, Validators always keep track of bridge smart contracts logs, on the lookout for new transactions. When a transaction is detected, it has to go through the signature validating process. Let us explain it with a simple example.
Assume that validator tracks Blockchain A (source blockchain) and detects a new transaction request. It verifies the transaction and sends its signature to the bridge if the transaction is correct. When the transaction gathers enough signatures, the User sends a single signature of the first Validator who approved the transaction or signatures from 2/3 of Validators to the Blockchain B (destination blockchain).
Blockchain B then checks whether the Validators signed the transaction. If there is a signature from the Validator that is not supposed to validate the transaction (for example, Validator that validates Blockchain C), Blockchain B’s smart contract does not allow money minting.
In most of the bridges, to notify the receiving blockchain about transaction confirmation, the user is supposed to send 2/3+ of signatures to the receiving blockchain. However, a transaction such as this is quite heavy on data and demands a large fee. Solbridge’s solution introduces the idea of a cheap single-signature transaction, providing the same level of security.
When sending a transaction to the receiving blockchain, it is up to the User to decide whether to send a fast, yet expensive transaction; or a cheap one, placing minted tokens under a 5-minute lock-in period.
In the case of a cheap transaction, the user has to wait for signatures from 2/3 of Validators. However, only 1 of the signatures has to be sent from any Validator who confirmed the transaction.
After the transaction is sent to the receiving blockchain, the wrapped tokens are minted but remain locked. If there are no cancellations from Validators during the 5-minute interval, the minted tokens are unlocked on the user’s address. This lock-in period ensures that even if a malicious user sends 1 signature before 2/3 of Validators confirm the transaction, there is enough time for Validators to cancel it.
When an incorrect transaction is detected by the Validator, it verifies whether ⅔ of other Validators confirmed it. If they did, the Validator does nothing. If they didn’t, the Validator sends a cancellation transaction to the receiving blockchain. The cancellation transaction burns tokens on the receiving blockchain, essentially cancelling the transfer.
