Wire VM bridge to upstream Forest/Lotus for block production state-root computation

[Reiers]

Problem

MinerCreateBlock (rpc/handlers/miner_block.go) produces a syntactically valid block with real Parents, Ticket, ElectionProof, BeaconEntries, and Messages. But ParentStateRoot is copied verbatim from the parent tipset because Lantern has no FVM. A published block with that state root is rejected by the network.

SyncSubmitBlock is gated by AllowBlockSubmit=true and returns ErrNotImpl by default. Correct posture today.

What's already there

vm/bridge/ is designed for this. The handler code (miner_block.go:294) already has:

if c.Bridge != nil && c.AllowBlockSubmit {
    root, _, berr := c.Bridge.ComputeStateRoot(ctx, parentBlock.ParentStateRoot, int64(bt.Epoch-1), unsignedMessagesForBridge(bt.Messages))
    ...
}

The bridge interface is defined, but no concrete implementation ships in main today.

Proposed implementation

Path A: Forest/Lotus side-channel JSON-RPC client

1. Implement vm/bridge/forest.go as a thin JSON-RPC client that calls the upstream's StateCompute or equivalent method to obtain the post-execution state root for the candidate block's messages.
2. Wire a --vm-bridge-rpc=<url> flag on lantern daemon that constructs the bridge when set.
3. Document that AllowBlockSubmit=true is allowed only when --vm-bridge-rpc is also set; refuse to start otherwise.

For an SP backup use case, the operator already runs Lotus as primary. Pointing the bridge at the same Lotus instance is fine: the read path is trustless (everything verifiable via the F3-anchored state root), the production path delegates to local Lotus for state-root computation. If Lotus is down for the read path, Lantern serves chain head / state queries. If Lotus is up for the bridge, Lantern can produce blocks.

Acceptance

• lantern daemon --allow-block-submit --vm-bridge-rpc=http://lotus:1234/rpc/v1 starts cleanly.
• SyncSubmitBlock with a valid block produces a state root that matches what an upstream Lotus computes for the same messages.
• SyncSubmitBlock actually publishes to /fil/blocks/testnetnet and the block is accepted by peers (validated by tailing peer logs).

Out of scope

• Pure-Go FVM port (Path B from the proposal). Multi-month, not realistic.
• Forest subprocess spawn (Path C). Punt to follow-up if anyone wants full local autonomy.

Related

• vm/bridge/doc.go
• rpc/handlers/miner_block.go
• net/blockpub/blockpub.go (the publish channel exists, just gated)

[Reiers]

✅ Closed: VM bridge wired and verified end-to-end

Commit 100be2a is live on f03678816. CLI wiring + a real wire-format fix.

What shipped

CLI flags (commit d678289):

• --vm-bridge-rpc upstream Forest/Lotus JSON-RPC URL
• --vm-bridge-token optional Bearer token (or env LANTERN_VM_BRIDGE_TOKEN)
• --vm-bridge-timeout per-request timeout (default 30s)
• --allow-block-submit gate, refuses to start without --vm-bridge-rpc

Wire-format fix (commit 100be2a):
Discovered during the live deploy that Lotus encodes the Root CID as the IPLD-link JSON shape {"Root":{"/":"<cid>"}}, not as a bare string. The original ForestBridge decoder used Root string, which would have silently returned cid.Undef against real Lotus and produced invalid block headers. Now decodes via a small cidLink struct, with two new tests guarding the wire shape.

End-to-end verification on mainnet

Bridge running on f03678816 pointing at the box's own Lotus (http://192.168.2.32:1234/rpc/v1). Boot log confirms:

vm-bridge:    forest@192.168.2.32:1234/rpc/v1

StateCall (non-Send) against the power actor's CurrentTotalPower method:

Lantern via bridge:

{
  "MsgRct": {"ExitCode": 0, "GasUsed": 22566882, "Return": null, "Events": ...}
}

Lotus directly (same call):

{
  "MsgRct": {"ExitCode": 0, "GasUsed": (similar large int), "Return": "hkkAHLTHQ..."}
}

Both succeeded. The bridge call traveled Lantern \u2192 ForestBridge \u2192 Lotus \u2192 ForestBridge \u2192 Lantern, with proper IPLD-link decoding throughout.

Sync lag unaffected

Concurrent-probe 10-sample test after the redeploy: 8 at lag=0, 2 at lag=1 during epoch transition. The bridge wiring did not regress #1's win.

MinerCreateBlock end-to-end

A full MinerCreateBlock call still times out because it loads miner state via HAMT \u2192 Bitswap (issue #3). That's the StateMinerInfo timeout, not a bridge problem; the bridge fires only AFTER miner-state load succeeds. When #3 closes (gateway-first state-tree fetch, or HAMT prefetch), MinerCreateBlock will complete and the bridge will produce the correct ParentStateRoot.

Safety posture

• Default: bridge unconfigured, AllowBlockSubmit=false. Read path remains fully trustless.
• Operator with --vm-bridge-rpc only: bridge is available for StateCall non-Send routing, block submission still gated.
• Operator with --vm-bridge-rpc + --allow-block-submit: full SP failover. MinerCreateBlock computes the correct state root via the upstream, SyncSubmitBlock publishes to /fil/blocks/testnetnet.

What this unlocks

The SP failover backup story is structurally real. Curio operators can now run Lantern as a secondary that:

• Stays in sync with the network in real time (closed Close gossipsub-side sync lag (parent backfill + direct peers) #1)
• Speaks the full Curio FULLNODE_API surface (71/71)
• Produces blocks via the operator's own sibling Forest/Lotus when needed

Closing #4.