Thoughts on Libra “Blockchain”

A guide to the social media company’s foray into cryptocurrency

I dug into the 26-page technical document describing the protocol to be used as a platform for Facebook’s Libra coin (and more.) It has an impressive 53 authors! Here’s a breakdown:

Abstract

The Libra protocol allows a set of replicas—referred to as validators—from different authorities to jointly maintain a database of programmable resources.

There’s no mincing of words here—the system will be controlled by a set of authorities in a top-down fashion. However, note that it says the database is for “programmable resources” rather than just digital currency.

These resources are owned by different user accounts authenticated by public key cryptography and adhere to custom rules specified by the developers of these resources.

The use of generic words such as “resources” makes me suspect that this is for far more than just a stablecoin.

Transactions are based on predefined and, in future versions, user-defined smart contracts in a new programming language called Move. We use Move to define the core mechanisms of the blockchain, such as the currency and validator membership.

Okay, now it’s getting interesting. Use of a custom-built smart contracting language will result in a lot of questions around how feature-rich the language is, and as a result, how robust the system is against adversarial contracts. There will also be questions around developer-friendliness and how well Libra can protect smart contract developers from shooting themselves in the foot.

These core mechanisms enable the creation of a unique governance mechanism that builds on the stability and reputation of existing institutions in the early days but transitions to a fully open system over time.

It sounds like the Libra Association will be a federation that can evolve with the help of a voting system and some sort of pre-existing reputation.

1. Introduction

This ecosystem will offer a new global currency—the Libra coin—which will be fully backed with a basket of bank deposits and treasuries from high-quality central banks.

Libra is a generic crypto asset protocol, and the first asset will be a stablecoin.

Over time, membership eligibility will shift to become completely open and based only on the member’s holdings of Libra.

Sounds an awful lot like proof of stake. Apparently, the plan is to open up membership after five years, and hopefully they’ll have figured out proof of stake by then—though I expect they’ll run into the same problems as Ethereum.

The association has published reports outlining … the roadmap for the shift toward a permissionless system.

I’m pretty sure this would be the first time a distributed network transitioned from permissioned to permissionless. Perhaps the network as a whole can switch to proof of stake, but in order for the stablecoin peg/basket to be maintained, some set of entities must keep a bridge open to the traditional financial system. This will be a persistent point of centralized control via the Libra Association.

Validators take turns driving the process of accepting transactions. When a validator acts as a leader, it proposes transactions, both those directly submitted to it by clients and those indirectly submitted through other validators, to the other validators. All validators execute the transactions and form an authenticated data structure that contains the new ledger history. The validators vote on the authenticator for this data structure as part of the consensus protocol.

This sounds like Practical Byzantine Fault Tolerance, which is a well-understood 20-year-old algorithm, though they’ve probably made a few tweaks. We learn in Section 5 of the white paper that it’s called LibraBFT, which is a variant of the HotStuff consensus protocol.

As part of committing a transaction T i at version i, the consensus protocol outputs a signature on the full state of the database at version i—including its entire history—to authenticate responses to queries from clients.

This is notable, primarily because it means that new validators should be able to join the network and sync quickly without having to replay the entire history of the blockchain, assuming that they trust the existing validators.

2. Logical Data Model

The Libra protocol uses an account-based data model to encode the ledger state.

From a data structure perspective, Libra is more like Ethereum or Ripple than Bitcoin. A UTXO model has pros and cons—such as better privacy and a more robust transaction history due to the simplicity of the output-based history—but it can be harder to work with complex smart contracts. Thus the account model makes sense because Facebook is unlikely to be concerned with privacy, even though the platform sounds interested in smart contracts.

The Libra protocol does not link accounts to a real-world identity. A user is free to create multiple accounts by generating multiple key-pairs. Accounts controlled by the same user have no inherent link to each other. This scheme follows the example of Bitcoin and Ethereum in that it provides pseudonymity for users.

This sounds surprisingly good, but I wonder if this is also the case for Libra Coin, the asset. It will be interesting to observe how open this system is for developers who want to build apps that more heavily preserve privacy.

Every resource has a type declared by a module. Resource types are nominal types that consist of the name of the type and the name and address of the resource’s declaring module.

It seems like you can generate an address, and that address can have an arbitrary number of assets assigned to it, as long as each asset has a unique name.

Executing a transaction T i produces a new ledger state S i as well as the execution status code, gas usage, and event list.

Well, now we know how the system is protected from resource exhaustion attacks, presumably leveraging a resource cost system similar to Ethereum’s.

There is no concept of a block of transactions in the ledger history.

Interesting. There is no actual blockchain data structure in the Libra protocol—blocks are more of a virtual, logical construct that are used by validators for the purpose of coordinating confirmed snapshots of the system state. Backing up, now the first sentence of the section makes more sense:

