Application Contexts

Ample applies to two distinct scenarios in KERI:

1. Witness Pools: For witnessed events, ample determines how many witnesses must confirm an event to establish its validity and prevent a dishonest controller from creating conflicting event versions.

2. Multi-Signature Groups: For multi-sig identifier control, ample sets the signing threshold for group operations, preventing accidental lockout scenarios where valid operations could be blocked.

Protocol Architecture

KAACE Integration

Ample is a core component of KAACE (KERI's Agreement Algorithm for Control Establishment), which establishes consensus between witnesses on the key state of a KERI identifier. The algorithm uses ample to determine when sufficient witness agreement has been achieved.

The consensus architecture operates as follows:

1. Event Propagation: A controller creates a key event and sends it to their designated witness pool
2. Witness Verification: Each witness independently verifies the event's cryptographic validity
3. Receipt Generation: Witnesses create signed receipts of the event
4. Consensus Determination: When the ample threshold of witnesses have receipted the event, consensus is achieved
5. Accountability Establishment: The consensus on key state forms the basis for controller accountability

State Management

Ample affects the state management of KELs (Key Event Logs) and KERLs (Key Event Receipt Logs):

• Pre-consensus State: Events exist but have not achieved ample witness agreement
• Consensus State: Events have achieved ample witness receipts and are considered stable
• Accountability State: The key state derived from ample-confirmed events establishes what the controller is accountable for

Message Formats & Encoding

While ample itself is a numeric parameter rather than a message format, it affects the structure and interpretation of several KERI message types:

Witness Configuration in Establishment Events

Ample is implicitly defined through witness configuration fields in inception events and rotation events:

{
  "v": "KERI10JSON00011c_",
  "t": "icp",
  "d": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
  "i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
  "s": "0",
  "kt": "1",
  "k": ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"],
  "nt": "1",
  "n": ["EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM"],
  "bt": "2",
  "b": [
    "BBilc4-L3tFUnfM_wJr4S4OJanAv_VmF_dJNN6vkf2Ha",
    "BLskRTInXnMxWaGqcpSyMgo0nYbalW99cGZESrz3zapM",
    "BIKKuvBwpmDVA4Ds-EpL5bt9OqPzWPja2LigFYZN2YfX"
  ],
  "c": [],
  "a": []
}

Key fields:

• bt: Threshold of Accountable Duplicity (TOAD) - the minimum number of witness receipts required
• b: Array of witness AIDs
• n: Total number of witnesses (length of b array)

The ample calculation uses these values: given n witnesses and TOAD bt, the system calculates the appropriate fault tolerance f and verifies that bt satisfies the ample constraint.

Receipt Messages

Receipt messages (rct) are the mechanism by which witnesses confirm events. The ample threshold determines how many receipts are required:

{
  "v": "KERI10JSON00011c_",
  "t": "rct",
  "d": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
  "i": "BBilc4-L3tFUnfM_wJr4S4OJanAv_VmF_dJNN6vkf2Ha",
  "s": "0"
}

When the number of valid receipts reaches the ample threshold, the event achieves consensus.

Protocol Mechanics

Ample Calculation Algorithm

The KERI protocol implements ample calculation through a deterministic algorithm that takes the total number of participants and optionally a fault number, then computes the minimum required participants for supermajority.

The algorithm operates in two modes:

Mode 1: Fault Number Not Specified

When f is not provided, the algorithm:

1. Calculates the maximum possible f that satisfies n >= 3*f + 1
2. Determines m based on the weak parameter:
   • If weak=True: Minimizes m using m = (n+f+1)/2 (ceiling division)
   • If weak=False: Maximizes m using m = n-f

Mode 2: Fault Number Specified

When f is provided, the algorithm:

1. Verifies that n >= 3*f + 1 (Byzantine constraint)
2. Calculates m bounds: (n+f+1)/2 <= m <= n-f
3. Returns m based on the weak parameter (minimum or maximum bound)

Consensus Achievement

The protocol mechanics for achieving ample consensus:

1. Event Creation: Controller creates and signs a key event
2. Witness Distribution: Event is sent to all witnesses in the witness pool
3. Independent Verification: Each witness independently:
   • Verifies event signatures
   • Checks event sequence and digest chains
   • Validates against protocol rules
4. Receipt Generation: Valid events receive signed receipts from witnesses
5. Receipt Collection: Controller and validators collect witness receipts
6. Ample Verification: When receipts from m witnesses are collected, ample is achieved
7. Consensus Declaration: The event is considered to have achieved consensus

Timing and Ordering

Ample consensus has important timing properties:

• Asynchronous: Witnesses may receipt events at different times
• Eventually Consistent: Given sufficient time, honest witnesses will converge on the same event history
• No Global Clock: The protocol does not require synchronized clocks across witnesses
• Partial Ordering: Only requires ordering within a single identifier's event sequence, not global ordering across all identifiers

Security Properties

Threat Model

Ample is designed to provide security guarantees against several threat scenarios:

Dishonest Controller: A controller attempting to create conflicting versions of their key event log to different parties (duplicity attack).

Faulty Witnesses: Up to f witnesses may be compromised, offline, or behaving incorrectly.

Network Partitions: Temporary network failures that prevent some witnesses from communicating.

Eclipse Attacks: Attempts to isolate validators from honest witnesses.

Security Guarantees

The ample constraint provides several critical security properties:

Uniqueness of Agreement: At most one sufficient agreement can occur. If ample witnesses agree on an event, no other conflicting event can achieve ample agreement.

Duplicity Detection: If a controller creates conflicting events, at least one honest witness will detect the duplicity because achieving ample for both conflicting events is mathematically impossible.

Fault Tolerance: The system can tolerate up to f faulty witnesses while still achieving consensus among honest witnesses.

Accountability: Once ample consensus is achieved, the controller is accountable for that key state. Any attempt to present a different key state will be detectable as duplicity.

Attack Resistance

Sybil Attacks: Ample provides resistance to Sybil attacks because:

• Witnesses are explicitly designated by the controller in establishment events
• Adding fake witnesses requires rotating the witness set, which is a detectable event
• The n >= 3*f + 1 constraint ensures sufficient honest witnesses

Collusion Attacks: The Byzantine constraint n >= 3*f + 1 ensures that even if f witnesses collude with a dishonest controller, there are still enough honest witnesses to detect duplicity.

Denial of Service: While ample cannot prevent DoS attacks on witnesses, the threshold structure ensures that:

• Consensus can still be achieved if some witnesses are unavailable
• The system degrades gracefully as witnesses become unavailable
• No single witness can prevent consensus

Lockout Prevention

A critical security property of ample in multi-signature contexts is lockout prevention. If the signing threshold for a multi-sig group is set lower than the ample number, the group could experience accidental lockout where valid operations are blocked. By using ample as the minimum threshold, the system ensures:

• Sufficient participants are required to prevent unilateral actions
• The group cannot be locked out by unavailable participants
• The threshold balances security and availability

Interoperability

Dependencies on KERI Protocols

Ample is deeply integrated with several KERI protocol components:

KEL (Key Event Log): Ample determines when events in a KEL have achieved sufficient witness consensus to be considered stable and accountable.

KERL (Key Event Receipt Log): The KERL contains both events and receipts. Ample defines how many receipts are required for an event to be considered fully witnessed.

KAACE: Ample is a core parameter in the KERI Agreement Algorithm for Control Establishment, determining the consensus threshold.

Witnesses: The witness pool size and configuration directly determine the ample calculation.

TOAD (Threshold of Accountable Duplicity): TOAD is the controller-specified threshold that must satisfy the ample constraint.

Integration with ACDC

While ample is primarily a KERI protocol concept, it has implications for ACDC (Authentic Chained Data Container) credentials:

Issuer Key State: The key state used to sign an ACDC must have achieved ample consensus to be considered authoritative.

Delegation Chains: When ACDCs form delegation chains, each delegating identifier's key state must have achieved ample consensus.

Revocation Registries: TEL (Transaction Event Log) registries that track ACDC revocation status rely on ample consensus for their backing witnesses.

Relationship to Other Consensus Mechanisms

Ample differs from traditional consensus mechanisms:

vs. Blockchain Consensus: Unlike Proof-of-Work or Proof-of-Stake, ample does not require global ordering of all events. Each identifier has its own independent consensus domain.

vs. Practical Byzantine Fault Tolerance (PBFT): While both use Byzantine fault tolerance principles, ample is applied per-identifier rather than globally, enabling massive scalability.

vs. Raft/Paxos: These algorithms provide total ordering of events. Ample only requires ordering within a single identifier's event sequence.

Implementation Considerations

Witness Pool Sizing

Implementers must carefully consider witness pool size:

Minimum Viable Pool: The smallest practical witness pool is 3 witnesses with f=0, giving m=2. This provides minimal fault tolerance.

Recommended Pool: A pool of 5-7 witnesses with f=1 or f=2 provides good balance between security and operational complexity.

Large Pools: Pools of 10+ witnesses provide high fault tolerance but increase operational overhead and latency.

TOAD Configuration

The Threshold of Accountable Duplicity must be set appropriately:

Too Low: Setting TOAD below ample creates security vulnerabilities where insufficient witnesses could confirm conflicting events.

Too High: Setting TOAD too high reduces availability, as more witnesses must be online and responsive for consensus.

Optimal Setting: TOAD should typically equal the ample number for the desired fault tolerance level.

Performance Considerations

Latency: Achieving ample consensus requires waiting for m witnesses to respond. Network latency and witness processing time affect overall system latency.

Throughput: The need to collect ample receipts limits the rate at which events can be confirmed. Parallel processing of receipts can improve throughput.

Scalability: Because ample is calculated per-identifier, the system scales horizontally. Adding more identifiers does not increase the consensus burden on any single witness pool.

Common Implementation Challenges

Receipt Collection: Implementing efficient receipt collection and verification requires careful state management to track which witnesses have receipted which events.

Timeout Handling: Determining appropriate timeouts for witness responses requires balancing responsiveness with reliability.

Partial Receipts: Handling scenarios where some but not all witnesses respond requires implementing retry logic and fallback strategies.

Witness Rotation: When witnesses are rotated through establishment events, implementations must handle the transition period where old and new witnesses may both be active.

Reference Table

The KERI specification provides a reference table showing the relationship between total participants (N) and the minimum required ample number (M) for various fault tolerance levels. This table serves as a practical reference for system designers:

This table demonstrates how the ample number scales with the total participant count to maintain Byzantine fault tolerance properties.

Conclusion

Ample is a fundamental consensus parameter in KERI that ensures secure, fault-tolerant agreement on key state while enabling massive scalability through per-identifier consensus domains. By requiring a supermajority of witnesses to confirm events, ample provides strong security guarantees against dishonest controllers and faulty witnesses, while the mathematical constraints ensure that at most one valid consensus can emerge. This property is essential for establishing accountability in decentralized identity systems and forms the foundation for KERI's duplicity detection capabilities.

• Insufficient witnesses: When fewer than ample witnesses are available
• Timeout: When witnesses don't respond within expected timeframes
• Invalid receipts: When witness signatures don't verify
• Configuration errors: When TOAD is set below ample

Testing Considerations

Test implementations should verify:

• Ample calculation correctness for various n and f values
• Consensus achievement with exactly ample receipts
• Failure to achieve consensus with fewer than ample receipts
• Proper handling of witness failures up to the fault tolerance limit
• Lockout prevention in multi-signature scenarios