fix(gno): support inter-realm cross-calls in voyager tx and state plugins

[aronpark1007]

Summary

Rewrites gno tx plugin msg templates for the new inter-realm cross-call convention, fixes state-module parsing, and completes gno event-source parsing for batch_send/packet_ack which were previously unimplemented stubs.

Changes

voyager/plugins/transaction/gno/src/main.rs

• Rewrite all datagram templates to types.NewMsg*(...) constructors under cur realm / cross(cur)
• Restore relayer wiring via fee_recipient

voyager/modules/state/gno/src/main.rs

• Accept both old/new parse_gno_string_object return formats
• Find PacketSend event by type instead of by index
• Stop hardcoding the core realm path in query_packet_by_hash

voyager/plugins/event-source/gno/src/ibc_events.rs

• Add chunked_attr helper to reassemble hex values gno splits across multiple attrs, used for packet_data, acknowledgement, maker_msg
• Implement BatchSend { packet_hash, batch_hash, channel_id } parsing (previously {} stub)
• Implement PacketAck { packet_hash, source_channel_id, source_connection_id, source_connection_client_id, destination_channel_id, destination_channel_version, destination_connection_id, destination_connection_client_id, timeout_timestamp, acknowledgement, maker } parsing (previously {} stub)
• Trim PacketRecv down to the fields gno actually emits (packet_hash, destination_channel_id, maker_msg)

voyager/plugins/event-source/gno/src/lib.rs

• Wire up BatchSend/PacketAck construction (channel/connection state queries → ibc_union_spec::event assembly)
• Fix PacketRecv match arm to the trimmed field set

Test plan

• cargo +nightly-2025-12-05 check -p voyager-event-source-plugin-gno passes cleanly (workspace-wide cargo check is blocked by an unrelated macOS/nightly embed-commit link-section issue, not touched by this branch)
• Manually cross-checked every parsed attribute key/type against the actual gno contract emit call sites (e.g. emitPacketAckEvent) to confirm they match

[vercel]

@aronpark1007 is attempting to deploy a commit to the unionbuild Team on Vercel.

A member of the Team first needs to authorize it.

[aronpark1007]

Right now the gno event interface defines every field the on-chain event emits, but most of them end up marked _ (unused) at the point they're actually consumed. Looking at other chains, e.g. Sui, the event interface only defines the fields that are actually parsed/used, and the rest (like packet metadata) is filled in later via RPC queries. Would it make sense for gno to trim its event interfaces down to just the fields that are actually consumed, following the same pattern?

For example, PacketAck:

union/voyager/plugins/event-source/gno/src/ibc_events.rs

Lines 84 to 96 in 75feaf2

	PacketAck {
	packet_hash: H256,
	source_channel_id: ChannelId,
	source_connection_id: ConnectionId,
	source_connection_client_id: ClientId,
	destination_channel_id: ChannelId,
	destination_channel_version: String,
	destination_connection_id: ConnectionId,
	destination_connection_client_id: ClientId,
	timeout_timestamp: Timestamp,
	acknowledgement: Bytes,
	maker: String,
	},

is only actually consumed like this (rest marked _):

union/voyager/plugins/event-source/gno/src/lib.rs