All data in the Libra Blockchain is stored in a single versioned database. A version number is an unsigned 64-bit integer that corresponds to the number of transactions the system has executed.

Every crypto asset network I’m familiar with works the same way at a very high level: There is a system state, then a transaction is executed and is effectively a state transition function, and then a new system state exists.

The purpose of putting batches of transactions into containers, or blocks, is for the purpose of ordering and time-stamping them. This is very important with permissionless networks, in which the data is authenticated via dynamic multiparty membership signatures where the validators can freely join and leave the network. Since Libra runs a permissioned system, it can use a more efficient consensus algorithm that doesn’t need to batch transactions because the transaction history is much less likely to be rewritten.

In the initial version of the Libra protocol, only a limited subset of Move’s functionality is available to users. While Move is used to define core system concepts, such as the Libra currency, users are unable to publish custom modules that declare their own resource types. This approach allows the Move language and toolchain to mature—informed by the experience in implementing the core system components—before being exposed to users. The approach also defers scalability challenges in transaction execution and data storage that are inherent to a general-purpose smart contract platform.

This sounds quite similar to the “open validator membership” plans referenced earlier. It seems as though Facebook has not yet solved any of the massive problems that Ethereum has been working on for years.

In order to manage demand for compute capacity, the Libra protocol charges transaction fees, denominated in Libra coins.

The Libra coins are actually the native unit of the protocol, much like ETH is the native unit of Ethereum. This leads to another question about the pseudonymous nature of Libra: Can you acquire coins without AML/KYC? If not, then it seems like you wouldn’t be able to use any of the system’s functionality anonymously. From reading about the Calibra wallet, it will require AML/KYC. So I wonder if there will eventually be on-ramps into the system that aren’t tightly controlled.

The system is designed to have low fees during normal operation, when sufficient capacity is available.

This is really vague and raises many questions: What are low fees? What is normal operation? What is sufficient capacity?

3. Executing Transactions

Many parts of the core logic of the blockchain are defined using Move, including the deduction of gas fees. To avoid circularity, the VM disables the metering of gas during the execution of these core components.

This sounds pretty dangerous, but the document’s authors note that the core components must be written defensively to prevent DoS attacks.

The key feature of Move is the ability to define custom resource types … the Move type system provides special safety guarantees for resources. A resource can never be copied, only moved. These guarantees are enforced statically by the Move VM. This allows us to represent Libra coins as a resource type in the Move language.

That clears up the earlier question of whether or not Libra coins are a native asset like ETH or BTC. I expect these coins are just the default or only resource type that will be allowed in the system when it launches, and other resources will come later.

Move’s stack-based bytecode has fewer instructions than a higher-level source language would. In addition, each instruction has simple semantics that can be expressed via an even smaller number of atomic steps. This reduces the specification footprint of the Libra protocol and makes it easier to spot implementation mistakes.

This sounds well-thought-out; hopefully it means the security of their scripting language will be better vetted than Ethereum’s was.

4. Authenticated Data Structures and Storage

The Libra protocol uses a single Merkle tree to provide an authenticated data structure for the ledger history … specifically, the ledger history uses the Merkle tree accumulator approach to form Merkle trees, which also provides efficient append operations.

Once again we see that “The Libra Blockchain” is not actually a blockchain. It’s really weird that this protocol seems to be very well designed, and yet they keep calling it a blockchain when the data structure of the ledger history is a set of signed ledger states. Validators are making commitments for each ledger state, and all of the historical ledger states are also committed to in Merkle trees, but I have yet to actually see any backlinked lists of data that form a chain—much less a chain of blocks.

The authenticator of an account is the hash of this serialized representation.

Note that this representation requires recomputing the authenticator over the full account after any modification to the account. The cost of this operation is O(n), where n is the length of the byte representation of the full account.

Hmmm, sounds like an opening to DoS attacks if there aren’t limitations placed on the amount of data stored by a given account.

We anticipate that as the system is used, eventually storage growth associated with accounts may become a problem. Just as gas encourages responsible use of computation resources, we expect that a similar rent-based mechanism may be needed for storage. We are assessing a wide range of approaches for a rent-based mechanism that best suits the ecosystem.

Another unsolved problem. Can’t wait for “The rent is too damn high!” memes.

The voting power must remain honest both during the epoch as well as for a period of time after the epoch in order to allow clients to synchronize to the new configuration. A client that is offline for longer than this period needs to resynchronize using some external source of truth to acquire a checkpoint that they trust.

Ouch. It’s not clear how long this “period of time” is, but if an epoch is less than a day, then I’d guess the specified “period of time” is too. It would seem that this consensus protocol is not robust enough that participants may leave and rejoin the network as they wish.

