Blink - The most scalable alternative to blockchain

[Blinknet]

Hi all,

The Blink project consists of a team of 8 engineers who have come up with a new consensus protocol. You can read about it here. We have already implemented a prototype that currently supports up to 20.000 transactions per second in a global network, with a >99% confirmation probability in 1-2 seconds.

We are looking for feedback regarding our white paper. Please leave your comments here and we'll try to address the issues you raise.

[tromp]

The whitepaper looks like a rewrite of the Raiblocks/nano one...

[Blinknet]

There are indeed some similarities with Raiblocks (the account chains), but that's just a small part of our protocol. The most important concepts in our algorithm are the lockers, the rounds, and the consensus mechanism, which is much more robust than Raiblocks.

[monsterer2]

Note that an inconsistency can never occur without the complicity of the lockers
involved. So whenever the network nodes find out about an inconsistency, they will
punish those lockers by confiscating their collateral.

'Find out' needs some clarification. Why can't I create a million network nodes which I control that either:

a) approve my conflicting transactions

or

b) 'disapprove' genuine transactions

and then just steal the collateral of genuine participant lockers?

[Blinknet]

'Find out' needs some clarification. Why can't I create a million network nodes which I control that either:

a) approve my conflicting transactions

or

b) 'disapprove' genuine transactions

and then just steal the collateral of genuine participant lockers?

Your voice in the network is proportional to the amount of money you have (POS). Check out the locker selection function for more details.

[monsterer2]

'Find out' needs some clarification. Why can't I create a million network nodes which I control that either:

a) approve my conflicting transactions

or

b) 'disapprove' genuine transactions

and then just steal the collateral of genuine participant lockers?

Your voice in the network is proportional to the amount of money you have (POS). Check out the locker selection function for more details.

So, as an attacker with large stake, all I need to do is vote against valid transactions and just harvest all their stake? Neat.

[Blinknet]

So, as an attacker with large stake, all I need to do is vote against valid transactions and just harvest all their stake? Neat.

Yes, that's how POS works, if you have more than half the stake you can do anything. But probably if you already have half the stake you are not interested in attacking anyone, but you'd like the value of the coin to go up

[monsterer2]

So, as an attacker with large stake, all I need to do is vote against valid transactions and just harvest all their stake? Neat.

Yes, that's how POS works, if you have more than half the stake you can do anything. But probably if you already have half the stake you are not interested in attacking anyone, but you'd like the value of the coin to go up

No, it isn't. In regular PoS you can double spend if you own a large relative proportion of stake, but in your model, you can actually harvest all the stake from the entire rest of the network.

[Blinknet]

You can actually harvest all the stake from the entire rest of the network.

What do you mean, how do you convince the other nodes to update their ledgers accordingly? Please read the paper more thoroughly.

[tromp]

> So far, we’ve reached speeds of over 30 000 transactions per second on a local network
and 15 000 transaction on a global network, but we expect to improve these numbers in
the next 2-3 months.

At those speeds, assuming a single tx takes about 250 bytes, a full node would fill up a 1TB drive in a few days, and new nodes would struggle to ever finish the initial block download...

It's easy to be scalable if you have no concerns for bandwidth and storage requirements...

[monsterer2]

You can actually harvest all the stake from the entire rest of the network.

What do you mean, how do you convince the other nodes to update their ledgers accordingly? Please read the paper more thoroughly.

If I control a large enough stake, why can't I report valid transactions as conflicting and steal the stake which those lockers held when they signed the transactions?

[Blinknet]

At those speeds, assuming a single tx takes about 250 bytes, a full node would fill up a 1TB drive in a few days, and new nodes would struggle to ever finish the initial block download...

It's easy to be scalable if you have no concerns for bandwidth and storage requirements...

Not sure why you're saying it's easy to scale, and even if it were, not sure what's wrong with supporting this level of scaling. Our advantage is actually also confirmation times, the scalability is a bonus. The full history being too large for a new node argument basically applies to any scaling on the main protocol at this level. We do have a solution for this, given how we store the state using a persistent Merkle tree, and a full node only needs to store the current state and not all transactions. A full node can check that the history is valid at any time, since consensus is reached on the hash of a round, for which proof can be requested from nodes that have the history at that point.

We expect a new node to sync up by only getting the latest state of all accounts (which is a lot smaller than the transaction history), and checking transactions through random sampling.

If I control a large enough stake, why can't I report valid transactions as conflicting and steal the stake which those lockers held when they signed the transactions?

You have to provide proof of the conflicting transactions, as two locker signatures approving conflicting transactions. It's specified in the paper, this proof is considered in lieu of the signature of the penalized node's account.

