diff --git a/.vscode/settings.json b/.vscode/settings.json index 2accb736..f0b04505 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -1,6 +1,7 @@ { "cSpell.words": [ "smesher", + "smeshing", "Smeshing", "Spacemesh" ] diff --git a/docs/start/smeshing/smeshing_adv/post_init.md b/docs/start/smeshing/smeshing_adv/post_init.md index 29943184..59382515 100644 --- a/docs/start/smeshing/smeshing_adv/post_init.md +++ b/docs/start/smeshing/smeshing_adv/post_init.md @@ -5,41 +5,27 @@ title: PoST Initialization ## Proof Generation -Once an epoch, after the node has received a PoET proof and during the PoET cycle gap, the node will generate a -[proof of spacetime](#proof-generation), which requires that it sequentially read all of the PoST data. The details -aren't something most miners need to worry about as the node will handle the process for you; see +Once per epoch, after the node has received a PoET and the PoET cycle gap is underway, the node will generate a +[PoST](../../../learn/post.md), which requires that it sequentially read all of the PoST data. The details +are not something most smeshers need to worry about as the node will handle the process for you. See [Fine-tuning Node Performance](./performance.md) for information on benchmarks and parameters that can be tweaked. -The first part of the proving process is an initial proof of work phase called **k2pow** that uses a proof of work -algorithm called [RandomX](https://github.com/tevador/RandomX). During this phase, which is CPU bound, you should see -CPU usage spike briefly for a few minutes. There should be very little network or disk activity during this phase. As -explained in the [Profiler docs](https://github.com/spacemeshos/post-rs/blob/main/docs/profiler.md#is-that-all-that-is-happening-during-the-proof-generation), -it should take a low-end CPU around 2.5 minutes to compute k2pow for 4 SU; computation time scales linearly with the -hash rate and number of storage units being proven. See the [RandomX Benchmark](https://xmrig.com/benchmark) to get a -sense of your CPU's RandomX hash rate. +The first part of the proving process is an initial proof-of-work phase called **k2pow** that uses a proof of work algorithm called [RandomX](https://github.com/tevador/RandomX). During this phase, which is CPU bound, you should see CPU usage spike briefly for a few minutes with there being very little network or disk activity. As explained in the [Profiler docs](https://github.com/spacemeshos/post-rs/blob/main/docs/profiler.md#is-that-all-that-is-happening-during-the-proof-generation), it should take a low-end CPU around 2.5 minutes to compute k2pow for 4 SUs. The computation time scales linearly with the hash rate and number of storage units being proven. See the [RandomX Benchmark](https://xmrig.com/benchmark) to get a sense of your CPU's RandomX hash rate. -Once the k2pow phase is complete, the node begins the PoST proving process, which takes longer as it involves reading -and computing a hash function over all the committed PoST data. How long depends on factors including the disk read -speed, CPU speed, and configured [nonces and threads](./advanced.md#fine-tuning-proving). This process may be CPU bound -or IO bound, depending on the configuration. (It also doesn't touch the network.) +Once the k2pow phase is complete, the node begins the PoST proving process, which takes longer as it involves reading and computing a hash function over all the committed PoST data. The duration of the proving depends on factors including the disk read +speed, CPU speed, and configured [nonces and threads](./advanced.md#fine-tuning-proving). This process may be CPU bound or IO bound, depending on the configuration. (This phase does not use the network.) ## Initialization -The most important part of becoming a smesher is the PoST initialization (sometimes referred to as -"plotting"). This process requires a GPU and is designed to be costly and time-consuming due to the crypto-economic -design of the protocol. As described above, unlike in proof of stake networks, there's no "slashing" (burning a portion -of stake) in the Spacemesh protocol. Instead, the sanction for engaging in malicious behavior such as equivocation is -invalidation of a smesher ID, which invalidates all of the PoST data associated with that ID. In order for this sanction +The most important part of becoming a smesher is the PoST initialization (sometimes referred to as "PoS initialization" or "plotting"). This process requires a GPU and is designed to be costly and time-consuming due to the crypto-economic design of the protocol. As described above, unlike in proof-of-stake networks, there is no "slashing" (burning a portion +of stake) in the Spacemesh protocol. Instead, the sanction for engaging in malicious behavior such as equivocation is the invalidation of a smesher ID which, in turn, invalidates all of the PoST data associated with that ID. In order for this sanction to be costly, performing PoST initialization and generating PoST data must also be costly. -Note that initialization can theoretically be performed using a CPU (as opposed to a GPU), but it will take so long that -this option isn't viable for the vast majority of miners. +Note that initialization can theoretically be performed using a CPU (as opposed to a GPU), but it will take so long that this option is not viable for the vast majority of miners. ### OpenCL -PoST initialization requires support for [OpenCL](https://en.wikipedia.org/wiki/OpenCL). Installation instructions will -vary depending upon your operating system, platform, and GPU hardware. A good starting place for Linux users is -[this wiki page](https://wiki.archlinux.org/title/GPGPU). On Ubuntu and other Debian-compatible systems it may be enough +PoST initialization requires support for [OpenCL](https://en.wikipedia.org/wiki/OpenCL). Installation instructions will vary depending upon your operating system, platform, and GPU hardware. A good starting place for Linux users is [this wiki page](https://wiki.archlinux.org/title/GPGPU). On Ubuntu and other Debian-compatible systems, it may be enough to install these packages: ```bash @@ -47,8 +33,7 @@ to install these packages: > sudo apt-get install ocl-icd-libopencl1 opencl-headers clinfo ``` -To test if OpenCL is installed and configured correctly on your system, try running `clinfo`. You should see output -similar to the following: +To test if OpenCL is installed and configured correctly on your system, try running `clinfo`. You should see output similar to the following: ```bash > clinfo -l @@ -58,23 +43,16 @@ Platform #0: NVIDIA CUDA #### macOS Overview -For macOS users, OpenCL is bundled with the system, and the framework is available out of the box on macOS version 10.6 -(Snow Leopard) and later. Therefore, explicit installation of OpenCL is generally not required. However, to ensure -compatibility and optimal performance with your specific hardware and software setup, you might need to update your -macOS. +For macOS users, OpenCL is bundled with the system and the framework is available out of the box on macOS version 10.6 (Snow Leopard) and later. Therefore, explicit installation of OpenCL is generally not required. However, to ensure compatibility and optimal performance with your specific hardware and software setup, you might need to update your macOS. ##### Steps -* Update macOS: Keep your macOS up to date to ensure you have the latest OpenCL framework versions and GPU drivers. - You can check for updates in the “Software Update” section of System Preferences. -* Use clinfo: To verify the OpenCL configuration, you can install `clinfo` using the command `brew install clinfo`. - Then, run `clinfo` in the terminal to check the available OpenCL platforms and devices. +* **Update macOS**: Keep your macOS up to date to ensure that you have the latest OpenCL framework versions and GPU drivers. You can check for updates in the “Software Update” section of System Preferences. +* **Use `clinfo`**: To verify the OpenCL configuration, you can install `clinfo` using the command `brew install clinfo`. Then, run `clinfo` in the terminal to check the available OpenCL platforms and devices. -#### Windows Installation Overview +#### Windows Overview -Installing OpenCL on Windows requires manual GPU drivers updates, as the operating system does not include these drivers -by default. The process is similar across different GPU manufacturers but requires visiting the specific manufacturer’s -website to download the appropriate drivers. +Installing OpenCL on Windows requires manual GPU drivers updates as the operating system does not include these drivers by default. The process is similar across different GPU manufacturers but requires visiting the specific manufacturer’s website to download the appropriate drivers. ##### Steps diff --git a/docs/start/smeshing/smeshing_adv/setup.md b/docs/start/smeshing/smeshing_adv/setup.md index 50a82b51..879230ed 100644 --- a/docs/start/smeshing/smeshing_adv/setup.md +++ b/docs/start/smeshing/smeshing_adv/setup.md @@ -1,19 +1,23 @@ --- id: setup -title: Advanced Setup +title: Advanced Smeshing Guide --- -Now that you have the necessary resources ready, it is time to start smeshing! This section will walk you through how to do that. First, a couple of quick notes: -- This guide is intended as an advanced smeshing guide, covering cases such as parallel init, cloud GPUs, and transferring and managing multiple identities. In particular it does not cover the baseline case of using Smapp to initialize a single smesher. That process is straightforward and mostly automated in Smapp, and the steps are outlined in this explainer video. The guide does explain the differences between mining using Smapp or the CLI where appropriate. +Welcome to the advanced smeshing guide! As you can tell from the title, this guide is for the advanced smeshers who want more fine-grain control of the smeshing process. For non-tech-savvy users, we recommend following the [basic smeshing guide](../smeshing_basic/setup.md). If this is your first visit to the docs website, we recommend starting from the [beginning](../start.md) to fully understand smeshing and its requirements. Then, you can choose if you want to follow the basic or the advanced smeshing guide. Lastly, please make sure that your system meets the [minimum requirements](../../smeshing/requirements.md). -- This guide uses Linux. So, all the commands are for a Linux terminal, and should be the same for most UNIX-based systems. In most cases, the same commands should work verbatim on other platforms including Windows and macOS with appropriate tweaks (e.g., using the correct platform-specific paths). Contributions containing correct instructions for different platforms are welcome. Feel free to open an issue with a contribution. +## Getting Started -- In order to smesh one must have a fully synchronized Spacemesh node running. Strictly speaking, running a node is not required during the PoST initialization process, since it relies only upon static data (with one exception, explained in a moment) such as the smesher's identity and the PoST init params (total storage to initialize, max file size, etc.). Most smeshers nevertheless choose to run a full node throughout the init process for several reasons: the node itself can perform the initialization for you, it means you will have a fully-synchronized node when the init finishes and smeshing begins (with the opportunity to troubleshoot any issues in the interim), and it means you will have a trustless copy of the highest `commitmentAtxId`. +To get started with the advanced smeshing guide, please make note of the following points: + +- This guide is intended as an advanced smeshing guide, covering cases such as [parallel PoST initialization](#parallel-initialization), [cloud GPUs](./advanced.md#cloud-gpu), and transferring and [managing multiple identities](./advanced.md#multiple-identities). However, this guide does not cover using Smapp to initialize a singular smeshing node. That process is straightforward and mostly automated in Smapp, and has been explained in the [basic smeshing guide](../smeshing_basic/setup.md) section. + +- This guide uses Linux. As such, all the commands are for a Linux terminal and should be the same for most UNIX-based systems. In most cases, the same commands should work verbatim on other platforms including Windows and macOS with appropriate tweaks (e.g., using the correct platform-specific paths). Contributions containing correct instructions for different platforms are welcome. Feel free to open an issue with a contribution. + +- In order to smesh, one must have a fully synchronized Spacemesh node running. Strictly speaking, running a node is not required during the PoST initialization process, since it relies only upon static data (with one exception, explained below) such as the smesher's identity and the PoST initialization params (total storage to initialize, max file size, etc.). Nevertheless, most smeshers choose to run a full node throughout the init process. A major reason is because the node can perform the initialization itself. This means that you will have a fully-synchronized node when the initialization finishes and smeshing begins (with the opportunity to troubleshoot any issues in the interim). This also means that you will have a trustless copy of the highest `commitmentAtxId`. ## `commitmentAtxId​` -The one piece of dynamic data that you need to perform PoST init is the highest commitmentAtxId. This is simply the ID of the highest ATX known at the time that PoST initialization begins. It is used to mitigate a certain class of protocol attack; for more information, see POPS-VRF implementation. -The simplest way to get this is to ask your own node, using the API as such: +The one piece of dynamic data that you need to perform PoST init is the highest `commitmentAtxId`. This is the ID of the highest ATX known at the time that PoST initialization begins. It is used to mitigate a certain class of protocol attacks. For more information, see the [POPS-VRF implementation](https://github.com/spacemeshos/pm/issues/172). The simplest way to get this is to ask your own node, using the API as such: ```bash > grpcurl -plaintext 127.0.0.1:9092 spacemesh.v1.ActivationService.Highest | jq -r '.atx.id.id' | base64 -d | xxd -p -c 64 @@ -22,29 +26,25 @@ The simplest way to get this is to ask your own node, using the API as such: While we plan to operate public nodes in the near future, we do not operate any at present. Therefore, we strongly encourage you to double-check this information, ideally by running your own node, or alternatively by checking with the community on Discord. -Continue reading to run your own node and start smeshing. - -## Compiling `go-spacemesh` +## Installing and Compiling `go-spacemesh` -go-spacemesh has a very limited set of dependencies and requirements, the main one being a Go toolchain. It also requires `make` and [Git Large File Storage](https://docs.github.com/en/repositories/working-with-files/managing-large-files/installing-git-large-file-storage). Make sure you have a [recent version of Go](https://go.dev/dl/) installed, clone the [go-spacemesh repository](https://github.com/spacemeshos/go-spacemesh), then run `make install`, which will install the other dependencies for you automatically. Note that this includes a compiled version of the Spacemesh PoST library, but as long as your Go toolchain is set up correctly, this should work out of the box. +`go-spacemesh` has a very limited set of dependencies and requirements, with the main one being a Go toolchain. It also requires `make` and [Git Large File Storage](https://docs.github.com/en/repositories/working-with-files/managing-large-files/installing-git-large-file-storage). Make sure you have a [recent version of Go](https://go.dev/dl/) installed, clone the [go-spacemesh repository](https://github.com/spacemeshos/go-spacemesh), then run `make install`, which will install the other dependencies for you automatically. Note that this includes a compiled version of the Spacemesh PoST library, but as long as your Go toolchain is set up correctly, this should work out of the box. You can see the minimum required version of Go in a few places including [`go.mod`](https://github.com/spacemeshos/go-spacemesh/blob/989682a9f574e9860912287634a47bb0db2d0640/go.mod#L3) and the [README](https://github.com/spacemeshos/go-spacemesh/blob/989682a9f574e9860912287634a47bb0db2d0640/README.md?plain=1#L89). -You can see the minimum required version of Go in a few places including [`go.mod`](https://github.com/spacemeshos/go-spacemesh/blob/989682a9f574e9860912287634a47bb0db2d0640/go.mod#L3) and the [README](https://github.com/spacemeshos/go-spacemesh/blob/989682a9f574e9860912287634a47bb0db2d0640/README.md?plain=1#L89). - -Assuming you intend to run your node on mainnet, **make certain that you compile using the tag that matches the [latest release](https://github.com/spacemeshos/go-spacemesh/releases)**, e.g.: +Assuming that you intend to run your node on the mainnet, **make certain that you compile using the tag that matches the [latest release](https://github.com/spacemeshos/go-spacemesh/releases)**, e.g.: ```bash -> git clone --depth 1 --branch v1.1.1 https://github.com/spacemeshos/go-spacemesh.git +> git clone --depth 1 --branch v1.7.4 https://github.com/spacemeshos/go-spacemesh.git > make install > make build ``` This builds the `go-spacemesh` binary in the `build/` directory. -For the most up to date information on compiling check the [README](https://github.com/spacemeshos/go-spacemesh#readme), [Makefile](https://github.com/spacemeshos/go-spacemesh/blob/develop/Makefile) and [Makefile-libs](https://github.com/spacemeshos/go-spacemesh/blob/develop/Makefile-libs.Inc), and the [release workflow](https://github.com/spacemeshos/go-spacemesh/blob/develop/.github/workflows/release.yml). +For the most up-to-date information on compiling `go-spacemesh`, check the [README](https://github.com/spacemeshos/go-spacemesh#readme), [Makefile](https://github.com/spacemeshos/go-spacemesh/blob/develop/Makefile), and [Makefile-libs](https://github.com/spacemeshos/go-spacemesh/blob/develop/Makefile-libs.Inc), along with the [release workflow](https://github.com/spacemeshos/go-spacemesh/blob/develop/.github/workflows/release.yml). ## Running a local Full Node -The node features a set of reasonable default parameters that should work well out of the box for most users and most use cases, but you can change all of them using command line flags and/or the config file. The exact command you use to run `go-spacemesh` will depend upon your local configuration and requirements. See the [README](https://github.com/spacemeshos/go-spacemesh#readme) and run `go-spacemesh -h` for the full list of arguments: +The node features a set of reasonable default parameters that should work well out of the box for most users and most use cases. However, you can change all of them using command line flags and/or the config file. The exact command you use to run `go-spacemesh` will depend upon your local configuration and requirements. See the [README](https://github.com/spacemeshos/go-spacemesh#readme) and run `go-spacemesh -h` for the full list of arguments: ```bash > go-spacemesh -h @@ -74,7 +74,7 @@ Flags: ... ``` -Assuming everything else is set up correctly in your config file (see next section), the only CLI flag you need is to specify the location of the config file, e.g.: +Assuming everything else is set up correctly in your config file (see the next section), the only CLI flag you need is to specify the location of the config file, e.g.: ```bash > go-spacemesh -c node-config.json @@ -82,16 +82,16 @@ Assuming everything else is set up correctly in your config file (see next secti ## Configuring the Node -The node currently does not need any config to run with mainnet. You can however request the config and override any needed value. To request the current mainnet compatible config please run: +The node currently does not need any config to run with the mainnet. However, you can request the config and override any needed value. To request the current mainnet compatible config, please run: ```bash > curl -s https://configs.spacemesh.network/networks.json | jq '.[0].conf' "https://configs.spacemesh.network/config.mainnet.json" ``` -Most users will want to start with the existing network config file as a template and add customizations to match their local environment and preferences. Note that **it's essential you not change existing config parameters unless you know what you're doing.** Some config sections, like `genesis`, must not be changed under any circumstances or **your node will not be compatible with mainnet.** Your messages will be dropped and your node may be banned by its peers. Some, like `p2p` and `smeshing`, may be tweaked by power users who know what they're doing, but can also cause problems for your node. Others such as `api` and `logging` are safe to change. When in doubt, [ask for help](https://chat.spacemesh.io)! +Most users will want to start with the existing network config file as a template and add customizations to match their local environment and preferences. Note that **it is essential you not change existing config parameters unless you know what you are doing.** Some config sections, like `genesis`, must not be changed under any circumstances or **your node will not be compatible with mainnet,** your messages will be dropped, and your node may be banned by its peers. Some, like `p2p` and `smeshing`, may be tweaked by power users who know what they are doing. Others, such as `api` and `logging`, are safe to change. When in doubt, [ask for help on our Discord server](https://chat.spacemesh.io)! -Assuming you're starting with the default network config file, you'll want to add something like the following to start smeshing: +Assuming that you are starting with the default network config file, you will want to add something like the following to start smeshing: ``` "smeshing": { @@ -109,31 +109,27 @@ Assuming you're starting with the default network config file, you'll want to ad }, ``` -For more information on choosing the `smeshing-opts` and `smeshing-proving-opts`, see [fine-tuning proving](#fine-tuning-proving), [the postcli README](https://github.com/spacemeshos/post/tree/develop/cmd/postcli) and [the profiler README](https://github.com/spacemeshos/post-rs/blob/main/docs/profiler.md), respectively, and the sections below on these topics. +For more information on choosing the `smeshing-opts` and `smeshing-proving-opts`, see [fine-tuning proving](./advanced.md#fine-tuning-proving), [the postcli README](https://github.com/spacemeshos/post/tree/develop/cmd/postcli) and [the profiler README](https://github.com/spacemeshos/post-rs/blob/main/docs/profiler.md), respectively, and the sections below on these topics. ### Collecting Rewards -The coinbase account (specified in the config, above, as `smeshing-coinbase`) is the account that will receive the rewards from smeshing. The coinbase account is fixed per smesher, per epoch, as the smesher commits to it in an ATX for an entire epoch. However, it can be changed at any time, and the change will take effect in the epoch that the next published ATX targets. Note that many smeshers can also use the same coinbase (although to do so would reduce privacy since those smeshers could be associated via the shared coinbase address), and also that there's no requirement that a smesher even provide a coinbase that they control. In theory the coinbase could be set to someone else's account, or even to a burn account. - -The simplest way to generate a coinbase account is to install and open [Smapp](https://github.com/spacemeshos/smapp/releases); it'll automatically generate a new account the first time it's opened, assuming one doesn't already exist (make sure to backup the recovery mnemonic!). - -If you prefer you can use the [`smcli` tool](https://github.com/spacemeshos/smcli) to generate and display a new Wallet containing one or more accounts from the command line. See the README in that repository for more information on the tool. +The coinbase account (specified in the config, above, as `smeshing-coinbase`) is the account that will receive the rewards from smeshing. The coinbase account is fixed per smesher, per epoch, as the smesher commits to it in an ATX for an entire epoch. However, it can be changed at any time, and the change will take effect in the epoch that the next published ATX targets. Note that many smeshers can also use the same coinbase (although to do so would reduce privacy since those smeshers could be associated via the shared coinbase address) and there is also no requirement that a smesher even provide a coinbase that they control. In theory, the coinbase could be set to someone else's account, or even to a burn account. -Either way, you should now have a Spacemesh-compatible address in bech32 format that starts with `sm1`. +The simplest way to generate a coinbase account is to install and open [Smapp](https://github.com/spacemeshos/smapp/releases). It will automatically generate a new account the first time it is run, assuming one does not already exist (make sure to back up the recovery mnemonic!). If you prefer, you can use the [`smcli` tool](https://github.com/spacemeshos/smcli) to generate and display a new Wallet containing one or more accounts from the command line. See the [README](https://github.com/spacemeshos/smcli?tab=readme-ov-file#smcli-spacemesh-command-line-interface-tool) in that repository for more information on the tool. Either way, you should now have a Spacemesh-compatible address in bech32 format that starts with `sm1`. ### Running Multiple Nodes -It is possible to run multiple `go-spacemesh` processes on a single system. This is of course subject to the [resource requirements](https://docs.spacemesh.io/docs/start/smeshing/requirements) outlined above; in particular, make sure that the system has high enough bandwidth to support many nodes. You'll need to change a few parameters to enable this: +It is possible to run multiple `go-spacemesh` processes on a single system. This is, of course, subject to the [resource requirements](https://docs.spacemesh.io/docs/start/smeshing/requirements). In particular, make sure that the system has high enough bandwidth to support many nodes. You will need to change a few parameters to enable running multiple nodes: -1. Node data directory: each node must have its own data directory to store network state. Specify it on the command line using the `-d datadir` flag or in the config in `{"main":{"data-folder":""}}`. -1. Smeshing data directory: each smeshing node must point to a different PoST data directory. Specify in the config using `{"smeshing":{"smeshing-opts":{"smeshing-opts-datadir":""}}}`. **See note below about avoiding equivocation!** -1. Lockfile: each running node must specify a different lockfile. Specify it on the command line using `--filelock` or in the config with `{"main":{"filelock":""}}`, e.g. `/tmp/go-spacemesh-01.lock`. -1. GRPC API ports: assuming you have GRPC enabled, each running node must use a different set of ports for the public and private GRPC services. Specify them in the config with `{"api":{"grpc-public-listener":":","grpc-private-listener":":"}}"`. Use `"0.0.0.0"` to listen on all interfaces, or specify an IP address attached to a particular interface. See next section for more information on the API and the difference between public and private services. -1. P2P listen port: you can specify a different port for each node using the `--listen` CLI flag or in the config file using `"p2p": {"listen": "/ip4/0.0.0.0/tcp/6100"}`. +1. **Node data directory**: Each node must have its own data directory to store network state. You can specify it via the command line using the `-d datadir` flag or in the config in `{"main":{"data-folder":""}}`. +1. **Smeshing data directory**: Each smeshing node must point to a different PoS data directory. You can specify it in the config using `{"smeshing":{"smeshing-opts":{"smeshing-opts-datadir":""}}}`. *See the note below about avoiding equivocation!* +1. **Lockfile**: Each node must specify a different lockfile. You can specify it via the command line using `--filelock` or in the config with `{"main":{"filelock":""}}` (e.g., `/tmp/go-spacemesh-01.lock`). +1. **GRPC API ports**: Assuming you have GRPC enabled, each running node must use a different set of ports for the public and private GRPC services. You can specify them in the config with `{"api":{"grpc-public-listener":":","grpc-private-listener":":"}}"`. Use `"0.0.0.0"` to listen on all interfaces, or specify an IP address attached to a particular interface. See the next section for more information on the API and the difference between public and private services. +1. **P2P listen port**: You can specify a different port for each node using the `--listen` command line flag or in the config file using `"p2p": {"listen": "/ip4/0.0.0.0/tcp/6100"}`. ## System Service on Linux -On compatible Linux-based systems, we strongly recommend running `go-spacemesh` as a [systemd service](https://linuxhandbook.com/create-systemd-services/). This makes log management easier, and it ensures that the node will automatically restart if it dies or is killed, and that it automatically starts when the system is restarted. Each Linux distribution is different, so please check the documentation for your distribution to determine precisely where to create the service file. On most distributions the file should live in `/etc/systemd/system`. Here's a sample service file - please read the [systemd documentation](https://www.freedesktop.org/software/systemd/man/systemd.service.html) for more information and update paths, users, etc. to suit your particular system: +On compatible Linux-based systems, we strongly recommend running `go-spacemesh` as a [systemd service](https://linuxhandbook.com/create-systemd-services/). This makes log management easier and ensures that the node will automatically restart if it dies or is killed, while also automatically starting the node when the system is restarted. Each Linux distribution is different, so please check the documentation for your distribution to determine precisely where to create the service file. On most distributions, the file should live in `/etc/systemd/system`. Here is a sample service file - please read the [systemd documentation](https://www.freedesktop.org/software/systemd/man/systemd.service.html) for more information and update paths, users, etc. to suit your particular system: ``` [Unit] @@ -170,7 +166,7 @@ You can then view the logs of the running service by running: ## Parallel Initialization -While by default initialization occurs using a single GPU, it's possible to initialize a single identity using many GPUs in parallel, on a single system or on multiple systems. This can be done using `postcli`: specify the desired number of units, count the total number of init files, then initialize a subset on each GPU/each system, e.g.: +While, by default, initialization occurs using a single GPU, it is possible to initialize a single identity using many GPUs in parallel, either on a single system or on multiple systems. This can be done using `postcli`: simply specify the desired number of units, count the total number of PoS init files, then initialize a subset on each GPU/each system, e.g.: ```bash ./postcli -numUnits 100 -printNumFiles @@ -189,6 +185,6 @@ On Machine B: ./postcli -numUnits 100 -id -commitmentAtxId -fromFile 800 -datadir ./dataB ``` -When combining the files, care must be taken to manually merge the metadata contained in the `post_metadata.json` files since each will contain a different nonce value and the smallest nonce must be chosen. For the same reason we strongly recommend that you not perform initialization **using multiple GPUs on a single system using the same PoST data directory,** because the nonces found by one process will be overwritten by those found by another. +When combining the files, care must be taken to manually merge the metadata contained in the `post_metadata.json` files since each will contain a different nonce value and the smallest nonce must be chosen. For the same reason, we strongly recommend that you *not* perform initialization **using multiple GPUs on a single system using the same PoST data directory,**. This is because the nonces found by one process will be overwritten by those found by the other. -See [the postcli README](https://github.com/spacemeshos/post/tree/develop/cmd/postcli) for more information. +See [the postcli README](https://github.com/spacemeshos/post/tree/develop/cmd/postcli#postcli) for more information.