added initial draft for upgrade to mesa#1133
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
|
|
||
| Below we presents details what was changed in the archive node database schema between Berkeley and Mesa version. | ||
|
|
||
| **Zkapp_state_nullable additional Columns ** |
There was a problem hiding this comment.
This is not complete. we also updated the non-nullable table.
|
|
||
| ``` | ||
|
|
||
| **Version table** |
There was a problem hiding this comment.
This is wrong. if you look at current codebase.
| - 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
dkijania
force-pushed
the
dkijania/upgrade-to-mesa
branch
from
afa6095 to
e19daf8
Compare
| hide_title: true | ||
| description: Post-Upgrade Flags and Configurations for Mainnet | ||
| keywords: | ||
| - Berkeley |
There was a problem hiding this comment.
should this be Berkeley or Mesa?
|
|
||
| # 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). |
There was a problem hiding this comment.
Should this be Berkeley?
| 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. |
| 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 |
|
|
||
| :::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`. |
There was a problem hiding this comment.
is this the right version?
| 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). |
There was a problem hiding this comment.
version will need to change
| - 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. |
There was a problem hiding this comment.
Ram requirement is not new
| ### 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). |
| ## 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) |
| ## 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: |
There was a problem hiding this comment.
errors should be reported to us, not to MF
dkijania
force-pushed
the
dkijania/upgrade-to-mesa
branch
from
087520f to
9df874d
Compare
dkijania
force-pushed
the
dkijania/upgrade-to-mesa
branch
from
2dd75c4 to
3fac3ae
Compare
|
|
||
| docker run --name mina -d \ | ||
| -v mina-config:/root/.mina-config \ | ||
| minaprotocol/mina-daemon:4.0.0-bullseye-mainnet \ |
There was a problem hiding this comment.
Why is the pre-fork image 4.0.0? Shouldn't it be tagged 3.x.x, pointing to the RC?
There was a problem hiding this comment.
oh right, stop slot release would still have 3.xx
|
|
||
| ### Archive Node Operator | ||
|
|
||
| Archive nodes do **not** support automode — they always require manual steps. You also need to handle the database migration. |
There was a problem hiding this comment.
I thought what we said is just upgrade the schema prefork and run post-fork archive and everything should work as expected, does that changed?
There was a problem hiding this comment.
I will reword it, yes. Let's avoid using migration term, it's just simple upgrade
| ```bash | ||
| # Pre-Upgrade: install both automode packages | ||
| sudo apt-get update | ||
| sudo apt-get install mina-mainnet-prefork-mesa=4.0.0 mina-mainnet-postfork-mesa=4.0.0 |
There was a problem hiding this comment.
Same comment as Corvo's, I think pre-fork shoudl be 3.X.X
|
|
||
| <ul className="checklist"> | ||
| <li>Chosen an <a href="/network-upgrades/mesa/upgrade-modes">upgrade mode</a>: automode (recommended) or manual</li> | ||
| <li>Upgraded node to the current stable version (3.3.0)</li> |
There was a problem hiding this comment.
This probably won't be it. I think it's already not it, right?
|
|
||
| <ul className="checklist"> | ||
| <li>Chosen an <a href="/network-upgrades/mesa/upgrade-modes">upgrade mode</a>: automode (recommended) or manual</li> | ||
| <li>Upgraded node to the current stable version (3.3.0)</li> |
| #### Software Upgrade | ||
|
|
||
| <ul className="checklist"> | ||
| <li>Upgraded node to the current stable version (3.3.0)</li> |
| #### Software Upgrade | ||
|
|
||
| <ul className="checklist"> | ||
| <li>Upgraded node to the current stable version (3.3.0)</li> |
| <details> | ||
| <summary><b>Example: zkApp Developer</b></summary> | ||
|
|
||
| **Frank** maintains a zkApp deployed on mainnet. His contract uses on-chain state and he wants to take advantage of Mesa's expanded 31-field state. |
| He verifies that: | ||
| - His existing zkApp (compiled for Berkeley) still works unchanged on the preflight Mesa network | ||
| - Transactions deploy and execute correctly | ||
| - If he plans to use the expanded state fields (9–31), his new contract version compiles and deploys on preflight |
|
|
||
| **Hours before the fork (State Finalization)** — Frank does **nothing**. His deployed zkApp keeps running on the Berkeley chain. No transactions can be submitted during this phase anyway. | ||
|
|
||
| **Fork day (Upgrade)** — Frank does **nothing**. His existing zkApp state carries over to the Mesa chain automatically. All account state (including zkApp state fields 1–8) is preserved exactly as-is. |
| zkapp deploy --network mainnet | ||
| ``` | ||
|
|
||
| If his zkApp does not need the new state fields, no redeployment is needed — it continues to work on Mesa without changes. |
There was a problem hiding this comment.
is this true? don't all apps need to be redeployed?
| ```bash | ||
| sudo systemctl stop mina | ||
| sudo apt-get update | ||
| sudo apt-get install mina-mainnet-mesa=<mesa-version> |
There was a problem hiding this comment.
Don't we know what this is at this point?
I've seen in a few places
| sudo systemctl stop mina | ||
|
|
||
| sudo apt-get update | ||
| sudo apt-get install mina-mainnet-mesa=<mesa-version> |
There was a problem hiding this comment.
The tagging scheme is a bit confusing to me. Why is it necessary to have a -mesa in the package name? Isn't 4.x.x enough to indicate this is a mesa package?
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
|
|
||
| ```bash | ||
| sudo apt-get update | ||
| sudo apt-get install mina-mainnet-prefork-mesa=4.0.0 mina-mainnet-postfork-mesa=4.0.0 |
There was a problem hiding this comment.
Pre-fork package version incorrectly set to 4.0.0 instead of 3.3.0 (Berkeley version)
|
|
||
| ### Expanded zkApp State | ||
|
|
||
| Mesa extends the on-chain state available to zkApps from 8 fields to 31 fields per account. This significantly increases the data capacity available to smart contracts, enabling more complex application logic without off-chain workarounds. |
There was a problem hiding this comment.
Field count documentation incorrectly states 31 fields total when Mesa actually extends to 32 fields (element0 through element31)
| ```bash | ||
| # Pre-Upgrade: install both automode packages | ||
| sudo apt-get update | ||
| sudo apt-get install mina-mainnet-prefork-mesa=4.0.0 mina-mainnet-postfork-mesa=4.0.0 |
There was a problem hiding this comment.
Pre-fork Mesa package incorrectly specified as 4.0.0 instead of 3.3.0 (pre-fork stable version)
| sudo systemctl stop mina | ||
|
|
||
| sudo apt-get update | ||
| sudo apt-get install mina-mainnet-mesa=<mesa-version> |
There was a problem hiding this comment.
| sudo apt-get install mina-mainnet-mesa=<mesa-version> | |
| sudo apt-get install mina-mainnet-mesa=4.0.0 |
Debian example uses placeholder <mesa-version> while Docker example uses concrete version 4.0.0-bullseye-mesa, causing inconsistency in documentation examples
| |--|--|--|--|--| | ||
| | Mina Daemon Node | 32 GB RAM | 8 core processor with BMI2 and AVX CPU instruction set are required | 64 GB | 1 Mbps Internet Connection | | ||
| | SNARK Coordinator | 32 GB RAM | 8 core processor | 64 GB | 1 Mbps Internet Connection | | ||
| | SNARK Worker | 32 GB RAM | 4 core/8 threads per worker with BMI2 and AVX CPU instruction set are required | 64 GB | 1 Mbps Internet Connection | |
There was a problem hiding this comment.
32GB ram and 64GB storage per worker seems a bit high.
There was a problem hiding this comment.
Mesa SNARK Worker should be 6 core / 12 thread
| | SNARK Worker | 32 GB RAM | 4 core/8 threads per worker with BMI2 and AVX CPU instruction set are required | 64 GB | 1 Mbps Internet Connection | | ||
| | Archive Node | 32 GB RAM | 8 core processor | 64 GB | 1 Mbps Internet Connection | | ||
| | Rosetta API standalone Docker image | 32 GB RAM | 8 core processor | 64 GB | 1 Mbps Internet Connection | | ||
| | Mina Seed Node | 64 GB RAM | 8 core processor | 64 GB | 1 Mbps Internet Connection | |
There was a problem hiding this comment.
To add to Chrstian's comment, it doesn't make sense to me for any node other than archive to have a 64GB storage requirement -- There's nothing growing linearly, and should not be, right?
I guess, logs could grow, but still 64GB seems too big.
|
|
||
| :::caution | ||
|
|
||
| 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`. |
There was a problem hiding this comment.
Why installing new package couldn't auto remove the old?
There was a problem hiding this comment.
yes i think we can remove this line. That was copy paste from past where we move generate-keypair to daemon docker
|
|
||
| During the Pre-Upgrade phase, node operators prepare their infrastructure for the Mesa hard fork. Select your role below and work through each item on the checklist. | ||
|
|
||
| ## Readiness Checklist |
There was a problem hiding this comment.
Could we point most of this list to other parts of the doc, in case people need more information?
dkijania
force-pushed
the
dkijania/upgrade-to-mesa
branch
from
8a09b07 to
79f6863
Compare
| | **zkApp Developers** | No action required. Monitor announcements. | | ||
|
|
||
| :::danger For exchanges | ||
| Transactions submitted after the stop-transaction-slot **will not carry over** to the Mesa chain. Freeze all MINA activity before this point. |
There was a problem hiding this comment.
Suggest adding a place holder page where we'll publish the specific numbers of fork time and slot-txn-end, slot-chain-end, etc. Exchanges should be able to be pointed to that page by clicking the "stop-transaction-slot" word here via a link, for example.
| |---|---| | ||
| | **Block Producers (automode)** | **Nothing.** Your node transitions to Mesa automatically. It will start producing blocks when the Mesa genesis timestamp arrives. | | ||
| | **Block Producers (manual)** | Stop your node. Wait for the Mesa release announcement. Install the new package. Restart with [updated flags](/network-upgrades/mesa/upgrade-steps/post-upgrade). | | ||
| | **SNARK Workers** | Follow the same mode as your coordinator (automode = automatic, manual = reinstall and restart). | |
There was a problem hiding this comment.
| Select your role to see a simplified view of what you need to do and when. | ||
|
|
||
| <details> | ||
| <summary><b>Block Producers & SNARK Workers (automode)</b></summary> |
There was a problem hiding this comment.
again, we're mixing the concept of snark coordinator and snark workers. It's a bad thing that's being done in this doc before and somehow we're using AI to regenerate these hallucinations
|
|
||
| --- | ||
|
|
||
| ### Timeline by Role |
There was a problem hiding this comment.
Not a fan of these pictures either.
|
|
||
| For in-depth technical details on the dispatcher and dual-binary architecture, see [Upgrade Modes - Details](/network-upgrades/mesa/upgrade-modes-details). | ||
|
|
||
| :::caution Automode requires a process restart and persistent filesystem |
There was a problem hiding this comment.
Why is this here instead of on upgrade-modes page?
There was a problem hiding this comment.
+1
This should be in upgrade-modes page
| - **Kubernetes / Helm**: Ensure your pod has `restartPolicy: Always` (the k8s default). If you use a custom `livenessProbe` or a Helm chart with its own restart logic, verify it does not treat exit code 0 as a failure that triggers a full volume wipe or pod replacement. | ||
| ::: | ||
|
|
||
| :::info Dispatcher limitation (current implementation) |
| | **Rosetta API Operators** | [Archive Upgrade](/network-upgrades/mesa/archive-upgrade), [Upgrade Steps](/network-upgrades/mesa/upgrade-steps), [Post-Upgrade Flags](/network-upgrades/mesa/upgrade-steps/post-upgrade), [Post-Upgrade](/network-upgrades/mesa/upgrade-steps/post-upgrade) | | ||
| | **Exchanges** | [Requirements](/network-upgrades/mesa/requirements), [Upgrade Steps](/network-upgrades/mesa/upgrade-steps), [Appendix](/network-upgrades/mesa/appendix) | | ||
|
|
||
| ## Network Details |
There was a problem hiding this comment.
Is this pre or postfork? Is this something we need to update when RC is released?
| @@ -0,0 +1,546 @@ | |||
| --- | |||
There was a problem hiding this comment.
suggest to simplify this so most stuff go into subpage. This is too long.
| |--|--|--|--|--| | ||
| | Mina Daemon Node | 32 GB RAM | 8 core processor with BMI2 and AVX CPU instruction set are required | 64 GB | 1 Mbps Internet Connection | | ||
| | SNARK Coordinator | 32 GB RAM | 8 core processor | 64 GB | 1 Mbps Internet Connection | | ||
| | SNARK Worker | 32 GB RAM | 6 core/12 threads per worker with BMI2 and AVX CPU instruction set are required | 64 GB | 1 Mbps Internet Connection | |
There was a problem hiding this comment.
I think we should better reduce the requirement here.
I think 1GB(nothing is stored on disk by the SNARK worker at all except from the log) storage + 8G RAM(If not fewer) per SNARK worker is good enough already.
We should keep in mind that node ops should usually run more than 1 SNARK workers.
|
|
||
| **IP:** | ||
|
|
||
| By default, the Mina Daemon will attempt to retrieve its public IP address from the system. If you are running the node behind a NAT or firewall, you can set the `--external-ip` flag to specify the public IP address. |
There was a problem hiding this comment.
This is just copy pasted from node operators > validators > requirements. I don't like the fact we're copy-pasting in our docs.
|
|
||
| ### How it works | ||
|
|
||
| 1. You install the stop-slot release ([3.x.x](https://github.com/MinaProtocol/mina/releases)) during the Pre-Upgrade phase. |
There was a problem hiding this comment.
This is instruction for debian. I suggest make it an tab page and point to docker-compose-quickstart for people using docker composes. We may also want to rename that page.
| ### Who should use Automode | ||
|
|
||
| - Block producers who want a hands-off upgrade experience | ||
| - SNARK coordinators running daemon nodes |
There was a problem hiding this comment.
The wording is confusing, because a SNARK coordinator is a kind of daemon node.
There was a problem hiding this comment.
Should snark workers be included here? Based on a comment from Corvo I think not, and that it's ok like this
| - Operators who want to minimize downtime and operational risk | ||
|
|
||
| ### Requirements | ||
|
|
There was a problem hiding this comment.
Shouldn't requirement go first before "How it works"? Also despite there being duplication between here and "How it works", I'm not a fan of the naming of "How it works" because it's a instruction instead of explanation of mechanism.
| - Meet the [hardware requirements](/network-upgrades/mesa/requirements) | ||
|
|
||
| :::info | ||
| Automode applies only to the daemon process. Archive nodes and Rosetta API instances require separate upgrade steps — see [Archive Upgrade](/network-upgrades/mesa/archive-upgrade) and [Post-Upgrade](/network-upgrades/mesa/upgrade-steps/post-upgrade). |
There was a problem hiding this comment.
Archive node, Rosetta node, and standalone snark workers as well.
| Automode applies only to the daemon process. Archive nodes and Rosetta API instances require separate upgrade steps — see [Archive Upgrade](/network-upgrades/mesa/archive-upgrade) and [Post-Upgrade](/network-upgrades/mesa/upgrade-steps/post-upgrade). | ||
| ::: | ||
|
|
||
| ## Manual Mode |
There was a problem hiding this comment.
It might actually be good if we collapse Manual Mode and Auto mode into 2 tabs in top level.
| @@ -0,0 +1,271 @@ | |||
| --- | |||
There was a problem hiding this comment.
This is not exclusive to mesa or berkeley. I think? I wonder if there's a better way structuring the doc.
|
|
||
| The Mina release (version 3.x.x) that node operators install **before** the fork. This release contains the stop-slot logic that gracefully halts the network at the designated time. In [automode](#automode), this release also bundles both the [pre-fork](#pre-fork-binary) and [post-fork binary](#post-fork-binary). | ||
|
|
||
| ### Stop-Transaction-Slot {#stop-transaction-slot} |
|
|
||
| A predefined global slot number baked into the [stop-slot release](#stop-slot-release). When the network reaches this slot, nodes stop accepting new user transactions. Block production continues with empty blocks (no user commands, no coinbase, no fee transfers) for approximately 100 more slots until the [stop-network-slot](#stop-network-slot). This is the point where exchanges must disable deposits and withdrawals. | ||
|
|
||
| ### Stop-Network-Slot {#stop-network-slot} |
There was a problem hiding this comment.
We use name slot_chain_end in code.
|
|
||
| ## Protocol Terms | ||
|
|
||
| ### Expanded zkApp State |
| <Tabs groupId="operator-type"> | ||
| <TabItem value="block-producer" label="Block Producer" default> | ||
|
|
||
| #### Infrastructure |
There was a problem hiding this comment.
Why is this not in requirement.mdx? Why are we repeating same info everywhere in the doc?
| @@ -0,0 +1,441 @@ | |||
| --- | |||
There was a problem hiding this comment.
Why there's 2 section Exchange/Rosetta here? I thought they mean the samething.
| For full details, see the [Mesa release notes](https://github.com/MinaProtocol/mina/releases). | ||
|
|
||
| :::info What changed in Mesa | ||
| - The `--hardfork-handling` flag is **removed** (not supported on the Mesa chain). If you were using it, remove it from your startup configuration. |
| | **SNARK Workers** | Follow the same path as block producers (automode or manual). | | ||
| | **Archive Nodes** | Install stop-slot release. Choose upgrade method: _trustless_ (run upgrade script now) or _trustful_ (import o1Labs dump later). If trustless, run the [archive upgrade script](/network-upgrades/mesa/archive-upgrade) — it is backward compatible and can be applied early. | | ||
| | **Exchanges** | Install stop-slot release. Update integrations (mina-signer, Rosetta API). Test on devnet. Plan deposit/withdrawal freeze window. | | ||
| | **zkApp Developers** | Update to the Mesa-compatible o1js version, recompile your contract, and verify it on the [preflight network](/network-upgrades/mesa/preflight-network). Plan to redeploy on Mesa after the fork — every zkApp must be redeployed because the protocol version bump changes the verification key. | |
There was a problem hiding this comment.
I think o1js will have upgrade docs - we should provide a link to them once they're out.
| | [Upgrade](/network-upgrades/mesa/upgrade-steps/upgrade) | Network halts, state is exported, Mesa build is published | | ||
| | [Post-Upgrade](/network-upgrades/mesa/upgrade-steps/post-upgrade) | Block production resumes on Mesa, flags and configurations for the new network | | ||
|
|
||
| **Please note:** A simplified Node Status service will be part of the upgrade tooling and enabled by default in the Pre-Upgrade release with stop-slots ([3.x.x](https://github.com/MinaProtocol/mina/releases)). This feature allows 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 can disable the reports using the flag `--node-stats-type none`. |
There was a problem hiding this comment.
I think this is a typo and was supposed to be --node-status-type. However, that flag is not recognized by the daemon either. I don't think there is any way of disabling the node status reporting once set in the config.
There was a problem hiding this comment.
This flag was introduced in MinaProtocol/mina#15277 but was later removed.
| docker run --name mina -d \ | ||
| minaprotocol/mina-daemon-auto-hardfork:<version>-bullseye-mainnet \ | ||
| daemon \ | ||
| --block-producer-key /keys/my-wallet \ | ||
| --config-directory /root/.mina-config \ | ||
| --libp2p-keypair /keys/libp2p-key \ | ||
| --peer-list-url https://bootnodes.minaprotocol.com/networks/mainnet.txt \ | ||
| --generate-genesis-proof true \ | ||
| --file-log-rotations 500 \ | ||
| --log-json |
There was a problem hiding this comment.
For this one, the config directory is persistent, but only within the container itself and not on disk. Might be fine for this example, but something to keep in mind - the existing online docs mention creating a dedicated volume for config directory persistence, for instance.
There was a problem hiding this comment.
Also this might need some kind of --restart flag
| --config-directory /root/.mina-config \ | ||
| --libp2p-keypair /keys/libp2p-key \ | ||
| --peer-list-url https://bootnodes.minaprotocol.com/networks/mainnet.txt \ | ||
| --generate-genesis-proof true \ |
There was a problem hiding this comment.
This is harmless, but the --generate-genesis-proof flag does nothing:
| docker exec mina mina client status | ||
| ``` | ||
|
|
||
| **Example — Debian (automode):** |
There was a problem hiding this comment.
Are we doing auto mode on just debian and not through docker? Unsure if I'm forgetting about that.
|
|
||
| SNARK coordinators follow the same path as manual block producers. SNARK workers connect to a coordinator and do not need independent upgrades — they just need the coordinator to be on Mesa. | ||
|
|
||
| The coordinator schedule is identical to the block producer schedule above — use [Manual Mode](#block-producer-manual-mode) depending on your preference. After the coordinator transitions to Mesa, restart your SNARK workers and reconnect them to the coordinator. |
There was a problem hiding this comment.
Workers also need to use the mesa version after they're restarted
| @@ -0,0 +1,41 @@ | |||
| --- | |||
There was a problem hiding this comment.
@dkijania Corvo is right. The requirements page has somehow replaced the index in the deployed version
I've suggested changes to the sidebar.js
| label: 'Berkeley Upgrade', | ||
| link: { | ||
| type: 'doc', | ||
| id: 'network-upgrades/berkeley/requirements', |
There was a problem hiding this comment.
This should be id: 'network-upgrades/berkeley/index',
| type: 'doc', | ||
| id: 'network-upgrades/berkeley/requirements', | ||
| }, | ||
| items: [ |
There was a problem hiding this comment.
need to add the requirements item
'network-upgrades/berkeley/requirements',
|
|
||
| ### Overview | ||
|
|
||
| <img src="/img/network-upgrades/mesa/simplified-schedule.png" alt="Mesa upgrade timeline overview" /> |
There was a problem hiding this comment.
yes, the new version is here, for example: https://docs.google.com/presentation/d/1y4RjpgPDfDruVKwPQdgJl38c2-wIPQr8rCydj_fwckk/edit?slide=id.g3df4c7c489f_0_103#slide=id.g3df4c7c489f_0_103
| This documentation uses terms like _automode_, _stop-slot_, _trustless upgrade_, _dispatcher_, and more. If you encounter an unfamiliar term, check the **[Glossary](/network-upgrades/mesa/glossary)** for definitions. | ||
| ::: | ||
|
|
||
| ## What Mesa Introduces |
There was a problem hiding this comment.
Indeed, we are missing MIPs here.
You can use the short overview describing each here: https://www.o1labs.org/blog/mesa-upgrade
| **Weeks before the fork** — Frank updates his o1js dependency to the Mesa-compatible version and tests his zkApp on the [preflight network](/network-upgrades/mesa/preflight-network): | ||
|
|
||
| ```bash | ||
| npm install o1js@latest |
There was a problem hiding this comment.
latest is not accurate, as 3.0.0 is in pre-release. Latests would give you 2.15 if you are in pre-mesa.
If we expect them to use pre-flight it should now be o1js@3.0.0-mesa.698ca
|
|
||
| ### Node Auto-restart | ||
|
|
||
| Ensure your nodes are set to restart automatically after a crash. For guidance, refer to the [auto-restart instructions](/node-operators/validator-node/connecting-to-the-network#start-a-mina-node-with-auto-restart-flows-using-systemd) |
There was a problem hiding this comment.
This link no longer has any info on starting a mina node with auto-restart. We need to fix it. Not sure where the content is now
| ### Who should use Automode | ||
|
|
||
| - Block producers who want a hands-off upgrade experience | ||
| - SNARK coordinators running daemon nodes |
There was a problem hiding this comment.
Should snark workers be included here? Based on a comment from Corvo I think not, and that it's ok like this
| - Restart your node with the [updated flags](/network-upgrades/mesa/upgrade-steps/post-upgrade) | ||
| 4. Your node begins participating in the Mesa network once the genesis timestamp is reached. | ||
|
|
||
| ### Who should use Manual mode |
There was a problem hiding this comment.
Shouldn't we be explicit here that AN ops and Rosseta API ops should do manuaL?
| - Operators who want to minimize downtime and operational risk | ||
|
|
||
| ### Requirements | ||
|
|
|
|
||
| The daemon does **not** restart itself. Your process manager must detect the exit and restart the process. On restart, the dispatcher sees the `activated` file and launches the Mesa binary with the auto-generated config. | ||
|
|
||
| **This means two things are critical:** |
There was a problem hiding this comment.
For being critical, these things should probably be highlighted either in the Upgrade Modes page that everyone should read, or in the requirements. Upgrade mode mentions it very lightly, with a broken link, and persisten config directory is not mentioned
|
|
||
| You start it with the same flags you normally use. The dispatcher handles the rest. | ||
|
|
||
| ### Automode Debian Packages |
There was a problem hiding this comment.
Also, info like this one seems to be clear instructions (so they should probably go in "upgrade modes" page rather than details. This section is not an implementation detail, rather, what you must do if you don't use docker.
I suggest revising the whole page with this distinction in mind:
- steps to follow should en up in "upgrade modes" or "upgrade steps1
- implementation details should remain in this page, but under Appendix
|
|
||
| This image includes both pre-fork and post-fork packages but uses a dedicated hardfork entrypoint that requires manual intervention to complete the transition. | ||
|
|
||
| ## Which Mode Should I Pick? |
There was a problem hiding this comment.
Remove this whole section. It's duplicated from "Upgrade Modes" page
| With **manual mode**, the time between the stop-network-slot and when you restart your node on Mesa is downtime. If the Mesa genesis timestamp arrives before you finish the upgrade, you will miss blocks until your node catches up. | ||
| ::: | ||
|
|
||
| ## Troubleshooting Automode |
There was a problem hiding this comment.
There should be a separate Troubleshooting page.
| @@ -0,0 +1,65 @@ | |||
| --- | |||
| title: Docker Compose Quickstart | |||
There was a problem hiding this comment.
This page is very confusing to me.
It's logically not related to what I had been reading before.
Could this be sent to the Appendix as an item there? And where should there be links to this? Upgrade Steps?
|
|
||
| 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 window that the Mesa network infrastructure will be bootstrapped, and seed nodes will become available. o1Labs will also finalize the archive node upgrade 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/mesa/docs/upgrading-to-mesa.md). |
|
|
||
| 1. During the upgrade phase (between _stop-network-slot_ and the publishing of the Mesa release), block producers can shut down their nodes. | ||
| 2. After the publication of the Mesa node release, block producers and SNARK workers should upgrade their nodes and be prepared for block production at the genesis timestamp, which is the slot when the first Mesa block will be produced. | ||
| 3. It is possible to continue using the same libp2p key after the upgrade. Remember to adjust the new flag to pass the libp2p key to the node. |
There was a problem hiding this comment.
can we link to the flag?
|
|
||
| # Post-Upgrade | ||
|
|
||
| At approximately 1 hour after the publishing of the Mesa node release, at a predefined slot (Mesa genesis timestamp), block production starts and the network is successfully upgraded. |
|
|
||
| The flags below are **unchanged from Berkeley** — if your node was running correctly before the fork, the same flags will work on Mesa. This section is provided as a reference for operators setting up fresh nodes or verifying their configuration. | ||
|
|
||
| For full details, see the [Mesa release notes](https://github.com/MinaProtocol/mina/releases). |
There was a problem hiding this comment.
this link does not take you to mesa
| #### Rollback | ||
|
|
||
| You can rollback the upgrade process by restoring the database from a backup taken before running the upgrade script. | ||
| Another is to run rollback script which is part of the upgrade script. It will drop all tables and other database objects created by the upgrade script. |
There was a problem hiding this comment.
| Another alternative is to run the rollback script, which is part of the upgrade script. It will drop all tables and other database objects created by the upgrade script. |
7 participants
No description provided.