How-To: Run the miden-node and miden-faucet on a remote instance

[phklive]

Hello, following is the process that I use to setup the miden-node and miden-faucet on a remote instance:

1. Setup the instance, connect to it and make sure everything is up to date by running sudo apt update -y && sudo apt upgrade -y
2. Use the following command to install the miden-node and miden-faucet locally: cargo install miden-node miden-faucet
3. Clone the miden-node repo from github: https://github.com/0xPolygonMiden/miden-node
4. Now you should be able to run miden-node and miden-faucet in your terminal as they are now executable processes in your path
5. We now need to update systemd and add 2 processes miden-node and miden-faucet use sudo touch /etc/systemd/system/miden-node.service and sudo touch /etc/systemd/system/miden-faucet.service (code should be provided)
6. We will now need to add the configuration files for the miden-node and faucet using mkdir /etc/miden/ and after going back to the miden-node folder, do cp config/miden-node.toml /etc/miden/ and cp config/miden-faucet.toml /etc/miden/ and cp config/genesis.toml /etc/miden/
7. Configure the miden-node.toml, miden-faucet.toml and genesis.toml files to will
8. in your home directory create a miden folder using mkdir miden it will contain all the runtime files for the miden-node and faucet
9. cd into the miden folder and run miden-node make-genesis --inputs-path /etc/miden/genesis.toml
10. To be able to serve the static files for the miden-faucet you should use the following command (still in the miden folder) mkdir -p bin/faucet/src/ then you should use cp -r ../miden-node/bin/faucet/src/static bin/faucet/src
11. You should now restart the systemd deamon using sudo systemctl daemon-reload.
12. You should now be able to enable and start both the miden-node and miden-faucet processes sudo systemctl enable miden-node.service && sudo systemctl enable miden-faucet.service and sudo systemctl start miden-node.service and sudo systemctl start miden-faucet.service
13. This will start the miden-node on port 0.0.0.0:8080 and the miden-faucet on 0.0.0.0:80.
14. To make sure that the miden-faucet website is accessible make sure to install nginx and setup a reverse proxy enabling the serving on the miden-faucet website for the end user
15. enjoy.

Hope that you we're able to replicate, if anything please drop a question.

[Dominik1999]

Can you change the description to installing the node and faucet from crates.io? We want to set up a CD pipeline for new releases on crates.io

[phklive]

Sure thing, done.

[phklive]

The only problem is that the static folder and the config files are contained in the miden-node repo on GH hence we still need to clone the repo or download the files manually.

[Dominik1999]

Did you test those exact steps? If so, for which target architecture?

[phklive]

These are the steps I used to setup the remote nodes for the Testnet.

I tried to make as detailed as possible. It would be great if someone could try them and let me know at each step of the way if something should be added for more clarity or if they have any questions.

This has been done on an AWS remote machine running Ubuntu.

[sshrihar]

Can we remove the requirement from Step 3 to clone the repository and provide the required config files as part of the package downloaded in step 2.

[phklive]

To the extent of my knowledge we are not able to add config files to crates.io.

But we could add a CLI command to the miden-node and miden-faucet like init that would setup all the correct config files with defaults.

See Miden client: https://github.com/0xPolygonMiden/miden-client

[bobbinth]

Yeah - I think it would be nice to add miden-node init and miden-faucet init commands. Let's create an issue for this.

[phklive]

Created: #385

[Mirko-von-Leipzig]

Issues I encountered while trying to follow the guide:

1. Unclear what the expected outcome is. An overview of the end-goal would be useful. e.g. systemd services for a node and a faucet, each with their own databases. It was also unclear whether the faucet would create a faucet account on launch, or whether genesis should have the account "pre-loaded". In the end the answer was simple, but when one is unsure then these questions make it difficult to know where to debug.
2. testing feature isn't mentioned but should be enabled
3. Configuration files should explain what the properties are for. This should include the systemd files which didn't quite match my expectations. Mostly this would just prevent some of my confusion so maybe this isn't actually necessary.
4. Existing systemd configuration deleted the storage file on startup. This probably confused me the most. I'm still unsure why this was there - probably related to some bug/hack-around of the faucet on startup. This caused the faucet to never startup as there was no storage file, causing the script to fail.
5. The faucet's static webpage must be edited to point to the reverse proxy url instead of localhost. Ideally we would not need to configure this at all, but the page should determine the servers url automatically.

