Partnered With:

Interview with Cdot Liu: The trust-free relay cross-chain is the perfect cross-chain

Read this article in 34 Minutes

Put aside the appearance of cross - chain, from the most essential understanding of perfect cross - chain

Original title: "A Detailed Explanation of The Technical Points and Difficulties of Cross-chain: Starting from the Perfect Cross-Chain"

Source: Mechanical clock

Original interview and article: Li Painting

Respondent: Yi Liu, founder of Cdot

The first thing to know about cross-chain is that we will never be able to actually transfer assets from one chain to another. In the case of Bitcoin, 21 million bitcoins will all and will only stay in a certain Bitcoin address and will not go anywhere else.

So what's going on with cross-chain asset transfer? It locks up an asset on one chain and issues an equivalent replacement of that asset on another chain. (Note: Hash locking is not in this mode)

Take the cross-chain between Bitcoin and Ethereum. It requires you to transfer your bitcoin to an address, lock in that bitcoin, and then issue a bitcoin replacement on Ethereum and transfer it to your Ethereum address. To redeem, you need to call a smart contract to destroy the bitcoin replacement, and then release the locked bitcoin to you on the Bitcoin network.

The only difficulty, it is easy to see, is the interflow of messages.

That is, when you lock up your bitcoin on the Bitcoin network, you can mint COINS in Ethereum as long as ethereum knows about it. After you destroy your replacement in Ethereum, the Bitcoin network can release COINS to you on the Bitcoin network as long as it knows about it.

So why is it so hard to get messages back and forth? I spoke with Liu Yi, founder of Cdot, who believes that multi-chain is a more viable system, so he and his team are working on linking chains to each other. Cdot has already built cross-chain Bridges for Ethereum and Flow, and is working on cross-chain Bridges for Cosmos and Polkadot, Cosmos and Ethereum.

Why is perfect cross chain hard to achieve

Q: To start with a "big" question, how do you see the importance of cross-chain?

Liu Yi: The main problem facing the development of public chain technology is how to break through the bottleneck of performance and cost without sacrificing too much the combinability of applications on the chain. Currently, there are three solutions: fragmentation, Layer 2, and multi-chain (cross-chain). Polkadot, Cosmos, Ava, and many other teams, including Cdot, are working in this multi-chain direction.

In other words, if the Substrate /Cosmos SDK can be used to develop a dedicated chain for each encryption protocol, and if this encryption protocol can be interoperated with other encryption protocols across the chain, then the performance and cost problems of the common chain can be solved.

Q: Back to today's technical topic, what is the difficulty of communicating two chain messages across a chain?

Liu: I can only talk about it in an article Vitalik wrote in 2016 called "Chain Interoperability". He has divided cross-chain technologies into three categories, hash time locks, witnesses, and interpasses. I just think they can only be used.

Witness and relay are downchain processes that move messages around: it sees something happening on the A chain and tells the B chain.

What's the difference? When I receive a message on the target chain, if the witness crosses the chain, I verify that the message came from the witness, and if I trust the witness, I trust the message, and I perform the action that should be performed.

If it is a relay across the chain, I verify that it is not a relay from which the message is coming, I verify that the message is coming from the source chain, and if it is, I perform the action that is to be performed.

In other words, a witness can be seen as a relay that needs to be trusted, and a relay can be seen as a witness that does not need to be trusted. This is the core difference between the two; relay is clearly more trustless than witness.

A relay is not a bad thing. If a relay commits information that is not from the source chain, the target chain validates it and recognizes it. But a witness can do evil. It can create a message and send it to the target chain, which, after verifying that it came from a trusted witness, will perform the operation.

So, it seems that everyone should be using relays to make cross-chain products, but why is there a witness mode? Because relay cross - chain requirements are higher.

What exactly does it require? Let's say we're two chains, and you have an event up here, and it's sent to me by a relay, and I want to verify that this information is coming from your chain, right?

