build: Set consensus and pruning as default for EN (matter-labs#2956)

## What ❔
ENs, started from docker compose, now have consensus and pruning enabled
as default. Also, the EN docs were updated.

docs/guides/external-node/00_quick_start.md

@@ -10,28 +10,28 @@ To start a mainnet instance, run:
 
 ```sh
 cd docker-compose-examples
-docker compose --file mainnet-external-node-docker-compose.yml up
+sudo docker compose --file mainnet-external-node-docker-compose.yml up
 ```
 
 To reset its state, run:
 
 ```sh
 cd docker-compose-examples
-docker compose --file mainnet-external-node-docker-compose.yml down --volumes
+sudo docker compose --file mainnet-external-node-docker-compose.yml down --volumes
 ```
 
 To start a testnet instance, run:
 
 ```sh
 cd docker-compose-examples
-docker compose --file testnet-external-node-docker-compose.yml up
+sudo docker compose --file testnet-external-node-docker-compose.yml up
 ```
 
 To reset its state, run:
 
 ```sh
 cd docker-compose-examples
-docker compose --file testnet-external-node-docker-compose.yml down --volumes
+sudo 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/dashboards).
@@ -44,33 +44,23 @@ The HTTP JSON-RPC API can be accessed on port `3060` and WebSocket API can be ac
 >
 > The node will recover from a snapshot on it's first run, this may take up to 10h. Before the recovery is finished, the
 > API server won't serve any requests.
-
-> [!NOTE]
 >
 > If you need access to historical transaction data, please use recovery from DB dumps (see Advanced setup section)
 
 ### System 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 nodes that use snapshots recovery and history pruning (the default for docker-compose setup).
 >
-> Those are requirements for a freshly started node and the the state grows about 1TB per month for mainnet
-
-> [!NOTE]
+> For requirements for nodes running from DB dump see the [running](03_running.md) section. DB dumps are a way to start ZKsync node with full historical transactions history.
 >
-> To stop historical DB growth, you can enable DB pruning by uncommenting `EN_PRUNING_ENABLED: true` in docker compose
-> file, you can read more about pruning in
-> [08_pruning.md](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/08_pruning.md)
+> For nodes with pruning disabled, expect the storage requirements on mainnet to grow at 1TB per month. If you want to stop historical DB
+> pruning you can read more about this in the [pruning](08_pruning.md) section.
 
 - 32 GB of RAM and a relatively modern CPU
 - 50 GB of storage for testnet nodes
-- 300 GB of storage for mainnet nodes
+- 500 GB of storage for mainnet nodes
 - 100 Mbps connection (1 Gbps+ recommended)
 
 ## Advanced setup

docs/guides/external-node/01_intro.md

@@ -5,28 +5,27 @@ This documentation explains the basics of the ZKsync Node.
 ## Disclaimers
 
 - The ZKsync node is in the alpha phase, and should be used with caution.
-- The ZKsync node is a read-only replica of the main node. We are currently working on decentralizing our infrastructure
-  by creating a consensus node. The ZKsync node is not going to be the consensus node.
+- The ZKsync node is a read-only replica of the main node.
 
 ## What is the ZKsync node
 
 The ZKsync node is a read-replica of the main (centralized) node that can be run by external parties. It functions by
-fetching data from the ZKsync API and re-applying transactions locally, starting from the genesis block. The ZKsync node
+receiving blocks from the ZKsync network 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:**
 
 - recovery from a DB dump, in Ethereum terms this corresponds to archival node
 - recovery from a snapshot, in Ethereum terms this corresponds to light node, such nodes will only have access to
-  transactions data from after the node was initialized. The database is currently not pruned on such nodes.
+  transactions data from after the node was initialized. The database can be pruned on such nodes.
 
 ## High-level overview
 
 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.
+- Consensus layer that interacts with the peer network and retrieves transactions and blocks to re-execute.
 - Sequencer component that actually executes and persists transactions received from the synchronization layer.
 - Several checker modules that ensure the consistency of the ZKsync node state.
 
@@ -44,7 +43,7 @@ With the EN, you _can not_:
 - Generate proofs.
 - Submit data to L1.
 
-A more detailed overview of the EN's components is provided in the [components](./06_components.md) section.
+A more detailed overview of the EN's components is provided in the [components](06_components.md) section.
 
 ## API overview
 

docs/guides/external-node/03_running.md

@@ -2,10 +2,10 @@
 
 > [!NOTE]
 >
-> If you want to just run node with recommended default setting, please see directory docker-compose-examples
+> If you want to just run node with recommended default setting, please see the [quick start](00_quick_start.md) page.
 
 This section assumes that you have prepared a configuration file as described on the
-[previous page](./02_configuration.md).
+[previous page](02_configuration.md).
 
 ## System Requirements for nodes started from DB dumps
 
@@ -80,4 +80,4 @@ If you've been running the ZKsync node for some time and are going to redeploy i
 - Start the EN
 
 Monitoring the node behavior and analyzing the state it's in is covered in the
-[observability section](./04_observability.md).
+[observability section](04_observability.md).

docs/guides/external-node/04_observability.md

@@ -1,7 +1,7 @@
 # ZKsync node Observability
 
 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.
+[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
 [Prometheus](https://prometheus.io/docs/introduction/overview/) and [Grafana](https://grafana.com/docs/).
@@ -38,17 +38,6 @@ memory leaking.
 | `api_web3_call`                                | Histogram | `method`                              | Duration of Web3 API calls                                         |
 | `sql_connection_acquire`                       | Histogram | -                                     | Time to get an SQL connection from the connection pool             |
 
-## Interpretation
-
-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 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`.
 
 Metrics can be used to detect anomalies in configuration, which is described in more detail in the
-[next section](./05_troubleshooting.md).
+[next section](05_troubleshooting.md).

docs/guides/external-node/07_snapshots_recovery.md

@@ -2,7 +2,7 @@
 
 Instead of initializing a node using a Postgres dump, it's possible to configure a node to recover from a protocol-level
 snapshot. This process is much faster and requires much less storage. Postgres database of a mainnet node recovered from
-a snapshot is only about 300GB. Note that without [pruning](08_pruning.md) enabled, the node state will continuously
+a snapshot is less than 500GB. Note that without [pruning](08_pruning.md) enabled, the node state will continuously
 grow at a rate about 15GB per day.
 
 ## How it works
@@ -97,5 +97,3 @@ Recovery logic also exports some metrics, the main of which are as follows:
 | Metric name                                             | Type      | Labels       | Description                                                           |
 | ------------------------------------------------------- | --------- | ------------ | --------------------------------------------------------------------- |
 | `snapshots_applier_storage_logs_chunks_left_to_process` | Gauge     | -            | Number of storage log chunks left to process during Postgres recovery |
-| `db_pruner_pruning_chunk_duration_seconds`              | Histogram | `prune_type` | Latency of a single pruning iteration                                 |
-| `merkle_tree_pruning_deleted_stale_key_versions`        | Gauge     | `bound`      | Versions (= L1 batches) pruned from the Merkle tree                   |

docs/guides/external-node/08_pruning.md

@@ -48,7 +48,7 @@ of the first block in the batch). You can configure the retention period using:
 EN_PRUNING_DATA_RETENTION_SEC: '259200' # 3 days
 ```
 
-The retention period can be set to any value, but for mainnet values under 21h will be ignored because a batch can only
+The retention period can be set to any value, but for mainnet values under 24h will be ignored because a batch can only
 be pruned after it has been executed on Ethereum.
 
 Pruning can be disabled or enabled and the data retention period can be freely changed during the node lifetime.

docs/guides/external-node/docker-compose-examples/mainnet-external-node-docker-compose.yml

@@ -65,7 +65,6 @@ services:
     entrypoint:
       [
       "/usr/bin/entrypoint.sh",
-      # Uncomment the following line to enable consensus
       "--enable-consensus",
       ]
     restart: always
@@ -97,7 +96,7 @@ services:
       EN_MAIN_NODE_URL: https://zksync2-mainnet.zksync.io
       EN_L1_CHAIN_ID: 1
       EN_L2_CHAIN_ID: 324
-      # EN_PRUNING_ENABLED: true
+      EN_PRUNING_ENABLED: true
 
       EN_STATE_CACHE_PATH: "./db/ext-node/state_keeper"
       EN_MERKLE_TREE_PATH: "./db/ext-node/lightweight"

docs/guides/external-node/docker-compose-examples/testnet-external-node-docker-compose.yml

@@ -65,7 +65,6 @@ services:
     entrypoint:
       [
       "/usr/bin/entrypoint.sh",
-      # Uncomment the following line to enable consensus
       "--enable-consensus",
       ]
     restart: always
@@ -97,7 +96,7 @@ services:
       EN_MAIN_NODE_URL: https://sepolia.era.zksync.dev
       EN_L1_CHAIN_ID: 11155111
       EN_L2_CHAIN_ID: 300
-      # EN_PRUNING_ENABLED: true
+      EN_PRUNING_ENABLED: true
 
       EN_STATE_CACHE_PATH: "./db/ext-node/state_keeper"
       EN_MERKLE_TREE_PATH: "./db/ext-node/lightweight"