[Utility] Per-chain Relays To Token Multiplier

[Olshansk]

Objective

Feature parity with RTTM from Morse.

Origin Document

• [Living Ticket] Prepare tickets/work that need to be completed during Alpha TestNet #437
• Pocket Forum PIP33
• [v0.11 feature] Per-chain Relays To Token Multiplier pocket-core#1580

Goals

• Achieve RTTM parity w/ Morse

Deliverables

• Research Morse: Study & understand how RTTM works in Morse
• Governance: Add the RTTM governance parameter
• Implement: Implement RTTM in Shannon
• Integrate: Make sure the RTTM values are probability capture in the Sparse Merkle Trie
• CLI: Update the poktrolld (if necessary) to support updating the RTTM governance parameter
• Test: Add unit, integration and E2E tests
• Tooling: Add Makefile targets to easily trigger (on LocalNet) and test (e2e) modifying / updating / testing different RTTM values
• Document: Add a new page to dev.poktroll.com explaining how RTTM works and how to use it
• Comments: Add/update TODOs and comments alongside the source code so it is easier to follow.

Non-goals / Non-deliverables

• Expanding beyond what Morse has for RTTM (except integration into the SMT)

Estimated Days of Work

2 days

Disclaimer: This is the total projected number of estimated hours to completion & merge. The owner of this tickets is expected to use this GitHub issue to communicate with the core protocol team along the way, with update & feedback for each deliverable throughout the duration of this work._

---

Creator: @Olshansk
Co-Owners: @moatus

[rBurgett]

@Olshansk I'd be happy to take this.

[Olshansk]

@rBurgett Sounds great!

Few questions / suggestions (some redundancy from our offline conversations but posting here for posterity)

1. Q1: When do you think you'll be able to start?
2. S1: Please start with a draft PR and cc the team (@bryanchriswhite, @Olshansk, @red-0ne) before diving too deep into the implementation, tests, docs, etc...
3. S2: Make sure to look into ignite to see if there is any scaffolding opportunity (less work, standards, etc...)

CCing @moatus for visibility.

[rBurgett]

I'll start tomorrow and work on it as I can around my current, full work schedule. I'll have a draft PR up by Monday.

[Olshansk]

[Olshansk]

@rBurgett I found this thread in the cosmos docs: error while using map in txs w/ the tl;dr is that you can use maps in txs.

[Olshansk]

Also, I noticed that we're "re-inventing the wheel" on how params are updated. I did so by surching for "update-params"

[Olshansk]

I decided to dive deeper into the whole thing and have an alternative suggestion. CCing @bryanchriswhite and @moatus for context too.

1. We keep the default ComputeUnitToToken multiple as is.
2. We update the Service protobuf to have a compute_units_to_token_multiplier

message Service {
  // For example, what if we want to request a session for a certain service but with some additional configs that identify it?
  string id = 1; // Unique identifier for the service

  // TODO_TECHDEBT: Name is currently unused but acts as a reminder that an optional onchain representation of the service is necessary
  string name = 2; // (Optional) Semantic human readable name for the service
  
+  uint64 compute_units_to_token_multiplier = 3;
}

3. The owner of the Service (i.e. the Source owner) is the only one who can update the multiplier on their source.
4. The default for it is based on (1)
5. During session settlement, we query the service and leverage it there
6. We won't need a global RTTM map (simplifying things)

[rBurgett]

@Olshansk that is an interesting alternative. Using a global RTTM map and serializing it as a string isn't complicated, imo, but I'll defer to your suggestion. Now, regarding number four where you say that the default should be the compute_units_to_tokens_multiplier, do you mean that 1) when a service is created we should set that as the service's compute_units_to_tokens_multiplier value? Or, 2) that should we treat the cuttm as an optional service param and fallback to the default during session settlement if a service-specific cuttm is not set?

[Olshansk]

tl;dr Let's do the following:

• Keep the global param variable compute_units_to_tokens_multipler (this will have a default value in genesis)
• Each Service have it's own compute_units_per_relay that can only be set the service owner/creator (this will need a default value upon service creation)
• Scratch the original map approach; we have found something easier

---

This is a result per an offline discussion with @moatus @RawthiL and @studna.

[rBurgett]

Sounds like a plan.

[red-0ne]

Closing as per #552 and #706.