spike (tweets): how do we facilitate organic tweets on SN42

[Luka-Loncar]

Problem summary:

• We need to think how the organic request will work from an architecture perspective to make sure there is a cohesive solution.
• We need to move away from synthetic requests as this is part of our success and increasing emissions.
• Defining the architecture of organic tweets.
• From there the mechanisms of selection and scoring.

Acceptance criteria:

• Session to collaborate and review solutions with Brendan, Mati, Chris. Spike out of this session.
• Add to board data that is available to help out Chris.
• a set of tickets rolled up into an EPIC that defines the roadmap on which we execute this as a v2.0.0 release of SN42
• Architecture diagram here: https://miro.com/app/board/uXjVL8mpQWw=/

[Luka-Loncar]

We go to this spike when we finish validation of returned data.

[grantdfoster]

We are encouraging validators to NOT run their API as this is the default setting. Need more clarity on what an organic request looks like before it makes sense to include it in scoring.

[teslashibe]

Think this is probably ~1-2d of work this

[teslashibe]

Closes https://github.com/orgs/masa-finance/projects/7/views/1?pane=issue&itemId=89411153&issue=masa-finance%7Cmasa-bittensor%7C316 which was a duplicate ticket

[grantdfoster]

@5u6r054 and I discussed organic requests and here is a summary of our conversation:

1. Unified Queue System

While miners currently cannot distinguish between an organic or synthetic request (they use the same synapse), we can improve upon how requests are made to the subnet in the first place, favoring a centralized queue over each validator having to expose and market their own API. Takeaways:

• All incoming API requests (organic) are placed in a global queue.
• Both organic and synthetic requests (if applicable) are processed from this unified queue, ensuring load is spread across validators and miners, and network bandwidth is maximized.

2. Always-Running Queue Consumer

• A continuous consumer process on the validator pulls requests from the queue
• These requests could be randomly assigned to a single miner for fulfillment
• These requests could be made to the top scoring miners (based on latency + request fulfillment)

3. Periodic Scoring Rounds

• Scoring occurs at a fixed cadence (e.g., every nth tempo).
• During scoring rounds, requests are pulled from the same queue and sent to multiple miners for comparison.
• Consider weighting requests with larger volume as those tasks are more difficult to complete

4. Scoring Criteria

• Request Fulfillment: Miners are scored based on conformity to the requested number of tweets.
• Tweet Uniqueness: Checks for unique tweet IDs among the returned results.
• Spot Check: Validators verify the accuracy of returned tweets.
• Miners who pass the above criteria are ranked based on response time.
• Average response time is calculated, and individual miners are scored relative to this average.

5. Variability in Requests

• To handle variability in tweet count requests, scoring rewards miners who return the requested number
• Perhaps establish a weight to requests with larger volume as those are more difficult to fulfill
• Guard against there being less tweets than requested, potentially using the average count returned as a benchmark
• Larger requests may reduce miners' ability to handle other tasks, creating a balanced challenge

6. Bandwidth Consideration

• Continuous requests are limited to a single miner to conserve bandwidth
• Scoring requests are designed to periodically evaluate performance while minimizing overhead

7. Transparency and Miner Incentives

• Miners cannot distinguish between scored and non-scored requests, ensuring fairness.
• Consistent performance across organic requests ensures better scores and encourages reliable participation.

8. Protocol Dependency

• Requiring miners to stake tokens (e.g., Masa) ensures alignment with the subnet's protocol and incentivizes participation.

[grantdfoster]

Based on the above conversation and the Miro board architecture diagram, I propose to cut the following tickets. Let's come to consensus on the scope first, and then can define granular acceptance criteria in each ticket.

• spike: score on request fulfillment and latency
• spike: miner selection, random or best scored
• feat: implement central queue system
• feat: remove synthetic request engine
• feat: integrate scoring into random rounds
• fix: miner selection count in config from 3 to 1