diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 5f31c5916dc50..ebec1036d1bf5 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -290,6 +290,42 @@ Permitted WHATWG specification URLs must anchor to a specification defined in th Although not recommended by WHATWG, EIPs must anchor to a particular commit so that future readers can refer to the exact version of the living standard that existed at the time the EIP was finalized. This gives readers sufficient information to maintain compatibility, if they so choose, with the version referenced by the EIP and the current living standard. +### Internet Engineering Task Force (IETF) + +Links to an IETF Request For Comment (RFC) specification may be included using normal markdown syntax, such as: + +```markdown +[RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) +``` + +Which renders as: + +[RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) + +Permitted IETF specification URLs MUST anchor to a specification with an assigned RFC number (meaning cannot reference internet drafts), and so MUST match this regular expression: + +```regex +^https:\/\/www.rfc-editor.org\/rfc\/.*$ +``` + +### Bitcoin Improvement Proposal + +Links to Bitcoin Improvement Proposals may be included using normal markdown syntax, such as: + +```markdown +[BIP 38](https://github.com/bitcoin/bips/blob/3db736243cd01389a4dfd98738204df1856dc5b9/bip-0038.mediawiki) +``` + +Which renders to: + +[BIP 38](https://github.com/bitcoin/bips/blob/3db736243cd01389a4dfd98738204df1856dc5b9/bip-0038.mediawiki) + +Permitted Bitcoin Improvement Proposal URLs must anchor to a specific commit, and so must match this regular expression: + +```regex +^(https://github.com/bitcoin/bips/blob/[0-9a-f]{40}/bip-[0-9]+\.mediawiki)$ +``` + ### Digital Object Identifier System Links qualified with a Digital Object Identifier (DOI) may be included using the following syntax: diff --git a/EIPS/eip-6093.md b/EIPS/eip-6093.md index b5fce6869f2de..e82cc65cfed59 100644 --- a/EIPS/eip-6093.md +++ b/EIPS/eip-6093.md @@ -32,9 +32,9 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S The following errors were designed according to the criteria described in [Rationale](#rationale). -This EIP defines standard errors that may be used by implementations in certain scenarios, but does not specify whether implementations should revert in those scenarios, which remains up to the implementers, unless a revert is mandated by the corresponding EIPs. +This EIP defines standard errors that may be used by implementations in certain scenarios but it does not specify whether implementations should revert in those scenarios, which remains up to the implementers unless a revert is mandated by the corresponding EIPs. -The names of the error arguments are defined in the [Parameter Glossary](#parameter-glossary), and MUST be used according to those definitions. +The names of the error arguments are defined in the [Parameter Glossary](#parameter-glossary) and MUST be used according to those definitions. ### [ERC-20](./eip-20.md) @@ -43,15 +43,18 @@ The names of the error arguments are defined in the [Parameter Glossary](#parame Indicates an error related to the current `balance` of a `sender`. Used in transfers. -- MUST be used when `balance` is less than `needed`. -- MUST NOT be used if `balance` is greater than or equal to `needed`. +Usage guidelines: + +- `balance` MUST be less than `needed`. #### `ERC20InvalidSender(address sender)` Indicates a failure with the token `sender`. Used in transfers. -- MUST be used for disallowed transfers from the zero address. +Usage guidelines: + +- RECOMMENDED for disallowed transfers from the zero address. - MUST NOT be used for approval operations. - MUST NOT be used for balance or allowance requirements. - Use `ERC20InsufficientBalance` or `ERC20InsufficientAllowance` instead. @@ -61,8 +64,10 @@ Used in transfers. Indicates a failure with the token `receiver`. Used in transfers. -- MUST be used for disallowed transfers to the zero address. -- MUST be used for disallowed transfers to non-compatible addresses (eg. contract addresses). +Usage guidelines: + +- RECOMMENDED for disallowed transfers to the zero address. +- RECOMMENDED for disallowed transfers to non-compatible addresses (eg. contract addresses). - MUST NOT be used for approval operations. #### `ERC20InsufficientAllowance(address spender, uint256 allowance, uint256 needed)` @@ -70,15 +75,18 @@ Used in transfers. Indicates a failure with the `spender`'s `allowance`. Used in transfers. -- MUST be used when `allowance` is less than `needed`. -- MUST NOT be used if `allowance` is greater than or equal to `needed`. +Usage guidelines: + +- `allowance` MUST be less than `needed`. #### `ERC20InvalidApprover(address approver)` Indicates a failure with the `approver` of a token to be approved. Used in approvals. -- MUST be used for disallowed approvals from the zero address. +Usage guidelines: + +- RECOMMENDED for disallowed approvals from the zero address. - MUST NOT be used for transfer operations. #### `ERC20InvalidSpender(address spender)` @@ -86,34 +94,42 @@ Used in approvals. Indicates a failure with the `spender` to be approved. Used in approvals. -- MUST be used for disallowed approvals to the zero address. -- MUST be used for disallowed approvals to the owner itself. +Usage guidelines: + +- RECOMMENDED for disallowed approvals to the zero address. +- RECOMMENDED for disallowed approvals to the owner itself. - MUST NOT be used for transfer operations. - Use `ERC20InsufficientAllowance` instead. ### [ERC-721](./eip-721.md) -### `ERC721InvalidOwner(address owner)` +#### `ERC721InvalidOwner(address owner)` Indicates that an address can't be an owner. Used in balance queries. -- MUST be used for addresses whose ownership is disallowed (eg. ERC-721 explicitly disallows `address(0)` to be an owner). -- MUST not be used for transfers. +Usage guidelines: + +- RECOMMENDED for addresses whose ownership is disallowed (eg. ERC-721 explicitly disallows `address(0)` to be an owner). +- MUST NOT be used for transfers. - Use `ERC721IncorrectOwner` instead. -### `ERC721NonexistentToken(uint256 tokenId)` +#### `ERC721NonexistentToken(uint256 tokenId)` Indicates a `tokenId` whose `owner` is the zero address. -- MUST be used when attempting to interact with a non-minted or burned token. +Usage guidelines: + +- The `tokenId` MUST BE a non-minted or burned token. #### `ERC721IncorrectOwner(address sender, uint256 tokenId, address owner)` Indicates an error related to the ownership over a particular token. Used in transfers. -- MUST be used when `sender` is not `owner`. +Usage guidelines: + +- `sender` MUST NOT be `owner`. - MUST NOT be used for approval operations. #### `ERC721InvalidSender(address sender)` @@ -121,7 +137,9 @@ Used in transfers. Indicates a failure with the token `sender`. Used in transfers. -- MUST be used for disallowed transfers from the zero address. +Usage guidelines: + +- RECOMMENDED for disallowed transfers from the zero address. - MUST NOT be used for approval operations. - MUST NOT be used for ownership or approval requirements. - Use `ERC721IncorrectOwner` or `ERC721InsufficientApproval` instead. @@ -131,8 +149,10 @@ Used in transfers. Indicates a failure with the token `receiver`. Used in transfers. -- MUST be used for disallowed transfers to the zero address. -- MUST be used for disallowed transfers to non-`ERC721TokenReceiver` contracts or those that reject a transfer. (eg. returning an invalid response in `onERC721Received`). +Usage guidelines: + +- RECOMMENDED for disallowed transfers to the zero address. +- RECOMMENDED for disallowed transfers to non-`ERC721TokenReceiver` contracts or those that reject a transfer. (eg. returning an invalid response in `onERC721Received`). - MUST NOT be used for approval operations. #### `ERC721InsufficientApproval(address operator, uint256 tokenId)` @@ -140,15 +160,19 @@ Used in transfers. Indicates a failure with the `operator`'s approval. Used in transfers. -- MUST be used when operator `isApprovedForAll(owner, operator)` is false. -- MUST be used when operator `getApproved(tokenId)` is not `operator`. +Usage guidelines: + +- `isApprovedForAll(owner, operator)` MUST be false for the `tokenId`'s owner and `operator`. +- `getApproved(tokenId)` MUST not be `operator`. #### `ERC721InvalidApprover(address approver)` Indicates a failure with the `owner` of a token to be approved. Used in approvals. -- MUST be used for disallowed approvals from the zero address. +Usage guidelines: + +- RECOMMENDED for disallowed approvals from the zero address. - MUST NOT be used for transfer operations. #### `ERC721InvalidOperator(address operator)` @@ -156,8 +180,10 @@ Used in approvals. Indicates a failure with the `operator` to be approved. Used in approvals. -- MUST be used for disallowed approvals to the zero address. -- MUST be used for disallowed approvals to the owner itself. +Usage guidelines: + +- RECOMMENDED for disallowed approvals to the zero address. +- The `operator` MUST NOT be the owner of the approved token. - MUST NOT be used for transfer operations. - Use `ERC721InsufficientApproval` instead. @@ -168,15 +194,18 @@ Used in approvals. Indicates an error related to the current `balance` of a `sender`. Used in transfers. -- MUST be used when `balance` is less than `needed` for a `tokenId`. -- MUST NOT be used if `balance` is greater than or equal to `needed` for a `tokenId`. +Usage guidelines: + +- `balance` MUST be less than `needed` for a `tokenId`. #### `ERC1155InvalidSender(address sender)` Indicates a failure with the token `sender`. Used in transfers. -- MUST be used for disallowed transfers from the zero address. +Usage guidelines: + +- RECOMMENDED for disallowed transfers from the zero address. - MUST NOT be used for approval operations. - MUST NOT be used for balance or allowance requirements. - Use `ERC1155InsufficientBalance` or `ERC1155InsufficientApprovalForAll` instead. @@ -186,8 +215,10 @@ Used in transfers. Indicates a failure with the token `receiver`. Used in transfers. -- MUST be used for disallowed transfers to the zero address. -- MUST be used for disallowed transfers to non-`ERC1155TokenReceiver` contracts or those that reject a transfer. (eg. returning an invalid response in `onERC1155Received`). +Usage guidelines: + +- RECOMMENDED for disallowed transfers to the zero address. +- RECOMMENDED for disallowed transfers to non-`ERC1155TokenReceiver` contracts or those that reject a transfer. (eg. returning an invalid response in `onERC1155Received`). - MUST NOT be used for approval operations. #### `ERC1155InsufficientApprovalForAll(address operator, address owner)` @@ -195,14 +226,18 @@ Used in transfers. Indicates a failure with the `operator`'s approval in a transfer. Used in transfers. -- MUST be used when operator `isApprovedForAll(owner, operator, tokenId)` is false. +Usage guidelines: + +- `isApprovedForAll(owner, operator)` MUST be false for the `tokenId`'s owner and `operator`. #### `ERC1155InvalidApprover(address approver)` Indicates a failure with the `approver` of a token to be approved. Used in approvals. -- MUST be used for disallowed approvals from the zero address. +Usage guidelines: + +- RECOMMENDED for disallowed approvals from the zero address. - MUST NOT be used for transfer operations. #### `ERC1155InvalidOperator(address operator)` @@ -210,7 +245,9 @@ Used in approvals. Indicates a failure with the `operator` to be approved. Used in approvals. -- MUST be used for disallowed approvals to the zero address. +Usage guidelines: + +- RECOMMENDED for disallowed approvals to the zero address. - MUST be used for disallowed approvals to the owner itself. - MUST NOT be used for transfer operations. - Use `ERC1155InsufficientApproval` instead. @@ -220,7 +257,9 @@ Used in approvals. Indicates an array length mismatch between `ids` and `values` in a `safeBatchTransferFrom` operation. Used in batch transfers. -- MUST be used only if `idsLength` is different from `valuesLength` +Usage guidelines: + +- `idsLength` MUST NOT be `valuesLength`. ### Parameter Glossary @@ -250,12 +289,12 @@ Considering this, the error names are designed following a basic grammatical str ### Actions and subjects -The main actions that can be performed within a token are: +An error is defined based on the following **actions** that can be performed on a token and its involved _subjects_: - **Transfer**: An operation in which a _sender_ moves to a _receiver_ any number of tokens (fungible _balance_ and/or non-fungible _token ids_). - **Approval**: An operation in which an _approver_ grants any form of _approval_ to an _operator_. -The subjects outlined above are expected to exhaustively represent _what_ can go wrong in a token transaction, deriving a specific error by adding an [error prefix](#error-prefixes). +These attempt to exhaustively represent what can go wrong in a token operation. Therefore, the errors can be constructed by specifying which _subject_ failed during an **action** execution, and prefixing with an [error prefix](#error-prefixes). Note that the action is never seen as the subject of an error. diff --git a/EIPS/eip-6968.md b/EIPS/eip-6968.md new file mode 100644 index 0000000000000..bdb1e0966732a --- /dev/null +++ b/EIPS/eip-6968.md @@ -0,0 +1,94 @@ +--- +eip: 6968 +title: Contract Secured Revenue on an EVM based L2 +description: Contract Secured Revenue on an EVM based L2 +author: Zak Cole , Zak Cole (@zscole), Kevin Owocki , Lightclient +discussions-to: https://ethereum-magicians.org/t/eip-6968-generalized-csr-protocol/14178 +status: Draft +type: Standards Track +category: Core +created: 2023-05-01 +--- + +## Abstract + +Contract Secured Revenue (CSR) allows smart contract developers to claim a percentage of all transaction fees paid by users when interacting with their smart contracts. + +This EIP proposes the introduction of CSR on EVM-based L2s which would provide smart contract developers who deploy on L2s access to revenue streams and/or public goods. + +## Motivation + +Using protocol rewards of an L1 to fund smart contract development would be a big change to the way the current market works. This EIP *does not* advocate for any changes to the existing Ethereum L1. + +This EIP does advocate that L2s could begin to experiment with Contract Secured Revenue as a means of: + +1. creating a new revenue stream for smart contract developers +2. creating a new way of funding public goods +3. creating incentives for developers to deploy their dapps on your network + +## Specification + +### Parameters + +| Constant | Value | +|---|---| +| REVENUE_SHARE_QUOTIENT | 5 | + +### Fee Mechanism + +The current [EIP-1559](./eip-1559.md) fee behavior is modified so that `header.base_fee_per_gas * REVENUE_SHARE_QUOTIENT` per gas is reallocated proportionally, based on gas used, to each contract executed during the transaction. + +Implicitly, this means that no fees are redistributed to externally owned accounts (EOA). + +#### Gas Tracking + +In order to fairly distribute the fee revenue, a new transaction-wide gas tracker is defined. + +When executing a block, maintain a mapping `gas_used_by_address` of `address` to `uint64`. This will track the amount of gas used by each address. For every EVM instruction that does not instantiate a new execution frame (e.g. `CALL`, `CALLCODE`, `DELEGATECALL`, `STATICCALL`, `CREATE`, and `CREATE2`), add the cost of the instruction to the address' current sum in the mapping. + +For EVM instructions which do instantiate new frames, greater care must be taken to determine the cost of the instruction to the calling frame. For simplicity, this cost is defined to be the total cost of the operation minus the amount of gas passed to the child frame. The gas passed to the child frame is determined via [EIP-150](./eip-150.md). The computed cost is added to the address' current sum in the mapping. + +Additionally: + +- If the address does not exist in the mapping, it's total gas used is `0`. +- If the instructions throws an out-of-gas (OOG) error, all remaining gas allocated to execution frame is added to the current total gas used by the address. +- No other exceptional halt adds remaining gas to the counter for the address where the halt occurred. + +#### Setting Revenue Recipient + +Revenue recipients are tracked via a new transaction wide mapping `revenue_recipient` of `address` to `address`. The default value for every key is the key itself. For example, unless set otherwise, the key `0xdead...beef` maps to the value `0xdead...beef`. + +To set a different revenue recipient, a new instruction `SETREVENUERECIPIENT` is introduced with the opcode `0x49`. The operation takes `1` stack element as input and outputs `0` stack elements. + +The `20` least significant bytes of the input stack element is the address of the new revenue recipient for the instruction's caller. The `revenue_recipient` entry is updated to reflect this. + +The instruction costs `3` gas. + +#### Dispersing Revenue + +After a transaction completes, for every element (`addr`, `gas_used`) in `gas_used_by_address`, increase the balance of `revenue_recipient[addr]` by `gas_used * (header.base_fee_per_gas // REVENUE_SHARE_QUOTIENT)` + +## Rationale + +### Tracking Gas Proportionally + +A simpler mechanism would be to send the full transaction revenue to the `to` value of the transaction. This, however, does not accurately reward the composition of many different smart contracts and applications. Additionally, it is not compatible with smart contract wallets which, by definition, are often the first destination of a transaction. + +Maintaining a transaction wide tracker of gas uses makes it possible to distribute revenue to contracts which are genuinely the most utilized. + +### Ephemeral Revenue Recipient Mapping + +Constructing the revenue recipient mapping ephemerally during each transaction appears inefficient on the surface. This value is expected to be relatively static and even if it did need to change, the change could be facilitated by the recipient contract. + +Unfortunately such a change is much more invasive for the EVM. The recipient value would need to be stored somewhere. This would require a modification to the account structure in the state trie. Also, the recipient value would need to be set at some point. This would necessitate either a modification to the `CREATE*` opcodes or a new opcode, similar to `SETREVENUERECIPIENT`, that would be called by initcode to "initialize" the recipient value. + +## Security Considerations + +### Increased Max Block Size/Complexity + +Similar to EIP-1559, we must consider the effects this will have on block size. Depending on the method by which this is implemented, it could increase maximum block size in the event that a significant number of contracts opt-in to CSR. + + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/EIPS/eip-7053.md b/EIPS/eip-7053.md new file mode 100644 index 0000000000000..2daf5d5de54a4 --- /dev/null +++ b/EIPS/eip-7053.md @@ -0,0 +1,117 @@ +--- +eip: 7053 +title: Interoperable Digital Media Indexing +description: Interoperable Indexing of Digital Media on the EVM-compatible Blockchains. +author: Bofu Chen (@bafu), Tammy Yang (@tammyyang) +discussions-to: https://ethereum-magicians.org/t/eip-7053-interoperable-digital-media-indexing/14394 +status: Draft +type: Standards Track +category: ERC +created: 2023-05-22 +--- + +## Abstract + +This EIP proposes an interoperable indexing strategy designed to enhance the organization and retrieval of digital media information across multiple smart contracts and EVM-compatible blockchains. This system enhances the traceability and verification of cross-contract and cross-chain data, facilitating a more efficient discovery of storage locations and crucial information related to media assets. The major purpose is to foster an integrated digital media environment on the blockchain. + +## Motivation + +Given the significant role digital media files play on the Internet, it's crucial to have a robust and efficient method for indexing immutable information. Existing systems encounter challenges due to the absence of a universal, interoperable identifier for digital media content. This leads to fragmentation and complications in retrieving metadata, storage information, or the provenance of specific media assets. The issues become increasingly critical as the volume of digital media continues to expand. + +The motivation behind this EIP is to establish a standardized, decentralized, and interoperable approach to index digital media across EVM-compatible networks. By integrating Decentralized Content Identifiers (CIDs) and Commit events, this EIP puts forward a mechanism enabling unique identification and indexing of each digital media file. Moreover, this system suggests a way for users to access a complete history of data associated with digital media assets, from creation to the current status. This full view enhances transparency, thereby providing users with the necessary information for future interactions with digital media. + +This method creates a common interface that any digital media system can use to provide a standard way of indexing and searching their content. + +|| +|:--:| +| ![](../assets/eip-7053/digital-media-indexing-system-and-metadata-lookup.jpg) | +| Figure 1: Digital Media Indexing Relationships and Lookup | + +This EIP aims to create an interoperable indexing system to associate all data of the same digital content together (Figure 1). This will make it easier for users to find and trust digital media content, and it will also make it easier for systems to share and exchange information about this digital media content. + +## 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. + +### Content Identifier + +Content Identifier in this EIP is the the content address generated by passing the content of a digital media through a cryptographic hash function. Before the indexing process for digital media can begin, it is REQUIRED to generate unique Content Identifiers for each file. This identifier should the same as the Content Identifiers on the decentralized storage, ensuring each identifier provides access to the metadata, media information, and the content file itself. + +### Commit Function + +To index digital media, we shall call the commit function and generate Commit event: + +```solidity +/** + * @notice Emitted when a new commit is made. + * @param recorder The address of the account making the commit. + * @param assetCid The content identifier of the asset being committed. + * @param commitData The data associated with the commit. + */ +event Commit(address indexed recorder, string indexed assetCid, string commitData); + +/** + * @notice Registers a commit for an asset. + * Emits a Commit event and records the block number of the commit in the recordLogs mapping for the provided assetCid. + * @dev Emits a Commit event and logs the block number of the commit event. + * @param assetCid The content identifier of the asset being committed. + * @param commitData The data associated with the commit. + * @return The block number at which the commit was made. + */ +function commit(string memory assetCid, string memory commitData) public returns (uint256 blockNumber); +``` + +## Rationale + +The design decisions in this EIP prioritize the effectiveness and efficiency of the indexing method. To achieve this, Decentralized Content Identifiers (CIDs) are utilized to uniquely identify digital media content across all systems. This approach offers accurate and precise searching of media, along with the following benefits: + +1. Strengthened data integrity: CIDs serve as cryptographic hashes of the content, ensuring their uniqueness and preventing forgery. With the content in hand, obtaining the CID allows for searching relevant information associated with that content. + +2. Streamlined data portability: CIDs enable the seamless transfer of digital media content across different systems, eliminating the need for re-encoding or reconfiguration of protocols. This promotes a more interoperable and open indexing system. For example, in cases where Non-Fungible Tokens (NFTs) are created prior to Commit events, the digital media content can still be indexed by converting the file referenced by the tokenURI using the same mechanism. This conversion process ensures that the digital media content associated with NFT tokens can be indexed with a consistent identification approach. + +## Reference Implementation + +```solidity +// SPDX-License-Identifier: CC0-1.0 +pragma solidity ^0.8.4; + +import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol"; +import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol"; + +contract CommitRegister is Initializable { + using ECDSA for bytes32; + + mapping(string => uint[]) public commitLogs; + + event Commit(address indexed recorder, string indexed assetCid, string commitData); + + function initialize() public initializer {} + + function commit(string memory assetCid, string memory commitData) public returns (uint256 blockNumber) { + emit Commit(msg.sender, assetCid, commitData); + commitLogs[assetCid].push(block.number); + return block.number; + } + + function getCommits(string memory assetCid) public view returns (uint[] memory) { + return commitLogs[assetCid]; + } +} +``` + +## Security Considerations + +When implementing this EIP, it's essential to address several security aspects to ensure the safety and integrity of the digital media index: + +1. Input Validation: Given that commit function accepts string parameters, it's important to validate these inputs to avoid potential injection attacks. Although such attacks are less common in smart contracts than traditional web development, caution should be exercised. + +2. Data Integrity: The commit function relies on CIDs, which are assumed to be correct and point to the right data. It's important to note that this EIP doesn't validate the content behind the CIDs and the commit data, which remains a responsibility of the users or implementing applications. + +3. Event Listening: Systems relying on listening to the Commit events for changes need to be aware of potential missed events or incorrect ordering, especially during periods of network congestion or reorganizations. + +Implementers should consider these security aspects in the context of their specific use case and deployment scenario. It is strongly recommended to perform a comprehensive security audit before deploying any implementation of this EIP to a live network. + + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). diff --git a/assets/eip-7053/digital-media-indexing-system-and-metadata-lookup.jpg b/assets/eip-7053/digital-media-indexing-system-and-metadata-lookup.jpg new file mode 100644 index 0000000000000..8afd23d2c4d9e Binary files /dev/null and b/assets/eip-7053/digital-media-indexing-system-and-metadata-lookup.jpg differ