Cryptocurrencies and blockchain are increasing in popularity and gaining public awareness, but there’s a risk the technology will be unable to keep up with demand. We all have heard of blockchains where, in a network (like Bitcoin) all the transactions are grouped into blocks chronologically with a cryptographic proof and chained. The world currently is in a place where billions of transactions happen every second and all these cannot be integrated into a single branch of chained blocks (i.e blockchains). At a maximum, Bitcoin can handle about three to seven transactions per second. But if crypto was to go mainstream, it would need to process hundreds of thousands of transactions per second to ensure the economy could keep moving without massive delays for consumers and businesses.

Hence Transactions Chains are introduced (by Uniris), where each block contains only one transaction and these transactions are chained to form a transaction chain. Every identity (person, device, node, etc) has it’s own transaction chain independent of each other. (This potentially means that an identity will have it’s own blockchain) and there can be billions of Transactions Chains inside Uniris network.

Let us take an example of a transaction and see how it is integrated in Bitcoin vs Transaction Chain

Transaction in Bitcoin: When Alice sends Bob 10 Bitcoins

As you can see Alice's transactions is inside a block with many transactions put together in the same block.

Transaction in Uniris: Alice sends Bob 10 Uniris Coins (UCO)

Here Alice's transaction is in her own Transaction Chain and is validated instantly. Her transaction chain does not interfere with that of other identities as they have their own transactions chains. This exponentially increases the scalability.

The Transactions Chains are validated with a new form of consensus called ARCH Consensus, created by Uniris, is based on an unpredictable election of a small subset of nodes (miner) to validate and store transactions (197 per 100,000 nodes). The network uses supervised multicasting so that each node will always know where to look for data via the most efficient network path, allowing a linear increase in the number of transactions/sec as a function of the number of network nodes (~100x).

Do you want to know whats inside Transactions Chains?

When a transaction is generated in the network it will be called 'Pending Transaction' as it does not have proof of network validation.

Pending Transaction

To be processed by the network, this transaction must have the following information (Figure above):

  • @addr : An unused address that corresponds to the hash of the public key of the transaction that will succeed it in the chain.
  • type : A type defining the functional role of the pending transaction.
  • timestamp: The date and time of the transaction generation.
  • DATA : Data zone containing all the operations to be performed (operation on one of the registers, programmed tasks, smart-contracts, operations on an identity, etc.)
  • Prev-PubKey : The public key associated with the previous transaction (the address of the previous transaction being the hash of this public key)
  • PrevKey Sig : Signature from the private key associated with the mentioned public key to prove the possession of the private key, the chaining of transactions and the content of the transaction (address, type, timestamp and data area “DATA”).
  • OriginKey Sig : Signature from the private key associated with the device or software from which the pending transaction was generated. This signature is used for the proof of work of the nodes.
Each transaction also has an additional signature (Figure 1.2) corresponding to the signature of the device that generated the transaction. This signature is used inside the Proof of Work mechanism and can be integrated as a necessary condition for the validation of a transaction (for example, in the context of an electronic vote, this will ensure that a person’s biometric identity is generated only through a recognized device).


Validated Transaction is when a pending transaction is completed with the validation proofs required by the Heuristic Algorithms. These validation proofs are defined as follows:

Validated Transaction

Validation Stamp is the stamp generated by the elected coordinator node and containing

  • Proof of integrity: proving the linkage of the previous transactions
  • PoW: result of the Proof of Work
  • Ledgers Operations: contains all the ledger operations that will be taken into account by the network:
    – the ledger movements mentioned in the pending transaction DATA/Ledgers along with the issuer’s signature.
    – the list of unspent transaction outputs (UTXO) of the sender’s chain on the address of the new transaction.
    – the ledger movements to the nodes that participated in the validation and retrieval of the data (effective payment of the welcome, coordinator, cross-validation nodes and nodes from which the data were downloaded) DATA/Ledgers/Fee – the fees can be mentioned explicitly or not mentioned (if not, the costs will be calculated by the coordinator node).
  • Cryptographic signature of the Validation Stamp of the coordinating node, the public key being already mentioned in the list of beneficiaries of the fees.
  • Cross Validation Stamps To be considered as valid, the Validation Stamp must be joined by as many Cross Validation Stamps as required by the Heuristics Algorithms. Cross Validation Stamps are the signatures of the Validation Stamp by each of the cross-validation nodes (in case of inconsistency or disagreement it will contain the list of inconsistencies noted, all signed by the cross validation node).

Conclusion:

Whenever a transaction is created, it is validated by the ARCH Consensus mechanism and added to the Transaction Chain of the respective identity who sent the transaction. The overall flow of the transaction is shown below

Pending Transaction => Validated Transaction => Joined inside Transaction Chain.

Overall flow of the Transaction

EXTRA INFO----------------------------------------------------------------------------------Transactions Chains not only contain the Transactions generated by any identity but also contain Beacons Chains, Networks Chains and Oracles Chains
Beacons Chains: Since no node has the physical ability to know the status of each transaction in an unlimited network, the Uniris network uses a set of specific transaction chains called Beacons Chains which at all times provide the entire status of the network using a pure decentralized way.
Network Chains: Identical to other transactions chains but use different validation and replication algorithms. Network transactions chains are replicated on all nodes. There are also the set of algorithms, software and configuration files stored in the form of chains. This includes, but not limited to, election of validation and storage nodes, updating of node keys, Shared Secrets, Interpreters, Prediction Module, Beacon Chain management, etc.
Oracles Chains: The "World State" Oracle behaves in the same way as the Beacons Chains. For example when a new weather report is published - all information will also be aggregated at the end of the day by a last transaction on the chain. The information listed within this chain is of several kinds: climatic, financial (stock market prices, crypto-currencies prices – including the Uniris Coin), societal (number of occurrences of keywords on information sites or even when possible the last words most used on search engines). All references (URLs, etc.) are listed in a specific smart-contracts chain

Transactions Chains is a patented technology (FR3049089 (A1), US2019044735, WO2017162931) (Method of transaction validation relating to Transactions Chains through a decentralized network Transaction validation relating to one or more transactions chains in a unitary and asynchronous way by the elimination all the limitations of the Blockchain technology. The process allows enhanced security and confidentiality, in particular by integrating the constraints in terms of geolocation and number of validations of the messages.)