spike: Distributed work framework

[teslashibe]

Problem

Currently all nodes will service a request, but the first person to respond wins in the current LLM limitation.

Questions

• [ ] How many works need to service a request
• [ ] Is there a timeout?
• [ ] When each trigger is reached we then consolidate the request into one response object
• [ ] k-nearest neighbors to select those to service request
• [ ] Is a list maintained by validators, do they in the long term assign work? Good to be in a pool today
• [ ] Routing of data to inform the way we improve here
• [ ] Can we extend this to Twitter and to Web Scraper
• [ ] Data store - this would be governed by validators
• [ ] Can we use this to help scale our Twitter capacity? And apply this to any actor and the work they are doing?

Solution

[Luka-Loncar]

@restevens402 to modify this issue so it covers the rest of the requirements.

[mudler]

Let's first have a spike on this so we can collect our thoughts on a possible solution before jumping into implementation.

the outcome of the spike should be new cards to track that, and have implementation details

[mudler]

It would make sense to need first in place a ledger/consensus state where information about the work and the worker can be annotated, implementation for this is kinda blocked IMHO.

To select a worker we might just check the resources that the request wants and if the worker can satisfy that with its capabilities (e.g. a worker might want to share an LLM service, but maybe not a scraper) - and keep apply a first-come-first-serve approach, especially in the first iteration, but in a synchronized manner.

A simple, first pass implementation that comes to my mind is (without validators):

• A user that needs a service (e.g. Twitter scraping) annotates to the ledger that it is requesting a twitter service.
• The first node that with consensus manages to write itself as provider of that service, fulfills the user request and updates the chain with the status

Implications:

• There is a shared ledger
• The access to the ledger is provided via consensus protocols

A v1 then could potentially include:

• A validator actor that annotates the requests to assign rewards in a reserved chain, which requires a list of trusted nodes that are able to write inside of it (other validators will accept new blocks only signed by validators)
• Every reward/utility have to be calculated by all validators and reach verifiable majority consensus by validators (by exchanging signed messages which can be verified)
• A way to challenge workers/user to verify the validity of the requests (and avoid malicious actors to generate fake rewards)
• Better optimizations of fulfilling requests (which worker should be used? are there better heuristics to explore?)
• A validator that, in scope with bittensor "syncronizes" subnet rewards that are validated by majority consensus by validators

Open points that needs to be solved:

• How to make sure that who is syncronizing rewards can't be a malicious actor? ideally we want to achieve majority consensus here too in a way that blocks malicious validators

[jdutchak]

completed in ticket #314