In our previous discussions, we explored the fundamentals of the IOTA Tangle, including Directed Acyclic Graphs (DAGs), random walks, and various tip selection mechanisms. Now, we delve into the financial aspects of the system, specifically clarifying what it means for "Transaction A to approve Transaction B."
The Concept of Transaction Approval
As mentioned in the first article of this series, each transaction contains information such as "Alice sends Bob 10 IOTAs." The primary role of a transaction approver is to verify whether Alice indeed possesses 10 IOTAs to transfer to Bob.
Some might wonder where these IOTAs originate. Unlike well-known cryptocurrencies like Ethereum or Bitcoin, IOTA does not rely on mining. Instead, all IOTAs were created during the genesis transaction, meaning no new IOTAs are generated thereafter. The total supply remains constant. Initially, IOTAs were distributed to early investors through an Initial Coin Offering (ICO). Subsequent transactions among users form the current transaction network.
Validating Transactions: A Practical Example
Let's consider a simple scenario involving Alice and Bob. Each transaction is represented as a small box for clarity, displaying their account balances before and after the transaction. Initially, Alice has 10i. After sending 10i to Bob, Alice's balance becomes zero.
Later, another user named Charlie initiates a transaction. After running a tip selection algorithm, Charlie determines that he must approve Alice's transaction. To do this, Charlie needs to confirm that Alice had sufficient funds for the transfer. Failure to validate properly could result in Charlie's own transaction never being approved.
To approve Alice's transaction, Charlie must list all transactions directly and indirectly approved by Alice's transaction, tracing back to the genesis transaction. This process generates a comprehensive sequence:
- Genesis transaction creates 15i.
- Genesis transaction sends 2i to Bob.
- Genesis transaction sends 8i to Alice.
- Genesis transaction sends 5i to Charlie.
- Charlie sends 3i to Donna.
- Bob sends 2i to Alice.
Any sequence where Alice ends up with 10i and Bob with 0i is acceptable. Crucially, Charlie must ensure that no account in the system has a negative balance. If any account shows a negative balance, Charlie's transaction would be deemed invalid.
Handling Insufficient Balances
What happens if Alice attempts to send more IOTAs than she possesses? For instance, if Alice tries to send 100i but only has 10i, her transaction—and all subsequent transactions that approve it—will be considered invalid by the IOTA network.
The situation becomes more complex when approving two transactions simultaneously (which is the typical case). In a scenario where Bob's payment transaction approves two of Alice's payment transactions, it is valid only if Alice's balance can cover both transfers.
If the balance is insufficient, as illustrated below, Bob cannot successfully approve Alice's transactions. Doing so would result in a negative balance for Alice, violating the IOTA protocol. Consequently, the network would reject Bob's transaction, and it would never gain approval.
Double-Spend Attacks and Their Resolution
The above scenario exemplifies a double-spend attack, where Alice spends the same funds twice. Notably, Alice may not intentionally breach the protocol; she might accidentally broadcast two transactions. Regardless, this creates two conflicting branches in the Tangle that cannot be reconciled. This poses a significant challenge for honest IOTA users: "Which transaction should they approve?"
The solution lies in the weighted random walk mechanism, as discussed earlier. Eventually, one branch will gain a higher cumulative weight, while the other diminishes. Subsequent transactions will attach to the heavier branch, effectively confirming it, while the lighter branch is abandoned. This process implies a delay between transaction issuance and confirmation. Even if some transactions approve a newly issued transaction, it does not guarantee that the transaction is free from conflicts. To achieve confirmed status, the transaction must attain sufficient confirmation confidence—a topic we will explore in the next article.
👉 Explore advanced consensus mechanisms
Frequently Asked Questions
What is the genesis transaction in IOTA?
The genesis transaction marks the creation of all IOTAs during the initial coin distribution. No additional IOTAs are generated after this point, ensuring a fixed supply.
How does IOTA prevent double-spending?
IOTA uses a weighted random walk algorithm and tip selection rules to ensure that conflicting transactions (double-spends) are identified. The branch with higher cumulative weight is confirmed, while the other is discarded.
Why is transaction approval necessary?
Approval ensures that the sender has sufficient funds and that no negative balances occur in the network. It maintains the integrity and security of the Tangle.
What is confirmation confidence?
Confirmation confidence refers to the probability that a transaction is permanently accepted by the network. It increases as more transactions approve it directly or indirectly.
Can transactions be reversed once confirmed?
Once a transaction achieves high confirmation confidence and is part of the heavier branch, it is considered immutable and cannot be reversed.
How long does transaction confirmation take?
Confirmation time varies based on network activity and the weight of the transaction. It may take longer during high congestion or if conflicts exist.
Reference: The Tangle: an illustrated introduction (Part 4: Approvers, balances, and double-spends)