From 1f540e3dc368a6dd154ecf85f0c5863caaf2bbc2 Mon Sep 17 00:00:00 2001 From: barriebyron Date: Tue, 11 Jul 2023 11:06:24 -0400 Subject: [PATCH 1/6] edit grooming --- docs/node-operators/archive-node/overview.mdx | 219 +----------------- docs/node-operators/archive-redundancy.mdx | 78 ++++--- docs/node-operators/block-producers.mdx | 58 +++-- docs/node-operators/connecting-to-devnet.mdx | 72 ++++-- 4 files changed, 139 insertions(+), 288 deletions(-) diff --git a/docs/node-operators/archive-node/overview.mdx b/docs/node-operators/archive-node/overview.mdx index 92ac5d010..e3f694026 100644 --- a/docs/node-operators/archive-node/overview.mdx +++ b/docs/node-operators/archive-node/overview.mdx @@ -1,222 +1,7 @@ --- -title: Overview +title: Overview DELETE OBSOLETE --- # Archive Node Overview +now in archive-node.mdx -:::note - -A new version of Mina Docs is coming soon! This page will be rewritten. - -::: - - -Mina nodes are succinct by default, meaning they don't need to maintain historical information about the network, block, or transactions. -For some usecases, it is useful to maintain this historical data, which you can do by running an **Archive Node.** - -An **Archive Node** is just a regular mina daemon that is connected to a running archive process. -The daemon will regularly send blockchain data to the archive process, -which will store it in a [Postgres](https://www.postgresql.org/) database. - -Running an archive node therefore requires some knowledge of managing a Postgres database instance. -In this section, we'll set up a database, run the Archive Node, connect it to a daemon, and try some queries on the data. -Let's get started by installing what we need. - -## Installation - -1. Install the latest version of Mina. If you haven't upgraded to the latest version of the daemon, head [back to the docs](getting-started) to get the latest version. You can run `mina -help` to check if the installation succeeded. -2. Install [Postgres](https://www.postgresql.org/download/). -3. Install the archive node package. - - - Ubuntu/Debian: - - ``` - sudo apt-get install mina-archive=1.3.0-9b0369c - ``` - - - Docker: - ``` - minaprotocol/mina-archive:1.3.0-9b0369c-bullseye - ``` - -## Setup - -Below are some basic instructions on how to set up everything required to get an archive node running locally. These will be slightly different if you're connecting to a cloud instance of postgres, if your deployment uses docker, or if you want to run these processes on different machines. - - - -Note: Some of these instructions may depend on how your operating system installs postgres (and assume that it is installed in the first place). - - - -1. Start a local postgres server. This will just run it in the foreground for testing, you will likely want to run it in the background or use your OS's service manager (like systemd) to run it for you. Alternatively, you may use a postgres service hosted by a cloud provider. - -``` -postgres -p 5432 -D /usr/local/var/postgres -``` - -For macOS, run `brew services start postgres` to start a local postgres server. - -2. Create database (here called `archive`) on server and load the schema into it. This will only need to be done the first time the archive node is set up. - -``` -createdb -h localhost -p 5432 -e archive - -psql -h localhost -p 5432 -d archive -f <(curl -Ls https://raw.githubusercontent.com/MinaProtocol/mina/master/src/app/archive/create_schema.sql) -``` - -3. Start archive process on port 3086, connecting to the postgres database we started on port 5432 in step 1. - -``` -mina-archive run \ - --postgres-uri postgres://localhost:5432/archive \ - --server-port 3086 -``` - -4. Start the daemon, connecting it to the archive process that we just started on port 3086. If you want to connect to an archive process on another machine, you can specify a hostname as well, like `localhost:3086`. - -``` -mina daemon \ - ..... - --archive-address 3086\ -``` - -## Upgrading/Repairing the Archive Data - -Due to a bug in the originally released archive node version 1.1.5, some early transactions may not be represented properly in your database. See [here](https://gist.github.com/lk86/22b07d3b3f91c765f34e4e4398a84701) for complete instructions on migrating your archive database. - -## Using the Archive Node - -Now that we've got the archive node running, let's take a look at the tables in the database. - -To list the tables in the database, you can run the `\dt` command, in psql. -View the full schema of the tables [here](https://github.com/minaProtocol/mina/blob/master/src/app/archive/create_schema.sql). - -Below are some notable fields in each table. - -### Table 1: user_commands - -# - -This table keeps track of transactions made on the network. - -``` -... - user_command_type Type of transaction being made - Possible values: `'payment', 'delegation' - To see a specific type of transaction, i.e. payments or creating a token, specify this field in your queries. - source_id public key of the sender - receiver_id public key of the receiver - amount amount being sent from the sender to the receiver - token ID of a token **If you are querying for different type of token transactions, specify this field.** -``` - -### Table 2: internal_commands - -This table keeps track of rewards earned from snark work or block producing. - -``` -... - internal_command_type represents whether the command is a `fee_transfer` from snark work or a `coinbase` reward from block producing. - Use this field for information about block rewards and snark rewards (there is also an extra fee_transfer added to support sending all the transaction fees summed together to the block_creator) - receiver_id public key ID of the receiver - fee amount being sent from the protocol to the receiver - token ID of a token **If you are querying for different type of token transactions, specify this field.** -``` - -### Table 3: blocks - -``` -... - id - parent_id ID of the previous block in the blockchain - Use this field for information about block rewards and snark rewards (there is also an extra fee_transfer added to support sending all the transaction fees summed together to the block_creator) - creator_id public key of the block creator -``` - -### Join tables - -There are two join tables in the archive database, which links blocks to transactions. -By linking the block table and command tables, these tables allow you to identify -specific transactions within blocks. - -#### Join table 1: blocks_user_commands - -``` -... -block_id ID of the block containing the user command -user_command_id ID of the user command -sequence_no 0-based order of the user command among the block transactions -``` - -#### Join table 2: blocks_internal_commands - -``` -... -block_id ID of the block containing the internal command -internal_command_id ID of the internal command -sequence_no 0-based order of the internal command among the block transactions -secondary_sequence_no 0-based order of a fee transfer within a coinbase internal command -``` - -## Try a query - -Now that we've taken a look at the structure of the data, let's try a query. - -**Example 1:** Find all blocks that have been created by your public key - -``` -SELECT * -FROM blocks AS b -INNER JOIN public_keys AS pk1 ON b.creator_id = pk1.id -WHERE value = 'MY_PK' -``` - -**Example 2:** Find all payments you’ve received by your public key - -``` -SELECT * -FROM user_commands AS uc -JOIN blocks_user_commands AS buc ON uc.id = buc.user_command_id -JOIN public_keys AS pk ON uc.receiver_id = pk.id -WHERE value = 'MY_PK' -AND type = 'payment' -``` - -**Example 3:** Find the block at height 12 on the canonical chain - -``` -WITH RECURSIVE chain AS ( - (SELECT ... FROM blocks b WHERE height = (select MAX(height) from blocks) - ORDER BY timestamp ASC - LIMIT 1) - - UNION ALL - - SELECT ... FROM blocks b - INNER JOIN chain - ON b.id = chain.parent_id AND chain.id <> chain.parent_id -) SELECT ..., pk.value as creator FROM chain c - INNER JOIN public_keys pk - ON pk.id = c.creator_id - WHERE c.height = 12 -``` - -**Example 3:** List the counts of blocks created by each public key and sort them in descending order - -``` -SELECT p.value, COUNT(*) FROM blocks -INNER JOIN public_keys AS p ON creator_id = ip.id -GROUP BY p.value -ORDER BY count DESC; -``` - -**Example 4:** List the counts of applied payments created by each public key and sort them in descending order - -``` -SELECT p.value, COUNT(*) FROM user_commands -INNER JOIN public_keys AS p ON source_id = p.id -WHERE status = 'applied' -AND type = 'payment' -GROUP BY p.value ORDER BY count DESC; -``` diff --git a/docs/node-operators/archive-redundancy.mdx b/docs/node-operators/archive-redundancy.mdx index 254b20248..eef31d85e 100644 --- a/docs/node-operators/archive-redundancy.mdx +++ b/docs/node-operators/archive-redundancy.mdx @@ -11,15 +11,19 @@ A new version of Mina Docs is coming soon! This page will be rewritten. # Archive Redundancy -The [archive node](/node-operators/archive-node) will store its data in a PostgreSQL database that node operators host on a provider of their choice, including self-hosting, if desired. However, for redundancy, archive node data can also be stored to an object storage (e.g. [Google Cloud Storage](#upload-block-data-to-google-cloud-storage); soon S3 & others) or to a [`mina.log`](#save-block-data-from-logs) file, which can live on your computer or be streamed to any typical logging service (e.g. LogDNA). +The [archive node](/node-operators/archive-node) stores its data in a PostgreSQL database that node operators host on a provider of their choice, including self-hosting. For redundancy, archive node data can also be stored to an object storage like [Google Cloud Storage](#upload-block-data-to-google-cloud-storage); soon S3 and others) or to a [`mina.log`](#save-block-data-from-logs) file that reside on your computer or be streamed to any typical logging service, for example, LogDNA. -Archive data is critical for applications that require historical lookup. On the protocol side, archive data is currently important for disaster recovery to reconstruct a certain state, but may not be required in a future version of Mina. To that end, having a single [archive node setup](/node-operators/archive-node) might not be sufficient. If the daemon that sends blocks to the archive process or if the archive process itself fails for some reason, there can be missing blocks in the database. To minimize the risk of archive data loss there are a few redundancy techniques that can be employed. +Archive data is critical for applications that require historical lookup. -A single archive node setup has a daemon sending blocks to an archive process which writes them to the database. +On the protocol side, archive data is important for disaster recovery to reconstruct a certain state. A single [archive node set up](/node-operators/archive-node) might not be sufficient. -It is possible to connect multiple daemons to the archive process by specifying the address of an archive process in multiple daemons, thereby reducing the dependency on a single daemon to provide blocks to the archive process. +If the daemon that sends blocks to the archive process or if the archive process itself fails for some reason, there can be missing blocks in the database. To minimize the risk of archive data loss, employ redundancy techniques. -For example, the server-port of an archive process is 3086, then the daemons can connect to it using the flag `archive-address` +A single archive node setup has a daemon sending blocks to an archive process that writes them to the database. + +To connect multiple daemons to the archive process, specify the address of an archive process in multiple daemons to reduce the dependency on a single daemon to provide blocks to the archive process. + +For example, the server port of an archive process is 3086. The daemons can connect to that port using the flag `archive-address` ``` mina daemon \ @@ -27,19 +31,21 @@ mina daemon \ --archive-address :3086\ ``` -Similarly, it is possible to have multiple archive processes write to the same database. In this case the postgres uri passed to the archive process would be same across multiple archive processes. +Similarly, it is possible to have multiple archive processes write to the same database. In this case, the postgres uri passed to the archive process would be same across multiple archive processes. -However, multiple archive processes writing to a database concurrently could cause data inconsistencies (explained in https://github.com/MinaProtocol/mina/issues/7567). To avoid this, set the transaction isolation level of the archive database to `Serializable` using the following query: +However, multiple archive processes concurrently writing to a database could cause data inconsistencies (explained in https://github.com/MinaProtocol/mina/issues/7567). To avoid this, set the transaction isolation level of the archive database to `Serializable` with the following query: ALTER DATABASE SET DEFAULT_TRANSACTION_ISOLATION TO SERIALIZABLE ; -This should be done after creating the [database](/node-operators/archive-node) and before connecting an archive process to it. +Set the transaction level after you create the [database](/node-operators/archive-node) and before you connect an archive process to it. -## Backing up block data +## Back up block data -To further ensure there that archive data can be restored one can use the following features to backup block data and restore them when necessary. +To ensure that archive data can be restored, use the following features to back up and restore block data. -We have a mechanism in place for logging a high-fidelity machine-readable representation of blocks using JSON including some opaque information deep within. We use these logs internally to quickly replay blocks to get to certain chain-states for debugging. This information suffices to recreate exact states of the network. +A mechanism for logging a high-fidelity machine-readable representation of blocks using JSON includes some opaque information deep within. + +These logs are used internally to quickly replay blocks to get to certain chain states for debugging. This information suffices to recreate exact states of the network. Some of the internal data look like this: @@ -51,33 +57,51 @@ This JSON will evolve as the format of the block and transaction payloads evolve ### Upload block data to Google Cloud Storage -To indicate a daemon to upload block data to Google Cloud Storage, pass the flag `--upload-blocks-to-gcloud` . To successfully upload the file, daemon requires the following environment variables to be set: 1. `GCLOUD_KEYFILE` : Key file for authentication 2. `NETWORK_NAME`: Network name to be used in the filename to easily distinguish between blocks in different networks (main-net and testnets) 3. `GCLOUD_BLOCK_UPLOAD_BUCKET` : Google Cloud Storage bucket where the files are uploaded +The daemon generates a file for each block with the name `-.json` . These files are called precomputed blocks and have all the fields of a block. + +To specify a daemon to upload block data to Google Cloud Storage, pass the flag `--upload-blocks-to-gcloud`. + +Set the following environment variables: + +- `GCLOUD_KEYFILE`: Key file for authentication + +- `NETWORK_NAME`: Network name to use in the filename to easily distinguish between blocks in different networks (Mainnet and Testnets) -The daemon generates a file for each block with the name `-.json` . These are called precomputed blocks and will have all the fields of a block. +- `GCLOUD_BLOCK_UPLOAD_BUCKET`: Google Cloud Storage bucket where the files are uploaded ### Save block data from logs -The daemon also logs the block data if the flag `-log-precomputed-blocks` is passed. The log to look for is `Saw block with state hash $state_hash` that contains `precomputed_block` in the metadata and has the block information. This is the same information (precomputed blocks) that gets uploaded to Google Cloud Storage. +The daemon logs the block data if the flag `-log-precomputed-blocks` is passed. + +The log to look for is `Saw block with state hash $state_hash` that contains `precomputed_block` in the metadata and has the block information. These precomputed blocks contain the same information that gets uploaded to Google Cloud Storage. ### Generate block data from another archive database -From a fully synced archive database, one can generate block data for each block using the `mina-extract-blocks` tool. +From a fully synced archive database, you can generate block data for each block using the `mina-extract-blocks` tool. + +The `mina-extract-blocks` tool generates a file for each block with name `.json`. + +The tool takes an `--archive-uri`, an `--end-state-hash`, and an optional `--start-state-hash` and writes all the blocks in the chain starting from start-state-hash and ending at end-state-hash (including start and end). -The tool takes an `--archive-uri`, an `--end-state-hash`, and an optional --start-state-hash and writes all the blocks in the chain starting from start-state-hash and ending at end-state-hash (including start and end). +If only the end hash is provided, then the tool generates blocks starting with the unparented block closest to the end block. This would be the genesis block if there are no missing blocks in between. The block data in these files are called extensional blocks. Since these are generated from the database, they have only the data stored in the archive database and do not contain any other information pertaining to a block (for example, blockchain SNARK) like the precomputed blocks and can only be used to restore blocks in the archive database. -If only the end hash is provided, then the tool generates blocks starting with the unparented block closest to the end block. This would be the genesis block if there are no missing blocks in between. The tool generates a file with name `.json` for each block. The block data in these files are called extensional blocks. Since these are generated from the database, they would have only the data stored in the archive database and would not contain any other information pertaining to a block (for example, blockchain snark) that the precomputed blocks would have and therefore, can only be used to restore blocks in the archive database. +Provide the flag `--all-blocks` to write out all blocks contained in the database. -Alternatively, instead of specifying state hashes, you can provide the flag `--all-blocks`, and the tool will write out all blocks contained in the database. +## Identify missing blocks -## Identifying missing blocks +To determine any missing blocks in an archive database, use the `mina-missing-block-auditor` tool. -The tool `mina-missing-block-auditor` can be used to determine any missing blocks in an archive database. The tool outputs a list of state hashes of all the blocks in the database that are missing a parent. This can be used to monitor the archive database for any missing blocks. The URI of the postgres database can be specified using the flag `--archive-uri` +The tool outputs a list of state hashes of all the blocks in the database that are missing a parent. This list can be used to monitor the archive database for any missing blocks. Specify the URI of the postgres database by using the flag `--archive-uri`. -## Restoring blocks +## Restore blocks -Missing blocks in an archive database can be restored if there is block data (precomputed or extensional) available from the options listed [above](#backing-up-block-data) using the tool `mina-archive-blocks`. +When you have block data (precomputed or extensional) available from [Back up block data](/node-operators/archive-redundancy#back-up-block-data), you can restore missing blocks in an archive database using the tool `mina-archive-blocks`. -1. Restore precomputed blocks: (from option [1](#upload-block-data-to-google-cloud-storage) and [2](#save-block-data-from-logs) above) +1. Restore precomputed blocks from: + + - [Upload block data to Google Cloud Storage]](/node-operators/archive-redundancy#upload-block-data-to-google-cloud-storage) + + - [Save block data from logs](/node-operators/archive-redundancy#save-block-data-from-logs) ``` mina-archive-blocks --precomputed --archive-uri FILES @@ -91,10 +115,12 @@ Missing blocks in an archive database can be restored if there is block data (pr ## Staking ledgers -Staking ledgers are used to determine slot winners for each epoch. Mina daemon stores staking ledger for the current and the next epoch (after it is finalized). When transitioning to a new epoch, the "next" staking ledger from the previous epoch is used to determine slot winners of the new epoch and a new "next" staking ledger is chosen. Since staking ledgers for older epochs are no longer accessible, users may want to still keep them around for reporting or other purposes. +Staking ledgers are used to determine slot winners for each epoch. Mina daemon stores staking ledger for the current and the next epoch after it is finalized. When transitioning to a new epoch, the "next" staking ledger from the previous epoch is used to determine slot winners of the new epoch and a new "next" staking ledger is chosen. Since staking ledgers for older epochs are no longer accessible, you can still keep them around for reporting or other purposes. -Currently these ledgers can be exported using the cli command- +Export these ledgers using the mina cli command: mina ledger export [current-staged-ledger|staking-epoch-ledger|next-epoch-ledger] -Epoch ledger transition happens once every 14 days (given slot-time = 3mins and slots-per-epoch = 7140). The window to backup a staking ledger is ~27 days considering "next" staking ledger is finalized after k (currently 290) blocks in the current epoch and therefore will be available for the rest of the current epoch and the entire next epoch. +Epoch ledger transition happens once every 14 days (given slot-time = 3mins and slots-per-epoch = 7140). + +The window to backup a staking ledger is ~27 days considering "next" staking ledger is finalized after k (currently 290) blocks in the current epoch and therefore is available for the rest of the current epoch and the entire next epoch. diff --git a/docs/node-operators/block-producers.mdx b/docs/node-operators/block-producers.mdx index cddc796d1..a2b8b96c1 100644 --- a/docs/node-operators/block-producers.mdx +++ b/docs/node-operators/block-producers.mdx @@ -11,46 +11,60 @@ A new version of Mina Docs is coming soon! This page will be rewritten. # Block Producers -The role of a block producer in Mina is to achieve [consensus](../about-mina/consensus) and provide security to the blockchain. The block producer is responsible for creating new blocks, which include recent transactions broadcast on the network and a blockchain proof that proves the current state of the chain is valid. +The role of a block producer in Mina is to achieve [consensus](../about-mina/consensus) and provide security to the blockchain. The block producer is responsible for creating new blocks that include recent transactions broadcast on the network and a blockchain proof that proves the current state of the chain is valid. -In Mina, anyone may become a block producer. There is an unbounded number of participants with the chance of producing a block proportional to the funds staked. Funds are not locked and are not subject to slashing. +In Mina, anyone can become a block producer. There is an unbounded number of participants with the chance of producing a block proportional to the funds staked. Funds are not locked and are not subject to slashing. -In return for staking funds and generating the required blockchain proofs, blocks produced and included in the canonical chain are rewarded in the form of a coinbase and transaction fees, less any fees paid to purchase required [transaction snark work](./snark-workers). +In return for staking funds and generating the required blockchain proofs, blocks that are produced and included in the canonical chain are rewarded in the form of a coinbase and transaction fees, less any fees paid to purchase required [transaction SNARK work](./snark-workers). -To produce a block successfully, a block producer must have the current state of the blockchain. Additionally, they must have enough available compute to produce a blockchain SNARK within the slot time and be connected to peers to broadcast the generated block within an acceptable delay as defined by the network consensus parameters. +To successfully produce a block, a block producer must have the current state of the blockchain. A block producer must have enough available compute to produce a blockchain SNARK within the slot time and be connected to peers to broadcast the generated block within an acceptable delay as defined by the network consensus parameters. -### Selecting a block producer +### Select a block producer -The opportunity to produce a block for a slot is determined by a [verifiable random function](../glossary#vrf) (VRF). This function can be thought of as a lottery. Each block producer independently runs this VRF for each slot, and if they get an output greater than a threshold proportional to the producer's stake, they have the chance to produce a block at the designated slot. +The opportunity to produce a block for a slot is determined by a [verifiable random function](/glossary#verifiable-random-function-vrf) (VRF). Think of this function as a lottery. Each block producer independently runs this VRF for each slot and if the output is greater than a threshold proportional to the producer's stake, they have the chance to produce a block at the designated slot. -This process is secret, in that only the private key holder can determine the VRF output, and hence only they know when they are to produce a block. This aids security as it is impossible for an adversary to target a known block producer at a certain slot, e.g., by a denial of service or targeted attack. As a result, it also means that multiple producers can be selected for the same slot. If multiple producers produce a valid block for the same slot, this will produce a short-range fork where the consensus rules will select the longest chain. +This process is secret so that only the private key holder can determine the VRF output and only they know when they are to produce a block. This selection process aids security as it is impossible for an adversary to target a known block producer at a certain slot, e.g., by a denial of service or targeted attack. As a result, multiple producers can be selected for the same slot. When multiple producers produce a valid block for the same slot, ta short-range fork is produced where the consensus rules select the longest chain. The stake distribution is determined from the snarked ledger at the last block of `current epoch-2`, so there is a delay for any recently acquired or [delegated stake](#stake-delegation). For example, if the current epoch is 10, the staking distribution is determined from the snarked ledger of the last block of the 8th epoch. -:::note - -View the output of the VRF in the logs by looking for `Checking VRF evaluations`. - -::: +To view the output of the VRF in the logs, look for `Checking VRF evaluations`. ### Generating a block When a block producer is selected to produce a block for a slot, they perform the following actions: -* Choose the current best tip from their transition frontier (local store of blocks) on which to build the new block. -* Select transactions and any snark work required from the transaction and snark pools. A block producer must purchase snark work at least in equal quantity to the transactions they add to a block. In addition to any user transactions, they also add a coinbase transaction as a reward for producing the block and any fee transfers to pay the snark workers. -* Generate the proposed next state of the blockchain. This comprises creating a diff of the staged ledger that includes the account ledger and scan state (a queue of transactions yet to have proofs). This diff is applied to the existing staged ledger to produce the new state. -* Creates a blockchain proof to prove that the new state is valid. This SNARK additionally validates the prior protocol state proof. -* Creates a delta transition chain proof that proves the validity of the block if it is received within an acceptable network delay as defined by the network consensus parameters. -* Applies this newly generated state locally, adding it into the existing transition frontier. -* Broadcasts the block (referred to as an external transition) to its peers. +- Choose the current best tip from their transition frontier (local store of blocks) on which to build the new block. + +- Select transactions and any SNARK work required from the transaction and SNARK pools. + + A block producer must purchase SNARK work at least in equal quantity to the transactions they add to a block. + In addition to any user transactions, a block producer must also add a coinbase transaction as a reward for producing the block and any fee transfers to pay the SNARK workers. + +- Generate the proposed next state of the blockchain. + + - Create a diff of the staged ledger that includes the account ledger and scan state (a queue of transactions yet to have proofs). + - Apply this diff to the existing staged ledger to produce the new state. + +- Create a blockchain proof to prove that the new state is valid. + + This SNARK additionally validates the prior protocol state proof. + +- Create a delta transition chain proof that proves the validity of the block if it is received within an acceptable network delay as defined by the network consensus parameters. + +- Apply this newly generated state locally and add it into the existing transition frontier. + +- Broadcast the block (call an external transition) to its peers. ### Stake delegation -Delegated funds are not spendable and may be undelegated at any time by re-delegating the stake back to the original account. +Delegated funds are not spendable and can be undelegated at any time by re-delegating the stake back to the original account. ## Supercharged coinbase -To further incentivize staking, if the account that wins the slot is one that does not have any [time-locked tokens](./time-locked-accounts), the block producer will receive double the coinbase rewards. +To further incentivize staking, if the account that wins the slot does not have any [time-locked tokens](./time-locked-accounts), the block producer receives double the coinbase rewards. + +The supercharged coinbase applies to both delegating and staking accounts. The supercharged reward is determined using the account that won the slot. For example: + +- If a non-time-locked account delegates to a time-locked account, if the non-time-locked account wins the slot, the coinbase is supercharged. -The supercharged coinbase applies to all accounts, either delegating or staking. The supercharged reward is determined using the account that won the slot. For example, if a non-time-locked account delegates to a time-locked account, if the non-time-locked account wins the slot, the coinbase is supercharged. If the time-locked account wins, the coinbase is not supercharged. +- If the time-locked account wins, the coinbase is not supercharged. diff --git a/docs/node-operators/connecting-to-devnet.mdx b/docs/node-operators/connecting-to-devnet.mdx index eed70149c..b8e0ff436 100644 --- a/docs/node-operators/connecting-to-devnet.mdx +++ b/docs/node-operators/connecting-to-devnet.mdx @@ -10,36 +10,47 @@ A new version of Mina Docs is coming soon! This page will be rewritten. ::: -In this section, we'll connect to the `Devnet` network. `Devnet` is a network dedicated for developers building on top of the Mina protocol. It is designed for testing -and experimentation of developers and holds no real value. Users can reach out on Discord if they would like to request a prefunded account. +The Devnet network is designed for testing and experimentation. Devnet is a dedicated network for developers who are building on top of the Mina protocol. -Only use the `Devnet` network if you are a developer and building on top of the Mina protocol. If you are interested in running a node, please connect -to [Mainnet RC](connecting-to-the-network) instead. +MINA on this network holds no real value. To request a prefunded account, reach out on [Mina Protocol Discord](https://discord.gg/minaprotocol). + +If you are interested in running a node, connect +to [Mainnet network](connecting-to-the-network) instead. ## Update your software -Connecting to `Devnet` requires a specific build of the Mina client as well as a specific version of a peers list. Using the `Devnet` build and peers list does not work for `Zenith`. +Connecting to Devnet requires a specific build of the Mina client and a specific version of a peers list. -Follow the instructions below for your operating system below. +Follow the steps for your operating system. -### Ubuntu 18.04 / Debian 9 +### Ubuntu 18.04 and Debian 9 -Follow along below to install the latest **Stable** [Mina Release 1.3.1.2](https://github.com/MinaProtocol/mina/releases/tag/1.3.1.2) or visit the [Github Releases Page](https://github.com/MinaProtocol/mina/releases) to discover and install pre-release (Alpha/Beta) builds. +Install the latest **Stable** [Mina Release 1.3.1.2](https://github.com/MinaProtocol/mina/releases/tag/1.3.1.2) or visit the [GitHub Releases Page](https://github.com/MinaProtocol/mina/releases) to install pre-release (Alpha/Beta) builds. -You can set up the new debian `stable` repository and install the latest version as follows: +TO set up the new debian `stable` repository and install the latest version: -``` +```sh echo "deb [trusted=yes] http://packages.o1test.net $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/mina.list sudo apt-get install --yes apt-transport-https sudo apt-get update sudo apt-get install --yes curl unzip mina-devnet=1.3.0-9b0369c ``` -Check that daemon installed correctly by running `mina version`. The output should read `Commit 9b0369c27bb85c8ab2f8725c6e977eb27b53b826 on branch master`. +To check that daemon installed correctly: -## Start up a node +```sh +mina version +``` -Run the following commands to start up a Mina node instance and connect to the `Devnet` network: +The expected output is: + +```text +Commit 9b0369c27bb85c8ab2f8725c6e977eb27b53b826 on branch master +``` + +## Start and connect a node to Devnet + +To start a Mina node instance and connect to the Devnet network: ``` mina daemon --peer-list-url https://storage.googleapis.com/seed-lists/devnet_seeds.txt @@ -47,29 +58,30 @@ mina daemon --peer-list-url https://storage.googleapis.com/seed-lists/devnet_see ### Docker -When running your daemon using Docker, first create a directory on the host machine to mount as a volume: +To run your daemon using Docker, create a directory on the host machine to mount as a volume: -``` +```sh cd ~ mkdir ~/.mina-config ``` -To produce blocks or otherwise customize the configuration for the mina daemon, create a file `~/.mina-env` containing the following: +To produce blocks or customize the configuration for the mina daemon, create the `~/.mina-env` file: -``` +```sh export MINA_PRIVKEY_PASS="My_V3ry_S3cure_Password" LOG_LEVEL=Info FILE_LOG_LEVEL=Debug EXTRA_FLAGS=" --block-producer-key " PEER_LIST_URL=https://storage.googleapis.com/seed-lists/devnet_seeds.txt ``` -Ensure to replace with the full path to your block producer private key, for example, `/home/ubuntu/keys/my-wallet`. -If you do not intend to produce blocks then you can keep ~/.mina-env empty except for the PEER_LIST_URL. +- Replace with the full path to your block producer private key. For example, `/home/ubuntu/keys/my-wallet`. -Now simply run the image with your ~/.mina-config and ~/.mina-env mounted into the container: +If you do not want to produce blocks, then provide only the `PEER_LIST_URL`. -``` +Now, run the image with your `~/.mina-config` and `~/.mina-env` files mounted into the container: + +```sh docker run --name mina -d \ -p 8302:8302 \ --restart=always \ @@ -79,6 +91,20 @@ minaprotocol/mina-daemon:1.3.1.2-25388a0-bullseye-devnet \ daemon \ ``` -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`. +To follow the logs: + +```sh +docker logs -f mina +``` + +If the node crashes, save the log output to a file: -Run `docker exec -it mina mina client status` to monitor connectivity to the network. +```sh +docker logs mina > mina-log.txt +``` + +To monitor connectivity to the network: + +```sh +docker exec -it mina mina client status +``` From 0d57d5342141c21f68e50eb98f10a5b825c17b8c Mon Sep 17 00:00:00 2001 From: barriebyron Date: Wed, 12 Jul 2023 11:28:12 -0400 Subject: [PATCH 2/6] editorial standards for connecting topics --- docs/node-operators/connecting-to-devnet.mdx | 36 ++- .../connecting-to-the-network.mdx | 275 +++++++++++------- 2 files changed, 196 insertions(+), 115 deletions(-) diff --git a/docs/node-operators/connecting-to-devnet.mdx b/docs/node-operators/connecting-to-devnet.mdx index b8e0ff436..0a0d3421b 100644 --- a/docs/node-operators/connecting-to-devnet.mdx +++ b/docs/node-operators/connecting-to-devnet.mdx @@ -14,8 +14,13 @@ The Devnet network is designed for testing and experimentation. Devnet is a dedi MINA on this network holds no real value. To request a prefunded account, reach out on [Mina Protocol Discord](https://discord.gg/minaprotocol). -If you are interested in running a node, connect -to [Mainnet network](connecting-to-the-network) instead. +If you are interested in running a node, connect to [Mainnet network](connecting-to-the-network) instead. + +## High-Level Overview + +1. Install or update your node to the required specific mina daemon. +1. Start a mina node and connect to Devnet. +1. Check your connectivity. ## Update your software @@ -27,7 +32,7 @@ Follow the steps for your operating system. Install the latest **Stable** [Mina Release 1.3.1.2](https://github.com/MinaProtocol/mina/releases/tag/1.3.1.2) or visit the [GitHub Releases Page](https://github.com/MinaProtocol/mina/releases) to install pre-release (Alpha/Beta) builds. -TO set up the new debian `stable` repository and install the latest version: +To set up the new debian `stable` repository and install the latest version: ```sh echo "deb [trusted=yes] http://packages.o1test.net $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/mina.list @@ -91,20 +96,21 @@ minaprotocol/mina-daemon:1.3.1.2-25388a0-bullseye-devnet \ daemon \ ``` -To follow the logs: +## Check your connectivity -```sh -docker logs -f mina -``` +Follow the logs: -If the node crashes, save the log output to a file: + ```sh + docker logs -f mina + ``` -```sh -docker logs mina > mina-log.txt -``` +If the node crashes, save the log output to a file: -To monitor connectivity to the network: + ```sh + docker logs mina > mina-log.txt + ``` +Monitor connectivity to the network: -```sh -docker exec -it mina mina client status -``` + ```sh + docker exec -it mina mina client status + ``` diff --git a/docs/node-operators/connecting-to-the-network.mdx b/docs/node-operators/connecting-to-the-network.mdx index 32526c693..18e84b144 100644 --- a/docs/node-operators/connecting-to-the-network.mdx +++ b/docs/node-operators/connecting-to-the-network.mdx @@ -1,6 +1,17 @@ --- -title: Connecting to the Network +title: Connect to the Mina Network hide_title: true +description: Steps to install mina and connect to the Mina Mainnet network. +keywords: + - how do I connect to the mina network + - mina protocol + - mainnet + - install mina + - start a mina node + - .mina-env + - connectivity + - how to monitor a mina node + - standalone mina node --- :::note @@ -9,145 +20,187 @@ A new version of Mina Docs is coming soon! This page will be rewritten. ::: -# Connecting to the Network +# Connect to the Mina Network -In this section, we'll connect to the `Mainnet` network and send our first transaction. Let's first start up the node so that we can begin issuing commands. +Steps to install mina, connect to the Mina Mainnet network, and test connectivity. -## Update your software +## High-Level Overview -The first step in connecting to `Mainnet` is installing the latest daemon version. Follow the instructions for your operating system below. +1. Install or update your node to the latest mina daemon. +1. Start a standalone mina node. +1. Stop the standalone node. +1. Configure the node as a block producer, or customize, with the `~/.mina-env` file. +1. Start a mina node with auto-restart workflows. +1. Check your connectivity. +1. Monitor the mina client status. -### Ubuntu 18.04, 20.04 / Debian 9, 10, 11 +## Update your mina daemon -Follow along below to install the latest **Stable** [Mina Release 1.3.1.2](https://github.com/MinaProtocol/mina/releases/tag/1.3.1.2) or visit the [Github Releases Page](https://github.com/MinaProtocol/mina/releases) to discover and install pre-release (Beta) builds. +The first step to connecting to Mainnet is to install the latest daemon version. -You can set up the new `stable` package repository and install the latest version as follows: +Follow the steps for your operating system. -``` +### Ubuntu 18.04, 20.04 and Debian 9, 10, 11 + +Install the latest **Stable** [Mina Release 1.3.1.2](https://github.com/MinaProtocol/mina/releases/tag/1.3.1.2) or visit the [GitHub Releases Page](https://github.com/MinaProtocol/mina/releases) to install pre-release (Beta) builds. + +To set up the new `stable` package repository and install the latest version: + +```sh echo "deb [trusted=yes] http://packages.o1test.net $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/mina.list sudo apt-get install --yes apt-transport-https sudo apt-get update sudo apt-get install --yes curl unzip mina-mainnet=1.3.1.2-25388a0 ``` -Check that daemon installed correctly by running `mina version`. The output should read `Commit 25388a0fed9695e8e9d04f75f50c2bae1c9c80db on branch master`. +To verify the daemon is correctly installed: -## Start up a node +```sh +mina version +``` -Since this technology is still relatively new, there are a few rare situations where your node can run into some issues. We don't want for your nodes to break and you not realize! So we've made some officially supported auto-restart flows for you. We'll be iterating on these in future releases. +The expected output is: -However, first we'll want to make sure everything works by running it manually before starting with the auto-restart flows. +```text +Commit 25388a0fed9695e8e9d04f75f50c2bae1c9c80db on branch master +``` -Note: If you are using the Hetzner hosting provider, we are currently experiencing an issue where Hetzner believes our software is being malicious. See the [Networking section of the troubleshooting page](/node-operators/troubleshooting#networking) to learn how to mitigate this before starting a node. +## Start a standalone mina node -Run the following command to start up a Mina node instance and connect to the live network: +**Note:** A known issue exists with the Hetzner hosting provider. If you are using Hetzner, follow the [Networking troubleshooting](/node-operators/troubleshooting#my-hosting-provider-is-warning-me-abuse-message-netscan-detected) guidance before you start a node. -``` -mina daemon --peer-list-url https://storage.googleapis.com/seed-lists/mainnet_seeds.txt -``` +Auto-restart flows are in place to ensure your nodes perform optimally. -If you have a key with stake and would like to produce blocks, also provide `--block-producer-key ~/keys/my-wallet`, replacing `~/keys/my-wallet` with the path to your private key if not the default. +1. Start a standalone mina node to make sure everything works. -The `--peer-list` argument specified above refer to the seed peer address - this is the initial peer we will connect to on the network. Since Mina is a [peer-to-peer](/glossary#peer-to-peer) protocol, there is no single centralized server we rely on. + To start a Mina node instance and connect to the live network: -See [here](/node-operators/troubleshooting) for common issues when first running a node. + ```sh + mina daemon --peer-list-url https://storage.googleapis.com/seed-lists/mainnet_seeds.txt + ``` -You're not done yet! Now that you've confirmed things are okay by running the standalone process, it is important we start Mina in a manner that will auto-restart itself when it dies. + The `--peer-list` argument specifies the the source file of seed peer addresses for the initial peer to connect to on the network. Mina is a [peer-to-peer](/glossary#peer-to-peer) protocol, so there is no dependence on a single centralized server. -First kill the existing `mina daemon` process with `Ctrl-C`, and then keep reading: + If you have a key with MINA stake and want to produce blocks: + + ```sh + mina daemon --peer-list-url https://storage.googleapis.com/seed-lists/mainnet_seeds.txt --block-producer-key ~/keys/my-wallet + ``` + + where `~/keys/my-wallet` is the path to your private key, if not the default. -### Creating your .mina-env +For help solving common issues when first running a node, see Node Operators [Troubleshooting](/node-operators/troubleshooting). -To produce blocks or otherwise customize the configuration for the mina daemon, create a file `~/.mina-env` containing the following: +## Stop the standlone node -``` -MINA_PRIVKEY_PASS="My_V3ry_S3cure_Password" -LOG_LEVEL=Info -FILE_LOG_LEVEL=Debug -EXTRA_FLAGS=" --block-producer-key " -``` -Ensure to replace with the full path to your block producer private key, for example, `/home/ubuntu/keys/my-wallet`. +- Kill the existing `mina daemon` process: -If you do not intend to produce blocks then you can keep ~/.mina-env empty for now. + Press `Ctrl+C`. -To change how mina is configured, simply specify flags to the mina daemon process with space-separated arguments between the quotes in `EXTRA_FLAGS=""`. +## Start a mina node with auto-restart flows -The mina systemd service no longer expects a peers.txt file, it just uses the PEER_LIST_URL variable to determine where to fetch initial peers from, and the PEER_LIST_URL for the mainnet package defaults to [https://storage.googleapis.com/seed-lists/mainnet_seeds.txt](https://storage.googleapis.com/seed-lists/mainnet_seeds.txt). +Now that you've confirmed things are okay by running the standalone process, start mina with auto-restart workflows that allow the node to continue running after you log out and restart automatically when the machine restarts. -After your .mina-env is ready, run the following commands to start up a Mina node instance and connect to the live network: +### Create and customize the .mina-env -``` -systemctl --user daemon-reload -systemctl --user start mina -systemctl --user enable mina -sudo loginctl enable-linger -``` +To produce blocks or otherwise customize the configuration for the mina daemon: -These commands allow the node to continue running after you logout and restart automatically when the machine reboots. +1. Create the `~/.mina-env` file. +1. To produce blocks, add the required configuration: -By default, the node connects to the network using the default external port of 8302. This can be changed using the `-external-port` flag, just add that to EXTRA_FLAGS. + ``` + MINA_PRIVKEY_PASS="My_V3ry_S3cure_Password" + LOG_LEVEL=Info + FILE_LOG_LEVEL=Debug + EXTRA_FLAGS=" --block-producer-key " + ``` -You can also look into the mina process itself that's running in the background and auto-restarting. + Replace with the full path to your block producer private key. For example, `/home/ubuntu/keys/my-wallet`. -This command will let you know if `mina` had any trouble getting started. + If you do not want to produce blocks then you can keep `~/.mina-env` empty for now. -``` -systemctl --user status mina -``` +1. To change how mina is configured, specify flags to the mina daemon process with space-separated arguments between the quotes in `EXTRA_FLAGS=""`. -You can stop mina gracefully, and stop automatically-restarting the service: + You can change the default values with `EXTRA_FLAGS`: -``` -systemctl --user stop mina -``` + - External port 8302 + - Change with `-external-port` + - Mainnet package [https://storage.googleapis.com/seed-lists/mainnet_seeds.txt](https://storage.googleapis.com/seed-lists/mainnet_seeds.txt) + - Change with `--peer-list-url` -Manually Restart it: +1. After your `.mina-env` file is ready, start a Mina node instance and connect to the live network: -``` -systemctl --user restart mina -``` + ```sh + systemctl --user daemon-reload + systemctl --user start mina + systemctl --user enable mina + sudo loginctl enable-linger + ``` -And look at logs: + These commands allow the node to continue running after you log out and restart automatically when the machine reboots. -``` -journalctl --user -u mina -n 1000 -f -``` +## Check your connectivity -In some cases in order to view logs you need to run the following command instead: +Monitor the mina process that's running in the background and auto-restarting. -``` -journalctl --user-unit mina -n 1000 -f -``` +Check if `mina` had any trouble getting started: + + ```sh + systemctl --user status mina + ``` + +Stop mina gracefully and stop automatically restarting the service: + + ```sh + systemctl --user stop mina + ``` -That command will show you the last 1000 lines and follow from there. +Manually restart the mina process: + + ```sh + systemctl --user restart mina + ``` + +Look at logs that show the last 1000 lines, and follow from there: + + ```sh + journalctl --user -u mina -n 1000 -f + ``` + +In some cases, you might need run the following command to view the logs: + + ```sh + journalctl --user-unit mina -n 1000 -f + ``` ### Docker When running your daemon using Docker, first ensure that your private key has the correct permissions. -``` -cd ~ -chmod 700 ~/keys -chmod 600 ~/keys/my-wallet -mkdir ~/.mina-config -``` + ```sh + cd ~ + chmod 700 ~/keys + chmod 600 ~/keys/my-wallet + mkdir ~/.mina-config + ``` -To produce blocks or otherwise customize the configuration for the mina daemon, create a file `~/.mina-env` containing the following: +To produce blocks or otherwise customize the configuration for the mina daemon, create a `~/.mina-env` files with the following: -``` -export MINA_PRIVKEY_PASS="My_V3ry_S3cure_Password" -LOG_LEVEL=Info -FILE_LOG_LEVEL=Debug -EXTRA_FLAGS=" --block-producer-key " -PEER_LIST_URL=https://storage.googleapis.com/seed-lists/mainnet_seeds.txt -``` -Ensure to replace with the full path to your block producer private key, for example, `/home/ubuntu/keys/my-wallet`. + ```sh + export MINA_PRIVKEY_PASS="My_V3ry_S3cure_Password" + LOG_LEVEL=Info + FILE_LOG_LEVEL=Debug + EXTRA_FLAGS=" --block-producer-key " + PEER_LIST_URL=https://storage.googleapis.com/seed-lists/mainnet_seeds.txt + ``` -If you do not intend to produce blocks then you can keep ~/.mina-env empty except for the PEER_LIST_URL. + Replace with the full path to your block producer private key. For example, `/home/ubuntu/keys/my-wallet`. -Now simply run the image with your keys, ~/.mina-env, and ~/.mina-config mounted into the container: +If you do not want to produce blocks, then provide only the `PEER_LIST_URL`. -``` +Now, run the image with your `~/.mina-config` and `~/.mina-env` files mounted into the container: + +```sh docker run --name mina -d \ -p 8302:8302 \ --restart=always \ @@ -158,43 +211,65 @@ minaprotocol/mina-daemon:1.3.1.2-25388a0-bullseye-mainnet \ daemon ``` -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 [#mentor-nodes](https://discord.com/channels/484437221055922177/746316198806814760) channel on Mina Protocol Discord or attach the `full ~/.mina-config/mina.log` to a GitHub issue and link the issue in discord. +## Checking connectivity + +Follow the logs: -Run `docker exec -it mina mina 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. + ```sh + docker logs -f mina + ``` -:::tip +If the node crashes, save the log output to a file: -If you encounter `[Warn] Shutdown before Mina instance was created, not saving a visualization` when attempting to run your Docker container, [increase the resources that the Docker container is allowed to use](https://docs.docker.com/config/containers/resource_constraints/). + ```sh + docker logs mina > mina-log.txt + ``` -::: + Post the output to the [#mentor-nodes](https://discord.com/channels/484437221055922177/746316198806814760) channel on Mina Protocol Discord or attach the full `~/.mina-config/mina.log` to a GitHub issue and link the issue in Discord. -## Checking connectivity +Monitor connectivity to the network: -Now that we've started up a node and are running the Mina daemon, open up another shell and run the following command: + ```sh + docker exec -it mina mina client status + ``` - mina client status +At least 10 peers are expected. Watch the block height and the max observed block height climb. :::tip -It may take up to a minute before `mina client status` connects to the daemon when first starting up. So if you see `Error: daemon not running. See mina daemon`, just a wait a bit and try again. +If you encounter `[Warn] Shutdown before Mina instance was created, not saving a visualization` when you attempt to run your Docker container, [increase the resources](https://docs.docker.com/config/containers/resource_constraints/) that the Docker container is allowed to use. ::: -Most likely we will see a response that include the fields below: +## Monitor the mina client status + +Monitor the mina client status in a different terminal window. + +Now that a node is started and running the Mina daemon, run: + + ```sh + mina client status + ``` + +When first starting up a node, it can take up to a minute before `mina client status` connects to the daemon. If you see `Error: daemon not running. See mina daemon`, just a wait a bit and try again. + +The expected response includes these fields: ... Peers: Total: 4 (...) ... Sync Status: Bootstrap -If you see `Sync Status: Bootstrap`, this means that the node is bootstrapping and needs to sync with the rest of the network. You may need to be patient here as this step might take some time for the node to get all the data it needs. +- `Sync Status: Bootstrap` means that the node is bootstrapping and needs to sync with the rest of the network. Be patient here as this step might take some time for the node to get all the data it needs. + +- After a while, the node connects to more peers and then moves into `Sync Status: Catchup` which gathers the most recent blocks and state while catching up to the the highest block. -After a while, your node should connect to more peers and then should move into `Sync Status: Catchup`, which means we're gathering the most recent blocks and state trying to catch up the the highest block. +- When sync status reaches `Synced` and the node is connected to 1 or more peers, the node is successfully connected to the network. A corresponding daemon log shows the sync status: `[Info] Mina daemon is now synced`. -When sync status reaches `Synced` and the node is connected to 1 or more peers, we will have successfully connected to the network. We will also see a corresponding daemon log once we've synced: `[Info] Mina daemon is now synced`. +- An issue with your port configuration can causethe `Bootstrap` state to persist for more than an hour. -If you the `Bootstrap` state persists for more than an hour, there may be an issue with your port configuration. +## Step up your game -## Stepping up your game +Now that you have a fully synced node, learn about some of the more advanced features of the daemon such as [Sending a payment](sending-a-payment) and [Staking & Delegating](staking-and-snarking). -Now that we have a fully synced node, we can learn about some of the more advanced features of the daemon such as [Sending a payment](sending-a-payment) and [Staking & Delegating](staking-and-snarking). And if you want to earn more tokens, check out the [Mina Foundation Delegation Program](foundation-delegation-program). +To earn MINA tokens, check out the [Mina Foundation Delegation Program](foundation-delegation-program). From 8efe53494007597b28e64e0e724c0d312ade9e33 Mon Sep 17 00:00:00 2001 From: barriebyron Date: Wed, 12 Jul 2023 11:31:20 -0400 Subject: [PATCH 3/6] remove obsolete duplicate topic --- docs/node-operators/archive-node/overview.mdx | 7 ------- 1 file changed, 7 deletions(-) delete mode 100644 docs/node-operators/archive-node/overview.mdx diff --git a/docs/node-operators/archive-node/overview.mdx b/docs/node-operators/archive-node/overview.mdx deleted file mode 100644 index e3f694026..000000000 --- a/docs/node-operators/archive-node/overview.mdx +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Overview DELETE OBSOLETE ---- - -# Archive Node Overview -now in archive-node.mdx - From a8a5415b88a4a04272016756e1a905a97c6fd609 Mon Sep 17 00:00:00 2001 From: barriebyron Date: Wed, 12 Jul 2023 11:43:56 -0400 Subject: [PATCH 4/6] add metadata to edited topics --- docs/node-operators/archive-redundancy.mdx | 8 ++++++++ docs/node-operators/connecting-to-devnet.mdx | 12 ++++++++++++ 2 files changed, 20 insertions(+) diff --git a/docs/node-operators/archive-redundancy.mdx b/docs/node-operators/archive-redundancy.mdx index eef31d85e..146f97d3c 100644 --- a/docs/node-operators/archive-redundancy.mdx +++ b/docs/node-operators/archive-redundancy.mdx @@ -1,6 +1,14 @@ --- title: Archive Redundancy hide_title: true +description: Steps to install mina and connect to the Devnet network. +keywords: + - mina historical archive data + - what is an archive node + - archive node redundancy + - mina historical lookup + - archive process + - how do I back up block data --- :::note diff --git a/docs/node-operators/connecting-to-devnet.mdx b/docs/node-operators/connecting-to-devnet.mdx index 0a0d3421b..756d2c7fa 100644 --- a/docs/node-operators/connecting-to-devnet.mdx +++ b/docs/node-operators/connecting-to-devnet.mdx @@ -1,5 +1,14 @@ --- title: Connect to Devnet +description: Steps to install mina and connect to the Devnet network. +keywords: + - how do I connect to the Devnet network + - what is a Devnet + - how do I test a mina node + - install mina + - start a mina node + - how do I check Devnet connectivity + - mina logs --- # Connect to Devnet @@ -61,6 +70,8 @@ To start a Mina node instance and connect to the Devnet network: mina daemon --peer-list-url https://storage.googleapis.com/seed-lists/devnet_seeds.txt ``` +The `--peer-list` argument specifies the the source file of seed peer addresses for the initial peer to connect to on the network. Mina is a [peer-to-peer](/glossary#peer-to-peer) protocol, so there is no dependence on a single centralized server. + ### Docker To run your daemon using Docker, create a directory on the host machine to mount as a volume: @@ -109,6 +120,7 @@ If the node crashes, save the log output to a file: ```sh docker logs mina > mina-log.txt ``` + Monitor connectivity to the network: ```sh From 2abc3393b325e4d5fb83272c71d6fc16c9f41f9d Mon Sep 17 00:00:00 2001 From: barriebyron Date: Wed, 12 Jul 2023 11:46:21 -0400 Subject: [PATCH 5/6] add metadata for block producer --- docs/node-operators/block-producers.mdx | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/node-operators/block-producers.mdx b/docs/node-operators/block-producers.mdx index a2b8b96c1..931ecbe1b 100644 --- a/docs/node-operators/block-producers.mdx +++ b/docs/node-operators/block-producers.mdx @@ -1,6 +1,15 @@ --- title: Block Producers hide_title: true +description: Steps to install mina and connect to the Devnet network. +keywords: + - role of block producer in Mina + - block producers + - how do I become a block producer + - coinbase rewards + - supercharged coinbase + - how to produce a block + - how to select a block producer --- :::note From a520f2c3d4372a3b63989d4e36a1676fbffba3a3 Mon Sep 17 00:00:00 2001 From: barriebyron Date: Wed, 12 Jul 2023 11:47:20 -0400 Subject: [PATCH 6/6] update block producer short desc --- docs/node-operators/block-producers.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/node-operators/block-producers.mdx b/docs/node-operators/block-producers.mdx index 931ecbe1b..9690c8c97 100644 --- a/docs/node-operators/block-producers.mdx +++ b/docs/node-operators/block-producers.mdx @@ -1,7 +1,7 @@ --- title: Block Producers hide_title: true -description: Steps to install mina and connect to the Devnet network. +description: The role of a block producer in Mina is to achieve consensus and provide security to the blockchain. keywords: - role of block producer in Mina - block producers