Here's a presentation from our Software Engineer - Vuksan Simunovic who explained how to bootstrap a custom proof of stake blockchain network with a few examples, additional clarification, and useful tools.

1. Bootstrapping a Custom
Proof-of-Stake Blockchain Network
Vuksan Simunović
Software Engineer @ MVP Workshop
August 12, 2019

2. For some time now, we have been striving to broaden our knowledge about
custom blockchain solutions.
Business-wise, PoS consensus in a blockchain network is a much better
option, although it comes with a set of disadvantages which we had to
overcome during development.
Therefore, this presentation is about the entire process of
implementing a custom blockchain — something that we have
been mastering along the way.

3. Ethereum blockchain operates under certain rules that cannot be changed.
Rules are useful — that we can agree on. Yet, rules such as the ones proposed by
Proof-of-Stake (PoS) or Proof-of-Work (PoW) consensus cannot be applied to
every single product or business that exists and wants to become
blockchain-based. In that case, you can:
01 02
Start building a new
blockchain from
scratch
(time, energy & money consuming)
Use some existing
frameworks such as
Cosmos-SDK and
Tendermint.

4. First things first, let’s take a look at
the current state of affairs in PoS
networks.

5. Business Advantages and Technological
Disadvantages of PoS Networks
Proof-of-Stake networks are often a more convenient solution for
products that strive to introduce blockchain than Proof-of-Work networks.
● The main advantage of PoS is that it consumes less energy
● The main disadvantage of PoS is bootstrapping period

6. Implementing a Custom Blockchain
Here at MVP Workshop (yes, we are a blockchain R&D studio), we are working
with various blockchain solutions that are based on existing blockchain
platforms, such as Ethereum and Stellar.
But, however powerful, these technologies have certain limitations. For example,
Ethereum enables deploying custom logic using Smart Contracts, but its core
concepts, such as the network’s consensus algorithm, cannot be modified easily.
Having scrutinized the web, we stumbled upon Cosmos Network and decided to
use its building blocks — Tendermint and Cosmos-SDK — to build Electionr.

7. Simplified Blockchain Architecture
From an architectural perspective, every blockchain
consists of three layers:
● Networking — Responsible for transactions
propagation via peer-to-peer (p2p) communication
between nodes.
● Consensus — A fault-tolerant mechanism used to
reach an agreement on the current state of the
network. Notable examples include Proof-of-Work
(PoW) and Proof-of-Stake (PoS).
● Application — Responsible for updating the network
state by executing transactions in a deterministic
manner. For Ethereum, this is Ethereum Virtual
Machine (EVM).

8. What Is Tendermint?
Tendermint is a Byzantine-fault-tolerant (BFT) state machine replica. Its
purpose is to provide networking and consensus layers that make up a
generic engine so that developers only have to worry about the
application layer of their blockchain.

9. What Is Cosmos-SDK?
Cosmos-SDK is a framework for building a blockchain application layer
whose power comes from its modularity.
SDK applications are built by aggregating a collection of interoperable
modules. Each module can be seen as a small state-machine. It maintains
a subset of the state and contains its own transaction processor, while the
SDK is responsible for routing each transaction to its respective module.

10. The most notable modules are:
Auth — Used to manage accounts.
Bank — Transfers tokens between accounts.
Distribution — Passively distributes rewards in
the system.
Staking — Used to enable blockchain to
support a PoS system.
Slashing — Disincentivizes any malicious
activity by a network actor with value at stake
by penalizing him.

11. Electionr
We named our custom blockchain implementation Electionr since its
primary objective is to introduce a transparent and fairer process for
bootstrapping a Proof-of-Stake (PoS) network.
Check out our GitHub account
https://github.com/MVPWorkshop/electionr

12. Electionr - The Problem
If a PoS network is launched with no pre-mine, and block rewards are
issued to validators, then its starting validators can accumulate 100% of
the tokens. If there is no permissionless modus operandi to nominate
validators, then the starting validators may be a colluding cartel or greedy
founders who can dominate the network — especially in the early years
when inflation is still high.

13. Electionr - The Solution
In order to launch an egalitarian Proof-of-Stake network, validator nodes
are elected using a process called Proof of Determination (PoD) during the
first year.
PoD is based on PoW, but with one major difference — it is stopped before
the major flaws that PoW brings have the chance to emerge, since it is
limited to one year. By using elements of Proof-of-Work to bootstrap the
initial validator set without a pre-mined sum, we can avoid giving starting
validators too much power and unfair advantage from the beginning.

14. Electionr - The Solution
PoD is used to prepare the PoS network by deploying an election contract,
as well as a bridging contract that links PoS chain to Ethereum.
This PoD process consists of 12 monthly cycles. Each month, the validator
pool is expanded to allow cycle winners to enter and take their roles as
new validators.

15. Electionr - The Solution
The election contract enables validator-elects to nominate themselves to
become a validator. In order to do that, they need to call the contract’s
public method with the following arguments: their PoS key, validator’s
operator address, nonce, and the hash of these attributes. After the cycle
is over, seven lowest hashes are chosen as new validators. Any
validator-elect can choose to increase their odds by cycling through
nonces off-chain and attempting to find the lowest possible hash before
calling the contract method.

16. Electionr - The Solution
The bridge contract enables the movement of Ethereum assets to the
liquidity pool on the PoS network. The bridge contract can be either
one-way or two-way. The one-way bridge does not allow removing ETH and
is inherently safer and less complex. The one-way bridge can also be
decommissioned after the network has been bootstrapped. On the other
hand, the two-way bridge gives liquidity to tokens on the PoS network
since it allows them to be sold for ETH via signature consensus. The
two-way bridge is more complex since it requires slashing conditions on
the PoS network to prevent stealing assets.

17. Peer-to-peer network is a
real pain to draw. Here’s
our try!

18. Electionr - Implementation
The election (Ethereum) contract is written in Solidity and consists of three public functions:
● electMe() — Checks whether submitted function arguments are valid and positions validator-elect in the right place in a sorted
doubly linked list.
● publishGenesisSigs() — The caller of this function is a validator with the lowest submitted hash during the initial PoD cycle. After
this function is called, the pointer in the doubly linked list is moved to the first non-validator hash, and GenesisValidatorSet
event is emitted, publishing elected validators that should initialize the network. The next cycle begins after that.
● publishSigs() — After the initial cycle period, publishing a new validator set is not limited only to the one with the lowest hash
but is open to anyone. Everything else is rather similar to publishGenesisSigs().
The election (Ethereum)
contract is written in Solidity
and consists of three public
functions:

19. We hope that you like what you’ve read so far.
Before continuing to the conclusions here’s a chance to visit our
blog and read all about the Electionr Tools, and Validator
Election and Protection.

20. Conclusion
However interesting, this project proved to be a real challenge.
Understanding the concepts implemented by Tendermint and Cosmos is
not an easy task since their project is continually evolving and new
concepts are often being introduced.
In other words, our team had to keep up with this rapidly evolving
technology and frequently adjust the codebase so that our project stays
up-to-date with Cosmos-SDK, without trying to modify the constantly
changing codebase.

21. Thank you!
No matter if you have just an idea you would like to validate, or already existing
project you would like us to collaborate on – we are open for a chat.
GET IN TOUCH

22. Follow us and subscribe for more company updates
@mvpworkshop
@mvpworkshop
@mvpworkshop
And feel free to get in touch
services@mvpworkshop.co