feat(link): custom light client - POC

[dhfang]

Summary

Adds support for custom light-client provers in downstream-compiled ibc binaries.

• Exposes an importable CLI root command with custom prover factory registration.
• Adds public prover, factory, registry, and configuration APIs.
• Includes a remote HTTP prover POC backed by attestation.
• Validates a complete packet relay through the custom-compiled CLI and remote prover.

I chose to expose the CLI root command and have it accept the custom light client provers as this felt like the option that was the smallest extension of the public surface and the most straightforward for consumers to understand. This also enables consumers of custom light client prover functionality to continue operating Link through the CLI. Alternatives like exposing the relayer service drag more of the internals out into the public interface requiring the consumer to understand a larger set of components and the relayer service lifecycle. Exposing it also feels premature as the relayer service architecture is still not stable and we have not thoroughly thought through or tried to understand the possible use cases that may influence the design of these libraries.

Once the approach is validated, I'll remove the POC specific code and do some additional cleanup before putting up the PR for review. I haven't fully refactored the internal proof generation library to keep the diff small as I mainly wanted feedback on the public API which is as follows:

Public API

Downstream binaries register custom prover factories when constructing the CLI:

func main() {
    registry := lightclient.NewRegistry()

    if err := registry.Register(myclient.Factory{}); err != nil {
        panic(err)
    }

    root := cli.NewRootCmd(cli.Options{
        Relayer: cli.RelayerOptions{
            ProverFactories: registry,
        },
    })

    os.Exit(cli.Execute(root))
}

A factory identifies its client type and constructs one prover for each configured client:

type Factory struct{}

func (Factory) Type() string {
    return "my-client"
}

func (Factory) New(
    ctx context.Context,
    opts lightclient.ProverFactoryOptions,
) (lightclient.Prover, error) {
    var params Params
    if err := opts.Client.ClientParams.Decode(&params); err != nil {
        return nil, err
    }

    return NewProver(
        opts.Client.ClientID,
        opts.HostChain,
        opts.CounterpartyChain,
        params,
    )
}

Custom provers implement the proof-generation contract used by the relayer. The relayer creates one prover per light client instance that is responsible for creating proofs for the light client and indicating what height of the counterparty chain it considers provable

type Prover interface {
    LatestProvableHeight(context.Context) (uint64, time.Time, error)

    StateProof(
        context.Context,
        uint64,
    ) ([]byte, error)

    PacketProofs(
        context.Context,
        uint64,
        ProofKind,
        []channeltypesv2.Packet,
    ) ([][]byte, error)
}

Operators select the custom implementation and provide implementation-specific parameters through the normal Link configuration via a new arbitrarily shaped clientParams:

relayer:
  connections:
    - alias: example
      clientA:
        chainId: "1"
        clientId: "client-a"
        type: my-client
        clientParams:
          endpoint: https://prover.example.com

I've left some comments in the diff to highlight the most important parts.

[dhfang]

This is an example of how a consumer would construct the binary to compile their custom proving logic into the CLI.

[dhfang]

E2E POC

[dhfang]

Exposes root command in public api

[dhfang]

This accepts arbitrary yaml configuration and lets the custom prover implementations decide how to validate and interpret it.

[dhfang]

Implementation of a server that implements the interface the POC remote prover expects. Executes attestation proof logic.

[dhfang]

POC of how consumers might implement a prover that calls out to a remote service to generate proofs.

[dhfang]

The prover interface that consumers would create custom implementations of.

[dhfang]

Consumers create a factory that the relayer invokes to create provers during startup.

We could extend this to also offer a ValidateParams method that hooks into config validation and lets consumers validate clientParams. This doesn't really feel necessary as I doubt consumers will intend to distribute their binary very broadly and probably don't care as much about the UX as much as we do. They can currently just do some validation in the constructor if they want.