Lines 1014 to 1026 in 75feaf2

	IbcEvent::PacketAck {
	packet_hash,
	source_channel_id,
	source_connection_id: _,
	source_connection_client_id: _,
	destination_channel_id: _,
	destination_channel_version: _,
	destination_connection_id: _,
	destination_connection_client_id: _,
	timeout_timestamp: _,
	acknowledgement,
	maker: _,
	} => {

vs. Sui's equivalent, which only carries the fields it needs:

union/voyager/plugins/event-source/sui/src/events.rs

Lines 119 to 124 in 75feaf2

	pub struct PacketAck {
	pub channel_id: u32,
	pub packet_hash: Vec<u8>,
	pub acknowledgement: Vec<u8>,
	pub maker: SuiAddress,
	}

[benluelo]

@aronpark1007 the event parsing can also be implemented more intelligently to use all of the emitted fields in the gno event, up to y'all how you want to emit them on-chain

[aronpark1007]

@benluelo
Fixed the bptree proof verification issue — gno.land switched its main store from IAVL to a bptree store (gnolang/gno#5937), which uses a different ics23 spec (ics23:bptree vs IAVL), so our gno light client couldn't verify proofs anymore and relayers started failing with spec-mismatch errors.

Added a BPTREE_PROOF_SPEC/GNO_SPECS in lib/ics23 matching gno's actual bptree spec, wired it into the gno client-bootstrap so new clients use it, and along the way found+fixed an inverted max_depth check bug in ics23 that was silently broken until now. Added a regression test using a real proof pulled from topaz-1 (post-migration) to make sure it actually verifies.

[tbruyelle]

For reference, here is what we had to do for our ts-relayer to support ics23:bptree spec https://github.com/allinbits/ibc-v2-ts-relayer/pull/24/changes

[benluelo]

given the changes to the proof format, we'll either 1. need to implement a bptree verifier in solidity or 2. use proof lens clients for gno

[aronpark1007]

@benluelo, Confirmed proof-lens bridging works correctly on-chain end to end. One issue we ran into along the way:

voyager-plugin-transaction-batch and voyager-plugin-transaction-batch-proof-lens can end up registered on the same chain, but the plain transaction-batch plugin can't handle events for a proof-lens client (encode_proof intentionally errors — "proofs for this client must be encoded for the underlying l1 client"). Since both plugins' interest_filter is effectively "take everything" (Any) or "take only these ids" (Many), leaving either on Any causes it to grab events meant for the other, causing a fatal error.

Working around this today by scoping both to Many with disjoint, explicitly-listed client_ids per chain — which works, but means manually maintaining an up-to-date id list any time a client is (re)created on that chain.

Is there a better way to handle this scoping, or would you be open to adding a Deny variant to ClientConfigsSerde (exclude a small set of ids, allow everything else) so we only need to track the proof-lens id(s) instead of every other client on the chain?

[benluelo]

the normal batch plugin and the proof lens plugin are mutually exclusive; only one needs to be registered for a chain. having both of them registered doesn't make any sense

[aronpark1007]

the normal batch plugin and the proof lens plugin are mutually exclusive; only one needs to be registered for a chain. having both of them registered doesn't make any sense

You were right — we had transaction-batch and transaction-batch-proof-lens both registered on the same chain, which was unnecessary. Removed the plain transaction-batch entry for that chain and reverted the proof-lens one back to Any. Confirmed bidirectional transfer works end-to-end with this simpler setup.

Thank you for the quick feedback!

[aronpark1007]

gno tx plugin error handling

Previously every gno tx failure was retried forever. This PR classifies known errors.gno failures into drop-vs-retry:

Error string	Handling	Reason
packet already acknowledged	Dropped	already finalized elsewhere
acknowledgement already written	Dropped	already finalized elsewhere
packet commitment not found	Dropped	already acked/timed out
packet already received	Dropped	duplicate recv
packet timeout expired	Dropped	dest-side timeout already passed
packet commitment already exists	Dropped	duplicate send
batch packets not found	Dropped	batch already processed
batch receipts not found	Dropped	batch already processed
port already registered	Dropped	idempotent, already done
caller not authorized to write ack / ...send packet	Dropped (error-logged)	signer/config bug
rlm does not match crossing frame / rlm is not proxy realm	Dropped (error-logged)	wiring bug
not enough packets / batch must use the same channel	Dropped (error-logged)	msg construction bug
invalid counterparty connection id / ...channel id	Dropped (error-logged)	msg construction bug
timeout must be set	Dropped (error-logged)	malformed packet
acknowledgement mismatch / ...count mismatch / ...cannot be empty	Dropped (error-logged)	malformed ack
client not found / connection not found / channel not found / port not found	Dropped (error-logged)	stale/wrong id (ids are never deleted)
invalid connection state / invalid channel state	Retry (unconfirmed)	might be mid-handshake race, might be stale msg
client is not active	Retry (unconfirmed)	frozen/expired client, unsure if recoverable
packet receipt not found	Retry (unconfirmed)	might be an indexing race
client state / consensus state / membership proof not found`	Retry (unconfirmed)	might be an indexing race
packet timeout not reached	Retry (intentional)	should self-resolve once time passes
packet combined data too large	Retry (out of scope)	should split batch instead, follow-up

@benluelo, Would appreciate confirmation on the Retry (unconfirmed) rows — can any of these actually be permanent, or are they always transient races?

[benluelo]

looks fine to me, any issues will be sorted out as Voyager is actually run anyways.

[moul]

fyi, gnolang/gno#5937 is merged.