fix(docs): grammar and capitalization

content/tutorials/max-gas-pub-data/10.index.md

@@ -25,24 +25,24 @@ ZKSync Era distinguishes between computational costs and pubdata costs.
 
 ## ZKSync Era's Approach to Pubdata Costs
 
-ZKSync Era has developed a special solution for charging pubdata costs in a state diff rollup:
+ZKSync Era has developed a unique solution for charging pubdata costs in a state diff rollup:
 
 1. **Dynamic Pricing**: Pubdata costs are calculated dynamically based on current L1 gas prices.
 2. **Post-Execution Pubdata Charging**: Users are charged for pubdata based on a counter that tracks pubdata
 usage during transaction execution. This includes storage writes, bytecode deployment, and L2->L1 messages.
-The final cost depends on both the amount of pubdata used and the gas price per pubdata unit, which is determined at the time of execution.
+The final cost depends on the amount of pubdata used and the gas price per pubdata unit, which is determined at the time of execution.
 3. **Efficient for Repeated Operations**: Applications that repeatedly modify the same storage slots
 benefit from this model, as they're not charged for each individual update.
 
-## How ZKSync Era Charges for Pubdata (process)
+## How Zksync Era Charges for Pubdata (Process)
 
 ZKSync Era employs a sophisticated method for charging pubdata costs, addressing several challenges inherent to state diff-based rollups:
 
 - **Post-Charging Approach**: Instead of pre-charging for pubdata (which is impossible due to the nature of state diffs),
 ZKSync Era uses a post-charging mechanism.
 - **Pubdata Counter**: ZKSync Era uses a pubdata counter that tracks potential pubdata usage during transaction execution.
-This counter is modified by the operator for storage writes (which can be positive or negative), incremented by system
-contracts for L1 data publication, and can be reverted along with other state changes. The final value of this counter,
+This counter is modified by the operator for storage writes (which can be positive or negative) and incremented by system
+contracts for L1 data publication. The counter can revert along with other state changes. The final value of this counter,
 combined with the gas price per pubdata unit, determines the pubdata cost of the transaction.
   - The system maintains a counter that tracks how much pubdata has been spent during a transaction.
 - **Execution Process**:
@@ -56,44 +56,44 @@ combined with the gas price per pubdata unit, determines the pubdata cost of the
 - **Pubdata Counter Modifications**:
   - Storage writes: The operator specifies the increment for the pubdata counter (can be negative).
   - Publishing bytes to L1: The counter is incremented by the number of bytes published.
-  - Transaction revert: The pubdata counter is reverted along with storage and events.
+  - Transaction revert: The pubdata counter value reverts along with storage and events.
 - **Advantages of Post-Charging**:
   - Removes unnecessary overhead.
   - Decouples execution gas from data availability gas.
-  - Eliminates caps on `gasPerPubdata`.
+  - Eliminates caps on `gasPerPubdata.`
 
 ## Implications for Users and Developers
 
 1. **Cost Predictability**: While costs may vary with L1 gas prices, users can estimate costs based on the state changes their transactions will cause.
-2. **Optimization Opportunities**: Developers can optimize their applications to minimize state changes, potentially reducing costs for users.
+2. **Optimization Opportunities**: Developers can optimize their applications to minimize state changes, potentially reducing users' costs.
 3. **Efficient for Certain Use Cases**: Applications like oracles or high-frequency trading platforms may find this model particularly cost-effective.
 4. **Transaction Behavior**: Users should be aware that transactions may be rejected or reverted based on
 pubdata costs, even if they seem to have sufficient gas for execution.
 5. **Flexible Pricing**: The absence of hard caps on `gasPerPubdata` allows for more flexible pricing models.
 
-In the next section, we'll explore how to measure gas costs and set the DEFAULT_GAS_PER_PUBDATA_LIMIT in ZKSync Era, providing practical insights.
+The following section provides practical insights into measuring gas costs and setting the DEFAULT_GAS_PER_PUBDATA_LIMIT in the ZKSync era.
 
-## Measuring Gas Costs and setting different values for pubdata gas limit
+## Measuring Gas Costs and Setting Different Values for Pubdata Gas Limit
 
-This guide demonstrates how to measure gas costs and set the `DEFAULT_GAS_PER_PUBDATA_LIMIT` in ZKSync Era using a practical
+This guide demonstrates how to measure gas costs and set the `DEFAULT_GAS_PER_PUBDATA_LIMIT` in the ZKSync Era using a practical
 example: a ZKFest Voting Contract. **What is Max Gas Per Pubdata?** Max gas per pubdata is a value attached to each transaction
 on ZKsync Era, representing the maximum amount of gas a user is willing to pay for each byte of pubdata (public data) published on Ethereum.
 
 **Key points:**
 
 1. Default value: 50,000 gas per pubdata byte
