5 ms·
> To Jepsen’s surprise, RDX Works asserted that phenomena such as aborted read, intermediate read, and lost writes do not constitute safety violations (in the b
by daenney 5y ago
> To Jepsen’s surprise, RDX Works asserted that phenomena such as aborted read, intermediate read, and lost writes do not constitute safety violations (in the blockchain sense). RDX Works claims that to describe these errors as safety violations would not be understood by readers from a blockchain background; this report is therefore “factually incorrect”. On these grounds, RDX Works requested that Jepsen delete any mention of our findings from the abstract of this report.
That certainly does not inspire any confidence.
> Jepsen respectfully declines to do so.
Thank you for sticking to that.
- Mleekko 5y agoWhat Radix say is true though. In private DBs, reads from the DB node are considered transactions and need to follow the same rules as writes. But on public blockchains(ledgers) only state manipulation is what matters. For example, Metamask obtaining an address balance would be a transaction, but no one calls it that way because it doesn't modify the state.
- daenney 5y agoSure. But they could have asked for the additional clarifications or context to be added to make this clear, instead of requesting a bunch of stuff be removed because they’re concerned it’ll paint them in a bad light.
- faraz85 5y agoAs I understand from the report, no request was made to remove the content but to leave terms like "liveness break" and "safety break" out of the abstract until those terms were defined in the main report.
- moby_click 5y agoI don't think readers with any kind of computational background expect to read FAILED writes. Apparently, neither does RDX Works - claiming to have fixed most of the issues.
- faraz85 5y agoPleased they ignored that request too, although I can see where RDX are coming from. In a distributed ledger it's all about state. The consensus layer of the architecture is rock solid according to this report.
- aphyr 5y agoThe core ledger system lost committed transactions by choosing not to write them to disk before acknowledgement.
- Mleekko 5y agoYeah, the issue is serious but at the same time: "This problem occurred only in cases where every node was killed at roughly the same time". And there are 100 nodes on the network. (and it is fixed now)
- NelsonMinar 5y agoWell, Radix says it is fixed now. That's the gist of their response to this report, "we fixed a lot of things and no one's tested the new code but trust us!"
- Mleekko 5y agonope, if you read it one more time, for this particular issue Jepsen confirms the fix.
- Too 5y agoIsn't this is a rather common configuration for a distributed DB? Given one node dies before flush, you trust that the remaining nodes in the system will not die at the same time and live long enough to flush to their respective disks. It's a gamble yes, but depending on your environment the risk can be smaller than the benefits. For a blockchain ledger, you might want to choose the safer corner of CAP in that equation.
- belter 5y agoJepsen is the Carl Jung of Distributed Systems...