Stratis Federated Sidechains

Stratis is in the process of bootstrapping and deploying the first community ran sidechain. This will enable the execution of immutable code written in native C# (or smart contracts in C#) meaning the production and validation of the blocks on the sidechain network will be out of the control of any central authority and is the responsibility of the miners on the sidechain.

A quick recap on sidechains

The Stratis sidechain concept is based on the custodial federation model, coins are held in a multisig account controlled by a group of federation members which verify and approve transfers between the mainchain and the sidechain.

A detailed explanation of sidechains can be found here:
https://academy.stratisplatform.com/Sidechains/sidechains-introduction.html

At a high level, a user on the mainchain sends coins to the multisig address and specifies in an op_return the target address on the sidechain. After enough confirmations have occurred (on the Stratis mainchain a block is considered final after 500 confirmations or around 8 hours) the federation will unlock coins on the sidechain multisig to the users target address. The same process works when you send them back to the mainchain.

A more technical specification of the cross chain transfer can be found here:
https://github.com/stratisproject/FederatedSidechains/blob/master/requirements/cross-chain-transfer.md

The sidechain block production currently uses a simple Proof of Authority consensus model to extend the ledger history, more info on PoA can be found here:
https://academy.stratisplatform.com/FullNode/PoA/PoA-introduction.html
And here: https://github.com/stratisproject/StratisBitcoinFullNode/blob/master/Documentation/Features/PoA/PoA_overview.md

The responsibility of the collateral nodes

The federation members are not to be confused with the sidechain block producers (which is Stratis’ definition of master nodes).

In the selected approach we combined the multisig federation members with the block producers to form two tiers of master nodes:

• 10k STRAT collateral: these are block producer nodes.
  There can be up to 100 such nodes per sidechain.
• 50k STRAT collateral: these are block producers and multisig federation members.
  Their responsibility is to produce blocks and authorise the transfer of coins between the mainchain and sidechain.
  These nodes have the added responsibility of securing the funds locked in the multisig and therefore require higher collateral.

Master nodes that are not producing blocks for a defined period of time will be kicked off by the network protocol itself.

Mining and master nodes

The master node collateral will be kept on the mainchain.
This is so the node operators can collect both the reward on the fee and by staking the mainchain.
The more sidechains the more secure the mainchain will become. We anticipate that, once cold staking is activated, significantly more coins will be locked in to master nodes and be used for staking, as a result staking weight will increase and with it the network security.

Semi decentralization, is it even a thing?

The processes of achieving consensus in POA is not as decentralized as POW/POS, so I would classify this model as a semi-decentralised consensus model where the security of the sidechain network is inherited form the mainchain network and the collateral of the block producers.

Should I build a sidechain?

I was approached a few times from companies asking if they should build a sidechain.

There can be a few reasons to build a sidechain on Stratis, for example keeping a sidechain lightweight. Or building a strong network without a community of miners, it will be fairly easy to find a few millions of STRAT in the Stratis community as federation members that will allocate collateral to secure a sidechains.

Smart Contracts

Smart contracts are effectively extensions of the protocol.

The Bitcoin security model is very conservative, extensions to the protocol are signalled using BIP9 by miners. This is how various features got activated like BIP68 and SegWit.
Bitcoin also has the notion of standard transactions, these are scripts (the smart contracts of Bitcoin) which are known templates of transactions that nodes on the network will relay, to create non-standard transactions on the bitcoin protocol one has to be a miner (or have access to a miner).

Ethereum has no limitation on protocol extensions that can be submitted on the blockchain. Any script that can be serialized to EVM byte code is relayed and deployed by the miners. Ethereum are also standardizing smart contracts to create widely used industry accepted interfaces for smart contracts (ERC20, ERC721, ERC1155 etc…) that are properly tested, secured and approved by the Ethereum community.

Other blockchains build on the emerging Web Assembly (WASM) standard, a byte code VM designed for the web. EOS for example currently supports C++ to WASM compilations.

What makes Web Assembly especially appealing for developing smart contracts is its limited nondeterministic execution. While WASM is not mature enough at the moment there are various C# to WASM compilers in development.

Testing smart contracts is also a big part of the industry. Many companies offer services to audit contracts, due to the immutable nature of contracts.

Stratis Smart Contracts

Whitelisted smart contracts templates in native C#

Stratis smart contract templates will be publicly verified, they are then voted in by the miners before they are activated. Once a template is activated there is no limit on how many contracts can be deployed, more on how voting works can be found here:
https://github.com/stratisproject/StratisBitcoinFullNode/blob/master/Documentation/Features/SmartContracts/Contract_whitelisting.md

The dotnet core CLR is not a deterministic language, so to protect the network and its operators contracts must be verified to be a deterministic subset of byte code before they can be used, the processes of approval will be open and public. Contracts that have been rigorously tested to be secure and not violate determinism will be more likely to be voted by miners. Miners incentive to vote in contracts is the fee market they will create.

Longer deployment time but more testing
Smart contracts as a result will take longer to get deployed (until the template is whitelisted) but are arguably more secure due to the extra layer of testing that is required before they can be used. its also much easier to test such contracts as they execute in native C# so all the existing test framework and tools can be used.

Avoiding unethical contracts
An added side effect of contract whitelisting is the likely filtering out of contracts that can be considered unethical.

Ultimately the incentive of block producers is to generate revenue and it’s in their best interest to only look at the technical side of the code.

But the processes of verifying the C# language and the byte code will inevitably generate a discussion about moral and ethical functionality of the code itself and allow block producers a say on whether to vote such contracts in to the network.

C# smart contracts version 2

Currently the main goal for Stratis is to release a C# based smart contract platform on sidechains, this is so we can start to build the use-cases and the ecosystem around Stratis.

Our current smart contract engine has been designed in advance to allow to replace the byte code VM with other implementations such as a WASM VM.

So as the webassembly space matures and builds tools and support around the C# language, Stratis plan to release a future sidechain that will run a WASM VM.

To Summarise

Stratis is focusing on scaling crypto networks using sidechains, the upcoming Cirrus release is a demonstration of capabilities of the Stratis tech building on the same codebase that the main network (STRAT)is deployed on, the Stratis Fullnode Platform.

It’s also a demonstration of using different ways to achieve consensus on top of that same platform, the C# byte code engine.