Relaytakes the transaction that sent the packets.Packetsreports how far each of them got.
server.listenAddr, defaulting to 0.0.0.0:3000.
The ProverService described at the end of this page is one you implement and the relayer calls, to support a light client the CLI has no built-in prover for. The CLI does not serve it.
To list running services:
Health checks
Both relayers and standalone attestors expose the standardgrpc.health.v1.Health service
on their API address. Check is supported; Watch returns UNIMPLEMENTED.
With reflection enabled, check readiness using:
service field selects the check:
Relayer service
ibc.v2.relayer.RelayerApiService. ibc relayer relay and ibc relayer packets call these two.
Relay
Relay tracks the packets emitted by a source transaction and submits the transactions required to complete them.
RelayRequest
Field names in these tables are the schema’s. The JSON encoding uses lowerCamelCase, so
tx_hash is sent as txHash.
all_packets takes every packet for which this relayer has a configured client and route. Packets without one are skipped, and the request succeeds even when that leaves nothing to relay.
SelectedPackets
PacketSelector
A
selected_packets request fails if any packet it names is absent or has no configured route. Naming a packet that is already selected, in flight, or finished succeeds and changes nothing.
Relay answers with every send packet in the transaction, including the ones it will not carry.
RelayResponse
ObservedPacket
PacketSelection
A successful call means the relayer recorded the request.
Packets reports what happens after that.
Packets
Packets lists the packets this relayer is aware of, most recent first.
PacketsRequest
PacketFilter
Every field is optional, and a request with none returns everything the relayer has recorded.
PacketsResponse
Results are paged. Ask again with
next_cursor while has_more is set.
PacketStatus
TransactionInfo
PacketState
NOT_SELECTED and PENDING are still open. The other four are final.
REJECTED means the packet arrived and the application refused it, which is a completed relay and a failed application call. RELAY_FAILED means a permanent error stopped the relayer, wherever the packet had got to.
Attestation service
ibc.v2.attestor.AttestationService. One process can run several attestors, so every request names one.
Attestation
Both attestation calls return this shape.
attested_data is what was signed. A light client accepts the attestation when its threshold of attestors or more sign the same data.
StateAttestation
Retrieves an attestation for a state at a given height.
StateAttestationRequest
StateAttestationResponse
A height above what
LatestHeight reports is refused, so ask for the height first.
PacketAttestation
Retrieves an attestation for a set of packets.
PacketAttestationRequest
CommitmentType
commitment_type selects what is being proven, which differs by direction. A delivery proves a packet commitment, an acknowledgement proves an acknowledgement commitment, and a timeout proves that no receipt exists.
PacketAttestationResponse
One request carries at most 100 packets, each at most 128 KB, and a request over either limit is refused.
LatestHeight
Returns the latest height the attestor will generate attestations for.
LatestHeightRequest
LatestHeightResponse
Offset zero attests up to the chain’s
finalized tag. Above zero, the attestor reads latest and subtracts finalityOffset.
Info
Returns identity information about a configured attestor.
InfoRequest
InfoResponse
address is what a light client checks signatures against. So this call is how an operator confirms that the running attestor is the one an on-chain client expects.
Prover service
ibc.v2.prover.ProverService. A relayer runs one prover per light client it
submits to. Pointing a client end at this service replaces the built-in prover
with a remote one, so a light client the CLI does not implement can be supported
by serving these three calls. Every request names the client it is scoped to, so
one service can serve many clients across many chains.
Client
Every request carries one, identifying the light client the call is scoped to.
LatestProvableHeight
LatestProvableHeight returns the highest height a subsequent ClientUpdatePayloads and PacketProofs call sharing that height can currently succeed at, with that height’s counterparty-chain timestamp.
The relayer calls this first and proves at the height it returns, so a prover
paces the relayer by holding the height back until it can prove at it.
ClientUpdatePayloads
ClientUpdatePayloads returns the encoded light-client updates that bring the client to a height.
Each payload is opaque to the relayer, which passes it unchanged as
updateMsg in one router updateClient call, in order, ahead of the packets in the same transaction. A prover whose client cannot reach a height in one update returns several.
PacketProofs
PacketProofs proves each packet’s membership or non-membership at a height, one proof per packet with indices aligned to the request.
proofs is one proof per requested packet, in request order, so a response of a
different length than the request is an error. The relayer submits all proofs of
one response in a single transaction, in that order; a prover may therefore put
material the whole batch shares (such as an account proof) only in the first proof.
Packet
The packet a proof is requested for.
Acknowledgement
The acknowledgement supplied for a packet when requesting an acknowledgement proof.
Next steps
- Configuration for
server.listenAddrand theattestorsblock these calls read. - CLI commands for the commands that make these calls.