diff --git a/core/node/consensus/src/en.rs b/core/node/consensus/src/en.rs index e417b68cf2cb..2bddc3280362 100644 --- a/core/node/consensus/src/en.rs +++ b/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)); diff --git a/docs/src/announcements/attester_commitee.md b/docs/src/announcements/attester_commitee.md index 148e51a4f976..aa1274156df2 100644 --- a/docs/src/announcements/attester_commitee.md +++ b/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] > diff --git a/docs/src/guides/advanced/07_fee_model.md b/docs/src/guides/advanced/07_fee_model.md index 4592c5007ea2..4c5143f7e8e9 100644 --- a/docs/src/guides/advanced/07_fee_model.md +++ b/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 diff --git a/docs/src/guides/advanced/12_alternative_vm_intro.md b/docs/src/guides/advanced/12_alternative_vm_intro.md index a36f0b560d33..e91f8c4a6106 100644 --- a/docs/src/guides/advanced/12_alternative_vm_intro.md +++ b/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. diff --git a/docs/src/guides/advanced/13_zk_intuition.md b/docs/src/guides/advanced/13_zk_intuition.md index cee4dcfd1797..ac1e9a80e4c7 100644 --- a/docs/src/guides/advanced/13_zk_intuition.md +++ b/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]: diff --git a/docs/src/guides/advanced/15_prover_keys.md b/docs/src/guides/advanced/15_prover_keys.md index 5a3a264e8ddd..221b51053317 100644 --- a/docs/src/guides/advanced/15_prover_keys.md +++ b/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]: diff --git a/docs/src/guides/external-node/03_running.md b/docs/src/guides/external-node/03_running.md index caa528238aea..9d72f66732a0 100644 --- a/docs/src/guides/external-node/03_running.md +++ b/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 --dbname=`. 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) diff --git a/docs/src/guides/external-node/10_decentralization.md b/docs/src/guides/external-node/10_decentralization.md index 951538e6ab86..d878ee68d401 100644 --- a/docs/src/guides/external-node/10_decentralization.md +++ b/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]