Validator Setup Guide

Guide complet de configuration d’un validateur
Tags:

weight: 310 linkTitle: “Validator Guide”

THE KALIMA ECOSYSTEM

Consensus mechanism

Unique Delegated Proof of Stake mechanism with a vote solution – a raft variant

  • Saves computation cycles

  • Scales efficiently

  • Tailored to enterprise use case by providing a secure robust model for identity auditability and privacy

What are KLX validators?

A validator oversees transaction integrity and blockchain data immutability. Simple validation nodes do not have to be full nodes since they are not required to store ledger data.

Each validator must validate all blocks and blocks must be validated in respect with their time of arrival. The same reward is given to all validators for all block validations.

Why become a KLX validator?

  • Each validated transaction within the Kalima MainChain emits KLX tokens. These KLX are then distributed to validators, including master nodes. Each validator receives rewards based on the proportion of their stake within any given staking pool.

Can I become a KLX validator

  • Any user can aim to participate in the consensus if a reserve of KLX is held by that user to receive the associated remuneration. Only validators chosen by the network itself will become validators for the Kalima MainChain. Same reward is given to all validators for all block validations.

KLX validators

Different nodes with different purpose

There are 2 different validation nodes you can opt for:

Master Nodes

  • Master nodes are the main element in charge of validating transactions, they ensure traceability, integrity, and immutability of all transactions.

  • They participate in the consensus to elect the Leader Node in charge of timestamping and hashing of all transactions.

  • You can install as many master nodes as you need to set up a Kalima Privachain with a minimum of five of them. Master nodes store blockchain data and they publish them to the client’s node after validation.

  • Master nodes are the only ones with administration nodes authorized to access all the data contained within the blockchain, including authorization data. Master Nodes are special validation and full nodes, they implement standard Kalima consensus and when higher security is required, add a second level of validation with simple validation nodes.

Validator Nodes

  • Validation nodes oversee controlling transactions integrity and blockchain data immutability. Simple validation nodes do not have to be full nodes, they don’t have to store all the ledger. Validation Nodes elected to validate and timestamp transactions.

  • Each validator must validate all blocks and blocks with respect to their arrival time. The same reward is given to all validators for all block validations, preventing delayed or blocked transactions for economic reasons.

  • In a situation where a validator can’t validate a given block in the allotted time, the validator will receive a temporary participation penalty. His right to the candidate as a validator will be suspended for a duration of 3 months as a means of promoting the smooth functioning of the network.

Economic model

Rewards distribution

Each validated transaction within the Kalima MainChain emits 10 KLX that are distributed to validators and master nodes. These rewards are subject to the halving mechanism.

  • Rewards for Kalima validators

Validators, including master nodes will be rewarded in KLX for every transaction they validate in the network. Validation rewards will be divided by 2 after every halving, occurring every time 16 billion KLX tokens are emitted, up until the maximum limit of 480 billion KLX is reached.

  • Halving effect

At the time of the KLX launch, the reward per validated block will be of 10 KLX. The first halving will take place after the emission of 16 billion KLX tokens, whereby the reward per bloc will be divided by 2 and become 5 KLX per bloc.

Master nodes

Master Nodes will receive 50% of the emitted KLX as rewards to be evenly distributed between themselves

Master Nodes additionally receive 20% of all transaction fees, also evenly distributed between themselves

  • This is to compensate costs related to the storing of data, which normal Validator nodes don’t have to do

Validator nodes

  • Validator Nodes will receive 50% of the emitted KLX as rewards to be distributed between themselves.

HOW CAN I BECOME A KLX VALIDATOR

Requirements

Master Node

A master node is a Kalima consortium member and must hold 2% of circulating tokens at a minimum. The Kalima consortium elects a minimum of 5 master nodes.

A master node is also able to stake their own KLX.

Validator

Every holder possessing over 0,2% of KLX in circulation can create their own staking pool to candidate to become a validator.

A validator is a candidate who has accumulated at least 1% of circulating KLX tokens in their staking pool, through stakers. There will be a minimum of 50 validators.

Every candidate wanting to become a validator can stake their own KLX.

 

How to become a validator

Process

  1. Check the hardware recommendations below

  2. If the KLX reserve is met validators will be chosen by the network itself. This election ensures a sufficient level of rewards for the validators elected

  3. The first validators will be the consortium members, among the early investors who have made it possible to finance the development of the network during the pre-sale.

  4. Every elected validator will be subject to a security Bounty to make sure that they have a sufficient level of security for their infrastructure.

Hardware Recommendation

CPU : 6 cores / 12 threads, or more 2.8GHz, or faster

AVX2 instruction support (to use official release binaries, self-compile otherwise)

Support for AVX512f and/or SHA-NI instructions is helpful

GPU : not necessary at this time

RAM :16 GB, or more

Disk NVME SSD, or better

Accounts: 100GB, or larger. High TBW (Total Bytes Written) suggested

Ledger: 500GB or larger. High TBW suggested

OS: (Optional) 500GB or larger. High TBW suggested

Testing has shown better performance with the ledger on its own disk. Due to high IOPS it is not recommended to store Accounts and ledger on the same disk.

GOVERNANCE

MainChain

Rules

Client nodes connected to KLX platform will be either Privachains or exchanges.

Each Privachain has its own address or channel and will be initially limited to 99.900.

The maximum number of exchanges will be initially set to 100. Each Exchange will have a maximum number of 1.000.000 addresses.

Theses limits are fixed to protect KLX platform against deny of services attacks.

Penalties

  • In a situation where a validator can’t validate a given block in the allotted time, they will receive a temporary participation penalty. Their right to candidate as a validator will be suspended for a duration of 3 months as a mean of promoting the smooth functioning of the network.

  • In the case of purposeful harming of the network from a validator (network attack, lack of bounty conformity) the validator will see their 3 months suspension be extended depending on the severity of their action.

  • The staking model is subject to future changes based on decisions made by the Kalima consortium.

Nodes

Consensus runs on several nodes

Type of Nodes

1. Master nodes oversee validating transactions in the Kalima blockchain ensuring traceability, integrity, and immutability.

Store blockchain data and publish them to the client’s node after validation thus they are authorized to access all the data contained within the blockchain

2. Validation nodes control transaction integrity and data immutability. Elect the leader node in charge of timestamping and hashing transactions

3. Administrative Nodes authorize the client nodes

4. Voting Nodes enable validators and stakers to vote for governance management choices

5. Client Nodes synchronize data to which they are authorized from Master Nodes, create new transactions and execute smart contracts

Validation nodes on cloud platforms

Validators can run a voting and non-voting machine on a cloud computing platform or on premise. Client nodes can take advantage of small memory footprint of Kalima and its capacity to run in small devices, IoT gateways or smaller.

  • Docker

Running validator for live clusters (including mainnet-beta) inside Docker is not recommended. This is due to concerns of general Docker’s containerization overhead and resultant performance degradation unless specially configured.

  • Software

Prebuilt validators binaries are available for x86_64 CPUs

(Ubuntu 20.04 recommended).

  • Networking

Internet service for validators should be at least 300Mbit/s symmetric, commercial. 1GBit/s preferred

DISCLAIMER

The contents of this document comments and information contained herein this presentation have been prepared by Kalima (the «Company»). Anyone wishing to view these documents should first ensure that they are not subject to any local requirements by prohibiting or restricting access. Similarly, no one should access this document or apply to invest unless authorized, eligible and lawful to do so. Any unqualified investor should not see the document, should immediately return the documents to the Company, and should not read or use the information contained therein.

No public offer in any jurisdiction is made by the memorandum. The document is primarily intended for inspection by qualified investors and does not constitute an offer or solicitation of an offer in connection with shares in any jurisdiction in which such offer or solicitation is unlawful.

No public offer in any jurisdiction is made by the memorandum. The document is primarily intended for inspection by qualified investors and does not constitute an offer or solicitation of an offer in connection with shares in any jurisdiction in which such offer or solicitation is unlawful.

The document makes no representations or warranties, express or implied, on the part of the Company, their advisers or their respective directors, shareholders, partners, or employees, as to the accuracy or completeness of the information. All financial projections given are for illustrative purposes only and none of these projections or assumptions should be taken as a promise by the Company or as an indication, assurance or guarantee of the accuracy or completeness of such assumptions.

The presentation contains forward-looking statements. These statements include, but are not limited to, statements regarding the company’s prospects, developments, and business strategies. The forward-looking statements contained herein are based on current expectations and are subject to risks and uncertainties that could cause actual results to differ materially from those expressed or implied by such statements. Should one or more of these risks or uncertainties materialize, or should underlying assumptions prove incorrect, the Company’s actual results could differ materially from those expected, estimated or projected. Given these risks and uncertainties, potential investors should not rely solely on forward-looking statements. These forward-looking statements are made only as of the date of this document.

Each recipient of the document must make an independent assessment of the information provided by the Company. It is advisable to seek advice on the contents from an authorized person who specializes in investment advice. Neither the Company, nor any of their advisers, nor their respective directors, partners, representatives, agents, consultants, or employees shall be liable for any direct, indirect, or consequential damages suffered by any person who relies on any statements or omissions to the maximum extent permitted by law. The Document should not be construed as a recommendation to prospective investors by the Company or any of their respective officers to invest in the Company or its products and does not constitute a commitment by the Company to make an investment.