more lints

docs/bridging/bridgehub/overview.md

@@ -61,15 +61,12 @@ Most of the params are self-explanatory & replicate the logic of zkSync Era. The
 
 Here is a quick guide on how this transaction is routed through the bridgehub.
 
-1. The bridgehub retrieves the `baseTokenAssetId`  of the chain with the corresponding `chainId` and calls `L1AssetRouter.bridgehubDepositBaseToken` method. The `L1AssetRouter` will then use standard token depositing mechanism to burn/escrow the respective amount of the `baseTokenAssetId`. You can read more about it in [the asset router doc](../asset_router/Overview.md).
-
-This step ensures that the baseToken will be backed 1-1 on L1.
+1. The bridgehub retrieves the `baseTokenAssetId`  of the chain with the corresponding `chainId` and calls `L1AssetRouter.bridgehubDepositBaseToken` method. The `L1AssetRouter` will then use standard token depositing mechanism to burn/escrow the respective amount of the `baseTokenAssetId`. You can read more about it in [the asset router doc](../asset_router/Overview.md). This step ensures that the baseToken will be backed 1-1 on L1.
 
 2. After that, it just routes the corresponding call to the ZKChain with the corresponding `chainId` . It is now the responsibility of the ZKChain to validate that the transaction is correct and can be accepted by it. This validation includes, but not limited to:
