-
Notifications
You must be signed in to change notification settings - Fork 383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initialize math/rand
with entropy
#2745
Comments
Added the |
if we're talking about initializing the global rand instance, then why would the previous block hash help? it would always be zero, because initialization only happens at block height 0.
i guess this would be the genesis timestamp then.
You mentioned prev block hash i think because you mean to use this source of randomness for every block, right? Needs clarity Using the block hash every block for anything adds computational complexity for every empty block, so should be avoided unless necessary. If a programmer needs randomness that is secure by including entropy from the last block hash, that should be something outside of math/rand like a /p/ package. |
If unclear, I was speaking about gno, not go. It can help with any contract added after block 0 using For block 0 and
My proposal suggests that we should follow the approach of Go 1.20, which initializes the random number generator "for you," eliminating the need to handle it manually. This is my preferred idea. The second part of my comment offers an alternative proposal to continue using Go 1.18 and improve the efficiency of the well-known
This is not a block-level feature, but rather a VM feature. If you have no transactions, then your block will not compute it.
It was my initial idea as well, which is why I created the Recently, someone suggested introducing a new Instead, I would prefer to have While my |
An obvious question: The random values are reproducible by anyone, right? If that's right, then do you think it will be clear to devs that it shouldn't be used to generate cryptographic secrets? |
NOTE: This issue is outdated. I need to update it to make it current and more clear. |
FWIW, specifically on the issue of seeding, I think that using the last blockhash as a source of entropy to seed the nanoseconds field in the timestamp (I am assuming historical context here, but I am guessing that this is because we can't assume that nanosecond level timestamps will be available on nodes), while opaque, is fine so long as we make sure to document that this is what we are doing. I think that I mentioned this when I inadvertently waded into this discussion on Signal, but just in case, I ran into this issue first hand when I was porting my ISAAC PRNG implementation to Gno, and I was trying to figure out what tools I had available for providing default seeding. As you note, @jefft0, this approach is wholly inadequate for cryptographic purposes, but I would generally expect anyone who isn't a complete newcomer to writing code on a blockchain platform to understand the deterministic nature of the platform. I think that if it's clearly documented, it is the approach of least-friction. I won't weigh in on the issue of non-entropy-related uses for the block hash here, as that just pollutes this discussion. If there is another issue (I haven't had the chance yet to search to see) for that, I'll weigh in there. Otherwise, @moul I am happy to create one where that issue could be discussed separately from this one. |
I propose initializing
math/rand
with the previous block hash, consensus metadata timestamp, and original caller. This method leverages three sources that are guessable but hard to manipulate:This aligns with Go 1.20 standards, improving our randomness initialization.
Alternative Proposal
Alternatively, we could stay with Go 1.18 and use the unused timestamp nanoseconds field to derive the previous block hash, adding entropy with the limitation of not having two blocks in under one second.
cc @wyhaines @kristovatlas
The text was updated successfully, but these errors were encountered: