Warpgate

Warpgate

The cross-chain communication problem

We are entering a multichain world. Ethereum, other L1s, rollups, side-chains... will coexist in a same ecosystem which is the blockchain industry and we need to transfer liquidity between that chains.

Transferring liquidity between domains introduces a cross-chain communication problem. When a user wants to move liquidity from chain A to chain B, he needs to prove on chain B that his transaction on chain A has been validated.

There are currently different methods to provide such verification:

Use a kind of third-party oracle, trusted relayer or POS Network
Use HTLCs

The first method brings new critical trust assumptions and has already led to hundred of millions of funds stolen in hack. The second method does not provide the best user experience. That's why we decided to build Warpgate: a very light client to enable cross-chain communication with the same level of trust then the source network consensus system.

Very light clients

A light client is a program that allows to verify the data of a blockchain and to communicate with it in a decentralized and trust-less manner without storing the whole chain. A light client relies on a full node to gather the data but it can verify everything properly by itself. What we call a very light client is an on-chain* light client that cannot communicate with the network but can verify that a transaction has been included into a blockchain.
* another chain than one the client is verifying

We decided to build an Ethereum beacon chain very light client for Aleph Zero, which will allow cross-chain communication between post-merge Ethereum and Aleph Zero and thus bridging liquidity from Ethereum to Aleph Zero.

How we built it

We specified a data format we call a packet which contains all the information about a transaction and the block it is into that is needed to verify that a transaction has been included into a block.
We made an algorithm taking the packet as input and checking if the given transaction has been included into the block.

Then there are two ways to prove the block has been included into the blockchain:

Provide block hashes from an oracle
Provide block attestations from the sync committee: a subset of validators which has to sign every slot and changes every 27 hours

Challenges we ran into

We never used Ink! before and we had some trouble to learn this technology during the limited time of the hackaton. We will need more time to implement the full very light client with Ink!.

A word about very light clients

We think on-chain light clients are the endgame of bridging. They can allow trust-less cross-chain communication with a seamless user experience. We are going to work to implement and deploy them in the next coming weeks.

What's next for Warpgate

Implement the proof verification in Ink!
Choose between using an oracle to provide block headers and get then attested by the beacon chain sync committee
Deploy the bridge on Aleph Zero