diff --git a/docs/guides/external-node/00_quick_start.md b/docs/guides/external-node/00_quick_start.md index 5fd6bae2b9ac..e244268e7845 100644 --- a/docs/guides/external-node/00_quick_start.md +++ b/docs/guides/external-node/00_quick_start.md @@ -4,7 +4,7 @@ Install `docker compose` and `Docker` -## Running ZkSync external node locally +## Running zkSync node locally To start a mainnet instance, run: @@ -37,7 +37,7 @@ docker compose --file testnet-external-node-docker-compose.yml down --volumes You can see the status of the node (after recovery) in [local grafana dashboard](http://localhost:3000/d/0/external-node). -Those commands start external node locally inside docker. +Those commands start zkSync node locally inside docker. The HTTP JSON-RPC API can be accessed on port `3060` and WebSocket API can be accessed on port `3061`. @@ -52,17 +52,23 @@ The HTTP JSON-RPC API can be accessed on port `3060` and WebSocket API can be ac ### System Requirements -This configuration is approximate and should be considered as **minimal** requirements. +> [!NOTE] +> +> This configuration is only for nodes that use snapshots recovery (the default for docker-compose setup), for +> requirements for nodes running from DB dump see +> [03_running.md](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/03_running.md). DB dumps +> are a way to start zkSync node with full historical transactions history + +> [!NOTE] +> +> Those are requirements for a freshly started node and the the state grows about 1TB per month for mainnet -- 32-core CPU -- 64GB RAM -- SSD storage (NVME recommended): - - Sepolia Testnet - 10GB EN + 50GB PostgreSQL (at the time of writing, will grow over time, so should be constantly - monitored) - - Mainnet - 3TB EN + 7TB PostgreSQL (at the time of writing, will grow over time, so should be constantly monitored) +- 32 GB of RAM and a relatively modern CPU +- 30 GB of storage for testnet nodes +- 300 GB of storage for mainnet nodes - 100 Mbps connection (1 Gbps+ recommended) ## Advanced setup -If you need monitoring, backups, to recover from DB dump/snapshot or a more customized PostgreSQL settings, etc, please -see: [ansible-en-role repo](https://github.com/matter-labs/ansible-en-role) +If you need monitoring, backups, to recover from DB dump or a more customized PostgreSQL settings, etc, please see: +[ansible-en-role repo](https://github.com/matter-labs/ansible-en-role) diff --git a/docs/guides/external-node/01_intro.md b/docs/guides/external-node/01_intro.md index bd443a58f9bd..58d47cdb7ad9 100644 --- a/docs/guides/external-node/01_intro.md +++ b/docs/guides/external-node/01_intro.md @@ -1,19 +1,19 @@ -# External Node Documentation +# ZkSync Node Documentation -This documentation explains the basics of the zkSync Era External Node. +This documentation explains the basics of the zkSync Node. ## Disclaimers -- The external node is in the alpha phase, and should be used with caution. -- 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 alpha phase, and should be used with caution. +- The zkSync node is a read-only replica of the main node. We are currently working on decentralizing our infrastructure + by creating a consensus node. The zkSync node is not going to be the consensus node. -## What is the 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 external parties. It functions by +fetching data from the zkSync API and re-applying transactions locally, starting from the genesis block. The zkSync node +shares most of its codebase with the main node. Consequently, when it re-applies transactions, it does so exactly as the +main node did in the past. **It has two modes of initialization:** @@ -23,12 +23,12 @@ as the main node did in the past. ## 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: @@ -48,8 +48,8 @@ A more detailed overview of the EN's components is provided in the [components]( ## API overview -API exposed by the EN strives to be Web3-compliant. If some method is exposed but behaves differently compared to -Ethereum, it should be considered a bug. Please [report][contact_us] such cases. +API exposed by the zkSync node strives to be Web3-compliant. If some method is exposed but behaves differently compared +to Ethereum, it should be considered a bug. Please [report][contact_us] such cases. [contact_us]: https://zksync.io/contact @@ -59,42 +59,42 @@ Data getters in this namespace operate in the L2 space: require/return L2 block Available methods: -| Method | Notes | -| ----------------------------------------- | ------------------------------------------------------------------------- | -| `eth_blockNumber` | | -| `eth_chainId` | | -| `eth_call` | | -| `eth_estimateGas` | | -| `eth_gasPrice` | | -| `eth_newFilter` | Maximum amount of installed filters is configurable | -| `eth_newBlockFilter` | Same as above | -| `eth_newPendingTransactionsFilter` | Same as above | -| `eth_uninstallFilter` | | -| `eth_getLogs` | Maximum amount of returned entities can be configured | -| `eth_getFilterLogs` | Same as above | -| `eth_getFilterChanges` | Same as above | -| `eth_getBalance` | | -| `eth_getBlockByNumber` | | -| `eth_getBlockByHash` | | -| `eth_getBlockTransactionCountByNumber` | | -| `eth_getBlockTransactionCountByHash` | | -| `eth_getCode` | | -| `eth_getStorageAt` | | -| `eth_getTransactionCount` | | -| `eth_getTransactionByHash` | | -| `eth_getTransactionByBlockHashAndIndex` | | -| `eth_getTransactionByBlockNumberAndIndex` | | -| `eth_getTransactionReceipt` | | -| `eth_protocolVersion` | | -| `eth_sendRawTransaction` | | -| `eth_syncing` | EN 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 | -| `eth_hashrate` | Always returns zero | -| `eth_getUncleCountByBlockHash` | Always returns zero | -| `eth_getUncleCountByBlockNumber` | Always returns zero | -| `eth_mining` | Always returns false | +| Method | Notes | +| ----------------------------------------- | ---------------------------------------------------------------------------------- | +| `eth_blockNumber` | | +| `eth_chainId` | | +| `eth_call` | | +| `eth_estimateGas` | | +| `eth_gasPrice` | | +| `eth_newFilter` | Maximum amount of installed filters is configurable | +| `eth_newBlockFilter` | Same as above | +| `eth_newPendingTransactionsFilter` | Same as above | +| `eth_uninstallFilter` | | +| `eth_getLogs` | Maximum amount of returned entities can be configured | +| `eth_getFilterLogs` | Same as above | +| `eth_getFilterChanges` | Same as above | +| `eth_getBalance` | | +| `eth_getBlockByNumber` | | +| `eth_getBlockByHash` | | +| `eth_getBlockTransactionCountByNumber` | | +| `eth_getBlockTransactionCountByHash` | | +| `eth_getCode` | | +| `eth_getStorageAt` | | +| `eth_getTransactionCount` | | +| `eth_getTransactionByHash` | | +| `eth_getTransactionByBlockHashAndIndex` | | +| `eth_getTransactionByBlockNumberAndIndex` | | +| `eth_getTransactionReceipt` | | +| `eth_protocolVersion` | | +| `eth_sendRawTransaction` | | +| `eth_syncing` | zkSync node is considered synced if it's less than 11 blocks behind the main node. | +| `eth_coinbase` | Always returns a zero address | +| `eth_accounts` | Always returns an empty list | +| `eth_getCompilers` | Always returns an empty list | +| `eth_hashrate` | Always returns zero | +| `eth_getUncleCountByBlockHash` | Always returns zero | +| `eth_getUncleCountByBlockNumber` | Always returns zero | +| `eth_mining` | Always returns false | ### PubSub @@ -154,5 +154,5 @@ Always refer to the documentation linked above to see the list of stabilized met ### `en` namespace -This namespace contains methods that external nodes call on the main node while syncing. If this namespace is enabled, +This namespace contains methods that zkSync nodes call on the main node while syncing. If this namespace is enabled, other ENs can sync from this node. diff --git a/docs/guides/external-node/02_configuration.md b/docs/guides/external-node/02_configuration.md index 7771c5476f97..336d01479089 100644 --- a/docs/guides/external-node/02_configuration.md +++ b/docs/guides/external-node/02_configuration.md @@ -1,7 +1,7 @@ -# External Node Configuration +# ZkSync Node Configuration -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 +This document outlines various configuration options for the EN. Currently, the zkSync node requires the definition of +numerous environment variables. To streamline this process, we provide prepared configs for the zkSync Era - for both [mainnet](prepared_configs/mainnet-config.env) and [testnet](prepared_configs/testnet-sepolia-config.env). You can use these files as a starting point and modify only the necessary sections. @@ -10,7 +10,7 @@ default settings.** ## Database -The 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 @@ -22,12 +22,12 @@ recommended to use an NVME SSD for RocksDB. RocksDB requires two variables to be ## 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). +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 @@ -50,22 +50,22 @@ the metrics, leave this port not configured, and the metrics won't be collected. There are variables that allow you to fine-tune the limits of the RPC servers, such as limits on the number of returned entries or the limit for the accepted transaction size. Provided files contain sane defaults that are recommended for -use, but these can be edited, e.g. to make the 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 -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. +`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. ## Logging and observability `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 -format [here](https://docs.rs/env_logger/0.10.0/env_logger/#enabling-logging). +`RUST_LOG` variable allows you to set up the logs granularity (e.g. make the zkSync node emit fewer logs). You can read +about the format [here](https://docs.rs/env_logger/0.10.0/env_logger/#enabling-logging). `MISC_SENTRY_URL` and `MISC_OTLP_URL` variables can be configured to set up Sentry and OpenTelemetry exporters. diff --git a/docs/guides/external-node/03_running.md b/docs/guides/external-node/03_running.md index 93bffa33a56c..f6f76271c0c7 100644 --- a/docs/guides/external-node/03_running.md +++ b/docs/guides/external-node/03_running.md @@ -1,13 +1,24 @@ -# Running the External Node +# Running the ZkSync Node > [!NOTE] > -> If you want to just run external with recommended default setting, please see directory docker-compose-examples +> If you want to just run node with recommended default setting, please see directory docker-compose-examples This section assumes that you have prepared a configuration file as described on the [previous page](./02_configuration.md). -[**Minimal system requirements**](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/00_quick_start.md#system-requirements) +## System Requirements for nodes started from DB dumps + +This configuration is approximate and should be considered as **minimal** requirements. + +- 32-core CPU +- 64GB RAM +- SSD storage (NVME recommended): + - Sepolia Testnet - 10GB zkSync node + 50GB PostgreSQL (at the time of writing, will grow over time, so should be + 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 @@ -25,23 +36,23 @@ it in Docker. There are many of guides on that, [here's one example](https://www.docker.com/blog/how-to-use-the-postgres-docker-official-image/). Note however that if you run PostgresSQL as a stand-alone Docker image (e.g. not in Docker-compose with a network shared -between EN and Postgres), EN 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][host_docker_internal]). +between zkSync node and Postgres), zkSync node won't be able to access Postgres via `localhost` or `127.0.0.1` URLs. To +make it work, you'll have to either run it with a `--network host` (on Linux) or use `host.docker.internal` instead of +`localhost` in the zkSync node configuration ([official docs][host_docker_internal]). Besides running Postgres, you are expected to have a DB dump from a corresponding env. You can restore it using `pg_restore -O -C <DUMP_PATH> --dbname=<DB_URL>`. You can also refer to -[External Node configuration management blueprint](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/00_quick_start.md#advanced-setup) +[ZkSync Node configuration management blueprint](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/00_quick_start.md#advanced-setup) for advanced DB instance configurations. [host_docker_internal](https://docs.docker.com/desktop/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host) ## Running -Assuming you have the EN Docker image, an env file with the prepared configuration, and you have restored your DB with -the pg dump, that is all you need. +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: @@ -58,9 +69,9 @@ in RocksDB (mainly the Merkle tree) is absent. Before the node can make any prog RocksDB and verify consistency. The exact time required for that depends on the hardware configuration, but it is reasonable to expect the state rebuild on the mainnet to take more than 20 hours. -## Redeploying the 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 - Remove SK cache (corresponding to `EN_STATE_CACHE_PATH`) diff --git a/docs/guides/external-node/04_observability.md b/docs/guides/external-node/04_observability.md index c3efc33a30bd..1199503cc924 100644 --- a/docs/guides/external-node/04_observability.md +++ b/docs/guides/external-node/04_observability.md @@ -1,6 +1,6 @@ -# EN Observability +# zkSync node Observability -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](./02_configuration.md) section, so this section focuses on the exposed metrics. This section is written with the assumption that you're familiar with @@ -16,8 +16,8 @@ By default, latency histograms are distributed in the following buckets (in seco ## Metrics -EN 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. +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 memory leaking. @@ -25,7 +25,7 @@ memory leaking. | Metric name | Type | Labels | Description | | ---------------------------------------------- | --------- | ------------------------------------- | ------------------------------------------------------------------ | | `external_node_synced` | Gauge | - | 1 if synced, 0 otherwise. Matches `eth_call` behavior | -| `external_node_sync_lag` | Gauge | - | How many blocks behind the main node the 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 | @@ -40,12 +40,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. -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 -progress). +After applying a dump, the zkSync node has to rebuild the Merkle tree to verify the correctness of the state in +PostgreSQL. During this stage, `server_block_number { stage='tree_lightweight_mode' }` is increasing from 0 to +`server_block_number { stage='sealed' }`, while the latter does not increase (zkSync node needs the tree to be +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/docs/guides/external-node/05_troubleshooting.md b/docs/guides/external-node/05_troubleshooting.md index 58b540542893..1179a3e43efb 100644 --- a/docs/guides/external-node/05_troubleshooting.md +++ b/docs/guides/external-node/05_troubleshooting.md @@ -1,8 +1,8 @@ -# EN Troubleshooting +# zkSync node Troubleshooting -The EN 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. +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. However, if the node enters the crash loop or otherwise behaves unexpectedly, it may indicate either a bug in the implementation or a problem with configuration. This section tries to cover common problems. @@ -24,8 +24,8 @@ 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 -started without an applied dump. +The zkSync node is supposed to start with an applied DB dump. If you see any genesis-related errors, it probably means +the zkSync node was started without an applied dump. [contact_us]: https://zksync.io/contact @@ -43,7 +43,7 @@ you don't consider actionable, you may disable logs for a component by tweaking | WARN | "Following transport error occurred" | There was a problem with fetching data from the main node. | | WARN | "Unable to get the gas price" | There was a problem with fetching data from the main node. | | WARN | "Consistency checker error" | There are problems querying L1, check the Web3 URL you specified in the config. | -| WARN | "Reorg detected" | Reorg was detected on the main node, the 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/docs/guides/external-node/06_components.md b/docs/guides/external-node/06_components.md index 0fad9f3837fa..365d8227ef8e 100644 --- a/docs/guides/external-node/06_components.md +++ b/docs/guides/external-node/06_components.md @@ -1,41 +1,42 @@ -# EN components +# zkSync node components This section contains an overview of the EN's main components. ## API -The EN 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: +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, 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. +- Querying transactions: The zkSync node is not aware of the main node's mempool, and it does not sync rejected + transactions. Therefore, if a local lookup for a transaction or its receipt fails, the zkSync node will attempt the + same query on the main node. Apart from these cases, the API does not depend on the main node. Even if the main node is temporarily unavailable, the -EN can continue to serve the state it has locally. +zkSync node can continue to serve the state it has locally. ## Fetcher -The Fetcher component is responsible for maintaining synchronization between the EN 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. +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 -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. +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. ## State Keeper / VM 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 based on the data obtained from the Fetcher queue. +when a specific L2 block or L1 batch should be sealed. On the other hand, the zkSync node retrieves transactions from +the queue populated by the Fetcher and seals the corresponding blocks/batches based on the data obtained from the +Fetcher queue. -The actual execution of batches takes place within the VM, which is identical in both the Main and External nodes. +The actual execution of batches takes place within the VM, which is identical in both the Main and zkSync nodes. ## Reorg Detector @@ -45,13 +46,13 @@ due to significant issues: e.g. a bug in the sequencer implementation preventing 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. 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. +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. [finality]: https://era.zksync.io/docs/dev/developer-guides/finality.html @@ -66,12 +67,13 @@ When the Consistency Checker detects that a particular batch has been sent to L1 known as the "block commitment" for the L1 transaction. The block commitment contains crucial data such as the state root and batch number, and is the same commitment that is used for generating a proof for the batch. The Consistency Checker then compares the locally obtained commitment with the actual commitment sent to L1. If the data does not match, -it indicates a potential bug in either the main node or 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. +it indicates a potential bug in either the main node or zkSync node implementation or that the main node API has +provided incorrect data. In either case, the state of the zkSync node cannot be trusted, and the zkSync node enters a +crash loop until the issue is resolved. ## Health check server -The 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). This server can be -used, for example, to implement the readiness probe in an orchestration solution you use. +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.