diff --git a/docs/content/_snippets/info-high-traffic.mdx b/docs/content/_snippets/info-high-traffic.mdx index 734ea92ab9e..9604fa56a15 100644 --- a/docs/content/_snippets/info-high-traffic.mdx +++ b/docs/content/_snippets/info-high-traffic.mdx @@ -2,6 +2,6 @@ It is suggested to use dedicated nodes/shared services rather than public endpoints for production apps with high traffic volume. -You can either run your own Full nodes, or outsource this to a professional infrastructure provider (preferred for apps that have high traffic). +You can either run your own full nodes, or outsource this to a professional infrastructure provider (preferred for apps that have high traffic). ::: \ No newline at end of file diff --git a/docs/content/_snippets/initialize-iota-client-cli.mdx b/docs/content/_snippets/initialize-iota-client-cli.mdx index 1b621052b49..7a0375b7eef 100644 --- a/docs/content/_snippets/initialize-iota-client-cli.mdx +++ b/docs/content/_snippets/initialize-iota-client-cli.mdx @@ -7,13 +7,13 @@ See [Publish a Package](../developer/getting-started/publish.mdx) for a more det Before publishing your code, you must first initialize the IOTA Client CLI, if you haven't already. To do so, in a terminal or console at the root directory of the project enter `iota client`. If you receive the following response, complete the remaining instructions: ``` -Config file ["/.iota/iota_config/client.yaml"] doesn't exist, do you want to connect to a IOTA Full node server [y/N]? +Config file ["/.iota/iota_config/client.yaml"] doesn't exist, do you want to connect to a IOTA full node server [y/N]? ``` Enter `y` to proceed. You receive the following response: ``` -IOTA Full node server URL (Defaults to IOTA Devnet if not specified) : +IOTA full node server URL (Defaults to IOTA Devnet if not specified) : ``` Leave this blank (press Enter). You receive the following response: diff --git a/docs/content/_snippets/warning-advanced-instructions-node-setup.mdx b/docs/content/_snippets/warning-advanced-instructions-node-setup.mdx index cc42330d620..f3173ef9f33 100644 --- a/docs/content/_snippets/warning-advanced-instructions-node-setup.mdx +++ b/docs/content/_snippets/warning-advanced-instructions-node-setup.mdx @@ -1,6 +1,6 @@ :::warning Advanced -These instructions are for setting up a Full node for network participation. If you just need a local development environment, -you should instead follow the instructions in [Create a Local IOTA Network](/developer/getting-started/local-network) to create a local Full node, validators, and faucet. +These instructions are for setting up a full node for network participation. If you just need a local development environment, +you should instead follow the instructions in [Create a Local IOTA Network](/developer/getting-started/local-network) to create a local full node, validators, and faucet. ::: \ No newline at end of file diff --git a/docs/content/developer/advanced/custom-indexer.mdx b/docs/content/developer/advanced/custom-indexer.mdx index 8dc697fd66f..a9d61d20a75 100644 --- a/docs/content/developer/advanced/custom-indexer.mdx +++ b/docs/content/developer/advanced/custom-indexer.mdx @@ -1,6 +1,6 @@ --- title: Custom Indexer -description: You can build custom indexers using the IOTA micro-data ingestion framework. To create an indexer, you subscribe to a checkpoint stream with full checkpoint content. Establishing a custom indexer helps improve latency, allows pruning the data of your IOTA Full node, and provides efficient assemblage of checkpoint data. +description: You can build custom indexers using the IOTA micro-data ingestion framework. To create an indexer, you subscribe to a checkpoint stream with full checkpoint content. Establishing a custom indexer helps improve latency, allows pruning the data of your IOTA full node, and provides efficient assemblage of checkpoint data. --- import Quiz from '@site/src/components/Quiz'; @@ -8,7 +8,7 @@ import questions from '/json/developer/advanced-topics/custom-indexer.json'; You can build custom indexers using the IOTA micro-data ingestion framework. To create an indexer, you subscribe to a checkpoint stream with full checkpoint content. This stream can be one of the publicly available streams from IOTA, one that you set up in your local environment, or a combination of the two. -Establishing a custom indexer helps improve latency, allows pruning the data of your IOTA Full node, and provides efficient assemblage of checkpoint data. +Establishing a custom indexer helps improve latency, allows pruning the data of your IOTA full node, and provides efficient assemblage of checkpoint data. ## Interface and Data Format @@ -61,9 +61,9 @@ This is suitable for setups with a single ingestion pipeline where progress trac ### Local Reader -Colocate the data ingestion daemon with a Full node and enable checkpoint dumping on the latter to set up a local stream source. After enabling, the Full node starts dumping executed checkpoints as files to a local directory, and the data ingestion daemon subscribes to changes in the directory through an inotify-like mechanism. This approach allows minimizing ingestion latency (checkpoint are processed immediately after a checkpoint executor on a Full node) and getting rid of dependency on an externally managed bucket. +Colocate the data ingestion daemon with a full node and enable checkpoint dumping on the latter to set up a local stream source. After enabling, the full node starts dumping executed checkpoints as files to a local directory, and the data ingestion daemon subscribes to changes in the directory through an inotify-like mechanism. This approach allows minimizing ingestion latency (checkpoint are processed immediately after a checkpoint executor on a full node) and getting rid of dependency on an externally managed bucket. -To enable, add the following to your [Full node configuration](../../operator/iota-full-node/overview.mdx) file: +To enable, add the following to your [full node configuration](../../operator/iota-full-node/overview.mdx) file: ```yaml checkpoint-executor-config: @@ -106,7 +106,7 @@ The concurrency parameter specifies how many threads the workflow uses. Having a ### Hybrid Mode -Specify both a local and remote store as a fallback to ensure constant data flow. The framework always prioritizes locally available checkpoint data over remote data. It's useful when you want to start utilizing your own Full node for data ingestion but need to partially backfill historical data or just have a failover. +Specify both a local and remote store as a fallback to ensure constant data flow. The framework always prioritizes locally available checkpoint data over remote data. It's useful when you want to start utilizing your own full node for data ingestion but need to partially backfill historical data or just have a failover. ```rust executor.run( PathBuf::from("./chk".to_string()), // path to a local directory diff --git a/docs/content/developer/advanced/iota-repository.mdx b/docs/content/developer/advanced/iota-repository.mdx index c9ed46a047e..8bd6dbbf786 100644 --- a/docs/content/developer/advanced/iota-repository.mdx +++ b/docs/content/developer/advanced/iota-repository.mdx @@ -26,7 +26,7 @@ overview of the most important folders: IOTA. - [docker](https://github.com/iotaledger/iota/tree/develop/docker): Contains the docker files needed to spin up a node, an - indexer, a Full node, or other services. + indexer, a full node, or other services. - [docs](https://github.com/iotaledger/iota/tree/develop/docs): Contains this documentation and the source for this site. - [examples](https://github.com/iotaledger/iota/tree/develop/examples): Contains examples of apps written for IOTA and @@ -59,7 +59,7 @@ The following primary directories offer a good starting point for exploring the 0x2, 0x3). - [iota-network](https://github.com/iotaledger/iota/tree/develop/crates/iota-network) - Networking interfaces. -- [iota-node](https://github.com/iotaledger/iota/tree/develop/crates/iota-node) - Validator and Full node software. +- [iota-node](https://github.com/iotaledger/iota/tree/develop/crates/iota-node) - Validator and full node software. - [iota-protocol-config](https://github.com/iotaledger/iota/tree/develop/crates/iota-protocol-config) - On-chain system configuration and limits. - [iota-sdk](https://github.com/iotaledger/iota/tree/develop/crates/iota-sdk) - The IOTA Rust SDK. diff --git a/docs/content/developer/cryptography.mdx b/docs/content/developer/cryptography.mdx index 9dd0983de3a..c6de2035168 100644 --- a/docs/content/developer/cryptography.mdx +++ b/docs/content/developer/cryptography.mdx @@ -15,7 +15,7 @@ Go to [Transaction Authentication](./cryptography/transaction-auth.mdx). ## Checkpoint Verification Checkpoints define the history of the IOTA blockchain, similarly to how blocks define the history of traditional blockchains like Bitcoin or Ethereum. -For Full nodes and validators to trust a checkpoint, they must first verify it. Verification ensures that the checkpoint is a true checkpoint that the IOTA validator committee created. +For full nodes and validators to trust a checkpoint, they must first verify it. Verification ensures that the checkpoint is a true checkpoint that the IOTA validator committee created. Go to [Checkpoint Verification](./cryptography/checkpoint-verification.mdx). diff --git a/docs/content/developer/cryptography/checkpoint-verification.mdx b/docs/content/developer/cryptography/checkpoint-verification.mdx index 64f3d52e791..a1689035dcf 100644 --- a/docs/content/developer/cryptography/checkpoint-verification.mdx +++ b/docs/content/developer/cryptography/checkpoint-verification.mdx @@ -1,6 +1,6 @@ --- title: Checkpoint Verification -description: On the IOTA network, checkpoints define the history of the blockchain. Checkpoint verification is how Full nodes and other clients guarantee their state is exactly the same as the IOTA network. +description: On the IOTA network, checkpoints define the history of the blockchain. Checkpoint verification is how full nodes and other clients guarantee their state is exactly the same as the IOTA network. --- import Quiz from '@site/src/components/Quiz'; @@ -14,15 +14,15 @@ Checkpoints contain: - A list of all the transaction digests (and the corresponding transaction effects digests) that are included in the checkpoint. - A set of signatures from a quorum (more than 2/3rds) of the validators that formed the committee at the time the checkpoint was created. -Both validators and Full nodes consume checkpoints to remain synchronized with the network. +Both validators and full nodes consume checkpoints to remain synchronized with the network. ## Checkpoint verification -For Full nodes and validators to trust a checkpoint, they must first verify it. Verification ensures that the checkpoint is a true checkpoint that the IOTA validator committee created. +For full nodes and validators to trust a checkpoint, they must first verify it. Verification ensures that the checkpoint is a true checkpoint that the IOTA validator committee created. Checkpoint verification requires two interdependent pieces: -1. Assuming that the Full node (or other client) has the public keys of the validator committee that created the checkpoint, it can check the signatures on the checkpoint for validity. +1. Assuming that the full node (or other client) has the public keys of the validator committee that created the checkpoint, it can check the signatures on the checkpoint for validity. Checkpoints are signed by the aggregated BLS signatures of a quorum of the committee. If the signatures are valid, the client now knows that the checkpoint was created by the validator committee, and not by some other party. @@ -46,11 +46,11 @@ This allows the client to eventually verify all checkpoints up to the present ti After a client verifies a checkpoint, what can it do with that information? -As mentioned earlier, a checkpoint contains a list of transactions so a Full node, for instance, can begin fetching and executing those transactions. Because the transactions are identified by their digest (a cryptographic hash), the client can be sure that the transactions it executes have not been altered. +As mentioned earlier, a checkpoint contains a list of transactions so a full node, for instance, can begin fetching and executing those transactions. Because the transactions are identified by their digest (a cryptographic hash), the client can be sure that the transactions it executes have not been altered. Additionally, the checkpoint contains the effects digests of each transaction. The effects digest is the cryptographic hash of the `TransactionEffects`, which is itself a structure that lists all of the inputs and outputs of a transaction. It includes the digests of all objects that were written by the transaction. -This allows a Full node to verify that it has obtained the same execution results as those that the validators attested to when signing the checkpoint. +This allows a full node to verify that it has obtained the same execution results as those that the validators attested to when signing the checkpoint. -By executing checkpoints, and verifying transaction outputs, a Full node can build up the entire state of the IOTA network (that is, the collection of objects in the network) and trust that every byte of every object is correct. +By executing checkpoints, and verifying transaction outputs, a full node can build up the entire state of the IOTA network (that is, the collection of objects in the network) and trust that every byte of every object is correct. \ No newline at end of file diff --git a/docs/content/developer/exchange-integration/exchange-integration.mdx b/docs/content/developer/exchange-integration/exchange-integration.mdx index e3232b4d09c..29d50b7477b 100644 --- a/docs/content/developer/exchange-integration/exchange-integration.mdx +++ b/docs/content/developer/exchange-integration/exchange-integration.mdx @@ -11,13 +11,13 @@ This topic describes how to integrate IOTA, the token native to the IOTA network ## Requirements to configure a IOTA integration The requirements to configure a IOTA integration include: - - A IOTA Full node. You can operate your own IOTA Full node or use a Full node from a node operator. - - Suggested hardware requirements to run a IOTA Full node: + - A IOTA full node. You can operate your own IOTA full node or use a full node from a node operator. + - Suggested hardware requirements to run a IOTA full node: - CPU: 8 physical cores / 16 vCPUs - RAM: 128 GB - Storage (SSD): 4 TB NVMe drive -For best results, run IOTA Full nodes on Linux. IOTA supports the Ubuntu and Debian distributions. You can also fun a Full node on macOS. +For best results, run IOTA full nodes on Linux. IOTA supports the Ubuntu and Debian distributions. You can also fun a full node on macOS. ## Local testing @@ -25,7 +25,7 @@ You can develop and test your integration using a local development server. It w ## Configure a IOTA Full node -You can set up and configure a [IOTA Full node](../../operator/iota-full-node/overview.mdx) using Docker or directly from source code in the IOTA GitHub repository. +You can set up and configure a [IOTA full node](../../operator/iota-full-node/overview.mdx) using Docker or directly from source code in the IOTA GitHub repository. ## Set up IOTA addresses @@ -96,7 +96,7 @@ You can track balance changes by calling `iotax_getBalance` at predefined interv ### Using cURL -The following bash example demonstrates how to use `iotax_getBalance` for address `0x849d63687330447431a2e76fecca4f3c10f6884ebaa9909674123c6c662612a3`. If you use a network other than Devnet, replace the value for `rpc` with the URL to the appropriate Full node. +The following bash example demonstrates how to use `iotax_getBalance` for address `0x849d63687330447431a2e76fecca4f3c10f6884ebaa9909674123c6c662612a3`. If you use a network other than Devnet, replace the value for `rpc` with the URL to the appropriate full node. ```bash diff --git a/docs/content/developer/iota-101/transactions/sponsored-transactions/use-sponsored-transactions.mdx b/docs/content/developer/iota-101/transactions/sponsored-transactions/use-sponsored-transactions.mdx index 59a8fd18849..15ea7d9146d 100644 --- a/docs/content/developer/iota-101/transactions/sponsored-transactions/use-sponsored-transactions.mdx +++ b/docs/content/developer/iota-101/transactions/sponsored-transactions/use-sponsored-transactions.mdx @@ -26,7 +26,7 @@ To set up a user-initiated sponsored transaction, follow these steps: 2. **User sends `GasLessTransactionData` to the sponsor**: The user forwards the transaction data to the sponsor. 3. **Sponsor validates and signs**: The sponsor reviews the transaction, constructs `TransactionData` with gas fees, and signs it. 4. **Sponsor returns signed transaction**: The sponsor sends the signed `TransactionData` and their `Signature` back to the user. -5. **User verifies and signs**: The user verifies the transaction, signs the `TransactionData`, and submits the dual-signed transaction to the IOTA network via a Full node or through the sponsor. +5. **User verifies and signs**: The user verifies the transaction, signs the `TransactionData`, and submits the dual-signed transaction to the IOTA network via a full node or through the sponsor. ### Understanding `GasLessTransactionData` @@ -96,7 +96,7 @@ Use the API endpoint to receive dual-signed `SenderSignedData` and return the tr pub fn submit_dual_signed_transaction(dual_signed_data: SenderSignedData) -> Result<(Transaction, CertifiedTransactionEffects), Error>; ``` -For user and sponsor-initiated transactions, users can submit the dual-signed transaction either through the sponsor or directly to a Full node. +For user and sponsor-initiated transactions, users can submit the dual-signed transaction either through the sponsor or directly to a full node. #### Data Structures for Sponsored Transactions diff --git a/docs/content/developer/standards/display.mdx b/docs/content/developer/standards/display.mdx index 82db8ce3784..c06dea9050b 100644 --- a/docs/content/developer/standards/display.mdx +++ b/docs/content/developer/standards/display.mdx @@ -12,7 +12,7 @@ Use a `Publisher` object that you own to set `iota::display` for a type. In IOTA Move, `Display` represents an object that specifies a set of named templates for the type `T`. For example, for a type `0x2::hero::Hero` the display syntax is: `Display<0x2::hero::Hero>`. -IOTA Full nodes process all objects of the type `T` by matching the `Display` definition, and return the processed result when you query an object with the `{ showDisplay: true }` setting in the query. +IOTA full nodes process all objects of the type `T` by matching the `Display` definition, and return the processed result when you query an object with the `{ showDisplay: true }` setting in the query. ## Display properties diff --git a/docs/content/operator/archives.mdx b/docs/content/operator/archives.mdx index 921557b83bb..79c426fb1fe 100644 --- a/docs/content/operator/archives.mdx +++ b/docs/content/operator/archives.mdx @@ -1,14 +1,14 @@ --- title: IOTA Archives -description: The archive is a historical record of all transactions on IOTA. Enable archiving on your Full nodes as a best practice. +description: The archive is a historical record of all transactions on IOTA. Enable archiving on your full nodes as a best practice. --- import Quiz from '@site/src/components/Quiz'; import questions from '/json/node-operators/archives.json'; -An IOTA archive is a history of all transaction data on IOTA, trailing behind the latest checkpoint by 10 minutes. As an IOTA node operator, you can write this history to an object store like S3, GCS, or similar for safe keeping. Saving this archive data is considered a best practice because IOTA prunes transactions on Full nodes to remove historical transactions and their effects. Peer nodes, for example, might not catch up with all transactions and effects through synchronization if they lag behind the current epoch by more than the latest few epochs. Instead of relying on synchronization, peer nodes can fallback to downloading this information from an archive. +An IOTA archive is a history of all transaction data on IOTA, trailing behind the latest checkpoint by 10 minutes. As an IOTA node operator, you can write this history to an object store like S3, GCS, or similar for safe keeping. Saving this archive data is considered a best practice because IOTA prunes transactions on full nodes to remove historical transactions and their effects. Peer nodes, for example, might not catch up with all transactions and effects through synchronization if they lag behind the current epoch by more than the latest few epochs. Instead of relying on synchronization, peer nodes can fallback to downloading this information from an archive. -IOTA Archival nodes (Full nodes that write to an archive) don't store historical state on local storage and don't help query historical data. They serve the purpose of enabling peer nodes to catch up to the latest checkpoint and are useful for auditing and verifying the complete history of all transactions on the network. +IOTA Archival nodes (full nodes that write to an archive) don't store historical state on local storage and don't help query historical data. They serve the purpose of enabling peer nodes to catch up to the latest checkpoint and are useful for auditing and verifying the complete history of all transactions on the network. ## Create an Archival node diff --git a/docs/content/operator/data-management.mdx b/docs/content/operator/data-management.mdx index 9cab1da78c9..19a123687e5 100644 --- a/docs/content/operator/data-management.mdx +++ b/docs/content/operator/data-management.mdx @@ -1,29 +1,29 @@ --- title: Data Management -description: A high-level description of data management on the IOTA network that you can use to optimize your IOTA Full node configuration. +description: A high-level description of data management on the IOTA network that you can use to optimize your IOTA full node configuration. --- import Quiz from '@site/src/components/Quiz'; import questions from '/json/node-operators/data-management.json'; -Managing the data on your IOTA Full node is critical to ensuring a healthy IOTA network. This topic provides a high-level description of data management on IOTA Full nodes that you can use to optimize your Full node configuration. For more information about IOTA Full nodes, such as pruning policies and archival settings, see [Run an IOTA Full Node](iota-full-node/overview.mdx). +Managing the data on your IOTA full node is critical to ensuring a healthy IOTA network. This topic provides a high-level description of data management on IOTA full nodes that you can use to optimize your full node configuration. For more information about IOTA full nodes, such as pruning policies and archival settings, see [Run an IOTA Full Node](iota-full-node/overview.mdx). ## Basic IOTA Full node functionality -The minimal version of an IOTA Full node executes all of the transactions IOTA validators commit. IOTA Full nodes also orchestrate the submitting of new transactions to the system: +The minimal version of an IOTA full node executes all of the transactions IOTA validators commit. IOTA full nodes also orchestrate the submitting of new transactions to the system: -![Basic IOTA Full node functionality](/img/operator/data-management/fn-basic-functionality.png "A diagram that shows the operations of a basic IOTA Full node.") +![Basic IOTA full node functionality](/img/operator/data-management/fn-basic-functionality.png "A diagram that shows the operations of a basic IOTA full node.") -The preceding image shows how data flows through a Full node: +The preceding image shows how data flows through a full node: -1. **`State sync` protocol:** An IOTA Full node performs the following to achieve state synchronization: +1. **`State sync` protocol:** An IOTA full node performs the following to achieve state synchronization: - Retrieves the information about the committed checkpoints via the p2p gossip-like protocol - Executes the transactions locally to verify that effects match the effects certified by the quorum of the validators - Updates the local state with the latest object values accordingly. -2. **RPCs:** An IOTA Full node exposes IOTA RPC endpoints for querying the latest state of the system, including both the latest state metadata (such as, `iota_getProtocolConfig`), and the latest state object data (`iota_getObject)`. -3. **Transaction submission:** Each IOTA Full node orchestrates transaction submission to the quorum of the IOTA Validators, and, optionally if configured, locally executes the finalized transactions (called fast path execution), which circumvents the wait for checkpoint synchronization. +2. **RPCs:** An IOTA full node exposes IOTA RPC endpoints for querying the latest state of the system, including both the latest state metadata (such as, `iota_getProtocolConfig`), and the latest state object data (`iota_getObject)`. +3. **Transaction submission:** Each IOTA full node orchestrates transaction submission to the quorum of the IOTA Validators, and, optionally if configured, locally executes the finalized transactions (called fast path execution), which circumvents the wait for checkpoint synchronization. -## IOTA Full node Data and RPC types +## IOTA full node Data and RPC types An IOTA Full Node stores multiple categories of data in its permanent store. @@ -33,15 +33,15 @@ The per-epoch IOTA store is beyond the scope of this topic. IOTA uses the per-ep ::: -IOTA Full nodes store the following types of data: +IOTA full nodes store the following types of data: -1. **Transactions with associated effects and events:** IOTA uses a unique transaction digest to retrieve information about a transaction, including its effects and emitted events. IOTA Full nodes don't require the historic transaction information for basic Full node operations. To conserve disk space, you can enable pruning to remove this historical data. +1. **Transactions with associated effects and events:** IOTA uses a unique transaction digest to retrieve information about a transaction, including its effects and emitted events. IOTA full nodes don't require the historic transaction information for basic full node operations. To conserve disk space, you can enable pruning to remove this historical data. 2. **Checkpoints:** IOTA groups committed transactions in checkpoints, and then uses those checkpoints to achieve state synchronization. Checkpoints keep transaction digests that contain additional integrity metadata. -IOTA Full nodes don't require data from checkpoints to execute and submit transactions, so you can configure pruning for this data as well. -3. **Objects:** Transactions that mutate objects create new object versions. Each object has a unique pair of `(objectId, version)` used to identify the object. IOTA Full nodes don't require historic object versions to execute and submit transactions, so you can configure your Full node to also prune this data. -4. **Indexing information:** A Full node default configuration is to post-process the committed transactions: it indexes the committed information to enable efficient aggregation and filtering queries. For example, the indexing can be useful for retrieving all the historic transactions of a given sender, or finding all the objects owned by an address. +IOTA full nodes don't require data from checkpoints to execute and submit transactions, so you can configure pruning for this data as well. +3. **Objects:** Transactions that mutate objects create new object versions. Each object has a unique pair of `(objectId, version)` used to identify the object. IOTA full nodes don't require historic object versions to execute and submit transactions, so you can configure your full node to also prune this data. +4. **Indexing information:** A full node default configuration is to post-process the committed transactions: it indexes the committed information to enable efficient aggregation and filtering queries. For example, the indexing can be useful for retrieving all the historic transactions of a given sender, or finding all the objects owned by an address. -IOTA Full nodes support more than 40 RPC types that includes the following categories: +IOTA full nodes support more than 40 RPC types that includes the following categories: * **General metadata**, such as `iota_getProtocolConfig` and `iota_getChainIdentifier`. These requests don't depend on additional indexing and don't require historic data to process. * **Direct lookups**, such as `iota_getObject`, `iota_getEvents`. These requests don't depend on additional indexing, but require historic data in some cases, such as `iota_tryGetPastObject` and `iota_getTransactionBlock`. @@ -49,7 +49,7 @@ IOTA Full nodes support more than 40 RPC types that includes the following categ :::info -IOTA plans to migrate the RPC endpoints that require additional indexing away from IOTA Full nodes in the near future. This plan decouples the storage that is backing transaction execution from the storage that is better suited for data indexing. +IOTA plans to migrate the RPC endpoints that require additional indexing away from IOTA full nodes in the near future. This plan decouples the storage that is backing transaction execution from the storage that is better suited for data indexing. ::: @@ -63,15 +63,15 @@ The current archival storage format doesn't include historic object versions. ::: -As a Full node operator, you can [enable archival fallback for your Full node](./archives.mdx#set-up-archival-fallback) by specifying the URL to upload archival data. To ensure a healthy network, we encourage the IOTA community to set up additional archives to ensure archival data availability across the network. In a typical configuration, an archive trails behind the latest checkpoint by approximately 10 minutes. +As a full node operator, you can [enable archival fallback for your full node](./archives.mdx#set-up-archival-fallback) by specifying the URL to upload archival data. To ensure a healthy network, we encourage the IOTA community to set up additional archives to ensure archival data availability across the network. In a typical configuration, an archive trails behind the latest checkpoint by approximately 10 minutes. A Full Node that starts from scratch can replay (and thus re-verify) transactions that occurred since IOTA genesis from the given archive via [configuring Archival Fallback](./archives.mdx#set-up-archival-fallback) in the `fullnode.yaml` configuration file to point to the S3 bucket that stores the archive. -An IOTA Full node that fails to retrieve checkpoints from its peers via state sync protocol falls back to downloading the missing checkpoints from its pre-configured archive. This fallback enables a Full node to catch up with the rest of the system regardless of the pruning policies of its peers. +An IOTA full node that fails to retrieve checkpoints from its peers via state sync protocol falls back to downloading the missing checkpoints from its pre-configured archive. This fallback enables a full node to catch up with the rest of the system regardless of the pruning policies of its peers. -## IOTA Full node pruning policies +## IOTA full node pruning policies -As described previously, sustainable disk usage requires IOTA Full nodes to prune the information about historic object versions as well as historic transactions with the corresponding effects and events, including old checkpoint data. +As described previously, sustainable disk usage requires IOTA full nodes to prune the information about historic object versions as well as historic transactions with the corresponding effects and events, including old checkpoint data. Both transaction and object pruners run in the background. The logical deletion of entries from RocksDB ultimately triggers the physical compaction of data on disk, which is governed by RocksDB background jobs: the pruning effect on disk usage is not immediate and might take multiple days. @@ -89,22 +89,22 @@ To learn more about transaction pruning policies, see [Transaction pruning](iot ### Set an archiving watermark -In case your Full node is configured to upload committed information to an archive, you should ensure that pruning doesn't occur until after the corresponding data is uploaded. To do so, set the `use-for-pruning-watermark: true` in the Fullnode.yaml file as described in [Archival fallback](./archives.mdx#set-up-archival-fallback). +In case your full node is configured to upload committed information to an archive, you should ensure that pruning doesn't occur until after the corresponding data is uploaded. To do so, set the `use-for-pruning-watermark: true` in the Fullnode.yaml file as described in [Archival fallback](./archives.mdx#set-up-archival-fallback). -## IOTA Full node key-value store backup +## IOTA full node key-value store backup -To enable historic data queries for the IOTA Full nodes that prune old transactional data, Full node RPC implementation is configured to fallback for querying missing transactional data from a remote store. +To enable historic data queries for the IOTA full nodes that prune old transactional data, full node RPC implementation is configured to fallback for querying missing transactional data from a remote store. -If the information about the transaction digest, effects, events, or checkpoints is not available locally, a Full node automatically retrieves the historical data from a cloud-based key-value store (currently managed by the IOTA Foundation). Note that the current key-value store implementation keeps historic transactional data only: we plan to provide support for a similar setup for retrieving the historic object versions in a future release. +If the information about the transaction digest, effects, events, or checkpoints is not available locally, a full node automatically retrieves the historical data from a cloud-based key-value store (currently managed by the IOTA Foundation). Note that the current key-value store implementation keeps historic transactional data only: we plan to provide support for a similar setup for retrieving the historic object versions in a future release. ## Pruning policy examples -Use the examples in this section to configure your IOTA Full node. You can copy the examples, and then, optionally, modify the values as appropriate for your environment. +Use the examples in this section to configure your IOTA full node. You can copy the examples, and then, optionally, modify the values as appropriate for your environment. -### Minimal Full node +### Minimal Full Node -This configuration keeps disk usage to a minimum. A Full node with this configuration cannot answer queries that require indexing or historic data. +This configuration keeps disk usage to a minimum. A full node with this configuration cannot answer queries that require indexing or historic data. ```yaml # Do not generate or maintain indexing of IOTA data on the node @@ -129,7 +129,7 @@ authority-store-pruning-config: ### Full Node with indexing but no history -This setup manages secondary indexing in addition to the latest state, but aggressively prunes historic data. A Full node with this configuration: +This setup manages secondary indexing in addition to the latest state, but aggressively prunes historic data. A full node with this configuration: - Answers RPC queries that require indexing, like `iotax_getBalance()`. - Answers RPC queries that require historic transactions via a fallback to retrieve the data from a remote key-value store: `iota_getTransactionBlock()`. @@ -156,9 +156,9 @@ authority-store-pruning-config: ### Full Node with full object history but pruned transaction history -This configuration manages the full object history while still pruning historic transactions. A Full node with this configuration can answer all historic and indexing queries (using the transaction query fallback for transactional data), including the ones that require historic objects such as the `showBalanceChanges` filter of `iota_getTransactionBlock()`. +This configuration manages the full object history while still pruning historic transactions. A full node with this configuration can answer all historic and indexing queries (using the transaction query fallback for transactional data), including the ones that require historic objects such as the `showBalanceChanges` filter of `iota_getTransactionBlock()`. -The main caveat is that the current setup enables **transaction pruner** to go ahead of **object pruner**. The object pruner might not be able to properly clean up the objects modified by the transactions that have been already pruned. You should closely monitor the disk space growth on a Full node with this configuration. +The main caveat is that the current setup enables **transaction pruner** to go ahead of **object pruner**. The object pruner might not be able to properly clean up the objects modified by the transactions that have been already pruned. You should closely monitor the disk space growth on a full node with this configuration. In addition to the regular (pruned) snapshots, the IOTA Foundation also maintains special RocksDB snapshots with full history of object versions available for the operators using this configuration. diff --git a/docs/content/operator/genesis.mdx b/docs/content/operator/genesis.mdx index c2f87446c06..3abf6a21725 100644 --- a/docs/content/operator/genesis.mdx +++ b/docs/content/operator/genesis.mdx @@ -2,7 +2,7 @@ title: Genesis --- -Genesis is the initial state of the IOTA blockchain. To launch a network, the initial committee of validators collaborate by providing their validator information (public keys, network addresses, and so on) to a shared workspace. After all of the initial validators have contributed their information, IOTA generates the initial, unsigned genesis checkpoint (checkpoint with sequence number 0) and each validator provides their signature. IOTA aggregates these signatures to form a _certificate_ on the genesis checkpoint. IOTA bundles this checkpoint, as well as the initial objects, together into a single genesis.blob file that is used to initialize the state when running the `iota-node` binary for both validators and Full nodes. +Genesis is the initial state of the IOTA blockchain. To launch a network, the initial committee of validators collaborate by providing their validator information (public keys, network addresses, and so on) to a shared workspace. After all of the initial validators have contributed their information, IOTA generates the initial, unsigned genesis checkpoint (checkpoint with sequence number 0) and each validator provides their signature. IOTA aggregates these signatures to form a _certificate_ on the genesis checkpoint. IOTA bundles this checkpoint, as well as the initial objects, together into a single genesis.blob file that is used to initialize the state when running the `iota-node` binary for both validators and full nodes. ## Genesis blob locations diff --git a/docs/content/operator/indexer-functions.mdx b/docs/content/operator/indexer-functions.mdx index c676ed63c3b..684c7b06d5d 100644 --- a/docs/content/operator/indexer-functions.mdx +++ b/docs/content/operator/indexer-functions.mdx @@ -10,7 +10,7 @@ The IOTA Indexer is a node data service that serves data from the IOTA protocol, ## Functions The IOTA Indexer provides three main functionalities: -- Ingest data from a Full node to a relational database. Data on Full nodes is stored as BCS bytes in an embedded RocksDB database, thus the query capabilities are very limited. The indexer pulls checkpoint blob data, schematizing them into various tables like objects, transactions, and so on, with proper indices. +- Ingest data from a full node to a relational database. Data on full nodes is stored as BCS bytes in an embedded RocksDB database, thus the query capabilities are very limited. The indexer pulls checkpoint blob data, schematizing them into various tables like objects, transactions, and so on, with proper indices. - Serve online transaction processing (OLTP) RPC requests. With data in relational databases, IOTA indexer spins a stateless reader binary as JSON RPC server with an [interface](/references/iota-api). - Other than OLTP data ingestion and requests, the Indexer also supports some analytical data ingestion like transactions per second (TPS) and daily active user (DAU) metrics. diff --git a/docs/content/operator/iota-full-node/monitoring-and-pruning.mdx b/docs/content/operator/iota-full-node/monitoring-and-pruning.mdx index 0dd0a5d15f8..4414e18b3f9 100644 --- a/docs/content/operator/iota-full-node/monitoring-and-pruning.mdx +++ b/docs/content/operator/iota-full-node/monitoring-and-pruning.mdx @@ -8,7 +8,7 @@ import questions from '/json/node-operators/iota-full-node/pruning.json'; ## Monitoring -Monitor your Full node using the instructions in the [Node Monitoring and Metrics section](../telemetry/iota-metrics.mdx). +Monitor your full node using the instructions in the [Node Monitoring and Metrics section](../telemetry/iota-metrics.mdx). The default metrics port is `9184`. To change the port, edit your `fullnode.yaml` file. @@ -39,9 +39,9 @@ authority-store-pruning-config: # previous to the current epoch. In general, when set to N (where N >= 1), IOTA prunes # only object versions from checkpoints up to `current - N` epoch. # It is therefore possible to have multiple versions of an object present - # in the database. This setting is recommended for IOTA Full nodes as they might need to serve + # in the database. This setting is recommended for IOTA full nodes as they might need to serve # RPC requests that require looking up objects by ID and Version (rather than just the latest - # version). However, if your Full node does not serve RPC requests you should then also enable + # version). However, if your full node does not serve RPC requests you should then also enable # aggressive pruning. num-epochs-to-retain: 0 # Advanced setting: Maximum number of checkpoints to prune in a batch. The default @@ -58,7 +58,7 @@ IOTA periodically creates checkpoints. Each checkpoint contains the transactions IOTA performs transaction pruning in the background after checkpoints complete. -You can enable transaction pruning for your Full node or Validator node by adding `num-epochs-to-retain-for-checkpoints` +You can enable transaction pruning for your full node or Validator node by adding `num-epochs-to-retain-for-checkpoints` to the `authority-store-pruning-config` config for the node: ```yaml @@ -71,7 +71,7 @@ authority-store-pruning-config: # Number of epochs to wait before performing transaction pruning. # When this is N (where N >= 2), IOTA prunes transactions and effects from # checkpoints up to the `current - N` epoch. IOTA never prunes transactions and effects from the current and - # immediately prior epoch. N = 2 is a recommended setting for IOTA Validator nodes and IOTA Full nodes that don't + # immediately prior epoch. N = 2 is a recommended setting for IOTA Validator nodes and IOTA full nodes that don't # serve RPC requests. num-epochs-to-retain-for-checkpoints: 2 # Ensures that individual database files periodically go through the compaction process. diff --git a/docs/content/operator/iota-full-node/overview.mdx b/docs/content/operator/iota-full-node/overview.mdx index cdd63215d70..da11b6eb69d 100644 --- a/docs/content/operator/iota-full-node/overview.mdx +++ b/docs/content/operator/iota-full-node/overview.mdx @@ -11,19 +11,19 @@ import WarningAdvanced from './../../_snippets/warning-advanced-instructions-nod -IOTA Full nodes validate blockchain activities, including transactions, checkpoints, and epoch changes. Each Full node stores and services the queries for the blockchain state and history. +IOTA full nodes validate blockchain activities, including transactions, checkpoints, and epoch changes. Each full node stores and services the queries for the blockchain state and history. -This role enables validators to focus on servicing and processing transactions. When a validator commits a new set of transactions (or a block of transactions), the validator pushes that block to all connected Full nodes that then service the queries from clients. +This role enables validators to focus on servicing and processing transactions. When a validator commits a new set of transactions (or a block of transactions), the validator pushes that block to all connected full nodes that then service the queries from clients. ## Features -IOTA Full nodes: +IOTA full nodes: - Track and verify the state of the blockchain, independently and locally. - Serve read requests from clients. ## State Synchronization -IOTA Full nodes sync with validators to receive new transactions on the network. +IOTA full nodes sync with validators to receive new transactions on the network. A transaction requires a few round trips to 2f+1 validators to form a transaction _certificate_ (TxCert). @@ -35,13 +35,13 @@ This synchronization process includes: 1. Making sure that 2f+1 validators recognize the transaction and that it reaches finality. 1. Executing the transaction locally and updating the local DB. -This synchronization process requires listening to at a minimum 2f+1 validators to ensure that a Full node has properly processed all new transactions. IOTA will improve the synchronization process with the introduction of checkpoints and the ability to synchronize with other Full nodes. +This synchronization process requires listening to at a minimum 2f+1 validators to ensure that a full node has properly processed all new transactions. IOTA will improve the synchronization process with the introduction of checkpoints and the ability to synchronize with other full nodes. ## Architecture -An IOTA Full node is essentially a read-only view of the network state. Unlike validator nodes, Full nodes cannot sign transactions, although they can validate the integrity of the chain by re-executing transactions that a quorum of validators previously committed. +An IOTA full node is essentially a read-only view of the network state. Unlike validator nodes, full nodes cannot sign transactions, although they can validate the integrity of the chain by re-executing transactions that a quorum of validators previously committed. -Today, an IOTA Full node maintains the full history of the chain. +Today, an IOTA full node maintains the full history of the chain. Validator nodes store only the latest transactions on the frontier of the object graph (for example, transactions with >0 unspent output objects). diff --git a/docs/content/operator/iota-full-node/source.mdx b/docs/content/operator/iota-full-node/source.mdx index fc8f03947a2..63307bd797f 100644 --- a/docs/content/operator/iota-full-node/source.mdx +++ b/docs/content/operator/iota-full-node/source.mdx @@ -1,5 +1,5 @@ --- -description: Learn how to set up an IOTA Full node from source. +description: Learn how to set up an IOTA full node from source. title: Build From Source --- import Quiz from '@site/src/components/Quiz'; @@ -13,7 +13,7 @@ import NodeHardwareRequirements from './../../_snippets/node-hardware-requiremen ## Software requirements -IOTA recommends running IOTA Full nodes on Linux. IOTA supports the Ubuntu and Debian distributions. You can also run an IOTA Full node on macOS. +IOTA recommends running IOTA full nodes on Linux. IOTA supports the Ubuntu and Debian distributions. You can also run an IOTA full node on macOS. Make sure to [update Rust](https://www.rust-lang.org/tools/install). @@ -63,7 +63,7 @@ Open a terminal or console in the `iota` directory you downloaded in the previou cargo install ``` -2. Make a copy of the [Full node YAML template](https://github.com/iotaledger/iota/blob/develop/crates/iota-config/data/fullnode-template.yaml): +2. Make a copy of the [full node YAML template](https://github.com/iotaledger/iota/blob/develop/crates/iota-config/data/fullnode-template.yaml): ```bash cp crates/iota-config/data/fullnode-template.yaml fullnode.yaml @@ -114,7 +114,7 @@ cp crates/iota-config/data/fullnode-template.yaml fullnode.yaml 5. (Optional, skip this step to accept the default paths to resources). Edit the `fullnode.yaml` file to use custom paths. - 1. Update the `db-path` field with the path to the Full node database. + 1. Update the `db-path` field with the path to the full node database. ```yaml db-path: "/db-files/iota-fullnode"` ``` @@ -138,7 +138,7 @@ cargo run --release --bin iota-node ## 4. Start Services -At this point, your IOTA Full node is ready to connect to the IOTA network. +At this point, your IOTA full node is ready to connect to the IOTA network. 1. Open a terminal or console to the `iota` directory and run the following command to start your node: @@ -148,9 +148,9 @@ At this point, your IOTA Full node is ready to connect to the IOTA network. 2. (Optional) Publish/subscribe to notifications using JSON-RPC via websocket. -If your setup is successful, your IOTA Full node is now connected to the appropriate network. +If your setup is successful, your IOTA full node is now connected to the appropriate network. -Your Full node serves the read endpoints of the IOTA JSON-RPC API at: `http://127.0.0.1:9000`. +Your full node serves the read endpoints of the IOTA JSON-RPC API at: `http://127.0.0.1:9000`. ## Troubleshooting @@ -177,13 +177,13 @@ metrics-address: "0.0.0.0:9180" ## Update Your Full node -Whenever IOTA releases a new version, you must update your Full node with the release to ensure compatibility with the +Whenever IOTA releases a new version, you must update your full node with the release to ensure compatibility with the network it connects to. For example, if you use IOTA Testnet you should install the version of IOTA running on IOTA Testnet. -Use the following steps to update your Full node: +Use the following steps to update your full node: -1. Shut down your running Full node. +1. Shut down your running full node. 2. Move into the directory for your local `iota` repository and remove the database, 'genesis.blob' and 'migration.blob' files: @@ -204,19 +204,19 @@ Use the following steps to update your Full node: - [Devnet migration blob](https://dbfiles.devnet.iota.cafe/migration.blob): `curl -fLJO https://dbfiles.devnet.iota.cafe/migration.blob` 5. (Optional) Update your `fullnode.yaml` configuration file, if needed. -6. Recompile your IOTA Full node: +6. Recompile your IOTA full node: ```bash cargo run --release --bin iota-node ``` -7. Restart your IOTA Full node: +7. Restart your IOTA full node: ```shell ./target/release/iota-node --config-path fullnode.yaml ``` -Your Full node restarts on: http://127.0.0.1:9000. +Your full node restarts on: http://127.0.0.1:9000. :::info diff --git a/docs/content/operator/operator.mdx b/docs/content/operator/operator.mdx index 31bf74390f1..6342e5b7948 100644 --- a/docs/content/operator/operator.mdx +++ b/docs/content/operator/operator.mdx @@ -1,13 +1,13 @@ --- title: Operator Guides -description: Guides for operators on the IOTA network. Whether you are running a Full node for your dApp or operating as a validator on the IOTA network, these guides help you set up your environment and operate your network. +description: Guides for operators on the IOTA network. Whether you are running a full node for your dApp or operating as a validator on the IOTA network, these guides help you set up your environment and operate your network. --- -Operator guides demonstrate how to run Full nodes on IOTA, whether as a validator or operator of a Full node to support your dApp, as well as how to integrate IOTA into an exchange. +Operator guides demonstrate how to run full nodes on IOTA, whether as a validator or operator of a full node to support your dApp, as well as how to integrate IOTA into an exchange. -## IOTA Full node operators +## IOTA full node operators -Guides that inform Full node operators include: +Guides that inform full node operators include: - [IOTA Full Node Configuration](iota-full-node/overview.mdx) @@ -19,9 +19,9 @@ Guides that inform validators how to operate on IOTA include: - [Validator Configuration](validator-config.mdx) - [Validator Tasks](validator-operation/validator-tasks.mdx) -## IOTA Full node operators and validators +## IOTA full node operators and validators -Guides that benefit both Full node operators and validators include: +Guides that benefit both full node operators and validators include: - [Data Management](data-management.mdx) - [Genesis](genesis.mdx) diff --git a/docs/content/operator/snapshots.mdx b/docs/content/operator/snapshots.mdx index 9ac406f77b8..663fe90e3a6 100644 --- a/docs/content/operator/snapshots.mdx +++ b/docs/content/operator/snapshots.mdx @@ -1,14 +1,14 @@ --- title: Database Snapshots -description: Database snapshots of the IOTA network enable Full node operators a way to bootstrap a Full node without having to execute all the transactions that occurred after genesis. +description: Database snapshots of the IOTA network enable full node operators a way to bootstrap a full node without having to execute all the transactions that occurred after genesis. --- import Quiz from '@site/src/components/Quiz'; import questions from '/json/node-operators/snapshots.json'; -Database snapshots provide a point-in-time view of a database's store. In IOTA, the database snapshot captures a running database's view of the IOTA network from a particular node at the end of an epoch. While validators can enable snapshots, they are typically most valuable for Full node operators. +Database snapshots provide a point-in-time view of a database's store. In IOTA, the database snapshot captures a running database's view of the IOTA network from a particular node at the end of an epoch. While validators can enable snapshots, they are typically most valuable for full node operators. -Snapshots of the IOTA network enable Full node operators a way to bootstrap a Full node without having to execute all the transactions that occurred after genesis. You can upload snapshots to remote object stores like S3, Google Cloud Storage, Azure Blob Storage, and similar services. These services typically run the export process in the background so there is no degradation in performance for your Full node. With snapshots stored in the cloud, you're more easily able to recover quickly from catastrophic failures in your system or hardware. +Snapshots of the IOTA network enable full node operators a way to bootstrap a full node without having to execute all the transactions that occurred after genesis. You can upload snapshots to remote object stores like S3, Google Cloud Storage, Azure Blob Storage, and similar services. These services typically run the export process in the background so there is no degradation in performance for your full node. With snapshots stored in the cloud, you're more easily able to recover quickly from catastrophic failures in your system or hardware. To maintain a healthy IOTA network, IOTA encourages the IOTA community to bring up additional snapshots to ensure stronger data availability across the network. @@ -25,8 +25,8 @@ Formal snapshots are not suitable for use if you are running an RPC node that do ::: -You can configure a Full node snapshot to generate a state snapshot at the end of each epoch. -A single Full node can generate RocksDB snapshots, Formal snapshots, or both. +You can configure a full node snapshot to generate a state snapshot at the end of each epoch. +A single full node can generate RocksDB snapshots, Formal snapshots, or both. ## Formal snapshots @@ -36,9 +36,9 @@ Formal snapshots provide a mechanism for a node to restore to a canonical state 1. **Agnosticism:** Formal snapshots are by nature agnostic to the underlying database choice or implementation of the protocol. As the live object set is protocol defined, so is the formal snapshot. 1. **Verifiability:** Formal snapshots have first-class support in the core IOTA protocol. As such, they must be trustless/verifiable by the node operator upon download. To support this, the protocol signs a commitment to the live object state at end of epoch, which formal snapshots are checked against at restore time. If this verification fails, the node state is moved back to the state before the snapshot restore attempt. -Because these snapshots do not contain indexes, they are most immediately useful for validators and state sync Full nodes (SSFNs). You can upload snapshots to remote object stores like S3, Google Cloud Storage, Azure Blob Storage, and similar services. These services typically run the export process in the background so there is no degradation in performance for your Full node. With snapshots stored in the cloud, you can recover from catastrophic failures in your system or hardware more efficiently. +Because these snapshots do not contain indexes, they are most immediately useful for validators and state sync full nodes (SSFNs). You can upload snapshots to remote object stores like S3, Google Cloud Storage, Azure Blob Storage, and similar services. These services typically run the export process in the background so there is no degradation in performance for your full node. With snapshots stored in the cloud, you can recover from catastrophic failures in your system or hardware more efficiently. -## Restoring a Full node using snapshots +## Restoring a full node using snapshots ### Restoring using RocksDB snapshots @@ -71,7 +71,7 @@ To restore from a RocksDB snapshot, follow these steps: The following environment variables are used if `--no-sign-request` is not set: * *AWS*: `AWS_SNAPSHOT_ACCESS_KEY_ID`, `AWS_SNAPSHOT_SECRET_ACCESS_KEY`, `AWS_SNAPSHOT_REGION` -1. When using `iota-tool download-db-snapshot` the database is copied to the location you pass to `--path`, in a directory named `epoch_[NUM]`. Move this directory to the `live/` Full node database directory, for example `/opt/iota/db/authorities_db/full_node_db/live`. +1. When using `iota-tool download-db-snapshot` the database is copied to the location you pass to `--path`, in a directory named `epoch_[NUM]`. Move this directory to the `live/` full node database directory, for example `/opt/iota/db/authorities_db/full_node_db/live`. 1. Make sure you update the ownership of the downloaded directory to the `iota` user (or whichever linux user you run `iota-node` as): `sudo chown -R iota:iota /opt/iota/db/authorities_db/full_node_db/live`. @@ -79,7 +79,7 @@ To restore from a RocksDB snapshot, follow these steps: :::info -When you restore a Full node from a snapshot, write it to the path `/opt/iota/db/authorities_db/full_node_db/live`. To restore a Validator node, use the path `/opt/iota/db/authorities_db/live`. +When you restore a full node from a snapshot, write it to the path `/opt/iota/db/authorities_db/full_node_db/live`. To restore a Validator node, use the path `/opt/iota/db/authorities_db/live`. ::: @@ -126,9 +126,9 @@ Devnet: `s3://iota-rebased-devnet-snapshots/`, `s3://iota-rebased-devnet-formal ## Enabling snapshots -Full nodes do not take snapshots by default. To enable this feature you must apply specific configs to your Full node. +full nodes do not take snapshots by default. To enable this feature you must apply specific configs to your full node. -Follow these steps to change the configs for a Full node: +Follow these steps to change the configs for a full node: 1. Stop your node, if it's running. 2. Open your fullnode.yaml config file and apply config updates as the following sections show. diff --git a/docs/content/operator/validator-config.mdx b/docs/content/operator/validator-config.mdx index 29b0c05e794..34032f2423a 100644 --- a/docs/content/operator/validator-config.mdx +++ b/docs/content/operator/validator-config.mdx @@ -8,7 +8,7 @@ import Quiz from '@site/src/components/Quiz'; import questions from '/json/node-operators/validator-config.json'; import ValidatorRequirements from "../_snippets/validator-requirements-tab.mdx" -Validators on the IOTA network run special nodes and have additional tasks and responsibilities beyond those of Full node operators. +Validators on the IOTA network run special nodes and have additional tasks and responsibilities beyond those of full node operators. ## Requirements to run a validator on IOTA diff --git a/docs/content/references/cli/client.mdx b/docs/content/references/cli/client.mdx index 87060609c08..32f6524c410 100644 --- a/docs/content/references/cli/client.mdx +++ b/docs/content/references/cli/client.mdx @@ -469,7 +469,7 @@ will verify that all transactions local execution results match the effects on-c Use the `iota client profile-transaction --tx-digest ` command to re-execute a transaction locally and produce a gas profile. Similar to the `replay` command, this command fetches the transaction dependencies from the -Full node specified in the client environment that are needed to execute the transaction. During the local execution of the transaction, +full node specified in the client environment that are needed to execute the transaction. During the local execution of the transaction, this command records all the Move function invocations and the gas cost breakdown for each invocation. To enable the profiler, you must either install or build the IOTA Client binary locally with the `--features gas-profiler` flag. diff --git a/docs/content/references/event-query-and-subscription.mdx b/docs/content/references/event-query-and-subscription.mdx index 3390e6617d3..b4ffdd40869 100644 --- a/docs/content/references/event-query-and-subscription.mdx +++ b/docs/content/references/event-query-and-subscription.mdx @@ -2,7 +2,7 @@ title: Event Query and Subscription --- -IOTA Full nodes support publish/subscribe using JSON-RPC notifications via the WebSocket API. You can use this service with IOTA client to filter and subscribe to a real-time event stream generated from Move or from the IOTA network. +IOTA full nodes support publish/subscribe using JSON-RPC notifications via the WebSocket API. You can use this service with IOTA client to filter and subscribe to a real-time event stream generated from Move or from the IOTA network. The client provides an [event filter](#event-filters) to limit the scope of events. IOTA returns a notification with the event data and subscription ID for each event that matches the filter. diff --git a/docs/content/references/exchange-integration-guide.mdx b/docs/content/references/exchange-integration-guide.mdx index 678767a2ec2..4b39392f9a2 100644 --- a/docs/content/references/exchange-integration-guide.mdx +++ b/docs/content/references/exchange-integration-guide.mdx @@ -10,19 +10,19 @@ This topic describes how to integrate IOTA, the token native to the IOTA network The requirements to configure a IOTA integration include: -- A IOTA Full node. You can operate your own IOTA Full node or use a Full node from a node operator. -- Suggested minimum hardware to run a IOTA Full node: +- A IOTA full node. You can operate your own IOTA full node or use a full node from a node operator. +- Suggested minimum hardware to run a IOTA full node: - CPUs: 8 physical cores / 16 vCPUs - RAM: 128 GB - Storage (SSD): 4 TB NVMe drive -For best results, run IOTA Full nodes on Linux. IOTA supports the Ubuntu and Debian distributions. You can also fun a Full node on macOS. +For best results, run IOTA full nodes on Linux. IOTA supports the Ubuntu and Debian distributions. You can also fun a full node on macOS. -## Configure a IOTA Full node +## Configure a IOTA full node -You can set up and configure a IOTA Full node using Docker or directly from source code in the IOTA GitHub repository. +You can set up and configure a IOTA full node using Docker or directly from source code in the IOTA GitHub repository. -### Install a IOTA Full node using Docker +### Install a IOTA full node using Docker Run the command in this section using the same branch of the repository for each. Replace `branch-name` with the branch you use. For example, use `devnet` to use the IOTA Devnet network, or use `testnet` to use the IOTA Testnet network. You must download all files to, and run all commands from, the same folder location. @@ -49,14 +49,14 @@ Run the command in this section using the same branch of the repository for each ```bash wget https://dbfiles.testnet.iota.cafe/genesis.blob ``` -1. Start the Full node. The -d switch starts it in the background (detached mode). +1. Start the full node. The -d switch starts it in the background (detached mode). ```bash docker-compose up -d ``` -## Install a IOTA Full node from source +## Install a IOTA full node from source -Use the steps in this section to install and configure a IOTA Full node directly from the IOTA GitHub repository. These steps use [Cargo](https://doc.rust-lang.org/cargo/), the Rust package manager. +Use the steps in this section to install and configure a IOTA full node directly from the IOTA GitHub repository. These steps use [Cargo](https://doc.rust-lang.org/cargo/), the Rust package manager. 1. Install prerequisites for IOTA. 1. Clone the IOTA repository: @@ -80,7 +80,7 @@ Use the steps in this section to install and configure a IOTA Full node directly 1. Optionally, if you installed IOTA to a path other than the default, modify the fullnode.yaml file to use the path you used. Update the path to the folder where you installed iota-fullnode for the `db-path` and `genesis-file-location` as appropriate: `db-path: "/db-files/iota-fullnode-folder"` `genesis-file-location: "/iota-fullnode-folder/genesis.blob"` -1. Start you IOTA Full node: +1. Start you IOTA full node: ```bash cargo run --release --bin iota-node -- --config-path fullnode.yaml ``` @@ -111,7 +111,7 @@ IOTA supports both addresses with and without a 0x prefix. IOTA recommends that You can track balance changes by calling `iota_getBalance` at predefined intervals. This call returns the total balance for an address. The total includes any coin or token type, but this document focuses on IOTA. You can track changes in the total balance for an address between subsequent `iota_getBalance` requests. -The following bash example demonstrates how to use `iota_getBalance` for address 0x849d63687330447431a2e76fecca4f3c10f6884ebaa9909674123c6c662612a3. If you use a network other than Devnet, replace the value for `rpc` with the URL to the appropriate Full node. +The following bash example demonstrates how to use `iota_getBalance` for address 0x849d63687330447431a2e76fecca4f3c10f6884ebaa9909674123c6c662612a3. If you use a network other than Devnet, replace the value for `rpc` with the URL to the appropriate full node. ```bash rpc="https://api.devnet.iota.cafe:443" diff --git a/docs/content/references/ts-sdk/typescript/iota-client.mdx b/docs/content/references/ts-sdk/typescript/iota-client.mdx index 1a4210cdc33..e4dacb81007 100644 --- a/docs/content/references/ts-sdk/typescript/iota-client.mdx +++ b/docs/content/references/ts-sdk/typescript/iota-client.mdx @@ -35,7 +35,7 @@ during development. In a production application, however, you should use the - `mainnet` For local development, you can run `cargo run --bin iota start --with-faucet --force-regenesis` to -spin up a local network with a local validator, a Full node, and a faucet server. Refer to +spin up a local network with a local validator, a full node, and a faucet server. Refer to [the Local Network guide](../../../developer/getting-started/local-network.mdx) for more information. diff --git a/docs/site/src/pages/index.js b/docs/site/src/pages/index.js index 1919f7e9b1a..bf59252a2f7 100644 --- a/docs/site/src/pages/index.js +++ b/docs/site/src/pages/index.js @@ -118,7 +118,7 @@ export default function Home() { className={styles.cardLink} to="./operator/iota-full-node/overview" > - Run a IOTA Full node + Run an IOTA Full node diff --git a/docs/site/static/json/developer/advanced-topics/custom-indexer.json b/docs/site/static/json/developer/advanced-topics/custom-indexer.json index 984bbe3440d..12998fe23f4 100644 --- a/docs/site/static/json/developer/advanced-topics/custom-indexer.json +++ b/docs/site/static/json/developer/advanced-topics/custom-indexer.json @@ -13,12 +13,12 @@ "answerOptions": [ { "answerText": "It prioritizes locally available checkpoint data while using remote data for backfilling or failover", "isCorrect": true }, { "answerText": "It allows running multiple ingestion daemons simultaneously for faster checkpoint processing", "isCorrect": false }, - { "answerText": "It processes checkpoints from multiple Full nodes at once, improving throughput", "isCorrect": false }, - { "answerText": "It connects directly to the IOTA mainnet without needing a local Full node", "isCorrect": false } + { "answerText": "It processes checkpoints from multiple full nodes at once, improving throughput", "isCorrect": false }, + { "answerText": "It connects directly to the IOTA mainnet without needing a local full node", "isCorrect": false } ] }, { - "questionText": "Which part of the IOTA Full node configuration allows you to enable checkpoint dumping for a local reader setup?", + "questionText": "Which part of the IOTA full node configuration allows you to enable checkpoint dumping for a local reader setup?", "answerOptions": [ { "answerText": "checkpoint-executor-config", "isCorrect": true }, { "answerText": "data-ingestion-config", "isCorrect": false }, diff --git a/docs/site/static/json/developer/iota-101/transactions/sponsored-transactions/about-sponsored-transactions.json b/docs/site/static/json/developer/iota-101/transactions/sponsored-transactions/about-sponsored-transactions.json index 100030713f4..075e4ce865a 100644 --- a/docs/site/static/json/developer/iota-101/transactions/sponsored-transactions/about-sponsored-transactions.json +++ b/docs/site/static/json/developer/iota-101/transactions/sponsored-transactions/about-sponsored-transactions.json @@ -11,7 +11,7 @@ { "questionText": "In a user-initiated sponsored transaction, what step happens after the sponsor signs the TransactionData?", "answerOptions": [ - { "answerText": "The user submits the signed transaction directly to a Full node", "isCorrect": false }, + { "answerText": "The user submits the signed transaction directly to a full node", "isCorrect": false }, { "answerText": "The sponsor sends the TransactionData and Signature back to the user", "isCorrect": true }, { "answerText": "The transaction is broadcast to the network", "isCorrect": false }, { "answerText": "The user constructs the GasData object", "isCorrect": false } diff --git a/docs/site/static/json/node-operators/data-management.json b/docs/site/static/json/node-operators/data-management.json index 5a95a751b8e..3096b8293a6 100644 --- a/docs/site/static/json/node-operators/data-management.json +++ b/docs/site/static/json/node-operators/data-management.json @@ -1,6 +1,6 @@ [ { - "questionText": "What is the main purpose of the state sync protocol in an IOTA Full node?", + "questionText": "What is the main purpose of the state sync protocol in an IOTA full node?", "answerOptions": [ { "answerText": "To enable fast transaction submission.", "isCorrect": false }, { "answerText": "To synchronize the local state with committed checkpoints from validators.", "isCorrect": true }, @@ -9,7 +9,7 @@ ] }, { - "questionText": "Which configuration option would you set to enable aggressive pruning in your IOTA Full node?", + "questionText": "Which configuration option would you set to enable aggressive pruning in your IOTA full node?", "answerOptions": [ { "answerText": "num-epochs-to-retain: 0", "isCorrect": true }, { "answerText": "num-epochs-to-retain: 10", "isCorrect": false }, @@ -18,7 +18,7 @@ ] }, { - "questionText": "What happens when an IOTA Full node cannot retrieve checkpoints from its peers?", + "questionText": "What happens when an IOTA full node cannot retrieve checkpoints from its peers?", "answerOptions": [ { "answerText": "It stops processing new transactions.", "isCorrect": false }, { "answerText": "It falls back to downloading missing checkpoints from a pre-configured archive.", "isCorrect": true }, diff --git a/docs/site/static/json/node-operators/iota-full-node/node-setup.json b/docs/site/static/json/node-operators/iota-full-node/node-setup.json index 18c60e6b744..9f5016a4370 100644 --- a/docs/site/static/json/node-operators/iota-full-node/node-setup.json +++ b/docs/site/static/json/node-operators/iota-full-node/node-setup.json @@ -1,6 +1,6 @@ [ { - "questionText": "In the context of IOTA Full nodes, what is the significance of the 2f+1 validators during transaction processing?", + "questionText": "In the context of IOTA full nodes, what is the significance of the 2f+1 validators during transaction processing?", "answerOptions": [ { "answerText": "They ensure that transactions are signed before being sent to the network.", "isCorrect": false }, { "answerText": "They help in achieving consensus and finality for a transaction.", "isCorrect": true }, @@ -9,7 +9,7 @@ ] }, { - "questionText": "When configuring the Full node, which YAML parameter is critical for specifying the path to the database used by the node?", + "questionText": "When configuring the full node, which YAML parameter is critical for specifying the path to the database used by the node?", "answerOptions": [ { "answerText": "db-path", "isCorrect": true }, { "answerText": "data-storage", "isCorrect": false }, @@ -18,7 +18,7 @@ ] }, { - "questionText": "In the pruning configuration for an IOTA Full node, why would you set `num-epochs-to-retain` to 0?", + "questionText": "In the pruning configuration for an IOTA full node, why would you set `num-epochs-to-retain` to 0?", "answerOptions": [ { "answerText": "To retain all object versions indefinitely.", "isCorrect": false }, { "answerText": "To enable aggressive pruning of old object versions as soon as possible.", "isCorrect": true }, diff --git a/docs/site/static/json/node-operators/iota-full-node/overview.json b/docs/site/static/json/node-operators/iota-full-node/overview.json index e7ca0283c59..2aa742f3764 100644 --- a/docs/site/static/json/node-operators/iota-full-node/overview.json +++ b/docs/site/static/json/node-operators/iota-full-node/overview.json @@ -1,6 +1,6 @@ [ { - "questionText": "In the context of IOTA Full nodes, what is the significance of the 2f+1 validators during transaction processing?", + "questionText": "In the context of IOTA full nodes, what is the significance of the 2f+1 validators during transaction processing?", "answerOptions": [ { "answerText": "They ensure that transactions are signed before being sent to the network.", "isCorrect": false }, { "answerText": "They help in achieving consensus and finality for a transaction.", "isCorrect": true }, diff --git a/docs/site/static/json/node-operators/iota-full-node/pruning.json b/docs/site/static/json/node-operators/iota-full-node/pruning.json index 5cc66342e02..f7dcee2c69e 100644 --- a/docs/site/static/json/node-operators/iota-full-node/pruning.json +++ b/docs/site/static/json/node-operators/iota-full-node/pruning.json @@ -1,6 +1,6 @@ [ { - "questionText": "In the pruning configuration for an IOTA Full node, why would you set `num-epochs-to-retain` to 0?", + "questionText": "In the pruning configuration for an IOTA full node, why would you set `num-epochs-to-retain` to 0?", "answerOptions": [ { "answerText": "To retain all object versions indefinitely.", "isCorrect": false }, { "answerText": "To enable aggressive pruning of old object versions as soon as possible.", "isCorrect": true }, diff --git a/docs/site/static/json/node-operators/snapshots.json b/docs/site/static/json/node-operators/snapshots.json index 03587085c46..35ea84b063e 100644 --- a/docs/site/static/json/node-operators/snapshots.json +++ b/docs/site/static/json/node-operators/snapshots.json @@ -9,7 +9,7 @@ ] }, { - "questionText": "Which command is used to restore a Full node from a RocksDB snapshot?", + "questionText": "Which command is used to restore a full node from a RocksDB snapshot?", "answerOptions": [ { "answerText": "iota-tool download-db-snapshot", "isCorrect": true }, { "answerText": "iota-tool restore-snapshot", "isCorrect": false }, @@ -18,7 +18,7 @@ ] }, { - "questionText": "What must be done before restoring a Full node using a formal snapshot?", + "questionText": "What must be done before restoring a full node using a formal snapshot?", "answerOptions": [ { "answerText": "Ensure the node is running with the latest software.", "isCorrect": false }, { "answerText": "Stop the node if it's currently running.", "isCorrect": true },