Proof-of-Service Consensus Algorithm Overview
In our quest to find the most relevant consensus algorithm solution, we studied four such algorithms (RAFT, SBFT, Honey Badger, Algorand) that we expected to meet our requirements. Even though each of them has distinctive advantages, we had to develop our custom consensus to solve the problems we faced, however, namely: a guarantee of stable work, resistance to attacks, complete decentralization and the problem of “isolation of the leader”.
Our main goal was to create a reliable and balanced algorithm that would guarantee the highest level of security as well as ensuring that every masternode holder within the REMME ecosystem is fairly represented and incentivized to participate. Over the last few months, we’ve put our brightest minds from R&D team and REMME Research Lab to create an algorithm solving all of these issues and building a balanced and fair reward system. And we did it!
REMChain is one of the components of our solution and a basic layer of our distributed Public Key Infrastructure — PKI(d) protocol. In a nutshell, it’s a multi-purpose blockchain that acts as a distributed storage for a certificate’s hash, state (valid or revoked), public key and expiration date. Masternodes control the registration and revocation of certificates, with a custom Proof-of-Service consensus algorithm ensuring that these nodes can agree on the order in which entries should be appended to the blockchain.
A feature of our algorithm is a system that is programmed to make a pseudo-random (stochastic model with reputation) selection of masternodes that sign the block. The algorithm is based on the concept of committees that are re-elected for signing each block. The committee is formed using a system of reputation which depends on the initial stake and quality of masternode work (the masternode is always online and proposes only true blocks). The reputation of the masternode and a bet (amount of tokens the masternode holder is ready to place to increase its chance of being selected by the consensus) will influence the random chance of closing the block.
Let’s dive deep into the details of our consensus!
Masternodes are used to provide consistency and fault tolerance. Their primary role is to facilitate the registration of public keys on REMChain and to oversee the revocation of these as required. Masternodes also validate batches of transactions and combine them into blocks, while ensuring that consensus is maintained across the network.
The algorithm controlling the masternodes is developed so as not to limit these to a certain specific number. This makes it possible to avoid operating a closed network and gives everyone the opportunity to compete for participation in signing blocks on REMChain. Also, the absence of a given number makes REMChain more reliable and resilient in terms of potential attacks.
Initially we will launch 300 nodes, divided into two stages. Each of these stages will take a certain period of time to complete. Participation in the tokensale and having retained tokens since that date will give applicants priority to run a masternode in the first phase, which will grant a greater amount of time in which to earn a trusted reputation. This will result in increasing their chances to be chosen to join the committee, and as a result earn a reward. Once the first 300 masternode holders have earned a sufficiently high reputation, the other phase of nodes will be launched for all who wish to join.
Reputation is a sum of stake (min 250,000 or more tokens deposited on the reputational account of a masternode at the moment of its setting up) and accumulated reward for block production as an indicator of trust of the masternode.
The masternode owner can withdraw the minimal stake of 250k tokens at any time, but his masternode will become a node and won’t be able to participate in consensus any more. To start a masternode again, the node owner will have to repeat the installation procedure from the beginning.
The profitability of the masternode owner depends on their reputation: the higher the reputation (the more tokens that are deposited when setting up a node), the greater the likelihood that a masternode will gain entry into the committee and earn a reward for block production.
The committee is the number of masternodes (initially 10) that are allowed to offer block production. The committee for the next consensus is formed in a random way every time after the block is produced. To form a new committee, the algorithm uses the following information: hash-code of the latest block, the list of all masternodes including the amount of reputation on the reputational account of each masternode.
Bet is an amount of tokens that helps to increase the chances of being selected by consensus to produce a block. A bet is restricted from the bottom by the minimum bet (Model value is 10,000 REM tokens at the rate of 1 REM token = $0.04.The value is corrected based on token price volatility) and is defined by the masternode owner. That means each masternode sends its own block and its own bet for consensus approval.
*Note: it is unprofitable to bet too much (more than 9x the cost of a block) due to the network fee commission.
Types of commissions:
- Obligatory payment: Fee is charged for those masternodes that were chosen to become the committee members. The fee is collected in favor of a masternode whose block will be accepted in the blockchain, and will be included in the reward. Model value is 1 REM at the rate of 1 REM = $0.04. The value is corrected based on token price volatility.
- Network fee: Commission of REMChain network. This is paid by a masternode for block production reward and is sent to an address of the REMChain account. Model value is 10%.
- Transaction fee: Commission for internal transactions (including transactions for atomic swaps, transactions between accounts of different nodes, etc) in REMChain blockchain. Model value is 0.1%. The commission goes as a part of the reward to the node, whose block was accepted to the blockchain.
*Note: the fee is not charged for transactions between two accounts of one node.
How it works
When installing a node, the system generates a pair of public and private keys. In turn, the public key is used to generate the addresses of the Operational account and the Reputational account. To become a masternode and to have the possibility of being elected to the committee, it is necessary to make the first operation — to transfer at least 250,000 REM tokens (stake) or more from the Operational account to the Reputational account.
*Note: your reputation can be funded from the operational account only once when installing a masternode. Increasing your reputation while operating a masternode will only be possible through getting a REWARD.
Thus, each masternode has two types of account: Operational and Reputational.
The Reputational account
The Reputational account is developed to store reputation in the form of REM tokens. The reputation of the masternode consists of:
- Deposit made at masternode registration (minimum 250,000 tokens). This amount cannot be withdrawn while the masternode is functioning.
- Part of the reward for operations in REMChain, which can’t be withdrawn just after it has been received. The withdrawal time is calculated individually and depends on the masternode reputation.
The Operational account
The Operational account is developed to store REM tokens that can be used to perform the following:
- Transfer tokens within REMChain (from one Operational account to another Operational account of another masternode owner).
- Transfer tokens from the Reputational account (withdrawing).
- Output / input of tokens from the internal blockchain to the Ethereum blockchain and vice-versa, by converting internal tokens in a 1:1 ratio from ERC20 to REM tokens based on the Atomic Swap (link).
- Make a bet.
- Pay transaction and obligatory fees
*Note: if your node was chosen into the committee and there are not enough tokens on your Operational account to make all necessary payments, the payments will be charged from the Reputational account. This will thereby reduce the reputation of the node.
After a client has generated public keys and specified its lifetime, a committee, formed after the confirmation of the latest block, receives requests for storing public keys. From these requests each masternode included in the committee forms its own variant of the block.
Each block includes a public key from the request and transaction with a bet. Masternodes send produced blocks to all committee members. The consensus on block confirmation is made within the committee and the structure of the committee is changed after each successful block confirmation. If the committee by consensus accepted the block proposed by the masternode, the masternode receives a reward.
The reward for the confirmed block consists of:
- Payments from clients for the maintenance of public keys.
- The own bet of the masternode.
- Obligatory payments of all masternodes that were included in the committee.
- Masternode bet whose block was rejected by consensus in previous iterations of the consensus (if any).
- Transaction fees.
- Minus 10% Network fee.
The reward will be delivered to the Reputational account of the masternode. A part of the delivered amount of tokens will be available for withdrawing to the Operational account. Which part is available for withdrawing will be defined according to the reputation of the masternode.
Each masternode owner can define their own strategy for withdrawal of tokens. Masternode owners can transfer from a Reputational account to the Operational one any amount of tokens available for withdrawal for the moment, but if they want to keep running a node, their stake of available tokens should not drop to less than 250k REM on the Reputational account.
At the same time, you should keep in mind that withdrawing tokens will decrease your reputation, which means that you will have a lower chance of closing the block and earning a reward for it. Meanwhile, accumulating tokens on the Reputational account will help to increase the masternode’s income in the future.
There are two main strategies for managing tokens:
Reputation enhancement model. The masternode owner does not withdraw funds from the Reputational account and thus invests in the reputation of their masternode. The reputation of such nodes is constantly growing, which increases their chances of becoming a committee member, closing the block and getting rewarded for it.
The fast income model. Each masternode has a minimum stake of 250,000 REM deposited on the Reputational account. If an operator chooses a strategy to gain quick income by withdrawing all earned tokens, their reputation remains minimal, which over time reduces the likelihood of getting into the committee and the opportunity to earn money in the system.
REMME’s custom consensus algorithm controls the way in which nodes interact with the network and creates a fair and transparent system that is free of favoritism or centralized effect. Implementation of the reputation and bet approach enabled us to:
- Solve the problem when one particular token holder owns a large amount of tokens and can harm the token economy.
- Create a scheme to minimize possible attacks that can be performed when a particular token holder owns n-quantity of masternodes.
We will present the full document for Token Economy 1.0 where you will be able to find a deep description of REMME’s consensus algorithm. The document will be available on our website before the mainnet launch.
We hope this comprehensive guide to REMME’s custom consensus algorithm and masternode operation has answered all of your questions, and shed greater light on the work we’ve been doing over the last few months. If there are any matters we haven’t addressed to your satisfaction, however, contact the community manager and we’ll do our best to help.