Hermes: XRPL Validation message service
Published: 2022-08-20 15:39:00

[XRPScan](https://xrpscan.com/) is one of the most popular XRPL explorer and network analysis platform. Our [Amendments](https://xrpscan.com/amendments) and [Validators](https://xrpscan.com/validators) registry is widely used by the community to keep track of the state of the XRP Ledger.

Validator agreement data is generated on the basis of validations emitted by the validators. However, these validations are not on-ledger. There are a few sources that track validator agreement, but none that we're aware of are 100% resilient or supported.


## Introducing Hermes (Beta)

[Hermes](https://github.com/xrpscan/hermes) is a layer 2 messaging network for storing and relaying XRPL validation messages. Hermes servers can be linked together to create a P2P network to spool `validationReceived` messages emitted by rippled.

Validation messages are ephemeral, therefore they must be saved as soon as they're emitted. If a service processing XRPL Validation messages need to be momentarily offline (due to an outage, service restart or upgrade), it can fetch missing Validation messages from the Hermes network. Hermes server offers data access via REST and gRPC endpoints.

Access to historical validation messages opens the possibility of evaluating validators for their robustness or for inclusion/exclusion from UNLs.


## Architecture

![Hermes architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/20jo7jwbi1zo5bxhgv8w.png)


## Installation

Hermes server is tested on Linux. It needs **OpenSSL** binaries, **MongoDB**, access to **rippled** and **Node.js** runtime.

Please follow [installation guide](https://github.com/xrpscan/hermes#installation) to run Hermes locally and peer with other nodes.


## Recommendations

Assuming 3.85 seconds ledger interval time, polling every 1 hour and fetching 2000 ledger validations may provide a good balance between data coverage and network traffic.

```
PEERSYNC_ENABLED = true
PEERSYNC_POLL_INTERVAL = 3600
PEERSYNC_FETCH_DEPTH = 2000
```


## Performance test

XRPL closes roughly **21,500** ledgers a day. To do this, it generates more than **3.4 Million** (mainnet and other nets) validation messages every day. We performed a simple test on our test server to measure how much time it takes to sync mainnet validation messages from the p2p network.

| Range    | Ledgers  | Validations  | Time        |
| -------: | -------: | -----------: | ----------: |
| 1 hour   |     898  |     117,021  |   0m3.051s  |
| 1 day    |  21,501  |   2,791,281  |   1m1.338s  |
| all      | 391,058  |  34,322,489  | 13m11.065s  |


## Beta participants

Following Hermes servers are available for beta testing. If you're willing to run an instance and would like to peer with us, use this endpoint:

- [vms.test.xrpscan.com](https://vms.test.xrpscan.com/)


## What can be improved

Hermes servers collect validation messages directly from the rippled servers they're connected to, therefore a lot of peersync response contains duplicate validation messages. To optimize data transferred over the p2p network, Hermes would need to add a de-duplication strategy at the request time.

## Conclusion

We hope this project provides a way to persist validation messages and allow granular access to validator performance data. Our goal is to provide high-quality validation data, so the network operators can make objective decisions about their UNLs.

If you're running a Hermes server, we'd love to peer with your node. Please [contact us](https://twitter.com/xrpscan) and we'd get peering.


## Thank you

Thank you to [XPRL Grants](https://xrplgrants.org/) for sponsoring this project. A special thank you to [XRPL Foundation](https://foundation.xrpl.org/) for providing testing infrastructure, and to [nixerFFM](https://twitter.com/nixerFFM) for independently running various Hermes prototypes.

---