How to Integrate Orakl Network’s Verifiable Random Function and Request-Response?
Orakl Network offers four distinct services: Data Feed, Proof of Reserve, Verifiable Random Function, and Request-Response. The Verifiable Random Function (VRF) and Request-Response (RR) services are requested through a consumer smart contract, which consequently receives fulfillment from the oracle. There are multiple ways to request these services, and depending on how you choose to integrate with Orakl Network, we have different recommendations for making requests.
In this blog post, we share the best practices for integrating with Orakl Network to minimize maintenance and enable delegation of payment for Orakl Network services to your customers. We assume that the reader is already familiar with the basic use of Prepayment, Verifiable Random Function, or Request-Response services.
What Type of Application Are You Building?
While there are numerous application types that could integrate with Orakl Network, this article specifically focuses on applications where you construct a platform whose users request VRF or RR services directly. The common use cases include requests for a random event triggered by a user in a game, user-generated requests for information outside of the blockchain, and many others.
If you’re the one making requests, we recommend following our developer guide for Verifiable Random Function, Request-Response and Prepayment instead.
What Is the Architecture of Your Application?
VRF and RR requests are initiated from a consumer smart contract, which subsequently sends requests to VRFCoordinator and RequestResponseCoordinator, respectively. The consumer smart contract is a component of your application that manages requests, fulfillments, and their associated operations based on the response value.
Your application design may opt for either a Single Consumer Smart Contract or Per-User Consumer Smart Contract. This design choice is pivotal as it impacts the optimal approach for integrating Orakl Network into your application. Before delving into their differences and use cases, let’s first discuss how we can make requests in Orakl Network.
How to Make a Request?
Coordinator (VRFCoordinator and RequestResponseCoordinator) smart contracts facilitate two types of requests, varying in their payment methods for services. We can either pay along with the request (using the payable modifier), referred to as direct payment, or use funds from a permanent account identified by a unique account ID.
When using direct payment, a temporary Account is created behind the scenes and funded with the estimated service and fulfillment fees. Once fulfilled, the fees are collected by the oracle, and the temporary account is then permanently removed. Integrating direct payment is straightforward; however, it becomes challenging to track all requests and expenditures as each request is linked to a new account. Additionally, requests tend to be more expensive due to the deployment of a new temporary Account smart contract with each request. If your application architecture utilizes Per-User Consumer Smart Contract, direct payment is the right approach due to its straightforward initialization.
The permanent account approach is the recommended method when your architecture uses a Single Consumer Smart Contract. The advantages of a permanent account over the temporary one include cheaper requests due to the reuse of a single Account smart contract, the ability to use funds for all paid services, cancellation of requests, and access from multiple permissioned applications.
Single Consumer Smart Contract
The Single Consumer Smart Contract is an architectural feature that involves using only one contract to communicate with Orakl Network. In this scenario, we recommend integrating your consumer smart contract with a permanent account. The prerequisite for using a permanent account is to create the account and whitelist your consumer smart contract.
Users of your application can deposit funds into permanent account in the same transaction before making the request (VRF, RR). Funds in the permanent account will then be utilized during fulfillment. For both deposit and request operations, we need to supply the account ID of the application’s permanent account.
Per-User Consumer Smart Contract
The Per-User Consumer Smart Contract describes an architectural feature that maintains a separate consumer smart contract for each user of the application. In this scenario, we recommend utilizing direct payment due to its simpler initial setup. Payment for the service and the creation of a temporary account will be encapsulated within the request transaction (VRF, RR), without the need to specify an account ID or an additional call to deposit funds into a permanent account.
However, because the creation of a temporary account results in additional transaction fee overhead, if the application anticipates frequent requests to Orakl Network, it’s feasible to create a permanent account for each consumer smart contract. Each consumer smart contract would then retain its designated permanent account, whitelist itself, deposit funds before initiating a request, and specify its account ID during request submissions.
Still Confused?
If this article didn’t address all your questions, please feel free to reach out to us at business@orakl.network. Our dedicated team of experts can assist with onboarding and guide you through the integration of Orakl Network solutions.
New To Orakl Network?
Orakl Network is an easy to use native token oracle that supports Verifiable Random Functions (VRF), Request-Response, Data Feed and Proof of Reserve. You can learn about each of these functionalities at our documentation or dive directly to code with curated hands-on tutorials for each of our services: vrf-consumer, request-response-consumer and data-feed-consumer.
