Cross-chain mechanism

FSC uses a proof-of-stake consensus protocol that has a chance of forking and requiring more blocks to be confirmed. A block is signed by only one validator, so it is difficult to rely on one block to verify data from FSC.

In order to fully utilize the validator quorum of other chains, an idea similar to many [Bridge] or Oracle blockchains is adopted:

Cross-chain communication requests from FSC will be submitted and executed as transactions on the FON smart chain. The execution of transactions emits Events, which can be observed and packaged in some "Oracle*" to other chains. This type of "Oracle" package does not have Block Headers, Hash and Merkle Proof, but directly contains the cross-chain information of the action, such as the sender, receiver and transfer amount.

To ensure the security of the oracle, validators from other chains will form another quorum "Oracle Relayers". Each validator of other chains should run a dedicated process as an Oracle Relayer. These Oracle Relayers will use the same validator key to submit cross-chain communication packages (such as Oracles) to other chains and vote. Any package signed by more than ⅔ * N+1 Oracle Relayers voting power is as secure as any block signed by ⅔ * N+1 equal quorum of validator voting power.

By using the same validator quorum, it keeps the light client code on other chains and keeps the continuous block updates on other chains. This type of Oracle also has an Oracle ID and type to ensure ordering and correct error handling.

Timeouts and error handling

There are scenarios where cross-chain communication fails. For example, the relay package failed to execute on FSC due to some coding errors in the contract. Timeout and error handling logic are used in such scenarios. Both networks should repair themselves for identifiable user and system errors or any expected anomalies. For example, when the transfer from other chains to FSC fails, FSC will send a failure event, and Oracle Relayers will perform refunds from other chains; when the transfer from FSC to other chains fails, the other chains will send refund packages to Relayer for relay to unlock. funds. However, unexpected errors or exceptions may still occur during any step of cross-chain communication. In this case, Relayers and Oracle Relayers will find that the corresponding cross-chain channel is stuck in a specific sequence. After the timeout period, repeaters and Oracle repeaters can request "SkipSequence" transactions and the stuck sequence will be marked as "unexecutable". A corresponding alert will be raised and the community must discuss how to handle the situation, such as giving back via the validator's sponsor, or clearing funds during the next network upgrade.

Cross-chain user experience

Ideally, users would want to use two parachains as if they were one chain. It would require adding more aggregated transaction types to cross-chain communication to achieve this, which would add significant complexity, tight coupling, and maintenance burden. Here other chains and FSC only implement the basic operations of enabling value flow on initial startup, leaving most of the user experience work to the client UI, such as the wallet. For example, a great wallet might allow users to sell tokens directly from FSC onto other chains’ DEX order books in a secure manner.

Cross-chain contract events

Cross-chain Contract Events (CCCE) are designed to allow smart contracts to trigger cross-chain transactions directly through contract code. This is possible based on:

■ Can provide standard system contracts to serve operations that can be called by general smart contracts;

■ Standard events can be emitted by standard contracts;

■ Oracle Relayers can capture standard events and trigger corresponding cross-chain operations;

■ Dedicated, code-managed addresses (accounts) can be created on other chains and accessed by contracts on FSC, here named "Contract Address on Other Chains" (CAoB).

Several standard operations are implemented:

■ FSC to other chain transfer: This is implemented in the same way as normal FSC to other chain transfer and is only triggered through standard contracts. Funds can be transferred to any address on other chains, including the corresponding CAoB of the contract originating the transfer.

■ Transfer on other chains: This is a special cross-chain transfer, while the real transfer is from CAoB to any other address (even another CAoB).

■ Transfers from other chains to FSC: This is achieved through two cross-chain communications. The first time it is triggered by the FSC contract and propagated to other chains, then on the second pass, the other chains will start the normal cross-chain transfer from other chains to FSC, from CAoB to the contract address on FSC. It is important to note that the FSC contract only increments the balance on any transfer in the second pass, and error handling in the second pass is the same as normal other chain-to-FSC transfers.

■ IOC (Immediate-Or-Cancel) Trade Out: The main goal of transferring assets to other chains is to trade. This event will instruct a certain amount of the asset in the CAoB to be traded into another asset if possible, and all results of the transaction, i.e. the source token left and the target token of the transaction, will be transferred back to the FSC. Other chains will handle such relay events by sending an "immediate or cancel" (i.e. IOC order) to the trading pair, and the results will be relayed back to FSC once the next match is completed.

■ Auction Trade Out: This event will instruct other chains to send auction orders to trade a certain amount of assets in CAoB for another asset as much as possible, and transfer all results back to the FSC auction at the end. FSC will launch auction function.

Trade Out has some details:

■ Both can have limit prices for transactions (absolute or relative);

■ The final result will be written as a cross-chain package and passed back to FSC;

■ Cross-chain communication fees may be charged for assets transferred back to FSC;

■ The FSC contract maintains a mirror of the balance and outstanding orders on CAoB. No matter what error occurs during Trade Out, the final state is propagated back to the original contract and its internal state is cleared.

With the above features, it simply adds cross-chain transfer and exchange functions with high liquidity to all smart contracts on FSC. It will greatly increase the application scenarios on smart contracts and dApps, realizing 1 chain + 1 chain > 2 chains.