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)?
Why we rolled our own consensus algorithm
41–44 of 44 posts
Re: Why we rolled our own consensus algorithm
#42Earlier 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...
Re: Why we rolled our own consensus algorithm
#43Earlier 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.
Re: Why we rolled our own consensus algorithm
#44TL;DR: This is an announcement that they didn't actually do anything yet. (algorithm not yet fully decided on, just buzzword soup).