This article is a translation of the German IOTA Beginner’s Guide by .
Without a stored transaction history up to the Genesis transaction, a hypothetical inflation bug would not be noticeable.
Of course it is noticeable. IOTA is a distributed ledger technology and thus creates a single source of truth that all participants can trust. All full-nodes on the network are synchronized and there is consensus. Each token on an address is uniquely identifiable and each output names the exact token to be moved. To do this, of course, the system must be bug-free, secure, and distributed enough so that one can “afford” to track only the relevant data (the current ledger state) and no longer need to keep the transaction history.
IOTA is a data and value transfer protocol, not a decentralized database
Nodes do not store every transaction that has ever occurred. Just like the Internet, the IOTA protocol does not store data or in other words, the Tangle is not a data storage. However, the IOTA protocol itself does not delete anything. To do so IOTA nodes can/must be configured to delete old data that is no longer needed, just as it can be done in Bitcoin (see Pruning Mode of Bitcoin Core 0.11, introduced in 2014). However, despite a deleted transaction history, it is still possible to prove that a certain message was confirmed in the tangle in the past. With the so-called “Proof of Inclusion” (Merkle Proofs), IOTA is able to prove that a transaction was directly or indirectly referenced by another transaction without having to provide the entire chain of actual transactions.
However, deleting data does not make the protocol any less secure
The reason Bitcoin, Ethereum, IOTA, and pretty much every major cryptocurrency out there uses a pruning feature in their node software is because it doesn’t affect security and the nodes don’t fall back on that old data as part of their consensus mechanism.
An IOTA node currently produces more data than a Bitcoin node, so there will most likely be more people who have this pruning mode enabled and fewer people who keep a full history of everything that has ever happened. All IOTA nodes will store the most recent transaction history of at least a few weeks or even months, which is perfectly sufficient for hypothetical bugs, because what’s the point of finding a bug years later – no one would agree to reset the Bitcoin network to a state of, say, 2017 if a bug was discovered in that time period.
What is needed is essentially a “decentralization of node implementations.”
Ideally, one achieves resilience to bugs by having multiple teams of developers implement different Node software. Then, if a node has a bug, only the nodes with the same software will fall out of sync.
This is one of the reasons why IOTA runs on “Bee” and “Hornet” nodes implemented by completely different teams in completely different programming languages. It is very unlikely that two teams will make the exact same mistake, which makes the network resilient to bugs.
Value and data transactions are handled in different ways
Value transactions
The Tangle (DAG) is the underlying technology of the IOTA communication protocol. It is the “communication medium” between the nodes. Hidden in this tangle (IOTA 2.0) on a second level is the so-called UTXO DAG (ledger), which keeps a record of the history. This payment history is kept over a much longer period of time (years) than the actual tangle.
With IOTA, no history is needed for all transactions to check if tokens have been added out of nowhere (hypothetical inflation bug). The limited balance is completely circulated and known to all synchronized nodes and before nodes can send IOTA tokens they always need to verify that the number of IOTA tokens is correct. In doing so any change to the ledger is validated by all synchronized nodes (consistency check of the ledger), therefore it is very easy to verify the total amount of limited IOTA tokens in existence. All nodes keep a list and check if the number remains consistent with each transaction. It is impossible to change the amount of IOTA tokens without changing the software (hardcoded) on all nodes, which would be a mandatory destructive update. Of course, such an update will not work without the support of the entire community and could even lead to a split in the network if there is disagreement (requires an additional coordinator to be trusted in IOTA 1.x).
“If more than 50% of the node operators decide to manually reset their nodes after a bug, then theoretically this is possible. The extent to which this actually works in practice depends on how serious the problem is. When Bitcoin created 184 billion Bitcoins out of thin air due to a bug, all miners decided to reset the network together. But that is done via “social consensus” in the real world and is not part of the protocol.” – Hans Moog, IF
Nodes that are out of sync will just get an error message and will not be able to participate in the network. When a full node comes online after being offline, the node has to listen to the network and download everything to see the status of the ledger. The node will look at the consensus and also take into account the status of the high Mana nodes. Re-commissioning a node is similar to starting a new node from scratch.
With the completion of the Chrysalis update, the new ledger state has already been implemented in preparation for IOTA 2.0 (an extended version of the UTXO model). This new ledger state is based on the principle of parallel reality. This decouples consensus from balance tracking, which allows for high flexibility and massively reduces message complexity by only voting on conflicts. Furthermore, it becomes easier to track balances. Each address will not only contain its total balance, but also several sub-balances, which are tagged to indicate which transaction created the balances. Each token on an address is therefore uniquely identifiable and each issue would name the exact token to be moved.
Data Transactions
As described earlier, the history of data-only (0-value) transactions can be lost over time. New transactions are only propagated (not validated), confirmed, and directly notarized by the network. With the help of “notarization” it is possible to prove that an electronic document existed in a certain form at a certain time and has not been modified since its creation. When a notarization is created, a unique hash (fingerprint) of a document is calculated and stored together with a timestamp in the IOTA ledger (tangle) in an unalterable way. If at a later time it is to be verified that the document in question existed at the claimed time and / or has not been altered. The data is retrieved from the Tangle and compared with the available information. Again, the transaction can be verified with “Proof of Inclusion”.
If someone wants to store the history of transactions in a decentralized manner, they can build a second-layer solution for this themselves, run a (selective) perma-node, or pay third parties for storage. For the IOTA base layer, the focus is on performance, throughput and security and not on building a global database.
Original source
https://iota-einsteiger-guide.de/transaktionshistorie.html
Last Updated on 21. June 2021