This will be aimless and might take multiple days.
- I heard before Libra launched it would be partially based on Stellar/XLM. I'm curious if that's true but haven't read that paper. stellar.org/papers/stellar…
- The real content starts with "The Libra protocol" on page 2. This is mostly readable although at first they seem to equivocate between "database" and "ledger", and possibly "resource" and "transaction".
2. The full history matters, which means in 2080 you'll still be lugging around data from this year. The network cost increases with time
- The word "Gas", an Etherium vocabulary word, shows up here out of the blue.
- "There is no concept of a block of transactions in the ledger history." The fundamental unit is the transaction. This seems to sidestep some performance limitations in Bitcoin clones.
Modules (data types and basic operations on them)
Resources (items in the database; can only be moved not copied; can only be created by modules)
Transactions (scripts; cost Libra coins to execute; the only things that can change the database)
Events (receipts; the event record can be queried from validators, but they're not part of the database, they can't be read by transactions)
They start by explaining the validator (the database server) is not trusted, so every computation returns a result AND a quickly-checkable proof that it was performed correctly.
They then spend a full page explaining what a Merkle Tree is. I'm not sure why. I think it's an example of data you can create proofs along with a result on
So like I said, they start this part by describing Merkle trees. … incorrectly. Or at least in a heterodox way.
They refer you to a book (um), but I *think* the PDF is here: usenix.org/legacy/events/…
- The current Libra implementation is designed only for Libracoin
- A version is coming introducing user modules; plus more efficient representation for account contents; plus "rent" for excessive disk usage, making Libra general-purpose
I'll read this tomorrow.
Let's talk about Byzantine Fault Tolerance.
Earlier I suggested Libra uses "proof of stake". This was wrong:
…which *was* designed for blockchain applications, and its paper is specifically concerned with the idea some of the database servers in the pool are malicious.
The Libra paper spends two (2) pages on it. Maybe they just expect you to read the Hotstuff paper.
"Byzantine" doesn't mean "complex" here. It's about the East Roman Empire.
n: number of nodes currently in the network
f: number of "faulty" nodes, or rather, maximum allowable # of faulties
(n - f): at least this many nonfaulty nodes are assumed to exist
"replica": what Libra calls a "validator"
And then they do it again. For… some reason.
Prepare accepts transactions; precommit accepts a prepare vote; commit accepts a precommit vote.
Hotstuff suggests (and I think Libra uses) an extension where you overlay votes, so you commit round N, precommit N+1, and prepare N+2 at once.
First off, we're so concerned about voters going out to lunch— but what if the *leader* goes out to lunch? Libra has an answer to that one, they invent a shared clock and define a timeout period. So that's fine.
This turns out not to exist.
But then it gets worse.
I was about to complain Libra is the same, but— wait!
They talk about N. The # of nodes in the system.
N is a constant.
*The number of nodes is fixed!!!*
Is Libra "decentralized"? Can Libra or a network with Libra's protocol *ever* be "decentralized", even in principle?