Merge pull request #1063 from MinaFoundation/update-docs-to-3-0-2

Update Docs to 3.0.2

docs/berkeley-upgrade/archive-migration/mainnet-database-maintenance.mdx

@@ -143,7 +143,7 @@ where:
 
 :warning: Running a replayer from scratch on a Devnet/Mainnet database can take up to a couple of days. The recommended best practice is to break the replayer into smaller parts by using the checkpoint capabilities of the replayer.
 
-:warning: You must run the replayer using the Mainnet version. You can run it from the Docker image at `minaprotocol/mina-archive:3.0.0-93e0279-bullseye`.
+:warning: You must run the replayer using the Mainnet version. You can run it from the Docker image at `minaprotocol/mina-archive:3.0.2-4aac388-bullseye`.
 
 ## Missing blocks
 
@@ -155,7 +155,7 @@ If you uploaded the missing blocks to Google Cloud, the missing blocks can be re
 
    The `download-missing-blocks` script uses `localhost` as the database host so the script assumes that psql is running on localhost on port 5432. Modify `PG_CONN` in `download_missing_block.sh` for your environment.
 
-1. Install the required `mina-archive-blocks` and `mina-missing-blocks-auditor` scripts that are packed in the `minaprotocol/mina-archive:3.0.0-93e0279-bullseye` Docker image.
+1. Install the required `mina-archive-blocks` and `mina-missing-blocks-auditor` scripts that are packed in the `minaprotocol/mina-archive:3.0.2-4aac388-bullseye` Docker image.
 
 1. Export the `BLOCKS_BUCKET`:
 
@@ -183,7 +183,7 @@ O1labs maintains a Google bucket containing precomputed blocks from Devnet and M
 Note: It's important to highlight that precomputed blocks for **Devnet** between heights `2` and `1582` have missing fields or incorrect transaction data. Utilizing these blocks to patch your Devnet archive database will result in failure. For those who rely on precomputed blocks from this bucket, please follow the outlined steps:
 
 1. Download additional blocks from `gs://mina_network_block_data/devnet-extensional-bundle.tar.gz`.
-2. Install the necessary `mina-archive-blocks` script contained within the `minaprotocol/mina-archive:3.0.0-93e0279-bullseye` Docker image.
+2. Install the necessary `mina-archive-blocks` script contained within the `minaprotocol/mina-archive:3.0.2-4aac388-bullseye` Docker image.
 3. Execute mina-archive-blocks to import the extracted blocks from step 1 using the provided command:
 
       ```sh

docs/berkeley-upgrade/flags-configs.mdx

@@ -12,7 +12,7 @@ keywords:
 
 # Post-Upgrade Flags and Configurations for Mainnet
 
-Please refer to the Berkeley node release notes [here](https://github.com/MinaProtocol/mina/releases/tag/3.0.0).
+Please refer to the Berkeley node release notes [here](https://github.com/MinaProtocol/mina/releases/tag/3.0.2).
 
 ### Network details
 
@@ -21,13 +21,13 @@ Chain ID
 a7351abc7ddf2ea92d1b38cc8e636c271c1dfd2c081c637f62ebc2af34eb7cc1
 
 Git SHA-1
-93e02797f72abe2cbf8dfca6f2328e9c8cd76546
+4aac38814556b9641ffbdfaef19b38ab7980011b
 
 Seed List
 https://storage.googleapis.com/mina-seed-lists/mainnet_seeds.txt
 
 Node build
-https://github.com/MinaProtocol/mina/releases/tag/3.0.0
+https://github.com/MinaProtocol/mina/releases/tag/3.0.2
 ```
 
 ### Block Producer's
@@ -87,8 +87,8 @@ Running an Archive Node involves setting up a non-block-producing node and a Pos
 For more information about running archive nodes, see [Archive Node](/node-operators/archive-node).
 
 The PostgreSQL database requires two schemas:
