Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 172 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.
RUN (Read, Update, Nullify) is a peer-to-peer, end-verifiable monotonic update policy that replaces traditional CRUD (Create, Read, Update, Delete) operations by eliminating server-side creation and deletion, instead using append-only logs with nullification to maintain verifiable, tamper-evident data structures in decentralized systems.
RUN (Read, Update, Nullify) represents a fundamental paradigm shift in data management for decentralized systems, replacing the traditional CRUD (Create, Read, Update, Delete) model with an approach specifically designed to protect authentic data in peer-to-peer environments. The core principle is that data always originates from a controller (the client/peer), never from a centralized server, and that all state changes are recorded in verifiable, append-only logs rather than being destructively modified or deleted.
The key properties of RUN include:
The scope of RUN extends to any system requiring verifiable data provenance in decentralized environments, particularly where multiple parties need to independently verify data authenticity without relying on trusted intermediaries.
The RUN model emerged from the recognition that traditional CRUD operations, designed for centralized client-server architectures, are fundamentally incompatible with the security requirements of decentralized identity and data systems. In traditional CRUD:
Servers in RUN-based systems operate under strict constraints:
This constrained role is enforced through:
Implementing nullification rather than deletion requires careful design:
Explicit Nullification Events: Create specific event types that mark previous data as invalid while preserving the original data in the log.
Status Fields: Include status indicators (active/nullified) that can be updated through new events.
Temporal Validity: Use timestamp-based validity periods, with nullification occurring through expiration or explicit revocation events.
Reference Preservation: Maintain references to nullified data so that the complete history remains navigable.
RUN's replay attack protection depends on proper sequencing:
Monotonically Increasing Sequence Numbers: Each event must have a sequence number strictly greater than its predecessor.
Timestamp Validation: Timestamps should be within acceptable bounds relative to the receiver's clock, accounting for network latency and clock drift.
Duplicate Detection: Systems must track previously seen sequence numbers to reject replays.
Out-of-Order Handling: Define policies for handling events that arrive out of sequence order.
Efficient RUN implementations require careful attention to storage:
Append-Only Storage: Use storage systems optimized for sequential writes (e.g., log-structured storage).
Indexing Current State: Maintain separate indices for current state to avoid replaying entire logs for queries.
These assumptions break down in decentralized systems where:
The evolution toward RUN reflects broader trends in distributed systems design, including:
KERI implements RUN as the foundational data management model for its entire protocol stack, including Key Event Logs (KELs), Transaction Event Logs (TELs), and ACDC credential registries.
In KERI's KEL implementation:
The KEL structure ensures that:
KERI's Best Available Data Acceptance (BADA) mechanism implements RUN principles for asynchronous data flows:
BADA provides a medium level of security through event ordering mechanisms, making it suitable for scenarios where the overhead of full TEL infrastructure is not justified.
TELs extend RUN to credential lifecycle management:
KERI's RUN implementation differs fundamentally from traditional database systems:
Traditional CRUD:
KERI RUN:
The RUN model in KERI provides:
RUN is particularly valuable in scenarios requiring:
Regulatory Compliance: Industries like finance and healthcare need complete audit trails that cannot be tampered with. RUN's append-only logs with nullification provide exactly this capability.
Multi-Party Workflows: When multiple organizations need to verify the same data independently, RUN enables each party to validate the complete history without trusting intermediaries.
Long-Lived Credentials: Digital credentials that may be verified years after issuance benefit from RUN's preservation of complete issuance and revocation history.
Dispute Resolution: When disagreements arise about data provenance or state changes, RUN's complete audit trail provides objective evidence.
Security: The append-only nature prevents attackers from covering their tracks by deleting evidence of compromise. Even if an attacker gains temporary control, their actions remain in the log.
Transparency: All state changes are visible to authorized parties, enabling accountability and reducing opportunities for fraud.
Resilience: Logs can be replicated across multiple parties, making the system resistant to single points of failure.
Verifiability: Cryptographic linking of events enables mathematical proof of data integrity rather than relying on trust.
Storage Requirements: Maintaining complete history requires more storage than keeping only current state. However, modern storage costs make this increasingly practical.
Complexity: Implementing append-only logs with proper cryptographic linking is more complex than traditional CRUD operations. KERI provides libraries and tools to manage this complexity.
Performance: Processing event logs to derive current state can be slower than direct database queries. KERI implementations use caching and indexing to mitigate this.
Privacy Considerations: Complete history preservation can conflict with "right to be forgotten" regulations. KERI addresses this through techniques like selective disclosure and private attributes in ACDCs.
Successful RUN implementations typically follow these patterns:
Event Sourcing: Store all state changes as events, derive current state by replaying events.
CQRS (Command Query Responsibility Segregation): Separate write operations (appending to logs) from read operations (querying current state).
Eventual Consistency: Accept that different parties may temporarily have different views of state, with convergence over time.
Snapshot + Delta: Periodically create snapshots of current state to avoid replaying entire history, with deltas for subsequent changes.
The RUN model represents a fundamental rethinking of data management for decentralized systems, trading some traditional database conveniences for the security, verifiability, and auditability essential to trustworthy digital identity and credential systems.
Snapshot Strategies: Periodically create snapshots of current state with pointers to the log position.
Archival Policies: Define policies for archiving old log segments while maintaining verifiability.
RUN systems must define consistency guarantees:
Eventual Consistency: Accept that different parties may temporarily have different views, with convergence over time.
Causal Consistency: Ensure that causally related events are seen in the correct order by all parties.
Strong Consistency: For critical operations, require synchronous confirmation from multiple parties before considering an event committed.