「Understanding Darwinia 1–9」Darwinia LCMP, A Light-Client Based Cross-Chain Messaging Protocol

What is LCMP

LCMP is Darwinia’s Light-client Cross-chain Messaging Protocol (formerly: Darwinia Bridge Messages Protocol). It allows one blockchain to send messages to another blockchain as long as they have established messaging channels with each other.

Darwinia itself is a cross-chain messaging infrastructure. On the protocol layer, Darwinia is not strictly limited to the use of LCMP. It is only one of many supported cross-chain protocols, shown in the figure below:

Cross-chain Workflow

LCMP is a light-client-based protocol composed of two layers. A Truth layer which contains the light-client, and a message layer used for sending cross-chain messages. The light-client in a target chain’s Truth layer is used to verify messages from the source chain.

As the following diagram illustrates, there are four components spanning the source and target chains. The cross-chain message workflow is described below:

A DApp on the Application Layer calls send_message on the Message Layer to initiate a cross-chain operation. After send_message is executed, the Relayer forwards the message to the Target Chain, where the Truth Layer verifies it, and executes the tasks carried within. Once complete, the Relayer forwards a confirmation message back to the source chain.

General Purpose

LCMP is a general-purpose protocol that’s open and permissionless, so it knows nothing about the Dapps running on it. LCMP makes no assumptions about the Application Layer.

LCMP offers generalized cross-chain capabilities that can extend smart contract functionality beyond the boundaries of today’s single-chain decentralized applications. It empowers developers with the ability to create extensible and composable DApps, designed for the heterogeneous multi-chain future.

Seamless Multi-chain Functionality using a Single Smart Contract

LCMP allows developers to select the best blockchain features for their Dapps, regardless of what chain the functionality resides on.

Using Darwina Cross-chain messaging SDK, developers can build multi-chain Dapps as easily as building ordinary Dapps, picking and choosing the features and functionality they need from any supported chain, and integrating them into a single smart contract deployment.

This ability to stitch together multiple smart contracts across numerous chains will redefine the way Dapps are developed. With Darwinia SDK, developers can focus on Dapp functionality and user experience, while leaving bridging to the experts. This is the beginning of the era of multi-chain Dapps.

Trust-less Cross-chain Messaging

Use of light-clients makes for a highly secure bridge design because it guarantees valid message delivery without placing trust in intermediary entities. Developers need only to trust the consensus of the source and destination chains, and the smart contract code, which is open source.

Cross-chain Feature Comparison and Glossary

There are currently a variety of cross-chain mechanisms, each with their own pros and cons, but for the purpose of this article and Darwinia's focus on putting security-first, let's categorize them broadly into three types, ordered according to those requiring the most trust, to the least:

External Validators & Federations:

This includes MPC Multi-Party Computation, TSS Threshold Signature Scheme, Multi-Sig, and PoS systems where there is most often a group of validators that monitor a smart contract address on the source chain and, upon reaching consensus, perform an action on the destination chain. Asset transfers are typically done by locking up the asset in the smart contract and minting the equivalent amount of that asset on the destination chain. These are often bonded validators with a separate token as a security model. Optimistic bridges are a variation of this which further enhances security via the addition of a 1 of N security model that mitigates attack vectors related to collusion or compromised keys.

Liquidity networks:

This is essentially a peer-to-peer network where each node acts as a router and holds an inventory of assets on both the source and destination chain. These networks most often inherit the security of the underlying blockchain; through the use of locking and challenge mechanisms, users are guaranteed that routers cannot run away with user funds. This type of bridge is best suited for cross-chain asset transfer because the assets provided by routers are native to the destination chain rather than wrapped assets, which are not fully fungible with each other, or portable between chains.

Light clients & Relays:

Actors monitor events on the source chain and generate cryptographic inclusion proofs about past events that were recorded on that chain. These proofs are then forwarded, along with the block headers, to contracts (i.e. the “light client”) on the destination chain, which verifies that a certain event was recorded and executes an action after that verification. This is a highly secure bridge design because it guarantees valid message delivery without placing trust in intermediary entities, but at the same time, it is also resource-intensive to roll out at scale because developers must build a new smart contract on each new destination chain that parses state proofs from the source chain. Oracle-based bridges are a variation on this and are more extensible, especially for chains like BTC that do not support light clients, however this added extensibility comes at the expense of decentralization because it requires Trust in the Oracle provider.

Furthermore, we can evaluate bridge design according to the following factors:

• Security: Trust & liveness assumptions, tolerance for malicious actors, the safety of user funds, and reflexivity.
• Speed: Latency to complete a transaction, as well as finality guarantees. There is often a tradeoff between speed and security.
• Connectivity: Overall selection of destination chains for both users and developers, as well as degree of difficulty for integrating an additional destination chain.
• Capital efficiency: Economics around capital required to secure the system and transaction costs to transfer assets.
• Generality: Ability to transfer specific assets, more complex state, and /or execute cross-chain contract calls.

All taken together, the trade-offs of these three bridge designs according to the various factors are compared and contrasted below:

Bridge Security Considerations

We can further break down the Security factor and examine the bridge designs on a Spectrum of Trust, with the least security-focused solutions being completely uncollateralized, or managed by human or machine-based multi-sig holders; while at the other end of the spectrum, highly decentralized solutions that leverage the security of the source chain. It's worthwhile stating, however, that no solution can be completely trust-less as there will always be implied risks associated with code flaws.

• Trusted systems: Actors do not post any collateral and users do not recover funds in case of system failure or malicious activity, so users rely exclusively on the reputation of the bridge operator.
• Bonded systems: Similar to the insured model (i.e. actors have skin-in-the-game), except users do not recover funds in case of error or misbehavior because the slashed collateral is likely burned.
• Insured systems: Malicious actors may be able to steal user funds, but there is an economic disincentive because they are required to post collateral and will get slashed in the case of error or misbehavior. If user funds are lost, they can be reimbursed through slashed collateral.

Note: The collateral type matters for both the Bonded and Insured models; when the collateral is the protocol token itself there are higher risks because the token value will likely crash if the bridge fails, which further reduces security guarantees.

• Optimistic: A step up in security compared to bonded or insured bridges that use External Verification. The 1 of N security model of optimistic bridges mitigates attack vectors related to collusion or compromised keys.
• Trust-less: The bridge’s security is equal to that of the source chain because there are no trusted intermediaries; only a liveliness assumption. Outside of consensus-level attacks on the underlying blockchain, user funds cannot be lost or stolen. Darwinia LCMP, Cosmos IBC, and Polkadot XCMP are three examples.

About Darwinia Network

Darwinia is a generalized light-client based message delivery network built on Substrate that’s designed to be a foundational layer for the next generation of cross-chain Dapps and games, and a primary in/out point of the Polkadot ecosystem. Darwinia Network provides a highly-secure and programmable bridging framework between heterogeneous chains such as Polkadot, Ethereum, Polygon, and BSC.

Darwinia’s Light-Client Messaging Protocol (LCMP) is a powerful and easy to implement bridging solution provided by the Darwinia Universal Cross-Chain Messaging SDK, and can be used to build cross-chain Dapps such as:

• Cross-Chain DEX: Allow users to exchange assets across multiple chains in a single transaction.
• Lending: Allow users to pledge collateral on one chain and borrow assets on other chains.
• Cross-Chain Asset Bridge: Development of Cross-Chain Asset Bridge integrating Darwinia Universal Cross-Chain Message SDK.
• NFT Market: Bid on auctions taking place on another chain.
• DAO Governance: Allow for a unified multi-chain governance mechanism without needing to move assets to a central voting chain.

The products and tools developed by Darwinia team have been awarded three Web3 Foundation grants and a level-2 Substrate Builders award, and are also mentioned in the Polkadot lightpaper as friends of Polkadot.

Follow Us: Github | Website | Medium | Telegram | Twitter | Discord | Reddit