Skip to content

Commit

Permalink
Update EIP-5732: Move to Final (ethereum#5919)
Browse files Browse the repository at this point in the history
* Move EIP-5732 to Final

* Wording

* Update requires

* Tighten up grammar

* Fix list formatting

* Tighten security considerations

* Remove random sublist

Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
  • Loading branch information
2 people authored and wnft committed Nov 15, 2022
1 parent c8c6a16 commit dd7cd38
Showing 1 changed file with 11 additions and 12 deletions.
23 changes: 11 additions & 12 deletions EIPS/eip-5732.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,12 +4,11 @@ title: Commit Interface
description: A simple but general commit interface to support commit-reveal scheme.
author: Zainan Victor Zhou (@xinbenlv), Matt Stam (@mattstam)
discussions-to: https://ethereum-magicians.org/t/erc-5732-simple-commit-interface-to-support-commit-reveal-schemes/11115
status: Last Call
last-call-deadline: 2022-11-13
status: Final
type: Standards Track
category: ERC
created: 2022-09-29
requires: 165
requires: 165, 1271
---

## Abstract
Expand Down Expand Up @@ -66,7 +65,7 @@ interface IERC_COMMIT_GENERAL {

But there MUST be a way to supply an extra field of `secret_salt`, so that committer can later open the `secret_salt` in the reveal TX that exposes the `secret_salt`. The size and location of `secret_salt` is intentionally unspecified in this EIP to maximize flexibility for integration.

8. Compliant contract is RECOMMENDED to implement [EIP-165](./eip-165.md).
8. It is RECOMMENDED for compliant contracts to implement [EIP-165](./eip-165.md).

## Rationale

Expand Down Expand Up @@ -112,14 +111,14 @@ function commit(bytes32 commitment, bytes calldata data) public {
## Security Considerations

1. Do not use the reference implementation in production. It is just for demonstration purposes.
2. The reveal transactions, parameters, especially `secret_salt` MUST be kept in secrecy before revealing to achieve privacy.
3. The length of `secret_salt` cryptographically long enough and the way to generate a `secret_salt` shall be cryptographically safe.
4. User shall NEVER reuse a used `secret_salt`. It's RECOMMENDED for client application to warn User for reusing a secret_salt.
5. Contract implementations SHOULD consider deleting the commitment of a given sender immediately to reduce chance of replay attack or re-entry attack by adversaries.
6. Contract implementations MAY consider also include the ordering of commitment received to add restriction on the order of reveal TX transactions.
7. Cautious on the potential replay attack across different chain-ids or chains resulting from forks, in which case, a ChainId shall be included in the generation of commitment.
8. Proper time-gap is suggested if the purpose is to avoid front-running attack.
9. For compliant contract that requires the `_timePoint` from next TX to be _strictly greater_ than a previous TX, `block.timestamp` and `block.number` are not reliable as two TX could co-exist in the same block resulting in the same `_timePoint` value. In such case, compliant contract is to take extra measures to enforce this strict-monotone-ness. For example, use a separate state variable in the contract to keep track of number of commits it receives, or reject any second/other TX that shares the same `block.timestamp` or `block.number`.
2. The reveal transactions and parameters, especially `secret_salt`, MUST be kept secret before they are revealed.
3. The length of `secret_salt` must be cryptographically long enough and the random values used to generate `secret_salt` must be cryptographically safe.
4. Users must NEVER reuse a used `secret_salt`. It's recommended for client applications to warn users who attempt to do so.
5. Contract implementations should consider deleting the commitment of a given sender immediately to reduce the chances of a replay attack or re-entry attack.
6. Contract implementations may consider including the ordering of commitment received to add restrictions on the order of reveal transactions.
7. There is potential for replay attacks across different chainIds or chains resulting from forks. In these cases, the chainId must be included in the generation of commitment. For applications with a higher risk of replay attacks, implementors should consider battle-tested and cryptographically-secure solutions such as [EIP-712](./eip-712.md) to compose commitments before creating their own new solution.
8. Proper time gaps are suggested if the purpose is to avoid frontrunning attacks.
9. For compliant contract that requires the `_timePoint` from the next transaction to be _strictly greater_ than that of any previous transaction, `block.timestamp` and `block.number` are not reliable as two transactions could co-exist in the same block resulting in the same `_timePoint` value. In such case, extra measures to enforce this strict monotonicity are required, such as the use of a separate sate variable in the contract to keep track of number of commits it receives, or to reject any second/other TX that shares the same `block.timestamp` or `block.number`.

## Copyright

Expand Down

0 comments on commit dd7cd38

Please sign in to comment.