diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 89789b081502..2676289d0f3a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -40,7 +40,7 @@ We aim to make it as easy as possible to contribute to the mission. This is stil and suggestions here too. Some resources to help: 1. [In-repo docs aimed at developers](docs) -2. [zkSync Era docs!](https://docs.zksync.io) +2. [ZKsync Era docs!](https://docs.zksync.io) 3. Company links can be found in the [repositories' readme](README.md) ## Code of Conduct diff --git a/README.md b/README.md index 4700b1b43a9e..013d932aa1ae 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,10 @@ -# zkSync Era: A ZK Rollup For Scaling Ethereum +# ZKsync Era: A ZK Rollup For Scaling Ethereum [![Logo](eraLogo.png)](https://zksync.io/) -zkSync Era is a layer 2 rollup that uses zero-knowledge proofs to scale Ethereum without compromising on security or +ZKsync Era is a layer 2 rollup that uses zero-knowledge proofs to scale Ethereum without compromising on security or decentralization. Since it's EVM compatible (Solidity/Vyper), 99% of Ethereum projects can redeploy without refactoring -or re-auditing a single line of code. zkSync Era also uses an LLVM-based compiler that will eventually let developers +or re-auditing a single line of code. ZKsync Era also uses an LLVM-based compiler that will eventually let developers write smart contracts in C++, Rust and other popular languages. ## Knowledge Index @@ -27,7 +27,7 @@ The following questions will be answered by the following resources: ## License -zkSync Era is distributed under the terms of either +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 <https://opensource.org/blog/license/mit/>) @@ -47,7 +47,7 @@ at your option. ## Disclaimer -zkSync Era has been through lots of testing and audits. Although it is live, it is still in alpha state and will go +ZKsync Era has been through lots of testing and audits. Although it is live, it is still in alpha state and will go through more audits and bug bounty programs. We would love to hear our community's thoughts and suggestions about it! It is important to state that forking it now can potentially lead to missing important security updates, critical features, and performance improvements. diff --git a/checks-config/era.dic b/checks-config/era.dic index 0b55a55c83ea..3f4c8fc8fa4f 100644 --- a/checks-config/era.dic +++ b/checks-config/era.dic @@ -135,7 +135,7 @@ boolean prover timestamp H160 -zkSync +ZKsync AccessList miniblock member₁ @@ -212,7 +212,7 @@ EOAs zeroized cardinality -// zkSync-related words +// ZKsync-related words matterlabs zkweb zksync @@ -610,7 +610,7 @@ DBs unexecutable RLP DAL -zkSync's +ZKsync's l2_to_l1 PoW coinbase diff --git a/core/bin/contract-verifier/src/main.rs b/core/bin/contract-verifier/src/main.rs index 5789422641c8..118e7f41be97 100644 --- a/core/bin/contract-verifier/src/main.rs +++ b/core/bin/contract-verifier/src/main.rs @@ -112,7 +112,7 @@ async fn update_compiler_versions(connection_pool: &ConnectionPool<Core>) { use zksync_config::configs::DatabaseSecrets; #[derive(StructOpt)] -#[structopt(name = "zkSync contract code verifier", author = "Matter Labs")] +#[structopt(name = "ZKsync contract code verifier", author = "Matter Labs")] struct Opt { /// Number of jobs to process. If None, runs indefinitely. #[structopt(long)] diff --git a/core/bin/external_node/README.md b/core/bin/external_node/README.md index d6fa78dbd3d3..335ceed7b719 100644 --- a/core/bin/external_node/README.md +++ b/core/bin/external_node/README.md @@ -1,4 +1,4 @@ -# zkSync External Node +# ZKsync External Node This application is a read replica that can sync from the main node and serve the state locally. diff --git a/core/bin/external_node/src/config/mod.rs b/core/bin/external_node/src/config/mod.rs index e329150721c0..9cd6a758a25c 100644 --- a/core/bin/external_node/src/config/mod.rs +++ b/core/bin/external_node/src/config/mod.rs @@ -647,7 +647,7 @@ pub(crate) struct RequiredENConfig { /// L1 chain ID (e.g., 9 for Ethereum mainnet). This ID will be checked against the `eth_client_url` RPC provider on initialization /// to ensure that there's no mismatch between the expected and actual L1 network. pub l1_chain_id: L1ChainId, - /// L2 chain ID (e.g., 270 for zkSync Era mainnet). This ID will be checked against the `main_node_url` RPC provider on initialization + /// L2 chain ID (e.g., 270 for ZKsync Era mainnet). This ID will be checked against the `main_node_url` RPC provider on initialization /// to ensure that there's no mismatch between the expected and actual L2 network. pub l2_chain_id: L2ChainId, diff --git a/core/bin/external_node/src/main.rs b/core/bin/external_node/src/main.rs index 04435f66bf4b..0adf3ddf8cb5 100644 --- a/core/bin/external_node/src/main.rs +++ b/core/bin/external_node/src/main.rs @@ -692,7 +692,7 @@ async fn shutdown_components( Ok(()) } -/// External node for zkSync Era. +/// External node for ZKsync Era. #[derive(Debug, Parser)] #[command(author = "Matter Labs", version)] struct Cli { diff --git a/core/bin/zksync_server/src/main.rs b/core/bin/zksync_server/src/main.rs index c51cc5380253..1c54895863c0 100644 --- a/core/bin/zksync_server/src/main.rs +++ b/core/bin/zksync_server/src/main.rs @@ -38,7 +38,7 @@ mod node_builder; #[global_allocator] static GLOBAL: tikv_jemallocator::Jemalloc = tikv_jemallocator::Jemalloc; #[derive(Debug, Parser)] -#[command(author = "Matter Labs", version, about = "zkSync operator node", long_about = None)] +#[command(author = "Matter Labs", version, about = "ZKsync operator node", long_about = None)] struct Cli { /// Generate genesis block for the first contract deployment using temporary DB. #[arg(long)] diff --git a/core/lib/basic_types/src/lib.rs b/core/lib/basic_types/src/lib.rs index 5c54b0a21696..a55705886c55 100644 --- a/core/lib/basic_types/src/lib.rs +++ b/core/lib/basic_types/src/lib.rs @@ -1,4 +1,4 @@ -//! The declaration of the most primitive types used in zkSync network. +//! The declaration of the most primitive types used in ZKsync network. //! //! Most of them are just re-exported from the `web3` crate. @@ -86,7 +86,7 @@ impl TryFrom<U256> for AccountTreeId { } } -/// ChainId in the zkSync network. +/// ChainId in the ZKsync network. #[derive(Copy, Clone, Debug, Serialize, PartialEq, Eq, PartialOrd, Ord, Hash)] pub struct L2ChainId(u64); @@ -183,13 +183,13 @@ impl From<u32> for L2ChainId { } basic_type!( - /// zkSync network block sequential index. + /// ZKsync network block sequential index. L2BlockNumber, u32 ); basic_type!( - /// zkSync L1 batch sequential index. + /// ZKsync L1 batch sequential index. L1BatchNumber, u32 ); @@ -201,13 +201,13 @@ basic_type!( ); basic_type!( - /// zkSync account nonce. + /// ZKsync account nonce. Nonce, u32 ); basic_type!( - /// Unique identifier of the priority operation in the zkSync network. + /// Unique identifier of the priority operation in the ZKsync network. PriorityOpId, u64 ); diff --git a/core/lib/basic_types/src/network.rs b/core/lib/basic_types/src/network.rs index 5f4683aeb672..cfa82e8c8464 100644 --- a/core/lib/basic_types/src/network.rs +++ b/core/lib/basic_types/src/network.rs @@ -1,4 +1,4 @@ -//! The network where the zkSync resides. +//! The network where the ZKsync resides. //! // Built-in uses @@ -12,7 +12,7 @@ use crate::L1ChainId; // Local uses -/// Network to be used for a zkSync client. +/// Network to be used for a ZKsync client. #[derive(Debug, Serialize, Deserialize, Clone, Copy, PartialEq, Eq)] #[serde(rename_all = "camelCase")] pub enum Network { diff --git a/core/lib/config/src/configs/chain.rs b/core/lib/config/src/configs/chain.rs index ade0f9d4226f..c1abd1fea102 100644 --- a/core/lib/config/src/configs/chain.rs +++ b/core/lib/config/src/configs/chain.rs @@ -9,11 +9,11 @@ use zksync_basic_types::{ pub struct NetworkConfig { /// Name of the used Ethereum network, e.g. `localhost` or `rinkeby`. pub network: Network, - /// Name of current zkSync network + /// Name of current ZKsync network /// Used for Sentry environment pub zksync_network: String, - /// ID of current zkSync network treated as ETH network ID. - /// Used to distinguish zkSync from other Web3-capable networks. + /// ID of current ZKsync network treated as ETH network ID. + /// Used to distinguish ZKsync from other Web3-capable networks. pub zksync_network_id: L2ChainId, } @@ -29,10 +29,10 @@ impl NetworkConfig { } /// An enum that represents the version of the fee model to use. -/// - `V1`, the first model that was used in zkSync Era. In this fee model, the pubdata price must be pegged to the L1 gas price. +/// - `V1`, the first model that was used in ZKsync Era. In this fee model, the pubdata price must be pegged to the L1 gas price. /// Also, the fair L2 gas price is expected to only include the proving/computation price for the operator and not the costs that come from /// processing the batch on L1. -/// - `V2`, the second model that was used in zkSync Era. There the pubdata price might be independent from the L1 gas price. Also, +/// - `V2`, the second model that was used in ZKsync Era. There the pubdata price might be independent from the L1 gas price. Also, /// The fair L2 gas price is expected to both the proving/computation price for the operator and the costs that come from /// processing the batch on L1. #[derive(Debug, Clone, Copy, Deserialize, PartialEq, Eq)] diff --git a/core/lib/crypto/README.md b/core/lib/crypto/README.md index e224b2732d34..38b5a306a9bd 100644 --- a/core/lib/crypto/README.md +++ b/core/lib/crypto/README.md @@ -1,10 +1,10 @@ -# zkSync crypto. Essential cryptography primitives for the zkSync network +# ZKsync crypto. Essential cryptography primitives for the ZKsync network -`zksync_crypto` is a crate containing essential zkSync cryptographic primitives, such as private keys and hashers. +`zksync_crypto` is a crate containing essential ZKsync cryptographic primitives, such as private keys and hashers. ## License -`zksync_crypto` is a part of zkSync stack, which is distributed under the terms of both the MIT license and the Apache +`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. diff --git a/core/lib/crypto_primitives/src/eip712_signature/typed_structure.rs b/core/lib/crypto_primitives/src/eip712_signature/typed_structure.rs index 1315ccb06a26..a08273c0a037 100644 --- a/core/lib/crypto_primitives/src/eip712_signature/typed_structure.rs +++ b/core/lib/crypto_primitives/src/eip712_signature/typed_structure.rs @@ -160,7 +160,7 @@ impl Eip712Domain { pub const NAME: &'static str = "zkSync"; /// Version of the protocol. While there may be `2.x` releases, the minor release version bump /// should not be breaking, meaning that clients from the `2.x-1` version should be able to communicate - /// with zkSync server. Thus `VERSION` corresponds to the major version only. + /// with ZKsync server. Thus `VERSION` corresponds to the major version only. pub const VERSION: &'static str = "2"; pub fn new(chain_id: L2ChainId) -> Self { diff --git a/core/lib/dal/src/lib.rs b/core/lib/dal/src/lib.rs index 45d1f94b486d..0a2ed3bdd641 100644 --- a/core/lib/dal/src/lib.rs +++ b/core/lib/dal/src/lib.rs @@ -1,4 +1,4 @@ -//! Data access layer (DAL) for zkSync Era. +//! Data access layer (DAL) for ZKsync Era. // Linter settings. #![warn(clippy::cast_lossless)] diff --git a/core/lib/eth_client/src/lib.rs b/core/lib/eth_client/src/lib.rs index 2adac587b66c..6e24047dd48c 100644 --- a/core/lib/eth_client/src/lib.rs +++ b/core/lib/eth_client/src/lib.rs @@ -152,7 +152,7 @@ pub trait EthInterface: Sync + Send { /// /// The example use cases for this trait would be: /// -/// - An operator that sends transactions and interacts with zkSync contract. +/// - An operator that sends transactions and interacts with ZKsync contract. /// - A wallet implementation in the SDK that is tied to a user's account. /// /// When adding a method to this trait: diff --git a/core/lib/l1_contract_interface/src/lib.rs b/core/lib/l1_contract_interface/src/lib.rs index fc96347bf70b..26a9aefa9f1e 100644 --- a/core/lib/l1_contract_interface/src/lib.rs +++ b/core/lib/l1_contract_interface/src/lib.rs @@ -1,4 +1,4 @@ -//! Utilities for interacting with the zkSync L1 contract +//! Utilities for interacting with the ZKsync L1 contract //! //! Provides utilities both to encode input data for the contract and to decode //! the data provided by the contract. diff --git a/core/lib/state/src/lib.rs b/core/lib/state/src/lib.rs index 1359e62824f5..b01d4fd35375 100644 --- a/core/lib/state/src/lib.rs +++ b/core/lib/state/src/lib.rs @@ -1,4 +1,4 @@ -//! Execution of transaction in zkSync Era +//! Execution of transaction in ZKsync Era // Linter settings. #![warn(missing_debug_implementations, missing_docs, bare_trait_objects)] diff --git a/core/lib/types/src/api/mod.rs b/core/lib/types/src/api/mod.rs index 6e22e17de673..ce21a754c7aa 100644 --- a/core/lib/types/src/api/mod.rs +++ b/core/lib/types/src/api/mod.rs @@ -89,7 +89,7 @@ impl<'de> Deserialize<'de> for BlockNumber { } } -/// Block unified identifier in terms of zkSync +/// Block unified identifier in terms of ZKsync /// /// This is an utility structure that cannot be (de)serialized, it has to be created manually. /// The reason is because Web3 API provides multiple methods for referring block either by hash or number, diff --git a/core/lib/types/src/block.rs b/core/lib/types/src/block.rs index c9b1c528f7e3..221b9b4d63ff 100644 --- a/core/lib/types/src/block.rs +++ b/core/lib/types/src/block.rs @@ -200,7 +200,7 @@ pub struct L2BlockHasher { } impl L2BlockHasher { - /// At the beginning of the zkSync, the hashes of the blocks could be calculated as the hash of their number. + /// At the beginning of the ZKsync, the hashes of the blocks could be calculated as the hash of their number. /// This method returns the hash of such L2 blocks. pub fn legacy_hash(l2_block_number: L2BlockNumber) -> H256 { H256(keccak256(&l2_block_number.0.to_be_bytes())) diff --git a/core/lib/types/src/commitment/mod.rs b/core/lib/types/src/commitment/mod.rs index 7c4184e5e189..61c2d7b5ea27 100644 --- a/core/lib/types/src/commitment/mod.rs +++ b/core/lib/types/src/commitment/mod.rs @@ -1,7 +1,7 @@ //! Data structures that have more metadata than their primary versions declared in this crate. //! For example, L1 batch defined here has the `root_hash` field which is absent in `L1BatchHeader`. //! -//! Existence of this module is caused by the execution model of zkSync: when executing transactions, +//! Existence of this module is caused by the execution model of ZKsync: when executing transactions, //! we aim to avoid expensive operations like the state root hash recalculation. State root hash is not //! required for the rollup to execute L1 batches, it's needed for the proof generation and the Ethereum //! transactions, thus the calculations are done separately and asynchronously. diff --git a/core/lib/types/src/fee.rs b/core/lib/types/src/fee.rs index 5f32beb2fd4c..524015cdd095 100644 --- a/core/lib/types/src/fee.rs +++ b/core/lib/types/src/fee.rs @@ -57,9 +57,9 @@ impl Default for TransactionExecutionMetrics { pub struct Fee { /// The limit of gas that are to be spent on the actual transaction. pub gas_limit: U256, - /// zkSync version of EIP1559 maxFeePerGas. + /// ZKsync version of EIP1559 maxFeePerGas. pub max_fee_per_gas: U256, - /// zkSync version of EIP1559 maxPriorityFeePerGas. + /// ZKsync version of EIP1559 maxPriorityFeePerGas. pub max_priority_fee_per_gas: U256, /// The maximal gas per pubdata byte the user agrees to. pub gas_per_pubdata_limit: U256, diff --git a/core/lib/types/src/fee_model.rs b/core/lib/types/src/fee_model.rs index 79c9a94eda9f..9c2cc4d2aaf8 100644 --- a/core/lib/types/src/fee_model.rs +++ b/core/lib/types/src/fee_model.rs @@ -157,10 +157,10 @@ pub struct PubdataIndependentBatchFeeModelInput { } /// The enum which represents the version of the fee model. It is used to determine which fee model should be used for the batch. -/// - `V1`, the first model that was used in zkSync Era. In this fee model, the pubdata price must be pegged to the L1 gas price. +/// - `V1`, the first model that was used in ZKsync Era. In this fee model, the pubdata price must be pegged to the L1 gas price. /// Also, the fair L2 gas price is expected to only include the proving/computation price for the operator and not the costs that come from /// processing the batch on L1. -/// - `V2`, the second model that was used in zkSync Era. There the pubdata price might be independent from the L1 gas price. Also, +/// - `V2`, the second model that was used in ZKsync Era. There the pubdata price might be independent from the L1 gas price. Also, /// The fair L2 gas price is expected to both the proving/computation price for the operator and the costs that come from /// processing the batch on L1. #[derive(Debug, Clone, Copy, Serialize, Deserialize)] diff --git a/core/lib/types/src/l1/mod.rs b/core/lib/types/src/l1/mod.rs index 348600b6ee89..05f08987a2d3 100644 --- a/core/lib/types/src/l1/mod.rs +++ b/core/lib/types/src/l1/mod.rs @@ -1,4 +1,4 @@ -//! Definition of zkSync network priority operations: operations initiated from the L1. +//! Definition of ZKsync network priority operations: operations initiated from the L1. use std::convert::TryFrom; @@ -119,7 +119,7 @@ pub struct L1TxCommonData { pub op_processing_type: OpProcessingType, /// Priority operations queue type. pub priority_queue_type: PriorityQueueType, - /// Tx hash of the transaction in the zkSync network. Calculated as the encoded transaction data hash. + /// Tx hash of the transaction in the ZKsync network. Calculated as the encoded transaction data hash. pub canonical_tx_hash: H256, /// The amount of ETH that should be minted with this transaction pub to_mint: U256, diff --git a/core/lib/types/src/l2/mod.rs b/core/lib/types/src/l2/mod.rs index 57edc6181c8a..5a5276407529 100644 --- a/core/lib/types/src/l2/mod.rs +++ b/core/lib/types/src/l2/mod.rs @@ -31,7 +31,7 @@ pub enum TransactionType { LegacyTransaction = 0, EIP2930Transaction = 1, EIP1559Transaction = 2, - // EIP 712 transaction with additional fields specified for zkSync + // EIP 712 transaction with additional fields specified for ZKsync EIP712Transaction = EIP_712_TX_TYPE as u32, PriorityOpTransaction = PRIORITY_OPERATION_L2_TX_TYPE as u32, ProtocolUpgradeTransaction = PROTOCOL_UPGRADE_TX_TYPE as u32, diff --git a/core/lib/types/src/lib.rs b/core/lib/types/src/lib.rs index 2617bf0e4984..3c3a96c297d7 100644 --- a/core/lib/types/src/lib.rs +++ b/core/lib/types/src/lib.rs @@ -1,6 +1,6 @@ -//! zkSync types: essential type definitions for zkSync network. +//! ZKsync types: essential type definitions for ZKsync network. //! -//! `zksync_types` is a crate containing essential zkSync network types, such as transactions, operations and +//! `zksync_types` is a crate containing essential ZKsync network types, such as transactions, operations and //! blockchain primitives. #![allow(clippy::upper_case_acronyms, clippy::derive_partial_eq_without_eq)] @@ -63,7 +63,7 @@ pub mod proto; pub mod transaction_request; pub mod utils; -/// Denotes the first byte of the special zkSync's EIP-712-signed transaction. +/// Denotes the first byte of the special ZKsync's EIP-712-signed transaction. pub const EIP_712_TX_TYPE: u8 = 0x71; /// Denotes the first byte of the `EIP-1559` transaction. diff --git a/core/lib/types/src/protocol_upgrade.rs b/core/lib/types/src/protocol_upgrade.rs index c1bcc2f5cace..c0d7267ebfae 100644 --- a/core/lib/types/src/protocol_upgrade.rs +++ b/core/lib/types/src/protocol_upgrade.rs @@ -352,7 +352,7 @@ pub struct ProtocolUpgradeTxCommonData { pub gas_per_pubdata_limit: U256, /// Block in which Ethereum transaction was included. pub eth_block: u64, - /// Tx hash of the transaction in the zkSync network. Calculated as the encoded transaction data hash. + /// Tx hash of the transaction in the ZKsync network. Calculated as the encoded transaction data hash. pub canonical_tx_hash: H256, /// The amount of ETH that should be minted with this transaction pub to_mint: U256, diff --git a/core/lib/types/src/tokens.rs b/core/lib/types/src/tokens.rs index 26aec479498d..ddabaffa2319 100644 --- a/core/lib/types/src/tokens.rs +++ b/core/lib/types/src/tokens.rs @@ -9,7 +9,7 @@ pub struct TokenInfo { pub metadata: TokenMetadata, } -/// Relevant information about tokens supported by zkSync protocol. +/// Relevant information about tokens supported by ZKsync protocol. #[derive(Debug, Serialize, Deserialize, Clone, PartialEq)] pub struct TokenMetadata { /// Token name (e.g. "Ethereum" or "USD Coin") diff --git a/core/lib/types/src/tx/mod.rs b/core/lib/types/src/tx/mod.rs index 9bf38aa19555..7078f4ee3fe3 100644 --- a/core/lib/types/src/tx/mod.rs +++ b/core/lib/types/src/tx/mod.rs @@ -1,6 +1,6 @@ //! `transactions` is module that holds the essential information for every transaction. //! -//! Since in zkSync Era every operation can be executed either from the contract or rollup, +//! Since in ZKsync Era every operation can be executed either from the contract or rollup, //! it makes more sense to define the contents of each transaction chain-agnostic, and extent this data //! with metadata (such as fees and/or signatures) for L1 and L2 separately. diff --git a/core/lib/utils/src/lib.rs b/core/lib/utils/src/lib.rs index 1c17d4efe264..7f9304e3110c 100644 --- a/core/lib/utils/src/lib.rs +++ b/core/lib/utils/src/lib.rs @@ -1,4 +1,4 @@ -//! Various helpers used in the zkSync stack. +//! Various helpers used in the ZKsync stack. pub mod bytecode; mod convert; diff --git a/core/lib/web3_decl/src/client/network.rs b/core/lib/web3_decl/src/client/network.rs index dabde86678bf..2e7dcce9937f 100644 --- a/core/lib/web3_decl/src/client/network.rs +++ b/core/lib/web3_decl/src/client/network.rs @@ -52,7 +52,7 @@ impl From<L2ChainId> for L2 { } } -/// Associates a type with a particular type of RPC networks, such as Ethereum or zkSync Era. RPC traits created using `jsonrpsee::rpc` +/// Associates a type with a particular type of RPC networks, such as Ethereum or ZKsync Era. RPC traits created using `jsonrpsee::rpc` /// can use `ForNetwork` as a client boundary to restrict which implementations can call their methods. pub trait ForNetwork { /// Network that the type is associated with. diff --git a/core/lib/web3_decl/src/error.rs b/core/lib/web3_decl/src/error.rs index e80ea23d8e3a..1ea737a947f5 100644 --- a/core/lib/web3_decl/src/error.rs +++ b/core/lib/web3_decl/src/error.rs @@ -1,4 +1,4 @@ -//! Definition of errors that can occur in the zkSync Web3 API. +//! Definition of errors that can occur in the ZKsync Web3 API. use std::{ collections::HashMap, diff --git a/core/lib/web3_decl/src/lib.rs b/core/lib/web3_decl/src/lib.rs index 7146a87099ce..c104668d5977 100644 --- a/core/lib/web3_decl/src/lib.rs +++ b/core/lib/web3_decl/src/lib.rs @@ -1,4 +1,4 @@ -//! `zksync_web3_decl` is a collection of common types required for zkSync Web3 API +//! `zksync_web3_decl` is a collection of common types required for ZKsync Web3 API //! and also `jsonrpsee`-based declaration of server and client traits. //! //! Web3 namespaces are declared in `namespaces` module. diff --git a/core/lib/web3_decl/src/types.rs b/core/lib/web3_decl/src/types.rs index ec6bbed46883..41902e408e7a 100644 --- a/core/lib/web3_decl/src/types.rs +++ b/core/lib/web3_decl/src/types.rs @@ -3,7 +3,7 @@ //! Most of the types are re-exported from the `web3` crate, but some of them maybe extended with //! new variants (enums) or optional fields (structures). //! -//! These "extensions" are required to provide more zkSync-specific information while remaining Web3-compilant. +//! These "extensions" are required to provide more ZKsync-specific information while remaining Web3-compilant. use core::{ convert::{TryFrom, TryInto}, @@ -21,7 +21,7 @@ pub use zksync_types::{ Address, Transaction, H160, H256, H64, U256, U64, }; -/// Token in the zkSync network +/// Token in the ZKsync network #[derive(Clone, Debug, PartialEq, Serialize, Deserialize)] #[serde(rename_all = "camelCase")] pub struct Token { diff --git a/core/lib/zksync_core_leftovers/src/lib.rs b/core/lib/zksync_core_leftovers/src/lib.rs index 1ed84263c2d5..b4194f99f450 100644 --- a/core/lib/zksync_core_leftovers/src/lib.rs +++ b/core/lib/zksync_core_leftovers/src/lib.rs @@ -78,7 +78,7 @@ use zksync_web3_decl::client::{Client, DynClient, L1}; pub mod temp_config_store; -/// Inserts the initial information about zkSync tokens into the database. +/// Inserts the initial information about ZKsync tokens into the database. pub async fn genesis_init( genesis_config: GenesisConfig, database_secrets: &DatabaseSecrets, diff --git a/core/node/api_server/src/tx_sender/mod.rs b/core/node/api_server/src/tx_sender/mod.rs index 1dd3f4c6e941..a6bbbf9ffa04 100644 --- a/core/node/api_server/src/tx_sender/mod.rs +++ b/core/node/api_server/src/tx_sender/mod.rs @@ -1,4 +1,4 @@ -//! Helper module to submit transactions into the zkSync Network. +//! Helper module to submit transactions into the ZKsync Network. use std::{sync::Arc, time::Instant}; diff --git a/core/node/api_server/src/web3/namespaces/eth.rs b/core/node/api_server/src/web3/namespaces/eth.rs index d1801fde6e4d..397ce77c050f 100644 --- a/core/node/api_server/src/web3/namespaces/eth.rs +++ b/core/node/api_server/src/web3/namespaces/eth.rs @@ -840,17 +840,17 @@ impl EthNamespace { } pub fn uncle_count_impl(&self, _block: BlockId) -> Option<U256> { - // We don't have uncles in zkSync. + // We don't have uncles in ZKsync. Some(0.into()) } pub fn hashrate_impl(&self) -> U256 { - // zkSync is not a PoW chain. + // ZKsync is not a PoW chain. U256::zero() } pub fn mining_impl(&self) -> bool { - // zkSync is not a PoW chain. + // ZKsync is not a PoW chain. false } diff --git a/core/node/block_reverter/README.md b/core/node/block_reverter/README.md index 9d82fb0d189d..0c696dca4761 100644 --- a/core/node/block_reverter/README.md +++ b/core/node/block_reverter/README.md @@ -1,4 +1,4 @@ -# zkSync Era Block reverter +# ZKsync Era Block reverter -This crate contains functionality for rolling back state of a zkSync Era node and reverting committed L1 batches on +This crate contains functionality for rolling back state of a ZKsync Era node and reverting committed L1 batches on Ethereum. diff --git a/core/node/commitment_generator/README.md b/core/node/commitment_generator/README.md index da99ca9403a1..eaa5017e8f0d 100644 --- a/core/node/commitment_generator/README.md +++ b/core/node/commitment_generator/README.md @@ -1,4 +1,4 @@ -# zkSync Era commitment generator +# ZKsync Era commitment generator -This crate contains an implementation of the zkSync Era commitment generator component, which is responsible for the +This crate contains an implementation of the ZKsync Era commitment generator component, which is responsible for the calculation commitment info for L1 batches. diff --git a/core/node/consensus/src/era.rs b/core/node/consensus/src/era.rs index a8477a8bb672..0e73c29f7741 100644 --- a/core/node/consensus/src/era.rs +++ b/core/node/consensus/src/era.rs @@ -1,5 +1,5 @@ //! This module provides convenience functions to run consensus components in different modes -//! as expected by the zkSync Era. +//! as expected by the ZKsync Era. //! //! This module simply glues APIs that are already publicly exposed by the `consensus` module, //! so in case any custom behavior is needed, these APIs should be used directly. diff --git a/core/node/consistency_checker/src/lib.rs b/core/node/consistency_checker/src/lib.rs index 79ce137560c6..e4634c86e403 100644 --- a/core/node/consistency_checker/src/lib.rs +++ b/core/node/consistency_checker/src/lib.rs @@ -302,9 +302,9 @@ pub fn detect_da( #[derive(Debug)] pub struct ConsistencyChecker { - /// ABI of the zkSync contract + /// ABI of the ZKsync contract contract: ethabi::Contract, - /// Address of the zkSync diamond proxy on L1 + /// Address of the ZKsync diamond proxy on L1 diamond_proxy_addr: Option<Address>, /// How many past batches to check when starting max_batches_to_recheck: u32, @@ -382,7 +382,7 @@ impl ConsistencyChecker { let event = self .contract .event("BlockCommit") - .context("`BlockCommit` event not found for zkSync L1 contract") + .context("`BlockCommit` event not found for ZKsync L1 contract") .map_err(CheckError::Internal)?; let committed_batch_numbers_by_logs = diff --git a/core/node/eth_sender/src/tests.rs b/core/node/eth_sender/src/tests.rs index 00b02c2fe9b5..a3bb9951f44a 100644 --- a/core/node/eth_sender/src/tests.rs +++ b/core/node/eth_sender/src/tests.rs @@ -178,7 +178,7 @@ impl EthSenderTester { commitment_mode, ), gateway.clone(), - // zkSync contract address + // ZKsync contract address Address::random(), contracts_config.l1_multicall3_addr, Address::random(), diff --git a/core/node/eth_watch/README.md b/core/node/eth_watch/README.md index f805f3e4c389..5b4dd5c2ea0d 100644 --- a/core/node/eth_watch/README.md +++ b/core/node/eth_watch/README.md @@ -1,6 +1,6 @@ -# zkSync Era Eth Watcher +# ZKsync Era Eth Watcher -This crate contains an implementation of the zkSync Era Eth Watcher component, which fetches the changes from the +This crate contains an implementation of the ZKsync Era Eth Watcher component, which fetches the changes from the corresponding L1 contract. ## Overview diff --git a/core/node/eth_watch/src/client.rs b/core/node/eth_watch/src/client.rs index 604ea2f471cc..764573002996 100644 --- a/core/node/eth_watch/src/client.rs +++ b/core/node/eth_watch/src/client.rs @@ -57,7 +57,7 @@ impl EthHttpQueryClient { confirmations_for_eth_event: Option<u64>, ) -> Self { tracing::debug!( - "New eth client, zkSync addr: {:x}, governance addr: {:?}", + "New eth client, ZKsync addr: {:x}, governance addr: {:?}", diamond_proxy_addr, governance_address ); diff --git a/core/node/eth_watch/src/event_processors/governance_upgrades.rs b/core/node/eth_watch/src/event_processors/governance_upgrades.rs index d26cfe6dbd9b..72f5c411892f 100644 --- a/core/node/eth_watch/src/event_processors/governance_upgrades.rs +++ b/core/node/eth_watch/src/event_processors/governance_upgrades.rs @@ -14,7 +14,7 @@ use crate::{ /// Listens to operation events coming from the governance contract and saves new protocol upgrade proposals to the database. #[derive(Debug)] pub struct GovernanceUpgradesEventProcessor { - // zkSync diamond proxy + // ZKsync diamond proxy target_contract_address: Address, /// Last protocol version seen. Used to skip events for already known upgrade proposals. last_seen_protocol_version: ProtocolSemanticVersion, diff --git a/core/node/eth_watch/src/lib.rs b/core/node/eth_watch/src/lib.rs index 7cb0064c3d73..7c27a6322c2f 100644 --- a/core/node/eth_watch/src/lib.rs +++ b/core/node/eth_watch/src/lib.rs @@ -1,6 +1,6 @@ //! Ethereum watcher polls the Ethereum node for the relevant events, such as priority operations (aka L1 transactions), //! protocol upgrades etc. -//! New events are accepted to the zkSync network once they have the sufficient amount of L1 confirmations. +//! New events are accepted to the ZKsync network once they have the sufficient amount of L1 confirmations. use std::time::Duration; diff --git a/core/node/genesis/src/lib.rs b/core/node/genesis/src/lib.rs index bfa6b77cbfef..461f208e3012 100644 --- a/core/node/genesis/src/lib.rs +++ b/core/node/genesis/src/lib.rs @@ -1,4 +1,4 @@ -//! This module aims to provide a genesis setup for the zkSync Era network. +//! This module aims to provide a genesis setup for the ZKsync Era network. //! It initializes the Merkle tree with the basic setup (such as fields of special service accounts), //! setups the required databases, and outputs the data required to initialize a smart contract. diff --git a/core/node/house_keeper/README.md b/core/node/house_keeper/README.md index 4f8c399a85b2..eaeb7c14b203 100644 --- a/core/node/house_keeper/README.md +++ b/core/node/house_keeper/README.md @@ -1,4 +1,4 @@ -# zkSync Era housekeeper +# ZKsync Era housekeeper This crate contains functionality for performing “administrative” work to keep the system flowing. It does: diff --git a/core/node/proof_data_handler/README.md b/core/node/proof_data_handler/README.md index 8c3392c5b1fe..8cc48fe0aa35 100644 --- a/core/node/proof_data_handler/README.md +++ b/core/node/proof_data_handler/README.md @@ -1,3 +1,3 @@ -# zkSync Era Proof data handler +# ZKsync Era Proof data handler This crate contains functionality for sending proof-related info from `Server` to `Prover` and back. diff --git a/core/node/shared_metrics/README.md b/core/node/shared_metrics/README.md index 45aa229f808a..e60cf9176369 100644 --- a/core/node/shared_metrics/README.md +++ b/core/node/shared_metrics/README.md @@ -1,3 +1,3 @@ -# zkSync Era shared metrics +# ZKsync Era shared metrics -This crate contains the definitions of various metrics that are shared among different zkSync Era components. +This crate contains the definitions of various metrics that are shared among different ZKsync Era components. diff --git a/core/node/state_keeper/src/seal_criteria/mod.rs b/core/node/state_keeper/src/seal_criteria/mod.rs index 505d9944149d..a721c53b6467 100644 --- a/core/node/state_keeper/src/seal_criteria/mod.rs +++ b/core/node/state_keeper/src/seal_criteria/mod.rs @@ -122,7 +122,7 @@ pub enum SealResolution { /// tx in the next block. /// While it may be kinda counter-intuitive that we first execute transaction and just then /// decided whether we should include it into the block or not, it is required by the architecture of - /// zkSync Era. We may not know, for example, how much gas block will consume, because 1) smart contract + /// ZKsync Era. We may not know, for example, how much gas block will consume, because 1) smart contract /// execution is hard to predict and 2) we may have writes to the same storage slots, which will save us /// gas. ExcludeAndSeal, diff --git a/core/tests/loadnext/README.md b/core/tests/loadnext/README.md index 52b4c68dec34..59288a7160ec 100644 --- a/core/tests/loadnext/README.md +++ b/core/tests/loadnext/README.md @@ -1,7 +1,7 @@ -# Loadnext: loadtest for zkSync +# Loadnext: loadtest for ZKsync -Loadnext is a utility for random stress-testing the zkSync server. It is capable of simulating the behavior of many -independent users of zkSync network, who are sending quasi-random requests to the server. +Loadnext is a utility for random stress-testing the ZKsync server. It is capable of simulating the behavior of many +independent users of ZKsync network, who are sending quasi-random requests to the server. The general flow is as follows: diff --git a/core/tests/loadnext/src/account/mod.rs b/core/tests/loadnext/src/account/mod.rs index d5bd22dd6844..5dcd5167165e 100644 --- a/core/tests/loadnext/src/account/mod.rs +++ b/core/tests/loadnext/src/account/mod.rs @@ -354,7 +354,7 @@ impl AccountLifespan { } } - /// Generic submitter for zkSync network: it can operate individual transactions, + /// Generic submitter for ZKsync network: it can operate individual transactions, /// as long as we can provide a `SyncTransactionHandle` to wait for the commitment and the /// execution result. /// Once result is obtained, it's compared to the expected operation outcome in order to check whether diff --git a/core/tests/loadnext/src/account_pool.rs b/core/tests/loadnext/src/account_pool.rs index 1ea6f61b9dff..7b5e277e139b 100644 --- a/core/tests/loadnext/src/account_pool.rs +++ b/core/tests/loadnext/src/account_pool.rs @@ -77,7 +77,7 @@ pub struct TestWallet { } /// Pool of accounts to be used in the test. -/// Each account is represented as `zksync::Wallet` in order to provide convenient interface of interaction with zkSync. +/// Each account is represented as `zksync::Wallet` in order to provide convenient interface of interaction with ZKsync. #[derive(Debug)] pub struct AccountPool { /// Main wallet that will be used to initialize all the test wallets. @@ -102,7 +102,7 @@ impl AccountPool { )? .for_network(l2_chain_id.into()) .build(); - // Perform a health check: check whether zkSync server is alive. + // Perform a health check: check whether ZKsync server is alive. let mut server_alive = false; for _ in 0usize..3 { if let Ok(Ok(_)) = timeout(Duration::from_secs(3), client.get_main_contract()).await { @@ -111,7 +111,7 @@ impl AccountPool { } } if !server_alive { - anyhow::bail!("zkSync server does not respond. Please check RPC address and whether server is launched"); + anyhow::bail!("ZKsync server does not respond. Please check RPC address and whether server is launched"); } let test_contract = loadnext_contract(&config.test_contracts_path)?; diff --git a/core/tests/loadnext/src/command/api.rs b/core/tests/loadnext/src/command/api.rs index b32620bd3438..2f5628f5759b 100644 --- a/core/tests/loadnext/src/command/api.rs +++ b/core/tests/loadnext/src/command/api.rs @@ -53,7 +53,7 @@ impl AllWeighted for ApiRequestType { pub struct ApiRequest { /// Type of the request to be performed. pub request_type: ApiRequestType, - /// zkSync block number, generated randomly. + /// ZKsync block number, generated randomly. pub block_number: api::BlockNumber, } diff --git a/core/tests/loadnext/src/command/tx_command.rs b/core/tests/loadnext/src/command/tx_command.rs index a2ac37dfc8b8..2c325f1a67e4 100644 --- a/core/tests/loadnext/src/command/tx_command.rs +++ b/core/tests/loadnext/src/command/tx_command.rs @@ -12,7 +12,7 @@ use crate::{ static WEIGHTS: OnceCell<[(TxType, f32); 5]> = OnceCell::new(); -/// Type of transaction. It doesn't copy the zkSync operation list, because +/// Type of transaction. It doesn't copy the ZKsync operation list, because /// it divides some transactions in subcategories (e.g. to new account / to existing account; to self / to other; etc)/ #[derive(Debug, Copy, Clone, PartialEq)] pub enum TxType { diff --git a/core/tests/loadnext/src/config.rs b/core/tests/loadnext/src/config.rs index 7f3e1e258305..a9648edb00ae 100644 --- a/core/tests/loadnext/src/config.rs +++ b/core/tests/loadnext/src/config.rs @@ -41,7 +41,7 @@ pub struct LoadtestConfig { /// Address of the ERC-20 token to be used in test. /// /// Token must satisfy two criteria: - /// - Be supported by zkSync. + /// - Be supported by ZKsync. /// - Have `mint` operation. /// /// Note that we use ERC-20 token since we can't easily mint a lot of ETH on diff --git a/core/tests/loadnext/src/corrupted_tx.rs b/core/tests/loadnext/src/corrupted_tx.rs index cb1c8fcf1b7b..cf4064a4cf8f 100644 --- a/core/tests/loadnext/src/corrupted_tx.rs +++ b/core/tests/loadnext/src/corrupted_tx.rs @@ -6,7 +6,7 @@ use zksync_types::{ use crate::{command::IncorrectnessModifier, sdk::signer::Signer}; -/// Trait that exists solely to extend the signed zkSync transaction interface, providing the ability +/// Trait that exists solely to extend the signed ZKsync transaction interface, providing the ability /// to modify transaction in a way that will make it invalid. /// /// Loadtest is expected to simulate the user behavior, and it's not that uncommon of users to send incorrect diff --git a/core/tests/loadnext/src/executor.rs b/core/tests/loadnext/src/executor.rs index a7b1fa47c994..48d90f19c1d7 100644 --- a/core/tests/loadnext/src/executor.rs +++ b/core/tests/loadnext/src/executor.rs @@ -633,7 +633,7 @@ impl Executor { /// Returns the amount of funds to be deposited on the main account in L2. /// Amount is chosen to be big enough to not worry about precisely calculating the remaining balances on accounts, - /// but also to not be close to the supported limits in zkSync. + /// but also to not be close to the supported limits in ZKsync. fn amount_to_deposit(&self) -> u128 { u128::MAX >> 32 } @@ -696,7 +696,7 @@ async fn deposit_with_attempts( tracing::info!("Deposit with tx_hash {deposit_tx_hash:?}"); - // Wait for the corresponding priority operation to be committed in zkSync. + // Wait for the corresponding priority operation to be committed in ZKsync. match ethereum.wait_for_tx(deposit_tx_hash).await { Ok(eth_receipt) => { return Ok(eth_receipt); diff --git a/core/tests/loadnext/src/main.rs b/core/tests/loadnext/src/main.rs index 6a3125931f12..309dd7557687 100644 --- a/core/tests/loadnext/src/main.rs +++ b/core/tests/loadnext/src/main.rs @@ -1,8 +1,8 @@ -//! Loadtest: an utility to stress-test the zkSync server. +//! Loadtest: an utility to stress-test the ZKsync server. //! //! In order to launch it, you must provide required environmental variables, for details see `README.md`. //! Without required variables provided, test is launched in the localhost/development mode with some hard-coded -//! values to check the local zkSync deployment. +//! values to check the local ZKsync deployment. use std::time::Duration; diff --git a/core/tests/loadnext/src/sdk/abi/update-abi.sh b/core/tests/loadnext/src/sdk/abi/update-abi.sh index 35d03a469dfd..3fdcd4d58028 100755 --- a/core/tests/loadnext/src/sdk/abi/update-abi.sh +++ b/core/tests/loadnext/src/sdk/abi/update-abi.sh @@ -2,7 +2,7 @@ cd `dirname $0` -# Main zkSync contract interface +# Main ZKsync contract interface cat $ZKSYNC_HOME/contracts/l1-contracts/artifacts/contracts/bridgehub/IBridgehub.sol/IBridgehub.json | jq '{ abi: .abi}' > IBridgehub.json cat $ZKSYNC_HOME/contracts/l1-contracts/artifacts/contracts/state-transition/IStateTransitionManager.sol/IStateTransitionManager.json | jq '{ abi: .abi}' > IStateTransitionManager.json cat $ZKSYNC_HOME/contracts/l1-contracts/artifacts/contracts/state-transition/chain-interfaces/IZkSyncHyperchain.sol/IZkSyncHyperchain.json | jq '{ abi: .abi}' > IZkSyncHyperchain.json diff --git a/core/tests/loadnext/src/sdk/ethereum/mod.rs b/core/tests/loadnext/src/sdk/ethereum/mod.rs index 6800fb75a7d3..ca168152a640 100644 --- a/core/tests/loadnext/src/sdk/ethereum/mod.rs +++ b/core/tests/loadnext/src/sdk/ethereum/mod.rs @@ -135,7 +135,7 @@ impl<S: EthereumSigner> EthereumProvider<S> { self.eth_client.as_ref() } - /// Returns the zkSync contract address. + /// Returns the ZKsync contract address. pub fn contract_address(&self) -> H160 { self.client().contract_addr() } @@ -272,7 +272,7 @@ impl<S: EthereumSigner> EthereumProvider<S> { } /// Performs a transfer of funds from one Ethereum account to another. - /// Note: This operation is performed on Ethereum, and not related to zkSync directly. + /// Note: This operation is performed on Ethereum, and not related to ZKsync directly. pub async fn transfer( &self, token_address: Address, @@ -443,7 +443,7 @@ impl<S: EthereumSigner> EthereumProvider<S> { Ok(tx_hash) } - /// Performs a deposit in zkSync network. + /// Performs a deposit in ZKsync network. /// For ERC20 tokens, a deposit must be approved beforehand via the `EthereumProvider::approve_erc20_token_deposits` method. #[allow(clippy::too_many_arguments)] pub async fn deposit( diff --git a/core/tests/ts-integration/README.md b/core/tests/ts-integration/README.md index cb3a1aa5ae7e..93c225066698 100644 --- a/core/tests/ts-integration/README.md +++ b/core/tests/ts-integration/README.md @@ -1,6 +1,6 @@ # NFTF -- New Fancy Test Framework -This folder contains a framework for writing integration tests for zkSync Era, as well as set of integration test +This folder contains a framework for writing integration tests for ZKsync Era, as well as set of integration test suites. This framework is built atop of [jest](https://jestjs.io/). It is _highly recommended_ to familiarize yourself with its @@ -23,7 +23,7 @@ prepare the context for tests. Context initialization consists of: - Creating personal accounts for each test suite. - Providing funds to these accounts. -Basically, during initialization, everything is prepared for writing tests that interact with zkSync. +Basically, during initialization, everything is prepared for writing tests that interact with ZKsync. After that, each test suite is ran _in parallel_. Each test suite can claim its own account and be sure that this account has funds on it and is not used by any other suite. diff --git a/core/tests/ts-integration/contracts/README.md b/core/tests/ts-integration/contracts/README.md index d08f934e8456..532703ad210f 100644 --- a/core/tests/ts-integration/contracts/README.md +++ b/core/tests/ts-integration/contracts/README.md @@ -1,4 +1,4 @@ # Contracts test data This folder contains data for contracts that are being used for testing to check the correctness of the smart contract -flow in zkSync. +flow in ZKsync. diff --git a/core/tests/ts-integration/contracts/custom-account/SystemContractsCaller.sol b/core/tests/ts-integration/contracts/custom-account/SystemContractsCaller.sol index 01b7b5198add..c5be4983e377 100644 --- a/core/tests/ts-integration/contracts/custom-account/SystemContractsCaller.sol +++ b/core/tests/ts-integration/contracts/custom-account/SystemContractsCaller.sol @@ -6,7 +6,7 @@ import {MSG_VALUE_SIMULATOR_IS_SYSTEM_BIT, MSG_VALUE_SYSTEM_CONTRACT} from "./Co import "./Utils.sol"; // Addresses used for the compiler to be replaced with the -// zkSync-specific opcodes during the compilation. +// ZKsync-specific opcodes during the compilation. // IMPORTANT: these are just compile-time constants and are used // only if used in-place by Yul optimizer. address constant TO_L1_CALL_ADDRESS = address((1 << 16) - 1); diff --git a/core/tests/ts-integration/contracts/custom-account/TransactionHelper.sol b/core/tests/ts-integration/contracts/custom-account/TransactionHelper.sol index 7fc883ed882c..82747b88d358 100644 --- a/core/tests/ts-integration/contracts/custom-account/TransactionHelper.sol +++ b/core/tests/ts-integration/contracts/custom-account/TransactionHelper.sol @@ -10,7 +10,7 @@ import "./interfaces/IContractDeployer.sol"; import {BASE_TOKEN_SYSTEM_CONTRACT, BOOTLOADER_FORMAL_ADDRESS} from "./Constants.sol"; import "./RLPEncoder.sol"; -/// @dev The type id of zkSync's EIP-712-signed transaction. +/// @dev The type id of ZKsync's EIP-712-signed transaction. uint8 constant EIP_712_TX_TYPE = 0x71; /// @dev The type id of legacy transactions. @@ -20,7 +20,7 @@ uint8 constant EIP_2930_TX_TYPE = 0x01; /// @dev The type id of EIP1559 transactions. uint8 constant EIP_1559_TX_TYPE = 0x02; -/// @notice Structure used to represent zkSync transaction. +/// @notice Structure used to represent ZKsync transaction. struct Transaction { // The type of the transaction. uint256 txType; @@ -118,7 +118,7 @@ library TransactionHelper { } } - /// @notice Encode hash of the zkSync native transaction type. + /// @notice Encode hash of the ZKsync native transaction type. /// @return keccak256 hash of the EIP-712 encoded representation of transaction function _encodeHashEIP712Transaction(Transaction calldata _transaction) private @@ -251,7 +251,7 @@ library TransactionHelper { // Hash of EIP2930 transactions is encoded the following way: // H(0x01 || RLP(chain_id, nonce, gas_price, gas_limit, destination, amount, data, access_list)) // - // Note, that on zkSync access lists are not supported and should always be empty. + // Note, that on ZKsync access lists are not supported and should always be empty. // Encode all fixed-length params to avoid "stack too deep error" bytes memory encodedFixedLengthParams; @@ -290,7 +290,7 @@ library TransactionHelper { // Otherwise the length is not encoded at all. } - // On zkSync, access lists are always zero length (at least for now). + // On ZKsync, access lists are always zero length (at least for now). bytes memory encodedAccessListLength = RLPEncoder.encodeListLen(0); bytes memory encodedListLength; @@ -327,7 +327,7 @@ library TransactionHelper { // Hash of EIP1559 transactions is encoded the following way: // H(0x02 || RLP(chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list)) // - // Note, that on zkSync access lists are not supported and should always be empty. + // Note, that on ZKsync access lists are not supported and should always be empty. // Encode all fixed-length params to avoid "stack too deep error" bytes memory encodedFixedLengthParams; @@ -368,7 +368,7 @@ library TransactionHelper { // Otherwise the length is not encoded at all. } - // On zkSync, access lists are always zero length (at least for now). + // On ZKsync, access lists are always zero length (at least for now). bytes memory encodedAccessListLength = RLPEncoder.encodeListLen(0); bytes memory encodedListLength; diff --git a/core/tests/ts-integration/contracts/custom-account/Utils.sol b/core/tests/ts-integration/contracts/custom-account/Utils.sol index da3d4eb60878..e562948942d7 100644 --- a/core/tests/ts-integration/contracts/custom-account/Utils.sol +++ b/core/tests/ts-integration/contracts/custom-account/Utils.sol @@ -3,7 +3,7 @@ pragma solidity >=0.8.0; /** * @author Matter Labs - * @dev Common utilities used in zkSync system contracts + * @dev Common utilities used in ZKsync system contracts */ library Utils { function safeCastToU128(uint256 _x) internal pure returns (uint128) { diff --git a/core/tests/ts-integration/src/helpers.ts b/core/tests/ts-integration/src/helpers.ts index d3464bc84bdd..7848749bfe31 100644 --- a/core/tests/ts-integration/src/helpers.ts +++ b/core/tests/ts-integration/src/helpers.ts @@ -64,7 +64,7 @@ export async function anyTransaction(wallet: zksync.Wallet): Promise<ethers.prov } /** - * Waits until a new L1 batch is created on zkSync node. + * Waits until a new L1 batch is created on ZKsync node. * This function attempts to trigger this action by sending an additional transaction, * however it may not be enough in some env (e.g. if some testnet is configured to utilize the block capacity). * diff --git a/core/tests/ts-integration/src/matchers/transaction.ts b/core/tests/ts-integration/src/matchers/transaction.ts index 95d9ff122936..4058d28321a3 100644 --- a/core/tests/ts-integration/src/matchers/transaction.ts +++ b/core/tests/ts-integration/src/matchers/transaction.ts @@ -3,7 +3,7 @@ import { MatcherModifier } from '../modifiers'; import * as zksync from 'zksync-ethers'; import { AugmentedTransactionResponse } from '../retry-provider'; -// This file contains implementation of matchers for zkSync/ethereum transaction. +// This file contains implementation of matchers for ZKsync/ethereum transaction. // For actual doc-comments, see `typings/jest.d.ts` file. export async function toBeAccepted( diff --git a/core/tests/ts-integration/src/prerequisites.ts b/core/tests/ts-integration/src/prerequisites.ts index c20e33bbab4d..15e1cc096df9 100644 --- a/core/tests/ts-integration/src/prerequisites.ts +++ b/core/tests/ts-integration/src/prerequisites.ts @@ -1,17 +1,17 @@ import * as fs from 'fs'; import * as path from 'path'; -// All zkSync test suites are expected to be named `*.test.ts`. +// All ZKsync test suites are expected to be named `*.test.ts`. const TEST_SUITE_MARKER = 'test.ts'; // Files that are excluded from the integration test suited (e.g. unit tests for the framework itself). const EXCLUDED_FILES = ['self-unit.test.ts']; /** - * Gets all the files that contain zkSync integration test suites. + * Gets all the files that contain ZKsync integration test suites. * Used to provide each test suite a funded wallet. * - * @returns list of filenames that correspond to zkSync integration test suites. + * @returns list of filenames that correspond to ZKsync integration test suites. */ export function lookupPrerequisites(): string[] { const files = loadFilesRecursively(`${__dirname}/../tests/`); diff --git a/core/tests/ts-integration/src/types.ts b/core/tests/ts-integration/src/types.ts index 4ab6a0bf0d8b..14cf11cec14f 100644 --- a/core/tests/ts-integration/src/types.ts +++ b/core/tests/ts-integration/src/types.ts @@ -68,7 +68,7 @@ export interface TestEnvironment { */ mainWalletPK: string; /** - * URL of zkSync node's HTTP Web3 API. + * URL of ZKsync node's HTTP Web3 API. */ l2NodeUrl: string; /** @@ -76,11 +76,11 @@ export interface TestEnvironment { */ l1NodeUrl: string; /** - * URL of zkSync node's WS Web3 API. + * URL of ZKsync node's WS Web3 API. */ wsL2NodeUrl: string; /** - * URL of zkSync node's contract verification API. + * URL of ZKsync node's contract verification API. */ contractVerificationUrl: string; /** diff --git a/core/tests/ts-integration/tests/api/web3.test.ts b/core/tests/ts-integration/tests/api/web3.test.ts index b99e83855b2c..09f78ce75059 100644 --- a/core/tests/ts-integration/tests/api/web3.test.ts +++ b/core/tests/ts-integration/tests/api/web3.test.ts @@ -1,5 +1,5 @@ /** - * This suite contains tests for the Web3 API compatibility and zkSync-specific extensions. + * This suite contains tests for the Web3 API compatibility and ZKsync-specific extensions. */ import { TestMaster } from '../../src'; import * as zksync from 'zksync-ethers'; @@ -144,7 +144,7 @@ describe('web3 API compatibility tests', () => { }); test('Should check the network version', async () => { - // Valid network IDs for zkSync are greater than 270. + // Valid network IDs for ZKsync are greater than 270. // This test suite may run on different envs, so we don't expect a particular ID. await expect(alice.provider.send('net_version', [])).resolves.toMatch(chainId.toString()); }); diff --git a/core/tests/ts-integration/tests/contracts.test.ts b/core/tests/ts-integration/tests/contracts.test.ts index 57e9ad057506..2b23ab7cb34b 100644 --- a/core/tests/ts-integration/tests/contracts.test.ts +++ b/core/tests/ts-integration/tests/contracts.test.ts @@ -154,7 +154,7 @@ describe('Smart contract behavior checks', () => { test('Should interchangeably use ethers for eth calls', async () => { // In this test we make sure that we can use `ethers` `Contract` object and provider - // to do an `eth_Call` and send transactions to zkSync contract. + // to do an `eth_Call` and send transactions to ZKsync contract. // This check is important to ensure that external apps do not have to use our SDK and // can keep using `ethers` on their side. diff --git a/core/tests/ts-integration/tests/l1.test.ts b/core/tests/ts-integration/tests/l1.test.ts index db0308ba4b9d..e149a8f7e59f 100644 --- a/core/tests/ts-integration/tests/l1.test.ts +++ b/core/tests/ts-integration/tests/l1.test.ts @@ -149,7 +149,7 @@ describe('Tests for L1 behavior', () => { const accumutatedRoot = calculateAccumulatedRoot(alice.address, message, receipt.l1BatchTxIndex, id, proof); expect(accumutatedRoot).toBe(root); - // Ensure that provided proof is accepted by the main zkSync contract. + // Ensure that provided proof is accepted by the main ZKsync contract. const chainContract = await alice.getMainContract(); const acceptedByContract = await chainContract.proveL2MessageInclusion( receipt.l1BatchNumber, diff --git a/core/tests/ts-integration/tests/mempool.test.ts b/core/tests/ts-integration/tests/mempool.test.ts index 00f95bfefacb..6dacc54ac1fb 100644 --- a/core/tests/ts-integration/tests/mempool.test.ts +++ b/core/tests/ts-integration/tests/mempool.test.ts @@ -137,7 +137,7 @@ describe('Tests for the mempool behavior', () => { }); /** - * Sends a valid zkSync transaction with a certain nonce. + * Sends a valid ZKsync transaction with a certain nonce. * What transaction does is assumed to be not important besides the fact that it should be accepted. * * @param wallet Wallet to send transaction from. diff --git a/core/tests/ts-integration/tests/self-unit.test.ts b/core/tests/ts-integration/tests/self-unit.test.ts index f59d66f1361f..50655e7c2c73 100644 --- a/core/tests/ts-integration/tests/self-unit.test.ts +++ b/core/tests/ts-integration/tests/self-unit.test.ts @@ -1,6 +1,6 @@ /** * This file contains unit tests for the framework itself. - * It does not receive a funced account and should not interact with the zkSync server. + * It does not receive a funced account and should not interact with the ZKsync server. */ import { TestMaster } from '../src/index'; import { BigNumber } from 'ethers'; diff --git a/docs/guides/advanced/01_initialization.md b/docs/guides/advanced/01_initialization.md index 7e7e74957cb8..79c33434d3b5 100644 --- a/docs/guides/advanced/01_initialization.md +++ b/docs/guides/advanced/01_initialization.md @@ -1,6 +1,6 @@ -# zkSync deeper dive +# ZKsync deeper dive -The goal of this doc is to show you some more details on how zkSync works internally. +The goal of this doc is to show you some more details on how ZKsync works internally. Please do the dev_setup.md and development.md (these commands do all the heavy lifting on starting the components of the system). @@ -20,9 +20,9 @@ there, make sure to run `zk` (that compiles this code), before re-running `zk in As first step, it gets the docker images for postgres and reth. -Reth (one of the Ethereum clients) will be used to setup our own copy of L1 chain (that our local zkSync would use). +Reth (one of the Ethereum clients) will be used to setup our own copy of L1 chain (that our local ZKsync would use). -Postgres is one of the two databases, that is used by zkSync (the other one is RocksDB). Currently most of the data is +Postgres is one of the two databases, that is used by ZKsync (the other one is RocksDB). Currently most of the data is stored in postgres (blocks, transactions etc) - while RocksDB is only storing the state (Tree & Map) - and it used by VM. @@ -116,7 +116,7 @@ This is one of the "rich wallets" we predefined for local L1. **Note:** This reth shell is running official Ethereum JSON RPC with Reth-specific extensions documented at [reth docs](https://paradigmxyz.github.io/reth/jsonrpc/intro.html) -In order to communicate with L2 (our zkSync) - we have to deploy multiple contracts onto L1 (our local reth created +In order to communicate with L2 (our ZKsync) - we have to deploy multiple contracts onto L1 (our local reth created Ethereum). You can look on the `deployL1.log` file - to see the list of contracts that were deployed and their accounts. First thing in the file, is the deployer/governor wallet - this is the account that can change, freeze and unfreeze the diff --git a/docs/guides/advanced/02_deposits.md b/docs/guides/advanced/02_deposits.md index 7a40e33f91c9..4018fed46325 100644 --- a/docs/guides/advanced/02_deposits.md +++ b/docs/guides/advanced/02_deposits.md @@ -33,7 +33,7 @@ Now, let's see how many tokens we have: // This checks the tokens on 'L1' (reth) ./web3 --rpc-url http://localhost:8545 balance 0x618263CE921F7dd5F4f40C29f6c524Aaf97b9bbd -// This checks the tokens on 'L2' (zkSync) +// This checks the tokens on 'L2' (ZKsync) ./web3 --rpc-url http://localhost:3050 balance 0x618263CE921F7dd5F4f40C29f6c524Aaf97b9bbd ``` @@ -55,7 +55,7 @@ and now let's bridge it over to L2. ## Bridging over to L2 -For an easy way to bridge we'll use [zkSync CLI](https://github.com/matter-labs/zksync-cli) +For an easy way to bridge we'll use [ZKsync CLI](https://github.com/matter-labs/zksync-cli) ```shell npx zksync-cli bridge deposit --chain=dockerized-node --amount 3 --pk=0x5090c024edb3bdf4ce2ebc2da96bedee925d9d77d729687e5e2d56382cf0a5a6 --to=0x618263CE921F7dd5F4f40C29f6c524Aaf97b9bbd diff --git a/docs/guides/advanced/03_withdrawals.md b/docs/guides/advanced/03_withdrawals.md index 3d1a46ff4cb9..69f5b0f87089 100644 --- a/docs/guides/advanced/03_withdrawals.md +++ b/docs/guides/advanced/03_withdrawals.md @@ -1,4 +1,4 @@ -# zkSync deeper dive bridging stuff back (a.k.a withdrawals) +# ZKsync deeper dive bridging stuff back (a.k.a withdrawals) Assuming that you have completed [part 1](01_initialization.md) and [part 2](02_deposits.md) already, we can bridge the tokens back by simply calling the zksync-cli: diff --git a/docs/guides/advanced/0_alternative_vm_intro.md b/docs/guides/advanced/0_alternative_vm_intro.md index b47c71bde2f5..fab623e38ae3 100644 --- a/docs/guides/advanced/0_alternative_vm_intro.md +++ b/docs/guides/advanced/0_alternative_vm_intro.md @@ -4,7 +4,7 @@ [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 +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 multi-client philosophy, there are multiple clients, and they are written in Go, Rust, and other traditional programming languages, all running and verifying the same STF. @@ -68,7 +68,7 @@ For each frame, the following memory areas are allocated: calldata/copy the `returndata` from the calls to system contracts to not interfere with the standard Solidity memory alignment. - _Stack_. Unlike Ethereum, stack is not the primary place to get arguments for opcodes. The biggest difference between - stack on zkEVM and EVM is that on zkSync stack can be accessed at any location (just like memory). While users do not + stack on zkEVM and EVM is that on ZKsync stack can be accessed at any location (just like memory). While users do not pay for the growth of stack, the stack can be fully cleared at the end of the frame, so the overhead is minimal. - _Code_. The memory area from which the VM executes the code of the contract. The contract itself can not read the code page, it is only done implicitly by the VM. @@ -115,7 +115,7 @@ copying. Some of the operations which are opcodes on Ethereum, have become calls to some of the system contracts. The most notable examples are `Keccak256`, `SystemContext`, etc. Note, that, if done naively, the following lines of code would -work differently on zkSync and Ethereum: +work differently on ZKsync and Ethereum: ```solidity pop(call(...)) @@ -142,7 +142,7 @@ result in `revert(0,0)`. - `mimic_call`. The same as a normal `call`, but it can alter the `msg.sender` field of the transaction. - `to_l1`. Sends a system L2→L1 log to Ethereum. The structure of this log can be seen [here](https://github.com/code-423n4/2023-10-zksync/blob/ef99273a8fdb19f5912ca38ba46d6bd02071363d/code/contracts/ethereum/contracts/zksync/Storage.sol#L47). -- `event`. Emits an L2 log to zkSync. Note, that L2 logs are not equivalent to Ethereum events. Each L2 log can emit 64 +- `event`. Emits an L2 log to ZKsync. Note, that L2 logs are not equivalent to Ethereum events. Each L2 log can emit 64 bytes of data (the actual size is 88 bytes, because it includes the emitter address, etc). A single Ethereum event is represented with multiple `event` logs constitute. This opcode is only used by `EventWriter` system contract. - `precompile_call`. This is an opcode that accepts two parameters: the uint256 representing the packed parameters for @@ -227,7 +227,7 @@ by another system contract (since Matter Labs is fully aware of system contracts ### Simulations via our compiler In the future, we plan to introduce our “extended” version of Solidity with more supported opcodes than the original -one. However, right now it was beyond the capacity of the team to do, so in order to represent accessing zkSync-specific +one. However, right now it was beyond the capacity of the team to do, so in order to represent accessing ZKsync-specific opcodes, we use `call` opcode with certain constant parameters that will be automatically replaced by the compiler with zkEVM native opcode. @@ -251,7 +251,7 @@ Full list of opcode simulations can be found We also use [verbatim-like](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions/extensions/verbatim.md) -statements to access zkSync-specific opcodes in the bootloader. +statements to access ZKsync-specific opcodes in the bootloader. All the usages of the simulations in our Solidity code are implemented in the [SystemContractHelper](https://github.com/code-423n4/2023-10-zksync/blob/main/code/system-contracts/contracts/libraries/SystemContractHelper.sol) @@ -284,7 +284,7 @@ above substitutions to work. ## Bytecode hashes -On zkSync the bytecode hashes are stored in the following format: +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 @@ -306,6 +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 +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/contracts.md b/docs/guides/advanced/contracts.md index 03d09469975d..5148ee917f7f 100644 --- a/docs/guides/advanced/contracts.md +++ b/docs/guides/advanced/contracts.md @@ -1,10 +1,10 @@ -# zkSync contracts +# ZKsync contracts -Now that we know how to bridge tokens back and forth, let's talk about running things on zkSync. +Now that we know how to bridge tokens back and forth, let's talk about running things on ZKsync. We have a bunch of great tutorials (like this one <https://docs.zksync.io/build/tooling/hardhat/getting-started>) that you can follow to get the exact code & command line calls to create the contracts - so in this article, let's focus on -how things differ between zkSync and Ethereum. +how things differ between ZKsync and Ethereum. **Note** Before reading this article, I'd recommend doing the hardhat tutorial above. @@ -23,9 +23,9 @@ the ABI, so that they can set the proper function arguments). All the bytecode will be run on the EVM (Ethereum Virtual Machine) - that has a stack, access to memory and storage, and a bunch of opcodes. -## zkSync flow +## ZKsync flow -The main part (and the main cost) of the zkSync is the proving system. In order to make proof as fast as possible, we're +The main part (and the main cost) of the ZKsync is the proving system. In order to make proof as fast as possible, we're running a little bit different virtual machine (zkEVM) - that has a slightly different set of opcodes, and also contains a bunch of registers. More details on this will be written in the future articles. @@ -37,7 +37,7 @@ While having a separate compiler introduces a bunch of challenges (for example, allows us to move some of the VM logic (like new contract deployment) into System contracts - which allows faster & cheaper modifications and increased flexibility. -### zkSync system contracts +### ZKsync system contracts Small note on system contracts: as mentioned above, we moved some of the VM logic into system contracts, which allows us to keep VM simpler (and with this - keep the proving system simpler). @@ -51,15 +51,15 @@ visible - like our `ContractDeployer` ### ContractDeployer -Deploying a new contract differs on Ethereum and zkSync. +Deploying a new contract differs on Ethereum and ZKsync. -While on Ethereum - you send the transaction to 0x00 address - on zkSync you have to call the special `ContractDeployer` +While on Ethereum - you send the transaction to 0x00 address - on ZKsync you have to call the special `ContractDeployer` system contract. If you look on your hardhat example, you'll notice that your `deploy.ts` is actually using a `Deployer` class from the `hardhat-zksync-deploy` plugin. -Which inside uses the zkSync's web3.js, that calls the contract deployer +Which inside uses the ZKsync's web3.js, that calls the contract deployer [here](https://github.com/zksync-sdk/zksync2-js/blob/b1d11aa016d93ebba240cdeceb40e675fb948133/src/contract.ts#L76) ```typescript @@ -71,14 +71,14 @@ override getDeployTransaction(..) { ``` Also `ContractDeployer` adding a special prefix for all the new contract addresses. This means that contract addresses -WILL be different on `zkSync` and Ethereum (and also leaves us the possibility of adding Ethereum addresses in the +WILL be different on `ZKsync` and Ethereum (and also leaves us the possibility of adding Ethereum addresses in the future if needed). You can look for `CREATE2_PREFIX` and `CREATE_PREFIX` in the code. ### Gas costs -Another part, where zkSync differs from Ethereum is gas cost. The best example for this are storage slots. +Another part, where ZKsync differs from Ethereum is gas cost. The best example for this are storage slots. If you have two transactions that are updating the same storage slot - and they are in the same 'batch' - only the first one would be charged (as when we write the final storage to ethereum, we just write the final diff of what slots have @@ -86,11 +86,11 @@ changed - so updating the same slot multiple times doesn't increase the amount o ### Account abstraction and some method calls -As `zkSync` has a built-in Account Abstraction (more on this in a separate article) - you shouldn't depend on some of +As `ZKsync` has a built-in Account Abstraction (more on this in a separate article) - you shouldn't depend on some of the solidity functions (like `ecrecover` - that checks the keys, or `tx.origin`) - in all the cases, the compiler will try to warn you. ## Summary -In this article, we looked at how contract development & deployment differs on Ethereum and zkSync (looking at +In this article, we looked at how contract development & deployment differs on Ethereum and ZKsync (looking at differences in VMs, compilers and system contracts). diff --git a/docs/guides/advanced/fee_model.md b/docs/guides/advanced/fee_model.md index 40974f461ea3..3e6473d3ab96 100644 --- a/docs/guides/advanced/fee_model.md +++ b/docs/guides/advanced/fee_model.md @@ -182,7 +182,7 @@ meaning it cannot be less than 80M or more than 4G. ### Why validation is special In Ethereum, there is a fixed cost for verifying a transaction's correctness by checking its signature. However, in -zkSync, due to Account Abstraction, we may need to execute some contract code to determine whether it's ready to accept +ZKsync, due to Account Abstraction, we may need to execute some contract code to determine whether it's ready to accept the transaction. If the contract rejects the transaction, it must be dropped, and there's no one to charge for that process. @@ -224,7 +224,7 @@ You can find this code in [get_txs_fee_in_wei][get_txs_fee_in_wei] function. ## Q&A -### Is zkSync really cheaper +### Is ZKsync really cheaper In short, yes. As seen in the table at the beginning, the regular L2 gas price is set to 0.25 Gwei, while the standard Ethereum price is around 60-100 Gwei. However, the cost of publishing to L1 depends on L1 prices, meaning that the @@ -232,7 +232,7 @@ actual transaction costs will increase if the L1 gas price rises. ### Why do I hear about large refunds -There are a few reasons why refunds might be 'larger' on zkSync (i.e., why we might be overestimating the fees): +There are a few reasons why refunds might be 'larger' on ZKsync (i.e., why we might be overestimating the fees): - We must assume (pessimistically) that you'll have to pay for all the slot/storage writes. In practice, if multiple transactions touch the same slot, we only charge one of them. diff --git a/docs/guides/advanced/how_l2_messaging_works.md b/docs/guides/advanced/how_l2_messaging_works.md index 7bd067eca550..45aba51da03b 100644 --- a/docs/guides/advanced/how_l2_messaging_works.md +++ b/docs/guides/advanced/how_l2_messaging_works.md @@ -1,6 +1,6 @@ # How L2 to L1 messaging works -In this article, we will explore the workings of Layer 2 (L2) to Layer 1 (L1) messaging in zkSync Era. +In this article, we will explore the workings of Layer 2 (L2) to Layer 1 (L1) messaging in ZKsync Era. If you're uncertain about why messaging is necessary in the first place, please refer to our [user documentation][user_docs]. diff --git a/docs/guides/advanced/how_transaction_works.md b/docs/guides/advanced/how_transaction_works.md index 800b2612d162..96c75e3609cc 100644 --- a/docs/guides/advanced/how_transaction_works.md +++ b/docs/guides/advanced/how_transaction_works.md @@ -26,7 +26,7 @@ Here's a simplified table of the transaction types: | 0x0 | 'Legacy' | Only includes `gas price` | These are traditional Ethereum transactions. | 60% / 82% | | 0x1 | EIP-2930 | Contains a list of storage keys/addresses the transaction will access | At present, this type of transaction is not enabled. | | 0x2 | EIP-1559 | Includes `max_priority_fee_per_gas`, `max_gas_price` | These are Ethereum transactions that provide more control over the gas fee. | 35% / 12% | -| 0x71 | EIP-712 (specific to zkSync) | Similar to EIP-1559, but also adds `max_gas_per_pubdata`, custom signatures, and Paymaster support | This is used by those who are using zkSync specific Software Development Kits (SDKs). | 1% / 2% | +| 0x71 | EIP-712 (specific to ZKsync) | Similar to EIP-1559, but also adds `max_gas_per_pubdata`, custom signatures, and Paymaster support | This is used by those who are using ZKsync specific Software Development Kits (SDKs). | 1% / 2% | | 0xFF | L1 transactions also known as priority transactions `L1Tx` | Originating from L1, these have more custom fields like 'refund' addresses etc | Mainly used to transfer funds/data between L1 & L2 layer. | 4% / 3% | Here's the code that does the parsing: [TransactionRequest::from_bytes][transaction_request_from_bytes] diff --git a/docs/guides/advanced/pubdata-with-blobs.md b/docs/guides/advanced/pubdata-with-blobs.md index e27372e934ef..edeaa5b4ebf0 100644 --- a/docs/guides/advanced/pubdata-with-blobs.md +++ b/docs/guides/advanced/pubdata-with-blobs.md @@ -16,11 +16,11 @@ unlike 4844 which supports just 6 per block. ## Technical Approach -The approach spans both L2 system contracts and L1 zkSync contracts (namely `Executor.sol`). When a batch is sealed on +The approach spans both L2 system contracts and L1 ZKsync contracts (namely `Executor.sol`). When a batch is sealed on L2 we will chunk it into blob-sized pieces (4096 elements \* 31 bytes per what is required by our circuits), take the hash of each chunk, and send them to L1 via system logs. Within `Executor.sol` , when we are dealing with blob-based commitments, we verify that the blob contains the correct data with the point evaluation precompile. If the batch -utilizes calldata instead, the processing should remain the same as in a pre-4844 zkSync. Regardless of if pubdata is in +utilizes calldata instead, the processing should remain the same as in a pre-4844 ZKsync. Regardless of if pubdata is in calldata or blobs are used, the batch’s commitment changes as we include new data within the auxiliary output. Given that this is the first step to a longer-term solution, and the restrictions of proto-danksharding that get lifted diff --git a/docs/guides/advanced/pubdata.md b/docs/guides/advanced/pubdata.md index cc0c82497cab..7a32076221f1 100644 --- a/docs/guides/advanced/pubdata.md +++ b/docs/guides/advanced/pubdata.md @@ -1,6 +1,6 @@ # Overview -Pubdata in zkSync can be divided up into 4 different categories: +Pubdata in ZKsync can be divided up into 4 different categories: 1. L2 to L1 Logs 2. L2 to L1 Messages @@ -15,7 +15,7 @@ array. > Note: When the 4844 was integrated this bytes array was moved from being part of the calldata to blob data. While the structure of the pubdata changes, we can use the same strategy to pull the relevant information. First, we -need to filter all of the transactions to the L1 zkSync contract for only the `commitBlocks/commitBatches` transactions +need to filter all of the transactions to the L1 ZKsync contract for only the `commitBlocks/commitBatches` transactions where the proposed block has been referenced by a corresponding `executeBlocks/executeBatches` call (the reason for this is that a committed or even proven block can be reverted but an executed one cannot). Once we have all the committed blocks that have been executed, we then will pull the transaction input and the relevant fields, applying them in order diff --git a/docs/guides/architecture.md b/docs/guides/architecture.md index e87f4bca7e55..25676ad74aa7 100644 --- a/docs/guides/architecture.md +++ b/docs/guides/architecture.md @@ -1,7 +1,7 @@ -# zkSync v2 Project Architecture +# ZKsync v2 Project Architecture This document will help you answer the question: _where can I find the logic for x?_ by giving a directory-tree style -structure of the physical architecture of the zkSync Era project. +structure of the physical architecture of the ZKsync Era project. ## High-Level Overview @@ -10,15 +10,15 @@ The zksync-2-dev repository has the following main units: <ins>**Smart Contracts:**</ins> All the smart contracts in charge of the protocols on the L1 & L2. Some main contracts: - L1 & L2 bridge contracts. -- The zkSync rollup contract on Ethereum. +- The ZKsync rollup contract on Ethereum. - The L1 proof verifier contract. -**<ins>Core App:**</ins> The execution layer. A node running the zkSync network in charge of the following components: +**<ins>Core App:**</ins> The execution layer. A node running the ZKsync network in charge of the following components: - Monitoring the L1 smart contract for deposits or priority operations. - Maintaining a mempool that receives transactions. - Picking up transactions from the mempool, executing them in a VM, and changing the state accordingly. -- Generating zkSync chain blocks. +- Generating ZKsync chain blocks. - Preparing circuits for executed blocks to be proved. - Submitting blocks and proofs to the L1 smart contract. - Exposing the Ethereum-compatible web3 API. @@ -36,27 +36,27 @@ This section provides a physical map of folders & files in this repository. - `/contracts` - `/ethereum`: Smart contracts deployed on the Ethereum L1. - - `/zksync`: Smart contracts deployed on the zkSync L2. + - `/zksync`: Smart contracts deployed on the ZKsync L2. - `/core` - - `/bin`: Executables for the microservices components comprising zkSync Core Node. + - `/bin`: Executables for the microservices components comprising ZKsync Core Node. - `/admin-tools`: CLI tools for admin operations (e.g. restarting prover jobs). - `/external_node`: A read replica that can sync from the main node. - `/lib`: All the library crates used as dependencies of the binary crates above. - - `/basic_types`: Crate with essential zkSync primitive types. - - `/config`: All the configured values used by the different zkSync apps. + - `/basic_types`: Crate with essential ZKsync primitive types. + - `/config`: All the configured values used by the different ZKsync apps. - `/contracts`: Contains definitions of commonly used smart contracts. - - `/crypto`: Cryptographical primitives used by the different zkSync crates. + - `/crypto`: Cryptographical primitives used by the different ZKsync crates. - `/dal`: Data availability layer - `/migrations`: All the db migrations applied to create the storage layer. - `/src`: Functionality to interact with the different db tables. - `/eth_client`: Module providing an interface to interact with an Ethereum node. - `/eth_signer`: Module to sign messages and txs. - - `/mempool`: Implementation of the zkSync transaction pool. + - `/mempool`: Implementation of the ZKsync transaction pool. - `/merkle_tree`: Implementation of a sparse Merkle tree. - `/mini_merkle_tree`: In-memory implementation of a sparse Merkle tree. - `/multivm`: A wrapper over several versions of VM that have been used by the main node. @@ -65,47 +65,47 @@ This section provides a physical map of folders & files in this repository. - `/queued_job_processor`: An abstraction for async job processing - `/state`: A state keeper responsible for handling transaction execution and creating miniblocks and L1 batches. - `/storage`: An encapsulated database interface. - - `/test_account`: A representation of zkSync account. - - `/types`: zkSync network operations, transactions, and common types. - - `/utils`: Miscellaneous helpers for zkSync crates. - - `/vlog`: zkSync logging utility. + - `/test_account`: A representation of ZKsync account. + - `/types`: ZKsync network operations, transactions, and common types. + - `/utils`: Miscellaneous helpers for ZKsync crates. + - `/vlog`: ZKsync logging utility. - `/vm`: ULightweight out-of-circuit VM interface. - `/web3_decl`: Declaration of the Web3 API. - `zksync_core/src` - `/api_server` Externally facing APIs. - - `/web3`: zkSync implementation of the Web3 API. + - `/web3`: ZKsync implementation of the Web3 API. - `/tx_sender`: Helper module encapsulating the transaction processing logic. - - `/bin`: The executable main starting point for the zkSync server. - - `/consistency_checker`: zkSync watchdog. - - `/eth_sender`: Submits transactions to the zkSync smart contract. + - `/bin`: The executable main starting point for the ZKsync server. + - `/consistency_checker`: ZKsync watchdog. + - `/eth_sender`: Submits transactions to the ZKsync smart contract. - `/eth_watch`: Fetches data from the L1. for L2 censorship resistance. - `/fee_monitor`: Monitors the ratio of fees collected by executing txs over the costs of interacting with Ethereum. - `/fee_ticker`: Module to define the price components of L2 transactions. - `/gas_adjuster`: Module to determine the fees to pay in txs containing blocks submitted to the L1. - `/gas_tracker`: Module for predicting L1 gas cost for the Commit/PublishProof/Execute operations. - - `/metadata_calculator`: Module to maintain the zkSync state tree. + - `/metadata_calculator`: Module to maintain the ZKsync state tree. - `/state_keeper`: The sequencer. In charge of collecting the pending txs from the mempool, executing them in the VM, and sealing them in blocks. - `/witness_generator`: Takes the sealed blocks and generates a _Witness_, the input for the prover containing the circuits to be proved. - - `/tests`: Testing infrastructure for zkSync network. + - `/tests`: Testing infrastructure for ZKsync network. - `/cross_external_nodes_checker`: A tool for checking external nodes consistency against the main node. - - `/loadnext`: An app for load testing the zkSync server. + - `/loadnext`: An app for load testing the ZKsync server. - `/ts-integration`: Integration tests set implemented in TypeScript. -- `/prover`: zkSync prover orchestrator application. +- `/prover`: ZKsync prover orchestrator application. - `/docker`: Project docker files. -- `/bin` & `/infrastructure`: Infrastructure scripts that help to work with zkSync applications. +- `/bin` & `/infrastructure`: Infrastructure scripts that help to work with ZKsync applications. - `/etc`: Configuration files. - - `/env`:`.env` files that contain environment variables for different configurations of zkSync Server / Prover. + - `/env`:`.env` files that contain environment variables for different configurations of ZKsync Server / Prover. - `/keys`: Verification keys for `circuit` module. -- `/sdk`: Implementation of client libraries for the zkSync network in different programming languages. - - `/zksync-rs`: Rust client library for zkSync. +- `/sdk`: Implementation of client libraries for the ZKsync network in different programming languages. + - `/zksync-rs`: Rust client library for ZKsync. diff --git a/docs/guides/development.md b/docs/guides/development.md index 16d497f876ed..5e53877993dd 100644 --- a/docs/guides/development.md +++ b/docs/guides/development.md @@ -1,6 +1,6 @@ # Development guide -This document covers development-related actions in zkSync. +This document covers development-related actions in ZKsync. ## Initializing the project diff --git a/docs/guides/external-node/00_quick_start.md b/docs/guides/external-node/00_quick_start.md index e244268e7845..826c296fcd93 100644 --- a/docs/guides/external-node/00_quick_start.md +++ b/docs/guides/external-node/00_quick_start.md @@ -4,7 +4,7 @@ Install `docker compose` and `Docker` -## Running zkSync node locally +## Running ZKsync node locally To start a mainnet instance, run: @@ -37,7 +37,7 @@ docker compose --file testnet-external-node-docker-compose.yml down --volumes You can see the status of the node (after recovery) in [local grafana dashboard](http://localhost:3000/d/0/external-node). -Those commands start zkSync node locally inside docker. +Those commands start ZKsync node locally inside docker. The HTTP JSON-RPC API can be accessed on port `3060` and WebSocket API can be accessed on port `3061`. @@ -57,7 +57,7 @@ The HTTP JSON-RPC API can be accessed on port `3060` and WebSocket API can be ac > This configuration is only for nodes that use snapshots recovery (the default for docker-compose setup), for > requirements for nodes running from DB dump see > [03_running.md](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/03_running.md). DB dumps -> are a way to start zkSync node with full historical transactions history +> are a way to start ZKsync node with full historical transactions history > [!NOTE] > diff --git a/docs/guides/external-node/01_intro.md b/docs/guides/external-node/01_intro.md index 440d561bc6fe..c9d01d9a87f9 100644 --- a/docs/guides/external-node/01_intro.md +++ b/docs/guides/external-node/01_intro.md @@ -1,17 +1,17 @@ # ZkSync Node Documentation -This documentation explains the basics of the zkSync Node. +This documentation explains the basics of the ZKsync Node. ## Disclaimers -- The zkSync node is in the alpha phase, and should be used with caution. -- The zkSync node is a read-only replica of the main node. We are currently working on decentralizing our infrastructure - by creating a consensus node. The zkSync node is not going to be the consensus node. +- The ZKsync node is in the alpha phase, and should be used with caution. +- The ZKsync node is a read-only replica of the main node. We are currently working on decentralizing our infrastructure + by creating a consensus node. The ZKsync node is not going to be the consensus node. -## What is the zkSync node +## What is the ZKsync node -The zkSync node is a read-replica of the main (centralized) node that can be run by external parties. It functions by -fetching data from the zkSync API and re-applying transactions locally, starting from the genesis block. The zkSync node +The ZKsync node is a read-replica of the main (centralized) node that can be run by external parties. It functions by +fetching data from the ZKsync API and re-applying transactions locally, starting from the genesis block. The ZKsync node shares most of its codebase with the main node. Consequently, when it re-applies transactions, it does so exactly as the main node did in the past. @@ -23,18 +23,18 @@ main node did in the past. ## High-level overview -At a high level, the zkSync node can be seen as an application that has the following modules: +At a high level, the ZKsync node can be seen as an application that has the following modules: - API server that provides the publicly available Web3 interface. - Synchronization layer that interacts with the main node and retrieves transactions and blocks to re-execute. - Sequencer component that actually executes and persists transactions received from the synchronization layer. -- Several checker modules that ensure the consistency of the zkSync node state. +- Several checker modules that ensure the consistency of the ZKsync node state. With the EN, you are able to: -- Locally recreate and verify the zkSync Era mainnet/testnet state. +- Locally recreate and verify the ZKsync Era mainnet/testnet state. - Interact with the recreated state in a trustless way (in a sense that the validity is locally verified, and you should - not rely on a third-party API zkSync Era provides). + not rely on a third-party API ZKsync Era provides). - Use the Web3 API without having to query the main node. - Send L2 transactions (that will be proxied to the main node). @@ -48,7 +48,7 @@ A more detailed overview of the EN's components is provided in the [components]( ## API overview -API exposed by the zkSync node strives to be Web3-compliant. If some method is exposed but behaves differently compared +API exposed by the ZKsync node strives to be Web3-compliant. If some method is exposed but behaves differently compared to Ethereum, it should be considered a bug. Please [report][contact_us] such cases. [contact_us]: https://zksync.io/contact @@ -87,7 +87,7 @@ Available methods: | `eth_getTransactionReceipt` | | | `eth_protocolVersion` | | | `eth_sendRawTransaction` | | -| `eth_syncing` | zkSync node is considered synced if it's less than 11 blocks behind the main node. | +| `eth_syncing` | ZKsync node is considered synced if it's less than 11 blocks behind the main node. | | `eth_coinbase` | Always returns a zero address | | `eth_accounts` | Always returns an empty list | | `eth_getCompilers` | Always returns an empty list | @@ -154,5 +154,5 @@ Always refer to the documentation linked above to see the list of stabilized met ### `en` namespace -This namespace contains methods that zkSync nodes call on the main node while syncing. If this namespace is enabled, +This namespace contains methods that ZKsync nodes call on the main node while syncing. If this namespace is enabled, other ENs can sync from this node. diff --git a/docs/guides/external-node/02_configuration.md b/docs/guides/external-node/02_configuration.md index 336d01479089..5b8b7512eb3e 100644 --- a/docs/guides/external-node/02_configuration.md +++ b/docs/guides/external-node/02_configuration.md @@ -1,7 +1,7 @@ # ZkSync Node Configuration -This document outlines various configuration options for the EN. Currently, the zkSync node requires the definition of -numerous environment variables. To streamline this process, we provide prepared configs for the zkSync Era - for both +This document outlines various configuration options for the EN. Currently, the ZKsync node requires the definition of +numerous environment variables. To streamline this process, we provide prepared configs for the ZKsync Era - for both [mainnet](prepared_configs/mainnet-config.env) and [testnet](prepared_configs/testnet-sepolia-config.env). You can use these files as a starting point and modify only the necessary sections. @@ -10,7 +10,7 @@ default settings.** ## Database -The zkSync node uses two databases: PostgreSQL and RocksDB. +The ZKsync node uses two databases: PostgreSQL and RocksDB. PostgreSQL serves as the main source of truth in the EN, so all the API requests fetch the state from there. The PostgreSQL connection is configured by the `DATABASE_URL`. Additionally, the `DATABASE_POOL_SIZE` variable defines the @@ -22,11 +22,11 @@ recommended to use an NVME SSD for RocksDB. RocksDB requires two variables to be ## L1 Web3 client -zkSync node requires a connection to an Ethereum node. The corresponding env variable is `EN_ETH_CLIENT_URL`. Make sure +ZKsync node requires a connection to an Ethereum node. The corresponding env variable is `EN_ETH_CLIENT_URL`. Make sure to set the URL corresponding to the correct L1 network (L1 mainnet for L2 mainnet and L1 sepolia for L2 testnet). -Note: Currently, the zkSync node makes 2 requests to the L1 per L1 batch, so the Web3 client usage for a synced node -should not be high. However, during the synchronization phase the new batches would be persisted on the zkSync node +Note: Currently, the ZKsync node makes 2 requests to the L1 per L1 batch, so the Web3 client usage for a synced node +should not be high. However, during the synchronization phase the new batches would be persisted on the ZKsync node quickly, so make sure that the L1 client won't exceed any limits (e.g. in case you use Infura). ## Exposed ports @@ -50,12 +50,12 @@ the metrics, leave this port not configured, and the metrics won't be collected. There are variables that allow you to fine-tune the limits of the RPC servers, such as limits on the number of returned entries or the limit for the accepted transaction size. Provided files contain sane defaults that are recommended for -use, but these can be edited, e.g. to make the zkSync node more/less restrictive. +use, but these can be edited, e.g. to make the ZKsync node more/less restrictive. ## JSON-RPC API namespaces There are 7 total supported API namespaces: `eth`, `net`, `web3`, `debug` - standard ones; `zks` - rollup-specific one; -`pubsub` - a.k.a. `eth_subscribe`; `en` - used by zkSync nodes while syncing. You can configure what namespaces you want +`pubsub` - a.k.a. `eth_subscribe`; `en` - used by ZKsync nodes while syncing. You can configure what namespaces you want to enable using `EN_API_NAMESPACES` and specifying namespace names in a comma-separated list. By default, all but the `debug` namespace are enabled. @@ -64,7 +64,7 @@ to enable using `EN_API_NAMESPACES` and specifying namespace names in a comma-se `MISC_LOG_FORMAT` defines the format in which logs are shown: `plain` corresponds to the human-readable format, while the other option is `json` (recommended for deployments). -`RUST_LOG` variable allows you to set up the logs granularity (e.g. make the zkSync node emit fewer logs). You can read +`RUST_LOG` variable allows you to set up the logs granularity (e.g. make the ZKsync node emit fewer logs). You can read about the format [here](https://docs.rs/env_logger/0.10.0/env_logger/#enabling-logging). `MISC_SENTRY_URL` and `MISC_OTLP_URL` variables can be configured to set up Sentry and OpenTelemetry exporters. diff --git a/docs/guides/external-node/03_running.md b/docs/guides/external-node/03_running.md index f6f76271c0c7..5789c34cdaa2 100644 --- a/docs/guides/external-node/03_running.md +++ b/docs/guides/external-node/03_running.md @@ -14,9 +14,9 @@ This configuration is approximate and should be considered as **minimal** requir - 32-core CPU - 64GB RAM - SSD storage (NVME recommended): - - Sepolia Testnet - 10GB zkSync node + 50GB PostgreSQL (at the time of writing, will grow over time, so should be + - Sepolia Testnet - 10GB ZKsync node + 50GB PostgreSQL (at the time of writing, will grow over time, so should be constantly monitored) - - Mainnet - 3TB zkSync node + 8TB PostgreSQL (at the time of writing, will grow over time, so should be constantly + - Mainnet - 3TB ZKsync node + 8TB PostgreSQL (at the time of writing, will grow over time, so should be constantly monitored) - 100 Mbps connection (1 Gbps+ recommended) @@ -36,22 +36,22 @@ it in Docker. There are many of guides on that, [here's one example](https://www.docker.com/blog/how-to-use-the-postgres-docker-official-image/). Note however that if you run PostgresSQL as a stand-alone Docker image (e.g. not in Docker-compose with a network shared -between zkSync node and Postgres), zkSync node won't be able to access Postgres via `localhost` or `127.0.0.1` URLs. To +between ZKsync node and Postgres), ZKsync node won't be able to access Postgres via `localhost` or `127.0.0.1` URLs. To make it work, you'll have to either run it with a `--network host` (on Linux) or use `host.docker.internal` instead of -`localhost` in the zkSync node configuration ([official docs][host_docker_internal]). +`localhost` in the ZKsync node configuration ([official docs][host_docker_internal]). Besides running Postgres, you are expected to have a DB dump from a corresponding env. You can restore it using `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/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) ## Running -Assuming you have the zkSync node Docker image, an env file with the prepared configuration, and you have restored your +Assuming you have the ZKsync node Docker image, an env file with the prepared configuration, and you have restored your DB with the pg dump, that is all you need. Sample running command: @@ -69,9 +69,9 @@ in RocksDB (mainly the Merkle tree) is absent. Before the node can make any prog RocksDB and verify consistency. The exact time required for that depends on the hardware configuration, but it is reasonable to expect the state rebuild on the mainnet to take more than 20 hours. -## Redeploying the zkSync node with a new PG dump +## Redeploying the ZKsync node with a new PG dump -If you've been running the zkSync node for some time and are going to redeploy it using a new PG dump, you should +If you've been running the ZKsync node for some time and are going to redeploy it using a new PG dump, you should - Stop the EN - Remove SK cache (corresponding to `EN_STATE_CACHE_PATH`) diff --git a/docs/guides/external-node/04_observability.md b/docs/guides/external-node/04_observability.md index 1199503cc924..538c1130b62e 100644 --- a/docs/guides/external-node/04_observability.md +++ b/docs/guides/external-node/04_observability.md @@ -1,6 +1,6 @@ -# zkSync node Observability +# ZKsync node Observability -The zkSync node provides several options for setting up observability. Configuring logs and sentry is described in the +The ZKsync node provides several options for setting up observability. Configuring logs and sentry is described in the [configuration](./02_configuration.md) section, so this section focuses on the exposed metrics. This section is written with the assumption that you're familiar with @@ -16,7 +16,7 @@ By default, latency histograms are distributed in the following buckets (in seco ## Metrics -zkSync node exposes a lot of metrics, a significant amount of which aren't interesting outside the development flow. +ZKsync node exposes a lot of metrics, a significant amount of which aren't interesting outside the development flow. This section's purpose is to highlight metrics that may be worth observing in the external setup. If you are not planning to scrape Prometheus metrics, please unset `EN_PROMETHEUS_PORT` environment variable to prevent @@ -25,7 +25,7 @@ memory leaking. | Metric name | Type | Labels | Description | | ---------------------------------------------- | --------- | ------------------------------------- | ------------------------------------------------------------------ | | `external_node_synced` | Gauge | - | 1 if synced, 0 otherwise. Matches `eth_call` behavior | -| `external_node_sync_lag` | Gauge | - | How many blocks behind the main node the zkSync node is | +| `external_node_sync_lag` | Gauge | - | How many blocks behind the main node the ZKsync node is | | `external_node_fetcher_requests` | Histogram | `stage`, `actor` | Duration of requests performed by the different fetcher components | | `external_node_fetcher_cache_requests` | Histogram | - | Duration of requests performed by the fetcher cache layer | | `external_node_fetcher_miniblock` | Gauge | `status` | The number of the last L2 block update fetched from the main node | @@ -40,12 +40,12 @@ memory leaking. ## Interpretation -After applying a dump, the zkSync node has to rebuild the Merkle tree to verify the correctness of the state in +After applying a dump, the ZKsync node has to rebuild the Merkle tree to verify the correctness of the state in PostgreSQL. During this stage, `server_block_number { stage='tree_lightweight_mode' }` is increasing from 0 to -`server_block_number { stage='sealed' }`, while the latter does not increase (zkSync node needs the tree to be +`server_block_number { stage='sealed' }`, while the latter does not increase (ZKsync node needs the tree to be up-to-date to progress). -After that, the zkSync node has to sync with the main node. `server_block_number { stage='sealed' }` is increasing, and +After that, the ZKsync node has to sync with the main node. `server_block_number { stage='sealed' }` is increasing, and `external_node_sync_lag` is decreasing. Once the node is synchronized, it is indicated by the `external_node_synced`. diff --git a/docs/guides/external-node/05_troubleshooting.md b/docs/guides/external-node/05_troubleshooting.md index 1179a3e43efb..43d6ae26b135 100644 --- a/docs/guides/external-node/05_troubleshooting.md +++ b/docs/guides/external-node/05_troubleshooting.md @@ -1,6 +1,6 @@ -# zkSync node Troubleshooting +# ZKsync node Troubleshooting -The zkSync node tries to follow the fail-fast principle: if an anomaly is discovered, instead of attempting state +The ZKsync node tries to follow the fail-fast principle: if an anomaly is discovered, instead of attempting state recovery, in most cases it will restart. Most of the time it will manifest as crashes, and if it happens once, it shouldn't be treated as a problem. @@ -24,8 +24,8 @@ Other kinds of panic aren't normally expected. While in most cases, the state wi ## Genesis Issues -The zkSync node is supposed to start with an applied DB dump. If you see any genesis-related errors, it probably means -the zkSync node was started without an applied dump. +The ZKsync node is supposed to start with an applied DB dump. If you see any genesis-related errors, it probably means +the ZKsync node was started without an applied dump. [contact_us]: https://zksync.io/contact @@ -43,7 +43,7 @@ you don't consider actionable, you may disable logs for a component by tweaking | WARN | "Following transport error occurred" | There was a problem with fetching data from the main node. | | WARN | "Unable to get the gas price" | There was a problem with fetching data from the main node. | | WARN | "Consistency checker error" | There are problems querying L1, check the Web3 URL you specified in the config. | -| WARN | "Reorg detected" | Reorg was detected on the main node, the zkSync node will rollback and restart | +| WARN | "Reorg detected" | Reorg was detected on the main node, the ZKsync node will rollback and restart | Same as with panics, normally it's only a problem if a WARN+ level log appears many times in a row. diff --git a/docs/guides/external-node/06_components.md b/docs/guides/external-node/06_components.md index 2210842c9d1a..733400058a82 100644 --- a/docs/guides/external-node/06_components.md +++ b/docs/guides/external-node/06_components.md @@ -1,29 +1,29 @@ -# zkSync node components +# ZKsync node components This section contains an overview of the EN's main components. ## API -The zkSync node can serve both the HTTP and the WS Web3 API, as well as PubSub. Whenever possible, it provides data +The ZKsync node can serve both the HTTP and the WS Web3 API, as well as PubSub. Whenever possible, it provides data based on the local state, with a few exceptions: - Submitting transactions: Since it is a read replica, submitted transactions are proxied to the main node, and the response is returned from the main node. -- Querying transactions: The zkSync node is not aware of the main node's mempool, and it does not sync rejected - transactions. Therefore, if a local lookup for a transaction or its receipt fails, the zkSync node will attempt the +- Querying transactions: The ZKsync node is not aware of the main node's mempool, and it does not sync rejected + transactions. Therefore, if a local lookup for a transaction or its receipt fails, the ZKsync node will attempt the same query on the main node. Apart from these cases, the API does not depend on the main node. Even if the main node is temporarily unavailable, the -zkSync node can continue to serve the state it has locally. +ZKsync node can continue to serve the state it has locally. ## Fetcher -The Fetcher component is responsible for maintaining synchronization between the zkSync node and the main node. Its +The Fetcher component is responsible for maintaining synchronization between the ZKsync node and the main node. Its primary task is to fetch new blocks in order to update the local chain state. However, its responsibilities extend beyond that. For instance, the Fetcher is also responsible for keeping track of L1 batch statuses. This involves monitoring whether locally applied batches have been committed, proven, or executed on L1. -It is worth noting that in addition to fetching the _state_, the zkSync node also retrieves the L1 gas price from the +It is worth noting that in addition to fetching the _state_, the ZKsync node also retrieves the L1 gas price from the main node for the purpose of estimating fees for L2 transactions (since this also happens based on the local state). This information is necessary to ensure that gas estimations are performed in the exact same manner as the main node, thereby reducing the chances of a transaction not being included in a block. @@ -32,23 +32,23 @@ thereby reducing the chances of a transaction not being included in a block. The State Keeper component serves as the "sequencer" part of the node. It shares most of its functionality with the main node, with one key distinction. The main node retrieves transactions from the mempool and has the authority to decide -when a specific L2 block or L1 batch should be sealed. On the other hand, the zkSync node retrieves transactions from +when a specific L2 block or L1 batch should be sealed. On the other hand, the ZKsync node retrieves transactions from the queue populated by the Fetcher and seals the corresponding blocks/batches based on the data obtained from the Fetcher queue. -The actual execution of batches takes place within the VM, which is identical in both the Main and zkSync nodes. +The actual execution of batches takes place within the VM, which is identical in both the Main and ZKsync nodes. ## Reorg Detector -In zkSync Era, it is theoretically possible for L1 batches to be reverted before the corresponding "execute" operation +In ZKsync Era, it is theoretically possible for L1 batches to be reverted before the corresponding "execute" operation is applied on L1, that is before the block is [final][finality]. Such situations are highly uncommon and typically occur due to significant issues: e.g. a bug in the sequencer implementation preventing L1 batch commitment. Prior to batch -finality, the zkSync operator can perform a rollback, reverting one or more batches and restoring the blockchain state +finality, the ZKsync operator can perform a rollback, reverting one or more batches and restoring the blockchain state to a previous point. Finalized batches cannot be reverted at all. -However, even though such situations are rare, the zkSync node must handle them correctly. +However, even though such situations are rare, the ZKsync node must handle them correctly. -To address this, the zkSync node incorporates a Reorg Detector component. This module keeps track of all L1 batches that +To address this, the ZKsync node incorporates a Reorg Detector component. This module keeps track of all L1 batches that have not yet been finalized. It compares the locally obtained state root hashes with those provided by the main node's API. If the root hashes for the latest available L1 batch do not match, the Reorg Detector searches for the specific L1 batch responsible for the divergence. Subsequently, it rolls back the local state and restarts the node. Upon restart, @@ -67,13 +67,13 @@ When the Consistency Checker detects that a particular batch has been sent to L1 known as the "block commitment" for the L1 transaction. The block commitment contains crucial data such as the state root and batch number, and is the same commitment that is used for generating a proof for the batch. The Consistency Checker then compares the locally obtained commitment with the actual commitment sent to L1. If the data does not match, -it indicates a potential bug in either the main node or zkSync node implementation or that the main node API has -provided incorrect data. In either case, the state of the zkSync node cannot be trusted, and the zkSync node enters a +it indicates a potential bug in either the main node or ZKsync node implementation or that the main node API has +provided incorrect data. In either case, the state of the ZKsync node cannot be trusted, and the ZKsync node enters a crash loop until the issue is resolved. ## Health check server -The zkSync node also exposes an additional server that returns HTTP 200 response when the zkSync node is operating -normally, and HTTP 503 response when some of the health checks don't pass (e.g. when the zkSync node is not fully +The ZKsync node also exposes an additional server that returns HTTP 200 response when the ZKsync node is operating +normally, and HTTP 503 response when some of the health checks don't pass (e.g. when the ZKsync node is not fully initialized yet). This server can be used, for example, to implement the readiness probe in an orchestration solution you use. diff --git a/docs/guides/external-node/prepared_configs/mainnet-config.env b/docs/guides/external-node/prepared_configs/mainnet-config.env index efd087b0bb32..35278205b96f 100644 --- a/docs/guides/external-node/prepared_configs/mainnet-config.env +++ b/docs/guides/external-node/prepared_configs/mainnet-config.env @@ -75,7 +75,7 @@ RUST_LIB_BACKTRACE=1 # -------------- THE FOLLOWING VARIABLES DEPEND ON THE ENV --------------- # ------------------------------------------------------------------------ -# URL of the main zkSync node. +# URL of the main ZKsync node. EN_MAIN_NODE_URL=https://zksync2-mainnet.zksync.io EN_L2_CHAIN_ID=324 diff --git a/docs/guides/external-node/prepared_configs/testnet-goerli-config-deprecated.env b/docs/guides/external-node/prepared_configs/testnet-goerli-config-deprecated.env index 2c1723460a27..eb8b6481d75f 100644 --- a/docs/guides/external-node/prepared_configs/testnet-goerli-config-deprecated.env +++ b/docs/guides/external-node/prepared_configs/testnet-goerli-config-deprecated.env @@ -75,7 +75,7 @@ RUST_LIB_BACKTRACE=1 # -------------- THE FOLLOWING VARIABLES DEPEND ON THE ENV --------------- # ------------------------------------------------------------------------ -# URL of the main zkSync node. +# URL of the main ZKsync node. EN_MAIN_NODE_URL=https://zksync2-testnet.zksync.dev EN_L2_CHAIN_ID=280 diff --git a/docs/guides/external-node/prepared_configs/testnet-sepolia-config.env b/docs/guides/external-node/prepared_configs/testnet-sepolia-config.env index d85543a8ec56..98e2ee6bd510 100644 --- a/docs/guides/external-node/prepared_configs/testnet-sepolia-config.env +++ b/docs/guides/external-node/prepared_configs/testnet-sepolia-config.env @@ -75,7 +75,7 @@ RUST_LIB_BACKTRACE=1 # -------------- THE FOLLOWING VARIABLES DEPEND ON THE ENV --------------- # ------------------------------------------------------------------------ -# URL of the main zkSync node. +# URL of the main ZKsync node. EN_MAIN_NODE_URL=https://sepolia.era.zksync.dev EN_L2_CHAIN_ID=300 diff --git a/docs/guides/launch.md b/docs/guides/launch.md index 2889216dbbe9..35588debd3ae 100644 --- a/docs/guides/launch.md +++ b/docs/guides/launch.md @@ -1,6 +1,6 @@ # Running the application -This document covers common scenarios for launching zkSync applications set locally. +This document covers common scenarios for launching ZKsync applications set locally. ## Prerequisites diff --git a/docs/guides/repositories.md b/docs/guides/repositories.md index d43bab72e5e2..36a52a2ae76f 100644 --- a/docs/guides/repositories.md +++ b/docs/guides/repositories.md @@ -1,6 +1,6 @@ # Repositories -## zkSync +## ZKsync ### Core components @@ -54,10 +54,10 @@ | --------------------------------------------------------------- | ----------------------------------------------------------------------------- | | [era-test-node](https://github.com/matter-labs/era-test-node) | In memory node for development and smart contract debugging | | [local-setup](https://github.com/matter-labs/local-setup) | Docker-based zk server (together with L1), that can be used for local testing | -| [zksync-cli](https://github.com/matter-labs/zksync-cli) | Command line tool to interact with zksync | -| [block-explorer](https://github.com/matter-labs/block-explorer) | Online blockchain browser for viewing and analyzing zkSync chain | -| [dapp-portal](https://github.com/matter-labs/dapp-portal) | zkSync Wallet + Bridge DApp | -| [hardhat-zksync](https://github.com/matter-labs/hardhat-zksync) | zkSync Hardhat plugins | +| [zksync-cli](https://github.com/matter-labs/zksync-cli) | Command line tool to interact with ZKsync | +| [block-explorer](https://github.com/matter-labs/block-explorer) | Online blockchain browser for viewing and analyzing ZKsync chain | +| [dapp-portal](https://github.com/matter-labs/dapp-portal) | ZKsync Wallet + Bridge DApp | +| [hardhat-zksync](https://github.com/matter-labs/hardhat-zksync) | ZKsync Hardhat plugins | | [zksolc-bin](https://github.com/matter-labs/zksolc-bin) | solc compiler binaries | | [zkvyper-bin](https://github.com/matter-labs/zkvyper-bin) | vyper compiler binaries | @@ -65,16 +65,16 @@ | Public repository | Description | | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | -| [zksync-web-era-docs](https://github.com/matter-labs/zksync-docs) | [Public zkSync documentation](https://docs.zksync.io), API descriptions etc. | +| [zksync-web-era-docs](https://github.com/matter-labs/zksync-docs) | [Public ZKsync documentation](https://docs.zksync.io), API descriptions etc. | | [zksync-contract-templates](https://github.com/matter-labs/zksync-contract-templates) | Quick contract deployment and testing with tools like Hardhat on Solidity or Vyper | | [zksync-frontend-templates](https://github.com/matter-labs/zksync-frontend-templates) | Rapid UI development with templates for Vue, React, Next.js, Nuxt, Vite, etc. | -| [zksync-scripting-templates](https://github.com/matter-labs/zksync-scripting-templates) | Automated interactions and advanced zkSync operations using Node.js | -| [tutorials](https://github.com/matter-labs/tutorials) | Tutorials for developing on zkSync | +| [zksync-scripting-templates](https://github.com/matter-labs/zksync-scripting-templates) | Automated interactions and advanced ZKsync operations using Node.js | +| [tutorials](https://github.com/matter-labs/tutorials) | Tutorials for developing on ZKsync | -## zkSync Lite +## ZKsync Lite | Public repository | Description | | --------------------------------------------------------------------------- | -------------------------------- | -| [zksync](https://github.com/matter-labs/zksync) | zkSync Lite implementation | -| [zksync-lite-docs](https://github.com/matter-labs/zksync-lite-docs) | Public zkSync Lite documentation | +| [zksync](https://github.com/matter-labs/zksync) | ZKsync Lite implementation | +| [ZKsync-lite-docs](https://github.com/matter-labs/zksync-lite-docs) | Public ZKsync Lite documentation | | [zksync-dapp-checkout](https://github.com/matter-labs/zksync-dapp-checkout) | Batch payments DApp | diff --git a/docs/guides/setup-dev.md b/docs/guides/setup-dev.md index b8db0c1575c7..4e005fc2795f 100644 --- a/docs/guides/setup-dev.md +++ b/docs/guides/setup-dev.md @@ -35,7 +35,7 @@ foundryup --branch master ## Supported operating systems -zkSync currently can be launched on any \*nix operating system (e.g. any linux distribution or MacOS). +ZKsync currently can be launched on any \*nix operating system (e.g. any linux distribution or MacOS). If you're using Windows, then make sure to use WSL 2, since WSL 1 is known to cause troubles. @@ -43,7 +43,7 @@ Additionally, if you are going to use WSL 2, make sure that your project is loca accessing NTFS partitions from within WSL is very slow. If you're using MacOS with an ARM processor (e.g. M1/M2), make sure that you are working in the _native_ environment -(e.g. your terminal and IDE don't run in Rosetta, and your toolchain is native). Trying to work with zkSync code via +(e.g. your terminal and IDE don't run in Rosetta, and your toolchain is native). Trying to work with ZKsync code via Rosetta may cause problems that are hard to spot and debug, so make sure to check everything before you start. If you are a NixOS user or would like to have a reproducible environment, skip to the section about `nix`. diff --git a/docs/specs/blocks_batches.md b/docs/specs/blocks_batches.md index ce678edf937d..c5d846a39736 100644 --- a/docs/specs/blocks_batches.md +++ b/docs/specs/blocks_batches.md @@ -196,7 +196,7 @@ The hash of an L2 block is To add a transaction hash to the current miniblock we use the `appendTransactionToCurrentL2Block` [function](https://github.com/code-423n4/2023-10-zksync/blob/ef99273a8fdb19f5912ca38ba46d6bd02071363d/code/system-contracts/contracts/SystemContext.sol#L373). -Since zkSync is a state-diff based rollup, there is no way to deduce the hashes of the L2 blocks based on the +Since ZKsync is a state-diff based rollup, there is no way to deduce the hashes of the L2 blocks based on the transactions’ in the batch (because there is no access to the transaction’s hashes). At the same time, in order to server `blockhash` method, the VM requires the knowledge of some of the previous L2 block hashes. In order to save up on pubdata (by making sure that the same storage slots are reused, i.e. we only have repeated writes) we diff --git a/docs/specs/data_availability/pubdata.md b/docs/specs/data_availability/pubdata.md index 3584a0430557..0bbb753411c1 100644 --- a/docs/specs/data_availability/pubdata.md +++ b/docs/specs/data_availability/pubdata.md @@ -1,6 +1,6 @@ # Handling pubdata in Boojum -Pubdata in zkSync can be divided up into 4 different categories: +Pubdata in ZKsync can be divided up into 4 different categories: 1. L2 to L1 Logs 2. L2 to L1 Messages @@ -13,7 +13,7 @@ pre-Boojum system these are represented as separate fields while for boojum they array. Once 4844 gets integrated this bytes array will move from being part of the calldata to blob data. While the structure of the pubdata changes, the way in which one can go about pulling the information will remain the -same. Basically, we just need to filter all of the transactions to the L1 zkSync contract for only the `commitBatches` +same. Basically, we just need to filter all of the transactions to the L1 ZKsync contract for only the `commitBatches` transactions where the proposed block has been referenced by a corresponding `executeBatches` call (the reason for this is that a committed or even proven block can be reverted but an executed one cannot). Once we have all the committed batches that have been executed, we then will pull the transaction input and the relevant fields, applying them in order @@ -106,7 +106,7 @@ be [applied](https://github.com/code-423n4/2023-10-zksync/blob/ef99273a8fdb19f5912ca38ba46d6bd02071363d/code/system-contracts/contracts/L1Messenger.sol#L110): `chainedLogsHash = keccak256(chainedLogsHash, hashedLog)`. L2→L1 logs have the same 88-byte format as in the current -version of zkSync. +version of ZKsync. Note, that the user is charged for necessary future the computation that will be needed to calculate the final merkle root. It is roughly 4x higher than the cost to calculate the hash of the leaf, since the eventual tree might have be 4x @@ -179,7 +179,7 @@ With Boojum, `factoryDeps` are included within the `totalPubdata` bytes and have ### Compressed Bytecode Publishing -This part stays the same in a pre and post boojum zkSync. Unlike uncompressed bytecode which are published as part of +This part stays the same in a pre and post boojum ZKsync. Unlike uncompressed bytecode which are published as part of `factoryDeps`, compressed bytecodes are published as long l2 → l1 messages which can be seen [here](https://github.com/code-423n4/2023-10-zksync/blob/ef99273a8fdb19f5912ca38ba46d6bd02071363d/code/system-contracts/contracts/Compressor.sol#L80). @@ -254,7 +254,7 @@ markAsPublished(hash(_bytecode)) ## Storage diff publishing -zkSync is a statediff-based rollup and so publishing the correct state diffs plays an integral role in ensuring data +ZKsync is a statediff-based rollup and so publishing the correct state diffs plays an integral role in ensuring data availability. ### How publishing of storage diffs worked before Boojum @@ -287,9 +287,9 @@ These two fields would be then included into the block commitment and checked by ### Difference between initial and repeated writes -zkSync publishes state changes that happened within the batch instead of transactions themselves. Meaning, that for +ZKsync publishes state changes that happened within the batch instead of transactions themselves. Meaning, that for instance some storage slot `S` under account `A` has changed to value `V`, we could publish a triple of `A,S,V`. Users -by observing all the triples could restore the state of zkSync. However, note that our tree unlike Ethereum’s one is not +by observing all the triples could restore the state of ZKsync. However, note that our tree unlike Ethereum’s one is not account based (i.e. there is no first layer of depth 160 of the merkle tree corresponding to accounts and second layer of depth 256 of the merkle tree corresponding to users). Our tree is “flat”, i.e. a slot `S` under account `A` is just stored in the leaf number `H(S,A)`. Our tree is of depth 256 + 8 (the 256 is for these hashed account/key pairs and 8 is diff --git a/docs/specs/l1_l2_communication/l1_to_l2.md b/docs/specs/l1_l2_communication/l1_to_l2.md index ed1605a039a6..f4a23219e277 100644 --- a/docs/specs/l1_l2_communication/l1_to_l2.md +++ b/docs/specs/l1_l2_communication/l1_to_l2.md @@ -1,6 +1,6 @@ # Handling L1→L2 ops -The transactions on zkSync can be initiated not only on L2, but also on L1. There are two types of transactions that can +The transactions on ZKsync can be initiated not only on L2, but also on L1. There are two types of transactions that can be initiated on L1: - Priority operations. These are the kind of operations that any user can create. @@ -103,7 +103,7 @@ We also remember that the upgrade transaction has been processed in this batch ( ### Revert -In a very rare event when the team needs to revert the batch with the upgrade on zkSync, the +In a very rare event when the team needs to revert the batch with the upgrade on ZKsync, the `l2SystemContractsUpgradeBatchNumber` is [reset](https://github.com/code-423n4/2023-10-zksync/blob/ef99273a8fdb19f5912ca38ba46d6bd02071363d/code/contracts/ethereum/contracts/zksync/facets/Executor.sol#L412). diff --git a/docs/specs/l1_smart_contracts.md b/docs/specs/l1_smart_contracts.md index 207920476602..65c408714ba3 100644 --- a/docs/specs/l1_smart_contracts.md +++ b/docs/specs/l1_smart_contracts.md @@ -235,8 +235,8 @@ The diagram below outlines the complete journey from the initiation of an operat ## ValidatorTimelock -An intermediate smart contract between the validator EOA account and the zkSync smart contract. Its primary purpose is -to provide a trustless means of delaying batch execution without modifying the main zkSync contract. zkSync actively +An intermediate smart contract between the validator EOA account and the ZKsync smart contract. Its primary purpose is +to provide a trustless means of delaying batch execution without modifying the main ZKsync contract. ZKsync actively monitors the chain activity and reacts to any suspicious activity by freezing the chain. This allows time for investigation and mitigation before resuming normal operations. @@ -246,12 +246,12 @@ the Alpha stage. This contract consists of four main functions `commitBatches`, `proveBatches`, `executeBatches`, and `revertBatches`, which can be called only by the validator. -When the validator calls `commitBatches`, the same calldata will be propagated to the zkSync contract (`DiamondProxy` +When the validator calls `commitBatches`, the same calldata will be propagated to the ZKsync contract (`DiamondProxy` through `call` where it invokes the `ExecutorFacet` through `delegatecall`), and also a timestamp is assigned to these batches to track the time these batches are committed by the validator to enforce a delay between committing and execution of batches. Then, the validator can prove the already committed batches regardless of the mentioned timestamp, -and again the same calldata (related to the `proveBatches` function) will be propagated to the zkSync contract. After -the `delay` is elapsed, the validator is allowed to call `executeBatches` to propagate the same calldata to zkSync +and again the same calldata (related to the `proveBatches` function) will be propagated to the ZKsync contract. After +the `delay` is elapsed, the validator is allowed to call `executeBatches` to propagate the same calldata to ZKsync contract. The owner of the ValidatorTimelock contract is the same as the owner of the Governance contract - Matter Labs multisig. diff --git a/docs/specs/prover/overview.md b/docs/specs/prover/overview.md index a7f814a458a8..5ac6dd59b772 100644 --- a/docs/specs/prover/overview.md +++ b/docs/specs/prover/overview.md @@ -1,4 +1,4 @@ -# Intro to zkSync’s ZK +# Intro to ZKsync’s ZK This page is specific to our cryptography. For a general introduction, please read: [https://docs.zksync.io/build/developer-reference/rollups.html](https://docs.zksync.io/build/developer-reference/rollups.html) @@ -6,8 +6,8 @@ This page is specific to our cryptography. For a general introduction, please re As a ZK rollup, we want everything to be verified by cryptography and secured by Ethereum. The power of ZK allows for transaction compression, reducing fees for users while inheriting the same security. -ZK Proofs allow a verifier to easily check whether a prover has done a computation correctly. For zkSync, the prover -will prove the correct execution of zkSync’s EVM, and a smart contract on Ethereum will verify the proof is correct. +ZK Proofs allow a verifier to easily check whether a prover has done a computation correctly. For ZKsync, the prover +will prove the correct execution of ZKsync’s EVM, and a smart contract on Ethereum will verify the proof is correct. In more detail, there are several steps. @@ -46,7 +46,7 @@ It is very important that every step is actually “constrained”. The prover m If the circuit is missing a constraint, then a malicious prover can create proofs that will pass verification but not be valid. The ZK terminology for this is that an underconstrained circuit could lead to a soundness error. -### What do zkSync’s circuits prove +### What do ZKsync’s circuits prove The main goal of our circuits is to prove correct execution of our VM. This includes proving each opcode run within the VM, as well as other components such as precompiles, storage, and circuits that connect everything else together. This diff --git a/docs/specs/prover/zk_terminology.md b/docs/specs/prover/zk_terminology.md index a0b7d101a64f..a747bb962998 100644 --- a/docs/specs/prover/zk_terminology.md +++ b/docs/specs/prover/zk_terminology.md @@ -20,14 +20,14 @@ revealing the actual information. ### Constraint -A constraint is a rule or restriction that a specific operation or set of operations must follow. zkSync uses +A constraint is a rule or restriction that a specific operation or set of operations must follow. ZKsync uses constraints to verify the validity of certain operations, and in the generation of proofs. Constraints can be missing, causing bugs, or there could be too many constraints, leading to restricted operations. ### Constraint degree The "constraint degree" of a constraint system refers to the maximum degree of the polynomial gates in the system. In -simpler terms, it’s the highest power of polynomial equations of the constraint system. At zkSync, we allow gates with +simpler terms, it’s the highest power of polynomial equations of the constraint system. At ZKsync, we allow gates with degree 8 or lower. ### Constraint system @@ -42,7 +42,7 @@ assignment of values to these Variables, ensuring that the rules still hold true The geometry defines the number of rows and columns in the constraint system. As part of PLONK arithmetization, the witness data is arranged into a grid, where each row defines a gate (or a few gates), and the columns are as long as -needed to hold all of the witness data. At zkSync, we have ~164 base witness columns. +needed to hold all of the witness data. At ZKsync, we have ~164 base witness columns. ### Log @@ -64,9 +64,9 @@ prover to the verifier. ### Prover -In our zkSync zk-rollup context, the prover is used to process a set of transactions executing smart contracts in a +In our ZKsync zk-rollup context, the prover is used to process a set of transactions executing smart contracts in a succinct and efficient manner. It computes proofs that all the transactions are correct and ensures a valid transition -from one state to another. The proof will be sent to a Verifier smart contract on Ethereum. At zkSync, we prove state +from one state to another. The proof will be sent to a Verifier smart contract on Ethereum. At ZKsync, we prove state diffs of a block of transactions, in order to prove the new state root state is valid. ### Satisfiable diff --git a/docs/specs/zk_evm/account_abstraction.md b/docs/specs/zk_evm/account_abstraction.md index c106fafc880f..0ea2e3fa4a09 100644 --- a/docs/specs/zk_evm/account_abstraction.md +++ b/docs/specs/zk_evm/account_abstraction.md @@ -1,6 +1,6 @@ # Account abstraction -One of the other important features of zkSync is the support of account abstraction. It is highly recommended to read +One of the other important features of ZKsync is the support of account abstraction. It is highly recommended to read the documentation on our AA protocol here: [https://docs.zksync.io/build/developer-reference/account-abstraction](https://docs.zksync.io/build/developer-reference/account-abstraction) diff --git a/docs/specs/zk_evm/bootloader.md b/docs/specs/zk_evm/bootloader.md index ec7f8378151d..41dfefa85168 100644 --- a/docs/specs/zk_evm/bootloader.md +++ b/docs/specs/zk_evm/bootloader.md @@ -6,7 +6,7 @@ On standard Ethereum clients, the workflow for executing blocks is the following 2. Gather the state changes (if the transaction has not reverted), apply them to the state. 3. Go back to step (1) if the block gas limit has not been yet exceeded. -However, having such flow on zkSync (i.e. processing transaction one-by-one) would be too inefficient, since we have to +However, having such flow on ZKsync (i.e. processing transaction one-by-one) would be too inefficient, since we have to run the entire proving workflow for each individual transaction. That’s why we need the _bootloader_: instead of running N transactions separately, we run the entire batch (set of blocks, more can be found [here](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/Smart%20contract%20Section/Batches%20%26%20L2%20blocks%20on%20zkSync.md)) @@ -19,7 +19,7 @@ unlike system contracts, the bootloader’s code is not stored anywhere on L2. T bootloader’s address as formal. It only exists for the sake of providing some value to `this` / `msg.sender`/etc. When someone calls the bootloader address (e.g. to pay fees) the EmptyContract’s code is actually invoked. -Bootloader is the program that accepts an array of transactions and executes the entire zkSync batch. This section will +Bootloader is the program that accepts an array of transactions and executes the entire ZKsync batch. This section will expand on its invariants and methods. ## Playground bootloader vs proved bootloader @@ -62,12 +62,12 @@ supported: - Note, that unlike type 1 and type 2 transactions, `reserved0` field can be set to a non-zero value, denoting that this legacy transaction is EIP-155-compatible and its RLP encoding (as well as signature) should contain the `chainId` of the system. -- `txType`: 1. It means that the transaction is of type 1, i.e. transactions access list. zkSync does not support access +- `txType`: 1. It means that the transaction is of type 1, i.e. transactions access list. ZKsync does not support access lists in any way, so no benefits of fulfilling this list will be provided. The access list is assumed to be empty. The same restrictions as for type 0 are enforced, but also `reserved0` must be 0. - `txType`: 2. It is EIP1559 transactions. The same restrictions as for type 1 apply, but now `maxFeePerErgs` may not be equal to `getMaxPriorityFeePerErg`. -- `txType`: 113. It is zkSync transaction type. This transaction type is intended for AA support. The only restriction +- `txType`: 113. It is ZKsync transaction type. This transaction type is intended for AA support. The only restriction that applies to this transaction type: fields `reserved0..reserved4` must be equal to 0. - `txType`: 254. It is a transaction type that is used for upgrading the L2 system. This is the only type of transaction is allowed to start a transaction out of the name of the contracts in kernel space. @@ -238,7 +238,7 @@ succeeded, the slot `2^19 - 1024 + i` will be marked as 1 and 0 otherwise. ## L2 transactions -On zkSync, every address is a contract. Users can start transactions from their EOA accounts, because every address that +On ZKsync, every address is a contract. Users can start transactions from their EOA accounts, because every address that does not have any contract deployed on it implicitly contains the code defined in the [DefaultAccount.sol](https://github.com/code-423n4/2023-10-zksync/blob/main/code/system-contracts/contracts/DefaultAccount.sol) file. Whenever anyone calls a contract that is not in kernel space (i.e. the address is ≥ 2^16) and does not have any @@ -323,7 +323,7 @@ Also, we [set](https://github.com/code-423n4/2023-10-zksync/blob/ef99273a8fdb19f5912ca38ba46d6bd02071363d/code/system-contracts/bootloader/bootloader.yul#L3812) the fictive L2 block’s data. Then, we call the system context to ensure that it publishes the timestamp of the L2 block as well as L1 batch. We also reset the `txNumberInBlock` counter to avoid its state diffs from being published on L1. -You can read more about block processing on zkSync +You can read more about block processing on ZKsync [here](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/Smart%20contract%20Section/Batches%20&%20L2%20blocks%20on%20zkSync.md). After that, we publish the hash as well as the number of priority operations in this batch. More on it diff --git a/docs/specs/zk_evm/fee_model.md b/docs/specs/zk_evm/fee_model.md index a75d45a737b9..78f9d38ae366 100644 --- a/docs/specs/zk_evm/fee_model.md +++ b/docs/specs/zk_evm/fee_model.md @@ -1,4 +1,4 @@ -# zkSync fee model +# ZKsync fee model This document will assume that you already know how gas & fees work on Ethereum. @@ -6,18 +6,18 @@ On Ethereum, all the computational, as well as storage costs, are represented vi certain amount of gas, which is generally constant (though it may change during [upgrades](https://blog.ethereum.org/2021/03/08/ethereum-berlin-upgrade-announcement)). -zkSync as well as other L2s have the issue which does not allow to adopt the same model as the one for Ethereum so +ZKsync as well as other L2s have the issue which does not allow to adopt the same model as the one for Ethereum so easily: the main reason is the requirement for publishing of the pubdata on Ethereum. This means that prices for L2 transactions will depend on the volatile L1 gas prices and can not be simply hardcoded. ## High-level description -zkSync, being a zkRollup is required to prove every operation with zero knowledge proofs. That comes with a few nuances. +ZKsync, being a zkRollup is required to prove every operation with zero knowledge proofs. That comes with a few nuances. ### `gas_per_pubdata_limit` -As already mentioned, the transactions on zkSync depend on volatile L1 gas costs to publish the pubdata for batch, -verify proofs, etc. For this reason, zkSync-specific EIP712 transactions contain the `gas_per_pubdata_limit` field in +As already mentioned, the transactions on ZKsync depend on volatile L1 gas costs to publish the pubdata for batch, +verify proofs, etc. For this reason, ZKsync-specific EIP712 transactions contain the `gas_per_pubdata_limit` field in them, denoting the maximum price in _gas_ that the operator \*\*can charge from users for a single byte of pubdata. For Ethereum transactions (which do not contain this field), it is enforced that the operator will not use a value @@ -28,23 +28,23 @@ larger value than a certain constant. The operations tend to have different “complexity”/”pricing” in zero knowledge proof terms than in standard CPU terms. For instance, `keccak256` which was optimized for CPU performance, will cost more to prove. -That’s why you will find the prices for operations on zkSync a lot different from the ones on Ethereum. +That’s why you will find the prices for operations on ZKsync a lot different from the ones on Ethereum. ### Different intrinsic costs Unlike Ethereum, where the intrinsic cost of transactions (`21000` gas) is used to cover the price of updating the -balances of the users, the nonce and signature verification, on zkSync these prices are _not_ included in the intrinsic +balances of the users, the nonce and signature verification, on ZKsync these prices are _not_ included in the intrinsic costs for transactions, due to the native support of account abstraction, meaning that each account type may have their own transaction cost. In theory, some may even use more zk-friendly signature schemes or other kinds of optimizations to allow cheaper transactions for their users. -That being said, zkSync transactions do come with some small intrinsic costs, but they are mostly used to cover costs +That being said, ZKsync transactions do come with some small intrinsic costs, but they are mostly used to cover costs related to the processing of the transaction by the bootloader which can not be easily measured in code in real-time. These are measured via testing and are hard coded. ### Batch overhead & limited resources of the batch -In order to process the batch, the zkSync team has to pay for proving of the batch, committing to it, etc. Processing a +In order to process the batch, the ZKsync team has to pay for proving of the batch, committing to it, etc. Processing a batch involves some operational costs as well. All of these values we call “Batch overhead”. It consists of two parts: - The L2 requirements for proving the circuits (denoted in L2 gas). @@ -57,7 +57,7 @@ resources_. While on Ethereum, the main reason for the existence of batch gas limit is to keep the system decentralized & load low, i.e. assuming the existence of the correct hardware, only time would be a requirement for a batch to adhere to. In the -case of zkSync batches, there are some limited resources the batch should manage: +case of ZKsync batches, there are some limited resources the batch should manage: - **Time.** The same as on Ethereum, the batch should generally not take too much time to be closed in order to provide better UX. To represent the time needed we use a batch gas limit, note that it is higher than the gas limit for a @@ -71,7 +71,7 @@ case of zkSync batches, there are some limited resources the batch should manage single slot happening in the same batch need to be published only once, we need to publish all the batch’s public data only after the transaction has been processed. Right now, we publish all the data with the storage diffs as well as L2→L1 messages, etc in a single transaction at the end of the batch. Most nodes have limit of 128kb per transaction - and so this is the limit that each zkSync batch should adhere to. + and so this is the limit that each ZKsync batch should adhere to. Each transaction spends the batch overhead proportionally to how close it consumes the resources above. @@ -79,7 +79,7 @@ Note, that before the transaction is executed, the system can not know how many transaction will actually take, so we need to charge for the worst case and provide the refund at the end of the transaction. -### How `baseFee` works on zkSync +### How `baseFee` works on ZKsync In order to protect us from DDoS attacks we need to set a limited `MAX_TRANSACTION_GAS_LIMIT` per transaction. Since the computation costs are relatively constant for us, we _could_ use a “fair” `baseFee` equal to the real costs for us to @@ -114,16 +114,16 @@ sure that the excess gas will be spent on the pubdata). ### High-level: conclusion -The zkSync fee model is meant to be the basis of the long-term fee model, which provides both robustness and security. +The ZKsync fee model is meant to be the basis of the long-term fee model, which provides both robustness and security. One of the most distinctive parts of it is the existing of the batch overhead, which is proportional for the resources consumed by the transaction. -The other distinctive feature of the fee model used on zkSync is the abundance of refunds, i.e.: +The other distinctive feature of the fee model used on ZKsync is the abundance of refunds, i.e.: - For unused limited system resources. - For overpaid computation. -This is needed because of the relatively big upfront payments required in zkSync to provide DDoS security. +This is needed because of the relatively big upfront payments required in ZKsync to provide DDoS security. ## Formalization @@ -156,7 +156,7 @@ contain almost any arbitrary value depending on the capacity of batch that we wa `BOOTLOADER_MEMORY_FOR_TXS` (_BM_) — The size of the bootloader memory that is used for transaction encoding (i.e. excluding the constant space, preallocated for other purposes). -`GUARANTEED_PUBDATA_PER_TX` (_PG_) — The guaranteed number of pubdata that should be possible to pay for in one zkSync +`GUARANTEED_PUBDATA_PER_TX` (_PG_) — The guaranteed number of pubdata that should be possible to pay for in one ZKsync batch. This is a number that should be enough for most reasonable cases. #### Derived constants diff --git a/docs/specs/zk_evm/precompiles.md b/docs/specs/zk_evm/precompiles.md index 4874bcdf9404..c6adc00410bb 100644 --- a/docs/specs/zk_evm/precompiles.md +++ b/docs/specs/zk_evm/precompiles.md @@ -19,7 +19,7 @@ nor the instructions to put the parameters in memory. For Go-Ethereum, the code being run is written in Go, and the gas costs are defined in each precompile spec. -In the case of zkSync Era, ecAdd and ecMul precompiles are written as a smart contract for two reasons: +In the case of ZKsync Era, ecAdd and ecMul precompiles are written as a smart contract for two reasons: - zkEVM needs to be able to prove their execution (and at the moment it cannot do that if the code being run is executed outside the VM) @@ -36,7 +36,7 @@ The arithmetic is carried out with the field elements encoded in the Montgomery operating in the Montgomery form speeds up the computation but also because the native modular multiplication, which is carried out by Yul's `mulmod` opcode, is very inefficient. -Instructions set on zkSync and EVM are different, so the performance of the same Yul/Solidity code can be efficient on +Instructions set on ZKsync and EVM are different, so the performance of the same Yul/Solidity code can be efficient on EVM, but not on zkEVM and opposite. One such very inefficient command is `mulmod`. On EVM there is a native opcode that makes modulo multiplication and it diff --git a/docs/specs/zk_evm/system_contracts.md b/docs/specs/zk_evm/system_contracts.md index 136d2136cd9e..48f072435519 100644 --- a/docs/specs/zk_evm/system_contracts.md +++ b/docs/specs/zk_evm/system_contracts.md @@ -26,7 +26,7 @@ values are set on genesis explicitly. Notably, if in the future we want to upgra This contract is also responsible for ensuring validity and consistency of batches, L2 blocks and virtual blocks. The implementation itself is rather straightforward, but to better understand this contract, please take a look at the [page](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/Smart%20contract%20Section/Batches%20&%20L2%20blocks%20on%20zkSync.md) -about the block processing on zkSync. +about the block processing on ZKsync. ## AccountCodeStorage @@ -86,7 +86,7 @@ and returns `success=1`. ## SHA256 & Keccak256 -Note that, unlike Ethereum, keccak256 is a precompile (_not an opcode_) on zkSync. +Note that, unlike Ethereum, keccak256 is a precompile (_not an opcode_) on ZKsync. These system contracts act as wrappers for their respective crypto precompile implementations. They are expected to be used frequently, especially keccak256, since Solidity computes storage slots for mapping and dynamic arrays with its @@ -128,7 +128,7 @@ More information on the extraAbiParams can be read ## KnownCodeStorage -This contract is used to store whether a certain code hash is “known”, i.e. can be used to deploy contracts. On zkSync, +This contract is used to store whether a certain code hash is “known”, i.e. can be used to deploy contracts. On ZKsync, the L2 stores the contract’s code _hashes_ and not the codes themselves. Therefore, it must be part of the protocol to ensure that no contract with unknown bytecode (i.e. hash with an unknown preimage) is ever deployed. @@ -151,9 +151,9 @@ The KnownCodesStorage contract is also responsible for ensuring that all the “ ## ContractDeployer & ImmutableSimulator -`ContractDeployer` is a system contract responsible for deploying contracts on zkSync. It is better to understand how it -works in the context of how the contract deployment works on zkSync. Unlike Ethereum, where `create`/`create2` are -opcodes, on zkSync these are implemented by the compiler via calls to the ContractDeployer system contract. +`ContractDeployer` is a system contract responsible for deploying contracts on ZKsync. It is better to understand how it +works in the context of how the contract deployment works on ZKsync. Unlike Ethereum, where `create`/`create2` are +opcodes, on ZKsync these are implemented by the compiler via calls to the ContractDeployer system contract. For additional security, we also distinguish the deployment of normal contracts and accounts. That’s why the main methods that will be used by the user are `create`, `create2`, `createAccount`, `create2Account`, which simulate the @@ -168,7 +168,7 @@ the L2 contract). Generally, rollups solve this issue in two ways: - XOR/ADD some kind of constant to addresses during L1→L2 communication. That’s how rollups closer to full EVM-equivalence solve it, since it allows them to maintain the same derivation rules on L1 at the expense of contract accounts on L1 having to redeploy on L2. -- Have different derivation rules from Ethereum. That is the path that zkSync has chosen, mainly because since we have +- Have different derivation rules from Ethereum. That is the path that ZKsync has chosen, mainly because since we have different bytecode than on EVM, CREATE2 address derivation would be different in practice anyway. You can see the rules for our address derivation in `getNewAddressCreate2`/ `getNewAddressCreate` methods in the @@ -179,7 +179,7 @@ way to support EVM bytecodes in the future. ### **Deployment nonce** -On Ethereum, the same nonce is used for CREATE for accounts and EOA wallets. On zkSync this is not the case, we use a +On Ethereum, the same nonce is used for CREATE for accounts and EOA wallets. On ZKsync this is not the case, we use a separate nonce called “deploymentNonce” to track the nonces for accounts. This was done mostly for consistency with custom accounts and for having multicalls feature in the future. @@ -197,13 +197,13 @@ custom accounts and for having multicalls feature in the future. - Calls `ImmutableSimulator` to set the immutables that are to be used for the deployed contract. Note how it is different from the EVM approach: on EVM when the contract is deployed, it executes the initCode and -returns the deployedCode. On zkSync, contracts only have the deployed code and can set immutables as storage variables +returns the deployedCode. On ZKsync, contracts only have the deployed code and can set immutables as storage variables returned by the constructor. ### **Constructor** On Ethereum, the constructor is only part of the initCode that gets executed during the deployment of the contract and -returns the deployment code of the contract. On zkSync, there is no separation between deployed code and constructor +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 @@ -228,7 +228,7 @@ part of the compiler specification. This contract treats it simply as mapping fr 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 +`ImmutableSimulator.getImmutable(getCodeAddress(), index)`. Note that on ZKsync it is possible to get the current 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). @@ -248,7 +248,7 @@ are not in kernel space and have no contract deployed on them. This address: ## L1Messenger -A contract used for sending arbitrary length L2→L1 messages from zkSync to L1. While zkSync natively supports a rather +A contract used for sending arbitrary length L2→L1 messages from ZKsync to L1. While ZKsync natively supports a rather limited number of L1→L2 logs, which can transfer only roughly 64 bytes of data a time, we allowed sending nearly-arbitrary length L2→L1 messages with the following trick: diff --git a/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/call.md b/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/call.md index 71b40a0cb2ab..060ba8ec2346 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/call.md +++ b/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/call.md @@ -6,7 +6,7 @@ The call type is encoded on the assembly level, so we will describe the common h distinctions if there are any. For more information, see the -[zkSync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#call-staticcall-delegatecall). +[ZKsync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#call-staticcall-delegatecall). ## [CALL](https://www.evm.codes/#f1?fork=shanghai) diff --git a/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/create.md b/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/create.md index a35703545d62..eeecb93526ab 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/create.md +++ b/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/create.md @@ -3,7 +3,7 @@ The EVM CREATE instructions are handled similarly. For more information, see the -[zkSync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#create-create2). +[ZKsync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#create-create2). ## [CREATE](https://www.evm.codes/#f0?fork=shanghai) diff --git a/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/return.md b/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/return.md index 0e1756b6f193..014a2a3e47c1 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/return.md +++ b/docs/specs/zk_evm/vm_specification/compiler/instructions/evm/return.md @@ -12,7 +12,7 @@ is common for Yul and EVMLA representations. ## [RETURN](https://www.evm.codes/#f3?fork=shanghai) This instruction works differently in deploy code. For more information, see -[the zkSync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#return-stop). +[the ZKsync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#return-stop). ### LLVM IR diff --git a/docs/specs/zk_evm/vm_specification/compiler/instructions/evmla.md b/docs/specs/zk_evm/vm_specification/compiler/instructions/evmla.md index 3304c2efe66c..06549962244b 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/instructions/evmla.md +++ b/docs/specs/zk_evm/vm_specification/compiler/instructions/evmla.md @@ -26,7 +26,7 @@ LLVM IR codegen references: The same as [setimmutable](yul.md#setimmutable). For more information, see the -[zkSync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#setimmutable-loadimmutable). +[ZKsync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#setimmutable-loadimmutable). LLVM IR codegen references: @@ -38,7 +38,7 @@ LLVM IR codegen references: The same as [loadimmutable](yul.md#loadimmutable). For more information, see the -[zkSync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#setimmutable-loadimmutable). +[ZKsync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#setimmutable-loadimmutable). LLVM IR codegen references: @@ -50,7 +50,7 @@ LLVM IR codegen references: The same as [linkersymbol](yul.md#linkersymbol). For more information, see the -[zkSync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/libraries). +[ZKsync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/libraries). [The LLVM IR generator code](https://github.com/matter-labs/era-compiler-solidity/blob/main/src/yul/parser/statement/expression/function_call/mod.rs#L956). diff --git a/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/call.md b/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/call.md index 9a6b39d54d7d..bada21b359d0 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/call.md +++ b/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/call.md @@ -1,4 +1,4 @@ -# zkSync Era Extension Simulation (call) +# ZKsync Era Extension Simulation (call) NOTES: diff --git a/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/overview.md b/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/overview.md index 889865e5f9be..a3fedb085c78 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/overview.md +++ b/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/overview.md @@ -1,6 +1,6 @@ -# zkSync Era Extensions +# ZKsync Era Extensions -Since we have no control over the Solidity compiler, we are using temporary hacks to support zkSync-specific +Since we have no control over the Solidity compiler, we are using temporary hacks to support ZKsync-specific instructions: - [Call substitutions](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions/extensions/call.md) diff --git a/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/verbatim.md b/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/verbatim.md index f2b1be0ff4f6..7291e5bf46a1 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/verbatim.md +++ b/docs/specs/zk_evm/vm_specification/compiler/instructions/extensions/verbatim.md @@ -1,4 +1,4 @@ -# zkSync Era Extension Simulation (verbatim) +# ZKsync Era Extension Simulation (verbatim) NOTES: diff --git a/docs/specs/zk_evm/vm_specification/compiler/instructions/overview.md b/docs/specs/zk_evm/vm_specification/compiler/instructions/overview.md index bc8daf3b2e1a..56515c9eadce 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/instructions/overview.md +++ b/docs/specs/zk_evm/vm_specification/compiler/instructions/overview.md @@ -5,7 +5,7 @@ In this specification, instructions are grouped by their relevance to the EVM in - [Native EVM instructions](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions/extensions/overview.md). - [Yul auxiliary instructions](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions/yul.md). - [EVM legacy assembly auxiliary instructions](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions/evmla.md). -- [zkSync Era extensions](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions/extensions/overview.md). +- [ZKsync Era extensions](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions/extensions/overview.md). Most of the EVM native instructions are represented in both Yul and EVM legacy assembly IRs. If they are not, it is stated explicitly in the description of each instruction. @@ -25,7 +25,7 @@ Every instruction is translated via two IRs available in the Solidity compiler u ## Yul Extensions -At the moment there is no way of adding zkSync-specific instructions to Yul as long as we use the official Solidity +At the moment there is no way of adding ZKsync-specific instructions to Yul as long as we use the official Solidity compiler, which would produce an error on an unknown instruction. There are two ways of supporting such instructions: one for Solidity and one for Yul. @@ -38,13 +38,13 @@ optimizing them out and is not emitting compilation errors. To see the list of available instructions, visit this page: -[zkSync Era Extension Simulation (call)](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions/extensions/call.md) +[ZKsync Era Extension Simulation (call)](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions/extensions/call.md) ### The Yul Mode -The non-call zkSync-specific instructions are only available in the Yul mode of **zksolc**. +The non-call ZKsync-specific instructions are only available in the Yul mode of **zksolc**. To have better compatibility, they are implemented as `verbatim` instructions with some predefined keys. To see the list of available instructions, visit this page: -[zkSync Era Extension Simulation (verbatim)](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions/extensions/verbatim.md) +[ZKsync Era Extension Simulation (verbatim)](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions/extensions/verbatim.md) diff --git a/docs/specs/zk_evm/vm_specification/compiler/instructions/yul.md b/docs/specs/zk_evm/vm_specification/compiler/instructions/yul.md index 4841eee78521..55ae98166af8 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/instructions/yul.md +++ b/docs/specs/zk_evm/vm_specification/compiler/instructions/yul.md @@ -41,7 +41,7 @@ destination. For more information, see Writes immutables to the auxiliary heap. For more information, see the -[zkSync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#setimmutable-loadimmutable). +[ZKsync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#setimmutable-loadimmutable). LLVM IR codegen references: @@ -54,7 +54,7 @@ Reads immutables from the [ImmutableSimulator](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/system_contracts.md#simulator-of-immutables). For more information, see the -[zkSync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#setimmutable-loadimmutable). +[ZKsync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#setimmutable-loadimmutable). LLVM IR codegen references: @@ -71,7 +71,7 @@ compiler will return the list of deployable libraries not provided with `--libra like Hardhat to automatically deploy libraries. For more information, see the -[zkSync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/libraries). +[ZKsync Era documentation](https://docs.zksync.io/build/developer-reference/ethereum-differences/libraries). [The LLVM IR generator code](https://github.com/matter-labs/era-compiler-solidity/blob/main/src/yul/parser/statement/expression/function_call/mod.rs#L956). diff --git a/docs/specs/zk_evm/vm_specification/compiler/overview.md b/docs/specs/zk_evm/vm_specification/compiler/overview.md index d55b86756162..0af322e0b489 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/overview.md +++ b/docs/specs/zk_evm/vm_specification/compiler/overview.md @@ -8,7 +8,7 @@ | solc | The original Solidity compiler, developed by the Ethereum community. Called by zksolc as a subprocess to get the IRs of the source code of the project. | | LLVM | The compiler framework, used for optimizations and assembly generation. | | EraVM assembler/linker | The tool written in Rust. Translates the assembly emitted by LLVM to the target bytecode. | -| Virtual machine | The zkSync Era virtual machine called EraVM with a custom instruction set. | +| Virtual machine | The ZKsync Era virtual machine called EraVM with a custom instruction set. | | Intermediate representation (IR) | The data structure or code used internally by the compiler to represent source code. | | Yul | One of the Solidity IRs. Is a superset of the assembly available in Solidity. Used by default for contracts written in Solidity ≥0.8. | | EVMLA | One of the Solidity IRs called EVM legacy assembly. Is a predecessor of Yul, but must closer to the pure EVM bytecode. Used by default for contracts written in Solidity <0.8. | @@ -17,11 +17,11 @@ | EraVM bytecode | The smart contract bytecode, executed by EraVM. | | Stack | The segment of the non-persistent contract memory. Consists of two parts: 1. The global data, accessible from anywhere. Available to the compiler, not available to the user code. 2. The function-local stack frame without the depth limit like in EVM. | | Heap | The segment of the non-persistent contract memory. All the data is globally accessible by both the compiler and user code. The allocation is handled by the solc’s Yul/EVMLA allocator only. | -| Auxiliary heap | The segment of the non-persistent contract memory, introduced to avoid conflicts with the solc’s allocator. All the data is globally accessible by the compiler only. The allocation is handled by the zksolc’s compiler only. All contract calls specific to zkSync, including the system contracts, are made via the auxiliary heap. It is also used to return data (e.g. the array of immutables) from the constructor. | +| Auxiliary heap | The segment of the non-persistent contract memory, introduced to avoid conflicts with the solc’s allocator. All the data is globally accessible by the compiler only. The allocation is handled by the zksolc’s compiler only. All contract calls specific to ZKsync, including the system contracts, are made via the auxiliary heap. It is also used to return data (e.g. the array of immutables) from the constructor. | | Calldata | The segment of the non-persistent contract memory. The heap or auxiliary heap of the parent/caller contract. | | Return data | The segment of the non-persistent contract memory. The heap or auxiliary heap of the child/callee contract. | | Contract storage | The persistent contract memory. No relevant differences from that of EVM. | -| System contracts | The special set of zkSync kernel contracts written in Solidity by Matter Labs. | +| System contracts | The special set of ZKsync kernel contracts written in Solidity by Matter Labs. | | Contract context | The special storage of VM that keeps data like the current address, the caller’s address, etc. | ## Concepts @@ -95,7 +95,7 @@ the sake of assisting the upcoming audit. | calldataload | CALLDATALOAD | calldata | Stack: 1 input. Calldata: read 32 bytes. Stack: 1 output | - | 0 in deploy code. | | calldatacopy | CALLDATACOPY | calldata, heap | Stack: 3 inputs. Calldata: read N bytes. Heap: write N bytes | - | Generated by solc in the runtime code only. Copies 0 in deploy code. | | calldatasize | CALLDATASIZE | calldata | Stack: 1 output | - | 0 in deploy code. | -| codecopy | CODECOPY | calldata | Stack: 3 inputs. Calldata: read N bytes. Heap: write N bytes | - | Generated by solc in the deploy code only, but is treated as CALLDATACOPY, since the constructor arguments are calldata in zkSync 2.0. Compile time error in Yul runtime code. Copies 0 in EVMLA runtime code. | +| codecopy | CODECOPY | calldata | Stack: 3 inputs. Calldata: read N bytes. Heap: write N bytes | - | Generated by solc in the deploy code only, but is treated as CALLDATACOPY, since the constructor arguments are calldata in ZKsync 2.0. Compile time error in Yul runtime code. Copies 0 in EVMLA runtime code. | | codesize | CODESIZE | calldata | Stack: 1 output | - | - | | returndatacopy | RETURNDATACOPY | return data, heap | Stack: 3 inputs. Return data: read N bytes. Heap: write N bytes | - | - | | returndatasize | RETURNDATASIZE | return data | Stack: 1 output | - | - | @@ -137,6 +137,6 @@ the sake of assisting the upcoming audit. | pc | PC | unsupported | - | - | Compile time error | | selfdestruct | SELFDESTRUCT | unsupported | - | - | Compile time error | -For more information on how zkSync Era achieves EVM-equivalence, see the +For more information on how ZKsync Era achieves EVM-equivalence, see the [Instructions](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/VM%20Section/How%20compiler%20works/instructions) section. 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 0a68d0c4f299..3e328d663693 100644 --- a/docs/specs/zk_evm/vm_specification/compiler/system_contracts.md +++ b/docs/specs/zk_evm/vm_specification/compiler/system_contracts.md @@ -7,7 +7,7 @@ special handling, see ## Types of System Contracts -There are several types of System Contracts from the perspective of how they are handled by the zkSync Era compilers: +There are several types of System Contracts from the perspective of how they are handled by the ZKsync Era compilers: 1. [Environmental data storage](#environmental-data-storage). 2. [KECCAK256 hash function](#keccak256-hash-function). @@ -46,14 +46,14 @@ For reference, see Handling of this function is similar to [Environmental Data Storage](#environmental-data-storage) with one difference: Since EVM also uses heap to store the calldata for `KECCAK256`, the required memory chunk is allocated by the IR -generator, and zkSync Era compiler does not need to use [the auxiliary heap](#auxiliary-heap). +generator, and ZKsync Era compiler does not need to use [the auxiliary heap](#auxiliary-heap). For reference, see [the LLVM IR codegen source code](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/context/function/llvm_runtime.rs). ### Contract Deployer -See [handling CREATE][docs-create] and [dependency code substitution instructions][docs-data] on zkSync Era +See [handling CREATE][docs-create] and [dependency code substitution instructions][docs-data] on ZKsync Era documentation. For reference, see LLVM IR codegen for @@ -85,7 +85,7 @@ For reference, see ### Simulator of Immutables -See [handling immutables][docs-immutable] on zkSync Era documentation. +See [handling immutables][docs-immutable] on ZKsync Era documentation. For reference, see LLVM IR codegen for [instructions for immutables](https://github.com/matter-labs/era-compiler-llvm-context/blob/main/src/eravm/evm/immutable.rs) diff --git a/etc/contracts-test-data/README.md b/etc/contracts-test-data/README.md index d08f934e8456..532703ad210f 100644 --- a/etc/contracts-test-data/README.md +++ b/etc/contracts-test-data/README.md @@ -1,4 +1,4 @@ # Contracts test data This folder contains data for contracts that are being used for testing to check the correctness of the smart contract -flow in zkSync. +flow in ZKsync. diff --git a/etc/contracts-test-data/contracts/custom-account/SystemContractsCaller.sol b/etc/contracts-test-data/contracts/custom-account/SystemContractsCaller.sol index e4d241116a1e..3ec2b81a1074 100644 --- a/etc/contracts-test-data/contracts/custom-account/SystemContractsCaller.sol +++ b/etc/contracts-test-data/contracts/custom-account/SystemContractsCaller.sol @@ -6,7 +6,7 @@ import {MSG_VALUE_SYSTEM_CONTRACT, MSG_VALUE_SIMULATOR_IS_SYSTEM_BIT} from "./Co import "./Utils.sol"; // Addresses used for the compiler to be replaced with the -// zkSync-specific opcodes during the compilation. +// ZKsync-specific opcodes during the compilation. // IMPORTANT: these are just compile-time constants and are used // only if used in-place by Yul optimizer. address constant TO_L1_CALL_ADDRESS = address((1 << 16) - 1); diff --git a/etc/contracts-test-data/contracts/custom-account/TransactionHelper.sol b/etc/contracts-test-data/contracts/custom-account/TransactionHelper.sol index 7fc883ed882c..82747b88d358 100644 --- a/etc/contracts-test-data/contracts/custom-account/TransactionHelper.sol +++ b/etc/contracts-test-data/contracts/custom-account/TransactionHelper.sol @@ -10,7 +10,7 @@ import "./interfaces/IContractDeployer.sol"; import {BASE_TOKEN_SYSTEM_CONTRACT, BOOTLOADER_FORMAL_ADDRESS} from "./Constants.sol"; import "./RLPEncoder.sol"; -/// @dev The type id of zkSync's EIP-712-signed transaction. +/// @dev The type id of ZKsync's EIP-712-signed transaction. uint8 constant EIP_712_TX_TYPE = 0x71; /// @dev The type id of legacy transactions. @@ -20,7 +20,7 @@ uint8 constant EIP_2930_TX_TYPE = 0x01; /// @dev The type id of EIP1559 transactions. uint8 constant EIP_1559_TX_TYPE = 0x02; -/// @notice Structure used to represent zkSync transaction. +/// @notice Structure used to represent ZKsync transaction. struct Transaction { // The type of the transaction. uint256 txType; @@ -118,7 +118,7 @@ library TransactionHelper { } } - /// @notice Encode hash of the zkSync native transaction type. + /// @notice Encode hash of the ZKsync native transaction type. /// @return keccak256 hash of the EIP-712 encoded representation of transaction function _encodeHashEIP712Transaction(Transaction calldata _transaction) private @@ -251,7 +251,7 @@ library TransactionHelper { // Hash of EIP2930 transactions is encoded the following way: // H(0x01 || RLP(chain_id, nonce, gas_price, gas_limit, destination, amount, data, access_list)) // - // Note, that on zkSync access lists are not supported and should always be empty. + // Note, that on ZKsync access lists are not supported and should always be empty. // Encode all fixed-length params to avoid "stack too deep error" bytes memory encodedFixedLengthParams; @@ -290,7 +290,7 @@ library TransactionHelper { // Otherwise the length is not encoded at all. } - // On zkSync, access lists are always zero length (at least for now). + // On ZKsync, access lists are always zero length (at least for now). bytes memory encodedAccessListLength = RLPEncoder.encodeListLen(0); bytes memory encodedListLength; @@ -327,7 +327,7 @@ library TransactionHelper { // Hash of EIP1559 transactions is encoded the following way: // H(0x02 || RLP(chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list)) // - // Note, that on zkSync access lists are not supported and should always be empty. + // Note, that on ZKsync access lists are not supported and should always be empty. // Encode all fixed-length params to avoid "stack too deep error" bytes memory encodedFixedLengthParams; @@ -368,7 +368,7 @@ library TransactionHelper { // Otherwise the length is not encoded at all. } - // On zkSync, access lists are always zero length (at least for now). + // On ZKsync, access lists are always zero length (at least for now). bytes memory encodedAccessListLength = RLPEncoder.encodeListLen(0); bytes memory encodedListLength; diff --git a/etc/contracts-test-data/contracts/custom-account/Utils.sol b/etc/contracts-test-data/contracts/custom-account/Utils.sol index da3d4eb60878..e562948942d7 100644 --- a/etc/contracts-test-data/contracts/custom-account/Utils.sol +++ b/etc/contracts-test-data/contracts/custom-account/Utils.sol @@ -3,7 +3,7 @@ pragma solidity >=0.8.0; /** * @author Matter Labs - * @dev Common utilities used in zkSync system contracts + * @dev Common utilities used in ZKsync system contracts */ library Utils { function safeCastToU128(uint256 _x) internal pure returns (uint128) { diff --git a/etc/env/base/README.md b/etc/env/base/README.md index 8bf4ceb48cdb..c583685d953c 100644 --- a/etc/env/base/README.md +++ b/etc/env/base/README.md @@ -1,6 +1,6 @@ -# Base configuration for zkSync stack +# Base configuration for ZKsync stack -This folder contains the template for generating the configuration for zkSync applications. Configs in this folder are +This folder contains the template for generating the configuration for ZKsync applications. Configs in this folder are assigned default values suitable for development. Since all the applications expect configuration to be set via the environment variables, these configs are compiled into diff --git a/etc/env/base/chain.toml b/etc/env/base/chain.toml index 8e0c37b76935..88a4c71bbb9b 100644 --- a/etc/env/base/chain.toml +++ b/etc/env/base/chain.toml @@ -1,13 +1,13 @@ -# zkSync chain parameters +# ZKsync chain parameters [chain.eth] # Name of the used Ethereum network network = "localhost" -# Name of current zkSync network +# Name of current ZKsync network # Used for Sentry environment zksync_network = "localhost" -# ID of current zkSync network treated as ETH network ID. -# Used to distinguish zkSync from other Web3-capable networks. +# ID of current ZKsync network treated as ETH network ID. +# Used to distinguish ZKsync from other Web3-capable networks. zksync_network_id = 270 [chain.state_keeper] @@ -78,10 +78,10 @@ max_gas_per_batch = 200000000 max_pubdata_per_batch = 100000 # The version of the fee model to use. -# - `V1`, the first model that was used in zkSync Era. In this fee model, the pubdata price must be pegged to the L1 gas price. +# - `V1`, the first model that was used in ZKsync Era. In this fee model, the pubdata price must be pegged to the L1 gas price. # Also, the fair L2 gas price is expected to only include the proving/computation price for the operator and not the costs that come from # processing the batch on L1. -# - `V2`, the second model that was used in zkSync Era. There the pubdata price might be independent from the L1 gas price. Also, +# - `V2`, the second model that was used in ZKsync Era. There the pubdata price might be independent from the L1 gas price. Also, # The fair L2 gas price is expected to both the proving/computation price for the operator and the costs that come from # processing the batch on L1. fee_model_version = "V1" diff --git a/etc/env/base/contracts.toml b/etc/env/base/contracts.toml index b88a3e179eae..491bd19ea4bf 100644 --- a/etc/env/base/contracts.toml +++ b/etc/env/base/contracts.toml @@ -1,4 +1,4 @@ -# Addresses of the deployed zkSync contracts. +# Addresses of the deployed ZKsync contracts. # Values of this file are updated automatically by the contract deploy script. [contracts] diff --git a/etc/env/base/private.toml b/etc/env/base/private.toml index 1d6f8dabf82b..e6367e013519 100644 --- a/etc/env/base/private.toml +++ b/etc/env/base/private.toml @@ -9,7 +9,7 @@ test_database_prover_url = "postgres://postgres:notsecurepassword@localhost:5433 [eth_sender.sender] # Set in env file for development, production, staging and testnet. operator_private_key = "0x27593fea79697e947890ecbecce7901b0008345e5d7259710d0dd5e500d040be" -# Address to be used for zkSync account managing the interaction with a contract on Ethereum. +# Address to be used for ZKsync account managing the interaction with a contract on Ethereum. # Derived from the `OPERATOR_PRIVATE_KEY`. operator_commit_eth_addr = "0xde03a0B5963f75f1C8485B355fF6D30f3093BDE7" diff --git a/etc/test_config/README.md b/etc/test_config/README.md index ac7ecffd4ec7..3ec67f196736 100644 --- a/etc/test_config/README.md +++ b/etc/test_config/README.md @@ -1,6 +1,6 @@ -# Test data for zkSync +# Test data for ZKsync -This folder contains the data required for various zkSync tests. +This folder contains the data required for various ZKsync tests. Directory contains three subfolders: diff --git a/flake.nix b/flake.nix index 018aebb15da9..0287d4cf09d1 100644 --- a/flake.nix +++ b/flake.nix @@ -20,7 +20,7 @@ # ################################################################################################### { - description = "zkSync-era"; + description = "ZKsync-era"; inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.05"; flake-utils.url = "github:numtide/flake-utils"; diff --git a/infrastructure/local-setup-preparation/README.md b/infrastructure/local-setup-preparation/README.md index fe59f930bf4c..6f3c97961434 100644 --- a/infrastructure/local-setup-preparation/README.md +++ b/infrastructure/local-setup-preparation/README.md @@ -1,6 +1,6 @@ # Scripts for local setup preparation -This project contains scripts that should be executed when preparing the zkSync local setup used by outside developers, +This project contains scripts that should be executed when preparing the ZKsync local setup used by outside developers, e.g. deposit ETH to some of the test accounts. With the server running (`zk server`), execute the following from `$ZKSYNC_HOME` to fund the L2 wallets diff --git a/infrastructure/local-setup-preparation/src/index.ts b/infrastructure/local-setup-preparation/src/index.ts index 805d13aadcdb..9d8b7efea66d 100644 --- a/infrastructure/local-setup-preparation/src/index.ts +++ b/infrastructure/local-setup-preparation/src/index.ts @@ -16,7 +16,7 @@ async function depositWithRichAccounts() { const handles: Promise<any>[] = []; if (!process.env.CONTRACTS_BRIDGEHUB_PROXY_ADDR) { - throw new Error('zkSync L1 Main contract address was not found'); + throw new Error('ZKsync L1 Main contract address was not found'); } // During the preparation for the local node, the L2 server is not available, so diff --git a/infrastructure/protocol-upgrade/src/index.ts b/infrastructure/protocol-upgrade/src/index.ts index c94d280495f2..d78726437852 100644 --- a/infrastructure/protocol-upgrade/src/index.ts +++ b/infrastructure/protocol-upgrade/src/index.ts @@ -15,7 +15,7 @@ async function main() { const ZKSYNC_HOME = process.env.ZKSYNC_HOME; if (!ZKSYNC_HOME) { - throw new Error('Please set $ZKSYNC_HOME to the root of zkSync repo!'); + throw new Error('Please set $ZKSYNC_HOME to the root of ZKsync repo!'); } else { process.chdir(ZKSYNC_HOME); } diff --git a/infrastructure/zk/src/index.ts b/infrastructure/zk/src/index.ts index 1fd05252a591..0c11c110c6e3 100644 --- a/infrastructure/zk/src/index.ts +++ b/infrastructure/zk/src/index.ts @@ -60,7 +60,7 @@ async function main() { const ZKSYNC_HOME = process.env.ZKSYNC_HOME; if (!ZKSYNC_HOME) { - throw new Error('Please set $ZKSYNC_HOME to the root of zkSync repo!'); + throw new Error('Please set $ZKSYNC_HOME to the root of ZKsync repo!'); } else { process.chdir(ZKSYNC_HOME); } diff --git a/prover/prover_cli/README.md b/prover/prover_cli/README.md index 74f291c8d573..053744914b97 100644 --- a/prover/prover_cli/README.md +++ b/prover/prover_cli/README.md @@ -1,6 +1,6 @@ # Prover CLI -CLI tool for performing maintenance of a zkSync Prover +CLI tool for performing maintenance of a ZKsync Prover ## Installation diff --git a/zk_toolbox/Cargo.toml b/zk_toolbox/Cargo.toml index 6f9c288438ed..15e1ddc4cdcb 100644 --- a/zk_toolbox/Cargo.toml +++ b/zk_toolbox/Cargo.toml @@ -17,7 +17,7 @@ authors = ["The Matter Labs Team <hello@matterlabs.dev>"] exclude = ["./github"] repository = "https://github.com/matter-labs/zk_toolbox/" description = "ZK Toolbox is a set of tools for working with zk stack." -keywords = ["zk", "cryptography", "blockchain", "ZKStack", "zkSync"] +keywords = ["zk", "cryptography", "blockchain", "ZKStack", "ZKsync"] [workspace.dependencies] diff --git a/zk_toolbox/crates/common/src/term/logger.rs b/zk_toolbox/crates/common/src/term/logger.rs index b505123114be..33a88bd961e2 100644 --- a/zk_toolbox/crates/common/src/term/logger.rs +++ b/zk_toolbox/crates/common/src/term/logger.rs @@ -14,7 +14,7 @@ fn term_write(msg: impl Display) { } pub fn intro() { - cliclak_intro(style(" zkSync toolbox ").on_cyan().black()).unwrap(); + cliclak_intro(style(" ZKsync toolbox ").on_cyan().black()).unwrap(); } pub fn outro(msg: impl Display) { diff --git a/zk_toolbox/crates/config/src/consts.rs b/zk_toolbox/crates/config/src/consts.rs index 90645ff19acf..9141d044af94 100644 --- a/zk_toolbox/crates/config/src/consts.rs +++ b/zk_toolbox/crates/config/src/consts.rs @@ -18,7 +18,7 @@ pub(crate) const INITIAL_DEPLOYMENT_FILE: &str = "initial_deployments.yaml"; pub(crate) const ERC20_DEPLOYMENT_FILE: &str = "erc20_deployments.yaml"; /// Name of the contracts file pub(crate) const CONTRACTS_FILE: &str = "contracts.yaml"; -/// Main repository for the zkSync project +/// Main repository for the ZKsync project pub const ZKSYNC_ERA_GIT_REPO: &str = "https://github.com/matter-labs/zksync-era"; /// Name of the docker-compose file inside zksync repository pub const DOCKER_COMPOSE_FILE: &str = "docker-compose.yml";