Process Flow

The multiplexing process in CESR follows a precise sequence enabled by the protocol's composability properties:

Step 1: Primitive Preparation

Each primitive to be multiplexed must first be properly formatted:

1. Derivation code prepending: Each primitive receives a derivation code that specifies its type and length
2. 24-bit alignment: Primitives are padded to align on 24-bit boundaries (the least common multiple of 6-bit Base64 characters and 8-bit bytes)
3. Self-framing verification: Each primitive must be independently parseable with its type, size, and value information

For example, a public key primitive in text domain might be represented as:

DKxy2sgzfplyr-tgwIxS19f2OchFHtLwPWD3v4oYimBx

Where D is the derivation code indicating an Ed25519 public key, and the remaining 43 characters encode the key value.

Step 2: Count Code Application

When multiple primitives are to be grouped, CESR uses count codes to specify the group structure:

1. Count determination: The system calculates how many primitives will be in the group
2. Count code selection: An appropriate count code is chosen from CESR's code tables
3. Count code prepending: The count code is placed at the beginning of the group

For instance, a count code -AAB might indicate "the following group contains 2 primitives in text domain."

Step 3: Concatenation

The actual multiplexing occurs through concatenation:

1. Sequential joining: Primitives are concatenated in order without delimiters
2. Group nesting: Groups can contain other groups, enabling hierarchical structures
3. Stream construction: The final multiplexed stream is a continuous sequence of characters (text domain) or bytes (binary domain)

A multiplexed stream might look like:

-AABDKxy2sgzfplyr-tgwIxS19f2OchFHtLwPWD3v4oYimBx0BDQzNTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0

Where:

• -AAB = count code (2 primitives follow)
• DKxy... = first primitive (public key)
• 0BDQ... = second primitive (signature)

Step 4: Domain Transformation (Optional)

CESR's composability property enables domain transformation:

1. Text-to-binary conversion: The entire multiplexed stream can be converted from text (Base64) to binary domain
2. Preservation of structure: Count codes and primitive boundaries are maintained during conversion
3. Round-trip capability: The stream can be converted back to text domain without loss

This transformation satisfies the formal composability requirement:

T(cat(b[k])) = cat(T(b[k])) for all k
B(cat(t[k])) = cat(B(t[k])) for all k

State Changes During Multiplexing

The multiplexing process involves several state transitions:

Initial state: Individual primitives exist as separate data structures ↓ Framing state: Each primitive is wrapped with its derivation code and aligned ↓ Grouping state: Count codes are applied to define group boundaries ↓ Concatenated state: Primitives are joined into a continuous stream ↓ Transmitted state: Stream is sent over network channel ↓ Demultiplexed state: Receiving parser separates primitives back into individual components

Decision Points

Key decision points in the multiplexing process:

1. Text vs. Binary domain: Choose encoding based on use case (text for debugging/logging, binary for bandwidth efficiency)
2. Group structure: Determine whether flat concatenation or hierarchical nesting is appropriate
3. Count code selection: Select from multiple count code tables based on primitive types and quantities
4. Alignment strategy: Decide on pre-padding approach to achieve 24-bit boundaries

Technical Requirements

Cryptographic Requirements

Multiplexing in CESR must maintain cryptographic integrity:

1. Non-repudiable signatures: Indexed signatures must remain verifiable after multiplexing
2. Digest preservation: SAIDs (Self-Addressing Identifiers) must maintain their cryptographic binding to content
3. Key authenticity: Public keys must remain cryptographically verifiable against their derivation codes
4. Threshold satisfaction: Multi-signature schemes must preserve threshold requirements through the multiplexing process

Timing Considerations

The multiplexing process has specific timing characteristics:

Stream processing speed: CESR is designed to support high-bandwidth applications. As documented in [Document 3], modern datacenter cores operate at approximately 5 GHz, while network pipelines reach 40 GHz. This 8x speed differential necessitates the parallel processing capabilities that multiplexing enables.

Look-ahead capability: Unlike JSON which requires parsing the entire stream to determine boundaries, CESR's self-framing design allows parsers to determine chunk sizes immediately by reading count codes. This eliminates sequential parsing bottlenecks.

Pipelining latency: The multiplexing/demultiplexing cycle must be fast enough to support real-time witness receipt collection and key event validation in KERI networks.

Error Handling

Multiplexing implementations must handle several error conditions:

1. Malformed primitives: Detection of primitives that violate 24-bit alignment requirements
2. Invalid count codes: Handling of count codes that don't match actual primitive counts
3. Truncated streams: Recovery when network transmission cuts off mid-primitive
4. Domain conversion failures: Detection of primitives that cannot be converted between text and binary domains
5. Nested group violations: Validation that hierarchical structures maintain proper nesting

Alignment Constraints

The fundamental technical constraint is 24-bit boundary alignment:

• Text domain: All primitives must be integer multiples of 4 Base64 characters (4 × 6 bits = 24 bits)
• Binary domain: All primitives must be integer multiples of 3 bytes (3 × 8 bits = 24 bits)
• Pad size calculation: ps = (3 - (N mod 3)) mod 3 where N is raw binary length

This constraint ensures that no bits from adjacent primitives share the same character or byte after domain conversion, which is essential for maintaining the composability property.

Usage Patterns

Pattern 1: KEL Transmission

When transmitting a Key Event Log, multiplexing combines:

• Inception events with their signatures
• Rotation events with witness receipts
• Interaction events with anchored data

