feat(node): guardian signed delegate signatures broadcast

[evan-gray]

This returns the gossip message time restriction pre #4743 in favor of a canonical guardian only approach. This allows any guardian to collect a quorum of delegated guardian set signatures for a message and broadcast them in a single message.

The goal is that this should maintain the same safeguards and security of the original delegated guardian set messages but provide the same security / DoS prevention as observation requests.

Tested with https://api.wormholescan.io/api/v1/observations/delegate/50/00000000000000000000000062deeafee06c7442a21c93ededc79a0cb5791c83/1750

This required a change in Wormholescan to store the full data from the gossip message, so some earlier messages may not contain all the relevant fields. I expect that if a prior message was needed for some reason, it could either be re-observed or the data could be backfilled.

Reviewers: the most critical code is in p2p.go 👀

---

Summary

• Add broadcast-delegate-signatures admin command that fetches delegate observations from the wormholescan API for a given VAA ID and rebroadcasts them on the delegated_attestation p2p topic
• Introduces a new DelegateSignaturesBroadcast gossip message type that carries observation data once with a compact array of per-guardian (addr, sent_timestamp, signature) tuples
• The CLI client fetches from wormholescan, groups by hash, verifies each delegate signature by reconstructing the original DelegateObservation bytes, and sends only verified signatures to the guardian node
• The admin server is a thin passthrough that forwards the pre-built broadcast to p2p for signing and publication
• Receiving guardians verify both the broadcast envelope (canonical guardian signature) and each inner delegate signature, then feed them into the existing delegate observation processor pipeline

[johnsaigle]

@claude

[github-actions]

Claude Code is working…

I'll analyze this and get back to you.

View job run

[johnsaigle]

Given that we're doing checks against the current Guardian Set on one level, and the delegated/canonical sets on another level, do we need to worry about the boundary cases like:

• Changing a Guardian Set?
• Changing the Delegated Guardian Set for a chain?

[johnsaigle]

I think we should update the test coverage to make sure we're handling the non-VAA-hash-related fields correctly.

Otherwise, the rest of the comments are improvements but IMO they do not need to block the PR.

[mdulin2]

Looks pretty good to me! The checks on the single signature appear to all be done on the batch case as well.

[johnsaigle]

A few small notes for test coverage and logging in case we hit size limits on the p2p layer.
Otherwise looks good and I'm happy to approve once these are resolved.

[djb15]

Approving changes to gossip.proto