Skip to content
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

Merged
merged 19 commits into from
Oct 17, 2023
Merged

Initial version of random numbers contract #1093

merged 19 commits into from
Oct 17, 2023

Conversation

jayantk
Copy link
Contributor

@jayantk jayantk commented Oct 11, 2023

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.

@vercel
Copy link

vercel bot commented Oct 11, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

2 Ignored Deployments
Name Status Preview Comments Updated (UTC)
example-oracle-amm ⬜️ Ignored (Inspect) Visit Preview Oct 17, 2023 7:53pm
xc-admin-frontend ⬜️ Ignored (Inspect) Visit Preview Oct 17, 2023 7:53pm

// (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
Copy link
Collaborator

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.

Copy link
Contributor Author

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?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is added right?

Comment on lines 17 to 18
// - what's the impact of # of in-flight requests on gas usage?
// - fuzz test?
Copy link
Collaborator

@ali-bahjati ali-bahjati Oct 17, 2023

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice test!

Copy link
Collaborator

@ali-bahjati ali-bahjati left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice!

@jayantk jayantk merged commit 727f9ec into main Oct 17, 2023
4 checks passed
@jayantk jayantk deleted the random1 branch October 17, 2023 20:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants