Jameson Lopp's Thoughts on "Libra Blockchain"

Nothing I have read has led me to believe that this system will resist the censorship system.

Summary

"The Libra protocol allows a set of replicas (called validators) from different organizations to jointly maintain a database of programmable resources."

The system will be controlled by a series of authorities in a top-down manner. However, please note that this database is for "programmable resources" and not digital currency.

"These resources are owned by different user accounts that are public key cryptographically authenticated and adhere to the custom rules specified by the developers of those resources."

Using generic words such as "resources" makes me suspect that this is more than just a stable currency.

"The transaction is based on a predetermined contract. In a future release, the user will use a new programming language called Move to define the smart contract. We use Move to define the core mechanisms of the blockchain, such as token and validator membership. ""

Using a custom-built smart contract language can lead to many problems, such as how rich the features of the language are and how powerful the system is for contracts. There are some issues with how much developer is friendly and how much Libra can protect smart contract developers from getting into trouble.

“These core mechanisms create a unique governance mechanism based on the stability and reputation of existing institutions in the early days, but will transition to fully open systems over time.”

It sounds like the Libra Association will be an alliance that can develop itself through voting and some kind of reputation.

1 Introduction

“This ecosystem will provide a new global currency – the Libra currency – that will be fully supported by a series of bank deposits and high-quality central bank government bonds.”

Libra is a universal encryption asset protocol whose first asset will be a stable currency.

"Over time, Libra's membership will be fully open and based solely on Libra's membership holdings."

It sounds a lot like POS. Obviously, their plan is to open the membership after 5 years, and hope they can find the POS at that time… I expect they will encounter the same problems as Ethereum!

“The report published by the association outlines the road map for the transition to a non-permitted system.”

I am pretty sure this will be the first world of a distributed network transition from licensing to no licensing . Maybe the network as a whole can switch to PoS, but in order to maintain a stable peg / basket, some entities must maintain a bridge with the traditional financial system. This will be a point of continuous centralized control through the Libra Association.

“The verifier drives the process of accepting transactions in turn. When the validator acts as the leader, it proposes transactions to other validators, including transactions submitted directly to it by the client and transactions submitted indirectly through other validators. All validators execute Transaction and form an authenticated data structure containing the new ledger history. As part of the consensus agreement, the validator votes on the validator of the data structure."

This sounds like a Practical Byzantine Fault Tolerance – an old algorithm that has been around for 20 years. But they may have made some adjustments. We learned in Section 5 of the white paper that it is called LibraBFT and is a variant of the HotStuff consensus protocol.

"As part of submitting transaction Ti on version i, the consensus protocol outputs the full state signature of the database (including its entire history) on version i to authenticate the response to the query from the client."

This is mainly because it means that the new validator should be able to join the network and synchronize quickly without having to replay the entire history of the blockchain, as long as they trust the existing validator.

2. Logical data model

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

From a data structure perspective, Libra is more like Ethereum or Ripple than Bitcoin. Due to the simplicity of the output-based history, the UTXO model has its advantages and disadvantages, such as better privacy and a more robust transaction history. But dealing with complex smart contracts can be even more difficult. Therefore, the account model makes sense, Facebook is less likely to care about privacy, and it is really interested in smart contracts.

“Libra's protocol does not link accounts to real identities. Users can create multiple accounts by generating multiple keys. Accounts controlled by the same user have no intrinsic links to each other. The program uses bitcoin and Ethereum, for example, provides users with pseudonyms."

At the same time, I also want to know if Libra's stable currency assets are also the same… Observing this system is very interesting for developers who want to build more privacy-protected applications.

"Each resource has a type declared by the module. The resource type is a nominal type consisting of the name of the type and the name and address of the resource declaration module."

It sounds like people can generate an address, as long as each asset has a unique name that can be assigned to any number of assets.

"Executing the transaction Ti will generate a new ledger status Si and execute the status code, gas usage and event list."

So now we know how to protect the system from resource exhaustion attacks through a resource cost system similar to Ethereum.

“There is actually no concept of trading in the history of ledgers.”

Interestingly, there is no actual blockchain data structure in the Libra protocol—the block is more of a virtual/logical structure that coordinates the confirmed snapshot of the system state. Now the first sentence of this section makes more sense:

"All data in the Libra blockchain is stored in a single version-controlled database. The version number is an unsigned 64-bit integer that corresponds to the number of transactions executed by the system."

