We are pursuing this idea of being able to access any token, NFT, DEFI contract, on any blockchain, with low fees and securely; what we are calling the internet of value.

Good news everyone, we recently tested our new bridge between SmartBCH and Binance Smart Chain, we transferred our Swap token Ki from SmartBCH to BSC, with what is a new set of smart contracts. While we initially deployed already available open source code for our Testnet bridge, after long consideration and testing a few other bridges, we decided to design and create our own bridge! On this and an upcoming post I will try to summarize why we are writing new code, how are things going and what plans we have as we built the basic infrastructure to the internet of value!

Bitcoin Cash at the center of the bridge, its PoW Baby!

The highly scalable properties of Smart Bitcoin Cash, and its low fees create the perfect platform to make it the center of a set of bridges and tools that would allow for value to flow across chains. We see a future where tokens and NFTS securely move across blockchains with low fees and high security. We see how in turn PoW based scarcity and usefulness, are the ultimate value generators for a blockchain coin. Not all networks are the same, and PoW chains are the only ones we believe can be truly scarce. Consider how relatively easy it is to launch a new PoS chain, yet the same is not true for a PoW chain, energy sets a hard limit and creates real scarcity. Scalable and scarce, Bitcoin Cash is the perfect platform for the internet of value.

​

Bitcoin Cash at the center of the Internet of Value

Federated bridges

We had previously discussed how a Federated bridge works, if you will like to learn more about them please check our previous post: https://www.reddit.com/r/btc/comments/osynga/lets_talk_about_bridges/

Here are some popular Federated bridges, they all work very similarly to each other.

-https://bridge.roninchain.com/-https://github.com/ChainSafe/ChainBridge-https://github.com/certusone/wormhole-https://github.com/rsksmart/tokenbridge-https://xbridge.qbt.fi/bridge

Many of the above bridges suffered recent hacks, the attacks targeted vulnerabilities on their smart contracts code, and API end points. Some of these bridges are trying to do a lot of things, have lots of moving parts and are very complex. In the case of Wormhole, they created not only a bridge but a protocol that allows any message to be relayed across multiple chains, while useful the added complexity may prove to be a mistake. We believe it would be better to focus every design detail on resiliency. Roninchain attack results in 600M dollars being lost!

A big disadvantage of federated bridges is that federators need to coordinate their actions. This proved to be a challenge on our recent work testing RSK bridge and Chainsafe bridge. Not only are they difficult to deploy and maintain, but coordinating work among members of the bridge proved extremely difficult.

Many of these Federator bridges have limited multi chain support, adding new chains adds complexity. For instance if you wanted to use RSK bridge to support multiple chains, you would end up having to deploy one bridge set for each one of the chains. Then coordinating the work among the different participants of the federation becomes an even more difficult task. A nightmare for any devops, and a security issue for the bridge itself.

Federated bridges like RSK need several transactions to complete moving a token with minimal security. In this case, even while the platform is configured to always receive 5 out of 5 signatures, the high costs result in that there is always just 3 signatures, the other 2 are out of the picture for real world usage.

When things go bad for Federators, an it does happen often, lots of devops work required. This required work adds risks, coordination among the different parties running a Federator is often needed.

These are just some of the most notorious issues with the current generation of available bridges, there are many more considerations.

Our solution, “Signatory bridges”.

Signatories based bridges share various of the same ideas that make Federated bridges work, but they simplify the components that make bridging possible .

Lets now go over how a token is moved using our new bridge. First the user sends the token into a multi-signature contract that locks it. Signatories take notice of the deposits, once the deposits gets to a certain level of finality, signatories do their best attempt to make accessible a signed message certifying that a token is locked into the bridge contract. Unlike Federators voting on the destination chain contract, a Signatory merely signs a message and blindly does its best to write to a website. The Signatory does not have any open ports, it is completely hidden from the internet. Does not communicate to other signatories or even tries to call functions of any contracts. It works completely independently. It sees a transaction, it signs it when it is certain the transaction won't be rolled back.

Multiple Signatories running independently are signing the same transaction and doing their best to communicate it to the outside world. One or a few failing to do so, does not stop the transaction from being successful. Our bridge is optimized for resiliency. A user is able to find enough Signatories signed messages corresponding to his deposit and put them together to form a claim.

The user then switches to the destination network and submits a transaction with the claim to the bridge contract on the other side. If the claim is valid the contract then mints or unlocks the coins/tokens and sends them to the user submitting the claim.

The way the destination contract knows the claim is valid is by checking the validity of the signatures. The contract stores the public keys of the signatories it trusts so that it can verify that the claim message was in-fact signed by the signatories.

This simplifies the bridging process a lot; there is no voting meaning lower complexity and much lower costs on the contract. There is no need for Federators paying contracts for each of the votes. Instead of multiple transactions, this signatory method only needs 2. One deposit, one claims. While at the same time maintaining the levels of security of signatories and even improving it. You will notice that it wont make much difference to have a 3 out of 5 signature check scheme, or a 15 out of 20, it would still only be 2 transactions.

Signatories are EXTREMELY simple, small code footprint, well-known cryptography primitives. Closed box, rarely will need an update if ever. Can be deployed in minutes, no open ports and can be kept under a firewall. Set it and forget it. No access to keys by Devops. The Signatory makes use of a docker container with an encrypted file system. Upon its first run internally generates keys and informs of its public key.

Notice how the only thing that the signatories did is they certified a transaction exists and is valid. Signatories did not move any value from one chain to another. There may a time when laws may need services moving value to report on them.

Another big upside, adapting the code for non EVM compatible blockchains is extremely easy. Only the claiming contracts need to be rewritten. Imagine the same on a Federators based bridge, they need to support making calls for different types of blockchains. A lot more complex!

Ki is a SmartBCH sep20 token, now available in Binance Smart Chain.

Pick only two: Fast, Cheap, Secure?

This post is already way too long, and we have more to share but will continue on a follow up post starting with an answer to the Pick Two question above.

If you would like to support the work we are doing, consider switching some of your liquidity and trading to our decentralized exchange at https://www.koingfu.com , You can also buy some of our recently launched token $Ki , all the work we are doing will be supported by it as we move forward!

You can also join our Telegram group, the group is only available with this invite link: https://t.me/+Hi_qG5A59IhiZGQx

​

Thank you!