CommerceBlock in Nutshell
Website: https://www.commerceblock.com
Twitter: https://twitter.com/commerceblock
Github: https://github.com/commerceblock
Telegram: https://t.me/commerceblock
CommerceBlock have crafted MainStay sidechains with a Covalence token economy model and GuardNodes to secure the network with integrated BIP175 Pay-To-Contract integration, a Bitcoin Improvement Proposal by CB founders that has also implemented by Decred. The vision is a tree-like network of interconnected chains supporting tokenised assets (commodities & other physical assets/securities/derivatives etc), all governed by GuardNodes that earn native leaf chain tokens for services (similar to Masternodes).
Tech Summary
BIP175 Pay-To-Contract Protocol
Designed to mimic real-world payment interactions between merchants and customers whilst ensuring only the merchant and customer have cryptographic proof of who is being paid and for what (kinda like zero knowledge proofs). Used instead of OP_RETURN as more efficient and reduces blockchain bloating
MainStay Protocol
Highly efficient, scalable and interoperable sidechain systems that can incorporate advanced smart-contracting and privacy features while simultaneously exploiting the full security and immutability of the Bitcoin blockchain secured via proof-of-work
Covalence Protocol
Provides framework for sharing token economies with fine balance between decentralisation, transparency, governance and ownership that is scalable, efficient and secure
GuardNodes
Secure & govern the network consensus rules and provide distributed services to lightweight clients and sidechain users, paid in leaf chain token
Use Cases
Primary use case for sidechains is tokenisation of assets from securities to commodities whilst leveraging the most secure blockchain — Bitcoin. ‘Tree’ and ‘leaf’ chains secured to Bitcoin StayChain create interconnected network of asset chains. GuardNodes are essentially masternodes/staking CBTs (based on Decred’s ticketing system), but payout in the corresponding transactional asset… e.g. stake CBTs, get Oil Token, Platinum Token, Fine Art token etc.
Network Utility
The CBT token will be used to coordinate the provision of network and validation services to asset-backed and STO sidechains. An asset-backed token sidechain will provide their transaction fees to a distributed group of ‘GuardNodes’ that provide network monitoring and other services. Being a part of that group will require the staking (time-locking) of CBT, and payout in local leaf chain asset.
Permissioning
The client has full control over all the chain permissions and policy. The feature provided via the GuardNode platform is that they (via the service agreement) agree to pay all of, or a fraction of, the transaction fees generated on their chain to a specified number of GuardNodes. They set the fee policy — but if they wanted they could pay additional funds to ensure they incentivised GuardNodes adequately for the distributed security they provide. Ultimately, the market will decide on the value of the service.
In the current implementation, client chains issue requests which allow them to specify the parameters of both the service agreement (length, no. tickets, auction parameters etc.) and the fee payments. So, GuardNodes cannot be replaced during the service period. The service period is chosen by the client chain, but it’s expected that it will be on the order of months. There will be mechanisms to make rolling over service periods seamless, but inoperative or poorly performing GuardNodes can be replaced at the service renewal. It has been designed so that the incentives should ensure a consistent level of service — with the use of CBT locking, service proofs and reputation tokens.
Reputation Tokens/Credits (REP)
Trust can be built via Reputation Tokens. For example, 1 Reputation Token for each day of verified ‘service’ (i.e. running a GuardNode). Reputation Tokens can then be used to get a discount on the required staking amount. This is not currently planned as a tradable token.
ERC20 CBT vs Mainnet
CBTs are currently in an ERC20 contract on Ethereum, but to use them (to run a GuardNode) they will be need to be transferred to the CBT mainnet (or service chain). Whilst Exchanges catch up with the tech, to facilitate this temporarily, CB are implementing a two-way peg between the ERC20 contract the service chain — this will enable users to move CBT back-and-forth as required. This will work in a very similar way to how BTC is transferred into the Liquid sidechain, and will be controlled by the block-producing nodes of the sidechain.
Wallet
Currently building on a forked version of Electrum but this will likely be a pretty basic interface (i.e. just holding/trading tokens). The GuardNode interface will be more complex to provide a user-friendly way of staking, getting tickets running the nodes etc. This will be based off of something like Decredition and a one-click solution.
Further Reading
Building the CommerceBlock Tree (high level)
https://blog.commerceblock.com/building-the-commerceblock-tree-1ee39430cfac
Cultivating the CommerceBlock Tree (a little more detail)
https://blog.commerceblock.com/cultivating-the-commerceblock-tree-b2e38e9e7677
MainStay Protocol Summary
https://blog.commerceblock.com/attestation-with-mainstay-78f06feb3aea
MainStay Whitepaper
https://www.commerceblock.com/wp-content/uploads/2018/03/commerceblock-mainstay-whitepaper.pdf
Covalence Whitepaper
https://www.commerceblock.com/wp-content/uploads/2018/12/covalence-1.pdf
Github GuardNode Spec
https://github.com/commerceblock/ocean-api-reference/blob/master/guardnode.md
Liquid to Ocean (differences between Blockstream’s Liquid and CommerceBlock’s Ocean)