> In practice, it is much more complicated: while a limited set of “validators” — aka miners — share a history of transactions in (individual) blocks that are chained together (i.e. a blockchain), what Libra actually exposes is the current state of the ledger. In practice this means that adding new transactions can be much quicker and more efficient — more akin to adding a line to a spreadsheet than rebuilding the entire spreadsheet from scratch.

The author seems to be referring to the two different accounting models in crupyotcurrency: the coin model and the account model.

The coin (aka UTXO) model mimics physical cash. A transaction changes ownership of a digital token, leaving a chain of ownership in its wake. This is the model used by Bitcoin.

The account model credits and debits specific amounts from an account. This is the model used by Ethereum.

The author seems to imply that the speed of a network depends on which accounting model is being used.

It doesn't. In both cases, signatures must be validated, and this is the most costly computation. In neither case is the entire chain of transactions reloaded to verify a single payment. Instead, the most recent state is extended.

Transaction volume is largely a function of how open the network is and how trusted the parties are that write blocks. The more open the network to membership by arbitrary players, the slower it will be. The less trust in those writing blocks, the slower it will be.

Bitcoin users value censorship resistance and insist on validating their own blocks (or at least they should). The network is configured make this possible by, for example, setting a block size limit among other features.

Libra will need none of this. Validators will be implicitly trusted. What they say goes. A certain minimum hardware spec can be set and enforced, ensuring fast payment processing, at the expense of censorship resistance and openness.