added initial draft for upgrade to mesa#1133
Open
dkijania wants to merge 45 commits into
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
glyh
reviewed
Nov 30, 2025
cjjdespres
reviewed
Dec 3, 2025
| - 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
yamimaio
reviewed
Dec 11, 2025
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
glyh
reviewed
Mar 17, 2026
glyh
reviewed
Mar 17, 2026
yamimaio
reviewed
Mar 19, 2026
| ```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 |
Collaborator
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> |
|
|
||
| **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. |
| ```bash | ||
| sudo systemctl stop mina | ||
| sudo apt-get update | ||
| sudo apt-get install mina-mainnet-mesa=<mesa-version> |
Collaborator
There was a problem hiding this comment.
Don't we know what this is at this point?
I've seen in a few places
glyh
reviewed
Mar 20, 2026
![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)
cjjdespres
reviewed
Mar 20, 2026
| |--|--|--|--|--| | ||
| | 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 | |
Member
There was a problem hiding this comment.
32GB ram and 64GB storage per worker seems a bit high.
Contributor
There was a problem hiding this comment.
Mesa SNARK Worker should be 6 core / 12 thread
glyh
reviewed
Mar 21, 2026
| | 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 | |
Member
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.
glyh
reviewed
Mar 21, 2026
|
|
||
| :::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`. |
Member
There was a problem hiding this comment.
Why installing new package couldn't auto remove the old?
Member
Author
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
glyh
reviewed
Mar 21, 2026
glyh
reviewed
Mar 21, 2026
|
|
||
| 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 |
Member
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
Address Section 4c of PR #1133 review feedback (yamimaio #3230147631). The "What You Need to Do — By Role" section duplicated content available elsewhere: - The per-role AI-generated timeline diagrams duplicated the same images already removed from mesa/index.mdx in commit 412c6a1. - The Block Producer code snippets (Docker automode, Debian automode, Docker manual, Debian manual) duplicated either the Alice/Carlos examples now on the new examples.mdx page (4a) or the install commands now on upgrade-modes.mdx (4b). - The SNARK Worker subsection duplicated the coordinator-spawned vs standalone explanation already on the SNARK Worker tab of pre-upgrade.mdx (commit b85eb94). - The Archive Node / Exchange subsections were one-line pointers to pages they already linked to. Replace the whole section with a short "Walkthroughs by role" pointer block: per-phase pages cover what every role does at each step, examples.mdx covers end-to-end narrative walkthroughs by role, and role-specific quick links point to the relevant sub-pages (upgrade-modes for daemon, pre-upgrade for SNARK workers, archive-upgrade for archive operators, post-upgrade for exchanges). The exchange danger admonition is retained — it's the only piece of content here that didn't have a single canonical home elsewhere. File shrinks from 203 lines to ~45. Regenerated static/llms-full.txt. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…dedup Address the smaller Section 4 review items grouped under "Other". upgrade-modes.mdx: - Reorder both Automode and Manual sections so Requirements comes before "How it works" (glyh #3198975457, yamimaio #3228833395). Operators want to know the prerequisites before they read the step-by-step. Also rename the two "How it works" subsections to "How automode works during the fork" / "How manual mode works during the fork" so the heading describes mechanism, not a to-do list. - Manual Mode section: explicitly state that Archive node and Rosetta API operators must use manual mode (yamimaio #3228818513). Add Archive / Rosetta bullets to the "Who should use Manual mode" list so the constraint is impossible to miss. sidebars.js (yamimaio #3230094542): - Move `network-upgrades/mesa/docker-compose-quickstart` out of the top-level Mesa Upgrade items list and into the Appendix category (alongside `appendix` and `upgrade-modes-details`). The page is reference material rather than part of the main upgrade flow. replayer.mdx (glyh #3198983919): - Add an `:::info Not Mesa-specific:::` admonition at the top explaining that mina-replayer is a general-purpose archive verification tool — this page just happens to cover the role it plays at hard-fork time. A future revision may relocate the general parts of this page to the Archive Node section. upgrade-steps/pre-upgrade.mdx (glyh #3199028680): - Add a lead-in paragraph pointing to the Requirements page and explaining the checklist intentionally avoids repeating concrete hardware specs (RAM/CPU/storage) so they only live in one place. - Strip "— 32 GB RAM, 8-core CPU" suffixes from the SNARK Coordinator and Archive Node tabs; keep a short per-worker note on the SNARK Worker tab pointing to the requirements row. - Fix four occurrences of a broken auto-restart link: `/node-operators/block-producer-node/connecting-to-the-network` does not exist (the file lives under `validator-node/`), and the `#start-a-mina-node-with-auto-restart-flows-using-systemd` anchor was already removed from that page. Repoint at `/node-operators/validator-node/connecting-to-the-network#running-mina-node-as-a-service`, matching the same fix applied to requirements.mdx in commit 99f9984. Regenerated static/llms-full.txt (still 384 pages). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mesa/index.mdx (glyh #3198928535):
- Remove the "Timeline by Role" section. The four `<details>` blocks
were short per-role summaries that paraphrased the Phase 1-4 actor
tables directly above them and duplicated the per-role narratives
on the new examples.mdx page (4a). Replace with a one-line pointer
to Upgrade Steps + Examples.
mesa/upgrade-steps/pre-upgrade.mdx (yamimaio #3230172497):
- Convert the "Detailed Steps" section from a flat
`### Block Producers / ### Archive / ### Exchanges` layout into a
`<Tabs>` block using the same `operator-type` group as the
Readiness Checklist above. Readers stay on their role tab across
both sections.
- Split the old "Block Producers and SNARK Workers" heading into
three separate tabs (Block Producer, SNARK Coordinator, SNARK
Worker) so the standalone-worker post-fork redeployment note
(cjjdespres #3235086255) is visible in the SNARK Worker tab here
as well, not just on the Readiness checklist above.
mesa/requirements.mdx (glyh #3198948996):
- Replace the duplicated IP/Port/Auto-restart prose (copy-paste from
Validator Node requirements) with a short "See also" pointer at
the canonical Validator Node sections. The Mesa-specific hardware
table at the top of the page stays.
mesa/upgrade-steps/post-upgrade.mdx:
- Add a Exchange/Rosetta distinction preamble (glyh #3199039711):
explain that Rosetta = integration layer, Exchange = end-platform,
and that most exchanges go through both tabs but the split matters
for the handful running without Rosetta.
- Expand the "What changed in Mesa" flags `:::info:::` callout
(glyh #3199042988 "What do you mean?"):
- `--hardfork-handling`: explain what it did on Berkeley and why
Mesa doesn't accept it. Note that the daemon will exit with
an unknown-argument error if you leave it set.
- `--genesis-ledger-dir` / `-config-file`: give concrete Mesa
paths instead of the vague "Mesa versions (included in the
package)". Note that automode rewrites these automatically.
- Add a third bullet making it explicit which flags carry over
unchanged (block-producer-key, libp2p-keypair, peer-list-url,
etc.).
Regenerated static/llms-full.txt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Address the remaining UX-call review items on upgrade-modes.mdx: - Collapse "Automode" and "Manual Mode" into top-level `<Tabs>` (glyh #3198978812). Readers pick their mode once and see only the relevant content. The comparison table moves to the top so an undecided reader can choose before opening a tab. Tabs use `groupId="upgrade-mode"` so the choice persists if the reader navigates to other pages with the same group. - Make the install-instructions section a nested `<Tabs>` block between Debian and Docker (glyh #3198971226). Each install tab contains exactly the apt / docker commands for that platform, and the Docker tab points docker-compose users at the `docker-compose-quickstart` page now living under Appendix. `groupId="install-method"` matches the same group used in connecting-to-the-network.mdx so the choice persists across the site. Applies to both Automode and Manual outer tabs (manual mode also gained a brief install section for parity). The page intentionally surfaces the "Archive / Rosetta / standalone SNARK workers must use Manual mode" constraint at the top, above the tabs, so an operator in that bucket sees it before they pick a tab. Regenerated static/llms-full.txt. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
A re-audit found two fixes from earlier review-resolution commits that did not actually land what reviewers asked for. Correct them properly: MIPs (glyh #3198894474, yamimaio #3228391904) — commit a0393a3 added only one MIP ("account-update limit") and linked the o1Labs blog post as the canonical reference. The actual canonical source is the MinaProtocol/MIPs repo, and the Mesa hard fork bundles four MIPs that were not previously documented: - MIP6 — Reduce slot time to 90s - MIP7 — Increase On-Chain State Size Limit (the existing "Expanded zkApp State" change) - MIP8 — Increase Events & Actions Limit - MIP9 — Increase zkApp Account-Update Limit Replace the "Additional Protocol Improvements" subsection with bullets that name each MIP, link to its canonical spec in MinaProtocol/MIPs, and summarize the operator-facing effect. The blog post is kept as a secondary, narrative reference. Node Status flags (related to cjjdespres #3220629641) — commit b85eb94 removed the bogus `--node-stats-type none` opt-out from upgrade-steps/index.mdx, but the same non-existent flag survived in: - post-upgrade.mdx#help-monitor-the-network: recommended `--node-stats-type full` (does not exist) and `--node-stats-type none` for opt-out. - glossary.mdx Node Status Service entry: said "Can be disabled with `--node-stats-type none`". Both rewritten against the actual Mesa flags as defined in the mina source on origin/mesa_preflight_prefork and origin/georgeee/mesa: - `--simplified-node-stats` (no-arg) — keep the report minimal - `--disable-node-status` (no-arg) — opt out entirely - `--node-status-url <url>` and `--node-error-url <url>` — endpoints The post-upgrade page also notes inline that `--node-stats-type` was never accepted by the daemon, so the previous docs were misleading. Regenerated static/llms-full.txt. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Re-audit of two earlier review resolutions after maintainer feedback
that they were technically applied but missed the substance of the
ask:
1) MIPs in mesa/index.mdx (glyh #3198894474, yamimaio #3228391904)
Earlier passes added a one-line bullet per MIP plus a link to the
o1Labs blog. The reviewer's intent — described in their reply — was
"describe the MIPs in the docs themselves, using the blog as a
source to draw from, not as a destination to link to."
Restructure "What Mesa Introduces":
- Drop the "Expanded zkApp State" subsection in isolation and the
loose "Additional Protocol Improvements" wrapper. Replace with
four MIP-themed subsections that match the canonical MIPs and
describe the operator-facing changes in real detail:
- Faster Blocks (MIP6) — slot time 180s -> 90s, coinbase 720 ->
360 MINA, epoch length halved to ~7.4 days, default zkApp soft
limit unset, recommended SNARK coordinator hardware (>= 4
workers).
- Expanded zkApp State (MIP7) — 8 -> 32 fields, redeploy
requirement for zkApps, archive schema additions, transaction
protocol version bump.
- Larger Events and Actions (MIP8) — 100 -> 1024 field-element
cap per transaction, individual 16-element cap removed.
- Larger zkApp Transactions (MIP9) — old weighted-cost formula
replaced with `np + n2 + n1 <= 16`, depends on MIP6 SNARK
optimization.
- Each section heads with a direct link to the canonical spec in
MinaProtocol/MIPs.
- The blog post link is removed entirely — Mina Protocol docs
should not depend on a third-party blog as the citation for
protocol changes.
- The two operational improvements (Automode Upgrades, Simplified
Archive Upgrade) keep their existing subsections.
2) Appendix sidebar entry (yamimaio #3228596882)
Earlier commit f492f09 made the Mesa "Appendix" sidebar item into
a Category as requested, but the first item inside the category was
itself labelled "Appendix" — producing the awkward "Appendix >
Appendix" hierarchy. The page in question is in fact a reference
for archive-node database schema changes between Berkeley and Mesa,
not a generic appendix.
- Rename appendix.mdx frontmatter title and sidebar_label to
"Archive Node Schema Changes". This also updates the rendered
`# Heading` since hide_title=true causes the title field to drive
the h1.
- Update the page description to match the renamed content.
- Update all five inbound `[Appendix](/network-upgrades/mesa/appendix)`
link texts across mesa docs (index, archive-upgrade, glossary,
pre-upgrade) to "Archive Node Schema Changes".
Path of the page itself is unchanged so no inbound URLs break.
3) Known issue not patched in this commit
The new MIP6 description states the slot duration becomes 90 seconds,
but Phase 2 of mesa/index.mdx and the glossary continue to claim
"State Finalization is exactly 5 hours / 100 slots" based on
cjjdespres review comment #3220498212. 5 hours only holds under
180-second slots, so MIP6 either changes that figure (to 100 slots
× 90s = 2.5h, or to 200 slots × 90s = 5h, depending on whether the
slot count is held constant) or cjjdespres was speaking about a
schedule that pre-dates MIP6 finalization. Flagging to maintainers
in the PR thread instead of silently changing it.
Regenerated static/llms-full.txt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ckage
The Mesa automode shipping vehicle has been unified: instead of asking
operators to install both `mina-{network}-prefork-mesa` and
`mina-{network}-postfork-mesa` by hand, there is now a single
`mina-{network}-automode` Debian umbrella package that depends on both
and lets apt resolve them transitively. Update the user-facing install
flow accordingly and keep the dependency relationship visible where it
matters for operators debugging their setup.
User-facing install instructions:
- `upgrade-modes.mdx`: rewrite the Debian install snippet to use
`sudo apt-get install mina-{network}-automode=4.x.x`. Add a short
paragraph noting that the package is an umbrella and apt pulls in
the two sub-packages automatically.
- `upgrade-steps/examples.mdx`: Alice's `apt-get install` line now
installs `mina-mainnet-automode=4.x.x` instead of the two `-mesa`
packages.
- `upgrade-steps/pre-upgrade.mdx`: Block Producer and SNARK
Coordinator checklists point at `mina-{network}-automode`.
- `index.mdx`: Phase 1 Block Producers row mentions the new package
by name and links to the install section on upgrade-modes.mdx.
Architecture / reference:
- `upgrade-modes-details.mdx`: the dual-binary table no longer labels
each binary with its (now sub-package) name; "How automode is
packaged" calls out the umbrella relationship explicitly and lists
what each sub-package supplies.
- `glossary.mdx`: pre-fork and post-fork binary entries point at
`mina-{network}-automode` as the install handle; the "Mesa Package
Naming Convention" entry now documents the umbrella + dependency
layout.
Regenerated static/llms-full.txt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Address PR #1133 review comment by glyh (#3198891299): the placeholder sentence pointing at the GitHub releases filter sat between the opening paragraph and the "New to the Mesa upgrade?" info admonition without adding information beyond what later sections (Network Details, Quick Reference) already cover. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Address PR #1133 review comment by glyh (#3198895612): the opening framing on the Mesa index page over-claimed who is affected. Two residual cases of the same overreach were left in the working tree: - mesa/index.mdx, Automode Upgrades section: "node operators can upgrade through a hard fork without manual intervention" implied every operator could opt in. Tighten to "block producers" and add an explicit note that archive node and Rosetta API operators still use manual mode — automode is not available for those node types. Matches the constraint already stated on upgrade-modes.mdx. - mesa/requirements.mdx frontmatter: the page description was a carbon-copy of the original mainnet-wide claim ("requires all nodes in a network to upgrade"). Rewrite it to describe the page's actual scope: hardware and connectivity requirements for daemon node operators, with the same role list used on the index page. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Address PR #1133 review comments by glyh (#3198904627), cjjdespres (#3220486292), and yamimaio (#3228350952): the original timeline diagram was AI-generated and flagged for replacement with an official design asset. The earlier commit had removed the diagram and left a TODO comment pointing at the slide deck / Berkeley upgrade-steps reference; this commit drops in the final asset. - Add `static/img/network-upgrades/mesa/mesa-upgrade-timeline.png` (960x540) — the four-phase timeline shown on the Mesa upgrade slide deck, covering Pre-Upgrade → State Finalization → Upgrade → Post-Upgrade with the stop-transaction-slot and network shutdown markers. - mesa/index.mdx Overview section: swap the TODO MDX comment for an `<img>` tag at full width with an alt-text description of the diagram's content. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Address PR #1133 review comment by glyh (#3198914880): operators landing on the Mesa index page need somewhere to click through and find the concrete fork-schedule numbers — Mesa genesis timestamp, stop-transaction-slot (`slot_tx_end`), stop-network-slot (`slot_chain_end`). The earlier round only linked at glossary definitions and left a TODO; this commit creates the page and wires it up. - New `docs/network-upgrades/mesa/fork-schedule.mdx` with TBD tables per network (mainnet, devnet) plus the already-known preflight values. Each entry calls out the daemon-config alias (`slot_tx_end` / `slot_chain_end`) and the 100-slot / 5-hour finalization invariant. Closes with a "How to use these values" section that addresses exchanges, block producers, archive, and Rosetta operators. - `sidebars.js`: insert `network-upgrades/mesa/fork-schedule` into the Mesa Upgrade items list between Upgrade Modes and Upgrade Steps — the natural reading flow is "pick a mode → check when the fork happens → execute the steps". - `mesa/index.mdx` Phase 2 intro: retarget the inline `stop-transaction-slot` and `stop-network-slot` mentions at the new Fork Schedule page (per glyh's suggested UX) and add a short trailing sentence pointing readers there. Drop the TODO MDX comment that was acting as a placeholder for this work. static/llms-full.txt is intentionally not regenerated in this commit — it will be refreshed in a single pass once the remaining review items have landed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…nused Address PR #1133 review comment by glyh (#3199042988). The earlier pass overstated the behaviour: it claimed the Mesa binary would reject `--hardfork-handling` with an unknown-argument error. That is wrong — the flag is still parsed by the Mesa binary, it just has no effect post-fork because there is no hardfork left to handle once the daemon is running on the Mesa chain. Rewrite the "What changed in Mesa" bullet on upgrade-steps/post-upgrade.mdx accordingly: - Change "is no longer recognized" → "should no longer be set" so the heading reflects intent, not a behaviour the binary does not exhibit. - Drop the inaccurate claim that the daemon will exit with an unknown-argument error. Replace it with an accurate statement that the flag is parsed but has no effect post-fork, and explain why fork handling has moved (automode dispatcher / manual stop/install/restart procedure). - Keep the operator advice intact: remove the flag from startup configs so it does not mask a real configuration mistake later. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Single regeneration pass after the six commits addressing follow-up review threads from @glyh and @cjjdespres: 64d55fd mina-{network}-automode umbrella package rename bf26f1b remove redundant "Please refer to Mesa release notes" line b6f16fc narrow "node operators" claims (index + requirements) 277af19 replace AI diagram placeholder with official PNG 7b077b2 add Fork Schedule placeholder page + retarget links 044b3dc correct --hardfork-handling description Page count goes from 384 → 385 (new Fork Schedule page). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Member
Author
PR #1133 — review feedback addressedPushed 23 commits on top of @glyh — addressed
@cjjdespres — addressed
Housekeeping
Known follow-ups (not blocking)A few items are still parked as TODO comments in-tree because they depend on inputs outside this PR:
Everything else flagged in review is resolved on this branch. Please re-check the threads you filed — let me know if any of the resolutions don't land the way you intended. |
Member
|
Placeholder for unresolved comments |
glyh
reviewed
May 20, 2026
|
|
||
| The Mesa daemon inherits the same networking and process-management requirements as the Berkeley daemon. Rather than restate them here, refer to the canonical sections in the Validator Node docs: | ||
|
|
||
| - **IP and port configuration** — `--external-ip`, `--external-port`, default port `8302` (libp2p). See [Validator Node Requirements](/node-operators/validator-node/requirements). |
Member
There was a problem hiding this comment.
Could you anchor this link? e.g. something like
/node-operators/validator-node/requirements#networking
glyh
reviewed
May 20, 2026
| mina libp2p generate-keypair --privkey-path <path-to-the-key-file> | ||
| ``` | ||
|
|
||
| Further information on [generating key pairs](/node-operators/validator-node/generating-a-keypair) on Mina Protocol. |
Member
There was a problem hiding this comment.
Wrong link, that page explains wallet keys not libp2p keys.
This is the correct page:
/seed-peers/generating-a-libp2p-keypair
glyh
reviewed
May 20, 2026
|
|
||
| Pick the tab that matches the mode you intend to run. If you are unsure, start with the Automode tab — it is the recommended path for daemon nodes. | ||
|
|
||
| <Tabs groupId="upgrade-mode"> |
glyh
reviewed
May 20, 2026
|
|
||
| See the Docker manual example on the [Examples](/network-upgrades/mesa/upgrade-steps/examples) page. | ||
|
|
||
| For docker-compose users, see the [docker-compose quickstart](/network-upgrades/mesa/docker-compose-quickstart) (under Appendix). |
Member
There was a problem hiding this comment.
that page is only for auto mode docker compose. Suggest remove this paragraph.
glyh
reviewed
May 20, 2026
| #### Keys | ||
|
|
||
| <ul className="checklist"> | ||
| <li>libp2p keypair is accessible</li> |
Member
There was a problem hiding this comment.
glyh
reviewed
May 20, 2026
|
|
||
| <ul className="checklist"> | ||
| <li>Block producer key file is accessible and backed up</li> | ||
| <li>libp2p keypair is accessible (same key can be reused from before the upgrade)</li> |
Member
There was a problem hiding this comment.
libp2p keys are not a must, it's only needed for seeds, or we're tracking uptime data via MUT.
glyh
reviewed
May 20, 2026
|
|
||
| **1. Worker spawned by a coordinator** (`--run-snark-worker` set on the coordinator) | ||
|
|
||
| <ul className="checklist"> |
Member
There was a problem hiding this comment.
I'd remove this complex list, and just say no separate actions are needed, have coordinators upgraded and snark workers attached to the coordinator will upgrade along with it.
glyh
reviewed
May 20, 2026
|
|
||
| <ul className="checklist"> | ||
| <li>Server meets <a href="/network-upgrades/mesa/requirements">hardware requirements</a> (per-worker specs apply for each SNARK worker)</li> | ||
| <li>Install the stop-slot release on the worker host as well — the worker must speak the same protocol as the coordinator</li> |
Member
There was a problem hiding this comment.
I don't think you need to install stop slot release for the worker. It doesn't read daemon config at all.
glyh
reviewed
May 20, 2026
| </ul> | ||
|
|
||
| </TabItem> | ||
| <TabItem value="exchange" label="Exchange"> |
Member
There was a problem hiding this comment.
why a separate section for exchange in additional to Rosetta?
glyh
reviewed
May 20, 2026
| @@ -0,0 +1,264 @@ | |||
| --- | |||
Member
There was a problem hiding this comment.
Could we just remove this page as a whole? I still can't tell why should this be in a separate page from requirements.mdx.
glyh
reviewed
May 20, 2026
Comment on lines
+42
to
+43
|
|
||
| 1. Exchanges shall disable MINA deposits and withdrawals during the entirety of the upgrade downtime, since the _stop-transaction-slot_ until the Mainnet Mesa network is operational. |
Member
There was a problem hiding this comment.
Same section copy pasted from state finalization page. I'd suggest do a proper audit on duplication. Samething mentioned like 4~5 times in the doc is annoying.
glyh
reviewed
May 20, 2026
|
|
||
| ## Verify Your Node | ||
|
|
||
| <Tabs groupId="operator-type"> |
Member
There was a problem hiding this comment.
It's weird that we're using tabs here but not later. I suggest put later "in-depth validation" into tabs as well.
glyh
reviewed
May 20, 2026
|
|
||
| You should see: | ||
| - **Sync status**: `Synced` | ||
| - **Chain ID** matching the Mesa chain ID (`a7351abc7ddf2ea92d1b38cc8e636c271c1dfd2c081c637f62ebc2af34eb7cc1`) |
Member
There was a problem hiding this comment.
This should be depend on which network we're forking, no? For now we only know the preflight's chain ID, but nothing about MUT, devnet and mainnet.
glyh
reviewed
May 20, 2026
| - **Chain ID** matching the Mesa chain ID (`a7351abc7ddf2ea92d1b38cc8e636c271c1dfd2c081c637f62ebc2af34eb7cc1`) | ||
| - **Block height** advancing | ||
|
|
||
| #### 2. Verify block production |
Member
There was a problem hiding this comment.
This should be removed and we just point to node-operators/block-producers section. So is most other stuff in this page on block producers. I'm sure that's the same situation for other couple of things here.
glyh
reviewed
May 20, 2026
| mina internal snark-worker \ | ||
| --proof-level full \ | ||
| --shutdown-on-disconnect false \ | ||
| --daemon-address <coordinator-ip>:<port> |
Member
There was a problem hiding this comment.
I haven't tested this(i.e. whether snark worker being compatible pre/post fork). I wasn't running a SNARK coordinator, could we find who actually run those in the dryrun and have them confirm the situation on this?
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
7 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.