Display HRMP/XCM channels for parachains

[vstakhov]

It might be useful to debug messages in the introspector. As the first step, I would suggest to add these fuctions to the parachains commander and then, probably, to the collector.

• Inspect inbound HRMP
• Inspect outbound HRMP
• Inspect UMP/DMP

Example:

2022-11-23T15:41:00.005000000Z +6002ms [#12] CANDIDATE BACKED
	💜 Candidate hash: 0x44b136826f6ea3cc1d1a92059a65d5eecd795b643c44fa3bc5fa4b30923b99b6
	🔗 Relay block hash: 0x3254d1eb7ca142a11b89755399dd76554b7e5752cc47fa6226f8b4895fbbd440
	👊 Disputes tracked
		👍 Candidate: 0x3d4f8a76b3c0ee1b809972df6510ab3de47e272260bfdbdfd9bbc14c2e3410fc, resolved valid; voted for: 6; voted against: 1
			👹 Validator voted against supermajority: idx: 3, address: 5HKPmK9GYtE1PSLsS1qiYU9xQ9Si1NcEhdeCq9sw5bqu4ns8
	👉 Inbound HRMP messages, received 4096 bytes in total
		📩 From parachain: 1002, 4096 bytes
	👈 Outbound HRMP messages, sent 4096 bytes in total
		📩 To parachain: 1002, 4096 bytes
	🥝 Availability core OCCUPIED

[sandreim]

Nice work! Can you describe how you want to approach the XCM message parsing ? Especially what kind of things we would be interested in seeing ?

I would suggest an alternative to get all the information without fetching the messages by decoding the HrmpChannel struct for each channel open to/from a para. We can compute the tput by substracting the total_sizes and msg_count between 2 relay parents that backed consecutive candidates of the para.

pub struct HrmpChannel {
	// NOTE: This structure is used by parachains via merkle proofs. Therefore, this struct requires
	// special treatment.
	//
	// A parachain requested this struct can only depend on the subset of this struct. Specifically,
	// only a first few fields can be depended upon (See `AbridgedHrmpChannel`). These fields cannot
	// be changed without corresponding migration of parachains.
	/// The maximum number of messages that can be pending in the channel at once.
	pub max_capacity: u32,
	/// The maximum total size of the messages that can be pending in the channel at once.
	pub max_total_size: u32,
	/// The maximum message size that could be put into the channel.
	pub max_message_size: u32,
	/// The current number of messages pending in the channel.
	/// Invariant: should be less or equal to `max_capacity`.s`.
	pub msg_count: u32,
	/// The total size in bytes of all message payloads in the channel.
	/// Invariant: should be less or equal to `max_total_size`.
	pub total_size: u32,
	/// A head of the Message Queue Chain for this channel. Each link in this chain has a form:
	/// `(prev_head, B, H(M))`, where
	/// - `prev_head`: is the previous value of `mqc_head` or zero if none.
	/// - `B`: is the [relay-chain] block number in which a message was appended
	/// - `H(M)`: is the hash of the message being appended.
	/// This value is initialized to a special value that consists of all zeroes which indicates
	/// that no messages were previously added.
	pub mqc_head: Option<Hash>,
	/// The amount that the sender supplied as a deposit when opening this channel.
	pub sender_deposit: Balance,
	/// The amount that the recipient supplied as a deposit when accepting opening this channel.
	pub recipient_deposit: Balance,
}

If we prioritize the collector to process these first, they could already be in storage, so we would just need to fetch them from there. But that's for later.

[vstakhov]

I'm inclined to think that it is better to dump transport protocols here and then do xcm decoding as a separate tool as suggested in #163

[sandreim]

I'm inclined to think that it is better to dump transport protocols here and then do xcm decoding as a separate tool as suggested in #163

You mean save the messages to disk from parachain commander ?