Bound All Work Triggered by a Single Token Selection Request [HIGH]

[HayimShaul]

Description
Conduct an architectural review of every code path reachable from a Selector.Select call -- token iteration depth, number of lock attempts, retry and back-off cycles, and lock-store growth -- and impose hard, configurable upper bounds on each dimension. Any request that would exceed these limits must be aborted early and all acquired locks released immediately. This is the primary defence against algorithmic attacks: no matter how a request is crafted (adversarial OwnerFilter, extreme quantity, or high concurrency), the system must shed load and return an error rather than consuming unbounded memory, CPU, storage, or wall-clock time.

Short Summary
An attacker can create a transaction that selects a large amount of tokens from database. This can exhaust the CPU and memory of the view service.

[SurbhiAgarwal1]

Hi @HayimShaul , @adecaro , I’d like to propose a structured approach to bound all work triggered by a Selector.Select request and prevent unbounded resource consumption.

---

1. Introduce a Selection Budget (Core Idea)

Define a per-request SelectionBudget that tracks and enforces limits across all dimensions:

• maxTokensScanned
• maxLockAttempts
• maxRetries
• maxDuration (wall-clock timeout)
• maxLocksHeld

This budget is initialized at the start of Selector.Select and passed through all downstream calls.

type SelectionBudget struct {
    MaxTokensScanned int
    MaxLockAttempts  int
    MaxRetries       int
    MaxLocksHeld     int
    Deadline         time.Time
}
Can you assign me this issue ?