Relayer

Relayers are responsible for submitting cross-chain communication packages between two blockchains. Due to the heterogeneous parallel chain structure, two different types of Relayer are created.

FSC Repeaters Repeaters used for other link-to-FSC communications are called "FSC repeaters", or simply "repeaters". A Relayer is an independent process that can be run by anyone anywhere, except that the Relayer must register with the FSC and deposit a certain number of refundable tokens. FSC only accepts relay requests from registered relays.

The packages they relay will be verified by on-chain light clients on FSC. A successful relay needs to pass sufficient verification and pay gas fees on FSC, so there should be incentive rewards to encourage the community to run Relayer.

Oracle Relay

The relays used by FSC to communicate with other chains use the “Oracle” model, the so-called “Oracle Relayers*”. Every validator (and only validators in the validator set) must run the Oracle relay. Each Oracle Relayer observes changes in the blockchain state. Once it captures the cross-chain communication packet, it submits the request for voting. Cross-chain actions will be performed after an Oracle Relayer with 2/3 of the voting power of the other chain's validators votes in favor of the change.

Oracle Replayers should wait for enough blocks to confirm finality on FSC before submitting and voting cross-chain communication packages to other chains.

Cross-chain fees will be distributed to other chain validators along with normal other chain block rewards.

This oracle type of relay relies on all validators to be supported. Since all votes for cross-chain communication packages are recorded on the blockchain, it is not difficult to have a measurement system to evaluate the performance of Oracle Relayers. Worst performers may get their rewards back via another slashing logic introduced in the future.

FSC will provide the underlying API of the blockchain for third-party projects to realize the docking of application scenarios and the overlay of digital assets, thereby solving relevant practical problems in the industry. In order to realize this vision, FSC has made corresponding layouts in the underlying design and top-level applications.

Fast transaction verification in seconds

By optimizing key aspects such as signature algorithms, ledger structures, data operations, serialization, consensus mechanisms, and message diffusion, FSC will achieve fast transaction verification in seconds. Meet the user experience of most financial scenarios in blockchain applications.

Storage of massive financial data

The double-entry accounting model of the blockchain has been continuously used in the system, accumulating a large amount of data, resulting in a decrease in operating speed. FSC will implement separate storage and sub-table storage mechanisms to achieve mass storage of data.

Improved transaction throughput

The essence of blockchain is a distributed shared accounting technology, and its distributed characteristics are mainly reflected in distributed consistency rather than distributed concurrent processing. In order to ensure data consistency and prevent the Byzantine Generals problem, some specific links can only be executed serially and cannot be executed in parallel. Through long-term testing and optimization practices, FSC’s processing performance will further significantly improve transaction throughput.

Node data fast synchronization

FSC will develop a mirroring mechanism that can regularly mirror the local ledger to implement a convenient rollback mechanism. Under a unified consensus, the mirroring label can be specified for rollback. At the same time, it shortens the cycle for new nodes to join the operation. They only need to synchronize the latest image and a small number of recent transaction collections to integrate into the network and participate in consensus verification.

Data permission control strategy

FSC provides two types of permission control strategies for writing and reading data information. Data information writing permissions, multiple users can be set up under the same account, and corresponding permissions are set for different operations to meet the usage scenarios of multi-party signature control. Data information reading permission, users can grant and revoke data operation permissions to single users or user groups, and user groups can be flexibly configured by users. The data includes user account information, transaction information, etc., and the granularity can be refined to each attribute field of the transaction or account.

Diverse expansion development

FSC's blockchain structure can meet the needs of different business fields and improve the system's scalability and maintenance efficiency. It can be used to mark assets and asset transfers, and can also provide multi-dimensional event records that cannot be tampered with. It can also be used for traceability to track the circulation process of financial assets.

Multiple privacy protections

In order to facilitate users to use FSC products and services, in addition to the traditional client generation and saving mechanism, FSC also provides two solutions: network hosting access and private key hardware access (U-key). Network hosting access means mapping usernames and passwords into private keys through a specific algorithm and storing them on the server. The private keys stored on the server side are all encrypted data, and the private keys can only be decrypted on the user side; the hardware private keys are to meet the needs of the financial industry.

