Blink Protocol— Anatomy of a transaction (part II)
This is the second article in a series where we explain the details of the Blink Protocol.
In the previous article, we introduced a few key concepts:
- Lockers — each account is assigned to a specific node, a supervisor responsible for pre-approving any transaction affecting the account
- Rounds — the timeline is divided in rounds (in the current implementation a round lasts 10 seconds). At the start of every round, new lockers are picked for the accounts.
In this article we will dive more into the structure of an account and a transaction, also offering details about some of the mechanisms that keep our network secure.
Finality
One of the defining features of any distributed ledger technology (DLT) is that transactions become immutable, i.e. they cannot be changed. This state of irreversibility is called finality.
To some it may sound surprising, but technically speaking almost all blockchain based protocols do not have finality. By design, honest nodes will always accept the longest chain as being the valid one. So if an attacker manages to produce a long enough chain, it can override the entire blockchain, starting with the genesis block. In practice, it is considered that once a block is confirmed by at least 6 other blocks (this is Bitcoin’s case, others may vary) it becomes immutable. But keep in mind this is not really guaranteed, it’s just an assumption backed by probabilities.
The Blink protocol does guarantee finality, and one of the goals of this series of articles is to show how a transaction reaches this state. For the purpose of this particular article though, we’ll assume finality is always reached a certain number of rounds in the past. Basically, the entire network agrees on the hash value of the state of all the accounts at the end of a certain past round.
Account structure — CTH
Our protocol works with objects called accounts. Each account consists of:
- an address;
- a balance — the amount of money currently in the account;
- account data — used mainly for smart contracts, similar to Ethereum;
- the CTH (chained transaction hash )— a hash value, more details below.
The CTH identifies in a cryptographically secure way the state of the account and its entire history. Even more, the CTH also secures that last finality state reached by the network. Basically, when a new transaction is issued, the new CTH of any of the accounts affected by the transaction is computed using the old CTH and the transaction hash.
The transaction hash contains info about:
- the previous CTH of the accounts affected
- the round id
- the amount of money transferred (or any other description of how the accounts are changed)
- the last finality state
So once a finality state is reached, it will be confirmed by all the future transactions.
Double spend prevention
In Blink, a double spend is represented by two transactions that operate on the same CTH value of an account. Because any transaction has to be signed by the lockers, a double spend can only happen with their explicit complicity.
If the network identifies two conflicting transactions, it will discard both of them and punish the corrupt locker(s) by confiscating part of its/their stake.
Choosing the lockers
Besides guaranteeing the immutability of transactions, the finality also serves an additional purpose. When a round starts, new lockers are chosen for all the accounts.
We use a pseudorandom function that takes as input, amongst other things, the last finality state. So as long as a potential attacker doesn’t have control over all the nodes (besides transactions, we have a simple mechanism that ensures every node will affect the finality hash), choosing the lockers stays a fair process.
A potential attacker could wait until the designated locker(s) for one of his accounts is a corrupt node. But even in this case, the damage the attacker can inflict is local and doesn’t affect the great majority of honest transactions. This isn’t the case in blockchain based systems, where a single node (or a small subset of nodes) is designated to choose the next block, having a global negative impact.
Conclusions
The finality state is a central component of the Blink protocol. It ensures transactions will eventually become irreversible, while also adding an extra layer of security.
In the next article of the series, we’ll talk about how a transactions is propagated through the network once it’s signed by the lockers, and how the nodes synchronise in case they miss one or more transactions.
If you liked this article:
Follow us on:
Twitter | Telegram
And visit our website.
Check out our Medium blog.
