The Truth Behind Libra, Facebook’s New Cryptocurrency — Think Big
By Alfonso de la Rocha on ALTCOIN MAGAZINE
Originally published at https://business.blogthinkbig.com on July 1, 2019.
It’s been almost a week since Facebook’s public release of Libra Blockchain, a decentralized programmable database promoted by Facebook to support a low-volatility cryptocurrency. Opiniated rivers of ink have been already poured in favor and against this project. Once the initial storm of opinions has passed, and after processing Libra’s whitepaper while trying not to read too many reviews in order not to pollute my own opinion, in this article I would like to share a technical overview about Libra and what, in my humble opinion, means for the blockchain ecosystem.
Disclaimer: The purpose of this document is to share a technical analysis of Facebook’s open source reference implementation of Libra.
Rationale Behind Facebook Libra
Before getting lost into the technicalities, it is worth understanding why Facebook has bothered to design yet another blockchain network. After a decade, Bitcoin and cryptocurrencies have shown to be the first success story of blockchain technology. Cryptocurrencies have served as an efficient medium of exchange for billions of people around the world, but their high-volatility and the fact that they are not backed by big corporations or governments but by developers, engineers, and decentralization maximalists have prevented their mass-adoption. Libra is Facebook’s attempt to fix this.
The Libra coin will be the first asset to be issued over the Libra blockchain, and it will be fully backed by a diversified basket of bank deposits and treasuries from high-quality central banks to ensure a low-inflation and low-volatility of the currency. The governance of the network, and therefore the Libra coin and its backed assets, will be managed by the Libra Association, initially formed by a diverse set of founding members such as Mastercard, Paypal, Visa, Facebook, Ebay, etc. Thus, Libra’s aim is to become a corporate-backed global financial network supporting a global currency managed by a brand new corporate-formed non-profit central bank (The Libra Association). It may seem silly, but this is huge, and an indication of it is the fact that there are no banks as founder members of the Libra Association.
The Libra Association is still accepting new members, and to join this select group an initial investment of $10 million in Libra investment tokens have to be made. Presumably, this initial investment will be used to purchase the basket of a financial asset used to back the currency. As already advanced, the members of the Libra Association will be the ones in charge of setting the governance of the network and its underlaying coin. Initially, Libra will be a permissioned network, but its design is thought out in such a way that in the future it can become a permissionless network based on Proof-of-stake. Every member of the Libra Association will have a validator node (in charge of executing and verifying transactions), and clients (i.e. users) will be able to send transactions to the network through these nodes. The aim is for Libra to become a global permisionless network.
Libra is Facebook’s attempt to create a global financial network where startups and incumbents can compete with new types of business models and financial applications lowering the barriers set by banks in the financial sector. A new generation of fintechs and financial disruptions is coming.
Technical Walkthrough
Libra seems like a great disruption from the business side, but what about the technical part? Does it offer something new to existing technologies? Let’s go through Libra Core’s, i.e. Facebook’s reference open source implementation of the technology, to clearly understand what it offers.
For the analysis, we evaluate the main concepts and schemes backing the operation of blockchain technologies in order to compare it with existing proposals. Mainly we discuss Libra’s logical data model, its transaction execution, its scripting programming language (Move), its consensus, its networking layer, and performance.
Logical Data Model
The Libra Blockchain is implemented as a decentralized database visible to validators and clients in the network. All data in Libra is stored in a single versioned database or ledger. The version of the ledger equals the number of transactions executed in the network, hence, every new successful transaction increase by one the version of the ledger. At each version, the database is made up of a tuple representing the transaction that triggered that version, the output of that transaction and the state of the ledger after executing the transaction. Thus, if we are at version 3 and we send a transaction to the network, after executing the transaction the status of the database will be in version 4 with the following data: (transaction4, the output of transaction4, state after transaction4). What does this mean? That transaction are not aggregated in blocks like in other technologies such as Bitcoin and Ethereum. This lack of blocks more closely resembles technologies such as Corda.
Changes in the database are triggered through transactions, and the specific changes to be performed over an asset are determined by Move scripts. Move is the underlaying programming language in Libra, and like Solidity smart contracts in Ethereum, or chaincodes in Hyperledger Fabric, it enables transactions to perform changes over the data stored in the ledger. In our previous example, our transaction4 operates over the state after transaction3 giving an output of transaction4. Simple, right?
What kind of operations can be performed in Libra? Through a validator, you can execute a transaction against the ledger state at the latest version (such as “transfer 10 Libras to my friend Bob”), or you can query about the ledger history at both, current and previous versions (so we can ask something like “what was the balance in Libras for Alice at version 3 of the ledger?” or “You know the current version of Charlie’s balance?”).
Finally, Libra uses an account-based data model to represent the ledger. This means that the state of the ledger is structured through a key-value store which maps account address keys to account values (i.e. users to their balance in Libras). Account address keys identify users in the system (they work like Ethereum and Bitcoin addresses, what is more, there is no enforced-KYC in Libra, so like in the aforementioned technologies, users may have more than the account in the network). Account values, on the other hand, are the collection of published Move resources and modules. Libra and other assets in the network are represented through Move resources, while Move modules are the code to be run over resources by a transaction (like smart contracts or chaincodes). This account-based model makes every user, asset and module accessible in the network through its unique address.
Figure 1 depicts an example of the account-based data model of Libra with four accounts. Ovals represent resources and rectangles modules. A directed edge from a resource to a module means that the type of resource was declared by that module. Thus, account 0x12 contains a balance of Currency.T resource declared by the Currency module.
Nerd alert, skip this paragraph if you are not highly technical: Unlike Bitcoin or Corda that uses a UTXO transaction model, where assets histories are modeled through the consumption of inputs and the generation of outputs; Libra uses an account-based model, more similar to the one in Ethereum, where the history of assets are modeled as updates over certain addresses in the ledger.
Key concepts:
- Data in Libra is stored in a versioned database.
- Changes in the ledger are triggered by transactions.
- Logic and resources in Libra are implemented as Move scripts.
- Users in Libra can have more than one account, and KYC is not enforced.
- Libra’s data model is not UTXO (like Bitcoin or Corda) but account-based (like in Ethereum)
Transaction Execution
The only way to change the ledger in Libra is through transactions. Transactions are triggered by users in the network. Like in many other blockchain technologies, transactions in Libra must be deterministic (the output and ledger changes of the transaction is completely predictable) and hermitic (all the information required to execute the transaction is contained in the transaction or in the current state of the ledger).
Like in Ethereum and other blockchain networks, in order to manage the demand for computing capacity in the Libra network, the concept of gas is used in transactions. Every transaction incurs in a gas expense according to the congestion of the network. This mechanism aims to reduce the demand when the system is under a higher load than it was provisioned for. The system is designed to have low fees during normal operation when sufficient capacity is available, and really high fees, for instance, in the presence of a potential denial-of-service attack. All this is regulated, like in Ethereum, using a gas price and gas cost, where the gas cost determines the specific effort to run a transaction, and the gas price the specific price of a unit of gas according to the congestion of the network. Users may set a high gas price to ensure that the validation of their transactions are prioritized.
As advanced above, transactions use Move scripts to determine the changes to be performed in the ledger, and the specific executions to be run. Initially, only the Move modules for the Libra coin are available for use, but in the future, any asset and related logic would be implementable using Move. Presumably, anyone in the network with enough gas will be able to deploy their own modules and resources to Libra (indeed, you would be able to issue Cryptokitties over Libra). Even more, every logic in the Libra network, even the management of the gas price and gas cost of transactions, and their execution are implemented using Move scripts.
In Libra, the execution of the transaction and the update of the ledger are performed independently (see Figure 2). When a transaction is sent to the network, (i) the first thing validator nodes do is to check its signatures are valid (i.e. they match the sender’s public key and the data transaction data). (ii) Then the “prologue” code is run. This Move script authenticates the transaction sender, ensures that the sender has sufficient Libra coin to pay the transactions fees, and verifies that the transaction is not a replay of a previous transaction (to prevent replay-attacks). (iii) Once the transaction prologue has completed successfully, Move’s virtual machine checks that the transaction and the code run by the transaction are well-formed (the VM verifies this by validating the corresponding Move modules and resources bytecode); (iv) if this verification is successful the transaction modules are published under the transaction sender’s account (Libra uses an address-based data model, remember?); (v) with everything related to the transaction verified and the modules published, published in the transaction is executed, the corresponding Move scripts are executed, the write operations performed by the scripts in the ledger are performed, and the transaction events (if they exist) are emitted; (vi) finally, the VM runs the transaction epilogue (another Move script similar to the prologue) that charges the user the gas used and increment the sender’s sequence number (this sequence number accounts the number of transactions performed by a user and prevents replay-attacks).
Key concepts:
- The execution of transactions in Libra must be deterministic and hermitic.
- Libra uses gas (through gas price and gas cost of transactions) to handle congestion and computing demands.
- Fees in Libra should be low with enough capacity available in the network.
- Every logic in Libra is implemented as a Move script.
- Initially, the only available resource is the Libra coin. In the future users will be able to deploy new modules and resources to the network using Move scripts.
The Move Programming Language
Throughout the document, we have been talking about Move Programming Language without presenting it formally. Move is a new programming language created for the execution of code over the Libra protocol. Move was designed (i) to enable flexible transactions via transactions scripts; (ii) to allow user-defined code and datatypes (such as Cryptokitties), including smart contracts via modules (you could kind of guess this from aforementioned descriptions); (iii) and support configuration and extensibility of the Libra protocol (remember that everything in Libra is a Move script, even the computation of gas costs and the gas price of transactions).
In Move a resource can never be copied, only moved (got it?). In addition, a resource type can only be created and destroyed by the module that declared the type. All these guarantees are enforced by the Move Virtual Machine, over which every Move script is run. Related to this is interesting the fact that the Libra coin is implemented as a resource type in the Move language (in contrast to Ether and Bitcoin, which have a special status in their respective languages).
There is a specific whitepaper dedicated in depth to explain the Move Programming Language, so we can leave this matter for a special issue about Move.
Key concepts:
- Again, everything in Libra is a Move script.
- Move allow the flexible transaction, configuration extensibility, and user-defined resources and modules.
- In Move resources can never be copied, only moved.
- Safety guarantees of Move are enforced by its Virtual Machine.
Byzantine Fault Tolerant Consensus
And what about the consensus, how do validator nodes reach a consensus in the state of the shared ledger with every new transaction? The answer is LibraBFT. LibraBFT is a Byzantine Fault Tolerant (BFT) consensus algorithm based on HotStuff. BFT consensus algorithms are designed so that an agreement between nodes is achieved even if 1/3 of them are malicious or compromised.
So how do LibraBFT works? Whenever validators receive new transactions from clients, they share them with the rest of validators through a shared mempool protocol. This mempool protocol aggregates every transaction pending validation in the network. LibraBFT then proceeds in a sequence of rounds. In each round, a validator takes the role of leader and proposes a block of transactions to extend a certified sequence of blocks that contain the full previous transaction history ( wait! But you told us that there were no blocks in Libra? And you are right, blocks here are just an abstraction used by the consensus algorithm to aggregate pending transactions, but data in the ledger is not stored using blocks).
Every validator receives the proposed block from the leader and checks their voting rules to determine if it should vote the certifying block or not (according to the changes proposed in the transaction). Once verified the execution of the transaction, each validator’s vote is shared with the leader, and if enough votes are collected by the leader (>= 2f+1 to ensure a BFT consensus) then the block is committed and spread through the network so that every validator can update its database.
Again, get ready for a nerdy note. LibraBFT provides safety and liveness in the partial synchrony model, as in the case of well-known consensus proposals such as Casper (Ethereum) and Tendermint (Cosmos). Libra does not pose anything disruptive in the consensus field, but it uses concepts that have shown to work in the cryptoworld.
Key concepts:
- LibraBFT supports 1/3 of compromised or malicious nodes in the network.
- Transactions pending validation are shared between validator nodes through a mempool protocol.
- A set of voting rounds are required between validators to reach consensus and commit changes to the ledger.
Networking
Like any other blockchain technology or decentralized system, Libra requires an underlying networking protocol to enable the communication between (at least) validator nodes in order to reach consensus. Libra’s networking protocol is inspired by the libp2p project, which is the distributed networking library promoted by the creators of IPFS and used in projects such as Parity Substrate.
Libra’s networking layer implements well-known schemes in peer-to-peer systems such as Multiaddr, for peer addressing, messages over TCP for reliable transport, Noise for authentication and full-end encryption, Yamux for multiplexing substreams over a single connection, and push-style gossip for peer discovery. I understand that you may have no clue what all these random concepts mean, but if you like distributed system I highly recommend you read and understand all these schemes, as they are the basis of almost every distributed system and blockchain protocol. They are the substrate of blockchain technology.
In order to authenticate nodes in the network, this networking service uses the same validator smart contract as the consensus algorithm to verify the public key of the connected node. Any change in a validators node status will be reflected in this smart contract, and to join the inter-validator network, a validator must authenticate using a network public key in the most recent validator set defined by the contract (this is the scheme used by Libra to permission nodes to the network).
And by the way, the first reference implementation of Libra core is written in Rust (like Parity, Substrate and many other projects), in case you want to start learning this programming language to be prepared for the future to come.
Key concepts:
- Libra is built over a P2P networking layer inspired in the well-known libP2P.
- Permissioning in Libra is achieved through a smart contract that holds the public keys of every allowed validator in the network.
Performance
One of the main concerns, when we talk about decentralized technologies and blockchain, is its performance. There are no performance evaluations about Libra yet, but according to the whitepaper, Libra has been designed to support in its initial launch at least 1000 transactions per second with a 10 seconds finality time (way more than what we are used to achieving with technologies such as Bitcoin, Ethereum or even Hyperledger Fabric).
According to their numbers, to achieve this, validators will require a bandwidth of at least 40Mbps, a CPU able to perform 1000 verifications per second (something achieved by any modern commodity CPU), and an SSD storage system preferably of around 16TB to support the expected load of the network. This HW requirement should be affordable by anyone. Unfortunately, until the network is not live, we won’t be able to verify this claim.
Key concepts:
- Libra’s first release is expected to support up to 1000 transactions per second with a 10 second finality time.
Hands On Libra Core
The open source reference infrastructure is already available in Github, and you can start running your own node and making your first Libra transactions. So, what kind of can of things can we start doing with Libra?
- After compiling and installing the node (Figure 3), we will have Libra’s command line available to start testing (Figure 4).
- The first thing we can do is create a new user account. This command creates a new asymmetric key pair and returns its corresponding address (Figure 5).
- With our user account ready, we need to get (mint) some coins to start transferring them. In this test, environment coins may be easily obtained using the “mint” command (Figure 6). Finally, we can send our newly minted coins to another user account (Figure 7). After performing the transaction, we can see all its details such as the signatures involved, the payload or the gas used.
In Libra’s official website you will find easy tutorials to start putting your hands on its technology.
Open Questions
Even after reading the whitepaper and our aforementioned analysis, a set of open question not covered by the technical whitepaper arise. I’m sure there are many more, but the ones that come to my mind are the following:
- Right now, the only available Move resource in the network is the Libra coin, what are the rules, and what kind of things will the user be able to do with Move? Will anyone is able to deploy their custom Move resources or modules, or only validators will be entitled to do this?
- The Libra coin is backed by a basket of financial assets, but who and how decides the monetary policy backing the Libra coin? It is a technical scheme, or is the Libra Association responsible for this? Can new Libra coins be minted or issued at any moment, or what are the rules?
- Taking a step back, what would be the specific rules for the governance of the network and the Libra coin?
- Libra wants to transition from a permissioned network to a permissionless one based on Proof-of-stake (PoS). How is this transition planned, and which specific PoS mechanism will be chosen for the network? Will the performance be maintained under this scenario?
- What will be the requirements, after the investment stage, for new members to join the permissioned network, and how is the onboarding and permissioning process performed?
- Has Libra any privacy scheme in its roadmap to enable private transactions? Are there any layer-2 or sharding mechanisms thought to scale Libra? And what are the regulatory requirements of Libra and the Libra coin? Do Libra coin and users using it have to enforce any regulations (KYC and AML)? Is it a bank, a currency, an exchange fund, security or all of the above, or none? What do central banks think? Cross-border sanctions? Can the controlling group ban applications? Users? Countries? How and why?
- How do you get people to use it? How do you cash in/out — what real-world distribution do you have (mobile operator payment systems like Mpesa have worked in emerging markets because the operators have already built this)? What happens if I lose my password?
Conclusions
This was a tough ride; I hope you enjoyed it as much as I did. My conclusion is that, as shown in our technical analysis, Libra doesn’t offer great disruption or innovation to current blockchain technologies and protocols. Every technical concept presented in Libra core has been studied and tested to a greater or lesser extent in other blockchain proposals. The real disruption is on the business side of the proposal. Libra is a corporate-backed blockchain initiative with a clear goal: issuing a new financially-backed global currency over a shared global exchange network. Its aim is to lower the barrier to financial innovation shifting the sovereignty of money from central banks to corporations. Let’s see how it ends up and the new type of services and business models it enables.
Originally published at https://business.blogthinkbig.com on July 1, 2019.