At the same time, it provides multiple privacy protection functions. First of all, the bottom layer of FSC provides homomorphic encryption. All user data is encrypted and stored and is only visible to the user. Secondly, encryption middleware services are provided, and users can choose according to business needs. Finally, the upper-layer application can encrypt the data during entry, and FSC is responsible for writing and reading the encrypted data generated by the user.

Visual operation and maintenance support

FSC will provide the visualization tools required for operation and maintenance management. System monitoring services deployed on FSC nodes: support data information monitoring at the business (blocks, transactions, contracts, consensus, etc.), network (networking, delay, throughput, etc.), and system levels (CPU, memory, disk, etc.) . At the same time, it provides a complete log, alarm and notification mechanism to facilitate the maintenance of financial commercial systems.

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.

Hard forks, specifications and dispute resolution

Different distributed ledger systems often differ in their underlying political philosophies and technology choices. The Ethereum project originally promised to be an "unstoppable application" that can realize "code is law". After an important smart contract was hacked, a debate arose about whether what happened could be described as a hack due to the lack of non-code instructions on what the program was intended to do. The differences eventually led to divisions within the community.

Because FSC contracts are simple zip files, it can easily contain PDF or other format documents describing the actual intent of the contract. There is no requirement to use this mechanism or for these documents to be legally binding. Nonetheless, in the case of financial applications, if disagreements arise, the legal meaning of the contract that contains them is more important than the software implementation that contains them.

It is technically possible to write a non-upgradeable contract. If such a contract governs an asset that exists only on the ledger, such as a cryptocurrency, then this can provide an approximation of "code as law." We leave the discussion of the wisdom contained in this concept to political scientists and reddit. Platform logs in FSC do not have a direct equivalent to a "hard fork" of the blockchain, so abandon the problem transaction chain or fraudulent transaction chain. The only way to do this is to agree outside the band on discarding an entire subgraph of transactions. Since there is no global visibility, this consensus need not include all participants on the network: only those who may have received and processed the relevant transactions. Another consequence of the lack of global visibility is that there is no single point of recording exactly who saw which transaction. Determining the set of entities that must agree to discard a subgraph means correlating the activity logs of nodes.

FSC nodes record sufficient information in logs to ensure that such correlations can be achieved. The platform defines a stream available to anyone to assist in this process. A tool is also provided that can generate "investigation requests" and send them to a seed node. The flow notifies the node administrator that a decision is required, and sufficient information is passed to the node to attempt to persuade the administrator to participate (such as a signed court order). If the administrator accepts the request via the node browser, subsequent jumps in the transaction chain are returned. This tool semi-automatically crawls the network in such a way that it finds all actors that would be affected by the proposed rollback operation. The platform does not participate in determining what types of transaction rollbacks are legitimate, and provides only minimal support for implementing rollback operations beyond locating the parties that must agree.

There are at least two strategies for modifying the ledger once the involved actors have been identified. One is to extend the transaction chain using transactions that simply correct the database so that it matches the expected reality. In order to make this approach possible, smart contracts must be written so that they can be modified arbitrarily outside of normal business logic when the submitted signatures reach a sufficient threshold. This strategy is simple and makes the most sense when the state contains a small number of parties, none of whom have any incentive to leave harmful information on the ledger.

An asset state resulting from theft or fraud will involve participants who will resist all attempts to patch it in the above manner, because they can derive real-world benefits from the time between when the ledger is corrupted and before it is restored to its actual state. For this situation, a more complex method needs to be used, that is, all participants except the uncooperative participants agree to mark the relevant state as no longer consumed or has been spent. This is essentially a limited form of database rollback.

Authority Proof Of Staked based on equity (Authority Proof Of Staked)

Although Proof of Work (PoW) has proven to be a practical solution for achieving decentralized networks, it is not environmentally friendly and requires a large number of participants to maintain network security.

Ethereum and some other networks, such as MATIC Bor, TOMOChain, GoChain, and xDAI, use Proof of Authority (PoA) or its variants in different scenarios, including testnets and mainnets. PoA provides defense against 51% attacks and more effectively prevents some Byzantine nodes from doing evil. Choosing PoA as the underlying consensus is one of the ideal options.

