Open federated gateway protocol (OFGP) whitepaper en

Dshadowzh edited this page Nov 2, 2018 · 12 revisions

Open federated gateway protocol (OFGP) whitepaper

Open federated gateway protocol for pegged sidechain

1 Introduction

We provide a set of common gateway protocol (OFGP - Open Federated Gateway Protocol) between the main chain and the side chain. The protocol consensus part goes through the Braft protocol to be organized efficiently through a consortium gateway. Through this asset on the main chain can be safely transferred to the side chain for higher speed transactions or for more diversify transactions. Assets can be pegged to each other in real time through the gateway.

1.1 Background

At the time of writing this article, was the time of the bursting of the ICO bubble. From experiencing the rise of bitcoin and altcoins and the FOMO to the capitulation of all crypto asset in 2018. People began to reflect on the true value of the economics behind the ICO. When the industry calms down from a single whitepaper full of promises and return to the value of the project itself. Everyone is paying more and more attention to the utility value of the project, from issuing tokens->operating the project->profit->the economy behind the process of burning tokens, token economy will all gradually be recognizes as the mainstream mode.

1.2 Sidechain Technology

People often talks about an impossible triangle in the blockchain field, which is Scalability, Decentralization, and Security, out of these three only two can simultaneously exist. While it is true Satoshi’s blockchain cannot compete on the scalability and performance compared with emerging blockchain technology, but its value is the most widely recognized and has withstood the longest security test. Under the road to expanding cryptocurrency functions and improving performance, people began to develop and experiment with new blockchains using sandboxes, altcoins, 2-layer protocols, and soft/hard forks.

In 2014, Adam Back et al. proposed a plan that is sidechain. The implementation of the sidechain will only be the transfer of coins, not the creation of new coins, because in many scenarios it is not necessary to create an independent currency for them. With sidechains, users can quickly experiment with these experimental changes safely and permissionless. This promotes the adoption of side chains. Compared with the use of another alternative coin, when using sidechains, participants will have less risk and have a stronger credit base.? whys

1.3 Gateway Service

There have been various proposals to solve the problem of value transfer between cross-chain/sidechain, from BTC Relay to lightning network to cosmos/polkadot, but none of them can solve the problem of cross-chain transaction in a completely decentralized solution. Utilizing a consortium blockchain to start a cross-chain application is the most viable technical solution at this stage. We hope to open the door to cross-chain cooperation through an open and transparent consortium blockchain. Let users choose the consortium gateway they trust, and promote a healthy competition in the consortium blockchain to provide a more secure, faster, and lower cost gateway service.

2 Product Feature

2.1 Gateway Protocol

We hope to accomplish an asset mortgage certification on the public blockchain using a consortium gateway. Doing so allows value to be transferred to the more versatile and higher performance side chain. On one hand this will solve the scalability problem, on the other hand this can help connect and transfer the value of multiple otherwise isolated public blockchains islands.

The system has the following features:

  • It is publicly verifiable that the gateway system is distributed removing the risk of centralization.
  • It can support the transfer of multiple types of assets to achieve the connection of multiple public chain value systems.
  • Guarantee the user's control over the assets, transfer of assets to and from the system can be done at any time.
  • We are an open protocol system that allows organizations or individuals that are trusted by our users to build their own affiliated consortium gateways.

2.2 Alliance Gateway

In a traditional sidechain architecture there is no independent gateway design. Generally, multiple signatures are completed by the nodes themselves in the sidechain. This mechanism relies on the complete trust of the main chain towards the sidechain, which means that the sidechain is generally developed for the purpose of one public blockchain. Meanwhile all the investors in the main chain fully trust the sidechain development team. This limits the development of the sidechain to a certain extent. We consider establishing an consortium gateway; they will maintain the main chain and the sidechain’s SPV or the whole node is used to verify the transactions of the main chain and the sidechain. Concurrently M/N method is used for multi-sign voting to ensure the security of the main chain assets.

At the same time, we separate the roles of the signer and the watcher in the gateway, enabling nodes that can obtain the trust of the main chain to form the consortium gateway to perform the signature operation. And let the watcher monitor the various types of main chains and sidechain. The sidechain developers (or third-party developers) can access the consortium gateway by doing a simple adaptation according to the protocol, thus gaining more support and trust form the main chain.

