Live data from Hacker News

The Blockchain Problem Space – When to Use Blockchain?

blog.ironbay.digital

21–30 of 63 posts

Re: The Blockchain Problem Space – When to Use Blockchain?

#21
post #15

TL/DR: "If Byzantine Fault Tolerance [0] does not create a huge advantage for your use-case, it is unlikely blockchain makes sense to consider over a traditional database." [0] https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

And that is wrong AFAICT. PoW is what achieves Byzantine fault tolerance, not the blockchain. What blockchain achieves is proof of history given only the latest block's hash. This might or might not have a PoW on top of it to achieve BFT. Practical example: An authoritative server which responds only with the latest block's hash (this is cheap, think microcontroller cheap) is another way to make a blockchain useful w…

This is just semantics. "Blockchain" in the sense it's usually used means proof-of-work; hashing that incorporates the history tree predates blockchain and exists in things we wouldn't usually consider "blockchain", e.g. git.

Re: The Blockchain Problem Space – When to Use Blockchain?

#22
post #6

The other major issue with Blockchain is that "all nodes can see everything". This is theoretically a problem with distributed databases as well. However, in the case of distributed databases, the database nodes that can "see everything" are not the end user, whereas, in Blockchain because the nodes are untrusted, one must assume that the end user can see the entire Blockchain state. This limits the number of use-cas…

We're working on 5), a privacy option for public blockchains using secure multi party computation. Few application trade-offs (mostly around availability logic and additional cost), no private or trusted chains.

Re: The Blockchain Problem Space – When to Use Blockchain?

#23
post #14

Earlier quoted context omitted.

Blockchain should be singular - "blockchains" should be used when referring to the technology in general. Getting this wrong is the #1 indicator that an article on blockchains isn't worth reading.

I'm not sure if it should be plural when referring to the technology in general. "Powered by blockchains technology" doesn't seem correct to me. I do hope you'll read the article regardless!

The word "blockchain" works just like the word "computer". You can have a blockchain or multiple blockchains, just as you can have a computer or multiple computers. And you'd refer to "blockchain technology" just as you'd refer to "computer technology."

Re: The Blockchain Problem Space – When to Use Blockchain?

#24
post #17

You know what is a great database with all those properties? Your folder with git. There is nothing that you cant do with git that you can do with blockchains as a database. About the BFT part, it fails the mention the very important part that it doesnt work without proof-of-work. --- So then when should we use p-o-w blockchains? When you want to decentralize control - both, distribution & conflict resolution.

Git has a history and UTXO does not store history only keeps with the latest commit

Re: The Blockchain Problem Space – When to Use Blockchain?

#25

TL/DR: "If Byzantine Fault Tolerance [0] does not create a huge advantage for your use-case, it is unlikely blockchain makes sense to consider over a traditional database." [0] https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

