QRNG minConfirmations

Ideas
,
1

Requests will be responded to after minConfirmations blocks. Expect this to correspond to 1–3 minutes based on chain conditions such as congestion and block times. These numbers are subject to change.
— docs: …/qrng/reference/chains.html

Problem

1 minute is fit for raffle or lottery concepts, but in a dynamic games that’s too slow.

Link by default provides a 3 blocks which can be optionally raised:

    // The default is 3, but you can set this higher.
    uint16 requestConfirmations = 3;

Does current QRNG architecture make possible to set minConfirmations optionally for less amount of blocks to response? (e.g. 10-15 sec for Polygon/Fantom and 35 sec for Ethereum)?

Solution

I’ve found that Quintessence provider can be used for 1 block response. And it’s optimal to have random providers with different response blocktime for optional tier of security.

Proposal

Clarify this moment in documentation, so users can understand that they have a option to not get only 1-3 minute response, but also 1+ block.

2

Hey thanks for the proposal, We are currently exploring the option of giving users multiple endpoints on top of the endpoint they already have access to . This will be an additional endpoint with 1 minConfirmation with a disclaimer that this is susceptible to security risks like block reorgs etc.

1 Like
3

Sorry I have one more question. Documentation states the Quintessence response needs 1 confirmation, but it still takes like 132 blocks in Fantom network. ANU response needs 250 confirmations, so this 132 blocks in Quintessence is required?

4

@copsupemli the docs are not accurate, I’ve submitted a PR to show the accurate minConfirmations for Quintessence. For Fantom as in your case, the minConfirmations is 80 blocks

1 Like
5

We have discussed QRNG response time in this PR where you noted that it’s possible to implement 1 minConfirmation endpoint in v0.11.

Does it was added into release?

Please, can you clarify the current position about this feature?

6

we were able to successfully update the Quintessence QRNG airnode to v0.10.0 this enables dapps to specify their own minConfirmations in the parameters for faster responses. For example:

        bytes32 requestId = airnodeRrp.makeFullRequest(
            airnode,
            endpointIdUint256,
            address(this),
            sponsorWallet,
            address(this),
            this.fulfillUint256.selector,
            abi.encode(
                bytes32("1s"),
                bytes32("_minConfirmations"),
                bytes32("10")
            )
        );

This request will have a minConfirmation of 10

you can also encode the parameters offchain like so:

import { encode } from '@api3/airnode-abi';
const parameters = encode([{ name: '_minConfirmations', type: 'string32', value: '10' }]);

and pass it as an argument like so:

       bytes32 requestId = airnodeRrp.makeFullRequest(
            airnode,
            endpointIdUint256,
            address(this),
            sponsorWallet,
            address(this),
            this.fulfillUint256.selector,
            parameters
        );
1 Like
7

We have tested this configuration option on the Fantom network, but fulfillment is still being finalized after 20-100 blocks (so 20-100 seconds).

We have tried the following options (using the RemixQrngExample.sol default contract sample, Quintessence airnode 0x224e030f03Cd3440D88BD78C9BF5Ed36458A1A25 and AirnodeRrpV0 0xa0AD79D995DdeeB18a14eAef56A549A04e3Aa1Bd):

  1. Setting ‘1s’ and ‘7’ for ‘_minConfirmations’
  2. Setting ‘1s’ and ‘1’ for ‘_minConfirmations’
  3. Leaving it “” empty (default setting)

However, the results remain the same (20-100 blocks/seconds to fullfill, Fantom).

Our goal with the API3 QRNG is to achieve random fulfillment within 10 to 20 seconds on any network after the makeRequestUint256 function is called. Is it technically possible?

8

The way airnode is configured atm is that it wakes up at every minute, checks for on-chain requests that meet the minConfirmation requirements, processes those requests and then goes back to sleep until the next minute. If after the fetching process a new request arrives then it doesn’t get processed until the next cycle. With minConfirmation 1 the average time for requests should be about 30 seconds, with 59 seconds being the longest time it takes for airnode to respond(the request arrives on chain just after airnode fetched the on-chain logs which means it has to processed in the next cycle) and 1-10 seconds being the smallest(the request arrives just before airnode starts fetching the logs). Keep in mind this is the time it takes for Airnode to respond not for the fulfill transaction to arrive on-chain which could be another 10-20 seconds. So you end up with a range 20-89 seconds for when the response finally arrives on-chain. Unfortunately with how airnode works atm, this is the theoretical minimum we can go in terms of latency. We do have plans to go from a cyclic airnode that wakes up every minute to an instance that wakes up every 15 minutes but checks for requests constantly in that 15 minute timeframe, however this version will arrive at a much later date.

I’m curious to see how minConfirmation 1 and 7 are giving similar results, I’ll test it out and let you know the results but based on the above logic it makes sense because only the lower part of the range would increase slightly.

1 Like
9

This explanation accurately reflects the results we obtained during testing.

Let me clarify that minConfirmation to 1 carries some risk, as we didn’t receive a response a few times (possibly due to node sync timing issues, in my opinion). But in terms on 1 minute node update it doesn’t matter, so we can stick to minConfirmation >2 anyway.

Much appreciated for your help on these topics, and we would also be happy to see your explanation to our question in Airnode GitHub issue #1559.

1 Like