Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 22 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
Liveness is a property of concurrent and distributed systems guaranteeing that "something good will eventually occur" - the system continues to make progress despite processes competing for critical sections. KERI deliberately omits strict liveness guarantees in favor of safety, decentralization, and eventual consistency.
Liveness is a fundamental property in concurrent and distributed systems theory that ensures a system makes continuous progress toward completing operations, even when multiple processes must coordinate access to shared resources or critical sections of code. The defining characteristic of liveness is the guarantee that "something good will eventually occur" - meaning the system will not become permanently stuck, deadlocked, or unable to complete legitimate operations.
In formal terms, liveness properties state that certain desirable events will eventually happen, contrasting with safety properties which state that certain undesirable events will never happen. All system properties can be expressed as the intersection of safety and liveness properties, making this distinction foundational to reasoning about distributed system correctness.
Liveness becomes particularly challenging in systems where:
Liveness guarantees emerged from early research into concurrent programming and distributed consensus. The concept gained prominence through:
Classical Consensus Problems: The Byzantine Generals Problem highlighted the difficulty of achieving both safety (agreement on correct values) and liveness (eventually reaching agreement) in adversarial distributed environments.
Practical Byzantine Fault Tolerance (pBFT): The pBFT algorithm demonstrated that Byzantine fault tolerant systems could achieve both safety and liveness efficiently, becoming the prototypical model for Byzantine agreement. pBFT guarantees that honest nodes will eventually reach consensus despite up to f Byzantine failures in a system of 3f+1 nodes.
Implementations should define application-specific timeout policies for witness agreement:
No protocol-level timeout is specified because liveness is not guaranteed.
Validators should implement redundant querying:
Controllers must implement recovery mechanisms for liveness failures:
Production systems should monitor:
Test suites should explicitly verify correct behavior during liveness failures:
CAP Theorem Implications: The CAP theorem established that distributed systems cannot simultaneously guarantee Consistency, Availability, and Partition tolerance. Liveness relates closely to availability - systems prioritizing liveness may sacrifice consistency during partitions, while systems prioritizing safety may sacrifice liveness.
Blockchain Consensus: Proof-of-Work blockchains like Bitcoin prioritize liveness (the chain always grows) while accepting temporary safety violations (chain reorganizations). This represents a deliberate trade-off where eventual consistency is deemed acceptable for the use case.
KERI takes a fundamentally different approach to liveness compared to traditional distributed consensus systems. As Samuel Smith characterizes it: "What if PBFT and Stellar had a baby that was missing liveness and total ordering but had safety and was completely decentralized, portable, and permission-less? It would be named KERI."
KERI's KAACE (KERI's Agreement Algorithm for Control Establishment) intentionally omits strict liveness guarantees. This design choice reflects KERI's priorities:
Safety Over Liveness: KERI prioritizes duplicity detection and safety guarantees over ensuring all operations eventually complete. If a controller attempts to create conflicting versions of their KEL, the system will detect this duplicity even if it cannot immediately resolve which version is authoritative.
Eventual Consistency Model: Rather than requiring immediate global consensus, KERI operates on an eventual consistency model where:
Decentralized Operation: By not requiring liveness, KERI avoids the coordination overhead that would necessitate:
This enables KERI to operate in highly asynchronous, partition-prone environments where strict liveness guarantees would be impractical or impossible to maintain.
The KAACE algorithm establishes control authority through witness agreement:
Critically, this process does not guarantee that agreement will be reached within any bounded time. If network partitions prevent witness communication, or if Byzantine witnesses refuse to participate, the system may not reach agreement. However, KERI's design ensures:
Safety is Maintained: Even without agreement, no witness will accept conflicting events as valid
Duplicity is Detectable: If a controller attempts to create multiple versions, honest witnesses will retain evidence of both versions
Recovery is Possible: Controllers can use key rotation to recover from situations where agreement cannot be reached
KERI introduces a novel separation of concerns between:
Promulgation Networks (witnesses): Designated by controllers to provide initial event validation and receipt generation. Witnesses do not require liveness guarantees - they simply record and sign events they observe.
Confirmation Networks (watchers): Selected by validators to independently monitor for duplicity. Watchers operate in promiscuous mode, accepting all events without requiring agreement, enabling ambient duplicity detection.
This separation means that even if the promulgation network fails to reach agreement (violating liveness), the confirmation network can still detect and report duplicity, maintaining the system's security properties.
By sacrificing liveness, KERI gains:
Complete Decentralization: No central coordinator or leader election required
Portability: KELs can be moved between infrastructures without protocol changes
Permission-less Operation: No gatekeepers or authorization requirements for participation
Scalability: No global synchronization bottleneck limiting throughput
Partition Tolerance: System continues operating correctly during network partitions
The cost is that KERI cannot guarantee:
Immediate Finality: Events may not be immediately confirmed by all witnesses
Bounded Latency: No upper bound on time to reach witness agreement
Guaranteed Progress: Controllers may need to take recovery actions if agreement fails
KERI's approach is particularly well-suited for identity and credential systems where:
Duplicity Detection Suffices: Detecting that a controller attempted to create conflicting key states is often more important than immediately resolving which state is correct. The existence of duplicity evidence itself invalidates the controller's trustworthiness.
Human-in-the-Loop Resolution: Identity disputes often require human judgment and legal processes anyway. KERI provides cryptographic evidence for these processes rather than attempting algorithmic resolution.
Long-Lived Identifiers: Identity systems operate over years or decades. Temporary delays in witness agreement are acceptable when identifiers persist for extended periods.
Asynchronous Verification: Verifiers can independently validate KELs without requiring real-time consensus, enabling offline verification and audit.
Implementers must understand that:
Controllers May Need Retry Logic: If witness agreement fails, controllers may need to re-promulgate events or rotate to a new witness set
Validators Should Monitor Multiple Sources: Relying on a single witness or watcher creates vulnerability to liveness failures. Validators should query multiple sources and compare results.
Recovery Mechanisms Are Essential: Key rotation and delegation provide recovery paths when liveness failures prevent normal operation
Timeout Policies Are Application-Specific: Applications must define their own timeout policies for how long to wait for witness agreement based on their risk tolerance and operational requirements
Unlike blockchain systems that prioritize liveness (the chain always grows), KERI prioritizes safety (no conflicting states are accepted as valid). This makes KERI suitable for:
High-Stakes Identity: Where accepting an invalid identity is worse than temporarily being unable to verify an identity
Regulatory Compliance: Where audit trails and duplicity evidence are more important than immediate transaction finality
Decentralized Trust: Where no single party should have the power to force consensus or censor participants
The trade-off is that KERI is not suitable for applications requiring:
Liveness represents a fundamental property of distributed systems, but KERI demonstrates that not all distributed systems require liveness guarantees. By deliberately omitting liveness in favor of safety, decentralization, and duplicity detection, KERI creates a practical foundation for decentralized identity systems that can operate in highly asynchronous, partition-prone environments while maintaining strong security properties. Understanding this design choice is essential for correctly implementing and deploying KERI-based systems.