Giters

webb-tools / tangle

Modular restaking infrastructure for developers, restakers, and operators.

Home Page:https://www.tangle.tools/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[CHECKLIST] Roles / Jobs v2

drewstone opened this issue · comments

commented

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

  • [ ] [SPEC] Design generalized role registration & abstractions
  • #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?)
    • Job types specified (DKG, TSS, Refresh, Rotation)?
    • Where is the role software located (Github, AWS, Bitbucket, IPFS, URL)?
    • Who controls updating the metadata?
    • What metadata can be appended to, updated, not updated, not deleted?
  • Job registration
    • Likely apart of the role registration.
    • What does job type metadata look like in generalized system?
  • Generalization
    • Roles have job types and job types imply programs
    • Job types should also specify slashing conditions somehow (EVM, Ink!, Pallet, zkVM, cross-chain message)
    • Job types should specify verification conditions somehow (EVM, Ink!, Pallet, zkVM, cross-chain message)

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.

  • 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

  1. Token curated service registry (people stake tokens on services and top X% earn rewards proportional to their stake).
  2. 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.