diff --git a/README.md b/README.md index b149b5bc584..4d658d75d44 100644 --- a/README.md +++ b/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 ) -- MIT license ([LICENSE-MIT](LICENSE-MIT) or ) +- MIT license ([LICENSE-MIT](LICENSE-MIT) or ) at your option. diff --git a/checks-config/era.cfg b/checks-config/era.cfg index ea5b65543f8..c8a6baba820 100644 --- a/checks-config/era.cfg +++ b/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 = ["."] diff --git a/core/CHANGELOG.md b/core/CHANGELOG.md index 64f010e72dd..25e51fef18e 100644 --- a/core/CHANGELOG.md +++ b/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) diff --git a/core/lib/crypto/README.md b/core/lib/crypto/README.md index 2a4f3d4b9c5..e224b2732d3 100644 --- a/core/lib/crypto/README.md +++ b/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. diff --git a/core/lib/state/README.md b/core/lib/state/README.md index 0e98203bc47..fd01452aed3 100644 --- a/core/lib/state/README.md +++ b/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 diff --git a/core/tests/vm-benchmark/README.md b/core/tests/vm-benchmark/README.md index 62d65b4dd80..cecbdb31d0c 100644 --- a/core/tests/vm-benchmark/README.md +++ b/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 diff --git a/docs/guides/advanced/0_alternative_vm_intro.md b/docs/guides/advanced/0_alternative_vm_intro.md index b3acf810b46..74e70edc953 100644 --- a/docs/guides/advanced/0_alternative_vm_intro.md +++ b/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. diff --git a/docs/guides/advanced/how_l2_messaging_works.md b/docs/guides/advanced/how_l2_messaging_works.md index 3bae11fc59d..0fea2be7d50 100644 --- a/docs/guides/advanced/how_l2_messaging_works.md +++ b/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 diff --git a/docs/guides/advanced/pubdata.md b/docs/guides/advanced/pubdata.md index b5cbe6b49b5..f0e159a8010 100644 --- a/docs/guides/advanced/pubdata.md +++ b/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 `[, ]` (starting from an empty state) then we can assume that the next time a write happens to diff --git a/docs/guides/advanced/zk_intuition.md b/docs/guides/advanced/zk_intuition.md index 47f6e6d43b1..e567ebf7ca8 100644 --- a/docs/guides/advanced/zk_intuition.md +++ b/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 diff --git a/docs/guides/launch.md b/docs/guides/launch.md index 6402bedc3fb..17898e3350b 100644 --- a/docs/guides/launch.md +++ b/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: diff --git a/docs/guides/repositories.md b/docs/guides/repositories.md index a22e46ec11a..154f0bccdd5 100644 --- a/docs/guides/repositories.md +++ b/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 | diff --git a/docs/specs/overview.md b/docs/specs/overview.md index 2ac88709091..0f87d91c5c7 100644 --- a/docs/specs/overview.md +++ b/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) diff --git a/docs/specs/prover/circuit_testing.md b/docs/specs/prover/circuit_testing.md index e0e59caf819..4c8a2a5f210 100644 --- a/docs/specs/prover/circuit_testing.md +++ b/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: diff --git a/docs/specs/prover/overview.md b/docs/specs/prover/overview.md index 2a1a6f89bdc..a6025e23bb8 100644 --- a/docs/specs/prover/overview.md +++ b/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). diff --git a/docs/specs/the_hyperchain/overview.md b/docs/specs/the_hyperchain/overview.md index 13f27acba94..f31c4da99f1 100644 --- a/docs/specs/the_hyperchain/overview.md +++ b/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. diff --git a/docs/specs/zk_evm/bootloader.md b/docs/specs/zk_evm/bootloader.md index 9a4b3f81b15..ec7f8378151 100644 --- a/docs/specs/zk_evm/bootloader.md +++ b/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 diff --git a/docs/specs/zk_evm/system_contracts.md b/docs/specs/zk_evm/system_contracts.md index f0e1f182de9..393c38db6c4 100644 --- a/docs/specs/zk_evm/system_contracts.md +++ b/docs/specs/zk_evm/system_contracts.md @@ -122,7 +122,8 @@ Whenever anyone wants to do a non-zero value call, they need to call `MsgValueSi - Pass `value` and whether the call should be marked with `isSystem` in the first extra abi params. - Pass the address of the callee in the second extraAbiParam. -More information on the extraAbiParams can be read [here](#flags-for-calls). +More information on the extraAbiParams can be read +[here](../../guides/advanced/0_alternative_vm_intro.md#flags-for-calls). ## KnownCodeStorage @@ -145,7 +146,7 @@ It is the responsibility of the [ContractDeployer](#contractdeployer--immutables those code hashes that are known. The KnownCodesStorage contract is also responsible for ensuring that all the “known” bytecode hashes are also -[valid](#bytecode-validity). +[valid](../../guides/advanced/0_alternative_vm_intro.md#bytecode-validity). ## ContractDeployer & ImmutableSimulator @@ -204,7 +205,8 @@ On Ethereum, the constructor is only part of the initCode that gets executed dur returns the deployment code of the contract. On zkSync, there is no separation between deployed code and constructor code. The constructor is always a part of the deployment code of the contract. In order to protect it from being called, the compiler-generated contracts invoke constructor only if the `isConstructor` flag provided (it is only available for -the system contracts). You can read more about flags [here](#flags-for-calls). +the system contracts). You can read more about flags +[here](../../guides/advanced/0_alternative_vm_intro.md#flags-for-calls). After execution, the constructor must return an array of: @@ -226,7 +228,8 @@ address. Whenever a contract needs to access a value of some immutable, they call the `ImmutableSimulator.getImmutable(getCodeAddress(), index)`. Note that on zkSync it is possible to get the current -execution address (you can read more about `getCodeAddress()` [here](#zksync-specific-opcodes). +execution address you can read more about `getCodeAddress()` +[here](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/advanced/0_alternative_vm_intro.md#zkevm-specific-opcodes). ### **Return value of the deployment methods** diff --git a/docs/specs/zk_evm/vm_overview.md b/docs/specs/zk_evm/vm_overview.md index 3d7062cfb1f..51d0e74cbf1 100644 --- a/docs/specs/zk_evm/vm_overview.md +++ b/docs/specs/zk_evm/vm_overview.md @@ -19,10 +19,9 @@ confused with the [precompiles](./precompiles.md), which are also pre-deployed c zkEVM, but these contract do not have special permissions and are called by the users and not the Bootloader. The zkEVM also has user-facing features. For the best possible UX the ZK Stack supports native -[account abstraction](./zkEVM/high_level/account_abstraction.md). This means users can fully customize how they pay the -fees needed to execute their transactions. +[account abstraction](./account_abstraction.md). This means users can fully customize how they pay the fees needed to +execute their transactions. All transactions need to pay fees. The requirements to run a rollup are different than the ones needed to run Ethereum, -so the ZK Stack has a different [fee model](./zkEVM/high_level/fee_model/fee_model.md). The fee model is designed to -consider all the components that are needed to run the rollup: data and proof execution costs on L1, sequencer costs, -and prover costs. +so the ZK Stack has a different [fee model](./fee_model.md). The fee model is designed to consider all the components +that are needed to run the rollup: data and proof execution costs on L1, sequencer costs, and prover costs. diff --git a/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/block.md b/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/block.md index 61fe1479b4b..228a80d4851 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/block.md +++ b/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/block.md @@ -14,7 +14,7 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs) runtime function. ## [COINBASE](https://www.evm.codes/#41?fork=shanghai) @@ -22,7 +22,7 @@ runtime function. ### System Contract This information is requested a System Contract called -[SystemContext](.https://github.com/code-423n4/2023-10-zksync/blob/main/code/system-contracts/contracts/SystemContext.sol). +[SystemContext](https://github.com/matter-labs/era-contracts/blob/main/system-contracts/contracts/SystemContext.sol). On how the System Contract is called, see [this section](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/system_contracts.md#environmental-data-storage). @@ -33,7 +33,7 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs) runtime function. ## [TIMESTAMP](https://www.evm.codes/#42?fork=shanghai) @@ -52,7 +52,7 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs#L137) runtime function. ## [NUMBER](https://www.evm.codes/#43?fork=shanghai) @@ -71,7 +71,7 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs#L137) runtime function. ## [PREVRANDAO](https://www.evm.codes/#44?fork=shanghai) | [DIFFICULTY](https://www.evm.codes/#44?fork=grayGlacier) @@ -90,7 +90,7 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs#L137) runtime function. ## [GASLIMIT](https://www.evm.codes/#45?fork=shanghai) @@ -109,7 +109,7 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs#L137) runtime function. ## [CHAINID](https://www.evm.codes/#46?fork=shanghai) @@ -128,7 +128,7 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs#L137) runtime function. ## [SELFBALANCE](https://www.evm.codes/#47?fork=shanghai) @@ -155,5 +155,5 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs#L137) runtime function. diff --git a/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/environment.md b/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/environment.md index 117a68cbb91..56be086cc7a 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/environment.md +++ b/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/environment.md @@ -23,7 +23,7 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs) runtime function. ## [ORIGIN](https://www.evm.codes/#32?fork=shanghai) @@ -42,7 +42,7 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs#L137) runtime function. ## [CALLER](https://www.evm.codes/#33?fork=shanghai) @@ -186,7 +186,7 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs#L137) runtime function. ## [EXTCODESIZE](https://www.evm.codes/#3b?fork=shanghai) @@ -205,7 +205,7 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs#L137) runtime function. ## [EXTCODECOPY](https://www.evm.codes/#3c?fork=shanghai) @@ -290,5 +290,5 @@ On how the System Contract is called, see is common for Yul and EVMLA representations. The request to the System Contract is done via the -[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs) +[SystemRequest](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs#L137) runtime function. diff --git a/docs/specs/zk_evm/vm_specification/compiler/system_contracts.md b/docs/specs/zk_evm/vm_specification/compiler/system_contracts.md index 96f370f986b..ca93cb6eb31 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/system_contracts.md +++ b/docs/specs/zk_evm/vm_specification/compiler/system_contracts.md @@ -38,7 +38,7 @@ Steps to handle such instructions: 6. Return the value as the result of the original instruction. For reference, see -[the LLVM IR codegen source code](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/runtime/system_request.rs). +[the LLVM IR codegen source code](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs). ### KECCAK256 Hash Function diff --git a/prover/prover_fri/README.md b/prover/prover_fri/README.md index 6ee00b9fbd0..54d678a39ab 100644 --- a/prover/prover_fri/README.md +++ b/prover/prover_fri/README.md @@ -43,8 +43,9 @@ flowchart LR ### Prerequisites -Make sure these dependencies are installed and available on your machine: [Installing dependencies](./setup-dev.md) Once -that is done, before starting, make sure you go into the root of the repository, then run +Make sure these dependencies are installed and available on your machine: +[Installing dependencies](../../docs/guides/setup-dev.md) Once that is done, before starting, make sure you go into the +root of the repository, then run ``` export ZKSYNC_HOME=$(pwd) @@ -231,8 +232,8 @@ Performing circuit upgrade requires crypto library to be updated and generating finalization hints if the circuit changes. Below steps can be used to perform circuit upgrade: 1. checkout if the circuit geometry has changed in the new version of the circuit by running the - [workflow](https://github.com/matter-labs/zkevm_test_harness/actions/workflows/geometry-config-generator.yml) in - harness and merge the generated PR. + [workflow](https://github.com/matter-labs/era-zkevm_test_harness/blob/v1.4.0/.github/workflows/.github/workflows/geometry-config-generator.yml) + in harness and merge the generated PR. 2. update the relevant crypto dependencies(boojum, zkevm_circuit, harness, etc) in `Cargo.lock`, for example: `cargo update -p zkevm_test_harness@1.4.0` 3. prepare an PR with the updated dependencies [sample PR](https://github.com/matter-labs/zksync-2-dev/pull/2481). @@ -250,8 +251,5 @@ finalization hints if the circuit changes. Below steps can be used to perform ci PR to generate the gpu setup data. 8. Once the setup data generation workflows are successful, update the PR with `setup_keys_id` id in [build-docker-from-tag.yml](../../.github/workflows/build-docker-from-tag.yml) and in - [fri-gpu-prover-integration-test.yml](../../.github/workflows/fri-gpu-prover-integration-test.yml), make sure to only - do it from `FRI prover` not old. -9. Run the GPU integration test - [workflow](https://github.com/matter-labs/zksync-era/actions/workflows/fri-gpu-prover-integration-test.yml) against - the PR to verify the GPU prover is working fine with new circuits. + [fri-gpu-prover-integration-test.yml](https://github.com/matter-labs/zksync-2-dev/blob/main/.github/workflows/fri-gpu-prover-integration-test.yml), + make sure to only do it from `FRI prover` not old.