fix: addresses broken links in preparation for ci link check (#869)

Related PRs:
- #868
- #870

## What ❔
- Addresses broken links in the repo
<!-- What are the changes this PR brings about? -->
<!-- Example: This PR adds a PR template to the repo. -->
<!-- (For bigger PRs adding more context is appreciated) -->

## Why ❔
- Should not have dead links in the repo
- Addressing issues with links prior to `zk linkcheck` usage in ci
<!-- Why are these changes done? What goal do they contribute to? What
are the principles behind them? -->
<!-- Example: PR templates ensure PR reviewers, observers, and future
iterators are in context about the evolution of repos. -->

## Checklist

<!-- Check your PR fulfills the following items. -->
<!-- For draft PRs check the boxes as you complete them. -->

- [x] PR title corresponds to the body of PR (we generate changelog
entries from PRs).
- [ ] Tests for the changes have been added / updated.
- [x] Documentation comments have been added / updated.
- [x] Code has been formatted via `zk fmt` and `zk lint`.
- [x] Spellcheck has been run via `zk spellcheck`.

README.md

@@ -18,7 +18,7 @@ The following questions will be answered by the following resources:
 | How can I run the project?                              | [launch.md](docs/guides/launch.md)             |
 | What is the logical project structure and architecture? | [architecture.md](docs/guides/architecture.md) |
 | Where can I find protocol specs?                        | [specs](docs/specs/README.md)                  |
-| Where can I find developer docs?                        | [docs](https://v2-docs.zksync.io/dev/)         |
+| Where can I find developer docs?                        | [docs](https://era.zksync.io/docs/)            |
 
 ## Policies
 
@@ -30,7 +30,7 @@ The following questions will be answered by the following resources:
 zkSync Era is distributed under the terms of either
 
 - Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or <http://www.apache.org/licenses/LICENSE-2.0>)
-- MIT license ([LICENSE-MIT](LICENSE-MIT) or <http://opensource.org/licenses/MIT>)
+- MIT license ([LICENSE-MIT](LICENSE-MIT) or <https://opensource.org/license/mit/>)
 
 at your option.
 

checks-config/era.cfg

@@ -15,7 +15,7 @@ lang = "en_US"
 # Windows: []
 # macOS [ /home/alice/Libraries/hunspell, /Libraries/hunspell ]
 
-# Additional search paths, which take presedence over the default
+# Additional search paths, which take precedence over the default
 # os specific search dirs, searched in order, defaults last
 search_dirs = ["."]
 

core/CHANGELOG.md

@@ -443,7 +443,7 @@
 ### Features
 
 * Implement dynamic L2-to-L1 log tree depth ([#126](https://github.com/matter-labs/zksync-era/issues/126)) ([7dfbc5e](https://github.com/matter-labs/zksync-era/commit/7dfbc5eddab94cd24f96912e0d43ba36e1cf363f))
-* **vm:** Introduce new way of returning from the tracer [#2569](https://github.com/matter-labs/zksync-era/issues/2569) ([#116](https://github.com/matter-labs/zksync-era/issues/116)) ([cf44a49](https://github.com/matter-labs/zksync-era/commit/cf44a491a324199b4cf457d28658da44b6dafc61))
+* **vm:** Introduce new way of returning from the tracer [#2569](https://github.com/matter-labs/zksync-2-dev/issues/2569) ([#116](https://github.com/matter-labs/zksync-era/issues/116)) ([cf44a49](https://github.com/matter-labs/zksync-era/commit/cf44a491a324199b4cf457d28658da44b6dafc61))
 * **vm:** Restore system-constants-generator ([#115](https://github.com/matter-labs/zksync-era/issues/115)) ([5e61bdc](https://github.com/matter-labs/zksync-era/commit/5e61bdc75b2baa03004d4d3e801170c094766964))
 
 ## [15.0.1](https://github.com/matter-labs/zksync-2-dev/compare/core-v15.0.0...core-v15.0.1) (2023-09-27)

core/lib/crypto/README.md

@@ -7,4 +7,4 @@
 `zksync_crypto` is a part of zkSync stack, which is distributed under the terms of both the MIT license and the Apache
 License (Version 2.0).
 
-See [LICENSE-APACHE](../../LICENSE-APACHE), [LICENSE-MIT](../../LICENSE-MIT) for details.
+See [LICENSE-APACHE](../../../LICENSE-APACHE), [LICENSE-MIT](../../../LICENSE-MIT) for details.

core/lib/state/README.md

@@ -5,7 +5,7 @@ component responsible for handling transaction execution and creating miniblocks
 
 All state keeper data is currently stored in Postgres. (Beside it, we provide an in-memory implementation for
 benchmarking / testing purposes.) We also keep a secondary copy for part of it in RocksDB for performance reasons.
-Currently, we only duplicate the data needed by the [`vm`] crate.
+Currently, we only duplicate the data needed by the [`multivm`] crate.
 
 [`zksync_core`]: ../zksync_core
-[`vm`]: ../vm
+[`multivm`]: ../multivm

core/tests/vm-benchmark/README.md

@@ -29,7 +29,7 @@ them to "benches/iai.rs".
 ## Profiling (Linux only)
 
 You can also use `sh perf.sh bytecode_file` to produce data that can be fed into the
-[firefox profiler](profiler.firefox.com) for a specific bytecode.
+[firefox profiler](https://profiler.firefox.com/) for a specific bytecode.
 
 ## Fuzzing
 

docs/guides/advanced/0_alternative_vm_intro.md

@@ -2,7 +2,7 @@
 
 ## zkEVM clarifier
 
-[Back to ToC](../../README.md)
+[Back to ToC](../../specs/README.md)
 
 The zkSync zkEVM plays a fundamentally different role in the zkStack than the EVM does in Ethereum. The EVM is used to
 execute code in Ethereum's state transition function. This STF needs a client to implement and run it. Ethereum has a
@@ -41,8 +41,10 @@ Unlike EVM, which is stack machine, zkEVM has 16 registers. Instead of receiving
 receiving a _pointer_ in its first register *(*basically a packed struct with 4 elements: the memory page id, start and
 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](#contractdeployer--immutablesimulator)), whether the transaction has
-`isSystem` flag, etc. The meaning of each of these flags will be expanded further in this section.
+constructor
+[more about deployments here](https://github.com/matter-labs/zksync-era/blob/main/docs/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.
 
 _Pointers_ are separate type in the VM. It is only possible to:
 
@@ -160,7 +162,9 @@ result in `revert(0,0)`.
 Note, that currently we do not have access to the `tx_counter` within VM (i.e. for now it is possible to increment it
 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](#systemcontext) contract.
+corresponding call to the
+[SystemContext](https://github.com/matter-labs/zksync-era/blob/main/docs/specs/zk_evm/system_contracts.md#systemcontext)
+contract.
 
 More on the difference between system and user logs can be read
 [here](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/Smart%20contract%20Section/Handling%20pubdata%20in%20Boojum.md). -
@@ -195,11 +199,11 @@ 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](#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 name of the caller. This flag can be only set if the callee is in
-  kernel space.
+  [here](https://github.com/matter-labs/zksync-era/blob/main/docs/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
+  name of the caller. This flag can be only set if the callee is in kernel space.
 - The rest r3..r12 registers are non-empty only if the `isSystem` flag is set. There may be arbitrary values passed,
   which we call `extraAbiParams`.
 
@@ -284,7 +288,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](#constructing-vs-non-constructing-code-hash).
+  [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).
 - 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.
 
@@ -302,5 +306,6 @@ Note, that it does not have to consist of only correct opcodes. In case the VM e
 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](#knowncodestorage) to ensure that
-all allowed bytecodes in the system are valid.
+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)
+to ensure that all allowed bytecodes in the system are valid.

docs/guides/advanced/how_l2_messaging_works.md

@@ -205,9 +205,6 @@ transmitted to L1 for final verification.
 [executor_sol]:
   https://github.com/matter-labs/era-contracts/blob/3a4506522aaef81485d8abb96f5a6394bd2ba69e/ethereum/contracts/zksync/facets/Executor.sol#L26
 [mainet_executor]: https://etherscan.io/address/0x389a081BCf20e5803288183b929F08458F1d863D
-
-[sepolia_tx]:
-[0x18c2a113d18c53237a4056403047ff9fafbf772cb83ccd44bb5b607f8108a64c](https://sepolia.etherscan.io/tx/0x18c2a113d18c53237a4056403047ff9fafbf772cb83ccd44bb5b607f8108a64c)
-
+[sepolia_tx]: https://sepolia.etherscan.io/tx/0x18c2a113d18c53237a4056403047ff9fafbf772cb83ccd44bb5b607f8108a64c
 [mailbox_log_inclusion]:
   https://github.com/matter-labs/era-contracts/blob/3a4506522aaef81485d8abb96f5a6394bd2ba69e/ethereum/contracts/zksync/facets/Mailbox.sol#L54

docs/guides/advanced/pubdata.md

@@ -22,9 +22,9 @@ executed, we then will pull the transaction input and the relevant fields, apply
 current state of L2.
 
 One thing to note is that in both systems some of the contract bytecode is compressed into an array of indices where
-each 2 byte index corresponds to an 8 byte word in a dictionary. More on how that is done
-[here](./bytecode_compression.md). Once the bytecode has been expanded, the hash can be taken and checked against the
-storage writes within the `AccountCodeStorage` contract which connects an address on L2 with the 32 byte code hash:
+each 2 byte index corresponds to an 8 byte word in a dictionary. More on how that is done [here](./compression.md). Once
+the bytecode has been expanded, the hash can be taken and checked against the storage writes within the
+`AccountCodeStorage` contract which connects an address on L2 with the 32 byte code hash:
 
 ```solidity
 function _storeCodeHash(address _address, bytes32 _hash) internal {
@@ -80,7 +80,7 @@ The 4 main fields to look at here are:
 3. `factoryDeps`: An array of uncompressed bytecodes
 4. `l2ArbitraryLengthMessages` : L2 → L1 Messages
    1. We don’t need them all, we are just concerned with messages sent from the `Compressor/BytecodeCompressor` contract
-   2. These messages will follow the compression algorithm outline [here](./bytecode_compression.md)
+   2. These messages will follow the compression algorithm outline [here](./compression.md)
 
 For the ids on the repeated writes, they are generated as we process the first time keys. For example: if we see
 `[<key1, val1>, <key2, val2>]` (starting from an empty state) then we can assume that the next time a write happens to

docs/guides/advanced/zk_intuition.md

@@ -139,15 +139,13 @@ 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/ethereum/contracts/zksync/Verifier.sol
+[verifier]: https://github.com/matter-labs/era-contracts/blob/main/l1-contracts/contracts/zksync/Verifier.sol
 [bellman repo]: https://github.com/matter-labs/bellman
 [bellman cuda repo]: https://github.com/matter-labs/era-bellman-cuda
 [example ecrecover circuit]:
   https://github.com/matter-labs/era-sync_vm/blob/v1.3.2/src/glue/ecrecover_circuit/mod.rs#L157
-[zksync core witness]:
-  https://github.com/matter-labs/zksync-era/blob/main/core/lib/zksync_core/src/witness_generator/mod.rs
 [separate witness binary]: https://github.com/matter-labs/zksync-era/blob/main/prover/witness_generator/src/main.rs
 [zkevm_test_harness witness]:
-  https://github.com/matter-labs/zkevm_test_harness/blob/0c17bc7baa4e0b64634d414942ef4200d8613bbd/src/external_calls.rs#L575
-[heavy_ops_service repo]: https://github.com/matter-labs/heavy-ops-service/tree/v1.3.2
+  https://github.com/matter-labs/era-zkevm_test_harness/blob/fb47657ae3b6ff6e4bb5199964d3d37212978200/src/external_calls.rs#L579
+[heavy_ops_service repo]: https://github.com/matter-labs/era-heavy-ops-service
 [franklin repo]: https://github.com/matter-labs/franklin-crypto

docs/guides/launch.md

@@ -17,8 +17,9 @@ zk # installs and builds zk itself
 zk init
 ```
 
-If you face any other problems with the `zk init` command, go to the [Troubleshooting](#Troubleshooting) section at the
-end of this file. There are solutions for some common error cases.
+If you face any other problems with the `zk init` command, go to the
+[Troubleshooting](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/launch.md#troubleshooting) section at
+the end of this file. There are solutions for some common error cases.
 
 To completely reset the dev environment:
 

docs/guides/repositories.md

@@ -16,7 +16,7 @@
 | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
 | [era-compiler-tester](https://github.com/matter-labs/era-compiler-tester)             | Integration testing framework for running executable tests on zkEVM |
 | [era-compiler-tests](https://github.com/matter-labs/era-compiler-tests)               | Collection of executable tests for zkEVM                            |
-| [era-compiler-llvm](https://github.com/matter-labs/compiler-llvm)                     | zkEVM fork of the LLVM framework                                    |
+| [era-compiler-llvm](https://github.com/matter-labs//era-compiler-llvm)                | zkEVM fork of the LLVM framework                                    |
 | [era-compiler-solidity](https://github.com/matter-labs/era-compiler-solidity)         | Solidity Yul/EVMLA compiler front end                               |
 | [era-compiler-vyper](https://github.com/matter-labs/era-compiler-vyper)               | Vyper LLL compiler front end                                        |
 | [era-compiler-llvm-context](https://github.com/matter-labs/era-compiler-llvm-context) | LLVM IR generator logic shared by multiple front ends               |

docs/specs/overview.md

@@ -8,9 +8,8 @@ A user submits their transaction to the sequencer. The job of the sequencer is t
 using the zkEVM, and to provide a soft confirmation to the user that their transaction was executed. If the user chooses
 they can force the sequencer to include their transaction by submitting it via L1. After the sequencer executes the
 block, it sends it over to the prover, who creates a cryptographic proof of the block's execution. This proof is then
-sent to the L1 contract alongside the necessary data. On the L1 a
-[smart contract](./zkEVM/high_level/l1_smart_contracts.md) verifies that the proof is valid and all the data has been
-submitted, and the rollup's state is also updated in the contract.
+sent to the L1 contract alongside the necessary data. On the L1 a [smart contract](./l1_smart_contracts.md) verifies
+that the proof is valid and all the data has been submitted, and the rollup's state is also updated in the contract.
 
 ![Components](./img/L2_Components.png)
 

docs/specs/prover/circuit_testing.md

@@ -27,7 +27,7 @@ constraint system. Next, we define a helper function:
 To help run the test, we have a helper function called configure that returns a builder. The builder knows all of the
 gates and gate placement strategy, which will be useful for setting up the constraint system.
 
-![Contest(6).png](<./img/img/circuit_testing/Contest(6).png>)
+![Contest(6).png](<./img/circuit_testing/Contest(6).png>)
 
 The constaint system is almost ready! We still need to add the lookup tables for common boolean functions:
 

docs/specs/prover/overview.md

@@ -57,7 +57,7 @@ is described in more detail in
 
 The process of turning code into constraints is called arithmetization. Our arithmetization is based on a variation of
 “Plonk”. The details are abstracted away from the circuits, but if you’d like to learn more, read about Plonk in
-[Vitalik’s blog](https://vitalik.ca/general/2019/09/22/plonk.html) or the
+[Vitalik’s blog](https://vitalik.eth.limo/general/2019/09/22/plonk.html) or the
 [Plonky2 paper](https://github.com/mir-protocol/plonky2/blob/main/plonky2/plonky2.pdf).
 
 More details of our proving system can be found in the [Redshift Paper](https://eprint.iacr.org/2019/1400.pdf).

docs/specs/the_hyperchain/overview.md

@@ -1,6 +1,6 @@
 # Overview
 
-ZK Stack roll chains will be launched on L1 into a [shared bridge](./the_hyperchain/shared_bridge.md). The shared bridge
-will create an ecosystem of chains, with shared standards, upgrades, and free flow of assets. This free flow of assets
-will be enabled by [hyperbridges](./the_hyperchain/hyperbridges.md). Hyperbridges are trustless and cheap bridges
-between hyperchains, allowing cross-chain function calls.
+ZK Stack roll chains will be launched on L1 into a [shared bridge](./shared_bridge.md). The shared bridge will create an
+ecosystem of chains, with shared standards, upgrades, and free flow of assets. This free flow of assets will be enabled
+by [hyperbridges](./hyperbridges.md). Hyperbridges are trustless and cheap bridges between hyperchains, allowing
+cross-chain function calls.

docs/specs/zk_evm/bootloader.md

@@ -298,8 +298,9 @@ L1->L2 transactions are transactions that were initiated on L1. We assume that `
 transactions. It also has its L1 pubdata price as well as ergsPrice set on L1.
 
 Most of the steps from the execution of L2 transactions are omitted and we set `tx.origin` to the `from`, and
-`ergsPrice` to the one provided by transaction. After that, we use [mimicCall](#zksync-specific-opcodes) to provide the
-operation itself from the name of the sender account.
+`ergsPrice` to the one provided by transaction. After that, we use
+[mimicCall](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/advanced/0_alternative_vm_intro.md#zkevm-specific-opcodes)
+to provide the operation itself from the name of the sender account.
 
 Note, that for L1→L2 transactions, `reserved0` field denotes the amount of ETH that should be minted on L2 as a result
 of this transaction. `reserved1` is the refund receiver address, i.e. the address that would receive the refund for the