Transaction Lifecycle

A description of how transactions are broadcasted and finalised on pod.

Overview

Pod implements a leaderless consensus mechanism where transaction finalization occurs through validator attestations rather than traditional block creation. This approach enables rapid transaction finality through a quorum-based certification process.

Transaction States

A transaction in pod progresses through several distinct states:

1. Submitted: Transaction is broadcasted to the network

2. Validated: Individual validators have processed the transaction

3. Attested: Validators have provided signed attestations

4. Finalized: Sufficient attestations have been collected to form a certificate

Detailed Process Flow

1. Transaction Submission

When a client submits a transaction to pod:

1. Client sends transaction via JSON-RPC to a connected node

2. Node validates basic transaction format and parameters

3. Node forwards valid transaction to validators through consensus network

2. Validator Processing

Unlike traditional blockchain systems, pod doesn't batch transactions into blocks or rely on leader election. Instead:

1. Each validator independently:

   • Receives the transaction

   • Validates transaction format and signatures

   • Checks account balances and nonce values

   • If calling a smart contract function, checks that the function accepts the calldata, always ensuring enough gas was paid.

2. Upon successful validation, validators generate signed attestations containing:

   • Transaction hash

   • Validator's signature

3. Attestation Collection

Nodes collect attestations from validators according to their configuration:

• Collect all attestations from all validators

• Maintain complete network state

• Track attestation quorum for all transactions

4. Certificate Formation

A transaction reaches finality when:

1. More than two-thirds of validators have provided attestations

2. The attestations are cryptographically valid

3. The attestations form a consistent view of the transaction

The two-thirds threshold can be adjusted by clients who have different trust assumptions on the number of faulty nodes on the network. There is a trade-off between liveness and safety when adjusting this threshold.

5. Transaction Finalization

Once a certificate is formed:

1. Nodes update their local state

2. Clients can query transaction status via JSON-RPC

3. The transaction is considered irreversible

Performance Characteristics

Pod's leaderless consensus mechanism offers several advantages:

1. Fast Finality: Transactions can finalize as soon as sufficient attestations are collected, without waiting for block creation

2. Consistent Latency: No block time variability or leader election delays

3. High Throughput: Parallel processing by validators without block size limitations

Best Practices

When implementing applications on pod:

1. Always wait for transaction finalization before considering transactions complete.

2. Monitor transaction receipts to verify attestation collection.

3. Implement appropriate error handling for transaction submission and monitoring.

4. Consider using verifying clients for critical applications.

For high-value transactions, consider waiting for additional attestations beyond the minimum quorum for additional security.

bash