At the same time, the PoA protocol has been criticized for being less decentralized than PoW because validators, the nodes who take turns generating blocks, have tremendous power and are prone to corruption and security attacks. Other blockchains, such as EOS, have introduced different types of Delegated Proof of Stake (DPoS), allowing token holders to vote for validator nodes. It makes the network more decentralized and facilitates community management.

Inspired by the above, FSC combines DPoS and PoA to reach consensus. The solution adopted is:

1. Blocks are generated by a limited number of validators

2. Validators take turns generating blocks in a PoA manner, similar to Ethereum’s Clique consensus engine

3. The set of validators is selected and eliminated based on on-chain governance of equity pledges

Validator node quorum

During the genesis block phase of network launch, a number of trusted nodes will operate as the initial set of validators. After the block production begins, anyone can participate as a candidate in the election of validators. The maximum tolerance for validators in the FON smart chain's re-creation block is 99 validators. When there are >99 validators, they will not be able to join as a new validator. certifier. The stake pledge status determines that the top 21 nodes with the most stake pledges become the next set of validators. Such elections and eliminations occur every 3 hours.

FON is the token for FSC equity pledge.

To maintain compatibility with the Ethereum consensus protocol, including upcoming upgrades, FSC has chosen independent staking management. In the FSC stake staking module. It will accept FSC stakes from FON holders and calculate the set of nodes with the largest stakes. Every 3 hours, the ranking of block producers is refreshed and FSC is notified to update its validator set.

Before generating a new block, existing FSC validators regularly check whether there is a "ValidatorSetUpdate" message forwarded to FSC. If so, they will update the validator set after a certain height (i.e. a predefined block interval). For example, if FSC generates a block every 5 seconds and the check period is 240 blocks, then the current validator set will check and update the validator set for the next period in 1200 seconds (20 minutes).

safety and finality

Considering that more than half of the ½N+1 validators are honest and trustworthy, PoA-based networks can generally work safely and properly. However, in some cases, Byzantine validators may still manage to attack the network, such as through a "clone attack." In order to ensure FSC security, we encourage FSC users to wait until the received block is confirmed by more than ⅔N+1 different validators, and can tolerate less than 1/3*N Byzantine validators.

For 21 validators, if the block time is 5 seconds, then ⅔* N + 1 different validators will take (2/3*21 + 1)5 =75 seconds to confirm. Any significant application of FSC will likely have to wait ⅔N + 1 to ensure a relatively safe end result.

Consensus and number of validators

Based on the above design principles, FSC’s consensus protocol is to achieve the following goals:

1. The block time should be shorter than Ethereum time, such as 5 seconds or even less.

2. Only need to wait a limited amount of time for the transaction to be finalized, such as about 1 minute or less.

3. There is no inflation. The revenue of the blockchain comes from handling fees, which are paid in the form of FON.

4. Be as compatible with Ethereum as possible.

income

All FSC validators in the current validator set will receive income from fees paid in FON. Since FON is not an inflationary token, it will not generate mining revenue like the Bitcoin and Ethereum networks. Handling fees are the main revenue for validators. Since FON is also a utility token for other applications, delegators and validators will still receive other benefits of holding FON. Validators’ income is obtained from the fees collected from transactions in each block. Validators receive 85% of the total verification block revenue, and the remaining 15% will enter the official treasury to reward FON ecological users. Each validator will take turns generating blocks with equal probability (if they remain 100% online), so in the long run, all stable validators are likely to receive similarly sized gains.

instability

The availability of FSC relies on each validator in the validator set in the APoS consensus to be able to generate blocks in time when it is their turn to generate blocks. A validator may miss the opportunity to produce a block for a number of reasons, especially due to hardware, software, configuration or network issues. This unstable operation will harm the performance of the network and bring more uncertainty to the system. FSC has an internal contract that is responsible for recording the blocks missed by each validator. Once this indicator exceeds the predefined threshold, the validator will no longer participate in block production in the current 3 hours, and will no longer receive the allocated rewards, but will be shared by other better validators. In this way, poorly functioning validators will gradually exit.