Libra Technical Whitepaper Review

20 Jun 2019 by svet

Despite my natural aversion to centralized blockchains I have to recognize that the Libra Blockchain Technical Whitepaper published recently on the libra.org website presents itself a significant milestone in the progression of permissioned DLTs. It is very well written and, IMHO, outpaces that of Telegram, not to mention JPMorgan one, which had been already reviewed in this group.

Now, this out of the way, I might say that despite its impressive thoroughness and the amount of work, which a collective of more than 50 international authors (one might say, judging by their names, they appear to be preselected to represent all continents), put in designing Libra network's architecture, "Move" language and Libra consensus protocol, I still can't assign it "a" on the "Engineering" side of the "System" sub-rating.

The reason is that I've seen in my previous practice as a corporate systems analyst too many gigantic, centralized networks designed by large groups of smart practitioners, which, despite an initial good intention, ended up to become a mish mash of non-coherent, boxed and conflicting architectures. Not that I believe in Facebook's ultimate screwup. Moreover, I assign more than 70% probability to that it will not. Nonetheless, I simply do not have a good feeling about that project, which will be run by the gigantic corporation with multiple other parties involved, each of which doesn't necessarily have an alignment of interests with each other and with FCB.

Additionally, all main elements of Libra, its protocol, its accounts system (even taking into consideration Libra's "corporate" accounts and EOS-like sub-accounts tree), its transactions mechanism (gas model), its consensus (which is, basically, dBFT's RAFT version) present itself various modification degrees of already existing solutions / protocols (primarily those of Ethereum). Result: "Engineering" is "b+".

Do not take me wrong, there are some original Libra elements, which I've liked. For example, "Move" language, which is a first serious attempt ("Viper" excluding) to design OOP blockchain language from scratch. I think that "modules" (roughly an analogue of "classes") might notably outperform traditional DLT languages' functionality (f.e. that of "Solidity", specifically in creating / passing objects and in its use of proxy while addressing other contracts).

Moreover, "Velocity" of Libra might be in the "a" range, meaning that it has a chance to became a first centralized and, at the same time, practically highly scalable network (thanks to its existing, ginormous user base) with its throughput exceeding 1000 TPS. Many new elements of Libra were specifically worked out to boost its TPS and scalability performances (notably, Libra consensus). Result: "a--" (we'll see how it works before removing "--").

Of course, new networks' "Security" is always the most difficult element to rank without its testing and solid historical truck record. I'm of a conservative school of thoughts, that takes a "wait-and-see" approach. Despite very qualified efforts of Libra team to assure networks resistance to all popular attack vectors I can't make it "a" before I see it works. Besides, complex, centralized architectures always reinvigorate hackers ingenuity. Result: "b+".

Libra's "Transparency" (or "decentralization") is easy to rank. Obviously, it sucks. However, looks like FCB intends to undertake (in a distant future) some conscious efforts to increase the autonomy of nodes. Even going as far as promising (citing) "to make the Libra Blockchain fully permissionless". At this stage I simply refuse to believe in that "propaganda" but objectivity requires that I upgrade this sub-rating from a dismal "c" to an ugly "c+".

RESULT: "System": Security-Velocity- Engineering- Transparency: b+a--b+c+

Note, that with this kind of a dense and detailed paper I, by necessity, had to left unobserved in this brief review many of Libra's important features, which some of you might suggest to be decisive in order to change some of suggested by me sub-ratings. Well, I'm always open to your critics, anyway :)