Marking random benches

No, wait... I mean: Random Benchmarking. And no, I don't mean graffitiing street furniture.

We've been putting ARRNG (the on-chain RNG protocol formerly know as ICERING) through it's paces. Specifically we've been looking at how it performs with large volume requests.

Most RNG requests are small, with the vast majority being for a single random number. These tend to be a single RNG request in a single transaction. These are for common use cases, for example getting a verifiably random start position on-chain for an NFT collection. Or verifiable randomness on-chain for a prize draw.

But requests don't have to be this simple, and indeed there are potential use cases for much larger requests.

For example, we could imagine an NFT collection where the metadata is randomised on a per token basis with each token getting it's own random number. And maybe this request occurs as part of a single reveal, with a single transaction requesting 10,000 random numbers in a single call.

High-volume Requests

10,000 requests in one transaction means we need 10,000 responses. That's a lot.

For context, each block on Ethereum mainnet has an upper limit of about 1,420 transactions, assuming those transactions all use just 21k gas and the block expands all the way out to 30 million gas units.

So we already know that 10,000 response transactions will need seven blocks to complete. Even if no one else is using the chain at all!

But there is a bit of work to do before we can make the response. We need to request the verifiable RNG from random.org, receive it, then serve that to the requesting address. How quickly we can perform those actions will determine how quickly we can provide those 10,000 responses.

Initial Benchmarking Results

In our initial benchmarking we've focussed on a sample transaction with 100 requests. Clearly this is a lot less than 10,000 requests, but it allows us to examine how our architecture performs when handling the requests, and what the consequences would be with an even larger number of requests.

For 100 transactions ARRNG clears the backlog of requests in three blocks. This was running on goerli, and there wasn't much contention for resources while the tests were running, so is unlikely to be a truly accurate reflection of performance on a mainnet. But it gives us some initial data.

Performance of off-chain architecture while clearing the backlog was as expected, with no sign of stress. We can therefore extrapolate out 10,000 requests as requiring approximately 300 blocks to clear.

At least, on goerli.

Gas!

Beyond the time required by ARRNG, we have to consider the likely network congestion caused by responding to 10,000 requests. Indeed, would such a large queue of responses require active management to ensure that gas prices aren't driven too much by the response transactions alone?

This will be our next area of investigation. While requesting such a large amount of RNG at the same time isn't a current use case, we want to be ready to serve that demand in the future, should it be needed.