The Hermes team has just released Hermes v1.6!
Compared to the previous v1.5 release, this one is certainly smaller. The main feature included in this release is the addition of a “pull” mode alternative to the pre-existing “push” mode for fetching chain events. This feature allows Hermes to natively support WASM relaying, something that it has been unable to do until now. We’ll go into more detail on what these two modes mean, how they differ, and what their use-cases are.
The longstanding method that Hermes has used in order to catch chain events is by subscribing to a WebSocket endpoint that each chain exposes. We call this push-based relaying because the chain is making these events available and pushing them out; Hermes catches them as they become available.
To go with a simple analogy, you can imagine that the chain’s WebSocket endpoint is like a faucet where water is streaming out; the chain events are analogous to the water coming out of the faucet. The Hermes supervisor, which is the component that is responsible for listening to WebSocket endpoints and catching the relevant events, is a bit like a cup or a bucket that sits under the running stream of water. Note though that there are events emitted from the WebSocket endpoint that the Hermes supervisor is not interested in, so it isn’t catching all of the water per se; this is where this analogy breaks down a bit. In a way, each chain is “pushing” events to Hermes.
In contrast, pull-based relaying sees Hermes doing the work of polling events from chains’ /block_results RPC endpoint. In this mode, the onus is on Hermes to query the chains for the relevant events, hence why it is known as “pulling”.
From the testing that we’ve done, there doesn’t seem to be any marked difference performance-wise between the two modes. That being said, we have not at this point in time managed to extensively benchmark these two relaying modes against one another with different chain setups and relaying environments, so this assessment should be taken with a grain of salt.
In general, we recommend continuing to utilize the WebSocket-based relaying mode. The RPC-based mode should be thought of as a backup for situations when Hermes is not picking up all the chain events that it should be, such as when relaying for WASM-enabled chains that emit IBC events that are missing the message attribute. Without this attribute, the WebSocket is not able to catch these events to stream to Hermes, so the /block_results RPC endpoint must be used instead.
Hermes v1.6 introduces breaking changes to the Hermes configuration. In order to upgrade, you’ll need to remove the websocket_addr config option from the Hermes config.toml in favor of the new event_source setting. This needs to be done in every chain configuration section.
The event_source parameter receives an inline table of values. In order to maintain the default behavior of receiving events via WebSocket, you can configure the event_source setting like so:
1event_source = { mode = 'push', url = 'ws://127.0.0.1:26657/websocket', batch_delay = '500ms' }
When configuring this mode, you’ll need to specify the URL of the WebSocket endpoint that Hermes listens to. You’ll also need to specify the batch_delay parameter, which specifies the maximum amount of time between event batches that Hermes receives. In this mode, Hermes receives a new batch of events from a chain once the batch_delay parameter has elapsed, or when a new block has been created on that chain, whichever occurs first.
If you’d instead like to enable pull-based relaying over the /block_result RPC, that can be done like so:
1event_source = { mode = 'pull', interval = '1s' }
When this mode is enabled, you’ll need to specify the time interval in seconds that you would like Hermes to query the /block_results RPC endpoint.
With Hermes v1.6, Hermes is now able to natively support WASM relaying. Before the addition of this feature, chains that relayed WASM messages, such as Neutron, needed to introduce bespoke logic to work around this limitation in Hermes. Going forward, these sorts of workarounds will no longer be necessary.
This post certainly did not cover everything that came bundled in the v1.6 release. For the full list of everything included in the v1.6 release, please take a look at the changelog.
If you’d like to keep up with the Hermes team’s work, please follow the project on GitHub. You can also follow Informal System’s twitter account in order to receive updates on what every team at Informal is working on!