Add EIP: Restricted Behavior Transaction Type #9476
Conversation
github-actions
bot
added
c-new
File
|
eth-bot
added
e-consensus
eth-bot
changed the title
EIPS/eip-0000.md
Outdated
| @@ -0,0 +1,282 @@ | |||
| --- | |||
| eip: 0000 | |||
There was a problem hiding this comment.
| eip: 0000 | |
| eip: 7906 |
Don't forget to also rename the file!
EIPS/eip-7906.md
Outdated
| ## Abstract | ||
|
|
||
| Historically, transaction payloads in Ethereum only defined their inputs, while the behavior and the outcome of | ||
| transactions is only defined by the code permanently deployed on-chain. | ||
| With the growing complexity of the deployed codebases and the growing monetary value controlled by this code, | ||
| such an approach becomes increasingly more dangerous. | ||
|
|
||
| This proposal, for the first time, allows the transaction payload to define some guardrails, which will empower Ethereum users to restrict the behavior of the deployed on-chain codebases. |
There was a problem hiding this comment.
We should have a concise, short technical summary that captures the essence of what the proposal accomplishes. Currently, it includes too many details about the problem and context, which belong in the Motivation section. Please revise it to focus on the proposal's key purpose (e.g., introducing guardrails for transactions) and its primary benefit (e.g., enhancing security and reducing risks), while avoiding problem details and clearly Communicating the proposal’s core purpose and essence.
EIPS/eip-7906.md
Outdated
| * All opcodes (`0xffff`) - used to explicitly permit or ban all opcodes for an address | ||
| * `CALL` with value (`0xff00`) - used to explicitly permit or ban calls only if they carry a value in native currency | ||
| * Current contract deployment (`0xff01`) - preventing the specified address from having a code inserted in its place | ||
| * Reverted call (`0xff02`) - preventing the specified address from executing any reverted call | ||
|
|
||
| Consequently, all EIPs defining new opcodes must specify whether the opcode should be restricted by default or not. | ||
|
|
||
| ### New opcode `TXRESTRICTHASH` | ||
|
|
||
| With the growing adoption of Account Abstraction, it is important to expose the `execution_restrictions` value | ||
| to the Smart Contract Wallets. | ||
|
|
||
| The new `TXRESTRICTHASH` opcode pushes the following value onto the stack: | ||
|
|
||
| ``` | ||
| keccak256(execution_restrictions) | ||
| ``` | ||
|
|
||
| ### Revert Reason | ||
|
|
||
| When executed in a view mode, a `RESTRICTED_EXECUTION_TX_TYPE` transaction with an `execution_restrictions` violation | ||
| returns with the following revert reason: | ||
|
|
||
| ``` | ||
| error ExecutionRestrictionViolation(address _address, bytes32 _slot, bytes32 _opcode); | ||
| ``` | ||
|
|
||
| Where: | ||
|
|
||
| * `_address` - the violating contract's address | ||
| * `_slot` - the storage slot that has caused a violation, or `0x0` if not slot-related | ||
| * `_opcode` - the exact opcode that has caused the rule violation | ||
|
|
||
| ### RLP-encoding of the "Execution Restrictions" Parameter | ||
|
|
||
| The value of the `execution_restrictions` parameter is expressed as a | ||
| two-element `[permitted_operations, banned_operations]` RLP tuple. | ||
|
|
||
| #### Permitted Operations | ||
|
|
||
| We define the following constants to express various [permitted operations](#storage-altering-operations): | ||
|
|
||
| * `0x00` - permit `READ` operation | ||
| * `0x01` - permit `DECREASE` operation | ||
| * `0x02` - permit `INCREASE` operation | ||
| * `0x03` - permit `DELTA` operation | ||
| * `0x04` - permit `WRITE` operation | ||
|
|
||
| The `DELTA`, `INCREASE`, and `DECREASE` operations are expressed as a two-element `[operation, value]` RLP tuple. | ||
|
|
||
| The `permitted_operations` parameter is represented by an array of the following internal structure: | ||
|
|
||
| 1. Address of an account with explicitly permitted operations. | ||
| 2. Account balance permitted operation type, expressed as `[operation, value]` RLP tuple. | ||
| 3. An array of permitted operations per storage slot. | ||
| If left empty, all slots are permitted for arbitrary read and write. | ||
| If the same slot ID appears multiple types, each operation is permitted for the given slot. | ||
| * Storage Slot Identifier | ||
| * Permitted "operation" | ||
| * Maximum permitted amount (optional) | ||
| 4. An array of explicitly permitted [Restricted Opcodes](#opcodes-restricted-by-default). | ||
|
|
||
| Example of a `permitted_operations` encoding: | ||
|
|
||
| ``` | ||
| rlp( | ||
| [ | ||
| [0xAddress1, [0x01, 0xde0b6b3a7640000], [[0xSlotID1, [0x00]], [0xSlotID2, [0x01]], ["0xF4", "0xF5"]]], | ||
| [0xAddress2, [0x02, de0b6b3a7640000], [0xSlotID, [0x02, 0x777]]], | ||
| [0xAddress3, [], [0xSlotID, [0x00]]], | ||
| ] | ||
| ) | ||
| ``` | ||
|
|
||
| #### Banned Operations | ||
|
|
||
| * `0x00` - ban `ANY` operation | ||
| * `0x01` - ban `DECREASE` operation | ||
| * `0x02` - ban `INCREASE` operation | ||
| * `0x04` - ban `WRITE` operation | ||
|
|
||
| The `banned_operations` parameter is represented by an array of the following internal structure: | ||
|
|
||
| 1. Address of an account with explicitly banned operations | ||
| 2. Account balance banned operation type, expressed as `operation` value. | ||
| 3. An array of banned operations per storage slot. If left empty, all slots are banned for `ANY` operation. | ||
| * Storage Slot Identifier | ||
| * Banned "operation" | ||
| 4. An array of explicitly banned opcodes. May contain any valid opcode value. | ||
|
|
||
| Example of a `banned_operations` encoding: | ||
|
|
||
| ``` | ||
| rlp( | ||
| [ | ||
| [0xAddress1, 0x01, [[0xSlotID1, 0x00], [0xSlotID2, 0x01], ["0xF4", "0xF5"]]], | ||
| [0xAddress2, 0x04, [0xSlotID, 0x02]], []], | ||
| ] | ||
| ) | ||
| ``` |
There was a problem hiding this comment.
Use RFC 2119 keywords (e.g., MUST, SHOULD, MAY) in the Specification section to clearly define enforceable requirements and ensure alignment with EIP guidelines.
For example; "In case any of the specified restrictions is violated, the entire transaction is reverted on-chain and its gas is paid until the point of the restriction violation". Should be - "If any of the specified restrictions are violated, the transaction MUST revert on-chain, and its gas MUST be paid up to the point of the violation".
EIPS/eip-7906.md
Outdated
| With the growing adoption of Account Abstraction, it is important to expose the `execution_restrictions` value | ||
| to the Smart Contract Wallets. |
There was a problem hiding this comment.
This explains more about why certain design choices were made and belongs in the rationale section.
Co-authored-by: Mercy Boma Naps Nkari <[email protected]>
| We introduce a new [EIP-2718](./eip-2718.md) transaction, "restricted execution transaction", where the `TransactionType` is `RESTRICTED_EXECUTION_TX_TYPE` and the `TransactionPayload` is the RLP serialization of the following: | ||
|
|
||
| ``` | ||
| rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, execution_restrictions, signature_y_parity, signature_r, signature_s]) |
There was a problem hiding this comment.
What is authorization_list?
There was a problem hiding this comment.
The EIP-7702 authorization tuples. I followed the naming from the EIP-7702 itself:
The authorization_list is a list of tuples that store the address to code which the signer desires to execute in the context of their EOA. The transaction is considered invalid if the length of authorization_list is zero.
Should I remove the mention of authorization_list from this EIP or provide a link and an explanation of what this value means? I assumed that as EIP-7702 will be part of Ethereum very soon there is no need to re-explain it or "require" it specifically, am I wrong here?
There was a problem hiding this comment.
i think require: 7702 in header sorts of resolve the dependency specification and terminolgy assumption
There was a problem hiding this comment.
please require all the transaction types EIPs you are trying to addess
Co-authored-by: Sam Wilson <[email protected]>
|
The commit 97c8585 (as a parent of 85be0fc) contains errors. |
|
|
||
| ## Abstract | ||
|
|
||
| This proposal allows the transaction payload to define write protections for balances and storage slots that are to be enforced on the consensus level. |
There was a problem hiding this comment.
please don't insert line breaks by yourself unless introducing a new para, html render will auto render as per the screen size. similarly for the entire EIP
|
|
||
| In case any of the specified restrictions is violated, the entire transaction MUST **revert on-chain** and its gas MUST be paid until the point of the restriction violation. | ||
|
|
||
| The transaction is considered to be a valid transaction that can be included in a block and pays its own gas regardless of the contents of the `execution_restrictions` parameter. |
There was a problem hiding this comment.
please specify execution_restrictions grammar upfront and its encoding here
ATTENTION: ERC-RELATED PULL REQUESTS NOW OCCUR IN ETHEREUM/ERCS
--
When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: