[Utility] B1: QoS - Single Check

[Olshansk]

Objective

Implement MVP E2E Feature Path A1: E2E Relay- Trustless Relay

Origin Document

Purpose: A Fisherman makes periodic relays to all Servicers during an active session, tracks the QoS of each request, and maintains the results in a local ephemeral state.

Actors: Check all of the protocol actors involved in the feature

• [ ] Validator
• [ ] Application
• [x] Servicer
• [x] Fisherman
• [ ] Portal

Data Structures

• MVP requirements for QoS need to be defined. Example:
  • RoundTripTime (i.e. latency)
  • Availability (i.e. responsive)
• shared/core/types/proto/qos.proto needs to be created w/ data types to track QoS
• runtime/genesis/proto/genesis.proto needs to be updated to govern how QoS checks are made based on the sampling protocol. Example:
  • QoS check frequency per session
  • QoS check distribution per session

Interfaces

• shared/modules/utility_module.go will need to be updated with Fisherman specific interface logic for executing and storing a QoS check
• app/client/cli/ may need to be updated if new endpoints are needed to be exposed to the client for the implementation of this feature

Diagram

sequenceDiagram
    actor F as Fisherman
    actor S1 as Servicer 1
    actor SN as Servicer N

		title E2E Single QoS Check

    loop Repeats During Session
        F ->> +S1: Relay Request
        F ->> +SN: Relay Request (identical)
        S1 ->> -F: Relay Response 1
				F ->> F: Record & Store<br>QoS for S1
        SN ->> -F: Relay Response N
				F ->> F: Record & Store<br>QoS for SN
    end

User Stories as Tests

• Happy test cases
  • A fisherman makes a successful request to a servicer that is available
  • A fisherman makes a successful request to a servicer that has low latency
• Sad test cases
  • A fisherman makes successful request to a servicer that is unavailable
  • A fisherman makes successful request to a servicer that has high latency

Blockers

• E2E feature path dependencies:
  • A.1: Trustless Relay
  • E: All actors must be staked
• Open Questions:
  • How is a Fisherman notified that a session started?

Goals

• Complete the MVP implementation of the E2E Feature Path outlined in the objective
• Identify future tasks and test requirements to transition the feature to production

Deliverable

• POC:
  • [ ] A POC SPIKE to be closed out and split out into multiple PRs
• MVP:
  • [ ] A PR that adds or modifies relevant structures and interfaces; such as shared/core/types/proto, shared/modules, etc
  • [ ] A PR that materializes an MVP of the feature along with unit tests
  • [ ] A PR that introduces a new E2E tests with one happy and one sad path scenarios as described in the origin document (refer to e2e/README.md); this may require additions to the cli
  • [ ] A PR that updates all pertinent documentation
• PROD:
  • [ ] One or more subsequent GitHub issues that track future work including, but not limited to:
    • Enhancing test coverage
    • Adding subsequent features
    • Patching hacks or workarounds
    • Enabling your imagination!

General issue deliverables

• [ ] Update the appropriate CHANGELOG(s)
• [ ] Update any relevant local/global README(s)
• [ ] Update relevant source code tree explanations
• [ ] Add or update any relevant or supporting mermaid diagrams

Testing Methodology

• [ ] Task specific tests or benchmarks: make ...
• [ ] New tests or benchmarks: make ...
• [ ] All tests: make test_all
• [ ] LocalNet: verify a LocalNet is still functioning correctly by following the instructions at docs/development/README.md
• [ ] k8s LocalNet: verify a k8s LocalNet is still functioning correctly by following the instructions here

---

Creator: @Olshansk