fix: Fix a large number of link errors in the document

core/node/consensus/src/en.rs

@@ -178,7 +178,7 @@ impl EN {
         tracing::warn!("\
             WARNING: this node is using ZKsync API synchronization, which will be deprecated soon. \
             Please follow this instruction to switch to p2p synchronization: \
-            https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/10_decentralization.md");
+            https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/external-node/10_decentralization.md");
         let res: ctx::Result<()> = scope::run!(ctx, |ctx, s| async {
             // Update sync state in the background.
             s.spawn_bg(self.fetch_state_loop(ctx));

docs/src/announcements/attester_commitee.md

@@ -36,7 +36,7 @@ Participants can leave the committee at any time.
 The only action that is required to participate is to share your attester public key with the Main Node operator (by
 opening an issue in this repo or using any other communication channel). You can find it in the comment in the
 `consensus_secrets.yaml` file (that was - in most cases - generated by the tool described
-[here](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/10_decentralization.md#generating-secrets))
+[here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/external-node/10_decentralization.md#generating-secrets))
 
 > [!WARNING]
 >

docs/src/guides/advanced/07_fee_model.md

@@ -241,7 +241,7 @@ There are a few reasons why refunds might be 'larger' on ZKsync (i.e., why we mi
   impacts the amount of gas used by pubdata.
 
 [gas_adjuster]:
-  https://github.com/matter-labs/zksync-era/blob/main/core/lib/zksync_core/src/l1_gas_price/gas_adjuster/mod.rs#L30
+  https://github.com/matter-labs/zksync-era/blob/main/core/node/fee_model/src/l1_gas_price/gas_adjuster/mod.rs#L30
   'gas_adjuster'
 [get_txs_fee_in_wei]:
   https://github.com/matter-labs/zksync-era/blob/714a8905d407de36a906a4b6d464ec2cab6eb3e8/core/lib/zksync_core/src/api_server/tx_sender/mod.rs#L656

docs/src/guides/advanced/12_alternative_vm_intro.md

@@ -40,7 +40,7 @@ receiving a _pointer_ in its first register *(*basically a packed struct with 4
 length of the slice to which it points to*)* to the calldata page of the parent. Similarly, a transaction can receive
 some other additional data within its registers at the start of the program: whether the transaction should invoke the
 constructor
-[more about deployments here](https://github.com/matter-labs/zksync-era/blob/main/docs/specs/zk_evm/system_contracts.md#contractdeployer--immutablesimulator),
+[more about deployments here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/specs/zk_evm/system_contracts.md#contractdeployer--immutablesimulator),
 whether the transaction has `isSystem` flag, etc. The meaning of each of these flags will be expanded further in this
 section.
 
@@ -161,7 +161,7 @@ Note, that currently we do not have access to the `tx_counter` within VM (i.e. 
 and it will be automatically used for logs such as `event`s as well as system logs produced by `to_l1`, but we can not
 read it). We need to read it to publish the _user_ L2→L1 logs, so `increment_tx_counter` is always accompanied by the
 corresponding call to the
-[SystemContext](https://github.com/matter-labs/zksync-era/blob/main/docs/specs/zk_evm/system_contracts.md#systemcontext)
+[SystemContext](https://github.com/matter-labs/zksync-era/blob/main/docs/src/specs/zk_evm/system_contracts.md#systemcontext)
 contract.
 
 More on the difference between system and user logs can be read
@@ -197,7 +197,7 @@ the start of execution:
   to the call. Currently, two flags are supported: 0-th bit: `isConstructor` flag. This flag can only be set by system
   contracts and denotes whether the account should execute its constructor logic. Note, unlike Ethereum, there is no
   separation on constructor & deployment bytecode. More on that can be read
-  [here](https://github.com/matter-labs/zksync-era/blob/main/docs/specs/zk_evm/system_contracts.md#contractdeployer--immutablesimulator).
+  [here](https://github.com/matter-labs/zksync-era/blob/main/docs/src/specs/zk_evm/system_contracts.md#contractdeployer--immutablesimulator).
   1-st bit: `isSystem` flag. Whether the call intends a system contracts’ function. While most of the system contracts’
   functions are relatively harmless, accessing some with calldata only may break the invariants of Ethereum, e.g. if the
   system contract uses `mimic_call`: no one expects that by calling a contract some operations may be done out of the
@@ -286,7 +286,7 @@ On ZKsync the bytecode hashes are stored in the following format:
 
 - The 0th byte denotes the version of the format. Currently the only version that is used is “1”.
 - The 1st byte is `0` for deployed contracts’ code and `1` for the contract code
-  [that is being constructed](https://github.com/matter-labs/zksync-era/blob/main/docs/specs/zk_evm/system_contracts.md#constructing-vs-non-constructing-code-hash).
+  [that is being constructed](https://github.com/matter-labs/zksync-era/blob/main/docs/src/specs/zk_evm/system_contracts.md#constructing-vs-non-constructing-code-hash).
 - The 2nd and 3rd bytes denote the length of the contract in 32-byte words as big-endian 2-byte number.
 - The next 28 bytes are the last 28 bytes of the sha256 hash of the contract’s bytecode.
 
@@ -305,5 +305,5 @@ simply revert (similar to how EVM would treat them).
 
 A call to a contract with invalid bytecode can not be proven. That is why it is **essential** that no contract with
 invalid bytecode is ever deployed on ZKsync. It is the job of the
-[KnownCodesStorage](https://github.com/matter-labs/zksync-era/blob/main/docs/specs/zk_evm/system_contracts.md#knowncodestorage)
+[KnownCodesStorage](https://github.com/matter-labs/zksync-era/blob/main/docs/src/specs/zk_evm/system_contracts.md#knowncodestorage)
 to ensure that all allowed bytecodes in the system are valid.

docs/src/guides/advanced/13_zk_intuition.md

@@ -139,7 +139,7 @@ version 1.4.0.
 
 [witness_example]:
   https://github.com/matter-labs/era-zkevm_test_harness/tree/main/src/witness/individual_circuits/decommit_code.rs#L24
-[verifier]: https://github.com/matter-labs/era-contracts/blob/main/l1-contracts/contracts/zksync/Verifier.sol
+[verifier]: https://github.com/matter-labs/era-contracts/blob/main/l1-contracts/contracts/state-transition/Verifier.sol
 [bellman repo]: https://github.com/matter-labs/bellman
 [bellman cuda repo]: https://github.com/matter-labs/era-bellman-cuda
 [example ecrecover circuit]:

docs/src/guides/advanced/15_prover_keys.md

@@ -118,7 +118,7 @@ friendly hash function (currently Poseidon2).
 [recursive_circuit_list]:
   https://github.com/matter-labs/era-zkevm_test_harness/blob/3cd647aa57fc2e1180bab53f7a3b61ec47502a46/circuit_definitions/src/circuit_definitions/recursion_layer/mod.rs#L29
 [verification_key_list]:
-  https://github.com/matter-labs/zksync-era/tree/6d18061df4a18803d3c6377305ef711ce60317e1/prover/data/keys
+  https://github.com/matter-labs/zksync-era/tree/main/prover/data/keys
 [env_variables_for_hash]:
   https://github.com/matter-labs/zksync-era/blob/6d18061df4a18803d3c6377305ef711ce60317e1/etc/env/base/contracts.toml#L61
 [prover_setup_data]:

docs/src/guides/external-node/03_running.md

@@ -44,7 +44,7 @@ Besides running Postgres, you are expected to have a DB dump from a correspondin
 `pg_restore -O -C <DUMP_PATH> --dbname=<DB_URL>`.
 
 You can also refer to
-[ZKsync Node configuration management blueprint](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/00_quick_start.md#advanced-setup)
+[ZKsync Node configuration management blueprint](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/external-node/00_quick_start.md#advanced-setup)
 for advanced DB instance configurations.
 
 [host_docker_internal](https://docs.docker.com/desktop/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host)

docs/src/guides/external-node/10_decentralization.md

@@ -35,9 +35,9 @@ chmod 600 consensus_secrets.yaml
 ### Preparing configuration file
 
 Copy the template of the consensus configuration file (for
-[mainnet](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/prepared_configs/mainnet_consensus_config.yaml)
+[mainnet](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/external-node/prepared_configs/mainnet_consensus_config.yaml)
 or
-[testnet](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/prepared_configs/testnet_consensus_config.yaml)
+[testnet](https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/external-node/prepared_configs/testnet_consensus_config.yaml)
 ).
 
 > [!NOTE]

prover/crates/bin/vk_setup_data_generator_server_fri/src/main.rs

@@ -105,7 +105,7 @@ fn generate_vks(keystore: &Keystore, jobs: usize, quiet: bool) -> anyhow::Result
 #[command(
     author = "Matter Labs",
     version,
-    about = "Key generation tool. See https://github.com/matter-labs/zksync-era/blob/main/docs/guides/advanced/prover_keys.md for details.",
+    about = "Key generation tool. See https://github.com/matter-labs/zksync-era/blob/main/docs/src/guides/advanced/15_prover_keys.md for details.",
     long_about = None
 )]
 struct Cli {