Storage and encryption
To optimize the volume and fast access to the necessary data, leveldb with an open license is used (a technology for storing large amount of non-relational data of the key> value format).
Hierarchically generated BIP39 keys provide access to the network participants. In the bech32 format, keys for each participant are divided into three types: main address, smart contract address and node address with various prefixes.
Participants sign messages with their key and send messages to the node to exchange data. The data is combined into blocks and sent to consensus. Hashing is done using sha256 encoding.
Several levels of data serialization have been created in the kernel for complete data verification and errors exception from the moment it arrives at the node and until it is written to the block.
The ProofOfStake modified version of consensus makes decisions depending on the number of coins a validator has and on the total number of validators.
Each node constantly accepts transactions from network participants. The data goes to the initial pool for processing, which eliminates data overflow and consensus delay. Then the node validates the transaction based on its own blockchain and makes a decision: to approve or immediately reject the transaction. The accepted transactions are immediately sent to other network validators, which are automatically loaded from the main or other nodes.
The nodes that have received the validator status take part in the consensus at the same time with the data acceptance: validators become a proposer in a predetermined order (proposer is a validator that offers data for consideration).
In addition to ordinary addresses, the system may contain smart contracts that have their own logic and RAM. Both logic and memory of contracts are also used in a decentralized manner (stored in an identical state on all nodes).
Smart contracts are divided into main groups: support system development contracts and user contracts.
Contracts are added exclusively through a centralized node and are supported and executed only in a decentralized way. The contract can accept a transaction, and then, based on its own logic, perform a number of calculations and multiple transactions. Each contract is represented by a separate application on the nodes. All results of the contracts operations are sent to consensus for confirmation by other participants after execution to exclude modification of the code or memory data.
There is a commission with any transaction calculated in the main token, which depends on the current load on the network. It is possible to increase and decrease the commission to slow down and speed up transactions. All commissions are taken by the validator that offered the block with this transaction.