Inferix Decentralized GPU
  • Getting Started
    • Overview
    • $IFX
    • Resources
    • Brand Kit
    • Frequently asked questions (FAQs)
  • Inferix Whitepaper
    • Introduction
      • Rendering network using crowdsourced GPU
      • Rendering verification problem
    • High-level description of ANGV
      • Noise generation
      • Noise verification
      • Thread model
    • Implementation of ANGV
      • Structure of noise
      • Noise insertion
        • Geometric constraints
        • Distortion region
      • Adaptive noise spreading
      • Verification key generation
      • Noise verification
      • Threat analysis
        • Attacks on verification keys
        • Attacks on noises
        • Attacks on verifiers
      • Performance evaluation
      • Integration
    • Decentralized visual computing
      • Client Apps plugin
      • Client API and SDK
      • Manager node
      • Worker node
      • Decentralized storage
        • Data categories
        • Multi-level 3D polygon data
        • Polygon digester
        • Decentralized storage
        • Decentralized cache
      • Data security with FHE and TEE
        • Verifier data security enhancement with FHE
        • Worker and Manager data security enhancement with FHE
    • Decentralized federated AI
      • Federated learning with TensorOpera
      • Meta LLaMA
      • Stable Diffusion
      • Other AI models
      • Inferix AI
    • Economic model
      • GPU compute market for visual computing and federated AI
      • Inferix vision
      • $IFX token
      • Burn-Mint-Work token issuance model
      • Inferix bench and IBME
        • IB and IBM
        • IBME
      • Price simulation
      • Token metrics and allocation
        • Token allocation
        • Token vesting
      • Governance
      • Node staking and rewards
        • Worker
        • Verifier
        • Manager
        • Penalty pool
      • Node sale and guaranteed node buyback
        • Node sales
        • Guaranteed Node Buyback
    • Future development
      • PoR and NFT minting for graphics creative assets
      • ZKP and PoR communication
      • Inferix RemotePC
      • Rendering professional network
    • References
    • Appendix A: Proofs
    • Appendix B: Price simulation details
    • Appendix C: Hardware requirements for nodes
    • Appendix D: Performance evaluation data
  • Worker Node Guide
    • What is Worker Node
      • How do the Worker Node work
      • Worker Node Rewards
      • How to run Worker Node
      • What is the Worker Node License (NFT)
    • Worker Node Sales
      • Guide to Purchase Worker Nodes
      • Worker Node Sale Timeline
      • Node Supply, Price, Tiers and Purchase Caps
      • Guaranteed Node Buyback
      • How to get Node Whitelisted?
      • Smart Contract Addresses
      • User Discounts & Referral Program
      • Worker Node Purchase FAQ
      • ABKK Collaboration FAQ
  • Verifier Node Guide
    • What is Verifier Node
      • How do the Verifier Node work
      • Verifier Node Rewards
      • How to run Verifier Node
      • What is the Verifier Node License (NFT)
    • Verifier Node Sales
      • Guide to Purchase Verifier Nodes
      • Verifier Node Sale Timeline
      • Node Supply, Price, Tiers and Purchase Caps
      • Guaranteed Node Buyback
      • How to get Node Whitelisted?
      • Smart Contract Addresses
      • User Discounts & Referral Program
      • Verifier Node Purchase FAQ
      • Aethir Node Winners FAQ
  • Inferix MVP
    • Tutorial: MVP for designers & GPU owners
    • PoR MVP
  • Inferix Testnet 2 on Solana & IoTeX [ENDED]
    • Adding GPUs to the Network
      • For GPU providers
      • For GPU providers without funds
      • For users without GPUs
      • For Inferix Node Holders
    • Renting GPU Devices
    • User Revenue Calculation
      • Worker Rewards
      • Rental Revenue
      • Viewing Revenue
      • Claiming Rewards
    • GPU Staking & Unstaking
      • Staking Requirements
      • Unstaking GPUs
    • Guide to get tIFX tokens
    • Why choose Inferix DePIN GPU Solutions?
  • Inferix Testnet 1 on IoTeX [ENDED]
    • Inferix GPU Solutions
    • Adding GPUs to the Network
    • Renting GPU Devices
    • User Revenue Calculation
    • GPU Staking
    • Multiple options to participate in the Staking & Mining Program
    • Special airdrop for Inferix Node Holders! 🎉
    • Guide to get tIFX tokens
    • FAQ
  • Inferix Explorer
  • Team & Achievements
    • Our Story
    • Team
    • Member of Cohort 1 DePINSurf
    • Achievements
  • Community & Events
    • Events
    • Inferix Campaign: "ALLIANCE" (ENDED)
  • Terms of Service
    • Privacy Policy
    • Airdrop Terms of Service
Powered by GitBook
On this page
  1. Inferix Whitepaper
  2. Introduction

Rendering verification problem

PreviousRendering network using crowdsourced GPUNextHigh-level description of ANGV

Last updated 8 months ago

A user submits some graphics work to a manager, this work consists of several scenes; each contains information about graphical objects, the camera, light sources and materials. The photorealistic rendering consists of sophisticated computation processes that calculate light properties at surfaces of all visible objects, resulting in 3D rendered images of the scene .

One of the most important problems that Inferix has to solve is to verify the authenticity of rendered results ,, . That means how to ensure that once a user submits a valid scene, then after waiting for an amount of time, the user will receive authentically rendered images. The authenticity can be defined informally as if the result received from the rendering network and the result received when the scene is genuinely rendered by a rendering software are human perceptually indistinguishable.

The workers who join the rendering network are mostly workstations of GPU owners who want to make profit from their unused computational resources. Respecting the privacy of GPU owners and their resources, besides lightweight open-source software installed to manage the communication with the network, there is completely no control on workers.

Consequently, there is no constraint to oblige workers to render the graphics scene correctly. Indeed, a malicious worker may receive a rendering task, but does nothing then uses some forged images as results. Without rendering the scene, the managers and users know only superficial features of what the rendered images look like. Obviously, the managers and users have no interest in rendering the scene themselves since if they can do that, there is no need to rely on workers. Moreover, we cannot deploy any surveillance mechanism on the machines of workers due to privacy reasons. Even if we try to do that, this is only a matter of time before a worker reverse engineers the mechanism and eventually bypasses it. The situation doesn't seem to favor us: checking the authenticity of something while only having a little knowledge about it, otherwise the attacker has complete information.

Naturally, a public-key cryptography approach is using a scheme of fully homomorphic encryption (FHE) . The scene is encrypted first by a private key before sending it to workers. Given the corresponding public key, the homomorphic encryption software performs the graphics rendering on the encrypted scene without needing to decrypt it. Finally, the encrypted rendered results are returned and decrypted at the user's side using the private key. The advantage of FHE is that the workers, even being able to modify the FHE software on their side, cannot interfere with the FHE rendering processes or forge the rendering results without being detected. Unfortunately, this approach is impractical since all state-of-the-art implementations will make the performance of the homomorphic encryption rendering become unacceptable .

[1]
[2]
[3]
[4]
[5]
[6]