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 all 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
30 changes: 12 additions & 18 deletions EIPS/eip-5453.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
---
eip: 5453
title: Endorsement - Permit for Any Functions
description: A general protocol for approving function calls in the same transaction rely on EIP-5750.
description: A general protocol for approving function calls in the same transaction rely on ERC-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,10 @@ requires: 165, 712, 1271, 5750

## 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
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.
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` for [ERC-721](./eip-721.md) that
usually only permit for a single behavior (`transfer` for ERC-20 and `safeTransferFrom` for ERC-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.

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

1. Support permit(approval) alongside a function call.
Expand All @@ -28,8 +27,6 @@ usually only permit for a single behavior (`transfer` for EIP-20 and `safeTransf
6. Support accumulated voting
7. Support off-line signatures

<!-- TODO add details about Motivations and example use cases -->

## Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Expand All @@ -38,8 +35,6 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S

The interfaces and structure referenced here are as followed

<!-- TODO add detail explanation of each method parameters. -->

```solidity
pragma solidity ^0.8.9;

Expand Down Expand Up @@ -109,10 +104,10 @@ See [`IERC5453.sol`](../assets/eip-5453/IERC5453.sol).

### 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 Down Expand Up @@ -145,7 +140,6 @@ bytes32 validityDigest =
)
);
```
<!-- TODO convert the solidity code into mathematical representation. -->

9. The `functionParamStructHash` MUST be computed as followed

Expand All @@ -172,14 +166,14 @@ whereas
## 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_?`
could balance a wider range of use cases. E.g. the same use cases of ERC-2612 and `ERC-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_?`

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` but `ERC-5081` will not be adopted anytime soon, we choose to add these two numbers in our protocol to allow
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 +256,7 @@ See [`AERC5453.sol`](../assets/eip-5453/AERC5453.sol)

### 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`.

```solidity
pragma solidity ^0.8.9;
Expand Down