-
Notifications
You must be signed in to change notification settings - Fork 213
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
Initial version of random numbers contract #1093
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 2 Ignored Deployments
|
// (Optional) as an added security mechanism, this step can further incorporate the blockhash of the request transaction, | ||
// r = hash(x_i, x_U, blockhash). | ||
// | ||
// This protocol has the same security properties as the 2-party randomness protocol above: as long as either |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's not entirely true. I discussed it previously with @jayantk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, i think you're right that it's somewhat easier to attack the hash function itself. I looked at a few papers on the topic and it seems like they do the same thing we're doing here though (no added random value per element). I figure let's go with this for the moment, and we can ask TOB at the audit stage what they think.
uint64 endSequenceNumber; | ||
} | ||
|
||
// TODO: add block number? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is added right?
// - what's the impact of # of in-flight requests on gas usage? | ||
// - fuzz test? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A new storage allocation has a high cost (in L1s) but deleting it is reducing part of the gas cost on allocation. How can it be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, sorry this comment is confusing. The issue is that verifying a provider's value requires hashing multiple times, where the number of times is approximately the number of in-flight requests. I think that should be fine since hashing is cheap, but it's probably worth having some explicit metrics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(i clarified the code comment)
provider1FeeInWei, | ||
newHashChain[0], | ||
bytes32(keccak256(abi.encodePacked(uint256(0x0100)))), | ||
newHashChainOffset + 10 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be 10?
// Rotating the provider key uses a sequence number | ||
assertEq(sequenceNumber3, sequenceNumber2 + 2); | ||
|
||
// Requests that were in-flight at the time of rotation use the commitment from the time of request |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice test!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice!
This PR adds the core protocol logic for random number generation. It needs a bunch of tests and little features, but the main ideas are all there.
Note that there's a private key in the deploy script that got deleted in the last commit. That private key is from foundry's default local VM, so it's not a problem that it's revealed in git history.