Bringing custom sidechain

Blockchain
Blockchain – is immutable storage / ledger with decentralized peers and own consensus rules. All changes are made through the transactions.

Append new transaction
node
validator
Client broadcast the unconfirmed tx to all known peers. No guarantees, that leader will receive it first.
Client broadcast the tx
Validator validate the tx alongside with other txs in pool. Then form block by timer or by size.
Validator validate the tx
1
2
Validator mint block and replicate it over all known peers.
Validator mint block
3
node

Delays between tx has been broadcasted and validator received it
Latency
Higher fee – higher chances to be included in next block
Fees
1
2
We have to wait, until blockchain will validate enough txs, or timer will be triggered
Block mint delay
3
Time issues
Which factors can impact on new transaction to be included in block?

Off-chain
Off-chain is a pattern, where some operations, related to blockchain, are performed out of blockchain on custom platform

Off-chain concept
TX1: Alice->Bob (5 coins)
TX2 Alice-> Mike (5 coins)
Alice
TX1: Bob->Mike (2 coins)
Bob
1
2
TX1: Mike->Alice (2 coins)
Mike
3
5 coins
10 coins
2 coins
2 coins
DELTA
Alice: -13 coins
Bob: +3 coins
Mike +10 coins
Transaction

Off-chain implementations
General backend
sidechain

Sidechain
Sidechain is a pattern, which allows to use certain blockchain tokens on another blockchain / platform with an ability to move these tokens to original chain

Sidechain
GCR Token clone
Send to platform account (holder)
Holder send tokens back to account
GCR Token
Platform mint new tokens

Cluster components
State machine
Consensus Engine
Run all rules against tx
Form global state of system
Properties
Replicate all data across the cluster
Take care of collisions
Properties

Full EVM machine, as on Parity and Geth clients
Full EVM support
Can connect via web3
Integrated client
1
2
Mint block per each performed action
Quick block minting
3
State machine
State machine with Ganache

MOKKA use single leadership model for making changes to RSM, however each follower may hold unconfirmed changes and replicate them (via gossip protocol).
CP algorithm
MOKKA use internal timers for checking latency and timeouts (strategy nested from RAFT).
Sync system
1
2
Due to single leadership model, MOKKA appends changes quite slow, as all of these changes have to be processed by single leader first.
Performance
3
Consensus Mokka

Workflow
Send to platform account (holder)
The transaction about token transfer
Transaction validation
Consensus replicates all data
Node send new events to service

Real example
https://github.com/ega-forever/mokka/tree/master/examples/node/decentralized-ganache
Distributed ganache

Опрос
https://otus.ru/polls/6416/