Thread by @matt_garnett

I'm going to live tweet as I read the @Libra_ whitepapers & relate it to Eth 2.0 where I can. [THREAD]

@Libra_ I'll be reading these resources:

1. developers.libra.org/docs/reference…
2. developers.libra.org/docs/assets/pa…
3. developers.libra.org/docs/assets/pa…
4. developers.libra.org/docs/libra-cor…
5. developers.libra.org/docs/move-paper

@Libra_ Please correct & discuss any of my thoughts, thanks!

@Libra_ The consensus protocol is a BFT based system on "HotStuff" (arxiv.org/pdf/1803.05069…). BFT has been plagued with issues where the number of participants usually needed to be < 1000. It seems like HotStuff improves the communication to O(n) instead of the previous best O(n^2).

@Libra_ I found a draft paper "BFTree" which claims to scale HotStuff to millions of participants: storage.googleapis.com/celo_whitepape…

@Libra_ > In a custodial wallet model, the wallet product takes custody of customers' funds and private keys.

Custodial wallet is defined in the glossary, so that may be an indication as to what Calibra (FB's wallet) will look like.

@Libra_ They plan to use the Ed25519 curve which is a Schnorr signature based curve. Eth 2.0 uses BLS12_381 curve. I'm not an ECC expert by any means, but here is an article comparing the curves (i.e. why BLS is better): medium.com/cryptoadvance/…

@Libra_ > Events provide evidence that the successful execution of a transaction resulted in a specific effect.

Although Libra is an account based chain, this sounds very UTXO-like. I wonder why a user can't just view the current state of the chain to determine if something occurred.

@Libra_ $LBR is the abbreviation for Facebook's Libra currency. RT that you heard it here first. 💯

@Libra_ > Libra reserve is the total monetary holdings that back Libra. To be a validator node for the Libra Association, it is a requirement to invest in the reserve.

A reported $10M investment, but I have no way to verify this claim.

@Libra_ Move is the smart contract programming language for Libra. I've defined them in terms of Ethereum:

Move == Solidity
Move Module == Smart Contract
Move Resource == Storage

In an interesting move, they've spurred all the cross platform collaborations around Wasm on Blockchain™.

@Libra_ Transaction anatomy:

Libra => Ethereum
sender => msg.sender
transaction script => calldata
gas price => gas price
maximum gas amount => gas limit
sequence number => nonce
expiration time => blocks valid for (but doesn't exist in eth)

@Libra_ > A transaction script is not stored in the global state and cannot be invoked by other transaction scripts. It is a single-use program.

"Single-use program" makes it sounds like there are some specific nuances to tx scripts. Sounds similar to Fae: sites.google.com/consensys.net/…

@Libra_ All done with the glossary! On to "The Libra Blockchain" whitepaper.

@Libra_ > LBR will be fully backed with a basket of bank deposits and treasuries from high-quality central

This sounds like a 1:1 backing. Although our last 1:1 backed crypto asset (tether) had its issues, FB + crew will have to follow the law to the letter (or change it).

@Libra_ > Validators form the membership of the Libra Association, which will provide a framework for the governance of the
network and the reserve that backs the coin.

It appears to be a pay-to-play governance system in the beginning.

@Libra_ Below is an image which depicts the Libra protocol architecture. The leader, validator scheme is similar to the block proposer, validator committee idea in Eth 2.0, but the consensus algo and fork choice is totally different.

@Libra_ Although it is assumed that user clients communicate with the validators directly to get the state of the chain, it is also possible to sync a client from genesis, verifying the whole chain.

@Libra_ > 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.

IMO this appears to mean there is no concept of a "block".

@Libra_ A cool account mechanic that Libra offers is the ability to swap out a compromised private key and keep the same address. Although an improvement, this seems much more rigid than Eth's account abstraction proposal which offers that & more: ethresear.ch/t/a-recap-of-w…

@Libra_ > The Libra protocol does not link accounts to a real-world identity.

In general, I appreciate the position that Libra appears to be coming from. Whatever FB's intentions are, it seems like the Libra protocol is a neutral construction.

@Libra_ There is a consistent top level scheme for accessing resources across any account. For example, assuming some token resource "Currency":

`{owner_address}/resources/{token_address}.Currency.T`

This seems to move balances from the smart contract into the user's account state.

@Libra_ Contract code (modules) are immutable, but they are researching schemes to enable safe module updates. A single address can have multiple modules associated with it so long as they are named differently.

@Libra_ Libra wants users to query the chain for events to determine if a transaction succeeds vs. just checking if the tx was included in the chain. Their rationale for only checking inclusion is that it's error prone as the tx may have failed for some reason.

@Libra_ Transactions cannot read events, only the current state of the system. This seems against the current plans in Ethereum to rely more heavily on calldata vs. state.

I accidentally “forked” my thread so here is a tweet from earlier:

> Libra starts as a permissioned system and will transition to permissionless.

They claim their eventual goal is to allow *anyone* to become a node.

> A validator does not need to know the ledger history to execute new transactions

At first I was excited that this means some stateless design, but after further thinking I believe this is under the assumption that the validator has already generated the current state.

Unfortunately developers won't be able to deploy Move modules that declare their custom types of resources upon launch (i.e. no token rush).

> The Libra protocol charges transaction
fees, denominated in Libra coins. This follows the gas model popularized by Ethereum.

I think we could have guessed this, but $LBR will the protocol token to Libra as ether is to Ethereum.

> Fees spike during periods of high demand, representing a revenue source for the validators but a cost for the users.

Apparently this is how the validators will recoup their $10M! It doesn't seem like this system was influenced any by EIP-1559.

A weird semantic: new Move modules (smart contracts) are published under the sending user's address. Smart contracts will now have keys associated with them!

The semantics of resources in the Move language are inspired by "Light Linear Logic": girard.perso.math.cnrs.fr/LLL.pdf

The Move language is currently still under work, but the Move IR is available and should be readable enough for developers to begin experimenting.

"Transaction scripts" are the calldata of Libra, except they are expressed in arbitrary Move byte code. This is a really interesting technique that would allow txs to batch operations (think approve <> transfer flows) into one tx.

Important distinction:

> In Libra, modules contain code, and resources contain data values. An Ethereum smart contract is like a singleton object published under a single account address. A module can create an arbitrary number of resources under many addresses.

Primitives in Move:

* boolean
* uint64
* uint256
* fixed-size byte array
* struct
* reference

Libra *does* use a Sparse Merkle Tree (SMT) to store the ledger state. Ethereum currently makes use of the Modified Merkle Patricia Trie, but there are conversations of dropping it in favor of an SMT in Eth 1.x or 2.0.

Initially, account state is authenticated by hashing the entire account's storage. As account grow, they expect to transition to using a merkle / avl accumulator (as Ethereum currently does).

Rent schemes for storage are discussed, but nothing has been decided upon in the whitepaper.

Their BFT algorithm LibraBFT, which was derived from HotStuff, was chosen in order to initially support ~100 nodes at launch and eventually evolve to support 500-1000 nodes.

> We design an unpredictable leader election mechanism in which the leader of a round is determined by the proposer of the latest committed block using a verifiable random function

This seems to be their most important deviation from HotStuff. VRF is only pseudo-random though.

Unlike Eth 2.0, Libra validators are managed by Move modules (i.e. not as part of the consensus). The ability to define core blockchain primitives in Move is fascinating, I'm interested to know what else will be possible.

Like most POS blockchain architectures, they make a 2/3 honesty assumption.

Libra takes inspiration from libp2p, but the networking is implemented on TCP using a Multiaddr addressing scheme, Noise for authentication / e2e encryption, and Yamux to mux streams over a single connections.

Libra's 3 performance goals:

* Throughput
* Latency
* Capacity

They make the assumption that 1000tps will be enough to support the initial needs of the ecosystems, under the assumptions that many additional transaction will actually occur through state channels and within custodial wallet providers.

Expected computation requirements for Libra (to achieve ~1000tps):

* 40 Mbps internet connection
* A modern processor, something like an i7 or i5
* SSD to support the current state size

> Libra Investment Tokens represent an expectation of returns from interest on the reserve, further incentivizing the validators to keep the system operational.

This is the other way founding members will get their $10M back. I wonder if new deposits will also get "LIT" tokens.

> We plan to gradually transition to a proof-of-stake system where validators are assigned voting rights proportional to the number of Libra coins they hold.

I'm hoping this is a simplification, because if not it will face issues with plutocracy: vitalik.ca/general/2018/0…

Done with "The Libra Blockchain" whitepaper! I will take a break and continue with the next item later🤓.

Okay, back at it with "State Machine Replication in the Libra Blockchain".

Alex (NEAR) had a particularly interesting thread on Libra's choice to use HotStuff over Tendermint:

https://twitter.com/AlexSkidanov/status/1141040292767789056?s=20

In LibraBFT, a leader is chosen from the set of validators. This leader proposes a new set of txs to be included and then collect votes on the proposal. Once a majority threshold is reached, the txs are committed to the chain.

Tendermint / Casper consensus algorithms choose either linearity (O(n) communication for progress vs. O(n^2)) or responsiveness (the leader can advance immediately after collecting responses from validators). LibraBFT (HotStuff*) supports both of these desirable properties.

There is a claim stating that Casper is a permissioned consensus algorithm, but I would argue that it is permissionless. Anyone can become a validator by staking 32 ether, whereas the current Libra system allows only trusted "founding members" to become validators.

QC == Quorum Certificate

This is the aggregate of validator votes on a tx package that extends the longest canonical chain in LibraBFT.

There is very little describing the slashing scheme for LibraBFT, but in general it is expected that a whistleblower will submit proof of the following malicious behavior:

* unsuccessful block proposal
* multiple block proposals
* conflicting votes
* stale votes

In future revisions of the LibraBFT paper, they plan to do a thorough analysis of resource consumption in the presence of malicious actors and research the heuristics of the leader selection. They will use some VRF scheme for leader selection, while Eth 2.0 uses RANDAO / VDF.

The State Machine Replication whitepaper is dense and about half of it is proving LibraBFT. Although it isn't exactly tweet friendly, I'd recommend personally going through if you're looking for a more complete understanding: developers.libra.org/docs/assets/pa…

Onto "Move: A Language With Programmable
Resources": developers.libra.org/docs/assets/pa…

> 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.

Light Linear Logic: girard.perso.math.cnrs.fr/LLL.pdf

The fact that "significant" portions of the Libra protocol is written in Move is exciting. This sounds like it may be similar to the Execution Environment concept in Eth 2.0 phase 2: notes.ethereum.org/s/Bkoaj4xpN

Move aims to improve on the 3 drawbacks of EVM-style smart contract languages:

* Indirect representation of assets via integers
* Scarcity is not extensible since there is only one native protocol token
* Access control is not flexible because ownership is based on PK schemes

IMO the only valid point here is the first. There are absolutely additional scare tokens (that will likely even be native in eth 2.0) and smart contracts can own assets and describe arbitrary access control schemes.

> Libra coin itself is implemented as an ordinary Move resource with no special status in the language.

This is almost certainly how ether will be represented in Eth 2.0, since beacon chain ether will be the "reserve" backing shard ether.

> The bytecode is checked on-chain for resource, type, and memory safety by a bytecode verifier3 and then executed directly by a bytecode interpreter.

I would be interested to know the performance of this as each tx script will need to be verified before being interpreted.

A simple tx script in Move IR that transfers a coin from address to another:

```
public main(payee: address, amount: u64) {
let coin: 0x0.Currency.Coin = 0x0
.Currency
.withdraw_from_sender(copy(amount));

0x0.Currency.deposit(copy(payee), move(coin));
}
```

> The Move language implements linear resources that must be moved exactly once.

There are a lot of parallels between Move and Rust, which Libra Core happens to be written in.

`GetTxnSenderAddress` is a "transaction builtin" in Move IR that gives the execution context a reference to the data of the current tx. This is the same as `msg.sender`.

> We considered both a register-based and a stack-based bytecode interpreter and found that a stack machine with typed locals is a very natural fit for the resource semantics of Move.

I'm not aware of any blockchain vm that is register-based!

The Move tooling ecosystem that currently exists:

* programming model definition
* bytecode language
* module system w/ strong data abstraction & access controls
* VM w/ serializer/deserializer, bytecode verifier, bytecode interpreter

Libra plans to develop a "logical specification language and automated formal verification tool that leverage Move's verification-friendly design". This would be a *major* advantage over all existing blockchain languages.

Okay, onto the last resource (I swapped 4 & 5)! The "Libra Core Overview": developers.libra.org/docs/libra-cor…

> Admission Control (AC) is the public API endpoint for Libra and it takes public gRPC requests from clients.

I'm wondering if this is the "big scary black box" that will allow Libra to censor transactions from non-KYC/AML'd accounts.

A "pacemaker" emits messages to determine when a validator believes round should timeout. Validators rely on a quorum of pacemaker messages to avoid the need for a synchronized clock.

> We intend to design an unpredictable leader election mechanism in which the leader of a round is determined by the proposer of the last block using a verifiable random function VRF.

Since VRFs are only pseudo-random, I'm not sure what stops a leader from biasing the output.

Here are a bunch of sample programs written in Move IR (and the best place to start writing your own): github.com/libra/libra/tr…

If you've made it all the way to the end, then your persistence is admirable! I've gone through all the available materials on Libra and learned a ton (I hope you did too). Don't hesitate to ping me with any specific questions, I'd be happy to try and help.