Thread by @trondbjoroy

1/ Everything you need to know about how @hathornetwork combines #blockchain and #DAG technology to scale the network, without taking hits to its security and decentralization levels, and how this architecture affects transaction finality time.

🧵

$HTR #web3

2/ To understand transaction finality time on Hathor we must first understand how transactions are confirmed.

3/ Bitcoin's main scalability problem is the fact that its transactions sit inside the blocks, and the number of txs that can fit is limited by the block size.

Hathor blocks are very simple. There are no txs inside so they are lightweight and fast to propagate into the network.

4/ Hathor txs live outside the blocks, in a DAG of txs. Whenever a new tx comes along it gets included in the DAG.

Txs are only connected to other transactions. Blocks on the other hand are connected to both blocks and transactions and they form a blockchain inside the DAG.

5/ This blockchain inside the DAG confirms the transactions. Every time a new block is found it confirms two transactions in the DAG.

Each of these transactions again confirms two previous transactions. This is repeated until the whole DAG of transactions has been confirmed.

6/ So it doesn't matter if there are 2, 10, or 10,000 transactions between two blocks. All transactions that have come in since the previous block always get confirmed when the next block arrives.

7/ Now we know that transactions are confirmed not only by blocks but also by other transactions.

When traffic is low and there aren’t many new txs coming in, they obviously don’t contribute a lot to the confirmations. The blocks do most of the work in this scenario.

8/ However, when there are many transactions coming in, they give a large contribution to confirmations.

In this case, many of the transactions will already have been confirmed before the next blocks are found, so now the blocks just further strengthen the confirmations.

9/ In a nutshell, this is how blockchain and DAG are intertwined in Hathor’s architecture and how the DAG enables faster confirmation times the higher the number of transactions.

10/ Visualization of a Hathor graph with transactions and blocks

🟥 = blocks (forming a blockchain within the DAG of txs)
🟢 = confirmed transactions
⚪️ = in-progress transactions
🟡 = unconfirmed transactions (tips)
⚫️ = Not yet propagated transactions solving proof-of-work

11/ So how does this architecture affect transaction finality times?

We will assume finality means six confirmations as this is the well-known criteria from Bitcoin and has been adopted by most of the ecosystem.

12/ A transaction is said to be confirmed when it has reached an accumulated weight of six times the hash rate of the network. Put differently, to successfully double-spend tokens, an attacker would have to put in a minimum work effort of six times the entire network’s hash rate.

13/ Following this, the maximum transaction finality time on Hathor is three minutes. This assumes six confirmations, 30 seconds block time, and no new transactions coming in at all.

14/ However, in a high-load scenario where lots of transactions are being generated, finality becomes close to instant as transactions are able to confirm themselves without having to wait for blocks.

15/ We now know that changes in actual TPS affect confirmation times. So do changes in the relative hash power between miners and transactions (remember, miners only mine blocks on Hathor, not transactions).

16/ E.g. if the miners’ hash rate increases so does the required minimum accumulated weight for confirmed transactions, and more transactions will be needed to give more accumulated weight.

17/ These are just the basics and not extensive in any way. For a deep dive into this topic and the maths behind it, check out chapter 8 of Marcelo's thesis.

bibliotecadigital.fgv.br/dspace/bitstre…

18/ PS: what's considered final is a personal choice too. If you're receiving tokens worth $50M, you might want more confirmations.

PPS: Finality is always probabilistic. The blockchain could have a reorg even after six confirmations although the chances of it would be low.