Mina’s Berkeley Upgrade – What to Expect

The countdown to Mina’s major mainnet upgrade is well underway, and will bring three key features to the protocol, as voted on by the community: 

• Easier zkApp programmability (MIP 4)
• Kimchi, a more powerful proof system (MIP 3)
• Removal of Supercharged Rewards (MIP 1)

Ecosystem contributors have participated in extensive testing, pushing the network to its limits to get us to this point. With the final stage of testing, Upgrade Mechanism Testing (UMT), now complete, the team is preparing to upgrade Devnet, an environment designed for testing and experimentation, before deploying the upgrade to Mina Protocol’s mainnet. 

There are lots of moving pieces in this process, which require a high level of coordination across many ecosystem contributors. Below you can find an overview of what to expect throughout the upgrade process, both in the Devnet environment and on Mina Protocol’s mainnet. 

The upgrade process can be broken down into the following three phases: pre-upgrade, upgrade, and post-upgrade. 

Pre-upgrade: 

• Pre-upgrade release: Node operators and exchanges should update to the pre-upgrade build published by o1Labs. This build contains predetermined stop slots (for both when the network will stop accepting new transactions and for when the network will stop producing blocks) needed to initiate the upgrade. The majority of the stake (approximately 75% of active stake*) will need to be upgraded to the pre-upgrade build for the fork to be successful.
  • Note: This release will incorporate a light version of NodeStats by default to support reporting on upgraded stake, a key indicator for upgrade readiness. You can read more on this and the data it collects once the release notes become available on GitHub.  
• Archive node migration: In parallel, archive node operators should begin their migration process, and will continue with this incrementally until the stop network slot is reached. Documentation will be released for community archive node operators to commence migration at this point. 

*The network active stake is the sum of total stake delegated to Mina block producers that have produced at least 1 block in the last 10k blocks.

During upgrade (15-hour downtime window):

During the upgrade process, there will be 15 hours of network downtime:

• Hour 0: Once the majority stake has upgraded, at a predetermined point the stop transaction slot will be reached. Starting from this slot, all the blocks produced by the upgraded stake will be empty and not include any transactions (payments, delegations, coinbase, etc) and blocks containing transactions will not be accepted, confirming behavior is as expected.
  • It is crucial for block producers to continue running at least one node until the stop network slot is reached so the network reaches consensus on which block to upgrade from. The team at o1Labs will also be collecting network data from these nodes for the post-upgrade release build. Note: as blocks during this period will be empty, block rewards will not be generated during the scheduled network downtime.
• Hour 5: 5 hours after the stop transaction slot (equivalent to 100 slots), the stop network slot will be reached. At this point, block producers who have upgraded will no longer produce new blocks and no new blocks will be accepted, with chain density expected to drop.
  • Note: Block producers who have not upgraded their nodes will not have the stop slots set and may still produce blocks, which will be rejected by the network. For this reason, it’s important to ensure that the majority stake is upgraded before the upgrade process commences.
• Hours 5-14: During this period, o1Labs will publish the post-upgrade package, the build that is planned to run post-fork, by exporting the state at the fork block. This state will be validated along with the ledger state and migrated archive node before the build is ready for release. In parallel, the team will be preparing to launch the network, and will deploy seeds, archive nodes and cron jobs to validate node and network health.
  • Note: A validation tool will be available for the node operators that wish to validate the new Berkeley-compatible ledger against the ledger from the fork block.
• Hour 15: The post-upgrade release will be tagged, and notes shared with the community to begin upgrading before block production restarts. Release notes will be available on GitHub.  

Post-Upgrade:

• Hour 15: One hour after the post-upgrade release is available, the first Berkeley block is expected to be produced.
• Network monitoring: Once the upgrade is complete, and the first Berkeley block has been produced, the teams will be conducting extensive network monitoring to ensure the chain quality is as expected, and the majority stake has been upgraded to the post-Berkeley build. 

Key Roles

Exchanges:

• To minimize service disruption, Exchanges must upgrade their Mina nodes to the pre-upgrade version when requested (which will start producing empty blocks at the predefined slot). Any transactions submitted during the downtime period (after the stop transaction slot) will not be present in the chain after the upgrade. It is recommended to stop MINA deposits and/or withdrawals during the downtime period.
• Any exchanges that rely on the deprecated o1labs/client-sdk library to sign transactions should upgrade to the new library mina-signer prior to the mainnet upgrade.
• Any exchanges that rely on the archive node database directly should also evaluate if their integrations will be affected by the changes in the database schema.
• Any exchanges that do not want to rely on the archive node database export that will be provided by O(1)Labs after the upgrade should go through the archive node migration process that can be found here.
• For questions or support, please contact Mina Foundation through the dedicated Telegram or Discord channels.

Node operators: 

• Node operators should keep a close eye on their email and the #mainnet-updates Discord channel for the most up to date information. If you’d like to register to receive emails, please fill out the following form: https://forms.gle/sBPNp7hgrZEghdvNA 
• For the most up to date information on node releases, please view the GitHub page here. 
• Please familiarize yourself with the upgrade process timeline and understand when you need to upgrade.
• During the upgrade process, block producers should keep at least one node online until the stop-network-slot is reached. Please note: as blocks during this period will be empty, block rewards will not be generated during the scheduled network downtime.

Key Channels 

Please keep an eye on key channels for the latest status and timeline updates. To report any abnormal behavior during, please raise on GitHub: https://github.com/MinaProtocol/mina/releases 

For questions or other issues, please reach out to the team in Mina’s Discord server.

*Blog post edited in May, 2024, to reflect an increase in network downtime from 12 hours to 15 hours, an outcome of the Devnet Upgrade Retrospective.