Though many new "blockchain" systems do achieve BFT (perhaps most notably Tendermint, which seems to be passing aphyr's Jepsen tests with flying colors), it's important to keep in mind Bitcoin falls short of achieving it:

https://eprint.iacr.org/2014/765.pdf

"Regarding BA, we observe that Nakamoto’s suggestion falls short of solving it, and present a simple alternative which works assuming that the adversary’s hashing power is bounded by 1/3."

One important difference between how a truly BFT system behaves versus Bitcoin is how Bitcoin handles network partitions, or rather, how it doesn't handle them.

Specifically, when Bitcoin goes split-brain, i.e. in the event of a network partition, Bitcoin will "reorg" into two new chains, both of which will happily accept writes from both sides. When the partition is healed, one chain will win, and the writes to the other chain will be clobbered. Ideally these transactions will wind up in the mempool again and be accepted into the new chain, but that isn't a guarantee, more of a band-aid, and doesn't change the fact the system ostensibly acknowledged a write it then lost.

On the CAP triangle, Bitcoin has chosen to sacrifice partition tolerance (i.e. Bitcoin is NOT partition tolerant), and this is bad: https://codahale.com/you-cant-sacrifice-partition-tolerance/

There are ways to turn Bitcoin into a truly BFT system. The main one I like is decoupling proof-of-work from transaction processing, turning it into a leader election system for a more traditional BFT algorithm, such as ByzCoin:

https://arxiv.org/abs/1602.06997

With ByzCoin, if you can't reach quorum, you can't make progress, so in the event of a network partition the system will simply stop accepting writes if it can't reach quorum, as opposed to accepting writes which will go on to be clobbered by a future reorg.

Re: The Blockchain Problem Space – When to Use Blockchain?

#26
post #2

You really need a blockchain for ONE THING: To timestamp transactions in a distributed way. Transactions can be signed, proving authorship. At signing time, you can prove the transaction happened AFTER something else. The only thing missing is PROVING THE TRANSACTION HAPPENED BEFORE SOMETHING ELSE. For that, you need an incentive structure to keep each transaction be accepted by someone, somewhere, in a growing merkl…

The PoW isn't meant to elect the next miner. It's meant to ensure the integrity of the chain and maintain a lead in the work cost for the honest chain.

Re: The Blockchain Problem Space – When to Use Blockchain?

#27
post #7

Earlier quoted context omitted.

Unless you want to totally eliminate counter party risk or execute an unstoppable transaction. Most use cases do not require these benefits.

Unstoppable transaction is not a benefit.

It really depends on the use case. In general, in the commercial world, we want to be able to have transactions/contracts that can't just be voided without consequence because one of the parties thought it was a good deal at the time but it turned out not to be. On the other hand, most legal systems aren't going to enforce contracts that have ruinous effects on someone because of a simple mistake or event that no one could have foreseen.

Re: The Blockchain Problem Space – When to Use Blockchain?

#28
post #6

The other major issue with Blockchain is that "all nodes can see everything". This is theoretically a problem with distributed databases as well. However, in the case of distributed databases, the database nodes that can "see everything" are not the end user, whereas, in Blockchain because the nodes are untrusted, one must assume that the end user can see the entire Blockchain state. This limits the number of use-cas…

> 3) Encrypt or cryptographically hash portions of the state. But by definition, this portion of the state cannot be acted upon by smart contracts. This will change once homomorphic encryption is feasible.

He mentioned zero knowledge proofs in point (1) - that includes homomorphic encryption if I'm not mistaken.

Re: The Blockchain Problem Space – When to Use Blockchain?

#29
post #25

TL/DR: "If Byzantine Fault Tolerance [0] does not create a huge advantage for your use-case, it is unlikely blockchain makes sense to consider over a traditional database." [0] https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

Though many new "blockchain" systems do achieve BFT (perhaps most notably Tendermint, which seems to be passing aphyr's Jepsen tests with flying colors), it's important to keep in mind Bitcoin falls short of achieving it: https://eprint.iacr.org/2014/765.pdf "Regarding BA, we observe that Nakamoto’s suggestion falls short of solving it, and present a simple alternative which works assuming that the adversary’s hashin…

> With ByzCoin, if you can't reach quorum, you can't make progress [...]

This may be a stupid questions, but how does such a system prevent me from adding new nodes, only to remove them all at once if I want to prevent the system from progressing?

Re: The Blockchain Problem Space – When to Use Blockchain?

#30
> Blockchain, however, handles conflict resolution in quite a different way. If there is a net-split between Europe and the USA and two versions of the database emerge, it simply decides on re-connection to keep the entirety of the version that has received more traffic during the disruption (aka the longer chain). This means if the USA version wins, all of the modifications in the European version, even if there aren’t conflicts, are discarded. To reiterate, this means even if most of the interactions in Europe were just with other users in Europe and not in conflict with the USA version, all of those writes are thrown away regardless.

Is this really possible? I can't see why not. If so could a DoS on a specific region of nodes that's large enough to sustain it's own sub chain for a short period be possible? This would be extremely dangerous if transactions were confirmed by the network on a chain that is eventually ignored.

Post reply on HN