Ntity: Allowing everyone to certify everything on every blockchain

Alec Avedisyan
(c) 2013-2022 [draft v2.6.5 / 12.12.21 VBB]
alec.avedisyan@alumni.epfl.ch

Abstract: The use and implementation of Distributed Ledger Technology DLT[1], one of the corollaries of which is blockchain, requires in-depth technical knowledge.
The primary functionality of the DLT, though, is the writing and reading of immutable information and data.
Accessibility should, therefore, be very simple.
This is why Ntity was created.

Ntity is a simple protocol for standardizing certifications/assets on DLTs. And is not intended to replace existing blockchains but rather to reinforce them.

Note: This white paper being the reference document we will not explain here the technical details, please refer to the online documentation for more details.

Introduction

Having observed and evolved in the DLT world since the beginning we have observed the emergence as well as the rapid disappearance of some DLTs.

This was sometimes due to the technology itself having flaws, or to a small community that could not maintain the network.

The most important blockchains have also had to face failures, for example Ethereum and its DAO [2].

We think that decentralization of software execution is a bad idea and we will propose here an alternative where software execution is centralized but verifiable in a decentralized way.

We have also seen during the evolution of blockchain the emergence of smart-contracts of the NFT[3] [4] type, which is a revolutionary concept but which is often mono-blockchain (EVM &Bridges) and therefore difficult to transfer from one blockchain to another (e.g. from Ethereum to Bitcoin).

Smart contracts, although tested and proven, do not guarantee long-term infallibility. Remember that the vision of the blockchain contemplates a very long term approach.

Smart contracts pose another major problem when we think of future generations who will no longer have the tools to decrypt certain smart-contracts, either because the technology will no longer be maintained or because no one will be able to decrypt or execute a certain type of smart-contracts.

Ntity proposes the equivalent of an NFT truly cross blockchain and not based on smart contracts.

It is what we call here the Ntity framework.

This document describes "THE (e)NTITY" which is the heart of all human activities and interactions.

Registering AN ENTITY on a blockchain provides independent trust guaranteeing the authenticity of this ENTITY.

Similar to the previous scenario the blockchain registration could be either self-signed or signed by a trusted third party.

For example, the case of a bank that signs data after performing due diligence or a watch manufacturer that will issue a certificate of authenticity for a manufactured watch.

Below, a pyramid that shows the cost/size of the data in front of the importance of entering it in a DLT or in a database.

Image
*In most of the case, software, so called smart-contract, is a basic decision tools which should be humanly verifiable trigger like «IF this THEN that »

At the top of the pyramid is the proof. This is the minimum information that must be written in the DLT in order to show the existence of an information.
The proof can be materialized at least by a hash of the data or include all the data. It is the actual application as well as the costs of the blockchain that will define the choice of information to be included in the evidence.

In the middle of the pyramid we have the template which is crucial for the reconstruction of the proof.
It can be in the form of a script (e.g. hash algorithm) or in the form of a json data structure. It is advisable to write the template in the blockchain, in case one day it becomes necessary to rebuild the proof or simply to test it.

At the bottom left of the pyramid we have the data that is injected into the template to create the proof. While writing into the blockchain guarantees data availability even once the certification site goes down or disappears, writing data to the blockchain is expensive and as such could be perceived as being of limited interest. The ideal is to use a database (replicated/distributed), IPFS[5] or even a cold storage type data carrier for data entry.

At bottom right of the pyramid is the software that executes the code. The software takes the data and injects it into the template. The software that are registered in blockchains are often called smart contracts. The use of smart contracts and their publication has advantages but above all disadvantages, as many of the main blockchains are costing us. The main disadvantage is that registered software is no longer editable. However, smart contracts should be simple binary decision trees (true or false) that can be interpreted by anyone with no technical training. Writing a smart contract with more than 10 lines of code is nonsense and a risk. This is the reason why registering software is expensive and potentially risky.

There may be several approaches to linking the data to the blockchain, we will list them here:

We decide to identify principal features and note them with the following weights:
0 = Bad, 1 = Average, 2 = Good

Features A B C
Transaction cost stability 2 1 0
Data size on DLT 2 1 0
Data verification 2 2 2
Data reading speed 2 1 1
Data writing speed 2 1 1
Blockchain compatibility 2 (Majority) 2 (Majority) 1 (Same familly eg. EVM)
Scalability 2 2 0
Very long term deciphering 2 2 0
Data reconstruction if DB failure 0* 2 2
Score 16 14 7

* In case of non replicated centralized database, without any backup and not use of IPFS.

The table above is not intended to be exhaustive but it allows a reflection of the important parameters for recording & reading data in the blockchain in a very long term vision.

It is important to define precisely in advance the data that will be recorded on the blockchain. There are several considerations to take into account, the number of inscriptions on the blockchain as well as the cost for this writing.

