**Taiko Gwyneth Notes**

- It's a single VM that operates on multiple state trees. Each state tree corresponds to a rollup.
- As a user, block builder, etc. you can selectively choose which rollups you interact with (read or write), and ignore the rest.
- When the L2 block builder executes the VM (a fork of `revm`), it is just normal EVM execution, but it can switch between state trees (between databases) using a special opcode. Basically this allows it to switch between execution contexts, and pass a messages synchronously.
- The VM will receive each rollup's state root (and state witness) as input, execute over multiple states, then produce a state diff for each rollup. You can create a TEE or ZK proof for this whole execution.
- Then, you take these state diffs and encode them somehow (share a blob, or each in its own blob, doesn't really matter). Submit to Ethereum for DA, along with the proof of correctness.
- Once submitted and verified, all rollup state roots are updated.

So a shared VM executing over a set of rollup states in lockstep.

bytes32[] rollupStateRoots;

function submitBlock(bytes32[] calldata newRollupStateRoots, bytes calldata proof) {
    bytes32[] memory blobHashes;

    for (uint256 ii = 0; ii < MAX_BLOB_COUNT_PER_BLOCK; ii++) {
        bytes32 _blobVersionedHash;
        assembly { _blobVersionedHash := blobhash(ii) }
        if (_blobVersionedHash == bytes32(0)) break;
        blobHashes.push(_blobVersionedHash);
    }

    verifier.verifyProof(
        blobHashes,
        rollupStateRoots,
        newRollupStateRoots,
        proof
    );

    rollupStateRoots = newRollupStateRoots;
}

- As an L2 follower node, you can just decode blobs and apply state diffs that belong to your rollup, and ignore the rest. You can trust that the state diff is correct, relying on the proof. If you are able to acquire the source data (L2 txs and blocks), you can also maintain the L2 ledger locally, but there's no guarantee for this.