Cross-Chain Technology Solution

What is “cross-chain” operability? This concept has developed over the past few years, as it becomes more apparent that the crypto space will be populated not by one all-consuming blockchain, but rather a number of blockchains that serve different user functions. So “cross-chain” operability mainly refers to the possibility of converting assets originally stored on a particular blockchain into assets on another chain, thereby realizing a more full circulation of value. It can also be understood as an exchange behavior between different asset holders, but this process does not actually change the total value of each blockchain. Like currency transactions that take place on the cryptocurrency trading platforms, different types of digital currencies can be exchanged. However, currency trading on these platforms is conducted through a centralized database, not the blockchain, and cross-chain movement is not subject to a market.

Currently, there are three primary, mature methods of achieving cross-chain operability:

• Notary schemes
• Hash-locking
• Sidechains / relays

1. Notary scheme

This method can be understood as a Witness mode of centralized or multi-signature functionality, where the witness is a legitimate user of chain A, responsible for monitoring the events and status of chain B, and then operating chain A. The essential feature here is that there is no need to pay attention to the structure and consensus characteristics of the cross-chain mechanism separate from the normal workings of each blockchain. Assuming that A and B cannot trust each other, this method simply introduces a third party that both A and B can trust together to act as a notary public. In this case, A and B can indirectly trust each other. This method does not propose a ledger in itself and does not seek any consensus. On the contrary, it provides a top-level encrypted escrow system called a “connector.” With the help of this intermediary agency, different ledger systems can freely transfer money to each other through a third-party “connector” or “verifier.” The ledger system does not need to trust the “connector” because the protocol uses a cryptographic algorithm to create funds for each of the two ledger systems with their own connectors. When all parties agree on the transaction, they can interact with each other. The agreement removes the trust required by transaction participants, as the connector cannot lose or steal funds, which means that such transactions do not need to be protected by legal contracts and excessive review, which greatly reduces the thresholds for security and cost. Moreover, only the ledger systems involved can monitor the transaction, meaning that the details of the transactions can be hidden. The “validator” operates through an encryption algorithm, so it will not directly see the details of the transaction. Theoretically, the protocol can be compatible with any digital ledger system, and a bank’s existing ledger system can use the protocol with only minor changes. Thus, banks would be able to trade directly without a central counterparty or correspondent bank. The main representative projects of the notary scheme are: Interledger agreement, 0x agreement.

2. Hash-locking

Hash locking originated from the HTLC (Hashed TimeLock Contract) of the Lightning Network, and is now widely used. The process of its realization is as follows:

To walk through it step-by-step, one can use Hash-locking to realize an atomic exchange process of 20ETH and 1BTC, for example:

• 1. A generates a random number s, calculates h = hash (s), and sends h to B;
• 2. A generates HTLC, the overtime is set to: 2 hours, if B guesses the random number s within 2 hours, then take 1BTC, otherwise A retrieves 1BTC; here A locks the BTC contract with h, and B also has the same h. So A and B both have the same lock h, but A has the key s
• 3.B deploys a smart contract in Ethereum, if anyone can provide a random number s within 1 hour, so that the hash value is equal to h, that person can take away 20ETH from the smart contract;
• 4. A calls the smart contract deployed by B to provide the correct s and takes 20 ETH;
• 5. B knows s, there is still 1 hour left, and B can easily cashout 1BTC of A’s HTLC.

Once it times out, the transaction fails and is atomic.

Note: The time parameter is introduced here mainly so that when the time expires, the current user can withdraw his coins. Otherwise, your own coins may be maliciously locked indefinitely.

3. Side chain / relay

The side-chain system can read the events and status of the main chain and operate distinctly based on that information. That is, a side-chain system operates through SPV (Simple Payment Verification) and can verify the information of the header and merkle tree of the block. The distinguishing feature here is that one must pay unique attention to the structure and consensus characteristics of the cross-chain mechanism. In general, the main chain is oblivious to the existence of the side chain, while the side chain depends entirely upon the existence of the main chain; similarly, the double chain does not know the existence of the relay, and the relay must know the two chains.