-2. Can be customized per transaction, in this case, we’re testing three cases
+2. Can be customized per transaction; in this case, we're testing three cases
 3. Affects transaction success and cost
 
 ## Objective
 
-We'll deploy a smart contract and interact with it using various gas settings to understand how different
-parameters affect transaction execution and costs on ZKSync Era.
+We'll deploy and interact with a smart contract using various gas settings to understand how different parameters affect
+transaction execution and costs on ZKSync Era.
 
 ## Running the Experiment
 
 1. Set up your environment by creating a new project with ZKsync CLI
-2. Create the ZKFestVoting contract, and the deploy script based on the code below
+2. Create the ZKFestVoting contract and the deploy script based on the code below
 3. Analyze the output for each scenario, paying attention to:
     - Successful transactions and their gas usage
     - Rejected transactions and their error messages
@@ -194,7 +194,7 @@ contract ZKFestVoting {
     ```
 ::
 
-This contract uses bit manipulation to efficiently store voting data, minimizing storage costs and pubdata usage.
+This contract uses bit manipulation to store voting data efficiently, minimizing storage costs and pubdata usage.
 
 The `ZKFestVoting` contract allows participants to vote for different stages of ZKFest.
 
@@ -371,7 +371,7 @@ export default async function () {
 This deployment script serves as a practical example of how to interact with ZKsync Era, showcasing the impact
 of different gas settings on transaction execution and costs.
 
-This script deploys the contract and tests different scenarios with varying `gasPerPubdata` and `gasLimit` values.
+This script deploys the contract and tests scenarios with varying `gasPerPubdata` and `gasLimit` values.
 
 **The script includes:**
 
@@ -381,7 +381,7 @@ This script deploys the contract and tests different scenarios with varying `gas
 
 ## How It Works
 
-1. **Transaction Submission**: When sending a transaction, you specify the max gas per pubdata.
+1. **Transaction Submission**: When sending a transaction, specify the max gas per pubdata.
 
 2. **Execution**: ZKsync Era executes the transaction and calculates the actual pubdata cost.
 
@@ -391,14 +391,14 @@ This script deploys the contract and tests different scenarios with varying `gas
 
 - If actual cost ≤ specified max: Transaction succeeds
 - If actual cost > specified max: Transaction is rejected
-  - Which in this case, it’s happening with the very low gasPerPubdata example `await sendAndExplainTx("100", "2000000");`
+  - Which in this case, it's happening with the very low gasPerPubdata example `await sendAndExplainTx("100", "2000000");`
 
 ## Key Aspects of Gas Measurement and DEFAULT_GAS_PER_PUBDATA_LIMIT
 
 - **Deployment Fee Estimation**:
 The script estimates the deployment fee before deploying the contract, giving insight into the initial cost.
 - **Custom Transaction Creation**:
-The `createCustomTx` function allows setting custom `gasPerPubdata` and `gasLimit` values for each transaction.
+The `createCustomTx` function allows custom `gasPerPubdata` and `gasLimit` values to be set for each transaction.
 - **Testing Different Scenarios**:
   - failsDefault `DEFAULT_GAS_PER_PUBDATA_LIMIT` with a moderate `gasLimit`
   - Very low `gasPerPubdata` to see how it affects transaction execution
@@ -413,9 +413,9 @@ Comprehensive error handling and logging provide insights into transaction failu
 1. The `DEFAULT_GAS_PER_PUBDATA_LIMIT` (accessed via zksync-ethers library on `utils.DEFAULT_GAS_PER_PUBDATA_LIMIT`)
 serves for setting default pubdata gas limits.
 2. Very low gas per pubdata values may lead to transaction rejection due to insufficient pubdata gas.
-    1. In this case, the transaction won’t be included in the blockchain in the first place and the user is not charged with anything.
+    - In this case, the transaction won’t be included in the blockchain, and the user is not charged anything.
 3. Extremely high `gasLimit` values may not necessarily improve transaction success rates but could lead to higher costs.
 4. The optimal values depend on the specific operation and current network conditions.
 
 By experimenting with these parameters, developers can find the right balance between transaction success rate
- cost efficiency for their ZKSync Era applications.
+cost efficiency for their ZKSync Era applications.