For case A), it is necessary to define not only the fields for the hash function but also the structure of the data vector. In this case, the use of the document Doc axis (described in the "data structuration" section below) is essential. It allows to create a data template, to save this template in the blockchain. Then use the data from the entities to create a new document formatted according to the template. By convention the vector structure is in JSON format, but the document template allows writing any function for document formatting.

The use Doc is like a photo of the entity at a time T, several "photos" of the entity can be written in time in the blockchain according to the evolution of the entity creating a "Cascading Blockchain Datagram".

For cases B) and C) the use of the document table Doc is not necessary even if it is recommended.

The document table Doc allows you to save the hash, and a trigger prevents any changes in the table as soon as the hash value is available. However, if the hash value is forced, the difference will immediately appear in comparison with the blockchain. The other advantage of using Doc is version management. Indeed, an entity can be created or modified over time and the documents allow this traceability.

Each entry on the blockchain is stored in the Doc table.

Choice of the DLT
Ntity does not impose any blockchain in particular. It is important to choose the blockchain according to your own needs. It is strongly recommended to use blockchains with the most important communities, this is where the blockchain makes sense.

For obvious performance and cost reasons related to the blockchain, we have also deployed our own blockchain which is a POA clone of Ethereum. Ntity can be used on its own blockchain at low cost or on Bitcoin, Ethereum, Polygon depending on the usage. Remaining open to other DLT in the future.

The use of any other sidechain or privatechain is not recommended, in this case writing to a distributed database is just as effective, not to mention 51% attacks which are easier to implement.

Proposal of a protocol

In this section we will describe the 3 principles that compose the protocol. The datagram, the operations and the CBD.

- Datagram

The datagram is a precise structure in which the data or hash of a ntity will be encapsulated. The datagram is destined to be scalable. This is the reason why there are several versions of the datagam.

- Operations

The operations give us great flexibility and a different way to process information without having to use a smart contract.

For all the operations above, only the last owner can make the operation.
If another person tries to broadcast any operation, this operation could be written but remains invalid.

- CBD: Cascading Blockchain Datagram

Datagram & Operations → CBD

The CBD stands for Cascading Blockchain Datagram. This means that all data is overwritten from the first to the last transaction following 2 simple rules:

The operations of a CBD can be linked in 2 ways, either serially or in parallel.

Templates

The template is crucial for the reconstruction of the proof. It can be in the form of a script (e.g. hash algorithm) or in the form of a json data structure.

The technical documentation concerning the creation of a template is available at https://ntity.io/docs/template.php .

But the most interesting thing is that it is possible to use any existing template or to choose one from the template catalog.

Anyone can create their own template, register it on the blockchain of their choice and submit it to the template catalog. A bit like an app store.

Example: Sport Licence

Template Blockchain : Ethereum
Template Address : https://etherscan.io/tx/0xf7a2fe03c4b9a2c0ee4a8f9a0832a1765ee8a55a213c115fcdf0853944c4bd1a

Template structure in YAML

N: Sport Licence 
V: 1
L: json
D+:
 T: e
 n: Player Name
 f: Team name
 eo: Birthdate 
 ad1: League
 ad2: Season
 v-: Licence Number

N=Name of the certificat, V=Version, L=Language, D+= Public data, T=Type Entity, etc ...

Pubished certificat of Sport Licence template

{
  "N": "Sport Licence",
  "V": 1,
  "L": "json",
  "H"; "A875876t76Ae223...",
  "E": "ETERNAL"
  "D+": {
    "T": "e",
    "n": "Michael Jordan",
    "f": "Chicago Bulls",
    "eo": "1963-02-17",
    "ad1": "Alumni",
  }
}

E=Expire, The Published document generate a Hash "A875876t76Ae223..." wich is also the IPFS link

Conclusion

Today, access to and use of the blockchain in the corporate world involves significant technical barriers. Ntity wants to be a simple interface to be able to use the best of the blockchain, i.e., the ability to write immutable and certifiable data. All other blockchain properties, such as smart-contract, are "nice to have" but not necessary for data certification.

The aim of Ntity is to allow everyone to certify everything on every blockchain.

  1. DLT stands for Distributed Ledger Technology, it includes blochains (Bitcoin, Ethereum,...), but also other types of protocols with a decentralized infrastructure and with a content system that is not based on a block chain (DAG-based, obyte) ↩︎

  2. DAO Fail https://medium.com/swlh/the-story-of-the-dao-its-history-and-consequences-71e6a8a551ee ↩︎

  3. ERC721 NFT https://eips.ethereum.org/EIPS/eip-721 ↩︎

  4. ERC1155 FT+NFT https://eips.ethereum.org/EIPS/eip-1155 ↩︎

  5. IPFS https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf ↩︎