newsence
來源篩選

EIP-XXXX: Invariant Layout Guard Opcode

Ethereum Magicians

Simple Summary Introduce a protocol-level state safety mechanism through a new opcode. Abstract This EIP introduces a new opcode, MUTABLE , which restricts state changes to an explicitly defined scope. Any attempt to modify state outside the permitted scope MUST cause execution to revert. Motivation Unintended state mutation during execution is a persistent security risk in smart contract systems. This risk is especially pronounced in proxy-based architectures that rely on DELEGATECALL , where the calling contract effectively relinquishes control over which state changes may occur in the callee’s execution context. At the protocol level, there is currently no mechanism to stabilize or constrain state layout during execution. Introducing such a mechanism enables safer composition of contracts, supports future extensibility, and improves overall robustness for an increasingly dynamic Layer 1 ecosystem. At present, there exist contract-level approaches for constraining state mutation, which we refer to as an inner guard. These mechanisms offer strong and programmable protection for explicitly declared locations but fundamentally cannot defend against mutations outside the specified set. Because the number of potentially mutable locations is unbounded, attempting full coverage at the contract level is infeasible under current gas constraints. To achieve comprehensive protection, a complementary outer guard is required. This can only be implemented at the protocol level. By combining an inner guard with the proposed outer guard, contracts can form a robust firewall against unintended or malicious side effects arising from external calls. Example: import "https://github.com/Helkomine/invariant-guard/blob/main/invariant-guard/InvariantGuardInternal.sol"; import "@openzeppelin/contracts/utils/Address.sol"; contract InvariantSimple is InvariantGuardInternal { address owner; // Invariants cannot be applied to mapping with InvariantGuard. mapping(address => uint256) balances; function safeDelegateCall(address target, bytes calldata data) public payable invariantStorage(_getSlot()) { Address.functionDelegateCall(target, data); } function _getSlot() internal pure returns (bytes32[] memory slots) { bytes32 slot; assembly { slot := owner.slot } slots = new bytes32[](1); slots[0] = slot; } } PR: 1 post - 1 participant Read full topic

newsence

EIP-XXXX：不變佈局保護opcode

Ethereum Magicians
17 天前

AI 生成摘要

此以太坊改進提案（EIP）引入了一個新的opcode，MUTABLE，透過將狀態變更限制在明確定義的範圍內，來強制執行協議級別的狀態安全，並撤銷任何未經授權的變更。

EIP-XXXX: 不變量佈局守護操作碼 - EIPs - 以太坊魔法師協會

Simple Summary

A new opcode INVARIANTS is introduced to allow contracts to declare memory regions that must remain unchanged during execution.

Abstract

This EIP proposes a new opcode, INVARIANTS, which allows a contract to specify regions of memory that should not be modified during the execution of a transaction. This provides a mechanism for ensuring that certain critical data structures or state variables remain consistent, enhancing contract security and reliability.

Motivation

Currently, there is no built-in mechanism in the EVM to prevent accidental or malicious modification of specific memory regions during contract execution. This can lead to vulnerabilities where critical data structures are corrupted, resulting in unexpected behavior or security breaches.

The INVARIANTS opcode addresses this issue by allowing contracts to declare certain memory regions as "invariant." Any attempt to write to these regions after the INVARIANTS opcode has been executed will result in a revert. This provides a strong guarantee that the declared memory regions will remain unchanged, improving the overall security and reliability of smart contracts.

Specification

Opcode: INVARIANTS

  • Opcode Number: 0xXX (To be determined)
  • Gas Cost: G_base + G_memory * (number of invariants)
  • Stack Input: offset1, size1, offset2, size2, ..., offsetN, sizeN
  • Stack Output: None
  • Effect: Declares memory regions specified by (offset1, size1), (offset2, size2), ..., (offsetN, sizeN) as invariant. Any subsequent MSTORE, MSTORE8, or MSTORE32 operation that attempts to write to these regions will cause the transaction to revert.

Semantics

The INVARIANTS opcode takes a variable number of arguments from the stack, where each pair of arguments represents the offset and size of a memory region to be protected.

  1. The opcode pops pairs of offset and size values from the stack.
  2. For each pair, it marks the memory region starting at offset with length size as invariant.
  3. Any subsequent MSTORE, MSTORE8, or MSTORE32 operation that attempts to write to any byte within these invariant regions will cause the transaction to revert with an out-of-gas exception.

Error Conditions

  • If the stack does not contain an even number of elements, the transaction reverts with an out-of-gas exception.
  • If any offset or size value is out of bounds (e.g., negative or exceeds the maximum memory size), the transaction reverts with an out-of-gas exception.
  • If any invariant regions overlap, the transaction reverts with an out-of-gas exception.

Rationale

  • Security: The primary motivation is to enhance the security of smart contracts by preventing unintended or malicious modifications to critical memory regions.
  • Reliability: By ensuring that certain data structures remain consistent, the INVARIANTS opcode improves the reliability of smart contracts.
  • Gas Cost: The gas cost is designed to be reasonable, taking into account the computational cost of checking for violations of the invariant regions. The G_memory component scales linearly with the number of invariants to reflect the increased overhead of managing multiple regions.
  • Revert on Violation: Reverting the transaction on violation of an invariant ensures that the state of the blockchain remains consistent and prevents the propagation of corrupted data.

Backwards Compatibility

This EIP introduces a new opcode, which will require a hard fork to implement. Existing contracts will not be affected unless they explicitly use the INVARIANTS opcode.

Security Considerations

  • The INVARIANTS opcode should be used carefully to avoid restricting memory regions that are legitimately modified during contract execution.
  • The gas cost of the INVARIANTS opcode should be carefully considered to prevent denial-of-service attacks.
  • It is important to ensure that the implementation of the INVARIANTS opcode is robust and free from vulnerabilities.

Copyright

Copyright and related rights waived via .