or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
Randomness On Chain: A Suspiciously Devious Problem and Some Solutions
Written by neepheid, cha0sg0d, yush_g, with thoughts by ludens
Note: All of the thinking in this post has already been done many times in the past, including this blog post and this research conference. Our goal with this post is to strip away all the complexity of understanding eth2 and instead discuss the specific usecase of randomness in smart contracts.
Introduction – usecases for on-chain randomness
PREVRANDAO
that is generated by the proposer of each block, accessible via thedifficulty
opcode.PREVRANDAO
value works and propose a use case for on-chain games that enables developers to access a better source of randomness thanblockhash
in just a few lines of code.Why blockhash doesnt work on L1
Why blockhash mostly works on most L2s
Why difficulty = PREVRANDAO opcode works for most L1 contracts
How to make PREVRANDAO work on an L2
The VDF on blockhash solution
Unfortunately, because VDFs have been largely disproven, security of this is now a bit more dubious. I think you can still just jack up the advantage and calibrate over time as people calculate it faster, but you open yourself to one-time attacks.
We want a solution where randomness is atomic from the perspective of the user (i.e. they only send 1 transaction) and no one can manipulate any aspect of it, not even 1 bit. Consider this, for determining the randomness at any block n. The value of this rnadomness is \[VDF_{24\ seconds}(blockhash_{n-3})\]
To break this down, imagine seeding a 24 second verifiable delay function on the blockhash. The important thing about 24 is that it is more than 12, since blocks must be 12 seconds long in proof of stake (in proof of work, this wouldn't work since block times are variable). Then, any block producer might be able to change this value, but they wouldn't have enough time to calculate the effect of changing the blockhash before having to publish it, so it would not be manipulatable. Then, the first person to correctly send the VDF on chain at block n would pass the VDF verification function that updates the randomness stored on chain for everyone queried at block n. Since any client interacting with the randomness at that block would need the value of this VDF, default frontend game clients can run the VDF bashing behind the scenes as well, which has the added benefit of sometimes being able to score the player some of this MEV reward.
Notably, this randomness can also be submitted by any MEV searcher if we reimburse gas for updating randomness, and either run our own MEV searcher or publicize on keepr.network. This means the user (game player, NFT buyer, etc) only has to interact with 1 transaction on the chain.
Proof of concept walkthrough: random on-chain weather
In this scheme, we split weather changes into \(n\)-block "spans", where every \(n\)th block provides the random weather seed for the next \(n\) blocks (including itself).
For example, with spans of length 5, the \(RANDAO\) value for block 10 acts as the random seed for blocks 10, 11, 12, 13, and 14.
There isn't a specific "execution time". We just commit to some future blocks randomness and use that to impact subsequent player events.
To briefly expand on the signficance of the abovee a construction, let's imagine what can happen in a game with on-chain weather. Note that the objective is not that the weather is unknown when submitting a transaction, it's that the weather cannot be manipulated.
This mirrors our real world: