Nimera Blockchain Whitepaper

Author: Andrew Zimine

Nimera Blockchain Whitepaper

Author: Andrew Zimine

Foreword

This document contains a technical vision of one of the possible directions of blockchain technology development and the justification for why we see this particular direction as a priority. Here we detail as much as possible a system that could bring tangible improvements to blockchain technology and open doors to new uses.

This document is not meant to be a final or formal description of technical specifications. It will not discuss non-core aspects of the technology, such as APIs or programming languages used. The parameters mentioned are subject to change in the course of testing. Some mechanics may be added and others removed in the course of the development.

Introduction

Blockchain technology has been around for more than 12 years. In that time, distributed ledgers have proven successful in banking, supply chain management, medicine, energy, and more.

According to CoinMarketCap, in January 2019 there were about 4000 cryptocurrencies, most of which are using an in-house blockchain or a hark-fork of another network. Blockchain technology may revolutionize the financial industry, the Internet of Things (IoT) marketplace, and more.

Yet in 12 years of existence, no blockchain network has been able to achieve truly widespread adoption. Until now, blockchain and cryptocurrencies remain experimental technology used only by technical enthusiasts, developers, and companies as PR tools. The logical question is why?

We believe that this is due to several key problems that counteract widespread adoption, which has not yet been comprehensively solved in any network. Among these are:

• Scalability: What is the real capacity of popular networks? What resources do they require? Is the modest number of 30 transactions per second enough to use blockchain in the real world?
• Cost: Are people willing to pay hundreds of dollars for a transfer when the cost of a SWIFT or SEPA transaction is much lower, and transfers between accounts at the same bank are completely free?

And most importantly:

• Applicability: To what extent do the available technologies cover the real user needs? Are they applicable in the real world and do they fit into consumers’ normal lives, solve their pains and improve the experience of using apps and services?

We offer a vision that solves the problems listed above, especially the issue of applicability. Our solution is the first-ever blockchain integrated into an application at the architectural level.

PoW и PoS networks

There are 2 main incentive systems in the blockchain industry that maintain the network: Proof of Work (PoW) and Proof of Stake (PoS). Both have their pros and cons: PoW systems make it harder to “roll back” a transaction or conduct a 51% attack, and the more popular the network, the harder it is to affect it.

The disadvantages are that PoW systems are expensive to maintain. As a consequence, as the number of transactions increases, the network is limited by its performance threshold (number of transactions per unit of time).

Systems with “passive” mining (PoS) consume fewer resources than PoW networks but have an unbalanced reward model. In the long run, a larger stake will “drag” the generation to itself. PoS systems are also vulnerable to other problems, such as less network security, the possibility of transaction rollback, 51% attack, etc.

Proof of Time concept

Nimera Blockchain offers a universal solution — time sharing.

We do not charge transaction fees to users who participate in the support or development of the network.

Nimera Blockchain’s core principle is a “network charge”. It is a conditional-emission model in which 100% of the network charge (all the capacity that the network is physically capable of) is generated every 24 hours (full network charge cycle).

By the end of the conditional 24 hours this charge “resets” and everyone who has previously “spent” or used it has a similar reserve of “power”. This is a fundamentally new approach to decentralized system functionalities. The proposed approach stimulates users to maintain a balance that is exactly the number of tokens each user needs for his personal needs.

Besides, the principle of building Nimera Blockchain is based on “anarchy”. As developers we put almost no restrictions on the basic version of the network, allowing the community itself to vote for the best practices (except for the mathematics of the network). The whole network will evolve based on the decisions that were made by the community and approved by a quorum.

Applicable Blockchain

At this moment, no project has yet developed a blockchain technology or ecosystem suitable for widespread adoption. There are projects on the market with well-developed tokenomics and the potential for scalability. Some projects have emphasized usability — they offer useful APIs and SDKs.

However, most of these projects are at an early stage of development and have no practical use in the current stage of implementation.

At Nimera, we approached the development of our blockchain platform from a different angle. When we worked with the first version of the blockchain — EON — we developed and tested features that were useful to us as the primary user of the blockchain. We designed the network so that it would reduce usage costs, not interfere with the growth of either the company or the user base, and be flexible in further building new services.

From the beginning, we have been developing an applicable blockchain. Our technology is already a practical tool. EON blockchain was an alpha testing phase, and as a result of almost 5 years of work we have created a network that can be called not just publicly oriented, but applicable as well.

What does applicable blockchain mean? It means that the motivation of participants is based on the principles of equality and fairness — if a user is a part of the network he uses all its services for free.

The opportunities to use the network are multiples of each user’s participation in the project — from an advanced network node holder with a deep dive into the code base and architecture, to an ordinary user who needs to use the capabilities of the Nimera Blockchain-based ecosystem.

We show by our example what services and utilities can be deployed with the Nimera Blockchain: Multibroker, Multi-Acquiring, Channels Mobile Wallet, and other, already implemented systems that are waiting to be brought to market. Our main focus is on Nimera Blockchain consumers that generate transactions on the network, providing convenient services for end-users.

User advantages

All users are united by one physical quantity — time, which is a constant for everyone. When designing the Nimera Blockchain, we were guided by this parameter — each user, investing his time, receives the same amount of time back in the form of free service usage.

Any NION holder gets a fraction of the entire network’s bandwidth, which refreshes every 24 hours and automatically regenerates the charge. You don’t have to take any action — you just need to be a member of the network.

What does participation in the network get you? First of all, the genesis of Nimera — EON — was designed as a financially oriented blockchain, which solves the issues of secure and fast transfers of value over distance. It is not about sending coins but rather the secure transfer of absolutely any financial unit: from Bitcoin to USD, from Ether to EUR. When we talk about fiat currencies, we are not talking about stablecoins, but full-fledged fiat.

Moreover, the transfer of value within the Nimera ecosystem automatically includes all the properties of the blockchain itself: a single address to accept absolutely any currency, the same terms of value, speed of transaction, and commission of the internal network (free for NION users).

Benefits for developers and third-party networks

Third-party blockchains (even the most popular ones) can hedge their risks against increasing loads on the parent network without the risk of getting caught with a low fee in line or falling victim to a dramatic change in transaction costs.

Among other things, we allow the community to self-regulate and choose which scenarios have best practices by voting within the system. As architects of the network, we only lay down the mathematical integrity of the system — i.e., the foundation. The rest is configured by the community.

Enthusiasts who like to work with new technologies and have enough technical knowledge have a great chance to join the already running platform with an established consumer base: Multibroker, Multi-Acquiring, Channels Mobile Wallet, and in the future, they can become “network charge” providers for future projects.

But that’s not all. For developers and companies, we offer a tool for financial scenario development based on smart contracts, which are more convenient, simpler, and maintain the unity of business requirements at all stages of use.

This system does not require the retraining of specialists because the logic of implementation and connection of smart contracts is maximally simplified. Besides, in the second stage of Nimera Blockchain implementation, we will combine chat and blockchain, which opens huge opportunities for using blockchain in the social sphere both for users and developers.

Nimera Blockchain is a multicore network with vertical and horizontal scaling. At the core are several components responsible for the basic functions of the network.

Below are the features of Nimera Blockchain and the technical details we relied on during development.

Network architecture

Core: stores the data of accounts registered in the Nimera ecosystem and facilitates the transfer of value between different accounts and blockchains.

Payment network: is a separate blockchain with support for smart contracts. It is responsible for executing financial transactions. The payment network communicates with the core, retrieving from it data about the values used in transactions as well as the accounts involved. This design allows the payment network to achieve horizontal scalability.

Smart Bots: are used in chat rooms and can download contracts from the payment network, using them to make decisions. Smart bots have access to the transaction history and account database and can use this data to make decisions.

Chat server: allows users to communicate with each other and interact with smart bots.

In terms of architecture, Nimera Blockchain has two independent interaction entities — chat and blockchain, and two independent interaction objects — user and bot.

Technically, they work independently of each other, although users and bots can interact via chat and blockchain.

The architecture of the blockchain can be represented as follows:

This is a public network (core) for value transfer and several blockchains of smart contracts as a means of horizontally scaling the capacity of the network.

Each individual network can be represented as follows:

Generator: a full-fledged node that participates in block generation.

Potential generator: a full-fledged node, which may become a generator, but for now acts as an observer.

Observers: simplified peers that monitor the execution of operations in the network.

Commands and Transactions

Transactions in Nimera Blockchain are divided into 2 components: a command and a transaction.

Command: describes action on the network performed by the user, for example, transferring funds or registering a new account.

A transaction: it acts as a container for several commands and the sender is charged for the execution of commands.

The sender of the command and the sender of the transaction can be two different people.

This separation opens up a wide range of possibilities for users who have no base coins and cannot pay a transaction fee to use the network. They can negotiate with another person who will release their command to the network, paying a commission from their account.

Structure of a command and a transaction

Structurally, a transaction is divided into 2 elements: a command and a transaction.

A command is a specific operation in the network. It is specified by the type of operation and a set of fields necessary for the operation, for example, registration, transfer, etc.

A transaction is a container for several commands that is sent to the network. The transaction sets the commission and its payer.

Command structure

- version* : int — format version.

- id* : String — command identifier (calculated from command hash (according to EDS principles) and command creation time. The hashing algorithm is determined by the version).

- type* : String — a type of operation.

- publisher* : String — sender to the network.

- timestamp* : long — time of command creation.

- deadline* : long — timestamp of the command.

- data* : Map<String, Long|String|Map<…>> — command data.