-1. The PostgreSQL schema used by the Mina archive database: in the [release notes](https://github.com/MinaProtocol/mina/releases/tag/3.0.0)
-2. The PostgreSQL schema extensions to support zkApp commands: in the [release notes](https://github.com/MinaProtocol/mina/releases/tag/3.0.0)
+1. The PostgreSQL schema used by the Mina archive database: in the [release notes](https://github.com/MinaProtocol/mina/releases/tag/3.0.2)
+2. The PostgreSQL schema extensions to support zkApp commands: in the [release notes](https://github.com/MinaProtocol/mina/releases/tag/3.0.2)
 
 The non-block-producing node must be configured with the following flags:
 ```
@@ -127,7 +127,7 @@ docker run
 --name rosetta --rm \
 -p 3088:3088 \
 --entrypoint '' \
-minaprotocol/mina-rosetta:3.0.0-93e0279-bullseye \
+minaprotocol/mina-rosetta:3.0.2-4aac388-bullseye-mainnet \
 /usr/local/bin/mina-rosetta \
 --archive-uri "${PG_CONNECTION_STRING}" \
 --graphql-uri "${GRAPHQL_URL}" \

docs/berkeley-upgrade/requirements.mdx

@@ -30,7 +30,7 @@ Please note the following are the hardware requirements for each node type after
 
 :::caution
 
-If you have `mina-generate-keypair` installed, you will need to first `sudo apt remove mina-generate-keypair` before installing `mina-mainnet=3.0.0-93e0279`.  
+If you have `mina-generate-keypair` installed, you will need to first `sudo apt remove mina-generate-keypair` before installing `mina-mainnet=3.0.2-4aac388`.
 The `mina-generate-keypair` binary is now installed as part of the mina-mainnet package.
 
 :::
@@ -56,8 +56,8 @@ Ensure your nodes are set to restart automatically after a crash. For guidance,
 
 ### Generation of libp2p keypair
 
-To ensure connectivity across the network, it is essential that all seed nodes start with the **same** `libp2p` keypair.  
-This consistency allows other nodes in the network to reliably connect.  
+To ensure connectivity across the network, it is essential that all seed nodes start with the **same** `libp2p` keypair.
+This consistency allows other nodes in the network to reliably connect.
 Although the same libp2p keys can be reused from before the upgrade, if you need to manually generate new libp2p keys, use the following command:
 
 ```

docs/berkeley-upgrade/upgrade-steps.mdx

@@ -25,15 +25,15 @@ Below it's the description in detail of all the upgrade steps and what which nod
   - Review the [upgrade readiness checklist](https://docs.google.com/document/d/1rTmJvyaK33dWjJXMOSiUIGgf8z7turxolGHUpVHNxEU/edit#heading=h.2hqz0ixwjk3f) to confirm they have covered the required steps.
   - Upgrade their nodes to the 1.4.1 stable version
   - Ensure servers are provisioned to run Berkeley nodes, meeting the new hardware requirements
-  - Upgrade their nodes to the node version [3.0.0](https://github.com/MinaProtocol/mina/releases/tag/3.0.0), with stop-slots, when this version becomes available
+  - Upgrade their nodes to the node version [3.0.2](https://github.com/MinaProtocol/mina/releases/tag/3.0.2), with stop-slots, when this version becomes available
   - Start the archive node initial migration if they run archive nodes and wish to perform the migration in a decentralized manner
 
-**Please note:** a simplified Node Status service will be part of the upgrade tooling and enabled by default in Pre-Upgrade release with the stop-slots ([3.0.0](https://github.com/MinaProtocol/mina/releases/tag/3.0.0)). This feature will allow for a safe upgrade by monitoring the amount of upgraded active stake. Only non-sensitive data will be reported. If operators are not comfortable sharing their node version, they will have the option to disable the node version reports by using the appropriate node flag `--node-stats-type none`
+**Please note:** a simplified Node Status service will be part of the upgrade tooling and enabled by default in Pre-Upgrade release with the stop-slots ([3.0.2](https://github.com/MinaProtocol/mina/releases/tag/3.0.2)). This feature will allow for a safe upgrade by monitoring the amount of upgraded active stake. Only non-sensitive data will be reported. If operators are not comfortable sharing their node version, they will have the option to disable the node version reports by using the appropriate node flag `--node-stats-type none`
 
 ### Block Producers and SNARK Workers
 1. Review the [upgrade readiness checklist](https://docs.google.com/document/d/1rTmJvyaK33dWjJXMOSiUIGgf8z7turxolGHUpVHNxEU).
 1. Provision servers that meet the minimum hardware requirements, including the new 32GB RAM requirement and support for _AVX_ and _BMI2_ CPU instructions.
-1. Upgrade nodes to node version [3.0.0](https://github.com/MinaProtocol/mina/releases/tag/3.0.0) ([3.0.0](https://github.com/MinaProtocol/mina/releases/tag/3.0.0) has built-in stop slots).
+1. Upgrade nodes to node version [3.0.2](https://github.com/MinaProtocol/mina/releases/tag/3.0.2) ([3.0.2](https://github.com/MinaProtocol/mina/releases/tag/3.0.2) has built-in stop slots).
 
 ### Archive Node Operators and Rosetta Operators
 - Two migration processes will be available to archive node operators: _trustless_ and _trustful_. If the archive node operator wants to perform the _trustless_ migration, they should follow these steps; otherwise, proceed to the Upgrade phase. The _trustful_ migration will rely on o1Labs database exports and Docker images to migrate the archive node database and doesn’t require any actions at this stage.
@@ -42,15 +42,15 @@ Below it's the description in detail of all the upgrade steps and what which nod
   - Perform the initial archive node migration. Since Mainnet is a long-lived network, the initial migration process can take up to 48 hours, depending on your server specification and infrastructure.
   - If your Mina Daemon, archive node, or PostgreSQL database runs on different machines, the migration performance will be greatly impacted.
   - For more information on the archive node migration process, please refer to the [Archive Migration](/berkeley-upgrade/archive-migration) section.
-2. Upgrade all nodes to the latest stable version [3.0.0](https://github.com/MinaProtocol/mina/releases/tag/3.0.0).
+2. Upgrade all nodes to the latest stable version [3.0.2](https://github.com/MinaProtocol/mina/releases/tag/3.0.2).
 3. Provision servers that meet the minimum hardware requirements, primarily the new 32GB RAM requirement.
 4. Upgrade their nodes to the version that includes built-in stop slots before the pre-defined _stop-transaction-slot_.
 
 ### Exchanges
 1. Make sure to test your system integration with Berkeley's new features. Pay special attention to:
   - If you use the **o1labs/client-sdk** library to sign transactions, you should switch to **[mina-signer](https://www.npmjs.com/package/mina-signer)**. o1labs/client-sdk was **deprecated** some time ago and will be **unusable** once the network has been upgraded. Please review the migration instructions in [Appendix](/berkeley-upgrade/appendix).
   - If you rely on the archive node SQL database tables, please review the schema changes in Appendix 1 of this document.
-2. Upgrade all nodes to the latest stable version [3.0.0](https://github.com/MinaProtocol/mina/releases/tag/3.0.0).
+2. Upgrade all nodes to the latest stable version [3.0.2](https://github.com/MinaProtocol/mina/releases/tag/3.0.2).
 3. Provision servers that meet the minimum hardware requirements, particularly the new 32GB RAM requirement.
 4. Upgrade your nodes to the version that includes built-in stop slots before the pre-defined _stop-transaction-slot_.
 

docs/exchange-operators/rosetta/docker-compose.mdx

@@ -35,7 +35,7 @@ services:
     ports:
       - '5432:5432'
   bootstrap_db:
-    image: 'minaprotocol/mina-archive:3.0.0-93e0279-bullseye'
+    image: 'minaprotocol/mina-archive:3.0.2-4aac388-bullseye'
     command: >
       bash -c '
       curl -O https://673156464838-mina-archive-node-backups.s3.us-west-2.amazonaws.com/mainnet/mainnet-archive-dump-$(date +%F_0000).sql.tar.gz;
@@ -52,7 +52,7 @@ services:
       postgres:
         condition: service_healthy
   missing_blocks_guardian:
-    image: 'minaprotocol/mina-archive:3.0.0-93e0279-bullseye'
+    image: 'minaprotocol/mina-archive:3.0.2-4aac388-bullseye'
     command: >
       bash -c '
       curl -O https://raw.githubusercontent.com/MinaFoundation/helm-charts/main/mina-archive/scripts/missing-blocks-guardian-command.sh;
@@ -65,7 +65,7 @@ services:
       bootstrap_db:
         condition: service_completed_successfully
   mina_archive:
-    image: 'minaprotocol/mina-archive:3.0.0-93e0279-bullseye'
+    image: 'minaprotocol/mina-archive:3.0.2-4aac388-bullseye'
     restart: always
     command:
       - mina-archive
@@ -80,7 +80,7 @@ services:
       bootstrap_db:
         condition: service_completed_successfully
   mina_node:
-    image: 'minaprotocol/mina-daemon:3.0.0-93e0279-bullseye-mainnet'
+    image: 'minaprotocol/mina-daemon:3.0.2-4aac388-bullseye-mainnet'
     restart: always
     environment:
       MINA_LIBP2P_PASS: PssW0rD
@@ -99,7 +99,7 @@ services:
       bootstrap_db:
         condition: service_completed_successfully
   mina_rosetta:
-    image: 'minaprotocol/mina-rosetta:3.0.0-93e0279-bullseye'
+    image: 'minaprotocol/mina-rosetta:3.0.2-4aac388-bullseye-mainnet'
     restart: always
     environment:
       MINA_ROSETTA_MAX_DB_POOL_SIZE: 80

docs/exchange-operators/rosetta/run-with-docker.mdx

@@ -47,7 +47,7 @@ Run the container with following command (replace the image tag with one from do
     docker run -it --rm --name rosetta \
         --entrypoint=./docker-start.sh \
         -p 10101:10101 -p 3085:3085 -p 3086:3086 -p 3087:3087 \
-        minaprotocol/mina-rosetta:3.0.0-93e0279-focal
+        minaprotocol/mina-rosetta:3.0.2-4aac388-bullseye-mainnet
 ```
 
 You can also create a file with the environment variables and pass it to the docker run command with `--env-file` flag. For example, create a file named `mainnet.env` with the following content:

docs/mina-protocol/sending-a-payment.mdx

@@ -167,19 +167,19 @@ Once you feel comfortable with the basics of creating an address, and sending &
 
 Sometimes you may wish to send many transactions: for example, to payout rewards to those delegating to you if you're running a staking pool.
 
-All information here is relevant as of the 3.0.0 build:
+All information here is relevant as of the 3.0.2 build:
 
 ### Rate limiting
 
-Currently, nodes on the network will rate limit receiving messages from a given node. As of the 3.0.0 build, your node will also follow this rate limit when sending transactions. Specifically, the limit is currently set at 10 transactions every 15 seconds computed over a 5 minute window. If you attempt to send transactions faster than this rate, your node will queue them up and flush them as older transactions expire from the window upon which the rate limit is computed. You do not need to throttle sending these transactions yourself.
+Currently, nodes on the network will rate limit receiving messages from a given node. As of the 3.0.2 build, your node will also follow this rate limit when sending transactions. Specifically, the limit is currently set at 10 transactions every 15 seconds computed over a 5 minute window. If you attempt to send transactions faster than this rate, your node will queue them up and flush them as older transactions expire from the window upon which the rate limit is computed. You do not need to throttle sending these transactions yourself.
 
 Note that older releases of the mina daemon do not perform this rate limiting; if you are running an older version, you should manually limit the number of transactions. Due to overheads from rebroadcasting transactions, we do not recommend sending more than 50 transactions every 5 minutes if you need to manually rate limit.
 
 ### My node crashed or disconnected before I could finish sending transactions
 
-The Mina daemon does _not_ currently persist the transaction pool. This means that the transactions that your node will be unaware of any transactions that you've sent so far if your node crashes in the middle of this process. As of the 3.0.0 build, you can resend all transactions (exactly in the same manner as before) and they will be rebroadcasted on the network.
+The Mina daemon does _not_ currently persist the transaction pool. This means that the transactions that your node will be unaware of any transactions that you've sent so far if your node crashes in the middle of this process. As of the 3.0.2 build, you can resend all transactions (exactly in the same manner as before) and they will be rebroadcasted on the network.
 
-If you believe you were temporarily disconnected from the network, but your node stayed online (i.e. the gossip network may have missed one or more of your transactions), as of the 3.0.0 build, you can resend any of the transactions locally and they will be broadcasted again to the network even if your node thinks they've already been shared.
+If you believe you were temporarily disconnected from the network, but your node stayed online (i.e. the gossip network may have missed one or more of your transactions), as of the 3.0.2 build, you can resend any of the transactions locally and they will be broadcasted again to the network even if your node thinks they've already been shared.
 
 ### Cancelling a transaction and setting a new fee
 

docs/node-developers/sandbox-node.mdx

@@ -26,7 +26,7 @@ docker run \
   --name mina \
   -e RUN_DEMO=true \
   -e MINA_PRIVKEY_PASS='' \
-  minaprotocol/mina-daemon:3.0.0-93e0279-bullseye-mainnet
+  minaprotocol/mina-daemon:3.0.2-4aac388-bullseye-mainnet
 
 ```
 

docs/node-operators/archive-node/docker-compose.mdx

@@ -32,8 +32,8 @@ services:
     ports:
       - '5432:5432'
   bootstrap_db:
-    image: 'minaprotocol/mina-archive:3.0.0-93e0279-bullseye'
-    # image: 'gcr.io/o1labs-192920/mina-archive:3.0.0-dc6bf78-bullseye' # Use this image for Devnet
+    image: 'minaprotocol/mina-archive:3.0.2-4aac388-bullseye'
+    # image: 'gcr.io/o1labs-192920/mina-archive:3.0.1-alpha1-0473756-bullseye' # Use this image for Devnet
     command: >
       bash -c '
       curl -O https://673156464838-mina-archive-node-backups.s3.us-west-2.amazonaws.com/mainnet/mainnet-archive-dump-$(date +%F_0000).sql.tar.gz;
@@ -51,8 +51,8 @@ services:
       postgres:
         condition: service_healthy
   missing_blocks_guardian:
-    image: 'minaprotocol/mina-archive:3.0.0-93e0279-bullseye'
-    # image: 'gcr.io/o1labs-192920/mina-archive:3.0.0-dc6bf78-bullseye' # Use this image for Devnet
+    image: 'minaprotocol/mina-archive:3.0.2-4aac388-bullseye'
+    # image: 'gcr.io/o1labs-192920/mina-archive:3.0.1-alpha1-0473756-bullseye' # Use this image for Devnet
     command: >
       bash -c '
       curl -O https://raw.githubusercontent.com/MinaFoundation/helm-charts/main/mina-archive/scripts/missing-blocks-guardian-command.sh;
@@ -66,7 +66,7 @@ services:
       bootstrap_db:
         condition: service_completed_successfully
   mina_archive:
-    image: 'minaprotocol/mina-archive:3.0.0-93e0279-bullseye'
+    image: 'minaprotocol/mina-archive:3.0.2-4aac388-bullseye'
     restart: always
     command:
       - mina-archive
@@ -81,8 +81,8 @@ services:
       bootstrap_db:
         condition: service_completed_successfully
   mina_node:
-    image: 'minaprotocol/mina-daemon:3.0.0-93e0279-bullseye-mainnet'
-    # image: 'gcr.io/o1labs-192920/mina-daemon:3.0.0-dc6bf78-bullseye-devnet' # Use this image for Devnet
+    image: 'minaprotocol/mina-daemon:3.0.2-4aac388-bullseye-mainnet'
+    # image: 'gcr.io/o1labs-192920/mina-daemon:3.0.1-alpha1-0473756-bullseye-devnet' # Use this image for Devnet
     restart: always
     entrypoint: []
     command: >