Mainnet Beta Release 1.2.0beta8

[lk86]

The O(1) Labs team is making progress on the networking issues reported since 1.2.0beta2/3 but so far, we are struggling to solve the issue beyond about 40 hours of uptime. So to mitigate this, and to still provide an overall better experience than 1.1.X, we have improved the automated shutdown behavior to be configurable. The default stop time is after 24 hours of uptime, use the new --stop-time flag to reconfigure this value. The next release, 1.2.1alpha1, will include more comprehensive changes to improve responsiveness.

Now for the good news! 1.2.0beta8 also includes improvements to the new features from 1.2.0beta5. This beta release allows you to connect to our uptime tracking endpoint or run your own, but the data you submit now WILL NOT COUNT towards your uptime until this feature is released in a stable version. At that point the Mina Foundation will make an announcement, wipe the google cloud bucket, and reset everything for production use. In the meantime, you can try out the new daemon flags ( --uptime-submitter-key </path/to/private/key>, --uptime-url http://34.134.227.208/v1/submit) and the new environment variable UPTIME_PRIVKEY_PASS for providing the password to the keypair you registered with on the leaderboard. You no longer need to import your key to use it in this way, --uptime-submitter-key works identically to --block-producer-key. See #9499 for more details on how to use this new feature. Additionally, if you want to test out the backend side or experiment with creating your own leaderboard UI, check out the backend README.

If you run into any issues, please include Release: 1.2.0beta8 in the name of any issues you create. Please report any issues you encounter here: https://github.com/MinaProtocol/mina/issues/new/choose

Stability Improvements and Bug Fixes:

• Add --stop-time flag to configure the automatic restart behavior. Defaults to 24 hours. update stoppage time #9506

New Features:

• Improved Mina Foundation Uptime Tracking! Allow uptime submitter keyfile #9499
  • This feature no longer requires importing your keypair, now supports a new flag --uptime-submitter-key which takes the path to your private key, just like --block-producer-key.
  • To test the new system, pass in the following information to the daemon:
    • The path to the private key with the flag --uptime-submitter-key </path/to/private/key>
    • The URL of our testing backend server with the flag --uptime-url http://34.134.227.208/v1/submit
    • The password for the keypair associated to the given public key with the environment variable UPTIME_PRIVKEY_PASS=<YOUR PASSWORD HERE>. If you are using a .mina-env file on Debian then this value should be on its own line, not included in EXTRA_FLAGS=.
• New environment variables in .mina-env for use with the mina systemd service Lk86/fix mina service wantedby #9375 lk86/updated-mina-systemd-proposal #9533
  • Passes in the --peer-list-url automatically to correspond to the mina package (mina-mainnet for mainnet peers list, and mina-devnet for devnet peers).
    • This value can still be overridden with PEERS_LIST_URL variable in .mina-env
  • KEY_NAME variable is no longer supported, use EXTRA_FLAGS to configure block producer keys
  • LOG_LEVEL variable to set the daemon log level, with the default value Info
  • FILE_LOG_LEVEL variable to set the daemong file log level, with the default value Debug
  • Remove --generate-genesis-proof true as its a no-op in this mina version anyway
  • Changed WantedBy to default.target instead of multi-user.target as the latter does not work in user services (as many users have reported)

Archive Node:

We put together a new tool to process archive node data all the way back to the genesis block, locate any "swapped" balances (caused by a pre-1.1.5 bug in the archive node logic), and fix them. See https://gist.github.com/lk86/22b07d3b3f91c765f34e4e4398a84701 for complete instructions.

Complete Changelog since 1.2.0beta2:

1.2.0beta5...1.2.0beta8
For more information about the changes included in 1.2.0beta5, see the previous release notes
The beta6 and beta7 releases contain improvements to the transaction inclusion logic for block producers, and it is highly recommended that you upgrade to , 1.1.8, 1.2.0beta7, or this release. See our Retrospective for more information about our approach with these fixes and why they're important.

Upgrading & Connecting

Daemon Release Artifacts:

Docker Image:
gcr.io/o1labs-192920/mina-daemon:1.2.0beta8-5b35b27-mainnet
Debian Package:
NOTE: --peers-list-url flag is no long required when running with systemctl --user ...
To allow for installation of mina beta builds:

echo "deb [trusted=yes] http://packages.o1test.net stretch beta" | sudo tee /etc/apt/sources.list.d/mina-beta.list
sudo apt-get update
sudo apt-get install -y mina-mainnet=1.2.0beta8-5b35b27

Archive Node Release Artifacts:

Docker Image:
gcr.io/o1labs-192920/mina-archive:1.2.0beta8-5b35b27
Debian Package:
sudo apt-get install -y mina-archive-mainnet=1.2.0beta8-5b35b27
Schema for initializing postgres:
create_schema.sql

Sandbox Node: For testing in an isolated, single-node network without snarks

As of 1.2.0, the demo functionality is built into the standard daemon container, via the environment variable RUN_DEMO=true.
Just docker run -it --name mina-demo -e RUN_DEMO=true gcr.io/o1labs-192920/mina-daemon:1.2.0beta8-5b35b27-devnet and go!

NEW Devnet:

This release is the first to support the newly relaunched Devnet #9523. To use any of the above packages or docker images with devnet instead of mainnet, you can simply replace mainnet with devnet in either the name of the package or the docker image tag.

Block Producer Stats Sidecar:

The block producer sidecar will be replaced with the foundation delegation uptime tracker described above, once it is graduated to stable. In the meantime any version of the sidecar since ~1.1.6 should work the same way, and the data produced by the sidecar still counts towards foundation delegation elegibility.

Step by Step Guide:

Check out our documentation for complete instructions on using this version to connect to Mainnet. Docker only Make sure to run with --peer-list-url https://storage.googleapis.com/mina-seed-lists/mainnet_seeds.txt.

If you are running the correct version on the correct network, mina client status will show:

Chain id:     5f704cc0c82e0ed70e873f0893d7e06f148524e3f0bdae2afb02e7819a0c24d1
Git SHA-1:    5b35b27df8e137ddbe88874b4efdcf4bb2cb4ae9

---

This discussion was created from the release Mainnet Beta Release 1.2.0beta8.

[scarletbright]

Hello,

it's not working for me with the flag --uptime-submitter-key, only with --uptime-submitter-pubkey

with --uptime-submitter-key I'm getting this:

Oct 05 20:17:17 frhb65434ds mina[12902]: 2021-10-05 18:17:17 UTC [Info] Using uptime submitter keypair private-key password from environment variable UPTIME_PRIVKEY_PASS
Oct 05 20:17:17 frhb65434ds mina[12902]: FATAL ERROR
Oct 05 20:17:17 frhb65434ds mina[12902]:   ☠  Mina Daemon encountered a configuration error loading uptime submitter keypair.
Oct 05 20:17:17 frhb65434ds mina[12902]:   
Oct 05 20:17:17 frhb65434ds mina[12902]: Cannot open file: B62......

Edit: oh, I realised it should be a path to the key, not the key itself! However, is it okay to use --uptime-submitter-pubkey with a key itself (B62...)? Seems like it's working this way...

[lk86]

yes its ok to use --uptime-submitter-pubkey with the public key, but some folks reported issues with keys that are "imported" this way for long periods of time, so we have introduced the --uptime-submitter-key </path/to/private/key> method. Thank you for pointing this out as there was an issue in the first paragraph which has now been fixed.

[kakashi0x0]

--stop-time 25 returns Stopping daemon after 1560 mins and when there are no blocks to be produced = 26 hrs
--stop-time 30 returns Stopping daemon after 1860 mins and when there are no blocks to be produced = 31 hrs

is this supposed to be +1 hr?

[GistKen]

I had a block producer running and it went offline after 23 hours. It did not recover and I had to manually restart the service. The dump I performed is 203MB so I cannot attach the entire dump file. Is there a specific file preferred?