Every network of cryptographic assets that I am familiar with works in the same way at a very high level: there is a system state, then the transaction is executed, it is actually a state transition function, and then there is a new system state.

The purpose of placing a batch transaction into a container (block) is to order/time stamp. This is very important for unlicensed networks that validate data through dynamic multi-party signatures (verifiers are free to join and leave the network). Because Libra runs a licensed system, it can use a more efficient consensus algorithm without the need for batch transactions because transaction history is less likely to be overwritten.

"In the initial release of the Libra protocol, only a small portion of the Move functionality was available to users. Although Move is used to define core system concepts, such as Libra currency, users cannot publish custom modules that declare their own resource types. Prior to its disclosure, this approach allowed the mobile language and toolchain to mature—as determined by the experience of implementing core system components. This approach also avoids scalability challenges in transaction execution and data storage, while transaction execution And data storage is inherent in the general intelligence contract platform."

This sounds very similar to the "Open Validator Membership" program mentioned earlier. It seems that Facebook has not solved any big problem that Ethereum has been working on for years.

“In order to manage the demand for computing power, the Libra Agreement charges transaction fees denominated in Libra currency.”

Interestingly, it sounds like Libra's currency is actually the original unit of the agreement, just like the ETH's native unit. This has led to more questions about the nature of Libra's pseudonym; can you get coins without AML/KYC? If not, then you can't seem to be able to use any of the system's features anonymously. By reading Calibra wallet, it will need AML/KYC, so I want to know if there will be a system that is not strictly controlled.

“The system is designed to be less expensive during normal operation when there is sufficient capacity.”

This is really vague and raises a lot of questions – what is low fees? What is normal operation? What is enough capacity?

3. Execute the transaction

"Many parts of the core logic of the blockchain are defined with Move, including the deduction of the gas fee. To avoid looping, the VM disables the metering when executing these core components."

This sounds quite dangerous, but the authors point out that core components must be written in a defensive manner to prevent DoS attacks.

"The key feature of Move is the ability to define custom resource types. The Move type system provides special security for resources. Resources can never be copied and can only be moved. These guarantees are statically enforced by the Move VM. This allows us to move Language represents Libra currency as a resource type"

This clarifies the previous question: whether Libra coins are a natural asset like ETH or BTC. I hope these coins are just the default / unique resource type.

"Move's stack-based bytecode has fewer instructions than the high-level source code. In addition, each instruction has a simple semantics that can be expressed in fewer atomic steps. This reduces the specification footprint of the Libra protocol, and It's easier to find implementation errors."

This sounds well thought out; hopefully this means that the security of their scripting language will be better reviewed than Ethereum.

4. Authenticated data structure and storage

"The Libra protocol uses a Merkle tree to provide a validated data structure for the ledger history. Specifically, the ledger history uses the Merkle tree accumulator method to form the Merkle tree, which also provides efficient additional operations."

Once again we see that the "Libra blockchain" is actually not a blockchain. This protocol seems to be well designed, but when the data structure of the ledger history is a set of signed ledger states, they always call it a blockchain, which is really weird. The verifier is making a commitment for each ledger status, and all historical ledger status is also promised in the Merkle tree, but I haven't seen any reversed list of data forming the chain, let alone forming a block. .

"The account's validator is the hash of this serialized representation. Note that this representation requires recalculating the authenticator for the entire account after any modifications to the account. The cost of this operation is O(n), where n Is the byte representation length of the full account."

If there is no limit to the amount of data stored in a given account, it sounds like a DoS vector.

"We expect that with the use of the system, the ultimate storage-related storage growth may become an issue. Just as Gas encourages responsible use. For computing resources, we hope that a similar rent-based storage mechanism may be needed. We are working on Evaluate a range of methods that are best suited to ecosystem-based rent-based mechanisms."

Another unresolved issue. I can’t wait to say “the rent is too damn high!!”

"In order to allow the client to synchronize to the new configuration, the voting rights during the epoch period and after the epoch must be kept honest. Clients who have offline time beyond this period need to use some external data source to resynchronize to get their trust check. point."

It is not clear how long this "this period" is, but if an epoch is less than a day, I guess it will not be one day. It seems that this consensus agreement is not strong enough, and participants may leave and rejoin the network they want.

5.LibraBFT

“LibraBFT assumes that a set of 3f + 1 votes is distributed across a set of validators, which may be honest or Byzantine. LibraBFT is still safe, when up to f votes are controlled by Byzantine verifiers, It prevents attacks such as double overhead and forks."

