Cross-Chain Bridge Guide For Experts

A Technical Deep-Dive Into DAPP Network’s Interoperability Breakthrough

DAPP Network’s cross-chain bridge is an elegant aggregation of services and functionalities that is taking down the walls between chains to allow for data and tokens to flow freely. Developers can implement the code to give birth to a new generation of DeFi products, such as multi-chain liquidity pools and automated market makers (AMM.) Furthemore, all the components are built in a standardized fashion to allow developers to add adapters for other chains as easily as possible. A universal cross-chain bridge can unlock the superior liquidity on Ethereum for other chains. Ethereum developers can in turn utilize the DAPP Network’s universal layer-two to build their dApps for scale, while keeping their tokens on mainnet.

In this article, we’ll dive deep into the architecture of the bridge in order to understand how the various components come together to allow cross-chain token and data transfer.

Read all about the Universal Cross-Chain That’s Live on Ethereum.

A Look at the Cross-Chain Bridge’s Architecture

DAPP Network Services are made available via DAPP Service Providers (DSPs), who offer software services to developers on a free market basis. These services can be used in a standalone way, as well as harnessed together in a synergetic plug-and-play fashion. The cross-chain bridge is not a new service on the DAPP Network. Rather it is a combination of services leveraged together to pass messages between chains with quick finality.

The services utilized in the cross-chain bridge are:

1. LiquidScheduler: Task scheduler and automated task service, used across EOSIO chains to ensure the decentralized, continuous running of the bridge contract. Responsible for scheduling the passing of messages and receipts between chains, and periodically reading from the chains involved in the process.
2. LiquidOracles: Decentralized and trustless web oracles, used to retrieve state information about paired chains and contracts.
3. The vRAM System: Unrestricted decentralized and affordable on-chain memory, used on EOSIO chains to facilitate message and receipt compression in a way that minimizes RAM resource costs.
4. LiquidLink: Used on EOSIO chains to publish transactions to any implemented non-EOSIO chain. LiquidLink is currently fully-functional on Ethereum and could easily be modified for other chains as well as by an interested party or the community.

DAPP Network services that comprise the cross-chain bridge, connecting Ethereum and EOSIO.

Cross-Chain Bridge Under the Hood

To illustrate how the cross-chain bridge can empower the new generation of DeFi applications, let’s take a look at an example of token transfer between EOSIO and Ethereum and back.

Part 1: Sending a message from EOSIO to Ethereum

Let’s take a case study in which Alice wishes to transfer a token she has on EOSIO across to Ethereum.

Throughout the EOSIO to Ethereum part of the transfer, we will be using the following terminology to describe the smart contracts involved in transferring data and tokens between the chains:

• Originating Contract: A smart contract on EOSIO that collects transactions on EOSIO, publishes them to Ethereum once they are confirmed, and processes receipts to achieve finality.
• Destination Contract: A smart contract on Ethereum that processes transactions and publishes receipts when the transactions successfully execute on Ethereum.

Please note: It is up to the developers who create the bridge to choose whether to own these smart contracts themselves, or have them be a multi-signature contract as is the case with the bridge deployed by DAPP Network DSPs.

The first part of the transfer consists of the following phases:

1. Bridge Configuration
2. Message Creation
3. Message Confirmation
4. Message Passing
5. Receipt Creation
6. Finality

Phase 1 — Bridge Configuration

Before a transfer can take place, the Originating Contract defines the following:

1. The Ethereum address of the paired Destination Contract
2. The Ethereum chain name
3. The Consensus Threshold (how many DSP must respond with matching oracle results for a value to be considered valid).

Please note: In order for a token to be able to shuttle in between EOSIO and Ethereum, there must be corresponding token contracts deployed on both sides (i.e. Originating Contract on the EOSIO side and Destination Contract on the Ethereum side). Anyone can deploy these smart contracts and set the stage for cross-chain transfers.

Phase 2 — Message Creation

The Originating Contract adds a pending message to a queue in a multi-index table, grouped by block timestamp. The message is a properly formed Ethereum transaction in byte code addressed to the Destination Contract, with the transaction parameters, such as the amount and recipient, contained in the message payload.

Phase 3 — Message Confirmation

1. The Originating Contract creates a LiquidScheduler service job that periodically requests the Originating Contract’s chain’s Last Irreversible Block (LIB) time using the LiquidOracle Service. The LIB refers to a block that has reached finality on EOS, which is essential before triggering a transaction on Ethereum.
2. When the LIB time has exceeded the block timestamp of a pending message group, the group of messages is compressed and stored on IPFS using the vRAM System.
3. The IPFS URI is added to the confirmed messages queue in a multi-index table, resembling an on-chain pointer to the messages that are to be sent across to Ethereum.
4. The pending messages are dropped from the pending messages queue.

Phase 4 — Message Passing

