, 23 tweets, 7 min read Read on Twitter
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...
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 🙈
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.
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™ 💯)
5. "CanonicalSerialize"
"One design goal of this serialization format is to optimize for simplicity"
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

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.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to protolambda
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!