We build an affiliate gateway through an efficient Pbft-like protocol, which allows all signature, lock, and unlock operations to be completely traceable and provides the basis for internal negotiation within the federation.

3 Technical Details

3.1 Overall Architecture

Figure 1. Overall Flow Chart

As mentioned above, the Open Consortium Gateway Protocol is mainly responsible for protocol communication between the main chain and the sidechain: it is not only responsible for the issuing of token from the main chain to the side chain (withdrawal), and also back from side chain to the main chain. And guarantees the asset security and exchange rate stability during the two-way anchoring (pegging) process. It consists mainly of two parts:

  • Signer: Responsible for the back-to-back transaction signature of the sidechain to the main chain, and the consensus agreement of the gateway itself.

  • Watcher: Responsible for the interaction between the gateway and the chain. The main job is to observe the information on the chain and adapt to different main/sidechains.

  • Key store service: Service that stores a private key and provides a signature operation.

After the user sends the token to a specific address on the main chain, the watcher notifies the signer of the relevant transaction information by monitoring the main chain transaction, including the tid of the main chain transaction, the address of the specific address, the amount, and the corresponding sidechain address. The signer checks the authenticity of the transaction through the tid to the main chain, and after determining the transaction will not be revoked, saves the information of the transaction on its own consortium chain. And initiates a token request to the side chain.

After the user initiates a withdrawal on the side chain, the side chain completes the transaction of burning the token. The watcher of the side chain monitors the transaction of the whole node and sends the relevant information (tid, amount, user's side chain address, user's main chain address, etc.) to the signer. The signer verifies the authenticity of the transaction in the sidechain, and determines that the transaction will not be revoked. The consensus is then reached in the Braft chain. The signer initiates a transaction to the main chain. The input to the transaction is the token that was previously locked. The output of the transaction is generally divided into two parts: one part is sent to the user's address, which represents the return, and the other part continues to be locked. After the transaction is successful, signer saves the relevant information on its own chain.

Signer saves the private key through a Key Store Service. We want to build a heterogeneous key store service, so that the individual nodes in the gateway can still guarantee the security of the funds after being attacked. At 3.6 we will give a reference plan.

3.2 Business Process

Typically, a business process locks a certain amount of tokens on the main chain to issue new tokens (or deposit) on the sidechain. The sidechain is based on this new token to implement its own application. The reverse process is also supported, that is, cash withdrawals are made on the side chain, and the corresponding number of tokens can be unlocked on the main chain. The exchange rate of issuing token (or deposit) and the exchange rate of the exchange should be determined by the consortium gateway. The main chain and the sidechain will implement bidirectional connection through the consortium gateway.

  1. The consortium gateway generates a multi-sign address, and the user sends the token to the multi-sign address on the main chain. The multi-signature ensures that the user's token will be locked at this address until the user initiates an exchange in the side chain. Any one (or some, determined by a multi-tap algorithm) gateway member cannot spend this asset.

  2. Accordingly, tokens are generated (or just unlocked) at one or more designated addresses on the side chain, and these tokens are used for Dapps running on the sidechain.

  3. The user performs a return on the side chain, that is, the token on the side chain is returned to the token on the main chain. The side chain initiates a return transaction request to the consortium gateway

  4. The Consortium Gateway reached a consensus to confirm the return transaction. The transaction is then initiated on the main chain, and the corresponding number of tokens are unlocked and sent to the corresponding user address.

3.3.1 Introduction to Braft

We use an improved algorithm based on RAFT called BFT RAFT (Byzantine Fault Tolerant Raft; or Braft) to achieve consistency in multiple nodes in the gateway and provide fault tolerance, including general network failures (such as node failure) and Byzantine failures. In a network with 3f+1 nodes, the number of failed nodes is f, and the network can still operate correctly.

Similar to RAFT, the state of the node has three states: leader, follower, and candidate. The duration of each is divided into terms. Each term starts with an election phase. After the leader is selected, the a request for synchronization phase is performed until the current term has no available leader and the the term ends and a new term begins. Nodes communicate via RPC, as well as (RequestVote and AppendEntries).

