Factual Inaccuracies of “Facebook Libra Is Architecturally Unsound”
A post by Stephen Diehl about Facebook Libra is making the rounds this morning. It makes a number of claims about flaws in the software. Many of these claims are factually inaccurate. I consider it to be a gish gallop that bombards you with a bunch of negative claims, many of which are false or at best, specious.
For context, I am a contributor to OpenLibra, a group independent of Facebook (or should I say “FACEBOOK”) who are experimenting with operating the Libra software. My company also operates other BFT-based cryptocurrencies, such as the Cosmos Network which is based on Tendermint BFT. Prior to that I worked extensively in credit card processing at companies like Square and LivingSocial, also doing card processing integrations at several companies before that.
This post, like the original, is intended to be purely technical, and if it were to talk about my opinions of a hypothetical production Libra network, they wouldn’t be positive: the day Libra came out and I was first able to review the papers and code, my tl;dr was “some interesting looking tech with terrifying social implications”.
That said, allow me to review some of the technical claims:
Libra’s byzantine tolerance on a permissioned network is an incoherent design. #
The claim is that Libra is a centralized, “permissioned” network, and therefore doesn’t need BFT.
This claim would be a good one, but ignores some properties of the Libra software: it supports running in either a permissioned or permissionless mode as one of the settings in the configuration. I suspect Facebook’s longer term plans, were they to actually launch Libra, are to move to a permissionless proof-of-stake model much like the one used by Cosmos (which managed to launch in a fully permissionless mode).
Libra HotStuff BFT is not capable of achieving the throughput necessary for a payment rail #
This section throws a few numbers out: it claims the UK Bacs system does 580,000,000 transactions a month, or about 223 transactions per second.
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. I don’t think that number is unrealistic, and some of the testnets we are running for other BFT protocols are operating at those performance levels or above.
As another data point: the Open Libra testnet has been running for about a day and has made nearly 100,000 blocks (i.e. approximately 1/6th the number in the 10+ year history of the Bitcoin Blockchain), operated by volunteers on the open Internet. Though I didn’t take the time to do so for this post, I would love to measure the transaction throughput we’re able to achieve on this testnet.
Libra’s Move language is unsound #
The core argument of this section is the Move language claims to use linear types, but the Move IR compiler contains no prover to assert the soundness, ala something like the Rust borrow checker.
This is true, but also highly misleading: the Move IR compiler does not perform these checks, and can emit bytecode which is unsound, however that code is immediately checked by a bytecode verifier which asserts these properties, including reference safety. To me this provides better guarantees than doing these checks in the Move IR compiler alone: it ensures all bytecode is checked, regardless of what compiler emitted it.
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, but it’s certainly quite a bit more existing machinery than the original blog post would lead you to believe.
Beyond that, they have experimental support for translating their bytecode to Boogie IVL in order to facilitate formal verification.
Libra’s cryptography engineering is unsound #
And… here we get to the part of the post which really takes the cake. Stephen Diehl doesn’t understand cryptography, but sure has a lot to say about it.
It is impossible to say whether the dependencies on the following tools are secure or not as none of these libraries have had security audits nor do they have standard practice disclosure policies. Several core libraries in particular are indeterminate about their vulnerabilities to side channel and timing attacks.
My goodness, where to begin. I guess the part where the claims that these libraries have never had a security audit are completely incorrect: