Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
Abstract
This is a draft conceptualization meant to initialize a discussion on what I believe is a necessary evolution for EVM security. The goal is to introduce a standardized “Security Manifest” for smart contracts, coupled with a specialized mempool admission policy.
To be clear: this is a general idea. I am putting this forward to start the conversation, not to present a finalized specification. However, the premise is direct: we might need an infrastructure-layer gatekeeper that prevents zero-day exploits by enforcing intended contract behavior before execution.
Motivation
Currently, smart contract security relies entirely on execution-time logic (bounded by gas and block limits) or off-chain monitoring (often too late). Recent proposals like EIP-7906 (Transaction Assertions) are excellent, but they are user-side protections (e.g. slippage/state-diff limits). They do not protect the smart contract itself from an attacker.
I want to hit the obvious roadblocks first so we can move past them: I know L1 nodes cannot natively run non-deterministic AI or heavy heuristics without breaking consensus. Therefore, this proposal does not suggest putting AI inside Geth/Reth. Instead, it proposes a network-level standard to bridge off-chain threat analysis with on-chain mempool admission.
Proposed Architecture (High-Level)
The Manifest Standard: Contracts expose a standardized URI detailing normal parameters, state boundaries, and restricted modifications.
The Pre-Mempool Routing: Transactions targeting protected contracts are gossiped to a specialized builder network or pre-mempool.
Heuristic / AI Validation: Nodes within this specialized network run advanced non-deterministic checks (AI/ML threat modeling) against the transaction payload using the contract’s manifest.
Standard Mempool Admission: If deemed safe, the transaction is wrapped with a cryptographic proof (e.g., zkML) or a committee signature. The L1 node simply verifies this lightweight proof/signature before accepting it. Gas costs for verification are paid by the sender.
How the Manifest Should Look (Draft Concept)
The manifest should be an immutable document (on-chain or hosted on IPFS/Arweave to avoid content modiification without notice) referenced or accesible on-chain via a standardized function, such as securityManifestURI().
Format: A standardized JSON or YAML schema.
Content: It should act as an extension of the ABI, defining strict pre- and post-conditions. It would outline:
Acceptable input ranges (e.g., “Function X should never receive a uint256 larger than Y”).
State invariants (e.g., “The sum of all balances must strictly equal totalSupply”).
Behavioral anomalies (e.g., “A single transaction should not drain more than 10% of the TVL”).
Language: Ideally, it maps closely to existing invariant-testing syntax (like Halmos or Foundry’s forge test invariant structures) so developers can easily translate their local test constraints into a live network firewall.
Addressing the Elephant in the Room (Trade-offs & Attack Vectors)
I want to pre-emptively address the trade-offs, because I am aware that adding a security layer inherently adds a new attack vector.
Non-Retroactive: This specification cannot and should not be retroactive. You cannot arbitrarily attach a manifest to an existing, non-upgradeable contract to change its behavior. This must be an opt-in standard for new deployments or specific upgrade paths.
The “Malicious Admin” Vector: The typical question is: “What happens if an admin updates the manifest maliciously to censor users or brick the contract?” The answer is: The exact same thing that happens if an admin maliciously updates an ERC-1967 proxy implementation. Yes, it requires trust in the upgrade keys. This is simply a new flavor of the exact same trade-off we already accept with proxies.
Auditability: Because a malicious manifest could cause false positives (or intentional denial of service), the manifest is code. It must be audited exactly like the Solidity smart contract it protects.
Used maliciously, it’s a censorship tool. Used correctly, the win is staggering: developers would no longer need to rely purely on flawless formal verification or fear unpredictable edge-case attacks, because the infrastructure itself refuses to route transactions that violate the contract’s fundamental physics.
Open Questions for the Community
Mempool Gossip Rules: Should this be handled by a new EIP-2718 transaction type that requires a generic “validity proof” field, or handled entirely out-of-protocol by MEV-Boost builders?
L2 First? While the ultimate goal is EVM-wide infrastructure, would it make more sense to standardize this specifically for L2 Sequencer implementations first (similar to how Zircuit approaches sequencer-level quarantine)?
I look forward to the community’s brutal honesty and constructive ideas to refine this conceptualization.
1 post - 1 participant
Read full topic
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | ERC-8354: Confidential Agent Policy Verdicts | 0 | 12.87 | 24-07-2026 |
| 2 | ERC-8343: Contract Deactivation | 0 | 15.62 | 21-07-2026 |
| 3 | EIP-8337: Validated EVM Code | 0 | 6.96 | 14-07-2026 |
| 4 | Encrypt The Mempool #7, July 22, 2026 | 0 | 25.23 | 20-07-2026 |
| 5 | Timelock Account recovery: A trust minimized recovery system for Smart Accounts | 0 | 6.22 | 14-07-2026 |
| 6 | Cohort Order Book: an O(1) fully on-chain limit order book via generational fungible liquidity | 0 | 12.86 | 15-07-2026 |
| 7 | ERC-8349: Index-Based Multi-Facet Proxy | 0 | 10.21 | 21-07-2026 |
| 8 | ERC-XXXX: NFT-Bound Prediction Markets (LMSR pricing, on-chain state) | 0 | 15.86 | 21-07-2026 |
| 9 | EIP-8341: Partial Execution Payload Commitments | 0 | 18.4 | 17-07-2026 |
| 10 | ERC-TBA: Prediction Market CTF Wrapper | 0 | 11.4 | 27-07-2026 |