Powered by

# Gateway Discovery

# Discovery and Efficient Gateway Selection

In decentralized architectures like KnowledgeCache, it is inefficient for a DoD agent to blindly contact random Gateways, especially without knowing which ones are suitable for a given task. However, established decentralized discovery mechanisms can address this without requiring knowledge of each Gateway's cache contents.

# Discovery Mechanism Overview

While not explicitly described in the documentation, the system implies a discovery model based on the Peaq Protocol:

  1. Service Discovery via Peaq Protocol:
    Gateways register their presence and capabilities (e.g., location, load, specialization) in a decentralized service registry. DoD agents query this registry to discover available Gateways.

  2. Capability-based Selection:
    After retrieving available Gateway metadata, the DoD agent selects the most appropriate node using:

    • Geographic Proximity to minimize latency.
    • Load and Availability, choosing underutilized nodes.
    • Reputation or Staking, favoring trusted Gateways.
    • Domain Specialization, optionally preferring nodes tuned for specific topics.

  3. Routing Logic Inside Gateway:
    Once a Gateway is selected, the DoD agent sends the request. The Gateway:

    • First checks its off-chain Gateway KV-cache.
    • If no match, uses semantic and vector indexes to locate facts in the on-chain KCG (Arweave).
    • Applies contextual reasoning to construct a prompt using the retrieved knowledge.
    • Optionally falls back to a Big LLM if necessary.

  4. Distillation and Write-back:
    If new insights are distilled, the DoD agent sends back the result to the Gateway for validation and permanent write to the on-chain KCG.

# Caching Strategy and Priority Layers

Gateways are designed to optimize speed and cost:

  • On-device Tiny LLM KV-cache: ~20 ms latency.
  • Gateway shared KV-cache: 50–200 ms.
  • Public KCG access (Arweave): 300–1000 ms (direct), faster via index.
  • Big LLM fallback: 800–2000 ms.

This hierarchy ensures:

  • Most lookups are handled locally or via Gateway caches.
  • Gateway caches are dynamically updated using usage analytics (e.g., repeated misses, request spikes).
  • High-demand knowledge is promoted to “hot” or “warm” tiers for optimal reuse.

# Accelerated KCG Access via Gateway Indexes

Gateways avoid querying Arweave directly for each lookup. Instead, they:

  • Maintain off-chain semantic graphs and vector indexes pointing into the KCG.
  • Leverage these for sub-second retrieval from large knowledge graphs.
  • Operate a Federated Knowledge Mesh, replicating indices across multiple nodes to enhance locality and fault-tolerance.
  • Use multi-layered hybrid caching: on-device, Gateway-level, and public (KCG).

This design provides a scalable and low-latency infrastructure for real-time, on-demand knowledge reasoning in a fully decentralized setting.