diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
index f73fe609..d569c3ca 100644
--- a/.github/ISSUE_TEMPLATE/bug_report.md
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -7,7 +7,7 @@ assignees: ''
---
-### đ Bug Report for ZKsync Docs
+### đ Bug Report for zkSync Docs
#### đ Description
@@ -41,4 +41,4 @@ Add any other context about the problem here. If applicable, add screenshots to
```
Paste any relevant log output here.
-```
\ No newline at end of file
+```
diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml
index 34c81273..61fd4b71 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
+ url: https://github.com/zkSync-Community-Hub/zkync-developers/discussions
about: Please provide feedback, and ask questions here.
diff --git a/README.md b/README.md
index 1049e4ef..9ffdc6d9 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,7 @@
-# ZK Sync Docs
+# zkSync Docs
-Welcome to the ZK Sync Docs repository. This project serves as the community hub for ZKsync, providing comprehensive
-documentation for developers. Whether you're a beginner looking to get started with ZKsync or an experienced developer
+Welcome to the zkSync Docs repository. This project serves as the community hub for zkSync, providing comprehensive
+documentation for developers. Whether you're a beginner looking to get started with zkSync or an experienced developer
seeking advanced guides, you'll find the resources you need here.
## Tools used
@@ -62,9 +62,9 @@ bun run lint:eslint
## Contributions
-We welcome contributions from the community to ZKsync Docs.
+We welcome contributions from the community to zkSync Docs.
If you're looking for ideas on where to start with contributing, check out the [Contribution Overview](./content/90.contributing-to-documentation/10.index.md).
-To learn more on how to follow best practices when contributing to ZKsync Docs,
+To learn more on how to follow best practices when contributing to zkSync Docs,
refer to the [Contribution Guidelines](./content/90.contributing-to-documentation/20.contribution-guidelines.md).
If you are writing new content to add to the docs, the [Documentation Styleguide](./content/90.contributing-to-documentation/30.documentation-styleguide.md)
can provide additional guidance.
diff --git a/app.config.ts b/app.config.ts
index 2b843ab7..6b1234c6 100644
--- a/app.config.ts
+++ b/app.config.ts
@@ -5,7 +5,7 @@
*/
export default defineAppConfig({
seo: {
- siteName: 'ZKsync Docs',
+ siteName: 'zkSync Docs',
},
header: {
links: [
@@ -13,8 +13,8 @@ export default defineAppConfig({
icon: 'i-simple-icons-github',
to: 'https://github.com/matter-labs/zksync-docs',
target: '_blank',
- 'aria-label': 'ZKsync Docs on GitHub',
- title: 'ZKsync Docs on GitHub',
+ 'aria-label': 'zkSync Docs on GitHub',
+ title: 'zkSync Docs on GitHub',
},
],
},
diff --git a/app.vue b/app.vue
index 5ea66913..ea130f14 100644
--- a/app.vue
+++ b/app.vue
@@ -16,12 +16,12 @@ useHead({
{
name: 'keywords',
content:
- 'Documentation, Developers, Era, ZKsync, ZK Stack, Matter Labs, rollup, ZK rollup, zero confirmation, ZKP, zero-knowledge proofs, Ethereum, crypto, blockchain, permissionless, L2, secure payments, scalable',
+ 'Documentation, Developers, Era, zkSync, ZK Stack, Matter Labs, rollup, ZK rollup, zero confirmation, ZKP, zero-knowledge proofs, Ethereum, crypto, blockchain, permissionless, L2, secure payments, scalable',
},
{
name: 'description',
content:
- 'ZKsync Docs bring you all information you need about our protocol, APIs, SDKs, ZK Stack, and hyperchains. Start with our guides and tutorials, or go deep into our architecture and protocol specification.',
+ '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.',
},
{ name: 'author', content: 'https://matter-labs.io' },
],
@@ -36,14 +36,14 @@ useSeoMeta({
ogSiteName: seo?.siteName,
ogUrl: 'https://docs.zksync.io/',
ogImage: 'https://docs.zksync.io/social-card.png',
- ogImageAlt: 'ZKsync â Accelerating the mass adoption of crypto for personal sovereignty.',
+ ogImageAlt: 'zkSync â Accelerating the mass adoption of crypto for personal sovereignty.',
ogDescription:
- 'ZKsync Docs bring you all information you need about our protocol, APIs, SDKs, ZK Stack, and hyperchains. Start with our guides and tutorials, or go deep into our architecture and protocol specification.',
+ '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.',
twitterImage: 'https://docs.zksync.io/social-card.png',
twitterCard: 'summary_large_image',
twitterSite: '@zksync',
twitterCreator: '@the_matter_labs',
- twitterImageAlt: 'ZKsync â Accelerating the mass adoption of crypto for personal sovereignty.',
+ twitterImageAlt: 'zkSync â Accelerating the mass adoption of crypto for personal sovereignty.',
});
provide('navigation', navigation);
@@ -65,9 +65,9 @@ const links = computed(() => {
active: route.path.startsWith('/zk-stack'),
},
{
- label: 'External Node',
- to: '/external-node',
- active: route.path.startsWith('/external-node'),
+ label: 'zkSync Node',
+ to: '/zksync-node',
+ active: route.path.startsWith('/zksync-node'),
},
{
label: 'Ecosystem',
diff --git a/components/HeaderComponent.vue b/components/HeaderComponent.vue
index 992264b9..2ccd54c8 100644
--- a/components/HeaderComponent.vue
+++ b/components/HeaderComponent.vue
@@ -18,7 +18,7 @@ const { header } = useAppConfig();
- ZKsync
+ zkSync
-
+Our Quickstart series utilizes the `zksync-cli` to help you develop and interact with zkSync from your local machine. Check out our
+[zksync-cli section](/build/tooling/zksync-cli) to learn more on how to use the CLI.
You will need to install a couple tools to effectively use `zksync-cli`:
@@ -55,7 +54,7 @@ This era local node allows for quicker testing and debugging processes without i
The era local node will need Docker to run locally on your machine.
Download the appropriate version from the [Docker website](https://docs.docker.com/engine/install/).
-#### Run a local ZKsync Era node
+#### Run a local zkSync Era node
Run the following command in your terminal:
@@ -63,13 +62,11 @@ Run the following command in your terminal:
zksync-cli dev start
```
-Choose "In memory node" to deploy a local ZKsync Era node in a Docker container.
+Choose "In memory node" to deploy a local zkSync Era node in a Docker container.
-The local era node will also include pre-configured rich wallets for use,
-
-
+The local era node will also include pre-configured rich wallets for use, visit [era-test-node rich wallets](/build/test-and-debug/in-memory-node#pre-configured-rich-wallets)
-Your local ZKsync Era node is accessible at **[http://127.0.0.1:8011](http://127.0.0.1:8011/)**, ready for deployment or testing purposes.
+Your local zkSync Era node is accessible at **[http://127.0.0.1:8011](http://127.0.0.1:8011/)**, ready for deployment or testing purposes.
Leave this terminal open and running as you build your projects.
When you are done running your local Era node, you can stop it with `Ctrl+C`.
@@ -86,9 +83,9 @@ each of the guides.
### Install foundry-zksync
If you choose to use Foundry for the Quick Start series, you will need to
-install the `foundry-zksync` tool. This tool is a specialized fork of 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.
+install the `foundry-zksync` tool. This tool is a specialized fork of 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.
::callout{icon="i-heroicons-information-circle-16-solid" color="amber"}
`foundry-zksync` is still in an alpha stage, so some features might not be fully supported
@@ -123,7 +120,7 @@ If you did not set up a local era node for development and plan to use %%zk_test
- Use the [LearnWeb3 faucet](https://learnweb3.io/faucets/zksync_sepolia/)
to directly receive testnet ETH on %%zk_testnet_name%%.
- Alternatively, acquire SepoliaETH from [recommended faucets](/ecosystem/network-faucets)
- transfer it to the %%zk_testnet_name%% via the [ZKsync bridge](https://portal.zksync.io/bridge/?network=sepolia).
+ transfer it to the %%zk_testnet_name%% via the [zkSync bridge](https://portal.zksync.io/bridge/?network=sepolia).
2. Verify your balance:
@@ -156,9 +153,9 @@ To deploy contracts, you'll need to securely add your wallet's private key to th
## Next Steps
-You should now have a fully working local environment to build new projects on ZKsync!
+You should now have a fully working local environment to build new projects on zkSync!
-- Continue to [Hello ZKsync!](/build/quick-start/hello-zksync) to begin the series on building a crowdfunding campaign for Zeek.
+- Continue to [Hello zkSync!](/build/quick-start/hello-zksync) to begin the series on building a crowdfunding campaign for Zeek.
-- This setup provides you everything you need to build in ZKsync.
+- This setup provides you everything you need to build in zkSync.
You can skip on to creating your own projects using `zksync-cli` with your fully set up local dev environment.
diff --git a/content/00.build/10.quick-start/10.hello-zksync.md b/content/00.build/10.quick-start/10.hello-zksync.md
index 1a650f2e..e6732b1e 100644
--- a/content/00.build/10.quick-start/10.hello-zksync.md
+++ b/content/00.build/10.quick-start/10.hello-zksync.md
@@ -1,28 +1,28 @@
---
-title: Hello ZKsync!
-description: Learn to deploy smart contracts efficiently in the ZKsync environment.
+title: Hello zkSync!
+description: Learn to deploy smart contracts efficiently in the zkSync environment.
---
-Welcome to the Quickstart guide for deploying smart contracts on ZKsync! In this series, we'll walk you through the process
+Welcome to the Quickstart guide for deploying smart contracts on zkSync! In this series, we'll walk you through the process
of creating and deploying a simple smart contract that creates a crowdfunding campaign for Zeek. In this section you will learn the following:
:check-icon Initialize a new project with zksync-cli.
:check-icon Craft a smart contract to fund Zeek's latest adventure.
-:check-icon Deploy the contract on the ZKsync Era using your choice of Hardhat or Foundry.
+:check-icon Deploy the contract on the zkSync Era using your choice of Hardhat or Foundry.
-Let's dive in and start your developer journey on ZKsync!
+Let's dive in and start your developer journey on zkSync!
---
## Prerequisites
This Quickstart series requires some initial setup of tools to elevate your
-development experience building for ZKsync.
+development experience building for zkSync.
Make sure to go through the setup provided in the initial [Getting started](/build/quick-start) section.
-Select the framework you want to get started using ZKsync Era with.
+Select the framework you want to get started using zkSync Era with.
::content-switcher
---
@@ -38,21 +38,21 @@ items: [{
## Takeaways
-- **EVM Compatibility:** ZKsync is EVM compatible and you can write smart contracts in Solidity or Vyper.
-- **Custom Compilation:** Contracts deployed to ZKsync are compiled using `zksolc` or `zkvyper` as
-they generate a special bytecode for ZKsync's ZKEVM.
-- **Development Tools:** ZKsync supports your favorite development toolkit Hardhat and Foundry.
+- **EVM Compatibility:** zkSync is EVM compatible and you can write smart contracts in Solidity or Vyper.
+- **Custom Compilation:** Contracts deployed to zkSync are compiled using `zksolc` or `zkvyper` as
+they generate a special bytecode for zkSync's ZKEVM.
+- **Development Tools:** zkSync supports your favorite development toolkit Hardhat and Foundry.
## Next steps
-Having successfully deployed your first contract on ZKsync, you're well on your way to becoming
-a proficient ZKsync developer. To expand your expertise:
+Having successfully deployed your first contract on zkSync, you're well on your way to becoming
+a proficient zkSync developer. To expand your expertise:
- **Explore Contract Factories:** Enhance your project by building a contract factory
for the `CrowdfundingCampaign` contract in the [next guide](/build/quick-start/contract-factory). This will allow you to efficiently
manage multiple crowdfunding campaigns, each with its own unique parameters.
-- **Dive Deeper into ZKsync Features:** Investigate advanced ZKsync features such as account abstraction,
+- **Dive Deeper into zkSync Features:** Investigate advanced zkSync features such as account abstraction,
and paymasters.
-- **Join the Community:** Engage with the ZKsync developer community through forums,
+- **Join the Community:** Engage with the zkSync developer community through forums,
Discord channels, Dev Discussions, or GitHub repositories. Share your experiences, ask questions,
and collaborate on projects.
diff --git a/content/00.build/10.quick-start/20.contract-factory.md b/content/00.build/10.quick-start/20.contract-factory.md
index 31ee105e..b9c23849 100644
--- a/content/00.build/10.quick-start/20.contract-factory.md
+++ b/content/00.build/10.quick-start/20.contract-factory.md
@@ -1,17 +1,17 @@
---
title: Contract Factory
-description: Learn how to deploy and manage multiple smart contracts on ZKsync using a contract factory.
+description: Learn how to deploy and manage multiple smart contracts on zkSync using a contract factory.
---
This second Quickstart installment advances from your introductory exploration of smart contract deployment to dive into the utility of contract factories.
Through this guide, you'll learn how to streamline the deployment of multiple crowdfunding campaigns using a single contract factory, leveraging the
foundational `CrowdfundingCampaign` contract in the first guide.
-:check-icon Advance your ZKsync development journey with contract factories.
+:check-icon Advance your zkSync development journey with contract factories.
:check-icon Construct a contract factory to create multiple crowdfunding campaigns.
-:check-icon Seamlessly deploy your contract factory on ZKsync Era, using either Hardhat or Foundry.
+:check-icon Seamlessly deploy your contract factory on zkSync Era, using either Hardhat or Foundry.
Let's explore the efficiency and scalability that contract factories bring.
@@ -26,7 +26,7 @@ numerous similar contracts efficiently.
## Setup the project
-Select the framework you want to get started using ZKsync Era with.
+Select the framework you want to get started using zkSync Era with.
::content-switcher
---
@@ -53,15 +53,15 @@ off-chain monitoring and interaction.
## Next steps
-With the contract factory in your ZKsync development arsenal, you're set to elevate
+With the contract factory in your zkSync development arsenal, you're set to elevate
your smart contract projects. Here's how you can further your journey:
- **Contract Testing:** Progress to the next guide focused on testing your contracts.
Ensuring the reliability and security of your `CrowdfundingCampaign` through
comprehensive tests is critical.
-- **Advanced ZKsync Integrations:** Explore deeper into ZKsync's ecosystem by
+- **Advanced zkSync Integrations:** Explore deeper into zkSync's ecosystem by
implementing features like account abstraction and paymasters to enhance user
experience and contract flexibility.
-- **Community Engagement and Contribution:** Join the vibrant ZKsync community.
+- **Community Engagement and Contribution:** Join the vibrant zkSync community.
Participate in forums, Discord, or GitHub discussions. Sharing insights, asking queries,
-and contributing can enrich the ecosystem and your understanding of ZKsync.
+and contributing can enrich the ecosystem and your understanding of zkSync.
diff --git a/content/00.build/10.quick-start/30.testing.md b/content/00.build/10.quick-start/30.testing.md
index b121e1bf..a4a76615 100644
--- a/content/00.build/10.quick-start/30.testing.md
+++ b/content/00.build/10.quick-start/30.testing.md
@@ -1,21 +1,21 @@
---
title: Testing
-description: Discover how to effectively test smart contracts on ZKsync Era ecosystem.
+description: Discover how to effectively test smart contracts on zkSync Era ecosystem.
---
-Welcome back to our Quickstart Series, your fast-track to ZKsync development! In this
+Welcome back to our Quickstart Series, your fast-track to zkSync development! In this
third guide, we transition from deploying and managing contracts to the critical phase
of testing. This guide will walk you through the steps to ensure your `CrowdfundingCampaign`
contracts, introduced in our first guide and efficiently deployed through contract factories
in the second, work flawlessly.
-:check-icon Elevate your ZKsync toolkit with robust contract testing techniques.
+:check-icon Elevate your zkSync toolkit with robust contract testing techniques.
:check-icon Craft comprehensive tests for your `CrowdfundingCampaign` to ensure reliability and security.
:check-icon Use Hardhat or Foundry to write and run tests, ensuring your campaigns are ready.
-Dive into the world of smart contract testing and solidify the foundation of your ZKsync projects.
+Dive into the world of smart contract testing and solidify the foundation of your zkSync projects.
## Setup the project
@@ -34,7 +34,7 @@ items: [{
## Takeaways
- **Testing**: Understanding contract testing is important for ensuring the reliability and security of your smart contracts
-on ZKsync. Proper testing safeguards against unforeseen errors and vulnerabilities.
+on zkSync. Proper testing safeguards against unforeseen errors and vulnerabilities.
- **Comprehensive Coverage**: Achieving comprehensive test coverage, including both positive and negative testing
scenarios, is essential for a robust smart contract. This guide emphasized the `contribute` method,
but testing should encompass all aspects of your contract.
@@ -44,15 +44,15 @@ that enhance the testing process.
## Next Steps
-With a solid foundation in contract testing, you're well-equipped to advance your ZKsync
+With a solid foundation in contract testing, you're well-equipped to advance your zkSync
development journey. Consider the following steps to further your expertise:
- **Upgradeability**: Dive into the [Upgradeability article](/build/quick-start/upgrading) focusing on contract upgradeability.
Learning to make your contracts upgradeable will enable you to update and improve your smart contracts
over time without losing state or funds.
-- **Advanced ZKsync Integrations:** Explore deeper into ZKsync's ecosystem by
+- **Advanced zkSync Integrations:** Explore deeper into zkSync's ecosystem by
implementing features like account abstraction and paymasters to enhance user
experience and contract flexibility.
-- **Community Engagement and Contribution:** Join the vibrant ZKsync community.
+- **Community Engagement and Contribution:** Join the vibrant zkSync community.
Participate in forums, Discord, or GitHub discussions. Sharing insights, asking queries,
-and contributing can enrich the ecosystem and your understanding of ZKsync.
+and contributing can enrich the ecosystem and your understanding of zkSync.
diff --git a/content/00.build/10.quick-start/40.upgrading.md b/content/00.build/10.quick-start/40.upgrading.md
index aa26a900..1e653fc9 100644
--- a/content/00.build/10.quick-start/40.upgrading.md
+++ b/content/00.build/10.quick-start/40.upgrading.md
@@ -1,19 +1,19 @@
---
title: Upgradability
-description: Learn to make smart contracts upgradeable within the ZKsync ecosystem.
+description: Learn to make smart contracts upgradeable within the zkSync ecosystem.
---
In this fourth installment, we embark on a journey through contract upgradability,
an important aspect for maintaining and enhancing smart contracts over time. This guide will
lead you through the strategies and practices for making the `CrowdfundingCampaign` contract **upgradeable**.
-:check-icon Harness advanced techniques for contract upgradability in ZKsync.
+:check-icon Harness advanced techniques for contract upgradability in zkSync.
:check-icon Implement upgradeable patterns for the `CrowdfundingCampaign` to ensure long-term adaptability and improvement.
-:check-icon Leverage tools and best practices in ZKsync to facilitate seamless contract upgrades.
+:check-icon Leverage tools and best practices in zkSync to facilitate seamless contract upgrades.
-Begin to understand smart contract evolution and empower your ZKsync applications with the
+Begin to understand smart contract evolution and empower your zkSync applications with the
flexibility of upgradability.
Select your preferred upgrade mechanism:
@@ -49,9 +49,9 @@ functionalities evolve. This approach provides a resilient framework for your dA
- **Exploring Paymasters:** Continue on to the next guide focused on [using paymasters](/build/quick-start/paymaster)
with your smart contracts. Paymasters abstract gas payments in transactions,
offering new models for transaction fee management and enhancing user experience in dApps.
-- **Advanced ZKsync Integrations:** Explore deeper into ZKsync's ecosystem by
+- **Advanced zkSync Integrations:** Explore deeper into zkSync's ecosystem by
implementing features like account abstraction and paymasters to enhance user
experience and contract flexibility.
-- **Community Engagement and Contribution:** Join the vibrant ZKsync community.
+- **Community Engagement and Contribution:** Join the vibrant zkSync community.
Participate in forums, Discord, or GitHub discussions. Sharing insights, asking queries,
-and contributing can enrich the ecosystem and your understanding of ZKsync.
+and contributing can enrich the ecosystem and your understanding of zkSync.
diff --git a/content/00.build/10.quick-start/50.paymaster.md b/content/00.build/10.quick-start/50.paymaster.md
index 367647c6..f25d2a04 100644
--- a/content/00.build/10.quick-start/50.paymaster.md
+++ b/content/00.build/10.quick-start/50.paymaster.md
@@ -3,25 +3,25 @@ title: Paymaster
description: Implement a paymaster flow into your project.
---
-Welcome to the final part of our Quickstart Series on mastering ZKsync development!
+Welcome to the final part of our Quickstart Series on mastering zkSync development!
In this guide, we move beyond the basics
of smart contract deployment and the creation of contract factories to explore the innovative concept of paymasters
-in the ZKsync ecosystem. This guide will illuminate the power of paymasters to revolutionize transaction
+in the zkSync ecosystem. This guide will illuminate the power of paymasters to revolutionize transaction
fee management and enhance user experiences within your dApps.
-:check-icon Delve deeper into ZKsync development with the introduction of paymasters.
+:check-icon Delve deeper into zkSync development with the introduction of paymasters.
:check-icon Learn how paymasters can cover transaction fees for your dApp users, enhancing accessibility and user experience.
:check-icon Discover the flexibility of fee payment with paymasters, including the ability to pay
-fees in ERC20 tokens on ZKsync Era, using Hardhat or Foundry.
+fees in ERC20 tokens on zkSync Era, using Hardhat or Foundry.
Embark on this journey to understand how paymasters can add a new layer of functionality and user-friendliness
to your decentralized applications.
## What are Paymasters?
-Paymasters in the ZKsync ecosystem represent a groundbreaking approach to handling transaction fees.
+Paymasters in the zkSync ecosystem represent a groundbreaking approach to handling transaction fees.
They are special accounts designed to subsidize transaction costs for other accounts, potentially making
certain transactions free for end-users. This feature is particularly useful for dApp developers looking
to improve their platform's accessibility and user experience by covering transaction fees on behalf of their users.
@@ -41,13 +41,13 @@ fees, subject to user-approved limits.
As we explore paymasters, remember that while they offer enhanced flexibility for fee management, their
implementation should always prioritize security and user trust. This guide aims to equip you with the knowledge
-to effectively incorporate paymasters into your ZKsync projects, paving the way for more user-friendly and accessible dApps.
+to effectively incorporate paymasters into your zkSync projects, paving the way for more user-friendly and accessible dApps.
---
## Paymaster flow
-Select the paymaster type you want to get started using ZKsync Era with.
+Select the paymaster type you want to get started using zkSync Era with.
::content-switcher
---
@@ -65,7 +65,7 @@ items: [{
- **Comprehensive Understanding of Paymaster Contracts:** This guide has provided a detailed look at both the
`ApprovalFlowPaymaster` and the `GeneralPaymaster` contracts, illustrating how they manage transaction fees
-in ZKsync. These paymasters are pivotal in handling gas payments, offering a more accessible transaction
+in zkSync. These paymasters are pivotal in handling gas payments, offering a more accessible transaction
experience for users.
- **Flexibility and User Empowerment:** By covering the transaction fees through ERC20 tokens or general subsidies, these
paymaster contracts offer significant flexibility and reduce the friction typically associated with on-chain
@@ -79,6 +79,6 @@ and with different types validations, restrictions and enhancements.
- **Develop a Front-End Interface:** Consider building a user interface that interacts with the paymaster contracts
you have deployed. This will not only improve the usability of your contracts but also provide practical insights
into how end-users interact with your dApps in real-world scenarios.
-- **Community Engagement and Contribution:** Join the vibrant ZKsync community.
+- **Community Engagement and Contribution:** Join the vibrant zkSync community.
Participate in forums, Discord, or GitHub discussions. Sharing insights, asking queries,
-and contributing can enrich the ecosystem and your understanding of ZKsync.
+and contributing can enrich the ecosystem and your understanding of zkSync.
diff --git a/content/00.build/10.quick-start/_deploy_factory/_foundry_deploy_contract_factory.md b/content/00.build/10.quick-start/_deploy_factory/_foundry_deploy_contract_factory.md
index 512d1fc2..bb6c4e09 100644
--- a/content/00.build/10.quick-start/_deploy_factory/_foundry_deploy_contract_factory.md
+++ b/content/00.build/10.quick-start/_deploy_factory/_foundry_deploy_contract_factory.md
@@ -70,7 +70,7 @@ making it efficient to launch and manage multiple campaigns.
### Compile 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.
For this particular guide we are making use of `zksolc`.
To compile the contracts in the project, run the following command:
@@ -88,7 +88,7 @@ of Solidity files compiled.
[â ] Compiling 3 files with 0.8.20
[â ] Solc 0.8.20 finished in 336.48ms
Compiler run successful!
-Compiling contracts for ZKsync Era with zksolc v1.4.0
+Compiling contracts for zkSync Era with zksolc v1.4.0
```
The compiled zkEVM artifacts will be located in the `/zkout` folder, and the solc
diff --git a/content/00.build/10.quick-start/_deploy_factory/_hardhat_deploy_contract_factory.md b/content/00.build/10.quick-start/_deploy_factory/_hardhat_deploy_contract_factory.md
index 3dc65987..f1d8cfaf 100644
--- a/content/00.build/10.quick-start/_deploy_factory/_hardhat_deploy_contract_factory.md
+++ b/content/00.build/10.quick-start/_deploy_factory/_hardhat_deploy_contract_factory.md
@@ -73,7 +73,7 @@ Upon successful compilation, you'll receive output detailing the
of Solidity files compiled.
```bash
-Compiling contracts for ZKsync Era with zksolc v1.4.0 and solc v0.8.17
+Compiling contracts for zkSync Era with zksolc v1.4.0 and solc v0.8.17
Compiling 2 Solidity file
Successfully compiled 2 Solidity file
```
@@ -180,7 +180,7 @@ Estimated deployment cost: 0.0002500236 ETH
Requesting contract verification...
Your verification ID is: 10097
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
đ CrowdfundingFactory address: 0xD084EF36f8F5353f70498cD84cb8D2B844C120a8
đ New CrowdfundingCampaign deployed at: 0x060B748eC3512795E94045c406CFd5877DD84e4D
â
Deployment and campaign creation complete!
diff --git a/content/00.build/10.quick-start/_hello-zksync/_foundry_deploy_contract.md b/content/00.build/10.quick-start/_hello-zksync/_foundry_deploy_contract.md
index 133dfd28..5b37bf26 100644
--- a/content/00.build/10.quick-start/_hello-zksync/_foundry_deploy_contract.md
+++ b/content/00.build/10.quick-start/_hello-zksync/_foundry_deploy_contract.md
@@ -84,7 +84,7 @@ Owned and deployed with a set funding goal, it features:
- The `contribute` method to log funds, triggering `ContributionReceived` and `GoalReached` events.
- The `withdrawFunds` method, allowing the owner to collect accumulated funds post-goal achievement.
-Smart contracts deployed to ZKsync must be compiled using our custom compiler.
+Smart contracts deployed to zkSync must be compiled using our custom compiler.
For this particular guide we are making use of `zksolc`.
To compile the contracts in the project, run the following command:
@@ -102,7 +102,7 @@ of Solidity files compiled.
[â ] Compiling 2 files with 0.8.20
[â ] Solc 0.8.20 finished in 736.48ms
Compiler run successful!
-Compiling contracts for ZKsync Era with zksolc v1.4.0
+Compiling contracts for zkSync Era with zksolc v1.4.0
```
The compiled zkEVM artifacts will be located in the `/zkout` folder, and the solc artifacts will be
diff --git a/content/00.build/10.quick-start/_hello-zksync/_hardhat_deploy_contract.md b/content/00.build/10.quick-start/_hello-zksync/_hardhat_deploy_contract.md
index 03a254bb..655fe8c1 100644
--- a/content/00.build/10.quick-start/_hello-zksync/_hardhat_deploy_contract.md
+++ b/content/00.build/10.quick-start/_hello-zksync/_hardhat_deploy_contract.md
@@ -87,7 +87,7 @@ Upon successful compilation, you'll receive output detailing the
of Solidity files compiled.
```bash
-Compiling contracts for ZKsync Era with zksolc v1.4.0 and solc v0.8.17
+Compiling contracts for zkSync Era with zksolc v1.4.0 and solc v0.8.17
Compiling 1 Solidity file
Successfully compiled 1 Solidity file
```
@@ -167,7 +167,7 @@ Estimated deployment cost: 0.000501 ETH
Requesting contract verification...
Your verification ID is: 10067
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
```
𼳠Congratulations! Your smart contract is now deployed. đ
diff --git a/content/00.build/10.quick-start/_paymasters/_approval_paymaster_flow.md b/content/00.build/10.quick-start/_paymasters/_approval_paymaster_flow.md
index 4c20996e..13268742 100644
--- a/content/00.build/10.quick-start/_paymasters/_approval_paymaster_flow.md
+++ b/content/00.build/10.quick-start/_paymasters/_approval_paymaster_flow.md
@@ -1,6 +1,6 @@
---
title: Approval Paymaster
-description: Learn to deploy contract factories in the ZKsync environment.
+description: Learn to deploy contract factories in the zkSync environment.
---
Run the following command in your terminal to initialize the project.
@@ -159,7 +159,7 @@ Upon successful compilation, you'll receive output detailing the
of Solidity files compiled.
```bash
-Compiling contracts for ZKsync Era with zksolc v1.4.0 and solc v0.8.17
+Compiling contracts for zkSync Era with zksolc v1.4.0 and solc v0.8.17
Compiling 1 Solidity file
Successfully compiled 1 Solidity file
```
@@ -255,7 +255,7 @@ Estimated deployment cost: 0.0006278488 ETH
Requesting contract verification...
Your verification ID is: 10923
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
Paymaster ETH balance is now 5000000000000000
```
diff --git a/content/00.build/10.quick-start/_paymasters/_general_paymaster_flow.md b/content/00.build/10.quick-start/_paymasters/_general_paymaster_flow.md
index 30d1cdbb..1bb732fc 100644
--- a/content/00.build/10.quick-start/_paymasters/_general_paymaster_flow.md
+++ b/content/00.build/10.quick-start/_paymasters/_general_paymaster_flow.md
@@ -1,6 +1,6 @@
---
title: General Paymaster
-description: Learn to deploy contract factories in the ZKsync environment.
+description: Learn to deploy contract factories in the zkSync environment.
---
Run the following command in your terminal to initialize the project.
@@ -130,7 +130,7 @@ Upon successful compilation, you'll receive output detailing the
of Solidity files compiled.
```bash
-Compiling contracts for ZKsync Era with zksolc v1.4.0 and solc v0.8.17
+Compiling contracts for zkSync Era with zksolc v1.4.0 and solc v0.8.17
Compiling 4 Solidity file
Successfully compiled 4 Solidity file
```
@@ -224,7 +224,7 @@ Estimated deployment cost: 0.0004922112 ETH
Requesting contract verification...
Your verification ID is: 10634
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
Paymaster ETH balance is now 5000000000000000
```
diff --git a/content/00.build/10.quick-start/_testing/_foundry_contract_testing.md b/content/00.build/10.quick-start/_testing/_foundry_contract_testing.md
index b770eef5..c791930c 100644
--- a/content/00.build/10.quick-start/_testing/_foundry_contract_testing.md
+++ b/content/00.build/10.quick-start/_testing/_foundry_contract_testing.md
@@ -85,7 +85,7 @@ reliability of the contract.
### Compile 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.
For this particular guide we are making use of `zksolc`.
To compile the contracts in the project, run the following command:
@@ -103,7 +103,7 @@ of Solidity files compiled.
[â ] Compiling 22 files with 0.8.20
[â ] Solc 0.8.20 finished in 736.48ms
Compiler run successful!
-Compiling contracts for ZKsync Era with zksolc v1.4.0
+Compiling contracts for zkSync Era with zksolc v1.4.0
```
The compiled zkEVM artifacts will be located in the `/zkout` folder, and the solc artifacts will be
diff --git a/content/00.build/10.quick-start/_testing/_hardhat_contract_testing.md b/content/00.build/10.quick-start/_testing/_hardhat_contract_testing.md
index cfac6830..e4cff8ea 100644
--- a/content/00.build/10.quick-start/_testing/_hardhat_contract_testing.md
+++ b/content/00.build/10.quick-start/_testing/_hardhat_contract_testing.md
@@ -20,7 +20,7 @@ which operates seamlessly within a separate process for an optimized testing wor
If you have not set up your local era node yet, follow the instructions in the [Getting Started](/build/quick-start#setup-era-local-node-optional) section.
Within the `hardhat.config.ts`, you'll observe the `zksync` flag set to `true` under the
-`hardhat` network, indicating the integration with ZKsync's testing environment.
+`hardhat` network, indicating the integration with zkSync's testing environment.
```typescript [hardhat.config.ts]
hardhat: {
@@ -131,7 +131,7 @@ Upon successful compilation, you'll receive output detailing the
of Solidity files compiled.
```bash
-Compiling contracts for ZKsync Era with zksolc v1.4.0 and solc v0.8.17
+Compiling contracts for zkSync Era with zksolc v1.4.0 and solc v0.8.17
Compiling 2 Solidity file
Successfully compiled 2 Solidity file
```
diff --git a/content/00.build/10.quick-start/_upgrading/_beacon/_hardhat_beacon_contract_upgradability.md b/content/00.build/10.quick-start/_upgrading/_beacon/_hardhat_beacon_contract_upgradability.md
index 90bf3340..96354f99 100644
--- a/content/00.build/10.quick-start/_upgrading/_beacon/_hardhat_beacon_contract_upgradability.md
+++ b/content/00.build/10.quick-start/_upgrading/_beacon/_hardhat_beacon_contract_upgradability.md
@@ -112,7 +112,7 @@ Upon successful compilation, you'll receive output detailing the
of Solidity files compiled.
```bash
-Compiling contracts for ZKsync Era with zksolc v1.4.0 and solc v0.8.17
+Compiling contracts for zkSync Era with zksolc v1.4.0 and solc v0.8.17
Compiling 3 Solidity file
Successfully compiled 3 Solidity file
```
@@ -266,7 +266,7 @@ Upon successful compilation, you'll receive output detailing the
of Solidity files compiled.
```bash
-Compiling contracts for ZKsync Era with zksolc v1.4.0 and solc v0.8.17
+Compiling contracts for zkSync Era with zksolc v1.4.0 and solc v0.8.17
Compiling 4 Solidity file
Successfully compiled 4 Solidity file
```
@@ -405,13 +405,13 @@ Upon successful verification, you'll receive output detailing the verification p
```bash
Verifying implementation: 0x58BD5adb462CF087E5838d53aE38A3Fe0EAf7A31
Your verification ID is: 10547
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
Verifying beacon: 0x26410Bebf5Df7398DCBC5f00e9EBBa0Ddf471C72
Your verification ID is: 10548
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
Verifying beacon proxy: 0xD58FA9Fb362Abf69cFc68A3545fD227165DAc167
Your verification ID is: 10549
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
```
đ Congratulations! The `CrowdfundingCampaignV2` contract has been upgraded and verified!
diff --git a/content/00.build/10.quick-start/_upgrading/_transparent/_hardhat_transparent_contract_upgradability.md b/content/00.build/10.quick-start/_upgrading/_transparent/_hardhat_transparent_contract_upgradability.md
index a4383b8f..83173651 100644
--- a/content/00.build/10.quick-start/_upgrading/_transparent/_hardhat_transparent_contract_upgradability.md
+++ b/content/00.build/10.quick-start/_upgrading/_transparent/_hardhat_transparent_contract_upgradability.md
@@ -116,7 +116,7 @@ Upon successful compilation, you'll receive output detailing the
of Solidity files compiled.
```bash
-Compiling contracts for ZKsync Era with zksolc v1.4.0 and solc v0.8.17
+Compiling contracts for zkSync Era with zksolc v1.4.0 and solc v0.8.17
Compiling 3 Solidity file
Successfully compiled 3 Solidity file
```
@@ -152,7 +152,7 @@ export default async function (hre: HardhatRuntimeEnvironment) {
**Key Components:**
- **`hre.zkUpgrades.deployProxy`**: The method call to deploy the `CrowdfundingCampaign`
-contract via a transparent proxy, leveraging Hardhat's runtime environment for ZKsync upgrades.
+contract via a transparent proxy, leveraging Hardhat's runtime environment for zkSync upgrades.
This ensures the deployed contract can be upgraded in the future without losing its state or funds.
- **`initializer`**: Specifies the initialization method of the contract, `initialize` in this case,
which is required for setting up the proxy's state upon deployment.
@@ -261,7 +261,7 @@ Upon successful compilation, you'll receive output detailing the
of Solidity files compiled.
```bash
-Compiling contracts for ZKsync Era with zksolc v1.4.0 and solc v0.8.17
+Compiling contracts for zkSync Era with zksolc v1.4.0 and solc v0.8.17
Compiling 4 Solidity file
Successfully compiled 4 Solidity file
```
@@ -389,13 +389,13 @@ Upon successful verification, you'll receive output detailing the verification p
```bash
Verifying implementation: 0x58BD5adb462CF087E5838d53aE38A3Fe0EAf7A31
Your verification ID is: 10543
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
Verifying proxy: 0x68E8533acE01019CB8D07Eca822369D5De71b74D
Your verification ID is: 10544
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
Verifying proxy admin: 0x05198D9f93cBDfa3e332776019115512d8e0c809
Your verification ID is: 10545
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
```
đ Congratulations! The `CrowdfundingCampaignV2` contract has been upgraded and verified!
diff --git a/content/00.build/10.quick-start/_upgrading/_uups/_hardhat_uups_contract_upgradability.md b/content/00.build/10.quick-start/_upgrading/_uups/_hardhat_uups_contract_upgradability.md
index 100272b0..c5b84e0a 100644
--- a/content/00.build/10.quick-start/_upgrading/_uups/_hardhat_uups_contract_upgradability.md
+++ b/content/00.build/10.quick-start/_upgrading/_uups/_hardhat_uups_contract_upgradability.md
@@ -122,7 +122,7 @@ Upon successful compilation, you'll receive output detailing the
of Solidity files compiled.
```bash
-Compiling contracts for ZKsync Era with zksolc v1.4.0 and solc v0.8.17
+Compiling contracts for zkSync Era with zksolc v1.4.0 and solc v0.8.17
Compiling 4 Solidity file
Successfully compiled 4 Solidity file
```
@@ -272,7 +272,7 @@ Upon successful compilation, you'll receive output detailing the
of Solidity files compiled.
```bash
-Compiling contracts for ZKsync Era with zksolc v1.4.0 and solc v0.8.17
+Compiling contracts for zkSync Era with zksolc v1.4.0 and solc v0.8.17
Compiling 4 Solidity file
Successfully compiled 4 Solidity file
```
@@ -392,10 +392,10 @@ Upon successful verification, you'll receive output detailing the verification p
```bash
Verifying implementation: 0x9BE22706966D717d7b0C8aEC99A1a9d1b3bFeC50
Your verification ID is: 10618
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
Verifying proxy: 0x91921fDb0F8942c18eCeE4E3896b369ca0650483
Your verification ID is: 10619
-Contract successfully verified on ZKsync block explorer!
+Contract successfully verified on zkSync block explorer!
```
đ Congratulations! The `CrowdfundingCampaignV2_UUPS` contract has been upgraded and verified!
diff --git a/content/00.build/40.tooling/00.zksync-block-explorers.md b/content/00.build/40.tooling/00.zksync-block-explorers.md
index 029e708e..f0c9578b 100644
--- a/content/00.build/40.tooling/00.zksync-block-explorers.md
+++ b/content/00.build/40.tooling/00.zksync-block-explorers.md
@@ -1,31 +1,31 @@
---
title: Block Explorers
-description: Learn about the official and 3rd party resources for exploring the ZKsync Era network.
+description: Learn about the official and 3rd party resources for exploring the zkSync Era network.
---
-The [ZKsync Era Block Explorer](%%zk_mainnet_block_explorer_url%%)
-details comprehensive data about transactions, blocks, batches, wallets, tokens, and smart contracts on the ZKsync Era network.
+The [zkSync Era Block Explorer](%%zk_mainnet_block_explorer_url%%)
+details comprehensive data about transactions, blocks, batches, wallets, tokens, and smart contracts on the zkSync Era network.
## Block Explorer API
-Weâve developed the ZKsync Era Block Explorer API for developers to access ZKsync Era Block Explorer data directly via HTTP requests.
+Weâve developed the zkSync Era Block Explorer API for developers to access zkSync Era Block Explorer data directly via HTTP requests.
- [Mainnet Block Explorer API](https://block-explorer-api.mainnet.zksync.io/docs)
- [Testnet Block Explorer API](https://block-explorer-api.sepolia.zksync.dev/docs)
The API provides various endpoints for many use cases you might want in your app.
It is compatible with [Etherscan API](https://docs.etherscan.io/),
-which makes it easy to transition your existing apps to ZKsync Era network.
+which makes it easy to transition your existing apps to zkSync Era network.
-Feel free to contribute and create issues and feature requests in [ZKsync Era Block Explorer GitHub repo](%%zk_git_repo_block-explorer%%).
+Feel free to contribute and create issues and feature requests in [zkSync Era Block Explorer GitHub repo](%%zk_git_repo_block-explorer%%).
## Other block explorers
-A full list of ZKsync block explorers can be found on the ZKsync website's [Block Explorers page](https://zksync.io/explore#explorers).
+A full list of zkSync block explorers can be found on the zkSync website's [Block Explorers page](https://zksync.io/explore#explorers).
-### Etherscan - ZKsync Era Explorer
+### Etherscan - zkSync Era Explorer
-Etherscan allows you to explore and search the ZKsync Era network
+Etherscan allows you to explore and search the zkSync Era network
for transactions, addresses, tokens, prices and other activities taking place on the Network.
- [Etherscan Mainnet](https://era.zksync.network/)
@@ -33,21 +33,21 @@ for transactions, addresses, tokens, prices and other activities taking place on
### L2Scan
-L2Scan is the open source block explorer for ZKsync by the Unifra team
+L2Scan is the open source block explorer for zkSync by the Unifra team
- [L2Scan Mainnet](https://zksync-era.l2scan.co/)
- [L2Scan Testnet](https://zksync-era-sepolia.l2scan.co/)
### Blockscout
-Blockscout is a blockchain explorer for inspecting, analyzing, and interacting with ZKsync.
+Blockscout is a blockchain explorer for inspecting, analyzing, and interacting with zkSync.
- [Blockscout Mainnet](https://zksync.blockscout.com/)
- [Blockscout Testnet](https://zksync-sepolia.blockscout.com/)
### Hyperscan
-Routescan's ZKsync Explorer allows you to explore and search for transactions, addresses, tokens, prices and other activities taking place on ZKsync.
+Routescan's zkSync Explorer allows you to explore and search for transactions, addresses, tokens, prices and other activities taking place on zkSync.
- [Hyperscan](https://hyperscan.xyz/)
diff --git a/content/00.build/40.tooling/10.zksync-cli/00.index.md b/content/00.build/40.tooling/10.zksync-cli/00.index.md
index 40d827d3..b3a8a4e9 100644
--- a/content/00.build/40.tooling/10.zksync-cli/00.index.md
+++ b/content/00.build/40.tooling/10.zksync-cli/00.index.md
@@ -1,9 +1,9 @@
---
title: Getting Started
-description: Learn how to use the powerful ZKsync CLI tool for local development.
+description: Learn how to use the powerful zkSync CLI tool for local development.
---
-The ZKsync Command Line Interface (CLI) is a powerful tool designed to simplify the development and interaction with ZKsync from a command shell.
+The zkSync Command Line Interface (CLI) is a powerful tool designed to simplify the development and interaction with zkSync from a command shell.
## Usage
@@ -31,21 +31,21 @@ npm update -g zksync-cli
## Available Commands
-- [`dev`](zksync-cli/zksync-cli-dev): Start a local development environment with ZKsync and Ethereum nodes.
+- [`dev`](zksync-cli/zksync-cli-dev): Start a local development environment with zkSync and Ethereum nodes.
- [`create`](zksync-cli/zksync-cli-create): Scaffold new projects using templates for frontend, contracts, and scripting.
-- [`contract`](zksync-cli/zksync-cli-contract): Read and write data to ZKsync contracts without building UI.
+- [`contract`](zksync-cli/zksync-cli-contract): Read and write data to zkSync contracts without building UI.
- [`transaction`](zksync-cli/zksync-cli-transaction): Fetch and display detailed information about a specific transaction.
-- [`wallet`](zksync-cli/zksync-cli-wallet): Manage ZKsync wallet assets, including transfers and balance checks.
-- [`bridge`](zksync-cli/zksync-cli-bridge): Perform deposits and withdrawals between Ethereum and ZKsync.
+- [`wallet`](zksync-cli/zksync-cli-wallet): Manage zkSync wallet assets, including transfers and balance checks.
+- [`bridge`](zksync-cli/zksync-cli-bridge): Perform deposits and withdrawals between Ethereum and zkSync.
- [`config chains`](zksync-cli/zksync-cli-config-chains): Add or edit custom chains for flexible testing and development.
## Further Assistance
Need help? Join our [GitHub Discussions](%%zk_git_repo_zksync-developers%%/discussions/)
-to ask questions, share your experiences, and connect with the ZKsync community.
+to ask questions, share your experiences, and connect with the zkSync community.
## Source Code
-The [ZKsync CLI project](%%zk_git_repo_zksync-cli%%)
+The [zkSync CLI project](%%zk_git_repo_zksync-cli%%)
is open-source and available on GitHub under the MIT License.
Feel free to contribute, report issues, or suggest new features to help us improve the tool for everyone.
diff --git a/content/00.build/40.tooling/10.zksync-cli/01.troubleshooting.md b/content/00.build/40.tooling/10.zksync-cli/01.troubleshooting.md
index 528241b8..01923afe 100644
--- a/content/00.build/40.tooling/10.zksync-cli/01.troubleshooting.md
+++ b/content/00.build/40.tooling/10.zksync-cli/01.troubleshooting.md
@@ -3,7 +3,7 @@ title: Troubleshooting
description: Get help with issues related to zksync-cli.
---
-Encountering issues with ZKsync CLI? Here are some common problems and step-by-step recommendations for resolving them:
+Encountering issues with zkSync CLI? Here are some common problems and step-by-step recommendations for resolving them:
## `command not found: zksync-cli`
@@ -16,7 +16,7 @@ have the package installed locally or were using the `npx zksync-cli` command.
If you encounter an `unknown command` error, follow these steps:
-a. **Check the ZKsync CLI Version**
+a. **Check the zkSync CLI Version**
- Run `zksync-cli --version` to check your current version.
- Compare it with the latest version available on [npm](https://www.npmjs.com/package/zksync-cli).
@@ -50,7 +50,7 @@ e. **Use the Latest Version**
If `zksync-cli` is not running the latest version:
- Refer to the [instructions for `unknown command` Error](/build/tooling/zksync-cli/troubleshooting#unknown-command-error)
-above to check and update your ZKsync CLI version.
+above to check and update your zkSync CLI version.
---
diff --git a/content/00.build/40.tooling/10.zksync-cli/10.zksync-cli-dev.md b/content/00.build/40.tooling/10.zksync-cli/10.zksync-cli-dev.md
index 87f9fb57..5ff8e7a4 100644
--- a/content/00.build/40.tooling/10.zksync-cli/10.zksync-cli-dev.md
+++ b/content/00.build/40.tooling/10.zksync-cli/10.zksync-cli-dev.md
@@ -4,7 +4,7 @@ description: Manage a local node with zksync-cli.
---
Utilize `zksync-cli` to effortlessly initiate a local development environment.
-Using the command, `zksync-cli dev start`, you can spin up local ZKsync and Ethereum nodes, along with Block Explorer, Wallet, and Bridge
+Using the command, `zksync-cli dev start`, you can spin up local zkSync and Ethereum nodes, along with Block Explorer, Wallet, and Bridge
for a seamless development experience.
## Prerequisites
diff --git a/content/00.build/40.tooling/10.zksync-cli/20.zksync-cli-create.md b/content/00.build/40.tooling/10.zksync-cli/20.zksync-cli-create.md
index 900af702..3bb009d9 100644
--- a/content/00.build/40.tooling/10.zksync-cli/20.zksync-cli-create.md
+++ b/content/00.build/40.tooling/10.zksync-cli/20.zksync-cli-create.md
@@ -4,7 +4,7 @@ description: Use the zksync-cli create command to streamline project setup.
---
The `zksync-cli create` command streamlines project setup by offering templates for frontend development, smart contracts,
-and scripting for ZKsync, enabling rapid deployment and development.
+and scripting for zkSync, enabling rapid deployment and development.
### Prerequisites
@@ -33,7 +33,7 @@ Utilize tools like Hardhat to streamline your workflow.
### Scripting
-Enhance your project with Node.js scripting templates for automated interactions and advanced ZKsync operations.
+Enhance your project with Node.js scripting templates for automated interactions and advanced zkSync operations.
Includes examples of wallet or contract interactions using viem, ethers, or web3.js.
[zksync-scripting-templates repo](%%zk_git_repo_zksync-scripting-templates%%#readme)
diff --git a/content/00.build/40.tooling/10.zksync-cli/30.zksync-cli-contract.md b/content/00.build/40.tooling/10.zksync-cli/30.zksync-cli-contract.md
index 449e890a..11cd05d3 100644
--- a/content/00.build/40.tooling/10.zksync-cli/30.zksync-cli-contract.md
+++ b/content/00.build/40.tooling/10.zksync-cli/30.zksync-cli-contract.md
@@ -3,7 +3,7 @@ title: zksync-cli contract
description: Interact with contracts using the zksync-cli contract command.
---
-The `zksync-cli contract` command comes with actions to read, write and encode smart contracts on ZKsync.
+The `zksync-cli contract` command comes with actions to read, write and encode smart contracts on zkSync.
These commands automate tasks such as method verification, ABI handling, output decoding, and proxy contract processing.
::callout{icon="i-heroicons-light-bulb" color="blue"}
diff --git a/content/00.build/40.tooling/10.zksync-cli/40.zksync-cli-transaction.md b/content/00.build/40.tooling/10.zksync-cli/40.zksync-cli-transaction.md
index c52bff58..f1fe62a5 100644
--- a/content/00.build/40.tooling/10.zksync-cli/40.zksync-cli-transaction.md
+++ b/content/00.build/40.tooling/10.zksync-cli/40.zksync-cli-transaction.md
@@ -80,7 +80,7 @@ zksync-cli transaction info --full
### Displaying raw JSON response
-To view the raw JSON response from the ZKsync node, use the `--raw` option:
+To view the raw JSON response from the zkSync node, use the `--raw` option:
```bash
zksync-cli transaction info --raw
diff --git a/content/00.build/40.tooling/10.zksync-cli/50.zksync-cli-wallet.md b/content/00.build/40.tooling/10.zksync-cli/50.zksync-cli-wallet.md
index cafef4b9..6ff82343 100644
--- a/content/00.build/40.tooling/10.zksync-cli/50.zksync-cli-wallet.md
+++ b/content/00.build/40.tooling/10.zksync-cli/50.zksync-cli-wallet.md
@@ -1,9 +1,9 @@
---
title: zksync-cli wallet
-description: Manage your wallet on ZKsync using zksync-cli.
+description: Manage your wallet on zkSync using zksync-cli.
---
-Utilize the `zksync-cli wallet` command for an easy way to manage your assets on ZKsync, like token transfers and balance check.
+Utilize the `zksync-cli wallet` command for an easy way to manage your assets on zkSync, like token transfers and balance check.
## Commands
@@ -12,7 +12,7 @@ Utilize the `zksync-cli wallet` command for an easy way to manage your assets on
## Transfer
-To transfer ETH between accounts on ZKsync, use the following command:
+To transfer ETH between accounts on zkSync, use the following command:
```bash
zksync-cli wallet transfer
diff --git a/content/00.build/40.tooling/10.zksync-cli/60.zksync-cli-bridge.md b/content/00.build/40.tooling/10.zksync-cli/60.zksync-cli-bridge.md
index 6d798ff1..24453199 100644
--- a/content/00.build/40.tooling/10.zksync-cli/60.zksync-cli-bridge.md
+++ b/content/00.build/40.tooling/10.zksync-cli/60.zksync-cli-bridge.md
@@ -3,7 +3,7 @@ title: zksync-cli bridge
description: Facilitate bridge operations between L1 and L2 using zksync-cli.
---
-Facilitate bridge operations between Ethereum (L1) and ZKsync (L2), including token deposits, withdrawals,
+Facilitate bridge operations between Ethereum (L1) and zkSync (L2), including token deposits, withdrawals,
and finalizing withdrawals with the `zksync-cli bridge` command.
## Commands
diff --git a/content/00.build/40.tooling/10.zksync-cli/70.zksync-cli-config-chains.md b/content/00.build/40.tooling/10.zksync-cli/70.zksync-cli-config-chains.md
index 146e6446..6d50e58f 100644
--- a/content/00.build/40.tooling/10.zksync-cli/70.zksync-cli-config-chains.md
+++ b/content/00.build/40.tooling/10.zksync-cli/70.zksync-cli-config-chains.md
@@ -4,7 +4,7 @@ description: Configure custom chains to use with zksync-cli.
---
Specify your own chain configuration by adding or editing custom chains to use on `zksync-cli`.
-This feature is essential for developers looking to interact with ZK Stack Hyperchains.
+This feature is essential for developers looking to interact with ZK Stack Chains.
## Configuring Custom Chains
diff --git a/content/00.build/40.tooling/10.zksync-cli/_dir.yml b/content/00.build/40.tooling/10.zksync-cli/_dir.yml
index aad1b98c..acdf43cf 100644
--- a/content/00.build/40.tooling/10.zksync-cli/_dir.yml
+++ b/content/00.build/40.tooling/10.zksync-cli/_dir.yml
@@ -1 +1 @@
-title: ZKsync CLI
+title: zkSync CLI
diff --git a/content/00.build/40.tooling/20.hardhat/10.getting-started.md b/content/00.build/40.tooling/20.hardhat/10.getting-started.md
index 6c1b4347..c4142a40 100644
--- a/content/00.build/40.tooling/20.hardhat/10.getting-started.md
+++ b/content/00.build/40.tooling/20.hardhat/10.getting-started.md
@@ -1,11 +1,11 @@
---
title: Getting started
-description: Learn how to use Hardhat with ZKsync.
+description: Learn how to use Hardhat with zkSync.
---
::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
If you are using Windows, we strongly recommend you use Windows Subsystem for Linux (also known as WSL 2).
-You can use `Hardhat` and `Hardhat ZKsync plugins` without it, but it will work better if you use it.
+You can use `Hardhat` and `Hardhat zkSync plugins` without it, but it will work better if you use it.
To install Node.js using WSL 2, please read this [guide](https://learn.microsoft.com/en-us/windows/dev-environment/javascript/nodejs-on-wsl).
::
@@ -13,8 +13,10 @@ To install Node.js using WSL 2, please read this [guide](https://learn.microsoft
[Hardhat](https://hardhat.org) is an Ethereum development environment, designed for easy smart contract development.
One of its most prominent features is extendability: you can easily add new plugins to your hardhat project.
-ZKsync Era has the following official plugins for Hardhat:
+zkSync Era has the following official plugins for Hardhat:
+- [@matterlabs/hardhat-zksync](./hardhat-zksync.md) - used to access to all of the supported plugins and to use them
+as needed in your project. This should be the primary plugin most developers will need to use.
- [@matterlabs/hardhat-zksync-solc](./hardhat-zksync-solc.md) - used to compile contracts written in Solidity.
- [@matterlabs/hardhat-zksync-vyper](./hardhat-zksync-vyper.md) - used to compile contracts written in Vyper.
- [@matterlabs/hardhat-zksync-deploy](./hardhat-zksync-deploy.md) - used to deploy smart contracts.
@@ -22,14 +24,13 @@ ZKsync Era has the following official plugins for Hardhat:
- [@matterlabs/hardhat-zksync-verify-vyper](./hardhat-zksync-verify-vyper.md) - used to verify vyper smart contracts.
- [@matterlabs/hardhat-zksync-upgradable](./hardhat-zksync-upgradable.md) - used to deploy, update, and verify proxy smart contracts.
- [@matterlabs/hardhat-zksync-ethers](./hardhat-zksync-ethers.md) - wrapper around zksync-ethers with some extra Hardhat-specific functionality.
-- [@matterlabs/hardhat-zksync-node](./hardhat-zksync-node.md) - used to run the ZKsync era-test-node locally.
-- [@matterlabs/hardhat-zksync](./hardhat-zksync.md) - used to access to all of the supported plugins and to use them as needed in your project.
+- [@matterlabs/hardhat-zksync-node](./hardhat-zksync-node.md) - used to run the zkSync era-test-node locally.
-Along with the official plugins, there are [other plugins from the community](/build/tooling/hardhat/other-plugins) that you can use with ZKsync Era.
+Along with the official plugins, there are [other plugins from the community](/build/tooling/hardhat/other-plugins) that you can use with zkSync Era.
To learn more about Hardhat itself, check out [the official documentation](https://hardhat.org/getting-started/).
-This tutorial shows you how to setup a ZKsync Era Solidity project with Hardhat using the [ZKsync CLI](/build/tooling/zksync-cli).
+This tutorial shows you how to setup a zkSync Era Solidity project with Hardhat using the [zkSync CLI](/build/tooling/zksync-cli).
If you are using Vyper, check out the [Vyper plugin documentation](/build/tooling/hardhat/hardhat-zksync-vyper)
or the [vyper-example](%%zk_git_repo_hardhat-zksync%%/tree/main/examples/vyper-example) in GitHub!
@@ -38,29 +39,25 @@ or the [vyper-example](%%zk_git_repo_hardhat-zksync%%/tree/main/examples/vyper-e
- Make sure your machine satisfies the [system requirements](%%zk_git_repo_era-compiler-solidity%%/tree/main#system-requirements).
- You have Node installed and have `yarn` or `npm` package manager.
-- You are already familiar with deploying smart contracts on ZKsync.
-
-
+- You are already familiar with deploying smart contracts on zkSync. If not, please refer to the first section of the [Contract Deployment](/build/developer-reference/ethereum-differences/contract-deployment)
- A wallet with sufficient Sepolia `ETH` on Ethereum and %%zk_testnet_name%% to pay for deploying smart contracts.
-
-
+- 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.
- 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
Skip the hassle for test ETH by using `zksync-cli` for local testing.
-Use the `npx zksync-cli dev start` command to initialize a local ZKsync development environment, which includes local Ethereum and ZKsync nodes.
+Use the `npx zksync-cli dev start` command 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).
::
::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
-
-
-- Contracts compiled with other compilers will fail to deploy to ZKsync Era.
+- Contracts must be compiled using the
+[official zkSync Era compilers](/zk-stack/components/compiler/toolchain/overview), with their respective Hardhat plugins.
+
+- Contracts compiled with other compilers will fail to deploy to zkSync Era.
::
## Project setup
@@ -88,9 +85,9 @@ If you want to migrate an existing project, please check the [project migration
## Hardhat configuration
-The `hardhat.config.ts` file contains some ZKsync Era specific configurations:
+The `hardhat.config.ts` file contains some zkSync Era specific configurations:
-The ZKsync Era deployment and compiler plugin imports:
+The zkSync Era deployment and compiler plugin imports:
#### Solidity project
@@ -145,8 +142,8 @@ const zkSyncTestnet =
```
::callout{icon="i-heroicons-information-circle" color="blue"}
-For local ZKsync testing, modify `url` and `ethNetwork` in `hardhat.config.ts`
-to align with your local ZKsync and Ethereum node's L2 and L1 RPC URLs, respectively.
+For local zkSync testing, modify `url` and `ethNetwork` in `hardhat.config.ts`
+to align with your local zkSync and Ethereum node's L2 and L1 RPC URLs, respectively.
::
::callout{icon="i-heroicons-information-circle" color="blue"}
@@ -230,7 +227,7 @@ export default async function (hre: HardhatRuntimeEnvironment) {
// token: utils.ETH_ADDRESS,
// amount: deploymentFee.mul(2),
// });
- // // Wait until the deposit is processed on ZKsync
+ // // Wait until the deposit is processed on zkSync
// await depositHandle.wait();
// Deploy this contract. The returned object will be of a `Contract` type, similar to ones in `ethers`.
@@ -240,7 +237,7 @@ export default async function (hre: HardhatRuntimeEnvironment) {
const greeterContract = await deployer.deploy(artifact, [greeting]);
- //obtain the Constructor Arguments
+ // obtain the Constructor Arguments
console.log("constructor args:" + greeterContract.interface.encodeDeploy([greeting]));
// Show the contract info.
@@ -302,7 +299,7 @@ The template project contains another script to interact with the contract.
if (!PRIVATE_KEY) throw "âď¸ Private key not detected! Add it to the .env file!";
- // Address of the contract on ZKsync testnet
+ // Address of the contract on zkSync testnet
const CONTRACT_ADDRESS = "";
if (!CONTRACT_ADDRESS) throw "âď¸ Contract address not provided";
@@ -357,11 +354,8 @@ The template project contains another script to interact with the contract.
⨠Done in 14.32s.
```
-
+- To learn more about the zkSync Hardhat plugins check out the [plugins documentation](/build/tooling/hardhat/getting-started).
+- If you want to know more about how to interact with zkSync using Javascript,
+check out the [zksync-ethers Javascript SDK documentation](https://zksync-sdk-docs-staging.web.app/ethers/v6/getting-started).
diff --git a/content/00.build/40.tooling/20.hardhat/120.hardhat-zksync-node.md b/content/00.build/40.tooling/20.hardhat/120.hardhat-zksync-node.md
index ca50a022..da625d2f 100644
--- a/content/00.build/40.tooling/20.hardhat/120.hardhat-zksync-node.md
+++ b/content/00.build/40.tooling/20.hardhat/120.hardhat-zksync-node.md
@@ -6,7 +6,7 @@ description:
This plugin is used to provide a convenient way to run ZKsync Era [In-memory node](/build/test-and-debug/in-memory-node) locally using hardhat.
::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
-The ZKsync Era In-memory node binaries are not supported on Windows at the moment.
+The zkSync Era In-memory node binaries are not supported on Windows at the moment.
As an alternative, users can utilize the Windows Subsystem for Linux (WSL).
::
@@ -66,8 +66,8 @@ npm run hardhat node-zksync
::
-This command runs a local ZKsync In-memory node by initiating a JSON-RPC server.
-It uses the provided or default configurations to set up and run the ZKsync node, allowing for blockchain operations in a local environment.
+This command runs a local zkSync In-memory node by initiating a JSON-RPC server.
+It uses the provided or default configurations to set up and run the zkSync node, allowing for blockchain operations in a local environment.
The command also handles tasks such as downloading the necessary JSON-RPC server binary if it's not already present.
- `--port` - Port on which the server should listen. Defaults to 8011.
diff --git a/content/00.build/40.tooling/20.hardhat/20.migrating-to-zksync.md b/content/00.build/40.tooling/20.hardhat/20.migrating-to-zksync.md
index d1d7fb79..61c94248 100644
--- a/content/00.build/40.tooling/20.hardhat/20.migrating-to-zksync.md
+++ b/content/00.build/40.tooling/20.hardhat/20.migrating-to-zksync.md
@@ -1,24 +1,24 @@
---
-title: Migrating to ZKsync
-description: Learn how to migrate an existing Hardhat project to ZKsync Era.
+title: Migrating to zkSync
+description: Learn how to migrate an existing Hardhat project to zkSync Era.
---
::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
If you are using Windows, we strongly recommend you use Windows Subsystem for Linux (also known as WSL 2).
-You can use `Hardhat` and `Hardhat ZKsync plugins` without it, but it will work better if you use it.
+You can use `Hardhat` and `Hardhat zkSync plugins` without it, but it will work better if you use it.
To install Node.js using WSL 2, please read this [guide](https://learn.microsoft.com/en-us/windows/dev-environment/javascript/nodejs-on-wsl).
::
-This guide shows you how to migrate an existing Hardhat project to ZKsync Era.
+This guide shows you how to migrate an existing Hardhat project to zkSync Era.
## Overview
-ZKsync Era offers [multiple Hardhat plugins](/build/tooling/hardhat/getting-started) with different features.
-This guide details the one you need to migrate your project to ZKsync Era.
+zkSync Era offers [multiple Hardhat plugins](/build/tooling/hardhat/getting-started) with different features.
+This guide details the one you need to migrate your project to zkSync Era.
::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
-**Non-default paths are not supported yet**
+#### Non-default paths are not supported yet
- Contract files must be included in the `contracts` folder and deployment scripts must be included in the `deploy` folder.
- Support for custom paths will be included in the future.
@@ -26,9 +26,7 @@ This guide details the one you need to migrate your project to ZKsync Era.
## Install dependencies
-
-
-Although ZKsync Era is compatible with Solidity and Vyper,
+Although zkSync Era is compatible with Solidity and Vyper,
the deployed bytecode and the deployment process is different from Ethereum or other EVM blockchains.
So the first step is to install the compiler and deployer Hardhat plugins:
@@ -36,12 +34,16 @@ If you're using Vyper, replace `@matterlabs/hardhat-zksync-solc` with `@matterla
::code-group
+```bash [npm]
+npm i -D @matterlabs/hardhat-zksync
+```
+
```bash [yarn]
yarn add -D @matterlabs/hardhat-zksync
```
-```bash [npm]
-npm i -D @matterlabs/hardhat-zksync
+```bash [pnpm]
+pnpm i -D @matterlabs/hardhat-zksync
```
```bash [bun]
@@ -58,7 +60,7 @@ In your `hardhat.config.ts` file import the installed dependencies:
import "@matterlabs/hardhat-zksync";
```
-Networks on ZKsync Era require two different URL endpoints: one for layer 1 (Ethereum or Sepolia), and one for layer 2 (ZKsync).
+Networks on zkSync Era require two different URL endpoints: one for layer 1 (Ethereum or Sepolia), and one for layer 2 (zkSync).
This is how you add the %%zk_testnet_name%% to your list of networks in the `hardhat.config.ts`:
```typescript
@@ -96,11 +98,11 @@ or [Vyper](/build/tooling/hardhat/hardhat-zksync-vyper) plugins.
### How to configure multiple compilation targets
-To configure the `hardhat.config.ts` file to target both ZKsync Era and other networks, do the following:
+To configure the `hardhat.config.ts` file to target both zkSync Era and other networks, do the following:
-1. In your `hardhat.config.ts`, configure the ZKsync Era network with `zksync: true`.
+1. In your `hardhat.config.ts`, configure the zkSync Era network with `zksync: true`.
2. Configure all other networks with `zksync: false`.
-3. Run the compilation or deployment scripts with the network flag: `yarn hardhat compile --network zkSyncTestnet` for ZKsync Era network
+3. Run the compilation or deployment scripts with the network flag: `yarn hardhat compile --network zkSyncTestnet` for zkSync Era network
or `yarn hardhat compile --network sepolia` for other networks, e.g sepolia.
```typescript
@@ -110,9 +112,9 @@ networks: {
zksync: false, // Set to false to target other networks.
},
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 identifier of the network (e.g. `mainnet` or `sepolia`)
- zksync: true, // Set to true to target ZKsync Era.
+ zksync: true, // Set to true to target zkSync Era.
}
},
@@ -162,7 +164,7 @@ export default config;
## Compile contracts
-To compile your contracts for ZKsync Era, run:
+To compile your contracts for zkSync Era, run:
::code-group
@@ -185,12 +187,10 @@ Find more info and examples about [compiling libraries here](/build/tooling/hard
## Deploy contracts
::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
-`hardhat-deploy` version `^0.11.26` supports deployments on ZKsync Era.
+`hardhat-deploy` version `^0.11.26` supports deployments on zkSync Era.
::
To deploy your contracts you need to use the `Deployer` class from the `hardhat-zksync` plugin.
-
-
Here is a basic deployment script for a `Greeter` contract:
@@ -270,7 +270,7 @@ Apart from the same classes and methods provided by ethers, zksync-ethers includ
To verify your contracts you have two options:
-
+
- 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 4a306f66..ce4c984b 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,10 +11,9 @@ 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.
-**Practically this means that libraries with public methods need to be deployed separately
-and their addresses passed as an argument when compiling the main contract.**
+**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.
## OpenZeppelin utility libraries
@@ -105,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
@@ -131,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/110.hardhat-zksync.md b/content/00.build/40.tooling/20.hardhat/35.hardhat-zksync.md
similarity index 95%
rename from content/00.build/40.tooling/20.hardhat/110.hardhat-zksync.md
rename to content/00.build/40.tooling/20.hardhat/35.hardhat-zksync.md
index 936d8b0a..3bc06b06 100644
--- a/content/00.build/40.tooling/20.hardhat/110.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 11fd4213..6b44efa6 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](https://docs.zksync.io/zk-stack/components/compiler/toolchain/solidity.html#limitations)
@@ -184,7 +184,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 a794b957..32973aba 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 c935573d..ffc9d809 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,19 +11,19 @@ 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.
- A wallet with sufficient Sepolia `ETH` on Ethereum and %%zk_testnet_name%% to pay for deploying smart contracts on testnet.
-- 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).
::
@@ -75,7 +75,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: {
@@ -83,7 +83,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
}
@@ -91,15 +91,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
@@ -158,14 +158,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.
*/
@@ -219,7 +219,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
@@ -236,8 +236,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
::
@@ -257,7 +257,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.
@@ -368,7 +368,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
@@ -418,7 +418,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,
}
@@ -579,14 +579,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.
::
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 aaa7a2b2..79a9cdc2 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 590dade9..f3fedd8b 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 dcee8df8..419ec7ab 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/20.hardhat/other-plugins.md b/content/00.build/40.tooling/20.hardhat/other-plugins.md
index ec1dbb60..2b6cf469 100644
--- a/content/00.build/40.tooling/20.hardhat/other-plugins.md
+++ b/content/00.build/40.tooling/20.hardhat/other-plugins.md
@@ -1,9 +1,9 @@
---
title: Hardhat Community Plugins
-description: Discover community plugins for Hardhat that work on ZKsync Era.
+description: Discover community plugins for Hardhat that work on zkSync Era.
---
-The following plugins were created by the community and tested on ZKsync Era.
+The following plugins were created by the community and tested on zkSync Era.
Feel free to suggest new plugins by [creating a issue(feat request) at this page](%%zk_git_repo_hardhat-zksync%%/issues/new?assignees=&labels=feat&projects=&template=feature_report.md&title=).
## Supported plugins
@@ -17,7 +17,7 @@ You can use it as a starting template for your projects.
Multiple tasks for advanced deployments.
-This plugin was [updated to support ZKsync Era](https://github.com/wighawag/hardhat-deploy/pull/437) on version `0.11.26`.
+This plugin was [updated to support zkSync Era](https://github.com/wighawag/hardhat-deploy/pull/437) on version `0.11.26`.
[More information](https://www.npmjs.com/package/hardhat-deploy)
@@ -31,7 +31,7 @@ Automatically generate TypeScript bindings for smart contracts.
Plugin used to deploy and update upgradable smart contracts (proxies).
Use the [hardhat-zksync-upgradable plugin](./hardhat-zksync-upgradable) which provides an easy-to-use interface
-for interacting with the OpenZeppelin Upgrades Plugins within a Hardhat environment on ZKsync.
+for interacting with the OpenZeppelin Upgrades Plugins within a Hardhat environment on zkSync.
### hardhat-chai-matchers
@@ -52,7 +52,7 @@ Different options to export smart contract ABIs.
### hardhat-gas-reporter
-
+
Users should consider this when analysing the report generated by this plugin.
@@ -81,14 +81,14 @@ To prevent this, please include the `--no-compile` flag: `yarn hardhat verify --
This plugin adds new methods that interact with the Hardhat network used for testing.
-However, we do not recommend using the Hardhat network for testing contracts that will be deployed on ZKsync Era.
+However, we do not recommend using the Hardhat network for testing contracts that will be deployed on zkSync Era.
::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
-The additional methods provided by this plugin are not compatible with the ZKsync Era in-memory node or docker setup yet.
+The additional methods provided by this plugin are not compatible with the zkSync Era in-memory node or docker setup yet.
Currently, we are working on adapting our in-memory node to ensure compatibility with hardhat-network-helpers.
::
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 e1eb771d..f6f9b4d1 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.
@@ -37,11 +37,11 @@ For more details and contributions, visit the [GitHub repository](%%zk_git_repo_
While `foundry-zksync` is **alpha stage**, there are some limitations to be aware of, but not limited to:
- **Compile Time**: Some users may experience slow compiling.
-- **Specific Foundry Features**: Currently features such as `coverage`, `--gas-report` or `--verify` may not work as intended.
+- **Specific Foundry Features**: Currently features such as `--gas-report` or `--verify` may not work as intended.
We are actively working on providing support for these feature types.
- **Compiling Libraries**: Compiling non-inlinable libraries requires deployment and adding to configuration.
-
-For more information please refer to [official docs](https://era.zksync.io/docs/tools/hardhat/compiling-libraries.html).
+
+For more information please refer to [official docs](/build/tooling/hardhat/compiling-libraries).
```toml
# In foundry.toml
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 579642d2..d29ed460 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,50 +1,59 @@
---
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
+## Prerequisites
The primary prerequisite for using `foundry-zksync` is the [Rust Compiler](https://www.rust-lang.org/tools/install).
-### Installation Guide
+## Installation Guide
-To integrate `foundry-zksync` into your projects, you have the flexibility to install its components individually or the entire suite at once.
-Follow the steps below to get started:
+To integrate `foundry-zksync` into your projects, you have the flexibility to install its components individually or
+the entire suite at once. Follow the steps below to get started:
-1. Clone the repository:
+**Step 1:** Clone the repository:
- ```bash
- git clone git@github.com:matter-labs/foundry-zksync.git
- ```
+```bash
+git clone git@github.com:matter-labs/foundry-zksync.git
+```
+
+**Step 2:** Navigate to the project directory:
+
+```bash
+cd foundry-zksync
+```
-2. Navigate to the project directory and switch to the main branch:
+**Step 3:** Run the Installer: Execute the script to install the foundry-zksync binaries forge and cast
- ```bash
- cd foundry-zksync && git checkout dev
- ```
+```bash
+./install-foundry-zksync
+```
-For component-specific installations:
+Once the `forge` and `cast` binaries are installed, you can start using `foundry-zksync`. Source your preferred
+profile or refresh your terminal window to activate the changes. You are now ready to begin working with `foundry-zksync`.
+
+For component-specific installations from source:
- **Forge**: To install, execute:
- ```bash
- cargo install --path ./crates/forge --profile local --force --locked
- ```
+```bash
+cargo install --path ./crates/forge --profile local --force --locked
+```
- **Cast**: To install, run:
- ```bash
- cargo install --path ./crates/cast --profile local --force --locked
- ```
+```bash
+cargo install --path ./crates/cast --profile local --force --locked
+```
For the entire suite:
- Execute the following command for a comprehensive installation:
- ```bash
- cargo build --release
- ```
+```bash
+cargo build --release
+```
Choose the installation that best fits your development needs.
@@ -71,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]
@@ -92,8 +101,8 @@ mode = "3"
### Running Tests
Use `forge test --zksync` to run tests written for your smart contracts.
-
-
+
+For an overview of how to write tests using `foundry-zksync` please refer to Foundry testing [here](/build/test-and-debug/foundry).
## Deploying Smart Contracts with `forge`
@@ -116,7 +125,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:
@@ -127,7 +136,7 @@ forge build --zksync
### Deployment with `forge create --zksync`
-`forge create --zksync` deploys smart contracts to ZKsync.
+`forge create --zksync` deploys smart contracts to zkSync.
**Usage:**
@@ -172,7 +181,7 @@ contract Greeter {
```bash
-forge create src/Greeter.sol:Greeter --constructor-args "Hello ZKsync" --private-key --rpc-url %%zk_testnet_rpc_url%% --chain %%zk_testnet_chain_id%% --zksync
+forge create src/Greeter.sol:Greeter --constructor-args "Hello zkSync" --private-key --rpc-url %%zk_testnet_rpc_url%% --chain %%zk_testnet_chain_id%% --zksync
```
### Deploying Factory Contracts
@@ -223,7 +232,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" --private-key --rpc-url %%zk_testnet_rpc_url%% --chain %%zk_testnet_chain_id%%
+cast send "CreateNewGreeter(string)" "zkSync Rules" --private-key --rpc-url %%zk_testnet_rpc_url%% --chain %%zk_testnet_chain_id%%
```
**Interact with `Greeter.sol`**
@@ -247,27 +256,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%%:**
@@ -287,7 +296,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
@@ -311,7 +320,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%%
@@ -330,8 +339,8 @@ cast send --rpc-url --chain %%zk_testnet_chain_id%%
+cast send 0xe34E488C1B0Fb372Cc4a5d39219261A5a6fc7996 "setGreeting(string)" "Hello, zkSync!" --rpc-url %%zk_testnet_rpc_url%% --private-key --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!".
Replace `` with your actual private key.
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 2da32046..9f7105a9 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
@@ -56,11 +56,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 77f24b5e..33dfd5cb 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,22 +3,22 @@ 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).
---
## 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%%
@@ -30,7 +30,7 @@ New to ZKsync development with Hardhat? Explore the [Getting Started section](/b
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
@@ -38,13 +38,13 @@ New to ZKsync development with Hardhat? Explore the [Getting Started section](/b
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.
::
@@ -62,9 +62,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
@@ -79,7 +79,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 20fff8e9..bdbf251e 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
@@ -6,7 +6,6 @@ description: Learn how to setup a local in-memory era_test_node.
This section provides instructions on setting up and using the In-Memory Node, `era_test_node`, for local testing.
It covers installation, network forking, transaction details viewing, replaying transactions, and testing local bootloader and system contracts.
-
::callout{icon="i-heroicons-information-circle-16-solid" color="amber"}
Please keep in mind that `era-test-node` is still in its **alpha** stage,
some features might not be fully supported yet and may not work as fully intended.
@@ -279,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
@@ -317,14 +316,15 @@ Launch the local in-memory node:
## Deploy contracts
For the deployment of your contracts, you have the flexibility to choose between two preferred methods:
-either by using Hardhat with the `@matter-labs/hardhat-zksync` plugin, or via `foundry-zksync`.
+either by using Hardhat with the `@matter-labs/hardhat-zksync` plugin, or via [`foundry-zksync`](https://github.com/matter-labs/foundry-zksync).
+
The following example will detail the process using `foundry-zksync`.
Before proceeding, ensure that you've compiled your contracts using `forge build --zksync`.
```bash [foundry-zksync]
-forge create zkc contracts/Greeter.sol:Greeter \
- --constructor-args "ZKsync and Foundry" \
+forge create contracts/Greeter.sol:Greeter \
+ --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 068e7063..f8ce7293 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 7781d853..6fc7eeaf 100644
--- a/content/00.build/60.test-and-debug/50.foundry.md
+++ b/content/00.build/60.test-and-debug/50.foundry.md
@@ -1,12 +1,12 @@
---
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 93e7fd77..6250a6ac 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 7c8cf65f..9f48b050 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 1cb7ab10..948369d1 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]
(../developer-reference/account-abstraction.md), 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](./30.ethereum-differences/10.evm-instructions.md).
+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
similarity index 86%
rename from content/00.build/65.developer-reference/25..best-practices.md
rename to content/00.build/65.developer-reference/25.best-practices.md
index 9bd925cd..67c11564 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/overview)
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/introduction).
+Read more about [zkSync Era Account Abstraction support](/build/developer-reference/account-abstraction/introduction).
## 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 f84e3984..6635a035 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,25 +156,25 @@ 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](../../../10.zk-stack/05.concepts/10.blocks.md).
+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).
::: note 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`
@@ -202,7 +202,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 8b16fd50..4d311d28 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/40.pre-compiles.md b/content/00.build/65.developer-reference/30.ethereum-differences/40.pre-compiles.md
index 063d1079..97e795d1 100644
--- a/content/00.build/65.developer-reference/30.ethereum-differences/40.pre-compiles.md
+++ b/content/00.build/65.developer-reference/30.ethereum-differences/40.pre-compiles.md
@@ -4,7 +4,7 @@ description:
---
Some EVM cryptographic precompiles (notably pairings and RSA) aren't currently available. However, pairing is
-prioritized to allow deployment of both Hyperchains and protocols like Aztec/Dark Forest without modifications.
+prioritized to allow deployment of both ZK Chains and protocols like Aztec/Dark Forest without modifications.
Ethereum cryptographic primitives like `ecrecover`, `keccak256`, `sha256`, `ecadd` and `ecmul` are supported as precompiles.
No actions are required from your side as all the calls to the precompiles are done by the compilers under the hood.
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 13870059..01d813ce 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 6e0365bd..f706d94b 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](../50.era-contracts/20.system-contracts.md)
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](../50.era-contracts/20.system-contracts.md) 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.
@@ -93,13 +93,13 @@ Each zkEVM bytecode must adhere to the following format:
- There is a VM limit, the bytecode can not be more than `2^16` 32-byte words, i.e. `2^21` bytes.
- The bootloader has a memory limit for supplying pubdata of 450999 bytes,
therefore limiting the contract size to it as well. This limit is valid for
-Validium hyperchains, that donât have to publish the bytecode to the base layer.
+Validium ZK Chains, that donât have to publish the bytecode to the base layer.
- For rollups that must publish the deployed bytecode to the base layer (e.g.
Ethereum), there is an additional pubdata limit, which is normally smaller. By
-default, for each batch, this limit is set to 100000 bytes for hyperchains using
-calldata DA, or 120000\*number_of_blobs, for hyperchains using EIP-4844 blobs.
+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,40 +126,38 @@ 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](../../05.zksync-101/1.index.md)
+- [Security considerations and best practices on zkSync](/build/developer-reference/best-practices)
### Differences in `create()` behaviour
-To facilitate [support for account abstraction](../developer-reference/
-account-abstraction.md), ZKsync splits the nonce of each account into two parts:
-the deployment nonce and the transaction nonce. The deployment nonce represents the
+To facilitate [support for account abstraction](/build/developer-reference/account-abstraction/introduction), 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](../50.era-contracts/20.system-contracts.md), which provides the address
+[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.
To have a deterministic address, you should use the `create2` method from
-[ContractDeployer](../50.era-contracts/20.system-contracts.md). It is available for EOAs as well.
+[ContractDeployer](/build/developer-reference/era-contracts/system-contracts). It is available for EOAs as well.
## 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
@@ -168,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](../80.l1-l2-interoperability.md).
+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.introduction.md b/content/00.build/65.developer-reference/40.account-abstraction/10.introduction.md
index f14a0709..93380acb 100644
--- a/content/00.build/65.developer-reference/40.account-abstraction/10.introduction.md
+++ b/content/00.build/65.developer-reference/40.account-abstraction/10.introduction.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 f2fc8c0d..7b798045 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
@@ -29,7 +29,7 @@ transaction hashes do not repeat is to have a pair (sender, nonce) always unique
The following protocol is used:
- Before each transaction starts, the system queries the
-[NonceHolder](../50.era-contracts/20.system-contracts.md#nonceholder) to check whether the provided nonce has already been used or not.
+[NonceHolder](/build/developer-reference/era-contracts/system-contracts#nonceholder) to check whether the provided nonce has already been used or not.
- If the nonce has not been used yet, the transaction validation is run. The provided nonce is expected to be marked as "used" during this time.
- After the validation, the system checks whether this nonce is now marked as used.
@@ -44,8 +44,8 @@ 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
-[bootloader](../../../10.zk-stack/10.components/50.zksync-evm/10.bootloader.md). Since these
+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
need this value for some reason). That's why all the methods of the `IAccount` and
@@ -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 e9cd008b..af52cf41 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 76b87bd4..056f2457 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 4f3b5d21..247c23a4 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 6a817437..93868626 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 a8d452ad..1e33041d 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.
@@ -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 81c8af36..1fdbf348 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](./40.account-abstraction/10.intro
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 e1d99ee0..161091b2 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.
@@ -26,7 +26,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
@@ -39,11 +39,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 f90f38d9..69e237cd 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 9c25f600..9e26f170 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))`,
@@ -1202,3 +1202,167 @@ curl --request POST \
"id": 1
}
```
+
+### `zks_sendRawTransactionWithDetailedOutput`
+
+Executes a transaction and returns its hash, storage logs, and events that would have been generated
+if the transaction had already been included in the block. The API has a similar behaviour to
+`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.
+
+Itâs expected that the optimistic logs of two uncommitted transactions that modify the same state will not have causal
+relationships between each other.
+
+#### Inputs
+
+| Parameter | Type | Description |
+| --------- | -------- | --------------------------------------------------------------------------- |
+| `data` | `string` | The signed transaction. Typically, signed with a library such as ethers.js. |
+
+#### Example Request
+
+```curl
+curl -X POST -H "Content-Type: application/json" \
+--data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["Signed Transaction"],"id":1}' \
+"https://mainnet.era.zksync.io"
+```
+
+#### Example Response
+
+```json
+{
+ "transactionHash": "0xd586a9381ac33a70d1c34704664209242ee90316878fc1695aa8e4cf553c8595",
+ "storageLogs": [
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0x7",
+ "writtenValue": "0x40000000000000000000000006641f961"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0x6",
+ "writtenValue": "0x5f5e100"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0x9",
+ "writtenValue": "0xc0000000000000000000000006641f961"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0x16",
+ "writtenValue": "0xe1ef29fc6c51f74bbdef5bc1406e3c9925d89c5b1f79215648b82ac15419bcbe"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0xa",
+ "writtenValue": "0x0"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0x10c",
+ "writtenValue": "0xc0000000000000000000000006641f961"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0xa",
+ "writtenValue": "0xe3ed371c32f62f3b3a28d51b909b2668e293c6cbfa4b4fd549c8f00a9a93a296"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0x110",
+ "writtenValue": "0x0"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0x10f",
+ "writtenValue": "0x88"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0x1",
+ "writtenValue": "0x8001"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0x2",
+ "writtenValue": "0x5f5e100"
+ },
+ {
+ "address": "0x0000000000000000000000000000000000008003",
+ "key": "0xeaa2b2fbf0b42c559059e5e9510edc15755f1c1883f0e41d5ba5f9aea4ac201a",
+ "writtenValue": "0x4"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800a",
+ "key": "0xeaa2b2fbf0b42c559059e5e9510edc15755f1c1883f0e41d5ba5f9aea4ac201a",
+ "writtenValue": "0x55ce6fa97340"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800a",
+ "key": "0x31b66141c575a054316a84da9cf4aa6fe0abd373cab1bf4ac029ffc061aae0da",
+ "writtenValue": "0xb9b031bf400"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0x1",
+ "writtenValue": "0x36615cf349d7f6344891b1e7ca7c72883f5dc049"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800b",
+ "key": "0x1",
+ "writtenValue": "0x8001"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800a",
+ "key": "0x31b66141c575a054316a84da9cf4aa6fe0abd373cab1bf4ac029ffc061aae0da",
+ "writtenValue": "0xa7557c54f00"
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800a",
+ "key": "0xeaa2b2fbf0b42c559059e5e9510edc15755f1c1883f0e41d5ba5f9aea4ac201a",
+ "writtenValue": "0x56f41b001840"
+ }
+ ],
+ "events": [
+ {
+ "address": "0x000000000000000000000000000000000000800a",
+ "topics": [
+ "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
+ "0x00000000000000000000000036615cf349d7f6344891b1e7ca7c72883f5dc049",
+ "0x0000000000000000000000000000000000000000000000000000000000008001"
+ ],
+ "data": "0x00000000000000000000000000000000000000000000000000000b9b031bf400",
+ "blockHash": null,
+ "blockNumber": null,
+ "l1BatchNumber": "0x4",
+ "transactionHash": "0xd586a9381ac33a70d1c34704664209242ee90316878fc1695aa8e4cf553c8595",
+ "transactionIndex": "0x0",
+ "logIndex": null,
+ "transactionLogIndex": null,
+ "logType": null,
+ "removed": false
+ },
+ {
+ "address": "0x000000000000000000000000000000000000800a",
+ "topics": [
+ "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
+ "0x0000000000000000000000000000000000000000000000000000000000008001",
+ "0x00000000000000000000000036615cf349d7f6344891b1e7ca7c72883f5dc049"
+ ],
+ "data": "0x00000000000000000000000000000000000000000000000000000125ab56a500",
+ "blockHash": null,
+ "blockNumber": null,
+ "l1BatchNumber": "0x4",
+ "transactionHash": "0xd586a9381ac33a70d1c34704664209242ee90316878fc1695aa8e4cf553c8595",
+ "transactionIndex": "0x0",
+ "logIndex": null,
+ "transactionLogIndex": null,
+ "logType": null,
+ "removed": false
+ }
+ ]
+}
+```
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 25456d4c..51d1d670 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 addbbccc..ee2879de 100644
--- a/content/00.build/70.api-reference/35.ethereum-rpc.md
+++ b/content/00.build/70.api-reference/35.ethereum-rpc.md
@@ -1,6 +1,6 @@
---
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/). With the
@@ -1295,7 +1295,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
@@ -1479,7 +1479,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
@@ -1500,7 +1500,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 2613fc2a..a70861ea 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 eb9a9f96..7b3f281c 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 734dd264..8656ad50 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,11 +1,11 @@
---
title: Contribution Guidelines
-description: Learn how to contribute to ZKsync Docs
+description: Learn how to contribute to zkSync Docs
---
## Environments
-**Production**: Visit [ZKsync Docs](https://docs.zksync.io/) for official documentation.
+**Production**: Visit [zkSync Docs](https://docs.zksync.io/) for official documentation.
**Staging**: [zKsync Docs Staging](https://staging-docs.zksync.io/) environment.
@@ -39,7 +39,7 @@ Submit your PR against the `staging` branch.
## What the project uses
-ZKsync docs is built with Vue and Nuxt framework, utilizing Nuxt Modules for content development.
+zkSync docs is built with Vue and Nuxt framework, utilizing Nuxt Modules for content development.
Familiarize yourself with Nuxt and review documentation for primary plugins.
### 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 60a7d74e..3cb12baa 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).
-## Kinds of ZKsync Documentation
+## Kinds of zkSync 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 for writing
-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.
@@ -56,7 +56,7 @@ Feel encouraged to create multiple articles across different categories to compr
## Markdown and Vue
-ZKsync Docs combine Markdown with Vue components, available under `/components/content`.
+zkSync Docs combine Markdown with Vue components, available under `/components/content`.
Use Vue components in Markdown using `::` syntax and yaml frontmatter for props.
If the Vue component is an inline slot-less component, use the `{prop="val"}` format.
@@ -150,7 +150,7 @@ export default defineNuxtConfig({
## 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.
Use the markdown format to display images.
```md
@@ -196,12 +196,12 @@ the name of the anchor tag separated by dashes.
## 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.
@@ -213,7 +213,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 37bcf4da..c6d28fd7 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,16 +20,16 @@ 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.
### SNARK (Succinct Non-Interactive Argument of Knowledge)
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
@@ -39,4 +39,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 315f1079..408f3091 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
@@ -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 670fcd20..fa020cf5 100644
--- a/content/00.build/95.resources/40.community-channels.md
+++ b/content/00.build/95.resources/40.community-channels.md
@@ -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 162593ef..4d80ce01 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!
@@ -58,30 +58,30 @@ Feel free to explore these repositories, and don't hesitate to contribute!
- 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](https://discord.com/invite/QKSsp7tC2x)
+#### 1. Introduce Yourself on [zkSync Discord](https://discord.com/invite/QKSsp7tC2x)
- Join our Discord channel and say 'hi' in the `#introductions` thread. Share what interests you and what you're hoping to learn or contribute.
-#### 2. Follow [ZKsync Developers](https://twitter.com/zkSyncDevs) on X (formerly Twitter)
+#### 2. Follow [zkSync Developers](https://twitter.com/zkSyncDevs) on X (formerly Twitter)
- Keep up to date with the latest news, updates, and releases by following us on X.
#### 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](https://github.com/matter-labs/zksync-cli)
+#### 4. Deploy Your First Contract Using [zkSync-CLI](https://github.com/matter-labs/zksync-cli)
-- Familiarize yourself with the zkSync-CLI tool and deploy your first contract on the ZKsync Era testnet.
+- Familiarize yourself with the zkSync-CLI tool and deploy your first contract on the zkSync Era testnet.
#### 5. Tackle a 'Good First Issue'
@@ -90,7 +90,7 @@ a great way to get hands-on experience and a feel for the project.
### Community Engagement
-#### 6. Participate in [ZKsync Developer Discussions](https://github.com/zkSync-Community-Hub/zkync-developers/discussions)
+#### 6. Participate in [zkSync Developer Discussions](https://github.com/zkSync-Community-Hub/zkync-developers/discussions)
- Join the discourse on GitHub discussions or other community forums to provide answers, ask questions, or share insights.
diff --git a/content/00.build/95.resources/60.faq.md b/content/00.build/95.resources/60.faq.md
index e2cfbcf4..8ee8f712 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/overview).
- - Other innovations like [Hyperchains, Hyperbridges and ZK Stack](/zk-stack/concepts/hyperchains-hyperscaling).
+ - 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/introduction).
+ - Learn more about [account abstraction support in zkSync Era](/build/developer-reference/account-abstraction/introduction).
### EVM Compatibility
@@ -91,32 +91,32 @@ 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
precompiles (notably pairings and RSA) wonât be available in the very first release but will be implemented soon after the launch, with pairing
-being a priority to allow both Hyperchains and protocols like Aztec/Dark Forest to be deployed without modifications too.
+being a priority to allow both ZK Chains and protocols like Aztec/Dark Forest to be deployed without modifications too.
## 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/introduction).
+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/introduction).
-## 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 2e8c7774..e5740714 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/00.index.md b/content/10.zk-stack/00.index.md
index dc7da143..6e284426 100644
--- a/content/10.zk-stack/00.index.md
+++ b/content/10.zk-stack/00.index.md
@@ -1,6 +1,6 @@
---
title: Overview
-description: This section provides an overview of the ZK Stack and zkEVM, detailing their roles in launching secure zero-knowledge rollups and forming the hyperchain network.
+description: This section provides an overview of the ZK Stack and zkEVM, detailing their roles in launching secure zero-knowledge rollups and forming the ZK Chains.
---
@@ -27,14 +27,14 @@ Unlike traditional blockchains that require running a full node to verify transa
ZK Rollups allow their state to be validated externally through the proof provided.
This makes it simpler and more efficient to ensure the integrity of the rollup.
-## Hyperchain: A Network of Rollups
+## ZK Chain: A Network of Rollups
-ZK Rollups can also be validated by other rollups, facilitating the creation of a trustless network of rollups known as the hyperchain.
+ZK Rollups can also be validated by other rollups, facilitating the creation of a trustless network of rollups known as the ZK Chain.
This interconnected network enhances the scalability and interoperability of blockchain systems.
## Technical Specifications
The document will delve deeper into the zkEVM, providing a detailed specification of its components
including the prover, compiler, and the virtual machine itself.
-Additionally, it will outline the foundational elements of the hyperchain ecosystem,
+Additionally, it will outline the foundational elements of the ZK Chain ecosystem,
highlighting how these innovations contribute to the scalability and security of blockchain technology.
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 e592ee4c..b29f8dcd 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.
-
+
---
## 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,7 +105,7 @@ 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`
@@ -113,7 +113,7 @@ In ZKsync Era, while the EIP-1559 transaction format is supported, the `maxFeePe
[EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712)
enables structured data hashing and signing within transactions.
-
+
```json
"gasPerPubdata": "1212",
@@ -153,10 +153,10 @@ These fields are handled by our SDKs.
### Priority: `0xff`
-
+
highlighting the unique multi-layer interaction that does not exist on Ethereum L1.
---
-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 9e1bf118..10a9b12b 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 |
@@ -62,13 +62,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
@@ -109,16 +109,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
@@ -168,7 +168,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
@@ -180,7 +180,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:
@@ -188,7 +188,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 5b78a63a..7ae8b5ea 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 d8f67864..a84f88fa 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 7d69db8d..9e758cc8 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.hyperchains-hyperscaling.md b/content/10.zk-stack/05.concepts/50.zk-chains.md
similarity index 81%
rename from content/10.zk-stack/05.concepts/50.hyperchains-hyperscaling.md
rename to content/10.zk-stack/05.concepts/50.zk-chains.md
index 2a8032b0..28f93f6f 100644
--- a/content/10.zk-stack/05.concepts/50.hyperchains-hyperscaling.md
+++ b/content/10.zk-stack/05.concepts/50.zk-chains.md
@@ -1,6 +1,6 @@
---
-title: Hyperchains / Hyperscaling
-description: "Delve into the concept of Hyperchains and their integral role in scaling blockchain systems like Ethereum, ensuring a future of efficient, global on-chain activities."
+title: ZK Chains
+description: "Delve into the concept of ZK Chains and their integral role in scaling blockchain systems like Ethereum, ensuring a future of efficient, global on-chain activities."
---
The need for blockchain scalability is paramount as networks like Ethereum, currently limited to processing about 12 transactions per second,
@@ -9,37 +9,37 @@ While various architectures like Polkadot, Cosmos, Near, and Eth 2.0 explore sol
However, zero-knowledge proofs have emerged as a promising solution to these challenges,
offering cryptographic security when combined with data availability layers and ZK Rollups, thereby enhancing the scalability and security of Ethereum.
-## What are hyperchains?
+## What are ZK Chains?
-Hyperchains represent a sophisticated layer of blockchain architecture,
+ZK Chains represent a sophisticated layer of blockchain architecture,
consisting of parallel-running instances of zkEVM that achieve consensus and finality on Ethereum's Layer 1 (L1).
Inspired by the concept of hyperlinks in the traditional web, which connect various webpages,
-Hyperchains utilize Hyperbridges to connect different rollups within the ecosystem, facilitating seamless interactions across chains.
+ZK Chains utilize Hyperbridges to connect different rollups within the ecosystem, facilitating seamless interactions across chains.
![hyperbridges](/images/zk-stack/hyperbridges.png)
**Gray lines show proofs, orange lines the hyperbridges, which automatically connect all blue chains.**
### Structure and functionality
-Hyperchains operate with a shared bridge contract on Ethereum's L1 and include native bridges between individual rollups,
-enhancing the overall interoperability and efficiency of the network. Key features of Hyperchains include:
+ZK Chains operate with a shared bridge contract on Ethereum's L1 and include native bridges between individual rollups,
+enhancing the overall interoperability and efficiency of the network. Key features of ZK Chains include:
-1. **Trustless Validating Bridges**: Ensures that rollups within the Hyperchain are interconnected without requiring additional trust layers.
+1. **Trustless Validating Bridges**: Ensures that rollups within the ZK Chain are interconnected without requiring additional trust layers.
2. **Asset Transfers**: Hyperbridges facilitate the easy transfer of assets, including burning and minting mechanisms, across the ecosystem.
3. **Unified Governance**: Leveraging a shared governance framework on L1,
the ecosystem can coordinate updates or respond collectively to vulnerabilities, much like a traditional blockchain network would handle a fork.
-4. **Security and Trust**: All Hyperchains must utilize the standardized zkEVM engine to maintain consistent security and operational standards,
+4. **Security and Trust**: All ZK Chains must utilize the standardized zkEVM engine to maintain consistent security and operational standards,
ensuring that trust and security are derived directly from L1.
### Development and Deployment
-Hyperchains can be developed and deployed by anyone, fostering a diverse and open ecosystem.
-However, for a Hyperchain to remain trusted and fully interoperable within the network, it must utilize the zkEVM engine that powers the ZK Stack.
-This requirement ensures consistency in execution and security across different instances of Hyperchains.
+ZK Chains can be developed and deployed by anyone, fostering a diverse and open ecosystem.
+However, for a ZK Chain to remain trusted and fully interoperable within the network, it must utilize the zkEVM engine that powers the ZK Stack.
+This requirement ensures consistency in execution and security across different instances of ZK Chains.
### Modular Implementation
-Hyperchains are designed to be modular, meaning developers can select different components of their blockchain systems or implement their own,
+ZK Chains are designed to be modular, meaning developers can select different components of their blockchain systems or implement their own,
with the exception of the zkEVM core.
This modular approach allows for customization and flexibility in blockchain development
while maintaining core standards necessary for network security and interoperability.
@@ -50,21 +50,21 @@ while maintaining core standards necessary for network security and interoperabi
Hyperbridges are composed of smart contracts that verify transactions across chains using Merkle proofs.
The process involves locking the original asset in a shared L1 bridge contract, unifying liquidity across the network, and follows these steps:
-1. **Initiation**: A transaction is initiated on a Hyperchain, aimed at crossing to another chain within the ecosystem.
-2. **Settlement on L1**: The sending Hyperchain compiles a cryptographic proof of the transaction and settles it onto Ethereum's Layer 1,
+1. **Initiation**: A transaction is initiated on a ZK Chain, aimed at crossing to another chain within the ecosystem.
+2. **Settlement on L1**: The sending ZK Chain compiles a cryptographic proof of the transaction and settles it onto Ethereum's Layer 1,
anchoring the transaction's validity.
3. **Transaction Root Update**: Ethereum's Layer 1 updates the Transaction Root, a cumulative record reflecting all transactions processed across the ecosystem.
-4. **Root Importation**: The receiving Hyperchain imports this updated Transaction Root through its consensus mechanism,
+4. **Root Importation**: The receiving ZK Chain imports this updated Transaction Root through its consensus mechanism,
akin to the way Layer 1 to Layer 2 messages are currently handled.
-5. **Transaction Submission**: A relayer submits the transaction along with a Merkle Proof to the receiving Hyperchain.
+5. **Transaction Submission**: A relayer submits the transaction along with a Merkle Proof to the receiving ZK Chain.
This proof connects the transaction to the newly updated Transaction Root.
-6. **Verification and Execution**: The receiving Hyperchain verifies the transaction against the Transaction Root.
+6. **Verification and Execution**: The receiving ZK Chain verifies the transaction against the Transaction Root.
If the verification is successful, the transaction is executed, and the relayer is compensated for their service.
-7. **Proof Settlement**: Finally, the receiving Hyperchain settles its proof on L1, conclusively validating the transaction within the ecosystem.
+7. **Proof Settlement**: Finally, the receiving ZK Chain settles its proof on L1, conclusively validating the transaction within the ecosystem.
![hyperscaling](/images/zk-stack/hyperscalingBridgingFull.png)
-#### Types of Bridges in the Hyperchain Ecosystem
+#### Types of Bridges in the ZK Chain Ecosystem
- **L1-L2 Bridges**: These bridges are foundational, facilitating direct interactions between Ethereum's main chain (L1) and second-layer solutions (L2).
- **zkPorter Shard Bridges**: Specifically designed for developers, these bridges connect different shards of the zkPorter virtual machine.
@@ -91,27 +91,27 @@ This automation means that users do not need to manually manage the technical de
#### Unified Asset Management
-In a Hyperchain environment, users' wallets will display all of their assets across various chains in a unified interface.
+In a ZK Chain environment, users' wallets will display all of their assets across various chains in a unified interface.
Hereâs what this integration looks like:
- **Asset Bridging**: Relayers manage the process of bridging assets between chains,
handling the necessary burning and minting of assets as they move across the ecosystem.
-- **Intuitive Addressing**: Hyperchains feature unique identifiers that integrate with the Ethereum Name Service (ENS),
+- **Intuitive Addressing**: ZK Chains feature unique identifiers that integrate with the Ethereum Name Service (ENS),
making recipient addresses as straightforward as email addresses.
- While users can still use traditional Ethereum addresses, the combination with Hyperchain identifiers simplifies transactions further.
+ While users can still use traditional Ethereum addresses, the combination with ZK Chain identifiers simplifies transactions further.
#### Protocol-Integrated Bridging
Bridging is integrated directly into the transaction protocols of wallets, streamlining the process alongside standard asset transfers.
Key aspects of this integration include:
-- **Quick Settlement Times**: The time taken for bridging transactions depends on the proof settlement time of the specific Hyperchain,
+- **Quick Settlement Times**: The time taken for bridging transactions depends on the proof settlement time of the specific ZK Chain,
typically ranging from 1 to 15 minutes.
- **Minimal Infrastructure Needs**: With relayers being the primary external infrastructure, the overall system remains lightweight and cost-effective.
-#### Real-World Application: Cross-Hyperchain Uniswap Transaction
+#### Real-World Application: Cross ZK Chain Uniswap Transaction
-Consider a practical scenario where you want to swap Ethereum for DAI using a cross-hyperchain transaction on Uniswap:
+Consider a practical scenario where you want to swap Ethereum for DAI using a cross ZK Chain transaction on Uniswap:
1. **Transaction Initiation**: You initiate the transaction directly from your wallet.
2. **Relayer Involvement**: A relayer picks up your Ethereum and deposits it into the Uniswap chain.
@@ -119,7 +119,7 @@ Consider a practical scenario where you want to swap Ethereum for DAI using a cr
4. **Completion and Return**: The relayer then transfers the DAI back to your original chain.
This entire process is executed as a single transaction, making it feel as seamless as if no chain-switching occurred.
-The only difference a user might notice is a slightly longer confirmation time, depending on the specific Hyperchain used.
+The only difference a user might notice is a slightly longer confirmation time, depending on the specific ZK Chain used.
![hyperscalingUniswap](/images/zk-stack/hyperscalingUniswap.png)
@@ -135,11 +135,11 @@ Proof aggregation is a critical component in scaling blockchain technologies,
allowing for the efficient verification of transactions across multiple chains.
This process enhances the hyperscalability of the ecosystem,
vital for supporting extensive blockchain operations without overwhelming the base layer (L1).
-Below, we explore the various methods of proof aggregation within the Hyperchain ecosystem and their implications.
+Below, we explore the various methods of proof aggregation within the ZK Chain ecosystem and their implications.
### Simple proof aggregation
-Simple proof aggregation treats each Hyperchain's proofs as independent entities that are verified collectively on Ethereum L1.
+Simple proof aggregation treats each ZK Chain's proofs as independent entities that are verified collectively on Ethereum L1.
This method is straightforward but has limitations:
- **Infrequent Settlements**: To conserve on gas fees, proofs are settled less frequently, which can delay the verification process.
@@ -150,7 +150,7 @@ This method is straightforward but has limitations:
### L3s: Layered proof aggregation
-In this model, Hyperchains can act as Layer 3 (L3) networks that settle their proofs onto an intermediary Layer 2 (L2) Hyperchain.
+In this model, ZK Chains can act as Layer 3 (L3) networks that settle their proofs onto an intermediary Layer 2 (L2) ZK Chain.
hThis structure allows for several benefits and drawbacks:
- **Faster Inter-L3 Messaging**: L3s on the same L2 can communicate more swiftly and cheaply.
@@ -185,13 +185,13 @@ allowing transaction roots to be calculated outside of the proof and imported ah
### Sovereignty
-Hyperchains retain sovereignty, meaning they can opt in or out of proof aggregation:
+ZK Chain retain sovereignty, meaning they can opt in or out of proof aggregation:
-- **Optional Participation**: Hyperchains may choose not to participate in aggregation,
+- **Optional Participation**: ZK Chains may choose not to participate in aggregation,
opting instead to settle directly to Ethereum, albeit at higher costs.
- **Decentralized Aggregation Access**: Aggregation remains accessible and decentralized, ensuring low hardware requirements for provers.
-![Hyperchain Sovereignty](/images/zk-stack/hyperscalingSovereignty.png)
+![ZK Chain Sovereignty](/images/zk-stack/hyperscalingSovereignty.png)
### Feature comparison
@@ -206,9 +206,9 @@ Different aggregation methods offer various advantages and considerations:
| Sovereign | Yes | Yes | Yes |
---
-## Modularity: Hyperchain customization
+## Modularity: ZK Chain customization
-The ZK Stack offers a wide array of customization options for developers looking to tailor Hyperchains to specific needs
+The ZK Stack offers a wide array of customization options for developers looking to tailor ZK Chain to specific needs
or create entirely new blockchain architectures.
This modular approach allows for significant flexibility in configuring transaction sequencing, data availability policies, and privacy features.
Below, we explore these customization options in detail.
@@ -230,13 +230,14 @@ Below, we explore these customization options in detail.
### Data Availability (DA)
-Data Availability (DA) is a critical component in ensuring the security and functionality of Hyperchains.
+Data Availability (DA) is a critical component in ensuring the security and functionality of ZK Chain.
It governs how transaction data is managed and made accessible, impacting everything from user privacy to transaction speed and cost.
Below, we detail the various DA options available to developers using the ZK Stack, each tailored for specific security, privacy, and scalability needs.
#### zk-Rollup
-zk-Rollup is the recommended DA policy for most Hyperchains.
-It ensures that the values of every changed storage slot are published as calldata on Ethereum's Layer 1 (L1). This approach benefits from:
+zk-Rollup is the recommended DA policy for most ZK Chain.
+It ensures that the values of every changed storage slot are published as calldata (or blobs, depending on what's
+cheaper) on Ethereum's Layer 1 (L1). This approach benefits from:
- **Amortization of Costs**: Changes that net to zero are not posted, reducing unnecessary data and saving costs.
- **Inherited Security**: Adopts the full security and censorship-resistance properties of Ethereum, providing robust protection against potential attacks.
@@ -246,7 +247,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
@@ -274,7 +275,7 @@ this option requires sophisticated technical solutions to manage user interactio
### Logical state partitions in ZK Porters
-Logical state partitions within ZK Porters offer a powerful way for Hyperchains
+Logical state partitions within ZK Porters offer a powerful way for ZK Chain
to manage and interact with distinct subsets of their state in a synchronized manner.
This modular architecture not only increases the efficiency and scalability of operations but also introduces advanced functionalities
such as atomic transactions and state interoperability between partitions.
@@ -290,9 +291,9 @@ One prominent example of this is a combination of **[zkRollup + zkPorter](https:
### Privacy
-Hyperchains support various methods to enhance privacy:
+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 807599b4..27517619 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 01e8902c..a4a20094 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 functionality
+Account abstraction (AA) is a pivotal feature in zkSync that allows for greater flexibility and functionality
in how accounts operate and interact with transactions.
-
+
## 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 3438cd0c..14a4521a 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.overview.md b/content/10.zk-stack/10.components/70.compiler/20.specification/10.overview.md
index 7b3896f3..ab2fd663 100644
--- a/content/10.zk-stack/10.components/70.compiler/20.specification/10.overview.md
+++ b/content/10.zk-stack/10.components/70.compiler/20.specification/10.overview.md
@@ -17,7 +17,7 @@ to better understand the workflow or -->
| 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. |
@@ -27,11 +27,11 @@ to better understand the workflow or -->
| 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 c798e724..8903691f 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](instructions/evm/overview).
-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
+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)
@@ -96,7 +96,7 @@ For reference, see [the LLVM IR codegen source code](%%zk_git_repo_era-compiler-
+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.overview.md b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/10.overview.md
index aef64ba0..60d8a250 100644
--- a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/10.overview.md
+++ b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/10.overview.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.overview.md b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/10.overview.md
index ca858b32..0888a432 100644
--- a/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/10.overview.md
+++ b/content/10.zk-stack/10.components/70.compiler/20.specification/60.instructions/20.evm/10.overview.md
@@ -21,9 +21,9 @@ Such instructions are grouped into the following categories according to [the or
- [Create](create)
- [Return](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 e27ceecd..ac85433d 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
@@ -9,7 +9,7 @@ The call type is encoded on the assembly level, so we will describe the common h
+[zkSync Era documentation](https://era.zksync.io/docs/reference/architecture/differences-with-ethereum.html#call-staticcall-delegatecall). -->
## 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 cc9e57d8..fd809037 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](https://era.zksync.io/docs/reference/architecture/differences-with-ethereum.html#create-create2).
+For more information, see the [zkSync Era documentation](https://era.zksync.io/docs/reference/architecture/differences-with-ethereum.html#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 aff04da4..45f87640 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](https://era.zksync.io/docs/reference/architecture/differences-with-ethereum.html#return).
+This instruction works differently in deploy code. For more information, see [the zkSync Era documentation](https://era.zksync.io/docs/reference/architecture/differences-with-ethereum.html#return).
### 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 0c79b127..8cc8cc30 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 [$]
@@ -71,7 +71,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 5761105c..6b344b39 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](../system-contracts#contract-deployer).
For more information, see [CREATE](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](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](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).
@@ -100,8 +100,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](../instructions/overview#yul-extensions) available in the system mode. In order to compile a Yul contract
+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](../instructions/overview#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/10.components/80.fee-withdrawer.md b/content/10.zk-stack/10.components/80.fee-withdrawer.md
index 4c5d97be..42cac003 100644
--- a/content/10.zk-stack/10.components/80.fee-withdrawer.md
+++ b/content/10.zk-stack/10.components/80.fee-withdrawer.md
@@ -1,9 +1,9 @@
---
title: Fee Withdrawer
-description: Learn about the Fee Withdrawer, a tool that automates the transfer of collected fees from a hyperchain to a base layer address.
+description: Learn about the Fee Withdrawer, a tool that automates the transfer of collected fees from a ZK Chain to a base layer address.
---
[The Fee Withdrawer](https://github.com/matter-labs/era-fee-withdrawer)
-is a specialized tool that automates the process of transferring collected fees from a hyperchain to a specified address on the base layer.
+is a specialized tool that automates the process of transferring collected fees from a ZK Chain to a specified address on the base layer.
This functionality is crucial for maintaining the continuous operation of the ETH operator on the base layer,
ensuring there is always a sufficient supply of the gas token available for transactions.
diff --git a/content/10.zk-stack/10.components/90.portal-wallet-bridge.md b/content/10.zk-stack/10.components/90.portal-wallet-bridge.md
index 0876e0a2..e56a8233 100644
--- a/content/10.zk-stack/10.components/90.portal-wallet-bridge.md
+++ b/content/10.zk-stack/10.components/90.portal-wallet-bridge.md
@@ -1,15 +1,15 @@
---
title: Portal - Wallet + Bridge
-description: Discover how the Portal dApp facilitates interaction with your hyperchain, including asset bridging, transaction tracking, and contract management.
+description: Discover how the Portal dApp facilitates interaction with your ZK Chain, including asset bridging, transaction tracking, and contract management.
---
-[The Portal](https://github.com/matter-labs/dapp-portal) is a decentralized application (dApp) designed to enhance interaction with your hyperchain.
+[The Portal](https://github.com/matter-labs/dapp-portal) is a decentralized application (dApp) designed to enhance interaction with your ZK Chain.
It serves as a versatile tool for both you and your users, simplifying various operations within the blockchain environment.
### Key Features
-- **Bridging Assets:** The Portal enables the movement of assets between the Layer 1 (L1) network and your hyperchain, facilitating smooth asset transfers.
-- **Internal Transactions:** Users can send assets within the hyperchain efficiently, utilizing the Portal's user-friendly interface.
+- **Bridging Assets:** The Portal enables the movement of assets between the Layer 1 (L1) network and your ZK Chain, facilitating smooth asset transfers.
+- **Internal Transactions:** Users can send assets within the ZK Chain efficiently, utilizing the Portal's user-friendly interface.
- **Transaction History:** The Portal provides access to view and verify historical transactions, enhancing transparency and user trust in the platform.
- **Contract Management:** It supports users in managing smart contracts, including deployment and interaction functionalities.
diff --git a/content/10.zk-stack/20.running-a-hyperchain/10.locally.md b/content/10.zk-stack/20.running-a-zk-chain/10.locally.md
similarity index 66%
rename from content/10.zk-stack/20.running-a-hyperchain/10.locally.md
rename to content/10.zk-stack/20.running-a-zk-chain/10.locally.md
index 15aea084..d05caf2a 100644
--- a/content/10.zk-stack/20.running-a-hyperchain/10.locally.md
+++ b/content/10.zk-stack/20.running-a-zk-chain/10.locally.md
@@ -6,7 +6,7 @@ description:
## Getting Started with ZK Stack
::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
-ZK Stack is still under development. We advise you to only use for local and testnet deployments.
+A new and improved ZK Stack CLI is coming very soon. The current version is deprecated and may not function as expected.
::
## Development dependencies
@@ -35,7 +35,7 @@ to set up dependencies on your machine (don't worry about the Environment sectio
zk
```
-1. Last, start the wizard and follow instructions to set up and deploy your new hyperchain by running `zk stack init`
+1. Last, start the wizard and follow instructions to set up and deploy your new ZK Chain by running `zk stack init`
- Initially you want to `Configure new chain`
@@ -46,18 +46,18 @@ to set up dependencies on your machine (don't worry about the Environment sectio
- If you are doing this for the first time, several components need to be compiled/built, so do not worry if it takes a few minutes.
The console will show what is going on anyways.
- - If you don't want to configure any values for now and just want check the build process for a hyperchain, try out the `zk stack demo` command.
+ - If you don't want to configure any values for now and just want check the build process for a ZK Chain, try out the `zk stack demo` command.
::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 hyperchain.
+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).
::
-### Your hyperchain is now deployed
+### Your ZK Chain is now deployed
-Your hyperchain is now deployed to the base chain (most likely a local geth docker container) and configured.
+Your ZK Chain is now deployed to the base chain (most likely a local geth docker container) and configured.
You can find all configuration in a new `.env` file created on `/etc/env/.env`,
and if you deployed test tokens, their addresses will be available at `/etc/tokens/.json`
@@ -67,17 +67,17 @@ and if you deployed test tokens, their addresses will be available at `.
+1. You can now run transactions and start playing with your ZK Chain by using the RPC available at .
- - Don't forget to deposit some ETH and fund your accounts on your hyperchain. To do so follow the instructions for [Funding accounts](#funding-accounts).
+ - Don't forget to deposit some ETH and fund your accounts on your ZK Chain. To do so follow the instructions for [Funding accounts](#funding-accounts).
-## Using your hyperchain
+## Using your ZK Chain
### Funding accounts
-During the `zk stack init` configurator, you have a choice of what base layer to deploy the hyperchain onto:
+During the `zk stack init` configurator, you have a choice of what base layer to deploy the ZK Chain onto:
the local geth node, or an Ethereum network (e.g., Sepolia).
-The first step to start interacting with your hyperchain is to fund an account (or a few).
+The first step to start interacting with your ZK Chain is to fund an account (or a few).
This means you need some funds on the base layer.
#### Base layer is the local geth node
@@ -85,25 +85,25 @@ This means you need some funds on the base layer.
- If you chose to deploy on local geth node, you will have a set of addresses that have 100 ETH each.
You can find the list [here](https://github.com/matter-labs/local-setup/blob/main/rich-wallets.json)
- and use these addresses to deposit into your hyperchain via the bridge.
+ and use these addresses to deposit into your ZK Chain via the bridge.
#### Base layer is an Ethereum network (e.g., Sepolia)
- If you chose to deploy on an Ethereum network (e.g., Sepolia), you need to have an account on the base layer with ETH.
You can use the deployer, governor, or operator wallets setup during the the deployment process,
- or any other one you have funds, to deposit into your hyperchain via the bridge.
+ or any other one you have funds, to deposit into your ZK Chain via the bridge.
-Once you have the accounts with funds on the L1 base layer, you can do a deposit via the bridge to your hyperchain,
-and any further interactions with your hyperchain.
+Once you have the accounts with funds on the L1 base layer, you can do a deposit via the bridge to your ZK Chain,
+and any further interactions with your ZK Chain.
-### Using your hyperchain RPC
+### Using your ZK Chain RPC
Your server contains both HTTPS as well as WebSocket (WS) services that are fully web3 compatible (and contain some extra ZK Stack functionalities).
Learn more about it [here](/build/api-reference).
### Using zksync-cli
-ZKsync CLI allows you to easily interact and develop applications on your hyperchain.
+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:
@@ -112,17 +112,16 @@ An example deposit command via the bridge would look like:
npx zksync-cli bridge deposit --rpc=http://localhost:3050 --l1-rpc=http://localhost:8545
```
-### Using Portal
+### Using [Portal](https://github.com/matter-labs/dapp-portal)
The dApp Portal module allows you to:
-- View balances, transfer and bridge tokens to your hyperchain.
+- View balances, transfer and bridge tokens to your ZK Chain.
- Add contacts for quick and easy access.
-You can run the Portal module locally, and point it to your hyperchain configuration.
-It comes with scripts that help pulling the hyperchain configuration from your zksync-era repo and adapting to portal needs.
-Learn more [here](https://github.com/matter-labs/dapp-portal).
-An example command would look like:
+You can run the Portal module locally, and point it to your ZK Chain configuration. It comes with scripts that help
+pulling the ZK Chain configuration from your zksync-era repo and adapting to portal needs. Learn more
+[here](https://github.com/matter-labs/dapp-portal). An example command would look like:
```bash
npm run hyperchain:configure ../zksync-era
@@ -131,17 +130,18 @@ npm run dev:node:hyperchain
You can now navigate to the displayed Portal URL (typically ).
-### Using Block Explorer
+### Using [Block Explorer](https://github.com/matter-labs/block-explorer)
-A free open source block explorer is available for your hyperchain.
-Block explorer contains three components [Worker](https://github.com/matter-labs/block-explorer/tree/main/packages/worker),
-[API](https://github.com/matter-labs/block-explorer/tree/main/packages/api),
-and [App](https://github.com/matter-labs/block-explorer/tree/main/packages/app),
-which you can run all together locally and connect to your hyperchain.
+A free open source block explorer is available for your ZK Chain. Block explorer contains three components
-Make sure you have your [zksync-era](https://github.com/matter-labs/zksync-era) repo set up locally and the `zk server` is running.
-The wizard in this guide allows you to run the server in the end.
-If you chose not to, youâre still able to run it by executing:
+- [Worker](https://github.com/matter-labs/block-explorer/tree/main/packages/worker)
+- [API](https://github.com/matter-labs/block-explorer/tree/main/packages/api)
+- [App](https://github.com/matter-labs/block-explorer/tree/main/packages/app)
+
+Which you can run all together locally and connect to your ZK Chain.
+
+Make sure you have your [zksync-era](https://github.com/matter-labs/zksync-era) repo set up locally and
+the `zk server` is running. The wizard in this guide allows you to run the server in the end. If you chose not to, youâre still able to run it by executing:
```bash
zk server --components "http_api,eth,state_keeper,housekeeper"
@@ -162,7 +162,7 @@ npm install
#### Setting up env variables
-Next you need to set up all the necessary environment and configuration files with your hyperchain settings. You can use a script to set them up:
+Next you need to set up all the necessary environment and configuration files with your ZK Chain settings. You can use a script to set them up:
```bash
npm run hyperchain:configure
@@ -183,14 +183,13 @@ npm run dev
#### Verify block explorer is up and running
-By default, you can access front-end `App` at in your browser.
-`API` should be available at , `Worker` at and `Data Fetcher` at .
+By default, you can access front-end `App` at in your browser. `API` should
+be available at , `Worker` at and `Data Fetcher` at .
## Enabling Boojum prover
-With the default configuration, your hyperchain is not running a prover,
-and has a DummyExecutor contract, which mainly âacceptsâ that a batch is executed without proof.
-This enables you to test it with much lower hardware requirements.
+With the default configuration, your ZK Chain is not running a prover, and has a DummyExecutor contract,
+which mainly âacceptsâ that a batch is executed without proof. This enables you to test it with much lower hardware requirements.
To enable the prover, run the `zk stack prover-setup` command. It will guide through the necessary configuration.
@@ -220,9 +219,9 @@ The current minimum requirements for a low TPS scenario are:
## Addendum
-- If you make changes to any contract, you can always deploy a new hyperchain to easily test those changes.
-- If you configure your hyperchain once, you don't need to do it again as the wizard allows you to use an existing config file.
-- For now, it is only possible to deploy a hyperchain as an L2, but soon it will also work as L3s.
+- If you make changes to any contract, you can always deploy a new ZK Chain to easily test those changes.
+- If you configure your ZK Chain once, you don't need to do it again as the wizard allows you to use an existing config file.
+- For now, it is only possible to deploy a ZK Chain as an L2, but soon it will also work as L3s.
- When running the default matterlabs/geth, you have a set of rich wallets available to you.
::drop-panel
::panel{label="Rich Wallets"}
@@ -230,8 +229,8 @@ The current minimum requirements for a low TPS scenario are:
::
::
- If you face an issue compiling rust code (example `: Error allocating TSD`) try removing the `rust-toolchain` file from the repo.
-- If you want to have a custom local base chain, you must ensure you have a database for your hyperchain, as well as the local RPC for your L1.
- - To run a Postgres 14 database for your hyperchain, execute the following:
+- If you want to have a custom local base chain, you must ensure you have a database for your ZK Chain, as well as the local RPC for your L1.
+ - To run a Postgres 14 database for your ZK Chain, execute the following:
```bash
docker-compose -f docker-compose-zkstack-common.yml up -d postgres
diff --git a/content/10.zk-stack/20.running-a-hyperchain/20.production.md b/content/10.zk-stack/20.running-a-zk-chain/20.production.md
similarity index 78%
rename from content/10.zk-stack/20.running-a-hyperchain/20.production.md
rename to content/10.zk-stack/20.running-a-zk-chain/20.production.md
index e120f12f..8a9d810c 100644
--- a/content/10.zk-stack/20.running-a-hyperchain/20.production.md
+++ b/content/10.zk-stack/20.running-a-zk-chain/20.production.md
@@ -3,7 +3,7 @@ title: In Production
---
::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
-ZK Stack is still under development. We advise you to only use for local and testnet deployments.
+A new and improved ZK Stack CLI is coming very soon. The current version is deprecated and may not function as expected.
::
## Deploying to a non-local environment
@@ -18,7 +18,7 @@ Make sure you provide it and that it accepts external connections if your server
## Server (Sequencer) & Prover
-After configuring your hyperchain, you can generate docker images for your server and prover.
+After configuring your ZK Chain, you can generate docker images for your server and prover.
To do that run `zk stack docker-setup`.
This command will guide you to properly name and tag your image.
diff --git a/content/10.zk-stack/20.running-a-hyperchain/30.raas.md b/content/10.zk-stack/20.running-a-zk-chain/30.raas.md
similarity index 98%
rename from content/10.zk-stack/20.running-a-hyperchain/30.raas.md
rename to content/10.zk-stack/20.running-a-zk-chain/30.raas.md
index 26b4a3c1..cc142ef5 100644
--- a/content/10.zk-stack/20.running-a-hyperchain/30.raas.md
+++ b/content/10.zk-stack/20.running-a-zk-chain/30.raas.md
@@ -19,7 +19,7 @@ Get started today and revolutionize your product with the power of RaaS and ZK S
Use RaaS in to improve scalability, reduce costs, access specialized services, speed up development, enhance interoperability,
and maintain flexibility in an ever-evolving technological landscape.
-The list of RaaS providers you can use to deploy and customise their your hyperchain:
+The list of RaaS providers you can use to deploy and customise their your ZK Chain:
diff --git a/content/10.zk-stack/20.running-a-hyperchain/99.dependencies.md b/content/10.zk-stack/20.running-a-zk-chain/99.dependencies.md
similarity index 98%
rename from content/10.zk-stack/20.running-a-hyperchain/99.dependencies.md
rename to content/10.zk-stack/20.running-a-zk-chain/99.dependencies.md
index b0152449..7bdb5197 100644
--- a/content/10.zk-stack/20.running-a-hyperchain/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/10.zk-stack/20.running-a-hyperchain/99.enabling-prover.md b/content/10.zk-stack/20.running-a-zk-chain/99.enabling-prover.md
similarity index 93%
rename from content/10.zk-stack/20.running-a-hyperchain/99.enabling-prover.md
rename to content/10.zk-stack/20.running-a-zk-chain/99.enabling-prover.md
index 0b7a195f..7b8d5a0a 100644
--- a/content/10.zk-stack/20.running-a-hyperchain/99.enabling-prover.md
+++ b/content/10.zk-stack/20.running-a-zk-chain/99.enabling-prover.md
@@ -3,7 +3,7 @@ title: Enabling Prover
description:
---
-With the default configuration, your hyperchain is not running a prover,
+With the default configuration, your ZK Chain is not running a prover,
and has a `DummyExecutor` contract, which mainly âacceptsâ that a batch is executed without proof.
This enables you to test it with much lower hardware requirements.
diff --git a/content/10.zk-stack/20.running-a-hyperchain/99.using-hyperchain.md b/content/10.zk-stack/20.running-a-zk-chain/99.using-zk-chain.md
similarity index 74%
rename from content/10.zk-stack/20.running-a-hyperchain/99.using-hyperchain.md
rename to content/10.zk-stack/20.running-a-zk-chain/99.using-zk-chain.md
index 8a7e71eb..3d8cd211 100644
--- a/content/10.zk-stack/20.running-a-hyperchain/99.using-hyperchain.md
+++ b/content/10.zk-stack/20.running-a-zk-chain/99.using-zk-chain.md
@@ -1,5 +1,5 @@
---
-title: Using Your Hyperchain RPC
+title: Using Your ZK Chain RPC
description:
---
@@ -20,8 +20,8 @@ npx zksync-cli bridge deposit --rpc=http://localhost:3050 --l1-rpc=http://localh
## Using dApp Portal
-You can run the Portal module locally, and point it to your hyperchain configuration.
-It comes with scripts that help pulling the hyperchain configuration from your zksync-era repo and adapting to portal needs.
+You can run the Portal module locally, and point it to your ZK Chain configuration.
+It comes with scripts that help pulling the ZK Chain configuration from your zksync-era repo and adapting to portal needs.
Learn more here. An example command would look like:
```bash
@@ -31,8 +31,8 @@ npm run dev:node:hyperchain
## Using Block Explorer
-Block explorer contains three components (Worker, API, and App), which you can run all together locally and connect to your hyperchain.
-For that, you need to set up all the necessary environment and configuration files with your hyperchain settings.
+Block explorer contains three components (Worker, API, and App), which you can run all together locally and connect to your ZK Chain.
+For that, you need to set up all the necessary environment and configuration files with your ZK Chain settings.
You can use a script to build them. See setting up env variables.
Once you have your zksync-era repo set up locally, you can run the following command to
@@ -46,11 +46,11 @@ The script generates all the necessary configuration files for block-explorer, w
## Addendum
-- If you make changes to any contract, you can always deploy a new hyperchain to easily test those changes.
+- If you make changes to any contract, you can always deploy a new ZK Chain to easily test those changes.
-- If you configure your hyperchain once, you don't need to do it again as the wizard allows you to use an existing config file.
+- If you configure your ZK Chain once, you don't need to do it again as the wizard allows you to use an existing config file.
-- For now, it is only possible to deploy a hyperchain as an L2, but soon it will also work as L3s.
+- For now, it is only possible to deploy a ZK Chain as an L2, but soon it will also work as L3s.
- When running the default matterlabs/geth, you have a set of rich wallets available to you.
::drop-panel
@@ -58,9 +58,9 @@ The script generates all the necessary configuration files for block-explorer, w
:display-partial{path="/_partials/_rich-wallets"}
::
::
-- If you want to have a custom local base chain, you must ensure you have a database for your hyperchain, as well as the local RPC for your L1.
+- If you want to have a custom local base chain, you must ensure you have a database for your ZK Chain, as well as the local RPC for your L1.
-- To run a Postgres 14 database for your hyperchain, execute the following:
+- To run a Postgres 14 database for your ZK Chain, execute the following:
```bash
docker-compose -f docker-compose-zkstack-common.yml up -d postgres
diff --git a/content/20.external-node/_dir.yml b/content/20.external-node/_dir.yml
deleted file mode 100644
index cbef62e9..00000000
--- a/content/20.external-node/_dir.yml
+++ /dev/null
@@ -1 +0,0 @@
-title: External Node
diff --git a/content/20.external-node/00.index.md b/content/20.zksync-node/00.index.md
similarity index 80%
rename from content/20.external-node/00.index.md
rename to content/20.zksync-node/00.index.md
index c47ba460..f951b5ce 100644
--- a/content/20.external-node/00.index.md
+++ b/content/20.zksync-node/00.index.md
@@ -7,53 +7,52 @@ description:
For local testing, we recommend setting up an in-memory node and forking mainnet.
::
-This documentation explains the basics of the ZKsync Era External Node.
+This documentation explains the basics of the zkSync Era Node.
## Disclaimers
-- The external node is in the alpha phase, and should be used with caution.
-- While in alpha, the EN is dependent on a DB snapshot in order to run that is not yet publicly available.
-- The EN is a read-only replica of the main node. We are currently working on decentralizing our infrastructure by
- creating a consensus node. The EN is not going to be the consensus node.
+- The zkSync node is in the beta phase, and should be used with caution.
+- While in beta, the zkSync node is dependent on a DB snapshot in order to run that is not yet publicly available.
+- The zkSync node is a read-only replica of the main node. We are currently working on decentralizing our
+infrastructure by creating a consensus node. The zkSync node is not going to be the consensus node.
-## What is the External Node?
+## What is the zkSync Node?
-The external node (herein EN) is a read-replica of the main (centralized) node that can be run by external parties. It
-functions by fetching data from the ZKsync API and re-applying transactions locally, starting from the genesis block.
-The EN 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.
+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 EN 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 EN 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 EN state.
+- Several checker modules that ensure the consistency of the zkSync node state.
-With the EN, 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 EN, 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 EN'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 EN 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.
@@ -65,7 +64,7 @@ Data getters in this namespace operate in the L2 space: require/return L2 block
Available methods:
| Method | Notes |
-| ----------------------------------------- | ------------------------------------------------------------------------- |
+|-------------------------------------------|---------------------------------------------------------------------------|
| `eth_blockNumber` | |
| `eth_chainId` | |
| `eth_call` | |
@@ -159,5 +158,5 @@ Always refer to the documentation linked above to see the list of stabilized met
### `en` namespace
-This namespace contains methods that external nodes call on the main node while syncing. If this namespace is enabled
-other ENs 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
new file mode 100644
index 00000000..5390ef1e
--- /dev/null
+++ b/content/20.zksync-node/05.quickstart.md
@@ -0,0 +1,87 @@
+---
+title: Quick Start Guide for zkSync Node
+description:
+---
+
+## Prerequisites
+
+- **Installations Required:**
+ - [Docker](https://docs.docker.com/get-docker/)
+ - [Docker Compose](https://docs.docker.com/compose/install/)
+
+## Setup Instructions
+
+1. Clone the zkSync Era repository and navigate to the external 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
+
+### Starting the Node
+
+- **For a Mainnet instance:**
+
+ ```bash
+ cd docker-compose-examples
+ docker compose --file mainnet-external-node-docker-compose.yml up
+ ```
+
+- **For a Testnet instance:**
+
+ ```bash
+ cd docker-compose-examples
+ docker compose --file testnet-external-node-docker-compose.yml up
+ ```
+
+### Resetting the Node State
+
+- **For a Mainnet instance:**
+
+ ```bash
+ cd docker-compose-examples
+ docker compose --file mainnet-external-node-docker-compose.yml down --volumes
+ ```
+
+- **For a Testnet instance:**
+
+ ```bash
+ cd docker-compose-examples
+ docker compose --file testnet-external-node-docker-compose.yml down --volumes
+ ```
+
+### Monitoring Node Status
+
+Access the local Grafana dashboard to see the node status after recovery:
+[Local Grafana Dashboard](http://localhost:3000/d/0/external-node).
+
+### API Access
+
+- **HTTP JSON-RPC API:** Port `3060`
+- **WebSocket API:** Port `3061`
+
+### Important Notes
+
+- **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
+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
+
+The following are minimal requirements:
+
+- **CPU:** A relatively modern CPU is recommended.
+- **RAM:** 32 GB
+- **Storage:**
+ - **Testnet Nodes:** 30 GB
+ - **Mainnet Nodes:** 300 GB, with the state growing about 1TB per month.
+- **Network:** 100 Mbps connection (1 Gbps+ recommended)
+
+## Advanced Setup
+
+For additional configurations like monitoring, backups, recovery from DB dump or snapshot, and custom PostgreSQL
+settings, please refer to the [ansible-en-role repository](https://github.com/matter-labs/ansible-en-role).
diff --git a/content/20.external-node/10.component-breakdown.md b/content/20.zksync-node/10.component-breakdown.md
similarity index 71%
rename from content/20.external-node/10.component-breakdown.md
rename to content/20.zksync-node/10.component-breakdown.md
index ab12f734..b32727c8 100644
--- a/content/20.external-node/10.component-breakdown.md
+++ b/content/20.zksync-node/10.component-breakdown.md
@@ -1,35 +1,35 @@
---
-title: EN Components
+title: zkSync Node Components
description:
---
-This section contains an overview of the EN's main components.
+This section contains an overview of the zkSync node's main components.
## API
-The EN 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 EN 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 EN 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 EN 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 EN 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 EN 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 EN 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 both the Main and External nodes.
+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
-is applied on L1, that is before the block is [final](https://docs.zksync.io/zk-stack/concepts/finality.html).
+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](../10.zk-stack/05.concepts/30.finality.md).
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 EN must handle them correctly.
+However, even though such situations are rare, the zkSync node must handle them correctly.
-To address this, the EN 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 EN 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 EN.
+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
@@ -79,10 +79,10 @@ 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 external node implementation or that the main node API has provided incorrect data.
-In either case, the state of the EN cannot be trusted, and the EN enters a crash loop until the issue is resolved.
+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 EN also exposes an additional server that returns HTTP 200 response when the EN is operating normally,
-and HTTP 503 response when some of the health checks don't pass (e.g. when the EN 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.external-node/20.configuration.md b/content/20.zksync-node/20.configuration.md
similarity index 53%
rename from content/20.external-node/20.configuration.md
rename to content/20.zksync-node/20.configuration.md
index 4a97957a..b1fe6a9a 100644
--- a/content/20.external-node/20.configuration.md
+++ b/content/20.zksync-node/20.configuration.md
@@ -3,33 +3,31 @@ title: Configuration
description:
---
-This document outlines various configuration options for the EN.
-Currently, the EN 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.
+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 EN uses two databases: PostgreSQL and RocksDB.
+The zkSync node uses two databases: PostgreSQL and RocksDB.
-PostgreSQL serves as the main source of truth in the EN, so all the API requests fetch the state from there.
-The PostgreSQL connection is configured by the `DATABASE_URL`.
-Additionally, the `DATABASE_POOL_SIZE` variable defines the size of the connection pool.
+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.
-RocksDB is used in components where IO is a bottleneck, such as the State Keeper and the Merkle tree.
-If possible, it is recommended to use an NVME SSD for RocksDB.
-RocksDB requires two variables to be set: `EN_STATE_CACHE_PATH` and `EN_MERKLE_TREE_PATH`, which must point to different directories.
+RocksDB is used in components where IO is a bottleneck, such as the State Keeper and the Merkle tree. If possible, it is
+recommended to use an NVME SSD for RocksDB. RocksDB requires two variables to be set: `EN_STATE_CACHE_PATH` and
+`EN_MERKLE_TREE_PATH`, which must point to different directories.
## L1 Web3 client
-EN 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).
+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 EN 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 EN quickly,
-so make sure that the L1 client won't exceed any limits (e.g. in case you use Infura).
+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
@@ -40,9 +38,8 @@ 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 EN
+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/)
periodically to avoid a memory leak due to a
@@ -54,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 EN 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 external 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.
@@ -68,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 EN 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.external-node/30.running-node.md b/content/20.zksync-node/30.running-node.md
similarity index 71%
rename from content/20.external-node/30.running-node.md
rename to content/20.zksync-node/30.running-node.md
index 4bb8113f..0708a45b 100644
--- a/content/20.external-node/30.running-node.md
+++ b/content/20.zksync-node/30.running-node.md
@@ -3,19 +3,20 @@ title: Running a Node
description:
---
-This section assumes that you have prepared a configuration file as described on the [previous page](configuration).
+This section assumes that you have prepared a configuration file as described on the previous page.
-## Preferred hardware configuration
+## System Requirements for nodes started from DB dumps
-This configuration is approximate, expect updates to these specs.
+This configuration is approximate and should be considered as **minimal** requirements.
- 32-core CPU
- 64GB RAM
-- SSD storage:
- - Testnet - ~800 GB (at the time of writing) and will grow over time, so should be constantly monitored
- - Mainnet - ~400 GB (at the time of writing) and will grow over time, so should be constantly monitored
- - NVMe recommended
-- 100 Mbps network connection.
+- SSD storage (NVME recommended):
+ - 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
+ monitored)
+- 100 Mbps connection (1 Gbps+ recommended)
### A note about PostgreSQL storage
@@ -37,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 EN and Postgres), EN 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 EN 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=`.
@@ -48,7 +49,7 @@ Besides running Postgres, you are expected to have a DB dump from a correspondin
## Running
-Assuming you have the EN 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:
@@ -66,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 EN with a new PG dump
+## Redeploying the zkSync node with a new PG dump
-If you've been running the EN for some time and are going to redeploy it using a new PG dump, you should
+If you've been running the zkSync node for some time and are going to redeploy it using a new PG dump, you should
-- Stop the EN
+- Stop the zkSync node
- Remove SK cache (corresponding to `EN_STATE_CACHE_PATH`)
- Remove your current DB
- Restore with the new dump
-- Start the EN
+- 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.external-node/40.api-overview.md b/content/20.zksync-node/40.api-overview.md
similarity index 95%
rename from content/20.external-node/40.api-overview.md
rename to content/20.zksync-node/40.api-overview.md
index 87f66b43..b9a4d695 100644
--- a/content/20.external-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 EN 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` | EN 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 external nodes 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.external-node/50.observability.md b/content/20.zksync-node/50.observability.md
similarity index 85%
rename from content/20.external-node/50.observability.md
rename to content/20.zksync-node/50.observability.md
index 16dc8e0a..61a289ca 100644
--- a/content/20.external-node/50.observability.md
+++ b/content/20.zksync-node/50.observability.md
@@ -3,7 +3,7 @@ title: Observability
description:
---
-The EN 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
@@ -13,13 +13,13 @@ This section is written with the assumption that you're familiar with
By default, latency histograms are distributed in the following buckets (in seconds):
-```txt
+```bash
[0.001, 0.005, 0.025, 0.1, 0.25, 1.0, 5.0, 30.0, 120.0]
```
## Metrics
-EN 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 EN 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 EN 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 (EN 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 EN 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.external-node/60.troubleshooting.md b/content/20.zksync-node/60.troubleshooting.md
similarity index 87%
rename from content/20.external-node/60.troubleshooting.md
rename to content/20.zksync-node/60.troubleshooting.md
index 6e1c83d3..a62424cc 100644
--- a/content/20.external-node/60.troubleshooting.md
+++ b/content/20.zksync-node/60.troubleshooting.md
@@ -3,7 +3,7 @@ title: Troubleshooting
description:
---
-The EN 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,17 +27,15 @@ Other kinds of panic aren't normally expected. While in most cases, the state wi
## Genesis Issues
-The EN is supposed to start with an applied DB dump. If you see any genesis-related errors, it probably means the EN 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.
[contact_us](https://zksync.io/contact)
## Logs
-::callout{icon="i-heroicons-information-circle" color="blue"}
-Note: logs with the `error` level are reported to Sentry if it's configured. If you notice unneeded alerts there that
-you don't consider actionable, you may disable logs for a component by tweaking the configuration.
-::
+_Note: logs with the `error` level are reported to Sentry if it's configured. If you notice unneeded alerts there that
+you don't consider actionable, you may disable logs for a component by tweaking the configuration._
| Level | Log substring | Interpretation |
| ----- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
@@ -48,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 EN 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
new file mode 100644
index 00000000..52949170
--- /dev/null
+++ b/content/20.zksync-node/_dir.yml
@@ -0,0 +1 @@
+title: zkSync Node
diff --git a/content/30.ecosystem/00.index.md b/content/30.ecosystem/00.index.md
index 6a28c5a6..36d8abbd 100644
--- a/content/30.ecosystem/00.index.md
+++ b/content/30.ecosystem/00.index.md
@@ -1,10 +1,10 @@
---
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.
+in the zkSync Era ecosystem.
::card-group
::card
@@ -29,7 +29,7 @@ in the ZKsync Era ecosystem.
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
---
@@ -61,7 +61,7 @@ in the ZKsync Era ecosystem.
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 17fab019..ce12d649 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-de=bridges) 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.
## Omnibtc Finance
@@ -24,7 +24,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 c3243ddc..81aac225 100644
--- a/content/30.ecosystem/100.wallets.md
+++ b/content/30.ecosystem/100.wallets.md
@@ -3,19 +3,19 @@ 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.
## 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.
**Availability**: App Store (IOS and MacOS), Google Play Store
@@ -28,7 +28,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)
## Holdstation
diff --git a/content/30.ecosystem/30.data-indexers.md b/content/30.ecosystem/30.data-indexers.md
index 1cd1dbc0..6f928aa5 100644
--- a/content/30.ecosystem/30.data-indexers.md
+++ b/content/30.ecosystem/30.data-indexers.md
@@ -6,8 +6,8 @@ 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.
## Covalent
@@ -32,7 +32,7 @@ to make it easy to receive, transform, store and access your on-chain data.
[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 9c360602..62fc5434 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://twitter.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 164a1678..b340af24 100644
--- a/content/30.ecosystem/50.monitoring.md
+++ b/content/30.ecosystem/50.monitoring.md
@@ -6,7 +6,7 @@ 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.
diff --git a/content/30.ecosystem/60.network-faucets.md b/content/30.ecosystem/60.network-faucets.md
index 28ee9f33..da5d5e5a 100644
--- a/content/30.ecosystem/60.network-faucets.md
+++ b/content/30.ecosystem/60.network-faucets.md
@@ -30,4 +30,4 @@ using the [TxSync bridge](https://portal.txsync.io/bridge/?network=era-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 zkSync Sepolia or Ethereum Sepolia Testnet.
diff --git a/content/30.ecosystem/70.nft-marketplaces.md b/content/30.ecosystem/70.nft-marketplaces.md
index c17f966c..11e7c020 100644
--- a/content/30.ecosystem/70.nft-marketplaces.md
+++ b/content/30.ecosystem/70.nft-marketplaces.md
@@ -12,11 +12,11 @@ management of NFTs. These platforms offer distinct features and benefits.
buy and sell NFTs across different platforms, save money, and earn rewards.
**Specialty**: Aggregated Marketplace, Rewards
-## Kreatorland
+## Libera
-[Kreatorland](https://kreatorland.com/) is a native NFT marketplace built specifically for the
-ZKsync Era.
-**Specialty**: ZKsync Era Native
+[Libera](https://libera.xyz/) is a native NFT marketplace built specifically for the
+zkSync Era.
+**Specialty**: zkSync Era Native
## OKX NFT
@@ -27,16 +27,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 c019a6cd..93b05c8a 100644
--- a/content/30.ecosystem/80.oracles.md
+++ b/content/30.ecosystem/80.oracles.md
@@ -6,25 +6,38 @@ 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.
+### Chainlink
+
+[Chainlink](https://docs.chain.link/data-feeds/price-feeds/addresses?network=zksync&page=1) private feeds provide
+secure, reliable, and tamper-proof price data for your smart contracts.
+
## DIA
[DIA](https://docs.diadata.org/products/token-price-feeds) token price feeds provide smart
contract real-time price information of 3,000+ cryptocurrencies, transparently sourced from 80+
trusted, high-volume DEXs and CEXs. Check out the usage guide below to get started today!
-## Redstone
+### Gelato
-[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.
+[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
+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.
## Pyth
-[Pythnet](https://docs.pyth.network/documentation/pythnet-price-feeds) price feeds use a "pull"
+[Pythnet](https://docs.pyth.network/price-feeds) price feeds use a "pull"
price update model, where users are responsible for posting price updates on-chain when needed.
Checkout the usage guide to get started today!
+
+## Redstone
+
+[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.
diff --git a/content/30.ecosystem/90.node-providers.md b/content/30.ecosystem/90.node-providers.md
index 3f72d4f4..ac80b882 100644
--- a/content/30.ecosystem/90.node-providers.md
+++ b/content/30.ecosystem/90.node-providers.md
@@ -3,16 +3,21 @@ title: RPC Providers
description:
---
+### 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).
+
## 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
@@ -27,26 +32,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.
+
## 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 e7b51f54..27e6d4fa 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 d8e5a12b..34c05e01 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/_zksync.json b/content/_zksync.json
index af8b4a99..c02576e8 100644
--- a/content/_zksync.json
+++ b/content/_zksync.json
@@ -1,9 +1,9 @@
{
"zkevm": {
- "label": "ZKsync VM"
+ "label": "zkSync VM"
},
"mainnet": {
- "name": "ZKsync Era Mainnet",
+ "name": "zkSync Era Mainnet",
"identifier": "mainnet",
"rpc_url": "https://mainnet.era.zksync.io",
"websocket_url": "wss://mainnet.era.zksync.io/ws",
@@ -12,7 +12,7 @@
"block_explorer_url": "https://explorer.zksync.io"
},
"testnet": {
- "name": "ZKsync Sepolia Testnet",
+ "name": "zkSync Sepolia Testnet",
"identifier": "sepolia",
"rpc_url": "https://sepolia.era.zksync.dev",
"websocket_url": "wss://sepolia.era.zksync.dev/ws",
@@ -43,7 +43,7 @@
"zksolc-bin": "https://github.com/matter-labs/zksolc-bin",
"zksync-cli": "https://github.com/matter-labs/zksync-cli",
"zksync-contract-templates": "https://github.com/matter-labs/zksync-contract-templates",
- "zksync-developers": "https://github.com/ZKsync-Community-Hub/zksync-developers",
+ "zksync-developers": "https://github.com/zkSync-Community-Hub/zksync-developers",
"zksync-docs": "https://github.com/matter-labs/zksync-docs",
"zksync-era": "https://github.com/matter-labs/zksync-era",
"zksync-frontend-templates": "https://github.com/matter-labs/zksync-frontend-templates",
diff --git a/content/index.yml b/content/index.yml
index 76869899..c79f144e 100644
--- a/content/index.yml
+++ b/content/index.yml
@@ -1,18 +1,18 @@
-title: 'ZKsync Docs'
+title: 'zkSync Docs'
description:
Nuxt UI Pro is a collection of premium Vue components built on top of Nuxt UI to create beautiful & responsive Nuxt
applications in minutes.
navigation: false
hero:
- title: 'Unlock the Potential of Layer 2 Scaling with ZKsync'
- description: 'Explore comprehensive guides, developer tools, and resources to innovate on the ZKsync platform.'
+ title: 'Unlock the Potential of Layer 2 Scaling with zkSync'
+ description: 'Explore comprehensive guides, developer tools, and resources to innovate on the zkSync platform.'
orientation: vertical
headline:
label: See what's new in 21.1.0
to: https://github.com/matter-labs/zksync-era/releases
icon: i-heroicons-arrow-top-right-on-square-20-solid
links:
- - label: Start building on ZKsync
+ - label: Start building on zkSync
icon: i-heroicons-arrow-right-20-solid
trailing: true
to: '/build'
@@ -24,10 +24,10 @@ hero:
# to: https://github.com/nuxt-ui-pro/docs
# target: _blank
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: '#'
- title: 'Develop with zksync-cli'
@@ -35,13 +35,13 @@ features:
icon: 'i-simple-icons-windowsterminal'
to: '#'
- 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: '#'
community:
- title: 'Join the ZKsync Community'
+ title: 'Join the zkSync Community'
links:
- - label: 'Learn more about ZKsync'
+ - label: 'Learn more about zkSync'
icon: 'i-zksync-zksync-logo'
trailingIcon: 'i-heroicons-arrow-right-20-solid'
color: 'gray'
@@ -49,14 +49,14 @@ community:
size: lg
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: '#'
- 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: '#'
- - title: 'ZKsync Discord'
- description: 'Connect with devs and ZKsync enthusiasts on Discord.'
+ - title: 'zkSync Discord'
+ description: 'Connect with devs and zkSync enthusiasts on Discord.'
icon: 'i-simple-icons-discord'
to: '#'
diff --git a/cspell-config/cspell-dev.txt b/cspell-config/cspell-dev.txt
index a8e60196..a7cd411a 100644
--- a/cspell-config/cspell-dev.txt
+++ b/cspell-config/cspell-dev.txt
@@ -95,6 +95,10 @@ hexlify
insize
ecadd
ecmul
+Gbps
+ansible
+Gelato
+VRFs
// devs
dutterbutter
diff --git a/cspell-config/cspell-zksync.txt b/cspell-config/cspell-zksync.txt
index 0f305b04..6e34792d 100644
--- a/cspell-config/cspell-zksync.txt
+++ b/cspell-config/cspell-zksync.txt
@@ -1,4 +1,4 @@
-// ZKsync-related words
+// zkSync-related words
boojum
MatterLabs
Zeek
@@ -10,8 +10,6 @@ zkforge
zkout
zksolc
zkstack
-ZKsync
zksync
-!zkSync
zksync-cli
zkvyper
diff --git a/layouts/build-section.vue b/layouts/build-section.vue
index b76bcd72..601189f7 100644
--- a/layouts/build-section.vue
+++ b/layouts/build-section.vue
@@ -5,7 +5,7 @@ const { data: navigation } = await useAsyncData('build-navigation', () => {
_extension: 'md',
where: [
{
- _path: { $contains: 'build' },
+ _path: { $contains: '/build' },
},
],
});
diff --git a/layouts/ecosystem-section.vue b/layouts/ecosystem-section.vue
index 735279de..d1d611b6 100644
--- a/layouts/ecosystem-section.vue
+++ b/layouts/ecosystem-section.vue
@@ -5,13 +5,14 @@ const { data: navigation } = await useAsyncData('ecosystem-navigation', () => {
_extension: 'md',
where: [
{
- _path: { $contains: 'ecosystem' },
+ _path: { $contains: '/ecosystem' },
},
],
});
return fetchContentNavigation(query);
});
+console.log('WUT', navigation.value);
const navTree = (navigation.value && navigation.value[0] && navigation.value[0].children) || [];
diff --git a/layouts/zk-stack-section.vue b/layouts/zk-stack-section.vue
index f220e0ef..4fa8db42 100644
--- a/layouts/zk-stack-section.vue
+++ b/layouts/zk-stack-section.vue
@@ -5,7 +5,7 @@ const { data: navigation } = await useAsyncData('zk-stack-navigation', () => {
_extension: 'md',
where: [
{
- _path: { $contains: 'zk-stack' },
+ _path: { $contains: '/zk-stack' },
},
],
});
diff --git a/layouts/external-node-section.vue b/layouts/zksync-node-section.vue
similarity index 82%
rename from layouts/external-node-section.vue
rename to layouts/zksync-node-section.vue
index 93076e9e..bff904ac 100644
--- a/layouts/external-node-section.vue
+++ b/layouts/zksync-node-section.vue
@@ -1,11 +1,11 @@