Customizing EOSIO for Remme Protocol and REMChain: Consensus and Governance

As we’ve recently announced, for a number of reasons, Remme Protocol is movingto a faster and more scalable EOSIO ecosystem. To explain all the changes the Protocol will undergo, we’re launching a series of blogposts.

For us, forking the EOSIO codebase begins with customizing it for our specific use cases and token economy. With REMChain being run on Remme Protocol which in turn being built on the EOSIO codebase, it will not depend on the EOS mainnet. So REMChain will remain an independent blockchain fueled by the REM token, borrowing the best aspects of the EOSIO consensus.

Consensus Algorithm (BFT-DPOS)

Remme Protocol utilizes the only known decentralized consensus algorithm proven capable of meeting the performance requirements of PKI(d) applications on the blockchain, Delegated Proof of Stake (DPoS). Under this algorithm, those who hold a certain amount of tokens on a blockchain adopting the protocol software may select Block Producers (BPs) through a continuous voting mechanism. Anyone who accumulates a minimum required amount of tokens may choose to participate in block producer election by running for top 21 status or vote for other candidates they trust and feel confident about.

Active participation in the network’s governance (consistent voting and keeping a minimum required token balance staked) is a requirement to participate in the reward distribution process. The power of the vote is proportional to the amount of tokens that the account agreed to stake (the more tokens you stake the more influential your vote). This system of governance with the Block Producer election process puts the token holders in charge and sets proper incentives to elect the most credible and professional candidates to produce blocks. Otherwise, token holders would incur significant financial losses if the candidates they elected misbehaved and the network delivered a poor service to the end users.

The Remme Protocol software enables blocks to be produced exactly every 0.5 seconds and exactly one producer is authorized to produce a block at any given point in time. If the block is not produced at the scheduled time, then the block for that time slot is skipped. When one or more blocks are skipped, there is a 0.5 or more second gap in the blockchain.

Using the Remme Protocol, blocks are produced in rounds of 126 (6 blocks each, times 21 producers). At the start of each round, 21 unique block producers are chosen by the preference of votes cast by token holders. The selected producers are scheduled in an order agreed upon by 15 or more producers.

If a producer misses a block and has not produced any block within the last 24 hours they are removed from consideration until they notify the blockchain of their intention to start producing blocks again. This ensures the network operates smoothly by minimizing the number of blocks missed by not scheduling producers who are proven to be unreliable.

Under normal conditions a DPOS blockchain does not experience any forks because, rather than compete, the block producers cooperate to produce blocks. In the event of a fork, consensus will automatically switch to the longest chain. This method works because the rate at which blocks are added to a blockchain fork is directly correlated to the percentage of block producers that share the same consensus. In other words, a blockchain fork with more producers on it will grow in length faster than one with fewer producers, because the fork with more producers will experience fewer missed blocks.

Furthermore, no block producer should be producing blocks on two forks at the same time. A block producer caught doing this will likely be voted out. Cryptographic evidence of such double production may also be used to automatically remove abusers.

Byzantine Fault Tolerance (BFT) is added to traditional DPOS by allowing all producers to sign all blocks so long as no producer signs two blocks with the same timestamp or the same block height. Once 15 producers have signed a block, the block is deemed irreversible.

BFT Delegated Proof of Stake is robust under every conceivable natural network disruption and even secure in the face of the corruption of a large minority of producers. Unlike some competing algorithms, BFT can continue to function when a majority of producers fail. During this process, the community can vote to replace the failed producers until it can resume 100% participation.

Block Rewards

The block reward is divided between Block Producers in the following proportions:

70% — Shared between all Block Producers (both Active and Standby) proportionally to their stake.

20% — Shared between — Active Block Producers (the top21) proportionally to the number of votes they received (1 token = 1 vote).

10% — Remme Savings account

In order to maintain the status of a Block Producer, each one will have to re-assert their vote every week. Those who do not keep their votes up to date for more than a week:

• Block Producer stops getting block rewards
• The influence of last recorded vote decays by half every year

The block rewards are credited to the account with a call to the system’s contract method claimrewards. Rewards are liquid and may be staked by BP as a separate transaction.

How to become a Block Producer

With REMChain remaining an independent blockchain fueled by the REM token, there are specific criteria required to become a BP:

• an account needs to stake minimum 250k REM to be a BP
• tokens are locked for the first six month (you cannot change your mind once you start)
• the power of vote is built up gradually to 100% over six months. Note: BP earns full and liquid rewards from the start

Block Producer resignation

Once the owner decides to resign and no longer serve as a Block Producer, they are required to sign a dedicated transaction that calls the unregprod method within the system contract (not permitted during the lock period over the first six month). After this, staked tokens will gradually release over a period of six months. This is done to secure the network from speculative behavior among Block Producers.

User Agreement

The Remme Protocol software enables the establishment of a peer-to-peer terms of service agreement or a binding contract among those users who sign it, referred to as an “agreement”. The content of this agreement defines obligations among the users which cannot be entirely enforced by code and facilitates dispute resolution by establishing jurisdiction and choice of law along with other mutually accepted rules. Every transaction broadcast on the network must incorporate the hash of the agreement as part of the signature and thereby explicitly binds the signer to the contract.

The agreement also defines the human readable intent of the Protocol source code. This intent is used to identify the difference between a bug and a feature when errors occur and guides the community on what fixes are proper or improper.

Upgrading the Protocol

The Remme Protocol software defines the following process by which the Protocol, as defined by the canonical source code, can be updated:

1. Block producers propose a change to the code and obtain 15/21 approval.
2. Block producers maintain 15/21 approval of the new code for 30 consecutive days.
3. Changes to the code take effect 7 days later, giving all non-producing full nodes 1 week to upgrade after ratification of the source code.
4. All nodes that do not upgrade to the new code shut down automatically.

Emergency Changes

The Block Producers may accelerate the process if a software change is required to fix a harmful bug or security exploit that is actively harming users.

Our next blog post will cover the modifications related to resource management and token economy. Stay tuned!

Get more news about all our products in corporate Blog here.