- note : String — comment.

- confirmations*: Map<String, String> — captions (account ID — Base64 EDS).

- reference : String — dependence on another command in the transaction.

* — mandatory fields.

Transaction structure

- version* : int — format version.

- id* : String — transaction identifier (calculated by the transaction hash (according to the principles of EDS) and the time of transaction creation. The hashing algorithm is determined by the version).

- commands* : List<Command> — commands in the transaction.

- publisher* : AccId — commission payer.

- fee* : long — commission.

- confirmations*: Map<String, String> — signatures (account ID — Base64 EDS).

- timestamp* : long — time of transaction creation.

- deadline* : long — transaction lifetime.

- tags : Map<String, String> — tags.

- block : String — identifier of the block in which the transaction was confirmed (used only when querying the transaction from the peer).

* — mandatory fields.

Basic rules of transaction functioning

The transaction is signed by the sender, specified in the publisher field.

The transaction is executed automatically. An error in processing any command in the transaction will cause the entire transaction to fail. No command will be accepted.

All commands in a transaction are executed consecutively.

The command includes a publisher field so that only the correct account can release the transaction to the network.

The command has a reference field that allows you to control the relationship between commands. If the field is specified, the command must be included in the current transaction and placed before the current command in the transaction command list.

Network commission

Unlike most existing networks where the cost of transaction increases with the load on the network, in Nimera Blockchain the load is regulated by the ownership of the network, using a system of charges.

The larger the account balance, the more of the network the account “owns,” therefore the more load it can give to the network. At the same time, the balance itself is not spent on transactions and no commission is deducted for individual transactions.

Capacity

Capacity is the maximum value of the charge which corresponds to the balance. The network capacity corresponds to the volume of coins in the network and is determined by the formula 240*1⁰¹² (taking into account the 6 decimal places).

Charge

Depending on the account balance, the charge allows you to make a certain number of operations per day (150 NION on the account is 10 operations). The spent charge restores gradually over 24 hours. Thus the rate of charge recovery is directly proportional to the current balance.

The charge restores according to the formula:

C_new = min(B, C_old + B*dT/86400)

• Where: C_new — the new charge,
• C_old — old charge,
• B — balance,
• dT — time elapsed since the last update of the charge (in seconds),
• 86400 — number of seconds in a day.

The minimum between the calculated value and the balance is taken — thus ensuring the burning of the charge above the balance.

A key aspect of the mechanics is the ability to transfer the charge between accounts. The charge is transferred as a coin transfer transaction with the essence of the transaction being the charge itself, not the tokens.

When a charge is sent it is deducted from the sender and credited to the recipient. If the charge received exceeds the recipient’s maximum capacity, the excess is burned off. Thus the user can never have more charge than capacity, as the excess will always be burned off.

The charge can also take on a negative value. In this case, the user “borrows” the charge from the network. This feature allows you to continue to use the network even if all of the base charge have been used. The amount of charge available for borrowing is limited by the current balance.

Negative charge

Since the charge can go into a negative balance, users can continue to participate in the network when their own charge is low. This is useful immediately after creating a new account, smoothing out charge consumption due to daily load irregularities, or continuing to operate the service immediately after recharging if the charge runs out.

An example of loan mechanics:

To guarantee the return of the blocked charge, the required amount is blocked on the account. Unblocking occurs gradually as the charge is restored over a day.

For example, a new user has received 100 NION. He wants to instantly send 90 NION and needs to pay the equivalent of 10 NION per charge.

After the transaction, the user’s charge is -10 and the balance is 10 NION. It will take a maximum of two days to restore the charge. Until this time has passed, the user cannot send transactions with a commission of 10 units of charge. He will, however, be able to send transactions with a commission of 5 units within 12 hours due to the gradual recovery of the charge.

After 2 days, the user will have a charge of 10 and a balance of 10. He will be able to send 10 NION transactions with a commission of 10. Then he will be left with an account with zero balance and zero charge.

An example of loan restructuring mechanics:

Let’s say the user has 20 NION in his account and has already withdrawn his charge to -20.

In that case, the network locks 20 NION in the account to repay the debt through gradual charge recovery. The debt will be completely repaid after 24 hours. But after 12 hours 10 units of charge will be restored and the network will block only 10 NION on the account.

The minimum fee per byte of the transaction depends on the current load on the network. The higher the load, the higher the fee.

Adaptive Commission Calculation

The transaction fee per byte will be directly proportional to the load on the network. At maximum load, the commission will also be at maximum. At the minimum load, it will be the lowest. At fifty percent load, the commission will be fifty percent of the maximum.

Load measurement mechanics

The load will be measured by two mechanisms:

• The maximum load is estimated as processing a full block (of 1 000 000 bytes) every 10 seconds.
• Using the block occupancy in tendermint and maximum block size specified in tendermint consensus parameters. For averaging, we will take the average of the blocks for the last 5 minutes.