-
-- The fact that the user paid enough funds for the transaction (basically `request.l2GasLimit * derivedL2GasPrice(...) + request.l2Value >= request.mintValue`.
-- The fact the transaction is always executable (the `request.l2GasLimit`  is not high enough).
-- etc.
+    - The fact that the user paid enough funds for the transaction (basically `request.l2GasLimit * derivedL2GasPrice(...) + request.l2Value >= request.mintValue`.
+    - The fact the transaction is always executable (the `request.l2GasLimit`  is not high enough).
+    - etc.
 
 3. After the ZKChain validates the tx, it includes it into its priority queue. Once the operator executes this transaction on L2, the `mintValue` of the baseToken will be minted on L2. The `derivedL2GasPrice(...) * gasUsed` will be given to the operator’s balance. The other funds can be routed either of the following way:
 
@@ -134,7 +131,7 @@ The first few fields are the same as for the simple L1→L2 transaction case. Ho
 
 The function will do the following:
 
-**L1**
+#### L1
 
 1. It will deposit the `request.mintValue`  of the ZKChain’s base token the same way as during a simple L1→L2 transaction. These funds will be used for funding the `l2Value`  and the fee to the operator.
 2. It will call the `secondBridgeAddress` (`L1AssetRouter`) once again and this time it will deposit the funds to the `L1AssetRouter`, but this time it will be deposit not to pay the fees, but rather for the sake of bridging the desired token.
@@ -143,7 +140,7 @@ This call will return the parameters to call the l2 contract with (the address o
 3. After the BridgeHub will call the ZKChain to add the corresponding L1→L2 transaction to the priority queue.
 4. The BridgeHub will call the `SharedBridge` once again so that it can remember the hash of the corresponding deposit transaction. [This is needed in case the deposit fails](#claiming-failed-deposits).
 
-**L2**
+#### L2
 
 1. After some time, the corresponding L1→L2 is created.
 2. The L2AssetRouter will receive the message and re-route it to the asset handler of the bridged token. To read more about how it works, check out the [asset router documentation](../asset_router/Overview.md).

docs/chain_management/chain_genesis.md

@@ -65,7 +65,7 @@ Each single ZK Chain has a set of the following contracts that, while not belong
 
 To reuse as much code as possible from L1 and also to allow easier initialization, most of these contracts are not initialized as just part of the genesis storage root. Instead, the data for their initialization is part of the original diamondcut for the chain. In the same initial upgrade transaction when the chainId is initialized, these contracts are force-deployed and initialized also. An important part in it plays the new `L2GenesisUpgrade` contract, which is pre-deployed in a user-space contract, but it is delegate-called by the `ComplexUpgrader` system contract (already exists as part of genesis and existed before this upgrade).
 
-# Additional limitations for the current version
+## Additional limitations for the current version
 
 In the current version creating new chains will not be permissionless. That is needed to ensure that no malicious input can be provided there.
 

docs/chain_management/chain_type_manager.md

@@ -1,4 +1,4 @@
-## Chain Type Manager (CTM)
+# Chain Type Manager (CTM)
 
 [back to readme](../README.md)
 
@@ -25,7 +25,7 @@ In the long term vision STs deployment will be permissionless, however CTM will
 
 For now, only one CTM will be supported — the one that deploys instances of zkSync Era, possibly using other DA layers. To read more about different DA layers, check out [this document](../settlement_contracts/data_availability/custom_da.md).
 
-The exact process of deploying & registering a ST will be described in [sections below](#creating-new-chains-with-bridgehub). Overall, each ST in the current release will have the following parameters:
+The exact process of deploying & registering a ST can be [read here](./chain_genesis.md). Overall, each ST in the current release will have the following parameters:
 
 | ST parameter | Updatability | Comment |
 | --- | --- | --- |
@@ -49,10 +49,9 @@ In the current release, each chain will be an instance of zkSync Era and so the
 
 1. Firstly, the governance of the CTM will publish the server (including sequencer, prover, etc) that support the new version . This is done offchain. Enough time should be given to various zkStack devs to update their version.
 2. The governance of the CTM will publish the upgrade onchain by automatically executing the following three transactions:
-
-- `setChainCreationParams` ⇒ to ensure that new chains will be created with the version
-- `setValidatorTimelock` (if needed) ⇒ to ensure that the new chains will use the new validator timelock right-away
-- `setNewVersionUpgrade` ⇒ to save the upgrade information that each ST will need to follow to conduct the upgrade on their side.
+    - `setChainCreationParams` ⇒ to ensure that new chains will be created with the version
+    - `setValidatorTimelock` (if needed) ⇒ to ensure that the new chains will use the new validator timelock right-away
+    - `setNewVersionUpgrade` ⇒ to save the upgrade information that each ST will need to follow to conduct the upgrade on their side.
 
 3. After that, each ChainAdmin can upgrade to the new version in suitable time for them.
 

docs/chain_management/upgrade_process.md

@@ -1,5 +1,3 @@
-# TODO
-
 # Upgrade process document
 
 [back to readme](../README.md)

docs/gateway/gateway_protocol_upgrades.md

@@ -156,25 +156,3 @@ Definition:
     2. creation is probably not needed - as the contract was already there in a first place.
     3. same as above - but the state is ‘re-initialized’
 4. Same as above - but on chain ‘Z’
-
-### What can go wrong
-
-**Check 1 - protocol version**
-
-- chain is on the older protocol version before the migration start
-- resolution: don’t allow the migration, tell protocol to upgrade itself first.
-
-**Check 3a — protocol version on destination chain**
-
-- destination chain CTM is on the OLDER version than the payload
-  - resolution: fail the transfer - seems that CTMs were not upgraded.
-- destination chain CTM is on the NEWER version that then payload
-  - For simplicity - we could fail the transfer here too.
-
-**Check 4a — protocol version on the source chain in case of transfer failure**
-
-- source IZKChain is on the ‘older’ protocol version than the payload
-  - in theory - impossible, as this means that the IZKChain protocol version was ‘reverted’.
-- source IZKChain is on the ‘newer’ protocol version than the payload
-  - This is the **main** worst case scenario - as this means that the IZKChain was updated (via ‘inactive’ update) while the protocol transfer was ongoing.
-  - This is the ‘Stuck state’ case described in the paragraph above.

docs/gateway/nested_l3_l1_messaging.md

@@ -45,7 +45,7 @@ At the end of the batch, the L1Messenger system contract would query the Message
 
 Only the final aggregated root will be stored on L1.
 
-# Proving that a message belongs to a chain on top of SyncLayer
+## Proving that a message belongs to a chain on top of SyncLayer
 
 The process will consist of two steps:
 

docs/l2_system_contracts/batches_and_blocks_on_zksync.md

@@ -23,19 +23,19 @@ In order to get the returned value for `block.number`, `block.timestamp`, `block
 
 These return values for L2 blocks.
 
-# Blocks’ processing and consistency checks
+## Blocks’ processing and consistency checks
 
 Our `SystemContext` contract allows to get information about batches and L2 blocks. Some of the information is hard to calculate onchain. For instace, time. The timing information (for both batches and L2 blocks) are provided by the operator. In order to check that the operator provided some realistic values, certain checks are done on L1. Generally though, we try to check as much as we can on L2.
 
-## Initializing L1 batch
+### Initializing L1 batch
 
 At the start of the batch, the operator [provides](../../system-contracts/bootloader/bootloader.yul#L3935) the timestamp of the batch, its number and the hash of the previous batch. The root hash of the Merkle tree serves as the root hash of the batch.
 
 The SystemContext can immediately check whether the provided number is the correct batch number. It also immediately sends the previous batch hash to L1, where it will be checked during the commit operation. Also, some general consistency checks are performed. This logic can be found [here](../../system-contracts/contracts/SystemContext.sol#L469).
 
-## L2 blocks processing and consistency checks
+### L2 blocks processing and consistency checks
 
-### `setL2Block`
+#### `setL2Block`
 
 Before each transaction, we call `setL2Block` [method](../../system-contracts/bootloader/bootloader.yul#L2884). There we will provide some data about the L2 block that the transaction belongs to:
 
@@ -49,7 +49,7 @@ If two transactions belong to the same L2 block, only the first one may have non
 
 The `setL2Block` [performs](../../system-contracts/contracts/SystemContext.sol#L355) a lot of similar consistency checks to the ones for the L1 batch.
 
-### L2 blockhash calculation and storage
+#### L2 blockhash calculation and storage
 
 Unlike L1 batch’s hash, the L2 blocks’ hashes can be checked on L2.
 
@@ -67,15 +67,15 @@ Since zkSync is a state-diff based rollup, there is no way to deduce the hashes
 
 We store only the last 257 blocks, since the EVM requires only 256 previous ones and we use 257 as a safe margin.
 
-### Legacy blockhash
+#### Legacy blockhash
 
 For L2 blocks that were created before we switched to the formulas from above, we use the following formula for their hash:
 
 `keccak256(abi.encodePacked(uint32(_blockNumber)))`
 
 These are only very old blocks on zkSync Era and other ZK chains don't have such blocks.
 
-### Timing invariants
+#### Timing invariants
 
 While the timestamp of each L2 block is provided by the operator, there are some timing invariants that the system preserves:
 
@@ -85,7 +85,7 @@ While the timestamp of each L2 block is provided by the operator, there are some
 - The timestamp of a batch must be ≥ the timestamp of the latest L2 block which belonged to the previous batch.
 - The timestamp of the last miniblock in batch can not go too far into the future. This is enforced by publishing an L2→L1 log, with the timestamp which is then checked on L1.
 
-## Fictive L2 block & finalizing the batch
+### Fictive L2 block & finalizing the batch
 
 At the end of the batch, the bootloader calls the `setL2Block` [one more time](../../system-contracts/bootloader/bootloader.yul#L4110) to allow the operator to create a new empty block. This is done purely for some of the technical reasons inside the node, where each batch ends with an empty L2 block.