Transactions

Client Submits a Transaction

A Libra client constructs a raw transaction (let us call it T5raw) to transfer 10 Libra from Alice’s account to Bob’s account. The raw transaction includes the following fields. Each field is linked to its glossary definition.

• Alice's

  account address

  .

• A program that indicates the actions to be performed on Alice's behalf. It contains:

  • A Move bytecode

    peer-to-peer transaction script

    .

  • A list of inputs to the script (for this example, Bob's account address and the amount of payment).

• Gas price

  (in microlibra/gas units) — The amount Alice is willing to pay per unit of gas, to execute the transaction. Gas is a way to pay for computation and storage. A gas unit is an abstract measurement of computation with no inherent real-world value.

• Maximum gas amount

  Alice is willing to pay for this transaction.

• Expiration time

  of the transaction.

• Sequence number

  — 5

  • A transaction with sequence number 5 can only be applied to an account with sequence number 5.

The client signs transaction T5raw with Alice's private key. The signed transaction T5 includes the following:

• The raw transaction.

• Alice's public key.

• Alice's signature.

Lifecycle of the Transaction

Accepting the Transaction

1 — The client submits transaction T5 to validator V1 whose admission control (AC) component receives the transaction. (Client → AC AC.1)

2 — AC will use the virtual machine (VM) component to perform validation checks, such as signature verification, checking that Alice's account has sufficient balance, checking that transaction T5 is not being replayed, etc. (AC → VM AC.2, VM.1)

3 — When T5 passes the validation checks, AC sends T5 to V1's mempool. (AC → Mempool AC.3, MP.1)

Sharing the Transaction With Other Validators

4 — The mempool will hold T5 in an in-memory buffer. Mempool may already contain multiple transactions sent from Alice's address.

5 — Using the shared-mempool protocol, V1 will share the transactions (including T5) in its mempool with other validators (V2 to V100) and place transactions received from the other validators into its own mempool. (Mempool → Other Validators MP.2)

Proposing the Block

6 — As validator V1 is a proposer/leader, it will pull a block of transactions from its mempool and replicate this block as a proposal to other validators via its consensus component. (Consensus → Mempool MP.3, CO.1)

7 — The consensus component of V1 is responsible for coordinating agreement among all validators on the order of transactions in the proposed block. (Consensus → Other Validators CO.2). Refer to our technical paper State Machine Replication in the Libra Blockchain for details of our proposed consensus protocol LibraBFT.

Executing the Block and Reaching Consensus

8 — As part of reaching agreement, the block of transactions (containing T5) is passed to the execution component. (Consensus → Execution CO.3, EX.1)

9 — The execution component manages the execution of transactions in the virtual machine (VM). Note that this execution happens speculatively before the transactions in the block have been agreed upon. (Execution → VM EX.2, VM.3)

10 — After executing the transactions in the block, the execution component appends the transactions in the block (including T5) to the Merkle accumulator (of the ledger history). This is an in-memory/temporary version of the Merkle accumulator. The (proposed/speculative) result of executing these transactions is returned to the consensus component. (Consensus → Execution CO.3, EX.1). The arrow from "consensus" to "execution" indicates that the request to execute transactions was made by the consensus component. (For consistent use of arrows across this document, we are not using arrows to represent the flow of data).

11 — V1 (the consensus leader) attempts to reach consensus on the block's execution result with other validators participating in the consensus. (Consensus → Other Validators CO.3)

Committing the Block

12 — If the block's execution result is agreed upon and signed by a set of validators that have the super-majority of votes, validator V1's execution component reads the result of the block execution from the speculative execution cache and commits all the transactions in the block to persistent storage. (Consensus → Execution CO.4, EX.3), (Execution → Storage EX.4, ST.3)

13 — Alice's account will now have 100 Libra, and its sequence number will be 6. If T5 is replayed by Bob, it will be rejected as the sequence number of Alice's account (6) is greater than the sequence number of the replayed transaction (5).