5 ms·

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 ar

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.

aphyr 5y ago
The core ledger system lost committed transactions by choosing not to write them to disk before acknowledgement.
- Mleekko 5y ago
  Yeah, 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 ago
    Well, 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 ago
      nope, if you read it one more time, for this particular issue Jepsen confirms the fix.
- Too 5y ago
  Isn'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.
  - zbentley 5y ago
    > Isn't this is a rather common configuration for a distributed DB? In my experience it is not. Rather, aggressive fsyncing/O_DIRECT usage are common. The rationale for this is usually partition risk: better to durably log a write before propagating it than to potentially fail in propagating it and then be left in a position of having to either reactively fsync or hope that automatic flush-to-disk will persist your unexpectedly-sole possession of that update.
smw 5y ago
Are you (new account) failing to disclose your conflict of interest here?
- faraz85 5y ago
  Happy to share I'm an advocate of this project and follow its developments closely
  - antocv 5y ago
  - xwolfi 5y ago
    You're also financially involved, akin to a franchisee or a "member" in an MLM, and make money on providing staking services on this blockchain. It's fine, but it's important to put your comments in context: you will always tend to defend your overweight investment in this pyramid, while I never heard of it til today. One of your recent-ish blog article for instance, that contrast (commercial vs technical) with the Jepsen report: https://www.radstakes.com/post/airdrops-incoming-radstakes-partners-with-ociswap https://www.radstakes.com/post/airdrops-incoming-radstakes-p... And your statement of the 2% fee you seem to take on every staking: https://www.radstakes.com/post/radstakes-year-end-report https://www.radstakes.com/post/radstakes-year-end-report This report will not help your business, but you should pressure RDX Works into doing a new one on the next version rather than convince us we didn't read properly some quite shocking things in the first one :s
Smaug123 5y ago
> The consensus layer of the architecture is rock solid according to this report. That's quite a stretch. The report states explicitly a) the usual proviso that they can only prove the presence of bugs, not their absence, but more pertinently b) that their methodology is more usually applied to lower-latency databases, with the implication that they are less confident of their conclusions in this new regime: > Radix’s low throughput and high latency may have masked safety violations. In particular, our tests required several hours to reproduce e.g. aborted read (#13). Note also that they didn't even attempt to test what happens in the presence of malicious nodes!

aphyr 5y ago

The core ledger system lost committed transactions by choosing not to write them to disk before acknowledgement.

Mleekko 5y ago
Yeah, 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 ago
  Well, 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 ago
    nope, if you read it one more time, for this particular issue Jepsen confirms the fix.
Too 5y ago
Isn'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.
- zbentley 5y ago
  > Isn't this is a rather common configuration for a distributed DB? In my experience it is not. Rather, aggressive fsyncing/O_DIRECT usage are common. The rationale for this is usually partition risk: better to durably log a write before propagating it than to potentially fail in propagating it and then be left in a position of having to either reactively fsync or hope that automatic flush-to-disk will persist your unexpectedly-sole possession of that update.

smw 5y ago

Are you (new account) failing to disclose your conflict of interest here?

faraz85 5y ago
Happy to share I'm an advocate of this project and follow its developments closely
- antocv 5y ago
- xwolfi 5y ago
  You're also financially involved, akin to a franchisee or a "member" in an MLM, and make money on providing staking services on this blockchain. It's fine, but it's important to put your comments in context: you will always tend to defend your overweight investment in this pyramid, while I never heard of it til today. One of your recent-ish blog article for instance, that contrast (commercial vs technical) with the Jepsen report: https://www.radstakes.com/post/airdrops-incoming-radstakes-partners-with-ociswap https://www.radstakes.com/post/airdrops-incoming-radstakes-p... And your statement of the 2% fee you seem to take on every staking: https://www.radstakes.com/post/radstakes-year-end-report https://www.radstakes.com/post/radstakes-year-end-report This report will not help your business, but you should pressure RDX Works into doing a new one on the next version rather than convince us we didn't read properly some quite shocking things in the first one :s

Smaug123 5y ago

> The consensus layer of the architecture is rock solid according to this report. That's quite a stretch. The report states explicitly a) the usual proviso that they can only prove the presence of bugs, not their absence, but more pertinently b) that their methodology is more usually applied to lower-latency databases, with the implication that they are less confident of their conclusions in this new regime: > Radix’s low throughput and high latency may have masked safety violations. In particular, our tests required several hours to reproduce e.g. aborted read (#13). Note also that they didn't even attempt to test what happens in the presence of malicious nodes!