1. The Originating Contract creates a LiquidScheduler service job that periodically notifies DSPs to publish confirmed messages to the Destination Contract using the LiquidLink Service.
2. The notified DSPs requests the outstanding confirmed messages, retrieves them, and parses them. Parsing is done by performing a diff of the Destination Contract’s last received messages to compute the differences between the contents of files and take only the latest messages, uncompressing the latest message data from IPFS and constructing Ethereum transactions.
3. DSPs then send transactions to the Destination Contract. Once the Destination Contract has received a message from a sufficient number of DSPs as configured in the Consensus Threshold, (e.g. ⅔ in the above example), the contained transaction will be executed against the Destination Contract.

Phase 5 — Receipt Creation

When the Destination Contract executes a message transaction, it processes the message, generates a receipt, and adds it to its storage. The receipt contains both the original message and a response.

Phase 6 — Finality

1. The Originating Contract creates a LiquidScheduler job that periodically requests receipts from the Destination Contract using the LiquidOracle service.
2. The Originating Contract processes the receipt, thus completing the communication process.

Part 2: Sending a message from Ethereum to EOSIO

In the second part of our case study, Alice did what she needed to on Ethereum, and now she wishes to send her token back to EOSIO.

Now, the roles are reversed with the Originating Contract referring to the Ethereum contract that publishes transactions to EOSIO and process receipts to achieve finality. The Destination Contract is on EOSIO and is responsible for processing transactions and publishes receipts when successful.

This time, there are 7 phases involved in the process:

1. Bridge Configuration
2. Message Creation
3. Message Passing
4. Receipt Creation
5. Receipt Confirmation
6. Receipt Passing
7. Finality

Phase 1: Bridge Configuration

Before a transfer can take place, the Originating Contract defines the following:

1. The Consensus Threshold (how many DSP must respond with matching oracle results for a value to be considered valid).
2. The Consensus Members

Phase 2: Message Creation

An Ethereum smart contract (the Originating Contract) defines the paired EOSIO Bridge contract (the Destination Contract) and the EOSIO LiquidX chain name (by doing so, it allows the bridge to support any EOSIO chain).

The Originating Contract adds a confirmed message to it’s storage.

Phase 3: Message Passing

1. The Destination Contract creates a LiquidScheduler service job that periodically requests new messages from the originating contract using the LiquidOracle Service.
2. The DSPs that receive the LiquidScheduler service job retrieves new messages from Ethereum.
3. The DSP then sends new messages to the Destination Contract, which also creates a LiquidScheduler service job that periodically processes outstanding confirmed messages.

Phase 4: Receipt Creation

The Destination Contract processes the message and adds a pending receipt to a queue in a multi-index table, grouped by block timestamp. The receipt is a properly formed Ethereum transaction in byte code addressed to the Originating Contract, with the transaction parameters containing the message payload.

Phase 5: Receipt Confirmation

1. The Destination Contract creates a LiquidScheduler service job that periodically requests the Originating Contract’s chain’s Last Irreversible Block Time (LIB) using the LiquidOracle Service. The LIB refers to a block that has reached finality on Ethereum, which is essential before triggering a transaction on EOS.
2. When the LIB Time has exceeded the block timestamp of a pending receipt group, the group is compressed and stored on IPFS using the VRAM Service.
3. The IPFS URI is added to the confirmed receipts queue in a multi-index table, resembling an on-chain pointer to the receipts that are to be sent across to Ethereum.
4. The pending receipts are dropped from the pending receipts queue.

Phase 6: Receipt Passing

1. The Destination Contract creates a LiquidScheduler service job that periodically notifies DSPs to publish confirmed receipts to the Originating Contract using the LiquidLink Service.
2. The notified DSPs request the outstanding confirmed receipts, retrieves them, and parses them. Parsing is done by performing a diff of the Destination Contract’s last received receipts to compute the differences between the contents of files and take only the latest receipts, uncompressing the receipts data from IPFS and constructing Ethereum transactions.
3. DSPs then send the recipes back to the originating contract.

Phase 7: Finality

The Originating Contract processes the receipt, thus completing the communication process.

Broadband for Blockchain

Those who were around during the era of dial-up internet can probably recall the screeching sound that would precede a network connection. Looking back, such a manual connection process seems archaic in the era of 5G connectivity. But at that time, it was the only way to get online. For blockchains, the lack of seamless interoperability between chains and the limitations it causes will one day be viewed in a similar vein to the trials of dial-up internet.

DAPP Network’s cross-chain bridge is blockchain’s broadband moment. Just as the advent of always-on, limitless connectivity unclogged the internet and allowed developers to manifest their ideas in reality, so too cross-chain communication opens up avenues of liquidity and scalability for devs in the blockchain arena.

What are you waiting for? Dive straight into the bridge code, get chatting on the DAPP Devs Telegram channel and get those bridges up and running!

Follow LiquidApps

Website | Twitter | Telegram | LinkedIn | Github

Please click here to read an important disclaimer.