Blink Protocol — Anatomy of a transaction (part III)
This is the third article in a series where we explain the details of the Blink Protocol.
In the first article we introduced the concepts of lockers and rounds, while in the second article we talked a bit about finality and the CTH (chained transaction hash) of accounts.
In this third article we’ll talk about what happens to a transaction once it’s been signed by the sender and the lockers. We’ll show how the rest of the network will come to accept a valid transaction and how double spends are rejected by the system.
Transaction broadcasting
Once a transaction has been validated and signed by the lockers, it is ready to be spread throughout the network.
When a node finds out about a transaction, it will check if it’s valid and apply it on its own version of the ledger. Then, it will choose a random sample of network nodes (the size of the sample is a constant) and forward them the transaction.
The protocol allows a transaction to be broadcasted only in the current round or during the next round. An honest node will ignore transactions that were created two or more rounds in the past. It’s important to note that a node can still catch up if it loses connectivity, this step is explained later in the article in the sync section.
To estimate real world broadcasting times, we’ve run several simulations, of networks ranging between 1,000 and 100,000 nodes, distributed proportionally to the world population on the globe. We assume that a message is processed in at most 20 ms before being sent to other random nodes.
In our simulations, all transactions are broadcasted to 99.9% of the network in under 850 milliseconds.
Double spend attack
Because honest nodes accept a broadcasted transaction for only a short window of time, any double spend attempt must happen immediately. If there is no honest node that is told about the second dishonest transaction within two rounds, the double spend attempt will fail.
But once an honest node receives two conflicting transactions, it will immediately revert both of them. Then it will broadcast the two conflicting transactions together, and all the other honest nodes will subsequently revert the double spend.
Sync process
Although our simulations show that a transaction reaches almost the entire network in less than a second, it is only required that ~66% of the nodes receive a transaction during the broadcasting phase.
In the next step of the protocol, called the sync, every node starts to randomly (proportional to its stake) to interrogate other network nodes about their hash of the entire state of previous rounds. In case the state differs, the nodes will find and communicate transactions that were missed by one of the parties.
When a node finds out about a transaction that was either missed by itself or by another node, it will query a new random sample of the network about that particular transaction. The decision to apply or discard the transaction is taken according to whether two thirds of the random sampled nodes have it or not.
Persistent Merkle tree
One of the key components of the Blink protocol is the data structure we use to store the accounts and transactions so that we can have access to any of our states in the past, while also having the ability to quickly apply new transactions.
We need this since a sync between two nodes might require multiple back-and-forth queries to find their differences, and for these queries to be bandwidth efficient, they need to all be on the same states that nodes first started syncing on. Transactions are still happening all the time though, so nodes need to also be able to apply them constantly.
That’s why we use a persistent version of a Merkle tree. Persistence here is a theoretical computer science term describing data structures where one has access to all past version of that data structure, while storing only the deltas (not to be confused with simply persisting data on disk).
You can read more about persistent data structures here and about Merkle trees here.
Conclusions
The major difference between the sync and the broadcasting phase is that during the sync a node asks others about transactions, while during the broadcast others tell the node what transactions they have.
The goal of this phase is for every node to reach the same past state as the others in its random sample. By the end of sync, nodes will be ready to vote for the state of the past round, but more on this in the next article.
If you liked this article:
Follow us on:
Twitter | Telegram
And visit our website.
Check out our Medium blog.
