Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update EIP-5453: Move to Review #7690

Merged
merged 8 commits into from
Sep 12, 2023
Merged

Update EIP-5453: Move to Review #7690

Changes from 2 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
6b28910
Update eip-5453.md
xinbenlv Sep 12, 2023
5ea88da
Update eip-5453.md
xinbenlv Sep 12, 2023
b0dc8d0
Update eip-5453.md
xinbenlv Sep 12, 2023
1dd06df
Update eip-5453.md
xinbenlv Sep 12, 2023
1d0c705
Update eip-5453.md
xinbenlv Sep 12, 2023
3dfe07d
Update eip-5453.md
xinbenlv Sep 12, 2023
56f3e91
Update eip-5453.md
xinbenlv Sep 12, 2023
6f19bf7
Update eip-5453.md
xinbenlv Sep 12, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 10 additions & 10 deletions EIPS/eip-5453.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
description: A general protocol for approving function calls in the same transaction rely on EIP-5750.
author: Zainan Victor Zhou (@xinbenlv)
discussions-to: https://ethereum-magicians.org/t/erc-5453-endorsement-standard/10355
status: Stagnant
status: Review
type: Standards Track
category: ERC
created: 2022-08-12
Expand All @@ -13,11 +13,11 @@

## Abstract

This EIP establish a general protocol for permitting approving function calls in the same transaction rely on [EIP-5750](./eip-5750.md).
Unlike a few prior art ([EIP-2612](./eip-2612.md) for [EIP-20](./eip-20.md), [EIP-4494](./eip-4494.md) for [EIP-721](./eip-721.md) that
This EIP establish a general protocol for permitting approving function calls in the same transaction rely on [ERC-5750](./eip-5750.md).
Unlike a few prior art ([ERC-2612](./eip-2612.md) for [ERC-20](./eip-20.md), [ERC-4494](./eip-4494.md) for [ERC-721](./eip-721.md) that

Check failure on line 17 in EIPS/eip-5453.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

proposal `eip-4494.md` is not stable enough for a `status` of `Review` 

error[markdown-link-status]: proposal `eip-4494.md` is not stable enough for a `status` of `Review`
  --> EIPS/eip-5453.md
   |
17 | Unlike a few prior art ([ERC-2612](./eip-2612.md) for [ERC-20](./eip-20.md), [ERC-4494](./eip-4494.md) for [ERC-721](./eip-721.md) that
   |
   = help: because of this link, this proposal's `status` must be one of: `Draft`, `Stagnant`
   = help: see https://ethereum.github.io/eipw/markdown-link-status/
usually only permit for a single behavior (`transfer` for EIP-20 and `safeTransferFrom` for EIP-721) and a single approver in two transactions (first a `permit(...)` TX, then a `transfer`-like TX), this EIP provides a way to permit arbitrary behaviors and aggregating multiple approvals from arbitrary number of approvers in the same transaction, allowing for Multi-Sig or Threshold Signing behavior.

Check failure on line 18 in EIPS/eip-5453.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

the first match of the given pattern must be a link 

error[markdown-link-first]: the first match of the given pattern must be a link
  --> EIPS/eip-5453.md
   |
18 | usually only permit for a single behavior (`transfer` for EIP-20 and `safeTransferFrom` for EIP-721) and a single approver in two transactions (first a `permit(...)` TX, then a `transfer`-like TX), this EIP provides a way to permit arbitrary behaviors and aggregating multiple approvals from arbitrary number of approvers in the same transaction, allowing for Multi-Sig or Threshold Signing behavior.
   |
   = info: the pattern in question: `(?i)(?:eip|erc)-[0-9]+`
   = help: see https://ethereum.github.io/eipw/markdown-link-first/

Check failure on line 18 in EIPS/eip-5453.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

the first match of the given pattern must be a link 

error[markdown-link-first]: the first match of the given pattern must be a link
  --> EIPS/eip-5453.md
   |
18 | usually only permit for a single behavior (`transfer` for EIP-20 and `safeTransferFrom` for EIP-721) and a single approver in two transactions (first a `permit(...)` TX, then a `transfer`-like TX), this EIP provides a way to permit arbitrary behaviors and aggregating multiple approvals from arbitrary number of approvers in the same transaction, allowing for Multi-Sig or Threshold Signing behavior.
   |
   = info: the pattern in question: `(?i)(?:eip|erc)-[0-9]+`

Check failure on line 18 in EIPS/eip-5453.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
  --> EIPS/eip-5453.md
   |
18 | usually only permit for a single behavior (`transfer` for EIP-20 and `safeTransferFrom` for EIP-721) and a single approver in two transactions (first a `permit(...)` TX, then a `transfer`-like TX), this EIP provides a way to permit arbitrary behaviors and aggregating multiple approvals from arbitrary number of approvers in the same transaction, allowing for Multi-Sig or Threshold Signing behavior.
   |
   = help: see https://ethereum.github.io/eipw/markdown-refs/

<!-- TODO add context about other EIPs this EIP is designed to work with. -->

Check failure on line 20 in EIPS/eip-5453.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

HTML comments are not allowed when `status` is `Review` 

error[markdown-html-comments]: HTML comments are not allowed when `status` is `Review`
   --> EIPS/eip-5453.md
    |
 20 | <!-- TODO add context about other EIPs this EIP is designed to work with. -->
    |
   ::: EIPS/eip-5453.md
    |
 31 | <!-- TODO add details about Motivations and example use cases -->
    |
   ::: EIPS/eip-5453.md
    |
 41 | <!-- TODO add detail explanation of each method parameters. -->
    |
   ::: EIPS/eip-5453.md
    |
148 | <!-- TODO convert the solidity code into mathematical representation. -->
    |
    = help: see https://ethereum.github.io/eipw/markdown-html-comments/
## Motivation

1. Support permit(approval) alongside a function call.
Expand Down Expand Up @@ -109,10 +109,10 @@

### Behavior specification

As specified in [EIP-5750 General Extensibility for Method Behaviors](./eip-5750.md), any compliant method that has an `bytes extraData` as its
last method designated for extending behaviors can conform to [EIP-5453](./eip-5453.md) as the way to indicate a permit from certain user.
As specified in [ERC-5750 General Extensibility for Method Behaviors](./eip-5750.md), any compliant method that has an `bytes extraData` as its
last method designated for extending behaviors can conform to [ERC-5453](./eip-5453.md) as the way to indicate a permit from certain user.

1. Any compliant method of this EIP MUST be a [EIP-5750](./eip-5750.md) compliant method.
1. Any compliant method of this EIP MUST be a [ERC-5750](./eip-5750.md) compliant method.
2. Caller MUST pass in the last parameter `bytes extraData` conforming a solidity memory encoded layout bytes of `GeneralExtensonDataStruct` specified in _Section Interfaces_. The following descriptions are based on when decoding `bytes extraData` into a `GeneralExtensonDataStruct`
3. In the `GeneralExtensonDataStruct`-decoded `extraData`, caller MUST set the value of `GeneralExtensonDataStruct.erc5453MagicWord` to be the `keccak256("ERC5453-ENDORSEMENT")`.
4. Caller MUST set the value of `GeneralExtensonDataStruct.erc5453Type` to be one of the supported values.
Expand All @@ -127,7 +127,7 @@

7. Each `SingleEndorsementData` MUST have a `address endorserAddress;` and a 65-bytes `bytes sig` signature.

8. Each `bytes sig` MUST be an ECDSA (secp256k1) signature using private key of signer whose corresponding address is `endorserAddress` signing `validityDigest` which is the a hashTypeDataV4 of [EIP-712](./eip-712.md) of hashStruct of `ValidityBound` data structure as followed:
8. Each `bytes sig` MUST be an ECDSA (secp256k1) signature using private key of signer whose corresponding address is `endorserAddress` signing `validityDigest` which is the a hashTypeDataV4 of [ERC-712](./eip-712.md) of hashStruct of `ValidityBound` data structure as followed:

```solidity
bytes32 validityDigest =
Expand Down Expand Up @@ -172,14 +172,14 @@
## Rationale

1. We chose to have both `ERC5453_TYPE_A`(single-endorsement) and `ERC5453_TYPE_B`(multiple-endorsements, same nonce for entire contract) so we
could balance a wider range of use cases. E.g. the same use cases of EIP-2612 and EIP-4494 can be supported by `ERC5453_TYPE_A`. And threshold approvals can be done via `ERC5453_TYPE_B`. More complicated approval types can also be extended by defining new `ERC5453_TYPE_?`

Check failure on line 175 in EIPS/eip-5453.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

the first match of the given pattern must be a link 

error[markdown-link-first]: the first match of the given pattern must be a link
   --> EIPS/eip-5453.md
    |
175 | could balance a wider range of use cases. E.g. the same use cases of EIP-2612 and EIP-4494 can be supported by `ERC5453_TYPE_A`. And threshold approvals can be done via `ERC5453_TYPE_B`. More complicated approval types can also be extended by defining new `ERC5453_TYPE_?`
    |
    = info: the pattern in question: `(?i)(?:eip|erc)-[0-9]+`

Check failure on line 175 in EIPS/eip-5453.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

the first match of the given pattern must be a link 

error[markdown-link-first]: the first match of the given pattern must be a link
   --> EIPS/eip-5453.md
    |
175 | could balance a wider range of use cases. E.g. the same use cases of EIP-2612 and EIP-4494 can be supported by `ERC5453_TYPE_A`. And threshold approvals can be done via `ERC5453_TYPE_B`. More complicated approval types can also be extended by defining new `ERC5453_TYPE_?`
    |
    = info: the pattern in question: `(?i)(?:eip|erc)-[0-9]+`

2. We chose to include both `validSince` and `validBy` to allow maximum flexibility in expiration. This can be also be supported by EVM natively at if adopted [EIP-5081](./eip-5081.md) but EIP-5081 will not be adopted anytime soon, we choose to add these two numbers in our protocol to allow
2. We chose to include both `validSince` and `validBy` to allow maximum flexibility in expiration. This can be also be supported by EVM natively at if adopted [ERC-5081](./eip-5081.md) but EIP-5081 will not be adopted anytime soon, we choose to add these two numbers in our protocol to allow

Check failure on line 177 in EIPS/eip-5453.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

the first match of the given pattern must be a link 

error[markdown-link-first]: the first match of the given pattern must be a link
   --> EIPS/eip-5453.md
    |
177 | 2. We chose to include both `validSince` and `validBy` to allow maximum flexibility in expiration. This can be also be supported by EVM natively at  if adopted [ERC-5081](./eip-5081.md) but EIP-5081 will not be adopted anytime soon, we choose to add these two numbers in our protocol to allow
    |
    = info: the pattern in question: `(?i)(?:eip|erc)-[0-9]+`

Check failure on line 177 in EIPS/eip-5453.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

proposal `eip-5081.md` is not stable enough for a `status` of `Review` 

error[markdown-link-status]: proposal `eip-5081.md` is not stable enough for a `status` of `Review`
   --> EIPS/eip-5453.md
    |
177 | 2. We chose to include both `validSince` and `validBy` to allow maximum flexibility in expiration. This can be also be supported by EVM natively at  if adopted [ERC-5081](./eip-5081.md) but EIP-5081 will not be adopted anytime soon, we choose to add these two numbers in our protocol to allow
    |
    = help: because of this link, this proposal's `status` must be one of: `Draft`, `Stagnant`
smart contract level support.

## Backwards Compatibility

The design assumes a `bytes calldata extraData` to maximize the flexibility of future extensions. This assumption is compatible with [EIP-721](eip-721.md), [EIP-1155](eip-1155.md) and many other ERC-track EIPs. Those that aren't, such as [EIP-20](./eip-20.md), can also be updated to support it, such as using a wrapper contract or proxy upgrade.
The design assumes a `bytes calldata extraData` to maximize the flexibility of future extensions. This assumption is compatible with [ERC-721](eip-721.md), [ERC-1155](eip-1155.md) and many other ERC-track EIPs. Those that aren't, such as [ERC-20](./eip-20.md), can also be updated to support it, such as using a wrapper contract or proxy upgrade.

## Reference Implementation

Expand Down Expand Up @@ -262,7 +262,7 @@

### Reference Implementation of `EndorsableERC721`

Here is a reference implementation of `EndorsableERC721` that achieves similar behavior of [EIP-4494](./eip-4494.md).
Here is a reference implementation of `EndorsableERC721` that achieves similar behavior of [ERC-4494](./eip-4494.md).

Check failure on line 265 in EIPS/eip-5453.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

proposal `eip-4494.md` is not stable enough for a `status` of `Review` 

error[markdown-link-status]: proposal `eip-4494.md` is not stable enough for a `status` of `Review`
   --> EIPS/eip-5453.md
    |
265 | Here is a reference implementation of `EndorsableERC721` that achieves similar behavior of [ERC-4494](./eip-4494.md).
    |
    = help: because of this link, this proposal's `status` must be one of: `Draft`, `Stagnant`

```solidity
pragma solidity ^0.8.9;
Expand Down
Loading