[monsterer2]

You have to provide proof of the conflicting transactions, as two locker signatures approving conflicting transactions. It's specified in the paper, this proof is considered in lieu of the signature of the penalized node's account.

In that case, why isn't it optimal for me to submit nothing but pairs of conflicting transactions in a continuous manor hoping to have two signatures get accidentally signed due to network latency?

[Blinknet]

You have to provide proof of the conflicting transactions, as two locker signatures approving conflicting transactions. It's specified in the paper, this proof is considered in lieu of the signature of the penalized node's account.

In that case, why isn't it optimal for me to submit nothing but pairs of conflicting transactions in a continuous manor hoping to have two signatures get accidentally signed due to network latency?

Sorry, but what you're describing doesn't really apply, since the locker responsible for signing transaction is the same entity, and won't accidentally sign a transaction conflicting with another transaction he signed anymore than someone can crack a private key from the public key by accident. The case when two conflicting transactions take place in consecutive rounds is more complicate, and there's an analysis for it in the paper, please read it before trying to design attacks.

[monsterer2]

Sorry, but what you're describing doesn't really apply, since the locker responsible for signing transaction is the same entity, and won't accidentally sign a transaction conflicting with another transaction he signed anymore than someone can crack a private key from the public key by accident. The case when two conflicting transactions take place in consecutive rounds is more complicate, and there's an analysis for it in the paper, please read it before trying to design attacks.

i could find no such analysis. Please can you direct me to it?

[Blinknet]

Sorry, but what you're describing doesn't really apply, since the locker responsible for signing transaction is the same entity, and won't accidentally sign a transaction conflicting with another transaction he signed anymore than someone can crack a private key from the public key by accident. The case when two conflicting transactions take place in consecutive rounds is more complicate, and there's an analysis for it in the paper, please read it before trying to design attacks.

i could find no such analysis. Please can you direct me to it?

"The protocol assumes the nodes are not necessarily up to date with the state of all the
accounts, but they should be when it comes to those accounts for which they are
supposed to act as lockers. To achieve consistency, the nodes that are lockers for the same
account in consecutive rounds will communicate with each other. The old locker will
pass on the state of the account to the new locker.
Should the network have a low trust in lockers, at the expense of a small increase in
bandwidth and CPU usage, transactions can also be signed by the lockers of the current
round and also by the lockers of the previous round. This would ensure that no
transactions could ever be invalidated when lockers from consecutive rounds are not in
sync"

This part could probably be better emphasized.

good luck to you, I hope this project will be on top! By the way the name is super!

Thanks for that, glad you like the name.

[monsterer2]

"The protocol assumes the nodes are not necessarily up to date with the state of all the
accounts, but they should be when it comes to those accounts for which they are
supposed to act as lockers. To achieve consistency, the nodes that are lockers for the same
account in consecutive rounds will communicate with each other. The old locker will
pass on the state of the account to the new locker.
Should the network have a low trust in lockers, at the expense of a small increase in
bandwidth and CPU usage, transactions can also be signed by the lockers of the current
round and also by the lockers of the previous round. This would ensure that no
transactions could ever be invalidated when lockers from consecutive rounds are not in
sync"

This part could probably be better emphasized.

That's hardly an analysis. This is core of your consensus protocol, you can't gloss over it with a throwaway paragraph.

With a horizontal consensus like this (as opposed to a vertical chain of consensus, like a PoW chain) it is possible for the consensus to stall completely due to inability to reach an agreement. You've allowed a maximum of two rounds of consensus to occur, so what happens when both of these fail to reach an agreement? Why can't that happen?

[Blinknet]

With a horizontal consensus like this (as opposed to a vertical chain of consensus, like a PoW chain) it is possible for the consensus to stall completely due to inability to reach an agreement. You've allowed a maximum of two rounds of consensus to occur, so what happens when both of these fail to reach an agreement? Why can't that happen?

The two rounds limit refers to the amount of time nodes accept transactions through broadcasting. So if node A tells node B about a transaction from the past (more than 2 rounds ago), node B will ignore it.

But the consensus part is different than the tx broadcasting and lasts for more rounds. Node B can specifically request some account information from node A, e.g. he's behind with the transaction chain for that account, and update its state accordingly.

[monsterer2]

But the consensus part is different than the tx broadcasting and lasts for more rounds. Node B can specifically request some account information from node A, e.g. he's behind with the transaction chain for that account, and update its state accordingly.

So, when is a consensus reached? Why can't this go on forever?

[obadia]

I do not understand the logic to use the value on a wallet instead of Processing power. The PoW will then be pretty much void of sense, in my opinion and many hacking methods can arise from that..