## 1. Core Architecture (ISA)  `ovm-core-0001`

- **Address space**: 32-bit pointers may be limiting for modern large-scale
distributed systems. You might consider 64bit pointers, or a segmented/namespac
ebased addressing scheme where the high bits encode a node ID and low bits a
local offset.
- **Instruction set**: What operations are supported? Is it RISC-like,
stack-based, or a mix? The two pointers suggest operations on remote data;
does every instruction need two operands, or are some instructions unary
(e.g., load, store, branch)?
- **Stack and registers**: How many registers (N)? Is the stack included in
the serialised execution state? How deep is ndepth? The exact size affects
serialisation overhead.
- **Fixed width**: 128 bits per instruction may be too large for simple
operations (e.g., `NOP`). You might allow variablelength instructions or
compression for common cases, but fixed width simplifies parsing and routing.

**Options**:
- Define a minimal but complete instruction set (arithmetic, memory access,
control flow, mesh operations like `TELEPORT`).
- Use a registermachine model with a small fixed register file (e.g., 16
registers) and an evaluation stack for intermediate results.
- Include explicit `SUSPEND` and `RESUME` opcodes for checkpointing the
execution state.

## 2. Data Gravity Router  `ovm-mesh-0001`

**Key considerations**:

- **Cost model**: How do you quantify payload mass (size of data vs. size of
execution state)? Execution state includes code, registers, stack, and
possibly a scratchpad memory region. If the data to be processed is huge
(e.g., a database scan), teleporting the VM might be far cheaper.
- **Topology awareness**: The router must know network distances/latencies
between nodes. In a mesh with dynamic conditions, this needs continuous
updates.
- **Compute asymmetry**: Some nodes may be faster or have specialised hardware
(GPUs, FPGAs). The router should weigh compute capability against data
proximity.
- **Reference locality**: If the VM will access multiple remote data items in
succession, it may be better to move once to a datarich node than to fetch
each item individually.
- **Quarantine egress rules**: Security policies may restrict movement to
certain nodes or data classes.

**Possible enhancements**:
- Use **reinforcement learning** or **online heuristics** to adapt routing
decisions based on past performance.
- Define a **cost function** with adjustable weights that can be tuned by the
application or system administrator.
- Introduce a **gravity score** for each data object, indicating how strongly
it attracts execution (based on size, access frequency, and node
capabilities).

## 3. Transactional Memory / Fault Tolerance  `ovm-sync-0001`

This layer ensures no corruption if a node fails midteleportation. It keeps a
**ghost copy** on the caller, a **timeout epoch monitor**, a **twophase
commit** with temporary scratchpad, and a **poison pill** for zombie nodes.

**Design questions**:

- **Ghost copy**: Where is it stored? On the sending node? If the sender also
fails, what happens? Perhaps a thirdparty coordinator or a durable log is
needed.
- **Twophase commit**: What exactly is committed? The entire execution state,
or only the results written to remote data? Twophase commit in a distributed
environment is expensive; you may need an alternative like **sagas** or
**idempotent operations**.
- **Timeout epochs**: How are epochs defined and synchronised? Timeouts need
to be long enough to avoid false failures but short enough to recover quickly.
- **Scratchpad memory**: Should be isolated per teleportation to avoid
interference with other concurrent VMs.

**Suggestions**:
- Implement a **leasebased protocol**: the sending node retains a lease on the
VM state; if the receiver fails, the sender can reclaim and resend.
- Use **writeahead logging** on the sender to allow rollback if the receiver
partially executes but then disappears.
- Consider **optimistic concurrency** with versioning: if the data changes
while the VM is in transit, detect and abort/restart.

## 4. Research Questions

### `ovm-res-0001`  Infinite Loops / Runaway Bytecode

Preventing resource exhaustion on remote nodes is crucial.

**Options**:
- **Cyclelimit quota**: embed a counter that decrements on each instruction or
loop iteration; if it reaches zero, the VM is suspended or terminated and the
sender notified.
- **TTL** (timetolive): simpler but less precise; longrunning legitimate tasks
might be killed.
- **Cost metering**: each instruction has an associated cost (e.g., gas in
Ethereum). The sender prepays; when exhausted, execution halts.
- **Watchdog timers** on the node monitoring CPU/memory usage and killing
runaway VMs.

**Recommendation**: Combine a **cycle counter** (deterministic) with a **hard
resource cap** (memory, I/O) enforced by the node.

### `ovm-res-0002`  Scratchpad Memory Implementation

The scratchpad is needed for twophase commit and temporary storage.

**Options**:
- **Virtualised heap inside the VM**: allocate a fixedsize region in the VMs
memory space, but this increases serialised state size.
- **Nodelocal ephemeral storage**: scratchpad is stored on the remote node and
not transferred back; only committed results are returned. This keeps the
teleported payload small.
- **Hybrid**: small scratchpad travels with the VM, larger temporary data is
stored on the node and referenced by handle.

**Tradeoff**: The more state you move, the higher the teleportation cost; the
less you move, the more you rely on remote storage that may disappear.

### `ovm-res-0003`  PingPong Routing Loops

Two nodes may each think the other is better suited, causing endless bouncing.

**Possible solutions**:
- **Token/hop count**: each teleport increments a counter; if it exceeds a
threshold, the VM is parked at the current node and the sender is notified.
- **Costfunction hysteresis**: require a significant improvement (e.g., >10%
better) before moving again, preventing marginal gains from causing
oscillation.
- **Directional lock**: after moving, the VM cannot return to the previous
node unless a new external factor (e.g., data update) changes the decision.
- **Centralised or distributed coordinator** that arbitrates disputes, but
this adds overhead.

**Suggestion**: Use a **monotonically increasing route cost** or a
**visitednode list** with a maximum revisit count.

## 5. TODO: VM Dispatch Table  `ovm-todo-0001`

Drafting the opcode index is the first concrete implementation step. I
recommend starting with a minimal set:

- **Data movement**: `LOAD`, `STORE`, `MOV` (between registers), `PUSH`,
`POP`.
- **Arithmetic/logic**: `ADD`, `SUB`, `MUL`, `DIV`, `AND`, `OR`, `XOR`, `CMP`.
- **Control flow**: `JMP`, `JZ`, `JNZ`, `CALL`, `RET`.
- **Mesh operations**: `TELEPORT`, `SUSPEND`, `RESUME`, `SEND`, `RECV`.
- **Transaction control**: `BEGIN_TX`, `COMMIT_TX`, `ABORT_TX`.
- **System**: `HALT`, `YIELD`, `QUOTA_SET`.