Minor adjustments to content

ERCS/erc-7844.md

@@ -310,65 +310,66 @@ 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**
 
 ### **1. Core Functionality**
 
 - **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