From aed006a63fac6e8553f383c1c169ce406f650fda Mon Sep 17 00:00:00 2001 From: Aditya Arora Date: Tue, 8 Oct 2024 16:51:14 -0400 Subject: [PATCH 1/3] chore(entropy) Protocol design ediy --- pages/entropy/protocol-design.mdx | 36 ++++++++----------------------- 1 file changed, 9 insertions(+), 27 deletions(-) diff --git a/pages/entropy/protocol-design.mdx b/pages/entropy/protocol-design.mdx index e6d488ec..b85c2693 100644 --- a/pages/entropy/protocol-design.mdx +++ b/pages/entropy/protocol-design.mdx @@ -25,39 +25,21 @@ up-front using a hash chain. Users of the protocol then simply grab the next ran The provider commits to $x_0$ by posting it to the Entropy contract. Each random number in the sequence can then be verified against the previous one in the sequence by hashing it, i.e., $\mathrm{hash}(x_i) = x_{i - 1}$ -**Request**: To produce a random number, the following steps occur. - -1. The user U draws a random number $x_U$, and submits $h_U = \mathrm{hash}(x_U)$ to the contract -2. The contract remembers $h_U$ and assigns it an incrementing sequence number $i$, representing which - of the provider's random numbers the user will receive. -3. The user submits an off-chain request (e.g. via HTTP) to the provider to reveal the $i$'th random number. -4. The provider checks the on-chain sequence number and ensures it is > $i$. If it is not, the provider - refuses to reveal the ith random number. The provider should wait for a sufficient number of block confirmations - to ensure that the request does not get re-orged out of the blockchain. -5. The provider reveals $x_i$ to the user. -6. The user submits both the provider's revealed number $x_i$ and their own $x_U$ to the contract. -7. The contract verifies $\mathrm{hash}(x_i) = x_{i-1}$ to prove that $x_i$ is the $i$'th random number. The contract also checks that $\mathrm{hash}(x_U) = h_U$. - The contract stores $x_i$ as the $i$'th random number to reuse for future verifications. -8. If both of the above conditions are satisfied, the random number $r = \mathrm{hash}(x_i, x_U)$. - As an added security mechanism, this step can incorporate the blockhash of the block that the - request transaction landed in: $r = \mathrm{hash}(x_i, x_U, \mathrm{blockhash})$. +Pyth Entropy uses automatic callbacks to simplify the flow: -This protocol has the same security properties as the 2-party randomness protocol above: as long as either -the provider or user is honest, the number $r$ is random. Honesty here means that the participant keeps their -random number $x$ a secret until the revelation phase (step 5) of the protocol. Note that providers need to -be careful to ensure their off-chain service isn't compromised to reveal the random numbers -- if this occurs, -then users will be able to influence the random number $r$. - -With automatic callbacks the flow is simplified: - -1. The user U draws a random number $x_U$, and submits **both** $x_U$ and $h_U = \mathrm{hash}(x_U)$ to the contract -2. The contract remembers $h_U$ and assigns it an incrementing sequence number $i$, representing which - of the provider's random numbers the user will receive. $x_U$ is recorded in the event logs. +1. The user U draws a random number $x_U$, and submits it to the contract. The contract generates the hash $h_U = \mathrm{hash}(x_U)$ and records both $x_U$ and $h_U$. The contract uses [`constructUserCommitment`](https://github.com/pyth-network/pyth-crosschain/blob/7bccde484f01c19844b7105d63df207a24018957/target_chains/ethereum/contracts/contracts/entropy/Entropy.sol#L628-L632) to generate the user's commitment. +2. The contract [remembers $h_U$ and assigns it an incrementing **sequence number $i$**](https://github.com/pyth-network/pyth-crosschain/blob/7bccde484f01c19844b7105d63df207a24018957/target_chains/ethereum/contracts/contracts/entropy/Entropy.sol#L232-L246), representing which + of the provider's random numbers the user will receive. $x_U$ is recorded in the [event logs](https://github.com/pyth-network/pyth-crosschain/blob/7bccde484f01c19844b7105d63df207a24018957/target_chains/ethereum/contracts/contracts/entropy/Entropy.sol#L300-L306). 3. After sufficient block confirmations, the provider submits a reveal transaction with $x_i$ and $x_U$ to the contract. 4. The contract verifies $\mathrm{hash}(x_U) = h_U$ and $\mathrm{hash}(x_i) = x_{i-1}$ to prove that $x_i$ is the $i$'th random number. 5. If both of the above conditions are satisfied, the random number $r = \mathrm{hash}(x_i, x_U)$ is generated and a callback is made to the requesting contract. +This protocol has the same security properties as the 2-party randomness protocol above: as long as either +the provider or user is honest, the number $r$ is random. + In this flow, providers can refuse revealing $x_i$ if the final random number $r$ is not in their favor, or they may be able to access $x_U$ before on-chain submission (e.g. via mempool) and rotate their commitments to influence the random number $r$. Of course, both of these behaviors are detectable and protocols can blacklist providers that exhibit them. + +Pyth Network deployed a default entropy provider. The code of default provider can be found [here](https://github.com/pyth-network/pyth-crosschain/tree/7bccde484f01c19844b7105d63df207a24018957/apps/fortuna). From 046fe643eb34bf4162573e4c74ef40bbcd118086 Mon Sep 17 00:00:00 2001 From: Aditya Arora Date: Wed, 9 Oct 2024 11:49:14 -0400 Subject: [PATCH 2/3] improvements --- pages/entropy/protocol-design.mdx | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/pages/entropy/protocol-design.mdx b/pages/entropy/protocol-design.mdx index b85c2693..6f28982e 100644 --- a/pages/entropy/protocol-design.mdx +++ b/pages/entropy/protocol-design.mdx @@ -27,6 +27,8 @@ Each random number in the sequence can then be verified against the previous one Pyth Entropy uses automatic callbacks to simplify the flow: +- **Request**: To produce a random number, the following steps occur. + 1. The user U draws a random number $x_U$, and submits it to the contract. The contract generates the hash $h_U = \mathrm{hash}(x_U)$ and records both $x_U$ and $h_U$. The contract uses [`constructUserCommitment`](https://github.com/pyth-network/pyth-crosschain/blob/7bccde484f01c19844b7105d63df207a24018957/target_chains/ethereum/contracts/contracts/entropy/Entropy.sol#L628-L632) to generate the user's commitment. 2. The contract [remembers $h_U$ and assigns it an incrementing **sequence number $i$**](https://github.com/pyth-network/pyth-crosschain/blob/7bccde484f01c19844b7105d63df207a24018957/target_chains/ethereum/contracts/contracts/entropy/Entropy.sol#L232-L246), representing which of the provider's random numbers the user will receive. $x_U$ is recorded in the [event logs](https://github.com/pyth-network/pyth-crosschain/blob/7bccde484f01c19844b7105d63df207a24018957/target_chains/ethereum/contracts/contracts/entropy/Entropy.sol#L300-L306). @@ -35,11 +37,13 @@ Pyth Entropy uses automatic callbacks to simplify the flow: 5. If both of the above conditions are satisfied, the random number $r = \mathrm{hash}(x_i, x_U)$ is generated and a callback is made to the requesting contract. -This protocol has the same security properties as the 2-party randomness protocol above: as long as either -the provider or user is honest, the number $r$ is random. - In this flow, providers can refuse revealing $x_i$ if the final random number $r$ is not in their favor, or they may be able to access $x_U$ before on-chain submission (e.g. via mempool) and rotate their commitments to influence the random number $r$. Of course, both of these behaviors are detectable and protocols can blacklist providers that exhibit them. -Pyth Network deployed a default entropy provider. The code of default provider can be found [here](https://github.com/pyth-network/pyth-crosschain/tree/7bccde484f01c19844b7105d63df207a24018957/apps/fortuna). +This protocol has the same security properties as the 2-party randomness protocol above: as long as either +the provider or user is honest, the number $r$ is random. + +Note that providers need to be careful to ensure their off-chain service isn't compromised to reveal the random numbers -- if this occurs, then users will be able to influence the random number $r$. + +There are two separate default deployed providers, one for mainnet chains and one for testnet chains. The code of default deployed provider can be found [here](https://github.com/pyth-network/pyth-crosschain/tree/7bccde484f01c19844b7105d63df207a24018957/apps/fortuna). From 47f696cac76d66be8cc685649236e90543a3320b Mon Sep 17 00:00:00 2001 From: Aditya Arora Date: Wed, 9 Oct 2024 11:49:34 -0400 Subject: [PATCH 3/3] improvements --- pages/entropy/protocol-design.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/entropy/protocol-design.mdx b/pages/entropy/protocol-design.mdx index 6f28982e..5f1e8deb 100644 --- a/pages/entropy/protocol-design.mdx +++ b/pages/entropy/protocol-design.mdx @@ -46,4 +46,4 @@ the provider or user is honest, the number $r$ is random. Note that providers need to be careful to ensure their off-chain service isn't compromised to reveal the random numbers -- if this occurs, then users will be able to influence the random number $r$. -There are two separate default deployed providers, one for mainnet chains and one for testnet chains. The code of default deployed provider can be found [here](https://github.com/pyth-network/pyth-crosschain/tree/7bccde484f01c19844b7105d63df207a24018957/apps/fortuna). +The code of default deployed provider can be found [here](https://github.com/pyth-network/pyth-crosschain/tree/7bccde484f01c19844b7105d63df207a24018957/apps/fortuna).