Unheaded Kingdom S. Bellis Internet-Draft Unheaded Intended status: Experimental 19 March 2026 Expires: 20 September 2026 Shim Pipeline Specification for the Unheaded Protocol Computer draft-bellis-unheaded-shim-00 Abstract This document specifies the Shim pipeline for the Unheaded Protocol Computer (UPC). The Shim translates MBC (Monad Bytecode) programs into eBPF execution contexts, defines the per-hop processing model, and specifies the tick packet protocol that drives distributed computation across IPv6 network hops. The pipeline implements a four-stage architecture: Assembly, Verification, Loading, and Execution, with integrated support for memory-mapped I/O, framebuffer rendering, and CRC validation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them except as reference to a "work in progress." This Internet-Draft will expire on September 18, 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Bellis Expires 20 September 2026 [Page 1] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info/) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Relationship to Other Specifications . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Pipeline Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Stage 1: Assembly . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Input Format . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Binary Encoding . . . . . . . . . . . . . . . . . . . . . 7 4.3. Label Resolution . . . . . . . . . . . . . . . . . . . . 7 5. Stage 2: Verification . . . . . . . . . . . . . . . . . . . . 8 Bellis Expires 20 September 2026 [Page 2] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 5.1. Opcode Whitelist . . . . . . . . . . . . . . . . . . . . 8 5.2. Register Range Validation . . . . . . . . . . . . . . . . 8 5.3. Immediate Value Range Validation . . . . . . . . . . . . 8 5.4. Branch Target Validation . . . . . . . . . . . . . . . . 9 6. Stage 3: Loading . . . . . . . . . . . . . . . . . . . . . . 9 6.1. BPF Map Structures . . . . . . . . . . . . . . . . . . . 9 6.1.1. ROM_MAP . . . . . . . . . . . . . . . . . . . . . . . 9 6.1.2. RAM_MAP . . . . . . . . . . . . . . . . . . . . . . . 9 6.1.3. CPU_MAP . . . . . . . . . . . . . . . . . . . . . . . 10 6.1.4. SCREEN_MAP . . . . . . . . . . . . . . . . . . . . . 10 6.1.5. KBD_MAP . . . . . . . . . . . . . . . . . . . . . . . 11 6.1.6. Additional Maps . . . . . . . . . . . . . . . . . . . 11 6.2. Loading Sequence . . . . . . . . . . . . . . . . . . . . 11 7. Stage 4: Execution . . . . . . . . . . . . . . . . . . . . . 11 7.1. Fetch-Decode-Execute Cycle . . . . . . . . . . . . . . . 12 7.2. Instruction Limit and BPF Verifier Compliance . . . . . . 12 7.3. State Persistence . . . . . . . . . . . . . . . . . . . . 12 8. Tick Packet Protocol . . . . . . . . . . . . . . . . . . . . 12 8.1. Packet Structure . . . . . . . . . . . . . . . . . . . . 13 8.2. Processing Pipeline . . . . . . . . . . . . . . . . . . . 13 8.3. Tick Rates . . . . . . . . . . . . . . . . . . . . . . . 14 9. Memory-Mapped I/O . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Physical Address Map . . . . . . . . . . . . . . . . . . 14 9.2. Keyboard Access (0x0006_8000) . . . . . . . . . . . . . . 14 9.3. Framebuffer Access (0x0007_0000) . . . . . . . . . . . . 15 9.4. TTY/Console I/O (0x0007_F000 – 0x0007_FFFF) . . . . . . . 15 10. Framebuffer Specification . . . . . . . . . . . . . . . . . . 15 10.1. Dimensions and Layout . . . . . . . . . . . . . . . . . 15 10.2. Pixel Address Calculation . . . . . . . . . . . . . . . 16 10.3. Access Methods . . . . . . . . . . . . . . . . . . . . . 16 11. Dream Ladder Feature Stratification . . . . . . . . . . . . . 16 11.1. Conformance Levels . . . . . . . . . . . . . . . . . . . 16 11.1.1. Level 0: Microcode (Required) . . . . . . . . . . . 16 11.1.2. Level 1: Digital (Required) . . . . . . . . . . . . 16 11.1.3. Level 2: Mechanical (Required) . . . . . . . . . . . 17 11.1.4. Level 2a: Memory I/O (Recommended) . . . . . . . . . 17 11.1.5. Level 3: Interrupts and Exceptions (Optional) . . . 17 11.1.6. Level 4: Scheduling and Multitasking (Optional) . . 18 11.1.7. Level 5+: Virtual Memory, Syscalls, Filesystem (Future) . . . . . . . . . . . . . . . . . . . . . . 18 11.2. Conformance Declaration . . . . . . . . . . . . . . . . 18 12. CRC Validation Ordering . . . . . . . . . . . . . . . . . . . 18 12.1. Pre-Execution Validation . . . . . . . . . . . . . . . . 18 12.2. Post-Execution Recomputation . . . . . . . . . . . . . . 19 12.3. Anomaly Event Format . . . . . . . . . . . . . . . . . . 19 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 13.1. Shim Pipeline Stage Registry . . . . . . . . . . . . . . 19 13.2. BPF Map Type Registry for UPC . . . . . . . . . . . . . 20 Bellis Expires 20 September 2026 [Page 3] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 13.3. Dream Ladder Level Registry . . . . . . . . . . . . . . 20 14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 14.1. Primary Security Boundary: eBPF Verifier . . . . . . . . 21 14.2. CPU Exhaustion Prevention . . . . . . . . . . . . . . . 21 14.3. Memory Access Control . . . . . . . . . . . . . . . . . 21 14.4. Packet Leakage Prevention . . . . . . . . . . . . . . . 22 14.5. Tick Packet Injection Trust Model . . . . . . . . . . . 22 14.6. Register State Confidentiality . . . . . . . . . . . . . 22 14.7. Verification as a Security Gate . . . . . . . . . . . . 22 15. Normative References . . . . . . . . . . . . . . . . . . . . 22 16. Informative References . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The Shim is the execution engine of the Unheaded Protocol Computer (UPC), responsible for translating and executing Monad Bytecode (MBC) programs within eBPF runtime contexts. It forms the critical bridge between the declarative instruction set defined by the MBC ISA and the native eBPF verifier and execution model of the Linux kernel. The Shim operates within a four-stage pipeline: 1. Assembly: Text MBC programs are assembled into binary images 2. Verification: Assembled programs are validated against security and conformance rules 3. Loading: Verified programs and supporting data structures are loaded into BPF maps 4. Execution: The fetch-decode-execute cycle runs within XDP context, processing tick packets This specification defines: * The binary encoding of MBC programs and instruction formats * Verification rules enforced before loading and execution * BPF map structures supporting program state, memory, and I/O * The tick packet protocol that drives distributed computation * Memory-mapped I/O semantics for framebuffer and keyboard access * The Dream Ladder stratification model for conformance levels Bellis Expires 20 September 2026 [Page 4] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 1.1. Relationship to Other Specifications The Shim pipeline operates in conjunction with several related specifications in accordance with [RFC8126]: * The Protocol Foundation specification defines the Monad wire format (20-byte fixed header carried in IPv6 Hop-by-Hop options per [RFC8200]), which encodes register state and control flags at each hop * The MBC ISA specification specifies the MBC instruction set architecture (48 opcodes, 16-register architecture, 32-bit words) * The Sophia Dictionary specification defines dictionary lookup semantics used during MBC execution * The Wotan Memory Model specification specifies the BPF map memory model backing the Shim's RAM_MAP and ROM_MAP structures 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Pipeline Overview The Shim pipeline transforms MBC source code into executable packet processing logic through four sequential stages: ┌─────────────────────────────────────────────────────┐ │ MBC Source Code (Text) │ └──────────────────┬──────────────────────────────────┘ │ ▼ ╔════════════════════════════╗ ║ Stage 1: Assembly ║ ║ • Label resolution ║ ║ • Instruction encoding ║ ║ • Binary image output ║ ╚════════════┬═══════════════╝ │ ▼ ┌─────────────────────────────────────────────────────┐ │ Binary Program Image (32-bit words, little-endian) │ └──────────────────┬──────────────────────────────────┘ Bellis Expires 20 September 2026 [Page 5] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 │ ▼ ╔════════════════════════════╗ ║ Stage 2: Verification ║ ║ • Opcode whitelist ║ ║ • Register range check ║ ║ • Immediate range check ║ ║ • Branch target check ║ ╚════════════┬═══════════════╝ │ ▼ ┌─────────────────────────────────────────────────────┐ │ Verified Program Image │ └──────────────────┬──────────────────────────────────┘ │ ▼ ╔════════════════════════════╗ ║ Stage 3: Loading ║ ║ • Create BPF maps ║ ║ • Populate ROM_MAP ║ ║ • Initialize CPU state ║ ║ • Attach XDP program ║ ╚════════════┬═══════════════╝ │ ▼ ┌─────────────────────────────────────────────────────┐ │ Loaded Program in BPF Runtime │ └──────────────────┬──────────────────────────────────┘ │ ▼ ╔════════════════════════════╗ ║ Stage 4: Execution ║ ║ • Fetch-decode-execute ║ ║ • XDP invocation loop ║ ║ • Tick packet processing ║ ║ • State persistence ║ ╚════════════┬═══════════════╝ │ ▼ ┌─────────────────────────────────────────────────────┐ │ Output: Monad state via XDP_TX │ └─────────────────────────────────────────────────────┘ Each stage is atomic and idempotent. Programs rejected at Verification are never loaded. Programs that fail CRC validation during Execution emit an Anomaly event but do not execute MBC. Bellis Expires 20 September 2026 [Page 6] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 4. Stage 1: Assembly Assembly translates MBC instruction mnemonics into a binary program image. 4.1. Input Format MBC assembly is plain text, one instruction per line. Comments begin with '#' and extend to end of line. Blank lines are ignored. Labels are declared with a trailing colon and must appear alone on a line. # FizzBuzz example MOVI r0, 1 # Initialize r0 = 1 loop: ADDI r0, r0, 1 # Increment r0 JNE r0, 100, loop # Jump if not equal MOV r1, r0 # Move result to r1 HALT # Stop execution 4.2. Binary Encoding The output is a sequence of 32-bit words in little-endian byte order. Each instruction encodes to one word with format: Bits 31-26 25-20 19-14 13-8 7-2 1-0 ┌──────────┬──────┬──────┬──────┬────┬──┐ │ Opcode │ Dest │ Src1 │ Src2 │Imm │Rsvd│ │ (6 bits) │(6b) │(6b) │(6b) │(4b)│(2b)│ └──────────┴──────┴──────┴──────┴────┴──┘ Example encoding of MOVI r0, 42: Instruction: MOVI r0, 42 Opcode: 0x0F (MOVI) Destination: r0 (0) Immediate: 42 (0x2A) Binary: 0x0F00002A (little-endian) Bytes: 2A 00 00 0F 4.3. Label Resolution The assembler performs two passes: 1. First pass: Record label offsets (word addresses in the program image) Bellis Expires 20 September 2026 [Page 7] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 2. Second pass: Replace label references in branch instructions with computed offsets Label references are resolved as relative word offsets from the branch instruction's position. A label at word address N referenced from instruction at word address M becomes offset (N - M). 5. Stage 2: Verification Verification enforces security and correctness constraints before a program is loaded. Programs MUST pass verification or be rejected entirely. 5.1. Opcode Whitelist Only 48 opcodes are valid. The verifier MUST reject any program containing an opcode not in the following list: Valid opcodes: 0x00 HALT 0x01 NOP 0x02 MOV 0x03 MOVI 0x04 ADD 0x05 ADDI 0x06 SUB 0x07 SUBI 0x08 MUL 0x09 MULI 0x0A DIV 0x0B DIVI 0x0C MOD 0x0D MODI 0x0E AND 0x0F OR 0x10 XOR 0x11 NOT 0x12 SHL 0x13 SHR 0x14 LD 0x15 LDI 0x16 ST 0x17 STI 0x18 JMP 0x19 JEQ 0x1A JNE 0x1B JLT 0x1C JGT 0x1D CALL 0x1E RET 0x1F PUSH 0x20 POP 0x21 PUSHI 0x22 SYSCALL 0x23 LDMAP 0x24 STMAP 0x25 DICTLOOKUP 0x26 CRC16 0x27 FLAG 0x28 RFLAG 0x29 RESERVED 0x2A RESERVED 0x2B RESERVED 0x2C RESERVED 0x2D RESERVED ... 5.2. Register Range Validation All register references MUST be in range [0, 15]. The verifier MUST reject programs with register fields containing values greater than 15. 5.3. Immediate Value Range Validation Immediate values occupy 4 bits in the instruction encoding. MOVI and ADDI instructions with immediate values larger than 15 MUST be rejected at verification time. Programs requiring larger immediates MUST use multi-instruction sequences or load from ROM_MAP. Bellis Expires 20 September 2026 [Page 8] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 5.4. Branch Target Validation Branch instructions (JMP, JEQ, JNE, JLT, JGT) MUST have target offsets that: * Point to valid instruction boundaries (word-aligned addresses within the program image) * Do not exceed the program image bounds * Do not form backward branches with unbounded depth (prevent infinite loops without instruction limit enforcement) 6. Stage 3: Loading Loading creates the runtime BPF map structures and initializes program state. All maps MUST be created before the program begins execution. 6.1. BPF Map Structures 6.1.1. ROM_MAP ROM_MAP stores the immutable program image and constant data. * Type: BPF_MAP_TYPE_ARRAY * Entries: 262,144 (2^18) * Value size: 4 bytes per entry * Total size: 1 MiB * Access: Read-only during execution Verified program image is populated into ROM_MAP starting at index 0. Unused entries are zero-filled. 6.1.2. RAM_MAP RAM_MAP provides the flat address space for data memory and dynamic state. * Type: BPF_MAP_TYPE_ARRAY * Entries: 16,777,216 (2^24) * Value size: 4 bytes per entry Bellis Expires 20 September 2026 [Page 9] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 * Total size: 64 MiB * Access: Read-write during execution RAM_MAP is initialized to zero. Memory layout is defined in Section 7 (Memory-Mapped I/O). 6.1.3. CPU_MAP CPU_MAP maintains per-flow CPU state across distributed hops. * Type: BPF_MAP_TYPE_HASH * Max entries: 256 * Value size: 128 bytes (MbcCpuState structure) * Key: Flow tuple (source, destination, flow label) MbcCpuState structure contains: * r0-r15: 16 x 32-bit general-purpose registers * pc: 32-bit program counter (word address) * sp: 32-bit stack pointer (byte address) * flags: 16-bit condition code flags * ticks: 32-bit execution tick counter * reserved: 8 bytes for future extension 6.1.4. SCREEN_MAP SCREEN_MAP provides memory-mapped framebuffer access. * Type: BPF_MAP_TYPE_ARRAY * Entries: 64,000 * Value size: 1 byte per entry * Total size: 64 KiB * Layout: 320x200 pixels, 8-bit palette indices Bellis Expires 20 September 2026 [Page 10] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 6.1.5. KBD_MAP KBD_MAP provides memory-mapped keyboard input. * Type: BPF_MAP_TYPE_ARRAY * Entries: 8 * Value size: 4 bytes per entry * Total size: 32 bytes * Layout: Bitmask of 256 key states (1 bit per key) 6.1.6. Additional Maps The following maps support extended functionality: * TTY_MAP: Terminal I/O ring buffer * PROC_TABLE: Process/thread state management * SCHED_STATE: Scheduler state (Level 3+ feature) * TLB_MAP: Virtual memory translation cache (Level 3+ feature) * COMPUTE_EVENTS: Event log for anomalies and diagnostics 6.2. Loading Sequence 1. Create all BPF maps in kernel 2. Populate ROM_MAP with verified program image 3. Initialize CPU_MAP with default CPU state (all registers zero, pc=0, sp=0, flags=0) 4. Zero-fill RAM_MAP 5. Attach XDP program to network interface 6. Enable the program for packet processing 7. Stage 4: Execution Execution implements the fetch-decode-execute cycle within XDP context, processing one instruction per invocation up to a 256-instruction limit. Bellis Expires 20 September 2026 [Page 11] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 7.1. Fetch-Decode-Execute Cycle Loop: 1. Fetch: Read instruction from ROM[pc] 2. Decode: Parse opcode and operand fields 3. Execute: Perform operation, update registers/memory 4. Increment: pc += 1 5. Check limit: if ticks >= 256 or HALT, exit loop 6. Else: goto Loop 7.2. Instruction Limit and BPF Verifier Compliance Each XDP invocation MUST execute at most 256 instructions. This limit: * Prevents CPU exhaustion attacks * Ensures bounded execution time * Complies with BPF verifier's loop detection requirements * Enables predictable per-hop processing latency If an instruction limit is reached without HALT, the program suspends and resumes at the next tick packet. PC and register state persist via CPU_MAP across ticks. 7.3. State Persistence Program state persists across tick packets via BPF maps: * CPU_MAP: PC, registers, flags persist across ticks * RAM_MAP: Memory contents persist across ticks * SCREEN_MAP: Framebuffer contents persist across ticks State is keyed by flow tuple (source IP, destination IP, flow label). Different flows maintain independent execution contexts. 8. Tick Packet Protocol Tick packets are IPv6 packets [RFC8200] carrying Monad state and driving distributed computation across hops, with Shim programs verified against the BPF instruction set defined in [RFC9669]. Bellis Expires 20 September 2026 [Page 12] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 8.1. Packet Structure A tick packet consists of: 1. IPv6 Fixed Header (40 bytes) 2. Hop-by-Hop Options Header (24 bytes, containing Monad register file) 3. Payload (variable, application-specific data) ┌─────────────────────────────────┐ │ IPv6 Fixed Header (40 B) │ │ • Version (4b) │ │ • Traffic Class (8b) │ │ • Flow Label (20b) │ │ • Payload Length (16b) │ │ • Next Header (8b) = 0 (HbH) │ │ • Hop Limit (8b) │ │ • Source Address (128b) │ │ • Destination Address (128b) │ └─────────────────────────────────┘ │ ▼ ┌─────────────────────────────────┐ │ Hop-by-Hop Options (24 B) │ │ • Next Header (8b) │ │ • Hdr Ext Len (8b) = 2 │ │ • Padding (16b) │ │ • Option Type: 0x3E (Monad) │ │ • Option Data Len (8b) = 20 │ │ • Monad Register File (20 B) │ │ (per draft-bellis-foundation) │ └─────────────────────────────────┘ │ ▼ ┌─────────────────────────────────┐ │ Payload (variable) │ │ Application-specific data │ └─────────────────────────────────┘ 8.2. Processing Pipeline 1. Packet arrives at ingress interface 2. XDP program extracts Monad state from HbH option 3. Load/initialize CPU_MAP entry from Monad state Bellis Expires 20 September 2026 [Page 13] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 4. Validate Monad CRC-16/CCITT (MUST reject if invalid) 5. Execute MBC program (up to 256 instructions) 6. Recompute Monad CRC-16/CCITT 7. Write updated Monad state to packet HbH option 8. Return XDP_TX (bounce packet to next hop or originating interface) 8.3. Tick Rates Tick packet generation rates vary by operational mode: * LOCAL mode (single-hop loopback): 35 Hz (28 ms between ticks) * DISTRIBUTED mode (multi-hop propagation): ~1 kHz (1 ms between ticks, governed by network propagation) Tick rate is controlled by application logic, not the Shim itself. The Shim simply processes each arriving tick packet up to its 256-instruction limit. 9. Memory-Mapped I/O The Shim provides a unified 32-bit flat address space with reserved regions for memory-mapped I/O. 9.1. Physical Address Map Address Range Size Device Access ───────────────────────────────────────────────────────────── 0x0000_0000-0x0003_FFFF 256 KB ROM R 0x0004_0000-0x0006_7FFF 160 KB Reserved - 0x0006_8000-0x0006_8FFF 4 KB Keyboard (KBD_MAP) R 0x0006_9000-0x0006_FFFF 28 KB Reserved - 0x0007_0000-0x0007_FFFF 64 KB Framebuffer R/W 0x0008_0000-0xFFFF_FFFF 4GB - RAM (RAM_MAP) R/W 9.2. Keyboard Access (0x0006_8000) Keyboard state is exposed as an 8-entry array of 32-bit values, where each bit represents one key state (1 = pressed, 0 = released). Total of 256 keys supported. Bellis Expires 20 September 2026 [Page 14] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 LD r0, 0x68000 # Load keyboard state word 0 LDI r1, 1 # Shift amount for key 1 (ESC) SHR r0, r0, r1 # Shift right by 1 AND r0, r0, 1 # Mask for single bit # r0 now contains ESC key state (1 if pressed, 0 if not) 9.3. Framebuffer Access (0x0007_0000) The framebuffer is a 320x200 pixel display with 8-bit palette indices. Pixel (x, y) is stored at byte address 0x70000 + (y * 320) + x. # Write color 42 to pixel (x=100, y=50) MOVI r0, 100 # x coordinate MOVI r1, 50 # y coordinate # Calculate offset: y * 320 + x MULI r2, r1, 320 # r2 = y * 320 ADD r2, r2, r0 # r2 += x # Add base address ADDI r2, r2, 0x70000 # Write color value MOVI r3, 42 # Color index ST r2, r3 # Store at calculated address 9.4. TTY/Console I/O (0x0007_F000 – 0x0007_FFFF) Ring buffer for terminal output. Write operations enqueue characters; read operations drain the queue. 10. Framebuffer Specification The framebuffer is a 320x200 pixel display with scanline-major layout. 10.1. Dimensions and Layout * Width: 320 pixels * Height: 200 scanlines * Color depth: 8-bit palette index (256 colors) * Scanline stride: 320 bytes * Total size: 64 KiB Bellis Expires 20 September 2026 [Page 15] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 10.2. Pixel Address Calculation To write a pixel at coordinate (x, y): address = 0x70000 + (y * 320) + x Constraints: * 0 ≤ x ≤ 319 * 0 ≤ y ≤ 199 * Out-of-bounds writes are silently dropped by the BPF verifier 10.3. Access Methods * STB (single-byte write): ST instruction writes one pixel at a time (slowest, most precise) * SYS_DRAW_FRAME (bulk copy): Syscall that copies entire 64 KiB buffer to framebuffer in one operation (fastest, for scene rendering) 11. Dream Ladder Feature Stratification The Shim defines conformance levels that implementations must support, organized as a stratified ladder. 11.1. Conformance Levels 11.1.1. Level 0: Microcode (Required) Foundation layer providing: * Monad wire format (20-byte HbH option) with CRC-16/CCITT validation * Sophia dictionary lookups during instruction execution * XDP packet processing model Conformance: All implementations MUST support Level 0. 11.1.2. Level 1: Digital (Required) Instruction execution layer providing: * Full MBC instruction set (48 opcodes) Bellis Expires 20 September 2026 [Page 16] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 * 16-register architecture (r0-r15) * 32-bit word operations * Arithmetic, logic, and control flow instructions (no memory operations) * 256-instruction limit per tick Conformance: All implementations MUST support Level 1. 11.1.3. Level 2: Mechanical (Required) Memory operations layer providing: * RAM_MAP and ROM_MAP (64 MiB + 1 MiB flat address space) * LD/ST instructions for memory access * CPU_MAP for state persistence across ticks * Level 0 and 1 features Conformance: All implementations MUST support Level 2. 11.1.4. Level 2a: Memory I/O (Recommended) Memory-mapped I/O layer providing: * Framebuffer (320x200, 8-bit palette) at 0x70000 * Keyboard input at 0x68000 * TTY console at 0x7F000 * All Level 0-2 features Conformance: Implementations SHOULD support Level 2a. Level 2a enables interactive applications (games, demos, interactive programs). 11.1.5. Level 3: Interrupts and Exceptions (Optional) Advanced features for future extension: * Hardware interrupt handling * Exception handling and recovery Bellis Expires 20 September 2026 [Page 17] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 * Trap vector dispatch Conformance: Level 3 is OPTIONAL. Implementations may define their own Level 3 features. 11.1.6. Level 4: Scheduling and Multitasking (Optional) Process and thread management: * PROC_TABLE for process state * SCHED_STATE for scheduler decisions * Preemptive multitasking Conformance: Level 4 is OPTIONAL. 11.1.7. Level 5+: Virtual Memory, Syscalls, Filesystem (Future) Reserved for future extension. Currently not defined. 11.2. Conformance Declaration Implementations MUST declare which levels they support. A conforming implementation MUST support a contiguous range of levels starting from Level 0. For example: * "Level 0-2": Supports Microcode, Digital, and Mechanical layers * "Level 0-2a": Supports Mechanical plus Memory I/O * "Level 0-4": Supports full multitasking stack An implementation claiming Level N support MUST also support all levels 0 through N-1. 12. CRC Validation Ordering CRC-16/CCITT validation ensures that register state has not been corrupted during network transmission. 12.1. Pre-Execution Validation When a tick packet arrives, the Shim MUST: 1. Extract Monad state from IPv6 HbH option 2. Validate CRC-16/CCITT of Monad state Bellis Expires 20 September 2026 [Page 18] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 3. If CRC is invalid: emit an Anomaly event to COMPUTE_EVENTS map and DO NOT execute MBC 4. If CRC is valid: proceed to stage 4 execution This ensures corrupted state never affects program execution. 12.2. Post-Execution Recomputation After MBC execution completes (whether via HALT or 256-instruction limit), the Shim MUST: 1. Recompute CRC-16/CCITT of the updated register state 2. Write the updated Monad state with new CRC into the outgoing packet's HbH option 3. Return XDP_TX to transmit the packet This ensures correct state propagates to the next hop. 12.3. Anomaly Event Format When CRC validation fails, an Anomaly event is written to COMPUTE_EVENTS with structure: * timestamp: 64-bit Unix nanoseconds * event_type: 8-bit code (0x01 = CRC_FAILED) * flow_tuple: Source IP, Dest IP, Flow Label (for correlation) * monad_state: Copy of corrupted Monad state * expected_crc: Expected CRC value * computed_crc: Computed CRC value 13. IANA Considerations This specification requests creation of three IANA registries to support interoperability and future standardization. 13.1. Shim Pipeline Stage Registry Registry Name: Unheaded Shim Pipeline Stages Range: 0-255 Bellis Expires 20 September 2026 [Page 19] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 Initial assignments: * 1: Assembly * 2: Verification * 3: Loading * 4: Execution 13.2. BPF Map Type Registry for UPC Registry Name: Unheaded BPF Map Types Range: 0-255 Initial assignments: * 1: ROM_MAP (read-only program image) * 2: RAM_MAP (read-write memory) * 3: CPU_MAP (register state) * 4: SCREEN_MAP (framebuffer) * 5: KBD_MAP (keyboard input) * 6: TTY_MAP (terminal output) * 7: PROC_TABLE (process state) * 8: SCHED_STATE (scheduler state) * 9: TLB_MAP (virtual memory) * 10: COMPUTE_EVENTS (event log) 13.3. Dream Ladder Level Registry Registry Name: Unheaded Dream Ladder Levels Range: 0-7 Initial assignments: * 0: Microcode (required) Bellis Expires 20 September 2026 [Page 20] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 * 1: Digital (required) * 2: Mechanical (required) * 2a: Memory I/O (recommended) * 3: Interrupts and Exceptions (optional) * 4: Scheduling and Multitasking (optional) * 5-7: Reserved for future use 14. Security Considerations 14.1. Primary Security Boundary: eBPF Verifier The eBPF verifier is the primary security boundary. All MBC execution occurs within eBPF context, subject to kernel verification rules following principles established in [RFC9000] for transport reliability: * Memory access must be in-bounds (BPF map bounds enforce this) * Loops must be bounded (256-instruction limit enforces this) * Privilege escalation is not possible (XDP context isolation enforces this) 14.2. CPU Exhaustion Prevention The 256-instruction limit per tick prevents malicious programs from consuming excessive CPU resources. Programs exceeding this limit are suspended and resume at the next tick. Over a period of N ticks, the maximum total instructions executed is 256 * N, providing predictable resource consumption. 14.3. Memory Access Control BPF maps provide bounds checking: * ROM_MAP: Out-of-bounds reads return zero * RAM_MAP: Out-of-bounds writes are silently dropped * SCREEN_MAP: Out-of-bounds pixel writes are silently dropped The kernel enforces all bounds checks; the Shim does not need to replicate this. Bellis Expires 20 September 2026 [Page 21] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 14.4. Packet Leakage Prevention All Shim processing returns XDP_TX (bounce packet to sender or next hop). Return codes XDP_DROP and XDP_PASS are never used, preventing accidental packet leakage into the host stack or transmission to unintended recipients. 14.5. Tick Packet Injection Trust Model Any node on the network path can inject tick packets. The Shim does not authenticate the origin of tick packets. This is an architectural assumption: use network ACLs and IPSec if authentication is required. The Shim's responsibility is to: * Validate CRC to detect corruption (but not forgery) * Process only valid, well-formed MBC instructions * Prevent execution of out-of-spec opcodes 14.6. Register State Confidentiality Monad register contents are visible in plaintext at each hop (in the IPv6 HbH option). There is no confidentiality for register state. If confidentiality is required, apply TLS or IPSec encryption at a layer above the Shim. 14.7. Verification as a Security Gate The Verification stage MUST reject programs with: * Invalid opcodes (prevents execution of undefined instructions) * Out-of-range registers (prevents register field corruption) * Out-of-range immediates (prevents encoding errors) * Invalid branch targets (prevents control flow attacks) Programs that fail verification MUST NEVER be loaded. No exceptions. 15. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . Bellis Expires 20 September 2026 [Page 22] Internet-Draft Shim Pipeline Specification for the Unhe March 2026 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 8200, July 2017, . [RFC9669] Thaler, D., Ed., "BPF Instruction Set Architecture (ISA)", RFC 9669, DOI 10.17487/RFC9669, October 2024, . 16. Informative References [RFC9000] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021, . Author's Address Stevie Bellis Unheaded Email: stevie@bellis.tech Bellis Expires 20 September 2026 [Page 23]