You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pages/entropy/protocol-design.mdx
+12-26Lines changed: 12 additions & 26 deletions
Original file line number
Diff line number
Diff line change
@@ -25,34 +25,13 @@ up-front using a hash chain. Users of the protocol then simply grab the next ran
25
25
The provider commits to $x_0$ by posting it to the Entropy contract.
26
26
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}$
27
27
28
-
**Request**: To produce a random number, the following steps occur.
29
-
30
-
1. The user U draws a random number $x_U$, and submits $h_U = \mathrm{hash}(x_U)$ to the contract
31
-
2. The contract remembers $h_U$ and assigns it an incrementing sequence number $i$, representing which
32
-
of the provider's random numbers the user will receive.
33
-
3. The user submits an off-chain request (e.g. via HTTP) to the provider to reveal the $i$'th random number.
34
-
4. The provider checks the on-chain sequence number and ensures it is > $i$. If it is not, the provider
35
-
refuses to reveal the ith random number. The provider should wait for a sufficient number of block confirmations
36
-
to ensure that the request does not get re-orged out of the blockchain.
37
-
5. The provider reveals $x_i$ to the user.
38
-
6. The user submits both the provider's revealed number $x_i$ and their own $x_U$ to the contract.
39
-
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$.
40
-
The contract stores $x_i$ as the $i$'th random number to reuse for future verifications.
41
-
8. If both of the above conditions are satisfied, the random number $r = \mathrm{hash}(x_i, x_U)$.
42
-
As an added security mechanism, this step can incorporate the blockhash of the block that the
Pyth Entropy uses automatic callbacks to simplify the flow:
44
29
45
-
This protocol has the same security properties as the 2-party randomness protocol above: as long as either
46
-
the provider or user is honest, the number $r$ is random. Honesty here means that the participant keeps their
47
-
random number $x$ a secret until the revelation phase (step 5) of the protocol. Note that providers need to
48
-
be careful to ensure their off-chain service isn't compromised to reveal the random numbers -- if this occurs,
49
-
then users will be able to influence the random number $r$.
50
-
51
-
With automatic callbacks the flow is simplified:
30
+
-**Request**: To produce a random number, the following steps occur.
52
31
53
-
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
54
-
2. The contract remembers $h_U$ and assigns it an incrementing sequence number $i$, representing which
55
-
of the provider's random numbers the user will receive. $x_U$ is recorded in the event logs.
32
+
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.
33
+
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
34
+
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).
56
35
3. After sufficient block confirmations, the provider submits a reveal transaction with $x_i$ and $x_U$ to the contract.
57
36
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.
58
37
5. If both of the above conditions are satisfied,
@@ -61,3 +40,10 @@ With automatic callbacks the flow is simplified:
61
40
In this flow, providers can refuse revealing $x_i$ if the final random number $r$ is not in their favor, or
62
41
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$.
63
42
Of course, both of these behaviors are detectable and protocols can blacklist providers that exhibit them.
43
+
44
+
This protocol has the same security properties as the 2-party randomness protocol above: as long as either
45
+
the provider or user is honest, the number $r$ is random.
46
+
47
+
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$.
48
+
49
+
The code of default deployed provider can be found [here](https://github.com/pyth-network/pyth-crosschain/tree/7bccde484f01c19844b7105d63df207a24018957/apps/fortuna).
| Sonic Fantom Testnet |[`0x96124d1f6e44ffdf1fb5d6d74bb2de1b7fb`](https://testnet.soniclabs.com/address/0x96124d1f6e44ffdf1fb5d6d74bb2de1b7fbe7376)|
144
+
| Sonic Fantom Testnet |[`0x96124d1f6e44ffdf1fb5d6d74bb2de1b7fb`](https://unichain-sepolia.blockscout.com/address/0x2880aB155794e7179c9eE2e38200202908C17B43)|
0 commit comments