2PM.Network
WebsiteXDiscordLinkedinGithub
  • Overview
    • What is 2PM.Network
    • Architecture
    • FAQ
    • Official Social Channels
  • 2PM Data VSIES Service
    • What is Data VSIES and why is it important
    • [V] Data Validation (ZK)
    • [SI] Data Standardization and Index
    • [E] Data Encryption Client (FHE)
    • [S] Data Storage and Access
    • Data VSIES SDK
  • Node Framework
    • Modular Architecture
    • Federated Learning
      • Horizontal Federated Learning Task
      • Logistic Regression Task
      • On-chain Secure Aggregation
      • Typical Scenarios
    • FHE Machine Learning
      • Built-in Models
      • Deep Learning
      • Typical Scenarios
    • Task Submission
    • Running a 2PM Node
      • Installation
      • Chain Connector Configuration
      • Data Preparation
      • Joining a Subnet
  • Security and Verification
    • Node Staking and Slash Mechanism
    • Running Verification Client
      • EigenLayer
      • Mind Network
    • Restaking and Delegation
  • Model Inference
    • 2PM Node Inference API
    • Posting Request to a Subnet Model
    • Getting Inference Results on Chain
      • Oracle Adapters
  • Monetization and Incentives
    • AI Model IP Assets
    • Distribution Algorithm
  • 2PM DAO
    • Build Subnets
      • Establishing New Subnets
      • General Requirements
      • Data Schema Definition
      • Model Selection
      • Task Implementation
    • $DMP Token
  • Deployed Smart Contracts
    • Subnets on Testnets
    • Local Deployment Guideline
  • Ecosystem
    • Partners
    • Use Cases
      • Private Personalized Recommendation
Powered by GitBook
On this page
  1. Model Inference

Getting Inference Results on Chain

PreviousPosting Request to a Subnet ModelNextOracle Adapters

Last updated 10 months ago

Typically, node operators are required to be deployed for oracle adapters. After the adapters are launched locally or on the node, users need to find the corresponding contract address for their subnet.

The following is the workflow of Chainlink Function:

  1. User initiates the Chainlink Function embedded in the dApp: This is the starting point of the process, where the user triggers the Chainlink Function by interacting with the decentralized application (dApp).

  2. The dApp sends a request to the Chainlink Functions smart contract: This request contains three key elements:

    • API endpoint: Specifies the external source from which to fetch data

    • Data transformation logic: Defines how to process the retrieved data

    • Encrypted credentials (if required): Used for secure access to APIs that require authentication

  3. The Decentralized Oracle Network (DON) processes the request:

    • The DON continuously monitors the Chainlink Functions smart contract

    • When a request is detected, each node independently performs the following operations: a. Triggers its runtime environment. b. Retrieves external data c. Executes specified data computations d. Returns the result

  4. Reaching consensus and returning results using OCR 2.0:

    • Nodes reach consensus on the final answer using the Off-Chain Reporting (OCR) 2.0 protocol

    • One node is selected to transmit the result back on-chain

    • If the selected node fails to publish the data, another node is chosen for transmission

    • This mechanism ensures high reliability and trust-minimized security

Chainlink Function Workflow