The Libra Blockchain is a cryptographically authenticated database maintained using the Libra protocol. The database stores a ledger of programmable resources, such as Libra coins. A resource adheres to custom rules specified by its declaring module, which is also stored in the database. A resource is owned by an account that is authenticated using public key cryptography. An account could represent direct end users of the system as well as entities, such as custodial wallets, that act on behalf of their users. An account’s owner can sign transactions that operate on the resources held within the account.
Validators maintain the database and process transactions submitted by clients for inclusion in the database. The validators use a distributed consensus protocol to agree on an ever-growing list of transactions that have been committed to the database as well as the results of executing those transactions. This consensus protocol must be reliable even in the presence of malicious or erroneous behavior by a minority of validators. Validators take turns driving the process of accepting transact tions. When a validator acts as a leader, it proposes transactions, both those directly submitted to it by clients and those indirectly submitted through other validators, to the other validators (All validators execute the transactions and form an authenticated data structure that contains the new ledger history. The validators vote on the authenticator for this data structure as part of the consensus protocol. As part of committing a transaction at the consensus protocol outputs a signature on the full state of the database at version — including its entire history — to authenticate responses to queries from clients.
Clients can issue queries to a validator to read data from the database. Since the database is authenticated, clients can be assured of the accuracy of the response to their query. As part of the response to a read query, a validator returns a signed authenticator for the latest version of the database known to the validator.
In addition, a client can optionally create a replica of the entire database by synchronizing the transaction history from the validators. While creating a replica, a client can verify that validators executed transactions correctly, which increases accountability and transparency in the system. Other clients can read from a client that holds a replica in the same way they would read from a validator to verify the authenticity of the response. For the sake of simplicity, the rest of this paper assumes that clients query a validator directly rather than a replica