Solana: the real difference

If you know one smart-contract platform, this chapter is for you. If you don’t, the one-line version: there, the platform’s rules are fixed by the network and your program lives inside them; here, your program’s rules are the only rules, and the network just checks the proof. vprogs rollups and Solana look strikingly similar on the surface, and the one place they differ explains everything else about the design.

The similarities are real

Both systems share the same core shape:

A Solana developer reading tt’s guest code will feel at home: there are user accounts with balances, locks authorizing spends, a minimum-balance floor on accounts, an index of “who owns what”. The similarity is deliberate.

The difference: whose runtime is it?

On Solana, the runtime is the chain. Sealevel (Solana’s parallel transaction scheduler), the account model, rent and fee rules, what makes a transaction well-formed: all of that is protocol, identical for every program, enforced by every validator, changeable only by a network upgrade. Programs run inside a runtime they cannot change: they orchestrate accounts, but the rules are set by the network.

In a vprogs rollup, the runtime is the program. tt’s guest literally ships a runtime.rs, and inside the proof it is the only runtime there is. Resource derivation lives in the app too: tt decides its resource kinds, its hash domains, its id derivations (the framework hands you the pattern; the app picks the keyspace). Transaction validity, lock semantics, what a “turn timer” means: all rollup program logic, executed and proved like any other line of guest code. There is no shared runtime; every program assembles its own from the framework’s parts.

The claim needs a boundary, because it is smaller than it sounds. A chain’s hardest problems are agreement: what order transactions happened in, where the data lives, what counts as settled, what is final. The program re-solves none of them: it buys ordering, data availability, settlement, and finality from Kaspa unchanged (Based rollup on Kaspa to How it all chains). What moves into the program is the layer Solana fixes in protocol, the system program’s duties:

• Account creation and addressing. On Solana the system program creates accounts, and PDAs (program-derived addresses) hand programs control of derived accounts. Here derivation is app code: tt gives games their own keyspace, derived from the creator’s lock and a counter, with domain separation keeping keyspaces from colliding.
• The cost of holding state. Solana’s rent is protocol: holding state costs lamports, enforced by every validator. Nothing meters rollup state per block; state costs what proving and storage cost the operator, so the honest limit is how much you can afford to keep, not how much the protocol lets you. A program can still place floors as rules: tt’s minimum-balance floor and its withdrawal minimum are config the app chose, batteries rather than metering.
• Transaction well-formedness and balance. On Solana these are protocol rules, enforced by the runtime and the system program. Here they are program logic, proved with everything else.

This is a direct consequence of the zkVM: since the guest is an ordinary program, whatever it computes about its own rules is covered by the same proof that covers the rules themselves. On a chain, the runtime must be fixed because every validator must agree on it before running your code. In a rollup, agreement comes from the receipt, so the runtime can be as application-specific as the application.

What it buys

• Resource derivation as a design surface. The keyspace pattern above is plain code: the app picks any derivation it can compute, and the proof pins the result.
• Rules that can be arbitrary. A turn timer that forfeits a round, a pot that splits on a draw: no need to fit these into a shared execution model, because there is no shared execution model.
• New rules, new identity. “The protocol” is the guest ELF; changing the rules is changing the program (covenant ids pin image ids precisely so this is explicit: a new rules version is a new identity, not a surprise). The money path is explicit: a new image id is a new covenant id, so an upgrade means moving to a new instance: users exit through the old instance’s permission tree and deposit into the new one. In-place migration does not ship, and draining the old instance still needs someone to keep its stack settling; an instance everyone is leaving is the least likely to keep one, which is The machinery’s liveness trust at its sharpest.

What it costs

• No free composability. Solana programs share one state machine, so one program can call another atomically. Each vprogs program is its own proved system; cross-program calls are future work, sketched but not shipped (Single sovereign apps lives inside this limitation).
• The runtime is your responsibility. Nobody else guarantees your rules make sense. The framework’s batteries (locks, unlockers, signers) are the strong default, and runtime.rs’s job is largely assembling them rather than inventing from zero. But the choice, and the consequences, belong to the program.

The Ethereum reader’s checklist

The Solana comparison above covers accounts and runtimes; the reader from EVM rollups has a different checklist, and the answers are short:

In Solana the runtime belongs to the network; in a vprogs rollup it belongs to the program, assembled from framework parts and covered by the proof, on top of an L1 that still owns ordering, data availability, and settlement.