Pre-RFC: Policy-based relaying

[romac]

This is a pre-RFC meant to gather requirements for the upcoming policy-based relaying implementation in Hermes.

Call To Action

Please read the document below and comment on this discussion thread with other types of relaying policies or any other kind of requirements.

Based on the replies to this discussion, we will put together a proper RFC for discussing various potential implementations.

Summary

Allow operators to define policies which control which IBC datagrams will be relayed by Hermes.

Motivation

As Hermes was being deployed, internally and by external entities, their respective operators manifested the need for being able to filter which IBC datagrams Hermes should relay in order to protect themselves from substantial costs due to blindly relaying (and paying for) every single IBC datagram emitted by the various chains the relayer was connected to.

At the moment, we have identified the following filters (hereafter policies):

• P1: Only relay datagrams between two clients (source/destination) if both clients are configured to use a 1/3 trust threshold for light client.
• P2a: On a per-chain basis, relay datagrams exclusively over any of the channel/port in the given list (allowlist).
• P2b: On a per-chain basis, only relay datagrams over any channel/port that is not present in the the given list (denylist).
• P3: Only relay IBC transfer packets which have a gas price higher than some predetermined value.
• P4: Only relay IBC datagrams sent by a given account or list of accounts.

Current State

As of Hermes v0.6.1, the relayer can already be configured in a somewhat ad-hoc way to filter the datagrams to relay based on policies P1, P2a, and P2b.

At the moment, policies P1 and P2 cannot be enabled or disabled independently of each other, and policies P2a and P2b are exclusive .

Moreover, policy P1 is hard-coded into Hermes, and operators cannot change the value of the trust threshold that is enforced, nor can they supply their own list of trust thresholds to allow.

Policies P2a and P2b are defined in the relayer configuration file in TOML:

# Example configuration of a channel filter, denying packet relaying
# on channel with port ID 'transfer' and channel ID 'channel-0':
[chains.packet_filter]
policy = 'deny'
list = [
  ['transfer', 'channel-0'],
]

Policies P3 and P4 are under consideration, and might be supported in a ad-hoc way until Hermes implements the present RFC.

[adizere]

[Adding here one more policy example, from a conversation with a relayer operator.]

P5: Allow/deny relaying of IBC datagrams based on the connection identifier.

An example syntax to extend the current (v0.11.0) policy and fulfil P5 (while maintaining backwards compatibility) could be:

[chains.connection_filter]
policy = 'deny'
list = [
  ['connection-0'],
]

I'm wondering what should happen if there is a conflict between packet_filter and connection_filter. For instance, a channel X could be "allowed" but the underlying connection "denied". Hermes will skip channel X, but that would be unintuitive. So not sure if the above extension is ideal.

[ancazamfir]

I imagine that under the connection filter you would only want to restrict connection message relaying for connections that use or not use some clients. Something like:

[chains.connection_filter]
policy = 'deny'
list = [
  ['07-tendermint-0'],
]

(For channels you would specify filtering based on client and/or connection ids, for channel message relaying)

I think with the requirement you describe the policy should be under packet filtering as it specifies how packet filtering should be done. Things could become complex. One example (it would look different in a policy language):

[chains.packet_filter]
policy = [
   'deny': ['connection-id`: ['connection-0']],
   'allow': ['port-id`: ['transfer'], 'channel-id': ['channel-0', 'channel-1',...],

So this could read "any transfer packet over a channel in the list that doesn't use connection-0". You can argue that the user could figure out which channels use connection-0 and just keep an 'allow' option. But this is still a valid configuration that has 3 filters that each could drop a packet. Here we cascade the filters (f1 /\ f2 /\ f3)
But you can imagine something like "any transfer packet OR any packet over a channel in the list that, packet doesn't use connection-0, i.e. f1 /\ (f2 \/ f3).