Update EIP-7999: Update eip-7999.md

EIPS/eip-7999.md

@@ -311,7 +311,7 @@ The analysis leads to the following conclusions, all of which apply with increas
 2. The protocol would be best served by taking a single aggregate ETH fee from the user. 
 3. The proposer already considers the aggregate impact when making its inclusion decision. 
 
-Thus, the proposal is that the user specifies a single ETH `max_fee`. The protocol first ensures that the `max_fee` $F$ covers the base fee across gas limits in all dimensions, $F > \sum b_i l_i$, and finally charges the minimum aggregate fee possible. The total fee paid to the protocol is thus the same as in the original multidimensional fee market design. The design is future-proof in that additional dimensions easily are incorporated, retaining the single `max_fee`.
+Thus, the proposal is that the user specifies a single ETH `max_fee`. The protocol first ensures that the `max_fee` $F$ covers the base fee across gas limits in all dimensions, $F > \sum b_i l_i$, and finally charges the minimum aggregate fee possible. The total fee paid to the protocol is thus the same as in the original multidimensional fee market design. The design is future-proof in that additional dimensions can easily be incorporated, retaining the single `max_fee`.
 
 ### Priority fee
 
@@ -362,9 +362,9 @@ The latter rationale also motivates the specific parameterization chosen. The EI
 
 #### Relationship to previous EIPs and other resources
 
-We acknowledge that calldata already has been limited by EIP-7623, with further repricings proposed in [EIP-7976](./eip-7976.md). These EIPs limit worst-case block sizes by metering and conditionally pricing calldata at the transaction level as opposed to at the block level, having the calldata price vary with a transaction's execution usage. This may lead to secondary markets if users wish to combine different transactions to take advantage of the "rebate" on calldata when consumed together with EVM gas. Treating calldata as a separate resource with a price based on block usage would allow for a more precise control over usage, and transactors would not need to interact with a secondary market to achieve the best price. 
+We acknowledge that calldata already has been limited by EIP-7623, with further repricings proposed in [EIP-7976](./eip-7976.md). These EIPs limit worst-case block sizes by metering and conditionally pricing calldata at the transaction level as opposed to at the block level, having the calldata price vary with a transaction's execution usage. This may lead to secondary markets if users wish to combine different transactions to take advantage of the "rebate" on calldata when consumed together with EVM gas. Treating calldata as a separate resource with a price based on block usage would allow for more precise control over usage, and transactors would not need to interact with a secondary market to achieve the best price. 
 
-Given that the EIP-7623 design already achieves calldata moderation, it must be remembered that an individual fee market for calldata would merely be a first step toward a multidimensional fee market. Calldata is not an endgame. It is likely best to transition over several hard forks, and the options available at the present must then be considered, which leads to a focus on calldata. Another present consideration is block level access lists (BALs) and their interaction. 
+Given that the EIP-7623 design already achieves calldata moderation, it must be remembered that an individual fee market for calldata would merely be a first step toward a multidimensional fee market. Calldata is not an endgame. It is likely best to transition over several hard forks, and the options available at present must then be considered, which leads to a focus on calldata. Another present consideration is block level access lists (BALs) and their interaction. 
 
 A resource such as state is more attractive to separate than calldata. We could achieve exact control over state growth, while allowing temporary spikes many times above current gas limits. However, an expansion into other resources requires a multidimensional gas repricing, which has currently not yet been completed. The next section will further discuss remaining complexities of multidimensional EVM gas, and the strategies available for overcoming them.
 
@@ -384,7 +384,7 @@ It is possible to expand into multiple EVM resource dimensions without breaking
 
 #### Transaction types under multiple EVM resources with non-deterministic limits
 
-A key difference between the new and old transaction types is that the old transaction types set only one limit, whereas the new can set several. When adding deterministic resources such as calldata, this is not a concern, because consumption of this resource can be deducted from the user-specified limit as a pre-processing step. But once there is more than one non-deterministic resource—as can be the case when EVM gas is separated into several resources—things get slightly more complicated. If we wish to ensure that old transaction types still can function properly under these circumstances, we must apply the single limit to multiple non-deterministic resources. The following subsections will outline how this can be achieved by aggregating the gas of these separate resources during EVM processing.
+A key difference between the new and old transaction types is that the old transaction types set only one limit, whereas the new ones can set several. When adding deterministic resources such as calldata, this is not a concern, because consumption of this resource can be deducted from the user-specified limit as a pre-processing step. But once there is more than one non-deterministic resource—as can be the case when EVM gas is separated into several resources—things get slightly more complicated. If we wish to ensure that old transaction types still can function properly under these circumstances, we must apply the single limit to multiple non-deterministic resources. The following subsections will outline how this can be achieved by aggregating the gas of these separate resources during EVM processing.
 
 The new transaction type can supply several limits, making expansion into multiple EVM resources more straightforward. However, it turns out that we may also wish to retain the ability of the new transaction type to set a single limit for EVM gas. The reason is that the single limit and aggregate processing facilitates backward compatibility for contracts that rely on gas observability. As previously noted, these contracts must be able to supply subcalls with an aggregate gas stipend, to be counted against any EVM resource. Furthermore, there is an inherent simplicity of the single limit that is not to be discounted.