For some time now, we have been striving to broaden our knowledge about custom blockchain solutions. When presented with a problem of creating a fair and transparent method for bootstrapping a blockchain network, we recognized how great a learning opportunity this is to further broaden our knowledge of custom blockchain solutions, and thus Electionr was born.
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 article is not only about creating Electionr but also about the entire process of implementing a custom blockchain — something that we have been mastering along the way.
So, let’s dive right in. When it comes to blockchain, Ethereum brought about a major shift forward in technology, and its limits are yet to be explored. However useful, 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 either need to start building a new blockchain from scratch (which would consume too much of your time, energy, and severely affect your budget) or use some existing frameworks such as Cosmos-SDK and Tendermint.
Apart from creating new rules, what else can we do? We can break the existing ones and we can bend them by finding and exploiting certain loopholes. Breaking the rules is very difficult on blockchain, but bending them to succumb to your will is theoretically possible.
How do we fight bending the rules? By introducing new ones that will minimize potential malpractice. Our project, called Electionr, is based on Cosmos-SDK and Tendermint, and its primary goal is to put a stop to some of the wrongdoings that can occur in existing PoS networks.
First things first, let’s take a look at the current state of affairs in PoS networks.
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. For example, Bitcoin at one point used a total of 0.13% of all the energy in the world. That being said, China is home to the majority of miners who use a lot of energy for PoW mining, and most of it doesn’t come from renewable energy sources, thus creating a negative impact on the planet’s atmosphere and affecting the climate.
Therefore, Proof-of-Stake consensus in a blockchain network is a much better option business-wise, but it also comes with a set of disadvantages that pave the way for malpractice.
One of them is its bootstrapping period. Unlike PoW networks which can start with zero coin supply and equal participation rights, PoS networks need to have initial token distribution since they require several parties to stake tokens from the beginning. That is often done via Initial Coin Offering (ICO) where the initial coin supply is sold and distributed to investors, founders, developers, advisors, etc. In order to raise as much money as possible, founders usually offer large bonuses for big investors, putting smaller ones in a disadvantageous position.
However, those large investors can conspire in order to gain the majority of tokens and, consequently, control of a network. They are often referred to as colluding cartels and are not a welcome sight among PoS network members. If recognized, they can lead to a collapse of trust in a network, making it worthless in the process.
Therefore, our mission with Electionr is pretty clear. We strive to make a PoS blockchain network that includes a fairer, transparent initial role distribution process, hoping to put an end to one of the pressing problems regarding the PoS consensus.
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. Moreover, we have recently become a member of the Enterprise Ethereum Alliance, in addition to becoming a Stellar technology company partner.
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 faced a problem that involved launching a Proof-of-Stake network in an egalitarian way, which implies issuing block rewards in a fair, liquid, and accessible manner with no pre-mined sum, we knew that there was a need for an alternative solution.
Having scrutinized the web, we stumbled upon Cosmos Network and decided to use its building blocks — Tendermint and Cosmos-SDK — to build Electionr.
What Are Tendermint and Cosmos-SDK?
Before we proceed to discuss our project, let’s take a quick overview of a simplified blockchain architecture as well as these two Cosmos’ blocks.
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).
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.
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.
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.
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. The idea for this problem and its solution originated from the work we did on Legaler’s Proof of Determination Whitepaper.
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.
Even if the cartel or greedy founders are not present, massive coordination is required between genesis validators to launch the network, which creates channels of communication that may be exploited by cartels later. If tokens are not issued to non-validators, then non-validators can never enter the validator set. Such networks are doomed to fail.
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.
Therefore, 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.
- 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.
- 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.
When the PoS network starts working, a minor block reward (approximately 33%) is emitted into the liquidity pool on each block.
Once elected, the minimum number of validators will launch the network. Their growth is controlled in a predictable and permissionless manner until the maximum number of validators is reached. Once that happens, the election contract no longer serves a purpose and can be decommissioned. That ends the PoD process, leaving an active PoS network that is launched in an egalitarian way.
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().
One of the bigger issues during contract implementation was gas cost since we had to keep a record of every submitted hash and its submitter’s position in PoD. Our initial idea was to store submitted hashes in an array that would be sorted on publishGenesisSigs()/publishSigs() execution, but that idea was discarded quickly because it would require a lot of gas and could potentially exceed block gas limit, making the function uncallable.
Instead, we opted to use a sorted doubly linked list with a pointer on an item with the lowest submitted hash. When electMe() is called the submitted hash is stored at the position that represents the candidate’s place in line for becoming a validator. For example, if the list is populated with hashes respectively starting with 0x1, 0x2, 0x3, and the submitted hash is starting with 0x0, it will be stored at the beginning of the list and its submitter would be first in line to become a validator in the next cycle.
After the initial PoD cycle is completed and there are enough candidates who have submitted their hash, publishGenesisSigs() function will be enabled. The pointer that had pointed to the elect with the lowest hash will be moved to the first non-validator hash in a sorted list, and a GenesisValidatorSet event with relevant data of newly elected validators will be emitted. That way, we are keeping a history of previously elected validators on-chain. The process is repeated every 12 months when the maximum number of validators is reached.
Note: Computer scientists often joke that there are two hard things in their field of study — cache invalidation and naming things. We failed at the latter, as we unfortunately used both elected validators and validator-elects to denote validator winners that have submitted the lowest hashes in the cycle.
Electionr Tools
The idea behind Electionr Tools was to lower the knowledge barrier validators need in order to participate in Electionr blockchain. Certain tedious processes such as sending Transaction, “Mining” PoD hash, and more, are made easier with these tools:
- PoD “Miner” — Its goal is to make the hash calculation more convenient and automated. It should handle all monotonous processes of nonce incrementation and put your mind at ease so that you don’t have to worry whether you have sent the lowest hash of the ones calculated. You could even control the amount of gas you want to spend by specifying the time interval between subsequent calls of the electMe() method. If the miner, in any iteration, doesn’t find lower hash than the one in previous iterations, it won’t waste gas by submitting it to the contract.
- Initialize genesis script — Generates a genesis.json file for bootstrapping the network. Its job is to generate appropriate genesis.json for the provided validator set when a GenesisValidatorSet event from Ethereum main network gets emitted.
- Ethereum cycle watcher — After the network has been bootstrapped, first validators on the Electionr blockchain will need to run this script in order to watch for the next elected validator set that will be submitted by the NewValidatorsSet event.
Electionr Blockchain (Validator Election and Protection)
In order to allow validators to add new validator-elects to the validator set, we extended Cosmos-SDK with an additional election module. After each validator receives a NewValidatorsSet event that the PoD cycle for the month has finished, they can use the election module Insert function to broadcast that information (a list of validator-elects) to other validators.
But why would validators want to add more validators to Electionr blockchain? Because the block reward that each validator gets is designed to increase every time a new validator is added to the network. It is based on the following formula: BR * n/m, where BR represents block reward, n is the current number of validators in the network, and m is the maximum number of validators.
After more than two-thirds of validators have broadcast the same pieces of information about the cycle (voted on it), the consensus is achieved and the maximum number of validators is increased. Each validator-elect is given enough coins in order to achieve the minimum amount of power necessary to participate in Electionr blockchain as a validator.
Newly elected validators are protected for one month. After proving that they are determined (by participating in the PoD cycle), they will receive protection and get a fair chance to gather enough coins through the block reward system before someone can push them out with a higher stake. In order to achieve that, we had to modify the staking module of Cosmos-SDK — mainly the validator state change that occurs on every block.
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.
Our future milestones are:
- Modification of Cosmos SDK minting formula.
- Modification of Cosmos SDK fee distribution to validators.
- Implementation of the liquidity pool and one-way bridge contract.
- Implementation of the two-way bridge contract.
We believe that projects like Cosmos and Polkadot represent the future of blockchain. Custom blockchain implementations have the potential to improve processes that underlay present-day blockchain technology, thus contributing to decentralization and facilitating the creation of secure and trustless systems that could become one of the most sought-after technologies in days to come.
If you are interested in helping us finalize Electionr blockchain by contributing to this project, feel free to contact us.
If you wish to discover more about our studio, partner up or work with us, feel free to explore our services at mvpworkshop.co
Follow us and subscribe for more company updates and join the conversation on Twitter and LinkedIn. For free business consultation about how blockchain can impact and change your business model, or anything else related to the technology — contact us at [email protected]
Bootstrapping a Custom PoS Blockchain Network was originally published in MVP Workshop on Medium, where people are continuing the conversation by highlighting and responding to this story.
