The Plan for SHA-Gate V2

Since first proposing the SHA-Gate’s scheme, nine months have since passed. The native introspection opcodes have enhanced BCH’s scripting capability, and, in the process, we have learned a lot in practice. It has now come to the time we should revise its scheme and improve upon it.

SHA-Gate means “Smart-Holder-Authorized Gate”. Before going into the details of the plan, let’s first talk about some factors which we considered in the plan.

Factor 1: SHA-Gate should be an asymmetric design.

It is possible to transfer BCH from Bitcoin Cash main chain to smartBCH sidechain in a trustless way (verified-by-all). But it is impossible to do it trustlessly when we reverse the direction.

Every smartBCH full client is required to connect to a trustworthy Bitcoin Cash full client to get the main chain’s blocks. Transactions that happen on the main chain, including cross-chain transactions, are verified by every smartBCH full client.

But no one has the right to require every Bitcoin Cash full client to connect to a smartBCH full client. Thus, the smartBCH-to-BCH cross-chain transactions must be signed by a group of trusted operators who witness the cross-chain requests sent at smartBCH.

Factor 2: Miners are not as willing to join smartBCH’s ecosystem as BCH holders.

There are only four smartBCH validators elected by three SHA256 miners. However, after the XHedge hard fork of smartBCH, we have seen more and more new validators, with the number of validators elected by Proof-of-Stake (PoS) still increasing.

It is likely that the SHA256 miners are not motivated to check the validity of the smartBCH-to-BCH cross-chain transfers.

Factor 3: If the smartBCH-to-BCH bridge is hacked, BCH holders on smartBCH sidechain will be impacted most.

If the UTXOs holding cross-chain BCH are stolen, the BCH holders who are on the sidechain will suffer from it directly. Some or all of them may never get back their BCH at Bitcoin Cash main chain. The BCH holders on the main chain will not be directly affected. Hence, it would make sense for the operators on the sidechain to be elected and trusted by the BCH holders.

Factor 4: Enclaves are the ideal method to protect private keys on cloud.

Hardware security module (HSM) has long been used to protect private keys. With a HSM, users can bind a private key and a device together. The key cannot be accessed unless they have access to the device. If the device is not stolen, the key likewise is not stolen.

When users use witness software that runs on a cloud server, a private key is used. However, it is not bound to anything. It exists as plain text which can be copied and leaked. Hackers who hack into a user’s cloud server can get a copy of the user’s private key even without them noticing. Data leaks can also happen at the cloud server’s administrator end, in the event of a security breach, which may lead to the theft of a private key.
An enclave can be viewed as an isolated entity that binds a private key, a designated software, and a CPU chip together. The private key is encrypted. It cannot be decrypted on a different CPU chip, nor can it be decrypted by a different software (even one-byte difference of the binary leads to a different software). The server’s administrator cannot decrypt the private key and steal it either, even if he has physical access and holds the highest security authorization of the machine.

Thus, the private key can only be used in the ways specified in the software’s source codes, and in the machine which we rent over cloud.

Factor 5: Cross-chain operators may cause more damage than validators.

Miners can reorganize a Proof-of-Work (PoW) chain, which means transactions can be canceled suddenly and replaced by other transactions. Many of such attacks have happened in history and holders were impacted from double-spending.

Validators on PoS chains, however, cannot reorganize blocks. A PoS chain’s blocks are finalized one-by-one, at a block interval of seconds. When a non-validator full client verifies a signed block, the block has been finalized. The worst that validators can do is to try to fool the light clients (but not the full clients) by double-signing, which means 2/3 of the validators have malicious intent.

Cross-chain operators sign cross-chain transactions, whose validity is not checked by full clients, because full clients only have the context of the host chain and are unable to find out what happened on a foreign chain. They must trust the cross-chain operators’ endorsement of cross-chain transactions’ validity. If the cross-chain operators violate the protocol, they are able to then steal large amounts of coins.

Factor 6: In most cases, cross-chain bridges are hacked by exploiting software bugs, instead of stealing private keys.

