Skip to content

Commit

Permalink
Merge branch 'master' into create_native_aa_rpc_api
Browse files Browse the repository at this point in the history
  • Loading branch information
forshtat authored Sep 10, 2024
2 parents 237cd9a + 1ff6e56 commit 50686d3
Show file tree
Hide file tree
Showing 46 changed files with 3,174 additions and 16,839 deletions.
12 changes: 6 additions & 6 deletions .github/workflows/stale.yml
Original file line number Diff line number Diff line change
Expand Up @@ -20,16 +20,16 @@ jobs:
repo-token: ${{ secrets.GITHUB_TOKEN }}
ascending: true # Since we have so many issues, the stale bot finds it hard to keep track. This makes sure that at least the oldest are removed.
# Issue config
stale-issue-message: There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.
stale-issue-message: There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity.
close-issue-message: This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback.
days-before-issue-stale: 7
days-before-issue-close: 49 # 49 + 7 weeks = 3 months
days-before-issue-stale: 183
days-before-issue-close: 190
exempt-issue-labels: discussions-to
stale-issue-label: w-stale
# PR config
stale-pr-message: There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
stale-pr-message: There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
close-pr-message: This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.
days-before-pr-stale: 14
days-before-pr-close: 42 # 42 + 14 weeks = 3 months
days-before-pr-stale: 183
days-before-pr-close: 190
exempt-pr-milestones: "Manual Merge Queue"
stale-pr-label: w-stale
13 changes: 4 additions & 9 deletions ERCS/erc-3770.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,8 +12,8 @@ created: 2021-08-26

## Abstract

[ERC-3770](./eip-3770.md) introduces a new address standard to be adapted by wallets and dApps to display chain-specific addresses by using a human-reacable prefix.
[ERC-3770](./eip-3770.md) introduces a new address standard to be adapted by wallets and dApps to display chain-specific addresses by using a human-readable prefix.

## Motivation

The need for this proposal emerges from the increasing adoption of non-Ethereum Mainnet chains that use the Ethereum Virtual Machine (EVM). In this context, addresses become ambiguous, as the same address may refer to an EOA on chain X or a smart contract on chain Y. This will eventually lead to Ethereum users losing funds due to human error. For example, users sending funds to a smart contract wallet address which was not deployed on a particular chain.
Expand All @@ -36,13 +36,8 @@ Chain-specific address = "`shortName`" "`:`" "`address`"

### Semantics

```
`shortName` is mandatory and MUST be a valid chain short name from https://github.com/ethereum-lists/chains
`address` is mandatory and MUST be a [ERC-55](./eip-55.md) compatible hexadecimal address
```
* `shortName` is mandatory and MUST be a valid chain short name from https://github.com/ethereum-lists/chains
* `address` is mandatory and MUST be a [ERC-55](./eip-55.md) compatible hexadecimal address

### Examples

Expand Down
95 changes: 48 additions & 47 deletions ERCS/erc-4337.md

Large diffs are not rendered by default.

133 changes: 62 additions & 71 deletions ERCS/erc-7007.md

Large diffs are not rendered by default.

9 changes: 5 additions & 4 deletions ERCS/erc-7432.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,8 @@ title: Non-Fungible Token Roles
description: Role Management for NFTs. Enables accounts to share the utility of NFTs via expirable role assignments.
author: Ernani São Thiago (@ernanirst), Daniel Lima (@karacurt)
discussions-to: https://ethereum-magicians.org/t/eip-7432-non-fungible-token-roles/15298
status: Review
status: Last Call
last-call-deadline: 2024-09-17
type: Standards Track
category: ERC
created: 2023-07-14
Expand Down Expand Up @@ -337,7 +338,7 @@ Automatic expiration is implemented via the `grantRole` and `roleExpirationDate`
for setting the expiration date, and `roleExpirationDate` allow developers to check whether the role is expired. Since
`uint256` is not natively supported by most programming languages, dates are represented as `uint64` on this standard.
The maximum UNIX timestamp represented by a `uint64` is about the year `584,942,417,355`, which should be enough to be
considered "permanent". For this reason, it's RECOMMENDED using `type(uint64).max` to support use cases that require a
considered "permanent". For this reason, it's recommended using `type(uint64).max` to support use cases that require a
role never to expire.

