What makes the Universa Blockchain so secure? HashID

In this article we’ll dive a little bit further into the security of the Universa Blockchain. What makes it safe to use? How is the data in the blockchain protected?

In the previous articles we compared the speed and the cost of the Universa Blockchain Protocol to Bitcoin and Ethereum. In case you missed it, read more about it here.

Universa Today is maintained by the help of the community. If you would like to participate, feel free to contact @starnold on Telegram. As you can see the articles are translated in various languages, but many hands make light work.

Security of the Universa Blockchain

First of all, you have to understand one of the key aspects of a blockchain: immutability and trust without the need for trusted third parties. But how can a protocol have such characteristics without someone who’s auditing a process or payment? In the world of blockchains, the auditing is done by a network of nodes.

The nodes of the network reach the consensus of a blockchain protocol. They register data which needs to be(come) immutable. The easiest example is money: you want your digital money to be yours. It should not be possible that outsiders can claim your money. This is possible by two aspects:

  • Network which holds the distributed ledger (with each node holding a copy of the distributed ledger);
  • Cryptography.

The nodes check the data of all the peers in the network. Each node holds/checks its own data and when a consensus question has to be decided, each node votes.

In case of money, the nodes validate and audit the balance sheet of all the participants of the network. This balance sheet in the Universa Blockchain is just a number (amount) in the smart contract. Because the network is a distributed and decentralized system, the nodes reach a consensus (90+%) about the data. This prevents single entities to cheat.

The Universa Blockchain Protocol has several interesting aspects which guarantees a secure network. Sensitive business data is not stored flippantly and unwittingly in unknown reaches of the globe. It is encrypted and regulated by organizational security practices. This makes it possible for enterprises to trust a blockchain with sensitive or private business processes. This is where the second aspect of security comes in: cryptography.


Cryptography is the key to this success. There are several ways to encrypt your data. The Bitcoin network, for example, uses the SHA-256 hash function and the encryption algorithm in Ethereum is Keccak. Both of them belong to a somewhat-different hashing family. SHA-256 is one from the SHA-2 family and Keccak from SHA3.

Interestingly though, the Ethereum implementation is basically a SHA3 algorithm. But as it appeared just some little time before the SHA3 was officially accepted, it differs from it (in some minor constants).

The Keccak algorithm in Ethereum is basically the same as SHA3 standard, though it is not binary compatible. What may cause serious problems, when using hardware implementations or other standard-conforming solutions for example.

For now, they’re more-or-less safe to use, though you can find a number of attacks and problems already.

A hash function changes some input into a digest. It’s a one-way function which is practically infeasible to invert. You may understand that the ‘hashed’ piece of information can be transferred across the internet in a very safe manner.

If we take the word ‘universa’ and we hash it with the SHA-256 function, the result is a string like this:


But if we change the input a little bit to ‘un1versa’, the output (or the hash) will be completely different. It’s not possible to derive the input by comparing these two outputs. The new hash will be:


You could try and test it yourself on several websites. As you can see, both hashes look completely different, while the input is almost the same, also known as the so-called ‘avalanche effect’. A tiny change in the input causes a major change in the output

But ..  If there is a weak spot in the algorithm in the future, the data cannot be guaranteed to be stored securely. Universa solves this potential vulnerability with the so-called HashID

Bitcoin, Ethereum and Universa

Bitcoin and Ethereum are both using one single hash each from other family. The Universa Blockchain uses three different cryptographic hash functions from three different algorithm families and basically combines their results into a complex hash function, taking all the best qualities from three independent algorithms.

The used hash functions are:

  • SHA-512/256
  • SHA3-256 (256 bits)
  • Streebog (256 bits)

All of them are standardized across the whole world. SHA-512, for example, is standardised by the USA Federal Government in 2002. The Japanese government and European Union both accept this cryptographic technique as well. Besides that, Streebog is standardized by the Russian Federation in 2012.

It is one of so called “GOST” algorithms. GOST means GOsudarstvenniy STandard, “State Standard”. There are no more ‘standardized’ standards in Russia than GOSTs; and the GOST standards cover everything, from technologies/industries and up to food production and handling.

So to make it clear:

  • Universa Blockchain uses three different hash functions;
  • These belong to completely different algorithm families;
  • They are developed by three significantly different cryptographer teams and utilizing rather different cryptographic concepts and primitives;
  • If one of the hash functions face vulnerabilities in the future, the data won’t be(come) open into public.

