docs: add tx filterer docs, fix minor mistakes

docs/.vuepress/sidebar/en.ts

@@ -614,7 +614,7 @@ export const enSidebar = sidebar({
               link: "/zk-stack/concepts/data-availability/overview.md"
             },
             {
-              text: "Recreating State form L1",
+              text: "Recreating State from L1",
               link: "/zk-stack/concepts/data-availability/recreate-l2-state-from-l1-state-diffs.md"
             },
             {

docs/build/developer-reference/l1-l2-interop.md

@@ -25,6 +25,16 @@ L1 to L2 communication is governed by the [`IZkSync.sol`](https://github.com/mat
 - If you prefer to learn-by-doing, the [cross chain governance tutorial](../tutorials/smart-contract-development/cross-chain-tutorial.md) is a practical example of layer interoperability.
   :::
 
+#### L1 to L2 transaction filtering
+
+A hyperchain operator can filter L1→L2 transactions coming through the Diamond proxy. It is achieved by having an
+address of the special contract, responsible for transaction filtering, in the state transition storage. If the filterer
+exists, it is being called in the [Mailbox facet](https://github.com/matter-labs/era-contracts/blob/dev/l1-contracts/contracts/state-transition/chain-deps/facets/Mailbox.sol#L243)
+with the tx details and has to return whether the transaction can be executed or not. If you want to use this feature,
+you have to deploy a contract that implements the [`ITransactionFilterer` interface](https://github.com/matter-labs/era-contracts/blob/dev/l1-contracts/contracts/state-transition/chain-interfaces/ITransactionFilterer.sol#L8)
+and set its address in the admin facet's [`setTransactionFilterer`](https://github.com/matter-labs/era-contracts/blob/dev/l1-contracts/contracts/state-transition/chain-deps/facets/Admin.sol#L95)
+function. The same setter can be used to remove the filterer, it has to be called with the `0` address.
+
 ### Gas estimation
 
 The SDK processes gas estimation for transactions implicitly. However, it is also possible to implement the gas estimation processes explicitly.

docs/zk-stack/components/shared-bridges.md

@@ -160,7 +160,7 @@ be able to leverage them when available).
     Hyperchain.
   - `Facets` and `Verifier` are shared across chains that relies on the same ST: `Base`, `Executor` , `Getters`, `Admin`
     , `Mailbox.`The `Verifier` is the contract that actually verifies the proof, and is called by the `Executor`.
-  - Upgrade Mechanism The system requires all chains to be up-to-date with the latest implementation, so whenever an
+  - `Upgrade Mechanism` The system requires all chains to be up-to-date with the latest implementation, so whenever an
     update is needed, we have to “force” each chain to update, but due to decentralization, we have to give each chain a
     time frame (more information in the
     [Upgrade Mechanism](https://www.notion.so/ZK-Stack-shared-bridge-alpha-version-a37c4746f8b54fb899d67e474bfac3bb?pvs=21)

docs/zk-stack/components/smart-contracts/smart-contracts.md

@@ -172,7 +172,7 @@ Implementation detail - function returns a magic value just like it is designed
 
 Bridges are completely separate contracts from the Diamond. They are a wrapper for L1 <-> L2 communication on contracts
 on both L1 and L2. Upon locking assets on L1, a request is sent to mint these bridged assets on L2. Upon burning assets
-on L2, a request is sent to unlock them on L2.
+on L2, a request is sent to unlock them on L1.
 
 Unlike the native Ether bridging, all other assets can be bridged by the custom implementation relying on the trustless
 L1 <-> L2 communication.
@@ -288,4 +288,4 @@ struct Deposit {
 ```
 
 Currently, the limit is used only for blocking deposits of the specific token (turning on the limitation and setting the
-limit to zero). And on the near future, this functionality will be completely removed.
+limit to zero). And in the near future, this functionality will be completely removed.

docs/zk-stack/components/zkEVM/bootloader.md

@@ -49,8 +49,7 @@ We also ensure that transactions do not exceed the limits of the memory space al
 
 ## Transaction Types and Validation
 
-While the main transaction format is the internal []`Transaction`
-format](<https://github.com/code-423n4/2023-10-zksync/blob/ef99273a8fdb19f5912ca38ba46d6bd02071363d/code/system-contracts/contracts/libraries/TransactionHelper.sol#L25>),
+While the main transaction format is the internal [`Transaction` format](https://github.com/matter-labs/era-contracts/blob/main/system-contracts/contracts/libraries/TransactionHelper.sol#L25),
 it is a struct that is used to represent various kinds of transactions types. It contains a lot of `reserved` fields
 that could be used depending in the future types of transactions without need for AA to change the interfaces of their
 contracts.