Hermes relaying policy based on minimum gas price

[adizere]

Crate

ibc-relayer

Summary

Quoting from a conversation with DeX team:

feature that would be really useful: relayer min gas-prices (per chain). A param that would enable us to only relay IBC transfer packets that have a gas-prices value superior to it. This way we could avoid relaying 0-fee txs and limit spamming

Based on conversations with SDK team, it seems unfeasible at the moment to implement support in Hermes for filtering based on gas price, because this information does not end up in the events that Hermes receives, and which it uses to relay packets. To find out the gas price, Hermes would need to query for the transaction, which is an additional round-trip per tx on average. This could be an acceptable overhead, or alternatively we can try to patch the SDK and backport the necessary changes so that the even system includes details about gas price, but it's unclear if this effort is worthwhile in the light of the upcoming relayer fees (#1168).

Update: The SDK adapted the changes necessary for emitting the fee in the event system cosmos/cosmos-sdk#9860 (comment). The feature will be on the 0.43 SDK line. We're planning to adapt Hermes with milestone 09.2021 and add this feature.

Problem Definition

Currently Hermes relays all packets associated with a channel that is allowed (#69). This allows for a situation where a user can submit to a chain a MsgTransfer packet specifying zero fees (similar to a spam message), the chain could potentially accept the transaction, and Hermes would relay that message to the destination chain.

Hermes v0.6.0 has no support to filter out packets based on the fees/gas that a packet pays at the source chain. It is not clear how to do so, because the event associated with the packet does not seem to include information about fees.

Specifically, upon a send packet for a MsgTransfer, the source chain generates and sends to Hermes a raw event that looks like this:

 events: {
    "ibc_transfer.receiver": [
        "cosmos18y63eeu539qld8syhk7skwcy2edfn9k5dr8a08",
    ],
    "send_packet.packet_src_channel": [
        "channel-0",
    ],
    "tm.event": [
        "Tx",
    ],
    "ibc_transfer.sender": [
        "cosmos1xcvkugkqcq4fxxkgkv9y4xwnkheufz7pg9p736",
    ],
    "send_packet.packet_src_port": [
        "transfer",
    ],
    "message.action": [
        "transfer",
    ],
    "send_packet.packet_timeout_timestamp": [
        "0",
    ],
    "send_packet.packet_dst_port": [
        "transfer",
    ],
    "send_packet.packet_connection": [
        "connection-0",
    ],
    "transfer.sender": [
        "cosmos1xcvkugkqcq4fxxkgkv9y4xwnkheufz7pg9p736",
        "cosmos1xcvkugkqcq4fxxkgkv9y4xwnkheufz7pg9p736",
    ],
    "send_packet.packet_timeout_height": [
        "1-9236",
    ],
    "message.module": [
        "ibc_channel",
        "transfer",
    ],
    "message.sender": [
        "cosmos1xcvkugkqcq4fxxkgkv9y4xwnkheufz7pg9p736",
        "cosmos1xcvkugkqcq4fxxkgkv9y4xwnkheufz7pg9p736",
    ],
    "transfer.recipient": [
        "cosmos17xpfvakm2amg962yls6f84z3kell8c5lserqta",
        "cosmos1a53udazy8ayufvy0s434pfwjcedzqv34kvz9tw",
    ],
    "tx.hash": [
        "5622227C5F80B1FBFE6D3ABEB4B82EEC0FAE6FE871653B283FB4CC81D3A3E82E",
    ],
    "transfer.amount": [
        "85stake",
        "500samoleans",
    ],
    "send_packet.packet_data": [
        "{\"amount\":\"500\",\"denom\":\"samoleans\",\"receiver\":\"cosmos18y63eeu539qld8syhk7skwcy2edfn9k5dr8a08\",\"sender\":\"cosmos1xcvkugkqcq4fxxkgkv9y4xwnkheufz7pg9p736\"}",
    ],
    "send_packet.packet_sequence": [
        "4",
    ],
    "tx.height": [
        "8222",
    ],
    "send_packet.packet_channel_ordering": [
        "ORDER_UNORDERED",
    ],
    "send_packet.packet_dst_channel": [
        "channel-1",
    ],
},

Hermes uses the above raw event data to build the RecvPacket, which it eventually submits to the destination chain. The only information about gas/fees here is the first element of the vector "transfer.amount", which is 85stake, but it seems this vector is sometimes only 1 element (the value of the transfer), so it's not clear if Hermes can reliably use this information to detect zero-fee (or "spam") packets.

The raw event pasted above is represented as a field called events from the tendermint_rpc crate Event object. Note that this field has no type information (it's just strings in a hashmap).

It is possible to obtain information about the gas that a transaction uses, but that is encoded in a different object called TxResult, and we'll need to investigate if the data from this object can be correlated reliably with the raw event pasted above.

For completeness, here is a snippet of how the result is represented:

       result: TxResult {
            log: Some(
                "[omitted]",
            ),
            gas_wanted: Some(
                "84972",
            ),
            gas_used: Some(
                "77157",
            ),  ....

Proposal & acceptance criteria

• investigate if we can reliably correlate the field events of a tendermint_rpc::event::Event with the gas information that can be found in the inner structure result of that Event. Note that the result is three layer deep nested inside the Event: Event -> data -> tx_result -> result

• if we can correlate the two, then add support in the configuration file for a relaying policy that specifies a minimum gas

• decide which is the relevant field of a result between the two: gas_wanted and gas_used, for parametrizing the relaying policy, and that is the field that the policy will correspond to

• the points above are no longer a concern since we want to filter based on neither of gas_wanted nor gas_used, but on gas_price.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[adizere]

Closing as outdated.