How do you verify that? I need a light client with your chain on my chain. This is roughly analogous to the Bitcoin SPV, but it happens on the chain, not in your mobile wallet, which means that I have all of your blockheads here.

At this point, when a message arrives, the relay will not only give me the message, it will also give me the Proof of the message, which is a Merkle Proof, which will tell me which block (height) on your chain the event or transaction occurred on.

After I get Merkle Proof, since I have all your block heads, I can take out the block heads corresponding to the height and verify whether the transaction or the event exists with Merkle Proof. If the existence is proved, I am sure that the message is indeed from your chain.

Then, when my chain generates an event or makes a trade, the relay sends it back to you, and you have all of my block headers, as well, to verify that the message came from me. This is a perfect cross chain, right?

But why don't you try to achieve the perfect relay across the chain? Because some chains are no way to implement other chains' light clients. Bitcoin, for example, does not implement any of the chain's light clients.

Is it possible to implement other chains of light clients on Ethereum? It depends on the difficulty of implementation. Ethereum needs to implement light client with smart contract, but smart contract is limited by GAS, so the calculation amount of light client verification should be able to accommodate within the Gas Limit.

Q: Can it be argued that if one chain does not have the requirements to implement the light client of the other chain, it will never be able to cross the chain as a relay with the other chain?

Liu: It can only cross the chain in the form of witnesses, but it can be mixed, using witnesses in one direction and relays in the other.

For example, if I develop a chain, Bitcoin certainly cannot achieve my light client, but I can achieve the light client of Bitcoin, so bitcoin to my direction can be used relay, I can only use witness to the direction of Bitcoin.

Q: What about Ethereum? For example, you want to implement a relay between Ethereum and Cosmos across a chain.

Mr. Liu: Ethereum is a complex problem. It has the conditions to implement some light clients, but as mentioned above, the main limitation is the Gas Limit.

For example, a chain of Tendermint (The consensus protocol adopted by Cosmos) needs to verify its block head by relaboring and cross-chain. Its block head is the signature of all verifiers. These signatures are verified by BLS signature algorithm.

The intelligent contract can directly invoke the pre-compiled encryption algorithm, such as the call ECRecover method. It only needs 3000 GAS to verify ECDSA signature, which is still relatively low. Instead of trying to verify that there is no precompiled BLS signature, you would have to implement the entire signature verification algorithm soldesert, which is not backed by the underlying body, and that would be too expensive.

The best way to verify a BLS signature seems to be two hundred thousand GAS. If there are 100 verifier in the Tendermint, there may be 100 signatures in each block and 100 BLS signatures can be verified. Gas is bound to exceed and it's impossible to do.

However, in Vitalik's roadmap this year, Ethereum 1.x will add the BLS signature precompile contract, which is equivalent to implementing BLS verification at the bottom of the client, so that a function call can verify the signature.

Assuming that, like ECDSA, it is also 3000 GAS, the verification of 100 BLS signatures is 300,000 GAS, it is possible to achieve this in the intelligent contract.

With BLS precompiled, it would theoretically be possible to implement a light client of the Tendermint on Ethereum, and thus ethereum and Cosmos would enable two-way relay spanning. So if you're talking about a continuum like Cosmos, bitcoin won't work, ethereum won't work now, but maybe in the future.

Q: Even chains developed using Cosmos's IBC standard are not naturally cross-linked?

Liu: Yes, even if both chains implement IBC, the light client of the other chain should be realized if the relay crosses the chain.

How do cross-chain messages travel between chains

Q: The light client is used for cross-chain message validation, but how is the cross-chain message itself delivered between the two chains?

Liu Yi: The cross-chain bridge is very picturesque. It has two piers and a bridge. Two piers are two sets of smart contracts (some chains may be called modules), one running in chain A, one running in chain B; In the middle is the bridge, which is the process under the chain, which is responsible for monitoring the events of the two sets of intelligent contracts on both sides.

