Partial order

How pod achieves a weaker form of consensus that does not give total but only partial order, and how that affects applications building on top of pod.

Overview

Pod achieves high performance through a giving up on full consensus. Instead of requiring strong consensus where all participants agree on exact transaction order, pod employs weaker consensus that allows transactions to have some temporal flexibility while maintaining critical safety guarantees.

How pod Achieves Weak Consensus

Independent Validator Operation

The key distinction in pod compared to most distributed ledgers is that validators operate completely independently:

1. Each validator maintains its own local log

2. Validators never communicate directly with each other

3. Each validator processes transactions based on its local view

4. Validators sign timestamps based on their local clock

This independent operation eliminates the communication overhead traditional consensus requires.

Wiggle Room Instead of Order

Rather than agreeing on exact timestamp for a transaction, pod provides a timestamp with a "wiggle room":

1. Confirmation timestamp

   1. The median of all timestamps in a certificate is called a confirmation timestamp.

2. Wiggle room

   1. The confirmation timestamp is not the same for all clients.

   2. Pod provides a minimum possible and maximum possible confirmation timestamp.

   3. Any other client's confirmation timestamp is within the minimum and maximum possible timestamps.

Compatible Operations

The weak consensus model works well for operations that don't require strict ordering:

1. Single-Owner Operations

Operations where all state changes are controlled by one account:

• Sequenced naturally by sender's transaction nonce

• No coordination needed with other participants

• Order relative to other accounts doesn't matter

2. Commutative Operations

Operations where execution order doesn't affect outcome:

Example: Payments Payments work because they have asymmetric access patterns:

• Sender: Only owner can deduct (checked by nonce)

• Receiver: Anyone can add (commutative operation)

• No coordination needed between different payments

// Simplified payment example
function transfer(address to, uint256 amount) public {
    // Only owner can deduct (ordered by nonce)
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount;
    
    // Anyone can add (commutative)
    balances[to] += amount;
}

Operations Requiring Full Consensus

Some operations fundamentally require strict ordering:

1. Order-Dependent Results

   • Traditional AMM swaps

   • Auctions with price competition

   • Operations where outcome depends on exact execution order

2. State-Dependent Validity

   • Operations that need exact state for validation

   • Complex multi-step processes

   • Cross-contract interactions with dependencies

Implementation Guidelines

When building applications for pod's fast path:

Design Principles

1. Embrace Uncertainty

   • Design for time windows, not exact order

   • Handle temporary ordering uncertainty

2. Independent Operations

   • Minimize dependencies between transactions

   • Design commutative operations where possible

   • Use owner-based sequencing

Conclusion

By allowing validators to operate independently and embracing temporal flexibility, pod achieves high performance for compatible operations. Understanding these principles is crucial for designing efficient applications on pod.