Proposal for randomness story

[palango]

Tasks

Beta Give feedback

1. Research randomness/randao on OP stack
2. Research possible migration strategies from random beacon to OP-randomness

[karlb]

OP-stack passes through the PrevRandao from the L1 block. Since the L2 has more blocks than L1, the value does not change every block. In the case of Optimism mainnet, it is an average of 6 blocks with the same value (12s block time on Ethereum / 2s block time on Optimism = 6), but the number can easily diverge from this average:

$ for i in (seq -f '%.0f' 117675000 117675050); cast block -r https://mainnet.optimism.io -f mixHash "$i"; end | uniq -c
   1 0x0bca08abf4417ba93ca098115fca8fef07701b3706d7e6e25c57cec42c17013a
  12 0xd2ae47a123d19563eedd1c3caaae6d2f9b28ab848b654fce1a31c6552d9ea67e
   1 0x4be473674feb8ef1144b0d211615baf016aff5a59e6031d09631cf29afdbb6a7
   5 0x9c6da802f562d7f7c03be53718938f61ba835b6751efeadced4080800800fc20
   6 0xb280d0a7a7d8d640c5f45d3465e1cce4e1a0d72aa7f6ae6244ea03cb8aed868a
   6 0x981ef46c4b480c81ad0624fe643ef23934cfa36954440c30f863245316ed19ef
   6 0x5cf4253b3b2383d9b4609d51d7e70176236b1274f29b21235b804c47ed485f8d
   6 0x344f023b1d1798f10e1058efcbf7087420f07fce80439be2516207a227d4d174
   6 0x9ed5323596fb1575ea156efbad040daf2012ea1fa7e1f4c140eebf927db549a5
   2 0xa1ae14cb2baa3ecdd6a66d957f88e684b8cbfe9a685a7cb3ac34dec91fabb89a

Due to the latency with which the PrevRandao moves from L1 to L2, application developers should work with a larger lookahead when the randomness is used for important purposes. See EIP-4399 "Tips for application developers". This is especially true if we only read data from finalized blocks, as this further increased the time between knowing the randao value and its availability on L2.

[karlb]

To maintain the interface for existing users of Celo's randao, we could change the implementation of our current random function to just return block.prevrandao. That approach is very simple to implement, but has some limitations:

• It only implements the random function, none of the other functions ins the Random contract. That is the only function that was advertised on docs.celo.org and also the only one that really makes sense to be used by third parties. So this should be ok.
• Although the randao concept is very similar between the current Celo L1 and Optimism, the randao value on the L2 will be known a longer time in advance (see comment above). This could pose a risk to existing contracts if they rely on the specifics of the current behavior.
• Similarly, returning the same value across multiple blocks could break existing contracts using Celo's Random contract.

If we could find out how often the Random contract is used outside of the core Celo protocol and by which contracts, that would give us insight in how likely these problems are.

[karlb]

After checking the Blockscout db for Celo mainnet, we know that the Random contract was never used by third parties and there isn't even any recent internal usage (except for the consensus). So we can just stop supporting out current randomness system and provide Optimism's prevrandao without any changes.