MIDDLE.X: A Review of the Development Status of Lightweight Client Cross-Chain Bridges
The lightweight client technology is still undergoing intense evolution, and as more research and exploration take place, the difficulty of building lightweight clients will gradually decrease in the future.This article was first published as Chapter 5.5 of the PAKA Cross-Chain Research Report. Click to view the complete report.
Author: MIDDLE.X
Cross-chain bridges are generally categorized into three technical paradigms: light client cross-chain, external witness cross-chain, and hash time-locked atomic swaps. According to Arjun Bhuptani's categorization, these three technical paradigms can also be referred to as native verification, external verification, and local verification.
Currently, the most notable cross-chain bridges on the market (such as LayerZero, Multichain, Axelar, Hyperlane) almost all belong to the external witness bridge category.
Although external witness cross-chain bridges offer better compatibility and can relatively easily expand to more blockchains, they inevitably introduce new trust assumptions. Users must trust that the external witness set will not act maliciously. In contrast, the trust layer of light client bridges is more robust, as they do not require new trust assumptions; as long as the chain is secure, the bridge is secure. In scenarios where only two chains (or slightly more than two chains) need to be connected, light client bridges are more suitable.
In this article, we will review the main light client bridges currently available and the development status of light client cross-chain technology.
Light Client Principles
Let’s start with a basic overview of the principles of light clients. A light client, also known as a light node, is often represented on-chain in the form of a light smart contract. The basic principle of light client cross-chain is to deploy a light node contract of the source chain on the target chain to verify messages coming from the source chain. To achieve bi-directional cross-chain functionality, it is necessary to deploy each chain's light node contract on the other chain.
Compared to full nodes, light nodes are lightweight nodes that do not store the complete sequence of blocks but only the sequence of block headers. Although block headers are small in size, they contain a cryptographic summary of the complete data in the block. When a light node needs to know whether a particular transaction is included in the chain, it can execute SPV verification using the block header of the block containing the transaction and the Merkle path of that transaction.
To maintain the light node deployed on the target chain, off-chain agents must continuously synchronize the block headers of the source chain to the target chain. The light node contract does not have a trust assumption regarding the off-chain agent responsible for synchronizing the block headers. This is because the light node contract will verify the block headers it synchronizes, and the off-chain agent cannot deceive the light node.
The logic for verifying block headers in light nodes is no different from that in full nodes and miner nodes, consisting of validity verification and finality verification.
For PoW chains, validity verification mainly refers to verifying the proof of work of the block, while finality verification checks whether more valid blocks have been appended after the block header (on the BTC chain, it is generally believed that six appended blocks can confirm the finality of a block; on Ethereum, it is generally believed that 25 appended blocks can confirm the finality of a block).
For PoS chains, validity verification refers to verifying whether the block was generated by a randomly selected block producer, while finality verification checks whether the block has been signed by validators holding more than 2/3 of the voting weight. However, PoS light nodes do not need to verify validity; they only need to verify finality. This is because in PoS chains, the final block is always valid, whereas in PoW chains, it may not be.
Next, we will begin our review:
BTC Relay
BTC Relay is the earliest light node contract and the first light client cross-chain bridge. Its working principle is simple: it deploys an SPV light node for BTC on Ethereum to perform SPV verification of transactions on the BTC chain.
The off-chain role "Relayer" is responsible for continuously transmitting the block headers of the BTC chain to the light node contract, which formally accepts the block headers after performing validity and finality verification.
The Relayer pays gas fees for storing and verifying block headers on Ethereum, while also receiving fees from users initiating cross-chain requests as compensation, thus earning a profit. Anyone can become a Relayer and set their own fees for each call. Others wishing to become Relayers can replace the current Relayer by paying a small fee and setting a lower fee standard. Users concerned about high fees can also run their own Relayer service.
It is important to note that BTC Relay is a one-way bridge that only supports the verification of BTC information on Ethereum and does not support the verification of information in the opposite direction. Therefore, BTC Relay does not issue cross-chain derivative assets of BTC, and its use case is limited to supporting users in paying Ethereum fees with Bitcoin.
Of course, BTC Relay can serve as a building block, acting as a one-way trust layer to provide transaction verification services for other BTC cross-chain derivatives in the BTC→Ethereum direction.
Waterloo Bridge
Waterloo Bridge is a cross-chain bridge developed by Kyber Network and is the first cross-chain bridge to implement bi-directional light client verification, facilitating cross-chain transactions between Ethereum and EOS. Although Waterloo Bridge has received little attention due to the decline of EOS, its technical solution remains representative.
Waterloo Bridge implements a light client for EOS through Ethereum smart contracts, while also implementing a light client for Ethereum through EOS smart contracts.
Due to the relatively slow block generation on Ethereum and the ample computing and storage resources on EOS, the Ethereum light node contract established on EOS is an SPV light node, which synchronizes Ethereum block headers one by one to the light node contract, similar to the principle of BTC Relay.
However, since EOS has a faster block generation speed and resources are tight on Ethereum, the EOS light node contract on Ethereum is designed to only synchronize blocks where the BP set (block producer set) has changed, rather than synchronizing all blocks continuously. This design must address two issues:
How to verify historical block headers: When the transaction to be verified is not in the stored blocks, the light node contract needs to first obtain the corresponding block header from a full node. However, a verification process is also needed; how does the light node contract verify these obtained block headers?
How to verify the latest block header: How to verify the finality of the latest synchronized block header without having the complete historical block header?
How to Verify Historical Block Headers
The light node contract needs to be able to verify the block headers obtained from full nodes based on the stored block headers. How can this be achieved? We need to understand that EOS's consensus protocol is DPoS, where $EOS stakers vote to elect 21 BPs (Block Producers). These 21 BPs take turns producing blocks in a cyclic manner, and each block generated is signed by the 21 BPs. A block signed by more than 15 BPs is considered final, and these signatures are reflected in the block header.
Although EOS has a fast block generation speed, the BP set does not change frequently. As long as the light client knows the list of BPs (public key list), it can verify all block headers during that BP set's term. In other words, if the block header obtained from the full node has been signed by 15 BPs from the corresponding term, it will be accepted by the light client contract.
How to Verify the Latest Block Header
Since the election voting for the BP set occurs on-chain, the voting results will be reflected in the block header of a certain block Block{i}. The block header of Block{i} will include the list of BPs and their terms. When Block{i} and the new BP set it contains are generated, this new BP set is not yet effective, and Block{i} will be signed by the old BP set.
In simple terms, we can also understand that the old BP set approves the new BP set by signing a block that includes the election results of the new BP set. As long as the light client correctly retains the initial BP set and tracks the blocks where the BP set changes, it can trace back to the latest BP set through this "approval relationship chain." Mastering the latest BP set allows for the verification of the latest block.
Thus, as long as the light client contract is initialized with the correct initial BP set, it can complete subsequent verification work independently.
Message Verification Process
When there is a message on EOS that needs to be cross-chain transmitted to Ethereum, Waterloo Bridge will: ①. Check whether the block header of the block containing the message already exists in the light client; if not, proceed to step ②; if it exists, proceed to step ③; ②. The Relayer obtains the block header of the block containing the message from a full node and submits it to the light client, which verifies the block header based on the latest BP set it holds, meaning the light client checks whether the block header has been signed by more than 2/3 of the BP set to determine its validity; ③. Execute SPV verification on the message using the verified block header.
EOS's consensus mechanism belongs to the BFT class of consensus mechanisms, and the implementation method of the light client for EOS has become a typical paradigm for BFT public chain light clients.
Waterloo Bridge Introduction (Part 1)
Waterloo Bridge Introduction (Part 2)
Rainbow Bridge
Rainbow Bridge is the official cross-chain bridge developed by Near to connect the Near ecosystem with the Ethereum ecosystem. The Rainbow Bridge documentation mentions that the main designer of Rainbow Bridge is Anton Bukov, who is now the CTO of 1inch. Although he is no longer working full-time at Near, he still guides the development of Rainbow Bridge.
Structure
The core components of Rainbow Bridge are two on-chain contracts and three off-chain agents:
On-chain contracts:
EthOnNearClient: An Ethereum light node implemented as a Near contract in Rust.
NearOnEthClient: A Near light node implemented as an Ethereum contract in Solidity.
Off-chain agents:
Eth2NearRelay: Responsible for transmitting Ethereum block headers to EthOnNearClient.
Near2EthRelay: Responsible for transmitting Near block headers to NearOnEthClient.
Watchdog: Responsible for challenging Near2EthRelay for submitting invalid block headers, which will be detailed later.
EthOnNearClient needs to track every block header on Ethereum. NearOnEthClient only needs to track one block header per epoch, with one epoch in Near being approximately 43,000 blocks, or around 4 hours. It is impractical to synchronize all blocks, but fortunately, the validator set in Near changes only once per epoch, and there is only one block header containing the re-election information of the validator set per epoch. The design of NearOnEthClient largely draws from the EosOnEthClient in Waterloo Bridge and even reuses some of the code from Waterloo Bridge.
However, NearOnEthClient faces a technical challenge: Ethereum is incompatible with the Ed25519 signature format used by Near, making the verification of Near block headers in NearOnEthClient quite complicated. Therefore, Rainbow Bridge introduces an optimistic verification scheme.
When Near2EthRelay submits a block header to NearOnEthClient, it needs to stake some $NEAR on the Near chain. During a 4-hour window, challengers known as Watchdogs can raise challenges. If no Watchdogs raise challenges by the end of the window, the block header is formally accepted by NearOnEthClient. If a Watchdog raises a challenge and it is successful, the Near2EthRelay that submitted the invalid block header will incur an economic penalty, with half of its stake being destroyed and the remaining half becoming a reward for the challenging Watchdog.
The introduction of optimistic verification brings a new trust assumption: at least one Watchdog is honest.
In BTC Relay, only one Relayer operates at a time, but in Rainbow Bridge, both Eth2NearRelay and Near2EthRelay allow multiple instances to run simultaneously. Multiple Relayers can compete with each other to try to submit the same block, with only one succeeding each time; they can also back each other up, so if one Relayer does not submit a block in time, others will still submit, reducing the likelihood of service unavailability.
Incentives
Currently, Rainbow Bridge does not provide economic incentives for the two groups of Relay services forwarding block headers, as Near expects the main applications running on Rainbow Bridge (e.g., $ETH asset bridge, $NEAR asset bridge, ERC20 asset bridge, NFT bridge) to run their own Relay services, and at least one pair of Relay services is operated by Near officials. Future versions of Rainbow Bridge may introduce economic incentives for Relay services and corresponding charging mechanisms for cross-chain users/applications.
Latest Developments
Near has released the EVM-compatible environment Aurora, and currently, Rainbow Bridge 2.0 supports cross-chain transactions between Ethereum and Aurora. If one needs to cross-chain from Ethereum to Near, it must go through Aurora. It is important to note that while Aurora maintains an independent ledger and has its own blockchain explorer, it is not an independent blockchain but a runtime on Near. Aurora does not have its own independent validator set, and the bridge between Near and Aurora is not a cross-chain bridge but a bridge between runtimes. We should also note that at the time of writing this article, Ethereum has just completed its transition to PoS. Therefore, the Ethereum light client designed for the PoW version in Rainbow Bridge and Waterloo Bridge may soon be redesigned.
Near Introduction Documentation
Snowbridge (Snowfork)
SnowBridge is a cross-chain bridge project with official backing from Polkadot, developed by the Snowfork team, aimed at creating a native verification bridge between the Polkadot ecosystem and Ethereum.
Snowbridge is still under development, and our knowledge of it comes from the current documentation, which appears to be incomplete, with some sections still marked as "coming soon." We can only analyze Snowbridge based on the existing materials.
Snowbridge will have its own parachain, which will operate as a public good parachain in the future, called SnowBridge Parachain, responsible for establishing a bridge with Ethereum. Other parachains will connect to Ethereum indirectly through SnowBridge Parachain via XCMP. This means that Ethereum's light node Pallet will run on SnowBridge Parachain.
- In Substrate, there is no concept of contracts; developers deploy applications to the chain by adding Pallets, which are essentially the same as contracts, as they are both on-chain runtimes.
Snowbridge will consist of the following modules:
Contracts deployed on Ethereum:
Polkadot RPC: Used to handle cross-chain requests on Ethereum.
Polkadot and its parachain light client verifier.
Pallets deployed on Snowbridge Parachain:
ETHEREUM RPC for handling cross-chain requests on Polkadot.
Ethereum light client verifier.
Ethereum Light Client on Snowbridge Parachain
According to the current documentation of Snowbridge (as of October 14, 2022), the Ethereum light client is designed as an SPV light node, with the Relayer responsible for synchronizing Ethereum block headers one by one. The light client Pallet will check the proof of work and follow the heaviest fork. (However, to adapt to Ethereum's transition to PoS, Snowbridge is likely to have a new solution.)
Polkadot Light Client on Ethereum
It is important to note that since the consensus of SnowBridge Parachain is managed by the relay chain, the light client will synchronize the block headers of the relay chain, not the block headers of SnowBridge Parachain. To keep track of the latest validator set information, it is necessary to synchronize block headers that include the re-election of the validator set, meaning at least one block header must be synchronized per epoch. When a transaction needs to be verified, the light client will request the block header of SnowBridge Parachain from the relay chain as needed and verify its finality using the block header of the relay chain that contains it.
Compared to Waterloo, Snowfork faces a new problem: EOS has only 21 validators, but Polkadot has around 1000 validators. Even if exactly 2/3 of the validators sign a block, the gas consumed to verify over 600 signatures on Ethereum is exorbitant. Rainbow Bridge bypasses this issue through an optimistic verification mechanism, while Snowfork chooses to confront it directly.
Snowbridge's solution is to adopt a sampling mechanism: when obtaining block headers, the light client randomly selects a subset from the corresponding validator set of that block header. The light client will only verify the signatures of this subset rather than all signatures. According to Snowfork's research, the number of validators in this subset only needs to be ceil(log2(3*N)) (where N is the total number of validators). If N is 1000, then only 12 validator signatures need to be sampled.
BEEFY
To better support bridging with other public chains, Polkadot has developed a finality tool called BEEFY (as of the time of writing, BEEFY's code is still being refined) based on the GRANDPA consensus. After a block in the Polkadot relay chain is finalized by GRANDPA, there is an additional BEEFY consensus signing phase, where validators need to add an MMR root to the block header and then perform a separate round of consensus signing on the block header.
With BEEFY, light clients will not need to understand the complexities of GRANDPA; they only need to verify BEEFY signatures. Most importantly, the BEEFY signature format is fully compatible with Ethereum, facilitating verification on the Ethereum side.
Incentives
SnowBridge will be released in two phases. The first phase will launch the Basic Bridge, which has the basic functionality of a cross-chain bridge but lacks an incentive layer, meaning there are no incentives for Head Relayers and Message Relayers. If users/applications want to ensure their messages are successfully relayed, they need to run their own Relayer service. The second phase will transition to the Incentive Bridge, which will establish incentives for Relayers.
Application Layer
In the Snowfork team's plan, after SnowBridge goes live, three asset bridges will be quickly launched: the DOT asset bridge, which supports creating snowDOT on Ethereum; the ETH asset bridge, which supports creating snowETH on Polkadot; and the ERC20 asset bridge, which supports creating a mapped version of ERC20 assets on Polkadot, named in the format: snow-[asset name].
LCMP (Darwinia)
LCMP (Light-client Cross-chain Messaging Protocol) is a heterogeneous cross-chain protocol developed by Darwinia, which is a general-purpose, open cross-chain transmission protocol based on light client solutions. This protocol is currently available as an SDK, allowing Dapps to integrate freely. The cross-chain ecosystem built by Darwinia includes two chains: Darwinia Chain and Darwinia Parachain, with Darwinia Parachain being a parachain of Polkadot. Both chains have corresponding canary networks, Crab Chain and Crab Parachain, with Crab Parachain being a parachain of Kusama.
Darwinia Chain has deployed an EVM-compatible environment called Darwinia Smart Chain. It is referred to as a Chain because Darwinia Smart Chain has an independent state machine and browser, but it is not an independent blockchain (similar to the relationship between Aurora and Near). Correspondingly, Crab Chain also has an EVM-compatible environment called Crab Smart Chain.
Light Client Design
As of the time of writing, LCMP has already achieved:
Bridging between Darwinia Chain and Ethereum.
Bridging between Crab Chain and Crab Parachain.
Among these, the light client solution used for the latter is no different from Waterloo, and we will focus on the light client used for bridging between Darwinia Chain and Ethereum. Since BEEFY is not yet available, the block header signatures of Darwinia Chain, developed based on Substrate, are not compatible with Ethereum.
Darwinia currently adopts a transitional solution by electing a group of signers through governance, specifically responsible for signing the block headers of Darwinia Chain. The light client will verify the legality of the block header by checking the signatures of this group. Although there are over 100 validators on Darwinia Chain, the signer group consists of no more than 10 people, making it economically feasible to verify these signatures on the Ethereum side.
Eth Client On Darwinia Chain
The merged Ethereum beacon chain, as a PoS chain, has hundreds of thousands of validators, making it unrealistic to verify their signatures. Therefore, Ethereum introduced a new consensus phase in an upgrade known as Altair. After the Altair upgrade, every 256 epochs (approximately 27 hours), a committee of 512 validators will be selected from the validators to sign the finalized block headers. The light client only needs to verify whether 2/3 of the committee has signed to validate a block header. However, 512 is still a bit much, so Ethereum also uses BLS technology to aggregate the many signatures of the committee into a single signature, further reducing the verification cost for the light client.
Darwinia has implemented the Ethereum light client on Darwinia Chain based on the Altair upgrade, which only needs to synchronize one block header every 27 hours. This should be the first on-chain light client implementation for Ethereum after its transition to PoS.
Fees and Incentives
Cross-chain initiators (which could be users or Dapps) need to pay fees when sending cross-chain messages, which will include three parts:
Gas fees for executing transactions on the source chain.
Fees paid to the Relayer.
The specific pricing is determined by the market, and numerous Relayers can engage in price competition. It is important to note that Relayers need to pay gas fees on the target chain, and this cost will be reflected in their pricing, meaning cross-chain initiators do not need to pay gas fees on the target chain separately.
- Fees paid to the Treasure.
A certain proportion of the cross-chain fees paid by cross-chain initiators will enter the Darwinia Treasure. The Treasure will use some of its funds to subsidize the Head Relayer.
zkBridge
At the time of writing this article, zkBridge is a recently launched project that has completed only a small amount of development. However, it is one of the few projects to date that applies zero-knowledge proof technology to the construction of cross-chain bridges. zkBridge uses ZK-SNARK proofs for the scalability of light nodes.
Currently, zkBridge has implemented an instance of a Cosmos Client on Ethereum using Solidity, which has been tested to generate a ZK-SNARK proof for a Cosmos Zone block header in 2 minutes, and then verify it on Ethereum with only 220k gas. In comparison, without ZK-SNARK proof, the cost would be 64 million gas.
The main innovations of zkBridge are:
deVirgo: A distributed method for generating ZK-SNARK proofs called deVirgo, which significantly reduces the time required to generate ZK-SNARK proofs off-chain by distributing the computational workload to more devices.
Recursive proofs: To reduce on-chain costs, zkBridge uses a recursive proof scheme (proof of proofs), compressing the size of ZK-SNARK proofs to around 131 bytes through two rounds of recursion.
Batch processing: zkBridge has implemented a block header update contract that takes block height as input and returns the corresponding block header. However, zkBridge does not call the update contract for every new block; instead, the prover can first collect N block headers and generate a single proof. The value of N can be set, and the larger N is, the longer the user waits, but the lower the system's operating cost.
It must be said that zero-knowledge proof technology is a miraculous technology. The main bottleneck limiting its adoption is the high technical threshold and development difficulty, but in the development of zero-knowledge proof technology, the rewards are always commensurate with the efforts.
MAP Protocol
MAP Protocol is a general heterogeneous cross-chain protocol based on light clients and relay chains.
Unlike many of the aforementioned projects, MAP chooses to establish a relay chain called MAP Chain as a transit station for cross-chain message passing. Connecting chains do not need to establish direct connections; instead, they all connect to MAP Chain, meaning each connecting chain only needs to deploy the light node contract of MAP Chain, while MAP Chain deploys the light node contracts of each connecting chain.
The architecture of MAP Protocol is divided into three layers: the protocol layer, the cross-chain service layer, and the application layer. Among them:
Protocol layer: We can understand this as the trust layer, including MAP Chain and the light client programs of each connecting chain;
Cross-chain service layer: Provides some common modules for the application layer, allowing applications to avoid "reinventing the wheel." For example, a common Vault module can lock funds for some asset bridge applications, although applications can also choose to build their own Vault instead of using this module.
Application layer: Refers to applications that use MAP Protocol as a medium for cross-chain message transmission.
In addition, MAP Protocol includes three off-chain roles:
Maintainer: Responsible for updating the block headers of each light node contract and can earn $MAP inflation rewards.
Messenger: Responsible for transmitting cross-chain messages and can earn cross-chain fees paid by users, but needs to advance the gas fees on the target chain and relay chain.
MAP Chain validators: Responsible for the consensus process of MAP Chain, requiring staking of $MAP, and can earn $MAP inflation rewards. MAP Chain currently uses the IBFT-PoS consensus mechanism.
Cross-Chain Message Flow
The MAP Protocol documentation does not elaborate much on the message transmission mechanism. From the current snippets, the message flow should be as follows: When an application on the source chain initiates a cross-chain request, the cross-chain message M is included in a transaction T1, which is sent by the messenger to the relay chain. After the relay chain receives transaction T1, it includes transaction T1 and its accompanying message M in transaction T2, which the messenger relays to the target chain. After the target chain receives T2, it verifies it and sends it to the target application.
Although MAP Protocol is a project initiated in 2019, it currently only supports Ethereum, BSC, and Polygon, which raises questions about the "general" label. In fact, since light node contracts cannot be reused when expanding across different chains, cross-chain bridges based on light node contracts find it challenging to achieve "universality."
Cosmos IBC
IBC is a well-designed homogeneous cross-chain protocol and an essential component of the Cosmos cross-chain network.
The Cosmos cross-chain network mainly consists of Hubs and Zones, with bridges established between Zones and Hubs via the IBC (InterBlockChain) protocol, and bridges between Zones established through Hubs as intermediaries. The Cosmos cross-chain network also includes Peg Zones and heterogeneous bridging components, which do not fall under the IBC category.
Hubs and Zones are open for admission, and any blockchain built on the Cosmos SDK can become a Hub or a Zone and register as a connecting chain to any Hub. Unlike Polkadot's relay chain, the Hub in Cosmos is not unique.
Light Client
Each Zone registering with a Hub must deploy an IBC module, which includes the Hub's light client contract. The IBC module in the Hub will also integrate the light client contracts of each connecting Zone.
The Tendermint consensus mechanism does not have the concept of epochs, and each block may result in changes to the validators. However, the light client contracts in IBC include a concept called TrustPeriod, which is a parameter that needs to be set when initializing the light client. Within a TrustPeriod, small changes to the validator set are allowed; individual validators may join or leave, but there will not be significant changes.
Such small changes are acceptable because each signature will almost never have exactly 2/3 of the voting weight signed; there will always be some overflow. Even if individual validators join or leave, the light client can check the block header against the validator set before the change, and it is highly likely that it will still observe that 2/3 of the voting weight has signed.
Therefore, the light client contracts in IBC only need to update the information of the validator set once per TrustPeriod, meaning that only one block header needs to be synchronized for each TrustPeriod.
The work of synchronizing block headers will be executed by Relayers.
Core Concepts and Principles
IBC constructs three abstract concepts: Connection, Channel, and Packet.
- Connection
A Connection refers to the link between two Zones. Establishing a Connection can be understood as pairing the two Zones, at which point both Zones request the latest block headers of each other's light clients from the Hub. The establishment of a Connection follows a three-way handshake principle (the handshake communication is triggered by Relayers). Once the handshake is complete, the Connection is opened.
At this point, a Channel can be established on top of the Connection. The Channel Connection connects two Zones, while the Channel connects a pair of applications on the two Zones (this pair of applications may come from the same application or different applications). The two applications establish a Channel through a three-way handshake principle (the handshake communication is triggered by Relayers). Once the Channel is established, these two applications can send Packets to each other.
- Channel
The Channel is the core concept of IBC, allowing applications to establish direct connections. As an abstract concept, a Channel does not exist as a physical entity. For the receiving application, the Channel defines the sender; knowing from which Channel the message is sent indicates which application from which Zone it comes. For the sending application, the Channel defines the recipient; to send a message to a specific application, the message is placed in the corresponding Channel.
The Channel also defines the message sequence; messages within the same Channel follow a queue and have a strict temporal relationship, with earlier messages always arriving first. There is no temporal relationship between messages in different Channels.
It is important to note that an application should ideally use a single Channel consistently. For example, if an asset bridge application uses multiple Channels to create mapped assets on the target chain, multiple Channels will generate different mapped assets, leading to unnecessary complications.
- Packet
A Packet is a standardized data structure that defines the format of cross-chain messages allowed to be transmitted within a Channel. The transmission of a Packet involves three steps:
sendPacket: The sending application creates a Packet with sequence number N on the source chain and adds it to the sending queue;
recvPacket: The Relayer relays the Packet to the target chain, where it is stored by the receiving application.
acknowledgePacket: The Relayer returns proof that the receiving application has stored the Packet back to the source chain, which deletes the Packet with sequence number N from the sending queue.
If the receiving contract does not store the Packet for an extended period, the Relayer returns a timeout message. It is important to note that Cosmos IBC differs from MAP Protocol in that the Packet is sent directly from the source Zone to the target Zone without needing to transit through the Hub. This is because the target Zone can directly query the block header of the source Zone from the Hub and then perform verification on the Packet. This means that the Hub only needs to relay block headers.
Specifically, the Hub has the light node of the source Zone, which can verify the block header of the source Zone, and the target Zone has the light node of the Hub, which can verify the block header of the Hub. When the target Zone needs a block header SourceZoneBlockHead{i} from the source Zone, it can ask the Relayer to fetch it from the Hub. The light node on the target Zone verifies HubBlockHead{i} and then uses HubBlockHead{i} to verify SourceZoneBlockHead{i}, allowing it to verify the Packet from the source Zone.
Fees and Incentives
IBC includes a configurable fee module, allowing the initiator of a Connection to customize the charging standards and payments to Relayers. However, based on our observations, the project parties of Zones and application project parties often have the motivation to run their own Relayers.
Conclusion
Currently, in the design of light client solutions, PoW light clients are primarily SPV light clients that synchronize all block headers of the source chain one by one, while PoS light clients mostly adopt a jump synchronization scheme, synchronizing only the block headers where the validator set changes. As long as the light client is initialized correctly and keeps track of changes in the validator set, it can master the latest validator set.
In practice, the construction of light clients also encounters issues such as high verification costs for block headers and incompatible signature schemes. Different projects adopt various methods to address these challenges, including optimistic verification (Rainbow Bridge), validator set sampling (Snowfork), and off-chain generation of zero-knowledge proofs (zkBridge). Additionally, public chains are motivated to upgrade and adapt themselves to better support cross-chain functionality, as seen in Ethereum's Altair upgrade and Polkadot's development of the BEEFY module.
In summary, light client technology is still undergoing intense evolution, and as more research and exploration take place, the difficulty of constructing light clients will gradually decrease.
