Introducing Bluwhale
  • Introducing Bluwhale
  • Architecture
    • Overview
    • ERC-7231
    • Data Authentication
    • Bluwhale Link
    • Data Provider
    • Third-party Verification
    • On-chain Attestation
    • Trusted Execution Environment Cluster
    • About Trusted Execution Environments
    • Zero-Knowledge Proof
  • Verifier Nodes
    • Verifier Node Sale
    • Purpose of Verifier Nodes
    • Verifier Node Operations & App
    • Node Rewards & Projections
    • Node Licenses
    • Node Delegration
    • Node FAQs
  • Tokenomics
    • Utility
    • Distribution/Vesting
    • Staking
  • Bluwhale Community
    • Community Activations
    • Social & Community Links
    • Distributor & Referral Programs
    • Media Coverage
  • Resources
  • General FAQs
  • Brand Guidelines
  • Media Kit
  • Contact Us
  • Personalization Protocol
    • Overview
    • Architecture
      • Overview
      • Identity Layer
      • Data Storage Layer
      • Computation & Training Layer
      • Execution Layer
      • Verification Layer
  • How to Purchase Nodes
    • How to Purchase Nodes on Solana
  • Buyback Program
  • Why Verifier Nodes
  • How do Verifier Nodes Work
  • Bluwhale NFT License
  • Bluwhale Protocol Service
  • Trusted Execution Environment (TEE)
  • Verifier Node
  • Attestation
  • Delegation
  • SGX Attestation Verification
  • Verifier Node Sale Dynamics
  • Smart Contract Addresses
  • License Key (NFT)
  • Delegation
  • Node Rewards
  • Join Alphanet Verifier Nodes
  • Prerequisites
  • Delegation Tutorial
  • Operating a Verifier Node
  • Running in VPS
  • Running in CLI
  • Running in Desktop App
  • Explorer
Powered by GitBook
On this page

Verifier Node

  • Any address holding a Bluwhale NFT License, or delegated by an address holding a Bluwhale NFT License, can become a verifier node.

  • Each node has a delegation weight (initially set to 100, with an upper limit adjustable by the admin). The delegation weight represents the number of delegations to that node.

  • Before a verifier node can publish a verification, it must notify the service contract to go online. The first time each verifier node goes online, it is registered with a uint16 nodeID, with the system capable of registering up to 65,535 nodes.

  • After each attestation is published, Chainlink VRF will select the verification nodes for that round from the currently online nodes. The nodeID list of selected verification nodes will be stored in the service contract. When a verifier submits a verification, the contract will check if it is on the current round's verification node list.

  • To efficiently select a random verification node list from the online nodes, the service contract maintains an active node list (activeVrfNodeList) with a maximum length of 2,000. When the list is full, a new node must replace an existing node with a lower delegation weight.

  • Nodes that are online for at least 6 hours daily are eligible for rewards (refer to the rewards rules section for details). Delegators to these nodes can also receive rewards.

  • If a node fails to submit a verification, anyone can initiate a slashing against it (the slasher will receive a reward). If a node misses too many verifications, it will be forced offline.

  • When submitting verifications, a verifier node can delegate the submission to the Bluwhale backend (this process is gasless, requiring only an EIP-712 signature from the verifier). The Bluwhale backend aggregates multiple verifications and submits them in batches, significantly reducing the system's overall cost.

Gasless mode is optional. You can always submit the tx to the smart contract directly.

  • The commission rate is adjustable by the node operator, with a minimum adjustment period (tentatively set to one week).

  • Nodes can specify an address to receive their rewards.

PreviousTrusted Execution Environment (TEE)NextAttestation

Last updated 10 months ago