Protocol Design
The Entropy protocol is an extension of a classical commit/reveal protocol. The original version has the following steps:
- Two parties A and B each draw secret random numbers, and .
- A and B hash their random numbers and share the hashes, and
- A and B reveal and
- Both parties verify that and
- The random number
This protocol has the property that the result is random as long as either A or B are honest. Thus, neither party needs to trust the other -- as long as they are themselves honest, they can ensure that the result is random.
Entropy implements a version of this protocol that is optimized for on-chain usage. The key difference is that one of the participants (the provider) commits to a sequence of random numbers up-front using a hash chain. Users of the protocol then simply grab the next random number in the sequence.
Setup: The provider P computes a sequence of random numbers, for :
The provider commits to 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.,
Pyth Entropy uses automatic callbacks to simplify the flow:
- Request: To produce a random number, the following steps occur.
- The user U draws a random number , and submits it to the contract. The contract generates the hash and records both and . The contract uses
constructUserCommitment
(opens in a new tab) to generate the user's commitment. - The contract remembers and assigns it an incrementing sequence number (opens in a new tab), representing which of the provider's random numbers the user will receive. is recorded in the event logs (opens in a new tab).
- After sufficient block confirmations, the provider submits a reveal transaction with and to the contract.
- The contract verifies and to prove that is the 'th random number.
- If both of the above conditions are satisfied, the random number is generated and a callback is made to the requesting contract.
In this flow, providers can refuse revealing if the final random number is not in their favor, or they may be able to access before on-chain submission (e.g. via mempool) and rotate their commitments to influence the random number . Of course, both of these behaviors are detectable and protocols can blacklist providers that exhibit them.
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 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 .
The code of default deployed provider can be found here (opens in a new tab).