[Utility] A1: E2E Relay - Trustless Relay

[Olshansk]

Objective

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

Origin Document

Purpose: A staked Application can make a direct relay and receive a response from a staked Servicer, selected by the Session, based on the GeoZone and ChainID.

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

• Validator
• Application
• Servicer
• Fisherman
• Portal

Data Structures

• shared/core/types/proto/relay.proto - will need to be updated to reflect the V1 design. For example:
  • AATs are no longer needed since the signature will define the validation
• utility/service/service.go will need to be updated to reflect V1-specific logic in servicing a request per the README

Interfaces

• app/client/cli/ will need to be updated to reflect the changes made to relay.proto
• shared/modules/utility_module.go may need to be updated with Servicer specific logic for handling a relay

Diagram

sequenceDiagram
    actor A as Application
    actor FN as Full/Dispatch Node
    actor S as Servicer
    actor D as Data Node

		title E2E Trustless Relay

    loop Repeats During Session
				A ->> +FN: GetSessionData
				FN ->> -A: SessionData
        A ->> +S: Relay Request
				S ->> S: Validate Relay
				S ->> +D: RPC Request
				D ->> -S: RPC Response
				S ->> S: Store signed RPC (Request, Response) 
				S ->>-A: Relay Response
    end

Loading

User Stories as Tests

• Happy test cases
  • An Application requests the account balance of a specific address at a specific height from a Servicer staked for the Ethereum RelayChain in the same GeoZone, and receives a successful response.
• Sad test cases
  • An Application requests the account balance of a specific address at a specific height from a Servicer staked for the Ethereum RelayChain in the same GeoZone, and the request times out without a response.

Blockers

• E2E feature path dependencies:
  • E.1: Actor Staking
• Infrastructure dependencies
  • Running an Ethereum data node

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