Randomness service: Improve performance and reliability

[GabrielMartinezRodriguez]

Linked Issues

• closes https://linear.app/happychain/issue/HAPPY-310/debug-and-fix-why-the-random-function-is-currently-throwing-an-error
• closes https://linear.app/happychain/issue/HAPPY-311/investigate-and-resolve-why-the-first-drand-submission-is-delayed-by
• closes https://linear.app/happychain/issue/HAPPY-268/evaluate-gas-usage-for-the-postdrand-method

Description

This PR aims to improve the performance and reliability of the randomness service, after noticing the following problems:
1 - The 'random()' method in the Random contract was failing in some blocks
2 - We were experiencing multiple drand network errors
3 - The first drand was delayed in submission by about 30 seconds
To fix the first problem, I discovered that it was caused because the drand delay wasn't sufficient to include the drand to be used in the random function in all blocks. For example, if the drand delay is 2, and you are in the block with timestamp 11, you are using the drand for timestamp 9. To include transactions in the block with timestamp 11, you must submit transactions with at least 1 second of margin, meaning you must submit the drand for the block with timestamp 11 at timestamp 11 or later.
This is problematic because we don't receive the block with timestamp 9 exactly at timestamp 9, and simultaneously, we must request drands from the network. The network delay is approximately 300ms, with peaks of 1s. The situation was even worse because we were performing gas estimation for every 'postDrand' transaction, adding about 600ms extra to include the transaction.
These multiple delays were causing us to miss multiple blocks.
To address these issues, this PR adds:

Increased drand delay from 2 to 4
Hardcoded gas limit to avoid estimating gas for every transaction
Increased timeout for the drand network from 500 ms to 1000 ms

With these changes, we fix problems 1 and 2.
To solve problem 3, I found a bug: if there were no reveal transactions, we weren't sending the post drand transaction. This was causing a delay of about 30 seconds after the randomness service starts to reveal commitments that were committed approximately 30 seconds earlier.

Toggle Checklist

Checklist

Basics

• B1. I have applied the proper label & proper branch name (e.g. norswap/build-system-caching).
• B2. This PR is not so big that it should be split & addresses only one concern.
• B3. The PR targets the lowest branch it can (ideally master).

Reminder: PR review guidelines

Correctness

• C1. Builds and passes tests.

• C2. The code is properly parameterized & compatible with different environments (e.g. local,
  testnet, mainnet, standalone wallet, ...).

• C3. I have manually tested my changes & connected features.

• C4. I have performed a thorough self-review of my code after submitting the PR,
  and have updated the code & comments accordingly.

Architecture & Documentation

• D1. I made it easy to reason locally about the code, by (1) using proper abstraction boundaries,
  (2) commenting these boundaries correctly, (3) adding inline comments for context when needed.
• D2. All public-facing APIs & meaningful (non-local) internal APIs are properly documented in code
  comments.
• D3. If appropriate, the general architecture of the code is documented in a code comment or
  in a Markdown document.

[cloudflare-workers-and-pages]

Deploying happychain with    Cloudflare Pages

Latest commit:	ca26b17
Status:	✅  Deploy successful!
Preview URL:	https://8a1f88a4.happychain.pages.dev
Branch Preview URL:	https://graphite-base-404.happychain.pages.dev

View logs

[GabrielMartinezRodriguez]

• Deploy randomness service #416 : 2 dependent PRs (#434 , #441 )
• Add config contract #404
• Randomness service: Improve performance and reliability #372 👈 (View in Graphite)
• Add transaction submission failure hook and error handling #366
• Increase default RPC timeout to 2000ms #365
• Add configurable HTTP polling interval for block monitoring #362
• Force initialization before using the TXM #361
• Script to monitor randomness service #325
• Script to easily launch the randomness service locally #324
• Submit drand numbers #318
• Random oracle contracts #307
• Only prune finalized randomness entries #305
• Add NewBlock hook #304
• Refactors the randomness service to be able to process pending commitments  #303
• Add SQLite persistence to randomness service #300
• Txm no longer receives Viem objects #298 : 1 other dependent PR (#299 )
• Add flush mechanism #289 : 1 other dependent PR (#297 )
• Allow run multiple txm simultaneously within the same service #285
• Added docs for txm #272
• Mutex in tx monitor #264
• Purge transactions #232
• Txm hooks #229
• Use kysely instead of mikro-orm #250
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[linear]

HAPPY-311 Investigate and resolve why the first Drand submission is delayed by about 30 seconds after initializing the randomness service. Also, address the Drand network error

[linear]

HAPPY-310 Debug and fix why the `random()` function is currently throwing an error

[linear]

HAPPY-268 Evaluate gas usage for the postDrand method

[not-reed]

i always forget block.timestamp is in seconds, not ms 😄

this needs 4s, to be 2 block delay?

I don't full understand how this works, but would it be possible to call randomForTimestamp and getRevealedValue to 'frontrun' someone else calling random() by 1 block then? effectively seeing the future slightly

[GabrielMartinezRodriguez]

Yes, it was a bit confusing. We changed the name of all the time-related variables to indicate whether they are in seconds or milliseconds. Now, this variable is called DRAND_DELAY_SECONDS.

Regarding "frontrunning," yes, you could know the drand value that we are going to use for random(), but you will never know the revealed value that we mix with the drand value. We emit the reveal transaction as soon as we receive the previous block. For example, if we are targeting the reveal of block N, we send the reveal transaction as soon as we receive block N-1.

Additionally, we have modified the node in this PR: HappyChainDevs/op-geth#1 to force the node to always execute the first transaction of the block—actually, the second, since the first is the system transaction "setL1BlockValuesEcotone".

With this, you can never know the output of random() before it has already been executed.

[norswap]

@not-reed The delay's goal is that the "canonical" drand value for block T=X is the latest Drand at X-DRAND_DELAY. That's because sometimes there is a block at X and a Drand value at X, and in those cases we cannot post the Drand value to the chain ontime. There are also issues due to needing to hit submit 1s before the block, network latency to get the Drand value etc...

That's why we had to increase this value: it turned at time T, it would sometimes take 1s to get the Drand value, and with the need to submit enough in advance, we'd sometimes miss the block.

Regarding frontrunning, I don't know I would frame it those terms — but anyone knows the Drand T at time T (+ network delay). So people will always know the Drand value before it hits the chain (we have to know it to post it).

Drand is still useful for two things:

1. commitments to future randomness, if you commit enough in advance (we have this defined in the contracts), then nobody will know the drand value at that time
2. removing our ability to influence randomness: synchronous randomness if formed by taking the Drand value + a random value to which we committed before the Drand value was knowns — that way, there's absolutely no way we can influence the randomness
   • we will still know the value before anyone else, so there is trust is we don't share it

[not-reed]

1000 is the delay?

block 1 at ts 0 => tries and fails
block 1 at ts 1000 => tries and fails
block 2 at ts 2000 => tries and succeeds

is it a problem that the final try if everything fails is guaranteed to be next block now?

[GabrielMartinezRodriguez]

We have to submit the drand value at most 4 seconds after it is generated because, after that moment, it will be used by "random()". So, that is not a problem