Blink - The most scalable alternative to blockchain

[Blinknet]

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

At page 27 of the white paper you can read about the consensus protocol. At page 31 there is a "Commitment" section. Basically, the nodes have X rounds (we didn't agree on the exact value of X yet) to reach consensus. If they don't, no reward is given to them, so it's in their interest to achieve consensus.

[1714951301]

1714951301

[1714951301]

1714951301

[Blinknet]

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..

That's the purpose, to make PoW void of sense, so humanity doesn't use as much electricity as a small/medium size country just to make Bitcoin secure. Of course PoS protocols are much more complex and attention to details is crucial.

[monsterer2]

At page 27 of the white paper you can read about the consensus protocol. At page 31 there is a "Commitment" section. Basically, the nodes have X rounds (we didn't agree on the exact value of X yet) to reach consensus. If they don't, no reward is given to them, so it's in their interest to achieve consensus.

I'd argue that it is not in their interests to achieve consensus, as the reward is only transaction fees, which are small compared to the stake you can confiscate from nodes who behave badly.

Thereby, as a rational actor it is in your interest to make nodes behave badly by trying to disrupt the normal consensus, and then provide the proof, draining them of their stake.

[Blinknet]

I'd argue that it is not in their interests to achieve consensus, as the reward is only transaction fees, which are small compared to the stake you can confiscate from nodes who behave badly.

Thereby, as a rational actor it is in your interest to make nodes behave badly by trying to disrupt the normal consensus, and then provide the proof, draining them of their stake.

Transaction fees are not the only reward they get, there is also a certain newly created amount distributed to nodes each round (if they reach consensus). Perhaps even more important, the nodes have a lot of stake invested, so it's in their own interest to keep the value of the coin up in the real world. Failing to reach consensus on a consistent basis would undermine the trust in the network and make the stake useless even if they keep. Rational actors behave optimal in the long term.

You cannot drain nodes of their stake because you cannot convince the other nodes to update their ledgers accordingly.

[monsterer2]

Transaction fees are not the only reward they get, there is also a certain newly created amount distributed to nodes each round (if they reach consensus).

You cannot drain nodes of their stake because you cannot convince the other nodes to update their ledgers accordingly.

Why cant I? If consensus nodes are tricked into acting badly, the network's decision will be to confiscate their stake, following the rules.

Even if you print coins as the reward for achieving consensus, the reward from stealing stake is still greater than this by necessity, because tricking them has zero cost associated with it.

[Blinknet]

Why cant I? If consensus nodes are tricked into acting badly, the network's decision will be to confiscate their stake, following the rules.

How exactly do you trick them?

[monsterer2]

Why cant I? If consensus nodes are tricked into acting badly, the network's decision will be to confiscate their stake, following the rules.

How exactly do you trick them?

By continually submitting conflicting transactions. Network latency means its very possible that I'll get two locker signatures for the same spend in consecutive rounds. Then I provide the proof, and drain their accounts.

[Blinknet]

By continually submitting conflicting transactions. Network latency means its very possible that I'll get two locker signatures for the same spend in consecutive rounds. Then I provide the proof, and drain their accounts.

The lockers are always up to date with the state of the accounts they oversee. When you submit two conflicting transactions, only the first one will be signed by the lockers (the second one will be rejected). Please read the paper again.

[monsterer2]

By continually submitting conflicting transactions. Network latency means its very possible that I'll get two locker signatures for the same spend in consecutive rounds. Then I provide the proof, and drain their accounts.

The lockers are always up to date with the state of the accounts they oversee. When you submit two conflicting transactions, only the first one will be signed by the lockers (the second one will be rejected). Please read the paper again.

How is that possible? With 10000 transactions per second, you can never guarantee consistency like that. 'First' is relative when you're dealing with latency.

According to the paper, lockers are chosen at random anyway, so you've got the potential for different lockers to be signing the same spend in different rounds.

[Blinknet]

How is that possible? With 10000 transactions per second, you can never guarantee consistency like that. 'First' is relative when you're dealing with latency.

According to the paper, lockers are chosen at random anyway, so you've got the potential for different lockers to be signing the same spend in different rounds.

The claim of 20K TPS is on the global state, not per account. So account consistency is not really an issue for the locker.

We've previously replied about the way lockers from consecutive rounds communicate with each other to ensure account consistency.

[monsterer2]

How is that possible? With 10000 transactions per second, you can never guarantee consistency like that. 'First' is relative when you're dealing with latency.

According to the paper, lockers are chosen at random anyway, so you've got the potential for different lockers to be signing the same spend in different rounds.

The claim of 20K TPS is on the global state, not per account. So account consistency is not really an issue for the locker.

We've previously replied about the way lockers from consecutive rounds communicate with each other to ensure account consistency.

You've glossed over it, and the paper doesn't cover it. This is the core of your consensus mechanism. You've asked for feedback on your whitepaper in this thread, I've taken the time to read it, the least you can do is to address the concerns I've raised without glibly just directing me to re-read the paper.

[Blinknet]

You've glossed over it, and the paper doesn't cover it. This is the core of your consensus mechanism. You've asked for feedback on your whitepaper in this thread, I've taken the time to read it, the least you can do is to address the concerns I've raised without glibly just directing me to re-read the paper.

Sorry if we may seem dismissive of criticism, especially when we're actually trying to receive feedback.
All the issues you're raising are actually addressed in those 2 paragraphs in the paper though.
There are two possible solutions to mitigate the problem you're raising: either having lockers from consecutive rounds communicate with one another, and do a passing of the account state at the end of the round, with signatures to back it up, or require that each transaction is signed by lockers from the previous round and from the current round. Both of these solutions are presented in the paper, and each of them solves the problem you keep coming to (spamming the network with transactions, until an inconsistency is approved).

I know they're not expanded on, but is it really not clear why this would work? For us it seemed enough at this point.

If you think that anything more needs to be said here, let us know, but please try to at least acknowledge the argument.

[monsterer2]

You've glossed over it, and the paper doesn't cover it. This is the core of your consensus mechanism. You've asked for feedback on your whitepaper in this thread, I've taken the time to read it, the least you can do is to address the concerns I've raised without glibly just directing me to re-read the paper.

Sorry if we may seem dismissive of criticism, especially when we're actually trying to receive feedback.
All the issues you're raising are actually addressed in those 2 paragraphs in the paper though.
There are two possible solutions to mitigate the problem you're raising: either having lockers from consecutive rounds communicate with one another, and do a passing of the account state at the end of the round, with signatures to back it up, or require that each transaction is signed by lockers from the previous round and from the current round. Both of these solutions are presented in the paper, and each of them solves the problem you keep coming to (spamming the network with transactions, until an inconsistency is approved).

I know they're not expanded on, but is it really not clear why this would work? For us it seemed enough at this point.

If you think that anything more needs to be said here, let us know, but please try to at least acknowledge the argument.

Thank you for clarifying. As far as I can see, the first of those proposed solutions will result in a 'no consensus' result in the best case, as the account state will look to both lockers like each of them has the correct spend individually.

The second solution sounds like it will lead to all lockers being forced to sign all transactions as there is no way to tell there is going to be a double spend, so lockers from round A will have to be online to sign round B and so on and so forth.

[Blinknet]

Thank you for clarifying. As far as I can see, the first of those proposed solutions will result in a 'no consensus' result in the best case, as the account state will look to both lockers like each of them has the correct spend individually.

The second solution sounds like it will lead to all lockers being forced to sign all transactions as there is no way to tell there is going to be a double spend, so lockers from round A will have to be online to sign round B and so on and so forth.

I'm not sure why you'd think that would happen in the first solution, since the locker of the current round would only consider valid what the locker of the previous round says is the state at the end of the previous round. The locker from the previous round always trumps the one from the current round.

Both current round and previous round lockers signing on transactions would basically be an explicit version of this.

You wouldn't need to extend this to further past rounds, since honest nodes should only re-broadcast/accept transaction from the current round, or from the last x second of the last round. The duration of a round needs to be long enough so that a transaction can be broadcast to the majority of the network.

There's no way to create inconsistent transactions like this, the worst that could happen is that a locker signs a valid transaction that doesn't have time to be broadcast to the network.

[monsterer2]

There's no way to create inconsistent transactions like this, the worst that could happen is that a locker signs a valid transaction that doesn't have time to be broadcast to the network.

What happens when lockers aren't available to sign for their allotted accounts?

Say we have 20 transactions from 20 accounts, being allocated to 20 lockers, and 10 of them are offline?

[Blinknet]

There's no way to create inconsistent transactions like this, the worst that could happen is that a locker signs a valid transaction that doesn't have time to be broadcast to the network.

What happens when lockers aren't available to sign for their allotted accounts?

Say we have 20 transactions from 20 accounts, being allocated to 20 lockers, and 10 of them are offline?

The accounts need to wait for the next round, if the transactions are not signed by the lockers they are invalid and won't be accepted by the network.

[monsterer2]

There's no way to create inconsistent transactions like this, the worst that could happen is that a locker signs a valid transaction that doesn't have time to be broadcast to the network.

What happens when lockers aren't available to sign for their allotted accounts?

Say we have 20 transactions from 20 accounts, being allocated to 20 lockers, and 10 of them are offline?

The accounts need to wait for the next round, if the transactions are not signed by the lockers they are invalid and won't be accepted by the network.

So that round closes empty, or we get 10/20 transactions in the round?

[Blinknet]

There's no way to create inconsistent transactions like this, the worst that could happen is that a locker signs a valid transaction that doesn't have time to be broadcast to the network.

What happens when lockers aren't available to sign for their allotted accounts?

Say we have 20 transactions from 20 accounts, being allocated to 20 lockers, and 10 of them are offline?

The accounts need to wait for the next round, if the transactions are not signed by the lockers they are invalid and won't be accepted by the network.

So that round closes empty, or we get 10/20 transactions in the round?

Our entire algorithm is focused around the idea that independent transactions can be treated independently. So in that round all the other transactions will be accepted, except those that were performed on accounts which had unresponsive lockers.

[monsterer2]

Our entire algorithm is focused around the idea that independent transactions can be treated independently. So in that round all the other transactions will be accepted, except those that were performed on accounts which had unresponsive lockers.

Ok, so, 10/20 go through in this round.

...What happens when the 10 which were offline, weren't actually offline at all, but just delayed due to latency and they produce a fork of the just submitted round with the last 10/20 transaction in it?

[Blinknet]

Our entire algorithm is focused around the idea that independent transactions can be treated independently. So in that round all the other transactions will be accepted, except those that were performed on accounts which had unresponsive lockers.

Ok, so, 10/20 go through in this round.

...What happens when the 10 which were offline, weren't actually offline at all, but just delayed due to latency and they produce a fork of the just submitted round with the last 10/20 transaction in it?

There's no way to create a fork on those transactions, since the majority of the network needs to receive them in the next round at most, to confirm them. Think of lockers as a pre-validation step, gatekeeper to the system if you will. Since those transactions were not confirmed by a majority of the network, that means that those transactions will never be accepted, and everyone the applied them will undo them.

Between the time a transaction is signed by a locker and confirmed by the network, it's essentially pending. We expect running a full node to be something that only servers with decent processing power and good internet should do, so delays are rare. The latency between almost any pair of servers with decent internet in the world is less than 300ms. Even if delays happen between some pairs of nodes, there would have to be a global internet problem in order for a majority of the network to have these issues.

In essence, we want to optimize the system as much as possible for the average case, while still being robust for any worse case.