It seems really naive to think that if FB were to get a foothold in the currency markets with a permissioned product that they would later on go against their own interests and transition to a permissionless alternative (not to mention the massive legal and technical hurdles that this transition would require)
...but I don't know why I'm arguing against Libra, it's such an all-around terrible product, I should just keep my mouth shut. Facebook is tarnishing the idea of a "corporatecoin" for the next few years and doing all of us a favor in the process.
https://en.wikipedia.org/wiki/Libra_(cryptocurrency)#Blockch...
Of course, they were very happy to make all kinds of vague, rosy promises right out of the gate... it doesn't cost them anything to do so.
But if you are capable of doing an initial launch on an permissioned ledger and achieve the initial network effects anyway, what's the point of providing such guarantees later on?
Call it like it is: Company scrip.
> Libra’s byzantine tolerance on a permissioned network is an incoherent design.
This post's argument rests on their being a unused flag in the configuration file for a feature which is not implemented. The Libra whitepaper indicates that a permissionless design is beyond their ability to implement at this time. There is no reason to believe a proof-of-stake model is what is intended. Even the whitepaper states:
> The challenge is that as of today we do not believe that there is a proven solution that can deliver the scale, stability, and security needed to support billions of people and transactions across the globe through a permissionless network.
> Libra HotStuff BFT is not capable of achieving the throughput necessary for a payment rail
This seems like some actual benchmarks that simulate real system load are needed before a conclusion can be made.
> Libra’s Move language is unsound
It seems like the OP takes a more traditional view of type checkers as a Haskeller programmer. Pushing type-checking to the bytecode level is a very nontraditional approach to compiler design and contradicts the original Libra whitepaper claiming to implement linear types. Libra does not do this provide any linear typechecker or formal verification at this time.
> Libra’s cryptography engineering is unsound
This section is subject to some debate. It seems there are some unpublished audits of the libraries that may lend credibility to the Rust libraries but are unpublished. The original post doesn't claim that they are insecure, just that the more audits and testing the libraries undergo the more trusted they should become trusted (i.e. libsodium).
It also seems that Libra implements a lot of extraneous next-gen crypto that is dead code and not used for any purpose in the core logic.
> Libra has no capacity for consumer protection mechanisms
The section agrees with the OP that this does not exist.
Both true and false. Typically, someone with good systems knowledge can estimate throughput from reviewing architecture / design / implementation.
BigO notation also applies when an algorithm is distributed and runs over a network. An algorithm that's O(n^2) will always be slower than an algorithm that's O(2n). You don't need to run benchmarks to find that out.
There shouldn't be two posts about the same thing on the front page. In most cases we'd merge the follow-up into the original, but since the points of view here are so opposed, it's going to seem like favoritism no matter what we do. My first crack at this is to let the opposing side have a hearing since the original has already spent many hours on the front page.
Curiously it claims Libra can’t do this, but posts no numbers about Libra’s throughtput. Libra’s throughput target is 1,000 transactions/sec (see Section 8: Performance in the Libra paper) with 10 second latencies on consensus time.
OK but 1,000 transactions/sec is a non-starter. A single large seller or popular event driving a live transaction burst can need thousands. Even two decades ago, a WWE event could need 15K sales per second, or 5K per second for Amazon’s black Friday.
If you’re looking to compete with the order of magnitude of a Visa/MC, you’re needing 15,000 - 25,000 per second.
For a commercially available ‘distributed ledger’ able to handle these characteristics (including service level objectives for operating it in production), take a look at the AWS QLDB we asked AWS to make available a couple years ago.
AWS introduced “managed blockchain” and the very different “QLDB” in the same keynote.
Compare under the covers to see why, despite the hype, they introduced QLDB, which is designed for real work when you know who is running the servers:
https://aws.amazon.com/managed-blockchain/
If you’re a trusted entity or a trusted consortium with legal paper among your members, you probably don’t want the blockchains, you probably want QLDB.
That said, can we please all agree that a prediction of probable future action is not a defense of the status quo?
> I suspect Facebook’s longer term plans, were they to actually launch Libra, are to move to.... >...it’s being worked on, and it certainly has “the capacity” for them.
This is all well and good but it's certainly not a thing that is happening now. At the very least I would like to see Facebook write down that they intend to do these things before I accept this as a justification.
...no?
Arcieri: Is it actually sound? I don’t know, it’s brand new and looks unfinished to me, and even if it were finished I’m unqualified to make that assertion
Oh snap.
I'm by no means a fan of Facebook and Libra, but Diehls post felt far from frontpage worthy to me.
> Stephen Diehl doesn’t understand cryptography, but sure has a lot to say about it.
This is how I felt about the entire post, to be honest.
It felt like a consultant on a mission, who doesn't really understand the topic, only took a cursory glance at a project, and yet berates it extensively. All while sprinkling in some of his particular knowledge, giving a false sense of technical expertise.
Is it me or is this a common trope of blog posts that hit the top of HN?