Open Olshansk opened 2 months ago
@Olshansk I'd be happy to take this.
@rBurgett Sounds great!
Few questions / suggestions (some redundancy from our offline conversations but posting here for posterity)
ignite
to see if there is any scaffolding opportunity (less work, standards, etc...)CCing @moatus for visibility.
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.
@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.
Also, I noticed that we're "re-inventing the wheel" on how params are updated. I did so by surching for "update-params"
I decided to dive deeper into the whole thing and have an alternative suggestion. CCing @bryanchriswhite and @moatus for context too.
ComputeUnitToToken
multiple as is.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;
}
@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?
tl;dr Let's do the following:
compute_units_to_tokens_multipler
(this will have a default value in genesis)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)This is a result per an offline discussion with @moatus @RawthiL and @studna.
Sounds like a plan.
Objective
Feature parity with RTTM from Morse.
Origin Document
437
Goals
Deliverables
poktrolld
(if necessary) to support updating the RTTM governance parameterMakefile
targets to easily trigger (on LocalNet) and test (e2e) modifying / updating / testing different RTTM valuesNon-goals / Non-deliverables
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