AppendEntries)。 Suppose the entire cluster has 3f+1 nodes, and no more than f of them are Byzantine nodes (downtime or lying). The cluster has one leader and the other nodes are followers. The leader is responsible for packing the block and broadcasting it to all followers. Only when 2f+1 nodes recognize the block and then a new block can be added to the chain.

The leader has a concept of term, term is a consecutive numbered integer, and leader is obtained by p = term mod N, where N is the number of cluster nodes and p is the number of the node (0~N-1). When the leader fails, a new term begins and switches to a new leader.

3.3.2 Consensus Process

For each round of consensus, the leader is responsible for mining and broadcasting a new block. Init indicates the current state, n indicates the height of the current block, and req is the block itself. The state of all nodes is in three steps: Inited, Prepared, and Committed.

Inited It is Inited when a node accepts. Before accepting, you need to compare the local term, n, that have not accepted the other. A message will be broadcast after Inited.

Prepared After the node reaches the Inited state and receives 2f+1, the node enters the Prepared state, which means that the previously received information is validated by the entire network and can be added to the block. After Prepared node will broadcast ??

Committed After the node reaches the Prepared state and receives 2f+1, the node enters the Committed state. At this time, it can be confirmed that the entire network can write a new block to the local chain. The node can also add a new block to the chain.

3.3.3 Replacing the leader

When the leader crashes or broadcasts a fake block, the other nodes will verify that there is a problem with the leader, broadcast and record a weak-accuse:, i is the ID of the node. At the same time, all nodes collect the weak-accuse from other nodes. When f+1 weak-accuses are collected, they can be broadcast as a strong-accuse, triggering a change of leader. The node is term->term+1, and the new leader ID is calculated and voted. After the corresponding node receives at least 2f+1 votes, it can declare itself as the new leader. The new leader will also display the voting information it receives to all nodes to verify its legitimacy.

3.3.4 Transaction type and data format on the braft chain

There are four types of transactions on chain: main chain lock, main chain unlock, issuing side chain token , burning side chain token. We use the transaction ID (TxID for short) on the main chain and the unique name of the main chain registration.

For example, the data format of the main chain lock token is similar to a tuple (main chain ID, main chain TxID, main chain locked amount, side chain ID, , operation status) (for ease of understanding, timestamp, nonce and other data is omitted here). The data format of the side chain currency is: (main chain TxID, side chain ID, side chain TxID, , operation status). Through the blockchain browser, we can display the same (main chain ID, main chain TxID, side chain ID, side chain TxID) as a transaction set, and observe the asset transfer life cycle between a complete main chain and sidechain.

3.4 Technical details

The process of transferring a token from one public chain to another is called a gateway transaction. The node receives the public chain transaction monitored by the watcher, puts it a line to be processed, and after a series of processing steps, initiates a token transfer transaction on the other side of the public chain to complete the token cross-chain transaction.

There are various factors that need to be considered during the process of token transfers. Below are some points we have listed:

  1. Cheating happening between the input and output transaction created by the leader
  2. Leader does not initiate a transaction
  3. The full node of different nodes are not fully synchronized.
  4. How to prevent double spending (such as an ETH coin transaction, withdrawing twice on the BCH chain)
  5. Network problem, failed to send signature or failed to send transaction

Combined with the above issues, we have developed a comprehensive transaction processing process. The processing flow will be slightly different depending on the target chain. The difference here is mainly whether the token transfer of the target chain is based on UTXO or based on smart contracts. For demonstration purposes, the following two public chains, BCH and ETH, are used as examples.

he basic operation from BCH to ETH is to transfer a certain amount of BCHs to the specified multi-signal address on the BCH chain. The corresponding gateway will go to the contract on the ETH chain to deposit the specified account with the corresponding amount of tokens. The contract's token and BCH are permanently pegged to a fixed ratio.

3.4.1 Trading Process

The leader creates an input for the ETH transaction and broadcasts it to all nodes in the network for signature. After the nodes receive the signature request, it checks the legality of the transaction content. If the verification passes, the contract interface is invoked to initiate a deposit transaction, otherwise the input is returned.

