Commit/Reveal design vs secret contract design


#1

Through looking at two use cases that use commit-reveal design mechanisms (voting, auctions), it seems that this could be a recurring change in how smart contracts vs. secret contracts are designed.

“Commit-reveal” is the practice of hashing an amount (say, the direction of a vote or the exact amount of a bid), submitting it to the contract, and revealing the number after a period of time has passed.

  • commit reveal requires two user interactions with the contract
  • commit reveal data is public after the reveal period has ended

Because secret contracts rely on encryption rather than hashing, the data is decrypted inside an enclave to find the result (in these use-cases, direction of a vote and amount of a bid).

  • this requires only one user interaction
  • this is binding-- there is not an option to choose to not reveal your vote or bid (in commit-reveal, a mechanism can be designed to punish non-revealing participants, but it is optional)
  • non-winning bids are never public AND individual votes are never revealed

Some questions I have–

  1. Are there scenarios where commit-reveal is used outside of these two basic mechanisms? I would like to understand more about its cost/benefit.
  2. What are the risks of automating the “reveal” portion of the user interaction? Are there examples of this being done in functioning dApps?

I am not looking yet at the cost of the different models yet, only how they affect the dynamic of the games.


#2
  1. Commit-reveal is really what’s known as a Commitment Scheme. It’s a very useful cryptographic primitive that is actually used in many places, including when developing secure computation/MPC protocols.

  2. I have not considered this. I believe that if you automate this, you need to trust the side asking you to reveal. One way to do it is to listen to an event from a smart contract (which you, as the user, know and audited). That way, you know exactly when and how you will be asked to reveal. One risk is to make sure no one can change the ‘rules of the game’ - e.g., there’s no back-door allowing upgrades to the smart contract.