fix: lint ci err

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

@@ -8,7 +8,9 @@ Unlike traditional rollups that publish transaction data (calldata), ZKsync Era
 - Smart contract bytecodes
 - L2 → L1 messages and logs
 
-The charge is calculated as `pubdata_bytes_published * gas_per_pubdata` directly from the context of the execution. This approach allows for more efficient handling of applications that frequently modify the same storage slot, such as oracles. These applications can update storage slots multiple times while maintaining a constant footprint on L1 pubdata.
+The charge is calculated as `pubdata_bytes_published * gas_per_pubdata` directly from the context of the execution.
+This approach allows for more efficient handling of applications that frequently modify the same storage slot, such as oracles.
+These applications can update storage slots multiple times while maintaining a constant footprint on L1 pubdata.
 
 ## Key Differences from Ethereum
 
@@ -24,15 +26,22 @@ ZKsync Era distinguishes between computational costs and pubdata costs.
 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 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.
+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 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)
 
 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) 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.
+- **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) 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**:
     1. The current pubdata spent is recorded as basePubdataSpent.
@@ -43,7 +52,8 @@ ZKsync Era employs a sophisticated method for charging pubdata costs, addressing
     6. The pubdata check is repeated. If it fails at this stage, the transaction is reverted (user pays for computation but no state changes occur).
     7. If a paymaster is used, steps d-f are repeated for the paymaster's postTransaction method.
 - **Pubdata Counter Modifications**:
-  - **Storage writes:** The operator specifies the increment for the pubdata counter. Note that this value can be negative if, for example, the storage diff is being reversed, such as in the case of a reentrancy guard.
+  - **Storage writes:** The operator specifies the increment for the pubdata counter. Note that this value can be negative if, for example,
+  the storage diff is being reversed, such as in the case of a reentrancy guard.
   - **Publishing bytes to L1:** The counter is incremented by the number of bytes published.
   - **Transaction revert:** The pubdata counter value reverts along with storage and events.
 - **Advantages of Post-Charging**:
@@ -64,7 +74,9 @@ The following section provides practical insights into measuring gas costs and s
 
 ## 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 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.
+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:**
 
@@ -74,7 +86,8 @@ This guide demonstrates how to measure gas costs and set the `DEFAULT_GAS_PER_PU
 
 ## Objective
 
-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.
+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
 
@@ -179,6 +192,7 @@ contract ZKFestVoting {
         }
     }
   ```
+
 </details>
 
 </br>
@@ -355,6 +369,7 @@ export default async function () {
       }
     }
   ```
+
 </details>
 </br>
 
@@ -404,7 +419,7 @@ Comprehensive error handling and logging provide insights into transaction failu
 serves for setting default pubdata gas limits.
 2. Very low gas per pubdata values may lead to transaction rejection due to insufficient pubdata gas.
     - 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 upfront costs
+3. Extremely high `gasLimit` values may not necessarily improve transaction success rates but could lead to higher upfront 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.