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:
- Off-chain Jobs (aka
web2
requests): These are jobs that are processed off-chain and the result is also delivered off-chain. - On-chain Subscriptions (aka
web3
requests): Usinginfernet-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. - Delegated Subscriptions (aka
web2
toweb3
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.
- User sends a request to the Infernet Node, indicating the compute they want to run.
- Infernet Node creates a job, returning a
job ID
to the user. - The Infernet Node dispatches the job to a container that runs the compute (which could be an ML model).
- The container processes the request and returns the result to the Infernet Node.
- The Infernet Node stores the result in its database.
- 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.
- User sends a request to the Infernet Node, indicating that they want a streamed response.
- Infernet Node creates a
job ID
if it has an available container, it requests a stream from the container. - The container processes the request and streams the result back to the Infernet Node.
- 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:
- User creates a subscription by calling their consumer smart contract.
- The consumer contract calls the Coordinator method to create a either a callback or (recurring) subscription.
- The subscription is picked up by an Infernet Node.
- The Infernet Node dispatches the subscription to a container that runs a compute (which could be an ML model).
- The container processes the subscription and returns the result to the Infernet Node.
- The Infernet Node delivers the result to the smart contract via the Coordinator contract.
- 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:
- User deploys a smart contract that implements the
Delegator
pattern. - They initialize the contract with a public address that they own. This address is referred to as the
signer
. - The user prepares a subscription, and signs it with the signer's private key.
- The user sends the signed subscription via a POST request to the Infernet Node.
- The Infernet Node recovers the signer's public key from the signature and verifies it against the destination
contract's
getSigner()
method. - The Infernet Node dispatches the subscription to a container that runs a compute.
- The container processes the subscription and returns the result to the Infernet Node.
- The Infernet Node delivers the result to the smart contract via the Coordinator contract.
- 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.