diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml index 60f25512..7ae069ae 100644 --- a/.github/ISSUE_TEMPLATE/config.yml +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -1,5 +1,5 @@ blank_issues_enabled: true contact_links: - name: zksync-developers Discussion - url: https://github.com/zkSync-Community-Hub/zkync-developers/discussions - about: These forms are for zkSync Docs related issues. If you have questions or need help, please visit the zksync-developers Discussion. + url: https://github.com/ZKsync-Community-Hub/zkync-developers/discussions + about: These forms are for ZKsync Docs related issues. If you have questions or need help, please visit the zksync-developers Discussion. diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index d7df2fbd..bee51f1d 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,6 +1,6 @@ - + - Plugin: verify your contracts programmatically using the [Hardhat verify plugin](/build/tooling/hardhat/hardhat-zksync-verify) If you have any problems migrating your project, [send us a message on Discord](https://join.zksync.dev/). diff --git a/content/00.build/40.tooling/20.hardhat/30.compiling-libraries.md b/content/00.build/40.tooling/20.hardhat/30.compiling-libraries.md index f6bbcf81..fa1bd2ff 100644 --- a/content/00.build/40.tooling/20.hardhat/30.compiling-libraries.md +++ b/content/00.build/40.tooling/20.hardhat/30.compiling-libraries.md @@ -11,7 +11,7 @@ i.e. does not use external calls to access the library methods and uses the code - _Non-inlinable_. The ones that have at least one `public` or `external` method. While they may be inlined by the Solidity compiler, they are not inlined when compiled to Yul representation. -Since Yul is an intermediate step when compiling to %%zk_zkevm_label%% bytecode, this means that these libraries can not be inlined by the zkSync compiler. +Since Yul is an intermediate step when compiling to %%zk_zkevm_label%% bytecode, this means that these libraries can not be inlined by the ZKsync compiler. **Libraries with public methods must be deployed separately, and their addresses should be passed as arguments when compiling the main contract.** Usage of the methods of this library will be replaced with calls to its address. @@ -104,9 +104,9 @@ This documentation provides details on how the tool handles the compilation and ### Manual deployment To resolve the issue, you need to create _a separate project_, where only the library file will be located. -After deploying _only_ the library to zkSync Era, you should get the address of the deployed library and pass it to the compiler settings. +After deploying _only_ the library to ZKsync Era, you should get the address of the deployed library and pass it to the compiler settings. The process of deploying the library is the same as deploying a smart contract. -You can learn how to deploy smart contracts on zkSync Era in the [getting started](getting-started#compile-and-deploy-a-contract) guide. +You can learn how to deploy smart contracts on ZKsync Era in the [getting started](getting-started#compile-and-deploy-a-contract) guide. Let's say that the address of the deployed library is `0xF9702469Dfb84A9aC171E284F71615bd3D3f1EdC`. To pass this address to the compiler parameters, open the `hardhat.config.ts` file of the project where the `Main` contract is located @@ -130,7 +130,7 @@ module.exports = { defaultNetwork: "zkTestnet", networks: { zkTestnet: { - url: "%%zk_testnet_rpc_url%%", // URL of the zkSync network RPC + url: "%%zk_testnet_rpc_url%%", // URL of the ZKsync network RPC ethNetwork: "%%zk_testnet_identifier%%", // Can also be the RPC URL of the Ethereum network (e.g. `https://sepolia.infura.io/v3/`) zksync: true, }, diff --git a/content/00.build/40.tooling/20.hardhat/35.hardhat-zksync.md b/content/00.build/40.tooling/20.hardhat/35.hardhat-zksync.md index 32fe822b..dcc3f503 100644 --- a/content/00.build/40.tooling/20.hardhat/35.hardhat-zksync.md +++ b/content/00.build/40.tooling/20.hardhat/35.hardhat-zksync.md @@ -3,7 +3,7 @@ title: hardhat-zksync description: --- -The hardhat-zksync plugin provides a convenient method for bundling and accessing a range of zkSync-related Hardhat plugins. +The hardhat-zksync plugin provides a convenient method for bundling and accessing a range of ZKsync-related Hardhat plugins. This approach simplifies the process of utilizing these plugins and promotes ease of use. List of contained plugins: @@ -18,7 +18,7 @@ List of contained plugins: ::callout{icon="i-heroicons-information-circle" color="blue"} **Popular Hardhat plugins**: You can find a list of all official plugins [here](getting-started). -Also, zkSync supports some other [popular plugins](other-plugins) that can be used. +Also, ZKsync supports some other [popular plugins](other-plugins) that can be used. :: ### Installation diff --git a/content/00.build/40.tooling/20.hardhat/40.hardhat-zksync-solc.md b/content/00.build/40.tooling/20.hardhat/40.hardhat-zksync-solc.md index 0cf786bd..a8a626c8 100644 --- a/content/00.build/40.tooling/20.hardhat/40.hardhat-zksync-solc.md +++ b/content/00.build/40.tooling/20.hardhat/40.hardhat-zksync-solc.md @@ -3,7 +3,7 @@ title: hardhat-zksync-solc description: --- -This plugin is used to provide a convenient interface for compiling Solidity smart contracts before deploying them to zkSync Era. +This plugin is used to provide a convenient interface for compiling Solidity smart contracts before deploying them to ZKsync Era. Learn more about the latest updates in the [changelog](%%zk_git_repo_hardhat-zksync%%/blob/main/packages/hardhat-zksync-solc/CHANGELOG.md). @@ -68,7 +68,7 @@ zksolc: { compilerPath: "zksolc", // optional. Ignored for compilerSource "docker". Can be used if compiler is located in a specific folder libraries:{}, // optional. References to non-inlinable libraries missingLibrariesPath: "./.zksolc-libraries-cache/missingLibraryDependencies.json", // optional. This path serves as a cache that stores all the libraries that are missing or have dependencies on other libraries. A `hardhat-zksync-deploy` plugin uses this cache later to compile and deploy the libraries, especially when the `deploy-zksync:libraries` task is executed - isSystem: false, // optional. Enables Yul instructions available only for zkSync system contracts and libraries + isSystem: false, // optional. Enables Yul instructions available only for ZKsync system contracts and libraries forceEvmla: false, // optional. Falls back to EVM legacy assembly if there is a bug with Yul optimizer: { enabled: true, // optional. True by default @@ -100,7 +100,7 @@ Learn more about [compiling libraries here](compiling-libraries) A `hardhat-zksync-deploy` plugin uses this cache later to compile and deploy the libraries, especially when the `deploy-zksync:libraries` task is executed. Defaults to `./.zksolc-libraries-cache/missingLibraryDependencies.json`. -- `isSystem` - required if contracts use enables Yul instructions available only for zkSync system contracts and libraries +- `isSystem` - required if contracts use enables Yul instructions available only for ZKsync system contracts and libraries - `forceEvmla` - falls back to EVM legacy assembly if there is an issue with the Yul IR compilation pipeline. - `optimizer` - Compiler optimizations: - `enabled`: `true` (default) or `false`. @@ -140,7 +140,7 @@ The `compilerVersion.json` file is used by the plugin to get the latest availabl This file undergoes invalidation every 24 hours (currently), subsequently being updated with fresh information. This approach is implemented to provide a caching mechanism, avoiding the risk of encountering GitHub throttling issues during fetching new releases. -### zkSync Era Solidity compiler +### ZKsync Era Solidity compiler Due to [the identified limitations](/zk-stack/components/compiler/toolchain/solidity#limitations) of the [upstream Solidity compiler](https://github.com/ethereum/solidity), @@ -183,7 +183,7 @@ networks: { zksync: false, // disables zksolc compiler }, zkSyncTestnet: { - url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of zkSync Era network. + url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of ZKsync Era network. ethNetwork: "%%zk_testnet_identifier%%", // The Ethereum Web3 RPC URL, or the identifier of the network (e.g. `mainnet` or `sepolia`) zksync: true, // enables zksolc compiler } diff --git a/content/00.build/40.tooling/20.hardhat/50.hardhat-zksync-vyper.md b/content/00.build/40.tooling/20.hardhat/50.hardhat-zksync-vyper.md index b210ec04..fd5133ba 100644 --- a/content/00.build/40.tooling/20.hardhat/50.hardhat-zksync-vyper.md +++ b/content/00.build/40.tooling/20.hardhat/50.hardhat-zksync-vyper.md @@ -4,7 +4,7 @@ description: --- The [@matterlabs/hardhat-zksync-vyper](https://www.npmjs.com/package/@matterlabs/hardhat-zksync-vyper) plugin -provides an interface for compiling Vyper smart contracts before deploying them to zkSync Era. +provides an interface for compiling Vyper smart contracts before deploying them to ZKsync Era. Learn more about the latest updates in the [changelog](%%zk_git_repo_hardhat-zksync%%/blob/main/packages/hardhat-zksync-vyper/CHANGELOG.md). diff --git a/content/00.build/40.tooling/20.hardhat/60.hardhat-zksync-deploy.md b/content/00.build/40.tooling/20.hardhat/60.hardhat-zksync-deploy.md index c521496c..5bcdaf49 100644 --- a/content/00.build/40.tooling/20.hardhat/60.hardhat-zksync-deploy.md +++ b/content/00.build/40.tooling/20.hardhat/60.hardhat-zksync-deploy.md @@ -3,7 +3,7 @@ title: hardhat-zksync-deploy description: --- -This plugin provides utilities for deploying smart contracts on zkSync Era with artifacts built by the `@matterlabs/hardhat-zksync-solc` +This plugin provides utilities for deploying smart contracts on ZKsync Era with artifacts built by the `@matterlabs/hardhat-zksync-solc` or `@matterlabs/hardhat-zksync-vyper` plugins. ## Prerequisite @@ -11,21 +11,21 @@ or `@matterlabs/hardhat-zksync-vyper` plugins. To use the `hardhat-zksync-deploy` in your project, we recommend that: - You have a Node installation and `yarn` or `npm` package manager. -- You are already familiar with deploying smart contracts on zkSync Era. +- You are already familiar with deploying smart contracts on ZKsync Era. -If not, please refer to the first section of the [zkSync 101 material](/build/zksync-101/hello-zksync). +If not, please refer to the first section of the [ZKsync 101 material](/build/zksync-101/hello-zksync). - A wallet with sufficient Sepolia `ETH` on Ethereum and %%zk_testnet_name%% to pay for deploying smart contracts on testnet. You can get Sepolia ETH from the [network faucets](/ecosystem/network-faucets). -- Get testnet `ETH` for zkSync Era using [bridges](https://zksync.io/explore#bridges) to bridge funds to zkSync. +- Get testnet `ETH` for ZKsync Era using [bridges](https://zksync.io/explore#bridges) to bridge funds to ZKsync. - You know [how to get your private key from your MetaMask wallet](https://support.metamask.io/hc/en-us/articles/360015289632-How-to-export-an-account-s-private-key). ::callout{icon="i-heroicons-information-circle" color="blue"} -**Local zkSync Testing with zksync-cli**: +**Local ZKsync Testing with zksync-cli**: Skip the hassle for test ETH by using `zksync-cli` for local testing. -Simply execute `npx zksync-cli dev start` to initialize a local zkSync development environment, which includes local Ethereum and zkSync nodes. +Simply execute `npx zksync-cli dev start` to initialize a local ZKsync development environment, which includes local Ethereum and ZKsync nodes. This method allows you to test contracts without requesting external testnet funds. Explore more in the [zksync-cli documentation](/build/tooling/zksync-cli). :: @@ -77,7 +77,7 @@ bun add @matterlabs/hardhat-zksync-deploy --dev ## Network Configuration -In the `hardhat.config.ts` file, specify zkSync Era and Ethereum networks in the `networks` object. +In the `hardhat.config.ts` file, specify ZKsync Era and Ethereum networks in the `networks` object. ```typescript networks: { @@ -85,7 +85,7 @@ networks: { url: "https://sepolia.infura.io/v3/" // The Ethereum Web3 RPC URL (optional). }, zkTestnet: { - url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of zkSync Era network. + url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of ZKsync Era network. ethNetwork: "%%zk_testnet_identifier%%", // The Ethereum Web3 RPC URL, or the identifier of the network (e.g. `mainnet` or `sepolia`) zksync: true } @@ -93,15 +93,15 @@ networks: { // defaultNetwork: "zkTestnet", // optional (if not set, use '--network zkTestnet') ``` -- `zkTestnet` is an arbitrary zkSync Era network name. You can select this as the default network using the `defaultNetwork` property. -- `url` is a field containing the URL of the zkSync Era node in case of the zkSync Era network (with `zksync` flag set to `true`), -or the URL of the Ethereum node. This field is required for all zkSync Era and Ethereum networks used by this plugin. +- `zkTestnet` is an arbitrary ZKsync Era network name. You can select this as the default network using the `defaultNetwork` property. +- `url` is a field containing the URL of the ZKsync Era node in case of the ZKsync Era network (with `zksync` flag set to `true`), +or the URL of the Ethereum node. This field is required for all ZKsync Era and Ethereum networks used by this plugin. - `ethNetwork` is a field with the URL of the Ethereum node. You can also provide network name (e.g. `%%zk_testnet_identifier%%`) as the value of this field. In this case, the plugin will either use the URL of the appropriate Ethereum network configuration (from the `networks` section), or the default `ethers` provider for the network if the configuration is not provided. -This field is required for all zkSync networks used by this plugin. -- `zksync` is a flag that indicates if the network is zkSync Era. This field needs to be set to `true` for all zkSync Era networks; it is `false` by default. +This field is required for all ZKsync networks used by this plugin. +- `zksync` is a flag that indicates if the network is ZKsync Era. This field needs to be set to `true` for all ZKsync Era networks; it is `false` by default. ## Usage in deployment scripts @@ -160,14 +160,14 @@ class Deployer { ): Promise /** - * Sends a deploy transaction to the zkSync network. + * Sends a deploy transaction to the ZKsync network. * For now it uses default values for the transaction parameters: * * @param contractNameOrArtifact The previously loaded artifact object, or contract name that will be resolved to artifact in the background. * @param constructorArguments The list of arguments to be passed to the contract constructor. * @param overrides Optional object with additional deploy transaction parameters. * @param additionalFactoryDeps Additional contract bytecodes to be added to the factory dependencies list. - * The fee amount is requested automatically from the zkSync Era server. + * The fee amount is requested automatically from the ZKsync Era server. * * @returns A contract object. */ @@ -221,7 +221,7 @@ const config: HardhatUserConfig = { url: "https://sepolia.infura.io/v3/" // The Ethereum Web3 RPC URL (optional). }, zkTestnet: { - url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of zkSync Era network. + url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of ZKsync Era network. ethNetwork: "%%zk_testnet_identifier%%", // The Ethereum Web3 RPC URL, or the identifier of the network (e.g. `mainnet` or `sepolia`) zksync: true, // ADDITION @@ -238,8 +238,8 @@ const config: HardhatUserConfig = { - `accounts` represents a list of the private keys or mnemonic object for the account used in the deployment process. ::callout{icon="i-heroicons-information-circle" color="blue"} -**Accounts on zkSync Era Test Node or zksync-cli Local Node**: -`accounts` object will be automatically be populated with rich accounts if used network is zkSync Era Test Node or zksync-cli Local Node +**Accounts on ZKsync Era Test Node or zksync-cli Local Node**: +`accounts` object will be automatically be populated with rich accounts if used network is ZKsync Era Test Node or zksync-cli Local Node :: @@ -259,7 +259,7 @@ const config: HardhatUserConfig = { url: "https://sepolia.infura.io/v3/" // The Ethereum Web3 RPC URL (optional). }, zkTestnet: { - url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of zkSync Era network. + url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of ZKsync Era network. ethNetwork: "%%zk_testnet_identifier%%", // The Ethereum Web3 RPC URL, or the identifier of the network (e.g. `mainnet` or `sepolia`) zksync: true, accounts: ['0xac1e735be8536c6534bb4f17f06f6afc73b2b5ba84ac2cfb12f7461b20c0bbe3', '0x28a574ab2de8a00364d5dd4b07c4f2f574ef7fcc2a86a197f65abaec836d1959'] // The private keys for the accounts used in the deployment process. @@ -370,7 +370,7 @@ const config: HardhatUserConfig = { url: "https://sepolia.infura.io/v3/", // The Ethereum Web3 RPC URL (optional). }, zkTestnet: { - url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of zkSync Era network. + url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of ZKsync Era network. ethNetwork: "%%zk_testnet_identifier%%", // The Ethereum Web3 RPC URL, or the identifier of the network (e.g. `mainnet` or `sepolia`) zksync: true, // ADDITION @@ -420,7 +420,7 @@ const config: HardhatUserConfig = { url: "https://sepolia.infura.io/v3/" // The Ethereum Web3 RPC URL (optional). }, zkTestnet: { - url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of zkSync Era network. + url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of ZKsync Era network. ethNetwork: "%%zk_testnet_identifier%%", // The Ethereum Web3 RPC URL, or the identifier of the network (e.g. `mainnet` or `sepolia`) zksync: true, } @@ -581,14 +581,14 @@ For a step-by-step guide on how to deploy missing libraries, see the `deploy-zks - To run a specific script, add the `--script` argument, e.g. `hardhat deploy-zksync --script 001_deploy.ts`. Runs script with name `001_deploy.ts`. - To run a scripts with specific tags add the `--tags` argument, e.g `hardhat deploy-zksync --tags all`. Run all scripts with tag `all`. -- To run on a specific zkSync Era network, use the standard Hardhat `--network` argument, e.g. `--network zkTestnet`. +- To run on a specific ZKsync Era network, use the standard Hardhat `--network` argument, e.g. `--network zkTestnet`. The network with the name `zkTestnet` needs to be configured in the `hardhat.config.ts` file, with all required fields stated above, or specify `defaultNetwork` in `hardhat.config.ts` file. ::callout{icon="i-heroicons-information-circle" color="blue"} If network argument `--network` or `defaultNetwork` configuration are not specified, -local setup with `http://localhost:8545` (Ethereum RPC URL) and `http://localhost:3050` (zkSync Era RPC URL), -will be used. In this case zkSync Era network will not need to be configured in `hardhat.config.ts` file. +local setup with `http://localhost:8545` (Ethereum RPC URL) and `http://localhost:3050` (ZKsync Era RPC URL), +will be used. In this case ZKsync Era network will not need to be configured in `hardhat.config.ts` file. For more details about a dockerized local setup, check out [Local testing](/build/test-and-debug/dockerized-l1-l2-nodes). :: diff --git a/content/00.build/40.tooling/20.hardhat/70.hardhat-zksync-upgradable.md b/content/00.build/40.tooling/20.hardhat/70.hardhat-zksync-upgradable.md index c52bac1e..95116ba2 100644 --- a/content/00.build/40.tooling/20.hardhat/70.hardhat-zksync-upgradable.md +++ b/content/00.build/40.tooling/20.hardhat/70.hardhat-zksync-upgradable.md @@ -4,12 +4,12 @@ description: --- The `hardhat-zksync-upgradable` plugin is a Hardhat plugin that supports end-to-end pipelines -for deploying and updating upgradable smart contracts on the zkSync Era network. +for deploying and updating upgradable smart contracts on the ZKsync Era network. The plugin is based on [@openzeppelin/upgrades-core](https://www.npmjs.com/package/@openzeppelin/upgrades-core) plugin for deploying and managing upgradeable smart contracts on the Ethereum network. The `hardhat-zksync-upgradable` plugin provides an easy-to-use interface for interacting with the -[OpenZeppelin Upgrades Plugins](https://docs.openzeppelin.com/upgrades-plugins) within a Hardhat environment on zkSync. +[OpenZeppelin Upgrades Plugins](https://docs.openzeppelin.com/upgrades-plugins) within a Hardhat environment on ZKsync. ::callout{icon="i-heroicons-exclamation-triangle" color="amber"} Ensure you are using the correct version of the plugin with ethers: @@ -138,7 +138,7 @@ With transparent proxies, a contract's address is owned by a proxy contract, whi When a new implementation is deployed, the proxy can be upgraded to point to the new implementation, allowing for seamless upgrades without requiring changes to the contract's interaction code. -To deploy a simple upgradable contract on zkSync Era local setup, first create a test wallet and add it to the new Deployer. +To deploy a simple upgradable contract on ZKsync Era local setup, first create a test wallet and add it to the new Deployer. ```typescript // mnemonic for local node rich wallet @@ -156,7 +156,7 @@ const contract = await deployer.loadArtifact(contractName); await hre.zkUpgrades.deployProxy(deployer.zkWallet, contract, [42], { initializer: "initialize" }); ``` -The `deployProxy` method deploys your implementation contract on zkSync Era, deploys the proxy admin contract, and finally, deploys the transparent proxy. +The `deployProxy` method deploys your implementation contract on ZKsync Era, deploys the proxy admin contract, and finally, deploys the transparent proxy. ### Full deploy proxy script @@ -210,7 +210,7 @@ npx hardhat run SCRIPT_FILE ::callout{icon="i-heroicons-exclamation-triangle" color="amber"} - deployProxy method (and other deploy/upgrade methods from the zkUpgrades) needs to know which wallet to use to deploy smart contracts. -- For this reason, the wallet needs to have a configured provider that connects it to the specific zkSync network. +- For this reason, the wallet needs to have a configured provider that connects it to the specific ZKsync network. - This provider is configured in the hardhat config file, by stating the RPC url of the network to connect to. :: @@ -339,7 +339,7 @@ with no disruption to the contract's operation. This allows for more advanced upgrade patterns, such as adding or removing functionality while minimizing downtime. -1. Start by creating a `Deployer` for the zkSync Era network and load the `Box` artifact: +1. Start by creating a `Deployer` for the ZKsync Era network and load the `Box` artifact: ```typescript // mnemonic for local node rich wallet @@ -358,7 +358,7 @@ This allows for more advanced upgrade patterns, such as adding or removing funct await hre.zkUpgrades.deployBeacon(deployer.zkWallet, boxContract); ``` -1. Use the `deployBeaconProxy` method which receives the zkSync Era wallet, beacon contract, and the implementation (Box) contract with its arguments. +1. Use the `deployBeaconProxy` method which receives the ZKsync Era wallet, beacon contract, and the implementation (Box) contract with its arguments. ```typescript const box = await hre.zkUpgrades.deployBeaconProxy(deployer.zkWallet, beacon, boxContract, [42]); @@ -427,7 +427,7 @@ This means we can optimize the process to check for the existing implementation instead of deploying a new implementation contract every time. The upgradable plugin saves this information in the manifest file. This file will be created in your project's `.upgradable` folder. -The manifest file is created per network, meaning you will have different data saved for upgrading contracts on the local setup and zkSync Era networks. +The manifest file is created per network, meaning you will have different data saved for upgrading contracts on the local setup and ZKsync Era networks. ## Upgrading proxies @@ -511,7 +511,7 @@ To upgrade the implementation of the transparent upgradeable contract, use the ` `upgradeProxy` receives 3 arguments: -- A zkSync Era wallet. +- A ZKsync Era wallet. - The address of the previously deployed box proxy. - The artifact containing the new `Box2` implementation. @@ -770,7 +770,7 @@ const config: HardhatUserConfig = { url: "https://sepolia.infura.io/v3/", // The Ethereum Web3 RPC URL (optional). }, zkSyncSepoliaTestnet: { - url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of zkSync Era network. + url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of ZKsync Era network. ethNetwork: "%%zk_testnet_identifier%%", // The Ethereum Web3 RPC URL, or the identifier of the network (e.g. `mainnet` or `sepolia`) zksync: true, // ADDITION @@ -787,7 +787,7 @@ const config: HardhatUserConfig = { - accounts represents a list of the private keys or mnemonic object for the account used in the deployment or in the upgrade process. - accounts object will automatically be populated with rich accounts if used network is zkSync Era Test Node or zksync-cli Local Node + accounts object will automatically be populated with rich accounts if used network is ZKsync Era Test Node or zksync-cli Local Node To establish a default index per network, which is by default `0`, you can include a `deployerAccounts` section in your `hardhat.config.ts` file. ```typescript @@ -802,7 +802,7 @@ const config: HardhatUserConfig = { url: "https://sepolia.infura.io/v3/", // The Ethereum Web3 RPC URL (optional). }, zkSyncSepoliaTestnet: { - url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of zkSync Era network. + url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of ZKsync Era network. ethNetwork: "%%zk_testnet_identifier%%", // The Ethereum Web3 RPC URL, or the identifier of the network (e.g. `mainnet` or `sepolia`) zksync: true, // The private keys for the accounts used in the deployment process. diff --git a/content/00.build/40.tooling/20.hardhat/80.hardhat-zksync-verify.md b/content/00.build/40.tooling/20.hardhat/80.hardhat-zksync-verify.md index f3fedd8b..590dade9 100644 --- a/content/00.build/40.tooling/20.hardhat/80.hardhat-zksync-verify.md +++ b/content/00.build/40.tooling/20.hardhat/80.hardhat-zksync-verify.md @@ -3,7 +3,7 @@ title: hardhat-zksync-verify description: --- -This plugin is used to verify contracts on the zkSync Era network. +This plugin is used to verify contracts on the ZKsync Era network. [Changelog](%%zk_git_repo_hardhat-zksync%%/blob/main/packages/hardhat-zksync-verify/CHANGELOG.md) @@ -58,7 +58,7 @@ Import the plugin in the `hardhat.config.ts` file: import "@matterlabs/hardhat-zksync-verify"; ``` -Add the `verifyURL` property to the zkSync Era network in the `hardhat.config.ts` file as shown below: +Add the `verifyURL` property to the ZKsync Era network in the `hardhat.config.ts` file as shown below: ```typescript networks: { @@ -66,7 +66,7 @@ networks: { url: "https://sepolia.infura.io/v3/" // The Ethereum Web3 RPC URL (optional). }, zkTestnet: { - url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of zkSync Era network. + url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of ZKsync Era network. ethNetwork: "%%zk_testnet_identifier%%", // The Ethereum Web3 RPC URL, or the identifier of the network (e.g. `mainnet` or `sepolia`) zksync: true, // Verification endpoint for Sepolia @@ -78,18 +78,18 @@ networks: { Additional network properties: -- `zkTestnet` is an arbitrary zkSync Era network name. You can select this as the default network using the `defaultNetwork` property. -- `url` is a field with the URL of the zkSync Era node -in case of the zkSync Era network (with `zksync` flag set to `true`), or the URL of the Ethereum node. -This field is required for all zkSync Era and Ethereum networks used by this plugin. +- `zkTestnet` is an arbitrary ZKsync Era network name. You can select this as the default network using the `defaultNetwork` property. +- `url` is a field with the URL of the ZKsync Era node +in case of the ZKsync Era network (with `zksync` flag set to `true`), or the URL of the Ethereum node. +This field is required for all ZKsync Era and Ethereum networks used by this plugin. - `ethNetwork` is a field with the URL of the Ethereum node. You can also provide network name (e.g. `%%zk_testnet_identifier%%`) as the value of this field. In this case, the plugin will either use the URL of the appropriate Ethereum network configuration (from the `networks` section), -or the default `ethers` provider for the network if the configuration is not provided. This field is required for all zkSync networks used by this plugin. -- `zksync` is a flag that indicates a zkSync Era network configuration. This field is set to `true` for all zkSync Era networks. +or the default `ethers` provider for the network if the configuration is not provided. This field is required for all ZKsync networks used by this plugin. +- `zksync` is a flag that indicates a ZKsync Era network configuration. This field is set to `true` for all ZKsync Era networks. If you want to run a `hardhat-verify` verification, this field needs to be set to `false`. -If set to `true`, the verification process will try to run the verification process on the zkSync Era network. -- `verifyURL` is a field that points to the verification endpoint for the specific zkSync network. +If set to `true`, the verification process will try to run the verification process on the ZKsync Era network. +- `verifyURL` is a field that points to the verification endpoint for the specific ZKsync network. This parameter is optional, and its default value is the testnet verification url. - Testnet: `%%zk_testnet_block_explorer_url%%/contract_verification` - Mainnet: `%%zk_mainnet_block_explorer_url%%/contract_verification` diff --git a/content/00.build/40.tooling/20.hardhat/90.hardhat-zksync-verify-vyper.md b/content/00.build/40.tooling/20.hardhat/90.hardhat-zksync-verify-vyper.md index 419ec7ab..dcee8df8 100644 --- a/content/00.build/40.tooling/20.hardhat/90.hardhat-zksync-verify-vyper.md +++ b/content/00.build/40.tooling/20.hardhat/90.hardhat-zksync-verify-vyper.md @@ -3,7 +3,7 @@ title: hardhat-zksync-verify-vyper description: --- -This plugin is used to verify vyper contracts on the zkSync Era network. +This plugin is used to verify vyper contracts on the ZKsync Era network. ::callout{icon="i-heroicons-exclamation-triangle" color="amber"} Current version of the verify vyper plugin has a limitation where in order to verify the vyper contract, @@ -42,7 +42,7 @@ Ensure you are using the correct version of the plugin with ethers: ## Setup The [@matterlabs/hardhat-zksync-verify-vyper](https://www.npmjs.com/package/@matterlabs/hardhat-zksync-verify-vyper) plugin -is used to verify contracts on zkSync network. +is used to verify contracts on ZKsync network. To use it, install plugin and then import `@matterlabs/hardhat-zksync-verify-vyper` in the `hardhat.config.ts` file. ::code-group @@ -69,7 +69,7 @@ Import the plugin in the `hardhat.config.ts` file: import "@matterlabs/hardhat-zksync-verify-vyper"; ``` -Add the `verifyURL` property to the zkSync Era network in the `hardhat.config.ts` file as shown below: +Add the `verifyURL` property to the ZKsync Era network in the `hardhat.config.ts` file as shown below: ```typescript networks: { @@ -77,7 +77,7 @@ networks: { url: "https://sepolia.infura.io/v3/" // The Ethereum Web3 RPC URL (optional). }, zkTestnet: { - url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of zkSync Era network. + url: "%%zk_testnet_rpc_url%%", // The testnet RPC URL of ZKsync Era network. ethNetwork: "%%zk_testnet_identifier%%", // The Ethereum Web3 RPC URL, or the identifier of the network (e.g. `mainnet` or `sepolia`) zksync: true, // Verification endpoint for Sepolia @@ -89,16 +89,16 @@ networks: { Additional network properties: -- `zkTestnet` is an arbitrary zkSync Era network name. You can select this as the default network using the `defaultNetwork` property. -- `url` is a field with the URL of the zkSync Era node. This field is required for all zkSync networks used by this plugin. +- `zkTestnet` is an arbitrary ZKsync Era network name. You can select this as the default network using the `defaultNetwork` property. +- `url` is a field with the URL of the ZKsync Era node. This field is required for all ZKsync networks used by this plugin. - `ethNetwork` is a field with the URL of the Ethereum node. You can also provide network name (e.g. `sepolia`) as the value of this field. In this case, the plugin will either use the URL of the appropriate Ethereum network configuration (from the `networks` section), or the default `ethers` provider for the network if the configuration is not provided. -This field is required for all zkSync networks used by this plugin. -- `zksync` is a flag that indicates a zkSync Era network configuration. -This field is set to `true` for all zkSync Era networks. Field value `true` is required for this plugin work. +This field is required for all ZKsync networks used by this plugin. +- `zksync` is a flag that indicates a ZKsync Era network configuration. +This field is set to `true` for all ZKsync Era networks. Field value `true` is required for this plugin work. If field is missing or if values is set to `false` plugin will throw a error. -- `verifyURL` is a field that points to the verification endpoint for the specific zkSync network. +- `verifyURL` is a field that points to the verification endpoint for the specific ZKsync network. This parameter is optional, and its default value is the testnet verification url. - Testnet: `%%zk_testnet_block_explorer_url%%/contract_verification` - Mainnet: `%%zk_mainnet_block_explorer_url%%/contract_verification` diff --git a/content/00.build/40.tooling/30.foundry/10.overview.md b/content/00.build/40.tooling/30.foundry/10.overview.md index f6f9b4d1..d1028d3b 100644 --- a/content/00.build/40.tooling/30.foundry/10.overview.md +++ b/content/00.build/40.tooling/30.foundry/10.overview.md @@ -3,11 +3,11 @@ title: Overview description: Learn about foundry-zksync. --- -`foundry-zksync` is a specialized fork of [Foundry](https://github.com/foundry-rs/foundry), tailored for zkSync. +`foundry-zksync` is a specialized fork of [Foundry](https://github.com/foundry-rs/foundry), tailored for ZKsync. -It extends Foundry's capabilities for Ethereum app development to support zkSync, allowing for the compilation, -deployment, testing, and interaction with smart contracts on zkSync. -`foundry-zksync` introduces `--zksync` flag, or the use of `vm.zkVm(true)` to target the zkSync VM. +It extends Foundry's capabilities for Ethereum app development to support ZKsync, allowing for the compilation, +deployment, testing, and interaction with smart contracts on ZKsync. +`foundry-zksync` introduces `--zksync` flag, or the use of `vm.zkVm(true)` to target the ZKsync VM. ### Status and Contribution @@ -19,9 +19,9 @@ For more details and contributions, visit the [GitHub repository](%%zk_git_repo_ ### Features -`foundry-zksync` offers a set of features designed to work with zkSync, providing a comprehensive toolkit for smart contract deployment and interaction: +`foundry-zksync` offers a set of features designed to work with ZKsync, providing a comprehensive toolkit for smart contract deployment and interaction: -- **Smart Contract Deployment**: Easily deploy smart contracts to zkSync mainnet, testnet, or a local test node. +- **Smart Contract Deployment**: Easily deploy smart contracts to ZKsync mainnet, testnet, or a local test node. - **Asset Bridging**: Bridge assets between L1 and L2, facilitating seamless transactions across layers. - **Contract Interaction**: Call and send transactions to deployed contracts on %%zk_testnet_name%% or local test node. - **Solidity Testing**: Write tests in Solidity for a familiar testing environment. diff --git a/content/00.build/40.tooling/30.foundry/20.getting-started.md b/content/00.build/40.tooling/30.foundry/20.getting-started.md index 2e0d7fd2..d3415894 100644 --- a/content/00.build/40.tooling/30.foundry/20.getting-started.md +++ b/content/00.build/40.tooling/30.foundry/20.getting-started.md @@ -1,6 +1,6 @@ --- title: Getting Started -description: Learn how to setup and use Foundry with your zkSync project. +description: Learn how to setup and use Foundry with your ZKsync project. --- ## Prerequisites @@ -80,7 +80,7 @@ This can be used to create a new `foundry.toml` file with `forge config --basic By default `forge config` shows the currently selected foundry profile and its values. It also accepts the same arguments as `forge build`. -An example `foundry.toml` for zkSync with zksolc configurations may look like: +An example `foundry.toml` for ZKsync with zksolc configurations may look like: ```toml [profile.default] @@ -129,7 +129,7 @@ forge build [OPTIONS] --zksync - `--fallback-oz `: Recompile with `-Oz` if bytecode is too large. - `--detect-missing-libraries`: Detect and report missing libraries. - `-O, --optimization `: Set LLVM optimization levels. -- `--zk-optimizer`: Optimize specifically for zkSync. +- `--zk-optimizer`: Optimize specifically for ZKsync. **Example Usage:** Compile with default settings or specify `zksolc` version: @@ -145,7 +145,7 @@ The following commands make use of Foundry keystore instead of private keys. [Learn how to create a keystore](#private-key-setup-with-foundry-keystore). :: -`forge create --zksync` deploys smart contracts to zkSync. +`forge create --zksync` deploys smart contracts to ZKsync. **Usage:** @@ -190,7 +190,7 @@ contract Greeter { ```bash -forge create src/Greeter.sol:Greeter --constructor-args "Hello zkSync" --account myKeystore --sender --rpc-url %%zk_testnet_rpc_url%% --chain %%zk_testnet_chain_id%% --zksync +forge create src/Greeter.sol:Greeter --constructor-args "Hello ZKsync" --account myKeystore --sender --rpc-url %%zk_testnet_rpc_url%% --chain %%zk_testnet_chain_id%% --zksync ``` ### Deploying Factory Contracts @@ -241,7 +241,7 @@ forge create src/GreeterFactory.sol:Factory --factory-deps src/Greeter.sol:Greet **Deploy `Greeter.sol` via `GreeterFactory.sol`:** ```sh -cast send "CreateNewGreeter(string)" "zkSync Rules" --account myKeystore --sender --rpc-url %%zk_testnet_rpc_url%% --chain %%zk_testnet_chain_id%% +cast send "CreateNewGreeter(string)" "ZKsync Rules" --account myKeystore --sender --rpc-url %%zk_testnet_rpc_url%% --chain %%zk_testnet_chain_id%% ``` **Interact with `Greeter.sol`** @@ -265,27 +265,27 @@ cast to-ascii 0x000000000000000000000000000000000000000000000000000000000000002 **Output:** ```sh -zkSync Rules +ZKsync Rules ``` -## Basic zkSync Chain Interactions with `cast` +## Basic ZKsync Chain Interactions with `cast` ### Introduction -This guide introduces you to fundamental interactions within the zkSync chain using `cast`, a component of the `foundry-zksync` toolkit. +This guide introduces you to fundamental interactions within the ZKsync chain using `cast`, a component of the `foundry-zksync` toolkit. Learn how to query chain IDs, retrieve client versions, check L2 ETH balances, obtain gas prices, and more. ### Chain ID Retrieval - **Local Node:** - Retrieve the Chain ID for a local zkSync node with: + Retrieve the Chain ID for a local ZKsync node with: ```sh cast chain-id --rpc-url http://localhost:3050 ``` - Expected Output: `270`, indicating the Chain ID of your local zkSync node. + Expected Output: `270`, indicating the Chain ID of your local ZKsync node. - **%%zk_testnet_name%%:** @@ -305,7 +305,7 @@ Knowing the client version is vital for compatibility checks and debugging: cast client --rpc-url %%zk_testnet_rpc_url%% ``` -Expected Output: `zkSync/v2.0`, denoting the client version. +Expected Output: `ZKsync/v2.0`, denoting the client version. ### L2 Balance Check @@ -329,7 +329,7 @@ Expected Output: A value such as `100000000`, indicating the current gas price. ### Latest Block Details -Gain insights into the latest block on the zkSync chain: +Gain insights into the latest block on the ZKsync chain: ```sh cast block latest --rpc-url %%zk_testnet_rpc_url%% @@ -348,7 +348,7 @@ cast send --rpc-url --chain %%zk_testnet_chain_id%% +cast send 0xe34E488C1B0Fb372Cc4a5d39219261A5a6fc7996 "setGreeting(string)" "Hello, ZKsync!" --rpc-url %%zk_testnet_rpc_url%% --account myKeystore --sender --chain %%zk_testnet_chain_id%% ``` -This command calls the `setGreeting` function of a contract, updating the greeting to "Hello, zkSync!". +This command calls the `setGreeting` function of a contract, updating the greeting to "Hello, ZKsync!". diff --git a/content/00.build/60.test-and-debug/00.index.md b/content/00.build/60.test-and-debug/00.index.md index 87f541fa..b3bf03d2 100644 --- a/content/00.build/60.test-and-debug/00.index.md +++ b/content/00.build/60.test-and-debug/00.index.md @@ -1,9 +1,9 @@ --- title: Getting Started -description: Learn about the recommended paths of testing and debugging your projects on zkSync. +description: Learn about the recommended paths of testing and debugging your projects on ZKsync. --- -zkSync Era provides two distinct testing environments for your local development needs: +ZKsync Era provides two distinct testing environments for your local development needs: - Dockerized local setup - In-Memory Node. @@ -16,8 +16,8 @@ This section aims to unpack the intricacies of these tools, aiding you in select The local testing process revolves around two principal options: -1. **Dockerized local setup**: An extensive zkSync Era network simulation that comprises a Postgres database, -a local Geth node functioning as Layer 1, and the zkSync node. +1. **Dockerized local setup**: An extensive ZKsync Era network simulation that comprises a Postgres database, +a local Geth node functioning as Layer 1, and the ZKsync node. Opt for this setup for comprehensive simulations and testing that require interaction with both L1 and L2. 2. **In-Memory node**: A lightweight, speedy alternative, the in-memory node, supports forking the state from various networks, @@ -26,7 +26,7 @@ including the mainnet and testnet. This choice is ideal for swift testing, proto ### When to use each - Use the **Dockerized local setup** for in-depth simulations and tests that necessitate L1 and L2 interaction. -This detailed setup mirrors how your contracts will function within the mainnet zkSync Era network. +This detailed setup mirrors how your contracts will function within the mainnet ZKsync Era network. - Opt for the **In-Memory node** for swift testing, prototyping, or testing new changes via the local bootloader and system contracts. This setup facilitates forking the state from the mainnet or testnet, suitable for replaying transactions @@ -50,11 +50,11 @@ The following table highlights the key characteristics of each testing environme | Complete set of APIs | No (Basic set only) | Yes | | Websocket support | No | Yes | -Whether you're testing new contracts, debugging transactions, or prototyping, zkSync Era provides robust options for local testing. +Whether you're testing new contracts, debugging transactions, or prototyping, ZKsync Era provides robust options for local testing. Both the Dockerized local setup and the In-Memory Node offer feature-rich and quick setup options, each with their distinct strengths and limitations. Choose the most appropriate setup based on your specific needs, and happy testing! -## Use zkSync CLI for easy setup +## Use ZKsync CLI for easy setup -The [zkSync CLI](/build/tooling/zksync-cli) makes it simple for developers to work with both the Dockerized local setup and In-Memory Node. +The [ZKsync CLI](/build/tooling/zksync-cli) makes it simple for developers to work with both the Dockerized local setup and In-Memory Node. Use `zksync-cli dev start` to get your local development environment running along with additional modules like Block Explorer, Wallet and Bridge. diff --git a/content/00.build/60.test-and-debug/10.dockerized-l1-l2-nodes.md b/content/00.build/60.test-and-debug/10.dockerized-l1-l2-nodes.md index 0d7d5539..6f5db0aa 100644 --- a/content/00.build/60.test-and-debug/10.dockerized-l1-l2-nodes.md +++ b/content/00.build/60.test-and-debug/10.dockerized-l1-l2-nodes.md @@ -3,16 +3,16 @@ title: Docker L1 - L2 Nodes description: Guide to setup dockerized containers of L1 and L2 nodes. --- -Welcome to this step-by-step guide on establishing a local testing environment using Docker for zkSync development. -With this guide, you can effortlessly emulate the zkSync environment on your local system, making it simpler to test and develop features. +Welcome to this step-by-step guide on establishing a local testing environment using Docker for ZKsync development. +With this guide, you can effortlessly emulate the ZKsync environment on your local system, making it simpler to test and develop features. Let's get started! **Prerequisites**: 1. **Docker and docker-compose**: Ensure that Docker and `docker-compose` are installed on your machine. If you haven't already installed them, follow the [installation guide](https://docs.docker.com/get-docker/). -2. **zkSync Hardhat plugins**: A foundational understanding of the zkSync Hardhat plugins will be beneficial. -New to zkSync development with Hardhat? Explore the [Getting Started section](/build/tooling/hardhat/getting-started). +2. **ZKsync Hardhat plugins**: A foundational understanding of the ZKsync Hardhat plugins will be beneficial. +New to ZKsync development with Hardhat? Explore the [Getting Started section](/build/tooling/hardhat/getting-started). ::callout{icon="i-heroicons-exclamation-triangle" color="amber"} The `matterlabs/local-node` Docker image is currently based on the protocol `Version19` (deprecated on February 5, 2024), @@ -24,7 +24,7 @@ It should only be used for testing L1 <-> L2 communication. ## Set up the testing environment -1. Clone the dockerized zkSync project repository to your local machine: +1. Clone the dockerized ZKsync project repository to your local machine: ```bash git clone %%zk_git_repo_local-setup%% @@ -36,7 +36,7 @@ It should only be used for testing L1 <-> L2 communication. cd local-setup ``` -1. Launch the zkSync Era node locally using the `start.sh` script: +1. Launch the ZKsync Era node locally using the `start.sh` script: ```bash ./start.sh @@ -44,13 +44,13 @@ It should only be used for testing L1 <-> L2 communication. This script spins up three essential docker containers: - 1. **Postgres**: The database supporting zkSync. - 2. **Local Geth node**: Acts as the Layer 1 (L1) for zkSync. - 3. **zkSync node**: The core component. + 1. **Postgres**: The database supporting ZKsync. + 2. **Local Geth node**: Acts as the Layer 1 (L1) for ZKsync. + 3. **ZKsync node**: The core component. ::callout{icon="i-heroicons-light-bulb" color="blue"} The first execution of the `start.sh` script should proceed without interruptions. -If it halts unexpectedly, you might need to reset the local zkSync state and retry. +If it halts unexpectedly, you might need to reset the local ZKsync state and retry. The initialization might take up to 10 minutes initially. :: @@ -68,9 +68,9 @@ The initialization might take up to 10 minutes initially. **Network Id**: 270 --- -## Reset the zkSync State +## Reset the ZKsync State -If you need to revert the zkSync state to its initial configuration, execute the `clear.sh` script: +If you need to revert the ZKsync state to its initial configuration, execute the `clear.sh` script: ```bash ./clear.sh @@ -85,7 +85,7 @@ sudo ./clear.sh --- ## Leverage rich wallets -The local zkSync setup generously equips test wallets with ample amounts of ETH on both L1 and L2, making testing easier. +The local ZKsync setup generously equips test wallets with ample amounts of ETH on both L1 and L2, making testing easier. ::drop-panel ::panel{label="Rich Wallets"} diff --git a/content/00.build/60.test-and-debug/20.in-memory-node.md b/content/00.build/60.test-and-debug/20.in-memory-node.md index 3cccc710..ac7e2f4e 100644 --- a/content/00.build/60.test-and-debug/20.in-memory-node.md +++ b/content/00.build/60.test-and-debug/20.in-memory-node.md @@ -278,7 +278,7 @@ Launch the local in-memory node: - Use [foundry-zksync](%%zk_git_repo_foundry-zksync%%). Make sure to install and configure `foundry-zksync` before proceeding - (for installation instructions, please see [Foundry with zkSync Era](%%zk_git_repo_foundry-zksync%%?tab=readme-ov-file#-installation)): + (for installation instructions, please see [Foundry with ZKsync Era](%%zk_git_repo_foundry-zksync%%?tab=readme-ov-file#-installation)): ::code-group @@ -324,7 +324,7 @@ Before proceeding, ensure that you've compiled your contracts using `forge build ```bash [foundry-zksync] forge create contracts/Greeter.sol:Greeter \ - --constructor-args "zkSync and Foundry" \ + --constructor-args "ZKsync and Foundry" \ --private-key 7726827caac94a7f9e1b160f7ea819f172f7b6f9d2a97f992c38edeab82d4110 \ --rpc-url http://localhost:8011 \ --chain 260 \ @@ -495,7 +495,7 @@ To run the test file, execute: ``` :: -Well done! You've successfully run your first local tests with zkSync Era and `era_test_node`. +Well done! You've successfully run your first local tests with ZKsync Era and `era_test_node`. --- diff --git a/content/00.build/60.test-and-debug/40.hardhat.md b/content/00.build/60.test-and-debug/40.hardhat.md index f8ce7293..068e7063 100644 --- a/content/00.build/60.test-and-debug/40.hardhat.md +++ b/content/00.build/60.test-and-debug/40.hardhat.md @@ -187,7 +187,7 @@ Let's refactor our test file with the provided script: // Initialize commonly used variables before running the tests before(async function () { - // Create a provider connected to the zkSync testnet + // Create a provider connected to the ZKsync testnet const provider = new Provider(zkSyncTestnet.url); // Create a wallet instance using the rich wallet's private key @@ -286,7 +286,7 @@ import { zkSyncTestnet } from "../hardhat.config"; This section imports all necessary utilities and configurations needed to run our tests. - `expect` from Chai provides assertion functionalities for our tests. -- `Wallet`, `Provider`, and `Contract` from `zksync-ethers` help us with zkSync functionalities like creating wallets and interacting with contracts. +- `Wallet`, `Provider`, and `Contract` from `zksync-ethers` help us with ZKsync functionalities like creating wallets and interacting with contracts. - `hre` and `Deployer` give us hardhat specific functionalities for deploying and interacting with our contract. - `zkSyncTestnet` from our hardhat configuration provides network details of our running `era_test_node.` diff --git a/content/00.build/60.test-and-debug/50.foundry.md b/content/00.build/60.test-and-debug/50.foundry.md index ace8c07b..64f5f940 100644 --- a/content/00.build/60.test-and-debug/50.foundry.md +++ b/content/00.build/60.test-and-debug/50.foundry.md @@ -1,11 +1,11 @@ --- title: Foundry -description: Learn how to test using Foundry for zkSync. +description: Learn how to test using Foundry for ZKsync. --- For instructions on how to install `foundry-zksync` please refer to the Foundry [Getting Started](/build/tooling/foundry/getting-started) page. -`foundry-zksync`, a fork of Foundry, provides developers with a tailored testing framework designed specifically for zkSync environments. +`foundry-zksync`, a fork of Foundry, provides developers with a tailored testing framework designed specifically for ZKsync environments. Utilizing `forge test --zksync`, you can execute your smart contract tests efficiently. Tests are written in Solidity, and the framework is designed to recognize any contract function prefixed with `test` as a test case. By convention, tests are typically stored within the `test/` directory and have a `.t.sol` extension. diff --git a/content/00.build/65.developer-reference/00.index.md b/content/00.build/65.developer-reference/00.index.md index c6f22118..64cc3901 100644 --- a/content/00.build/65.developer-reference/00.index.md +++ b/content/00.build/65.developer-reference/00.index.md @@ -1,11 +1,11 @@ --- title: Getting Started -description: Kickstart your development journey with zkSync Era, covering everything from rollups to system contracts and fee structures. +description: Kickstart your development journey with ZKsync Era, covering everything from rollups to system contracts and fee structures. --- -Welcome to the zkSync Era Developer reference documentation! This guide is your starting point for -understanding the core components and advanced features of zkSync. It provides an essential -overview to help you effectively build on zkSync Era. +Welcome to the ZKsync Era Developer reference documentation! This guide is your starting point for +understanding the core components and advanced features of ZKsync. It provides an essential +overview to help you effectively build on ZKsync Era. ::card-group ::card @@ -22,7 +22,7 @@ overview to help you effectively build on zkSync Era. icon: i-heroicons-adjustments-horizontal-16-solid to: /build/developer-reference/ethereum-differences/evm-instructions --- - Learn about the key distinctions between Ethereum Layer 1 and zkSync Era. + Learn about the key distinctions between Ethereum Layer 1 and ZKsync Era. :: ::card --- @@ -34,19 +34,19 @@ overview to help you effectively build on zkSync Era. :: ::card --- - title: zkSync Era Contracts + title: ZKsync Era Contracts icon: i-heroicons-document-duplicate-16-solid to: /build/developer-reference/era-contracts/l1-contracts --- - Discover the zkSync Era L1 and system contracts. + Discover the ZKsync Era L1 and system contracts. :: ::card --- - title: zkSync Era Fee Model + title: ZKsync Era Fee Model icon: i-heroicons-currency-dollar-16-solid to: /build/developer-reference/fee-model --- - Understand the fee structure in zkSync to optimize transaction costs. + Understand the fee structure in ZKsync to optimize transaction costs. :: ::card --- @@ -54,6 +54,6 @@ overview to help you effectively build on zkSync Era. icon: i-heroicons-arrow-path-16-solid to: /build/developer-reference/bridging-assets --- - Facilitate asset transfers between Ethereum Layer 1 and zkSync Layer 2 efficiently + Facilitate asset transfers between Ethereum Layer 1 and ZKsync Layer 2 efficiently :: :: diff --git a/content/00.build/65.developer-reference/10.intro-rollups.md b/content/00.build/65.developer-reference/10.intro-rollups.md index 9f48b050..7c8cf65f 100644 --- a/content/00.build/65.developer-reference/10.intro-rollups.md +++ b/content/00.build/65.developer-reference/10.intro-rollups.md @@ -30,7 +30,7 @@ This allows transactions to be processed without the overhead of all the data as Currently, there are 2 types of rollups used to scale Ethereum. -1. ZK Rollups (Zero-Knowledge Rollups) - eg: zkSync, Loopring, Starknet, Scroll etc +1. ZK Rollups (Zero-Knowledge Rollups) - eg: ZKsync, Loopring, Starknet, Scroll etc 2. Optimistic Rollups - eg: Optimism, Arbitrum etc The main difference between ZK and Optimistic rollups is in the way this batch of transactions becomes final. @@ -41,7 +41,7 @@ In ZK rollups ('ZK' standing for zero-knowledge) the batch of transactions is ve verification passes, the batch of transactions is considered final like any other Ethereum transaction. This is achieved through the power of cryptographic validity proofs (commonly called zero-knowledge proofs). With any batch of off-chain transactions, the ZK rollup operator generates a proof of validity for this batch. Once the proof is generated, it is submitted to Ethereum to make the roll-up batch final. -In zkSync, this is done via a **SNARK**, succinct non-interactive argument of knowledge. +In ZKsync, this is done via a **SNARK**, succinct non-interactive argument of knowledge. ### What are Optimistic rollups? @@ -60,4 +60,4 @@ The term **Layer 2** (or **L2**) is used to describe an overlaying application o are most often built to provide further scalability solutions by taking on a portion of transaction-based tasks to lighten the impact on the layer 1 chain, quickening transaction times and lowering gas fees. -**zkSync Era is an L2, where L1 is the main Ethereum blockchain.** +**ZKsync Era is an L2, where L1 is the main Ethereum blockchain.** diff --git a/content/00.build/65.developer-reference/20.zksync-overview.md b/content/00.build/65.developer-reference/20.zksync-overview.md index 4f0ebb44..03846e9f 100644 --- a/content/00.build/65.developer-reference/20.zksync-overview.md +++ b/content/00.build/65.developer-reference/20.zksync-overview.md @@ -1,9 +1,9 @@ --- -title: zkSync Era Overview +title: ZKsync Era Overview description: --- -## zkSync Era overview +## ZKsync Era overview The general rollup workflow is as follows: @@ -12,20 +12,20 @@ The general rollup workflow is as follows: Rollup operation requires the assistance of an operator, who rolls transactions together, computes a zero-knowledge proof of the correct state transition, and affects the state transition by interacting with the rollup -contract. To understand the design, we need to look into how zkSync rollup transactions work. +contract. To understand the design, we need to look into how ZKsync rollup transactions work. -zkSync operations are divided into rollup transactions (initiated inside rollup by a +ZKsync operations are divided into rollup transactions (initiated inside rollup by a rollup account) and priority operations (initiated on the mainchain by an Ethereum account). -The zkSync rollup operation lifecycles are as follows: +The ZKsync rollup operation lifecycles are as follows: - A user creates a transaction or a priority operation. - After processing this request, the operator creates a rollup operation and adds it to the block. -- Once the block is complete, the operator submits it to the zkSync smart contract +- Once the block is complete, the operator submits it to the ZKsync smart contract as a block commitment. Part of the logic of some rollup operations is checked by the smart contract. -- The proof for the block is submitted to the zkSync smart contract as block verification. If the verification succeeds, the new state is considered final. +- The proof for the block is submitted to the ZKsync smart contract as block verification. If the verification succeeds, the new state is considered final. -Furthermore, on zkSync, each L2 block will progress through the following four stages until it is final. +Furthermore, on ZKsync, each L2 block will progress through the following four stages until it is final. - `Pending`: The transaction was received by the operator, but it has not been processed yet. - `Processed`: The transaction is processed by the operator and is confirmed to be included in the next block. @@ -40,26 +40,26 @@ The typical time for a transaction to go from `Processed` to `Finalized` is a co Please note that for developer convenience, we usually treat the `Processed` and `Committed` states as a single stage called `Committed` since they have no difference from the UX/DevEx standpoints. -### The State of zkSync +### The State of ZKsync -The current version of zkSync Era solves the needs of most applications on Ethereum, -and with more features planned for release soon, zkSync Era will provide developers +The current version of ZKsync Era solves the needs of most applications on Ethereum, +and with more features planned for release soon, ZKsync Era will provide developers with a design space to experiment with applications not possible on Ethereum today. With this release, we are supporting the following features: -- Native support of ECDSA signatures: Unlike the first version of zkSync and other +- Native support of ECDSA signatures: Unlike the first version of ZKsync and other ZK rollups, no special operation is required to register the user’s private key. Any account can be managed in L2 with the same private key that is used for L1. - Solidity 0.8.x support: Deploy your existing codebase with little to no changes required. - With small exceptions, our Web3 API is fully compatible with Ethereum. This allows seamless integration with existing indexers, explorers, etc. -- Support for Ethereum cryptographic primitives: zkSync natively supports `keccak256`, `sha256`, and `ecrecover` via precompiles. -- Hardhat plugin: Enables easy testing and development of smart contracts on zkSync. +- Support for Ethereum cryptographic primitives: ZKsync natively supports `keccak256`, `sha256`, and `ecrecover` via precompiles. +- Hardhat plugin: Enables easy testing and development of smart contracts on ZKsync. - L1 → L2 smart contract messaging: Allows developers to pass data from Ethereum to -smart contracts on zkSync, providing the required information to run various smart contracts. -- Native account abstraction: zkSync Era implements [account abstraction natively] +smart contracts on ZKsync, providing the required information to run various smart contracts. +- Native account abstraction: ZKsync Era implements [account abstraction natively] (/build/developer-reference/account-abstraction), which brings multiple UX improvements for all accounts. -## Highlights of zkSync Era +## Highlights of ZKsync Era - Mainnet-like security with zero reliance on 3rd parties. - Permissionless EVM-compatible smart contracts. @@ -67,14 +67,14 @@ smart contracts on zkSync, providing the required information to run various sma - Preserving key EVM features, such as smart contract composability. - Introducing new features, such as native account abstraction. -## zkSync in comparison +## ZKsync in comparison -zkSync [stands out remarkably](https://blog.matter-labs.io/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) +ZKsync [stands out remarkably](https://blog.matter-labs.io/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) in security and usability among existing L2 scaling solutions. Thanks to the combination of cutting-edge cryptography and on-chain data -availability, ZK rollups (the core network of zkSync) are the only L2 scaling +availability, ZK rollups (the core network of ZKsync) are the only L2 scaling solution that doesn't require any operational activity to keep the funds safe. For example, users can go offline and still be able to withdraw their assets safely when they come back, even if the ZK rollup validators are no longer around. -For a comprehensive distinction between zkSync Era and Ethereum, read this [guide](/build/developer-reference/ethereum-differences/evm-instructions). +For a comprehensive distinction between ZKsync Era and Ethereum, read this [guide](/build/developer-reference/ethereum-differences/evm-instructions). diff --git a/content/00.build/65.developer-reference/25.best-practices.md b/content/00.build/65.developer-reference/25.best-practices.md index 1baea598..22f85b99 100644 --- a/content/00.build/65.developer-reference/25.best-practices.md +++ b/content/00.build/65.developer-reference/25.best-practices.md @@ -3,8 +3,8 @@ title: Security and best practices description: --- -Before diving into development on zkSync Era, it's crucial to consider the following recommendations. These best -practices will help you optimize your code, ensure security, and align with the unique characteristics of zkSync Era. +Before diving into development on ZKsync Era, it's crucial to consider the following recommendations. These best +practices will help you optimize your code, ensure security, and align with the unique characteristics of ZKsync Era. ## Use `call` over `.send` or `.transfer` @@ -34,7 +34,7 @@ contracts against reentrancy attacks. It can help ensure the robustness and secu ## Use the proxy pattern at the early stage of the protocol -zkSync Era is based on the zk-friendly VM. Thus, we offer +ZKsync Era is based on the zk-friendly VM. Thus, we offer [a dedicated compiler](/zk-stack/components/compiler/toolchain) responsible for transforming conventional Solidity and Vyper code into zkEVM bytecode. @@ -42,17 +42,17 @@ While we have extensive test coverage to ensure EVM compatibility, issues may st We will implement the patches for these in a timely manner. To integrate a compiler bug fix, you need to recompile and upgrade your smart contract. We recommend using the -Proxy pattern for a few months after your first deployment on zkSync Era, even if you plan to migrate to an immutable +Proxy pattern for a few months after your first deployment on ZKsync Era, even if you plan to migrate to an immutable contract in the future. ## Do not rely on EVM gas logic -zkSync Era has a distinctive gas logic compared to Ethereum. There are two main drivers: +ZKsync Era has a distinctive gas logic compared to Ethereum. There are two main drivers: - We have a state-diff-based data availability, which means that the price for the execution depends on the L1 gas price. -- zkSync VM has a different set of computational trade-offs compared to the standard computational model. In +- ZKsync VM has a different set of computational trade-offs compared to the standard computational model. In practice, this means that the price for opcodes is different to Ethereum. Also, zkEVM contains a different set of -opcodes under the hood and so the “gas” metric of the same set of operations may be different on zkSync Era and on Ethereum. +opcodes under the hood and so the “gas” metric of the same set of operations may be different on ZKsync Era and on Ethereum. ::callout{icon="i-heroicons-exclamation-triangle" color="amber"} Our fee model is being constantly improved and so it is highly recommended **NOT** to hardcode any constants since the fee @@ -61,7 +61,7 @@ model changes in the future might be breaking for this constant. ## `gasPerPubdataByte` should be taken into account in development -Due to the state diff-based fee model of zkSync Era, every transaction includes a constant called `gasPerPubdataByte`. +Due to the state diff-based fee model of ZKsync Era, every transaction includes a constant called `gasPerPubdataByte`. Presently, the operator has control over this value. However, in EIP712 transactions, users also sign an upper bound on this value, but the operator is free to choose any value up to that upper bound. Note, that even if the value @@ -90,20 +90,20 @@ was no such parameter on Ethereum. This means that a malicious user could call t high and make the transaction fail, hence making it spend artificially more gas than required. This is the case for all relayer-like logic ported directly from Ethereum and so if you see your code relying on logic -like “the user should provide at X gas”, then the `gasPerPubdata` should be also taken into account on zkSync Era. +like “the user should provide at X gas”, then the `gasPerPubdata` should be also taken into account on ZKsync Era. -For now, zkSync Era operators use honest values for ETH L1 price and `gasPerPubdata`, so it should not be an issue if -enough margin is added to the estimated gas. In order to prepare for the future decentralization of zkSync Era, +For now, ZKsync Era operators use honest values for ETH L1 price and `gasPerPubdata`, so it should not be an issue if +enough margin is added to the estimated gas. In order to prepare for the future decentralization of ZKsync Era, it is imperative that you update your contract. ## Use native account abstraction over `ecrecover` for validation -Use zkSync Era's native account abstraction support for signature validation instead of this function. +Use ZKsync Era's native account abstraction support for signature validation instead of this function. We recommend not relying on the fact that an account has an ECDSA private key, since the account may be governed by multisig and use another signature scheme. -Read more about [zkSync Era Account Abstraction support](/build/developer-reference/account-abstraction). +Read more about [ZKsync Era Account Abstraction support](/build/developer-reference/account-abstraction). ## Use local testing environment @@ -112,7 +112,7 @@ them to the mainnet. Local testing allows you to test your contracts in a contro reduced network latency and cost. We provide [two different testing environments](/build/test-and-debug) designed for local testing purposes. -These tools allow you to simulate the zkSync network locally, enabling you to validate your contracts effectively. +These tools allow you to simulate the ZKsync network locally, enabling you to validate your contracts effectively. By incorporating local testing into your development workflow, you can effectively verify the behavior and functionality of your contracts in a controlled environment, ensuring a smooth deployment process to the mainnet. diff --git a/content/00.build/65.developer-reference/30.ethereum-differences/10.evm-instructions.md b/content/00.build/65.developer-reference/30.ethereum-differences/10.evm-instructions.md index 4f54a965..822ff9f1 100644 --- a/content/00.build/65.developer-reference/30.ethereum-differences/10.evm-instructions.md +++ b/content/00.build/65.developer-reference/30.ethereum-differences/10.evm-instructions.md @@ -5,7 +5,7 @@ description: ## `CREATE`, `CREATE2` -On zkSync Era, contract deployment is performed using the hash of the bytecode, and the `factoryDeps` field of EIP712 +On ZKsync Era, contract deployment is performed using the hash of the bytecode, and the `factoryDeps` field of EIP712 transactions contains the bytecode. The actual deployment occurs by providing the contract's hash to the `ContractDeployer` system contract. @@ -43,15 +43,15 @@ function myFactory(bytes memory bytecode) public { Unfortunately, it's impossible to differentiate between the above cases during compile-time. As a result, we strongly recommend including tests for any factory that deploys child contracts using `type(T).creationCode`. -Since the deploy and runtime code is merged together on zkSync Era, we do not support `type(T).runtimeCode` and it +Since the deploy and runtime code is merged together on ZKsync Era, we do not support `type(T).runtimeCode` and it always produces a compile-time error. ### Address derivation -For zkEVM bytecode, zkSync Era uses a distinct address derivation method compared to Ethereum. The precise formulas +For zkEVM bytecode, ZKsync Era uses a distinct address derivation method compared to Ethereum. The precise formulas can be found in our SDK, as demonstrated below: - + ```typescript export function create2Address(sender: Address, bytecodeHash: BytesLike, salt: BytesLike, input: BytesLike) { @@ -71,24 +71,24 @@ export function createAddress(sender: Address, senderNonce: BigNumberish) { } ``` -Since the bytecode differs from Ethereum as zkSync uses a modified version of the EVM, the address derived from the bytecode hash will also differ. -This means that the same bytecode deployed on Ethereum and zkSync will have +Since the bytecode differs from Ethereum as ZKsync uses a modified version of the EVM, the address derived from the bytecode hash will also differ. +This means that the same bytecode deployed on Ethereum and ZKsync will have different addresses and the Ethereum address will still be available and unused on -zkSync. If and when the zkEVM reaches parity with the EVM, the address derivation +ZKsync. If and when the zkEVM reaches parity with the EVM, the address derivation will be updated to match Ethereum and the same bytecode will have the same address -on both chains, deployed bytecodes to different addresses on zkSync could then be -deployed to the same the Ethereum-matching addresses on zkSync. +on both chains, deployed bytecodes to different addresses on ZKsync could then be +deployed to the same the Ethereum-matching addresses on ZKsync. ## `CALL`, `STATICCALL`, `DELEGATECALL` For calls, you specify a memory slice to write the return data to, e.g. `out` and `outsize` arguments for `call(g, a, v, in, insize, out, outsize)`. In EVM, if `outsize != 0`, the allocated memory will grow to `out + outsize` -(rounded up to the words) regardless of the `returndatasize`. On zkSync Era, `returndatacopy`, similar to `calldatacopy`, +(rounded up to the words) regardless of the `returndatasize`. On ZKsync Era, `returndatacopy`, similar to `calldatacopy`, is implemented as a cycle iterating over return data with a few additional checks and triggering a panic if `out + outsize > returndatasize` to simulate the same behavior as in EVM. -Thus, unlike EVM where memory growth occurs before the call itself, on zkSync Era, the necessary copying of return data -happens only after the call has ended, leading to a difference in `msize()` and sometimes zkSync Era not panicking where +Thus, unlike EVM where memory growth occurs before the call itself, on ZKsync Era, the necessary copying of return data +happens only after the call has ended, leading to a difference in `msize()` and sometimes ZKsync Era not panicking where EVM would panic due to the difference in memory growth. ```solidity @@ -100,7 +100,7 @@ success := call(gas(), target, 0, in, insize, out, 0) // memory untouched returndatacopy(out, 0, returndatasize()) // grows to 'out + returndatasize()' ``` -Additionally, there is no native support for passing Ether on zkSync Era, so it is handled by a special system contract +Additionally, there is no native support for passing Ether on ZKsync Era, so it is handled by a special system contract called `MsgValueSimulator`. The simulator receives the callee address and Ether amount, performs all necessary balance changes, and then calls the callee. @@ -123,7 +123,7 @@ That means that the code will panic if `2^32-32 + offset % 32 < offset + len`. ## `RETURN`, `STOP` -Constructors return the array of immutable values. If you use `RETURN` or `STOP` in an assembly block in the constructor on zkSync Era, +Constructors return the array of immutable values. If you use `RETURN` or `STOP` in an assembly block in the constructor on ZKsync Era, it will leave the immutable variables uninitialized. ```solidity @@ -156,26 +156,26 @@ contract Example { ## `TIMESTAMP`, `NUMBER` -For more information about blocks on zkSync Era, including the differences between `block.timestamp` and `block.number`, -check out the [blocks on zkSync Documentation](/zk-stack/concepts/blocks). +For more information about blocks on ZKsync Era, including the differences between `block.timestamp` and `block.number`, +check out the [blocks on ZKsync Documentation](/zk-stack/concepts/blocks). ::callout{icon="i-heroicons-light-bulb"} **Changes From the Previous Protocol Version**
Modifications were performed on how certain block properties were implemented on -zkSync Era. For details on the changes performed visit the [announcement on GitHub](https://github.com/zkSync-Community-Hub/zkync-developers/discussions/87). +ZKsync Era. For details on the changes performed visit the [announcement on GitHub](https://github.com/ZKsync-Community-Hub/zkync-developers/discussions/87). :: ## `COINBASE` -Returns the address of the `Bootloader` contract, which is `0x8001` on zkSync Era. +Returns the address of the `Bootloader` contract, which is `0x8001` on ZKsync Era. ## `DIFFICULTY`, `PREVRANDAO` -Returns a constant value of `2500000000000000` on zkSync Era. +Returns a constant value of `2500000000000000` on ZKsync Era. ## `BASEFEE` -This is not a constant on zkSync Era and is instead defined by the fee model. Most +This is not a constant on ZKsync Era and is instead defined by the fee model. Most of the time it is 0.25 gwei, but under very high L1 gas prices it may rise. ## `SELFDESTRUCT` @@ -203,7 +203,7 @@ Always produces a compile-time error with the zkEVM compiler. | Size of the constructor arguments | Contract size | Yul uses a special instruction `datasize` to distinguish the contract code and constructor arguments, so we -substitute `datasize` with 0 and `codesize` with `calldatasize` in zkSync Era deployment code. This way when Yul calculates the +substitute `datasize` with 0 and `codesize` with `calldatasize` in ZKsync Era deployment code. This way when Yul calculates the calldata size as `sub(codesize, datasize)`, the result is the size of the constructor arguments. ```solidity diff --git a/content/00.build/65.developer-reference/30.ethereum-differences/20.nonces.md b/content/00.build/65.developer-reference/30.ethereum-differences/20.nonces.md index 4d311d28..8b16fd50 100644 --- a/content/00.build/65.developer-reference/30.ethereum-differences/20.nonces.md +++ b/content/00.build/65.developer-reference/30.ethereum-differences/20.nonces.md @@ -15,13 +15,13 @@ the deployment of a new contract. Unlike EOAs, which can only increment their no by one per transaction, smart contracts have the ability to increase their nonce multiple times within a single transaction. -Conversely, zkSync features native account abstraction, allowing accounts to +Conversely, ZKsync features native account abstraction, allowing accounts to leverage the nonce for both replay attack protection and address derivation of -created contracts. Given that accounts in zkSync can be smart contracts, they may +created contracts. Given that accounts in ZKsync can be smart contracts, they may deploy several contracts in a single transaction. In order to maintain the expected and convenient use of a nonce in both transaction -validation and contract deployment contexts, zkSync introduces two different nonces: +validation and contract deployment contexts, ZKsync introduces two different nonces: - Transaction nonce - Deployment nonce @@ -31,10 +31,10 @@ nonce is incremented in the event of contract deployment. This way, accounts may send many transactions by following only one nonce value and the contract may deploy many other contracts without conflicting with the transaction nonce. -There are also other minor differences between zkSync and Ethereum nonce management: +There are also other minor differences between ZKsync and Ethereum nonce management: - Newly created contracts begin with a **deployment nonce** value of zero. This contrasts with Ethereum, where, following the specifications of [EIP-161](https://eips.ethereum.org/EIPS/eip-161), the nonce for newly created contracts starts at one. -- On zkSync, the deployment nonce is incremented only if the deployment succeeds. +- On ZKsync, the deployment nonce is incremented only if the deployment succeeds. On Ethereum nonce on deployment is updated even in case creation failed. diff --git a/content/00.build/65.developer-reference/30.ethereum-differences/50.native-vs-eip4337.md b/content/00.build/65.developer-reference/30.ethereum-differences/50.native-vs-eip4337.md index 01d813ce..13870059 100644 --- a/content/00.build/65.developer-reference/30.ethereum-differences/50.native-vs-eip4337.md +++ b/content/00.build/65.developer-reference/30.ethereum-differences/50.native-vs-eip4337.md @@ -3,24 +3,24 @@ title: Native AA vs EIP 4337 description: --- -The native account abstraction of zkSync and Ethereum's EIP 4337 aim to enhance +The native account abstraction of ZKsync and Ethereum's EIP 4337 aim to enhance accounts' flexibility and user experience, but they differ in critical aspects listed below: -1. **Implementation Level**: zkSync's account abstraction is integrated at the +1. **Implementation Level**: ZKsync's account abstraction is integrated at the protocol level; however, EIP 4337 avoids the implementation at the protocol level. -2. **Account Types**: on zkSync Era, smart contract accounts and paymasters are +2. **Account Types**: on ZKsync Era, smart contract accounts and paymasters are first-class citizens. Under the hood, all accounts (even EOAs) behave like smart contract accounts; **all accounts support paymasters**. 3. **Transaction Processing**: EIP 4337 introduces a separate transaction flow for smart contract accounts, which relies on a separate mempool for user operations, and Bundlers - nodes that bundle user operations and sends them to be processed by the EntryPoint contract, resulting in two separate transaction flows. In contrast, on -zkSync Era there is a unified mempool for transactions from both Externally Owned -Accounts (EOAs) and smart contract accounts. On zkSync Era, the Operator takes on +ZKsync Era there is a unified mempool for transactions from both Externally Owned +Accounts (EOAs) and smart contract accounts. On ZKsync Era, the Operator takes on the role of bundling transactions, irrespective of the account type, and sends them to the Bootloader (similar to the EntryPoint contract), which results in a single mempool and transaction flow. -4. **Paymasters support**: zkSync Era allows both EOAs and smart contract accounts +4. **Paymasters support**: ZKsync Era allows both EOAs and smart contract accounts to benefit from paymasters thanks to its single transaction flow. On the other hand, EIP 4337 does not support paymasters for EOAs because paymasters are only implemented in the new transaction flow for smart contract accounts. diff --git a/content/00.build/65.developer-reference/30.ethereum-differences/60.contract-deployment.md b/content/00.build/65.developer-reference/30.ethereum-differences/60.contract-deployment.md index c4974fd7..80b0cb04 100644 --- a/content/00.build/65.developer-reference/30.ethereum-differences/60.contract-deployment.md +++ b/content/00.build/65.developer-reference/30.ethereum-differences/60.contract-deployment.md @@ -4,7 +4,7 @@ description: Overview of the differences in contract deployment. --- -In order to maintain the same level of security as the L1, the zkSync operator is +In order to maintain the same level of security as the L1, the ZKsync operator is required to publish the code for each contract it deploys on the Ethereum chain. However, if multiple contracts are deployed using the same code, the operator only needs to publish it on Ethereum once. While the initial deployment of contracts can @@ -18,7 +18,7 @@ through EIP712 transactions, with the `factory_deps` field containing the byteco [Learn more about EIP712 transactions here](/zk-stack/concepts/transaction-lifecycle#eip-712-0x71). -## Ethereum / zkSync differences in contract deployment +## Ethereum / ZKsync differences in contract deployment **How deploying contracts works on Ethereum.** @@ -26,9 +26,9 @@ To deploy a contract on Ethereum, a user sends a transaction to the zero address (`0x000...000`) with the `data` field of the transaction equal to the contract bytecode concatenated with the constructor parameters. -**How deploying contracts works on zkSync.** +**How deploying contracts works on ZKsync.** -To deploy a contract on zkSync Era, a user calls the `create` function of the +To deploy a contract on ZKsync Era, a user calls the `create` function of the [ContractDeployer system contract](/build/developer-reference/era-contracts/system-contracts) providing the hash of the contract to be published, as well as the constructor arguments. The contract bytecode itself is supplied in the `factory_deps` field of @@ -49,7 +49,7 @@ or factory_deps for short, comes into play. Factory dependencies refer to a list bytecode hashes whose corresponding preimages were previously revealed on the L1 (where data is always available). -Under the hood, zkSync does not store bytecodes of contracts in its state tree, but +Under the hood, ZKsync does not store bytecodes of contracts in its state tree, but [specially formatted hashes of the bytecodes](#contract-size-limit-and-format-of-bytecode-hash). You can see that the [ContractDeployer](/build/developer-reference/era-contracts/system-contracts) system contract accepts the bytecode hash of the deployed contract and not its bytecode. However, for @@ -61,7 +61,7 @@ Once the transaction succeeds, these bytecodes are published on L1 and are consi Some examples of usage are: - The obvious one is when you deploy a contract, you need to provide its code in the `factory_deps` field. -- On zkSync, factories (i.e. contracts that can deploy other contracts) do not +- On ZKsync, factories (i.e. contracts that can deploy other contracts) do not store bytecodes of their dependencies, i.e. contracts that they can deploy. They only store their hashes. That's why you need to include _all_ the bytecodes of the dependencies in the `factory_deps` field. @@ -99,7 +99,7 @@ Ethereum), there is an additional pubdata limit, which is normally smaller. By default, for each batch, this limit is set to 100000 bytes for ZK chains using calldata DA, or 120000\*number_of_blobs, for ZK chains using EIP-4844 blobs. -The 32-byte hash of the bytecode of a zkSync contract is calculated in the following way: +The 32-byte hash of the bytecode of a ZKsync contract is calculated in the following way: - The first 2 bytes denote the version of bytecode hash format and are currently equal to `[1,0]`. - The second 2 bytes denote the length of the bytecode in 32-byte words. @@ -126,28 +126,28 @@ the necessary knowledge and experience to identify potential security risks. Inv investors and users from losses, reputation damage, and legal issues. Therefore, it's essential to prioritize smart contract security and take proactive measures to ensure that they are thoroughly audited for security holes before deploying your -smart contract on zkSync Era network. +smart contract on ZKsync Era network. For detailed information on smart contract vulnerabilities and security best practices, refer to the following resources: - [Cyfrin Updraft Security & Auditing Curriculum](https://updraft.cyfrin.io/courses/security). - [Consensys smart contract best practices](https://consensys.github.io/smart-contract-best-practices/). - [Solidity docs security considerations](https://docs.soliditylang.org/en/latest/security-considerations.html). -- [Security considerations and best practices on zkSync](/build/developer-reference/best-practices) +- [Security considerations and best practices on ZKsync](/build/developer-reference/best-practices) ### Differences in `create()` behaviour -To facilitate [support for account abstraction](/build/developer-reference/account-abstraction), zkSync splits the nonce of each account +To facilitate [support for account abstraction](/build/developer-reference/account-abstraction), ZKsync splits the nonce of each account into two parts: the deployment nonce and the transaction nonce. The deployment nonce represents the number of contracts the account has deployed using the `create()` opcode, while the transaction nonce is used for protecting against replay attacks for transactions. -This distinction implies that, while the nonce on zkSync behaves similarly to +This distinction implies that, while the nonce on ZKsync behaves similarly to Ethereum for smart contracts, calculating the address of a deployed contract for externally owned accounts (EOAs) is not as straightforward. On Ethereum, it can be safely determined using the formula `hash(RLP[address, -nonce])`. However, on zkSync, it is advisable to wait until the contract is +nonce])`. However, on ZKsync, it is advisable to wait until the contract is deployed and catch the `ContractDeployed` event emitted by the [ContractDeployer](/build/developer-reference/era-contracts/system-contracts), which provides the address of the newly deployed contract. The SDK handles all of these processes in the background to simplify the workflow. @@ -157,7 +157,7 @@ To have a deterministic address, you should use the `create2` method from ## Deploying contracts from L1 -Deploying contracts on zkSync Era is also possible via L1-L2 communication. +Deploying contracts on ZKsync Era is also possible via L1-L2 communication. The [interface](https://github.com/matter-labs/era-contracts/blob/main/l1-contracts/contracts/zksync/interfaces/IZkSync.sol) for submitting L1->L2 transactions accepts @@ -166,4 +166,4 @@ The logic for working with them is the same as for the default L2 deployments. T only difference is that since the user has already published the full preimage for the bytecodes on L1, there is no need to publish these bytecodes again on L1. -To learn more about L1-L2 communication on zkSync Era, visit [this section of the docs](/build/developer-reference/l1-l2-interoperability). +To learn more about L1-L2 communication on ZKsync Era, visit [this section of the docs](/build/developer-reference/l1-l2-interoperability). diff --git a/content/00.build/65.developer-reference/40.account-abstraction/10.index.md b/content/00.build/65.developer-reference/40.account-abstraction/10.index.md index 93380acb..f14a0709 100644 --- a/content/00.build/65.developer-reference/40.account-abstraction/10.index.md +++ b/content/00.build/65.developer-reference/40.account-abstraction/10.index.md @@ -1,6 +1,6 @@ --- title: Introduction -description: Discover how zkSync native Account Abstraction enhances transaction flexibility and user experience. +description: Discover how ZKsync native Account Abstraction enhances transaction flexibility and user experience. --- On Ethereum there are two types of accounts: @@ -20,11 +20,11 @@ create a lot of friction. As a result, such applications require L1 relayers, e.g. an EOA to help facilitate transactions from a smart-contract wallet. -Accounts in zkSync Era can initiate transactions, like an EOA, but can also have +Accounts in ZKsync Era can initiate transactions, like an EOA, but can also have arbitrary logic implemented in them, like a smart contract. This feature, called "account abstraction" (AA), aims to resolve the issues described above. -Native Account Abstraction on zkSync Era fundamentally changes how accounts operate +Native Account Abstraction on ZKsync Era fundamentally changes how accounts operate by introducing the concept of Smart Accounts and Paymasters. Smart Accounts are fully programmable, allowing for various customizations such as signature schemes, native multi-sig capabilities, spending limits, and application-specific restrictions. diff --git a/content/00.build/65.developer-reference/40.account-abstraction/20.design.md b/content/00.build/65.developer-reference/40.account-abstraction/20.design.md index 08a93acb..f56c4912 100644 --- a/content/00.build/65.developer-reference/40.account-abstraction/20.design.md +++ b/content/00.build/65.developer-reference/40.account-abstraction/20.design.md @@ -1,9 +1,9 @@ --- title: Design -description: Overview of zkSync's account abstraction design, focusing on enhancing transaction efficiency and user experience. +description: Overview of ZKsync's account abstraction design, focusing on enhancing transaction efficiency and user experience. --- -The account abstraction protocol on zkSync is very similar to [EIP4337](https://eips.ethereum.org/EIPS/eip-4337), +The account abstraction protocol on ZKsync is very similar to [EIP4337](https://eips.ethereum.org/EIPS/eip-4337), though our protocol is still different for the sake of efficiency and better UX. ## Keeping nonces unique @@ -44,7 +44,7 @@ which practically enforces the sequential ordering of nonces. ## Standardizing transaction hashes In the future, it is planned to support efficient proofs of transaction inclusion -on zkSync. This would require us to calculate the transaction's hash in the +on ZKsync. This would require us to calculate the transaction's hash in the [bootloader](/zk-stack/components/zksync-evm/bootloader). Since these calculations won't be free to the user, it is only fair to include the transaction's hash in the interface of the AA methods (in case the accounts may @@ -165,7 +165,7 @@ where the paymaster facilitates fee payment in ERC-20 tokens. ### Fees -The handling of transaction fees varies between different protocols, as illustrated by EIP-4337 and zkSync Era. +The handling of transaction fees varies between different protocols, as illustrated by EIP-4337 and ZKsync Era. #### Gas Limits in EIP-4337 EIP-4337 defines three types of gas limits to manage the costs associated with different transaction stages: @@ -174,8 +174,8 @@ EIP-4337 defines three types of gas limits to manage the costs associated with d - **`executionGas`**: Allocates gas for the execution of the transaction. - **`preVerificationGas`**: Specifies the gas used prior to the main verification process. -#### Unified Gas Limit in zkSync Era -Contrastingly, zkSync Era simplifies the fee structure by using a single `gasLimit` +#### Unified Gas Limit in ZKsync Era +Contrastingly, ZKsync Era simplifies the fee structure by using a single `gasLimit` field for all transaction-related costs. This unified `gasLimit` must be adequately set to cover: diff --git a/content/00.build/65.developer-reference/40.account-abstraction/30.extending-4337.md b/content/00.build/65.developer-reference/40.account-abstraction/30.extending-4337.md index af52cf41..e9cd008b 100644 --- a/content/00.build/65.developer-reference/40.account-abstraction/30.extending-4337.md +++ b/content/00.build/65.developer-reference/40.account-abstraction/30.extending-4337.md @@ -1,6 +1,6 @@ --- title: Extending EIP-4337 -description: Overview of the extensions to zkSync's native Account Abstraction from EIP4337. +description: Overview of the extensions to ZKsync's native Account Abstraction from EIP4337. --- To provide DoS protection for the operator, EIP4337 imposes several diff --git a/content/00.build/65.developer-reference/40.account-abstraction/40.building-smart-accounts.md b/content/00.build/65.developer-reference/40.account-abstraction/40.building-smart-accounts.md index 8fe3bf54..1388178f 100644 --- a/content/00.build/65.developer-reference/40.account-abstraction/40.building-smart-accounts.md +++ b/content/00.build/65.developer-reference/40.account-abstraction/40.building-smart-accounts.md @@ -18,7 +18,7 @@ This implementation returns an empty value when called by an external address, w ### EIP1271 Integration For smart wallets, we highly encourage the implementation of the [EIP1271](https://eips.ethereum.org/EIPS/eip-1271) signature-validation scheme. -This standard is endorsed by the zkSync team and is integral to our signature-verification library. +This standard is endorsed by the ZKsync team and is integral to our signature-verification library. ### Deployment Process diff --git a/content/00.build/65.developer-reference/50.era-contracts/10.l1-contracts.md b/content/00.build/65.developer-reference/50.era-contracts/10.l1-contracts.md index f546d3ad..165c3d9d 100644 --- a/content/00.build/65.developer-reference/50.era-contracts/10.l1-contracts.md +++ b/content/00.build/65.developer-reference/50.era-contracts/10.l1-contracts.md @@ -44,7 +44,7 @@ with the marker `isFreezable` should be inaccessible until the governor unfreeze ## Diamond -Technically, this L1 smart contract acts as a connector between Ethereum (L1) and zkSync (L2). +Technically, this L1 smart contract acts as a connector between Ethereum (L1) and ZKsync (L2). This contract checks the validity proof and data availability, handles L2 <-> L1 communication, finalizes L2 state transition, and more. @@ -122,8 +122,8 @@ fixed-length message with parameters `senderAddress == this`, `marker == true`, ## 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. @@ -133,12 +133,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/content/00.build/65.developer-reference/50.era-contracts/20.system-contracts.md b/content/00.build/65.developer-reference/50.era-contracts/20.system-contracts.md index 94ff803a..7cbea30e 100644 --- a/content/00.build/65.developer-reference/50.era-contracts/20.system-contracts.md +++ b/content/00.build/65.developer-reference/50.era-contracts/20.system-contracts.md @@ -31,7 +31,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 @@ -91,7 +91,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 @@ -123,7 +123,7 @@ Whenever anyone wants to do a non-zero value call, they need to call `MsgValueSi ## 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. @@ -145,9 +145,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 @@ -164,7 +164,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 @@ -175,7 +175,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. @@ -193,13 +193,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). @@ -223,7 +223,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. ### **Return value of the deployment methods** @@ -242,7 +242,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: @@ -308,7 +308,7 @@ compression. You can read more on how we compress state diffs and bytecodes in t Some of the system contracts have an impact on the account that may not be expected on Ethereum. For instance, on Ethereum the only way an EOA could increase its nonce is by sending a transaction. Also, sending a transaction could only increase nonce -by 1 at a time. On zkSync nonces are implemented via the [NonceHolder](#nonceholder) system contract and, if naively implemented, the users could be +by 1 at a time. On ZKsync nonces are implemented via the [NonceHolder](#nonceholder) system contract and, if naively implemented, the users could be allowed to increment their nonces by calling this contract. That's why the calls to most of the non-view methods of the nonce holder were restricted to be called only with a special `isSystem` flag, so that interactions with important system contracts could be consciously managed by the developer of the account. diff --git a/content/00.build/65.developer-reference/60.bridging-assets.md b/content/00.build/65.developer-reference/60.bridging-assets.md index 81c40d0b..38d768a9 100644 --- a/content/00.build/65.developer-reference/60.bridging-assets.md +++ b/content/00.build/65.developer-reference/60.bridging-assets.md @@ -3,7 +3,7 @@ title: Bridging Assets description: --- -Users can deposit and withdraw assets from zkSync Era using any of the [multiple bridges](https://zksync.io/explore#bridges). +Users can deposit and withdraw assets from ZKsync Era using any of the [multiple bridges](https://zksync.io/explore#bridges). Under the hood, bridging is implemented by having two contracts (one deployed to L1, and the second deployed to L2) @@ -31,7 +31,7 @@ Users must call the `deposit` method on the L1 bridge contract, which triggers t - The user's L1 tokens will be sent to the L1 bridge and become locked there. - The L1 bridge initiates a transaction to the L2 bridge using L1 -> L2 communication. - Within the L2 transaction, tokens will be minted and sent to the specified address on L2. - - If the token does not exist on zkSync yet, a new contract is deployed for it. + - If the token does not exist on ZKsync yet, a new contract is deployed for it. Given the L2 token address is deterministic (based on the original L1 address, name and symbol), it doesn't matter who is the first person bridging it, the new L2 address will be the same. - For every executed L1 -> L2 transaction, there will be an L2 -> L1 log message confirming its execution. @@ -43,7 +43,7 @@ You can find example scripts to deposit ETH and ERC20 tokens using the default b ::callout{icon="i-heroicons-light-bulb"} -- To provide additional security during the Alpha phase, **withdrawals in zkSync Era take 24 hours**. +- To provide additional security during the Alpha phase, **withdrawals in ZKsync Era take 24 hours**. - For more information, read the [withdrawal delay guide](/build/resources/withdrawal-delay). @@ -63,7 +63,7 @@ every withdrawal, we will take care of it by making an L1 transaction that prove ## Custom bridges on L1 and L2 To build a custom bridge, create a regular Solidity contract which extends one of -the interfaces mentioned below for the layer. The interfaces provide access to the zkSync Era SDK deposit and withdraw implementations. +the interfaces mentioned below for the layer. The interfaces provide access to the ZKsync Era SDK deposit and withdraw implementations. - L1: [IL1Bridge.sol](https://github.com/matter-labs/era-contracts/blob/main/l1-contracts/contracts/bridge/interfaces/IL1Bridge.sol) diff --git a/content/00.build/65.developer-reference/70.fee-model.md b/content/00.build/65.developer-reference/70.fee-model.md index d256229c..274b2a69 100644 --- a/content/00.build/65.developer-reference/70.fee-model.md +++ b/content/00.build/65.developer-reference/70.fee-model.md @@ -1,21 +1,21 @@ --- title: Fee Model -description: Overview of zkSync Era's fee model. +description: Overview of ZKsync Era's fee model. --- -zkSync Era's fee model is similar to Ethereum’s where `gas` is charged for +ZKsync Era's fee model is similar to Ethereum’s where `gas` is charged for computational cost, cost of publishing data on-chain and storage effects. However, -zkSync Era includes additional costs for publishing to L1 and for proof generation. +ZKsync Era includes additional costs for publishing to L1 and for proof generation. Because the L1 gas price for publishing data (on L1) is so volatile, the amount of required L2 `gas` is variable. -Therefore, for each block, the zkSync Era sequencer defines the following dynamic parameters: +Therefore, for each block, the ZKsync Era sequencer defines the following dynamic parameters: - `gasPrice`: the price, in gwei, of a unit of gas. - `gasPerPubdata`: the amount of `gas` for publishing one byte of data on Ethereum. -In zkSync Era, unlike in Ethereum where each opcode has a fixed gas price, storage +In ZKsync Era, unlike in Ethereum where each opcode has a fixed gas price, storage write charges remain dynamic due to the fluctuation of gas price on L1. Other -opcode prices are constant, similar to Ethereum. See the [zkSync opcode documentation](https://github.com/matter-labs/era-zkevm_opcode_defs/blob/9307543b9ca51bd80d4f5c85d6eb80efd8b19bb2/src/lib.rs#L227) +opcode prices are constant, similar to Ethereum. See the [ZKsync opcode documentation](https://github.com/matter-labs/era-zkevm_opcode_defs/blob/9307543b9ca51bd80d4f5c85d6eb80efd8b19bb2/src/lib.rs#L227) for an idea of how we calculate them. Like Ethereum, the most costly operation is a storage update. Execution of @@ -24,7 +24,7 @@ arithmetic operations is relatively cheap, as it involves computation alone and ## State diffs vs transaction inputs A considerable advantage we have over optimistic and most ZK rollups is that, -instead of publishing all transaction data to L1, zkSync Era only publishes state diffs, thus publishing significantly less data to L1. +instead of publishing all transaction data to L1, ZKsync Era only publishes state diffs, thus publishing significantly less data to L1. #### State diff example @@ -42,7 +42,7 @@ contract code hash on the newly deployed `Pair` address. - **Reuse as many storage slots as possible:** Only the final state diff is published on Ethereum. - **Reuse the contract code where possible:** - On Ethereum, avoiding constructor parameters and putting them into constants reduces some of the gas costs upon contract deployment. - - On zkSync Era the opposite is true: as contract bytecode is only published + - On ZKsync Era the opposite is true: as contract bytecode is only published once, updating the constructor parameters alone leads to substantial fee savings. ## Gas estimation for transactions @@ -50,22 +50,22 @@ contract code hash on the newly deployed `Pair` address. Ethereum has a constant of `21000` gas that covers the intrinsic costs of processing a transaction, i.e. checking the signature and updating the nonce for the account. -On zkSync Era this varies because we support custom and paymaster accounts. These -accounts require a (usually) higher amount of gas than EOAs. zkSync Era provides +On ZKsync Era this varies because we support custom and paymaster accounts. These +accounts require a (usually) higher amount of gas than EOAs. ZKsync Era provides functions for estimating the cost of a transaction regardless of the type of account. The transaction fee estimate depends on the entire transaction flow, including validation and execution. The `eth_estimateGas` function uses binary search to find the smallest gas value under which the transaction succeeds. -For any Rust developers interested in the zkSync Era implementation for gas estimation, see the [Rust code in our repo](https://github.com/matter-labs/zksync-era/blob/48fe6e27110c1fe1a438c5375fb256890e8017b1/sdk/zksync-rs/src/operations/execute_contract.rs#L129). +For any Rust developers interested in the ZKsync Era implementation for gas estimation, see the [Rust code in our repo](https://github.com/matter-labs/zksync-era/blob/48fe6e27110c1fe1a438c5375fb256890e8017b1/sdk/zksync-rs/src/operations/execute_contract.rs#L129). ### Transaction length -zkSync Era publishes state diffs on-chain. The cost of the transaction, however, +ZKsync Era publishes state diffs on-chain. The cost of the transaction, however, may still depend on transaction length because the sequencer stores long transactions in-memory. Long transactions incur additional costs during interactions with an account. -zkSync Era works with different types of accounts and, therefore, the protocol +ZKsync Era works with different types of accounts and, therefore, the protocol cannot make assumptions about signature length. Furthermore, given that a signature (and thus its length) is unavailable at the time of fee estimation, we cannot precisely estimate the cost of such a transaction. To mitigate this, we multiply @@ -73,7 +73,7 @@ the recommended cost of the transaction by a small percentage. ### `DefaultAccount` -By default, the zkSync Era sequencer provides a transaction structure with the +By default, the ZKsync Era sequencer provides a transaction structure with the available information during the fee estimation. Because the signature is unavailable prior to the transaction taking place, an @@ -103,7 +103,7 @@ See the documentation on [account abstraction](/build/developer-reference/accoun Because the entire transaction validation and execution flow is simulated in order to get the transaction’s fee, the user needs to have sufficient funds in their -account, otherwise the simulation may exit. This means that, to ensure the execution progresses, the zkSync Era sequencer adds the necessary balance, +account, otherwise the simulation may exit. This means that, to ensure the execution progresses, the ZKsync Era sequencer adds the necessary balance, temporarily, to the user’s account; specifically the sequencer increases the account balance by tx.maxFeePerGas \* tx.gasLimit. This ensures the `DefaultAccount`’s `payForTransaction` function runs successfully. @@ -129,7 +129,7 @@ Refunds are calculated by defining a fair value for the amount the user spent on ## Out-of-gas errors -Unlike on Geth, it is impossible to track out-of-gas errors on zkSync Era. +Unlike on Geth, it is impossible to track out-of-gas errors on ZKsync Era. The main reason is that the “actual” execution happens inside the `DefaultAccount` system contract and, due to the [63/64 rule](https://eips.ethereum.org/EIPS/eip-150), diff --git a/content/00.build/70.api-reference/00.index.md b/content/00.build/70.api-reference/00.index.md index 3fbca3e9..a4949d81 100644 --- a/content/00.build/70.api-reference/00.index.md +++ b/content/00.build/70.api-reference/00.index.md @@ -1,11 +1,11 @@ --- title: Overview -description: Explore the comprehensive guide to the zkSync Era JSON-RPC API, offering seamless Ethereum integration and advanced Layer 2 functionalities for developers. +description: Explore the comprehensive guide to the ZKsync Era JSON-RPC API, offering seamless Ethereum integration and advanced Layer 2 functionalities for developers. --- -Welcome to the zkSync Era API reference documentation! This page provides you with a high-level overview of our API capabilities and essential information. +Welcome to the ZKsync Era API reference documentation! This page provides you with a high-level overview of our API capabilities and essential information. -zkSync Era seamlessly integrates with the Ethereum ecosystem. To achieve this integration, +ZKsync Era seamlessly integrates with the Ethereum ecosystem. To achieve this integration, we support not only the standard Ethereum JSON-RPC API but also introduce L2-specific features that enhance functionality. @@ -25,7 +25,7 @@ Generally, these limits are ample, ranging from 10 to 100 requests per second (R ## API Collections Explore our curated collections of API endpoints tailored for every need, from seamless Ethereum integrations to advanced debugging tools. -Embrace the full potential of zkSync Era and elevate your dApps to new heights. Discover, integrate, and innovate with our robust API offerings. +Embrace the full potential of ZKsync Era and elevate your dApps to new heights. Discover, integrate, and innovate with our robust API offerings. ::card-group ::card @@ -38,11 +38,11 @@ Embrace the full potential of zkSync Era and elevate your dApps to new heights. :: ::card --- - title: zkSync JSON-RPC API + title: ZKsync JSON-RPC API icon: i-zksync-zksync-logo to: /build/api-reference/zks-rpc --- - Unlock Layer 2 capabilities with our dedicated zkSync JSON-RPC API. + Unlock Layer 2 capabilities with our dedicated ZKsync JSON-RPC API. :: ::card --- diff --git a/content/00.build/70.api-reference/10.conventions.md b/content/00.build/70.api-reference/10.conventions.md index 69e237cd..f90f38d9 100644 --- a/content/00.build/70.api-reference/10.conventions.md +++ b/content/00.build/70.api-reference/10.conventions.md @@ -1,6 +1,6 @@ --- title: Conventions -description: Formatting conventions and references for use with zkSync Era API docs. +description: Formatting conventions and references for use with ZKsync Era API docs. --- ## Hex value encoding diff --git a/content/00.build/70.api-reference/20.zks-rpc.md b/content/00.build/70.api-reference/20.zks-rpc.md index a2b20199..d4e2dce9 100644 --- a/content/00.build/70.api-reference/20.zks-rpc.md +++ b/content/00.build/70.api-reference/20.zks-rpc.md @@ -1,11 +1,11 @@ --- title: ZKs JSON-RPC API -description: Overview of the JSON-RPC API methods specific to zkSync Era, detailing operations and functionalities within the zkSync Era ecosystem. +description: Overview of the JSON-RPC API methods specific to ZKsync Era, detailing operations and functionalities within the ZKsync Era ecosystem. github: https://github.com/matter-labs/zksync-era/blob/main/core/lib/web3_decl/src/namespaces/zks.rs --- -zkSync Era provides a suite of JSON-RPC API methods designed for seamless interaction with its ecosystem. -These methods offer developers the tools needed to integrate their applications with zkSync Era's features, +ZKsync Era provides a suite of JSON-RPC API methods designed for seamless interaction with its ecosystem. +These methods offer developers the tools needed to integrate their applications with ZKsync Era's features, enhancing the capability to perform transactions, query network data, and interact with smart contracts efficiently. ## `zks_estimateFee` @@ -225,7 +225,7 @@ curl --request POST \ ## `zks_getBridgeContracts` -Retrieves the addresses of canonical bridge contracts for zkSync Era. +Retrieves the addresses of canonical bridge contracts for ZKsync Era. #### Parameters @@ -311,7 +311,7 @@ curl --request POST \ ## `zks_getConfirmedTokens` -Lists confirmed tokens. **Confirmed** in the method name means any token bridged to zkSync Era via the official bridge. +Lists confirmed tokens. **Confirmed** in the method name means any token bridged to ZKsync Era via the official bridge. The tokens are returned in alphabetical order by their symbol. This means the token id is its position in an alphabetically sorted array of tokens. @@ -326,7 +326,7 @@ position in an alphabetically sorted array of tokens. **Array** of token objects, each containing details about a specific confirmed token. - **l1Address**: DATA, 20 bytes - Layer 1 Ethereum address of the token. -- **l2Address**: DATA, 20 bytes - Layer 2 zkSync Era address of the token. +- **l2Address**: DATA, 20 bytes - Layer 2 ZKsync Era address of the token. - **name**: String - name of the token. - **symbol**: String - symbol of the token. - **decimals**: uint8 - number of decimals the token uses. @@ -590,7 +590,7 @@ Object containing detailed information about the specified block. - **l2FairGasPrice**: uint64 - fair gas price on L2 at the time of the block's execution. - **baseSystemContractsHashes**: Object - A collection of hashes for the base system contracts. - **operatorAddress**: DATA, 20 bytes - address of the operator who committed the block. -- **protocolVersion**: String - version of the zkSync protocol the block was committed under. +- **protocolVersion**: String - version of the ZKsync protocol the block was committed under. #### Example Request @@ -990,7 +990,7 @@ None Object -- **V2**: Object - fee parameter configuration for the current version of the zkSync protocol. +- **V2**: Object - fee parameter configuration for the current version of the ZKsync protocol. - **config**: Object - settings related to transaction fee computation. - **minimal_l2_gas_price**: uint64 - minimal gas price on L2. - **compute_overhead_part**: float64 - compute overhead part in fee calculation. @@ -1105,18 +1105,18 @@ curl --request POST \ This method generates Merkle proofs for one or more storage values associated with a specific account, accompanied by a proof of their authenticity. It verifies that these values remain unaltered. -Similar to Ethereum's `eth_getProof`, this method provides verification means under zkSync Era's distinct +Similar to Ethereum's `eth_getProof`, this method provides verification means under ZKsync Era's distinct Merkle tree architecture, noting several key differences: - The retrieval of values and their respective proofs is determined by an L1 batch number instead of a block number. -- zkSync Era employs a different Merkle tree structure, necessitating a unique approach to proof verification. +- ZKsync Era employs a different Merkle tree structure, necessitating a unique approach to proof verification. Unlike Ethereum's two-level hexadecimal trie—where the top level maps to accounts and the bottom to account storage slots—Era uses a single-level, full binary tree with 256-bit keys. - In Ethereum, account-level values are mapped using specific combinations of account and storage keys. For example, to store the code hash for account address A, it uses account `0x0000000000000000000000000000000000008002` -and a storage key generated by padding A's address. Conversely, zkSync Era's Merkle tree specifics are as follows: +and a storage key generated by padding A's address. Conversely, ZKsync Era's Merkle tree specifics are as follows: -**zkSync Era Merkle Tree Details:** +**ZKsync Era Merkle Tree Details:** - The tree is a one-level, full binary tree, supporting 256-bit keys and 40-byte values. - Keys are derived by reversing the output of `reversed(blake2s256([0_u8; 12] ++ account_address ++ storage_key))`, @@ -1210,7 +1210,7 @@ if the transaction had already been included in the block. The API has a similar `eth_sendRawTransaction` but with some extra data returned from it. With this API Consumer apps can apply "optimistic" events in their applications instantly without having to wait for -zkSync block confirmation time. +ZKsync block confirmation time. It’s expected that the optimistic logs of two uncommitted transactions that modify the same state will not have causal relationships between each other. diff --git a/content/00.build/70.api-reference/30.debug-rpc.md b/content/00.build/70.api-reference/30.debug-rpc.md index 51d1d670..25456d4c 100644 --- a/content/00.build/70.api-reference/30.debug-rpc.md +++ b/content/00.build/70.api-reference/30.debug-rpc.md @@ -1,6 +1,6 @@ --- title: Debug JSON-RPC API -description: Methods useful for debugging purposes with zkSync Era. +description: Methods useful for debugging purposes with ZKsync Era. github: https://github.com/matter-labs/zksync-era/blob/main/core/lib/web3_decl/src/namespaces/debug.rs --- diff --git a/content/00.build/70.api-reference/35.ethereum-rpc.md b/content/00.build/70.api-reference/35.ethereum-rpc.md index 94528d70..50283c7f 100644 --- a/content/00.build/70.api-reference/35.ethereum-rpc.md +++ b/content/00.build/70.api-reference/35.ethereum-rpc.md @@ -1,21 +1,21 @@ --- title: Ethereum JSON-RPC API -description: JSON-RPC API methods for the eth_ namespace for zkSync Era. +description: JSON-RPC API methods for the eth_ namespace for ZKsync Era. --- ZKsync Era supports the standard [Ethereum JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/). ## Important Differences for Developers -When working with zkSync, there are specific differences you should be aware of: +When working with ZKsync, there are specific differences you should be aware of: 1. **Block Data Retrieval Methods**: - Methods that return data about a block, such as `eth_getBlockByHash`, `eth_getBlockByNumber`, and Geth’s pubsub API `eth_subscribe` with the `newHeads` parameter, do not provide the actual `receiptsRoot`, `transactionsRoot`, and `stateRoot` values. - - Instead, these fields contain zero values because zkSync’s L2 blocks do not include the concept of a state root; only L1 batches have this concept. + - Instead, these fields contain zero values because ZKsync’s L2 blocks do not include the concept of a state root; only L1 batches have this concept. 2. **Unsupported Method**: - - The method `eth_sendTransaction` is intentionally not supported in zkSync. + - The method `eth_sendTransaction` is intentionally not supported in ZKsync. ## `eth_chainId` @@ -1305,7 +1305,7 @@ None **String** - A single string indicating the protocol version. The version is prefixed with an identifier -(e.g. "zks" for zkSync) followed by a version number. +(e.g. "zks" for ZKsync) followed by a version number. #### Example Request @@ -1489,7 +1489,7 @@ None #### Returns **String** - The client version supported by the node. -The version is prefixed with an identifier (e.g. "zkSync" for zkSync) followed by a version number. +The version is prefixed with an identifier (e.g. "ZKsync" for ZKsync) followed by a version number. #### Example Request @@ -1510,7 +1510,7 @@ curl --request POST \ ```json { "jsonrpc": "2.0", - "result": "zkSync/v2.0", + "result": "ZKsync/v2.0", "id": 1 } ``` diff --git a/content/00.build/70.api-reference/40.pub-sub-rpc.md b/content/00.build/70.api-reference/40.pub-sub-rpc.md index a70861ea..2613fc2a 100644 --- a/content/00.build/70.api-reference/40.pub-sub-rpc.md +++ b/content/00.build/70.api-reference/40.pub-sub-rpc.md @@ -1,10 +1,10 @@ --- title: PubSub JSON-RPC API -description: Methods to subscribe/unsubscribe to events and receive notifications on zkSync Era. +description: Methods to subscribe/unsubscribe to events and receive notifications on ZKsync Era. --- Clients can subscribe to specific events and receive notifications, -thus avoiding the need to poll. zkSync is fully compatible with [Geth's pubsub API](https://geth.ethereum.org/docs/interacting-with-geth/rpc/pubsub), +thus avoiding the need to poll. ZKsync is fully compatible with [Geth's pubsub API](https://geth.ethereum.org/docs/interacting-with-geth/rpc/pubsub), except for the `syncing` subscription. The WebSocket URL is `wss://mainnet.era.zksync.io/ws` diff --git a/content/00.build/90.contributing-to-documentation/10.index.md b/content/00.build/90.contributing-to-documentation/10.index.md index 7b3f281c..eb9a9f96 100644 --- a/content/00.build/90.contributing-to-documentation/10.index.md +++ b/content/00.build/90.contributing-to-documentation/10.index.md @@ -1,17 +1,17 @@ --- title: Overview -description: Explore how to contribute to zkSync's open-source projects and community. +description: Explore how to contribute to ZKsync's open-source projects and community. --- -zkSync is an open-source project. We champion community-driven development, which means you, -from any corner of the world, can contribute to shaping zkSync's future. +ZKsync is an open-source project. We champion community-driven development, which means you, +from any corner of the world, can contribute to shaping ZKsync's future. -This section outlines how you can enhance our documentation, engage with the zkSync community, +This section outlines how you can enhance our documentation, engage with the ZKsync community, and contribute to our other open-source projects. ### Edit Existing Content -We welcome your edits to any content on the zkSync Docs website. To contribute changes, +We welcome your edits to any content on the ZKsync Docs website. To contribute changes, you will need a [GitHub account](https://github.com/signup). For minor edits, use the "Edit this page" link found on pages within the Table of Contents on the right side of the page. @@ -37,15 +37,15 @@ to maintain consistency across our documentation. ### Submit a Community Tutorial or Guide -The zksync-docs project primarily focuses on documentation that helps readers understand zkSync and develop in the ecosystem. -If your guide or tutorial includes using another tool or service with zkSync, consider submitting it to our Community content. +The zksync-docs project primarily focuses on documentation that helps readers understand ZKsync and develop in the ecosystem. +If your guide or tutorial includes using another tool or service with ZKsync, consider submitting it to our Community content. These documents, while adjacent to our technical documentation, are hosted in a separate project repo on GitHub. -### Showcase Your Projects Built on zkSync +### Showcase Your Projects Built on ZKsync -We're excited to see new projects developed by our community within the zkSync ecosystem! +We're excited to see new projects developed by our community within the ZKsync ecosystem! If you've released a project recently, we'd love to hear about it. -Our [zkSync Community Hub Discussions](https://github.com/zkSync-Community-Hub/zksync-developers) +Our [ZKsync Community Hub Discussions](https://github.com/ZKsync-Community-Hub/zksync-developers) has a section where you can -[submit your project](https://github.com/zkSync-Community-Hub/zksync-developers/discussions/new?category=show-and-tell) +[submit your project](https://github.com/ZKsync-Community-Hub/zksync-developers/discussions/new?category=show-and-tell) for the community to discover. diff --git a/content/00.build/90.contributing-to-documentation/20.contribution-guidelines.md b/content/00.build/90.contributing-to-documentation/20.contribution-guidelines.md index 9540d76d..2efb8630 100644 --- a/content/00.build/90.contributing-to-documentation/20.contribution-guidelines.md +++ b/content/00.build/90.contributing-to-documentation/20.contribution-guidelines.md @@ -1,6 +1,6 @@ --- title: Contribution Guidelines -description: Learn how to contribute to zkSync Docs +description: Learn how to contribute to ZKsync Docs --- ## Fork the project @@ -56,7 +56,7 @@ in VSCode and search for `@recommended`. --- ## What the project uses -zkSync docs is built with Vue and Nuxt framework, utilizing various Nuxt Modules for content development. +ZKsync docs is built with Vue and Nuxt framework, utilizing various Nuxt Modules for content development. Familiarize yourself with their documentation to provide you with the full capability of contributing. ### Nuxt diff --git a/content/00.build/90.contributing-to-documentation/30.documentation-styleguide.md b/content/00.build/90.contributing-to-documentation/30.documentation-styleguide.md index 453f2ba2..e2710141 100644 --- a/content/00.build/90.contributing-to-documentation/30.documentation-styleguide.md +++ b/content/00.build/90.contributing-to-documentation/30.documentation-styleguide.md @@ -1,9 +1,9 @@ --- title: Documentation Styleguide -description: A comprehensive guide on zkSync documentation standards, including writing style, Markdown conventions, code snippets, and documentation categorization. +description: A comprehensive guide on ZKsync documentation standards, including writing style, Markdown conventions, code snippets, and documentation categorization. --- -This guide outlines the standards for creating zkSync documentation, +This guide outlines the standards for creating ZKsync documentation, ensuring consistency in writing style, Markdown conventions, and code snippets. ## Writing Style @@ -22,31 +22,31 @@ It's crucial to create content that is inclusive, diverse, and timeless. Focus o ## Spelling -Content in zkSync Docs are run through a linter for markdown formatting and spellchecking. +Content in ZKsync Docs are run through a linter for markdown formatting and spellchecking. Some words may not pass the spellcheck linter and will need to be added to the dictionary list. New words can be added to lists in `/cspell-config`. All words added to the dictionary are checked for spelling only. ## Time & Dates -To minimize confusion due to global date format variations, adhere to the following in zkSync docs: +To minimize confusion due to global date format variations, adhere to the following in ZKsync docs: - Start calendars on Mondays. - Use the date format `month dd, yyyy`, avoiding numerals for months (e.g., January 5, 2018). ## Types of documentation -Following the [Diataxis](https://diataxis.fr/) framework, zkSync Docs categorizes content into +Following the [Diataxis](https://diataxis.fr/) framework, ZKsync Docs categorizes content into -- **Tutorials**: Step-by-step instructions to teach general skills (e.g., Deploying your first contract on zkSync Era). +- **Tutorials**: Step-by-step instructions to teach general skills (e.g., Deploying your first contract on ZKsync Era). - **Guides**: Task completion instructions for readers with basic knowledge (e.g., Debugging with zksync-cli). - **References**: Detailed technical descriptions (e.g., Ethereum JSON-RPC API). - **Explanation**: Content to deepen subject understanding -(e.g., Differences between zkSync Native Account Abstraction and Ethereum's EIP 4337). +(e.g., Differences between ZKsync Native Account Abstraction and Ethereum's EIP 4337). ### Choosing a category -Leverage the [Diataxis](https://diataxis.fr/) system when crafting a new article for zkSync Docs. +Leverage the [Diataxis](https://diataxis.fr/) system when crafting a new article for ZKsync Docs. Writing without a clear category often results in unfocused content. A well-defined focus keeps the content streamlined and clarifies the takeaway for the reader. @@ -79,7 +79,7 @@ If you do not want a description for your page, simply leave the `description` v ## Images -Add images to the `public/images/` directory to use in zkSync docs +Add images to the `public/images/` directory to use in ZKsync docs and reference them from the `/images` path, do not include the `public/`. Use the markdown format to display images. @@ -119,7 +119,7 @@ Example link to an internal page using markdown format, with an anchor tag. ## Markdown and Vue components -zkSync Docs combine Markdown with Vue components though the syntax is different. +ZKsync Docs combine Markdown with Vue components though the syntax is different. For example, if you use a [Nuxt UI Button component](https://ui.nuxt.com/components/button), the html syntax would be the following: ```html @@ -219,12 +219,12 @@ export default defineNuxtConfig({ ## Localization -Currently, zkSync Docs does not offer localized documentation. +Currently, ZKsync Docs does not offer localized documentation. Updates to this section will be provided as localization features become available. ## Use of AI -While fully AI-generated content is not accepted for zkSync Docs, +While fully AI-generated content is not accepted for ZKsync Docs, the assistance of AI tools like ChatGPT in editing content is permitted. These tools can enhance the editing process, although they may occasionally produce inaccurate information. @@ -236,7 +236,7 @@ You can use the following as a prompt for an AI tool to help with editing: The content is written in common markdown format. Use the Google Developer Documentation Style Guide and the Microsoft Style Guide, emphasizing Bias-free communication. Write in an active voice. -Do not use the definite or indefinite article with “zkSync Era”. +Do not use the definite or indefinite article with “ZKsync Era”. Assume the reader may be an international person whose first language might not be English. Don’t use overly complex words unless the technical description is lost if changed. Ensure all communication is bias-free, following the Microsoft Style Guide's directives for inclusiveness and fairness in language. diff --git a/content/00.build/95.resources/20.glossary.md b/content/00.build/95.resources/20.glossary.md index 5932f450..093b9e45 100644 --- a/content/00.build/95.resources/20.glossary.md +++ b/content/00.build/95.resources/20.glossary.md @@ -1,6 +1,6 @@ --- title: Glossary -description: A dictionary of terms you'll encounter with zkSync +description: A dictionary of terms you'll encounter with ZKsync --- ### Account Abstraction @@ -20,11 +20,11 @@ Thus, any EVM smart contract works with 100% assurance out of the box. EVM Compatible means that a percentage of the opcodes of Ethereum’s EVM are supported; thus, a percentage of smart contracts work out of the box. -zkSync is optimized to be EVM source-code compatible (with a custom compiler), not EVM equivalent. +ZKsync is optimized to be EVM source-code compatible (with a custom compiler), not EVM equivalent. ### Paymaster -A Paymaster is an account on the zkSync network that can cover transaction fees for users. +A Paymaster is an account on the ZKsync network that can cover transaction fees for users. It can pay these fees directly and allow users to reimburse the fees using various digital assets. ### SNARK (Succinct Non-Interactive Argument of Knowledge) @@ -32,9 +32,9 @@ It can pay these fees directly and allow users to reimburse the fees using vario SNARKs are a kind of zero-knowledge proof system that are short and quick to verify. SNARKs are characterized by their use of the KZG (Kate, Zaverucha, and Goldberg) commitment scheme which uses elliptic curve cryptography. -### zkSync VM +### ZKsync VM -zkSync VM is the name of the architecture that enables zero-knowledge proof generation +ZKsync VM is the name of the architecture that enables zero-knowledge proof generation for the execution trace of smart contracts originally written for EVM. ### ZK Rollup @@ -44,4 +44,4 @@ After the verification passes, the verified batch is considered final like any o This is achieved through the power of cryptographic validity proofs (commonly called zero-knowledge proofs). With any batch of off-chain transactions, the ZK rollup operator generates a proof of validity for this batch. Once the proof is generated, it is submitted to Ethereum to make the roll-up batch final. -In zkSync, this is done via a [SNARK](#snark-succinct-non-interactive-argument-of-knowledge), succinct non-interactive argument of knowledge. +In ZKsync, this is done via a [SNARK](#snark-succinct-non-interactive-argument-of-knowledge), succinct non-interactive argument of knowledge. diff --git a/content/00.build/95.resources/30.audit-bug-bounty.md b/content/00.build/95.resources/30.audit-bug-bounty.md index 408f3091..08934ca1 100644 --- a/content/00.build/95.resources/30.audit-bug-bounty.md +++ b/content/00.build/95.resources/30.audit-bug-bounty.md @@ -3,7 +3,7 @@ title: Audits and Bug Bounty Program description: --- -zkSync Era takes security seriously and as such, we have completed multiple audits in all critical parts of the +ZKsync Era takes security seriously and as such, we have completed multiple audits in all critical parts of the protocol. On top of that, there is an ongoing massive bug bounty program. ## Audits @@ -19,7 +19,7 @@ Here is the list of **completed audits**: - [Layer 1 Diff Audit (Upgrade Audit)](https://blog.openzeppelin.com/zksync-layer-1-diff-audit/), OpenZeppelin, from 2022-11-21 to 2022-11-25. - [Layer 1 Diff Audit (Upgrade Audit)](https://blog.openzeppelin.com/zksync-l1-diff-audit-february-2023/), OpenZeppelin, from 2023-02-06 to 2023-02-17. - [Layer 1 Public Contest](https://code4rena.com/reports/2022-10-zksync/), Code4rena, from 2022-10-28 to 2022-11-09. -- [Layer 1 Smart Contracts](https://github.com/Secure3Audit/Secure3Academy/blob/main/audit_reports/zkSync/zkSync_L1_final_Secure3_Audit_Report.pdf), +- [Layer 1 Smart Contracts](https://github.com/Secure3Audit/Secure3Academy/blob/main/audit_reports/ZKsync/ZKsync_L1_final_Secure3_Audit_Report.pdf), Secure3, from 2022-10-22 to 2022-11-06. - [WETH Bridge Audit](https://blog.openzeppelin.com/zksync-weth-bridge-audit), OpenZeppelin, from 2023-03-27 to 2023-03-31. - [Bridge and .transfer & .send](https://blog.openzeppelin.com/zksync-bridge-and-.transfer-.send-diff-audit), OpenZeppelin, from 2023-04-24 to 2023-05-01. @@ -37,7 +37,7 @@ Code4rena, from 2023-03-10 to 2023-03-19. - [Layer 1 & 2 Diff Audit](https://blog.openzeppelin.com/november-diff-audit), OpenZeppelin, from 2023-11-27 to 2023-12-05. - [Short-Term Fee Model Changes](https://blog.openzeppelin.com/short-term-fee-model-changes-audit), OpenZeppelin, from 2023-12-06 to 2023-12-13. - ZK Proof System, Internal Audit, from 2022-10-24 to 2022-11-18. -- [ZK Proof System](https://github.com/HalbornSecurity/PublicReports/blob/master/ZK%20Audits/MatterLabs_zkSync_Era_Circuits_Zero_Knowledge_Security_Audit_Report_Halborn_Final..pdf), +- [ZK Proof System](https://github.com/HalbornSecurity/PublicReports/blob/master/ZK%20Audits/MatterLabs_ZKsync_Era_Circuits_Zero_Knowledge_Security_Audit_Report_Halborn_Final..pdf), Halborn, from 2023-01-09 to 2023-03-08. - [Smart Contract Security Assessment](https://github.com/HalbornSecurity/PublicReports/blob/master/Solidity%20Smart%20Contract%20Audits/MatterLabs_Verifier_Smart_Contract_Security_Assessment_Report_Halborn_Final.pdf), Halborn, from July 12th, 2023 - July 20th, 2023. @@ -46,12 +46,12 @@ Halborn, from July 12th, 2023 - July 20th, 2023. ## Bug Bounty Program -zkSync Era has a very detailed **[Bug bounty Program on Immunefi](https://immunefi.com/bounty/zksyncera/)**. In the listing, you can +ZKsync Era has a very detailed **[Bug bounty Program on Immunefi](https://immunefi.com/bounty/zksyncera/)**. In the listing, you can find all the information related to assets in scope, reporting, and the payout process. ### Scope -The bug bounty program for zkSync Era aims to identify and resolve +The bug bounty program for ZKsync Era aims to identify and resolve security vulnerabilities in our system before they can be exploited by malicious actors. The program is open to all individuals and teams who are interested in participating and are willing to comply with the diff --git a/content/00.build/95.resources/40.community-channels.md b/content/00.build/95.resources/40.community-channels.md index 65fe9a08..31dc3a46 100644 --- a/content/00.build/95.resources/40.community-channels.md +++ b/content/00.build/95.resources/40.community-channels.md @@ -9,7 +9,7 @@ Engage with our vibrant community and stay updated on the latest news, insights, A dedicated space in GitHub for developers to discuss, collaborate, and brainstorm on technical topics. -[Engage in GitHub Discussions](https://github.com/zkSync-Community-Hub/zksync-developers/discussions) +[Engage in GitHub Discussions](https://github.com/ZKsync-Community-Hub/zksync-developers/discussions) --- @@ -44,7 +44,7 @@ Delve deep into comprehensive articles, tutorials, and insights penned by our te The most effective way to seek technical support is by raising an issue on GitHub. Ensure you provide a comprehensive description, relevant details, and steps to reproduce for prompt assistance. -- **zkSync Era Issues**: Address all queries and concerns related to zkSync Era here. [Report zkSync Era Issue](https://github.com/matter-labs/zksync-era/issues) +- **ZKsync Era Issues**: Address all queries and concerns related to ZKsync Era here. [Report ZKsync Era Issue](https://github.com/matter-labs/zksync-era/issues) - **era-test-node Issues**: If you're facing challenges with the era-test-node, this is the place to raise them. [Report era-test-node Issue](https://github.com/matter-labs/era-test-node/issues) - **SDKs Issues**: For any issues related to our Software Development Kits, kindly head over to this section. [Report SDKs Issue](https://github.com/zksync-sdk) diff --git a/content/00.build/95.resources/50.contribution-track.md b/content/00.build/95.resources/50.contribution-track.md index e185bde4..682a525c 100644 --- a/content/00.build/95.resources/50.contribution-track.md +++ b/content/00.build/95.resources/50.contribution-track.md @@ -3,28 +3,28 @@ title: Contribution Track description: --- -Welcome to the zkSync Contributors Track! The purpose of this track is to accelerate your journey into the thriving zkSync development +Welcome to the ZKsync Contributors Track! The purpose of this track is to accelerate your journey into the thriving ZKsync development landscape. As a fully open-source project, we -believe in community-driven development, and that means anyone from anywhere can contribute to shaping the future of zkSync. +believe in community-driven development, and that means anyone from anywhere can contribute to shaping the future of ZKsync. This track aims to guide you in discovering various aspects of our project, inspire you to -contribute in the ways that interest you most, and provide a pathway to connect with the zkSync community. +contribute in the ways that interest you most, and provide a pathway to connect with the ZKsync community. ## Open-source repositories Here's a list of our key open-source repositories that you can contribute to: -### zkSync Era +### ZKsync Era -- [**zkSync Era**](https://github.com/matter-labs/zksync-era): Node implementation for zkSync Era. +- [**ZKsync Era**](https://github.com/matter-labs/zksync-era): Node implementation for ZKsync Era. ### Smart Contracts -- [**era-contracts**](https://github.com/matter-labs/era-contracts): Submodule containing the smart contracts for zkSync Era. +- [**era-contracts**](https://github.com/matter-labs/era-contracts): Submodule containing the smart contracts for ZKsync Era. ### Circuit Implementation -- [**era-sync_vm**](https://github.com/matter-labs/era-sync_vm): Houses the circuit implementation of zkVM specifically for zkSync Era. +- [**era-sync_vm**](https://github.com/matter-labs/era-sync_vm): Houses the circuit implementation of zkVM specifically for ZKsync Era. ### Testing and debugging @@ -32,17 +32,17 @@ Here's a list of our key open-source repositories that you can contribute to: ### Development tools -- [**zksync-cli**](https://github.com/matter-labs/zksync-cli): CLI tool that aims to simplify the development process on zkSync. -- [**hardhat-zksync**](https://github.com/matter-labs/hardhat-zksync): Hardhat plugins tailored for the zkSync Network. +- [**zksync-cli**](https://github.com/matter-labs/zksync-cli): CLI tool that aims to simplify the development process on ZKsync. +- [**hardhat-zksync**](https://github.com/matter-labs/hardhat-zksync): Hardhat plugins tailored for the ZKsync Network. ### Documentation -- [**zksync-web-era-docs**](https://github.com/matter-labs/zksync-web-era-docs): The go-to source for official zkSync documentation. +- [**zksync-web-era-docs**](https://github.com/matter-labs/zksync-web-era-docs): The go-to source for official ZKsync documentation. ### SDK and explorers -- [**block-explorer**](https://github.com/matter-labs/block-explorer): The official block explorer for navigating the zkSync network. -- [**zksync-sdk**](https://github.com/zksync-sdk): Software Development Kit for ease of integration with the zkSync network. +- [**block-explorer**](https://github.com/matter-labs/block-explorer): The official block explorer for navigating the ZKsync network. +- [**zksync-sdk**](https://github.com/zksync-sdk): Software Development Kit for ease of integration with the ZKsync network. Feel free to explore these repositories, and don't hesitate to contribute! @@ -50,39 +50,39 @@ Feel free to explore these repositories, and don't hesitate to contribute! ### Purpose -- Facilitate easy entry for external contributors into zkSync's development ecosystem. +- Facilitate easy entry for external contributors into ZKsync's development ecosystem. - Offer a structured approach to involvement, reducing the initial overwhelm of diving into a new project. -- Build a strong, diverse, and global community of developers who are excited about zkSync. +- Build a strong, diverse, and global community of developers who are excited about ZKsync. ### Who is it for? - Developers interested in blockchain and layer 2 solutions. - Open-source enthusiasts looking to contribute to a growing project. -- Those interested in contract development, dApp development, zkSync Era, and more. +- Those interested in contract development, dApp development, ZKsync Era, and more. ## The track ### Getting started -#### 1. Introduce yourself on zkSync Discord +#### 1. Introduce yourself on ZKsync Discord - Join our [Discord channel](https://discord.com/invite/QKSsp7tC2x) and say 'hi' in the `#introductions` thread. Share what interests you and what you're hoping to learn or contribute. -#### 2. Follow zkSync Developers on X (formerly Twitter) +#### 2. Follow ZKsync Developers on X (formerly Twitter) - Keep up to date with the latest news, updates, and releases by [following us on X](https://x.com/zkSyncDevs). #### 3. Dive into our official documentation -- Immerse yourself in our comprehensive official documentation to acquire essential knowledge on zkSync. If +- Immerse yourself in our comprehensive official documentation to acquire essential knowledge on ZKsync. If you discover a typo, syntax error, or see room for improvement, submit a Pull Request to contribute to its enhancement. ### Dive into development -#### 4. Deploy your first contract using zkSync-CLI +#### 4. Deploy your first contract using ZKsync-CLI -- Familiarize yourself with the [zkSync-CLI tool](https://github.com/matter-labs/zksync-cli) and deploy your first contract on the zkSync Era testnet. +- Familiarize yourself with the [ZKsync-CLI tool](https://github.com/matter-labs/zksync-cli) and deploy your first contract on the ZKsync Era testnet. #### 5. Tackle a 'Good First Issue' @@ -91,12 +91,12 @@ a great way to get hands-on experience and a feel for the project. ### Community engagement -#### 6. Participate in zkSync Developer discussions +#### 6. Participate in ZKsync Developer discussions -- Join the discourse on [GitHub discussions](https://github.com/zkSync-Community-Hub/zkync-developers/discussions) +- Join the discourse on [GitHub discussions](https://github.com/ZKsync-Community-Hub/zkync-developers/discussions) or other community forums to provide answers, ask questions, or share insights. #### 7. Submit a community tutorial or guide - Help others by sharing your knowledge. Write a tutorial or guide and submit it to our -[GitHub project](https://github.com/zkSync-Community-Hub/community-code) for [Community Code](https://code.zksync.io). +[GitHub project](https://github.com/ZKsync-Community-Hub/community-code) for [Community Code](https://code.zksync.io). diff --git a/content/00.build/95.resources/60.faq.md b/content/00.build/95.resources/60.faq.md index 73619961..5300e0da 100644 --- a/content/00.build/95.resources/60.faq.md +++ b/content/00.build/95.resources/60.faq.md @@ -3,47 +3,47 @@ title: FAQ description: --- -Here you will find some of the most common questions we receive about zkSync Era. +Here you will find some of the most common questions we receive about ZKsync Era. -## What is zkSync Era? +## What is ZKsync Era? -zkSync Era is a Zero Knowledge (ZK) rollup that supports generalized EVM compatibility for the Ethereum blockchain. The primary benefit of zkSync -Era is that developers who have created EVM dApps can port to zkSync Era effortlessly and realize +ZKsync Era is a Zero Knowledge (ZK) rollup that supports generalized EVM compatibility for the Ethereum blockchain. The primary benefit of ZKsync +Era is that developers who have created EVM dApps can port to ZKsync Era effortlessly and realize significantly lower gas fees and more transactions per second while inheriting Ethereum's security and decentralization. -## Why zkSync Era? +## Why ZKsync Era? -zkSync Era is a gigantic leap forward in Layer 2 technologies. It is a long-awaited improvement +ZKsync Era is a gigantic leap forward in Layer 2 technologies. It is a long-awaited improvement that offers many never before enjoyed benefits for Ethereum developers. -- **EVM Compatible** - zkSync is an EVM-compatible zero knowledge rollup that supports generalized EVM smart contracts. This means if you already -have EVM smart contracts, it’s super easy to port your dApp to zkSync Era. +- **EVM Compatible** - ZKsync is an EVM-compatible zero knowledge rollup that supports generalized EVM smart contracts. This means if you already +have EVM smart contracts, it’s super easy to port your dApp to ZKsync Era. - **Ethos Compatible** - we are very aligned with the ethos of decentralization and open source. All of our code will strive to be fully open-source -and zkSync will be executing a roadmap that will fully decentralize the sequencer and proof generation, and we will be executing a roadmap of +and ZKsync will be executing a roadmap that will fully decentralize the sequencer and proof generation, and we will be executing a roadmap of organizational subtractive management - that is, we will be decentralizing our organization as well. - **Certainty** - Unlike previous methods attempting to scale Ethereum which have in some cases offered weaker security guarantees than for -L1 (e.g. sidechains, plasma, and optimistic) zkSync Era uses zero-knowledge proofs which offer _certainty_ of security. -- **Future Proof** - Ecosystem projects that adopt zkSync Era now will enjoy all future improvements without the need to change their code, in +L1 (e.g. sidechains, plasma, and optimistic) ZKsync Era uses zero-knowledge proofs which offer _certainty_ of security. +- **Future Proof** - Ecosystem projects that adopt ZKsync Era now will enjoy all future improvements without the need to change their code, in particular coming from: - The prover technology: hardware acceleration and [new proof systems](https://zksync.mirror.xyz/HJ2Pj45EJkRdt5Pau-ZXwkV2ctPx8qFL19STM5jdYhc). - The compiler: integration of LLVM-enabled modern programming languages. [Learn more about our compiler toolchain](/zk-stack/components/compiler/toolchain). - Other innovations like [ZK Chains, Hyperbridges and ZK Stack](/zk-stack/concepts/zk-chains). -## What is the zkSync VM? +## What is the ZKsync VM? -zkSync VM is the name of the architecture that enables zero-knowledge proof generation for the execution trace of smart contracts originally +ZKsync VM is the name of the architecture that enables zero-knowledge proof generation for the execution trace of smart contracts originally written for EVM. Its architecture is based on the following components: -- zkSync VM, a Turing-complete RISC-like virtual machine optimized for proving in a ZKP circuit. It has several different implementations: +- ZKsync VM, a Turing-complete RISC-like virtual machine optimized for proving in a ZKP circuit. It has several different implementations: - Executor: fast native execution on CPU. - Witness generator: native executor to generate ZKP witness. - Prover: the actual ZKP circuit implementation. - LLVM-based compiler with: - Solidity frontend (more precisely: Yul frontend). - Vyper frontend. - - zkSync VM backend. + - ZKsync VM backend. - Special-purpose circuits (heavily relying on PLONK’s custom gates and lookup tables) as “precompiles” for computationally intensive operations, such as: - Non-algebraic hashes (Keccak, SHA256, Blake2). @@ -51,20 +51,20 @@ operations, such as: - Elliptic curve pairing. - Recursive aggregation circuit (combines the proofs from the above-mentioned parts). -### zkSync VM vs EVM +### ZKsync VM vs EVM -Apart from the opcodes and gas metering disparity, zkSync VM strictly inherits the EVM programming model and its invariants, including the ABI +Apart from the opcodes and gas metering disparity, ZKsync VM strictly inherits the EVM programming model and its invariants, including the ABI calling conventions. One important thing to emphasize is that the zkVM supports rollbacks and provably revertible transactions. It guarantees mutual protection: users can not stall the network with bombardment by revertible transactions, and the escape hatch (priority queue) protects the user’s ability to include any transactions into the blocks. As a result, developers can fully rely on the censorship-resistance provided by L1 without having to introduce any changes related to the -escape-hatch mechanism. This means that assets in a zkRollup account on zkSync will have exactly the same security guarantees as on L1. +escape-hatch mechanism. This means that assets in a zkRollup account on ZKsync will have exactly the same security guarantees as on L1. ### EVM Improvements -While maintaining maximum compatibility, the zkSync Era's zkEVM has significant improvements over the EVM that increase adoption and benefit +While maintaining maximum compatibility, the ZKsync Era's zkEVM has significant improvements over the EVM that increase adoption and benefit our ecosystem projects. - **Our compiler is based on LLVM**. LLVM-based compilers (Low-Level Virtual Machine) have become the default compiler for Mac OS X, iOS, FreeBSD, @@ -80,7 +80,7 @@ developer adoption and user experience in a number of ways: - Transaction fees can be paid in any token using [paymasters](/build/developer-reference/account-abstraction/paymasters). - Protocols can now subsidize gas for users from their smart contracts or even enable gasless transactions. - Transaction batches (multicall) can be confirmed in one click (big UX problem on Ethereum today). - - Learn more about [account abstraction support in zkSync Era](/build/developer-reference/account-abstraction). + - Learn more about [account abstraction support in ZKsync Era](/build/developer-reference/account-abstraction). ### EVM Compatibility @@ -91,14 +91,14 @@ versus EVM Equivalent. First, let’s define what is meant by the two. with 100% assurance out of the box. - **EVM Compatible** means that a percentage of the opcodes of Ethereum’s EVM are supported; thus, a percentage of smart contracts work out of the box. -zkSync is optimized to be EVM _compatible_ not EVM _equivalent_ for three primary reasons: +ZKsync is optimized to be EVM _compatible_ not EVM _equivalent_ for three primary reasons: 1. Creating a generalized circuit for EVM equivalence down to the bytecode would be prohibitively expensive and time-consuming. -2. Building on what we learned with zkSync Lite, we were able to design a system optimized for performance and provability in ZK. +2. Building on what we learned with ZKsync Lite, we were able to design a system optimized for performance and provability in ZK. 3. The opcodes we’ve chosen NOT to support are deprecated by Ethereum itself, or rarely used. In the case a project needs them, modifications to -work with zkSync are minimal and do not generate a need for a new security audit. +work with ZKsync are minimal and do not generate a need for a new security audit. -Almost every smart contract written for EVM will be supported by zkSync Era and will hold all key security invariants so that no additional security +Almost every smart contract written for EVM will be supported by ZKsync Era and will hold all key security invariants so that no additional security re-auditing will be required in most cases. There are a few other distinctions, for example, gas metering will be different (as is the case for other L2s as well). Some EVM’s cryptographic @@ -107,16 +107,16 @@ being a priority to allow both ZK chains and protocols like Aztec/Dark Forest to ## Security expectations -zkSync Era’s data availability layer is Ethereum. All ecosystem projects that build on zkSync Era will inherit the full security benefits of Ethereum. +ZKsync Era’s data availability layer is Ethereum. All ecosystem projects that build on ZKsync Era will inherit the full security benefits of Ethereum. This is obviously a critically important topic for us, and the system has gone through several security audits and maintains a very detailed bug -bounty program. You can read more about [zkSync Era security in this section of the docs](/build/resources/audit-bug-bounty). +bounty program. You can read more about [ZKsync Era security in this section of the docs](/build/resources/audit-bug-bounty). ### Triggering Security audits While there are a few, rarely used opcodes that we do not support, we have not found any instances with our ecosystem projects where a breaking change was anything other than a simple refactoring of a few lines of code. None of our -ecosystem projects who have ported to zkSync have reported that any change has caused a need for a security audit. +ecosystem projects who have ported to ZKsync have reported that any change has caused a need for a security audit. ## What is Account Abstraction? @@ -133,12 +133,12 @@ with use cases including: In other words, Account Abstraction brings about major improvements to the overall user experience, and expands the application design space for developers. Learn more in [this blog post](https://www.argent.xyz/blog/wtf-is-account-abstraction/) by Argent. -In zkSync Era Account Abstraction is natively implemented, meaning accounts can initiate transactions, like an EOA, but can also have +In ZKsync Era Account Abstraction is natively implemented, meaning accounts can initiate transactions, like an EOA, but can also have arbitrary logic implemented in them, like a smart contract. -If you want to better understand what Account Abstraction on zkSync looks like, you can read [this section of the docs](/build/developer-reference/account-abstraction). +If you want to better understand what Account Abstraction on ZKsync looks like, you can read [this section of the docs](/build/developer-reference/account-abstraction). -## zkSync Era vs Optimistic Rollups +## ZKsync Era vs Optimistic Rollups Optimistic rollups utilize an optimistic approach to secure their networks. At the time of their development, they represented an important incremental improvement over other available options. However, a widely held opinion @@ -152,7 +152,7 @@ Optimistic rollups suffer from the following key downsides: mechanism to pay participants to discover fraudulent or otherwise invalid (e.g. because of bugs) transactions. Game theory is never perfect and as with the game theory that broke with stablecoins and other systems, we just don’t think it can be relied on in the long term and at true scale to offer the security the ecosystem needs. -zkSync Era, on the other hand, relies on math, not game theory, to provide the absolute certainty of +ZKsync Era, on the other hand, relies on math, not game theory, to provide the absolute certainty of proof that every single transaction is valid and not fraudulent. - **Optimistic methods take 7 days to settle**. Settlement time is becoming an increasingly @@ -161,7 +161,7 @@ optimistic methods, this settlement problem will not go away. It's always going settlement time because optimistic methods need 7 days for their after-the-fact game theory to conclude its challenge window. The only way around this is to bring in third parties that provide some liquidity - but then again this is a potential security risk in trusting the liquidity providers. -zkSync Era provides settlement in hours but with optimizations in the system we'll reduce the +ZKsync Era provides settlement in hours but with optimizations in the system we'll reduce the settlement time without the need of projects to update their code. - **Optimistic rollups have no method of scaling beyond where they are now.** When optimistic methods first came out, they became popular @@ -169,12 +169,12 @@ because they scaled Ethereum (e.g. they enabled the processing of 10x Ethereum t _without degradation of security and decentralization_). The problem is that while they can scale Ethereum by 10x now, they have no mechanism to go beyond 10x without degrading security and decentralization. -In contrast, zkSync Era is based on zero-knowledge proofs which have important characteristics that optimistic methods do not - they can hyperscale. +In contrast, ZKsync Era is based on zero-knowledge proofs which have important characteristics that optimistic methods do not - they can hyperscale. ## Which Wallets are supported? -At the moment, we support any Ethereum-based wallet like Metamask, BitKeep, TrustWallet or Zerion. You can add zkSync network to your -Metamask manually by following the instructions in the [interact with zkSync Era](/build/connect-to-zksync) page. +At the moment, we support any Ethereum-based wallet like Metamask, BitKeep, TrustWallet or Zerion. You can add ZKsync network to your +Metamask manually by following the instructions in the [interact with ZKsync Era](/build/connect-to-zksync) page. ## Token Listing @@ -191,19 +191,19 @@ To access Sepolia testnet funds, [you can use one of our third party faucets](/e ## How long does it take to complete a deposit transaction? -The transactions on zkSync Era should not take more than 5 minutes. +The transactions on ZKsync Era should not take more than 5 minutes. ## Where can I see the transactions I submitted? Our [Block Explorer](https://explorer.zksync.io) will show everything you may need about a transaction. -## Can someone claim the address I have for my contract in other EVM networks in zkSync Era? +## Can someone claim the address I have for my contract in other EVM networks in ZKsync Era? The contract address derivation formula is different from the regular EVM approach. Even if a contract is deployed from the same account address -with the same nonce, the zkSync Era contract address will not be the same as it is in another EVM network. This means, for example, that no one +with the same nonce, the ZKsync Era contract address will not be the same as it is in another EVM network. This means, for example, that no one will be able to claim an existing Ethereum address of your protocol to try to trick users into interacting with a malicious version of it. -## What is Block Gas Limit on zkSync Era? +## What is Block Gas Limit on ZKsync Era? The current value is currently set at roughly 2^32 gas.
**Note**: This value is temporal and will be updated soon. @@ -211,11 +211,11 @@ The current value is currently set at roughly 2^32 gas.
## Can I withdraw my funds back to Ethereum? Yes, the bridge is two-way. You can withdraw your funds back to Ethereum. The withdrawal transaction -[will take ~24 hours, depending on the usage of the zkSync Era network](/build/resources/withdrawal-delay). +[will take ~24 hours, depending on the usage of the ZKsync Era network](/build/resources/withdrawal-delay). ## What is a testnet re-genesis? -Sometimes, the team working on zkSync Era will initiate a re-genesis on testnet - a restart of the blockchain which will introduce upgrades and +Sometimes, the team working on ZKsync Era will initiate a re-genesis on testnet - a restart of the blockchain which will introduce upgrades and return the state to the initial point. ## Why do my contracts not compile in Windows? @@ -226,7 +226,7 @@ Additionally, if you use WSL 2, make sure that your project is located in the Li ## Proof sampling on testnet -zkSync Era testnet is experiencing immense demand, but its permissionless nature leaves our developer +ZKsync Era testnet is experiencing immense demand, but its permissionless nature leaves our developer infrastructure vulnerable to potential DoS attack vectors. Generating ZK proofs inherently incurs costs, and a determined attacker could exploit this by submitting a massive number of transactions, resulting in significant expenses for us. As we currently lack a more effective method for rationing resources, we have opted to diff --git a/content/00.build/95.resources/70.withdrawal-delay.md b/content/00.build/95.resources/70.withdrawal-delay.md index e5740714..2e8c7774 100644 --- a/content/00.build/95.resources/70.withdrawal-delay.md +++ b/content/00.build/95.resources/70.withdrawal-delay.md @@ -5,20 +5,20 @@ description: In order to prevent a quick drain of the protocol in the case a critical bug is discovered and exploited, we are introducing a block execution delay. Each L2 block committed to L1 will have a time lock before it is executed and finalized. This means that there is enough time to verify the -effects of the transactions included in a block before the block becomes final. The zkSync team will be monitoring each block and investigating +effects of the transactions included in a block before the block becomes final. The ZKsync team will be monitoring each block and investigating any anomaly (e.g. rapid outflow, unusually large withdrawals, etc). To introduce this time lock, no changes were made to the audited smart contracts. Instead, we have used an existing Validator role that we control and that we further restricted by pointing it to an intermediate smart contract with a time lock. The time lock is initially configured for a **24-hour** delay, which will gradually decrease as the system matures. Changing the delay requires multiple signatures collected from several cold -wallets owned by zkSync leadership. +wallets owned by ZKsync leadership. This design has the following advantages: - Even if an attacker finds a critical bug in ZK circuits and also successfully compromises the servers running our sequencer, there is plenty of time to detect an exploit, investigate, and freeze the protocol via governance. -- No changes were introduced to the zkSync Era contracts, so even if the intermediate contract is compromised we revert back to the original state. -- Delayed execution affects not only the standard zkSync ETH and ERC20 bridges but also any custom bridge built by a different team. +- No changes were introduced to the ZKsync Era contracts, so even if the intermediate contract is compromised we revert back to the original state. +- Delayed execution affects not only the standard ZKsync ETH and ERC20 bridges but also any custom bridge built by a different team. - Implementing the logic in an external governor-controlled contract makes it easy to remove this limitation later. ## Why can't I find my withdrawal on Etherscan? @@ -45,8 +45,8 @@ On the other hand, **Internal Transactions** are initiated by a smart contract o Although these transactions can be prompted by user activity, they are not sent directly from one address to another but are instead part of the internal workings of a smart contract. Internal transactions may involve the transfer of ETH or ERC20 tokens between different addresses within the contract. -Withdrawals from the zkSync Era network are typically internal transactions managed by the -[zkSync Era Diamond Proxy](https://etherscan.io/address/0x32400084c286cf3e17e7b677ea9583e60a000324) +Withdrawals from the ZKsync Era network are typically internal transactions managed by the +[ZKsync Era Diamond Proxy](https://etherscan.io/address/0x32400084c286cf3e17e7b677ea9583e60a000324) contract. These transactions are recorded in the **Internal Transactions** section in Etherscan due to their internal nature. In summary, the **Transactions** section in Etherscan displays transactions between external addresses, while the **Internal Transactions** @@ -64,7 +64,7 @@ funds from, not the destination address. 4. Scroll down to the **Internal Transactions** section. 5. Look for the internal transaction that corresponds to your withdrawal. You should see a transaction that shows the withdrawal amount -coming from the bridge. Withdrawal transactions from zkSync Era appear as transactions from **zkSync Era: Diamond Proxy** to your wallet address. +coming from the bridge. Withdrawal transactions from ZKsync Era appear as transactions from **ZKsync Era: Diamond Proxy** to your wallet address. 6. Once you've located the transaction, click on the **Parent Tx Hash** to view more details about the transaction, including the block number, gas used, and sender and recipient addresses. diff --git a/content/10.zk-stack/05.concepts/00.transaction-lifecycle.md b/content/10.zk-stack/05.concepts/00.transaction-lifecycle.md index beb01bc8..7ae13af0 100644 --- a/content/10.zk-stack/05.concepts/00.transaction-lifecycle.md +++ b/content/10.zk-stack/05.concepts/00.transaction-lifecycle.md @@ -1,6 +1,6 @@ --- title: Transaction Lifecycle -description: An in-depth guide on the transaction lifecycle within the ZK Stack, explaining the roles of the sequencer and prover, and detailing the transaction statuses and types in zkSync Era. +description: An in-depth guide on the transaction lifecycle within the ZK Stack, explaining the roles of the sequencer and prover, and detailing the transaction statuses and types in ZKsync Era. --- The ZK Stack facilitates the launch of rollups, which require certain operators like the sequencer and the prover. @@ -39,7 +39,7 @@ which operates efficiently on 16GB of GPU RAM, allowing for decentralization of --- ## Transaction data -Transactions in zkSync Era are [comparable to those on Ethereum](https://ethereum.org/en/developers/docs/transactions/), +Transactions in ZKsync Era are [comparable to those on Ethereum](https://ethereum.org/en/developers/docs/transactions/), allowing the use of the same wallets. Minor differences exist, particularly regarding fee settings. For details on fees, refer to the [fee model documentation](/zk-stack/concepts/fee-mechanism). @@ -60,7 +60,7 @@ Returned values from any RPC call outputting transaction details include: Contract deployment transactions interact with the `ContractDeployer` system contract and differ from standard transactions. -[Learn more about contract deployment in zkSync](/build/developer-reference/ethereum-differences/contract-deployment). +[Learn more about contract deployment in ZKsync](/build/developer-reference/ethereum-differences/contract-deployment). --- ## Transaction statuses @@ -77,10 +77,10 @@ For more on transaction completion and irrevocability, see the [finality documen --- ## Transaction types -zkSync Era supports a range of transaction types that are compatible with Ethereum, +ZKsync Era supports a range of transaction types that are compatible with Ethereum, yet they incorporate unique settings particularly around fee configurations. Here’s a detailed look at the transaction types, -including legacy, EIP-2930, EIP-1559, and EIP-712, and how they are implemented in zkSync Era. +including legacy, EIP-2930, EIP-1559, and EIP-712, and how they are implemented in ZKsync Era. ::callout{icon="i-heroicons-information-circle" color="blue"} When using RPC methods like [`eth_getTransactionByHash`](https://ethereum.github.io/execution-apis/api-documentation/), @@ -105,14 +105,14 @@ modifies how transaction fees are handled, replacing `gasPrice` with a base fee - `maxFeePerGas`: Overall maximum fee, including the `maxPriorityFeePerGas` and the base fee determined by the network. ::callout{icon="i-heroicons-exclamation-triangle" color="amber"} -In zkSync Era, while the EIP-1559 transaction format is supported, the `maxFeePerGas` and `maxPriorityFeePerGas` parameters are not utilized. +In ZKsync Era, while the EIP-1559 transaction format is supported, the `maxFeePerGas` and `maxPriorityFeePerGas` parameters are not utilized. :: ### EIP-712: `0x71` [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) enables structured data hashing and signing within transactions. -zkSync Era uses this for features like [account abstraction](/build/developer-reference/account-abstraction) and [paymasters](/build/developer-reference/account-abstraction/paymasters). +ZKsync Era uses this for features like [account abstraction](/build/developer-reference/account-abstraction) and [paymasters](/build/developer-reference/account-abstraction/paymasters). ```json "gasPerPubdata": "1212", @@ -152,10 +152,10 @@ These fields are handled by our SDKs. ### Priority: `0xff` - + --- -Each of these transaction types ensures that while zkSync Era remains closely aligned with Ethereum standards, +Each of these transaction types ensures that while ZKsync Era remains closely aligned with Ethereum standards, it also optimizes for its Layer 2 specific needs and functionalities. diff --git a/content/10.zk-stack/05.concepts/10.blocks.md b/content/10.zk-stack/05.concepts/10.blocks.md index d7dfae35..fcbea55a 100644 --- a/content/10.zk-stack/05.concepts/10.blocks.md +++ b/content/10.zk-stack/05.concepts/10.blocks.md @@ -1,16 +1,16 @@ --- title: Blocks and Batches -description: Explore how zkSync Era processes transactions by grouping them into blocks and batches, the role of sealing blocks, and the importance of rollbacks in the virtual machine. +description: Explore how ZKsync Era processes transactions by grouping them into blocks and batches, the role of sealing blocks, and the importance of rollbacks in the virtual machine. --- ## Overview of blocks and batches -zkSync Era processes transactions not only as individual units but also groups them into blocks and batches for efficiency and cost-effectiveness. +ZKsync Era processes transactions not only as individual units but also groups them into blocks and batches for efficiency and cost-effectiveness. This section covers how transactions are grouped, the concept of sealing blocks, and why rollbacks are crucial in our virtual machine (VM). ### Understanding L2 and L1 blocks -**L2 blocks**, also referred to as miniblocks, are specific to the zkSync Era network and are not recorded on the Ethereum blockchain. +**L2 blocks**, also referred to as miniblocks, are specific to the ZKsync Era network and are not recorded on the Ethereum blockchain. These blocks contain a smaller number of transactions, allowing for quick processing. Contrastingly, **L1 rollup blocks**, or batches, consist of several consecutive L2 blocks. @@ -26,7 +26,7 @@ To clarify these concepts visually, consider the following illustrations: *The Block layout image displays the organization of transactions within blocks and how L2 blocks are arranged within L1 batches.* ![Explorer example](/images/zk-stack/explorer-example.png) -*This Explorer example shows how the zkSync Era explorer represents blocks and transactions.* +*This Explorer example shows how the ZKsync Era explorer represents blocks and transactions.* --- ## Detailed look at L2 blocks @@ -53,7 +53,7 @@ The properties of an L2 block can be observed when using the `getBlock` method f | number | The current L2 block number, null if pending | | timestamp | UNIX timestamp for when the L2 block was formed | | nonce | Tracks the most recent transaction by the account's counter | -| difficulty | Always returns `2500000000000000` as zkSync does not use a proof of work consensus | +| difficulty | Always returns `2500000000000000` as ZKsync does not use a proof of work consensus | | gasLimit | Maximum gas allowed in this block, always returns `2^32-1` | | gasUsed | Actual amount of gas used in this block | | transactions | An array of transaction objects - see [TransactionResponse interface](/sdk/js/ethers/v6/providers#gettransaction) | @@ -61,13 +61,13 @@ The properties of an L2 block can be observed when using the `getBlock` method f ::callout{icon="i-heroicons-information-circle" color="blue"} **Block number and timestamp considerations**: -Recent protocol updates have changed some block properties on zkSync Era. More information is available on the [GitHub announcement](https://github.com/zkSync-Community-Hub/zkync-developers/discussions/87). +Recent protocol updates have changed some block properties on ZKsync Era. More information is available on the [GitHub announcement](https://github.com/ZKsync-Community-Hub/zkync-developers/discussions/87). :: --- ## The role of L1 batches -L1 batches are integral to zkSync Era as they represent the unit of computation for generating proofs. +L1 batches are integral to ZKsync Era as they represent the unit of computation for generating proofs. From a VM perspective, each L1 batch is akin to executing a program—the Bootloader, which processes all transactions within the batch. ### L1 batch size and processing times @@ -108,16 +108,16 @@ These oracles need to support snapshotting and rolling back operations to ensure --- ## Retrieving block and batch numbers -Accessing block and batch numbers in zkSync Era is straightforward: +Accessing block and batch numbers in ZKsync Era is straightforward: - `eth_blockNumber` retrieves the latest L2 block number. - `eth_getBlockByNumber` provides details for a specific L2 block. -- `zks_L1BatchNumber` fetches the most recent batch number, critical for understanding the scope of transactions and operations within zkSync Era. +- `zks_L1BatchNumber` fetches the most recent batch number, critical for understanding the scope of transactions and operations within ZKsync Era. --- -## Deeper dive into zkSync Era's batch and block mechanisms +## Deeper dive into ZKsync Era's batch and block mechanisms -This section delves into the intricate processes involved in initializing and managing L1 batches and L2 blocks within zkSync Era, +This section delves into the intricate processes involved in initializing and managing L1 batches and L2 blocks within ZKsync Era, providing insights into the technical frameworks and operational protocols. ### Initializing L1 batch @@ -167,7 +167,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 transactions’ in the batch +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 serve `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 store only the @@ -179,7 +179,7 @@ You can read more on what are the repeated writes and how the pubdata is process For blocks that predate certain system upgrades (migration upgrades), the blockhash is generated using a simplified formula that incorporates only the block number. -This method ensures backward compatibility and integrity across different block versions within the zkSync Era system. +This method ensures backward compatibility and integrity across different block versions within the ZKsync Era system. We use the following formula for their hash: @@ -187,7 +187,7 @@ We use the following formula for their hash: ### Timing invariants -zkSync Era maintains strict timing invariants to ensure that each block's timestamp is accurate and consistent relative to other system timestamps. +ZKsync Era maintains strict timing invariants to ensure that each block's timestamp is accurate and consistent relative to other system timestamps. These invariants include: diff --git a/content/10.zk-stack/05.concepts/20.fee-mechanism.md b/content/10.zk-stack/05.concepts/20.fee-mechanism.md index 7ae8b5ea..5b78a63a 100644 --- a/content/10.zk-stack/05.concepts/20.fee-mechanism.md +++ b/content/10.zk-stack/05.concepts/20.fee-mechanism.md @@ -1,19 +1,19 @@ --- -title: "zkSync Fee Mechanism" -description: "Understanding the fee mechanism in zkSync, including the influence of L1 gas prices on L2 transactions, and the unique pricing for batch overheads and operation costs." +title: "ZKsync Fee Mechanism" +description: "Understanding the fee mechanism in ZKsync, including the influence of L1 gas prices on L2 transactions, and the unique pricing for batch overheads and operation costs." --- -## Introduction to zkSync's Fee Structure +## Introduction to ZKsync's Fee Structure In Ethereum, computational and storage costs are quantified using gas, with specific gas costs for each operation, which may change during system [upgrades](https://blog.ethereum.org/2021/03/08/ethereum-berlin-upgrade-announcement). -However, zkSync and other Layer 2 solutions face challenges in adopting this model due to the necessity of publishing pubdata on Ethereum. +However, ZKsync and other Layer 2 solutions face challenges in adopting this model due to the necessity of publishing pubdata on Ethereum. As a result, the cost of L2 transactions is tied to the fluctuating gas prices on L1 and cannot be hardcoded. --- ## Gas Per Pubdata Limit -In zkSync, transaction costs are influenced by the volatile gas prices on L1, which are needed to publish pubdata, verify proofs, and more. -This is addressed in zkSync-specific EIP712 transactions which include a `gas_per_pubdata_limit` field, +In ZKsync, transaction costs are influenced by the volatile gas prices on L1, which are needed to publish pubdata, verify proofs, and more. +This is addressed in ZKsync-specific EIP712 transactions which include a `gas_per_pubdata_limit` field, indicating the maximum gas price the operator can charge users per byte of pubdata. For Ethereum transactions lacking this field, the operator is restrained from exceeding a predefined constant value. @@ -22,21 +22,21 @@ For Ethereum transactions lacking this field, the operator is restrained from ex The complexity of zero-knowledge proof operations differs significantly from standard CPU operations. For example, the `keccak256` operation, while optimized for CPU performance, -incurs higher costs in zero-knowledge systems due to its mathematical demands, leading to distinct pricing structures in zkSync compared to Ethereum. +incurs higher costs in zero-knowledge systems due to its mathematical demands, leading to distinct pricing structures in ZKsync compared to Ethereum. --- -## Intrinsic Costs in zkSync +## Intrinsic Costs in ZKsync Unlike Ethereum, which uses a base intrinsic transaction cost to cover updates to user balances, nonce, and signature verifications, -zkSync does not include these costs in its intrinsic transaction pricing. -This stems from zkSync's support for account abstraction, +ZKsync does not include these costs in its intrinsic transaction pricing. +This stems from ZKsync's support for account abstraction, allowing different account types to potentially lower transaction costs through optimizations or more zk-friendly signature schemes. -The costs in zkSync primarily cover the intrinsic zero-knowledge proving costs, which are measured through testing and hardcoded due to their complexity. +The costs in ZKsync primarily cover the intrinsic zero-knowledge proving costs, which are measured through testing and hardcoded due to their complexity. --- ## Understanding Batch Overhead -zkSync incurs operational costs for proving each batch, referred to as "batch overhead," which includes: +ZKsync incurs operational costs for proving each batch, referred to as "batch overhead," which includes: 1. **L2 Costs**: These are the costs in L2 gas required for proving circuits. 2. **L1 Costs**: These cover proof verification and general batch processing on L1. @@ -46,7 +46,7 @@ Several factors determine when a batch is sealed, such as time constraints for u the transaction slot capacity of the bootloader, memory usage from transaction encoding, and pubdata bytes limitations, which currently stand at 128kb per transaction due to node constraints. -In the case of zkSync batches, here are the resources the protocol watches to decide when a batch is sealed: +In the case of ZKsync batches, here are the resources the protocol watches to decide when a batch is sealed: 1. **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 @@ -60,7 +60,7 @@ In the case of zkSync batches, here are the resources the protocol watches to de 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 much of these resources it requires. @@ -71,7 +71,7 @@ transaction. --- ## Base Fee and Gas Limits -To safeguard against DDoS attacks, zkSync implements a `MAX_TRANSACTION_GAS_LIMIT`. +To safeguard against DDoS attacks, ZKsync implements a `MAX_TRANSACTION_GAS_LIMIT`. The `baseFee` reflects the real costs of computation for the proof, and the `gas_per_pubdata_limit` must be set sufficiently high to cover the fees for the required L1 gas per byte of pubdata. During periods of high L1 gas demand, adjustments to these limits ensure that transactions remain feasible without exceeding resource allocations. @@ -103,9 +103,9 @@ sure that the excess gas will be spent on the pubdata. --- ## Refunds -Another distinctive feature of the fee model used on zkSync is the availability of refunds. +Another distinctive feature of the fee model used on ZKsync is the availability of refunds. Refunds can be issued for unused limited system resources and 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. --- ## Formulas and constants for calculating fees @@ -139,7 +139,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/content/10.zk-stack/05.concepts/30.finality.md b/content/10.zk-stack/05.concepts/30.finality.md index a84f88fa..d8f67864 100644 --- a/content/10.zk-stack/05.concepts/30.finality.md +++ b/content/10.zk-stack/05.concepts/30.finality.md @@ -13,19 +13,19 @@ which translates to approximately 13 minutes under normal network conditions. This duration allows for sufficient block confirmations to prevent reversals and ensure that transactions are settled securely. --- -## Finality on zkSync Era +## Finality on ZKsync Era -zkSync Era, as a Layer 2 (L2) rollup, ties its finality and security mechanisms to those of the underlying Layer 1 (L1) Ethereum chain. -The steps involved in reaching finality in zkSync Era include: +ZKsync Era, as a Layer 2 (L2) rollup, ties its finality and security mechanisms to those of the underlying Layer 1 (L1) Ethereum chain. +The steps involved in reaching finality in ZKsync Era include: 1. **Batch Formation**: Transactions are collected and grouped into a batch. This step generally takes a few minutes. 2. **Batch Commitment**: The complete batch is committed to the Ethereum blockchain. 3. **Proof Generation**: A cryptographic proof that validates the entire batch is generated. This process typically takes about an hour. 4. **Proof Submission**: The generated proof is submitted to an Ethereum smart contract for verification. 5. **Batch Finalization**: The batch undergoes a final verification and is settled on Ethereum. - This step includes a delay of approximately 21 hours as a security measure during the alpha phase of zkSync Era. + This step includes a delay of approximately 21 hours as a security measure during the alpha phase of ZKsync Era. -Overall, the complete finality time for a transaction on zkSync Era is around 24 hours, aligning with the finality of the corresponding Ethereum block. +Overall, the complete finality time for a transaction on ZKsync Era is around 24 hours, aligning with the finality of the corresponding Ethereum block. ::callout{icon="i-heroicons-information-circle" color="blue"} Advancements in validity proof research are continuously being made, @@ -35,11 +35,11 @@ promising potential reductions in proof generation times and, consequently, fast --- ## Instant confirmations -While the full finality process on zkSync Era can take up to 24 hours, transactions are treated with instant confirmation for user convenience: +While the full finality process on ZKsync Era can take up to 24 hours, transactions are treated with instant confirmation for user convenience: - **Immediate Transaction Display**: Once submitted, transactions are quickly shown in the user interface and API as unconfirmed. - **Immediate Asset Usability**: Users can immediately utilize the transferred assets for further transactions, - which may even be included in the same zkSync Era batch. + which may even be included in the same ZKsync Era batch. This feature enables a seamless user experience, although more cautious users may opt to wait for the transaction to reach full finality diff --git a/content/10.zk-stack/05.concepts/40.system-upgrades.md b/content/10.zk-stack/05.concepts/40.system-upgrades.md index 9e758cc8..7d69db8d 100644 --- a/content/10.zk-stack/05.concepts/40.system-upgrades.md +++ b/content/10.zk-stack/05.concepts/40.system-upgrades.md @@ -1,11 +1,11 @@ --- title: System Upgrades -description: Explore the structured approach to system upgrades in zkSync Era, including the roles of different branches and the audit process to ensure security and reliability. +description: Explore the structured approach to system upgrades in ZKsync Era, including the roles of different branches and the audit process to ensure security and reliability. --- -The [system contracts](https://github.com/matter-labs/era-contracts) at zkSync Era are pivotal for the functionality and security of the platform. +The [system contracts](https://github.com/matter-labs/era-contracts) at ZKsync Era are pivotal for the functionality and security of the platform. To ensure that these contracts meet the highest standards of security and reliability, a rigorous update and audit process is followed. -Here's a detailed breakdown of the system upgrade process for zkSync Era. +Here's a detailed breakdown of the system upgrade process for ZKsync Era. --- ## Main branch @@ -13,7 +13,7 @@ Here's a detailed breakdown of the system upgrade process for zkSync Era. The `main` branch of the [system contracts repository](https://github.com/matter-labs/era-contracts/blob/main/README.md) serves as the production-ready codebase. It contains the latest, most stable version of the protocol that has passed through all required audits. -This branch represents the secure backbone of zkSync Era, ready for deployment. +This branch represents the secure backbone of ZKsync Era, ready for deployment. ## Development branch @@ -53,6 +53,6 @@ This strategy helps in keeping the `main` branch up-to-date with all non-critica --- ## Conclusion -The structured upgrade process at zkSync Era not only ensures that system contracts are robust and secure +The structured upgrade process at ZKsync Era not only ensures that system contracts are robust and secure but also maintains a clear pathway from development to deployment. -This process underscores zkSync Era's commitment to reliability, security, and continuous improvement in its blockchain solutions. +This process underscores ZKsync Era's commitment to reliability, security, and continuous improvement in its blockchain solutions. diff --git a/content/10.zk-stack/05.concepts/50.zk-chains.md b/content/10.zk-stack/05.concepts/50.zk-chains.md index cc592a8e..39206f66 100644 --- a/content/10.zk-stack/05.concepts/50.zk-chains.md +++ b/content/10.zk-stack/05.concepts/50.zk-chains.md @@ -248,7 +248,7 @@ zkPorter is detailed extensively in [this informative post](https://blog.matter- Key aspects include: - **Cost Efficiency**: Designed for users seeking lower transaction costs, potentially at the expense of higher security risks. -- **Guardian Networks**: Developers can utilize the zkSync main zkPorter implementation, +- **Guardian Networks**: Developers can utilize the ZKsync main zkPorter implementation, establish their own guardian network, or integrate external DA solutions like EigenDA. #### Validium @@ -296,5 +296,5 @@ ZK chains support various methods to enhance privacy: - **Validium Mode**: Naturally provides privacy as long as the data is kept confidential by the operator. - **Privacy Protocols**: Specialized L3 protocols like Aztec or Tornado can be integrated to provide user-level privacy - while benefiting from zkSync Era’s features like account abstraction. + while benefiting from ZKsync Era’s features like account abstraction. - **Self-hosted Rollups**: Represent a long-term solution for privacy and scalability, where users manage their data and confirm state transitions off-chain. diff --git a/content/10.zk-stack/05.concepts/60.data-availability/00.index.md b/content/10.zk-stack/05.concepts/60.data-availability/00.index.md index 27517619..807599b4 100644 --- a/content/10.zk-stack/05.concepts/60.data-availability/00.index.md +++ b/content/10.zk-stack/05.concepts/60.data-availability/00.index.md @@ -1,9 +1,9 @@ --- title: Overview -description: An in-depth look at how zkSync ensures data availability through state diffs and compresses data to optimize L1 submissions, plus tools for reconstructing L2 state from L1 public data. +description: An in-depth look at how ZKsync ensures data availability through state diffs and compresses data to optimize L1 submissions, plus tools for reconstructing L2 state from L1 public data. --- -Data availability is a cornerstone of zkSync's architecture, +Data availability is a cornerstone of ZKsync's architecture, ensuring that the entire Layer 2 (L2) state can be [reconstructed](https://github.com/matter-labs/zksync-era/blob/main/docs/specs/data_availability/reconstruction.md) from the data submitted to Ethereum's Layer 1 (L1). @@ -11,17 +11,17 @@ This process not only secures the network but also optimizes cost-efficiency thr ## State diffs: Optimizing storage slots -Instead of submitting detailed transaction data, zkSync focuses on posting **state diffs** to L1. -These diffs represent changes in the blockchain's state, enabling zkSync to efficiently manage how data is stored and referenced: +Instead of submitting detailed transaction data, ZKsync focuses on posting **state diffs** to L1. +These diffs represent changes in the blockchain's state, enabling ZKsync to efficiently manage how data is stored and referenced: - **Efficient Use of Storage Slots**: Changes to the same storage slots across multiple transactions can be grouped, reducing the amount of data that needs to be sent to L1 and thereby lowering gas costs. - **Compression Techniques**: All data sent to L1, including state diffs, is compressed to further reduce costs. - [Read more about zkSync's compression methods](https://github.com/matter-labs/zksync-era/blob/main/docs/specs/data_availability/compression.md). + [Read more about ZKsync's compression methods](https://github.com/matter-labs/zksync-era/blob/main/docs/specs/data_availability/compression.md). ## Additional data posted to L1 -In addition to state diffs, zkSync also posts other crucial information to ensure comprehensive data availability: +In addition to state diffs, ZKsync also posts other crucial information to ensure comprehensive data availability: - **L2 to L1 Logs and Messages**: These ensure that communications and events are recorded and accessible. - **Published Bytecodes**: The bytecodes of deployed smart contracts are made available, crucial for contract interaction and verification. @@ -38,11 +38,11 @@ allowing some storage slots to remain off-chain while critical data is posted to ## Recreating L2 State From L1 Pubdata -zkSync provides tools to validate and reconstruct the L2 state from data available on L1. Here's how this process is typically managed: +ZKsync provides tools to validate and reconstruct the L2 state from data available on L1. Here's how this process is typically managed: ## Basic Flow -1. First, we need to filter all of the transactions to the L1 zkSync contract for only the `commitBlocks` transactions +1. First, we need to filter all of the transactions to the L1 ZKsync contract for only the `commitBlocks` transactions where the proposed block has been referenced by a corresponding `executeBlocks` call (the reason for this is that a committed or even proven block can be reverted but an executed one cannot). diff --git a/content/10.zk-stack/05.concepts/99.account-abstraction.md b/content/10.zk-stack/05.concepts/99.account-abstraction.md index 89f04e02..1343d500 100644 --- a/content/10.zk-stack/05.concepts/99.account-abstraction.md +++ b/content/10.zk-stack/05.concepts/99.account-abstraction.md @@ -1,9 +1,9 @@ --- title: Account Abstraction -description: Explore the nuances of account abstraction in zkSync, including account versioning, nonce ordering, and the significance of returned magic values in transaction validation. +description: Explore the nuances of account abstraction in ZKsync, including account versioning, nonce ordering, and the significance of returned magic values in transaction validation. --- -Account abstraction (AA) is a pivotal feature in zkSync that allows for greater flexibility and +Account abstraction (AA) is a pivotal feature in ZKsync that allows for greater flexibility and functionality in how accounts operate and interact with transactions. For a comprehensive understanding, it is recommended to review @@ -11,7 +11,7 @@ the detailed [AA protocol documentation](/build/developer-reference/account-abst ### Account versioning -Account versioning in zkSync facilitates future updates and changes to the account abstraction protocol +Account versioning in ZKsync facilitates future updates and changes to the account abstraction protocol by allowing accounts to specify which version of the protocol they support. This capability ensures backward compatibility and supports evolutionary development without disrupting existing account functionalities. The versions supported currently are: @@ -23,7 +23,7 @@ Such accounts are passive and should not be used as the `from` field in a transa ### Nonce ordering Nonce ordering is a critical aspect that dictates how transactions from accounts are processed concerning their sequence. -Accounts in zkSync can choose between two types of nonce ordering: +Accounts in ZKsync can choose between two types of nonce ordering: - `Sequential`: Nonces must follow a strict sequential order similar to externally owned accounts (EOAs). This setting ensures that transactions are processed in a specific sequence, requiring transaction `X` to be processed before transaction `X+1`. @@ -35,7 +35,7 @@ However, they provide a framework for expected transaction handling. ### Returned magic value -Both accounts and paymasters in zkSync are required to return a specific magic value during transaction validation. +Both accounts and paymasters in ZKsync are required to return a specific magic value during transaction validation. This magic value is critical for ensuring the integrity and correctness of transactions on the mainnet: - **Validation Enforcement**: On the mainnet, the magic value is strictly enforced to confirm that transactions meet all protocol criteria before execution. diff --git a/content/10.zk-stack/05.concepts/99.l1_l2_communication.md b/content/10.zk-stack/05.concepts/99.l1_l2_communication.md index 69205f1a..e333be1e 100644 --- a/content/10.zk-stack/05.concepts/99.l1_l2_communication.md +++ b/content/10.zk-stack/05.concepts/99.l1_l2_communication.md @@ -94,7 +94,7 @@ that the L2 part of a deposit has failed and ask the bridge to release funds. ## L1→L2 Messaging -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. @@ -197,7 +197,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/content/10.zk-stack/10.components/10.index.md b/content/10.zk-stack/10.components/10.index.md index 5c307788..c7aacba2 100644 --- a/content/10.zk-stack/10.components/10.index.md +++ b/content/10.zk-stack/10.components/10.index.md @@ -1,10 +1,10 @@ --- title: Overview -description: Explore the ZK Stack, a flexible, open-source framework designed for creating sovereign ZK-powered Ethereum rollups, known as ZK chains, utilizing the foundational technology of zkSync Era. +description: Explore the ZK Stack, a flexible, open-source framework designed for creating sovereign ZK-powered Ethereum rollups, known as ZK chains, utilizing the foundational technology of ZKsync Era. --- The ZK Stack is a comprehensive framework aimed at revolutionizing the development of Ethereum rollups through its modular design and open-source nature. -Based on the pioneering work of zkSync Era, +Based on the pioneering work of ZKsync Era, the ZK Stack extends the core functionalities to enable developers to build custom ZK chains—Layer 2 (L2) and Layer 3 (L3) solutions—that are tailored to specific needs while ensuring compatibility and interoperability within the Ethereum ecosystem. diff --git a/content/10.zk-stack/10.components/20.smart-contracts/10.index.md b/content/10.zk-stack/10.components/20.smart-contracts/10.index.md index 221a4559..c893d958 100644 --- a/content/10.zk-stack/10.components/20.smart-contracts/10.index.md +++ b/content/10.zk-stack/10.components/20.smart-contracts/10.index.md @@ -240,8 +240,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. @@ -251,12 +251,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/content/10.zk-stack/10.components/20.smart-contracts/20.system-contracts.md b/content/10.zk-stack/10.components/20.smart-contracts/20.system-contracts.md index 5c3d8fff..506bdbad 100644 --- a/content/10.zk-stack/10.components/20.smart-contracts/20.system-contracts.md +++ b/content/10.zk-stack/10.components/20.smart-contracts/20.system-contracts.md @@ -46,7 +46,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 @@ -106,7 +106,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 @@ -138,7 +138,7 @@ Whenever anyone wants to do a non-zero value call, they need to call `MsgValueSi ## 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. @@ -160,9 +160,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 @@ -177,7 +177,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 @@ -188,7 +188,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. @@ -206,13 +206,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). @@ -236,7 +236,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. ### **Return value of the deployment methods** @@ -255,7 +255,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/content/10.zk-stack/10.components/40.sequencer-server.md b/content/10.zk-stack/10.components/40.sequencer-server.md index df296525..d609b2fd 100644 --- a/content/10.zk-stack/10.components/40.sequencer-server.md +++ b/content/10.zk-stack/10.components/40.sequencer-server.md @@ -1,17 +1,17 @@ --- title: Sequencer / Server -description: Overview of the zkSync Sequencer, detailing its components and functionalities for monitoring and maintaining L1 and L2 operations. +description: Overview of the ZKsync Sequencer, detailing its components and functionalities for monitoring and maintaining L1 and L2 operations. --- -The zkSync Sequencer is a complex system composed of several services and modules that work together to monitor Ethereum Layer 1 (L1), +The ZKsync Sequencer is a complex system composed of several services and modules that work together to monitor Ethereum Layer 1 (L1), maintain Layer 2 (L2) state, and manage the order of incoming transactions. -This system is critical for the operation and reliability of the zkSync protocol. +This system is critical for the operation and reliability of the ZKsync protocol. -For more detailed information about each module, visit the [zkSync Era GitHub repository](%%zk_git_repo_zksync-era%%). +For more detailed information about each module, visit the [ZKsync Era GitHub repository](%%zk_git_repo_zksync-era%%). ## RPC services -RPC Services serve as the primary user interface for interacting with the zkSync server. They include: +RPC Services serve as the primary user interface for interacting with the ZKsync server. They include: - **HttpApi**: This is the HTTP public Web3 API that allows users to make requests via traditional HTTP methods. @@ -34,7 +34,7 @@ The ETH Operator module interfaces directly with L1, performing critical observa ## Sequencer -The Sequencer module processes incoming transactions on zkSync, organizes them into blocks, +The Sequencer module processes incoming transactions on ZKsync, organizes them into blocks, and ensures they comply with the constraints of the proving system. It includes: diff --git a/content/10.zk-stack/10.components/50.zksync-evm/00.index.md b/content/10.zk-stack/10.components/50.zksync-evm/00.index.md index c5de01d3..a29ab9c3 100644 --- a/content/10.zk-stack/10.components/50.zksync-evm/00.index.md +++ b/content/10.zk-stack/10.components/50.zksync-evm/00.index.md @@ -1,45 +1,45 @@ --- title: Overview -description: Learn about the zkSync VM's functionality, its role in the zkStack compared to the EVM in Ethereum, and how it handles smart contracts and transaction fees. +description: Learn about the ZKsync VM's functionality, its role in the zkStack compared to the EVM in Ethereum, and how it handles smart contracts and transaction fees. --- -The zkSync VM (zero-knowledge Ethereum Virtual Machine) is an essential component of the ZK Stack, +The ZKsync VM (zero-knowledge Ethereum Virtual Machine) is an essential component of the ZK Stack, designed to execute transactions similarly to the Ethereum Virtual Machine (EVM) but with a unique set of functionalities tailored to the needs of rollups. -## zkSync VM and its role in ZK Stack +## ZKsync VM and its role in ZK Stack Unlike the EVM that operates Ethereum's smart contracts directly, -the zkSync VM is specifically engineered to efficiently run the State Transition Function (STF), +the ZKsync VM is specifically engineered to efficiently run the State Transition Function (STF), which is vital for producing proofs of correct execution in a rollup context. This STF is defined by the [Bootloader](/zk-stack/components/zksync-evm/bootloader), which implements and runs it. ### Execution of transactions -Transactions executed by the zkSync VM are primarily written in native zkSync VM bytecode, enabling straightforward execution. -In the future, the system will also accommodate EVM bytecode through an efficient interpreter built into the zkSync VM. +Transactions executed by the ZKsync VM are primarily written in native ZKsync VM bytecode, enabling straightforward execution. +In the future, the system will also accommodate EVM bytecode through an efficient interpreter built into the ZKsync VM. --- -## Special features of zkSync VM +## Special features of ZKsync VM -The zkSync VM incorporates several specialized features to meet the demands of rollups, including: +The ZKsync VM incorporates several specialized features to meet the demands of rollups, including: - **Storage and Gas Metering:** Adaptations in storage handling and gas metering to suit the rollup model. - **Precompiles and System Contracts:** - The zkSync VM supports predeployed contracts known as precompiles and system contracts. + The ZKsync VM supports predeployed contracts known as precompiles and system contracts. While both are integral, system contracts have special permissions and are mainly invoked by the Bootloader, not by user transactions. These system contracts are crucial for managing specialized operations and are outlined in more detail [here](/zk-stack/components/smart-contracts/system-contracts). --- ## User-facing features -To enhance user experience, the zkSync VM supports account abstraction, allowing users to customize how transaction fees are paid. +To enhance user experience, the ZKsync VM supports account abstraction, allowing users to customize how transaction fees are paid. This flexibility is part of the zkStack's efforts to improve usability and accessibility. --- ## Fee model -The zkSync VM's fee model differs significantly from Ethereum's due to the unique requirements of running a rollup. +The ZKsync VM's fee model differs significantly from Ethereum's due to the unique requirements of running a rollup. It considers the various costs associated with rollup operations, including: - **Data and Proof Execution Costs on L1:** diff --git a/content/10.zk-stack/10.components/50.zksync-evm/10.bootloader.md b/content/10.zk-stack/10.components/50.zksync-evm/10.bootloader.md index de9eab73..92ff9697 100644 --- a/content/10.zk-stack/10.components/50.zksync-evm/10.bootloader.md +++ b/content/10.zk-stack/10.components/50.zksync-evm/10.bootloader.md @@ -1,21 +1,21 @@ --- title: Bootloader -description: Overview of the bootloader in zkSync, which processes transactions in batch mode for efficiency, including its role and operational mechanics. +description: Overview of the bootloader in ZKsync, which processes transactions in batch mode for efficiency, including its role and operational mechanics. --- In standard Ethereum clients, the process of executing blocks involves selecting and validating transactions one by one, executing them, and then applying the resulting state changes to the blockchain. This method is suitable for Ethereum's architecture but would be inefficient -for zkSync due to the need for running a complete proving workflow for each transaction. +for ZKsync due to the need for running a complete proving workflow for each transaction. -### Why zkSync Uses a Bootloader +### Why ZKsync Uses a Bootloader -To address this inefficiency, zkSync employs a bootloader. +To address this inefficiency, ZKsync employs a bootloader. This component allows for processing not just one transaction at a time but an entire batch of transactions as a single large operation. This approach is similar to how an EntryPoint works under EIP4337, which also manages transactions in arrays to support the Account Abstraction protocol. -You can learn more about [Batches & L2 blocks on zkSync](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/Smart%20contract%20Section/Batches%20%26%20L2%20blocks%20on%20zkSync.md). +You can learn more about [Batches & L2 blocks on ZKsync](https://github.com/code-423n4/2023-10-zksync/blob/main/docs/Smart%20contract%20Section/Batches%20%26%20L2%20blocks%20on%20zkSync.md). ### Operational Mechanism of the Bootloader @@ -66,12 +66,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. @@ -253,7 +253,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 @@ -332,7 +332,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/content/10.zk-stack/10.components/50.zksync-evm/20.precompiles.md b/content/10.zk-stack/10.components/50.zksync-evm/20.precompiles.md index 0797d7c3..98ed5661 100644 --- a/content/10.zk-stack/10.components/50.zksync-evm/20.precompiles.md +++ b/content/10.zk-stack/10.components/50.zksync-evm/20.precompiles.md @@ -51,7 +51,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/content/10.zk-stack/10.components/50.zksync-evm/30.vm-specification/10.index.md b/content/10.zk-stack/10.components/50.zksync-evm/30.vm-specification/10.index.md index fd535612..03901846 100644 --- a/content/10.zk-stack/10.components/50.zksync-evm/30.vm-specification/10.index.md +++ b/content/10.zk-stack/10.components/50.zksync-evm/30.vm-specification/10.index.md @@ -1,5 +1,5 @@ --- -title: zkSync Virtual Machine primer +title: ZKsync Virtual Machine primer description: --- diff --git a/content/10.zk-stack/10.components/50.zksync-evm/30.vm-specification/20.formal-spec.md b/content/10.zk-stack/10.components/50.zksync-evm/30.vm-specification/20.formal-spec.md index ea8528be..18904e3b 100644 --- a/content/10.zk-stack/10.components/50.zksync-evm/30.vm-specification/20.formal-spec.md +++ b/content/10.zk-stack/10.components/50.zksync-evm/30.vm-specification/20.formal-spec.md @@ -3,7 +3,7 @@ title: VM Formal Specification description: --- -This is the specification of the instruction set of EraVM 1.4.0, a language virtual machine for zkSync Era. +This is the specification of the instruction set of EraVM 1.4.0, a language virtual machine for ZKsync Era. It describes the virtual machine's architecture, instruction syntax and semantics, and some elements of system protocol. [See the Formal Specification here.](https://matter-labs.github.io/eravm-spec/spec.html) diff --git a/content/10.zk-stack/10.components/50.zksync-evm/_dir.yml b/content/10.zk-stack/10.components/50.zksync-evm/_dir.yml index 179d2b70..3ee34e92 100644 --- a/content/10.zk-stack/10.components/50.zksync-evm/_dir.yml +++ b/content/10.zk-stack/10.components/50.zksync-evm/_dir.yml @@ -1 +1 @@ -title: zkSync EVM +title: ZKsync EVM diff --git a/content/10.zk-stack/10.components/60.prover/10.index.md b/content/10.zk-stack/10.components/60.prover/10.index.md index 7a65a7e5..88306cd3 100644 --- a/content/10.zk-stack/10.components/60.prover/10.index.md +++ b/content/10.zk-stack/10.components/60.prover/10.index.md @@ -1,21 +1,21 @@ --- title: Overview -description: Exploring the prover in zkSync, a ZK rollup technology, which ensures secure and efficient transaction verification through cryptographic proofs. +description: Exploring the prover in ZKsync, a ZK rollup technology, which ensures secure and efficient transaction verification through cryptographic proofs. --- -zkSync utilizes Zero-Knowledge (ZK) proofs to ensure secure and efficient transaction processing on the Ethereum blockchain. +ZKsync utilizes Zero-Knowledge (ZK) proofs to ensure secure and efficient transaction processing on the Ethereum blockchain. This technology compresses transactions, significantly reducing fees for users while maintaining the robust security standards of Ethereum. -### How zkSync Utilizes ZK Proofs +### How ZKsync Utilizes ZK Proofs Zero-Knowledge proofs enable a verifier to confirm that a prover has correctly executed a computation without revealing the specifics of the transaction. This approach ensures both privacy and data security. -In zkSync, the prover is responsible for demonstrating the correct execution of zkSync’s Ethereum Virtual Machine (EVM), +In ZKsync, the prover is responsible for demonstrating the correct execution of ZKsync’s Ethereum Virtual Machine (EVM), and this proof is then verified by a smart contract on Ethereum. ### The Proving Process -The proving process in zkSync involves several crucial steps: +The proving process in ZKsync involves several crucial steps: 1. **Witness Generation**: This is the initial phase where, upon transaction initiation by a user, a witness is generated. @@ -28,7 +28,7 @@ The proving process in zkSync involves several crucial steps: 3. **Proof System**: The ZK circuit requires a robust proof system for processing. - In zkSync, this system is called Boojum. It comprises several components: + In ZKsync, this system is called Boojum. It comprises several components: - **Boojum**: This repository acts as a toolkit containing essential tools for proving and verifying circuit functionality, along with backend components necessary for circuit construction. @@ -38,7 +38,7 @@ The proving process in zkSync involves several crucial steps: Serving as the testing ground, this repository contains various tests to ensure the circuits function correctly and includes code essential for running these circuits. -### Understanding Circuits in zkSync +### Understanding Circuits in ZKsync A ZK circuit functions similarly to an arithmetic circuit, where inputs at the bottom pass through various computational steps, @@ -50,9 +50,9 @@ In Zero-Knowledge terminology, an underconstrained circuit may result in a sound ![Arithmetic Circuit Diagram](/images/zk-stack/circuit.png){class="bg-white m-auto"} -### What zkSync’s Circuits Prove +### What ZKsync’s Circuits Prove -The primary purpose of zkSync's circuits is to ensure the correct execution of the VM, covering every opcode, +The primary purpose of ZKsync's circuits is to ensure the correct execution of the VM, covering every opcode, storage interaction, and the integration of precompiled contracts. These elements are crucial for the holistic functioning and security of the system. This is described in more detail in @@ -60,11 +60,11 @@ This is described in more detail in ### Additional Resources -For those interested in a deeper dive into the technology behind zkSync's proof system, +For those interested in a deeper dive into the technology behind ZKsync's proof system, resources like Vitalik Buterin's blog on [Plonk](https://vitalik.eth.limo/general/2019/09/22/plonk.html) and the [Plonky2](https://github.com/mir-protocol/plonky2/blob/main/plonky2/plonky2.pdf) paper provide extensive information on the arithmetization process. More comprehensive details can also be found in the [Redshift Paper](https://eprint.iacr.org/2019/1400.pdf). -Through these sophisticated cryptographic processes, zkSync's prover efficiently secures and verifies transactions, +Through these sophisticated cryptographic processes, ZKsync's prover efficiently secures and verifies transactions, leveraging the power of ZK proofs to enhance blockchain scalability and security. diff --git a/content/10.zk-stack/10.components/60.prover/20.zk-terminology.md b/content/10.zk-stack/10.components/60.prover/20.zk-terminology.md index 999f37d2..81bfe589 100644 --- a/content/10.zk-stack/10.components/60.prover/20.zk-terminology.md +++ b/content/10.zk-stack/10.components/60.prover/20.zk-terminology.md @@ -1,6 +1,6 @@ --- title: ZK Terminology -description: This article provides definitions for key terms used in zkSync's zero-knowledge proof systems. +description: This article provides definitions for key terms used in ZKsync's zero-knowledge proof systems. --- ## Arithmetization @@ -18,11 +18,11 @@ An arithmetic circuit is a cryptographic tool that encodes computational problem ## Constraint -A constraint is a rule that certain operations must follow to maintain validity and support proof generation in zkSync. +A constraint is a rule that certain operations must follow to maintain validity and support proof generation in ZKsync. ## Constraint degree -Constraint degree refers to the highest polynomial degree present in the gates of a constraint system, with zkSync allowing up to a degree of eight. +Constraint degree refers to the highest polynomial degree present in the gates of a constraint system, with ZKsync allowing up to a degree of eight. ## Constraint system @@ -31,12 +31,12 @@ It is satisfied when specific values assigned to its variables make all equation ## Geometry -In zkSync's PLONK arithmetization, geometry refers to the arrangement of witness data in a grid format across defined rows and columns. -Each row defines a gate (or a few gates), and the columns are as long as needed to hold all of the witness data. zkSync uses ~164 base witness columns. +In ZKsync's PLONK arithmetization, geometry refers to the arrangement of witness data in a grid format across defined rows and columns. +Each row defines a gate (or a few gates), and the columns are as long as needed to hold all of the witness data. ZKsync uses ~164 base witness columns. ## Log -A log in zkSync is similar to a database log, recording a list of changes within the system. +A log in ZKsync is similar to a database log, recording a list of changes within the system. ## Lookup table @@ -49,7 +49,7 @@ A proof can either indicate the entire proving process or specifically refer to ## Prover -In zkSync, a prover processes transactions by computing proofs that validate state transitions, which are then verified by a smart contract on Ethereum. +In ZKsync, a prover processes transactions by computing proofs that validate state transitions, which are then verified by a smart contract on Ethereum. ## Satisfiable @@ -73,5 +73,5 @@ A witness is the confidential input in a cryptographic circuit, representing the ## Worker -A worker in zkSync is part of a multi-threaded proving system that allows for parallel execution of certain cryptographic computations, +A worker in ZKsync is part of a multi-threaded proving system that allows for parallel execution of certain cryptographic computations, such as polynomial addition. diff --git a/content/10.zk-stack/10.components/70.compiler/10.toolchain/10.index.md b/content/10.zk-stack/10.components/70.compiler/10.toolchain/10.index.md index 6dda6359..f97b311d 100644 --- a/content/10.zk-stack/10.components/70.compiler/10.toolchain/10.index.md +++ b/content/10.zk-stack/10.components/70.compiler/10.toolchain/10.index.md @@ -38,7 +38,7 @@ We are using two high-level source code compilers at the time of writing: **Security and best practices:**
Follow the [security considerations and best practices](/build/developer-reference/best-practices#security-and-best-practices) -to build smart contracts on zkSync Era. +to build smart contracts on ZKsync Era. :: ## IR Compilers @@ -72,13 +72,13 @@ easier to maintain outside of the framework. We recommend using our IR compilers via [their corresponding Hardhat plugins](/build/tooling/hardhat/getting-started). Add these plugins to the Hardhat's config file to compile new projects or migrate -existing ones to zkSync Era. For a lower-level approach, download our compiler binaries via the +existing ones to ZKsync Era. For a lower-level approach, download our compiler binaries via the links above and use their CLI interfaces. ### Installing and configuring plugins Add the plugins below to the Hardhat's config file to compile new projects or migrate -existing ones to zkSync Era. For a lower-level approach, download our compiler binaries +existing ones to ZKsync Era. For a lower-level approach, download our compiler binaries [links above](#ir-compilers) and use their CLI interfaces. - [hardhat-zksync-solc documentation](/build/tooling/hardhat/hardhat-zksync-solc) diff --git a/content/10.zk-stack/10.components/70.compiler/10.toolchain/20.solidity.md b/content/10.zk-stack/10.components/70.compiler/10.toolchain/20.solidity.md index 0ef59ced..75bf4552 100644 --- a/content/10.zk-stack/10.components/70.compiler/10.toolchain/20.solidity.md +++ b/content/10.zk-stack/10.components/70.compiler/10.toolchain/20.solidity.md @@ -105,7 +105,7 @@ sufficient level of abstraction over EVM. Projects written in Solidity `>=0.8` are compiled by default through the Yul pipeline, whereas those written in `<=0.7` are compiled via EVM legacy assembly which is a less friendly IR due to its obfuscation of control-flow and call graphs. -Due to this obfuscation, there are several limitations in zkSync for contracts written in Solidity `<=0.7`: +Due to this obfuscation, there are several limitations in ZKsync for contracts written in Solidity `<=0.7`: 1. Recursion on the stack is not supported. 2. Internal function pointers are not supported. @@ -113,7 +113,7 @@ Due to this obfuscation, there are several limitations in zkSync for contracts w ## Using libraries -The usage of libraries in Solidity is supported in zkSync Era with the following considerations: +The usage of libraries in Solidity is supported in ZKsync Era with the following considerations: - If a Solidity library can be inlined (i.e. it only contains `private` or `internal` methods), it can be used without any additional configuration. diff --git a/content/10.zk-stack/10.components/70.compiler/20.specification/10.index.md b/content/10.zk-stack/10.components/70.compiler/20.specification/10.index.md index 04ca1384..17e3a13f 100644 --- a/content/10.zk-stack/10.components/70.compiler/20.specification/10.index.md +++ b/content/10.zk-stack/10.components/70.compiler/20.specification/10.index.md @@ -15,7 +15,7 @@ please visit [Toolchain](/zk-stack/components/compiler/toolchain) to understand | 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. | | [EraVM specification](%%zk_git_repo_eravm-spec%%/spec.html) | A combination of a human readable documentation and a formal description of EraVM, including its structure and operation, instruction syntax, semantic, and encoding. | | 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. | @@ -25,11 +25,11 @@ please visit [Toolchain](/zk-stack/components/compiler/toolchain) to understand | EraVM bytecode | The smart contract bytecode, executed by EraVM. | | Stack | The segment of the non-persistent contract memory. Consists of two parts: global data and function stack frame. | | 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 diff --git a/content/10.zk-stack/10.components/70.compiler/20.specification/30.system-contracts.md b/content/10.zk-stack/10.components/70.compiler/20.specification/30.system-contracts.md index 7faee90a..51200d3d 100644 --- a/content/10.zk-stack/10.components/70.compiler/20.specification/30.system-contracts.md +++ b/content/10.zk-stack/10.components/70.compiler/20.specification/30.system-contracts.md @@ -8,7 +8,7 @@ Many EVM instructions require special handling by the System Contracts. Among th handling, see [the EVM instructions reference](/zk-stack/components/compiler/specification/instructions/evm). -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). @@ -47,7 +47,7 @@ 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](%%zk_git_repo_era-compiler-llvm-context%%/blob/main/src/eravm/context/function/llvm_runtime.rs). @@ -57,7 +57,7 @@ For reference, see See [handling CREATE](/build/developer-reference/ethereum-differences/evm-instructions#create-create2) and [dependency code substitution instructions](/build/developer-reference/ethereum-differences/evm-instructions#datasize-dataoffset-datacopy) -on zkSync Era documentation. +on ZKsync Era documentation. For reference, see LLVM IR codegen for [the deployer call](%%zk_git_repo_era-compiler-llvm-context%%/blob/main/src/eravm/context/function/runtime/deployer_call.rs) @@ -95,7 +95,7 @@ For reference, see [the LLVM IR codegen source code](%%zk_git_repo_era-compiler- ### Simulator of Immutables See [handling immutables](/build/developer-reference/ethereum-differences/evm-instructions#setimmutable-loadimmutable) -on zkSync Era documentation. +on ZKsync Era documentation. For reference, see LLVM IR codegen for [instructions for immutables](%%zk_git_repo_era-compiler-llvm-context%%/blob/main/src/eravm/evm/immutable.rs) diff --git a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/10.index.md b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/10.index.md index 55298158..07fd802d 100644 --- a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/10.index.md +++ b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/10.index.md @@ -27,7 +27,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. @@ -42,7 +42,7 @@ The reference of such extensions is coming soon. ### 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. The reference of such extensions is coming soon. diff --git a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/10.index.md b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/10.index.md index ca87f8d4..841e85a3 100644 --- a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/10.index.md +++ b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/10.index.md @@ -21,9 +21,9 @@ Such instructions are grouped into the following categories according to [the or - [Create](evm/create) - [Return](evm/return) -### zkSync VM Assembly +### ZKsync VM Assembly Assembly emitted for LLVM standard library functions depends on available optimizations which differ between versions. If there is no assembly example under an instruction, compile a reproducing contract with the latest version of `zksolc`. -zkSync VM specification contains a list of [all zkSync VM instructions (see the table of contents)](%%zk_git_repo_eravm-spec%%/spec.html). +ZKsync VM specification contains a list of [all ZKsync VM instructions (see the table of contents)](%%zk_git_repo_eravm-spec%%/spec.html). diff --git a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/calls.md b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/calls.md index ab1eed5e..06fc95e9 100644 --- a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/calls.md +++ b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/calls.md @@ -8,7 +8,7 @@ All EVM call instructions are handled similarly. The call type is encoded on the assembly level, so we will describe the common handling workflow, mentioning distinctions if there are any. For more information, see the -[zkSync Era documentation](/build/developer-reference/ethereum-differences/evm-instructions). +[ZKsync Era documentation](/build/developer-reference/ethereum-differences/evm-instructions). ## CALL diff --git a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/create.md b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/create.md index 2fb65181..0901db3a 100644 --- a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/create.md +++ b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/create.md @@ -5,7 +5,7 @@ description: The EVM CREATE instructions are handled similarly. -For more information, see the [zkSync Era documentation](/build/developer-reference/ethereum-differences/evm-instructions#create-create2). +For more information, see the [ZKsync Era documentation](/build/developer-reference/ethereum-differences/evm-instructions#create-create2). ## CREATE diff --git a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/return.md b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/return.md index 464ae579..5bedd6de 100644 --- a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/return.md +++ b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/return.md @@ -20,7 +20,7 @@ is common for Yul and EVMLA representations. Original [EVM](https://www.evm.codes/#f3?fork=shanghai) instruction. -This instruction works differently in deploy code. For more information, see [the zkSync Era documentation](/build/developer-reference/ethereum-differences/evm-instructions#return-stop). +This instruction works differently in deploy code. For more information, see [the ZKsync Era documentation](/build/developer-reference/ethereum-differences/evm-instructions#return-stop). ### LLVM IR diff --git a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/30.evmla.md b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/30.evmla.md index a65b048b..6726a6ed 100644 --- a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/30.evmla.md +++ b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/30.evmla.md @@ -3,7 +3,7 @@ title: EVM Legacy Assembly description: --- -These instructions do not have a direct representation in EVM or zkSync VM. Instead, they perform auxiliary operations +These instructions do not have a direct representation in EVM or ZKsync VM. Instead, they perform auxiliary operations required for generating the target bytecode. ## PUSH [$] @@ -68,7 +68,7 @@ Returns the address the contract is deployed to. Can be only found in deploy code. On EVM, returns the total size of the runtime code and constructor arguments. -On zkSync VM, it is always 0, since zkSync VM does not operate on runtime code in deploy code. +On ZKsync VM, it is always 0, since ZKsync VM does not operate on runtime code in deploy code. [The LLVM IR generator code](%%zk_git_repo_era-compiler-solidity%%/blob/main/src/yul/parser/statement/expression/function_call/mod.rs#L907). diff --git a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/40.yul.md b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/40.yul.md index c84e951c..471febfa 100644 --- a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/40.yul.md +++ b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/40.yul.md @@ -3,14 +3,14 @@ title: Yul description: --- -These instructions do not have a direct representation in EVM or zkSync VM. Instead, they perform auxiliary operations +These instructions do not have a direct representation in EVM or ZKsync VM. Instead, they perform auxiliary operations required for generating the target bytecode. ## datasize Original [Yul](https://docs.soliditylang.org/en/latest/yul.html#datasize-dataoffset-datacopy) auxiliary instruction. -Unlike on EVM, on zkSync VM target this instruction returns the size of the header part of the calldata sent to the +Unlike on EVM, on ZKsync VM target this instruction returns the size of the header part of the calldata sent to the [ContractDeployer](/zk-stack/components/compiler/specification/system-contracts#contract-deployer). For more information, see [CREATE](/zk-stack/components/compiler/specification/instructions/evm/create). @@ -23,7 +23,7 @@ LLVM IR codegen references: Original [Yul](https://docs.soliditylang.org/en/latest/yul.html#datasize-dataoffset-datacopy) auxiliary instruction. -Unlike on EVM, on zkSync VM target this instruction has nothing to do with the offset. Instead, it returns the bytecode hash +Unlike on EVM, on ZKsync VM target this instruction has nothing to do with the offset. Instead, it returns the bytecode hash of the contract referenced by the Yul object identifier. Since our compiler translates instructions without analyzing the surrounding context, it is not possible to get the bytecode hash from anywhere else in [datacopy](#datacopy). For more information, see [CREATE](/zk-stack/components/compiler/specification/instructions/evm/create). @@ -37,7 +37,7 @@ LLVM IR codegen references: Original [Yul](https://docs.soliditylang.org/en/latest/yul.html#datasize-dataoffset-datacopy) auxiliary instruction. -Unlike on EVM, on zkSync VM target this instruction copies the bytecode hash passed as [dataoffset](#dataoffset) to the +Unlike on EVM, on ZKsync VM target this instruction copies the bytecode hash passed as [dataoffset](#dataoffset) to the destination. For more information, see [CREATE](/zk-stack/components/compiler/specification/instructions/evm/create). [The LLVM IR generator code](%%zk_git_repo_era-compiler-solidity%%/blob/main/src/yul/parser/statement/expression/function_call/mod.rs#L938). @@ -97,8 +97,8 @@ Is a Yul optimizer hint which is not used by our compiler. Instead, its only arg Original [Yul](https://docs.soliditylang.org/en/latest/yul.html#verbatim) auxiliary instruction. -Unlike on EVM, on zkSync VM target this instruction has nothing to do with inserting of EVM bytecode. Instead, it is used to implement -[zkSync VM Yul Extensions](/zk-stack/components/compiler/specification/instructions#yul-extensions) available in the system mode. +Unlike on EVM, on ZKsync VM target this instruction has nothing to do with inserting of EVM bytecode. Instead, it is used to implement +[ZKsync VM Yul Extensions](/zk-stack/components/compiler/specification/instructions#yul-extensions) available in the system mode. In order to compile a Yul contract with extensions, both Yul and system mode must be enabled (`zksolc --yul --system-mode ...`). [The LLVM IR generator code](%%zk_git_repo_era-compiler-solidity%%/blob/main/src/yul/parser/statement/expression/function_call/verbatim.rs). diff --git a/content/10.zk-stack/20.running-a-zk-chain/10.locally.md b/content/10.zk-stack/20.running-a-zk-chain/10.locally.md index 399613a9..8d4d3868 100644 --- a/content/10.zk-stack/20.running-a-zk-chain/10.locally.md +++ b/content/10.zk-stack/20.running-a-zk-chain/10.locally.md @@ -51,7 +51,7 @@ to set up dependencies on your machine (don't worry about the Environment sectio ::callout{icon="i-heroicons-exclamation-triangle" color="amber"} The commands above are not just running docker containers, but are actually building the code from the repo to spin up your ZK chain. For this reason the process might take some time. -If you just want to run docker containers to play around with a zkSync chain, you can use `zksync-cli dev`. +If you just want to run docker containers to play around with a ZKsync chain, you can use `zksync-cli dev`. Learn more [here](/build/tooling/zksync-cli). :: @@ -103,7 +103,7 @@ Learn more about it [here](/build/api-reference). ### Using zksync-cli -zkSync CLI allows you to easily interact and develop applications on your ZK chain. +ZKsync CLI allows you to easily interact and develop applications on your ZK chain. When executing any command with zksync-cli, you can specify RPC urls for both L1 and L2. Your local server contains RPCs for both. An example deposit command via the bridge would look like: diff --git a/content/10.zk-stack/20.running-a-zk-chain/99.dependencies.md b/content/10.zk-stack/20.running-a-zk-chain/99.dependencies.md index 7bdb5197..b0152449 100644 --- a/content/10.zk-stack/20.running-a-zk-chain/99.dependencies.md +++ b/content/10.zk-stack/20.running-a-zk-chain/99.dependencies.md @@ -33,7 +33,7 @@ sudo systemctl start docker ## 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. @@ -41,7 +41,7 @@ Additionally, if you are going to use WSL 2, make sure that your project is loca accessing NTFS partitions from inside of 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/content/20.zksync-node/00.index.md b/content/20.zksync-node/00.index.md index 8e68b61f..2345045e 100644 --- a/content/20.zksync-node/00.index.md +++ b/content/20.zksync-node/00.index.md @@ -7,54 +7,54 @@ description: For local testing, we recommend setting up an in-memory node and forking mainnet. :: -This documentation explains the basics of the zkSync Era Node. +This documentation explains the basics of the ZKsync Era Node. ## Disclaimers -- The zkSync node software is provided "as-is" without any express or implied warranties. -- The zkSync node is in the beta phase, and should be used with caution. -- The zkSync node is a read-only replica of the main node. -- The zkSync node is not going to be the consensus node. +- The ZKsync node software is provided "as-is" without any express or implied warranties. +- The ZKsync node is in the beta phase, and should be used with caution. +- The ZKsync node is a read-only replica of the main node. +- The ZKsync node is not going to be the consensus node. - Running a sequencer node is currently not possible and there is no option to vote on blocks as part of the consensus mechanism or [fork-choice](https://eth2book.info/capella/part3/forkchoice/#whats-a-fork-choice) like on Ethereum. -## 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 anyone. 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 +The ZKsync node is a read-replica of the main (centralized) node that can be run by anyone. 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. -In Ethereum terms, the current state of the zkSync node represents an archive node, providing access to the entire history of the blockchain. +In Ethereum terms, the current state of the ZKsync node represents an archive node, providing access to the entire history of the blockchain. ## 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 zkSync node, you are able to: +With the ZKsync node, 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). -With the zkSync node, you _can not_: +With the ZKsync node, you _can not_: - Create L2 blocks or L1 batches on your own. - Generate proofs. - Submit data to L1. -A more detailed overview of the zkSync node's components is provided in the components section. +A more detailed overview of the ZKsync node's components is provided in the components section. ## API Overview -API exposed by the zkSync node strives to be Web3-compliant. +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](https://zksync.io/contact) such cases. @@ -158,5 +158,5 @@ Always refer to the documentation linked above and [API reference documentation] ### `en` namespace -This namespace contains methods that zkSync nodes call on the main node while syncing. If this namespace is enabled -other zkSync nodes can sync from this node. +This namespace contains methods that ZKsync nodes call on the main node while syncing. If this namespace is enabled +other ZKsync nodes can sync from this node. diff --git a/content/20.zksync-node/05.quickstart.md b/content/20.zksync-node/05.quickstart.md index da82feaf..2969bef9 100644 --- a/content/20.zksync-node/05.quickstart.md +++ b/content/20.zksync-node/05.quickstart.md @@ -1,5 +1,5 @@ --- -title: Quick Start Guide for zkSync Node +title: Quick Start Guide for ZKsync Node description: --- @@ -11,14 +11,14 @@ description: ## Setup Instructions -1. Clone the zkSync Era repository and navigate to the zkSync node guide: +1. Clone the ZKsync Era repository and navigate to the ZKsync node guide: ```bash git clone https://github.com/matter-labs/zksync-era.git cd zksync-era/docs/guides/external-node ``` -## Running a zkSync Node Locally +## Running a ZKsync Node Locally ### Starting the Node @@ -67,7 +67,7 @@ Access the local Grafana dashboard to see the node status after recovery: - **Initial Recovery:** The node will recover from a snapshot on its first run, which may take up to 10 hours. During this period, the API server will not serve any requests. - **Historical Data:** For access to historical transaction data, consider recovery from DB dumps. Refer to the Advanced Setup section for more details. -- **DB Dump:** For nodes that operate from a DB dump, which allows starting a zkSync node with a full historical +- **DB Dump:** For nodes that operate from a DB dump, which allows starting a ZKsync node with a full historical transactions history, refer to the documentation on running from DB dumps at [03_running.md](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/03_running.md). ## System Requirements diff --git a/content/20.zksync-node/10.component-breakdown.md b/content/20.zksync-node/10.component-breakdown.md index 0b0cef51..6c096982 100644 --- a/content/20.zksync-node/10.component-breakdown.md +++ b/content/20.zksync-node/10.component-breakdown.md @@ -1,35 +1,35 @@ --- -title: zkSync Node Components +title: ZKsync Node Components description: --- -This section contains an overview of the zkSync node's main components. +This section contains an overview of the ZKsync node's main components. ## API -The zkSync node can serve both the HTTP and the WS Web3 API, as well as PubSub. +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, +- 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. + 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. +Even if the main node is temporarily unavailable, the 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. +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 main node +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. @@ -39,34 +39,34 @@ 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 the queue populated by the Fetcher and seals the corresponding blocks/batches +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 any zkSync node. +The actual execution of batches takes place within the VM, which is identical in any ZKsync node. ## 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](/zk-stack/concepts/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, +Prior to batch 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. +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, the zkSync node resumes normal operation. +Upon restart, the ZKsync node resumes normal operation. ## Consistency Checker -The main node API serves as the primary source of information for the zkSync node. +The main node API serves as the primary source of information for the ZKsync node. However, relying solely on the API may not provide sufficient security since the API data could potentially be incorrect due to various reasons. The primary source of truth for the rollup system is the L1 smart contract. Therefore, to enhance the security of the EN, each L1 batch undergoes cross-checking against @@ -78,11 +78,11 @@ The block commitment contains crucial data such as the state root and batch numb 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 crash loop until the issue is resolved. +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 initialized yet). +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/content/20.zksync-node/20.configuration.md b/content/20.zksync-node/20.configuration.md index b1fe6a9a..ce3c3954 100644 --- a/content/20.zksync-node/20.configuration.md +++ b/content/20.zksync-node/20.configuration.md @@ -3,16 +3,16 @@ title: Configuration description: --- -This document outlines various configuration options for the zkSync node. 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 ZKsync node. 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 and testnet. You can use these files as a starting point and modify only the necessary sections. ## 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 zkSync node, so all the API requests fetch the state from there. The +PostgreSQL serves as the main source of truth in the ZKsync node, 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 size of the connection pool. @@ -22,11 +22,11 @@ recommended to use an NVME SSD for RocksDB. RocksDB requires two variables to be ## L1 Web3 client -The zkSync node requires a connection to an Ethereum node. The corresponding env variable is `EN_ETH_CLIENT_URL`. Make sure to set +The 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 quickly, so make sure +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 @@ -38,7 +38,7 @@ The dockerized version of the server exposes the following ports: - Prometheus listener: `3322` - Healthcheck server: `3081` -While the configuration variables for them exist, you are not expected to change them unless you want to use the zkSync node +While the configuration variables for them exist, you are not expected to change them unless you want to use the ZKsync node outside of provided docker environment (not supported at the time of writing). ::callout{icon="i-heroicons-information-circle" color="blue"} **NOTE**: if the Prometheus port is configured, it must be [scraped](https://prometheus.io/docs/introduction/overview/) @@ -51,12 +51,12 @@ If you are not intending to use the metrics, leave this port not configured, and 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 +`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. @@ -65,7 +65,7 @@ the `debug` namespace are enabled. `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 about the +`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/content/20.zksync-node/30.running-node.md b/content/20.zksync-node/30.running-node.md index 7e941f85..2f0fbc69 100644 --- a/content/20.zksync-node/30.running-node.md +++ b/content/20.zksync-node/30.running-node.md @@ -12,9 +12,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) @@ -38,9 +38,9 @@ Setting up Postgres is out of the scope of these docs, but the popular choice is 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 Postgres 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 make it work, +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). +the ZKsync node configuration (official docs). Besides running Postgres, you are expected to have a DB dump from a corresponding env. You can restore it using `pg_restore -O -C --dbname=`. @@ -49,7 +49,7 @@ Steps how to connect from a Docker container to a service on the host can be fou ## Running -Assuming you have the zkSync node Docker image, an env file with the prepared configuration, and you have restored your DB with +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: @@ -67,14 +67,14 @@ 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 zkSync node +- Stop the ZKsync node - Remove SK cache (corresponding to `EN_STATE_CACHE_PATH`) - Remove your current DB - Restore with the new dump -- Start the zkSync node +- Start the ZKsync node Monitoring the node behavior and analyzing the state it's in is covered in the observability section. diff --git a/content/20.zksync-node/40.api-overview.md b/content/20.zksync-node/40.api-overview.md index b9a4d695..144fe92a 100644 --- a/content/20.zksync-node/40.api-overview.md +++ b/content/20.zksync-node/40.api-overview.md @@ -4,7 +4,7 @@ description: --- ::callout{icon="i-heroicons-information-circle" color="blue"} -The API exposed by the zkSync node is designed to be Web3-compliant. +The API exposed by the ZKsync node is designed to be Web3-compliant. Any deviation from the Ethereum behavior is likely unintended, and we encourage users to report such discrepancies. :: @@ -40,7 +40,7 @@ Data getters in this namespace operate in the L2 domain. They deal with L2 block | `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 | @@ -113,4 +113,4 @@ Only the methods documented are deemed public. Other methods in this namespace, ### `en` Namespace -This namespace includes methods that zkSync node call on the main node during syncing. If this namespace is active, other ENs can sync using this node. +This namespace includes methods that ZKsync node call on the main node during syncing. If this namespace is active, other ENs can sync using this node. diff --git a/content/20.zksync-node/50.observability.md b/content/20.zksync-node/50.observability.md index 61a289ca..154d5ae2 100644 --- a/content/20.zksync-node/50.observability.md +++ b/content/20.zksync-node/50.observability.md @@ -3,7 +3,7 @@ title: Observability description: --- -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 section, so this section focuses on the exposed metrics. This section is written with the assumption that you're familiar with @@ -19,7 +19,7 @@ By default, latency histograms are distributed in the following buckets (in seco ## Metrics -The zkSync node exposes a lot of metrics, a significant amount of which aren't interesting outside the development flow. This +The 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 @@ -28,7 +28,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 | @@ -43,12 +43,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 PostgreSQL. +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 (the zkSync node needs the tree to be up-to-date to +`server_block_number { stage='sealed' }`, while the latter does not increase (the 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/content/20.zksync-node/60.troubleshooting.md b/content/20.zksync-node/60.troubleshooting.md index c83fd501..999c1dd1 100644 --- a/content/20.zksync-node/60.troubleshooting.md +++ b/content/20.zksync-node/60.troubleshooting.md @@ -3,7 +3,7 @@ title: Troubleshooting description: --- -The zkSync node tries to follow the fail-fast principle: if an anomaly is discovered, instead of attempting state recovery, in +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. @@ -27,7 +27,7 @@ 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 +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. Feel free to [contact_us](https://zksync.io/contact) in case of related questions. @@ -46,7 +46,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/content/20.zksync-node/_dir.yml b/content/20.zksync-node/_dir.yml index 52949170..83f8a65c 100644 --- a/content/20.zksync-node/_dir.yml +++ b/content/20.zksync-node/_dir.yml @@ -1 +1 @@ -title: zkSync Node +title: ZKsync Node diff --git a/content/30.ecosystem/00.index.md b/content/30.ecosystem/00.index.md index d925e19d..9187bdd4 100644 --- a/content/30.ecosystem/00.index.md +++ b/content/30.ecosystem/00.index.md @@ -1,11 +1,11 @@ --- title: Explore the Ecosystem -description: Explore the zkSync Era ecosystem, a comprehensive suite of services and tools from wallets to marketplaces that empower and enhance your experience. +description: Explore the ZKsync Era ecosystem, a comprehensive suite of services and tools from wallets to marketplaces that empower and enhance your experience. --- Explore Wallets, Data services, Node providers, Marketplaces, Oracles, and much, much more -in the zkSync Era ecosystem. -To see a wider list of the ecosystem, check out [zkSync Era on DappRadar](https://zksync.dappradar.com/ecosystem). +in the ZKsync Era ecosystem. +To see a wider list of the ecosystem, check out [ZKsync Era on DappRadar](https://zksync.dappradar.com/ecosystem). ::card-group ::card @@ -30,7 +30,7 @@ To see a wider list of the ecosystem, check out [zkSync Era on DappRadar](https: icon: i-heroicons-server-solid to: /ecosystem/node-providers --- - Connect to zkSync Era reliably with robust and scalable node services. + Connect to ZKsync Era reliably with robust and scalable node services. :: ::card --- @@ -62,7 +62,7 @@ To see a wider list of the ecosystem, check out [zkSync Era on DappRadar](https: icon: i-heroicons-currency-dollar-solid to: /ecosystem/network-faucets --- - Get free test tokens for development purposes in the zkSync test network. + Get free test tokens for development purposes in the ZKsync test network. :: ::card --- diff --git a/content/30.ecosystem/10.bridges.md b/content/30.ecosystem/10.bridges.md index be7ea6d6..a3f6f73b 100644 --- a/content/30.ecosystem/10.bridges.md +++ b/content/30.ecosystem/10.bridges.md @@ -4,17 +4,17 @@ description: --- Bridges are pivotal in enhancing interoperability between different networks or layers, facilitating seamless asset and -data transfer. In this section, we delve into various bridge solutions integrated within the zkSync ecosystem, providing +data transfer. In this section, we delve into various bridge solutions integrated within the ZKsync ecosystem, providing developers and users with diverse options for cross-chain or cross-layer interactions. ::callout{icon="i-heroicons-information-circle-16-solid" color="green"} -For an extended list of bridging options within the zkSync ecosystem, feel free to explore the +For an extended list of bridging options within the ZKsync ecosystem, feel free to explore the [bridges](https://zksync.dappradar.com/ecosystem?category=defi_bridge&page=1) category on Dappradar. :: -## zkSync Portal Bridge +## ZKsync Portal Bridge -The [Portal Bridge](https://bridge.zksync.io/) on zkSync provides a gateway for assets between Ethereum and the zkSync +The [Portal Bridge](https://bridge.zksync.io/) on ZKsync provides a gateway for assets between Ethereum and the ZKsync network, ensuring secure and efficient transfers. ## Across @@ -35,7 +35,7 @@ and borrowing services. Its primary objective is to integrate and harmonize on-c ## Orbiter Finance -[Orbiter Finance](https://www.orbiter.finance/?source=Ethereum&dest=zkSync%20Era&token=ETH) is a cross-chain rollup +[Orbiter Finance](https://www.orbiter.finance/?source=Ethereum&dest=ZKsync%20Era&token=ETH) is a cross-chain rollup protocol designed to enable safe, economical, and swift transfer of messages or assets across different networks. ## Owlto Finance diff --git a/content/30.ecosystem/100.wallets.md b/content/30.ecosystem/100.wallets.md index bd7689d5..24974647 100644 --- a/content/30.ecosystem/100.wallets.md +++ b/content/30.ecosystem/100.wallets.md @@ -3,26 +3,26 @@ title: Wallets description: --- -The following wallets are known for their robustness, ease of use, and compatibility with zkSync +The following wallets are known for their robustness, ease of use, and compatibility with ZKsync Era. These wallets offer various features including, but not limited to, DeFi, NFT management, and multiple chain support. ::callout{icon="i-heroicons-information-circle-16-solid" color="green"} -For an extended list of wallets within the zkSync ecosystem, feel free to explore the +For an extended list of wallets within the ZKsync ecosystem, feel free to explore the [wallets](https://zksync.dappradar.com/ecosystem?category=non_dapps_wallets&page=1) category on Dappradar. :: ## BlockWallet -[BlockWallet](https://blockwallet.io/networks/zksync-wallet) is designed for zkSync users seeking +[BlockWallet](https://blockwallet.io/networks/zksync-wallet) is designed for ZKsync users seeking a decentralized wallet in a user-friendly package. **Availability**: Chrome extension ## Clave -[Clave](https://getclave.io/) is a zkSync native non-custodial smart wallet powered by account +[Clave](https://getclave.io/) is a ZKsync native non-custodial smart wallet powered by account abstraction and the hardware-level security elements to simplify the onchain experience for the next billions. @@ -37,7 +37,7 @@ smart contract wallet with low-cost Layer 2 capabilities. ## Enkrypt -[Enkrypt](https://www.enkrypt.com/networks/zksync-wallet/) provides native support for zkSync and enables seamless building and deployment on zkSync. +[Enkrypt](https://www.enkrypt.com/networks/zksync-wallet/) provides native support for ZKsync and enables seamless building and deployment on ZKsync. **Availability**: Browser extension (all browsers) diff --git a/content/30.ecosystem/30.data-indexers.md b/content/30.ecosystem/30.data-indexers.md index 9630fab7..ebf62c56 100644 --- a/content/30.ecosystem/30.data-indexers.md +++ b/content/30.ecosystem/30.data-indexers.md @@ -6,11 +6,11 @@ description: ## Overview Welcome to the Analytics page, a comprehensive hub dedicated to interacting with data services, -analytic tooling on zkSync Era. Each guide includes hands-on examples, ensuring that both -newcomers and experienced developers can seamlessly harness the power of the analytical tooling within the zkSync Era. +analytic tooling on ZKsync Era. Each guide includes hands-on examples, ensuring that both +newcomers and experienced developers can seamlessly harness the power of the analytical tooling within the ZKsync Era. ::callout{icon="i-heroicons-information-circle-16-solid" color="green"} -For an extended list of options within the zkSync ecosystem, feel free to explore the +For an extended list of options within the ZKsync ecosystem, feel free to explore the [infrastructure and developer tools](https://zksync.dappradar.com/ecosystem?page=1&category=non_dapps_infrastructure%2Cnon_dapps_developer_tools) categories on Dappradar. :: @@ -52,7 +52,7 @@ that can be used independently or in conjunction to power your data stack. [The Graph](https://thegraph.com/) is a decentralized protocol for indexing and querying blockchain data. The Graph makes it possible to query data that is difficult to query directly. -Use The Graph network today to index protocol data on zkSync! +Use The Graph network today to index protocol data on ZKsync! ## Space & Time diff --git a/content/30.ecosystem/40.ide.md b/content/30.ecosystem/40.ide.md index 24392f98..cc4bd3a5 100644 --- a/content/30.ecosystem/40.ide.md +++ b/content/30.ecosystem/40.ide.md @@ -6,22 +6,22 @@ description: ## Overview Welcome to the **IDE page**, a comprehensive hub dedicated to interacting with ready-to-use -interactive developer environments using zkSync Era. Each guide has been curated to offer +interactive developer environments using ZKsync Era. Each guide has been curated to offer hands-on examples, ensuring that both newcomers and experienced developers can seamlessly get -started with developing on zkSync Era. +started with developing on ZKsync Era. ## Atlas IDE [**Atlas**](https://www.atlaszk.com/) provides a robust and user-friendly environment to write, test, and deploy your smart contracts in a matter of minutes. Discover the potential and get -started with Atlas today and deploy your first contract on zkSync Era by following this [video tutorial](https://www.youtube.com/watch?v=TL-QnxoPyUY)! +started with Atlas today and deploy your first contract on ZKsync Era by following this [video tutorial](https://www.youtube.com/watch?v=TL-QnxoPyUY)! ## Remix IDE -The [Remix](https://remix.ethereum.org/) plugin for zkSync Era is live, providing a smooth, -user-friendly interface for developers of all skill levels to engage with the zkSync ecosystem. -The plugin simplifies the writing and deployment of zkSync’s smart contracts, making it +The [Remix](https://remix.ethereum.org/) plugin for ZKsync Era is live, providing a smooth, +user-friendly interface for developers of all skill levels to engage with the ZKsync ecosystem. +The plugin simplifies the writing and deployment of ZKsync’s smart contracts, making it accessible to newcomers and experienced users. -Follow the [The zkSync Era Remix Plugin: A How-To Guide](https://medium.com/nethermind-eth/the-zksync-era-remix-plugin-a-how-to-guide-fc54e8d24bd3), +Follow the [The ZKsync Era Remix Plugin: A How-To Guide](https://medium.com/nethermind-eth/the-zksync-era-remix-plugin-a-how-to-guide-fc54e8d24bd3), written by [Nethermind](https://x.com/NethermindEth), the team who developed the plugin. diff --git a/content/30.ecosystem/50.monitoring.md b/content/30.ecosystem/50.monitoring.md index 7db9684f..b4234d23 100644 --- a/content/30.ecosystem/50.monitoring.md +++ b/content/30.ecosystem/50.monitoring.md @@ -6,28 +6,28 @@ description: Monitoring is a crucial aspect of the development and maintenance phases for any blockchain network. It provides insights into the performance, health, and other operational aspects of the network and applications. In this section, we explore key tools that offer monitoring -solutions, aiding developers in keeping a close watch on their projects within the zkSync +solutions, aiding developers in keeping a close watch on their projects within the ZKsync ecosystem. These tools provide a platform for analytics, real-time monitoring, and data aggregation which are essential for making informed decisions. ## Elliptic -[Elliptic](https://www.elliptic.co/), a leader in cryptoasset risk management, has integrated support for zkSync, +[Elliptic](https://www.elliptic.co/), a leader in cryptoasset risk management, has integrated support for ZKsync, a Layer 2 scaling solution for Ethereum, to bolster its blockchain analytics capabilities. -This partnership enables organizations building on zkSync, such as hybrid exchange GRVT, +This partnership enables organizations building on ZKsync, such as hybrid exchange GRVT, to use Elliptic's real-time wallet and transaction screening tools for efficient compliance and risk management. -The integration leverages zkSync's scalable, low-cost solution to Ethereum's high gas fees and slow transactions, +The integration leverages ZKsync's scalable, low-cost solution to Ethereum's high gas fees and slow transactions, enhancing security and transparency. This collaboration signifies a significant step in providing comprehensive blockchain support -and advancing the zkSync ecosystem with robust analytics tools. +and advancing the ZKsync ecosystem with robust analytics tools. ## Coinfirm / Lukka -[Lukka and Coinfirm](https://lukka.tech/) have joined forces with zkSync to provide advanced wallet screening solutions for the zkSync network. +[Lukka and Coinfirm](https://lukka.tech/) have joined forces with ZKsync to provide advanced wallet screening solutions for the ZKsync network. As the preferred provider for crypto-asset funds and fund service providers, Lukka is trusted by industry leaders such as State Street, Polychain, and eToro for its precise reporting and Enterprise Data Management solutions. Coinfirm's blockchain analytics platform offers robust transaction, wallet, and cluster monitoring for crypto assets. -This partnership will enhance zkSync's ecosystem by ensuring accurate and comprehensive wallet screening, +This partnership will enhance ZKsync's ecosystem by ensuring accurate and comprehensive wallet screening, supporting secure and transparent operations for users and businesses. ## Dune Analytics diff --git a/content/30.ecosystem/60.network-faucets.md b/content/30.ecosystem/60.network-faucets.md index 9b132c68..6cd97141 100644 --- a/content/30.ecosystem/60.network-faucets.md +++ b/content/30.ecosystem/60.network-faucets.md @@ -19,7 +19,7 @@ to claim %%zk_testnet_name%% **0.01 ETH per day**. GitHub authentication is requ ## Sepolia faucets Use any of the following faucets to claim SepoliaETH, which you can bridge to %%zk_testnet_name%% -using the [zkSync Bridge](https://portal.zksync.io/bridge?network=sepolia). +using the [ZKsync Bridge](https://portal.zksync.io/bridge?network=sepolia). - [LearnWeb3 Sepolia faucet](https://learnweb3.io/faucets/sepolia) - [QuickNode Sepolia faucet](https://faucet.quicknode.com/ethereum/sepolia) @@ -30,4 +30,4 @@ using the [zkSync Bridge](https://portal.zksync.io/bridge?network=sepolia). ## Sepolia USDC faucet -You can use [Circle's Testnet Faucet](https://faucet.circle.com/) to claim testnet USDC on zkSync Sepolia or Ethereum Sepolia Testnet. +You can use [Circle's Testnet Faucet](https://faucet.circle.com/) to claim testnet USDC on %%zk_testnet_name%% or Ethereum Sepolia Testnet. diff --git a/content/30.ecosystem/70.nft-marketplaces.md b/content/30.ecosystem/70.nft-marketplaces.md index 13cf0ffd..a3fca2a0 100644 --- a/content/30.ecosystem/70.nft-marketplaces.md +++ b/content/30.ecosystem/70.nft-marketplaces.md @@ -7,7 +7,7 @@ The following NFT marketplaces are specialized in facilitating the trade, creati management of NFTs. These platforms offer distinct features and benefits. ::callout{icon="i-heroicons-information-circle-16-solid" color="green"} -For an extended list of marketplaces within the zkSync ecosystem, feel free to explore the +For an extended list of marketplaces within the ZKsync ecosystem, feel free to explore the [marketplaces](https://zksync.dappradar.com/ecosystem?page=1&category=marketplaces) category on Dappradar. :: @@ -21,8 +21,8 @@ buy and sell NFTs across different platforms, save money, and earn rewards. ## Libera [Libera](https://libera.xyz/) is a native NFT marketplace built specifically for the -zkSync Era. -**Specialty**: zkSync Era Native +ZKsync Era. +**Specialty**: ZKsync Era Native ## OKX NFT @@ -33,16 +33,16 @@ market, allowing you to create and trade NFTs across multiple blockchains and pl ## Tevaera [Tevaera](https://market.tevaera.com/) is the first paymasters and ONFT powered marketplace on -the zkSync Era. It offers the lowest transaction fees while being fully secured by the Ethereum consensus. -**Specialty**: zkSync Era, Low Fees, Paymasters and ONFT +the ZKsync Era. It offers the lowest transaction fees while being fully secured by the Ethereum consensus. +**Specialty**: ZKsync Era, Low Fees, Paymasters and ONFT ## zkMarkets -[zkMarkets](https://www.zkmarkets.com/zksync-era) is a native NFT marketplace on zkSync, +[zkMarkets](https://www.zkmarkets.com/zksync-era) is a native NFT marketplace on ZKsync, supporting paymasters and Smart Wallets like Clave. It features a Launchpad, rarity tools, and aggregated listings. **Specialty**: Aggregated Marketplace, Paymasters, Smart Accounts, Rarity tools Choose a marketplace that aligns with your requirements, whether it's low fees, -multi-blockchain support, or specific zkSync Era functionalities. Always perform your own due +multi-blockchain support, or specific ZKsync Era functionalities. Always perform your own due diligence before using any third-party platforms. diff --git a/content/30.ecosystem/80.oracles.md b/content/30.ecosystem/80.oracles.md index 5edfb689..7622cc71 100644 --- a/content/30.ecosystem/80.oracles.md +++ b/content/30.ecosystem/80.oracles.md @@ -6,13 +6,13 @@ description: ## Overview Welcome to the Oracles page, a comprehensive hub dedicated to interacting with oracle services -on zkSync Era. As the demand for decentralized applications continues, the need for reliable +on ZKsync Era. As the demand for decentralized applications continues, the need for reliable and efficient oracle services becomes paramount. Within these sections, you'll unearth specialized usage guides and tangible examples designed to facilitate seamless interactions with a variety of different oracle services. ::callout{icon="i-heroicons-information-circle-16-solid" color="green"} -For an extended list of infrastructure options within the zkSync ecosystem, feel free to explore the +For an extended list of infrastructure options within the ZKsync ecosystem, feel free to explore the [infrastructure](https://zksync.dappradar.com/ecosystem?page=1&category=non_dapps_infrastructure) category on Dappradar. :: @@ -31,7 +31,7 @@ trusted, high-volume DEXs and CEXs. Check out the usage guide below to get start ### Gelato [Gelato](https://docs.gelato.network/web3-services/vrf/understanding-vrf) provides access to Verifiable Random -Functions (VRF) on zkSync. VRFs are cryptographic primitives that generate pseudorandom numbers in a way that is +Functions (VRF) on ZKsync. VRFs are cryptographic primitives that generate pseudorandom numbers in a way that is provably secure and verifiable. A VRF allows a holder of a private key to produce a random number along with a proof that the number was generated legitimately (making it publically verifiable). More information, including how to use VRFs in your dApp, can be found in the Gelato docs. @@ -46,4 +46,4 @@ Checkout the usage guide to get started today! [RedStone](https://docs.redstone.finance/docs/introduction) delivers frequently updated, reliable, and diverse data feeds for your dApp and smart contracts. Check out all the price -feeds available to zkSync Era and get started with the provided usage guide. +feeds available to ZKsync Era and get started with the provided usage guide. diff --git a/content/30.ecosystem/90.node-providers.md b/content/30.ecosystem/90.node-providers.md index 66ace4f2..d1481d00 100644 --- a/content/30.ecosystem/90.node-providers.md +++ b/content/30.ecosystem/90.node-providers.md @@ -4,7 +4,7 @@ description: --- ::callout{icon="i-heroicons-information-circle-16-solid" color="green"} -For an extended list of infrastructure options within the zkSync ecosystem, feel free to explore the +For an extended list of infrastructure options within the ZKsync ecosystem, feel free to explore the [infrastructure](https://zksync.dappradar.com/ecosystem?page=1&category=non_dapps_infrastructure) category on Dappradar. :: @@ -12,18 +12,18 @@ category on Dappradar. ### Alchemy [Alchemy](https://www.alchemy.com/zksync) is a leading developer platform with powerful APIs, SDKs, and tools to build -truly scalable onchain apps. Deploy on zkSync Mainnet and zkSync Sepolia Testnet using Alchemy's free and [paid plans](https://www.alchemy.com/pricing). +truly scalable onchain apps. Deploy on ZKsync Mainnet and ZKsync Sepolia Testnet using Alchemy's free and [paid plans](https://www.alchemy.com/pricing). ## Ankr [Ankr](https://www.ankr.com/rpc/zksync_era/) provides private and public RPC endpoints for -zkSync, powered by a globally distributed and decentralized network of nodes. They offer free +ZKsync, powered by a globally distributed and decentralized network of nodes. They offer free and [paid plans](https://www.ankr.com/rpc/pricing/) with increased request limits. ## BlockPI [BlockPI](https://blockpi.io/zksync) is a high-quality, robust, and efficient RPC service -network that provides access to zkSync nodes with [free and paid plans](https://docs.blockpi.io/documentations/pricing). +network that provides access to ZKsync nodes with [free and paid plans](https://docs.blockpi.io/documentations/pricing). ## Chainstack @@ -38,30 +38,30 @@ data correctness, and scalability. Chainbase will handle all the forks, upgrades ## DRPC [DRPC](https://drpc.org/public-endpoints/zksync) offers access to distributed network of -independent third-party partners and public nodes for zkSync. They provide a free tier that +independent third-party partners and public nodes for ZKsync. They provide a free tier that allows for an unlimited amount of requests over public nodes, or a paid tier which provides access to all providers, as well as other additional features. ## GetBlock -[GetBlock](https://getblock.io/nodes/zksync/) provides access to zkSync API endpoint for your -project. With GetBlock you don’t need to know how to run zkSync nodes as they are already are +[GetBlock](https://getblock.io/nodes/zksync/) provides access to ZKsync API endpoint for your +project. With GetBlock you don’t need to know how to run ZKsync nodes as they are already are available for mainnet and testnets. ### NOWNodes -[NOWNodes](https://nownodes.io/nodes) provides Full Node for zkSync with is a high-quality standart and 24/7 support. Free Plan is available. +[NOWNodes](https://nownodes.io/nodes) provides Full Node for ZKsync with is a high-quality standart and 24/7 support. Free Plan is available. ## Quicknode -[QuickNode](https://www.quicknode.com/chains/zksync) offers access to hosted zkSync nodes as +[QuickNode](https://www.quicknode.com/chains/zksync) offers access to hosted ZKsync nodes as part of their free Discover Plan. You can configure add-ons, like "Trace Mode" and "Archive Mode" for an additional cost by upgrading to one of their paid plans. ## Unifra [Unifra](https://unifra.io/) is a Web3 developer platform that provides tools, APIs, and node -infrastructure, and provides access to zkSync nodes that are nodes are reliable, scalable, and +infrastructure, and provides access to ZKsync nodes that are nodes are reliable, scalable, and easy to use. ### Public RPCs diff --git a/content/_partials/_compile-solidity-contracts.md b/content/_partials/_compile-solidity-contracts.md index 27e6d4fa..e7b51f54 100644 --- a/content/_partials/_compile-solidity-contracts.md +++ b/content/_partials/_compile-solidity-contracts.md @@ -2,7 +2,7 @@ title: Compile Solidity Contract --- -Smart contracts deployed to zkSync must be compiled using our custom compiler. +Smart contracts deployed to ZKsync must be compiled using our custom compiler. `zksolc` is the compiler used for Solidity. To compile the contracts in a project, run the following command: diff --git a/content/_partials/_enable-remix-zksync-plugin.md b/content/_partials/_enable-remix-zksync-plugin.md index 34c05e01..d8e5a12b 100644 --- a/content/_partials/_enable-remix-zksync-plugin.md +++ b/content/_partials/_enable-remix-zksync-plugin.md @@ -1,14 +1,14 @@ --- -title: Enable zkSync plugin in Remix +title: Enable ZKsync plugin in Remix --- -To deploy smart contracts to zkSync via Remix you need to enable the zkSync plugin. +To deploy smart contracts to ZKsync via Remix you need to enable the ZKsync plugin. 1. Visit [the Remix website](https://remix.ethereum.org/) 2. Click on the **“🔌 Plugin Manager”** button in the bottom-left corner 3. Search “zksync” and click on the **"Activate"** button. -![Enable zkSync plugin in Remix](/images/enable-remix-plugin.gif) +![Enable ZKsync plugin in Remix](/images/enable-remix-plugin.gif) -Once activated, you’ll see a new menu item with the zkSync logo. Click on it to see the different options to compile, -deploy, and interact with smart contracts on zkSync. +Once activated, you’ll see a new menu item with the ZKsync logo. Click on it to see the different options to compile, +deploy, and interact with smart contracts on ZKsync. diff --git a/content/index.yml b/content/index.yml index 5ecf0661..667c34a4 100644 --- a/content/index.yml +++ b/content/index.yml @@ -1,23 +1,23 @@ -title: 'zkSync Docs' +title: 'ZKsync Docs' description: - zkSync Docs bring you all information you need about our protocol, APIs, SDKs, ZK Stack, and ZK chains. Start with our + ZKsync Docs bring you all information you need about our protocol, APIs, SDKs, ZK Stack, and ZK chains. Start with our guides and tutorials, or go deep into our architecture and protocol specification. navigation: false hero: - title: 'Unlock the Potential of Layer 2 Scaling with zkSync' - description: 'Explore comprehensive guides, developer tools, and resources to innovate on zkSync.' + title: 'Unlock the Potential of Layer 2 Scaling with ZKsync' + description: 'Explore comprehensive guides, developer tools, and resources to innovate on ZKsync.' orientation: vertical links: - - label: Start building on zkSync + - label: Start building on ZKsync icon: i-heroicons-arrow-right-20-solid trailing: true to: '/build' size: xl features: - title: 'Explore zkSync Docs' + title: 'Explore ZKsync Docs' items: - - title: 'Getting Started with zkSync' - description: 'Jumpstart your zkSync journey with quickstart guides and fundamental concepts for developers.' + - title: 'Getting Started with ZKsync' + description: 'Jumpstart your ZKsync journey with quickstart guides and fundamental concepts for developers.' icon: 'i-zksync-zksync-logo' to: '/build/quick-start' - title: 'Develop with zksync-cli' @@ -25,21 +25,21 @@ features: icon: 'i-simple-icons-windowsterminal' to: '/build/tooling/zksync-cli' - title: 'Architecture' - description: 'Learn about the zkSync architecture and how it works under the hood.' + description: 'Learn about the ZKsync architecture and how it works under the hood.' icon: 'i-heroicons-sparkles-20-solid' to: '/zk-stack' community: - title: 'Join the zkSync Community' + title: 'Join the ZKsync Community' items: - title: 'Developer Updates' - description: 'Keep up to date with the latest from the zkSync team on X.' + description: 'Keep up to date with the latest from the ZKsync team on X.' icon: 'i-simple-icons-x' to: 'https://x.com/zksyncDevs' - title: 'GitHub Discussions' - description: 'Get help from the community and contribute to the zkSync project.' + description: 'Get help from the community and contribute to the ZKsync project.' icon: 'i-simple-icons-github' - to: 'https://github.com/zkSync-Community-Hub/zksync-developers/discussions' - - title: 'zkSync Discord' - description: 'Connect with devs and zkSync enthusiasts on Discord.' + to: 'https://github.com/ZKsync-Community-Hub/zksync-developers/discussions' + - title: 'ZKsync Discord' + description: 'Connect with devs and ZKsync enthusiasts on Discord.' icon: 'i-simple-icons-discord' to: 'https://join.zksync.dev/' diff --git a/cspell-config/cspell-zksync.txt b/cspell-config/cspell-zksync.txt index fa6433fd..b6f246a4 100644 --- a/cspell-config/cspell-zksync.txt +++ b/cspell-config/cspell-zksync.txt @@ -14,3 +14,7 @@ zkstack zksync zksync-cli zkvyper +!zkSync +!Zksync +!ZkSync +ZKsync diff --git a/nuxt.config.ts b/nuxt.config.ts index 34b73f3e..b58bba80 100644 --- a/nuxt.config.ts +++ b/nuxt.config.ts @@ -3,7 +3,7 @@ export default defineNuxtConfig({ extends: [['github:matter-labs/docs-nuxt-template', { install: true }], ['github:zksync-sdk/sdk-docs']], modules: ['@nuxt/content', '@nuxt/ui', '@nuxt/eslint', '@nuxtjs/seo', 'nuxt-gtag'], site: { - name: 'zkSync Docs', + name: 'ZKsync Docs', url: process.env.NUXT_SITE_ENV ? 'https://staging-docs.zksync.io' : 'https://docs.zksync.io', }, content: { diff --git a/package.json b/package.json index a8067404..733ffd7a 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { "name": "zksync-docs", "type": "module", - "description": "zkSync Docs V3", + "description": "ZKsync Docs V3", "version": "0.0.0", "license": "MIT", "devDependencies": { diff --git a/pages/index.vue b/pages/index.vue index 6965f721..72e8b146 100644 --- a/pages/index.vue +++ b/pages/index.vue @@ -14,7 +14,7 @@ useSeoMeta({ defineOgImage({ component: 'OgImageZK', title: seo?.siteName, - description: 'Access detailed guides, references and resources that will help you build with zkSync Era.', + description: 'Access detailed guides, references and resources that will help you build with ZKsync Era.', });