Update docs with seed peer list from main node

Author: brunoffranca

docs/src/guides/advanced/16_decentralization.md

@@ -34,7 +34,7 @@ If you are using the recommended file-based configuration then you'll need to ad
 ```yaml
 consensus:
   server_addr: '0.0.0.0:3054'
-  public_addr:
+  public_addr: '???'
     # Address under which the node is accessible to the other nodes.
     # It can be a public domain, like `example.com:3054`, in case the main node is accessible from the internet,
     # or it can be a kubernetes cluster domain, like `server-v2-core.<cluster name>.svc.cluster.local:3054` in
@@ -46,9 +46,12 @@ consensus:
     chain_id: ??? # chain id
     protocol_version: 1 # consensus protocol version
     validators:
-      - key: validator:public:??? # public key of the main node (copy this PUBLIC key from the secrets you generated)
+      - key: validator:public:??? # validator public key of the main node (copy this PUBLIC key from the secrets you generated)
         weight: 1
     leader: validator:public:??? # same as above - main node will be the only validator and the only leader.
+    seed_peers:
+      - key: 'node:public:ed25519:...' # node public key of the main node (copy this PUBLIC key from the secrets you generated)
+        addr: '???' # same as public_addr above
 ```
 
 And the secrets you generated to your `secrets.yaml` config file:
@@ -67,7 +70,7 @@ content:
 
 ```yaml
 server_addr: '0.0.0.0:3054'
-public_addr:
+public_addr: '???'
   # Address under which the node is accessible to the other nodes.
   # It can be a public domain, like `example.com:3054`, in case the main node is accessible from the internet,
   # or it can be a kubernetes cluster domain, like `server-v2-core.<cluster name>.svc.cluster.local:3054` in
@@ -79,9 +82,12 @@ genesis_spec:
   chain_id: ??? # chain id
   protocol_version: 1 # consensus protocol version
   validators:
-    - key: validator:public:??? # public key of the main node (copy this PUBLIC key from the secrets you generated)
+    - key: validator:public:??? # validator public key of the main node (copy this PUBLIC key from the secrets you generated)
       weight: 1
   leader: validator:public:??? # same as above - main node will be the only validator and the only leader.
+  seed_peers:
+      - key: 'node:public:ed25519:...' # node public key of the main node (copy this PUBLIC key from the secrets you generated)
+        addr: '???' # same as public_addr above
 ```
 
 And a `consensus_secrets.yaml` file with the with the secrets you generated previously:

docs/src/guides/external-node/10_decentralization.md

@@ -9,14 +9,6 @@ On the gossipnet, the data integrity will be protected by the BFT (byzantine fau
 
 ## Enabling gossipnet on your node
 
-> [!NOTE]
->
-> Because the data transmitted over the gossipnet is signed by the main node (and eventually by the consensus quorum),
-> the signatures need to be backfilled to the node's local storage the first time you switch from centralized (ZKsync
-> API based) synchronization to the decentralized (gossipnet based) synchronization (this is a one-time thing). With the
-> current implementation it may take a couple of hours and gets faster the more nodes you add to the
-> `gossip_static_outbound` list (see below). We are working to remove this inconvenience.
-
 > [!NOTE]
 >
 > The minimal supported server version for this is
@@ -65,9 +57,6 @@ for more details):
   your node from getting DoS`ed by too large network messages. Use the value from the template.
 - `gossip_dynamic_inbound_limit` - maximal number of unauthenticated concurrent inbound connections that can be
   established to your node. This is a DDoS protection measure.
-- `gossip_static_outbound` - list of trusted peers that your node should always try to connect to. The template contains
-  the nodes maintained by Matterlabs, but you can add more if you know any. Note that the list contains both the network
-  address AND the public key of the node - this prevents spoofing attacks.
 
 ### Setting environment variables