### Revocable Roles
Expand All @@ -347,8 +348,8 @@ others, the recipient may require assurance that the role cannot be revoked. The
to the `grantRole` function to specify whether a role can be revoked prematurely, enabling the standard to
support both use cases.

Regardless of the value of `revocable`, it's RECOMMENDED always to enable the `recipient` to revoke roles, allowing
them to eliminate undesirable assignments.
Regardless of the value of `revocable`, it's recommended always to enable the `recipient` to revoke roles, allowing them
to eliminate undesirable assignments.

### Custom Data

Expand Down
4 changes: 2 additions & 2 deletions ERCS/erc-7579.md
Original file line number Diff line number Diff line change
Expand Up @@ -93,7 +93,7 @@ function executeUserOp(PackedUserOperation calldata userOp, bytes32 userOpHash)

The execution mode is a `bytes32` value that is structured as follows:

- callType (1 byte): `0x00` for a single `call`, `0x01` for a batch `call` and `0xff` for `delegatecall`
- callType (1 byte): `0x00` for a single `call`, `0x01` for a batch `call`, `0xfe` for `staticcall` and `0xff` for `delegatecall`
- execType (1 byte): `0x00` for executions that revert on failure, `0x01` for executions that do not revert on failure but implement some form of error handling
- unused (4 bytes): this range is reserved for future standardization
- modeSelector (4 bytes): an additional mode selector that can be used to create further execution modes
Expand All @@ -105,7 +105,7 @@ Here is a visual representation of the execution mode:
| -------- | -------- | ------- | ------------ | ----------- |
| 1 byte | 1 byte | 4 bytes | 4 bytes | 22 bytes |

Accounts are NOT REQUIRED to implement all execution modes. The account MUST declare what modes are supported in `supportsAccountMode` (see below) and if a mode is requested that is not supported by the account, the account MUST revert.
Accounts are NOT REQUIRED to implement all execution modes. The account MUST declare what modes are supported in `supportsExecutionMode` (see below) and if a mode is requested that is not supported by the account, the account MUST revert.

The account MUST encode the execution data the following ways:

Expand Down
8 changes: 5 additions & 3 deletions ERCS/erc-7585.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ requires: 165, 721, 1155

## Abstract

This proposal introduces a design for `minimum value selection` storage proofs on Merkle trees. The design consists of two main components:
This proposal introduces a design for "minimum value selection" storage proofs on Merkle trees. The design consists of two main components:

1. A hashing algorithm termed MixHash, aimed to replace the commonly used Keccak256 and SHA256 algorithms.
2. Public data storage proofs. This enables anyone to present a proof to a public network, verifying their possession of a copy of specific public data marked by MixHash.
Expand Down Expand Up @@ -192,7 +192,7 @@ def generateProofWithPow(mixHash, blockHeight,file)
noise = noise + 1

m_path = getMerkleTreePath(chunk_hash_array, min_index)
return strorage_proof(mixHash, blockHeight, min_index, m_path, min_chunk,noise)
return storage_proof(mixHash, blockHeight, min_index, m_path, min_chunk,noise)
```

Applying this mechanism increases the cost of generating storage proofs, which deviates from our initial intent to reduce the widespread effective storage of public data. Moreover, heavily relying on a PoW-based economic model may allow Suppliers with significant advantages in PoW through specialized hardware to disrupt the basic participatory nature of the game, reducing the widespread distribution of public data. Therefore, it is advised not to enable the PoW mechanism unless absolutely necessary.
Expand Down Expand Up @@ -262,12 +262,15 @@ PublicDataProofDemo includes test cases written using Hardhat.
## Reference Implementation

PublicDataProof Demo

- A standard reference implementation

DMC public data inscription

- Based on public data storage certification, a complete economic model and gameplay has been designed on ETH network and BTC inscription network

Learn more background and existing attempts

- DMC Main Chain
- CYFS

Expand All @@ -280,4 +283,3 @@ The design of MixHash can support storage proofs for private files, but this req
## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).

4 changes: 2 additions & 2 deletions ERCS/erc-7588.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ title: Blob Transactions Metadata JSON Schema
description: Attaching metadata to blobs carried by blob transactions
author: Gavin Fu (@gavfu), Leo Wang (@wanglie1986), Bova Chen (@appoipp), Aiden X (@4ever9)
discussions-to: https://ethereum-magicians.org/t/erc7588-attaching-metadata-to-blobs-carried-by-blob-transactions/17873
status: Review
status: Final
type: Standards Track
category: ERC
created: 2024-01-01
Expand Down Expand Up @@ -149,4 +149,4 @@ This EIP does not introduce any new security risks or vulnerabilities, as the me

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Copyright and related rights waived via [CC0](../LICENSE.md).
159 changes: 159 additions & 0 deletions ERCS/erc-7603.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,159 @@
---
eip: 7603
title: ERC-1155 Multi-Asset extension
description: An interface compatible with ERC-1155 for Multi-Asset tokens with context-dependent asset type output control.
author: Haru (@haruu8)
discussions-to: https://ethereum-magicians.org/t/erc-multi-context-dependent-multi-asset-tokens-eip1155-extension/18303
status: Draft
type: Standards Track
category: ERC
created: 2024-01-25
requires: 165, 1155
---

## Abstract

The Multi-Asset Token standard, compatible with [ERC-1155](./eip-1155.md), facilitates the development of a new fundamental component: the context-dependent data output for each collection.

The context-dependent data output means that the asset is displayed in an appropriate format based on how the token is accessed. I.e., if the token is being opened in an e-book reader, the PDF asset is displayed; if the token is opened in the marketplace, the PNG or the SVG asset is displayed; if the token is accessed from within a game, the 3D model asset is accessed, and if the token is accessed by an Internet of Things (IoT) hub, the asset providing the necessary addressing and specification information is accessed.

A Token Collection can have multiple assets (outputs), which can be any file to order them by priority. They do not have to match in mime-type or tokenURI, nor do they depend on one another. Assets are not standalone entities but should be considered “namespaced tokenURIs”.

## Motivation

With ERC-1155 compatible tokens being a widespread form of tokens in the Ethereum ecosystem and being used for various use cases, it is time to standardize additional utility for them. Having multiple assets associated with a single Token Collection allows for greater utility, usability, and forward compatibility. This EIP improves upon ERC-1155 in the following areas:

- [Cross-metaverse compatibility](#cross-metaverse-compatibility)
- [Multi-media output](#multi-media-output)
- [Media redundancy](#media-redundancy)

### Cross-metaverse compatibility

The proposal can support any number of different implementations.

Cross-metaverse compatibility could also be referred to as cross-engine compatibility. An example is where a cosmetic item for game A is unavailable in game B because the frameworks are incompatible.

Such Tokens can be given further utility through new assets: more games, cosmetic items, and more.

The following is a more concrete example. One asset is a cosmetic item for game A, a file containing the cosmetic assets. Another is a cosmetic asset file for game B. A third is a generic asset intended to be shown in catalogs, marketplaces, portfolio trackers, or other generalized Token Collection viewers, containing a representation, stylized thumbnail, and animated demo/trailer of the cosmetic item.

This EIP adds a layer of abstraction, allowing game developers to pull asset data from a user's Tokens directly instead of hard-coding it.

### Multi-media output

Tokens of an eBook can be represented as a PDF, MP3, or some other format, depending on what software loads it. If loaded into an eBook reader, a PDF should be displayed, and if loaded into an audiobook application, the MP3 representation should be used. Other metadata could be present in the Tokens (perhaps the book's cover image) for identification on various marketplaces, Search Engine Result Pages (SERPs), or portfolio trackers.

### Media redundancy

Many Tokens are minted hastily without best practices in mind. Specifically, many Tokens are minted with metadata centralized on a server somewhere or, in some cases, a hardcoded IPFS gateway which can also go down, instead of just an IPFS hash.

By adding the same metadata file as different assets, e.g., one asset of metadata and its linked image on Arweave, one asset of this same combination on Sia, another of the same combination on IPFS, etc., the resilience of the metadata and its referenced information increases exponentially as the chances of all the protocols going down at once become less likely.

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

```solidity
/// @title ERC-7603 Context-Dependent Multi-Asset Tokens, ERC-1155 Execution
/// @dev See https://eips.ethereum.org/EIPS/erc-7603
pragma solidity ^0.8.23;
interface IERC7603 /* is ERC165 */ {
/**
* @notice Used to notify listeners that an asset object is initialised at `assetId`.
* @param assetId ID of the asset that was initialised
*/
event AssetSet(uint64 assetId);
/**
* @notice Used to notify listeners that an asset object at `assetId` is added to token's asset
* array.
* @param tokenId An ID of the token that received a new asset
* @param assetId ID of the asset that has been added to the token's assets array
* @param replacesId ID of the asset that would be replaced
*/
event AssetAddedToToken(
uint256[] tokenId,
uint64 indexed assetId,
uint64 indexed replacesId
);
/**
* @notice Used to notify listeners that token's priority array is reordered.
* @param tokenId ID of the token that had the asset priority array updated
*/
event AssetPrioritySet(uint256 indexed tokenId);
/**
* @notice Sets a new priority array for a given token.
* @dev The priority array is a non-sequential list of `uint16`s, where the lowest value is considered highest
* priority.
* @dev Value `0` of a priority is a special case equivalent to uninitialised.
* @dev Requirements:
*
* - `tokenId` must exist.
* - The length of `priorities` must be equal the length of the assets array.
* @dev Emits a {AssetPrioritySet} event.
* @param tokenId ID of the token to set the priorities for
* @param priorities An array of priorities of assets. The succession of items in the priorities array
* matches that of the succession of items in the array
*/
function setPriority(uint256 tokenId, uint64[] calldata priorities)
external;
/**
* @notice Used to retrieve IDs of assets of given token.
* @dev Asset data is stored by reference, in order to access the data corresponding to the ID, call
* `getAssetMetadata(tokenId, assetId)`.
* @dev You can safely get 10k
* @param tokenId ID of the token to retrieve the IDs of the assets
* @return uint64[] An array of the asset IDs of the given token
*/
function getAssets(uint256 tokenId)
external
view
returns (uint64[] memory);
/**
* @notice Used to retrieve the priorities of the assets of a given token.
* @dev Asset priorities are a non-sequential array of uint16 values with an array size equal to asset
* priorites.
* @param tokenId ID of the token for which to retrieve the priorities of the assets
* @return uint16[] An array of priorities of the assets of the given token
*/
function getAssetPriorities(uint256 tokenId)
external
view
returns (uint64[] memory);
/**
* @notice Used to fetch the asset metadata of the specified token's asset with the given index.
* @dev Can be overridden to implement enumerate, fallback or other custom logic.
* @param tokenId ID of the token from which to retrieve the asset metadata
* @param assetId Asset Id, must be in the assets array
* @return string The metadata of the asset belonging to the specified index in the token's assets array
*/
function getAssetMetadata(uint256 tokenId, uint64 assetId)
external
view
returns (string memory);
}
```

## Rationale

TBD <!-- TODO -->

## Backwards Compatibility

The MultiAsset token standard has been made compatible with ERC-1155 in order to take advantage of the robust tooling available for implementations of ERC-1155 and to ensure compatibility with existing ERC-1155 infrastructure.

## Security Considerations

Needs discussion. <!-- TODO -->

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Loading

0 comments on commit 50686d3

Please sign in to comment.