Oracle VRF

[DIGIX666]

based from this https://github.com/gnolang/gno/issues/265

Hello everyone, after repeatedly needing to randomize values, @kazai777 and I are looking into how to create an Oracle VRF.

Following our research, we wanted to validate our thinking on the creation steps and also get answers to some pending questions:

Off-chain ->

• Generation of private and public keys
• Implementation of the VRF function
• Setup of the Oracle service (API)
• Deployment of the Oracle service

In Gno ->

• Define the verification contract
• Deploy the contract on the blockchain

Questions:

• Who should hold the private key? (Should it be us as the creators of the oracle or a member of the core team?)
• How can we get the off-chain part audited without making a PR to avoid revealing the randomization mechanism to the public?
• Who should host the Oracle?

Feel free to provide any additional suggestions if you have any :)

[deelawn]

Hey @DIGIX666. I did some work earlier this year to build a generic package to enable various types of oracle implementations. It's called gnorkle. It is currently used in a realm meant to enable off-chain verification of gno addresses linked to github users. This example establishes a single trusted off-chain agent that can query the oracle realm for tasks. The agent complete the tasks and publishes the results back to the oracle realm.

gnorkle is built to be extended by implementing the Feed, Ingester, and Storage interfaces.

As for implementing a VRF specifically, I imagine this would be classified as a continuous data feed -- a feed that produces a "random" value on demand by doing some type of aggregation of the data sent to the oracle by multiple off-chain agents.

Writing a gno realm that acts as an oracle will always require a certain amount of trust unless the agent publishing to the realm is some external oracle like ChainLink. Even then, users must trust that it is actually ChainLink publishing the data.

I'm not sure what the exact use case or scope of your VRF proposal is, but have a look at some of the things I've linked here. I'd be happy to jump on a call with you to discuss in more detail.

[DIGIX666]

Hey @deelawn, thanks for your comment. I will dig into your links with @kazai777 , and we'll get back to you as soon as possible to organize a call. That would be great! :)

Hey @DIGIX666. I did some work earlier this year to build a generic package to enable various types of oracle implementations. It's called gnorkle. It is currently used in a realm meant to enable off-chain verification of gno addresses linked to github users. This example establishes a single trusted off-chain agent that can query the oracle realm for tasks. The agent complete the tasks and publishes the results back to the oracle realm.

gnorkle is built to be extended by implementing the Feed, Ingester, and Storage interfaces.

As for implementing a VRF specifically, I imagine this would be classified as a continuous data feed -- a feed that produces a "random" value on demand by doing some type of aggregation of the data sent to the oracle by multiple off-chain agents.

Writing a gno realm that acts as an oracle will always require a certain amount of trust unless the agent publishing to the realm is some external oracle like ChainLink. Even then, users must trust that it is actually ChainLink publishing the data.

I'm not sure what the exact use case or scope of your VRF proposal is, but have a look at some of the things I've linked here. I'd be happy to jump on a call with you to discuss in more detail.

Hey @deelawn, thanks for your comment. I will dig into your links with @kazai777 , and we'll get back to you as soon as possible to organize a call. That would be great! :)