Add ERC: Consolidated Dynamic Storage (CDS) #774
Conversation
Committing updated header Co-authored-by: Andrew B Coathup <[email protected]>
wisecameron
changed the title
eip-review-bot
changed the title
|
Changes in progress:
Note: I believe the remaining errors are not currently fixable because they relate to the absence of my assets directory in the main branch. If this assumption is incorrect, please let me know and I will adjust immediately. |
* Updated Contract * Significantly Improved Hashing Scheme * New storage-level diagrams * RFC-2119 * memberIndex, entryIndex, safeIndex, stringIndex clarifications * Example use cases * Clear breakdown of the system * Permission management spec
…ta hash calculation.
…ad of packing with data.
|
In progress:
My plan after this upcoming update is to start promoting the ERC more to encourage greater discussion before submitting for the next stage. |
* Motivation * Abstract * Rationale -- focused on clarifying exact technical benefits, exploring advantages more deeply - added standardization, interoperability
|
Current status: setting up a developer group to start encouraging more discussion. I think this concept has a ton of potential but needs to be thoroughly reviewed and optimized because it's a significantly different approach to storage management. |
fix: some typo and style
| The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. | ||
|
|
||
| ### Extendable Structs and Storage Spaces | ||
| - Extendable structs **MUST** leverage dynamic mappings with deterministic field hashes (`keccak256`). |
There was a problem hiding this comment.
Don't bold the uppercase keywords. Just leave them uppercase, but otherwise unadorned.
|  | ||
|
|
||
| The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. | ||
|
|
There was a problem hiding this comment.
I think you could do with a bit more introductory text before jumping straight into requirements. I'm having a bit of a hard time putting the specification into context (though admittedly I'm not a smart contract developer).
There was a problem hiding this comment.
Awesome, yeah considering that a lot of the rationale also needs to be moved, I'll do a significant revision and present the narrative in a more straightforward way. When I initially made this, I was focused too much on the benefits of upgrading storage without re-deployment, when the more fundamental benefit behind all of this is that it's a standardized, holistic approach to storage management in general. Tertiary benefits like in-place upgradeability, standardized access patterns, etc are all within that fundamental basis, but I don't really communicate this in the proposal.
| `A`, `B`, `C` hash offset structure not only allows CDS to functionally guarantee safety from collisions, but also aid in debugging by | ||
| allowing maintainers to instantly track the high-level objective of complex storage operations. | ||
|
|
||
| **Metadata Root:** |
There was a problem hiding this comment.
Re: introductory text, you definitely need some here. You're jumping straight into Yul.
| The `init_create` function **MUST** handle storage space creation in both an initialization and live extension setting. The function **MUST** take an array of types and sizes as input, which **MUST** conform to the above specifications, and be equivalent in length when input. Developers **MUST** include length equivalency validation for `types` and `sizes`. | ||
|
|
||
| ```solidity | ||
| function init_create( |
There was a problem hiding this comment.
You should move implementations into the reference implementation section (unless there is exactly one possible implementation). The specification section should define the observable behavior of an implementation, not the internals of how it works.
| Proxy-Delegate and Diamond Storage architectures have long been the industry standard for upgradeable smart contracts, providing critical mechanisms for separating logic from state. These approaches have enabled modular contract upgrades, mitigated contract size limitations, and allowed systems to evolve over time. However, as protocols scale, new challenges emerge—managing storage across multiple contracts, coordinating upgrades, and ensuring compatibility without introducing technical debt or unnecessary redeployments. | ||
|
|
||
| CDS builds upon these established patterns by introducing a dedicated, structured storage layer that eliminates many of the complexities inherent in Proxy-Delegate and Diamond architectures. In traditional models, storage modifications require careful slot management, pre-planning reserved fields, or governance-heavy migrations to maintain compatibility. These constraints impose operational overhead and increase the risk of misalignment between logic and storage. CDS removes these limitations by enabling in-place schema evolution, ensuring that storage structures expand deterministically without slot corruption, ABI misalignment, or redundant redeployments. | ||
|
|
||
| One of the key improvements CDS introduces is standardized storage access across contracts. Whereas Proxy-Delegate and Diamond models require each contract to define its own storage mappings, CDS provides a shared, structured interface that multiple contracts can access consistently. This reduces cross-contract storage fragmentation, simplifies state synchronization, and eliminates the inefficiencies of multi-hop storage dependencies and redundant mappings. | ||
|
|
||
| Furthermore, CDS is designed with long-term system maintainability in mind. As protocols expand, managing state across interdependent contracts becomes increasingly complex. CDS mitigates these risks by externalizing structured storage into a permissioned, extendable layer, ensuring that high-throughput contract interactions remain efficient even as ecosystems grow in scale and complexity. | ||
|
|
||
| Proxy-Delegate and Diamond architectures remain valuable for many upgradeable contract designs, offering modularity and logic flexibility. However, for protocols requiring sustainable long-term upgradeability, efficient cross-contract storage, and deterministic schema evolution, CDS provides a more scalable and future-proof alternative. By eliminating migration risks and reducing upgrade complexity, CDS ensures storage integrity, seamless interoperability, and efficient state management—empowering developers to focus on core logic rather than maintenance overhead. |
There was a problem hiding this comment.
Almost all of this belongs in the Motivation section, because it's justifying the proposal as a whole. The Rationale section is for explaining choices made within the document itself. My favorite analogy is:
Motivation: We need to build a shed because...
Rationale: We chose to paint the shed red because...
|
@SamWilsn Thank you so much for the thorough review, I sincerely appreciate it and will be sure to implement your recommendations, along with some additional points from the EM discussion. As an aside, to record where this proposal is, I'm currently building out a lot of external infrastructure (ie; builder's docs, contributor program) around this and HoneyBadger (which is an extended ERC-7844 implementation). So there will likely be some delay as I'm setting all of this up, but this proposal is still very active. |
Co-authored-by: Sam Wilson <[email protected]>
Co-authored-by: Sam Wilson <[email protected]>
Co-authored-by: Sam Wilson <[email protected]>
…ERCs into wisecameron/erc-cds
… architecture diagram)
|
The commit 9c33747 (as a parent of 93185ba) contains errors. |
Reference implementation:
https://github.com/wisecameron/ConsolidatedDynamicStorage/blob/main/contracts/CDSMinimal.sol