HashID in practice

As you might remember from the previous articles, the Universa Blockchain Protocol is based on the verification of the state of a contract. It does not execute the ‘decentralized apps’.

You could read the state of a contract as a long code. Do you remember the hash from ‘universa’ and ‘un1versa’? Such strings can easily be verified by the nodes of a blockchain. But if you try to change some information from the input (if you want to claim the ownership of a contract, for example), the ID of the contract will change enormously. The nodes won’t recognize it as ‘APPROVED’. You can read more about this on the Knowledge Base site.

So let’s put this hashing method with HashID into practice to see what happens. Let’s take the original smart contract from the UTN token as an example.

If you check the smart contract in the universaexplorer you can see the ID of the root contract:


This is a string of 128 symbols. But before we move from a smart contract to this small piece of text, a lot happened ‘behind the scenes’. This string represents a lot of information. It represents the state of a smart contract. But this string reflects the whole contents of a smart contract (or its revision). The only thing that the nodes have to do, is to verify if this state is valid (hence ‘APPROVED’). If that’s not the case, they could communicate this contract as DECLINED, REVOKED or UNDEFINED.

The only thing a node stores is the relation like:

“the contract with the state NPo4dIkNdgYfGiNrdExoX003+lFT/d45OA6GifmcRoTzxSRSm5c5jDHBSTaAS+QleuN7ttX1rTvSQbHIIqkcK/zWjx/fCpP9ziwsgXbyyCtUhLqP9G4YZ+zEY/yL/GVE is now VALID”

So let’s go back to the UTN smart contract with the ID of 128 symbols.

Smart contracts

Whenever a first (or a new) revision of smart contract is being registered in Universa network, each node receives the body of this contract (or its revision). After checking the contract bodies with a lot of various validation checks, if the node decides that the smart contract is valid and should be registered, it starts processing the body of this contract using the HashID algorithm. Each of the three different hash function in HashID scans over the whole contract and generates a 256 bits (32 bytes) string. So if you do this three times with three different hash functions, you’ll get a 3⋅256 = 768 bits (96 bytes) outcome. This output is encoded with Base64, which contains A-Z, a-z, 0-9, the + and the / character.

The property of Base64 encoding is that each 3 bytes of any binary data are encoded as 4 symbols of Base64 representation. Therefore, each HashID is usually displayed as 96⋅4/3 = 128 symbols. And that’s the number where we started: the HashID of a smart contract is a string of 128 symbols. And even just a single bit or letter altered (occasionally or intentionally) in the smart contract, causes significant changes in the outcome of each of the three components. Each of three component will change in a different way, using different algorithms; which leads to an incredibly unpredictable change in the HashID result – the quality so desired from good cryptographic hashes.

HashID in Universa

The HashID includes all the information about (‘revisioned’) smart contract. But now it’s stored in compact and non-reversible way. Each node stores the knowledge that “the contract with some specific APPROVED HashID”.

So at some point, some user may decide to use this smart contract (e.g. make a new revision). To do that, the user uploads the original smart contract body to the network. The HashID of this smart contract will be recalculated once again. As long as the information in the smart contract is valid and unchanged, the HashID calculation will result in the same value as the one stored as ‘APPROVED’ by the nodes of the network. So the nodes will consider it approved, and let the customer use it. This gives the data a huge level of security, while storing only a tiny amount of data rather than the whole contract body.


We started this article with immutability and trust without the need of third parties. How can this be achieved?

The Universa Blockchain Protocol uses a three-algorithm hashing to securely and privately store the input of a transaction (the smart contract) in the blockchain. If the string of 128 symbols is valid, the nodes will process the payment/transaction/revision. Because the HashID consists of hashing functions from three completely algorithm families, this gives the data extra security in case some vulnerabilities will be found in the future in any of them. Moreover, as these algorithms are standardized in different countries, it makes it possible for Universa to be standard-compliant in all of them.

The string of 128 symbols is verified by all the nodes of the blockchain. If they recognize it as valid (and all the other changes as legal), the transaction will be added to the DAG. Now the contract is stored immutably, securely, privately on a trusted way without the need of a single trusted third party.

Help translating this post to Anglais Allemand Néerlandais Italien Espagnol Croate Russe. Contact @starnold to participate!

Related posts

The Digital Migration: Why Universa is the Rail Blazer


What makes the Universa Blockchain so cheap?


Alexander meets Amsterdam 2020


Leave a Comment