Support on-demand block production

[omritoptix]

With the introduction of rollups to the cosmos ecosystem, one financial aspect of it is to only produce block when there is demand for it (i.e txs) - This could cause blocks not to be created for hours.

Currently the relayer assumes both chains connected via IBC producing block within an interval (seconds order of magnitude).

This causes relayer not to relay packets/establish channel if the rollup chain is not producing blocks.

I believe this feature is highly important to support the future of IBC and rollups on cosmos.

[jtieri]

iirc each ChainProcessor implementation is free to configure their own polling parameters that are consumed in Run, afaik the relayer should attempt to query the block results for some height with a timeout set via blockResultsQueryTimeout, if it does not get a response within the timeout period that query cycle is given up on and a new query cycle is initiated. i may be missing some detail here but to me that would mean that the CosmosProcessor should just continue to poll for new blocks even if it fails to retrieve a response during a given query cycle.

I strongly agree that the relayer needs to accommodate rollups and I'm more than willing to work on any features/refactoring that needs to be done to ensure we can meet the requirements/needs of the Dymension team (as well as anyone else working on rollups in the ecosystem)

I see that you folks have a fork of the repo, is there anything I can do to help upstream your required changes so you all don't need to maintain a fork?

[omritoptix]

Thanks for the write up. The main issue we've ran into while trying to make it work was that connection/channel creation and IBC packets relaying need both chains to produce at least one block (from the moment the relayer started) in order to ignite the message submission process in the relayer.

in that case, if the on-demand chain has no demand for blocks during the handshake process, the connection/channel creation will fail.

For the ibc packet relaying, after the relayer started, it will need at least one block to be sent from the on-demand chain to ignite the process. After that process is ignited and no more blocks need to be created on the on-demand chain for smooth flow of packets, unless the relayer is restarted.

[gjermundgaraba]

Bumping into this issue with rollkit and lazy block production. If you guys have a good idea on how you would want this solved, I can take a crack at it.

[jtieri]

Bumping into this issue with rollkit and lazy block production. If you guys have a good idea on how you would want this solved, I can take a crack at it.

Bumping into this issue with rollkit and lazy block production. If you guys have a good idea on how you would want this solved, I can take a crack at it.

it looks like @danwt has maybe solved this issue in a forked repo??

I would love to see these changes upstreamed if so!! It would be great to have the main relayer repo support both dymension and rollkit. happy to help in any way that i can also!