Open
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
dkijania
force-pushed
the
dkijania/upgrade-to-mesa
branch
from
ccabdf6 to
b2ae3c9
Compare
glyh
reviewed
Nov 30, 2025
docs/mesa-upgrade/appendix.mdx
Outdated
|
|
||
| Below we presents details what was changed in the archive node database schema between Berkeley and Mesa version. | ||
|
|
||
| **Zkapp_state_nullable additional Columns ** |
Member
There was a problem hiding this comment.
This is not complete. we also updated the non-nullable table.
glyh
reviewed
Nov 30, 2025
docs/mesa-upgrade/appendix.mdx
Outdated
|
|
||
| ``` | ||
|
|
||
| **Version table** |
Member
There was a problem hiding this comment.
This is wrong. if you look at current codebase.
cjjdespres
reviewed
Dec 3, 2025
docs/mesa-upgrade/upgrade-steps.mdx
Outdated
| - Operators shall import the SQL dump file provided by o1Labs to a freshly created database. | ||
| - Operators should direct their Mesa archive process to the newly created database. | ||
|
|
||
| **Please note:** both the _trustless_ and _trustful_ migration processes will discard all Mainnet blocks that are not canonical. If you wish to preserve the entire block history, i.e. including non-canonical blocks, you should maintain the Mainnet archive node database for posterior querying needs. |
dkijania
force-pushed
the
dkijania/upgrade-to-mesa
branch
from
b2ae3c9 to
afa6095
Compare
- remove information removal of non-canonical blocks - update description for schema changes
dkijania
force-pushed
the
dkijania/upgrade-to-mesa
branch
from
afa6095 to
e19daf8
Compare
yamimaio
reviewed
Dec 11, 2025
docs/mesa-upgrade/flags-configs.mdx
Outdated
| hide_title: true | ||
| description: Post-Upgrade Flags and Configurations for Mainnet | ||
| keywords: | ||
| - Berkeley |
Collaborator
There was a problem hiding this comment.
should this be Berkeley or Mesa?
docs/mesa-upgrade/flags-configs.mdx
Outdated
|
|
||
| # 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). |
Collaborator
There was a problem hiding this comment.
Should this be Berkeley?
docs/mesa-upgrade/requirements.mdx
Outdated
| 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. |
docs/mesa-upgrade/requirements.mdx
Outdated
| 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. | ||
| keywords: | ||
| - Berkeley |
docs/mesa-upgrade/requirements.mdx
Outdated
|
|
||
| :::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`. |
Collaborator
There was a problem hiding this comment.
is this the right version?
docs/mesa-upgrade/upgrade-steps.mdx
Outdated
| 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). |
Collaborator
There was a problem hiding this comment.
version will need to change
docs/mesa-upgrade/upgrade-steps.mdx
Outdated
| - 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. |
Collaborator
There was a problem hiding this comment.
Ram requirement is not new
docs/mesa-upgrade/upgrade-steps.mdx
Outdated
| ### 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). |
docs/mesa-upgrade/upgrade-steps.mdx
Outdated
| ## 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) |
docs/mesa-upgrade/upgrade-steps.mdx
Outdated
| ## 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: |
Collaborator
There was a problem hiding this comment.
errors should be reported to us, not to MF
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.