Blink Protocol — Anatomy of a transaction (part I)
The Blink team is working on developing the first cryptocurrency that has all the characteristics to rival Visa and PayPal:
- It’s highly scalable;
- Has almost instant transaction confirmation times;
- It’s secure;
- And it’s decentralised.
For those who don’t have the time or patience to go through the entire paper, we’ve decided to create a series of articles to offer a broad overview of the protocol.
The series will consist of 4 articles describing the steps that take place from the creation of a transaction up to the moment when finality is reached and the transaction becomes irreversible.
In this article we’ll present the first confirmation step, a pre-approval of a transaction that happens in less than 1 second, offering the possibility of real life payments for regular purchases.
Maintaining a ledger
In a peer to peer network, each node stores its own copy of the ledger. The challenge arises when an update has to be performed. When this happens, the nodes need to make sure that:
- The transaction is valid.
- All the other (honest) nodes will apply the update on their copies of the ledger
In the case of cryptocurrencies, checking if a transaction is valid means validating the signature of the sender and making sure the account’s balance is greater than the amount transferred, and maybe a few other simple operations specific to the protocol. This step is straightforward and easy to perform.
The real challenge arises in making sure all the other nodes will apply the same update.
One way to tackle this problem is to have all the nodes communicate with each other and have some sort of voting mechanism in place, to make sure a great majority agrees with the update.
While this sounds like a good enough solution, it does pose some challenges. As the network grows, each update will take more and more time, limiting throughput and increasing latency, so overall performance suffers.
A few protocols (Ripple, Stellar) use some variations of the voting system, where a node only consults a subset of other nodes, in an attempt to improve overall performance, while still making sure consensus is reached. But even so, the network growth continues to impact the performance figures.
Introducing the lockers
Instead of having all the nodes communicate with each other, the Blink protocol assigns each account to a specific node, a supervisor, called the locker of the account.
Whenever a transaction is initiated, it has to be signed by:
- the sender account
- the sender account’s locker
- the receiver account’s locker
The lockers are assumed to always be up to date with the state of the accounts they supervise. So if they agree with the transaction and sign it, we have a first confirmation step.
The client making the transaction communicates with the lockers almost instantly (in our current prototype it takes 0.3–0.6 seconds). The great majority of transactions signed by the lockers will eventually be accepted by the entire network.
The importance of the first confirmation step
For real life payments, and especially for micro transactions, merchants will most likely accept a transaction immediately after it’s signed by the lockers. There is indeed a risk of rejection, but using historic data each merchant can do a risk assessment and adjust its prices to cover the expected losses.
Having low latency is crucial in the real world. When you’re buying coffee from Starbucks you don’t want to wait 30 seconds for the payment to be accepted. Paying for accessing web content demands even lower confirmation times.
Blink is the only protocol that can deliver this kind of performance, with a layer of security provided by the lockers (Nano, the only competitor that promises low latency, doesn’t offer any security for this step).
Rounds and multiple lockers
It is possible that the locker of an account is malicious, or it simply goes offline for an indefinite amount of time. In this case it would be impossible for the account to send or accept any transactions.
Our solution is to divide the timeline in intervals called rounds. Each round will last a few seconds — in the current implementation the duration is set to 10 seconds. An account’s locker will change each round, so even if a node is malicious or offline and doesn’t sign the transactions, the client can wait for the next round and retry.
Another mechanism to increase security is to have more than one locker per account. A transaction would require a majority of the lockers’ signatures. Having multiple lockers is a better option for large money transfers, as they add an extra layer of security.
Getting accepted by the rest of the network
After a transaction is signed, it still needs to be accepted by the rest of the network (all the other nodes need to update their version of the ledger).
In the following articles of this series, we’ll describe a transaction more in-depth and the next steps of the protocol. We’ll show how, in the case of an honest transaction, it will get reach an irreversible state.
If you have any questions regarding this part of the protocol please leave your message down below and we’ll reply as soon as possible.
Stay tuned for the next article!
If you liked this article:
Follow us on:
Twitter | Telegram
And visit our website.
Check out our Medium blog.