After the node is signed, it directly goes to the ETH blockchain to monitor whether the transaction is completed or not. If it is detected, it creates a gateway internal transaction and records the transaction information of the two public chains. If the timeout is not monitored, the BCH blockchain transaction is placed again in line to wait for the next processing. The basic operation of returning tokens from ETH to the BCH blockchain is to burn a certain amount of tokens on the ETH contract, and the corresponding gateway will initiate a transaction on the BCH blockchain from the multi-sign address to the user address. The whole process is as follows:

The leader creates a BCH transaction to be signed, and broadcasts it to all nodes in the network. After the node receives the signature request, it checks the legality of the transaction content. If the verification passes, the signature is signed, and the signature content is broadcast to the network. If it doesn’t broadcast to all nodes, it rejects the signature node to collect the signature results of other nodes. If the signature satisfies the number of multiple signatures, the signature is merged and the transaction is sent to the BCH chain; if the nodes exceeding the threshold number refuse to sign, then the current round fails, and the request is added to the line to wait for the next round of processing to send the transaction to the BCH chain, and the node starts to go to the chain to monitor transaction, if detected finally the chain is confirmed and packaged into the block, and then a gateway is created. Internal transaction, record the transaction information of two public chains; if the timeout is not monitored, it puts the chain's transaction into the pending line and wait for the next processing.

3.4.2 Node Dynamic Joining and Exiting

The gateway as a consortium blockchain must support the dynamic joining and exiting of nodes. Every time a node changes, all nodes must be notified to reach a consensus on cluster changes. In addition, the gateway as an intermediary to connect multiple public chains must also do some additional processing, which we will explain in detail later. First, how to implement the node dynamic joining and exiting the gateway.

Node join Before the new node joins, you need to set up a boot node to obtain cluster information through this boot node. The joining process is as follows:

  1. The new node sends a request to the boot node, and the boot node returns information about all nodes in the current cluster (IP, port, nodeid, etc.)

  2. The new node broadcasts its own Join request to all nodes in the cluster. The request contains its own IP, port, pubkey and other information.

  3. After the leader receives the “Join” request, it will set the next block to Reconfig type, which is used to change the cluster node information; after receiving the Join request, other nodes will start waiting for the leader's Reconfig block.

  4. As the block consensus of the Reconfig type is completed, each node adds the information of the new node to the cluster information. If other nodes do not receive Reconfig after timeout, it triggers the “accuse” to re-elect the leader to process the Join request.

To prevent any server from joining the cluster, the cluster node needs to add the host and pubkey information of the new node before the new node can join. When the cluster node receives the Join request it will check the pubkey. Only nodes that pass the check is considered a valid Join request.

Node exit For nodes exiting it is simpler, the process is as follows:

  1. Node broadcasts Leave request
  2. After the leader receives the Leave request, it will set the next block to the Reconfig type, which is used to change the cluster node information. After receiving the Leave request, other nodes will start waiting for the leader's Reconfig block.
  3. As the block consensus of the Reconfig type is completed, each node marks the node as offline.
  4. If other nodes fail to receive Reconfig, the accuse is triggered to re-elect the leader to process the Leave request.

3.4.3 Impact on the public chain

As mentioned earlier, the gateway needs to do some extra processing in addition to updating the node information. The gateway has a multi-signal address (such as BCH) or a multi-sign contract (such as ETH) in the public chain. When a node joins or deletes, the corresponding multi-signal address or multi-sign contract will also have some adjustments. The following two cases are analyzed separately.

Multi-sign contract Multi-signing contracts are relatively simple, because the contract has an account model, and the token balance of each account has been saved automatically. It does not involve the migration of tokens. It only needs to provide an interface for updating members. The node calls this interface to update the member list when Reconfig is used.