Like PBFT, this consistent algorithm can tolerate 33% of the validators being dishonest. The HotStuff modification sounds well thought out:

1. Respond to inconclusive errors by having the verifier sign the state of the block (not just the sequence of transactions).

2. A pacemaker that issues a clear timeout signal, the verifier relies on arbitration to enter the next round – this should increase activity.

3. Unpredictable leadership election mechanisms to limit DoS attack leaders.

4. The aggregate signature retains the authenticator that signed the arbitration certificate to vote on the block acceptance.

6. Network

"Each validator in the Libra protocol maintains a complete view of the system and is directly connected to any validator that needs to communicate with it. A validator that cannot be directly connected is considered to be a Byzantine fault that the system can tolerate. range."

This will require a lot of work to extend the system to more than a hundred validators.

7, Libra core implementation

"The security of the Libra blockchain depends on the correct implementation of the validator, Move program, and Move VM. Solving these problems with the Libra core is an ongoing effort."

Although they wrote the implementation in Rust, this seems to be a good start for performance and security, but this part of the content has been basically summarized.

8, performance

“We look forward to the first launch of the Libra protocol to support 1000 payment calculations. 1000 payment transactions per second, and a final time of 10 seconds between the submitted and submitted transactions. Since there are only about 100 validators and they are Directly connected to each other, so the 10-second "block time" sounds feasible."

Minimum node requirements:

40 Mbps Internet connection

1 commodity CPU

16 TB SSD

Previously, some references required maintaining the ability of the verifier to perform initial synchronization from the beginning, rather than trusting the signature state from other validators. I anticipate that if Libra is fully utilized, then performing such synchronization will quickly become very impractical, so the node security model will be highly dependent on the trust validator.

9. Implementing Libra Ecosystem Policy with Move

“Libra currency reserves are a key mechanism for achieving value preservation. Each reserve has a stable set of liquid assets backed by reserves. The Libra currency contract allows the association to mint new coins as demand increases and destroy them when demand contracts are made. There is no monetary policy. It can only be minted and destroyed according to the requirements of authorized dealers. Users do not have to worry that this association will lead to inflation or currency depreciation: to cast new coins, there must be a corresponding statutory deposit reserve."

But now we are talking about events outside the network. As mentioned earlier in the white paper, the network cannot execute scripts that use network state external data input. Therefore, the modifiers "can" and "must" in the above paragraphs must refer to Libra's association policy or contractual obligations, and Libra's social network does not know this.

"The consistency algorithm relies on the validator set management Move module to maintain the current set of validators and manage the vote distribution between the validators. Initially, the Libra blockchain only awarded votes to the founding members."

Suppose the validator votes on changes to the validator set, which sounds like a problem we see in the POS system – a remote attack. If the threshold of the private key of the founding member is compromised, can the attacker write a new ledger history from the Genesis block? If so, will other nodes accept it? It is not clear whether the consensus agreement allows rewriting the old Status or just an additional status.

"We plan to gradually transition to POS"

If they can solve the unresolved problem.

Outstanding issues:

How does governance work?

We can see that the Libra Association is a committee of members that requires two-thirds of the majority to make a change. They are the only ones who are allowed to cast or destroy Libra coins, but if there is enough consensus, they can make whatever changes they want.

Do you need AML / KYC?

Obviously not at the protocol level, but Calibra Wallet states that all users will issue a verification ID through the government. It sounds like the Calibra wallet will be the only wallet available for at least a period of time, so it's unclear if developers and users can run the application's network on Libra and not follow the same standard caliber.

What is low cost? What is normal operation and what is sufficient capacity?

The Calibra Wallet FAQ promises low fees, but this seems to conflict with the operation of the underlying protocol at high loads.

“Transaction costs will be low cost and transparent, especially if you are an international remittance. Calibra will cut costs to help people keep more money.”

Is Libra really open to developers?

According to the plan to achieve a non-permitted consensus:

“The Libra blockchain will be open to everyone – any consumer, developer or business can use the Libra network to build products on top of it and add value through their services. Open access ensures low entry and innovation Thresholds and encourage healthy competition for consumers."

I suspect that developers can run any technically effective application they dream of on this platform. Nothing I have read makes me believe that this system will resist the censorship, but only time will prove it!

Author: Jameson Lopp Bitcoin developer, specializing in punk password

Compilation: Sharing Finance Ma Ming Editor: Sharing Finance Neo