Overall I was fairly close to getting it working, but the uncertainty of what was happening exactly also led me astray.

[Mirko-von-Leipzig]

Some other thoughts that came to mind (this is probably the wrong place for these)

1. Faucet binary could handle deployment of faucet account to the network. afaict right now the faucet account is part of the genesis block config instead? Maybe I'm wrong though; my understanding of the code is still quite superficial.
2. testing feature could be removed by moving PoW difficulty from base up to a constant in the node binary, and then also make this difficulty queriable via RPC for use by clients, faucets etc. This has some knock-on affects, and maybe we don't want this to make it difficult to misconfigure a network.
3. Default config strings for databases should include indication of which component they're for e.g. node-storage.sqlite, faucet-storage.sqlite.

[bobbinth]

Great feedback! Let's create an issue for improving the deployment process. Ideally, we'd end up with just a couple of shell scripts which can be run to deploy both node and faucet (we now have init commands introduced in #392 which should make things a bit simpler).

Also, I think we should cover two scenarios:

1. Installing everything from crates.io - this would be used for the testnet server. In the future, this should be triggered automatically when we create a new tag in the repo.
2. Installing from Github - this would be used for the devnet server. In the future, this would be triggered automatically whenever something is merged into the next branch.

Faucet binary could handle deployment of faucet account to the network. afaict right now the faucet account is part of the genesis block config instead? Maybe I'm wrong though; my understanding of the code is still quite superficial.

This could work now, but may break in the future when we introduce fees. The reason is that recording an account on-chain requires a transaction, which would require fees - and so we may run into a chicken-and-egg problem. It may be solvable in other ways, but keeping the faucet in the genesis is probably a simpler solution.

testing feature could be removed by moving PoW difficulty from base up to a constant in the node binary, and then also make this difficulty queriable via RPC for use by clients, faucets etc. This has some knock-on affects, and maybe we don't want this to make it difficult to misconfigure a network.

The PoW difficulty here is related to generating new account IDs which is done in miden-base (for context see 0xMiden/protocol#140, thought its a long read). This difficulty is controlled in miden-base based on whether the testing feature is enabled (the main reason for this is that we need to perform some actions in the build script to lower PoW). So, basically, when we want to have reduced difficulty, we need to import miden-base with testing feature enabled. Not sure how this can be achieved with the constant - but maybe I'm misunderstanding something?

[Mirko-von-Leipzig]

The PoW difficulty here is related to generating new account IDs which is done in miden-base (for context see 0xMiden/protocol#140, thought its a long read). This difficulty is controlled in miden-base based on whether the testing feature is enabled (the main reason for this is that we need to perform some actions in the build script to lower PoW). So, basically, when we want to have reduced difficulty, we need to import miden-base with testing feature enabled. Not sure how this can be achieved with the constant - but maybe I'm misunderstanding something?

Understood; what I was proposing is changing this function signature

// Current
fn validate_seed_digest(digest: &Digest)

// Suggested
fn validate_seed_digest(digest: &Digest, required_zeros: u32)

// Or with two hardcoded options
fn validate_testing_seed_digest(digest: &Digest)
fn validate_production_seed_digest(digest: &Digest)

essentially moving the configuration from compile time feature selection to program/runtime. Which I know is usually the opposite to what one wants however in this case it removes a configuration knob which is often good.

Callers can then decide what difficulty they want programmatically instead of via feature selection e.g. by adding a --mode testnet to the various binaries. Or conversely, --mode production to disable it until the default should change.

Though I care less about this now that I know about it :)

[bobbinth]

The main issue here is that we PoW checking logic needs to be adjusted not only on the Rust side of things but also in the transaction kernel (which is written in Miden assembly). The build script does something very hacky currently - it basically rewrites the MASM file to lower PoW (i.e., here). Making MASM script more flexible is certainly possible - but it is quite a bit more work and I'm not sure it is worth it (at least for now). At some point though, we need to find a better solution to this structure, and maybe what you are suggesting above, propagated to the MASM script, is the way to go.