EntropyStructsV2.sol 3.8 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071
  1. // SPDX-License-Identifier: Apache 2
  2. pragma solidity ^0.8.0;
  3. contract EntropyStructsV2 {
  4. struct ProviderInfo {
  5. uint128 feeInWei;
  6. uint128 accruedFeesInWei;
  7. // The commitment that the provider posted to the blockchain, and the sequence number
  8. // where they committed to this. This value is not advanced after the provider commits,
  9. // and instead is stored to help providers track where they are in the hash chain.
  10. bytes32 originalCommitment;
  11. uint64 originalCommitmentSequenceNumber;
  12. // Metadata for the current commitment. Providers may optionally use this field to help
  13. // manage rotations (i.e., to pick the sequence number from the correct hash chain).
  14. bytes commitmentMetadata;
  15. // Optional URI where clients can retrieve revelations for the provider.
  16. // Client SDKs can use this field to automatically determine how to retrieve random values for each provider.
  17. // TODO: specify the API that must be implemented at this URI
  18. bytes uri;
  19. // The first sequence number that is *not* included in the current commitment (i.e., an exclusive end index).
  20. // The contract maintains the invariant that sequenceNumber <= endSequenceNumber.
  21. // If sequenceNumber == endSequenceNumber, the provider must rotate their commitment to add additional random values.
  22. uint64 endSequenceNumber;
  23. // The sequence number that will be assigned to the next inbound user request.
  24. uint64 sequenceNumber;
  25. // The current commitment represents an index/value in the provider's hash chain.
  26. // These values are used to verify requests for future sequence numbers. Note that
  27. // currentCommitmentSequenceNumber < sequenceNumber.
  28. //
  29. // The currentCommitment advances forward through the provider's hash chain as values
  30. // are revealed on-chain.
  31. bytes32 currentCommitment;
  32. uint64 currentCommitmentSequenceNumber;
  33. // An address that is authorized to set / withdraw fees on behalf of this provider.
  34. address feeManager;
  35. // Maximum number of hashes to record in a request. This should be set according to the maximum gas limit
  36. // the provider supports for callbacks.
  37. uint32 maxNumHashes;
  38. // Default gas limit to use for callbacks.
  39. uint32 defaultGasLimit;
  40. }
  41. struct Request {
  42. // Storage slot 1 //
  43. address provider;
  44. uint64 sequenceNumber;
  45. // The number of hashes required to verify the provider revelation.
  46. uint32 numHashes;
  47. // Storage slot 2 //
  48. // The commitment is keccak256(userCommitment, providerCommitment). Storing the hash instead of both saves 20k gas by
  49. // eliminating 1 store.
  50. bytes32 commitment;
  51. // Storage slot 3 //
  52. // The number of the block where this request was created.
  53. // Note that we're using a uint64 such that we have an additional space for an address and other fields in
  54. // this storage slot. Although block.number returns a uint256, 64 bits should be plenty to index all of the
  55. // blocks ever generated.
  56. uint64 blockNumber;
  57. // The address that requested this random number.
  58. address requester;
  59. // If true, incorporate the blockhash of blockNumber into the generated random value.
  60. bool useBlockhash;
  61. // Status flag for requests with callbacks. See EntropyConstants for the possible values of this flag.
  62. uint8 callbackStatus;
  63. // The gasLimit in units of 10k gas. (i.e., 2 = 20k gas). We're using units of 10k in order to fit this
  64. // field into the remaining 2 bytes of this storage slot. The dynamic range here is 10k - 655M, which should
  65. // cover all real-world use cases.
  66. uint16 gasLimit10k;
  67. }
  68. }