Node Registration

Description

Although anyone can run a node and connect to the network, we restrict the creation of blocks and the distribution of coinbase rewards to a subset of registered nodes. The process of how new nodes can become registered, and how nodes are ejected from the registry, is managed entirely by the network protocol. This means that no single user or account has the authority to promote a node or change its status; nodes only change status by the automatic application of the protocol rules.

Process

• Each Node is uniquely identified by a key pair (private/public key), auto generated upon node installation. The private key is securely stored within the node, while the public key can be distributed across the network to other applications (eg. wallets) and to other nodes.
• Each user (account) that wishes to actively participate to the blockchain processes, be able to generate/validate blocks and get rewarded for doing so, must register the public key of the node he controls on the network via a “node registration” transaction. The number of nodes which can be registered is limited. When registering a node, to avoid spam, a minimum amount of user's funds must be locked (see LockedBalance in "Node Registration transaction type"). Node registrations are stored in the node registry (versioned/managed) table.
• Node registration is a lengthy process: nodes are first put in a queue and once a day the chosen ones (the ones with highest locked balance) are accepted to the node registry. The total number of nodes that can be accepted, per round, is also limited.
• In the event that the node registry list is full, during the node registration's daily round, a new registration with higher locked balance will expel the lowest from the node registry.
• Scarce participation to the nodes' peer to peer network or bad behaviours, such as attempts to hack the blockchain by submitting altered blocks or transactions will reduce the node's participation score or blacklist the node for a certain amount of time (which also leads to reducing the score) and eventually cause the node to be expelled from node registry (see "Proof of Participation").
• When a node is expelled of voluntarily unregistered, the locked balance is automatically returned to the node's owner account.

These mechanisms have three primary objectives:

• Discouraging bad behaviours: since it takes a big effort to be accepted, a user would think twice before trying to submit wrong data and thus been kicked out of the network.
• Encouraging good behaviours and implicitly creating a highly reliable and performing network: since active and honest nodes have better chances to be kept in the node registry than poorly connected and dishonest nodes, a user would most likely deploy his/her node to a reliable Server with a good network connectivity and double check that the software he/she is running is the 'official' version and not an altered one.
• Promoting competition between users: once node registry is full, only the highest locked balances can be admitted.

Database structure details and Transactions

Node Registration Table

Registered Nodes are stored in node_registry table having the following structure:

No	field	type
1	id	integer
2	node_public_key	bytes
3	account_address	bytes
4	registration_height	integer
5	locked_balance	integer
6	registration_status	integer
7	latest	integer
8	height	integer

Node Registration transaction type (for new nodes)

A node is registered by submitting a transaction of type 'node registration' (Type 2,0) with the following transaction body structure:

No	field	type
1	NodePublicKey	bytes
2	AccountAddress	bytes
3	LockedBalance	int64
4	Poown	ProofOfOwnership

• Transaction validation:
  • Transaction sender must be the owner of the node being registered: by submitting a valid proof of ownership, the sender can prove to the network to be the rightful node's owner
  • The public key being registered must not be already in node_registry, unless it belongs to a deleted node (a node with RegisterationStatus = 2 - NodeDeleted)
  • The Registering account (transaction's sender) must not be actively owning another node: one account is allowed to control exactly one node at the time
• Transaction application:
  • A new entry is added to node_registry table with all data parsed from the 'node registration' transaction body and 'RegistrationStatus' set to 1 (= NodeQueued)
  • account balance is deduced by the amount set in 'node registration' transaction's locked_balance

Update Node Registration transaction type

An already registered node is updated by submitting a transaction of type 'update node registration' (type 2,1), with the following transaction body structure:

No	field	type
1	NodePublicKey	bytes
2	LockedBalance	int64
3	Poown	ProofOfOwnership

• Transaction validation:
  • All above fields are mandatory for the transaction to be valid, even the ones that are not gonna change
  • Transaction sender must be the owner of the node being updated: by submitting a valid proof of ownership*, the sender can prove to the network to be the rightful node's owner
  • If updating node public key: the public key being updated must not be already in node_registry
  • If updating the locked balance: new locked balance must be higher than old one
• Transaction application:
  • A new entry is added to node_registry table copying the old data and updating the ones sent in the transaction body
  • If updating the locked balance: account balance is deduced by delta amount between new and old locked balance

Remove Node Registration transaction type

An already registered node (either in status 1 - NodeQueued or 0 - NodeRegistered) is unregistered by submitting a transaction of type 'remove node registration' (type 2,2), with the following transaction body structure:

No	field	type
1	NodePublicKey	bytes

• Transaction validation:
  • Transaction sender must be the owner of the node being unregistered: since the relationship between node owner (account address) and node (node public key) is stored in node_registry table, all network can verify that this transaction comes from the node's rightful owner, by verifying the tx signature
• Transaction application:
  • The node_registry entry is updated by setting RegistrationStatus = 2 (NodeDeleted)
  • LockedBalance is refund to the transaction's sender account address (= node's owner)

Claim Node Registration transaction type

An already registered node can be claimed by a user by submitting a transaction of type 'claim node registration' (type 2,3). When the transaction is confirmed, the node will be deleted and its locked funds transferred to the transaction's sender account. This transaction has the following body structure:

No	field	type
1	NodePublicKey	bytes
3	Poown	ProofOfOwnership

• Transaction validation:
  • By submitting a valid proof of ownership, the sender can prove to the network to be the rightful node's owner
  • The claimed node must be already registered: NodePublicKey must be already in node_registry
• Transaction application: - The node_registry entry is updated by setting RegistrationStatus = 2 (NodeDeleted) - LockedBalance is refund to the transaction's sender account address the transaction body

Proof of ownership

Proof of ownership is a message, signed by the node, that can be used by a client/wallet app to prove node ownership. It can be used as a way to authenticate a user to its node and perform administrative tasks, such as requesting a change of the node private/public key or as a way to perform transactions that require the sender to be recognised as the rightful owner of that node. This message is generated by the node and returned to the client by consuming the following off-chain api call. /nodeadmin/getProofOfOwnership:

• the request’s payload must contain the account address and a message signature signed by the account (the message to be signed is the account address itself)
• if node recognises the signature belonging to its owner, it generates a new ProofOfOwnership (of type model.ProofOfOwnership) and returns it to the client

Proof of Ownership (poown) message structure:

No	field	type
1	AccountAddress	byets
2	BlockHash	bytes
3	BlockHeight	uint32

The poown is signed by the node (with the node private key) and the signature is sent to the client together with the above message as a proof that he's the rightful owner of the node.

Once the client has a valid proof of onwership it can perform transactions such as:

• registering a new node on the network
• updating node registration data, such as locked funds, node address or node public key
• claiming a node ownership, in case for instance a user has lost access to his account and needs to change its node ownership to a new account
• removing a registered node from the network and claiming back the locked funds