Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save imeckler/510f5eed2a2b99ec1e2847ba289feca0 to your computer and use it in GitHub Desktop.
Save imeckler/510f5eed2a2b99ec1e2847ba289feca0 to your computer and use it in GitHub Desktop.

Note: If you haven't already added your qanet public address to our Google Sheet, please go ahead and add it using the link below. Only public addresses listed in this doc will receive public qanet tokens for testing. If you added your public address while a public qanet is running, you will have to wait until the next release to receive your tokens. Alternatively, you can ask the community members in the qa-task-force channel to send you some tokens now. Link to the Google sheet: https://docs.google.com/spreadsheets/d/15YT8DALkufDAxiYzT9dx-eW-JALjZTt-9H9ZqtvLPm0/edit?usp=sharing

If you ran a node before the hardfork:

  • run coda client stop-daemon (or docker exec -it mina coda client stop-daemon) to gracefully shut down your existing node
  • move any log files or keys (especially ~/.coda-config/coda.log and ~/.coda-config/wallet) to a new location for backup. Please send us your ~/.coda-config/mina-best-tip.log as well so that we can validate our chosen "best tip" for the new chain after the fork.
  • Once log files are safely stored elsewhere / emailed to logs@o1labs.org, run rm -rf ~/.coda-config to clear our your coda config directory, as most files there will not be valid post-fork.
  • Continue to the "running a node" sections below for Docker or baremetal.

Running a node with Docker:

  • The easiest solution for connecting to our public qa-net "turbo-pickles" is to use the pre-baked docker image minaprotocol/mina-daemon-baked which includes the files up to step 10 of the "Running a node in a VPS or Linux Machine" and is not limited to Debian/Ubuntu.
  1. Copy your public/private key files (usually ~/keys/my-wallet and ~/keys/my-wallet.pub) to ~/mina-keys/
  2. cd ~ && chmod 700 ~/mina-keys/my-wallet
  3. Download the latest peers list file to ~/peers.txt wget -O ~/peers.txt https://raw.githubusercontent.com/MinaProtocol/coda-automation/master/terraform/testnets/turbo-pickles/peers.txt
  4. Run the image with your keys, peers.txt, and ~/.coda-config mounted:
docker run --name mina -d \
-p 8301-8305:8301-8305 \
--restart=always \
--mount "type=bind,source=`pwd`/mina-keys,dst=/keys,readonly" \
--mount "type=bind,source=`pwd`/.coda-config,dst=/root/.coda-config" \
--mount type=bind,source="`pwd`/peers.txt,dst=/root/peers.txt",readonly \
-e CODA_PRIVKEY_PASS="YOUR PASSWORD" \
codaprotocol/coda-daemon-baked:0.1.1-41db206-turbo-pickles-534f712 daemon \
-peer-list-file /root/peers.txt \
-block-producer-key /keys/my-wallet \
-insecure-rest-server \
-file-log-level Debug \
-log-level Info
  1. Run docker logs -f mina to follow the logs, and if it crashes save the log output to a file with docker logs mina > mina-log.txt and post the output to the #qa-task-force channel or attach the full log to a github issue and link the issue in discord.
  2. Run docker exec -it mina coda client status to monitor connectivity to the network, you should quickly find at least 10 peers and watch the block height / max observed block height climb. If not, post the output of this command on the qa-task-force Discord channel and someone will help diagnose issues.
  3. Send us logs (with docker logs mina > mina-log.txt) shortly after connecting (~1hr) and after the node has been running a while (~24hr) if you can. Send your discord username, coda-log.txt, docker exec -it mina coda client status > status.log, and details on the platform you’re using via email to logs@o1labs.org. If the log file is too big, either compress it before attaching to your email or upload it to Google Drive and share the file with logs@o1labs.org (include your discord name, status.log, and details on the platform you’re using in the Share Message note)
  4. Post any issues to github. Please include your mina-log.txt, status.log,~/.coda-config/coda.log, details on your platfrom, and a printout of coda client status to the issue. If an issue exists already, please add your above information to the issue

Running a node in a VPS or Linux Machine:

  1. Run the following commands on a Debian:stretch or Ubuntu:18.04 image
  2. sudo apt-get update
  3. sudo apt-get install -y apt-transport-https ca-certificates
  4. echo "deb [trusted=yes] http://packages.o1test.net release main" | sudo tee /etc/apt/sources.list.d/coda.list
  5. sudo apt-get update
  6. If you have installed the coda daemon before, remove the old coda package so that it does not conflict with the new mina package sudo apt-get remove -y coda-testnet-postake-medium-curves
  7. sudo apt-get install -y curl mina-testnet-postake-medium-curves=0.1.1-41db206 --allow-downgrades
  8. wget -O ~/peers.txt https://raw.githubusercontent.com/MinaProtocol/coda-automation/master/terraform/testnets/turbo-pickles/peers.txt
  9. export KEYPATH=<keypath> where <keypath> is the full path to your private key file. If you submitted a public key to the excel spreadsheet for stake on the new network, then make sure to use the private key file corresponding to that public key.
  10. Use the new mina systemd service to keep the node running more easily.
  • systemctl --user daemon-reload
  • make a file ~/.mina-env containing the following two lines, replacing "your password here" with the password for ~/keys/my-wallet and adding any extra flags for the daemon you may want or need, like -external-ip or snark work flags:
