• 1. Introduction
      • 2. Transactions
      • 3. Timestamp Server
      • 4. Blocks
      • 5. Anchoring Timestamps
      • 6. Nimses Implementation
      • 7. Conclusion
      • 8. References
      Nimses Blockchain: System of Electronic Assets

      Abstract. An economic system that provides participants with an unconditional basic income for each minute of their lives requires both reliance on a cryptography and provision of acceptable throughput. Typical solutions relying either on trust or cryptography do not meet these requirements. This paper describes a hybrid system that does meet the requirements for such a global solution. A centralized timestamp server chains transactions in an ongoing chain by means of timestamps and announces block hashes of the chain in the generally recognized immutable ledger. The transaction model of the above-mentioned system allows operations to be processed simultaneously and independently, and throughput is limited only by the speed of reaching an internal consensus about transaction order.

      1. Introduction

      Modern centralized systems of electronic assets, which solve the double-spending problem by means of a trusted third party, basically rely on the trust of their users. As far as trust is concerned, such systems can not compete with ones which stem from cryptography and, as a rule, have a peer-to-peer structure[1]. Usually, there is a mechanism that incentivizes users to maintain the viability of the system and requires huge computational resources. As for such elements as a trusted third party and central emitter are completely eliminated. Another important disadvantage of this kind of systems is low transaction processing speed, which makes them unsuitable for global use.

      A new system reliant on cryptography, but not on trust is needed. Such a system must provide sufficient throughput for large-scale everyday use.

      This paper proposes a solution for the above problem. The solution is based on a centralized timestamp server and submission of an electronic asset as a chain of digital signatures. The server acts as a trusted third-party to solve double-spending problem, verifying the chronological order of transactions. Trust is guaranteed due to the anchoring of the operation history.

      2. Transactions

      An electronic asset is defined as a public chain of digital signatures and an account as an ordered pair (a unique identifier hereinafter referred to as an address and an asset).

      Initiating a regular transfer, the account owner creates and signs a transaction; the hash1 of the previous transaction is attached to the following one. This information is attached to the asset. A payee can verify each digital signature to ensure the correctness of the entire chain.

      1Here and below, a hash stands for the result of a one-way function.

      There is a problem when a payee can’t verify how many times the current asset has been spent by a previous owner. There are two common solutions to this problem. The first is to shift these concerns to a trusted central authority, which makes the entire monetary system dependant on itself. The second is to create a peer-to-peer network in which participants need to publicly announce transactions as well as be able to agree on the only order of the transactions. This causes a low network throughput and huge computational outlays.

      To address the above shortcomings of both approaches, we use a hybrid solution based on a centralized timestamp server that provides the correctness and chronological order of transactions. This is similar to a solution with a trusted central authority but has a mechanism of regular anchoring the entire transaction history in a public immutable ledger.

      3. Timestamp Server

      The system rules are defined as a set of generally accepted statements, established within it. For example transaction commissions, tax levies, etc.

      Having received a transaction, the server adds it to the processing queue. The processing is organized as follows: first, the server checks whether a transaction corresponds to the correctness of the current system state. If the check is positive, the server attaches the latest links of assets named “input links” and some result named “output links”, generated according to the system rules, to the transaction. The output links are connected with the input ones by means of the transaction, which then become the new input links in the following transactions. As a result, an accurate, chronological order of the procedure is guaranteed. Following the correct processing, the server attaches a timestamp to the transaction and publicly announces it. The timestamp indicates that specific data existed at that moment, and thus entered the chain.

      The problem, of course, is providing the genuine version of chain history by server relies on trust. We need a way for the user to be assured that the previous links of the assets haven’t been deleted. For this, the server regularly anchors the state of the chain into a generally recognized immutable ledger. This is how the chain is built, and the next link strengthens all the previous ones.

      4. Blocks

      To simplify the anchoring of the data history, transactions are organized into blocks, which consist of a Merkle tree from the transaction hashes and the block header. These trees are built from an ordered selection of transactions in the chain for a predefined period. A block header is defined as an ordered pair (the hash of the previous block header and Merkle tree root of the current one). Therefore, the blocks are linked in an ordered chain, wherein an attempt to change the information of any block requires to recomputation all the subsequent ones. Thus, it’s enough to anchor just the header hash instead of the entire chain of transactions.

      Usage of blockchain not only simplifies the anchoring of the data history but verifying transaction existence. To check whether a transaction is included into a block, it is not necessary a user download the entire transaction history, what is unacceptable due to its size and growth speed. A user can request a link to the block that contains the transaction and Merkle path leading to it to make sure that the corresponding transaction belongs to the block and all subsequent blocks are accepted and verified by the server.

      5. Anchoring Timestamps

      The anchoring of transaction history is established through a public announcement of some data in an immutable ledger, as in a newspaper or Usenet-post, that guarantees the unambiguous origin of the data. In 2019, it is reasonable to use public peer-to-peer decentralized systems as a ledger for anchoring, such as Bitcoin and Ethereum, as these ones have a sufficient level of reliability.

      6. Nimses Implementation

      6.0 Technical Requirements

      • Potential users volume: 3x109 users
      • Transaction latency: ~1 second
      • Transaction throughput: up to 106 TPS

      6.1 Accounts

      Only one type of asset corresponds to one account in our system, although the system itself supports many types of assets. Unique account address consists of a 20-byte numerical sequence, where the last 4 bytes indicate the type of asset.

      An account is described as follows: account type, asset type, the current balance, number of transactions in the chain of digital signatures, the set of associated public keys that verifies the account holders, emission type and other service data.

      Account state is defined as: the timestamp, transaction number in the corresponding chain of digital signatures and the final balance of the last link, which is calculated for this timestamp regarding the previous one with the consideration of emission and transaction receipt.

      Accounts are separate entities in the system, representing the current state of user assets. They are created by a special transaction that associates a unique address, initial state and a set of public keys. Then, the registered address is ready to participate in transactions.

      There are more than twenty account types in the system at the moment: common, tax, market and others.

      Address	= {16 byte} + {asset_id: 4 byte}
      Account	= (Address, Asset, Type, Emission,
          {Public Key}, State)
      State = (Time Point, Balance, Nonce, ...)
      Account Type = {

      6.2 Transactions

      A typical transaction consists of three parts: the header, body and sender witnesses.

      Transaction = (Header, Body, Witnesses)

      A transaction header is a tuple of protocol version, transaction type and time window, that shows duration while one can be recorded in the chain.

      Transaction Types = {
      Transaction Header = (Version, Type, Time Window)

      The account address and amount of either sent or received assets are defined as value reference.

      Value Reference = (Account Address, Value)

      A transaction body is an ordered pair of sets that contain value references of senders and receivers correspondingly.

      Transaction Body = (From: {Value Reference}, To: {Value Reference})

      Sender witnesses are an ordered set of every sender witness. A sender witness is an ordered pair of a sender signature and a hash of the public key that belongs to the signing pair. SHA3-256 is used as a hash function [4] (FIPS-202).

      Witnesses = ({Witness})
      Witness	= (Signature, Public Key Hash)

      A digital signature that is derived by means of signing both header and body of a transaction with any key pair from the set which is attached to sender account is a sender signature. There is ECDSA [2] (NIST.FIPS.186-4) on SECP256R1 [3] (RFC 5480) curve chosen as a digital signature algorithm.

      Signature	= ECDSA(Public Key, Transaction Header + Transaction Body, Private Key)

      Having a transaction added in a chain it supplements by input link hashes and output links. Every link is identified with a 256-bit hash. Their uniqueness is provided by the system and verified having a transaction added in the chain, as well as transaction one.

      A subset of some transactions is signed, not with the public keys of corresponding accounts, but with special service ones. For example, a tax institute is allowed to withdraw certain amounts of tax deductions from user accounts.

      These service keys are authorized in the system by means of special transaction, which is signed with one of root keys. Service keys are used to provide some necessary features of Nimses’ economic system. Tax withdrawals or penalties for violating the rules stand as examples of these features. These service keys can be used instead of user ones. Their secret parts are stored on special devices known as Hardware Security Modules in secure networks and can not be extracted from there.

      Key Types = {

      Rules of transaction validation are determined by a type of participating accounts and transaction one.

      6.3 Assets

      As mentioned before, the type of asset is determined by 4-bytes, which allows you to add new types as the system evolves.

      Currently, there are two types of assets: nim and dominim.

      6.3.1 Nim

      Nim is the basic asset of Nimses’ economic system. They act as the main tool for interacting with Nimses and between users of the system.

      Nims are emitted via an internal emission by the system, which is a function of astronomical time. At the time of registration in the system, each user automatically creates a common nim account2 subject to emission. Each common nim account is issued at one nim per minute. There is no other way to issue nims.

      In order to determine the number of emitted nims while a transaction is processed, the timestamp server additionally timestamps transaction being recorded in the chain with an astronomical timestamp and computes output links of the chain, taking nim emission into account.

      2 common nim - is an account type here

      6.3.2 Dominim

      Dominim is an asset, conceived as the main tool for capturing and holding fixed areas (refer to Nimonomy, Temples). One dominim is equal to 525960 nims (1440 * 365.25). At the time of registration, user automatically creates a dominim account as well.

      The mechanism of dominim emission works as follows. As is known from Nimonomy, Nimses has its own special accounts, which are replenished at the expense of user tax charges, after which part of these charges is distributed to accumulation accounts. There is also an accumulation account for dominim emission. The conversion of nims into dominims is implemented using a separate service and special transaction type. The service periodically checks state of the accumulation account and sends the transaction to the system, as soon as there are enough nims. The transaction counsumes required nims from accumulation account and spawns a dominim on the issue account. Thus obtained dominims form a dominim bank in Nimses.

      Also implemented a mechanism for the forced dominim emission at the user's request. A user sends a transaction, that requests a dominim, to the system. In this transaction, the dominim price, which is sent to the accumulation account, and the tax charge for the conversion, which is sent to the Nimses’ treasury, are withdrawn from the user's account. There is a special service that monitors such transactions and sends dominims to the user, after transaction succeeds.

      There is no other way to issue dominims.

      Fiat purchases of dominims are also implemented by means of a monitoring service that tracks currency payments and sends dominims to the user, after transaction succeeds. In this scenario, no dominim is emitted, so the purchase can be canceled if there are no dominims in the bank.

      6.4 Blocks

      Blocks amalgamate transactions in ordered sets and serve as tools that provide publicity, immutability and chronological order.

      A block consists of a set of transactions and a block header. A block header contains the hash of the previous block and the roots of two Merkle trees. The numbering of block heights starts from zero. The very first block, with zero height, has no previous one, so the hash from the word “nimses” is used instead of prev block hash.

      Block Header = (Version, Height, CommitAt, Gen, Prev Block Hash, Transaction Root, Receipt Root, Witness)

      Blocks in Nimses Blockchain have no size limit. Each block is responsible for a certain time interval, currently it is 10 minutes. All transactions that occurred during the interval are included into the corresponding block.

      The built block is uploaded into the shared distributed storage, and it is possible to obtain simplified proofs whether a transaction is included in the chain immediately after the block is uploaded.

      The computation of Merkle tree for transaction identifiers is similar to the algorithm described in RFC6962[5] section 2.1.2. SHA3-256[4] is used as a hash function. There is a last node duplicated on levels with an odd number of ones.

      6.4.1 Anchoring the history

      Having a block formed and written, the block hash is recorded in a third-party trusted ledger. Blocks can be also complemented with signatures of extra validators in the system, that confirm the correctness of the chain and transformations.

      Bitcoin network satisfies our requirements for publicity and immutability, and therefore it have been chosen anchoring of Nimses’ transaction history. In May of 2019, the cost of a 51% attack is over nine billion dollars. The anchoring is implemented by means of making a transaction with the OP_RETURN[6] output, which contains the hash of the block header.

      Nimses publicly announces each block header on its website and periodically anchors header hashes as described above. As soon as the anchoring transaction, which anchors the block with h, receives a secure number of confirmations in the Bitcoin network, all blocks with height ≤ h are reasonable to be considered as immutable ones.

      6.5 Horizontal scalability (Internal consensus)

      Participants of peer-to-peer networks must come to an agreement on the only version of the transaction history to prevent the double-spending problem. There are some general algorithms that are used for this approach: proof-of-work, proof-of-authority, proof-of-stake and others, which provide a uniqueness of history version. Centralized systems address above this shortcoming and can use more efficient methods that prevent double-spending.

      Since there is no need in replication of the entire history all over a huge number of participants to come to an agreement, it allows processing transactions in parallel, thus high throughput is provided.

      Timestamp server is defined as a private distributed network of separate nodes, which use a globally distributed storage of NewSQL class. This architecture provides linear scalability of both space and transaction throughput. The internal nodes reach consensus by means of Paxos algorithm.

      Current implementation takes 1 about second to process a transaction; therefore, throughput is directly proportional to the speed of reaching the internal consensus.

      7. Conclusion

      The hybrid system which has been presented meets the specified technical requirements. User trust stems from the infeasibility of changing chain history that has been anchored in a third-party ledger. The described custom model of transactions that allows parallel processing and both dynamic size and time period of a block provides throughput, that is required for a planetary system of asset exchange.

      8. References