TIP-6 / Transaction verification

Status: Implemented

This proposal describes and discusses how transactions can be proved to have taken place in the tagion system.

Motivation

Suppose we have three persons. Alice, Bob & Carol. Carol sets an item for sale which both Alice and Bob wants to buy. First person to buy it gets it. Alice sends the transaction to Carol, but Bob only says that he has already sent the money. Since only outputs are stored there is no way for Carol to verify if it was Bob or Alice who sent it. Also as a twist Carol may choose to send the money directly after receiving them making it look like the money was never sent at all.

Based on the above it can be seen that there can be ways where providing the history is important. Especially one link back. The following describes a solution as to how we by saving hashes of contracts in the recorderchain, along with the previous recorderblock in the DART, are able to provide history as to how transactions took place in the system.

Requirements

One of the KVP's of Tagion is that the system is designed so that the nodes should perform the least amount of work as possible, and in theory only have the job of storing current distributed data that there is consensus on.

Storing only the UTXO set, rather than the full transaction history and already spent outputs, enhances efficiency by reducing the amount of data needed for transaction validation. This approach simplifies the validation process, minimizes storage requirements, and supports features that improve security and privacy, such as the creation of new addresses for change. Again it is important to remember that the nodes do not require spent UTXO's in order to validate a transaction and therefore according to the foundation of Tagion it should not be in the consensus data.

Proposed solution

Currently Tagion nodes maintains a opt-in recorder-chain, which stores all changes to the database. It has a list of inputs, as well as outputs that are going to be added and removed. The idea is to add the hash of the contracts that have been executed in the system into the recorderchain, in order to be able to lookup the transaction hash, prove that the tx has happened and the input was created at some point in time.

It is important to note that only the transaction hash is kept in the recorderchain, meaning that without the raw contract which can calculate the contract the information is not easily usable though not privacy enhancing.

As mentioned earlier, Tagion nodes are not currently required to keep the state of the recorderchain. But in order to create a hash-lock between the recorderchain and dart for faster proofs, the hash of the last ReplicatorBlock should be added to the epoch_chain in the DART. This makes proving that the recorderchain is correct much faster, since I can lookup an epoch in the DART and instantly verify if the recorderchain matches it.

History

15/12/2025: Moved sections related to hash-tries and merkle proofs to separate TIP