As we continue to explain our new vision, this post explores bridges between Waves Platform and other blockchains.
One of the main priorities in Waves’ future development will be achieving interoperability between the Waves ecosystem and other blockchains. This will contribute to the widespread use of blockchain technology and boost its implementation for a range of applications.
The first step towards universal interoperability will be building a bridge connecting the Waves and Ethereum blockchains.
The biggest issues that needs to be resolved to facilitate inter-blockchain communication are receiving data from another blockchain and sending tokens between blockchains.
A scheme that allows one blockchain to know about transactions in another blockchain would enable direct exchange of funds between blockchains, making existing centralized gateways obsolete.
Introducing Chain collectors
Fig. 1.
Let’s say we have two independent blockchains, A and B. We need to be able to prove on the B network that a transaction has actually taken place on the A network, and vice versa.
To achieve that, a chain collector is created for the B network. This is a smart account storing block headers of network A blocks. The chain collector will only add a block’s header to the chain if there is a correct link to the previous block, a block generator’s valid signature, and an oracle’s valid signature.
The chain collector will store the sequence of blocks that has been checked as described above. A provider of validity and finality of data assumes responsibility for their correctness (see further below).
The use of chain collectors will facilitate “bridges” between independent blockchains, as it will enable proofs of token transfers between blockchains.
Building bridges
To automate the process of token transfer between independent blockchains, we suggest using smart accounts as “token ports”. A token port for the B network allows withdrawal of funds only if there is a proof of deposit for the same amount to the A network’s token port.
Upon receiving that proof, the B network’s token port checks the entire transaction, including its sender, recipient, amount and asset ID, to make sure that the transaction has been added to the specified block.
Finality issue
One important issue that needs to be addressed is block finality in the other blockchain. How can a blockchain know that a block in the other blockchain has truly been finalized? If block finality is based on probability, as is the case in PoS-consensus networks, it’s impossible to ensure a block’s finality in the other network.
However, a group of validators could be set up, who will validate authenticity and finality of blocks with their signatures. Validators’ public keys are known in advance, and the authenticity of data they provide is confirmed by their signatures.
If a block’s header has been signed by the required number of validators, it is considered to be finalized and becomes available to accounts in the B network. To withdraw the funds, a user will have to provide a Merkle Tree proof for the transfer transaction in the A network’s specific block.
A chain created by the B network’s validators is stored in the chain collector account’s state, and basically operates as an oracle.
A consensus between validators could be reached in a number of ways, including a multi-signature, which will be verified by the chain collector, or threshold signatures (also verified by the chain collector). After that the validators send their consensus decision to a blockchain interested in that information.
Exchange of funds between the Waves and Ethereum blockchains
In both networks, an account for sending and receiving funds — a token port — will be created. The accounts will know each other’s addresses.
Similarly, in both networks, chain collector accounts will be created, which will provide required transaction data for the other blockchain’s token port.
Sending tokens from Ethereum to Waves
Fig. 2
Let’s assume Alice, who has an account on the Ethereum blockchain, wants to send funds to Bob, who has an account on the Waves blockchain. Alice sends ETH to a token port on the Ethereum network and attaches Bob’s address to the transaction using the token port interface.
The transaction is subsequently added to the transactionRootHash of a block in the Ethereum network. Waves’ chain collector records the header of this block on the Ethereum network to its state.
To prove to the Waves’ token port that the transaction is present on the Ethereum blockchain, Bob initiates a validation process to confirm that the transactionRootHash contains the ID of that specific transaction. The token port checks this against the chain collector’s data using the Merkle proof. If the provided proof is correct, Bob will be able to collect the funds Alice sent him (in wETH).
Sending tokens from Waves to Ethereum
Fig. 3
Now let’s assume Bob, who has an account on the Waves blockchain, wants to send funds to Alice, who has an account on the Ethereum blockchain.
Bob sends WAVES to the token port for the Waves network and attaches Alice’s address on the Ethereum network to the transaction.
The transaction is subsequently added to the transactionRootHash of a block in the Waves network.
Ethereum’s chain collector writes the header of this block on the Waves network to its state.
To prove to the Ethereum token port that the transaction is present on the Waves blockchain, Alice initiates a validation process to confirm that the transactionRootHash contains the ID of that specific transaction. The token port checks this against the chain collector’s data using Merkle proof. If the provided data is correct, Alice will be able to collect the funds Bob sent her.
Economics and incentives
A token port could charge a fee for each deposit/withdrawal transaction.
A chain collector could operate by request: when an account on the B network needs information about a transaction on the A network, that account will send a request to the chain collector, requesting a block header at a specific height. In exchange for that information, the account pays a fee to the chain collector.
To hedge against a collusion between validators, they can be required to undergo a KYC procedure and, if a chain collector provides incorrect data, the validators will take responsibility for that.
Over the coming weeks, we’ll continue detailing further aspects of Waves’ evolving ecosystem.
Read Waves News channel
Follow Waves Twitter
Watch Waves Youtube
Subscribe to Waves Subreddit
Ecosystem development strategy: interchain bridges was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.