The side-chain is a blockchain based upon the anchoring of tokens on a certain original chain, just as fiat currencies would anchor gold (before Bretton Woods). The technology was originally designed to solve the scalability issues of first-generation blockchains. Each blockchain can implement mandatory consensus through a protocol. The performance of one such blockchain system can understand the consensus systems of other blockchains, and can automatically release Bitcoin after obtaining the locked transaction proof provided by other ledgers.

For example, BTC-Relay uses Ethereum as Bitcoin’s side chain, and it is connected with Bitcoin through Ethereum’s smart contract platform. Relying on SPV proof can enable users to verify Bitcoin transactions on Ethereum.

The usage scenarios are as follows:

• 1. Alice and Bob agree to use the BTCSwap contract for transactions. Alice wants to buy Bob’s eth, and Bob sends his eth to the BTCSwap contract
• 2. Alice sends bitcoin to Bob, she hopes that the BTCSwap contract will know about it so that the BTCSwap contract can release Bob’s eth.
• 3. Alice calls btcrelay.relayTx () through Bitcoin’s transaction information and BTCSwap contract address, and btcrelay triggers the processTransaction method in the BTCSwap contract after verifying that the transaction passes.

4. After being triggered, the BTCSwap contract confirms that the btcrelay address is a legal address, and then releases Bob’s eth. The transaction is now completed.

Thus, relays are more flexible. The “middleman” only acts as a data collector. After receiving the data from the sending chain, the target chain verifies it by the receiving chain to complete the transaction confirmation. The method of self-verification differs depending on the system structure. The main representatives of this concept are Cosmos and Polkadot. At present, it seems that the technical aspects of cross-chain relays have encountered obstacles and have not been able to achieve substantial progress and applications.

4. Comparison of various schemes

5. The cross-chain solution adopted by Cypherium:

By comparing the methods listed above and taking into account Cypherium’s own characteristics, our team has decided to adopt the notary mechanism and not engage in another set of protocols. We chose to directly adopt the Interledger protocol, because although InterLedger is initiated and led by the Ripple company, it is an open protocol. Any company or individual can participate in joint development and use it for free. It is not linked to any blockchain or XRP. Its original intention was to establish a global unified payment standard. It has been supported by Microsoft and World Wide Web ( W3C ) since its inception. Apple also introduced the notary mechanism to its own system in 2018, and it has already accessed and traded among many different financial networks: China’s Lianlian payment, the United States’ international fast remittance giant MoneyGram, 47 Japanese banks of the SBI alliance, Japan Mitsubishi UFJ Financial Group, Spanish Foreign Bank, Swedish Nordic Bank, Turkish AKbank Bank, Indian Yes Bank, Indian Axis Bank, Japanese SBI Group, American Star Credit Union, American EZ Forex, Canadian Cambridge FX, Standard Chartered Bank, Merri The Dagates Foundation, and the alliance is still expanding.

The notary is a component Cypherium dedicated to connection, focusing on the payment standard and unified protocol for connecting various ledgers. Its supporting communication objects include not only the blockchain but also various types of ledgers (usually the internal ledger systems of various banks), which are connected to each other through a trusted third-party “connector”. InterLedger protocol is an implementation model of hash-locking. In this system, two different ledger systems can freely transfer money between each other through third-party “connectors” or “verifiers.” The ledger system does not need to trust the “connector”, as the protocol uses cryptographic algorithms to create fund custody for the two ledger systems and connectors. When all parties agree on the amounts of funds, they can transact with each other across the ledger and the funds can flow immediately and automatically. And only participating parties in the ledger system can track the transaction; in other words, the transaction details can be hidden. The “validator” is operated by encryption algorithms, so, again, the transaction details will not be directly visible. This method is particularly suitable for existing banking systems. As a general rule, banks do not like to use other companies’ machines to verify their own transactions. In simple terms, they do not like public processing methods or semi-public processing methods, because these two methods may give outsiders opportunities for peeping at their internal data. This method alleviates that concern.

