Running Mina Berkeley Node

Mar 08, 2024

By Naamah (naamah8064 on Discord)

The reason I wrote this article is I wanted to test deploying a node on the Berkeley network to test ZkApps. So I went to the Berkeley RC1 release note here : https://github.com/MinaProtocol/mina/releases/tag/2.0.0berkeley\_rc1 and start following installation guide.

Things didn’t go as expected. At the end of the Berkeley Docker installation process, I tried to launch the mina container that immediately exited with an error.

2024-02-20 09:58:08 [ERROR] Entrypoint script /entrypoint.d/. is not a regular file, ignoring
2024-02-20 09:58:08 [ERROR] Entrypoint script /entrypoint.d/.. is not a regular file, ignoring
2024-02-20 09:58:18 Mina process exited with status code 1

Trying to find the reason, I ended up with an alternative solution that made things much more straightforward to have my node up and running. This is not a “conventionnal” way of using docker as it implies using a different container entry point but it works (many people with the same problem on the official mina discord channel were able to run a berkeley node following my instructions.)

Let’s start …

Configuration

All those steps have been performed using a Docker installation w/ WSL2 on a windows 11 computer

STEP 1 – Pull latest docker image

$ docker pull gcr.io/o1labs-192920/mina-daemon:2.0.0berkeley-rc1-1551e2f-focal-berkeley
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE minaprotocol/mina-daemon 2.0.0berkeley-rc1-1551e2f-focal-berkeley 353043fd4878 2 weeks ago 2.41GB

You can also user Docker Desktop GUI to pull the docker image

STEP 2 – Create your `keys` and `config` directories on the host

$ mkdir keys
$ mkdir config

STEP 3 – Getting an interactive bash session to the container

$ docker run –name mina -p 9302:8302 -p 127.0.0.1:3085:3085 –mount “type=bind,source=$(pwd)/keys,dst=/root/keys” –mount “type=bind,source=$(pwd)/config,dst=/root/.mina-config” –env MINA_LIBP2P_PASS=’pass’ –env MINA_PRIVKEY_PASS=’pass’ –env UPTIME_PRIVKEY_PASS=’pass’ –entrypoint /bin/bash -it 353043fd4878

Map keys and config directory from the host to the target container.

Set your env variables MINA_LIBP2P_PASS, MINA_PRIVKEY_PASS (optional if you want to run a bloc producer) and UPTIME_PRIVKEY_PASS (not required/useless on berkeley)

353043fd4878 is your image id.

STEP 4 – Generating libp2p keypair

Once inside your container, you now have access to the shell. We’ll use this to generate the libp2p key pair inside the `/root/keys` directory :

root@09437a971acb:~# mina libp2p generate-keypair -privkey-path /root/keys/libp2p Password for new private key file:
Again to confirm:
libp2p keypair:
CAESQFGW4XhXBHPsGf…

Put the same password as the one you specify above for MINA_LIBP2P_PASS environment variable

STEP 5 – Generating BP keys Then we’ll generate the BP key (if needed) :

root@b8244db5dff8:~# mina-generate-keypair –privkey-path /root/keys/my-wallet
Password for new private key file:
Again to confirm:
Keypair generated
Public key: B62…
Raw public key: 63B…

Put the same password as the one you specify above for MINA_PRIVKEY_PASS environment variable

File permission Ensure that your keys have the correct file permission (`chmod 600`) :

root@156a3593fdf3:~# ls -l ~/keys total 16
-rw——- 1 root root 483 Feb 18 04:01 libp2p
-rw-r–r– 1 root root 53 Feb 18 04:01 libp2p.peerid
-rwx—— 1 root root 263 Feb 18 02:50 my-wallet
-rwx—— 1 root root 56 Feb 18 02:50 my-wallet.pub

STEP 6 – Launch Mina Daemon

root@b8244db5dff8:~# mina daemon –peer-list-url https://storage.googleapis.com/seed-lists/berkeley\_seeds.txt –libp2p-keypair ~/keys/libp2p –block-producer-key /root/keys/my-wallet –insecure-rest-server –open-limited-graphql-port –limited-graphql-port 3095 –file-log-level Debug -log-level Info

Once inside the container, pressing Ctrl + p, Ctrl + q will detach you from the container’s console and leave the container running in the background.

You’ll be able to reattach to you running mina container using :

$ docker attach mina

Launch intercative shell session again and check mina daemon status

You can launch an additionnal interactive session again to interact with mina daemon if needed :

$ docker exec -it mina /bin/bash

Then you can get the status of you mina daemon and guess what ? It is synced !!

root@156a3593fdf3:~# mina client status Mina daemon status ———————————–

Global number of accounts: 8181
Block height: 4285
Max observed block height: 4285
Max observed unvalidated block height: 4285
Local uptime: 26m32s

Ledger Merkle root: jwi4sfjSY6JYKrjaL2wUUhYb6t7Ra5p5JhiMdznNFxbSPFZoN4W
Protocol state hash: 3NLwovdQsqLfz8qHFrqbuLx7u4KccdbD94S65pKrw6tVVgHWkbkb
Chain id: fd7d111973bf5a9e3e87384f560fdead2f272589ca00b6d9e357fca9839631da
Git SHA-1: 1551e2faaa246c01636908aabe5f7981715a10f4

Configuration directory: /root/.mina-config
Peers: 14
User_commands sent: 0
SNARK worker: None
SNARK work fee: 100000000
Sync status: Synced
Catchup status:
To build breadcrumb: 0
To initial validate: 0
Finished: 293
To download: 0
Waiting for parent to finish: 0
To verify: 0
Block producers running: 1 (B62…)
Coinbase receiver:
Block producer
Best tip consensus time: epoch=1, slot=359
Best tip global slot (across all hard-forks): 7499
Next block will be produced in: None this epoch… checking at in 14.125d (Generated from consensus at slot: 6970 slot-since-genesis: 6970)
Consensus time now: epoch=1, slot=359
Consensus mechanism: proof_of_stake
Consensus configuration:
Delta: 0
k: 290
Slots per epoch: 7140
Slot duration: 3m
Epoch duration: 14d21h
Chain start timestamp: 2024-02-02 14:01:01.000000Z
Acceptable network delay: 3m
Addresses and ports:
External IP: 0.0.0.0
Bind IP: 0.0.0.0
Libp2p PeerID: 12D…
Libp2p port: 8302
Client port: 8301
Metrics:
block_production_delay: 7 (0 0 0 0 0 0 0) transaction_pool_diff_received: 48
transaction_pool_diff_broadcasted: 0
transactions_added_to_pool: 24
transaction_pool_size: 6
snark_pool_diff_received: 41
snark_pool_diff_broadcasted: 0
pending_snark_work: 0
snark_pool_size: 18