appendix fix and renaming berkeley -> mesa

Author: dkijania

docs/mesa-upgrade/appendix.mdx

@@ -17,6 +17,8 @@ Below we present details of what changed in the archive node database schema bet
 
 ### Extended zkApp State Fields
 
+Both zkApp state tables have been modified to support additional state elements:
+
 **zkapp_states_nullable table**
    - Added columns `element8` through `element31` (nullable integer fields)
    - Each new column references `zkapp_field(id)`
@@ -39,31 +41,24 @@ ALTER TABLE zkapp_states ADD COLUMN IF NOT EXISTS element8 INT DEFAULT <zero_fie
 ALTER TABLE zkapp_states ADD COLUMN IF NOT EXISTS element31 INT DEFAULT <zero_field_id> NOT NULL REFERENCES zkapp_field(id);
 ```
 
-### Migration History Tracking
+This expansion allows zkApps to store up to 31 state elements instead of the previous 8, significantly increasing the state storage capacity for complex smart contracts.
 
-The upgrade introduces a new `migration_history` table to track database schema migrations. This helps manage future upgrades and prevents applying the same migration multiple times.
+### Version Tracking
 
-**migration_status enum type**
-```sql
-CREATE TYPE migration_status AS ENUM ('starting', 'applied', 'failed');
-```
+The upgrade introduces a new `version` table to keep track of the database schema version. The purpose of this table is to help with future database migrations. The table tracks which migration scripts were applied and when.
 
-**migration_history table**
+**version table**
 ```sql
