Step-by-Step: How Tagion works
written by Decard - the stewardship company of the Tagion platform
All technical terms will here be written in italics. Some of them are explained at the beginning, some first appear "in inverted commas" in the text and are explained there.
If not mentioned specifically, links in the text go to the technical documentation pages of the Tagion project. There, full technical details and codes are provided but - incontrast to this introductory text - a high level of technical understanding is assumed.
There is also complementary Glossary for terms here not touched upon.
a bit of terminology up-front
User: anybody making use of Tagion software, without being a node operator
Node: instance of main Tagion software (for Tagion Mainnet and Subsystems). Several nodes can run on one computer, but in a "distributed" system they will be on different computers connected via the internet
Subsystem: a bespoke network of nodes for a particular use-case, independent of the Tagion Mainnet in terms of rules and settings. It hosts its own database and sends regular hashed/encrypted status updates to the Mainnet (for validation and notary functions, further explained below). Because of this, Subsystems are here called "federated" with the Tagion Mainnet.
Database: large file with archived information that is maintained in/by the node software ("DART" is the name of Tagion's custom-deigned database system, further explained below)
App: user-interface to make changes to the database, it sends info about changes to a node
Transaction: unit of database-changes (add, edit, delete), including but not limited to currency related transactions
... that much said, we now have enough words to begin ...
starting from a general use-case
A user (s.a.) wants to enter some new pieces of information to the system. Let's assume that this information is about a particular use-case for which a federate Subsystem (s.a.) has been set up.
The user submits the information via an app (s.a.), e.g. on their mobile phone. This information can be new (it will be added to the database - s.a.), or it can be a change to (or deletion of) existing data.
The app they use is built upon - and sometimes still called - a "wallet application", a term inherited from the Tagion Mainnet with it's principle use-cases centered around financial transactions ("JustPay" is such a wallet application, more information about it on the Decard website). The application packages the information to be entered into the database in what is (figuratively) called an "envelope". Next to the basic data-input and possibly some conditional instructions, the envelope also includes additional required information (timestamp, user identity, references to other data, required permissions), and the whole message inside the envelope is then called a "contract" (a term inherited from "blockchain" and "DLT" concepts, which will be explained below).
These contracts are sent to a node (s.a.) via the internet or local communication networks. A contract is structured/written according to our custom "HiRPC" communication format, which in turn is based on our general data format called "HiBON". We felt compelled to design those new formats to achieve the utmost efficiency in terms of storage and computing requirements for the network.
from one node to many
The receiving node checks the information sent in the enveloped contract against the information already existing in its locally stored database (e.g. if user identities and permissions are valid and other data is referenced correctly). It will then notify the other nodes in the network about this new contract and its contents - because in a "distributed" system, all nodes need to make sure that they maintain the same (copy of the) database. However, as contracts are constantly being submitted to different nodes in the network, their individual versions of the database will continuously diverge.
Thus it is important that nodes continuously communicate with each other about the contratcs they received, and even about contracts submitted to other nodes which they heard about, this propagation of information is here called "gossip about gossip". This way, all nodes will eventually know of all recent changes across the whole network - at least up to a certain point in the (not-so-distant) past. Submissions that arrived after that time, will not have been shared across the whole network.
But for everything up to that point, a network-wide agreement about a correct and complete version of the database is reached. For distributed systems, this is called "consensus", and only at that point will the nodes in the Tagino network computed the information submitted in the last epoch (described as the "execution" of the contracts). As a result, all nodes end up of the same version of their respective databases. The resulting synchronised version of all individual database is called it's "state" (as in "state of play" or "the current situation").
How consensus on the state of the network is achieved is different from one distributed network to the next. So called "blockchains" offered the first popular solution for consensus without a central authority. And when the practical limitations of blockchains became obvious and new solutions were sought, the collective term "DLTs" was introduced - which stands for "distributed ledger technologies" . The "ledger" part of that term was again inherited from the early use-cases of DLTs in currency transactions and accounting.
how nodes know what other nodes know
Common to all DLTs consensus mechanism is, that nodes constantly communicate with each other about their local versions of the distributed database. The scenario in which some nodes fail to do so (be it deliberate/maliciously, or because of lost connectivity), is described as the so called "Byzantine General Problem". Consequently, DLTs that solve that problem and can deal with a certain number of divergent nodes are called "byzantine fault tolerant".
For Decard's platform two innovative "protocols" (meaning sets of rules about the communication between different software entities) enable a fast, secure, reliable consensus (which is also most efficient in terms of required storage capacity, internet bandwidth and energy consumption). This consensus is highly byzantine fault tolerant, as it still functions with up to 1/3 of all nodes being out of sync or not playing by the rules.
The first of those two protocols, developed and patented by Decard, is called the "Wavefront" protocol and it manages the gossip-about-gossip as introduced above. It swiftly conveys how many new contracts each of the two nodes have received (directly or indirectly) since the last epoch, and then enables them to efficiently synchronise their local knowledge. This includes contracts/transactions that were submitted to the communicating nodes since the last epoch, but also the contracts/transactions submitted to other nodes which either of the communicating nodes has already heard about.
The second protocol then establishes consensus not by comparing the databases themselves (or counting the number of blocks in a chain) but by tracking the level of shared knowledge that nodes have communicated about in the wavefront protocol. This consensus protocol was originally developed and patented by Leemon Baird (co-founder of the "Hedera" project), but released under an open-source license and called the "Hashgraph consensus algorithm".
Together, the two protocols ensure that the communication between nodes relates directly to the state of their shared database. From the network-wide communication history, each node can reconstruct by and for itself, and with mathematical certainty, what other nodes in the network know. Once information about new contracts/transactions (since the last epoch) has spread to enough nodes in the network (namely to 2/3+1 of all nodes), consensus about those contracts is established and the database is updated up to that point.
how our database is smarter than blockchains
Everything before that recent epoch is then fixed in the database and no competing versions (in blockchain systems those are called "forks") can occur. That is what is called "finality" in DLTs and while traditionally blockchains rely on "probabilistic finality" (because there is always a slight chance that a fork can gain consensus), Tagion features the absolute certainty with it's "deterministic finality", which is also described as "immutability".
Again, the immuntabilty concerns the consensus about the database, not the information in the database itself. As explained at the beginning, a given contract can stipulate the change or deletion of existing data - but only if all nodes in the network agree upon the validity (permissions and credentials granted) of the contract and reach consensus about the resulting state of the amended database.
Another effect of the way Tagion achieves consensus is that the order of changes to the database is determined by the time in which most nodes have received knowledge about contract affecting that change. We call this "fair ordering", as it cannot be manipulated by individual node operators or distorted by the amount of fees offered by users (as in many popular blockchain systems).
As a last step, each node calculates a signet of the complete new version of their database. These signets are mathematical fingerprints (call "hashes") of the database. For Decard's specially designed database called "DART" (which stands for "Distributed Archive of Random Transactions"), this fingerprint is called the "bullseye" (of the DART-board). And thanks to the patented architecture of the DART database, the the calculation, sharing and storage of a bullseye requires only minimal computing resources. Comparing the bullseyes of a given epoch across the network will quickly flag up nodes that had fallen out of sync. For a Subsystem the bullseyes are of additional importance because they get submitted to the Tagoin Mainnet where they are recorded to form a continuous audit trail of the Subsystem's accurate operation.
the best of two worlds
Talking about accountability: another unique design feature of the DART database is, that all entries and edits have an "owner", typically the user specified in the contract that created the data entry. Access rights to each data point can be managed like the file permissions in a conventional computer system (e.g. read, write, own). In this regard, rules concerning privacy, anonymity and security can be determined individually for each (type of) entry, or for each Subsystem database, depending on it's particular use-case. Only for contracts/transactions of "TGN", the native utility token on the Tagion Mainnet, the rules are fixed: they always revealing the amounts of the transactions, but not the identity of the actors, e.g. payer and payee.
In a Subsystem, the actors can be made visible (only to the participants of that Subsystem or more widely), while the content kept in the Subsystem's own database can be protected as appropriate for the use-case or industry. The level of data-protection available can be configured to be compliant with any privacy and data-protection regulation or even up to government agency levels of classification - including but not limited to access-control, authentication and sharing services, and multi-signature requirements.
Each Subsystem thus benefits from having its own distributed database, shared and synchronized across a freely defined set of participants (e.g in a "permissioned" networks) while also freely determining its own rules and governance as needed. The only mandatory information shared with the Tagion Mainnet is the regularly calculated bullseye-signet.
This is why the Mainnet is said to fulfill the function of a "public notary" to it's federated Subsystems. But public here goes beyond any nation state's public institutions and power. The governance rules and protocols being developed for the Tagion Mainnet make it "decentralised", meaning no entity owns or controls the network and anybody can participate. Thus, the trust and reliability provided by the Tagion platform extends beyond the classical boundaries between public and private, or nation states and industries.
This move away from central authority to an infrastructure that is run and governed by its users and stakeholders had been one of the impulses for the development of blockchain technologies. However, the particular way in which DLTs manage data and achieve consensus has been riddled with inefficiencies from the beginning. No DLT solution has achieved scalabilty without compromising on security or decentralization. This is where Tagion as a database system that functions in a distributed manner and designed to be decentralized is such a novelty.
Built from the ground up with efficiency as its foundational design principle, it achieves the speed, safety and energy efficiencies of traditional server based databases - while staying true to the promises of DLTs and providing the cooperative data infrastructure needed for mulitstakeholder industries and use-cases.
If you are now inspired to deploy Tagion for your business, project or community but do not have the expertise to set-up a node and Subsystem for yourself, contact Decard: the stewardship entity to drive the development and adoption of Tagion.