feat(gateway): expose StateGetRandomnessDigestFromBeacon

[rvagg]

Used by PDP, uses chain data to get historic randomness which is local and fairly fast. This is the main blocker for a PDP-only miner from using a public gateway only.

The main issue with being able to use this is the the lookback limit, for a 24h proving period you'd want to be able to look back up to 24h to submit a proof; I think a gateway, like glif, that had a 24h window should be OK for submitting proofs as long as they're done slightly early or on time.

Edit: No, we set the challenge epoch in the future at each window, so the lookback will be really small regardless, so I don't think there's a problem here with short lookback windows.

[Copilot]

Pull Request Overview

This PR exposes the StateGetRandomnessDigestFromBeacon method in the Gateway API to support PDP-only miners using public gateways. The main purpose is to enable miners to retrieve historic randomness from the chain without requiring access to a full node.

Key changes:

• Add StateGetRandomnessDigestFromBeacon method to the Gateway interface and implementation
• Update gateway proxy to handle the new method with appropriate rate limiting and validation
• Regenerate API proxy code and update OpenRPC documentation

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
gateway/proxy_fil_v1.go	Implements the gateway proxy method with chain rate limiting and tipset validation
api/api_gateway.go	Adds the method to the Gateway interface definition
api/proxy_gen.go	Auto-generated proxy code for the new method
extern/filecoin-ffi	Updates submodule commit reference
build/openrpc/*.json	Updates line number references in OpenRPC documentation
CHANGELOG.md	Documents the new feature

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[rjan90]

One comment from CoPilot there, which might make sense based on my limited search. Else the changes look good.

[rvagg]

No, Copilot is wrong. The check does both for me - the tipset at which I'm anchoring the search for the epoch, and the rand epoch itself. So I can't anchor the search for the tipset back too far (default being HEAD, aka EmptyTSK), and randEpoch is actually a Filecoin epoch that I want to select from on that chain, so it can't be too far back either. checkKeyedTipSetHeight gives me both checks in one (and does its own EmptyTSK -> HEAD conversion for me).