Q: Let's say I lock a cryptographic cat into a smart contract on Ethereum. It's easy for the downchain process to listen to this event, but how does it tell the smart contract on Flow that I've locked a cat?

Mr. Lau: The downlink process is to send Flow a deal that says there's a cat locked in ethereum and you're casting a cat on your side. It is a program that connects the nodes of Ethereum on one side and the nodes of Flow on the other through the RPC (remote procedure call) interface.

Q: Can you fully describe a specific cross-chain process?

A: Let's say we have an ERC20 token, like the UNI, which is issued on Ethereum, and we want to cross it onto a PlatON.

So ethereum has a smart contract on its side, let's say a Vault contract, which is one of the piers of the cross-chain bridge; A cross-linked user has to make two transactions. The first transaction is to invoke the Approve method for a UNI contract, allowing Vault contracts to be transferred to how many UNI users.

The second transaction is the Lock method to send the Vault contract, passing in the currency to be locked (UNI in this case) and the quantity (say 500) as parameters, and then providing an address of PlatON, saying that I Lock 500 in order to cast 500 UNI substitutes at this address.

At this point, the Vault contract will invoke the UNI contract to do the transfer of the UNI contract, and since the Vault contract has been approved, you can transfer the UNI from the user address to the Vault contract address, which means lock the UNI.

Once the lock is done, the Vault contract issues an event called the AssetLock event; The chain under the process is through RPC ; The interface is attached to the Ethereum node, and it subscribles to the AssetLock event of the Vault contract, which is available to the process that is linked as soon as it appears in the log.

This event contains parameters, such as which coin is locked, how much is locked, and who is the beneficiary on the other chain; The process under the chain will wait for confirmation of, say, 100 blocks, irreversibly; Then, the process under the chain also has an RPC interface that connects to PlatON, and it submits a transaction to PlatON, assuming the transaction is called Mint.

There will also be a contract on PlatON, such as the Control contract, which is another pier of the cross-chain bridge; The Control contract creates an ERC20-like contract, called the EUNI. The Control contract is the owner of the CONTRACT, which means it has the power to Control the supply of tokens to the EUNI contract.

When the Control contract receives a request from Mint, verifies that the request came from the witness, it invokes the Mint method of the EUNI contract and tells it to Mint 500 EUNI tokens for an address. Once the EUNI is cast, it is placed on the address provided by the user and the user is ready to use it.

In this case, if a user passes the EUNI to another user, and the new user wants the UNI in Ethereum, the thing he does is Approve it, and then it was used in the Control contract method, and it was used to burn up, say, 100 EUNI items, and release an event called AssetBurn.

The AssetBurn event monitored by the process under the chain to the Control contract will issue a trade request to the Ethereum Vault contract, call the Release interface, and after Ethereum verifies that the trade is from the witness, it will transfer the UNI from the address of the Vault contract to the specified user address, and the user will get the original UNI. So that's a whole chain spanning process.

Q: Can you cross chains without the role of "down the chain"? Let's say one chain goes and listens to the other chain, and then completes the relevant cross chain operation, right?

Liu Yi: This can't be done, because the chain can't initiate the operation actively, the chain logic is passive.

The only exception is the Substrate (Polkadot development framework), which has an off-chain worker mechanism above it that initiates a request using a downchain worker. Others, such as the Ethereum intelligent contract, cannot initiate anything on their own; it can only be invoked.

Q: Can it be understood that either the relay cross-chain or the witness cross-chain requires the process under the chain to deliver the message, the difference being that the relay cross-chain validates the message through the light client, while the witness cross-chain trusts the message provided by the witness?

Liu yi: There is basically no problem with this understanding. The relay depends on the availability of the process under the chain but not on its loyalty.

How can a witness be more trustworthy

Q: It seems easy to pass a message through a chain process. The hard part is validating the message or trusting the message?

