[SPIKE]: Determine how to handle messages pallet state growth

[JoeCap08055]

Feature Description

Details

The messages pallet currently stores all messages in its state. This has the potential for unbounded chain state growth and associated cost and performance penalties. We need to discuss the path forward to avoid this.

Possibilities

(note, the following are merely suggestions for exploration, not a limit on the options to be discussed)

1. Ring-buffer-like state storage with max # of messages
Pros:

• should be simple to implement, keeps latest messages queryable in state storage
  Cons:
• if bound by # of messages, more activity == short time span of retained messages
• getting historic messages become difficult (or impossible?)

2. Time-bound state storage
Similar to # 1, but instead of being bound by # of messages, it's bound by message age
Pros:

• Messages "live" for a defined period of time
  Cons:
• Expensive to implement on-chain writes
• Same issues with retrieving messages that have aged out

3. Event-based messages stream
Instead of storing messages in state storage, emit messages as individual events in the block. (Currently, we emit a single, parameterless MessagesInBlock event for any block that has any messages in it.
Pros:

• No state storage growth
• archive nodes would preserve all messages
  Cons:
• Message retrieval changes; must retrieve via RPC or runtime call, not state query.
• Historical messages require an archive node

4. Hybrid approach
A combination of # 1 & # 3 might work well: keep a small working set of the latest messages in state storage, for easy retrieval by applications that are "keeping current"; for older messages, an archive node provides complete message history.

Searched for Related Issues

• I have done a search for related issues and either found none, or noted them