Consensus
A fault-tolerant mechanism to achieve agreement, assurance, and security in the blockchain system across the decentralized network.
An easy way to interpret the notion of our consensus is to imagine it as a prevalent record-keeping mechanism in the crypto space that helps keep all contributing nodes (or you may call them participants or transactors as you like) in the network honest.
Hundreds of thousands of users work on authentication/verification of transactions on the blockchain every day and with such a dynamically changing status of the blockchain, it is then essential for these publicly-shared ledgers to have a secure and real-time consensus algorithm to ensure that all the trade happening on our network are genuine and all participants agree on a consensus on the status of the ledger. Thus, we brought about this consensus to determine the legitimacy of contributions made by the users on the chain.
Consensus is playing an important role in the protocol security of users' funds in cross-chain transactions. There will be two roles involved in our consensus mechanism:
➊ Executor: the one that executes the target chain transaction and claims the funds from the source chain.
➋ Validator: the one that validates the data of the executor's target transaction and signs/approves the asset-claiming request from the executor.
The flow chart that demonstrates the roles involved in the proof of consensus
There will be only one executor within our consensus for the time being, and it will constantly check and process transactions according to the set routine as follows.
The executor keeps monitoring cross-chain swaps on each of our supported blockchains, and then parses and validates the events with regard to the transactions. Events in the transactions contain the source and the target chain swap information, which includes the amount of the bridge token, the amount being swapped, the minimum of target tokens to be received, etc.
It is also responsible for checking the validity of the orders of the events, and whether the desired amount (the quoted price) within the event tallies with users' funds on the source chain. If the events within transactions are found invalid, the executor will require the validators to sign a rejecting request and submit a new transaction to reject the swap request from users along with their assets.
Once the events are validated and with the prerequisite that the liquidity on the target chain is sufficient, the executor will apply the best route on the target chain to swap bridge tokens to the target tokens. If liquidity is insufficient to underpin the swap, the executor might require the validators to sign the canceling request and submit a new transaction to cancel the swap request from users along with their assets.
Upon closing a swap, XY Protocol sends out both swap and closeSwap transactions to the validators, where the two transactions will be checked as to whether or not users have received their legitimate share of tokens. Once they are verified, the validators will consign a signature to XY Protocol to allow the Protocol to claim the assets for users.
Let's suggest a worst-case scenario in which XY Protocol attempted to steal a client's assets by swapping only a small portion of their tokens and taking possession of the rest of the assets, the validators were delicately designed not to put the signature to the deal that enables XY Protocol to claim the funds which do not belong to the Protocol itself. Instead, the validators would sanction a refund signature whereby the assets would be transferred back to the client on the source chain.
There will be multiple validators within our consensus, and it will support and constantly validate the data of the requests from the executors where necessary.
The validators will keep validating the executor's transactions on the target chain and check if the transactions meet the requirements of users, such as the closing target-chain token amount or the amount of bridge token given to users instead should a swap fail.
Upon validating transactions, the validators are responsible for putting signatures to the trade and allowing the executors to claim the credit on the source chain.
As implied in our Roadmap section, there will be improved versions of consensus to come, and we intend to combine the two roles into one as a Node. There will be numerous "self-sustained" nodes within our consensus, and every node has the capability to effect transactions and validate the data and trading information of other nodes' requests, which makes our consensus operate more of a decentralized, self-regulating system that works on a global scale without any single authority.
Last modified 5mo ago