Why we rolled our own consensus algorithm
quorumcontrol.com
quorumcontrol.com
> We are borrowing all the best parts of existing technology and combining them in a unique and innovative way.
To the best of my knowledge, none of the listed existing technologies have been formally verified.
However, if everyone had that attitude we'd never improve on the existing art. So I'm glad some people are willing to risk it.
But just to reiterate, if you're thinking of rolling your own consensus - or even implementing an existing consensus algorithm yourself (although that's much worse for Paxos than for Raft) - you're almost certainly making a big mistake.
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.
1. Reimplementing an existing cryptographic primitive, such as SHA-256.
2. Inventing a new cryptographic primitive, with a reduction to existing cryptographic assumptions, and implementing it. A recent example is SPHINCS-256, which was proven secure in the random oracle model.
3. Postulating a new cryptographic hardness assumption, inventing a new cryptographic primitive based on it, and implementing it. Recent examples are IOTA's Curl hash function and StarkWare's Jarvis cipher.
#1 is risky, but at least the risk can be mitigated by having qualified peers review the implementation. #2 is riskier, but still, it can be mitigated by having qualified peers review the proof. #3 seems far more dangerous, since it involves conjecture.
What the Tupelo team is doing is like #2 -- risky, yes, but not comparable to #3.
EDIT: Note, I'm not talking about blockchains and byzantine fault tolerance, but in context of Paxos/Raft.
Read the Google paper on their chubby distributed locking system using paxos. They had a hard time getting it right - unless you think you're so much better than them. IIRC Leslie Lamport works (worked?) for them.
Use an existing, well used, well scrutinized implementation of a known algorithm.
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.
Keep in mind that this is BFT consensus. Until recently, it was a niche area of research with very little real world usage. Even if an existing algorithm like PBFT met their needs, there are no well tested PBFT libraries.
But if you're a researcher/had a CS research background, I don't see why not. By definition research results in novel approaches (ideally better) than the current ones. You have to be willing to challenge the consensus.
PhD students who can prove that their algs work should work on it, like the results of this paper: https://raft.github.io
There is also this https://iohk.io/research/papers/#9BKRHCSI that claims to be formally verified Proof of Stake.
Promises are cheap.
e.g. IOHK is behind Cardano/ADA, which has a marvellous white paper making all sorts of mathematical promises ... and still runs off a central node.
In this case, it appears to be a system for private blockchains, i.e. a system with central administration. All "consensus" algorithms in this case are variants on taking turns - further elaboration is security theatre, given that attacking the system to that extent would go well beyond the legal agreements to be allowed to participate in the first place.
There must be some validity behind the idea of weighted random turn-taking though since it is similar to how the next version(serenity) of ethereum will work based
What will this achieve that a centralised database and existing legal structures and agreements won't?
(Assume I know the area and you can go into depth. However, remarkable claims will need a production system - anyone can and does claim anything's coming in "six months, for sure" - and an explanation of how you've achieved something that your many, many competitors haven't.)
If everyone asks you the same question, you’re the one who’s wrong, not everyone else.
If everyone is asking you why you did it, you probably shouldn’t have done it.
In security, you generally don't want "unique and innovative", you want tested, verified, robust algorithms that have been gone over with a fine-toothed comb.