Infernet
General
Overview

Overview

Infernet is an EVM-compatible framework for bringing generalized compute (and more specifically AI/ML compute ) on-chain. It lets users easily integrate typical AI use cases and workflows with their blockchain workflow. Users can offer their ML models to others or build protocols with their ML models.

Types of requests

Infernet allows for three types of requests to be processed:

  1. Off-chain Jobs (aka web2 requests): These are jobs that are processed off-chain and the result is also delivered off-chain.
  2. On-chain Subscriptions (aka web3 requests): Using infernet-sdk, users can request compute from their smart contracts. The compute is processed off-chain and the result is delivered back to their smart contract.
  3. Delegated Subscriptions (aka web2 to web3 requests): These are useful when a user wants to request a compute via an HTTP request and have the result delivered to their smart contract.

Off-chain Jobs (aka web2 requests)

Non-streaming Jobs

These are quite similar to a typical API request-response cycle.

  1. User sends a request to the Infernet Node, indicating the compute they want to run.
  2. Infernet Node creates a job, returning a job ID to the user.
  3. The Infernet Node dispatches the job to a container that runs the compute (which could be an ML model).
  4. The container processes the request and returns the result to the Infernet Node.
  5. The Infernet Node stores the result in its database.
  6. Using the job ID, the user can poll the Infernet Node to check the status of the job, and once the job is complete, they can fetch the result.

Streaming Jobs (aka web2 requests)

In these types of jobs, the result is streamed back to the user as it is being processed.

  1. User sends a request to the Infernet Node, indicating that they want a streamed response.
  2. Infernet Node creates a job ID if it has an available container, it requests a stream from the container.
  3. The container processes the request and streams the result back to the Infernet Node.
  4. The Infernet Node streams the result back to the user, starting with the Job ID and then the rest of the stream.

On-Chain Subscriptions (aka web3 requests)

On-chain subscriptions work as follows:

  1. User creates a subscription by calling their consumer smart contract.
  2. The consumer contract calls the Coordinator method to create a either a callback or (recurring) subscription.
  3. The subscription is picked up by an Infernet Node.
  4. The Infernet Node dispatches the subscription to a container that runs a compute (which could be an ML model).
  5. The container processes the subscription and returns the result to the Infernet Node.
  6. The Infernet Node delivers the result to the smart contract via the Coordinator contract.
  7. Coordinator contract delivers the result by calling the _receiveCompute() method on the consumer smart contract.

Delegate Subscriptions (aka web2 to web3 requests)

Delegate subscriptions are useful when a user wants to request a compute via an HTTP request and have the result delivered to their smart contract. To allow for this, the receiving contract must implement the Delegator pattern. How this works is as follows:

  1. User deploys a smart contract that implements the Delegator pattern.
  2. They initialize the contract with a public address that they own. This address is referred to as the signer.
  3. The user prepares a subscription, and signs it with the signer's private key.
  4. The user sends the signed subscription via a POST request to the Infernet Node.
  5. The Infernet Node recovers the signer's public key from the signature and verifies it against the destination contract's getSigner() method.
  6. The Infernet Node dispatches the subscription to a container that runs a compute.
  7. The container processes the subscription and returns the result to the Infernet Node.
  8. The Infernet Node delivers the result to the smart contract via the Coordinator contract.
  9. Coordinator contract also verifies the signature and delivers the result by calling the _receiveCompute() method on the consumer smart contract.

Eager vs Lazy Delivery

Infernet 1.0.0 adds new support for eager and lazy delivery of results. This feature allows users to choose how they want their compute results to be delivered on-chain.

Eager: This is the same as the diagrams above show. The result containing output & proofs is delivered to the smart contract & consumed as soon as compute is available to the Coordinator.

Lazy: In this case, the output of the computation is stored to a separate storage contract called Inbox. The smart contract is still notified via the _receiveCompute() method, but the outputs & proof are stored in the Inbox contract, rather than being delivered directly to the smart contract. This allows for flows where users would want to asynchronously consume the results. They will be able to fetch the results from the Inbox contract at a later time.

Where to go from here?

  • Easiest way to learn about Infernet is to see some example applications built using Infernet. Head over to Ritual Learn (opens in a new tab) for a wide variety of step-by-step tutorials & videos.
  • Got some AI models ready to go? Check out our Infernet Services (opens in a new tab) for out-of-the-box services that you can use.
  • Check out the Infernet Node section to learn how to configure and deploy your own nodes!
  • Check out the Containers documentation to learn how to build an Infernet-compatible service.