The Enhanced Random Number Generator for smartBCH
In the article "Light-weighted Manipulation-proof Random Number Generator for smartBCH", we introduced an enclave-guarded random number generator (RNG), which generates VRF outputs for smartBCH's block hashes, using a secp256k1 key that can only be accessed from within the enclave.
When using this RNG, the smart contract must fetch the block hash of a given height using the BLOCKHASH(0x40) bytecode and then verify the VRF output against this block hash with a proof that also comes from the enclave. The EVM specification limits that only recent 256 blocks can be queried for their hashes and the BLOCKHASH bytecode just returns zero for the old blocks.
This limitation causes inconvenience to DApp developers. When you want to submit the VRF output on chain as a fair random number, the corresponding block may be too old to be accessed by BLOCKHASH.
To solve this problem, EIP-2935 is proposed but it is unlikely to be accepted in the near future. So we decide to choose another solution: making the RNG endorse the relationship between the block height and the VRF of the block hash, with the enclave-protected secp256k1 key.
In the remainder of this article, we will introduce the light client concept and how the new RNG works.
Light Client
Light Clients, also known as Light Nodes or Thin Clients, are pared-down versions of full nodes. They do not download the entire blockchain but rather rely on block headers to validate transactions and world states.
RPC providers such as Infura and Quicknodes may cheat you if they turn evil. But light clients are always trustworthy as long as the blockchain's basic security assumption holds: for a PoW chain, it means more than 1/2 of the hash power is controlled by honest miners, and for a PoS chain, it means more than 2/3 of the validators are honest.
Light clients usually use a two-step scheme: validate the block headers; and prove the existence or non-existence of transactions or states against the Merkle roots contained in block headers.
Block hashes are actually block headers' hashes. So only the first step is needed for RNG.
The New RNG for smartBCH
The new RNG's workflow is as below:
Once it is started in an enclave, it gets a secp256k1 private key from EGVM's keygrantor and protects it in the enclave.
Get smartBCH's block headers from external helpers and validate them using light client technology
For a validated header, compute its hash which is also the block hash
Read the block height from the header
Compute block hash's VRF output using the enclave-protected secp256k1 private key
Generate a signature to endorse the relationship between the block height and the VRF output, using the same private key
The VRF outputs are generated in exactly the same way as the old RNG. So the DApps that rely on the old RNG can work just fine without modification. New DApps can use the signature to validate the VRF of blockhash at a given height, thus the BLOCKHASH bytecode is no longer needed.
The DApps know the EVM address computed from the RNG's secp256k1 private key. This address is determined by the RNG's binary code. If the code is changed, the enclave will generate a different private key and the DApps can discover this mismatch easily.
Reference
Light-weighted Manipulation-proof Random Number Generator for smartBCH **https://read.cash/@SmartBCH/light-weighted-manipulation-proof-random-number-generator-for-smartbch-79ac7d36**
EIP-2935 **https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2935.md**
The Ultimate Guide to Blockchain Light Clients **https://www.nervos.org/knowledge-base/ultimate_guide_to_light_clients**
SmartBCH Symbol Change Upgrade on 1st Feb
In last post, we introduced smartBCH’s symbol-change upgrade. This upgrade will be activated at height 13627300, on about 1st Feb. If you are running a smartbchd node, please update your binary to the latest version v0.6.0.
This latest version has following features:
1. At height 13627300, change the native token’s symbol to SBCH and change its name to SmartBCH
2. At height 13627300, change the native token’s totalSupply to 68313.420483504311319128 SBCH
3. At height 13627300, clear the SBCH balance of 0x8c4F85ec71C966e45A6F4291f5271f8114a7Ba15 (the old and disabled bridge address that was once controlled by CoinFLEX)
4. Optimized the performance of the transaction engine in the case of transactions accessing conflicting storage slots.
SmartBCH Symbol Change Upgrade and Total Supply Reduce
At present, the SmartBCH Alliance is dedicated to maintaining a 1:1 peg between smartBCH’s Native Token and the main chain BCH. This peg is primarily upheld by the benevolence of certain sBCH holders who opt not to sell their assets. Nevertheless, the assets held by the Alliance fall short of fully meeting the withdrawal requirements of all smartBCH's native token holders looking to transfer their funds to the main chain. Therefore, the Native Token on smartBCH is NOT a homogeneous asset of BCH. Given this reality, we believe it's crucial to transparently communicate potential risks to smartBCH users.
As a result, the smartBCH chain will undergo an upgrade to change the symbol of the native token from "BCH" to "SBCH" through a hard fork upgrade. Simultaneously, its name will transition from "BCH" to "SmartBCH". The total supply of SmartBCH is 68,313.420483504311319128 SBCH, of which 573.20 SBCH already burned. The balance of the bridging account holding more than 20 million sBCH will be cleared permanently.
For more detailed information, please refer to https://www.smartscout.cash.
More about the Staking Upgrade
We introduced smartBCH's staking upgrade on Jul 17. This staking upgrade will be activated at height 11006000, about 15 Aug. This article explains more details of this upgrade.
What will be upgraded?
A validator must stake no less than 32 BCH.
The PoW hashrate election will be disabled. The PoS election through the xhedge contract is the only way to become a validator.
Double-sign Slashing: a validator will be slashed 8 BCH if it signs multiple blocks at the same height.
Offline guard: the smartbchd clients will count each validator's signed blocks in small fixed 100-block windows; if a validator's signed blocks are less than 5, its voting power will be lowered to 1/10 of its normal power temporarily, until it signs enough blocks. During this process, the validator is not slashed
Offline slashing: the smartbchd clients will count each validator's signed blocks in large fixed 14400-block windows (about 24 hours); if a validator's signed blocks are less than 8640, it will be slashed 2 BCH.
The Details of Slashing
A validator will be slashed for the following cases.
**Long-time Offline**
The smartbch's blocks are divieded into successive non-overlapping 14400-block observing windows (about 24 hours). In each observing window, if a validator signs less than 8640 blocks (about 16 hours), it is considered as offline. Then the smartbchd clients will slash this validator at the end of the observing window: all the pending rewards of this validator and 2 BCH out from its staked BCH will slashed and sent to the slashed-coin receiver. And it will also lose its role as a valiator immediately, i.e., clear its voting power to zero. The left staked BCH of the slashed validator will be returned at the end of the next epoch.
Offline slashing is relatively easy to be triggered. If your valiator's machine is down for 8 hours within a 24-hour window, it will be slashed.
If your validator's machine is down and cannot be recovered, you can call the `retire` function of the staking contract to avoid the slashing before the end of the observing window. We will provide a UI for calling `retire` at https://assets.smartbch.org/staking-frontend/.
The 100-block small observing windows ensures the smartbch network is still stable even when multiple validators get offline one after another. 100 blocks is about 10 minutes. When a validator gets offline for about 10 minutes, its voting power is reduce to 1/10 of its normal value. If 34% of the validators get offline one after another, finally the lost voting power will be `66/(66+3.4)=4.9%`.
If smartbch is not protected by these small observing windows, the offline validators must be recovered as soon as possible because the accumulated voting power of offline validators must not exceed 66%. When smartbch is protected by these small observing windows, the recover time of the offline validators is allowed to be a bit longer, so we choose a 24-hour time window.
**Double-Signing**
If a validator signs two smartbch blocks at the same height, then the smartbchd clients will slash this validator immediately: all the pending rewards of this validator and 8 BCH out from its staked BCH will slashed and sent to the slashed-coin receiver. And it will also lose its role as a valiator immediately, i.e., clear its voting power to zero. The left staked BCH of the slashed validator will be returned at the end of the next epoch.
Double-signing is relatively hard to be triggered. If you do not copy your validator's consensus key to no less than one machines and run these machines at the same time, it will never be triggered.
What to do next
Currently, only the matrixport validator packs blocks and the other valdiators are temporarily disabled. The smartBCH side chain is working in a single-validator mode now.
After height 11006000, the new staking logic will be activated and the current validators should stake no less than 32 BCH in the epoch between height 11006000 and 11207601 (about 26 Aug, 2023). If you want to register a new validator, you should also stake no less than 32 BCH after height 11006000. You can stake exactly 32 BCH, or any value above that (33 BCH, 32.001 BCH, etc).
After height 11207601, all the validators with 32 BCH staked will take charge and smartBCH will exit the single-validator mode.
To vote for a new validator using locked BCH, you need to interact with the xhedge smart contract. The UI of xhedge.cash can help you. https://xhedge.cash/
To register a new validator and stake BCH, you need to interact with the staking smart contract. The UI of staking-frontend will be updated to support the new functions after this upgrade. https://assets.smartbch.org/staking-frontend/
If you are running a smartBCH node, please update to the latest v0.5.1. You can build its binary from the source or simple download its docker image using `docker pull smartbch/smartbchd:v0.5.1`. https://github.com/smartbch/smartbch/releases/tag/v0.5.1
How to Run an AtomicSwap Market-Making Bot
Running a Market-Making Bot can help maintaining the 1:1 peg between BCH and SBCH and get some earnings. We have tried our best to make it robust and secure. This article introduces how to run it in a robust and secure way.
Parameters
First of all, you need to decide some parameters which your bot and its counterparties must abide by. They are:
bch-lock-time: how many bch blocks must go by before a locked fund can be refunded. Recommended value: 144, which means 24 hours.
penalty-bps: if the counterparty failed to unlock the fund, it will be slashed with a penalty (in base points). Recommended value: 100-500 (1% - 5%).
fee-bps: the counterparty will be charged with a fee for a successful swap (in base points). Recommended value: 10 - 30 (0.1% - 0.3%)
min-swap-amt: the minimum amount for a swap. Recommended value: 0.01~0.1BCH
max-swap-amt: the maximum amount for a swap. Recommended value: 1~10BCH
bch-confirmations: the minimum confirmations that a BCH mainchain locking transaction must reach before it can be served by your bot. Recommended value: 6~10.
Prepare a cloud machine and start full node clients
It's suggested to run a bitcoincashnode full-node client and a smartbchd full-node client on your own cloud machine, which provide trustworthy information to your bot. An azure instance DC2sv3 with 16GB ram will be a best fit because it also supports SGX. The bot can work in an SGX enclave for better protection of your private keys. The clients need about 600GB SSD space.
If you do not want to use an SGX instance because it's more expensive, any machine with 16GB ram and 600GB SSD will do.
Then you can start bitcoincashnode and smartbchd. https://docs.bitcoincashnode.org/doc/ https://docs.smartbch.org/smartbch/mainnet#docker
Prepare accounts on the mainchain and the sidechain
The bot uses a mainchain account and a sidechain account to send transactions. So you must prepare these accounts' private keys and send some BCH to them.
It's suggested to use ElectronCash to generate the WIF private key for the mainchain account and use MetaMask to generate the HEX private key for the sidechain account. For both of these two wallets, you can use the same mnemonics. https://electroncash.readthedocs.io/en/latest/old/cmdline.html#export-private-keys-and-sweep-coins https://support.metamask.io/hc/en-us/articles/360015289632-How-to-export-an-account-s-private-key
After you get the WIF private key from ElectronCash, please use following command to get the public key of the mainchain account:
git clone https://github.com/smartbch/atomic-swap-covenants.git
cd atomic-swap-covenants
npm i
MAINNET=true ts-node scripts/htlc.ts user-info --wif=<WIF-from-ElectronCash>
The `pkh` line of the output is what you will need.
The mainchain account's address must be imported into the bitcoincashnode client through its RPC. Please run the following command on your cloud machine: https://docs.bitcoincashnode.org/doc/json-rpc/importaddress/
curl --user user:pass --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "importaddress", "params": ["bitcoincash:xxx", "asbot", true] }' -H 'content-type: text/plain;' http://localhost:8332/
Register your bot to the HTLC smart contract
The HTLC smart contract was deployed at 0x4dec1a09269DaDbAfBDBAF34A4cc224eCC1Bdc42. Its source code was opensourced here. https://github.com/smartbch/atomic-swap-contracts/releases/tag/v0.1.0
When it was deployed, the constructor set the following parameters:
minStakedValue = 1BCH. You must stake one BCH into the contract when registering a bot and can take it back after retiring.
minRetireDelay = 48 hours. You must wait for 48 hours after retirement before you can take back your staked BCH.
Staking BCH prevents evil guys from spaming the HTLC smart contracts by registering unworkable bots.
Please make sure your bot's side chain account has at lease 1.01 BCH and then use the following commands to register your bot to the HTLC smart contract:
git clone https://github.com/smartbch/atomic-swap-contracts.git
cd atomic-swap-contracts
npm i
KEY=<EVM-private-key-from-MetaMask> \
HARDHAT_NETWORK=sbch_mainnet node ./scripts/htlc.js register-bot \
--signer=0 \
--htlc-addr=0x4dec1a09269DaDbAfBDBAF34A4cc224eCC1Bdc42 \
--intro=MyBotIsTheBest_or_you_can_write_something_else \
--pkh=<the-public-key-hash-that-you-got-in-the-last-step> \
--bch-lock-time=144 \
--penalty-bps=200 \
--fee-bps=10 \
--min-swap-amt=0.01 \
--max-swap-amt=1.0 \
--staked-val=1.0 \
--status-checker=<An-EVM-account-that-can-mark-your-bot-as-unavailable>
You can use an account as your bot's status checker that watches whether your bot is online. When it finds that your bot is unavailable, it will send a transaction to the HTLC contract to mark your bot's status as "unavailable" such that users will not trade with it. If you do not need this feature, just set status checker to the same address as your bot.
Start Your Bot
Now you can start your bot on the cloud instance:
git clone https://github.com/smartbch/atomic-swap-bot.git
cd atomic-swap-bot
ego-go build github.com/smartbch/atomic-swap-bot/cmd/asbot
ego sign asbot
mkdir data
ego run asbot \
--db-file=/data/bot.db \
--bch-rpc-url=http://localhost:8332 \
--sbch-rpc-url=http://localhost:8545 \
--sbch-htlc-addr=0x4dec1a09269DaDbAfBDBAF34A4cc224eCC1Bdc42 \
--sbch-gas-price=1.05 \
--bch-confirmations=10 \
--bch-lock-fee-rate=2 \
--bch-unlock-fee-rate=2 \
--bch-refund-fee-rate=2 \
--sbch-lock-gas=500000 \
--sbch-unlock-gas=500000 \
--sbch-refund-gas=500000 \
--debug=false
Here we set the miner fee rate to be 2sat/byte. You can lower it to 1sat/byte as well.
The above `ego run asbot` command will output something like this to the console:
EGo v1.3.0 (360a6a40836461465fdbd0742dfb0f980b68c638)
[erthost] loading enclave ...
[erthost] entering enclave ...
[ego] starting application ...
The ecies pubkey: 03052743d278846f90cedb64282a3ea3db20a8414b627e4aff3dc5408110073eed
Enter the encrypted BCH WIF:
It needs you to encrypt the BCH WIF private key and the EVM hex private key on you local computer and input the encrypted keys on the cloud machine's console.
On your local computer, run the following command:
go run github.com/smartbch/atomic-swap-bot/cmd/encrypt
It asks you to input the ecies pubkey generated by the above `ego run asbot` command, your bot's WIF private key and its EVM private key. After your input these data to it, it will output the encrypted WIF key and EVM private key as hex strings. Copy and enter them to the `ego run asbot` command's prompt, and then your bot will decrypt the keys and use them to sign transactions.
Your bot will keep the private keys only in its memory. If it works in an SGX enclave, the private keys are impossible to be stolen from the protected memory.
Start Slaves for Your Bot (optional)
If your bot's cloud machine panics, it may miss the time window for unlocking funds and lose coins. To further secure your funds, you can use one or more slaves to help your bot. Every slave watches the counterparties' secret-revealing transactions independently. If your bot failed to unlock funds ten minutes after secret-revealing, a slave will send a transaction to help your bot unlock the fund.
It's good for a slave to have its own bitcoincashnode client and smartbch client. To start a slave, please use the following command:
git clone https://github.com/smartbch/atomic-swap-bot.git
cd atomic-swap-bot/cmd/asbot
go build .
./asbot \
--debug=false \
--db-file=bot.db \
--bch-rpc-url=http://localhost:8332 \
--sbch-rpc-url=http://localhost:8545 \
--bch-master-addr=bitcoincash:qz0ypj3acm80ve9qpzdy4rm7s9k0u7zrpu6nzfzgyh \
--sbch-master-addr=0xd7d00B26Eac76f1c8B646442ECBfb33201842149 \
--sbch-htlc-addr=0x4dec1a09269DaDbAfBDBAF34A4cc224eCC1Bdc42 \
--sbch-gas-price=1.05 \
--bch-confirmations=0 \
--bch-lock-fee-rate=2 \
--bch-unlock-fee-rate=2 \
--bch-refund-fee-rate=2 \
--sbch-lock-gas=500000 \
--sbch-unlock-gas=500000 \
--sbch-refund-gas=500000 \
--slave=true
Where the `bch-master-addr` and `sbch-master-addr` are the addresses of your bot's mainchain account and side chain account.
An Introduction to the Market-Making Bot for Atomic-Swap
To give members of the community a convenient and secure tool to maintain a 1:1 peg between BCH and SBCH, we have developed several tools based on AtomicSwap. The most important of these tools is the Market-Making Bot.
The Bot compensates for the usability shortcomings of the AtomicSwap protocol, which requires both parties to be online at the same time to complete the transaction. For non-professional users, being online all the time is impossible. Having both parties agree to be online at the same time makes matchmaking very difficult. The cross-chain scenarios served by AtomicSwap are naturally unable to automate the execution using means like an order book and AMM pool. Third-party custodian solutions like CEX are available but again go against the trustless principle that AtomicSwap adheres to.
The Market-Making Bot controls a private key. It is always online and readily available to non-professional users, thus avoiding difficult matchmaking.
In the AtomicSwap protocol, the roles of the two parties in a transaction are not reciprocal, but one party plays the "maker" role and the other party plays the "taker" role. The flow is as follows:
1. The maker announces an offer to swap coins through a certain smart contract.
2. The taker accepts the offer and deposits the tokens to be handed over to the maker into the Hashed Timelock Contract (HTLC) on the A blockchain.
3. The maker notices the toker's acceptance of the offer and deposits the token to be given to the taker in HTLC on the B blockchain.
4. The taker retrieves the coins from the HTLC on the B blockchain, which reveals the HTLC's hash preimage.
5. The maker uses the same hash preimage to retrieve the Token from HTLC on A blockchain.
The Market-Making Bot is always online, and it plays the role of the maker described above. It publishes its on-chain address, introduction, the validity period of one swap, fee rate, penalty ratio, and other information in the contract on smartBCH. At the same time, it holds a certain amount of BCH and SBCH on both BCH mainchain and smartBCH sidechain, the amount of which is publicly available. The coins it holds are the offer it gives to takers. Anytime, as long as the Bot has enough coins on the sidechain, takers can execute step 2 above on the mainchain, and vice versa. In step 2, to successfully complete the subsequent swap, the taker needs to provide the following information via OP_RETURN (on mainchain) or EVM Log (on sidechain):
1. The address of the Bot. There may be more than one Bot providing services to takers, and the on-chain address is needed to distinguish which one it is.
2. Taker's address
3. The hash lock
4. The expiration time of this Swap. It must meet the Bot's requirement of swap expiration time, otherwise, the Bot won't respond to this request.
5. The penalty ratio. It must be the same as the penalty ratio announced by the Bot, otherwise, the Bot will not respond to this request.
To provide service to takers, the Bot needs to use its funds, that is to say, it gives up the opportunity to utilize these funds to generate interest in other ways. Furthermore, Bot runs on cloud servers, which also incurs costs. Therefore, it makes sense for Bot to charge a percentage of the swapped assets as a fee.
AtomicSwap's trustless guarantee means that neither the taker nor the maker can embezzle the other's assets, while there is no guarantee that the swap will always be successful. Both the taker and the maker may pay the miner fee or gas fee for nothing but fail to complete the swap because of the other's non-cooperation. The Bot's inability to complete the swap due to subjective or objective reasons may cause the maker to lose its credibility, resulting in no taker being willing to trade with it at the end, which defeats its purpose of earning fees by providing services over a long period. Therefore, it is reasonable to believe that the Bot is unlikely to fail to cooperate with Taker because of subjective malice. On the contrary, takers do not need to maintain a better quality of service in the long run to accumulate credibility. Because they are anonymous, even intentional sabotage is difficult to trace. Based on these considerations, we do not penalize interaction failures caused by the Bot, while forfeiting a certain amount of money for transaction failures caused by takers, to avoid Bot suffering from ineffective use of funds due to attackers.
We will release the first version of the Market-Making Bot in a couple of days. If you'd like to help maintaining the 1:1 peg between BCH and SBCH, please consider run a Market-Making Bot, which can also bring fee earnings to you. If operating a Market-Making Bot looks too complex to you, just trading with a Bot is also helpful: when a Bot's SBCH pool is larger and BCH pool is small, you can swap BCH for SBCH with it, and then the pools will be more balanced.
SmartBCH will apply the staking upgrade
In the past, when applying to become a smartBCH validator, it was possible to stake a certain amount of BCH, but the lower bound of this amount can be as low as zero. At the same time, the amount of punishment for a validator's failure is limited to the rewards of the current epoch, and additional penalties are set to zero. This low-requirement strategy has attracted people to run smartBCH validators, but since there is no penalty, validators do not incur any financial losses even if they are running on servers that are not very reliable or are not well managed. This led to the instability of smartBCH. So we had to change this strategy. Also, the participation of PoW Hash Power in the election of Validators could also lead to instability because BCH's hash power relative to BTC is too low, and it's not hard for an attacker's validators to take up more than 1/3 of the voting power.
SmartBCH will be upgraded with a hard fork at height 11006000 (around August 15), and the following updates will be activated:
1. When applying to become a validator, it must STAKE at least 32BCH, and now those who are already validators need to increase its staked amount to 32BCH.
2. In case of a double-signing failure, you will be fined 8 BCH and lose your validity as a validator immediately.
3. If the number of signed blocks is less than 4320 out of 7200, it is considered to be an offline failure, and you will be fined 2BCH, and will be immediately disqualified as a validator.
4. Validator can no longer rely on PoW hash power to be elected, i.e. switching to full PoS.
If you wish to be elected as validator at the time of this hard fork, please STAKE enough SBCH before August 15th and contact us. Although smartBCH does not have a block reward similar to the main chain, we would like to try our best to give node operators enough incentive through community donations and other means. Please contact us for details.
This staking strategy is implemented in smartbch's v0.5.0-pre1 version. Please help us review the code. If you have any suggestions to optimize the staking strategy or tune the parameters, please let us known. We hope to reach consensus before August 15 and leave the current single-validator mode. https://github.com/smartbch/smartbch/releases/tag/v0.5.0-pre1
Thank you for your support and understanding, the smartBCH DEV team will continue to maintain and optimize the smartBCH ecosystem.
Emergency recover of smartBCH
We have developed an emergency patch to restart smartBCH using a single-validator mode. It’s an interim solution before we finish the real patch which raises the validators’ requirement by adding staking and slashing amounts.
A low requirement for validators is good for smartBCH to have more validators. SmartBCH has 28 validators before today’s halt accident, who can only get a limited gas fee as a reward in such a bear market. But the quality is more important than the quantity. So we must go forward and make sure all the validators are well managed using economic methods.
The RPC server **https://rpc.smartbch.org** has been recovered already.
If you are running a smartBCH node, no matter whether it is a validator or not, please use the following steps to recover it. We apologize for the inconvenience again and thank you for your cooperation.
# pull latest smartbchd image
docker pull smartbch/smartbchd:v0.4.7-p1
# make sure the version is v0.4.7-p1
docker run --rm smartbch/smartbchd:v0.4.7-p1 version
# stop the container/node
# replace 'sbchd' with your container name
docker stop sbchd
docker container rm sbchd
# clean up node state
# replace '~/.smartbchd' with your smartbchd home dir
cd ~/.smartbchd #
rm -rf data/cs.wal/
rm config/addrbook.json
# modify data/priv_validator_state.json, change it to
{
"height": "10319606",
"round": 0,
"step": 0
}
# restart container/node like this
sudo docker run \
-v ~/.smartbchd:/root/.smartbchd \
-p 0.0.0.0:8545:8545 \
-p 0.0.0.0:8546:8546 \
-p 0.0.0.0:26656:26656 \
--ulimit nofile=65535:65535 \
--log-opt max-size=200m \
--name sbchd \
-d smartbch/smartbchd:v0.4.7-p1 start --mainnet-genesis-height=698502 \
--log_level='json-rpc:debug,watcher:debug,*:info' \
--http.api='eth,web3,net,txpool,sbch,debug'
We need to refine the voting scheme of smartBCH
It is always easy to be a smartBCH validator. We kept the requirements low to invite more people to run smartBCH validators. For PoW votes, you only need to mine one BCH block during an epoch of 2016 blocks. For PoS votes, you only need to accumulate 500 Coindays on the smartBCH sidechain.
During the last bull market we had 35 validators and now we still have 28 validators. Although this is good for decentralization, it has also caused problems. Some validators are not running on stable machines with good internet connection. Maybe this is because the reward of validators is limited and they can not afford a good cloud infrastructure. Either way, the unstable validators make the smartBCH unstable.
Today, smartBCH halts because of some offline validators. And we can not reach enough validators and work with them to restart smartBCH.
In the short term, we will restart smartBCH with an emergency patch that uses a single validator to generate new blocks.
To stabilize the sidechain in the long term, we will soon perform a hard fork upgrade to increase the requirements to be elected as a validator. With higher requirements, there will likely be fewer validators, but this is helpful to ensure that validators are run by serious parties who really care about the sidechain.
We apologize for the inconvenience caused by the current low-requirement voting sche me We will write an article soon to explain the new voting scheme.
An Introduction to the AtomicSwap Tool
In order to provide community members with a convenient and secure tool for swapping between BCH and SBCH, several tools based on AtomicSwap have been developed and will soon be launched.
AtomicSwap is an effective tool to address the liquidity issue between the main chain and the sidechain of BCH. Using the AtomicSwap tool, the SPV can assist many sidechain users in converting their SBCH to BCH on the main chain, or vice versa.
AtomicSwap is a well-established method for swapping tokens across blockchains, enabling two parties to exchange assets on both chains. Strictly speaking, AtomicSwap is not a “cross-chain bridge” as it does not alter the total amount of tokens on each chain, nor can it generate new coins on the sidechain in the BCH/smartBCH scenario, nor can it burn coins on the sidechain and reissue them on the main chain.
AtomicSwap does not require trust in any centralized third party, and the two trading parties do not need to trust each other either. While bridges hold assets on behalf of others, a swap service does not provide custodial services, and users of a swap are not exposed to the same counterparty risk as bridge users. The two parties involved are the market-making bot on one side and the regular users on the other. Besides the SmartBCH Alliance, anyone can run a market-making bot since AtomicSwap is a permissionless protocol and the market-making bot code is open source.
We appreciate the patience and support of the community and hope that you will continue to assist us in reviewing and enhancing this tool. The underlying smart contract and covenant code can be found in these repositories:
**https://github.com/smartbch/atomic-swap-covenants**
**https://github.com/smartbch/atomic-swap-contracts**
The code for the market-making bot is available at
**https://github.com/smartbch/atomic-swap-bot**
The code for the front-end UI can be found at:
**https://github.com/smartbch/atomic-swap-frontend**
Coinflex Distributions Update
Dear SmartBCH users,
As of today, SmartBCH Alliance Limited (the “SPV”) has received the following distributions from Coinflex:
4,281,291.42 rvUSD, received by 0x0C7a57e8dfDb8e810DeD7A03B27EfBa46b9cAD7f
651,928.02 USDC, received by 0x0C7a57e8dfDb8e810DeD7A03B27EfBa46b9cAD7f
6,834.015 BCH, received by pp9xzxg4re07pdtkm5v2zdwjx2c6z6qnj5jnu6f6d9
Out of the 651,928.02 USDC received, 521,542.4 USDC(80%) has been swapped into 3,924.84 BCH and then transferred to pp9xzxg4re07pdtkm5v2zdwjx2c6z6qnj5jnu6f6d9, the remaining 130,385.62 USDC is reserved for legal and other operating expenses for the SPV. The SPV owns 10,758.86 BCH so far.
The SPV is opening an account in OPNX and will gradually swap rvUSD into BCH in the exchange.
Also, Coinflex has burned 33,365.67 sBCH back to the old bridge address 0x8c4F85ec71C966e45A6F4291f5271f8114a7Ba15. Now there are 67,756.766 sBCH in circulation on smartBCH.
According to the terms of restructuring approved by Seychelles Courts, the SPV shall be entitled to but haven’t received the following assets from Coinflex:
Common equity of Coinflex, which will be a pro rata share of the creditor allocation.
One board seat of Coinflex
According to Coinflex, they are still undergoing the legal process for restructuring. We will give an update once there is any major progress.
The SPV has entered into an agreement with Coinflex, in which the SPV will take over the responsibilities of maintaining the 1:1 peg between sBCH and BCH using all the assets owned by the SPV. However, as can be reasonably expected, there will be risk of failing to maintain such peg due to the discrepancy between the assets owned and the circulating sBCH. However, by receiving the assets from CoinFlex, the peg of sBCH:BCH is safer than not having receiving it, before which the peg has been remained well by the community.
We would like to express our sincere gratitude to the all the support given by the community, without any of you we wouldn’t have been able to come so far.
Overlooker: an enclave-based oracle for blockchain events
In cross-chain and mulit-chain applications, a fundamental component is an oracle that endorses the events that happened on a remote chain.
Traditionally, oracles use quorum-based schemes to ensure trustworthy outputs. Quorum is a group with a limited number of elected or appointed members. We trust that most of them are honest because:
1. They have proved their honesty in other affairs.
2. They have acted as oracles for a long time and have a good record and reputation.
3. Some economic arrangement rewards their honesty and punishes dishonesty.
However, as long as the quorum's members are human beings, someday a member may do evil because of corruption or violence coerce. Weaknesses of human nature cannot be overcome thoroughly.
Overlooker is a new kind of oracle that uses hardware to minimize the effect of human factors. For a given task, anyone can operate an overlooker instance and act as an oracle. The number is not limited. Operating an overlooker is permissionless. And every overlooker will output exactly the same result.
In this article, we will first introduce the underlying technologies that overlookers are based on. Then we describe the overlooker's implementation details. Finally, we discuss how to integrate overlooker into a cross-chain message-passing application.
## Background
### Enclaves
An enclave is a territory that is entirely surrounded by the territory of one other state or entity. In computer science, the term "enclave" is a trustable execution environment surrounded by untrustable hypervisor, OS, and other applications.
Hardware and firmware ensure that an enclave has the following features:
1. Integrity: a program in the enclave executes precisely as its source code specifies, no party can tamper with it, even the hypervisor and/or OS under it. A hacker or evil administrator with privilege cannot change how the code runs.
2. Isolation: the program(s) executing context (registers status and DRAM status) cannot be viewed or changed by any other party, even the hypervisor and/or OS under it.
3. Data sealing: the data written to persistent storage from the programs in an enclave are encrypted and can only be decrypted in the enclave later.
4. Attestation: after hardware-assistant measurement of the program running in an enclave, the hash digest of the measurement and some internal data can be signed by a key kept by hardware to convince the relying parties that it IS the predefined trustable program running.
Currently, the cloud-computing vendors provide three different kinds of enclaves: Intel SGX, AMD SEV-SNP, and AWS Nitro Enclaves. Intel SGX has the longest history and the most mature ecosystem.
### Full-node clients for blockchains
Full-node clients help you to verify the transactions and check the events/states. If you want to cheat someone running a full-node client for a PoS blockchain, you have two choices:
Choice#1: replace this full-node client's binary with a fake one, and
Choice#2: fulfill the following two tasks:
1. Collude with more than 2/3 of the blockchain's validators and make them sign fake blocks.
2. Let his full-node client only connect to the witch nodes controlled by you in the P2P network. These witch nodes will broadcast the fake blocks to his full-node client.
If the full-node client is running inside an enclave, the "integrity" and "attestation" features prevent you from manipulating its binary. So choice#1 is impossible.
If the full-node client is running on the cloud, the cloud vendor's network is very hard to attack. And bribing the validators to corrupt 2/3 of them is almost a "mission impossible".
So a full-node client running in an enclave provided by cloud-computing vendors is highly reliable. It's the best data source for remote chains' events.
### NaaS Providers
A Node-as-a-Service(NaaS) provider runs many full-node clients and its customers pay to access these clients' RPC endpoints.
Although NaaS providers usually use plain compute instances instead of enclave-enabled compute instances, they have a good reputation and practice to protect full-node clients from manipulation.
We can view the NaaS provides as the second-best data source for remote chains' events.
## Implementation
We use [EGVM](https://github.com/smartbch/egvm) (enclave-guarded virtual machine) to implement the overlooker. EGVM is a javascript virtual machine running inside enclaves. Currently, it only supports SGX enclaves.
The key feature of EGVM can be summarized as "code is private key". We all know the catchphrase "code is law", which means the consensus is encoded in the source code and enforced by the community. The catchphrase "code is private key" means an overlooker can use a unique private key that is derived from this overlooker's code.
This private key is bound to the code. It will change if the code changes. This private key is protected inside the overlooker's enclave. The external world cannot access it.
If the enclave hardware and the EGVM software are built correctly and bug-free, you can be sure that whenever you see a signature signed with the code-derived private key, it is signed by the code.
### KeyGrantor
KeyGrantor is a supporting component for EGVM. A KeyGrantor enclave holds a BIP32 extended private key (xprv). which is generated by the CPU's TRNG (true random number generator) or granted from another KeyGrantor enclave.
When you start a KeyGrantor enclave, if an upstream KeyGrantor is specified, it will connect to the upstream one and use an attestation report to prove that both of them have the same program (the measurements are identical). The upstream one checks the proof is correct before sending the xprv key to your KeyGrantor through a TLS channel. If no upstream KeyGrantor is specified, the KeyGrantor started by you will generate a new xprv key using TRNG, which can be granted to other KeyGrant enclaves later.
Using this method, one KeyGrantor can be "cloned" to many identical ones, which hold the same xprv key and has the same functionality. Anyone can get a cloned KeyGrantor, so it's totally permissionless.
### EGVM Script Engine
EGVM Script Engine is the core component of EGVM. It executes javascript code inside an enclave and this code can sign messages using a derived private key, which is granted by a KeyGrantor.
When we talk about "code is private key", the term "code" means the following parts:
1. The program (binary executable) of EGVM Script Engine.
2. The javascript code that EGVM Script Engine executes.
3. A json configuration that the javascript code reads in its initialization phase.
Before the script engine executes the javascript code, it sends the KeyGrantor an attestation report which contains the hash digests of all three parts. The KeyGrantor will derive a secp256k1 private key using the xprv key and these digests and send it to the script engine through a TLS channel.
The KeyGrantor discloses its BIP32 extended public key (xpub) and the script engine discloses the code's secp256k1 public key. Given the code's three parts, anyone can verify the code's secp256k1 public key against the xpub key.
### Witness Mode and Falsification Mode
Overlooker oracles are implemented with javascript and run in EGVM Script Engine. To prevent the damage caused by corrupted data sources and possible bugs in KeyGrantor/EGVM/Overlooker, the implementation must support two modes: witness mode and falsification mode.
In the witness mode, the overlooker endorse "the event is true" if and only if: the majority of data sources must be available and all the available data sources must all agree that the given event did happened on a remote blockchain.
In the falsification mode, the overlooker endorse "the event is false" if and only if: a minority of data sources all agree that the given event did NOT happened on a remote blockchain.
This is an asymmetry design. It is much easier to get a falsification signature than a witness signature. We can stop the application in emergency using a falsification signature even if:
1. the majority of data sources are corrupted and only a minority is honest
2. there is a severe bug in KeyGrantor/EGVM/Overlooker and the attackers can use the derived signature to sign any event.
## Integration
We can only get witness signatures and falsification signatures from overlookers. There is still a gap from a usable application. To integrate overlookers in applications, we need more roles to participate.
Let's take message channels as an example application. A message channel is a smart contract from which other contracts can read events that happened on a remote blockchain. To make it reliable, the following roles are necessary.
Auditors. The auditors review the source code of KeyGrantor and EGVM, as well as the javascript code that implements the overlooker, making sure there is no bug in them.
Configurator. The configurators vote to decide:
1. Which audited implementations of KeyGrantor/EGVM/Overlooker should be used by this message channel
2. What is the content of json configuration. The domain names, TLS certifications and other information of the selected data sources are encoded in the json configuration.
Because "code is private key", the configurators actually endorse the private key used by the overlooker oracle.
Relayer: a relayer runs an overlooker and uses the witness signatures to write events into the message channel. These events will undergo a cooling-down period before they can be read by other contracts.
Challenger: a challenger runs an overlooker and uses the falsification signature to falsify events in their cooling-down period. Once an event is falsified, this message channel is stopped in emergency.
The configurators must analyze why the event is falsified. If the reason is a bug in KeyGrantor/EGVM/Overlooker, they will switch to a patched implementation. If the reason is some corrupted data sources, they will write a new json configuration. When the problem is fixed, they will endorse a new private key for the overlooker and restart this message channel.
Relayers can be anyone, so the message channel has liveness: nobody can stop it from working. Challenger can be anyone, so the message channel has correctness: any stakeholder of the message channel can falsify a fake event.
A whitehat hacker protects smartBCH by reporting a vulnerability
Recently, a whitehat hacker pwningpwnwpnw reported a vulnerability in smartbchd.
The vulnerability is located in MoeingEVM's `host_bridge`. It is a bug in the C++ implementation of SEP206. The overflow condition of `amount+margin` was not checked.
This is a severe vulnerability which allows an attacker to mint infinite BCH on the side chain and drain all the tokens in Swap's pairs. If that happend, the only thing we can do is to hardfork smartBCH, just like what Ethereum did after "the DAO hack".
To patch this vulnerability, we did the following modification:
1. Add more checks to `host_bridge`
2. Add abort-on-overflow logic to `host_bridge`
3. Make abort-on-overflow logic to smartbch's golang code
4. Invalidate all the transactions which finish with one or more accounts with more than 21,000,000 BCH.
The latest smartbchd 0.4.7 is the patched version. If you have not updated your node's binary, please update it.
To show our appreciation to pwningpwnwpnw the whitehat and to thank him for protecting the smartBCH sidechain, we the dev team would like to reward him with 150 BCH. We only got 1000 BCH in our 2021 flipstarter, so this is the best we can do.
But these 150 BCH cannot match pwningpwnwpnw's contribution. We hereby call on the BCH and smartBCH supporters to donate more BCH as pwningpwnwpnw's reward. Your donations will show the community's unity and strength. Please kindly send your donations to the whitehat's addresses: 0x1Aa2FC6E54838C5b1a8d5bD052484De56D485822 bitcoincash:qretmzu6nrs2cc88kw053jw7lsru57qteue7a3s6my.
Some BCH enthusiasts are going to set up a foundation to raise funds to boost the smartBCH ecosystem. They have promised that if they succeed, some of the raised funds will also be rewarded to pwningpwnwpnw, and a bug bounty program will be set up.
Thanks again to all the supporters. We will continue to develop smartBCH to make it a more secure and powerful chain.
Comments on CoinFLEX’s Restructuring Proposal
The CoinFLEX’s restructuring proposal will be voted on very soon. After reviewing the documents provided by CoinFLEX and consulting with our lawyers, SmartBCH Alliance decides to support this scheme of the arrangement upon certain conditions which have been verbally agreed by CoinFLEX. Our lawyers are working with CoinFLEX to reflect the following conditions into the formal agreement: https://coinflex.com/blog/coinflex-vote-token-issuance-and-next-steps/
Since the CoinFLEX’s depositors did withdraw 10% of their deposit assets in July, shortly after it closed the withdrawal channel, SmartBCH Alliance requests to have the same right and to be traded fairly as the other creditors. That means in addition to the pro rata distributions to be received by SmartBCH Alliance as a creditor of CoinFLEX, SmartBCH Alliance will also receive 10% of its claim in BCH.
CoinFLEX still controls 33K SBCH on smartBCH chain. SmartBCH Alliance is asking CoinFLEX to formally promise to burn these SBCH to the bridge address(0x8c 4F85 ec71 C966 e45A 6F42 91f5 271f 8114 a7Ba 15). If these SBCH are burnt, the SmartBCH Alliance will only need to bail out approximately 68K SBCH.
CoinFLEX burns the fees on the main chain side as promised since the beginning of the CoinFLEX bridge.
If it gets 75% support and is approved by the courts, the SmartBCH Alliance can get the following assets as a creditor:
BCH
rvUSD
Shares of the new restructured company
If this scheme of arrangement is approved by the court, then the new board of the restructured company cannot impede it. The SmartBCH Alliance will be entitled to appoint one (out of five) director to the new board. Our lawyers have confirmed this.
The restructuring proposal takes away the deposited mainchain BCH in the CoinFLEX-maintained bridge to compensate for the loss of all creditors of CoinFLEX. This is against our opinion: these BCH were in the custodian for the sidechain users, and were not assets of CoinFLEX. However, we decided to make a compromise because the lawsuit will take a lot of time, money, and, the community’s attention. If the CoinFLEX issue remains unsolved, it will always be the dark clouds haunted around smartBCH’s ecosystem. The discussion of the smartBCH community will keep focusing on this and it will be hard to move on.
If the vote fails to get the 75% support as required, we have given up nothing of our rights on behalf of any sBCH holder, which will be able to claim that 100% BCH in the bridge should be returned by CoinFLEX.
SmartBCH Alliance will be able to bail out the 68K SBCH if the scheme of arrangement works out as planned.
Around 20% of the 68K SBCH will be distributed from CoinFlex, which is around 13.6K BCH.
rvUSD and the equity of CoinFlex distributed will be sold into sBCH, which we can safely estimate as around 10K BCH.
Our donors already hold more than 20K sBCH ready for donation.
We’ve got more than 75K main chain BCH donation commitments from donors.
If the scheme of arrangement works out, we are confident that we have enough resources to maintain the peg in the near future. After SHA-Gate v2 is ready, all the distributed BCH from CoinFLEX will be put into the new decentralized bridge and donated sBCH will be locked. By concept, the sidechain’s SBCH can be divided into two parts: one part is backed with 100% BCH on the mainchain and the other part is not backed at all. After the non-backed SBCH are locked, all the SBCH will be backed with 100% mainchain BCH.
Update from smartBCH Team in Early August
In the past few weeks, while under tremendous pressure, we have been working on the decentralized bridge, SHA-GATE v2 and the draft specification has been released. (https://bitcoincashresearch.org/t/the-draft-specification-of-sha-gate-v2/862). We released SHA-Gate2 CashScript covenants for reviewing. (https://github.com/smartbch/cc-covenant). We also released SmartBCH v0.4.5 (https://github.com/smartbch/smartbch/releases/tag/v0.4.5).
Since we are focused on the development of decentralized bridge, for quite a few months from now on, the peg between sBCH and main chain BCH will be maintained with the help from donors by leveraging bcBCH, which was created and issued by Bridge Bolivar.
In the past two weeks, we have been working with some potential donors who want to buy more sBCH by paying bcBCH. We provided smart contract software, which helps to buy sBCH automatically when price falls under target price, 0.995 bcBCH/sBCH for example. This software has already been working and we have seen a more stabilized peg between bcBCH and sBCH. (https://www.marketcap.cash/token/BCBCH). As the smart contract has not been audited, so we don’t open source the code yet.
We also work with the developers from the community to develop concentrated liquidity providers that perform better service for the takers on smartBCH. On Ethereum, Curv and UniSwap V3 can provide very good experience in stable token trading.
We have identified a leading international law firm that is willing to work with us in dealing with the CoinFLEX issue. With their help, a special purpose vehicle (SPV) has been incorporated and the SPV has already started the negotiations with Liquidity Technologies Ltd.(the entity that operates Coinflex). The name of the SPV is SmartBCH Alliance Limited. As advised by its counsels, the SPV will in no way represent any sBCH holders. t will only raise donations to bail out smartBCH and finance legal actions against Coinflex. No sBCH holder’s right will be compromised by this SPV and each sBCH holder has litberty to take any legal action against Coinflex if they wish.
The SPV has formally demanded CoinFLEX to return all the treasury BCH to smartBCH protocol. The demand pointed out that many sBCH holders own sBCH through DeFi and have no direct relationship whatsoever with CoinFLEX. The bridge service that CoinFLEX provides to sBCH holders is also distinct from the normal depositary services it provides to its customers. CoinFLEX and its management may have committed tort of conversion as well as criminal embezzlement.
The target of the SPV is to permanently and irrevocably lock a certain amount of sBCH as a way of filling the hole created by CoinFLEX, by raising donations and claiming back assets from CoinFLEX. The fulfillment of bail out will need to be compatible with the Bail Out DAO plan eventually, for which we are still working on the white paper.
Without prejudice to any rights, claims, and remedies of the SPV and sBCH holders, if a reasonable compromise could be reached without years of legal proceedings which could have the support from the donors backing this SPV, we will be open to a settlement with CoinFLEX with the promise from donors to fill the hole, as a “compromise” means that there will be discrepancy between we should get and what we get indeed from CoinFLEX. If the SPV cannot get a reasonable settlement deal with CoinFLEX, no legal rights of sBCH owners will be damaged. The SPV will be funding those legal actions by itself .
Other creditors of CoinFLEX have been trying to work out a settlement without getting into a years-long forced administration/insolvency proceedings.
The hole for smartBCH protocol created by this incident may be less than 101K sBCH, as we get unaudited and unconfirmed information from CoinFLEX that they still hold 33K sBCH tokens. So the net obligation for CoinFLEX with regard to smartBCH bridge service may be around 68K sBCH.
We want to fully accomplish the bailout plan within a short period of time after the decentralized bridge is launched, which is likely to happen early next year. It will need us to make sure the bailout plan can work out successfully and timely according to smartBCH’s decentralized bridge development, testing and launching, but not subject to CoinFLEX related time consuming legal process. Even if there is a peaceful settlement between CoinFLEX, creditors and the SPV, we are not quite sure that the legal process can be ended within 6 months. The SPV got enough soft commitment but we can always use help and soft commitment from more kind hearted donors in the smartBCH community to make sure the bailout plan happens as we planed.
Cheaplightning resigned from his mod role. He has served the community for more than one year without any payment received from us. We are sincerely grateful for his contribution and respect his decision.
The Bailout Plan for smartBCH’s centralized bridge run by CoinFLEX
Dear smartBCH users:
As you have already known, the smartBCH community is in an urgent situation. The centralized bridge maintained by CoinFLEX is stuck now. And the native token on smartBCH, which will be referred to as "sBCH", is not 1:1 anchored to BCH on the main chain.
As a decentralized bridge between the main chain and side chain has taken and will be taking more time to develop, smartBCH has relied on a centralized bridge, which had been run by CoinFLEX. CoinFLEX helps the custodian of cross-chain BCH. It never owns the BCH, nor do the smartBCH users lend BCH to CoinFLEX. CoinFLEX just keeps the smartBCH users’ BCH and when they exit the smartBCH side chain, they can get back the BCH from CoinFLEX. This mechanism worked fine until this recent crisis.
This 1:1 BCH to sBCH backing was sold to the public in the form of a bridge, and the public always understood it to be a senior secured claim on the BCH. In fact, most of the BCH-to-sBCH depositors are not even clients of CoinFLEX, as it was not required to open a Coinflex account in order to use the bridging service. Therefore sBCH holders cannot legally be categorized into the same class of creditors as normal CoinFLEX depositors.
Now there are 101,382.3 BCH holding in the Bitcoin Cash main chain treasury address 18rP7bbiLiqVnFs47Hin2q1Fhb6SuMAdVo controlled by CoinFLEX. The bridge’s custodian BCH is owned by the smartBCH users, not on the balance sheet of CoinFLEX. Even if CoinFLEX goes bankrupt, it must return these coins to the users.
The smartBCH community has kept talking with CoinFLEX. CoinFLEX has shown its cooperative attitude (but no actions), however, it is concerned about potential legal liability should it transfer BCH in its custody while it is still in the midst of addressing its financial issues. As a result, it is unable to open the bridge now. And we have got no guarantee about when it can be opened.
So, the cross-chain BCH are still in the treasury address, but they will be stuck for an uncertain time. The smartBCH users are facing risks and uncertainty.
To help users of smartBCH immediately, some BCH supporters are setting up “The Bail-Out DAO” (BODAO). BODAO will raise BCH to provide smartBCH users 1:1 exiting option to the main chain. After BODAO successfully owns 101,382.3 sBCH in total, it will have the right to claim all the 101,382.3 BCH on the treasury address. The BODAO will use every possible measure to get these BCH back, including raising an extra 101,382.3 sBCH as financial resources to sue Coinflex, its founders, directors, and other immoral creditors of Coinflex who want to touch our precious coins.
CoinFLEX is aware of BODAO. Privately, they have said some nice things about BODAO and apologized to the smartBCH community for halting the bridge. We hope they can speak directly to the public, so we do not copy their words here.
The organizers of BODAO are working hard on the details and several BCH whales have shown their interest. We the developers will soon enable a temporary centralized bridge between the main chain and the side chain, through which users can exit to the main chain with the liquidity provided by BODAO.
BODAO will issue a governance token SCG to encourage people to join it. The smartBCH chain is also planned to be updated to empower SCG.
We will remove the 50% voting power from SHA256 miners to the SCG token holders. At such a crisis, only BCH/sBCH holders can do themselves a favor to bail out themselves. In the future, the validators' role on smartBCH will always be elected by the SCG token holders and the sBCH holders. SCG holders will have 25% voting power, and sBCH holders will have 75% voting power.
A portion of the (currently) burnt gas fee on smartBCH will no longer be burnt. Instead, it will be used to buy SCG back and burn SCG tokens. The ratio of the portion will start at 50% of the burnt gas fee (25% of all the gas fee). Such ratio will be kept as a consistance until a chosen time in the future, and then it will be reduced continuously at a speed of 30% reduction per year.
We call for BCH/sBCH owners to join the BODAO. We also need legal experts joining us to prepare the legal actions. If you are interested, please contact @cheaplightning on telegram.
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. https://www.thesslstore.com/blog/what-is-a-hardware-security-module-hsms-explained
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. https://read.cash/@SmartBCH/cloud-enclaves-and-their-applications-in-blockchains-6cc24512
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. https://chain-swap.medium.com/chainswap-exploit-11-july-2021-post-mortem-6e4e346e5a32 https://medium.com/multichainorg/anyswap-multichain-router-v3-exploit-statement-6833f1b7e6fb https://slowmist.medium.com/the-analysis-and-q-a-of-poly-network-being-hacked-8112a35beb39 https://twitter.com/MultichainOrg/status/1483110393543544832 https://medium.com/@wormholecrypto/wormhole-incident-report-02-02-22-ad9b8f21eec6 https://twitter.com/Meter_IO/status/1490103308421255168 https://halborn.com/explained-the-ronin-hack-march-2022/
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.
Light-weighted Manipulation-proof Random Number Generator for smartBCH
In our early article introducing cloud enclaves, a mechanism for building manipulation-proof random number generators (RNG) with SGX enclaves was presented. Now we are planning to implement this mechanism on smartBCH, as our first real-world use case of SGX enclaves, and an important step for gathering experience before using enclaves in SHA-gate. https://read.cash/@SmartBCH/cloud-enclaves-and-their-applications-in-blockchains-6cc24512
This mechanism combines VRF and enclaves. The enclave contains VRF's private key, which is used to generate a pseudo-random number and its proof for each block's hash. Anyone can use the VRF's public key and the proof to verify the generated pseudo-random is valid. The enclave keeps the private key a secret, so the generated pseudo-random cannot be predicted even if you know the block's hash.
In the following sections, we'll compare this mechanism to two existing common mechanisms for building RNG and introduce its implementation details.
**A comparison of RNGs**
VDF (verifiable delay function) and the commit-reveal scheme are two widely used mechanisms for RNG.
VDF is a hash function that takes a long proveable time to compute but only a short time to verify. The block hashes are fed into VDF and the outputs are used as fair random numbers. Since the computation of VDF requires a proveable time to finish, the proposers can't try different hashes and pick the best.
The most beautiful part of VDF is that it does not need to trust any human. You only need to trust math (there is no cryptography algorithm that can reduce its computation steps) and physics (humans cannot manufacture semiconductor devices to speed it up dramatically).
Unfortunately, VDF is not so mature. On vdfresearch, you can find many VDF algorithms, but none of them are standardized. And VDF's physical research is just beginning. Another bad news is that the "short" verification time of VDF is still orders of magnitudes higher than plain ECDSA signatures, which makes this solution not cost-effective enough. https://vdfresearch.org
The commit-reveal scheme guides a quorum of operators to generate a fair random number. If these operators do not collude, i.e., at least one of them is honest, then the final result can't be manipulated. This scheme is very mature for it has been extensively tested in the field for years and Ethereum's RANDAO is based on it.
However, it has an availability issue: if some anticipator is offline and fails to reveal after committing, the result can't be generated. This issue can be alleviated by incentivizing the operators to ensure availability by using more hardware resources for redundancy. Furthermore, each new random number needs a lot of transactions for operators' committing and revealing, so it is much more expensive and takes a longer time than plain block hashes.
VRF is standarlized by IETF, and Intel SGX enclaves have been working in the field since 2015. They are both mature techniques. Although some vulnerabilities have been found for SGX in hyperthreading-enabled CPUs, they can be easily bypassed by disabling hyperthreading. https://www.ietf.org/archive/id/draft-irtf-cfrg-vrf-10.html
Compared to plain block hashes, the only operation the VRF+Enclave mechanism adds is one VRF verification. So the cost and delay are both very low.
Based on athe bove analysis, we compare these three mechanisms in the following table:
**CostTrust ModelMaturity**VDFHighTrust math and physicsLowCommit-RevealHighTrust a quorumHighVRF + EnclaveLowTrust hardware manufacturerHigh
It is clear that the VRF+Enclave mechanism do have some advantages and it is worth implementing.
**How we implement the VRF+Enclave RNG**
The source code implementing the VRF+Enclave RNG is already opensourced. The code is short and easy to understand. Here we just want to highlight some key points. https://github.com/smartbch/enclave-vrf
First, the enclave does not verify the block hashes fed to it. They may be invalid block hashes or some other chain's block hashes. Because the enclave does not run smartbchd itself, they do not know what the correct block hashes are. Instead, it just delays returning the VRF output. If you feed a block hash to it, it will delay five seconds before returning the VRF to you. Thus, even if a validator tries to utilize it to try different possible block hashes and pick the most beneficiary one, she will miss her time window of proposing a new block.
Second, there is a quorum to endorse the enclaves. The most important step of using enclaves is attestation. Attestation ensures that a web service is really running inside an enclave and its binary code is as expected. Although using utilities provided by Azure to attest to an enclave is easy for a programmer, most plain DEFI users may still find this job too hard. So we will invite some trustworthy developers in the smartBCH ecosystem to attest to the enclaves. Then they can endorse a VRF public key stored in a smart contract. The smart contract is also used in verifying VRF outputs of block hashes. Its solidity code can be found here. https://github.com/smartbch/enclave-vrf/tree/main/gov_contracts
Last but not least, to ensure availability, multiple nodes on different machines provide the same service, i.e., they keep the same VRF private key. The private key is generated in a master enclave and broadcasted to several slave enclaves. To prevent the private key from leaking, the master enclave will attest to the slave enclaves to ensure they are real enclaves and run the correct binary code.
**Conclusion**
Building a random number generator using the VRF+Enclave mechanism has several advantages. So we implement it as in the enclave-vrf repo, and plan to deploy it on smartBCH in the near future. https://github.com/smartbch/enclave-vrf
Let's get rid of transactions for approving/revoking tokens
Even as a DEFI beginner, you may already find SEP20 token's approving transactions are annoying: if you want to add liquidity to the CATS/FLEXUSD pool, you must send one transaction for approving CATS and another transaction for approving FLEXUSD, before you can finally deposit your CATS and FLEXUSD tokens into a DEX pool.
When you get more knowledge and experience on the risks and exploits in the DEFI world, you are aware that approving tokens to a contract is a dangerous operation. And then you find some utilities such as revoke.cash and approval-tracker to revoke your allowance to the contracts, which are annoying tasks, too. https://medium.com/mycrypto/bad-actors-abusing-erc20-approval-to-steal-your-tokens-c0407b7f7c7c https://kalis.me/unlimited-erc20-allowances https://steveng.medium.com/why-smart-contract-approval-is-dangerous-7e3da85ca6d2
When a cautious DEFI user interacts with a suspicious contract, she follows such a process: approve the necessary token allowances, call the suspicious contract, and finally revoke the remained allowances (if any). It is very tedious that this process needs at least three transactions (more transactions are needed when more tokens need to be approved). But it is worthwhile because she never worries about the approved allowances after this process.
You may wonder: why can't all these tasks be automated? People just click the wallet once and it will automatically send the transactions one by one. Well, even with such a feature, users still have to wait for several transactions to be broadcasted and then executed on-chain. The delay and waiting are still annoying.
A better solution is making the chain itself add a new feature to help out. And it's just what smartBCH is going to do: a feature named "EOA Delegator" is planned to be added in the next hardfork upgrade, i.e., the sha-gate upgrade.
EOA is short for Externally Owned Account, i.e., an account controlled by a private key. EOA delegators are smart contracts to which EOAs can *delegatecall*.
What is *delegatecall*? It means that whatever the bytecode in an EOA delegator does, it acts as if the EOA (instead of the contract) does it. For example, if the bytecode calls a SEP20 tokens `approve` method, the result is the same as the EOA calls the `approve` method and sets the allowance for some smart contract to spend from the EOA's balance.
Currently, no EVM-compatible chain allows an EOA to send a transaction that *delegatecall*s a smart contract. This will be changed in smartBCH's next upgrade. After that, smartBCH will take a specialized smart contract as the EOA delegator. Whenever they are used as the target of a transaction (called by EOAs), they execute as if they are *delegatecall*ed.
The EOA delegator has been already opensourced. They help EOA to automate such a process: 1) approve one or more tokens; 2) call a contract to do the desired job; 3) revoke any remained allowance. With EOA delegators, you can act as a cautious DEFI user easily. We welcome comments and reviews on them. https://github.com/smartbch/eoa_delegator
EOA delegator's technical detail is described in SEP103. If you have any suggestions or ideas on it, please reach out to us through telegram, GitHub, or email. https://github.com/smartbch/docs/blob/main/smartbch-evolution-proposals-seps/sep-103.md
The first ahead-of-time compiler for EVM: moeingaot
We are proud to introduce the first ahead-of-time compiler for EVM: moeingaot. https://github.com/smartbch/moeingaot
In the smartBCH's whitepaper, we wrote: "EVM, which is adopted more commonly than other VMs like WebAssembly, is a de facto standard for smart contracts. However, EVM lacks certain important speedup methods, such as ahead-of-time (AOT) compilers and just-in-time (JIT) compilers. In the software industry, almost every important VM has its AOT and/or JIT compilers, for example, JVM, ART VM, Javascript V8, DartVM, WebAssembly, LuaJIT, and GraalVM. We believe that it is about time that EVM has its compiler. And implementing an AOT compiler for it would be reasonable, since, unlike Javascript and Lua, it has static semantics."
To implement an ahead-of-time compiler, the quickest path is a bytecode-to-c converter. Lua2c converts Lua bytecode into C source, and wasm2c converts WebAssembly bytecode into C source. By compiling the C source we can get a native library or program whose function is equivalent to the VM's bytecode. Since Lua and WebAsssembly already have sophisticated JIT solutions, Lua2c and wasm2c are no longer maintained now. https://github.com/davidm/lua2c https://github.com/WebAssembly/wabt/blob/main/wasm2c/README.md
We believe that the first ahead-of-time compiler for EVM is better to follow the bytecode-to-c path and it would have a great value to the crypto world before a sophisticated EVM JIT compiler gets ready.
Moeingaot is based on a faster interpreter for EVM: evmone, which has already implemented a function for each EVM instruction. We implement it in golang. Firstly, it analyzes a smart contract's bytecode to extract the JUMP/JUMPI instructions' targets; then, it outputs a c++ source code containing function calls which one-to-one map to the instructions, together with labels and goto-statements for JUMPs. This source code and some other code from the evmone project, are compiled into a dynamically linked library. The smartBCH's full-node client can load this library and call a function that does exactly the same thing as the smart contract. https://github.com/ethereum/evmone
Moeingaot also supports compiling multiple smart contracts into one dynamically linked library and uses an entrance function named query_executor to query the function corresponding to a given smart contract.
We are still working on meoingaot for more case coverage and better performance. Currently, only preliminary benchmark data can be shared. The following synthetic benchmark is measured:
pragma solidity 0.8.13;
contract babylon {
uint public result;
int public fibResult0;
int public fibResult1;
function sqrt(uint y) external {
uint z;
if (y > 3) {
z = y;
uint x = y / 2 + 1;
while (x < z) {
z = x;
x = (y / x + x) / 2;
}
} else if (y != 0) {
z = 1;
}
result = z;
fibResult0 = fib(5);
fibResult1 = fib(100);
}
function fib(int n) public pure returns (int) {
int t1 = 0;
int t2 = 1;
for (int i = 1; i <= n; ++i) {
int nextTerm = t1 + t2;
t1 = t2;
t2 = nextTerm;
}
return t2;
}
}
With `255<<248` as its input, the `sqrt` function needs 104.8us to run on the evmone interpreter and 38.4um to run as a dynamic library compiled by moeingaot. Moeingaot is 2.73X faster than the evmone interpreter. This is a very encouraging result.
We will continue to optimize moeingaot and integrate it into smartBCH's full-node client in the next few months. Moeingaot will as well be inspirational to the EVM ecosystem.
The smartBCH mainnet will be hard forked to apply the XHedge upgrade
After the XHedge hard fork was applied to the Amber testnet on 14 Feb 2022, it has been working smoothly for seven weeks. Now we are going to apply the XHedge hard fork to smartBCH's mainnet at the height of 4106000 (next Wednesday, 20 Apr 2022).
The name "XHedge" of this hard fork comes from its most important feature: BCH holders can elect validators through the XHedge smart contract. During the last six weeks, we found some weaknesses in this smart contract and refined it. Now the mainnet will use the latest v0.4.4 XHedge contract, deployed at the address of 0x11e34Ee274929d607E06C5e49bB0dc26Ca920BF2. https://docs.smartbch.org/smartbch/developers-guide/xhedge-contract https://github.com/smartbch/xhedge/releases/tag/v0.4.4
After the XHedge hard fork, The voting power from miners (PoW) and the voting power from BCH holders (PoS) will both be 50%. For PoS voting, BCH holders can stake BCH into the XHedge smart contract to mint a pair of Lever NFT and Hedge NFT. The Lever NFT is used to elect validators for smartBCH and its voting power is proportional to the accumulated coin-days. And Hedge NFT can be used to endorse the value of stable coins. We hope in the future one or more DeFi projects can finally bring us stable coins with Hedge NFTs are the deposit reserve. https://docs.smartbch.org/smartbch/developers-guide/staking#epoch-based-validator-election
Another important feature is that validators can use an optimized scheme to adjust the minimum gas price together, and the adjustable range will be larger than the current version. Now on the smartBCH network, any validator can adjust the minimum gas price, and when the validators' options are different, there will be a chaos of meaningless rising and falling. https://docs.smartbch.org/smartbch/developers-guide/min-gasprice-decision
Users will also find the VRF verifying capability and the new mempool design useful. SEP109 adds a precompile smart contract to verify VRF (verifiable random function) hash results, in a gas-efficient way. The new mempool will allow accounts to send new transactions into successive blocks, while the current version only accepts transactions from the same user in every other block. https://docs.smartbch.org/smartbch/smartbch-evolution-proposals-seps/sep-109
There are also many new customized RPC endpoints, speed optimizations, and robustness enhancements. Besides, third-party libraries will be statically (instead of dynamically) linked to smartBCH's full-node client with v0.4.4.
After smartBCH's XHedge hard-fork, we'll focus on developing the SHA-gate feature, which enables a secure and decentralized bridge between BCH mainchain and smartBCH sidechain. It will take us several months and the SHA-gate hard fork will happen in 2022Q3, hopefully.
The XHedge hard fork opens the door for more validators on smartBCH. We welcome all players in the BCH ecosystem to run a validator of smartBCH and are ready to provide technical support.
Cloud Enclaves and their Applications in Blockchains
By Wang Kui (kui.wang@smartbch.org)
Top cloud computing vendors have recently been actively marketing confidential computing services, i.e., enclaves. Enclaves provide the features of integrity, isolation, data sealing, and attestation, through which relying parties only need to trust the CPU hardware and the code running inside enclaves. The cloud computing vendors and the administrators of enclave instances cannot tamper or peek at the execution inside enclaves.
Blockchains enforce "code is law" by consensus algorithms, while enclaves enforce "code is law" by CPU hardware. The similarity between them hints to us that it's possible to improve blockchain applications' security, privacy, and efficiency with enclaves
In this article, we'll introduce the mainstream enclave solutions of the top cloud computing vendors and discuss several applications which may benefit from enclaves.
Enclave Solutions
Traditionally, confidential computing means how we can trust a physical device's hardware-software stack. It follows a bottom-up scheme:
A secure cryptoprocessor measures the firmware and hardware of the device. If they are trustable, start the firmware.
The firmware measures the OS. If it is trustable, start it.
The OS measures application programs and starts only the trustable ones.
In the cloud computing era, the vendors still need to make the hardware-software stack secure and trustable. But their customers want more: even if the vendors are evil or their cloud infrastructures are vulnerable, the computing instances and containers are still trustable.
So today's confidential computing solutions start from some middle point in the hardware-software stack, instead of the bottom. The major server CPU manufacturers, i.e., Intel and AMD, take different choices:
AMD's SEV technology enables enclaves on top of hypervisors, which contain OS kernel and application programs.
Intel's SGX technology enables enclaves on top of OSes, which contain only (a part of) one program and one process (with multi-threading).
Currently, Microsoft and Google provide enclaves based on AMD CPUs, while Microsoft and Alibaba provide enclaves based on Intel CPUs. Despite the implementation details, their products all support the following features:
Integrity: a program in the enclave executes exactly as its source code specifies, no party can tamper with it, even the hypervisor and/or OS under it. A hacker or evil administrator with privilege cannot change how the code runs.
Isolation: the program(s) executing context (registers status and DRAM status) cannot be viewed or changed by any other party, even the hypervisor and/or OS under it.
Data sealing: the data written to persistent storage from the programs in an enclave are encrypted and can only be decrypted in the enclave later.
Attestation: after hardware-assistant measurement of the program running in an enclave, the hash digest of the measurement is signed by a key kept by hardware to convince the relying parties that it IS the predefined trustable program running.
When an enclave is providing services on the cloud, the relying parties can trust it even if the cloud computing vendor and its customer who rents and operates the enclave are both dishonest. The human factor threatening the service's security is reduced dramatically.
Manipulation-proof Random Number Generator
Various blockchain applications need random numbers for fairness, such as gaming, consensus, and stochastic payment. Since blockchain is deterministic, a true random number generator (RNG) based on physical entropy cannot be used.
Many applications directly use block hashes as a random source. Block hashes are cheap to use because there is always a hash for every block and no more computation is needed. But block hashes are prone to be manipulated. The block proposer can try different transaction sets and pick a block hash that is most beneficial to it. On PoW chains, this trial process may delay the proposer from successfully mining a block, so there is some potential penalty. On a PoS chain, it is almost riskless for the proposer to try different block hashes.
VRF (verifiable random function) is a special kind of hash function. Using a private key, VRF computes the hash result and proof from the input pre-image. With the corresponding public key and the proof, the hash result can be verified against the pre-image. If an honest party is holding VRF's private key, then the VRF results of block hashes can be used as fair random numbers, because the validators have no way to know the VRF results before proposing a new block.
An enclave can act as such an honest party: it does exactly as the source code specifies, and never reveal anything it should keep as a secret, including the VRF private key. When a DApp needs the random number corresponding to a block, it queries the enclave for the VRF result and the proof and then verifies them on-chain against the VRF public key and the block hash, i.e., the VRF input. If the check passes, the DApp will have confidence that this random number is not manipulated.
Improve privacy of CoinJoin
CoinJoin has long been used to improve the privacy of cryptocurrencies. It was first implemented by the Dash coin and later Bitcoin Cash also got an implementation of CoinJoin named CashShuffle.
CoinJoin's idea is quite simple: a UTXO-based transaction has multiple inputs and multiple outputs; by combining inputs and outputs from what would otherwise be separate transactions, into one jumbo transaction, the correspondence of the original transaction's inputs and outputs are obfuscated. Just make your UTXO set undergoes several levels of such jumbo transactions, and an external viewer cannot match the resulting UTXO set owned by you to the original UTXO set.
CoinJoin uses a client-server model. The servers coordinate which users are shuffling and know which user owns which inputs/outputs. This is a risk for privacy because servers may leak their knowledge. How to alleviate this risk? Dash coin uses multiple masternodes for coordinating and CashShuffle has decentralized servers. If you scatter the many levels of jumbo transactions among these servers (masternodes), then your UTXOs cannot be fully tracked as long as a few of these servers are honest. The more levels and servers you use, the harder your coins are to track.
The isolation feature of enclaves makes sure no information leaks out from the servers. If the client confirms the server runs inside an enclave through attestation, it would have the confidence no third party can steal the information sent to the server. Thus, fewer servers and levels are necessary and the total solution can be more efficient.
Blackbox Execution of Pure Functions
A common scenario of blockchain applications is that you need to convince the public that you have the solution of an equation but you don't want to reveal this solution to the public. For example, you want to prove that you know a pre-image that hashes to a given output but you do not want to show this pre-image to the public for verifying.
Let's generalize such a scenario to any pure function. A pure function has no side-effect and its outputs depend only on its inputs. We have:
A predefined specification of the pure function without ambiguity
Some public input arguments for this pure function, which can be revealed to anyone
Some private input arguments for this pure function, which cannot be known by anyone else except their owner
We want a reliable blackbox, which is trustworthy to compute the correct outputs from the given public and private input arguments. At the same time, the provider of private arguments does not need to worry about information leakage.
Several cryptographic technologies can implement a blockbox with relatively simple functions and we usually refer to them as "zero-knowledge-proof". Such technologies need a lot of expensive cryptographic computations and the function's logic cannot be too complex, or else the proof circuit would be extremely large. Furthermore, if the pure function has an unbounded loop inside, zero-knowledge-proof technologies would be infeasible because the proof circuit cannot be constructed. Another shortcoming of zero-knowledge-proof technologies is the hardness to use. If the engineer does not have enough cryptography knowledge, it is hard to get things working and prone to leave vulnerabilities.
Enclaves can also implement such blockboxes. Isolation ensures enclaves never leak private input arguments, while attestations ensure enclaves compute just as the source code specifies.
Compared to zero-knowledge-proof technologies, enclaves are weaker in the trust model: we only need to trust math to use zero-knowledge-proof but must trust CPU vendors to use enclaves. However, enclaves are much easier to use: the pure function's source code can be used directly in enclaves. There are no circuit constructions and unbounded loops are permitted.
Off-chain enclaves can easily interact with on-chain smart-contract. An enclave can be denoted by a public key stored on-chain. With the private key, it signs the pure function' public input arguments and the outputs. On-chain logic verifies the signature with the public key and accepts the outputs.
Reliable Witnesses for Chain-Crossing
All the chain-crossing technologies need witness. To make a cross-chain transaction from Chain A to Chain B happen, Chain B must be aware of Chain A's state change. The only trustless way for Chain B to keep track of Chain A's state is running a full-node client of Chain A to provide information for every Chain B's full-node client. This is a very rigorous requirement.
We do require that every smartBCH full-node client must have a corresponding BCH full-node client for querying transactions on BCH main chain. But it is impossible to require a BCH full-node client to watch a smartBCH node when running. It is also impossible for other chain-crossing scenarios, such as Ethereum to BSC, Ethereum to Solana, etc.
So it is unavoidable for cross-chain bridges to rely on some witnesses providing state information about another chain. The problem of witness collusion threatens all the cross-chain bridges. For some bridges, the witness set is the same set of validators and the state information is the Merkle root of the whole state tree, which leads to a little safer design but still cannot avoid collusion.
A witness runs a full-node client of Chain A and publishes its state to Chain B with its signature. If it turns evil, it may publish any information to Chain B, despite the actual state of Chain A. Even if the witness is a trustworthy organization, the machine administrator can still be bribed and the private key for generating signatures onto Chain B may get stolen.
As an enhancement, the witness can run its daemon process inside an enclave. The attestation process prevents corrupted administrators and isolation protects the private key.
When we implement SHA-Gate, the cross-chain bridge which transfers BCH between the main chain and smartBCH sidechain, enclaves will be taken into consideration since the blueprint.
Conclusion
Major cloud computing vendors provide several enclaves solutions. Enclaves' features of integrity, isolation, data sealing, and attestation, can help users build better blockchain applications. We the smartBCH developers will utilize them to improve the ecosystem of Bitcoin Cash.
The amber testnet will be hard forked to apply the XHedge upgrade
We are happy to announce that a new version of smartBCH (v0.4.2) is ready and the amber testnet will be hard forked at the height of 3088100 (next Monday), based on this version. We name this hard fork "XHedge", to highlight its most important feature: BCH holders can elect validators through the XHedge smart contract. https://github.com/smartbch/smartbch/releases/tag/v0.4.2 https://docs.smartbch.org/smartbch/developers-guide/xhedge-contract
After this hard fork, The voting power from miners (PoW) and the voting power from BCH holders (PoS) will both be 50%. For PoS voting, BCH holders can stake BCH into the XHedge smart contract to mint a pair of Lever NFT and Hedge NFT. The Lever NFT is used to elect validators for smartBCH and its voting power is proportional to the accumulated coin-days. And Hedge NFT can be used to endorse the value of stable coins. We hope in the future one or more DeFi projects can finally bring us stable coins with Hedge NFTs are the deposit reserve. https://docs.smartbch.org/smartbch/developers-guide/staking#epoch-based-validator-election
Another important feature is that validators can use an optimized scheme to adjust the minimum gas price together, and the adjustable range will be larger than the current version. Now on the smartBCH network, any validator can adjust the minimum gas price, and when the validators' options are different, there will be a chaos of meaningless rising and falling. https://docs.smartbch.org/smartbch/developers-guide/min-gasprice-decision
Users will also find the VRF verifying capability and the new mempool design useful. SEP109 adds a precompile smart contract to verify VRF (verifiable random function) hash results, in a gas-efficient way. The new mempool will allow accounts to send new transactions into successive blocks, while the current version only accepts transactions from the same user in every other block. https://docs.smartbch.org/smartbch/smartbch-evolution-proposals-seps/sep-109
There are also many new customized RPC endpoints, speed optimizations, and robustness enhancement. But the sha-gate function will not be included in this upgrade. We will implement sha-gate in the next few months and apply it after Bitcoin Cash main chain's 2022 May hard fork.
We hope the upgraded amber testnet will bring a better experience to users and developers. And when the new features are tested thoroughly on the amber testnet, we will soon apply the XHedge upgrade to the smartBCH mainnet.
The progress on the cross-chain bridge
We are pleased to share our progress on the cross-chain bridge between Bitcoin Cash and smartBCH. With the help from BCH community, smartBCH's developers have proposed a cross-chain mechanism named SHA-Gate which transfers BCH between the Bitcoin Cash main chain and a sidechain. It is decentralized, non-custodian, miner-supervised and fully implemented with Bitcoin Cash's script bytecode. It does not require any consensus change of Bitcoin Cash, nor rely on operators' honesty for asset security. https://docs.smartbch.org/smartbch/sha-gate
The developers are now busy in studying feasibility and safety of SHA-Gate, with coding and implementation followed soon. We invite the BCH community to help us review and refine SHA-Gate. Before SHA-Gate is ready for deployment, smartBCH will use a semi-centralized bridge operated by CoinFLEX. https://coinflex.com
CoinFLEX is delivering a semi-centralised Gateway v1 utilising its existing system for multi-chain coin rebalancing designed for FLEX Coin and flexUSD.
The solution, tried and tested by CoinFLEX since Oct 2020 will allow CoinFLEX users to deposit BCH on the Bitcoin Cash network and withdraw on smartBCH and reverse.
In the background, the multisig smartBCH authority guarding the full supply of smartBCH BCH will be monitoring the demand for smartBCH signalled by CoinFLEX and release the required BCH amounts on smartBCH network into the circulation, while CoinFLEX locks the matching amount of BCH on the Bitcoin Cash network into a publicly visible Treasury Wallet containing the BCH removed from the circulation. The Treasury Wallet is secured by Fireblocks multilayer technology utilising MPC cryptography with hardware isolation. All operations powered by Fireblocks are covered by their at rest & in transit insurance.
At all times, it will be possible to verify the BCH rebalancing on both blockchains by checking the BCH balance in the Bitcoin Cash Treasury Wallet vs BCH balance change in the smartBCH source wallet.
Detailed user guides of SHA-Gate and CoinFLEX's bridge will be delivered soon.
Bitcoin Cash’s sidechain, smartBCH, is launching with support from BCH community and miners
We are pleased to announce that we have launched smartBCH successfully on July 30th, 2021 with three nodes as the genesis validators: BTC.com, ViaBTC, and Matrixport. smartBCH is now in its first voting period. More validators will be elected by sha256 miners and will take on the duty in the future. We appreciate all the help from the BCH community!
We have spent two more months in development than the original estimation to finalize the data structure of MoeingADS and to implement **SEP101**, **SEP206**, and **Transaction Reorder** onto smartBCH. https://docs.smartbch.org/smartbch/smartbch-evolution-proposals-seps/sep-101 https://docs.smartbch.org/smartbch/smartbch-evolution-proposals-seps/sep-206 https://docs.smartbch.org/smartbch/in-depth-design-documents/tx-reorder
MoeingADS is the underlying storage engine for the world state, which is very hard to change in hard forks. Ethereum’s underlying storage engine MPT has never modified its data structure since the beginning. MoeingADS is now strong enough to support **51K TPS** and can support smartBCH’s growth for many years without changing its primary data structure. https://docs.smartbch.org/smartbch/in-depth-design-documents/benchmarking-moeingads
Innovation is the key mission of smartBCH. Its innovation is not only in the underlying storage and execution engines but also in the high-level semantics. Two new features, SEP101 (Store values with arbitrary length) and SEP206 (Manipulate Native Token as a SEP20 Token) were included ever since the genesis of smartBCH because they enhance EVM’s functionality and greatly eases DApp developers’ work. Also, to alleviate front-running, smartBCH reorders the transactions pseudo-randomly to prevent validators from ordering transactions in some profitable way.
In the next several months, our team will focus on the cross-chain gateway and cooperate with the community to continue building on smartBCH’s ecosystem.
In the past few weeks, many cross-chain bridge projects underwent exploits and suffered from massive loss of coins. Because of these events, we decided to redesign the cross-chain gateway between BCH and smartBCH. It will take security as the priority and be audited by the community.
Bitcoin Cash is a decentralized community and we are just a small team within it. We are not in control of the schedule of any browsers, wallets, DApps, and exchanges. However, it is encouraging to see that there are already several parties developing these indispensable elements for smartBCH. We’ll provide enough supports to them to enrich smartBCH’s ecosystem.
The launch is a solid step in smartBCH’s long journey. We invite everybody from the BCH community to use it and help its growth. We’ll soon provide some guides for BCH holders to try it and transfer a limited amount of coins cross-chain through the current simple gateway.
**About smartBCH**
smartBCH is a sidechain for Bitcoin Cash and has an aim to explore new ideas and unlock possibilities. It is compatible with Ethereum’s EVM and Web3 API and provides high throughput for DApps in a fast, secure, and decentralized manner.
If you see potential in what we are building and want to build with us, feel free to join our telegram: **https://t.me/smartbch_community**
Lastly, if there is anyone you know that could help with our project, please help us connect to them.
Dizzy symbolSHA256 hash power can stake smartBCH now. You can vote and elect the validators of smartBCH with bitcoincashnode in the testnet-T2: https://docs.smartbch.org/smartbch/testnets#smartbch-t2
SmartBCH Launches Billiongas Testnet and Reaches Benchmarking Goal
The Goal
From the very beginning, we have had the objective of utilizing low-level optimizations to maximize EVM throughput. The medium-term goal for showcasing such efforts was to consume 1 billion gas every 15 seconds.
For comparison, Ethereum consumes a maximum of 15 million gas every 15 seconds. Therefore, if we were to reach our goal, that would mean consuming more than 66 times the amount of gas Ethereum can currently handle. Needless to say, it is quite an ambitious goal!
We are proud to announce the release of the Billiongas Testnet, a testnet specifically designed to demonstrate the upper limits of the gas consumption capabilities of smartBCH. At the link, you will find the chain-ID, a list of JSON-RPC nodes you can connect to, and instructions on how to join. https://docs.smartbch.org/smartbch/testnets#smartbch-billiongas
Benchmark
Our first benchmark on this testnet went very well, as shown in the chart below.
The benchmark lasted 290,168 seconds (3 days, 8 hours, and 36 minutes) and produced 55,042 blocks. The total gas consumption was 27.297 trillion gas. Averaged out, that comes out to 94.07 million gas per second or 1.41 billion gas every 15 seconds. Mission accomplished!
For those who are curious about the variation in the chart, the dip and subsequent rise in gas/second around block 31,000 was due to switching to another machine for stressing different transactions. The drop at block 40,000 was because one machine switched to generating a different type of transaction. The drop around block 48,000 was caused by one machine running out of prepared transaction data.
The transactions executed during this benchmark were not just simple token transfers. To simulate actual usage of the EVM for the benchmark, we executed smart contract transactions on the Billiongas testnet. More details can be found in this document. https://docs.smartbch.org/smartbch/in-depth-design-documents/benchmarking-testnet
Making a fresh node catch up to the Billiongas testnet is very fast. It took one of our nodes 9 hours and 27 minutes to catch up to all 55,042 blocks. That’s 8.52 times faster than normal execution.
We would like to remind the reader that this is all without sharding or rollups. This is simply an EVM implementation optimized as described in our whitepaper. Additionally, the benchmark was done in a real-world environment with validators across the globe in Ohio, Singapore, and Ireland. https://docs.smartbch.org/smartbch/smartbch_whitepaper-en
One more noteworthy point about this concerns Vitalik Buterin’s recent article. Buterin, a co-founder of Ethereum, is of the opinion that no more than 10% of the CPU power of a validating node should be used for transaction validation. We agree that most of a validation node’s processing power should be held in reserve. Therefore, the Billiongas testnet benchmark only used 10–20% of the CPU for block verification. Should that become standard practice across the board, validation nodes will have processing power in reserve to respond to significant increases in transaction demand, to perform other tasks related to validation, and to sync quickly after being offline. We did another benchmark using 100% of the CPU for block verification. Those benchmark results can be found in this document. https://vitalik.ca/general/2021/05/23/scaling.html https://docs.smartbch.org/smartbch/in-depth-design-documents/benchmarking-moeingevm-moeingads
Next Steps
We encourage all interested parties to join one of our testnets to see how smartBCH works, test edge cases, and help debug if possible. We suggest using m6gd.4xlarge or m5ad.4xlarge to join the billiongas testnet, which is currently running. https://docs.smartbch.org/smartbch/testnets
Soon we will start testing a Bitcoin Cash smartBCH bridge and we will be working on testing election logic for smartBCH validators. Detailed discussions with Bitcoin Cash mining pools are ongoing and we expect to launch the smartBCH mainnet in July.
We would like to thank the Bitcoin Cash community and all interested and involved parties for their support and willingness to run testnet nodes, test transactions, and report issues. With the assistance, we continue to receive we expect great things in the very near future!
Join the smartBCH community to stay in touch!
Twitter: https://twitter.com/SmartBCH
Discord: https://discord.gg/uNTRSz6msj
Medium: https://medium.com/@smartbch
Telegram (Community Chat): https://t.me/smartbch_community
Telegram Announcement Channel: https://t.me/smartbch_official
GitHub: https://github.com/smartbch
Reddit: https://www.reddit.com/user/SmartBCH
Testnet for smartBCH, a Bitcoin Cash Layer-2 Project, Is Now Public
We are really excited to announce that, as of today, the smartBCH testnet is now live. Developers and DApp builders can now find the testnet information at **https://docs.smartbch.org/smartbch/testnets** . The testnet will allow anyone to experiment with and develop for a high-performance, EVM-compatible Bitcoin Cash sidechain.
We know the Bitcoin Cash community has been eagerly awaiting the release of the smartBCH testnet and interest has grown daily. Our telegram channel alone boasted hundreds of members even before the first single-node test version was released. The abilities of smartBCH, while still untested on a live public chain, are promising. Mark Lamb, CEO of CoinFLEX, has had his dev team running a private testnet of smartBCH. Lamb reported, “*Metamask is connecting without issue, and solidity code is working well. We set up a DEX on our private testnet, created tokens…and it’s all going smoothly.*”
There has been a huge surge of interest in “Ethereum killers” lately due to extreme congestion and high fees on Ethereum. Users and developers have flocked to other blockchains like BSC, Polkadot, and EOS. Even these alternative smart contract platforms have seen gas fees go higher due to market demand. SmartBCH is poised to take away some of the market share for DApps and DeFi by using novel attempts to scale far past what previous blockchains have managed to achieve.
smartBCH is a first-of-its-kind sidechain for Bitcoin Cash, launched by our dev team which has been in blockchain development since 2016. Bitcoin Cash has spent nearly its entire history as a top-10 coin by market capitalization. It enjoys relatively high liquidity, merchant adoption, and an enthusiastic and engaged community. Bitcoin Cash itself is not specifically equipped for smart contracting functions, preferring use cases centered around peer-to-peer cash. However, as a sidechain to Bitcoin Cash, smartBCH aims to build a new playground for the Bitcoin Cash ecosystem and enlarge the userbase. SmartBCH is EVM & Web3 compatible and has a short block interval to support DeFi applications. Its throughput will be as large as one billion gas every 15 seconds to allow more users to access DeFi at a very low cost.
With years of experience developing hardware and software solutions in the blockchain industry backing us up, we are pleased to announce the testnet is live and we welcome everyone to test its functionality. “*SmartBCH provides an EVM & Web3 compatible sidechain for Bitcoin Cash, staking its hash power while utilizing BCH as the native gas-paying token. What’s more, by incorporating hardware-friendly components, vastly increased scalability is unlocked,*” said Kui Wang, lead developer of smartBCH. “*We believe that smartBCH will provide the same benefits as ETH2.0 in a much shorter time frame, achieving a block gas limit of one billion.*”
For more information, please visit the official website: **https://smartbch.org**
**About smartBCH**
Started in December 2020, smartBCH is a sidechain for Bitcoin Cash and has an aim to explore new ideas and unlock novel possibilities. By developing optimized, high-throughput and hardware-friendly libraries compatible with the de facto standards of smart contracts, DeFi applications can be easily migrated into Bitcoin Cash’s ecosystem and run fluently at low cost. In March 2021, smartBCH raised 1000 BCH from the Bitcoin Cash community with a Flipstarter campaign. The funds will be used for product and business development.
Join the smartBCH community to stay in touch!
Twitter: **https://twitter.com/SmartBCH**
Discord: **https://discord.gg/uNTRSz6msj**
Read.Cash: **https://read.cash/@smartbch**
Telegram (Community Chat): **https://t.me/smartbch_community**
Telegram Announcement Channel: **https://t.me/smartbch_official**
GitHub: **https://github.com/smartbch**
Reddit: **https://www.reddit.com/user/SmartBCH**
@SmartBCH