Change commitment payload to make it possible to easily add new items in the future.

[tomusdrw]

Currently we sign on MMR root only. In the future we know that there will most likely be MMB (Merkle Mountain Belt) implementation coming, or potentially MMR with different hash usage (non-keccak).
It would be nice if we could keep adding things to the commitment without breaking compatibility with older applications.

We could consider encoding something like:

payload: Vec<([u8; 4] /* id */, Vec<u8> /* payload */)>

And additionally we should enforce the payload to be sorted by id so that it's easy to find the payload one cares about.
Alternatively it can just be a list with fixed ordering (i.e. MMR payload always expected at position 0).

[tomusdrw]

Regarding MMB Alfonso from W3F is the main contact in case w start implementing this :)

[seunlanlege]

I think a fixed position saves on unnecessary bytes. should i go ahead and implement this?

[tomusdrw]

I'm thinking that the solution with ids would be much more flexible and would have less SCALE-compatibility issues long-term. Imagine that we have 5 different payloads which don't necessarily need to be supported by all chains. This means that we always have a Vec of 5 elements (older implementations might have a Vec of less elements though), and on some entries we will have None elements. With ids we will have few extra bytes, but the vector stays minimal and we don't have additional None entries.

We could maybe use 2-byte id instead though, cause 4-bytes seems like an overkill.

[seunlanlege]

closed?

[tomusdrw]

Closed via paritytech/substrate#10307

[tomusdrw]

CC @musnit @vgeddes