feat(link): remote prover

[dhfang]

Summary

• Adds support for a remote gRPC prover.
• Renames ProofGenerator to Prover throughout.

The contract

proto/link/prover.proto mirrors the relayer's internal prover interface
method for method, with the client named on every request so one service can
serve many clients across many chains:

LatestProvableHeight(Client)                -> height, timestamp
StateProof(Client, height)                  -> proof
PacketProofs(Client, height, kind, packets) -> proofs[]

Configuration:

clientA:
  chainId: "1"
  clientId: link-1-2
  signer: relayer
  type: remote
  params:
    url: http://prover:9090

[dhfang]

This format of this is dependent on the type of light client, so we don't need to fill the ClientEnd config with tons of fields as we add support for more light clients.

[swift1337]

What parameters are available for configuration when using a remote prover? (Potentially).

[dhfang]

Defines how ClientEnd.Params is formed. I'm defining these in config.go for now while we only have two light clients, but could move these definitions to be besides the light client implementations eventually and have the type and params registered on startup similar to the other PoC.

[greptile-apps]

Greptile Summary

The PR adds a protobuf/Connect contract and configurable client type for delegating proof generation to a remote prover, while generalizing the existing attestation proof generator behind a shared prover interface.

• Adds the remote ProverService wire contract, generated clients, and packet conversion.
• Wires per-client prover implementations through bootstrap, relay pipelines, and finality processors.
• Adds a standalone test prover and black-box E2E coverage for remote proof generation.
• Extends relayer YAML validation with type-specific parameter blocks.

Confidence Score: 4/5

The PR should not merge until remote prover requests are bounded so an unresponsive service cannot indefinitely halt packet processing.

Remote prover calls use an HTTP client without a timeout and receive a background-derived pipeline context, allowing a server that accepts but never responds to hold stage workers forever and leave packets permanently pending.

Files Needing Attention: link/internal/relay/prover/remote/remote.go

Important Files Changed

Filename	Overview
link/internal/relay/prover/remote/remote.go	Implements the remote prover adapter and wire conversions, but its unbounded HTTP client can permanently stall pipeline workers.
link/internal/relay/prover/prover.go	Generalizes proof generation behind a prover interface and resolves attestation or remote implementations per configured client end.
link/internal/config/relayer.go	Adds strict type-specific parameter decoding and validation for remote prover URLs.
proto/link/prover.proto	Defines a coherent unary proof-generation contract carrying client identity, heights, proof kinds, and complete packet data.
link/internal/bootstrap/bootstrap.go	Replaces proof-generator wiring with the generalized prover set across relayer construction.
e2e/remote_prover_test.go	Exercises the remote prover contract through a standalone process and verifies a full receive-and-ack lifecycle.

Sequence Diagram

sequenceDiagram
  participant Dispatcher
  participant Pipeline
  participant Prover as Remote Prover
  participant Builder as Tx Builder
  participant Chain
  Dispatcher->>Pipeline: Dispatch packet
  Pipeline->>Prover: LatestProvableHeight
  Prover-->>Pipeline: Height and timestamp
  Pipeline->>Prover: StateProof(height)
  Prover-->>Pipeline: State proof
  Pipeline->>Prover: PacketProofs(height, packets)
  Prover-->>Pipeline: Aligned packet proofs
  Pipeline->>Builder: Build relay transaction
  Builder-->>Pipeline: Transaction calldata
  Pipeline->>Chain: Submit transaction

Loading

_{Reviews (1): Last reviewed commit: "build the poc prover as a separate test ..." | Re-trigger Greptile}

[dhfang]

This is pretty much identical to the internal interface except it specifies the chain and client in each request

[dhfang]

Exposing a remote prover for e2es via a binary - relies on internal attestations provers

[swift1337]

What parameters are available for configuration when using a remote prover? (Potentially).

[swift1337]

Let's update the example ibc.yml to showcase this scenario