docs: attestor and relayer deployment guides#218
Conversation
dhfang
left a comment
dhfang
left a comment
There was a problem hiding this comment.
The attestor one is a bit out of date, I think you may need to regenerate the guide
|
|
||
| --- | ||
|
|
||
| ## Health Checking |
There was a problem hiding this comment.
There should be a health check endpoint now
|
|
||
| ## Multi-Chain Deployments | ||
|
|
||
| Deploy one attestor instance per chain. Each instance gets its own config file specifying the chain's RPC URL and chain type. They can share a single signer service, differentiating keys by `wallet_id`. |
There was a problem hiding this comment.
The client is not restricted to one attestor instance per chain and will actually likely be using more than one to support some m of n multisig
|
|
||
| --- | ||
|
|
||
| ## Docker Deployment |
There was a problem hiding this comment.
I dont really think we need to include details around using docker, kubernetes, or configuring dns, this will vary widely depending on the customer
| ibc_attestor key show --show-private | ||
| ``` | ||
|
|
||
| The **public key / Ethereum address** derived from this keypair must be registered on-chain with the IBC light client so that attestations are accepted. Coordinate this registration with your chain operator. |
There was a problem hiding this comment.
Light clients currently require the attestor addresses on creation and then there is no way to update those values. We are working on changing that. The "Coordinate this registration with your chain operator" line feels unnecessary
| @@ -0,0 +1,661 @@ | |||
| --- | |||
| title: "Deployment" | |||
There was a problem hiding this comment.
I thought we wanted to move any documentation to do with the relayer out of the attestor repo. I believe we wanted to move things about operating the whole system to some public docs site
|
|
||
| The IBC v2 Relayer is a request-driven service that relays IBC v2 packets between Cosmos SDK chains and EVM-compatible chains (Ethereum, Base, Optimism, Arbitrum, Polygon, etc.). It exposes a gRPC API for submitting transactions to relay and tracking relay progress, and runs a background dispatcher that polls for pending packets. | ||
|
|
||
| The relayer is stateful — it persists packet state in PostgreSQL — and connects to two external services: a **Proof API** that generates relay transactions, and a **signing service** (local key file or remote gRPC signer) that authorizes those transactions. |
There was a problem hiding this comment.
I wouldn't characterize local signing as "external" or a "service"
|
|
||
| **Images**: | ||
| - `platform-relayer` — the relayer process itself | ||
| - `platform-relayer-migrate` — one-shot migration runner (golang-migrate), must run before the relayer starts |
| The relayer delegates proof and transaction generation to an external Proof API service. This is the [IBC Eureka Relayer / Proof API](https://github.com/cosmos/solidity-ibc-eureka/tree/main/programs/relayer). The relayer connects to it via gRPC (`ibcv2_proof_api.grpc_address`). | ||
|
|
||
| The Proof API itself depends on: | ||
| - **IBC Attestor instances** — one per chain being attested (see the [Attestor Deployment guide](/enterprise/components/interoperability/deployment-attestor)) |
|
|
||
| The Proof API itself depends on: | ||
| - **IBC Attestor instances** — one per chain being attested (see the [Attestor Deployment guide](/enterprise/components/interoperability/deployment-attestor)) | ||
| - **Chain RPC endpoints** — for both chains in each relay pair |
|
|
||
| --- | ||
|
|
||
| ## Pre-Deployment: On-Chain Setup |
There was a problem hiding this comment.
This feels a bit out of place in the relayer documentation
2 participants
No description provided.