Liu: Yes, because both chains have RPC interface, and both have SDK (software development kit), they can be accessed, so it's not difficult.

And cross-chain for a specific purpose, there is no need to define an extensible protocol, as long as its own good: define what events, what parameters to extract, what parameters to submit to whom, it is all right.

Q: Validating a message is a technical problem, either it can be verified or it can't be verified, but if you trust a message, there seems to be a different model, reflected in the witness cross chain is that it can be implemented in different ways, the message that needs to be trusted can come from a centralized witness or a decentralized witness?

Liu: Actually, it's a security issue. While security is a thing without limits, there is no absolute, security is usually a gradual process.

For example, in the beginning, when there are few assets, you can use a single witness, not even KMS (key management service); When you have assets, you use KMS; Many assets, need a number of witnesses, in order to save GAS, it is necessary to do under the chain signature aggregation; When you have more assets, you need MPC (secure multi-party calculations).

Then you add more assets, and you randomly group the parties participating in the MPC, such as RenVM. This is as difficult and as practical as making a common chain, but it also serves as a witness to decentralization.

Q: Can you describe it more specifically?

Mr. Liu: For example, with ethereum on one side and Flow on the other, we can develop a witness node to connect the two sides.

However, the security and availability of this witness is relatively low. If the hacker breaks into the witness's server and gets the witness's private key, he can steal all the ETH or ERC20 locked on the Ethereum.

Another risk is availability. If the witness server goes down, you can lock the asset in one chain and not forge it in the other, because the message won't get through.

If not many cross-chain assets are being loaded, one witness is acceptable, and there are ways to deal with the security and downtime issues of a single witness. But if you want to improve further, what do you do? It can contain three witnesses.

Let's say there's a bitcoin on one side and an Ethereum on the other, and there's a two-thirds multisignature wallet on the Bitcoin network, and the user sends a transaction and locks the bitcoin in, and when the three witnesses see it, they send a message to Ethereum, and ethereum confirms that the message came from the witness, and they mint tokens on ethereum.

On the return, the user sends a transaction through Ethereum asking for the bitcoin to be redeemed. Three witnesses see it and send multiple signatures to the Bitcoin network: one witness sends a transaction saying he wants to release it, another witness sends another transaction saying he wants to release it, and two-thirds of the wallet see two signatures and release the bitcoin to the user.

Two-thirds is better than one witness, but only two of the three private key holders could have taken it all, so its decentralisation is not enough.

A better solution would be a witness chain supported by MPC/TSS (secure multiparty computation/threshold signatures). I just said that witnesses need to be trusted, but if you make witnesses into a chain, can it also be trustless?

The trust set has expanded, so you have to trust the source chain, the target chain, and you have a witness in the middle, but this witness is not centralized, it's a chain, it has its own economic security, and as long as you believe that the validator set of the witness chain as a whole is not evil, then the whole process is still trustless.

Witness chains can randomly group multiple witness nodes, each with, say, a Bitcoin address, and then regroup the nodes over a period of time, making it harder for the nodes to collude and steal bitcoin.

The function of threshold signature is, for example, there are 21 nodes in a group and each node takes a piece of private key. If it is set to 15/21, there need to be 15 nodes in the 21 nodes to sign, then an ECDSA signature is formed, and then the wallet is unlocked through a transaction.

Clearly, this approach is more secure, more reliable (it can tolerate six nodes not being online, or intentionally not signing), and more economical because it requires only one transaction to unlock the bitcoin.

In the process of aggregate threshold signature, MPC is needed, because the private key of the node cannot be put together to sign, it needs to be calculated separately. Therefore, it is a mechanism of threshold signature plus MPC, which can form a witness chain.

Q: MPC/TSS is usually used to cross the chain between Bitcoin and Eum. Can it be easily ported to cross the other two chains?

Liu: Yes, but it's not necessarily easy. Its threshold signature and MPC are for ECDSA signatures, and it is easy for this mechanism to do asset cross chain between the chains of ECDSA. If its threshold signature and MPC support other signature algorithms, the mechanism can be extended to other chains.

