## 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`.

Each opcode could be encoded in the 32bit macroopcode, possibly with
subopcodes or flags (e.g., operand size, addressing mode).

## Overall Comments and Ideas

### Potential Use Cases
- **Edge computing / IoT**: Move code to sensor hubs where data is generated,
avoiding raw data transfer.
- **Database query processing**: Push down query fragments to the storage
nodes (similar to SQL pushdown but more general).
- **Distributed machine learning**: Move training loops to nodes holding
shards of data.
- **Blockchain smart contracts**: Code mobility could reduce onchain data
storage and improve scalability.
- **Multiparty computation**: Execution can visit multiple parties without
exposing data, with results only leaving as allowed.

### Related Work
- **Mobile agents** (e.g., Telescript, Aglets) but at a lower level.
- **Active networks** (programmable routers).
- **OSlevel process migration** (e.g., CRIU, OpenMosix).
- **WebAssembly** and **eBPF** for portable sandboxed code.
- **Dataflow architectures** where computation follows data.

### Security & Trust
A major challenge: executing untrusted bytecode on remote nodes. You need:
- **Sandboxing**: each VM in an isolated container, with resource limits.
- **Attestation**: nodes prove their identity and integrity before receiving
state.
- **Confidentiality**: execution state may contain sensitive data; encryption
might be needed.
- **Access control**: nodes must enforce permissions on data access, possibly
integrated into the routers egress rules.

### Performance
- Serialising/deserialising VM state for every teleport could be expensive.
You might use **snapshot/restore** techniques (like CRIU) but at a much finer
granularity.
- The routers decision latency must be low; otherwise, it defeats the purpose.
- Consider **prefetching** or **speculative execution** at multiple candidate
nodes.

### Next Steps
1. Define a concrete ISA specification (register count, stack depth,
addressing modes).
2. Build a **software interpreter** for a single node to validate the
instruction set.
3. Simulate a small mesh network (e.g., 10 nodes) to test the router
heuristics.
4. Implement a basic faulttolerance protocol (twophase commit or lease).
5. Evaluate with a benchmark where data gravity is strong (e.g., scanning a
large distributed log file).