Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
A major EIP being considered for I* is the partitioned binary tree (PBT): EIP-8297: Partitioned Binary Tree
This replaces the hexary MPT with a binary tree structure that is well-designed with a decade of lessons and thought of what is ideal for Ethereum, including cost savings for provers, adjacent access, VOPS syncing, and other goals.
One very recent feature addition of the PBT that has been under-discussed is the new code storage format. Essentially: contract code will be stored in a separate tree, indexed by codehash.
A major positive consequence of this is that it gives us an opportunity to cleanly solve the long-standing mess that has been Ethereum code delegation.
To recap the status quo:
Contracts have code.
Code can be big, and big code costs a lot of gas to deploy.
To avoid needing individual accounts to re-deploy big code each time, there are delegation patterns, where an account’s code says “read and use the code from address X” instead. The per-user cost then becomes only the fixed-side delegation code, which can be under 100 bytes
In EIP-7702, we added a weird in-protocol enshrined delegation, where a particular 23-byte sequence means “read and use the code from address X” in a particular context.
With general-purpose account abstraction (EIP-8141), there is more demand to make delegation more efficient, upgradeable and legible to the protocol.
Currently, there is a rule that code is immutable: once set to nonzero, it cannot be changed. Delegation (intentionally) provides a way around that. But now there is a new proposal, SETCODEFROM (EIP-8298), that allows a contract to change its code, specifically to set its code to equal the code from another address without paying the cost of fully deploying it (the argument being that it has already been deployed)
Thus, post-Hegota, we will be in a big software engineering mess: there are three ways to deploy big code to an account without paying big-code costs if that code is already onchain: traditional delegation, SETCODEFROM, and 7702 enshrined delegation.
The PBT creates a natural opportunity to clean this up: we can make code hashes the canonical primary way to “point to” a piece of code without paying the state byte costs of directly including the whole thing, and there will be no need for any more complex delegation methods.
Today, there is a long-standing invariant that contract code, once set, is immutable. SETCODEFROM removes this invariant. But with a codehash → code tree, we get the immutability back at a different level: once a particular code hash has been added to the tree, the code hash → code mapping is set in stone and cannot be changed (that’s just hash collision resistance). And so we can get the same safety properties by using codehash as the canonical identifier, and switching from a philosophy of “I’m using code from account X” to “I’m using code with hash Y”.
What does this mean practically?
Option 1: embrace SETCODEFROM as a primary form of delegation
Option 2: make a SETCODEHASH opcode. Pre-I*, make a system contract that anyone can ping to add a mapping of codehash → address, only if that contract does not contain the SETCODEFROM or SETCODEHASH opcode, and have the opcode point to that. In I*, make it work through the tree
Option 3: just have both opcodes?
But in all cases, this is an argument that code mutability of addresses is okay to embrace.
3 posts - 3 participants
Read full topic
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | All Core Devs - Testing (ACDT) #97, Sept 21, 2026 | 0 | 24.61 | 15-09-2026 |
| 2 | All Core Devs - Execution (ACDE) #246, September 24, 2026 | 0 | 17.28 | 14-09-2026 |
| 3 | ERC: AI Agent Proof-of-Safety Attestation & Transaction Guard Standard (IAgentTransactionGuard) | 0 | 15.4 | 13-09-2026 |
| 4 | ERC-8416: Epoch-Based Fixed-Rate Vault | 0 | 31.35 | 14-09-2026 |
| 5 | All Core Devs - Consensus (ACDC) #187, September 17 2026 | 0 | 16.64 | 14-09-2026 |
| 6 | ERC8415-Kit: Reference Implementation Now Public (CC0) | 0 | 13.08 | 17-09-2026 |
| 7 | EIP-8411: Fast Execution Payload Broadcast | 0 | 6.79 | 07-09-2026 |
| 8 | Onchain IP Asset and License Registry | 0 | 8 | 28-09-2026 |
| 9 | All Core Devs - Execution (ACDE) #247, October 8, 2026 | 0 | 15.62 | 28-09-2026 |
| 10 | "Module: A Reusable State-Machine Framework for NFT Capabilities (Ownership Module v0.5 → v1.0)" | 0 | 12.53 | 27-09-2026 |