Commission measurement mechanics

The concept of charge and capacity is used to collect a commission. To estimate the maximum commission, it is assumed that the entire network charge must be spent at the recovery rate. The maximum recovery rate depends on the total balance of the network. That is the total coin issue.

Knowing the maximum recovery rate and maximum capacity, we can calculate the maximum commission per byte of a transaction.

Assumptions made:

• Maximum load — a block of 1MB in 10 seconds.
• The evaluation window of the current load is 5 minutes.
• The current load is measured by the tendermint block parameters.
• All network charge must be spent at the recovery rate at maximum load.

Numbers

• 240,000,000 — coin emission.
• 1,000,000 bytes maximum in a block.
• 10 seconds to generate a block.
• 500 bytes — average transaction length.

Example 1: load — peak

• Maximum charge recovery per second: 240,000,000 /24/60/60 = 2,777 ~ 3,000 NION/sec
• Maximum load per second: 1 000 000 / 10 = 100 000 bytes / sec
• Maximum fee per byte: 3,000/100,000 = 0.03 NION/ byte.
• If 1 transaction takes 500 bytes, it is 15 NION.
• That is, at peak load, you should have 15 NION to send 1 transaction per day.

In this example, you need to have 15 NION on your balance to do 1 transaction per day.

Example 2: load — 1tr/sec.

Maximum fee per byte: 0.03 NION/byte.

Actual load: 500 bytes/sec.

Load coefficient: 500/100000 = 0.005

Actual commission per byte: 0.03*0.005 = 0.00015 NION per byte

Transaction fee: 0.00015*500 = 0.075 ~ 0.1 NION to send 1 tr per day

In this example, you would need to have 0.1 NION on balance to make 1 transaction per day.

Example 3: load — 10t/sec.

Maximum commission per byte: 0.03 NION/byte.

Actual load: 5000 bytes/sec.

Load coefficient: 5000/100000 = 0.05

Real commission per byte: 0.03*0.05 = 0.0015 NION per byte

Transaction fee: 0.0015*500 = 0.75 ~ 1 NION to send 1 tr per day.

In this example, to make 1 transaction per day you need to have 1 NION on your balance.

“Anarchy and Consent” Management System

The scheme is called anarchic because the core only prescribes the control parameters by which the core acts. At the same time, the mathematics of core management is not prescribed. At the same time, the consent is achieved by the fact that the consent of the majority of the multi-signature holders is required for any action to be taken on the network.

The control scheme described here will only be used at network launch. Subsequently, the approved and tested control rules will be transferred to the kernel once they have been tested and will be automated in the core.

Automation will be applicable when the following criteria are met:

1. The practices being automated are proven and will not change for the foreseeable future.
2. Automation of these practices is possible and does not conflict with the already established principles and practices.
3. The community agrees with the automation that is proposed for established practices.
4. The community agrees with how the automation will be conducted.

The concept of quorum

Some transactions in Nimera Blockchain will have the ability to set the core operation parameters. Since the state of the core is formed from the aggregate of the account’s states, there will be a control account with the ability to set the parameters of the core operation.

The controlling account, in turn, will be influenced by multiple accounts using multi-signature in quorum mode. Access to the multi-signature will be granted to community members or the managing fund.

Parameters that can be influenced by a managing account

The managing account will be able to influence several Nimera Blockchain core parameters:

1. Nodes, especially those involved in blockchain generation, i.e. tendermint validators.

The separation of generating peers and multi signatures of the managing account will come under control. This will separate the functions of block generators and network management and increase the reliability of the network. It is similar to the concept of the executive and legislative power division.

To support a particular validator, any account just needs to specify which account it supports in a special account data field. At the right moments in time, the state tree will be analyzed and statistics will be collected to determine which accounts support other accounts. These statistics will be used to select validators.

1. Management of the list of accounts with non-standard charge recovery rate, such as validator tendermint accounts.
2. Management of the composition of the multi-signature manager account.
3. Management of NION (technical / base) currency emission, the emitted coins of which go to the balance of the base account and are burned only from the balance of the base account.
4. Management of the trading coin, which is a colored coin of the base account and has all the parameters of colored coins: dynamic or automatic emission.

Smart Contracts

Nimera Blockchain uses WebAssembly contracts (WASM contracts), a technology that is now gaining popularity in decentralized networks. It is convenient primarily because WASM allows multiple languages to be used to write a contract, rather than one fixed language (like Solidity in Ethereum, for example). Thus, developers with different knowledge backgrounds can participate in the development of the network equally.

It is also worth noting the asynchronous execution of contracts. Until now, most virtual machines required the sequential execution of transactions, which significantly reduces speed. We plan to introduce parallel execution of contracts which will greatly improve node performance and scalability.