5. Byzantine Fault Tolerant Consensus

LibraBFT assumes that a set of 3f + 1 votes is distributed among a set of validators that may be honest, or Byzantine. LibraBFT remains safe, preventing attacks such as double spends and forks when at most f votes are controlled by Byzantine validators.

Much like PBFT this consensus algorithm can tolerate 33% of the validators being dishonest. The HotStuff modifications sound reasonable:

1. Resist non-determinism bugs by having validators sign the state of a block rather than just the sequence of transactions.
2. A pacemaker that emits explicit timeouts, and validators rely on a quorum of those to move to the next round—this should improve liveness.
3. Unpredictable leader election mechanism to limit DoS attacks against leader.
4. Aggregate signatures preserve the identity validators who sign quorum certificates to vote for block acceptance.

6. Networking

Each validator in the Libra protocol maintains a full membership view of the system and connects directly to any validator it needs to communicate with. A validator that cannot be connected to directly is assumed to fall within the quota of Byzantine faults tolerated by the system.

This is going to require a lot of work in order to scale the system past several hundred validators.

7. Libra Core Implementation

The security of the Libra Blockchain rests on the correct implementation of validators, Move programs, and the Move VM. Addressing these issues in Libra Core is a work in progress.

Pretty much sums up this section, though they wrote the implementation in Rust, which seems like a good start for performance and safety.

8. Performance

We anticipate the initial launch of Libra protocol to support 1,000 payment transactions per second with a 10-second finality time between a transaction being submitted and committed.

Since there will only be 100 or so validators, and they’re all directly connected to each other, 10-second block times sound doable.

Minimum node requirements:

• 40 Mbps Internet connection
• 1 commodity CPU
• 16 TB SSD

There were some references earlier to maintaining the ability for a validator to perform an initial sync from scratch, rather than trusting signed states from other validators. I expect that if Libra gets much use at all, it will quickly become highly impractical to perform such a sync, and as such, the node security model will be highly reliant upon trusting the validators.

9. Implementing Libra Ecosystem Policies with Move

The [Libra coin] reserve is the key mechanism for achieving value preservation. Through the reserve, each coin is fully backed with a set of stable and liquid assets. The Libra coin contract allows the association to mint new coins when demand increases and destroy them when the demand contracts. The association does not set a monetary policy. It can only mint and burn coins in response to demand from authorized resellers. Users do not need to worry about the association introducing inflation into the system or debasing the currency: For new coins to be minted, there must be a commensurate fiat deposit in the reserve.

Okay, but now we’re talking about events that are external to the network. As stated earlier in the white paper, the network is not able to execute scripts that use inputs of data that are external to the network’s state. Thus the modifiers “can” and “must” in the above snippet are surely referring to Libra Association policies or contractual obligations of which the network is unaware.

The consensus algorithm relies on the validator-set management Move module to maintain the current set of validators and manage the allocation of votes among the validators. Initially, the Libra Blockchain only grants votes to Founding Members.

Assuming that validators vote on changes to the validator set, it sounds like this results in a similar problem to what we see in proof of stake systems—long range attacks. If a sufficient threshold of founding members’ private keys are compromised, could an attacker write a new ledger history from genesis? If so, would other nodes accept it? It’s unclear if the consensus protocol allows for rewriting old states or if it’s append-only.

We plan to gradually transition to a proof-of-stake.

If they can solve the unsolved problems.

Outstanding Questions

How does governance work?

We can see here that the Libra Association is a council of members and a 2/3 supermajority is required to make changes. They are the only ones allowed to mint or destroy Libra coins, but they can presumably make any change they want if there is sufficient agreement.

Is AML/KYC required?

Apparently it’s not required at the protocol level, but the Calibra wallet states that all users will be verified via government-issued ID. It also sounds like the Calibra wallet will be the only available wallet for a while at least, so it’s unclear if developers and users can run apps on the Libra network that don’t abide by the same standards as Calibra.

What are low fees? What is normal operation? What is sufficient capacity?

The Calibra Wallet FAQ promises low fees, but it seems like this may be in conflict with the operation of the underlying protocol at times of high load.

Transaction fees will be low-cost and transparent, especially if you’re sending money internationally. Calibra will cut fees to help people keep more of their money.

Will Libra really be open to developers?

According to the plan to move toward permissionless consensus:

The Libra Blockchain will be open to everyone—any consumer, developer, or business can use the Libra network, build products on top of it, and add value through their services. Open access ensures low barriers to entry and innovation and encourages healthy competition that benefits consumers.

I’m skeptical that developers will be able to run any technically valid app they can dream of on this platform. Nothing I’ve read leads me to believe that this system will be resistant to censorship, but only time will tell!