Rivalz Network
  • Introducing Rivalz
  • ROME - Swarm Protocol
    • rAgent Creation
    • What is a PAG?
    • ROME Rewards
      • ROME Season 1 - 25,000,000 $RIZ in rewards
    • Swarms and Swarm Staking
    • Lending Market
    • User Guide - ROME Dashboard
      • PAG
      • Reputation & Rewards
      • Swarm Project Creation
      • Swarm Staking
      • Borrow Market
      • Lending Guide
  • rClients (ROME 🏛️)
    • rClient CLI Guide
  • OCY - DATA
  • ADCS - CONNECTIVITY
    • Overview
    • Core components
    • Create an Adapter
    • Create your consumer smart contract
    • How to automate your contract execution with Gelato
    • How to Become a Provider
    • Developer
  • NOSTRINGS - IDENTITY
  • VORD - APPLICATION
    • VORD
    • Sidelined
    • AI-Powered Telegram Bots (Coming Soon)
  • Rivalz Alliance & Ecosystem
  • Intel Incentivized Testnet
  • zNode (Validators)
    • zNode Utility
    • Running a zNode
    • Delegating a zNode
      • Rivalz zNode - NodeOps Delegation
    • zNode Burn Event (Ended)
  • RIZ Token
    • RIZ Overview & Contracts
    • Airdrop and Eligibility Requirements
      • Airdrop User Guide
      • Claim Page Guide
    • zNode RIZ Drop
    • $RIZ Tokenomics
    • $RIZ Staking User Guide
    • $wRIZ Staking User Guide
    • Stake to Aerodrome Liquidity Pool
    • Wrapping and Unwrapping $wRIZ User Guide
  • Roadmap
  • Official Links
Powered by GitBook
On this page
  • Key Features of Fetcher Nodes
  • 1. Fetcher Intelligent Data Retrieval
  • 2. Data Adapter - Standardized Data Interaction
  • 3. Aggregator Component - Data Aggregation and Consensus
  • Raft Consensus Mechanism
  • 1. Leader Election:
  • 2. Log Entry Creation:
  • 3. Log Replication:
  • 4. Commitment of the Log Entry:
  1. ADCS - CONNECTIVITY
  2. Design Components
  3. Off-chain Components
  4. ADCS Nodes

Fetcher Nodes

Last updated 6 months ago

Fetcher Nodes are essential components of the Agentic Data Coordination Service (ADCS), designed to intelligently retrieve, process, and aggregate data from diverse external sources. By leveraging a structured data adapter framework, Fetcher Nodes ensures that requestors have access to standardized and high-quality data structures. These nodes serve as pivotal data provision points for oracles within the ADCS system, guaranteeing the supply of reliable information necessary for efficiently fulfilling consumer requests.

Key Features of Fetcher Nodes

1. Fetcher Intelligent Data Retrieval

The Fetcher is responsible for intelligently fetching data from designated sources based on predefined configurations. It ensures efficient and accurate data retrieval by adhering to the specifications set within the data adapter, optimizing the process for both speed and reliability.

2. Data Adapter - Standardized Data Interaction

The Data Adapter framework ensures compatibility and standardization across various data sources. Each adapter is identified by a unique adapter hash, which guarantees that the data retrieved by the Fetcher is correctly structured and compatible for aggregation. This standardization is critical for maintaining data integrity throughout the ADCS ecosystem.

3. Aggregator Component - Data Aggregation and Consensus

The Aggregator consolidates data retrieved from multiple Fetchers, providing the final aggregated data. Each Fetcher Node maintains both a local aggregate and a global aggregate. The Aggregator processes data using methods such as median or majority voting to ensure accuracy and relevance. The Raft consensus mechanism is employed to achieve agreement among all nodes on the global aggregate, maintaining consistency and reliability across the network.

Raft Consensus Mechanism

To ensure that all nodes in the network agree on the global aggregate data, ADCS utilizes the Raft consensus mechanism. This process involves several critical steps:

1. Leader Election:

A leader node is elected among the Fetcher Nodes. The leader manages the log replication process and ensures synchronization across all follower nodes.

2. Log Entry Creation:

The leader proposes the global aggregate data by creating a new log entry containing the aggregated data. This log entry is then sent to all follower nodes for replication.

3. Log Replication:

Each follower node receives the proposed log entry from the leader and appends it to its own log. Followers send acknowledgments back to the leader to confirm receipt and storage of the log entry.

4. Commitment of the Log Entry:

Once the leader receives acknowledgments from a majority of the nodes, it considers the log entry committed. The leader updates the state machine and finalizes the global aggregate, ensuring that all nodes reflect the agreed-upon data.

Data Aggregation
Raft Consensus