Multi-sign address For multi-sign addresses using the UTXO model, the situation is a bit more complicated. The watcher needs to continuously monitor the old address and the new address (it can't assume that the user will switch to the new address immediately), and it needs to immediately transfer the UTXO of the old address to the new address. In addition, the gateway needs to continuously monitor the balance of the old address and transfer the balance of the old address to the new address.

3.4.3 Side Chain Contract Registration

Side chain contracts are divided into gateway management contracts and application contracts. The gateway management contract is a multi-sign contract, which includes several parts such as rights management, application contract registration management, and application contract issuing token. For security reasons, all interfaces require sufficient signatures to be invoked. The federation node uses its authority to manage the interface, it adjusts the contract’s multi-signing authority; registers the new application contract and assigns the number by applying the contract registration management interface; and cross-contracts the call through the application contract token issuing to complete the coin-issuing operation to the actual application contract.

The application contract is written for the application developer. On the basis of the specification of the ERC20, the transfer authority of the issuing interface can only be called by the gateway management contract. Through the gateway contract registration interface, submit the contract address, contract related information (received tokens, issued tokens) and so on.

3.5 Wallet

The wallet is a convenient means for customers to participate in the operation of the gateway transaction. In the OFGP protocol, the cooperation of the client is also required to quickly and conveniently complete the customer's request for depositing and withdrawing. Here, the wallet client only needs to do a small amount of upgrade to complete the customer's deposit and withdrawal request.

First of all, for depositing, the essence is to initiate a transaction on the main chain: transfer the specified token from the user's main chain address to a specific address. Compare to ordinary transaction that simply needs to provide data, the user also needs to provide the address information of the side chain. Then, when constructing the transaction data, the address information of the relevant side chain needs to be filled according to the data format of the OFGP protocol, and the subsequent signature and the broadcast transaction flow are the same. Afterwards, it is to monitor whether the deposit sidechain’s target address tokens are received. The process here is no different from ordinary transfer.

The withdrawal, from the perspective of the wallet and the deposit process, is equivalent to constructing a transaction: transfer from the user's sidechain address to a specific address or sidechain of the burning of the token transaction (specifically based on the implantation of sidechain. Here, it is also necessary to provide a receiving address for withdrawal to the main chain. When the wallet constructs a transaction, the address information of the relevant main chain is filled according to the data format of the OFGP protocol. In the future, it is to monitor whether the the withdrawal main-chain’s target address token are received. The process here is no different from ordinary transfer.

3.6 Key store service

Signer needs to be responsible for unlocking the main chain token to sign the sidechain request, and it needs to maintain the private key of the main chain multi-sign address and the private key of the side chain multi-sign address. Therefore, the management of the private key is crucial it needs to take into account both security and real-time use. The private key management service has different software/hardware solutions. We expect different gateways to choose the solution that suits their environment, and can implement heterogeneous solutions as much as possible. Below is a software solution, mainly to illustrate the basic technical principle. In addition, gateways can choose to have the HSM/KMS service of the cloud service provider, or it can choose to purchase a dedicated encryption machine hardware. The plan here is the private key isolation encryption storage, the private key generation and signing service runs independently, and the signature data output service is provided for finishing business process through the private key proxy service layer. The basic structure is as shown in the following figure:

keystore Figure 2 Private Key Management

As shown in the figure above, the management of private keys is mainly divided into three major blocks: key storage service, key management service, and private key proxy service.

  • The key storage service focuses on the storage of keys, and it ensures the security and reliability of key storage in the following ways.

    • Physically, the key storage medium belongs to an independent computer room and is in an independent local area network. The external network is inaccessible, limiting internet intrusion to the greatest extent. It only provides limited data and access to the key management service program. In special cases, the automatic control can directly disconnect the physical connection between the storage network and the outside world to form an offline island.
    • Sensitive data such as keys are stored in an encrypted manner (AES256), and each different data uses a different encryption key. Thus, even if the data is accidentally leaked, the original key information will not be revealed.
    • Note: The AES256 key used for key encryption is maintained by the Key Management Service, which is isolated from the Key Storage Service.
    • Redundant backup and off-site backup prevent data from being lost or unrecoverable due to physical damage, improving storage reliability.
  • Key management service, main purpose is the generation of keys and the use of keys. It does not directly provide external services, but responds externally through corresponding proxy services, which blocks direct contact with the outside world and while satisfying the business’s core needs. It is mainly responsible for the following tasks:

    • A multi-sign address and its key are generated according to the instruction, and the key is encrypted and stored in the key storage medium.
    • Based on the provided data, it reads the encrypted key, decrypt the real key, sign the data, and output the processed signed data.
  • The private key proxy service provides external multi-signature address and signature services, and provides the ability to manage risk management, track and record access behaviors, block illegal requests, monitor key management service operations, and provide system degradation processing capabilities, such as:

    • Interrupt private key management service
    • Cut off the private key storage network

The following is a chronological process to illustrate how the key management block works. The process of generating a multi-sign address is as follows:

  • The external service issues a request to the private key proxy service to generate a multi-sig address.
  • After the private key proxy service detects the requester and the request content are legitimate, the request key management service performs the generation of the multi-sign address.
  • The key management service generates a corresponding multi-signal address and a corresponding key. Each key is randomly selected with an AES256 encryption key for encryption, and the encrypted data is stored in the key storage service to obtain a storage path or an access index.
  • The key management service generates a unique identifier for each key, establishes an associated index relationship, and ensures that the AES256 encryption key and the storage access path of the key can be obtained through the unique identifier.
  • The key management service returns data: a multi-signal address + key identifier list for the private key agent service.
  • The private key proxy service returns relevant data to the external service requester

The signature process is as follows:

  • The external service issues a signature request to the private key proxy service (providing the necessary parameters: the data to be signed and the identifier of the used key).
  • After the private key proxy service detects that the requester and the requested content are legitimate, the key management service is requested to perform the signature.
  • The key management service obtains the storage access path and decryption key of the key based on the provided identifier.
  • The key management service obtains the encrypted key from the storage service through the storage access path, decrypts the original key by using the decryption key, performs a signing on the data, and securely removes the loaded key information after completion, and returns the signed key. The data is served to the private key agent.
  • The private key proxy service returns the relevant data to the external service requester.

4 Application scenarios

4.1 Unlicensed Innovation Side Chain

After the main chain transfers assets to the sidechain through the OFGP gateway, high-speed transactions can be completed on the sidechain (such as a small payment scenario with a second-level confirmation). In addition, an efficient and feature-rich smart contract can be implemented on the sidechain. The privacy of transactions is also enhanced by the utilize of ring signatures and zero-knowledge, so the risk of specific transactions is reduced. Finally, more functionality can be implemented in the smart contract’s sidechain.

Sidechains can experiment with or operate their own systems without the need to issue tokens and any licenses to directly use the main chain's monetary system (and user system), thereby avoiding high baseline start-up costs and policy risks.

4.2 Decentralized Exchange

Different main chain assets can be mapped to the sidechain through OFGP and established an efficient decentralized exchange (DEX) via the high-speed trading performance on the sidechain. However, the traditional DEX can only rely on one main chain to complete the transaction of one coin such as ERC20 tokens (e.g. Ethereum). To support various coins and tokens a centralized exchange is essential, but the security of the data cannot be guaranteed. Moreover, mapping the different tokens to the same side-chain through the consortium gateway can improve the flexibility of the exchange maneuvering various coins and tokens. At the same time, this will require a wallet to provide a more complex protocol.

For example, BCH can be mapped to BCH-GW1-ETH (a token on ETH) by establishing a BCH-ETH gateway. BCH-GW1-ETH as an ETH-based ERC20token, can be used in Ethereum, so the DEX contract developed on the BCH-GW1-ETH and ETH transaction pairs can be used for BCH-ETH transactions. Similarly, the coins of other main chains can accomplish their transaction on ETH. The exchange can also implement other higher performance side chains out there.

Figure 3 DEX base on OFGP

5 Conclusion

The OFGP protocol can facilitate the efficient transfer of assets between the main chain and the side chain. Unlike traditional ICO, ICO is essentially a form of giving out equity for financing. But all assets generated through OFGP are based on credit. Through the consortium gateway, a trust between the main chain and the side chain is established, and asset mapping through the gateway can accelerate the flow of assets between different ecosystems. At the same time, we also believe that there can be an innovation on the “no-trust and no-license” model. We hope that the side chain application can quickly carry out unlicensed innovation in the form of registration, and let the consortium gateway ensure the asset security of the main chain.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.