Live data from Hacker News

Why we rolled our own consensus algorithm

quorumcontrol.com

41–44 of 44 posts

Re: Why we rolled our own consensus algorithm

#41
post #40
post #29

Earlier quoted context omitted.

You're correct. Lamport has joined MSR in 2001 right after publishing "Time, Clocks, and the Ordering of Events in a Distributed System" and has been there ever since. I am not sure if he is still at the MV office but he was one of the reasons why MSR kept a presence in MV for a while.

Actually "Time, Clocks..." is a paper from the late 70s. Maybe you were thinking of the Paxos paper, "The Part-Time Parliament" (1998)?

Yeah, copy-pasted the wrong title and by the time I noticed, it was too late to edit. :)

Re: Why we rolled our own consensus algorithm

#42
post #31

Earlier quoted context omitted.

We completely agree with you that, in general, you don't want to attempt to create an entirely new consensus mechanism. As you know, there are generally only 2 (perhaps 3) broad categories of byzantine tolerant consensus that boil down to PBFT and Nakamoto consensus. Ours is a flavor of PBFT designed to reduce message complexity. We also draw from Casper in order to get the incentives and game theory right which woul…

There is a new consensus algorithm called Avalanche, which apparently starts a new, 3rd category. You can read the white paper here: https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPV...

Avalanche looks interesting, but there doesn't seem to be anything in the white paper to suggest how they plan to deal with Sybil attacks. Their safety guarantees are dependent on the number of Byzantine nodes in the network, but what prevents a single attacker from simulating a large number of independent nodes (e.g. with VMs, or a botnet) and exceeding that limit? Can a minority of correct nodes continue to function safely despite a hostile Byzantine majority?

Re: Why we rolled our own consensus algorithm

#43
post #15
post #11

Earlier quoted context omitted.

Just to drive it home. Those who actually make their own encryption libraries know their stuff, and have been in the space for years. You should never, ever, roll your own encryption. If it's a requirement, then change your damn requirements, because just like consensus; it is not easy to get right, and the pros make mistakes.

Consensus is not crypto, it's ridiculously trivial in comparison and usually so useless, that nobody even bothers doing it correctly all the way to the end user.

Consensus is at least as hard as crypto.

Re: Why we rolled our own consensus algorithm

#44
post #37

TL;DR: This is an announcement that they didn't actually do anything yet. (algorithm not yet fully decided on, just buzzword soup).

I believe Quorum is the Ethereum variant that JP Morgan developed in-house and considered "spinning off" to the community, i.e. abandoned but on github. Not clear if JPM are still paying devs to work on it.
Post reply on HN