Mailbox.process()
to deliver the message. The Relayer merely provides a convenience service for message senders.
It’s important that the Validator only signs finalized checkpoints to avoid compromising the safety of the protocol. Signing messages that get reorged out leads to slashing in the economic security module. The Validator agent connects to a single chain to check for new messages. If validating multiple chains, multiple instances of this agent must be run.
Hyperlane is developing the validator as a binary implemented in Rust that can be easily run by anyone. Operationally, validators need to run this binary and have access to an RPC provider or node for the chain that they are validating for. We hope that the majority of Hyperlane validators will come from each chain’s existing node operator community.
announce
transaction. This is the only transaction ever submitted by the Validator agent; the blockchain-specific key is otherwise not used at all. There is also the option of manually announcing a new Validator to avoid configuring the blockchain-specific key. Validators can be announced by anyone.
For messages using a Multisig ISM, validators read the current merkle root by calling MerkleTreeHook.latestCheckpoint()
.
Validators use the MerkleTreeHook.latestCheckpoint()
function to determine when new transactions need to be indexed. This polling mechanism ensures validators can start signing new messages without the need to backfill the entire tree.
deploy(validatorAddresses, threshold)
transaction on any implementation of StaticThresholdAddressSetFactory.
InsertedIntoTree
from the Merkle Tree Hook contract that the Mailbox calls whenever a new message is dispatched. This happens over RPC, and the agent builds an in-memory merkle tree based on the merkle insertion events, which are also cached to a local RocksDB database for fast startup. Whenever a new message is dispatched, the Checkpoint Submitter generates a checkpoint from the in-memory tree and adds it to a queue for processing.