Bitcoin Forum

Hi all,

The Blink (https://blink.network/) project consists of a team of 8 engineers who have come up with a new consensus protocol. You can read about it here (https://blink.network/media/blitz-protocol.pdf). 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.

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

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.

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

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.

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

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

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?

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.


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.

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.


Thanks for that, glad you like the name. :)

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?

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

I understand that, but what about the round itself? Surely there's a case where a given round can be submitted with a separate set of transactions, leading to a fork?

Btw, worldwide network propagation using gossip is on average 15s, that's why ETH's block time is around there.

We're trying to prove in the paper that actually there's no such case where a fork happens involuntarily.
That's the purpose of the synchronization phase, to make sure that forks happen only when nodes explicitly want them to happen. Nodes will keep making round proposals until they're sure that they've got a consensus. If nodes can't agree within a certain number of rounds, it's actually in their interest just to void the round.
If you're aware of a specific case when an involuntary fork can happen, please let us know.

Do you have any reference for the 15s gossip time? All of our testing showed much lower numbers in the order of a few seconds at most, if all you needed to gossip what in the order of a few hundred bytes. Blocks are much larger though, and that's why I'd imagine a disparity could come from.

What about in the case I've just presented, though? 10/20 lockers appear off-line, but really they're just delayed such that the round closes with the first 10/20, but then the other 10/20 also publish a round close for the same round, leading to a fork?

Here's your reference for propagation times: http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf

In the case you presented, if 10/20 lockers appear offline and later they try to broadcast the transactions for which they were the assigned lockers, the other nodes would simply ignore those transactions. Honest nodes always ignore transactions that were signed more than 2 rounds in the past. But indeed, there could be a conflict if the lockers come back online in the middle of the following round.

After the transaction broadcasting phase follows the sync & commitment. During this second phase nodes solve any kind of inconsistencies, e.g. revert double spends. Only after syncing there is a commitment vote on the global state some X rounds in the past. Anything that happened during those last X rounds is still subject to change through the sync process. A fork can only happen if the network doesn't agree on the commitment state.

As for the propagation times, check out this screenshot from the paper you linked: https://imgur.com/a/PcwwT. Our transactions currently have ~300 bytes, that's why the propagation times of Blockchain based protocols don't apply to us.

When is the ICO out?

Our intention is to have an ICO as quickly as possible, but first we need to raise seed capital and to build a team of great advisors/build a community around the project. We believe this project has top 10 potential, so we don't want to rush things.

The problem that you're facing is that of network partition combined with the fact that you allow a subset of lockers to participate in the sequence of processes that finalise the state.

You can end up with a fork if you allow a subset of all allocated lockers to finalise the state, due to network partition. If you require a majority to participate, you will get a stalled consensus until the partition resolves itself.

Nothing the lockers say finalizes the state. A locker signed transaction needs to be confirmed by a majority of nodes to be accepted.
Like previously stated, consensus is delayed until approved by the majority, even with the risk of voiding the round. The fact that you keep mentioning a fork means that you're not very clear on how the algorithm works. Did you understand this from the consensus section? It could be the paper is not clear on it, but please try reading it again.

To be honest, the paper very hard to read. A lot of babble, and hardly anything about the attack vectors, or failure modes.

I'd like to see a description of how the consensus will freeze in the worst case, rather than forking in the case of a network partition, for example.

Agree that the paper is hard to read, and that's partially unavoidable due to the complexity of the algorithm, and how all the parts are actually needed to work together. What exactly would you say is babble?

We haven't seen anyone understand the way the system works in under a day (including any of us), and you started making comments about an hour after we posted, so pretty sure you just skimmed through the paper.
It's understandable that you may not have the time to do a rigorous analysis, we're just some guys asking for advice on a forum, but what's the point in asking for attack vectors of a thing you don't understand?

We've actually pointed you to page 31 in a previous post, where we explicitly state that a majority of the network needs to agree on the state within a certain number of rounds, or else it's considered void, penalizing nodes essentially. Can you say why this doesn't say that consensus will freeze in the worst case?

There are a lot of other bits of analysis we could have added to the paper, but it would have made it over 100 pages long, without anything essential to understanding the core, since we've seen these naturally clear-up for the people that understood the core protocol, realizing that those issues apply to blockchain-based consensus and not to our algorithm.

I know you may be used to people posting crap algorithm that are easily dismissed by showing their obvious holes, and it's understandable why you'd fire some automatic arguments, they're usually valid. Still, I hope you can see that's not the case with us and that we're working on different assumptions than blockchain consensus developers.

Most of the time spent in the paper is talking about trivial things. Consensus is the hard bit, IMO the entire paper should be about that, the possible attack vectors, how it responds etc. You've made a lot of wild claims in there, which rang alarm bells for me, such as solving the NaS problem and even the claim about byzantine tolerance is hard to verify because of the way the paper is written.

Take a look at Ripple's last ledge close paper; that is clear and concise, and your design shares a lot of commonalities with that. 

Having to resort to an ICO already shows some technical flaws in my opinion.

The supply should be put out there automatically in a more elegant way than some ICO, which is why I think Bitcoin is superior already to this project.

Also a project doesn't work until it has been attacked by governments numerous times and failed at each attempt (every hardfork attempt on Bitcoin has been governments trying to screw it up). It must also held a couple billion worth for a couple years without no hacks.

Until then no amount of whitepapers is going to convince me to sell my BTC to buy any other so called "better alternative to Bitcoin".

