In this paper, 26 pages of technical documents about Facebook Libra coin (and more) platform protocols are studied in depth, and their contents are decomposed and explained. At the same time, we sincerely admire the 53 authors!
The following are the specific contents of the analysis:
(The English version is the original version of the agreement, and the Chinese translation is the interpretation of the agreement.)
The Libra protocol allows a set of replicas—referred to as
validators—from different authorities to jointly maintain a database
of programmable resources.
In other words, the system needs to be controlled by a group of authorities in a top-down manner. Note, however, that the database is designed to maintain “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 terms such as “resources” makes me suspect that this is more than just a stable currency.
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, that’s interesting. The use of a specialized intelligent contract language can lead to many problems, such as the richness of the language and the robustness of the system to antagonistic contracts. There are also questions about developer friendliness and how Libra protects smart contract developers from being affected.
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
It’s still a question of developer friendliness and how Libra protects smart contract developers from being affected.
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 general encrypted asset agreement. The first asset will be a stable currency.
Over time, membership eligibility will shift to become completely open
and based only on the member’s holdings of Libra.
It sounds like a certificate of equity. Obviously, the plan is to open membership in five years and hope that they will be able to find proof of shares at that time, although I expect that they will have the same problems as Ethereum.
The association has published reports outlining … the roadmap for the
shift toward a permissionless system.
I’m sure this will be the first time that distributed networks have changed from licensing to non-licensing. Perhaps the entire network can be converted into equity certificates, but in order to stabilize the currency/basket, some entities must remain open to the traditional financial system. This will be the focus of long-term centralized control through 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
It sounds like Practical Byzantine Fault Tolerance, a well-understood 20-year-old algorithm that has evolved, although they may have made some adjustments. We learned in Section 5 of the White Paper that it is called LibraBFT, 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 noteworthy, mainly because it means that new validators should be able to join the network and synchronize quickly without tracing the entire history of the block chain, provided they trust existing validators.
This account model is possible because Facebook is unlikely to focus on privacy, and it is really interested in smart contracts.
2. Logical Data Model
The Libra protocol uses an account-based data model to encode the
From a data structure perspective, Libra is more like Ethereum or Ripple than Bitcoin. The UTXO model has both advantages and disadvantages – because of the simplicity of output-based historical records, it has better privacy and more robust transaction history – but it may be more difficult to handle complex intelligent contracts. So the account model makes sense, because Facebook is unlikely to focus on privacy, even though it 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.
That sounds amazing, but I wonder if Libra coin is the same. It will be interesting for developers who want to develop applications that protect privacy better to observe the openness of the system.
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 that you can generate an address that can allocate any number of assets 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 to protect the system from resource exhaustion attacks, probably by utilizing resource-cost systems similar to Ethereum.
There is no concept of a block of transactions in the ledger history.
Interesting. There is no actual block chain data structure in Libra protocol – blocks are more like a virtual logical structure, which is used by verifiers to coordinate snapshots of system status confirmation. In retrospect, the first sentence of this section now has more meaning:
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 encrypted asset network I am familiar with works at a very high level in the same way: first there is a system state, then a transaction is executed, which is actually a state transition function, and then a new system state appears.
The purpose of placing batch transactions in containers or blocks is to sort and time stamp them. This is very important for an unlicensed network, where data is authenticated by dynamic multi-member signatures, and verifiers are free to join and leave the network. Because Libra runs a licensed system, it can use a more efficient consensus algorithm without requiring batch transactions because 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 very similar to the “open validator membership” program mentioned earlier. It seems that Facebook hasn’t solved any of the major problems that Ethereum has been trying to solve for years.
In order to manage demand for compute capacity, the Libra protocol
charges transaction fees, denominated in Libra coins.
Libra coins is actually the native unit of the protocol, just as ETH is the native unit of Ethereum. This raises another question about the anonymity of Libra: Can you get money without AML / KYC? If not, then you don’t seem to be able to use any of the system’s functions anonymously. Check Calibra Wallet, it will need AML / KYC. So I want to know if there will eventually be some ways to get into the system that are not strictly controlled.
The system is designed to have low fees during normal operation, when
sufficient capacity is available.
This is really ambiguous and raises a lot of questions: What is a low fee? What is normal operation? What is sufficient capacity?
3. Execution of 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
This sounds dangerous, but the author of the document points out that 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.
This clarifies the previous question: Is Libra coins a local asset like ETH or BTC? I hope that these currencies are only the default or only permissible resource types when the system starts. Other resources will be provided in the future.
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 thoughtful; hopefully it means that their scripting language will be more secure than Ethereum.
We see that the “Libra block chain” is not actually a block chain.
4. Verified data structure 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 block chain” is not actually a block chain. This protocol seems to be well designed, but strangely, when the data structure of account history is a set of signed account states, they still call it block chains. Verifiers are making promises for each account state, and all historical account states are also promised in the Merkle tree, but I haven’t really seen any list of backlinked data forming chains — let alone block chains.
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.
Well, without limiting the amount of data stored in a given account, it sounds like the beginning of a DoS attack.
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
Another unresolved problem. I can’t wait to say, “The rent is too high!”
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.
Oh. It’s not clear how long this “time period” is, but if an epoch is less than a day, I guess the same is true for the designated “time period”. It seems that this consensus protocol is not strong enough and participants may leave and rejoin the network at will.
5. Byzantine Fault Tolerance 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.
Like PBFT, this consistency algorithm can tolerate 33% of verifiers being dishonest. The modification of HotStuff sounds reasonable:
Non-deterministic errors are resisted by having the verifier sign the state of the block, not just the transaction sequence.
A pacemaker that sends a clear timeout signal relies on the arbitration set of these timeout signals to enter the next round – which should improve its activity.
An unpredictable leadership election mechanism to limit DoS attacks against leaders.
Aggregate signatures to save authenticators who sign arbitration set certificates to vote for blocks.
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
This will take a lot of work to extend the system to hundreds of validators.
- Libra Core Implementation Contents
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.
This section has been basically summarized, although they have written implementations in Rust, which seems to be a good start for performance and security.
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 are only about 100 validators, and they are all directly connected to each other, 10 seconds of block time sounds feasible.
Minimum node requirements:
- 40 Mbps Network Connection
- One Commodity CPU
- 16 TB SSD
There are some references on the ability to maintain the initial synchronization of the verifier from scratch, rather than trusting the signature status of other verifiers. I anticipate that if Libra is fully utilized, such synchronization will soon become highly impractical, and therefore the node security model will be highly dependent on trust verifiers.
9. Implementing Libra Ecosystem Strategy 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
Okay, but now we’re talking about events outside the network. As mentioned earlier in the white paper, the network cannot execute scripts that use external data input from the network state. Therefore, the modifiers “can” and “must” in the above code snippet definitely refer to Libra Association policies or contractual obligations that the network does not know.
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 the verifier votes for changes in the verifier set, it sounds like a similar problem we see in the equity certification system: remote attacks. If the critical threshold of the founder’s key is compromised, can an attacker write a new account history from the source? If so, will other nodes accept it? It is not clear whether the consensus protocol allows rewriting of the old state or only additional state.
We plan to gradually transition to a proof-of-stake.
If they can solve the unresolved problems.
How to manage?
We can see that Libra Association is a committee of members that requires an absolute majority of two-thirds to make a change decision. They are the only people who are qualified to cast or destroy Libra coin, but if there is enough consensus, they can make any changes they want.
Do you need AML / KYC?
Obviously, it is not required at the protocol level, but Calibra Wallet states that all users will be authenticated by an ID issued by the government. It sounds like Calibra wallet will be the only wallet available for some time, so it’s not clear whether developers and users can run applications that do not comply with the same standards as Calibra on the Libra network.
What is low fee? What is normal operation? What is sufficient capacity?
CALIBRA wallet FAQ promises low fees, but this seems to conflict with the operation of the underlying protocol at high loads.
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.
Is Libra really open to developers?
According to the plan to achieve the unauthorized 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
I doubt whether developers can run any technically effective applications they imagine on this platform. I didn’t read anything that convinced me that the system would resist censorship, but only time would tell us the answer!
Click on “Libra Blockchain” to see the original text
Sweep code to pay attention to the Jingdong cloud developer community, every day there are wonderful industry information oh!