SHA gate means Smart Holder Authorized Gate. Before we get into the details of the plan, let's first talk about some factors that we have considered in the plan.
It is possible to transfer BCH trustlessly (verified by everyone) from the Bitcoin Cash mainchain to the smartBCH sidechain. But it is impossible to do this with confidence if we reverse direction. Each smartBCH full client needs to connect to a trusted Bitcoin Cash full client to get the main chain blocks. Transactions that take place on the main chain, including cross-chain transactions, are verified by every smartBCH full customer. But no one has the right to require every Bitcoin Cash full customer to connect to a smartBCH full customer. Therefore, the SmartBCH to BCH cross-chain transactions must be signed by a group of trusted operators who witness the cross-chain requests sent to SmartBCH.
If the UTXOs holding cross-chain BCH are stolen, the BCH holders residing on the sidechain will suffer directly. Some or all of them may never get their BCH back at the Bitcoin Cash main chain. The BCH holders in the main chain are not directly affected. Therefore, it would make sense for sidechain operators to be chosen and trusted by BCH holders.
Miners can reorganize a proof-of-work (PoW) chain, meaning transactions can be abruptly canceled and replaced by other transactions. Many such attacks have happened in history and holders have been hit with double-spending. However, validators on PoS chains cannot reorganize blocks. The blocks of a PoS chain are completed sequentially at a block interval of seconds. When a non-Validator full client verifies a signed block, the block has been completed. The worst thing validators can do is try to fool the light clients (but not the full clients) by double signing, which means that 2/3 of the validators have malicious intentions. Cross-chain operators sign cross-chain transactions, whose validity is not checked by full clients since full clients only have the context of the host chain and cannot find out what happened on a foreign chain. You must trust cross-chain operators to validate cross-chain transactions. If the cross-chain operators break the protocol, they can steal large amounts of coins.
A UTXO is specified by a txid and a vout number and can only be issued once. If we use only one unique UTXO to hold all cross-chain BCHs, when it is issued we have another UTXO to hold all BCHs with a different txid and vout number. Any cross-chain transaction, whether transferring coins from smartBCH or to smartBCH, must correctly locate the unique UTXO. When there are many cross-chain transactions, network latency will cause some of those transactions to be double-spent on the same UTXO. This can lead to a poor user experience. If the unique UTXO always has the same P2SH address, it's a bit easier for us to find it. However, a fixed P2SH address means that the covenant's code and status cannot be changed, making the voting logic impossible. If the unique UTXOs script has voting logic and keeps its voting status, its P2SH address will change after each voting transaction. Then the only way to track this unique UTXO is to track all the transactions it has gone through, which will degrade the user experience.
A transaction signed by operators turns a cc-UTXO into an agreement. The federal government has a certain deadline. Before the deadline, a monitor can stop the transmission and convert the agreement back to a cc-UTXO. After the deadline, the recipient of the cross-chain transfer can issue the agreement. A monitor is an enclave that keeps a private key and runs daemon software that verifies the validity of transactions signed by the operators. The monitor's responsibility is to prevent damage when the operator's software is vulnerable and exploited.
To ensure that all smartBCH nodes release BCH to Alice at the same level and avoid consensus errors, the nodes check the main chains in CC epochs that have predefined fixed time periods. When a cc epoch has ended for N seconds, all cross-chain transfer requests that occurred during the cc epoch take effect together. The parameter N is large enough for all smartBCH nodes to reach a consensus about what happened on the main chain.
Lead Image by Darwin Laganzon from Pixabay.