# sBPF Program Execution on PVM

Solana programs currently execute in a modified [eBPF][ebpf] virtual environment. As we explore migration to PVM, we present two architectural approaches to maintain compatibility while leveraging PVM's capabilities:

- Develop [sBPF runtime][rbpf] as a service in PVM
- [Recompile sBPF][ebpf-instr] programs to PVM bytecode

graph LR
    sBPF[sBPF Program] --> SBPF[sBPF runtime]
    sBPF -- Transpiler --> LLVM[LLVM IR] -- polkavm-linker --> SBPFE[host environment]
    PVM --> State[(state diff)]

    subgraph PVM
        direction TB
        SBPF
        SBPFE
    end

## Program State Management

The state management flow illustrates how program execution and state transitions are handled between the client, Solana node, and PVM service.

sequenceDiagram
    Client->>+Solana-Node: Submit TX (params + storage_addr)
    Solana-Node->>+PVM-Service: sbpf
    Note over Solana-Node,PVM-Service: Initial State + Params
    PVM-Service->>PVM-Service: Execute Program
    PVM-Service->>Solana-Node: State Diff {storage_addr: (old→new)}
    Solana-Node->>Solana-Node: Validate Diff
    Solana-Node->>Client: TX Receipt

- **Focus on Execution:** state access should be validated in the solana node while the service on PVM service should only focus on execution.
- **Atomic State Updates:** state changes are tracked as diffs (old→new) and validated before commitment, allowing for atomic updates and rollbacks if validation fails.
- **Performance Optimization:** only initial state and final diffs are transferred, reducing network load and processing time.
- **State Validation:**
- Solana node validates state diffs before commitment
- State changes must reference valid storage addresses
- Changes are verified against program permissions and constraints
- _TODO: zk-proof for state validation_
- **Rollback Mechanism:** The diff-based approach allows easy rollback by discarding invalid state changes without affecting the base state.

This architecture provides a robust foundation for managing program state while maintaining security and consistency. The diff-based approach optimizes performance while enabling strong validation guarantees.

## Specification

- sBPF runtime as service on PVM
- fork [anza-xyz/sbpf][sbpf] and remove std dependencies
- introduce a pvm service based on the `sbpf::interpreter` using [jam-pvm-common][jam-pvm-common]
- _confirm PVM is available to run large services like an interpreter, if the cost is affordable, and the performance is acceptable, we can try to introduce the JIT service on PVM._
- sBPF program transpiler to PVM blob
- Write a transpiler based on the instruction set of [sbpf][sbpf] which translate the sBPF program to LLVM IR, and then integrate with [polkavm-linker][polkavm-linker] to generate the PVM blob.
- Intorudce a PVM service that provides the environment for the sBPF programs to run, e.g. storage accesses, etc.
- solana node modification
- state maintainence layer for state validation, state diff tracking, etc.
- replace the program execution logic with the PVM integration

## References

- [what is eBPF?][ebpf]
- [eBPF instruction set][ebpf-instr]
- [paritytech/revive][revive]
- [solana-labs/rbpf][rbpf]
- [Eclipse-Laboratories-inc/zk-bpf][zk-bpf]

[sbpf]: https://github.com/anza-xyz/sbpf
[ebpf]: https://ebpf.io/what-is-ebpf/
[rbpf]: https://github.com/solana-labs/rbpf
[ebpf-instr]: https://www.kernel.org/doc/html/v6.3/bpf/instruction-set.html
[zk-bpf]: https://github.com/Eclipse-Laboratories-inc/zk-bpf
[jam-pvm-common]: https://docs.rs/jam-pvm-common/latest/jam_pvm_common/
[polkavm-linker]: https://docs.rs/polkavm-linker/0.19.0/polkavm_linker/
[revive]: https://github.com/paritytech/revive