CODA_PRIVKEY_PASS="your password here"
EXTRA_FLAGS=" -file-log-level Debug "
  • systemctl --user start mina
  • systemctl --user status mina to see weather or not the daemon is running successfully, systemctl --user stop mina to stop the daemon, systemctl --user restart mina to restart the daemon, and journalctl --user -u mina -n 1000 -f to see the last 1000 log lines and keep following from there.
  • coda client status and other client commands will work as normal.
  1. After your node is synced to the network, run Coda Client Status and post the output on the qa-task-force Discord channel
  2. Send us logs shortly after connecting (~1hr) and after the node has been running a while (~24hr) if you can. Send your discord username, .coda-config/coda.log, coda client status > status.log, and details on the platform you’re using via email to logs@o1labs.org. If the log file is too big, either tail -n 10000 .coda-config/coda.log to extract the last 10,000 lines or upload the full file to Google Drive and share the file with logs@o1labs.org (include your discord name, coda client status > status.log, and details on the platform you’re using in the Share Message note)
  3. Post any issues to github. Please include your coda.log, details on your platfrom, and a printout of coda client status to the issue. If an issue exists already, please add your above information to the issue

Issue priority labels:

  • Critical: Anything that stops a node from connecting to the network. For example, if a node crashes, is unable to sync, or is unable to connect to peers.
  • High: Anything that doesn’t stop a node from syncing, but causes bad functionality of other features. For example, anything to do with connectivity that doesn’t break connectivity, or some transaction types not working as expected.
  • Medium: Unintended behavior that does not break nodes or features. For example bad logging or error handling.
  • Low: Convenience improvements

Hardware Requirements:

Sending and receiving mina does not require any special hardware, but running a block producer on the Mina network currently requires:

  • at least an 8-core processor
  • at least 12GB of RAM

Note that if you plan on running a snark worker node, you may need more RAM -- 16GB is recommended. GPUs aren't currently required, but may be required for node operators when the protoctol is upgraded.

Network: At least 1 Mbps connection

VM Instances: O(1) Labs has tested running nodes on several cloud providers, and recommends the following instances for basic node operator needs. Keep in mind that custom requirements as well as different cost constraints may require a different instance type.

To learn more about our hardware requirements, visit https://minaprotocol.com/docs/getting-started

Latest updates included in the recent release

  • New Snark
  • Time locked accounts
  • Updated network paramters
  • Bug fixes

Tests:

  • Disabled tokens: we have hid ability to create new tokens and send them behind a feature flags. Test to make sure tokens are disabled. Note: you will notice a crash when you try to create a token. This is a known issue and we will replace the crash with a friendly message in the next update.
  • Disabled snapps: we have hid snapps behind a feature flags. Test to make sure snapps are disabled as expected
  • Time Locked Accounts: You will notice your time locked account configuration in the Google Sheet. You are invited to get creative and find bugs that might exist. Here are ideas you can explore for testing:
  1. different amounts of payments before the cliff, after the cliff, before full vesting and after full vesting
  2. testing to confirm minimum balance works and becomes 0
  3. ensuring that you are receiving the correct amount of coinbase. Note that time locked accounts receive half the coinbase as unlocked accounts. You can learn more about time-locked accounts behere https://github.com/MinaProtocol/mina/blob/develop/rfcs/0025-time-locked-accounts.md and here MinaProtocol/mina#5753
    You can determine the correct balance of a time locked account using this interactive script https://repl.it/@garethtdavies/Mina-Time-Locked-Accounts

Notes:

  • You will notice that your node is stuck at synced at block height 1 until the network produces a new block. This is a known issue and will be addressed in the future releases
  • The log files will contain errors such as "Coda_net2: failed to parse log line from helper stderr " and variants of "Libp2p_helper.Go.addrutil: adding resolved addr:/ip4/0.0.0.0/tcp/8302". These are expected and will be addressed in the future releases
  • You might see the following errors in your log file. These are known errors and can be ignored:
  1. Genesis_ledger_helper can't find keys error messages: These can be ignored unless your build actually crashes immediately afterwards. Why is this happening? We want to see the errors.
  2. All of the libp2p errors: We need to go back and be more careful about hiding some of these messages as they look a lot scarier than they are. But for now, you can ignore them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment