Add EIP: Restricted Behavior Transaction Type

EIPS/eip-7906.md

@@ -0,0 +1,272 @@
+---
+eip: 7906
+title: Restricted Behavior Transaction Type
+description: A transaction type that provides a way for senders to restrict the outcomes of their execution
+author: Alex Forshtat (@forshtat), Shahaf Nacson (@shahafn), Dror Tirosh (@drortirosh)
+discussions-to: https://ethereum-magicians.org/t/eip-restricted-behavior-transaction-type/23130
+status: Draft
+type: Standards Track
+category: Core
+created: 2025-02-21
+---
+
+## 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.
+These protected transactions empower Ethereum users to restrict the behavior of the deployed on-chain smart contracts without needing to perform a deep analysis of the EVM code.
+
+## Motivation
+
+The total value of crypto assets that have been stolen to date allegedly exceeds the yearly GDP of a medium-sized nation.
+This level of loss and waste is indefensible and has a long list of negative consequences for everyone involved.
+
+Specifically, one of the major ways in which Ethereum users end up losing their funds is not exposing private keys,
+but instead being tricked into signing transactions that appear innocent in their Wallet applications but in practice
+perform a complete sweep of the senders' assets.
+
+This situation is largely a result of two factors and must be addressed urgently.
+
+First, the ability of an average user to find, review, and analyze the code the transaction will execute is very limited.
+Second, the ability of a Wallet application to autonomously and reliably analyze this information is even more limited.
+
+This means that users have no mechanism to enforce any limits on what transactions will actually do once they are signed,
+and leaves a vast majority of users forced to perform blind signing in order to interact with Ethereum,
+exposing them to significant and avoidable risks.
+
+Existing transaction types in Ethereum only define 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.
+
+By providing the Wallets and dApps with the ability to restrict the possible **outcomes** of a transaction,
+we can create a tool that users and wallets will apply to reduce their risk levels.
+
+## Specification
+
+### New Transaction Type
+
+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])
+```
+
+### Execution Restrictions
+
+There are a number of parameters that constitute the core of the transaction's execution restriction.
+These parameters are joined together and RLP encoded as part of the transaction payload.
+There are no additional costs associated with providing this parameter other than its gas cost equivalent to `calldata`.
+
+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.
+
+#### Storage Altering Operations
+
+The term "permitted operation" is defined as follows:
+
+* `READ` - read-only access to the given slot
+* `DECREASE` - read and decrease a value in the given slot
+* `INCREASE` - read and increase a value in the given slot
+* `DELTA` - read and either `INCREASE` or `DECREASE` a value in the given slot
+* `WRITE` - any storage read or write operation in the given slot
+* `TRANSIENT_WRITE` - any storage read or write operation in the given slot is allowed **during** the execution, but must remain unchanged as a result of the transaction
+
+For the `DELTA`, `INCREASE`, and `DECREASE` the value stored in the slot MUST be treated as an unsigned integer value.
+
+#### Explicitly Permitted Operations
+
+By default `RESTRICTED_EXECUTION_TX_TYPE` transactions are not permitted to perform the following operations:
+
+1. Modifying any account's `balance`
+2. Modifying any account's storage slots
+3. Executing any of the [Opcodes Restricted by Default](#opcodes-restricted-by-default)
+
+The `permitted_operations` field provides a description of what operations are permitted as part of the transaction's execution.
+The operations described by this field are permitted for the specified addresses.
+
+##### Wildcard Permitted Operation
+
+Providing the special value `[0x0000000000000000000000000000000000000000, [], []]` indicates that all
+operations are permitted for all addresses not explicitly mentioned in either the [Explicitly Permitted Operations](#explicitly-permitted-operations) or [Explicitly Banned Operations](#explicitly-banned-operations) lists.
+
+#### Explicitly Banned Operations
+
+The term "banned operation" is defined as follows:
+
+* `ANY` - **any** read and write access to the given slot
+* `DECREASE` - decrease of a value in the given slot
+* `INCREASE` - increase of a value in the given slot
+* `WRITE` - write access to the given slot
+
+Unlike the `permitted_operations`, all `INCREASE` and `DECREASE` operations are banned regardless of the amount the value changes.
+There is no `DELTA` operation defined for the banned operations.
+
+In case there is a conflict between a permit list and a ban list, the **ban list takes precedence**, and the transaction MUST **revert** upon violation.
+
+#### Opcodes Restricted by Default
+
+The following opcodes have non-local effects and their applications are restricted by `RESTRICTED_EXECUTION_TX_TYPE` by default:
+
+* `SELFDESTRUCT` (`0xFF`)
+* `DELEGATECALL` (`0xF4`)
+* `CALLCODE` (`0xF2`)
+* `STATICCALL` (`0xFA`)
+* `CALL` (`0xFA`)
+* `CREATE` (`0xF0`)
+* `CREATE2` (`0xF5`)
+* `LOG` (`0xA0`)
+* `LOG1` (`0xA1`)
+* `LOG2` (`0xA2`)
+* `LOG3` (`0xA3`)
+* `LOG4` (`0xA4`)
+
+Additionally, we introduce special values for non-opcode-based restrictions:
+
+* 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`
+
+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 MUST return 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]], []],
+  ]
+)
+```
+
+## Rationale
+
+### Explicitly Banned Operations Rationale
+
+In general, providing this value should be less preferable compared to making transactions with only a list of explicitly permitted operations and an outright ban on any other access.
+
+This, however, is not practical with the current diversity of pre-existing smart contracts.
+The transaction's execution path may depend on any number of external factors and the inconvenience of using sporadically reverting `RESTRICTED_EXECUTION_TX_TYPE` would outweigh the security benefits.
+
+The task of preparing the Execution Restrictions largely belongs to the dApp itself.
+
+### New `TXRESTRICTHASH` opcode
+
+With the growing adoption of Account Abstraction, it is important to expose the `execution_restrictions` value to the Smart Contract Wallets.
+
+## Backwards Compatibility
+
+This proposal describes a new transaction type that should not affect the functionality of existing systems.
+
+However, providing strict Execution Restrictions for transactions using smart contracts with multiple possible branching execution paths will result in unpredictable reverts.
+
+This proposal does intentionally attempt to create pressure on smart contract developers to create well-structured, linear execution flows for their users.
+
+## Security Considerations
+
+### Correct Wallet UI presentation
+
+The success of the `RESTRICTED_EXECUTION_TX_TYPE` transaction initiative lies in the wallet's ability to correctly
+understand and present the restrictions they are imposing on the transaction to the users.
+
+Wallets will need to be able to understand the meaning of the slots and operations being permitted by the transaction.
+This requires wallets to be aware of all major ERC standards, such as [ERC-20](./eip-20.md) and [ERC-721](./eip-721.md).
+In many cases, this also requires the wallets to be able to fetch and analyze the source code of the executed contracts.
+
+However, the introduction of the `execution_restrictions` parameter to transactions significantly streamlines the process by removing the need for a deep understanding of the executed code.
+Instead, only high-level information about the storage slots' meaning is required for a clear and safe representation of possible transaction outcomes.
+
+Note that for transactions involving operations that the wallet is not able to fully "understand", the user will still be asked to sign on an opaque set of changes.
+This is still an improvement from the "blind signing" of today by allowing an explicit ban on accessing certain balances or opcodes.
+
+### Insufficiently Restrictive Transactions
+
+The worst outcome of introducing a security feature is creating a false sense of security for its user.
+
+Wallets are expected to provide the banned operations list in a way that protects their users' valuable assets.
+
+It is critical that dApps, wallets, and users become educated about the consequences of not limiting their transactions' execution with sufficient strictness.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).