Jepsen: Radix DLT 1.0-Beta.35.1
jepsen.io
Jepsen: Radix DLT 1.0-Beta.35.1
1–10 of 78 posts
Re: Jepsen: Radix DLT 1.0-Beta.35.1
#2I 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.
Re: Jepsen: Radix DLT 1.0-Beta.35.1
#3I 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.
> 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.
Re: Jepsen: Radix DLT 1.0-Beta.35.1
#4I like the deadpan ‘radix claims 1.4mm tps; in testing, transactions at more than 1/s can cause slowdowns’ - impressive lack of eye rolling.
Re: Jepsen: Radix DLT 1.0-Beta.35.1
#5I like the deadpan ‘radix claims 1.4mm tps; in testing, transactions at more than 1/s can cause slowdowns’ - impressive lack of eye rolling.
Slightly out of context, the 1.4mm tps test was during an earlier iteration of the sharded architecture (coming in 2023) whereas Jepsen were testing the unsharded mainnet.
Re: Jepsen: Radix DLT 1.0-Beta.35.1
#6This is really hilarious:
> 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.
> 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.
Re: Jepsen: Radix DLT 1.0-Beta.35.1
#7This is really hilarious: > 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. > 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,…
The future is now.
(sorry for relatively low effort comment.)
Re: Jepsen: Radix DLT 1.0-Beta.35.1
#8I 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.
> 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…
What 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.
Re: Jepsen: Radix DLT 1.0-Beta.35.1
#9I 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.
> 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…
Pleased 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.
Re: Jepsen: Radix DLT 1.0-Beta.35.1
#10I like the deadpan ‘radix claims 1.4mm tps; in testing, transactions at more than 1/s can cause slowdowns’ - impressive lack of eye rolling.
Slightly out of context, the 1.4mm tps test was during an earlier iteration of the sharded architecture (coming in 2023) whereas Jepsen were testing the unsharded mainnet.
It may imply they’d need 1.4 million (mm is millimeters…) shards to meet that test number, and scale linearly while doing it, though.