RPC-Validator ISM

[nambrot]

Currently, whenever a new chain is being added, a dedicated validator instance has to be spun up to support the new chain, which puts a lower-bound on friction and latency to get a Hyperlane deployment. This ticket describes a new kind of validator and ISM architecture which allows the validator operator to automatically support arbitrary chains (via commitments to the RPC URL in the signature), and outsources the specification of the trust assumption in the form of the RPC URL to the ISM deployer.

Benefits

• Broad coverage
  • Validators are able to provide their services to pretty much any chain, as they are treated as a trusted RPC request maker
• Simplified validator operations
  • There is no need for a dedicated RPC node
  • There is no need for indexing messages anymore
• Suitability for direct relaying from the Warp UI/CLI
  • This kind of addresses one of the issues of the Trusted ISM approach in https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3555, as that requires said relayer to be live (or their key shared for testing purposes)

Considerations

• Validators are networked and announced and thus more easily DDOS'd

Spec

RPC-Validator

The rpc-validator would expose a simple HTTP-based API with a single method: POST /attest_to_message with the following body:

{
  "messageId": "0x123",
  "dispatchTxId": "0x456",
  "rpcUrl": "https://rpc-url.chain.com",
  "mailboxAddress": "0x789"
  "originDomain": 42
}

The rpc-validator makes a request to the given rpc url, ensures that the message was indeed dispatched on the mailbox, and then provides an attestation to the message while also committing to the RPC URL in question.

RPC-Validator-ISM

This will have to be a new ISM type.

The rpc-validator-ISM is configured with five configuration values:

1. address rpcValidatorAddress
2. string validatorUrl
3. address originMailboxAddress
4. uint32 originDomain
5. string rpcUrl

On verify, the ISM will take the passed in signature, and verify if the signatures commits to the configured values + messageId.

Relayer changes

The relayer will need to persist the origin TX hash of an indexed message (to bring down the RPC load on the validator). When building metadata for the message and encountering the rpc-validator-ISM, will will construct the HTTP call and make it against the configured validatorUrl and then construct the metadata with the response body.

Future Work

You can think of RPC-validators as pre-confirmations for TLS attestations from RPC providers. Like other pre-confirmation ISMs, they can be economically secured as long as there is a way to verify TLS signatures on-chain at some point. (Link to some projects)

[daniel-savu]

Another benefit is removing the need to set up S3, which is non-trivial.

What I'd add to this design:

• The new ISM could just be a flavor of MultisigISM with the validatorUrl added, I don't see why the need for the other fields
• Allow the rpc-validator to configure a matching list over the fields of the attest_to_message body, to be intentional about which deployments are being signed for. This makes DDoS-ing much less of a concern
• RPC errors would need to be included in the response, so the caller can rotate RPCs when they go down

[nambrot]

• You need the other fields to specify which mailbox to use (since rpc validator is not explicitly indexing)
• i dont think that's the ddos i'd be worried about