We analyzed six recent cross-chain security accidents that happened on Chainswap, Anyswap, Poly Network, Multichain, Wormhole, Meter.io, and Ronin Network. Five of them are caused by software bugs. Only Ronin Network had their bridge’s private keys stolen.

Thus, even if the operators are all trustworthy and vow to never collude, we are still far from being safe because the software run by operators may still have vulnerabilities.

Factor 7: If we use one unique UTXO to hold all the cross-chain BCH, it will be very hard to locate.

A UTXO is specified by a txid and a vout number and it can be spent only once. If we use just one unique UTXO to hold all the cross-chain BCH, when it is spent, we’ll have another UTXO to hold all the BCH with a different txid and a different vout number. Any cross-chain transaction, no matter whether it transfers coins from smartBCH or to smartBCH, must locate the unique UTXO correctly. When there are a lot of cross-chain transactions, the network latency will cause some of these transactions to be “double spent” upon the same UTXO. This can lead to a bad user experience.

If the unique UTXO always has the same P2SH address, it will be a bit easier for us to locate it. But a fixed P2SH address will mean that the covenant’s code and state cannot be changed, which makes voting logic impossible.

When the unique UTXO’s script has voting logic and keeps its voting state, its P2SH address will change after each voting transaction. Then the only way to trace this unique UTXO is to trace all the transactions it went through, which will worsen the user’s experience.

Based on the above factors of consideration, we have drafted a plan for SHA-Gate to be operational. We take a look at the process in two directions – “From smartBCH to BCH” and “From BCH to smartBCH“ in greater detail:

From smartBCH to BCH: cross-chain transaction constructed by operators and checked by monitors.

All BCH that have been transferred to smartBCH are held in cc-UTXOs. These cc-UTXOs are plain multisig P2SH UTXOs that can be spent by a quorum of operators.

An operator is an enclave keeping a private key and running a daemon software that traces the cross-chain transfer requests on smartBCH. Whenever it finds a valid cross-chain transfer request, it signs a Bitcoin Cash transaction and writes the signature into a smartBCH’s contract. When enough signatures have been collected from the operators, anyone can assemble the multisig transaction and broadcast it on the Bitcoin Cash main chain.

A transaction signed by operators turns a cc-UTXO into a covenant. The covenant has a specific deadline. Before the deadline, a monitor can stop the transfer and turn the covenant back into a cc-UTXO. After the deadline, the receiver of the cross-chain transfer can then spend the covenant.

A monitor is an enclave keeping a private key and running a daemon software that checks the validity of the transactions signed by operators. The monitors’ responsibility is to prevent damage when the operators’ software has vulnerabilities and is being exploited.

The operators and monitors are all elected in smart contracts on smartBCH. The operators are aware of the latest quorum of monitors, and when they sign transactions, they will encode the monitors’ public keys into the covenants. The operators are aware of the change in their quorum. When a new quorum of operators is elected, the old quorum of operators will transfer the ownership of the cc-UTXOs by turning them into new ones that can be spent by the new quorum.

From BCH to smartBCH: in a trustless way.

Alice sends a cross-chain transfer request by sending BCH to the multisig address controlled by the operators. All the smartBCH nodes will notice her transaction is finalized on the Bitcoin Cash main chain and release BCH to her on the sidechain.

To make sure all the smartBCH nodes release BCH to Alice at the same height and avoid consensus bugs, the nodes check the main chains in cc-epochs which have predefined fixed periods. When a cc-epoch has ended for N seconds, all the cross-chain transfer requests which happened during the cc-epoch will take effect together. The parameter N is large enough for all the smartBCH nodes to reach a consensus about what happened on the main chain.

Alice can also send a cross-chain transfer request by sending BCH to smartBCH’s burning address on the main chain. If the sidechain has enough burnt BCH waiting to be sent to the burning address on the main chain, Alice’s cross-chain transfer is able to finish once the current cc-epoch ends. If there are not enough burnt BCH on sidechain, Alice’s cross-chain transfer is then put in a waiting queue and will be finished in a future cc-epoch.