fix(contracts): OZ-L2-M02 WETH9 Approval Can Be Front-Run

[zimpha]

Purpose or design rationale of this PR

This PR fix the bug (M02 WETH9 Approval Can Be Front-Run) reported by OpenZeppelin. The following are the details:

The WETH9 contract has an approve function which allows the msg.sender (the approver) to authorize an address (the spender) to spend a determined amount of tokens on their behalf. However, if the approver wants to change the authorized amount of the spender, the approver needs to call the approve function again with the new amount. A malicious spender could front-run this second approve transaction, by using the transferFrom to spend all the previously authorized tokens before being authorized the amount specified in the second
approve transaction.

This is possible because L2 transactions are ordered by the L2 node based on gas price. This means that the malicious spender could transfer the original amount, and once this second approval transaction is confirmed, the spender could also transfer the second amount as well, rather than the approver's intent, which was only the second amount that was set. This is a well-known attack that is properly documented here.

While it is possible to avoid this problem by having every approver submit an approve transaction with the amount set to 0 prior to submitting another approve transaction with the newly desired amount, this is error-prone and gas-inefficient. Consider adding increaseAllowance and decreaseAllowance functions to atomically increase and decrease the allowance granted to the spender.

PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• build: Changes that affect the build system or external dependencies (example scopes: yarn, eslint, typescript)
• ci: Changes to our CI configuration files and scripts (example scopes: vercel, github, cypress)
• docs: Documentation-only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that doesn't fix a bug, or add a feature, or improves performance
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• test: Adding missing tests or correcting existing tests

Deployment tag versioning

Has tag in common/version.go been updated?

• No, this PR doesn't involve a new deployment, git tag, docker image tag
• Yes

Breaking change label

Does this PR have the breaking-change label?

• No, this PR is not a breaking change
• Yes

[zimpha]

@Thegaram I think this change is related to the l2geth's genesis.json file.

[github-actions]

LCOV of commit 5970a5b during Contracts #1163

Summary coverage rate:
  lines......: 52.3% (894 of 1711 lines)
  functions..: 69.5% (203 of 292 functions)
  branches...: no data found

Files changed coverage rate: n/a

[Thegaram]

LGTM. Since it's modified:

• We can consider removing the License notice.
• We can consider renaming WETH9 to WETH.