Restructure Voyager to support plugins

[benluelo]

WIP!!!

The Problem

The voyager codebase is currently very monolithic, with every chain and chain connection hardcoded. While this does work very well, it very difficult to extend without intimate knowledge of the entire codebase. Ideally, it would be possible to write a "module"/"plugin" that for a single chain, data source, ibc endpoint, transaction submission, transformation, etc.

One of the main reasons that voyager is designed the way it is currently is due to how 08-wasm clients work in ibc-go currently (as of ibc-go v8): the native module wraps the counterparty state in a Wasm<> wrapper, which means the counterparty must be aware of this (since the state isn't just stored verbatim). This causes massive complexity when dealing with cosmos chains:

1. running a native and a wasm version of a light client has a different interface - the wasm module is not opaque, so you cannot treat an 08-wasm tendermint client the same way as you would treat an 07-tendermint native client
   • it is also not possible to have two cosmos chains connect to each other via wasm clients currently
2. the relayer needs to know what "kind" of client the 08-wasm client is, which is currently not possible - we have added a requirement that all wasm clients supported by voyager must include an exported global in their wasm blob that can then be parsed out of it.

Other than the above (main) points, the relaying is effectively the same - we make this all seamless in voyager by (ab)using rust's type system, and handling the Wasm<> wrapping as transparently as possible.

Current State

An ideal interface for voyager plugins/modules would be:

1. very simple and trivial to implement (the module writer should be as unaware of any underlying complexity as possible)
2. (at least) as expressive and powerful as the current design that leverages rust's type system
3. general enough to support any* chain, but specific enough that module writers don't have to reinvent the wheel every time

* no promises. solana is weird

This is obviously quite difficult, especially point 2 - it is very difficult to express trait bounds at run time. However, looking at the voyager codebase, the vast majority of trait bounds fall into one of three broad categories:

What is the {chain/ibc stack} interface I'm interacting with?

Although not the original design, the codebase of voyager (although still quite monolithic) has evolved into a separation of "execution/ ibc interface" vs "consensus". Often times there are trait bounds such as:

Hc: ChainExt<Config = EthereumConfig, SelfClientState: Encode<Tr::IbcStateEncoding>> + EthereumIbcChain

link

Which is basically just a very verbose, monolithic way of saying "this is an ethereum-like chain with an evm ibc interface (our solidity ibc stack)", or:

    Hc: ChainKeyring<Signer = CosmosSigner>
        + CosmosSdkChainSealed<
            MsgError = BroadcastTxCommitError,
            SelfConsensusState: Encode<Proto> + TypeUrl,
            SelfClientState: Encode<Proto> + TypeUrl,
        >

link

Which similarly says "this is a cosmos-like chain with ibc-go".

While this design is very verbose and complex (a lot of which could be improved with an overhaul of the traits used here), it is also incredibly powerful in that it allows one to just implement a set of traits for their type and it becomes possible to use it within the message system as defined by the relay-message library. link

Can X be encoded with encoding scheme Y?

The two main IBC interfaces we interact with currently - ibc-go and our solidity ibc stack - use different encodings, protobuf and ethabi respectively. As seen above, we frequently make use of these trait bounds when defining what chains are capable of interacting with each other. For example, the implementation of DoFetchState for cosmos-sdk based chains (link):

// abridged
impl<Hc, Tr> DoFetchState<Hc, Tr> for Hc
where
    Hc: CosmosSdkChainSealed
        + ChainExt<
            StoredClientState<Tr>: Decode<Proto>,
            StoredConsensusState<Tr>: Decode<Proto>,
        >,
    Tr: ChainExt<SelfClientState: Decode<Proto>, SelfConsensusState: Decode<Proto>>

This states that in order to fetch state on this chain, in the context of this chain Hc (host chain) tracking a counterparty Tr (tracking), both the way the host chain stores it's state of Tr must be protobuf decodable, and the state types of Tr must also be protobuf decodable. Similar trait bounds can be seen throughout the relay-message library.

Is the tuple (Hc, Tr) a valid chain connection/ do Hc and Tr know how to "talk" to each other?

This one is a bit more complex - given the traits defined above, it is possible to implement any chain connecting to any chain, as long as the trait bounds are satisfied. However, just because the trait bounds are satisfied doesn't mean that Hc and Tr actually know how to talk to each other (for example, while it would be trivial to satisfy the trait bounds required for an ethereum<->ethereum connection, it's not actually usable since there isn't an ethereum light client that can be run on ethereum).

The actual valid pairs are expressed via the top-level enum in relay-message:

union/lib/relay-message/src/lib.rs

Lines 215 to 253 in e170469

	pub enum AnyLightClientIdentified<T: AnyLightClient> {
	/// The 08-wasm client tracking the state of Ethereum<Mainnet>.
	EthereumMainnetOnUnion(lc!(Ethereum<Mainnet> => Wasm<Union>)),
	/// The solidity client on Ethereum<Mainnet> tracking the state of Wasm<Union>.
	UnionOnEthereumMainnet(lc!(Wasm<Union> => Ethereum<Mainnet>)),
	/// The 08-wasm client tracking the state of Ethereum<Minimal>.
	EthereumMinimalOnUnion(lc!(Ethereum<Minimal> => Wasm<Union>)),
	/// The solidity client on Ethereum<Minimal> tracking the state of Wasm<Union>.
	UnionOnEthereumMinimal(lc!(Wasm<Union> => Ethereum<Minimal>)),
	/// The 08-wasm client tracking the state of Scroll.
	ScrollOnUnion(lc!(Scroll => Wasm<Union>)),
	/// The solidity client on Scroll tracking the state of Wasm<Union>.
	UnionOnScroll(lc!(Wasm<Union> => Scroll)),
	/// The 08-wasm client tracking the state of Arbitrum.
	ArbitrumOnUnion(lc!(Arbitrum => Wasm<Union>)),
	/// The solidity client on Arbitrum tracking the state of Wasm<Union>.
	UnionOnArbitrum(lc!(Wasm<Union> => Arbitrum)),
	/// The 08-wasm client tracking the state of Berachain.
	BerachainOnUnion(lc!(Berachain => Wasm<Union>)),
	/// The solidity client on Berachain tracking the state of Wasm<Union>.
	UnionOnBerachain(lc!(Wasm<Union> => Berachain)),
	/// The native tendermint client on Union tracking the state of Wasm<Cosmos>.
	WasmCosmosOnUnion(lc!(Wasm<Cosmos> => Union)),
	/// The 08-wasm client on Cosmos tracking the state of Union.
	UnionOnWasmCosmos(lc!(Union => Wasm<Cosmos>)),
	/// The native tendermint client on Union tracking the state of Cosmos.
	CosmosOnUnion(lc!(Cosmos => Union)),
	/// The native cometbls client on Cosmos tracking the state of Union.
	UnionOnCosmos(lc!(Union => Cosmos)),
	/// The 08-wasm client tracking the state of Cosmos.
	CosmosOnCosmos(lc!(Cosmos => Cosmos)),
	}

...and then expressed in the trait system as follows:

union/lib/relay-message/src/chain/ethereum.rs

Lines 1194 to 1212 in e170469

	impl<C, Tr> DoAggregate for Identified<Ethereum<C>, Tr, EthereumAggregateMsg<C, Tr>>
	where
	C: ChainSpec,
	Tr: ChainExt<SelfClientState: Encode<EthAbi>>,
	Identified<Ethereum<C>, Tr, AccountUpdateData<C, Tr>>: IsAggregateData,
	Identified<Ethereum<C>, Tr, BootstrapData<C, Tr>>: IsAggregateData,
	Identified<Ethereum<C>, Tr, BeaconGenesisData<C, Tr>>: IsAggregateData,
	Identified<Ethereum<C>, Tr, FinalityUpdate<C, Tr>>: IsAggregateData,
	Identified<Ethereum<C>, Tr, LightClientUpdates<C, Tr>>: IsAggregateData,
	Identified<Ethereum<C>, Tr, LightClientUpdate<C, Tr>>: IsAggregateData,
	AnyLightClientIdentified<AnyFetch>: From<identified!(Fetch<Ethereum<C>, Tr>)>,
	AnyLightClientIdentified<AnyEffect>: From<identified!(Effect<Tr, Ethereum<C>>)>,
	AnyLightClientIdentified<AnyWait>: From<identified!(Wait<Tr, Ethereum<C>>)>,
	AnyLightClientIdentified<AnyData>: From<identified!(Data<Ethereum<C>, Tr>)>,
	AnyLightClientIdentified<AnyAggregate>: From<identified!(Aggregate<Ethereum<C>, Tr>)>,
	{

Without getting into too much detail, this is basically a way of expressing "(Hc, Tr) is a valid tuple as defined in AnyLightClientIdentified". The important part here is that Hc never knows what Tr actually is - it just knows that it's some valid counterparty that it can connect to, and this is fully statically verified at compile time. This is, of course, extremely limiting as well, as a 3rd-party integration now needs to fork voyager, implement all the required interfaces, and modify the top-level AnyLightClientIdentified enum. (Incredibly non-trivial, even I find it difficult at times and I designed the whole system!)

Potential Pieces to the Puzzle

We use json to represent everything in the voyager queue. For the state types that end up being encoded/decoded via various formats, they are still represented as json at the boundaries, and then (via the trait bounds mentioned in the previous section) converted to/from bytes as required.

Essentially, we need a way for a chain module to export the following functionality:

Given a counterparty ibc interface, decode my state the way it's encoded by my light client on the counterparty

• ethereum: ethabi
• near: borsh
• ibc-go <= v8, native client: protobuf, wrapped in any
• ibc-go <= v8, 08-wasm clients: arbitrary bytes (encoding is decided by the light client), wrapped in wasm, wrapped in any

As an example, the scroll light client on union is an 08-wasm client. The client running on union stores the state wrapped in Any<Wasm<T>> (outside the control of the light client). As such, the scroll chain plugin to voyager would need to export functionality to decode the wrapper and internal state, returning a json representation of it. An potential design could look like this (assuming json-rpc):

--> {"jsonrpc": "2.0", "method": "plugin_decodeClientState", "params": {"counterparty": "ibc-go/08-wasm", "bytes": "0xDEADC0DE"}}
<-- {"jsonrpc": "2.0", "result": {"type_url": "ibc.lightclients.wasm.v1.ClientState", "value": {"data": {/* actual client state here */}, "checksum": "0x12345...67890", "latest_height", {...}}}}

And then there would also be the inverse operation, to encode the client state back to bytes as stored on the counterparty:

--> {"jsonrpc": "2.0", "method": "plugin_encodeClientState", "params": {"counterparty": "ibc-go/08-wasm", "client_state": {"type_url": "ibc.lightclients.wasm.v1.ClientState", "value": {"data": {/* actual client state here */}, "checksum": "0x12345...67890", "latest_height", {...}}}}}
<-- {"jsonrpc": "2.0", "result": "0xDEADC0DE"}

A new issue arises in the fact that these client/ consensus state types have traits implemented on them:

union/lib/unionlabs/src/traits.rs

Lines 148 to 154 in 1812ee6

	pub trait ClientState {
	type ChainId: Member + Display + Eq + Hash;
	type Height: Member + IsHeight + MaybeArbitrary;
	fn height(&self) -> Self::Height;
	fn chain_id(&self) -> Self::ChainId;
	}

union/lib/unionlabs/src/traits.rs

Lines 302 to 304 in 1812ee6

	pub trait ConsensusState {
	fn timestamp(&self) -> u64;
	}

To emulate this at runtime (outside of the type system), there are two possible solutions:

• Expose a json-rpc method to, given bytes (or a decoded client state json), call a "function" on it a la client_state.height() -> json-rpc plugin_clientStateHeight(client_state)

• Use jsonpath or jaq (or something similar). Modules would expose an rpc method that would be called at startup, which would return all supported ibc interfaces (think ibc-go/08-wasm as used above) and the required jsonpaths to emulate calling trait methods on client state, consensus state, header, etc. This would enable a nice wrapper type pattern like this:

  struct ClientStateWrapper {
      pub height_path: JsonPath,
      pub chain_id_path: JsonPath,
      pub value: Value,
  }
  
  #[derive(Debug, Serialize, Deserialize)]
  pub struct Height {
      pub revision_number: u64,
      pub revision_height: u64,
  }
  
  impl ClientStateWrapper {
      pub fn height(&self) -> Result<Height, serde_json::Error> {
          serde_json::from_value(self.height_path.find(&self.value)[0].clone())
      }
  
      pub fn chain_id(&self) -> Result<String, serde_json::Error> {
          serde_json::from_value(self.chain_id_path.find(&self.value)[0].clone())
      }
  }
  
  #[derive(Serialize, Deserialize)]
  struct ClientState {
      pub height: Height,
      pub chain_id: String,
  }
  
  let client_state = ClientState {
      height: Height {
          revision_number: 1,
          revision_height: 100,
      },
      chain_id: "chain-id-1".to_owned(),
  };
  
  let wrapper = ClientStateWrapper {
      height_path: "$.height".try_into().unwrap(),
      chain_id_path: "$.chain_id".try_into().unwrap(),
      value: serde_json::to_value(client_state).unwrap(),
  };
  
  println!(
      "height: {:?}, chain_id: {:?}",
      wrapper.height().unwrap(),
      wrapper.chain_id().unwrap(),
  );
  
  // height: Height { revision_number: 1, revision_height: 100 }, chain_id: "chain-id-1"

Given an ibc event I have fetched from my chain, figure out what the counterparty is

This requirement can basically be boiled down to "what is the counterparty chain id (and module) of a client id?", and is currently handled here:

union/lib/voyager-message/src/lib.rs

Lines 252 to 320 in 1812ee6

	impl HandleData<VoyagerMessage> for VoyagerData {
	fn handle(
	self,
	store: &<VoyagerMessage as QueueMessage>::Store,
	) -> Result<Op<VoyagerMessage>, QueueError> {
	Ok(match self {
	Self::Block(data) => {
	macro_rules! block_data_to_relay_event {
	($($Variant:ident => {$(
	$ClientType:pat => ($Hc:ty, $BlockHc:ty, $Tr:ty),
	)*})*) => {
	match data.handle(store)? {
	$(Op::Data(block_message::AnyChainIdentified::$Variant(
	block_message::Identified {
	chain_id,
	t: block_message::data::Data::IbcEvent(ibc_event),
	},
	)) => <VoyagerMessage as FromOp<RelayMessage>>::from_op(
	match ibc_event.client_type {
	$($ClientType => {
	mk_relay_event::<$Hc, $BlockHc, $Tr>(chain_id, ibc_event)
	})*
	_ => unimplemented!(),
	},
	),)*
	msg => VoyagerMessage::from_op(msg),
	}
	};
	}
	let _span = info_span!("block").entered();
	block_data_to_relay_event!(
	Cosmos => {
	ClientType::Wasm(WasmClientType::Cometbls) => (Wasm<Cosmos>, Cosmos, Union),
	ClientType::Tendermint => (Cosmos, Cosmos, Cosmos),
	}
	Union => {
	ClientType::Wasm(WasmClientType::EthereumMinimal) => (Wasm<Union>, Union, Ethereum<Minimal>),
	ClientType::Wasm(WasmClientType::EthereumMainnet) => (Wasm<Union>, Union, Ethereum<Mainnet>),
	ClientType::Wasm(WasmClientType::Scroll) => (Wasm<Union>, Union, Scroll),
	ClientType::Wasm(WasmClientType::Arbitrum) => (Wasm<Union>, Union, Arbitrum),
	ClientType::Wasm(WasmClientType::Berachain) => (Wasm<Union>, Union, Berachain),
	ClientType::Tendermint => (Union, Union, Wasm<Cosmos>),
	}
	EthMainnet => {
	ClientType::Cometbls => (Ethereum<Mainnet>, Ethereum<Mainnet>, Wasm<Union>),
	}
	EthMinimal => {
	ClientType::Cometbls => (Ethereum<Minimal>, Ethereum<Minimal>, Wasm<Union>),
	}
	Scroll => {
	ClientType::Cometbls => (Scroll, Scroll, Wasm<Union>),
	}
	Arbitrum => {
	ClientType::Cometbls => (Arbitrum, Arbitrum, Wasm<Union>),
	}
	Berachain => {
	ClientType::Cometbls => (Berachain, Berachain, Wasm<Union>),
	}
	)
	}
	Self::Relay(data) => {
	let _span = info_span!("relay").entered();
	VoyagerMessage::from_op(data.handle(store)?)
	}
	})
	}
	}

and here (cosmos):

union/lib/block-message/src/chain/cosmos_sdk.rs

Lines 243 to 276 in 1812ee6

	CosmosSdkFetch::FetchClientTypeFromConnectionId(ClientTypeFromConnectionId {
	connection_id,
	}) => fetch(id(
	c.chain_id(),
	Fetch::specific(ClientTypeFromClientId {
	client_id: c.client_id_of_connection(connection_id.clone()).await,
	}),
	)),
	CosmosSdkFetch::FetchClientTypeFromClientId(ClientTypeFromClientId { client_id }) => {
	data(id(
	c.chain_id(),
	Data::<C>::specific(ClientType {
	client_type: match client_id.to_string().rsplit_once('-').unwrap().0 {
	"07-tendermint" => unionlabs::ClientType::Tendermint,
	"08-wasm" => unionlabs::ClientType::Wasm(
	match c
	.checksum_of_client_id(client_id.clone())
	.then(|checksum| c.client_type_of_checksum(checksum))
	.await
	{
	Some(ty) => ty,
	None => {
	warn!(%client_id, "unknown client type for 08-wasm client");
	// this early return is kind of dirty but it works
	return noop();
	}
	},
	),
	ty => panic!("unsupported client type {ty}"),
	},
	__marker: PhantomData,
	}),
	))
	}

and here (eth):

union/lib/block-message/src/chain/ethereum.rs

Line 340 in 1812ee6

pub async fn mk_aggregate_event<Hc, F, Fut>(

(note that for eth we assume all clients are cometbls, as that is currently the case)

There are two possible solutions to this:

• Chain modules must know about all connected counterparties. This is not ideal because it tightly couples the modules together; going back to the scroll example, this model would require that the union chain module would have hardcoded in itself that it can connect to scroll.
• Chain modules expose an entrypoint "is this my client?"
  • this is incredibly annoying for ibc-go 08-wasm clients:
    

    union/lib/unionlabs/src/lib.rs

    Lines 132 to 254 in 1812ee6

    	#[macro_export]
    	macro_rules! export_wasm_client_type {
    	($type:ident) => {
    	const _: $crate::WasmClientType = $crate::WasmClientType::$type;
    	$crate::paste! {
    	#[no_mangle]
    	#[used]
    	static [ <WASM_CLIENT_TYPE_ $type> ]: u8 = 0;
    	}
    	};
    	}
    	/// This type is used to discriminate 08-wasm light clients.
    	/// We need to be able to determine the light client from the light client code itself (not instantiated yet).
    	/// Light clients supported by voyager must export a `#[no_mangle] static WASM_CLIENT_TYPE_<TYPE>: u8 = 0` variable.
    	#[derive(Debug, Clone, Copy, PartialEq, Eq, Serialize, Deserialize)]
    	#[cfg_attr(feature = "arbitrary", derive(arbitrary::Arbitrary))]
    	#[serde(rename_all = "snake_case")]
    	pub enum WasmClientType {
    	EthereumMinimal,
    	EthereumMainnet,
    	Cometbls,
    	Tendermint,
    	Scroll,
    	Arbitrum,
    	Linea,
    	Berachain,
    	}
    	#[derive(Debug, Clone, PartialEq, Serialize, Deserialize)]
    	#[cfg_attr(feature = "arbitrary", derive(arbitrary::Arbitrary))]
    	#[serde(rename_all = "snake_case")]
    	pub enum ClientType {
    	Wasm(WasmClientType),
    	Tendermint,
    	Cometbls,
    	}
    	#[cfg(test)]
    	mod tests {
    	use super::*;
    	#[test]
    	fn wasm_client_type_serde() {
    	assert_eq!(
    	r#"{"wasm":"ethereum_minimal"}"#,
    	serde_json::to_string(&ClientType::Wasm(WasmClientType::EthereumMinimal)).unwrap()
    	);
    	}
    	}
    	impl ClientType {
    	#[must_use]
    	pub const fn identifier_prefix(self) -> &'static str {
    	match self {
    	ClientType::Wasm(_) => "08-wasm",
    	ClientType::Tendermint => "07-tendermint",
    	ClientType::Cometbls => "cometbls",
    	}
    	}
    	}
    	impl FromStr for WasmClientType {
    	type Err = WasmClientTypeParseError;
    	fn from_str(s: &str) -> Result<Self, Self::Err> {
    	match s {
    	"EthereumMinimal" => Ok(WasmClientType::EthereumMinimal),
    	"EthereumMainnet" => Ok(WasmClientType::EthereumMainnet),
    	"Cometbls" => Ok(WasmClientType::Cometbls),
    	"Tendermint" => Ok(WasmClientType::Tendermint),
    	"Scroll" => Ok(WasmClientType::Scroll),
    	"Arbitrum" => Ok(WasmClientType::Arbitrum),
    	"Linea" => Ok(WasmClientType::Linea),
    	"Berachain" => Ok(WasmClientType::Berachain),
    	_ => Err(WasmClientTypeParseError::UnknownType(s.to_string())),
    	}
    	}
    	}
    	impl Display for WasmClientType {
    	fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
    	match self {
    	Self::EthereumMinimal => write!(f, "EthereumMinimal"),
    	Self::EthereumMainnet => write!(f, "EthereumMainnet"),
    	Self::Cometbls => write!(f, "Cometbls"),
    	Self::Tendermint => write!(f, "Tendermint"),
    	Self::Scroll => write!(f, "Scroll"),
    	Self::Arbitrum => write!(f, "Arbitrum"),
    	Self::Linea => write!(f, "Linea"),
    	Self::Berachain => write!(f, "Berachain"),
    	}
    	}
    	}
    	#[derive(Debug, PartialEq, Eq, thiserror::Error)]
    	pub enum WasmClientTypeParseError {
    	#[error("unknown wasm client type `{0}`")]
    	UnknownType(String),
    	}
    	// TODO: Move this and the above types into tools/parse-wasm-client-type, and make it into a library with an optional `parse` feature (so as to not bring in the very heavy wasmparser stack where it's not needed)
    	pub fn parse_wasm_client_type(
    	bz: impl AsRef<[u8]>,
    	) -> Result<Option<WasmClientType>, WasmClientTypeParseError> {
    	wasmparser::Parser::new(0)
    	.parse_all(bz.as_ref())
    	.find_map(|payload| {
    	payload.ok().and_then(|payload| match payload {
    	wasmparser::Payload::ExportSection(e) => Some(e),
    	_ => None,
    	})
    	})
    	.and_then(|exports| {
    	exports.into_iter().find_map(|export| {
    	export
    	.ok()
    	.and_then(|export| export.name.strip_prefix("WASM_CLIENT_TYPE_"))
    	})
    	})
    	.map(str::parse)
    	.transpose()
    	}

    
    since there is no interface in ibc-go to query the "type" of a wasm client, and all wasm clients' client ids are of the form 08-wasm-{N}, we would need to pass additional information in this query along with the client id itself (the query would essentially be a tagged enum, where the tag is the ibc interface; ibc-go/08-wasm, ibc-go/native, evm, etc). Any chain module that exposes the ibc-go/08-wasm ibc interface would need to include the client type as parsed out of the wasm blob here.

---

Transformations/ Optimization Passes

Along with supporting a custom interface for chain plugins/modules, we should also allow for writing arbitrary plugins that build on top of the vm infrastructure directly, as defined here:

union/lib/queue-msg/src/lib.rs

Lines 76 to 156 in 1812ee6

	#[queue_msg]
	#[debug(bound())]
	// TODO: Merge "event" and "data", and "fetch", "effect", and "wait"
	// essentially what we want is "pure custom message" and "impure custom message"
	// all other logic can be built with aggregations
	pub enum Op<T: QueueMessage> {
	/// An external event. This could be something like an IBC event, an external command, or
	/// anything else that occurs outside of the state machine. Can also be thought of as an "entry
	/// point".
	Event(T::Event),
	/// Inert data that will either be used in an aggregation or bubbled up to the top and sent as
	/// an output.
	Data(T::Data),
	/// Fetch some data from the outside world. This can also be thought of as a "read" operation.
	Fetch(T::Fetch),
	/// Send a message to the outside world. This can also be thought of as a "write" operation.
	Effect(T::Effect),
	/// Wait for some external condition.
	Wait(T::Wait),
	Defer(Defer),
	/// Repeats the contained message `times` times. If `times` is `None`, will repeat infinitely.
	Repeat {
	#[serde(default, skip_serializing_if = "Option::is_none")]
	times: Option<NonZeroU64>,
	msg: Box<Self>,
	},
	/// Executes the contained message only if `timeout_timestamp` has not been hit.
	Timeout {
	timeout_timestamp: u64,
	msg: Box<Self>,
	},
	/// A sequence of messages to be executed in order. Messages are handled from the front, with
	/// new messages requeued at the front:
	//
	/// ```txt
	/// [A B C]
	/// D = handle(A)
	/// [D B C]
	/// ```
	Seq(VecDeque<Self>),
	/// A list of messages to be executed concurrently. If this is queued as a top-level message,
	/// each contained message will be requeued individually as a top-level message, however if it
	/// is nested within another message, it's semantics are as follows:
	///
	/// ```txt
	/// [A B C]
	/// D = handle(A)
	/// [B C D]
	/// ```
	///
	/// Note that this is similar to `Sequence`, except that the new messages are queued at the
	/// *back* of the list, allowing for uniform progress across all nested messages.
	Conc(VecDeque<Self>),
	/// Race a list of messages. The head of the list is handled, and if it returns no new messages,
	/// then the rest of the list is dropped; otherwise, the new message is pushed to the back of the
	/// list (similar to [`Self::Conc`]).
	///
	/// ```txt
	/// [A B C]
	/// D = handle(A)
	/// if D.is_none() noop else race([B C D])
	/// ```
	Race(VecDeque<Self>),
	/// Handle `msg`, retrying on failure. If `msg` fails, this will requeue itself with `remaining - 1`.
	Retry {
	remaining: NonZeroU8,
	msg: Box<Self>,
	},
	Aggregate {
	/// Messages that are expected to resolve to [`Data`].
	queue: VecDeque<Self>,
	/// The resolved data messages.
	data: VecDeque<T::Data>,
	/// The message that will utilize the aggregated data.
	receiver: T::Aggregate,
	},
	/// Handle the contained message, voiding any returned `Data` messages that it returns.
	Void(Box<Self>),
	Noop,
	}

This would be a very low-level, yet extremely powerful tool for advances use-cases, such as

[KaiserKarel]

Yeah I think overal this is a good design. As a plugin builder, I most likely want as little complex types as possible. Just a bunch of if statements on a json object gets you very far.

Configuration wise, if voyager exposes an API that I can call, for querying counterparties etc, even better. That way voyager is still SoT and I don't need to maintain a separate DB.