Cross-Chain Communication Protocol (CCCP)
Introduction
Bifrost's Cross-Chain Communication Protocol (CCCP) realizes cross-chain communication through interactions between socket contracts and relayers. The CCCP enables users on one blockchain to utilize DApps provided on other blockchains.
A socket contract is a system contract installed on the Bifrost Network and all other external chains such as Ethereum. A socket contract emits a CCC-event when triggered by a CCC-request from another socket contract, and this CCC-event is delivered to another socket contract by a relayer. A user’s request goes around different socket contracts in the form of a CCC-event and terminates when all the necessary logic has been executed.
In particular, multiple relayers deliver the socket-events to ensure the protocol’s continuity even if a certain number of relayers fail or are compromised, and the “timeout rollback” function is in place to prevent the users’ assets from being locked in socket contracts even if the entire relayer group fails. Additionally, the total operational cost of the relayer group is significantly cut down by minimizing the number of transactions delivered to other blockchains that have relatively high costs.
Glossary
CCC Protocol (CCCP): Cross-Chain Communication Protocol
VS Protocol (VSP): Validator Synchronization Protocol
Validator: the consensus validation node of the Bifrost Network
Relayer: the CCC protocol-worker node of the Bifrost Network
CCC-request: is requested by a user which calls an f(x) installed on other blockchains
CCC-event: a CCCP message containing the CCC-request details (socket contract’s event)
External chain: any blockchain other than the Bifrost Network (e.g. Ethereum, BNB chain, Polygon, etc.)
f(x): a pre-defined function to be executed in other blockchains. (smart contract)
Positive status: the CCC-status indicating “success” (REQUESTED, EXECUTED, ACCEPTED, COMMITTED)
Negative status: the CCC-status indicating “failure”; the positive and negative statuses have been accordingly paired (FAILED, REVERTED, REJECTED, ROLLBACKED)
Components
A user sends a CCC-request to the socket contract, which calls a f(x) under another blockchain. As a f(x) requires cryptocurrency payment, the socket contract collects the user’s cryptocurrency.
Relayers deliver the following data to the socket contract:
Latest validator (relayer) list: relayers deliver the latest validator list to all external chains; all blockchains utilize the latest validator list for access control
Off-chain data: off-chain data such as certain assets’ prices or Bitcoin blockchain’s block hash are delivered to the Socket contract of the Bifrost Network; the oracle manager contract receives this data from the socket contract and provides oracle services
CCC-events: a relayer detects CCC-events from all supported blockchain networks and relays the detected event to its corresponding socket contract; the corresponding socket contract information can be derived from the CCC-event
System Contracts - The Bifrost Network supports the three system contracts:
The socket contract generates CCC-events which are to be treated by other socket contracts, or receives CCC-events emitted by other socket contracts and treats them. In particular, it executes request-indicated actions (e.g. mint, lending, leveraged investment) according to the protocol specifications.
The Built-in DeFi Suite - The DeFi Suite functions are abstracted and expressed as f(x).
The oracle manager contract collects the designated off-chain data and provides on-chain oracle services.
Protocol Design
The following design factors are applied to the CCCP to overcome the limitations of the smart contracts' execution environment.
Design Factors
As smart contracts do not provide sufficient data storage space, we only store the data’s hash instead of the entire data in smart contracts. If we need to reuse the data, we re-send it. We use this strategy because comparing the hash value is cheaper than initially storing the data.
A transaction may fail due to its atomic property. In this case, another transaction indicating this “failure” must be re-transmitted to leave its failed status on the smart contract.
Smart contracts do not provide built-in functions such as sorting array or mapping keys/values return, and implementing such functions is inefficient transaction fee-wise. Thus, the transaction sender may have to send an already sorted array data so that the smart contract does not have to do the sorting.
We minimize the number of transactions directed to external chains which impose relatively high fees. When a relayer group relays a CCC-event to an external chain, the CCC-event is first submitted with a signature to the Bifrost Network. Then, the primary relayer aggregates all signatures and delivers them to the external chain at once.
VSP is the sub-protocol of CCCP, which synchronizes the latest validator list of the Bifrost Network to all external chains. The validator list must stay up to date as the validators of the network can change periodically and socket contracts use information about validators for access control.
Assumptions
Relayers monitor every CCC-event.
Relayers possess sufficient amounts of native coins (e.g. BFC, ETH, BNB) for transaction fees.
Relayers are penalized for request forgeries. (Relayers do not harm the protocol for minor gains.)
The majority of relayers faithfully execute the protocol. (The number of relayers in shut down status or conducting request forgery attacks is always less than the majority.)
The preceding CCC-event accumulation will not cause the failure of the following CCC-event production.
Relayers process all events generated during their delegated time, even if they are un-delegated for any reason.
Relayers process all requests that occur during their term.
The Bifrost Network relays the next validator set.
Otherwise, relayers are penalized.
Inbound CCCP
The inbound protocol indicates the delivery method of the CCC-request from an external chain to the Bifrost Network. The figure below represents the CCC-event flow of the inbound protocol. The “relay type” marked for each relay is further explained in the section "Two-Types of Relay Vote".
Each user request delivered to the socket contract of an external chain sequentially goes through “REQUESTED”, “EXECUTED”, and “ACCEPTED” and finally ends in “COMMITTED” status. However, if the Phase 1 f(x) fails to execute, a request goes through “REQUESTED”, “REVERTED”, and “REJECTED” and ends in “ROLLBACKED” status. Requests completed as “ROLLBACKED” return the collected tokens during the user’s transaction.
Outbound CCCP
The outbound protocol indicates the delivery method of the user request from the Bifrost Network to an external chain. The figure below represents the CCC-event flow of the outbound protocol. The “relay type” marked for each relay is further explained in the section "Two-Types of Relay Vote".
Each user request delivered to the socket contract of an external chain sequentially goes through “REQUESTED”, “EXECUTED”, “ACCEPTED” and finally ends in “COMMITTED” status. However, if the Phase2 f(x) fails to execute, a request goes through “REQUESTED”, “REVERTED”, “REJECTED” and ends in “ROLLBACKED” status. Requests completed as “ROLLBACKED” return the collected tokens during the user’s transaction.'
Validator Synchronization Protocol
VSP delivers the updated information on the Bifrost Network’s validator(=relayer) set to all socket contracts on all supported external chains. Socket contracts update their access permission list with the delivered validator set.
Two Types of Relay Vote
A CCC-request is delivered by several relayers for a low risk of data falsification. On the other hand, if a valid CCC-event is concurrently delivered to two different blockchains, user assets can increase or decrease on both sides. For example, when there are five relayers, the quorum is three. There can be a case where two relayers succeed and three fail in transmitting a CCC-event transaction that mints in Ethereum. In such a case, the “failed relayers” transmit a CCC-event transaction to the Bifrost Network, and the user is refunded in Ethereum. However, if one of the “failed relayers” re-sends the mint transaction and succeeds, the user’s asset in the Bifrost Network increases and results in “double payment.” This example shows how one malicious relayer can cause protocol failure.
Situations like the above can occur as the socket contract did not clearly finalize the CCC-event process result before proceeding to the next phase. Thus, a CCC-request must be finalized as one status in each phase before emitting an event. The relayer must proceed to the next phase only when a CCC-event of the next status is detected.
Each phase of the protocol delivers relay votes to the socket contract through one of the type methods described below. Moreover, for phases executing f(x) as a result of the relay vote, the “Self Transition Rule” additionally applies.
Self Transition Rule (if fails)
For phases in which f(x) is executed, such as Inbound Phase1 or Outbound Phase2, the transaction may fail due to the logic of f(x) even if the relayers deliver valid CCC-events. However, as a failed transaction due to its atomic property cannot affect the socket contract, an “execution failure” CCC-event cannot be emitted. Thus, relayers set the CCC-event status to negative and transfer it to the socket contract. When the socket contract receives negative CCC-events from a majority of relayers, it emits the “execution failure” CCC-event and forces the process onto the next phase. (A negative status can never be restored to positive status.)
Furthermore, due to the transaction’s asynchronous property, we cannot know when the next status CCC-event is going to be emitted. There can be a situation where two out of five relayers emit a positive CCC-event, and the other two emit a negative CCC-event. If the remaining relayer does not act, this CCC-event can never be processed. This example shows how the protocol can fail due to one relayer.
Thus, relayers that have voted for positive status verify if the request has been finalized as a positive status after t seconds. If not finalized, the relayers change the original CCC-event to negative status and resend it. As a result, the CCC-event will always be processed in t seconds. (In the example case above, the status would ultimately be settled as negative.)
Figure Description
Each relayer delivers the event of the detected positive status to the next socket contract.
transaction success → set timer
transaction failure → change event to negative status and resend it
timeout → change event to negative status and resend it
For each status, the socket contract executes f(x) at the n-th relay vote transaction that reaches the majority and emits the next CCC-event.
Type 1: General Relay
In the case of a phase with no f(x) in its resulting logic, each relayer simply delivers the CCC-event through a transaction.
Figure Description
All relayers deliver the detected event to the next socket contract.
The socket contract emits the next CCC-event at the n-th relay vote transaction that reaches the majority.
Type 1-1: General Relay with signature
The relayer additionally attaches its signature to execute “Type 1: General Relay”. The socket contract saves the attached signatures, which can later be inquired en bloc by the socket contract.
Type 2: Aggregated Relay
Instead of having all the relayers deliver the CCC-event to an external chain with a relatively high fee, one primary relayer aggregates all relayers’ signatures and emits a CCC-event. (Once the primary relayer is designated, other relayers are automatically considered secondary relayers.)
To ensure that the failure of the primary relayer does not lead to the failure of the protocol, secondary relayers verify whether or not the CCC-event has been successfully emitted after t seconds. If not emitted, all secondary relayers take on the role of the primary relayer and emit the CCC-event.
Figure Description
Calculate the primary relayer index: (the height of the block containing the event) % (the total number of validators). The relayer with the calculated primary relayer index is designated as the primary relayer. (The rest become secondary relayers.)
Primary relayer
Inquires the socket contract for the relayers’ signature values submitted in the preceding phase.
Attaches the majority number of signatures and delivers it to the next socket contract.
Secondary relayers
If the primary relayer’s successful event delivery cannot be verified after
tseconds, execute the primary relayer process instead.
The socket contract emits the next CCC-event upon verifying the majority of the signatures received.
Applications
CCCP allows external chain users to use Bifrost Network DApp services. For example, let us say that f(x) is “Lending::Deposit” installed in the Bifrost Network. In this case, an Ethereum user can simply deposit tokens to the Ethereum socket contract, and this action will automatically deposit tokens to the lending service on the Bifrost Network. To give another example, let us say that f(x) is “Swap” in the Bifrost Network. In this case, a user can acquire some Bifrost Network’s token B by depositing some Ethereum’s token A through the inbound protocol, and then withdraw Avalanche’s token B through the outbound protocol. This implements a cross-chain swap.
Ultimately, the CCCP of the Bifrost Network allows users to enjoy DeFi services with relatively low fees and fast speed, and easily transfer assets between chains.
Last updated
