From f4d379a230ab781c07e7eed3f0eb5c454740db20 Mon Sep 17 00:00:00 2001 From: Cameron Warnick Date: Wed, 18 Dec 2024 17:13:57 -0800 Subject: [PATCH] Minor adjustments to content --- ERCS/erc-7844.md | 51 ++++++++++++++++++++++++------------------------ 1 file changed, 26 insertions(+), 25 deletions(-) diff --git a/ERCS/erc-7844.md b/ERCS/erc-7844.md index d603f3730e..e9817faed6 100644 --- a/ERCS/erc-7844.md +++ b/ERCS/erc-7844.md @@ -310,12 +310,12 @@ In short, CDS trades initial complexity for **long-term efficiency, safety, and **Why Use CDS When Diamond Storage Exists?** -The **Diamond Standard ([ERC-2535](https://eips.ethereum.org/EIPS/eip-2535))** modularizes smart contract logic elegantly, but retains a rigid storage model. While facets can be upgraded post-deployment, **the storage layout itself remains static**. To mirror the capabilities of CDS, the Diamond storage layer would require its own proxy-delegate solution up-front. Developers would need to swap the diamond delegate, then re-connect all of its linked contracts. *In a production environment, this process represents both cost and risk.* +The **Diamond Standard ([ERC-2535](https://eips.ethereum.org/EIPS/eip-2535))** modularizes smart contract logic elegantly, but retains a rigid storage model. While facets can be upgraded post-deployment, **the storage layout itself remains static**. To mirror the capabilities of CDS, a Diamond storage layer would require its own proxy-delegate solution up-front. Developers would need to swap the diamond delegate, then re-connect all of its linked contracts. *In a production environment, this process represents both cost and risk.* Additionally, this approach further exacerbates the *spiderweb contract structure*. ## Backwards Compatibility -This ERC introduces a new design pattern and does not interfere with existing Solidity implementations. CDS *does* *not* implicitly interfere with common libraries such as those provided by OpenZeppelin, but is not supported explicitly. Library-imposed global data within linked contracts leveraging +This ERC introduces a new design pattern and does not interfere with existing Solidity implementations. CDS *does* *not* implicitly interfere with common libraries such as those provided by OpenZeppelin, but is not supported explicitly. Library-imposed global data within CDS-linked contracts can be a problem. The ideal approach is to use lightweight libraries and to avoid mapped data in CDS-linked contracts whenever possible. ## **Test Cases** @@ -323,52 +323,53 @@ This ERC introduces a new design pattern and does not interfere with existing So - **Initialization** - Input: `types = [1, 3, 6], sizes = [32, 8, 128]`. - - Expected: Storage space initialized with 3 members. + - Expected: Storage space initialized with 3 members. - **Insert New Members** - Input: `insert_new_member(1, 128, storageSpace = 0)`. - - Expected: New `uint128` member added with correct `bitCount`. + - Expected: New `uint128` member added with correct `bitCount`. - **Data Storage and Retrieval** - Input: `put(42, memberIndex = 0, entryIndex = 0, storageSpace = 0)` → `get(0, 0, 0)`. - - Expected: `42`. + - Expected: `42`. ### **2. Edge Cases** - **String Handling** - Input: Insert five strings consecutively. - - Expected: No collisions; strings retrieved accurately. + - Expected: No collisions; strings retrieved accurately. - Input: insert two dynamic strings, then one uint256 - - Expected: uint256 is properly configured with: - `bitCount == 0` - because: - `safeIndex == 0` maps to the dynamic string with index 0. This zero value fills both decoded `{type, size}` slots in the standard type construction logic. Hence, we begin with a valid bitCount of 0. + - Expected: uint256 is properly configured with: + `bitCount == 0` + because: + `safeIndex == 0` maps to the dynamic string with index 0. This zero value fills both decoded `{type, size}` slots in the standard type construction logic. Hence, we begin with a valid bitCount of 0. - **Entry Creation** - Input: Add 10,000 entries to a storage space with `pushMany`. - - Expected: System can store to any of these entry indices. + - Expected: System can store to any of these entry indices. - **Invalid Input** - Input: `put(42, memberIndex = 1, storageSpace = 0)`. - - Expected: Reverts with error. + - Expected: Reverts with error. * Input: `put("42", memberIndex = 1, entryIndex = 0, storageSpace = 0)`. - - Expected: Reverts with error. + - Expected: Reverts with error. - Input: `put_string(42, memberIndex = 1, entryIndex = 0, storageSpace = 0)`. - - Expected: Reverts with error. + - Expected: Reverts with error. -## Gas Benchmarks (HoneyBadger) +## Gas Benchmarks -* This section assumes that storage operations interact with pre-populated slots. -* Displayed values reference *execution* cost. +* This section assumes that storage operations interact with pre-populated slots. +* These values are derived from the optimized HoneyBadger model and serve as good targets for efficiency. +* Displayed values reference *execution* cost. - `init_create([1], [256]):` 93,860 gas - `init_create([1,1,1], [8,256,256]):` 140,024 gas - `insert_new_member:` 40,653 gas - `push:` 10,316 gas - `put:` 15,543 gas - `put_batch([20, 20], [0, 1], 0, 0):` 22,895 gas - `get`: 9374 gas + `init_create([1], [256]):` 93,860 gas + `init_create([1,1,1], [8,256,256]):` 140,024 gas + `insert_new_member:` 40,653 gas + `push:` 10,316 gas + `put:` 15,543 gas + `put_batch([20, 20], [0, 1], 0, 0):` 22,895 gas + `get`: 9374 gas ## Reference Implementation @@ -383,7 +384,7 @@ While a CDS implementation imposes considerable overhead in terms of up-front ef **Access Control** It is highly recommended to fully lock the system with a permission management scheme. The most basic example would be to use a `mapping(address -> boolean) hasPerms` with a related modifier. Users who lack authorization should never have direct access to the system, including view functions. In the case of views, we prevent access because there is no need for non-users to have insight into your storage space scheme. It is recommended to use an abstraction layer via an additional contract to ensure that this information is abstracted away, and that users can't pry into data they shouldn't have access to. -**Types and Sizes** Types and sizes also represent an important vulnerability point. It is crucial to verify that types are within bounds, and to thoroughly verify that values conform to expected size(s). It is best practice to revert when encountering an incorrect size (ie; boolean, size 16) rather than correcting it in-place. +**Types and Sizes** Types and sizes also represent an important vulnerability point. It is crucial to verify that types are within bounds, and to thoroughly verify that entries conform to expected size(s). It is best practice to revert when encountering an incorrect size (ie; boolean, size 16) rather than correcting it in-place. ## Copyright