Blink Protocol — Anatomy of a transaction (part IV)
This is the fourth and last 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, in the second article we presented the structure of an account, and in the third article we talked about the transaction broadcasting and the sync phase.
In this fourth (and last) article we’ll show how the network reaches finality and then we’ll analyse some potential attacks and present solutions to them.
Finality
As we explained in the second article of the series, finality refers to a state where transactions become irreversible.
Some of the existing consensus protocols don’t have finality at all (e.g. Nano), others guarantee some probabilistic finality without ever truly reaching it (Bitcoin, Ethereum, and most blockchain based cryptocurrencies), while a small minority do indeed have finality. Blink falls in the latter category.
In our protocol, when a transaction is created, it is first signed by the lockers (two random nodes). Then, it is being broadcasted by the network during the current round and the following one. After that, nodes start syncing with one another, until they probabilistically reach the same state (the exact duration of the sync phase will be chosen in the future, when we launch the test net).
As a final step, the network will have a vote on the hash of the entire state of the past round. The vote process is independent from the other parts of our protocol. We’ll first implement a simple Byzantine Fault Tolerant voting process, proportional to stake, but this can be changed in future versions.
Each node will sign its vote and communicate it to the rest of the network, while also getting back all the other signed votes. An honest node will consider the most voted state as the one that is accepted by the network (in case it voted for a losing state, it will sync with some other node in order to apply the winning state). Nodes will only vote a single value per round, otherwise their stake can be confiscated.
This voting mechanism where every pair of nodes communicate with each other is extremely secure, but too slow to be applied for each transaction independently. Fortunately, we only need to employ it once per round, so it doesn’t affect the overall performance of the network.
Attacks
Going through the four articles in this series — Anatomy of a transaction, should give you a broad understanding of the Blink protocol. In this section we present some potential attacks and the ways the network is going to react to them.
Double spend
As we showed in the previous article, the double spend can only happen during a short period of time, and only with the complicity of at least one locker. As you know by now, Blink uses proof-of-stake, where accounts can delegate their voting power. But in addition to the stake, each node is required to have a collateral, a sum of money that can be confiscated in case of bad behaviour. This collateral weighs more into the probability of a node being selected a locker than the delegated stake.
So, in the case of a double spend, the network will identify the corrupt locker(s) and take their collateral, making it unfeasible to double spend most of the transactions. And in the case of large money transfers, recipients will wait for the finality anyway.
Spamming transactions
This is an attack every high throughput cryptocurrency needs to consider. Basically, there are only two ways it can be addressed: either through some transaction based proof-of-work, or using fees.
We chose to go with fees, for two reasons. First of all, proof-of-work increases latency, and we believe low latency is crucial for both payments and distributed apps. And second, having high throughput means fees will be low. We expect that in practice, if the network is well bellow capacity (almost anytime except during an attack), fees would be close to zero.
Nodes can estimate the throughput of the network based on past rounds. When a node is spammed with transactions, it will order them by fee and only broadcast those with the highest fees, until throughput is reached.
DDoS attacks
In a denial-of-service, the attacker wants to block the locker(s) of an account, to prevent incoming and outgoing payments.
Every round the lockers change, so this creates the opportunity for the account to opt for more lockers. In the case of multiple lockers, only a majority of them is necessary to sign the transaction, so the attacker’s cost increases because he needs to attack at least half of the new lockers.
DDoS attacks can’t be avoided completely, but they can become more expensive than they’re worth. It’s enough that an honest transaction reaches its lockers once in a round in order for the transaction to be signed, so the spammer has to essentially use up all of the target’s bandwidth.
And an important observation, in Blink an attacker that wants to block a single account would have to spend the same amount of resources it would take to block the entire network in some proof-of-stake blockchain protocols. This is one of the greatest advantages of not having a single point of failure.
Conclusions
This was the last article of the series, we hope you got yourself familiarised with our protocol. We believe it is the only solution on the market to offer the best performance without sacrificing security or decentralisation.
If you have any questions leave them in the comment sections or write us an email at contact@blink.network.
If you liked this article:
Follow us on:
Twitter | Telegram
And visit our website.
Check out our Medium blog.
