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