Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 170 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.
A duplicitous event log (DEL) is a verifiable data structure that records inconsistent event messages produced by a controller or witness with respect to a given Key Event Receipt Log (KERL), indexed to corresponding events in the KERL to provide cryptographic proof of duplicitous behavior.
A duplicitous event log (DEL) is a specialized data structure in KERI that serves as a forensic record of inconsistent event messages produced by a given controller or witness with respect to a specific KERL (Key Event Receipt Log). The DEL is fundamentally an indexed collection of duplicitous events where each entry references a corresponding event in the authoritative KERL.
The DEL serves three critical functions in KERI's security architecture:
The DEL is essential to KERI's duplicity detection mechanism, which distinguishes between two types of inconsistency:
As stated in the KERI specification, "a duplicitous event is a set of two or more provably mutually inconsistent event messages with respect to a KERL." The DEL captures these inconsistent message sets and indexes them to their corresponding KERL events.
Per-Entity Separation: Maintain separate DELs for each controller and each witness. Do not mix duplicity evidence from different entities in the same DEL.
Append-Only Semantics: DELs must be append-only. Never delete or modify existing entries, as this would destroy forensic evidence.
Signature Verification: Always verify signatures on duplicitous events before adding them to a DEL. Invalid signatures indicate a different type of attack (forgery) rather than duplicity.
Indexing Strategy: Implement efficient indexing by:
Compact Storage: Store only the minimal information needed to prove duplicity. Full KEL histories are not required in DELs.
CESR Encoding: Use CESR encoding for all cryptographic primitives to ensure efficient serialization and interoperability.
Compression: Consider compressing DEL entries for long-term storage, as duplicity events may be infrequent but must be retained indefinitely.
Fast Lookup: DEL queries must be fast, as validators may need to check multiple DELs during event validation.
Caching: Implement caching for frequently accessed DELs, especially for high-traffic identifiers.
Batch Queries: Support batch queries for assessing multiple identifiers or witnesses simultaneously.
Synchronization Protocol: Implement a protocol for sharing DEL entries among validators and watchers.
Verification: When receiving DEL entries from other validators, always verify the cryptographic proofs before accepting them.
Consensus: In distributed systems, use consensus mechanisms to agree on DEL contents when multiple validators detect the same duplicity.
The DEL is organized as a per-identifier, per-entity data structure. Each juror in the KERI ecosystem maintains separate DELs for:
This distributed maintenance model ensures that duplicity detection is ambient - any validator can independently verify duplicity by examining relevant DELs without requiring centralized coordination.
The DEL structure consists of:
Each entry in a DEL contains:
While the KERI specification does not mandate a specific serialization format for DELs, the logical structure includes:
DEL Entry Structure:
{
"kerl_reference": {
"aid": "<Autonomic Identifier>",
"sequence": <event sequence number>,
"digest": "<event digest>"
},
"duplicitous_events": [
{
"event": <complete event message>,
"signatures": [<signature attachments>],
"receipts": [<witness receipts if applicable>]
},
{
"event": <conflicting event message>,
"signatures": [<signature attachments>],
"receipts": [<witness receipts if applicable>]
}
],
"discovery": {
"timestamp": "<ISO 8601 timestamp>",
"source": "<discovery source>",
"context": "<discovery context>"
}
}
DEL entries leverage CESR (Composable Event Streaming Representation) encoding for cryptographic primitives, ensuring:
The event messages within DEL entries are typically serialized using:
DEL size is theoretically unbounded, as it grows with detected duplicity. However, practical constraints include:
Initialization Process:
When a juror begins monitoring an AID, it initializes empty DELs for:
These DELs remain empty unless duplicity is detected.
DELs follow an append-only model with specific update rules:
Adding Duplicity Evidence:
No Deletion Policy:
Metadata Updates:
DEL verification involves multiple steps:
Validation Algorithm:
function validateDELEntry(entry, kerl):
# Verify KERL reference exists
kerl_event = kerl.getEvent(entry.kerl_reference.sequence)
if kerl_event.digest != entry.kerl_reference.digest:
return INVALID
# Verify minimum duplicity (at least 2 versions)
if len(entry.duplicitous_events) < 2:
return INVALID
# Verify each event's signatures
for dup_event in entry.duplicitous_events:
if not verifySignatures(dup_event.event, dup_event.signatures):
return INVALID
# Verify mutual inconsistency
if not areEventsInconsistent(entry.duplicitous_events):
return INVALID
return VALID
DELs are integral to several KERI protocol operations:
KERI Core Protocol:
KAWA (KERI's Algorithm for Witness Agreement):
Judge and Jury Pools:
DEL lifecycle follows these phases:
1. Initialization Phase:
2. Active Monitoring Phase:
3. Forensic Analysis Phase:
4. Archival Phase:
DELs interact with several other KERI data structures:
Scenario 1: Controller Key Compromise
When a controller's keys are compromised, an attacker may attempt to create a conflicting rotation event:
Scenario 2: Malicious Witness
A compromised witness may provide inconsistent receipts:
Scenario 3: Ambient Duplicity Detection
The distributed nature of DEL maintenance enables ecosystem-wide duplicity detection:
DELs provide several security benefits:
Non-Repudiation: Because DEL entries contain signed event messages, duplicitous actors cannot deny their actions. The cryptographic signatures provide irrefutable proof.
Transparency: DELs make duplicity visible to the entire ecosystem, not just direct participants. This transparency deters malicious behavior.
Forensic Evidence: DELs provide permanent records for post-incident analysis, enabling root cause determination and accountability.
Trust Assessment: Validators can make informed decisions by examining DEL history, avoiding identifiers with duplicitous controllers or unreliable witnesses.
Attack Surface Reduction: The existence of DELs and the knowledge that duplicity will be permanently recorded discourages attacks, as the cost of detection is high.
When implementing DEL support:
The DEL is a cornerstone of KERI's security architecture, enabling the protocol's unique "duplicity evident" property that distinguishes it from blockchain-based and traditional PKI approaches. By making duplicity both detectable and provable, DELs ensure that malicious behavior cannot remain hidden, creating strong incentives for honest participation in the KERI ecosystem.
Access Control: Protect DEL write operations to prevent malicious actors from injecting false duplicity evidence.
Integrity Protection: Use cryptographic signatures or Merkle trees to protect DEL integrity.
Privacy: While DELs record duplicity, avoid including unnecessary information that could leak privacy about honest actors.
Audit Logging: Maintain audit logs of DEL modifications for forensic analysis.
Juror Integration: Jurors should automatically create and update DELs as part of their duplicity detection responsibilities.
Judge Integration: Judges should query DELs when determining authoritative key sets.
Validator Integration: Validators should consult DELs before trusting identifiers or witnesses.
Watcher Integration: Watchers should maintain DELs in promiscuous mode and make them queryable by validators.
Lazy Loading: Load DEL entries on-demand rather than keeping all DELs in memory.
Incremental Updates: Support incremental DEL updates rather than requiring full DEL transfers.
Pruning Strategy: While DELs are append-only, consider archiving very old entries to separate storage for performance.
Duplicity Simulation: Create test scenarios that simulate various duplicity attacks to verify DEL functionality.
Performance Testing: Test DEL query performance under load with large numbers of identifiers and duplicity events.
Consistency Testing: Verify that DELs remain consistent across distributed validators.
Recovery Testing: Test DEL recovery from backups and ensure forensic evidence is preserved.