Thread by @protolambda

Libra TAKE-2. Whitepaper is somewhat confusing, source code is where it's at to get the details. Dug through it for you. Not an audit, just fun. Comparing with Eth1/Eth2 where relevant. Getting in merkleization/hashing/crypto/misc, but not consensus.
Tweetstorm ⬇️ 🧐

0. First of all, source code is located here: github.com/libra/libra
Apache 2.0 license. 👏

1 They actually have a "legacy" and "next-gen" crypto package. Guess what's in the next gen? An unused BLS12-381 implementation. What we use in Eth2. Work in progress, but everyone is welcome to join standardization process. And experiments like this help the whole space 👏

1.1 Libra next-gen crypto collection: github.com/libra/libra/tr…

2 Merkleization turned out to be two-fold. The whitepaper is similar to Eth2: binary merkle trees. But not derived from an arbitrary structure, like Eth2 SSZ hash-tree-root. Reality is: they use multiple merkle approaches. Binary and Patricia trees.

2.1 Tests of their binary merkle-trees: github.com/libra/libra/bl… Interesting difference with Eth2: we're looking to do sparse right in Eth2. Generalize merkleization, identify leaf nodes in arbitrary structures by a "generalized index", and enable protocol improvements.

2.2 Libra on the other side, seems to be using "placeholders" (instead of zerohashes[depth]), effectively shortening the hashing path up to the root, and is doing indexing differently: just an accumulator index, instead of a general index for a nested one like Eth 2.

2.3 The binary accumulator serves a purpose of being updated continuously however, not like the binary tree-hashing in eth2, which serves tracking overrides of nodes. So we shouldn't compare them harshly, different purpose -> different approach.

2.4 It looks like they get around the need for zerohash[i] in the placeholder spot by adding the "defaults_bitfield" to their proof data, still investigating...
github.com/libra/libra/bl…

2.5 Although the accumulator proofs don't directly work as plain merkle-branch proofs, the use of the bitfield may actually compress things well, make verification cheaper, and enable to proof multiple sub-branches at the same time (with a few modifications)

2.6 So many binary tree-orders, but no generalized indices :(. Their code may actually be less complex when you can just mask a generalized index big-int 🙈
github.com/libra/libra/bl…
github.com/libra/libra/bl…

2.7 Libra-style merkle patricia trees: github.com/libra/libra/bl…, a modified version of Eth-1 style Merkle Patricia trees, also used for acount storage. Was hoping for optimized sparse binary trees, but well, this is proven to work ok-ish with Eth1 at least.

3 Their internal block-tree is super basic: HashMap<Hash, Block>. But also super minimal. Centralized consensus = less forks, easy finality. Just collect 'em, execute 'em, and when committed: put 'em in storage, and completely get rid of conflicting blocks.

3.1 If only real blockchain management, re-orgs and forking were that easy... Not blaming them though, it fits their use.
Source here: github.com/libra/libra/bl…

4. Addresses
32 bytes, with Bech32 + network ID support.
github.com/libra/libra/bl…

4.1 On their hash-function used in Move and address sytem: "TODO: keccak is just a placeholder, make a principled choose for the hash function" (typo PR anyone? You can be a Libra Contributor™ 💯)
github.com/libra/libra/bl…

5. "CanonicalSerialize"
"One design goal of this serialization format is to optimize for simplicity"
github.com/libra/libra/bl…
Looks a bit like Eth 2 simple-serialize. But even more simple, no offsets/optimization or hash-tree-root.

5.1 They implemented a simple way to encode sparse (or keyed) data, alike to the structure of a TreeMap, but no index/offsets. Also planned for eth2, but with offsets, and non-arbitrary keys (we just need indices), for better read times when only interested in part of the data.

6 The libra VM validator looks far from finished. github.com/libra/libra/bl…

7 Node is pretty minimal; just a gRPC server with a few consensus + tx pool methods. I see "trusted" and "seed" peers. Everything handled by admission control, which 1) handles TXs submits, 2) handles storage queries
github.com/libra/libra/bl…

github.com/libra/libra/tr…

7.1 I can see admission control getting a black-list functionality to censor things 🥺. But let's don't make the same mistake as EOS (blacklist update fail), or bitcoin (avoided double spends / inflation). It's not the mempool that needs to be protected, just fail the TX properly

7.2 background:
Bitcoin history: hackernoon.com/bitcoin-core-b…
EOS history (recent ish): zdnet.com/article/hacker…

8. That's it for now. May take a look at their consensus at some point. They use a VRF (readers; VDF is different), and some modified "HotStuff" consensus. But it's still a centralized system. Wonder when they get a public audit.
github.com/libra/libra/bl…