Q: Now that we know a little bit about relay cross-chain and witness cross-chain, what kind of cross-chain mechanism is a hash time lock?

Liu: I gave the hash time lock a new name: external coordination.

External coordination means that during the whole process of cross-chain, the two chains do not know each other, the A chain does not know what is happening on the B chain, and the B chain does not know what is happening on the A chain (note: in the relay cross-chain and witness cross-chain, the two chains know each other).

For example, hash time lock, we first make A transaction on A, get the hash, and then submit the hash to B. This is A coordinated cross-chain between two user wallets. The two chains do not know each other's chains.

Why extend the hash time lock to external coordination? Because in addition to hash time locks, there are a large number of non-hash time locks of external coordination across chains.

One of the biggest applications is the centralized exchange, where I put bitcoin in, and I took it out in ethereum, and it's a web application that does the coordinated cross chain.

External coordination across chains is also widely used in the area of consortium. chain vendors, such as Hyperledger Cactus, are middleware that specializes in external coordination and can span two chains. The user commits A transaction to the middleware, and the middleware knows that an operation is done on the A chain, and then an operation is done on the B chain, and the A chain and the B chain are mutually uninformed.

So whether it's coordinated by the wallet, or whether it's coordinated by the application, or whether it's coordinated by the middleware, the characteristic of this kind of cross-chain is that the two chains are actually mutually uninformed, and there are external entities that are coordinating.

Why do we rarely talk about external coordination in the realm of public chains or encryption protocols? Because a Web application or middleware must be run by a centralized entity, it cannot be decentralized.

But the wallet as the cross-chain coordination of external entities can be considered as trustless, because the user and the wallet are the same, we must trust the wallet to do anything, that is, it does not expand the trust set. That's why you think of a hash time lock as a trustless cross-chain.

But one of the limitations of a hash lock is that it can swap assets, and it also has business problems. The cross-chain Atomic Swap has been implemented since 2015. Five years have passed and no business has been formed.

Conclusion:

Let's end this article with a little summary. It seems possible to divide the current cross-chain approach into three broad categories:

The first type: centralized cross-chain (class external coordination). It is a centralized third party mortgaging assets on one chain and issuing assets on the other chain. The cross-chain of assets actually occurs when the third party mortgages and issues assets. In this process, there is no communication between the two chains.

When users conduct cross-chain operation, it is not A process of locking COINS or casting COINS, but closer to exchanging the assets in chain A for another kind of assets in chain B issued by A third party.

Centralized cross - chain is the easiest to realize, but it depends on a strong centralized trust. Such cross-chain projects include cross-chain assets provided by exchanges and so on.

Type 2: Witness cross - chain. Passing messages through processes down the chain, locking or unlocking assets on one chain and casting or destroying assets on the other; Both chains need to believe that the message delivered by the witness is true.

A witness may be one or more witness nodes, or a chain of witness nodes that, while believing in the witness, may be considered decentralized because it does not require the trust of one or more centralized third parties.

The realization of the cross-chain witness can be simple or complex, depending on the composition of the witness. Such cross-chain projects include RenVM, tBTC, and so on.

Type 3: Relay across chains. Passing messages through processes down the chain, locking or unlocking assets on one chain and casting or destroying assets on the other; The two chains have a light client on the other chain, which verifies that the message passed by the process under the chain is true.

Relay cross - chain is an ideal cross - chain way without trust, but it is difficult to realize. After Cosmos's IBC cross-chain 1.0 came online, it was possible to relay the cross-chain between the two Cosmos chains.

Cdot is also developing Substrate IBC, with funding from the ICF Foundation (Cosmos Eco-Fund), which enables the application chain of Substrate development and the ibC-enabled chain to relay across the chain. Substrate IBC is intended to be an important underlying component in a multi-chain world.