Skip to content

Instantly share code, notes, and snippets.

@duccas
Forked from lk86/qa-steps-12-14-2020-4.1-beta11.md
Last active November 11, 2020 14:27
Show Gist options
  • Save duccas/b8bcddea325a580d5044408945b44b14 to your computer and use it in GitHub Desktop.
Save duccas/b8bcddea325a580d5044408945b44b14 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

Running a node with Docker:

  • The easiest solution for connecting to our public qa-net "pickles-public" is to use the pre-baked docker image minaprotocol/mina-daemon-baked:pickles-public 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. Run the image with your keys and ~/.coda-config mounted:
docker run --name mina -d \
-p 8301-8305:8301-8305 \
-v /root/keys:/root/keys:ro
-v /root/coda-config:/root/.coda-config \
minaprotocol/mina-daemon-baked:pickles-public-minaccdb0c8-auto3ee47ed0 daemon \
-config-file /root/daemon.json \
-peer-list-file /root/peers.txt \
-block-producer-key root/keys/my-wallet \
-block-producer-password "YOUR PASSWORD HERE" \
-insecure-rest-server \
-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 monittor 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, 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 unstable 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. If you have run a daemon before, remove the old epoch ledger as a new one will be generated for the new chain rm ~/.coda-config/epoch_ledger.json
  8. sudo apt-get install -y curl mina-testnet-postake-medium-curves=0.0.16-beta7+-develop-ccbd0c8 --allow-downgrades
  9. wget -O ~/daemon.json https://raw.githubusercontent.com/MinaProtocol/coda-automation/master/terraform/testnets/pickles-public/genesis_ledger.json The "genesis_state_timestamp" on line 2 of ~/daemon.json should read "2020-11-07T06:00:10Z".
  10. wget -O ~/pickles-public-peers.txt https://raw.githubusercontent.com/MinaProtocol/coda-automation/master/terraform/testnets/pickles-public/peers.txt
  11. 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.
  12. export CODA_PRIVKEY_PASS=<private key password> where <private key password> is the password to your private key.
  13. coda daemon -peer-list ~/pickles-public-peers.txt -config-file ~/daemon.json -generate-genesis-proof true -log-json -log-level Debug -block-producer-key "${KEYPATH}" | coda-logproc | tee ~/coda-log.txt
  14. After your node is synced to the network, run Coda Client Status and post the output on the qa-task-force Discord channel
  15. 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-log.txt, 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, coda client status > status.log, and details on the platform you’re using in the Share Message note)
  16. Post any issues to github. Please include your coda-log.txt, 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.
@duccas
Copy link
Author

duccas commented Nov 11, 2020

With the mount from your docker guide, I was unable to start. Constantly issued:

invalid argument "/root/.coda-config,dst=/root/.coda-config" for "--mount" flag: invalid field '/root/.coda-config' must be a key=value pair

I changed:
--mount "type=bind,source=pwd/mina-keys,dst=/keys,readonly" \
--mount "pwd/.coda-config,dst=/root/.coda-config" \
to
-v /root/keys:/root/keys:ro
-v /root/coda-config:/root/.coda-config \

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment