Getting Started
Node Operations
Integrations
Tech Specs

Transaction Lifecycle

mslipper Written by

Sections in this article

Overview

When a transaction is submitted to the root node for inclusion in a block, it goes through the following stages:

  1. Insertion into the mempool
  2. Insertion into a block.
  3. Confirmation by the client.
  4. Finalization on the root chain.

This document will describe each stage in depth. A block diagram is included at the end.

Phase 1: Mempool Insertion

When a client signs a transaction and sends it to the root node, the transaction is inserted into the mempool for eventual insertion into a block. The mempool will validate the transaction prior to insertion. The following validations are performed:

  1. Transaction format is sane (i.e., the transaction structure itself is what we expect it to be).
  2. Signatures are valid and signed by the correct parties.
  3. Input amounts equal output amounts plus fees.
  4. Input amounts are not negative.
  5. The transaction is not double spent.

The mempool can contain a maximum of 65,534 transactions. This limit is due to Minimum Viable Plasma’s fixed Merkle tree depth of 16 and the fact that 1 transaction is the root node’s fee transaction.

If the transaction passes all validations, it will be added to an in-memory queue where it will sit until it is inserted into a block. The gRPC call that inserted the transaction will block until the transaction is inserted.

Phase 2: Block Insertion

Plasma will create new sidechain blocks according to the following rules:

  1. There are transactions in the mempool.
  2. 100 milliseconds has passed since the creation of the last block.

If there are no transactions in the mempool, Plasma will not create new blocks. The smart contract explicitly forbids insertion of empty blocks.

Once a block is created, all gRPC calls that inserted transactions into that block will receive an ‘inclusion receipt.’ The inclusion receipt is used to generate the appropriate confirmation signatures now that the transaction has been assigned a block number and an index within the block.

Phase 3: Client Confirmation

To allow recipient to spend the transaction they initiated, Clients must provide confirm signatures over the transaction and its inclusion receipt. Clients generate confirm signatures as follows:

  1. They set the block number and transaction index of the transaction to be confirmed to the values provided by the inclusion receipt.
  2. They hash the transaction.
  3. They concatenate that hash with the Merkle root of the block that includes the transaction.
  4. They hash the concatenation, sign it, and send it to the root node.

At this point, the transaction is spendable by the recipient.

Phase 4: Root Chain Finalization

Plasma periodically submits the Merkle roots of sidechain blocks to the Ethereum blockchain for finalization. Plasma blocks are currently submitted as soon as they are created, however in the future configurable finalization rules may be supported. Note that because there is a large difference between Ethereum’s block time and Plasma’s, block submission may lag behind block creation significantly. As such, blocks are written to an in-memory queue prior to submission.

Flow Diagram

See the diagram below for an overview of how everything fits together:

Transaction Flow Diagram

Related Articles