Changelog:
2024-03-14
- Updated the release candidate to rc1
- Updated the Emerynet and Mainnet proposal templates
2024-03-17
- Updated upgrade handler for Emerynet
2024-03-21
- Pre-release tag removed
- Release page updated
- Expected time for upgrade updated
Hello Agoric Validators & BLD Community,
Agoric OpCo is happy to announce that a new software release, agoric-upgrade-14, is available for the agoric-3 chain. 
Release details:
- Incremental Interchain stack upgrades
- Smart wallet upgrades
We’ve prepared the following:
Upgrade Handlers:
Emerynet: agorictest-upgrade-14-2
Mainnet: agoric-upgrade-14
Note: The upgrade to cosmos 0.46 includes a new index being created during the upgrade Based on tests using a copy of mainnet data, we estimate this upgrade can take from two to three hours for chains with a large IAVL state like the agoric-3 chain.
During that time, no progress is shown on the output, but the process will consume 100% of a CPU core.
Recommended Testnet Milestones
By running long-lived testnets and using that environment to evaluate software before promoting it to mainnet, validators play a vital role in maintaining a healthy, robust network for the Agoric community. Qualifying or certifying any new software release as production ready requires significant testing, and Agoric OpCo recommends that validators evaluate the following milestones before launching an on-chain governance proposal on the agoric-3 mainnet.
Note: Ensure that you’re up to date on golang and node versions for this release, and that you’ve upgraded to the latest version of Cosmovisor that supports the upgrade handler.
– Choose a testnet coordinator to kick off the Emerynet upgrade. Traditionally, the testnet coordinator submits the on-chain proposal for mainnet software upgrade.
– Evaluate core mainnet functionality. This could include:
- Exercising the new VM functionality of the release by participating in the upgrade
- Restarting your node after a successful upgrade
- Exercising on-chain governance parameters
- Creating a state-sync snapshot
- Spinning up a node using a state-sync snapshot
– Keep the community updated on testnet progress by posting updates to this thread and/or sharing details in Discord so that the community can follow progress towards launch.
– Coordinate with your fellow validators to determine if this release is ready to be promoted to mainnet. When the milestone checklist is completed by validators Agoric OpCo will remove the pre-release tag.
– Testnet Lead (or another validator) create a mainnet proposal, if needed seek support from the community for deposit.
Calculating an upgrade height
Creating an Emerynet upgrade proposal for rc1:
Use the following release: Release agoric-upgrade-14-rc1 · Agoric/agoric-sdk · GitHub
Confirm the commit hash and upgrade name BEFORE submitting a proposal.
Please note the instructions are slightly different than for the initial Emerynet upgrade, in particular the value of UPGRADE_TO and UPGRADE_INFO.
# Edit as needed
FROM_WALLET=yourwallet
UPGRADE_HEIGHT="1234-get-blockheight-from-estimator"
# Verify values
UPGRADE_TO="agorictest-upgrade-14-2"
CHAIN_ID="agoric-emerynet-8"
COMMIT_ID=$(git rev-parse HEAD)
ZIP_URL="https://github.com/Agoric/agoric-sdk/archive/${COMMIT_ID}.zip"
CHECKSUM=sha256:$(curl -L "$ZIP_URL" -o- | shasum -a 256 | cut -d' ' -f1)
UPGRADE_INFO="{\"binaries\":{\"any\":\"$ZIP_URL//agoric-sdk-${COMMIT_ID}?checksum=$CHECKSUM\"},\"source\":\"$ZIP_URL?checksum=$CHECKSUM\"}"
agd tx gov submit-proposal software-upgrade $UPGRADE_TO --upgrade-info="$UPGRADE_INFO" --upgrade-height="$UPGRADE_HEIGHT" --title="Upgrade to $UPGRADE_TO" --description="This proposal if voted will upgrade the chain to $UPGRADE_TO" --from=$FROM_WALLET --chain-id=$CHAIN_ID
When the testnet milestones are complete and validators have fully qualified the release on Emerynet, the testnet coordinator should inform Agoric OpCo to promote the release from rc to final and update tags accordingly, then create and submit a similar on-chain proposal to upgrade the agoric-3 chain to agoric-upgrade-14.
Creating a Mainnet upgrade proposal:
Confirm the commit hash and upgrade name BEFORE submitting a proposal.
Please note the changes to the instructions, in particular the value of UPGRADE_TO and UPGRADE_INFO.
# Edit as needed
FROM_WALLET=yourwallet
UPGRADE_HEIGHT="1234-get-blockheight-from-estimator"
# Verify values
UPGRADE_TO="agoric-upgrade-14"
CHAIN_ID="agoric-3"
COMMIT_ID=$(git rev-parse HEAD)
ZIP_URL="[https://github.com/Agoric/agoric-sdk/archive/${COMMIT_ID}.zip](https://github.com/Agoric/agoric-sdk/archive/$%7BCOMMIT_ID%7D.zip)"
CHECKSUM=sha256:$(curl -L "$ZIP_URL" -o- | shasum -a 256 | cut -d' ' -f1)
UPGRADE_INFO="{\"binaries\":{\"any\":\"$ZIP_URL//agoric-sdk-${COMMIT_ID}?checksum=$CHECKSUM\"},\"source\":\"$ZIP_URL?checksum=$CHECKSUM\"}"
agd tx gov submit-proposal software-upgrade $UPGRADE_TO --upgrade-info="$UPGRADE_INFO" --upgrade-height="$UPGRADE_HEIGHT" --title="Upgrade to $UPGRADE_TO" --description="This proposal if voted will upgrade the chain to $UPGRADE_TO" --from=$FROM_WALLET --chain-id=$CHAIN_ID
Important reminder for anyone generating state-sync snapshots or restoring from state-sync
In order to produce state-sync snapshots, beginning with agoric-upgrade-11 your node must have a “complete” JS database. If your DB isn’t complete, the state-sync generation process will fail. If you have been running a node continuously since the Mainnet 1B upgrade (agoric-upgrade-10), then your DB will be complete.
If you created your node from a state-sync restore before agoric-upgrade-11, or if you used a community snapshot that had itself restored from state-sync, then your DB will not be complete. You can restore from state-sync with agoric-upgrade-14 to obtain a complete DB.
We are aware of continued performance issues related to state-sync. In particular, we’ve observed that on the agoric-3 chain, the current implementation can require 100 GB of free disk space on /tmp and 16GB of memory during a state-sync restore. The process can take over an hour depending on the characteristics of the machine, and we’ve observed that setting a longer trusted blocks window is necessary during restore (e.g. 5000 blocks).
