Open hu55a1n1 opened 2 years ago
ChainHandle
trait to provide a method that gives access to the maxExpectedTimePerBlock
param. /header
endpoint to get the parameter from Tendermint chains. (See https://github.com/informalsystems/tendermint-rs/issues/1106)ChainHandle
?) on startup. Cache the parameter (in the ChainHandle?) on startup.
You should be able to cache the value on first use in the CachingHandle, backed by a cache with no TTL.
I wonder if this feature is needed, or potentially blocking, anything. It seems like it would simplify relayer operator life, but more like a nice-to-have than a wanted feature/requirement.
I will optimistically move it to v2 milestone, but in case we see the need for it, we can re-prioritize it later.
It seems we need to query via genesis
, not header
, as suggested in an earlier comment. For production networks, it is usually impossible to get a response to the genesis
query because it is too large (100MB, see eg cosmoshub-4); the genesis_chunked
method is awkward because results are base64 encoded (apparently).
The best we can do would be then to rely on IBC-go to add a new gRPC endpoint for us to allow querying for for GenesisState
of connection.
We can programatically obtain the max_expected_time_per_block
from the Params
in there.
Quoting Anca below:
There is a GenesisState defined in the ibc protos that includes this.
In genesis there is a param max_expected_time_per_block
...
"ibc": {
..
"connection_genesis": {
"connections": [],
"client_connection_paths": [],
"next_connection_sequence": "0",
"params": {
"max_expected_time_per_block": "30000000000"
}
},
Depends on https://github.com/cosmos/ibc-go/issues/1628 -- priority note: The issue will likely be ready in Q4/2022.
Summary
hermes
currently expects users to provide themax_block_time
parameter in the config and uses it to calculate the connection block delay as well as max clock drift. We can get this parameter directly from the chain (eg. using the/header
Tendermint ABCI endpoint). Also, since this is a genesis parameter and isn't expected to change, we can cache it.PS: Thanks to @ancazamfir for these ideas!
Acceptance Criteria
maxExpectedTimePerBlock
param.max_block_time
config parameter. Also, remove this config parameter entirely.For Admin Use