-
Notifications
You must be signed in to change notification settings - Fork 15
REMME masternodes high level concept 0.1.1
Masternodes or bonded validator systems are the series of servers that provide consistency and fault tolerance of the REMME blockchain network which provides fast and low-cost transactions for managing PKId. Masternodes are responsible for enabling specific services such as registering certificates on the blockchain and managing the revocation process.
The REMME core includes blockchain layer based on Hyperledger Sawtooth – a framework for custom blockchains designed to be modular: every part of the framework including the consensus algorithm can be replaced with custom code.
The REMME core is a system based on a custom consensus algorithm (Proof-of-service) which is the synergy of two concepts: Ethereum Clique as simple PoA protocol which runs on top of the pre-defined list of nodes; Dash masternodes network in which every user can enter the list of signing nodes by locking a certain amount of tokens and will be excluded from the list if their node works against the network rules and does not hold uptime.
The main rule requires masternodes to be online as long as possible. When a masternode goes offline, it is removed from the list of masternodes.
The following define general components and concepts related to Sawtooth:
A batch is a protobuf object containing a list of transactions, a header, and a signature. The signature is generated by the batch signer by signing the batch header with the batch signer’s private key. For more information on the structure of a batch, see Batch Data Structure.
A transaction is a protobuf object containing a payload, header, and signature. The signature is generated by the transaction signer by signing the transaction header with the transaction signer’s private key. For more information on the structure of a transaction, see Transaction Data Structure.
The consensus is the process of building agreement among a group of mutually distrusting participants. In this case, the mutually distrusting participants are the other nodes on the validator network.
A validator is a component ultimately responsible for validating batches of transactions, combining them into blocks, maintaining consensus with the network, and coordinating communication between clients, other validators, and transaction processors. Much of the actual validation is delegated to other components, such as transaction processors and the active consensus module.
A client is a program that connects to a validator and is able to query the state of the blockchain and submit transactions.
A validator network is a peer to peer network of validators (masternodes) that are working on the same blockchain.
A network operator is one or more people who collectively manage the network. The network operator determines and coordinates the overall network characteristics such as which transaction processors are being run, the consensus mechanism, modifying on-chain settings, modifying on-chain roles etc. (applicable for private and consortium blockchains)
There are planned two types of permissions on the blockchain:
- Public blockchain in which everyone is able to become a validator and push transaction onto the blockchain. Please note, that the first version of our blockchain available for public use will be built as a consortium blockchain: everyone can send transactions but only a predefined set of users can sign blocks. This is due to the limitation of the default consensus implementation on Sawtooth (will be switched to our custom consensus).
- Private blockchain with a limited set of validators and transactors (those who can send transactions) intended for corporate use.
Masternodes are required to be online as long as possible and to not miss their turn to sign a new block. If a masternode goes offline or misses it turn to produce a correct new block, it is moved out of the global list of masternodes. A masternode is rewarded with fees from all transaction included in a block. Thus a masternode is incentivized to follow the consensus rules and to include as many transactions as possible.
To make the working process of the algorithm clear, some use cases are provided:
- Submitting a request to become masternode To become a masternode a node sends a special transaction. This transaction gives the possibility to the network to check if the candidate node holds a sufficient amount of tokens and is reachable on the provided IP address. If these conditions are satisfied - the masternode is added to the end of the global list and the amount of tokens is blocked.
- Masternode successfully produces a new block When the turn comes a masternode should produce a new block and send it to the network within the specified amount of time.
- Masternode misses its turn or pushes a new block too fast (faster than the desired time) or issues an invalid block. The node is moved out of the list and the block should be produced as in 4.
- Masternode goes offline Each node should periodically send “heartbeat” package to the network. If the node fails to send a package in time more than 3 times in a row of 6 checks it is removed from the global list.
- The node owner wishes to stop it manually In this case, the node owner sends a special transaction to the network. Once the transaction is processed the locked amount of tokens is released and the node is removed from the global list.
The detailed reference for the core architecture (the level of the framework) is available here.
A masternode consists of:
- The validator itself: this is apart responsible for collecting transactions into blocks, validating the block structure and performing the consensus algorithm.
- Transaction processors: pieces of masternodes decomposed from the validator. They are responsible for performing transactions and checking their correctness.
As of today, those are separate executables and we are using docker-compose to manage the dependencies between the components. By the time of the first releases of masternodes for the public network, we plan to provide a single executable so that an end-user would not need to manage Docker.
REMME uses two ports: one TCP and one UDP to communicate with other members of a masternodes network. You may need to modify some firewall rules to facilitate this traffic. If you intend to participate in the REMME network over the internet each validator will need a publically routable IP address because the masternode software assumes complete connectivity to the other nodes in the network, NAT is not currently supported.
The REMME client communicates with validators via TCP port 8800. Firewall rules should be adjusted to allow egress traffic on port 8800 from each machine running the REMME client software to each validator you will be working with.
THE FOLLOWING REQUIREMENTS ARE SUBJECT TO CHANGE:
Software:
- Docker Community Edition (version 17.05.0-ce or newer)
- Docker Compose (version 1.13.0 or newer)
- Operating system: Ubuntu 16.04 LTS
Hardware:
- CPU 2 virtual cores
- 1 GB RAM
- 1 GB hard drive