-CREATE TABLE IF NOT EXISTS migration_history (
-    commit_start_at   TIMESTAMPTZ NOT NULL DEFAULT NOW() PRIMARY KEY,
-    protocol_version  TEXT NOT NULL,
-    migration_version TEXT NOT NULL,
-    description       TEXT NOT NULL,
-    status            migration_status NOT NULL
+CREATE TABLE IF NOT EXISTS version (
+    version_num INT PRIMARY KEY,
+    applied_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
 );
 ```
 
-The table tracks:
-- **commit_start_at**: Timestamp when the migration started
-- **protocol_version**: Target protocol version (e.g., '4.0.0' for Mesa)
-- **migration_version**: Version of the migration script itself (e.g., '0.0.5')
-- **description**: Human-readable description of the migration
-- **status**: Current state of the migration (starting, applied, or failed)
+The version table provides:
+- **Migration tracking**: Records which migrations have been applied
+- **Timestamp tracking**: Shows when each migration was executed
+- **Idempotency**: Prevents duplicate migration runs
+- **Version identification**: Easily identify the current database schema version
 
-The migration script uses protocol version '3.0.0' for Berkeley and '4.0.0' for Mesa, with built-in safety checks to prevent reapplying migrations or running them on incorrect database versions.
+The table is created if it does not exist already. Rollback and upgrade scripts will insert a new row with the version number and timestamp when the script was applied.

docs/mesa-upgrade/flags-configs.mdx

@@ -4,15 +4,15 @@ sidebar_label: Post-Upgrade Flags and Configurations
 hide_title: true
 description: Post-Upgrade Flags and Configurations for Mainnet
 keywords:
-  - Berkeley
+  - Mesa
   - upgrade
   - flags
   - configurations
 ---
 
 # 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.3).
+Please refer to the Mesa node release notes [here](https://github.com/MinaProtocol/mina/releases/tag/4.0.0).
 
 ### Network details
 
@@ -27,7 +27,7 @@ Seed List
 https://bootnodes.minaprotocol.com/networks/mainnet.txt
 
 Node build
-https://github.com/MinaProtocol/mina/releases/tag/3.0.3
+https://github.com/MinaProtocol/mina/releases/tag/4.0.0
 ```
 
 ### 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.3)
-2. The PostgreSQL schema extensions to support zkApp commands: in the [release notes](https://github.com/MinaProtocol/mina/releases/tag/3.0.3)
+1. The PostgreSQL schema used by the Mina archive database: in the [release notes](https://github.com/MinaProtocol/mina/releases/tag/4.0.0)
+2. The PostgreSQL schema extensions to support zkApp commands: in the [release notes](https://github.com/MinaProtocol/mina/releases/tag/4.0.0)
 
 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.1.0-ae112d3-bullseye-mainnet \
+minaprotocol/mina-rosetta:4.0.0-bullseye-mainnet \
 /usr/local/bin/mina-rosetta \
 --archive-uri "${PG_CONNECTION_STRING}" \
 --graphql-uri "${GRAPHQL_URL}" \

docs/mesa-upgrade/requirements.mdx

@@ -2,9 +2,9 @@
 title: Requirements
 sidebar_label: Requirements
 hide_title: true
-description: Berkeley upgrade is a major upgrade that requires all nodes in a network to upgrade to a newer version. It is not backward compatible.
+description: Mesa upgrade is a major upgrade that requires all nodes in a network to upgrade to a newer version. It is not backward compatible.
 keywords:
-  - Berkeley
+  - Mesa
   - upgrade
   - hardware requirements
 ---
@@ -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.1.0-ae112d3`.
+If you have `mina-generate-keypair` installed, you will need to first `sudo apt remove mina-generate-keypair` before installing `mina-mainnet=4.0.0`.
 The `mina-generate-keypair` binary is now installed as part of the mina-mainnet package.
 
 :::

docs/mesa-upgrade/upgrade-steps.mdx

@@ -25,31 +25,31 @@ 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 3.2.0 stable version
   - Ensure servers are provisioned to run Mesa nodes, meeting the new hardware requirements
-  - Upgrade their nodes to the node version [3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3), with stop-slots, when this version becomes available
+  - Upgrade their nodes to the node version [4.0.0](https://github.com/MinaProtocol/mina/releases/tag/4.0.0), with stop-slots, when this version becomes available
   - Run upgrade script for the archive node if they run archive nodes and wish to upgrade 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.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3)). 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 ([4.0.0](https://github.com/MinaProtocol/mina/releases/tag/4.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`
 
 ### 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.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3) ([3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3) has built-in stop slots).
+1. Provision servers that meet the minimum hardware requirements, including 32GB RAM and support for _AVX_ and _BMI2_ CPU instructions.
+1. Upgrade nodes to node version [4.0.0](https://github.com/MinaProtocol/mina/releases/tag/4.0.0) ([4.0.0](https://github.com/MinaProtocol/mina/releases/tag/4.0.0) has built-in stop slots).
 
 ### Archive Node Operators and Rosetta Operators
 - Two upgrade 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.
 
 1. Trustless migration:
   - Perform the archive node upgrade. Since Mainnet is a long-lived network, the upgrade process is a very fast operation and boils down to running the upgrade script against your archive. It should not take more than 1 minute, depending on your server specification and infrastructure.
   - For more information on the archive node upgrade process, please refer to the [Archive Upgrade](/mesa-upgrade/archive-upgrade) section.
-2. Upgrade all nodes to the latest stable version [3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3).
-3. Provision servers that meet the minimum hardware requirements, primarily the new 32GB RAM requirement.
+2. Upgrade all nodes to the latest stable version [4.0.0](https://github.com/MinaProtocol/mina/releases/tag/4.0.0).
+3. Provision servers that meet the minimum hardware requirements, primarily 32GB RAM.
 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 Mesa's new features. Pay special attention to:
   - 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.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3).
-3. Provision servers that meet the minimum hardware requirements, particularly the new 32GB RAM requirement.
+2. Upgrade all nodes to the latest stable version [4.0.0](https://github.com/MinaProtocol/mina/releases/tag/4.0.0).
+3. Provision servers that meet the minimum hardware requirements, particularly 32GB RAM.
 4. Upgrade your nodes to the version that includes built-in stop slots before the pre-defined _stop-transaction-slot_.
 
 ***
@@ -83,7 +83,7 @@ Remember that although you might be able to submit transactions, the majority of
 ## Upgrade
 
 - Starting at the _stop-network-slot_ the network will not produce nor accept new blocks, resulting in halting the network. During the upgrade period, o1Labs will use automated tooling to export the network state based on the block at the slot just before the _stop-transaction-slot_. The exported state will then be baked into the new Mesa build, which will be used to initiate the upgraded network. It is during the upgrade windows that the Mesa network infrastructure will be bootstrapped, and seed nodes will become available. o1Labs will also finalize the archive node migration and publish the PostgreSQL database dumps for import by the archive node operators who wish to bootstrap their archives in a trustful manner.
-- There is a tool available to validate that the Mesa node was built from the pre-upgrade network state. To validate, follow the instructions provided in this [location](https://github.com/MinaProtocol/mina/blob/berkeley/docs/upgrading-to-berkeley.md)
+- There is a tool available to validate that the Mesa node was built from the pre-upgrade network state. To validate, follow the instructions provided in this [location](https://github.com/MinaProtocol/mina/blob/mesa/docs/upgrading-to-mesa.md)
 
 ### Block Producers and SNARK Workers
 1. During the upgrade phase (between _stop-network-slot_ and the publishing of the Mesa release), block producers can shut down their nodes.
@@ -109,7 +109,7 @@ There will be both Docker images and archive node releases available to choose f
 ## Post-Upgrade
 - At approximately 1 hour after the publishing of the Mesa node release, at a predefined slot (Mesa genesis timestamp), block production will start, and the network is successfully upgraded.
 - Node operators can monitor their nodes and provide feedback to the technical team in case of any issues. Builders can start deploying zkApps.
-- **Please note:** The Node Status service will not be enabled by default in the Mesa release. If you wish to provide Node Status and Error metrics and reports to Mina Foundation, helping monitor the network in the initial phase, please use the following flags when running your nodes:
+- **Please note:** The Node Status service will not be enabled by default in the Mesa release. If you wish to provide Node Status and Error metrics and reports to o1Labs, helping monitor the network in the initial phase, please use the following flags when running your nodes:
   - `--node-stats-type [full|simple]`
   - `--node-status-url https://nodestats.minaprotocol.com/submit/stats`
   - `--node-error-url https://nodestats.minaprotocol.com/submit/stats`