Libra is a permissioned blockchain proposed by Facebook. Libra was formally announced on June 18, 2019.
Properties, Jargon, Definitions
- Born in ~2019
- Currently the project is a prototype
- Quick Technical Whitepaper
- Microlibra = the smallest amount of LBR, i.e. 10^-6 (i.e. same concept as a Satoshi in Bitcoin)
- 1 microlibra = 0.000001 LBR (10^−6)
- Ledger version (there are no blocks, only transactions)
- Rust is used for implementing the server
- RocksDB is used as its physical storage engine
- No Fixed Supply
- 10 sec for transaction finality
- Throughput up to 1000 transactions per second (1000 tx/s vs. 50k tx/s of Visa)
- Trusted set of validators
- Stablecoin
- Consensus algorithm: LibraBFT (a variant of HotStuff and BFT)
- Account-based data model
- Move (smart contract language)
Introduction
Libra is built on a secure, scalable, and reliable blockchain. It is backed by a reserve of assets designed to give it intrinsic value and is governed by the independent Libra Association tasked with evolving the ecosystem. The Libra Blockchain is a cryptographically authenticated distributed database, and it is based on the Libra protocol. At the heart of the Libra protocol are two fundamental concepts — transactions and states. At any point in time, the blockchain has a “state.” The state (or ledger state) represents the current snapshot of data on the chain. Executing a transaction changes the state of the blockchain. The ledger state, or global state of the Libra Blockchain, is comprised of the state of all accounts in the blockchain.
The Libra Blockchain is a decentralized, programmable database designed to support a low volatility cryptocurrency that will have the ability to serve as an efficient medium of exchange for billions of people around the world. The Libra protocol, which implements the Libra Blockchain aims to create a financial infrastructure that can foster innovation, lower barriers to entry, and improve access to financial services. The Libra protocol allows a set of replicas — referred to as validators — from different authorities to jointly maintain a database of programmable resources. 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. Validators process transactions and interact with each other to reach consensus on the state of the database. Transactions are based on predefined and, in future versions, user-defined smart contracts in a new programming language called Move.
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. At each version i, the database contains a tuple (Ti,Oi, Si) representing the transaction (Ti), transaction output (Oi), and ledger state (Si). Every executed transaction in the system is deterministic. The Libra protocol uses the Move language to implement the deterministic execution function.
A version is also called “height” in blockchain literature. The Libra Blockchain doesn’t have an explicit notion of a block — it only uses blocks for batching and executing transactions. A transaction at height 0 is the first transaction (genesis transaction), and a transaction at height 100 is the 101th transaction in the transaction store.
Account
The Libra protocol uses an account-based data model. A Libra account is a container for Move modules and Move resources. It is identified by an account address. This essentially means that the state of each account is comprised of both code and data:
- Move modules contain code (type and procedure declarations), but they do not contain data. The procedures of a module encode the rules for updating the global state of the blockchain.
- Move resources contain data but no code. Every resource value has a type that is declared in a module published in the distributed database of the blockchain.
An account may contain an arbitrary number of Move resources and Move modules.
Address
The address of a Libra account is a 256-bit value. Users can claim addresses using digital signatures. The account address is a cryptographic hash of a user’s public verification key. There is no limit on the number of addresses a Libra user can claim. Account is treated as an ordered map of access paths to byte array values.
Transaction
Clients of the Libra Blockchain update the ledger state by submitting transactions. At a high level, a transaction consists of a transaction script (written in Move bytecode) and arguments to the transaction script (e.g. a recipient account address or the number of Libra to send).
Transaction output
Executing a transaction Ti produces a new ledger state Si as well as the execution status code, gas usage, and event list (aggregated in output Oi). The event list is a set of side effects produced by executing the transaction. Move code can trigger an event emission through an event structure. Each event is associated with a unique key, which identifies the structure through which the event was emitted, and a payload, which provides detailed information about the event. Transaction execution does not have external effects.
When submitting a transaction the user pays a transaction fee. The only intention of this fee is to reduce demand when the system is under a higher load than it was provisioned for (e.g. due to a denial-of-service attack). Fee is determined by two factors: gas price and gas cost.
The transaction structure is a signed message containing the following data:
- Sender address: The account address of the transaction sender. The VM reads the sequence number, authentication key, and balance from the LibraAccount.T resource stored under this address.
- Sender public key: The public key that corresponds to the private key used to sign the transaction. The hash of this public key must match the authentication key stored under the sender’s LibraAccount.T resource.
- Program: A Move bytecode transaction script to execute, an optional list of inputs to the script, and an optional list of Move bytecode modules to publish.
- Gas price: The number of Libra coins that the sender is willing to pay per unit of gas in order to execute this transaction.
- Maximum gas amount: The maximum number of gas units that the transaction is allowed to consume before halting.
- Sequence number: An unsigned integer that must be equal to the sequence number from the sender’s LibraAccount.T resource. After this transaction executes, the sequence number is incremented by one. Since only one transaction can be committed for a given sequence number, transactions cannot be replayed.
Once a transaction hits the VM components, it is validated against six steps.
- Check signature.
- Run prologue. The prologue authenticates the transaction sender, ensures that the sender has sufficient Libra coin to pay for the maximum number of gas units specified in the transaction, and checks that the transaction is not a replay of a previous transaction.
- Verify transaction script and modules.
- Publish modules.
- Run transaction script.
- Run epilogue. Finally, the VM runs the transaction epilogue to charge the user for the gas used and increment the sender’s account sequence number.
Ledger history
The purpose of the ledger history is to keep a record of how the latest ledger state was computed. There is no concept of a block of transactions in the ledger history. However, in the logical data model, the transactions occur in sequence without distinction as to which block contained each transaction.
All validators must agree on the initial, or genesis, ledger state of the system. The initial state of the system is represented as an empty state. The genesis state is then created through a special transaction T0 that defines specific modules and resources to be created, rather than going through the normal transaction process. Clients and validators are configured to accept only ledger histories beginning with a specific T0.
Move
“Move” is a new programming language for implementing custom transaction logic and “smart contracts” on the Libra Blockchain. Because of Libra’s goal to serve billions of people one day, Move is designed with safety and security as the highest priorities. The main Move Design Goals are: first-class assets, flexibility, safety, and verifiability. A robust and elegant approach to programming with assets requires a representation that preserves these characteristics.
Move has three important roles in the system:
- To enable flexible transactions via transaction scripts.
- To allow user-defined code and datatypes, including “smart contracts” via modules.
- To support configuration and extensibility of the Libra protocol.
The key feature of Move is the ability to define custom resource types with semantics inspired by linear logic: a resource can never be copied or implicitly discarded, only moved between program storage locations. These safety guarantees are enforced statically by Move’s type system.
Furthermore, critical operations on a resource type T may only be performed inside the module that defines T.
Move adds flexibility to Libra via transaction scripts. Each Libra transaction includes a transaction script that is effectively the main procedure of the transaction.
Ideally, we would check every safety property of Move programs via on-chain bytecode analysis or runtime checks. Unfortunately, this is not feasible. We must carefully weigh the importance and generality of a safety guarantee against the computational cost and added protocol complexity of enforcing the guarantee with on-chain verification, e.g. the type system ensures that resources can never be duplicated, reused, or lost.
Move is static verification friendly, i.e.:
- No dynamic dispatch. The target of each call site can be statically determined. This makes it easy for verification tools to reason precisely about the effects of a procedure call without performing a complex call graph construction analysis.
- Limited mutability. Every mutation to a Move value occurs through a reference. References are temporary values that must be created and destroyed within the confines of a single transaction script. Move’s bytecode verifier uses a “borrow checking” scheme similar to Rust to ensure that at most one mutable reference to a value exists at any point in time. In addition, the language ensures that global storage is always a tree instead of an arbitrary graph. This allows verification tools to modularize reasoning about the effects of a write operation.
- Modularity. Move modules enforce data abstraction and localize critical operations on resources. The encapsulation enabled by a module combined with the protections enforced by the Move type system ensures that the properties established for a module’s types cannot be violated by code outside the module. We expect this design to enable exhaustive functional verification of important module invariants by looking at a module in isolation without considering its clients.
Move, following Rust and C++, implements move semantics. Each read of a Move variable x must specify whether the usage moves x’s value out of the variable (rendering x unavailable) or copies the value (leaving x available for continued use). Unrestricted values like u64 and address can be both copied and moved. But resource values can only be moved. Attempting to duplicate a resource value (e.g., using copy(coin)) will cause an error at bytecode verification time.
Resource safety prohibits other modules from copying, destroying, or double-moving resources.
The goal of Move is to enable programmers to define global blockchain state and securely implement operations for updating global state.
Both the future Move source language and the Move IR are compiled into Move bytecode, which is the format used by the Libra protocol.
The protocol avoids trusting the compiler by enforcing all of Move’s safety guarantees via bytecode verification: type-safety, reference-safety, and resource-safety.
Move modules are related to, but not the same as, the concept of “smart contracts” in Ethereum and other blockchain platforms. An Ethereum smart contract contains both code and data published in the ledger state. In Libra, modules contain code values, and resources contain data values.
There are two properties of physical assets that are difficult to encode in digital assets:
- Scarcity. The supply of assets in the system should be controlled. Duplicating existing assets should be prohibited, and creating new assets should be a privileged operation.
- Access control. A participant in the system should be able to protect her assets with access control policies
Significant parts of the Libra protocol in Move, including Libra coin, transaction processing, and validator management are implemented in Move.
Merkle Tree
All of the data in the Libra Blockchain is stored in a single-versioned distributed database. The storage is used to persist agreed upon blocks of transactions and their execution results. The blockchain is represented as an ever-growing Merkle tree of transactions. A “leaf” is appended to the tree for each transaction executed on the blockchain. Specifically, the ledger history uses the Merkle tree accumulator approach to form Merkle trees, which also provides efficient append operations.
Consensus
Validator nodes are entities in the Libra ecosystem that collectively decide which transactions will be added to the Libra Blockchain. The consensus algorithm used is LibraBFT, a robust and efficient state machine replication system designed for the Libra Blockchain. LibraBFT is based on HotStuff, a recent protocol that leverages several decades of scientific advances in Byzantine fault tolerance (BFT) and achieves the strong scalability and security properties required by internet settings. LibraBFT further refines the HotStuff protocol to introduce explicit liveness mechanisms and provides a concrete latency analysis. As long as the consensus protocol ensures a total order among transactions and the state transition scheme is deterministic, the components can interact in harmony.
LibraBFT provides the following key properties that are crucial for decentralizing trust:
- Safety: LibraBFT maintains consistency among honest validators, even if up to one-third of the validators are corrupt.
- Asynchrony: Consistency is guaranteed even in cases of network asynchrony (i.e., during periods of unbounded communication delays or network disruptions). This reflects our belief that building internet-scale consensus protocol whose safety relies on synchrony would be inherently both complex and vulnerable to Denial-of-Service (DoS) attacks on the network.
- Finality: LibraBFT supports a notion of finality, whereby a transaction becomes irreversibly committed. It provides concise commitments that authenticate the result of ledger queries to an end user.
- Linearity and Responsiveness: LibraBFT has two desirable properties that BFT consensus protocols preceding HotStuff were not able to simultaneously support — linearity and responsiveness. These two technical concepts are linked with the notion of leaders, a key approach for driving progress against partial synchrony. Informally, linearity guarantees that driving transaction commits incurs only linear communication (this is optimal) even when leaders rotate; responsiveness means that the leader has no built-in delay steps and advances as soon as it collects responses from validators.
- Simplicity and Modularity: The core logic of LibraBFT allows simple and robust implementation, paralleling that of public blockchains based on Nakamoto consensus. Notably, the protocol is organized around a single communication phase and allows a concise safety argument.
- Sustainability: Current public blockchains, where trust is based on computational power, have been reported to consume vast amounts of energy and may be subject to centralization. LibraBFT is designed as a proof-of-stake system, where participation privileges are granted to known members based on their financial involvement. LibraBFT can support economic incentives to reward good behaviors and/or punish wrongdoings from stakeholders. Computational costs in LibraBFT consist primarily of cryptographic signatures, a standard concept with efficient implementations.
The safety of the solution introduced by Lamport et al. relied on synchrony, a dependency that practical systems wish to avoid both due to complexity and because it exposes the system to DoS attacks on safety. LibraBFT leverages HotStuff and possesses many of the benefits achieved in four decades of works presented above.
State Machine Replication (SMR) protocols are meant to provide an abstract state machine distributed over the network and replicated between many processes, also called nodes. Historically, fault-tolerant protocols were meant to address common failures, such as crashes. In the context of a blockchain, the SMR consensus protocol is used to limit the power of individual nodes in the system.
Leaders, Rounds, Blocks, Votes
Validators receive transactions from clients and share them with each other through a shared mempool protocol. LibraBFT is a consensus protocol that progresses in rounds, where in each round a leader is chosen amongst the validators. LibraBFT belongs to the family of leader-based consensus protocols. In leader-based protocols, nodes make progress in rounds, each round having a designated node called a leader. Leaders are responsible for proposing new commands and obtaining signatures, called votes, from other nodes on their proposals. LibraBFT follows the chained variant of HotStuff, where a round is a communication phase with a single designated leader, and leader proposals are organized into a chain of blocks using cryptographic hashes.
The current consensus protocol would initially support at least 100 validators and would be able to evolve over time to support 500–1,000 validators. The initial launch of Libra protocol should support 1,000 payment transactions per second with a 10-second finality time between a transaction being submitted and committed.
The network layer is designed to be general-purpose and draws inspiration from the libp2p project. It currently provides two primary interfaces: (1) Remote Procedure Calls (RPC) and (2) DirectSend,which implements fire-and-forget-style message delivery to a single receiver.
The inter-validator network is implemented as a peer-to-peer system using Multiaddr scheme for peer addressing, TCP for reliable transport, Noise for authentication and full end-to-end encryption, Yamux for multiplexing substreams over a single connection, and push-style gossip for peer discovery. Each new substream is assigned a protocol supported by both the sender and the receiver. Each RPC and DirectSend type corresponds to one such protocol.
The Libra team has select elements of the protocol with parallelization and sharding in mind. The sparse Merkle tree approach to computing authenticators allows sharding the database across multiple machines (which increases capacity) or processing updates in parallel (which increases throughput).
The aspiration is to make the Libra Blockchain fully permissionless. To do this, the team plans to gradually transition to a proof-of-stake.
Validator Node
Clients of the Libra Blockchain create transactions and submit them to a validator node. A validator node runs a consensus protocol (together with other validator nodes), executes the transactions, and stores the transactions and the execution results in the blockchain. Validator nodes decide which transactions will be added to the blockchain and in which order.
The logical components of a validator node are: Admission Control, Mempool, Consensus, Execution, Virtual Machine and Storage. The storage module uses RocksDB as its physical storage engine. The Admission Control component is the entrance for a client to communicate with a node.
System Architecture
At the higher level we can describe the system architecture as depicted in the below image (i.e. Figure 9).
Networking describes the protocol that enables validators to communicate with each other securely, as required for consensus. The network component is implemented in the Actor programming model — i.e., it uses message-passing to communicate between different subcomponents running as independent “tasks.” The tokio framework is used as the task runtime.
Libra Association
The role of the association will be to:
- Manage the development of the technology. While the open-source structure helps drive day-to-day technical decisions regarding both Libra Core as well as the Libra protocol, the Libra Association Council provides a framework for the governance of the project. The council serves as a check to ensure that the decisions made by the open-source community are aligned with the Libra ecosystem as a whole.
- Define the open-source governance process. The open-source decision-making process will evolve as the community around the project grows.
- Define how changes are proposed, discussed, and accepted. In the early stage, rapid development is expected with a transition to a more formal process as the technology matures.
Libra is designed to be a currency where any user will know that the value of a Libra today will be close to its value tomorrow and in the future. The 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.
Initially, the Libra Blockchain only grants votes to Founding Members, entities that: (1) meet a set of predefined Founding Member eligibility criteria and (2) commit a certain amount into the project. These rules help to ensure the security requirements of having a safe and live validator set. Using the Founding Member eligibility criteria ensures that the Founding Members are organizations with established reputations, making it unlikely that they would act maliciously, and suggesting that they will apply diligence in defending their validator against outside attacks.
Conclusion
There is a lot more to say about the internals of the protocol. Currently, the project is just a prototype, the current design may change over time, the implementation even harder. In a few words, the Libra Protocol is a distributed database that uses the Merkle Tree data structure for storing the state, by submitting transactions you can change the state, transactions semantics can be customized by using the Move language, the state consistency is maintained among the participants by using a BFT consensus algorithm.
Disclaimer. The images and text of this article are an ordered and slightly modified collage of the official academic papers and developer documentation.
