This is really hilarious:<p>> When asked, RDX Works executives informed Jepsen that blockchain/DLT readers would normally understand present-tense English statements like these to be referring to potential future behavior, rather than the present.<p>> Jepsen is no stranger to ambitious claims, and aims to understand, analyze, and report on systems as they presently behave—in the context of their documentation, marketing, and community understanding. Jepsen encourages vendors and community members alike to take care with this sort of linguistic ambiguity.
It's funny how the comments here are polarized, some of them claiming that Jepsen slaughtered RDX, others that it proved that the consensus layer is rock solid.<p>Let's appreciate this for what it is. Blockchains are, at their heart, a type of database (or at the very least a ledger which can be the foundation on which some subset of database semantics can be layered). Performance and reliability are empirical claims which can be tested empirically, using the kind of methodology that Jepsen has been innovating for many years. It is very much to the credit of RDX Works that they subjected their product to this type of testing. I'm not saying anything about the way the <i>use</i> the test results in their blog post and marketing materials, though.<p>What I'd like to see going forward is that it's routine for blockchain-based databases to be tested the same way as real databases, based on actual shipping product rather than speculative goals. Whether you think this would be validating or devastating reveals quite a bit about your preconceptions, but either way would be a win for truth and progress.
I admire aphyr's ability to dive into a new and complex distributed systems technology and understand it enough to evaluate it for correctness. I hope the Radix developers have ears to listen, the comment in the report "RDX Works informed Jepsen that the blockchain/DLT community had developed idiosyncratic definitions of safety and liveness" is not encouraging.
Classic blockchain startup in the 2020s: put a cool name on your version of sharding, act as if it were already live and being used by governments / corporations, and hope enough people put rockets in the discord to keep the VC money coming in.
Aphyr and jepsen are a blessing both to breakdown software like these as to illustrate complex distribute system concepts with real world evidence. The dist sys class provided by Aphyr is amazing (<a href="https://github.com/aphyr/distsys-class" rel="nofollow">https://github.com/aphyr/distsys-class</a>)
OH YEAH JEPSEN IS TEARING APART CRYPTO!!!!<p>Aphyr is the best. No matter your fave distributed tech and all it's CAP-don't-matter stuff, he shows that... CAP does very much matter and it's really hard.<p>Cassandra? Kafka? MongoDB (bwahahahah)? It's all got edge cases.<p>He should be getting paid a million bucks a year by various auditing/accounting firms and the FTC/SEC for validating crypto claims. It would be a massive public service.<p>I like that its being treated like a database, and that the safety/correctness of any blockchain has to be viewed from a distributed database standpoint.
I have a pretty much opposite perspective on Jepsen than most of the folks here. My feeling is that essentially no distributed system is perfect or without trade offs (and certainly no single node system is perfect and wothout tradeoffs) and Jepsen posts basically make that clear over and over again like some form of techie outrage porn... but the tone and implication is as if somehow there is some alternative panacea without tradeoffs... and I find that a little bit misleading.<p>Basically an astute reader of Jepsen testing may deduce "I need to use a single node system" which is one option but without the availability characteristics modern users usually want