The current roles/jobs systems are tightly integrated. We have onchain types / enums that are ever-growing to match JobTypes, RoleTypes, and anything in between. This will be sufficient for an initial release though this isn't scalable, and we should augment the design with more capabilities. I see this living complementary to the existing role system.
This document lists out a variety of specs that should be completed and described to team for people's buy-in. Then we can task it out.
Specs
~[ ] [SPEC] Design generalized role registration & abstractions~
[x] #612
[ ] [SPEC] Design subscription jobs, on-demand jobs, and other extensions.
[ ] [SPEC] Restaking w/ any asset
[ ] [SPEC] Update tokenomics with subscription/on-demand jobs.
[ ] [SPEC] Update tokenomics with generalized role system.
[ ] [SPEC] Allow restakers to impose restrictions on service requests
[ ] [TASK] Services should be able to specify how often gadgets are expected to publish some outputs
Generalized role / job registration & abstractions
These 2 specs are quite related, since job types are tied closely to the role. We have multiple job types for a given role such as DKG or TSS, phases, etc. This spec(s) should deal with
Role registration
Is there a bond?
Are there phases of registration (audited?, proposed?, accepted?, endorsed?, licensed?)
We want to integrate service roles that might just be running another network's node infrastructure. Some examples of this are IPFS nodes for pinning service, distributed validators for building blocks on other networks, etc. Some questions arise from these types of services. What besides running the infra is the job? What is the job result? If there's output for these tasks, say distributed validators building blocks, do we benefit from submitting those blocks as job results? What do we do when there's no output, say for IPFS pinning.. is there an alternative job result to submit repeatedly? Lots of questions, need more answers for a design. Some things come to mind, namely that these jobs follow subscription like formats rather than on-demand structures.
Subscription jobs
Specify length of service
Specify frequency of service
On-demand jobs
Similar to what we have
Incentives / tokenomics
We either figure out a way to make everything a job result from either job types or weight subscription jobs in a manner that normalizes them with on-demand completions.
This is related to how we reward operators for the # of jobs they complete, i.e. if a subscription has no submittable job results then how do we reward it?
Generalized role tokenomics
As we generalize roles, we must also figure out a way to tie this into the tokenomics. If anyone can create a role, we can't arbitrarily reward these, since that can be easily manipulated. Some potential ideas
Token curated service registry (people stake tokens on services and top X% earn rewards proportional to their stake).
A whilelist by democracy vote (root level call to add a service to the reward set)
Restaking updates + with arbitrary assets
As we open bridges to other chains, we should also open up the ability to restake w/ arbitrary assets. These assets would could be de-facto nominators of a service's operators, would surely partake in restaking rewards and slashing conditions. There are a few questions that arise:
How do we factor this into the incentive system?
How should the assets be restaked, i.e. through what mechanism? Delegated to active services/operators of that service?
How much of them gets slashed and where do those funds go?
Can we give additional incentives for restaking assets? Separate these incentives from one another, i.e. X% to USDC restakers, DOT restakers, etc.
Allow restaking with preferences, i.e. I should be able to restake on any service that NODE_OPERATOR starts.
Service request restrictions
Right now, we allow anyone to request services from any restaker with the role. We should augment the functionality so that if a restaker has restrictions in place, that service requesters must submit a pending request for service to the restaker, who must accept the request in order for it to begin. This is a way to keep the system from being spammed by arbitrary service requests.
Overview
The current roles/jobs systems are tightly integrated. We have onchain types / enums that are ever-growing to match JobTypes, RoleTypes, and anything in between. This will be sufficient for an initial release though this isn't scalable, and we should augment the design with more capabilities. I see this living complementary to the existing role system.
This document lists out a variety of specs that should be completed and described to team for people's buy-in. Then we can task it out.
Specs
Generalized role / job registration & abstractions
These 2 specs are quite related, since job types are tied closely to the role. We have multiple job types for a given role such as DKG or TSS, phases, etc. This spec(s) should deal with
Subscription vs on-demand jobs
We want to integrate service roles that might just be running another network's node infrastructure. Some examples of this are IPFS nodes for pinning service, distributed validators for building blocks on other networks, etc. Some questions arise from these types of services. What besides running the infra is the job? What is the job result? If there's output for these tasks, say distributed validators building blocks, do we benefit from submitting those blocks as job results? What do we do when there's no output, say for IPFS pinning.. is there an alternative job result to submit repeatedly? Lots of questions, need more answers for a design. Some things come to mind, namely that these jobs follow subscription like formats rather than on-demand structures.
Generalized role tokenomics
As we generalize roles, we must also figure out a way to tie this into the tokenomics. If anyone can create a role, we can't arbitrarily reward these, since that can be easily manipulated. Some potential ideas
Restaking updates + with arbitrary assets
As we open bridges to other chains, we should also open up the ability to restake w/ arbitrary assets. These assets would could be de-facto nominators of a service's operators, would surely partake in restaking rewards and slashing conditions. There are a few questions that arise:
NODE_OPERATOR
starts.Service request restrictions
Right now, we allow anyone to request services from any restaker with the role. We should augment the functionality so that if a restaker has restrictions in place, that service requesters must submit a pending request for service to the restaker, who must accept the request in order for it to begin. This is a way to keep the system from being spammed by arbitrary service requests.