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–
- Are there scenarios where commit-reveal is used outside of these two basic mechanisms? I would like to understand more about its cost/benefit.
- 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.