Good luck with your project in any case.

Hey, I agree with you that there's no reason for most people to put money in a project just because of a whitepaper which very few people can actually go through. That's why we just want people to try to understand the algorithm and give us feedback now.

Most of the Bitcoin supply has already been distributed to less than 0.1% of the world's population, I don't think that's a very elegant delivery mechanism though. Neither would an ICO solve this issue, which is why we first want to get some seed investment from qualified investors (that's why we're not posting here to raise anything). In a competitive market, having the best tech is not enough to win, you still need Marketing and PR. Bitcoin is not that complicated to implement compared to our protocol, and came at a time when you didn't need marketing budgets to get adoption.

After that, we want to do a long-term coin distribution, where as many people have access to it, while allowing us to raise capital for development. Calling it an ICO is a bit of a stretch, but there's no great terminology since everyone seem to just try to raise as much money as possible quickly. Frankly, we don't know yet the details of this phase, but it's a separate problem from the consensus protocol, that we can provide details on later.

This project is definitely on my watchlist. Good luck to you guys!

Hi, Much respect and I like many of your posts here!

I think what he is calling "lockers" is what's needed and it's a cluster or coordinator nodes acting as a single unit
without any of them gaining total control.

without this the network clutter becomes far to high on scaleable systems so you have to have a compromise
and sending one transaction to 20,000 nodes so they can argue about it is pure madness anyway and should be
limited down to something like a hundred nodes based on the public address of the wallet so in effect the address
itself becomes like an IP-Range within the network if you follow what I am saying.

I award you one credit for your critical thinking

What do you have with the site?

20,000 transactions a second is huge. I think bitcoin is 6, eth around 20, PayPal 100 so this is no easy feet if pulled off. Still a way to go to VISAs 100,000 transactions a second but hey, they have a 20 year head start. How do you anticipate competing with bitcoin in future if they sort out transaction fees and fungibility? This is my only worry for many micro transaction coins.

Thanks!
Even if Bitcoin manages to get a lot more transaction per sec, with lower fees (pretty hard in itself), we still think our major advantage is in the latency to almost certainly confirm a message in under 1 sec.
Low confirmation times matter a lot more for microtransactions than for large cash transfers.

Since any transaction is never just accepted or rejected, but rather just increases in certainty with more information, the way we use lockers we think should be able to give high confirmation certainty in just 2 hops over the internet, which is in the order of hundreds of milliseconds.

And who gave you the right to control the whole supply? if 0.01% of the world population has most of the Bitcoins, blink is about to be owned by you and your team. if you had some worthy alternative to Bitcoin, you would've kept them all for yourself. we don't like anybody who'd keep everything without sharing with the community. you should distribute 20% to the community and sell 10% in ICO.

I think it's well written. I love projects built with scalability in mind. Your take is a cwry new and novel take and on problem. I'll definitely pay close attention. Is the blink network similar to iota in any way?

It's amusing how you start by saying who are we (the people that built it) to decide on distribution, and then tell us how we should do distribution.  :)
We said a couple post ago we want to distribute the coin as wide as possible, we just haven't figured out how exactly, and want to focus on the tech right now.
We'll take as much input as possible before doing anything, so we'll think about what you said, even though you seemed unnecessarily aggressive.

Hey guys, check out this GIF showing a transaction in the Blink Wallet https://twitter.com/theblinknet/status/981900386108956672 .

Anyone ever used this yet with good effect? I use something similar (I am not technical but it seems to me the same "type") with Byteball, and I always enjoy how it works - different from blockchain and yet still called "blockchain".

Did you decide yet on how you will do distribution? Maybe similar also to byteball?

It would be certainly succesful because in so many days no efficient protocols evolved substituting blockchain

Hey guys, we've tried to explain the fundamentals of the Distributed Ledger problem in our latest Medium article (https://medium.com/blinknet/distributed-ledgers-the-fundamental-problem-were-trying-to-solve-9ae3a2e5d8f7). Any feedback is welcomed :) .

Does it really made scalable or is just told so for advertising it?

Does it have efficient trader identifier combination? that thing helps identify the traders

Our current implementation supports 20,000 transactions per second, with a confirmation time of 300-600 milliseconds. We do plan on making the code open source in the future.


Not sure what you mean, but we have accounts, similar to Ethereum.

We started a series of Medium articles to better explain details of our protocol. You can read the first article here (https://medium.com/blinknet/blink-protocol-anatomy-of-a-transaction-part-i-c5fac657a681).

Blockchain is old and reliable platform to do so much transactions so better go with experience rather than trying new

Blockchain was the first solution to the distributed ledger problem. It is old and reliable, but it definitely doesn't scale.

Our second article which describes the details of our protocol is out! You can read it here (https://medium.com/blinknet/blink-protocol-anatomy-of-a-transaction-part-ii-141bc2444a52).

Hey guys, here’s the 3rd part of “Anatomy of a transaction”. Here we describe how a valid transaction is broadcasted and eventually accepted in the network, and how the double spends get rejected. You can read it here (https://twitter.com/theblinknet/status/989157376321359873).

Hey guys, the final part of “Anatomy of a transaction” can be read here (https://twitter.com/theblinknet/status/989909387794944006). You can check the entire series on our Medium page (https://medium.com/blinknet).

Our COO recently posted a Medium Article where he analyses the latency and finality in different cryptocurrencies. You can read it here (https://hackernoon.com/latency-and-finality-in-different-cryptocurrencies-a7182a06d07a).