Example structure:

[Count Code: 3 events]
  [Inception Event]
    [Event Data]
    [Controller Signature]
    [Witness Receipt 1]
    [Witness Receipt 2]
  [Rotation Event]
    [Event Data]
    [Controller Signature]
    [Witness Receipts...]
  [Interaction Event]
    [Event Data]
    [Anchored SAID]

Pattern 2: ACDC Credential Chains

ACDC credentials often form chains where one credential references another. Multiplexing enables efficient transmission:

[Count Code: Credential Chain]
  [Root Credential SAID]
  [Root Credential Signature]
  [Delegated Credential SAID]
  [Delegated Credential Signature]
  [Presentation Proof]

This pattern is particularly important for vLEI credentials where QVI credentials delegate to Legal Entity credentials, which in turn delegate to role credentials.

Pattern 3: Witness Receipt Aggregation

When collecting receipts from multiple witnesses, multiplexing combines:

[Count Code: N witnesses]
  [Witness 1 AID]
  [Witness 1 Receipt Signature]
  [Witness 2 AID]
  [Witness 2 Receipt Signature]
  ...
  [Witness N AID]
  [Witness N Receipt Signature]

This enables efficient verification of KAACE (KERI Agreement Algorithm for Control Establishment) consensus.

Pattern 4: Hierarchical Composition

CESR supports nested multiplexing for complex structures:

[Outer Count Code]
  [Inner Group 1]
    [Count Code]
    [Primitive 1.1]
    [Primitive 1.2]
  [Inner Group 2]
    [Count Code]
    [Primitive 2.1]
    [Primitive 2.2]
    [Primitive 2.3]
  [Standalone Primitive]

This hierarchical capability enables pipelining where different groups can be routed to different processor cores for parallel processing.

Best Practices

1. Use appropriate count codes: Select count codes that match the actual number and type of primitives to avoid parsing errors

2. Maintain deterministic ordering: KERI and ACDC require deterministic field ordering; maintain this in multiplexed streams

3. Leverage domain conversion: Use text domain for debugging and logging, binary domain for production transmission

4. Implement sniffability: Begin streams with group codes or field maps to enable automatic format detection by sniffers

5. Plan for demultiplexing: Structure multiplexed streams to facilitate efficient parallel processing during demultiplexing

6. Validate alignment: Verify 24-bit alignment before transmission to prevent composability violations

Integration Considerations

With KERI event streams: Multiplexing must preserve the cryptographic integrity of key events and their receipts. The KEL structure must remain verifiable after demultiplexing.

With ACDC credentials: When multiplexing ACDCs, preserve the SAID references that create the directed acyclic graph structure of chained credentials.

With IPEX exchanges: IPEX messages often contain multiplexed credentials and proofs. The multiplexing must support graduated disclosure patterns where different recipients receive different levels of detail.

With witness networks: Multiplexed witness receipts must support threshold satisfaction verification and duplicity detection.

Performance Implications

The multiplexing capability is critical for KERI's scalability:

Parallel processing: By enabling demultiplexing across multiple cores, CESR multiplexing allows systems to process event streams at rates matching network bandwidth (40 GHz) rather than being limited by single-core processing speed (5 GHz).

Bandwidth efficiency: Binary domain multiplexing reduces transmission overhead compared to text-based formats like JSON, which require structural delimiters and cannot be efficiently demultiplexed.

Stream pipelining: The combination of multiplexing (combining) and demultiplexing (separating) enables true pipelining where data flows through multiple processing stages in parallel.

Relationship to Traditional Multiplexing

While CESR multiplexing shares the name with traditional telecommunications multiplexing (combining multiple signals over a shared medium), it extends the concept with cryptographic properties:

Traditional multiplexing: Combines analog or digital signals for transmission efficiency

CESR multiplexing: Combines cryptographic primitives while maintaining:

• Individual primitive verifiability
• Composability across text/binary domains
• Self-framing for autonomous parsing
• Hierarchical nesting capability
• Cryptographic integrity preservation

This makes CESR multiplexing uniquely suited for verifiable data structures in decentralized identity systems where both efficiency and cryptographic verifiability are essential.

Performance Optimization

1. Minimize memory allocation: Reuse buffers for multiplexing operations
2. Implement zero-copy parsing: Where possible, reference primitives in-place rather than copying
3. Cache count code lookups: Frequently used count codes should be cached for fast access
4. Profile demultiplexing paths: Optimize the critical path for separating multiplexed streams

Error Handling

Robust implementations must handle:

1. Truncated streams: Detect when network transmission cuts off mid-primitive
2. Count code mismatches: Validate that actual primitive count matches count code
3. Invalid primitives: Reject primitives with malformed derivation codes
4. Alignment violations: Detect and report primitives that violate 24-bit boundaries

Testing Requirements

1. Composability tests: Verify round-trip conversion for all primitive types
2. Stress tests: Test with large numbers of multiplexed primitives
3. Nesting tests: Validate hierarchical composition with various nesting depths
4. Interoperability tests: Ensure multiplexed streams can be parsed by other CESR implementations

Integration with KERI

When integrating multiplexing with KERI:

1. Preserve event ordering: KEL events must maintain chronological order through multiplexing
2. Support witness receipt aggregation: Enable efficient collection of receipts from multiple witnesses
3. Maintain cryptographic integrity: Ensure signatures remain verifiable after demultiplexing
4. Support IPEX patterns: Enable graduated disclosure through selective multiplexing