The following is a schematic diagram of architecture using ILP technology for Cypherium’s and BTC cross-chain transfer:

Parties: sender: Alice; receiver: Bob; and connector: Cot.

Ledger relationship : Alice has a Bitcoin account, Bob has a Cypherium account, and Cot has both a Bitcoin and a Cypherium account.

Scene : Alice purchases Bob’s laptop online, at a price of 2,000 CPH coins.

1. Alice obtains a “shared password” provided by Bob through instant messaging software or other communication means. The communication must be encrypted, so that after the communication, only Alice and Bob know the “shared password”; at the same time, Bob will tell Alice his corresponding unique address in the ILP network, such as a52813334ee89485d661fee989a0e75402b2eeea.
2. Alice inquires Cot about the transaction cost of sending 2,000 CPH in BTC. At this time Cot will calculate the fee by real-time BTC and Cypherium market rate, while Cot will overcharge a 0.00001 BTC handling fee, and the final amount Alice needs to pay Con is 1.00001 BTC.
3. Alice generates the required ILP package according to the message format of the ILP specifics. The ILP package indicates that the target address is Cot. At the same time, a “conditional preimage” is generated based on the private content of the ILP package and the “shared password”. The preimage is hashed to obtain the “conditions” of a “custodial” transaction.
4. Alice initiates a “custodial” creation operation on the Bitcoin ledger system, sets the “custodial” conditions in step 3 and a timeout period, and sets the ILP package at the same time.
5. Cot detects a “custodial” creation operation involving itself on Bitcoin.
6. Cot parses the ILP package, and figures out it should credit Bob 2,000 CPH, and modify the ILP destination address to Bob.
7. Cot initiates a “custodial” creation operation on the Cypherium ledger, sets the “custodial” conditions in step 3 and a timeout period, which is less than the timeout period in step 4, and sets the ILP package.
8. Bob detected a “custodial” creation operation involving himself on Cypherium ledger.
9. Bob parses the ILP package and uses his “shared password” and private content in the ILP package to generate a “conditional preimage” and corresponding “conditions”. By comparing whether the “custodial” creation operation’s “conditions” are the same as the “condition” created by Bob, along with verifying whether the amount in the “custodial” transaction equals 2,000, the “custodial” transaction is either accepted or rejected. Here we assume the transaction is accepted.
10. Bob launches a “custodial“ confirmation operation on Cypherium ledger, sets “conditional preimage”. Cypherium ledger’s “custodial” transaction is completed; Bob receives 2,000 CPH.
11. Cot detects a “custodial” confirmation operation involving itself on the Cypherium ledger.
12. Cot analyzes the contents of the “custodial” confirmation operation and obtains the “conditional preimage”.
13. Cot initiates a “custodial” confirmation operation on the Bitcoin ledger, sets the “conditional preimage”, the “custodial” transaction on the Bitcoin ledger is completed, and Cot receives 1.00001 BTC.
14. Cot detects a “custodial” confirmation operation involving itself on the Bitcoin ledger.

Note that the “custodial” transaction here consists of four main steps:

Preparation: Nothing happens at this time. Only the necessary data is prepared, and the sender’s assets are not really transferred.

Creation: Assets belonging to an account on the “ledger” system are “custodial” and created transactions cannot be canceled within a certain period of time.

Confirmation: The “custodial” transaction is completed and the assets are transferred from one account in the “ledger” system to another account.

Rejection: The “custodial” transaction is canceled; the asset returns to the source account of the “ledger” system, the “custodial” transaction can set a timeout period; if no one performs the “confirmation” operation or “rejection” operation within the specified time, the “custodial” transaction automatically lapses.