mirror of
https://github.com/Xahau/xahau-web.git
synced 2025-11-04 04:15:47 +00:00
Update and Expand "Infrastructure" Section (#61)
* Remove extra section from Infrastructure sidebar in the documentation. Also remove cabbit.tech hubs. * Expand details on running a mainnet node. * Combine mainnet and testnet node install instructions to a single page. * Update system requirements. * Edit system requirements again. * Add placeholders for new documentation and contributing guidelines. * Update header, footer, and IndexLayout links to reflect renaming the infrastructure page to 'system-requirements'. * Fix overwrite from upstream index page layout. Add intro paragraph to running xahaud page. * Describe different types of nodes, expand contributing.md * Minor editing and revisions. * Additional guidelines added. * Add a placeholder page for 'Updating xahaud'. * Edited install/system requirements/updating. * Add instructions for updating Docker containers. * Add updating local install instructions. * Add background on enabling validation. * Add instructions on running xahaud as a validator. * Minor revisions to enabling validations and interacting with xahaud * Fixed minor typos and added formatting to the interacting.mdx webpage. * Add master example xahaud.cfg file to table on install page.
This commit is contained in:
J. Scott Branson
19
CONTRIBUTING.md
Normal file
19
CONTRIBUTING.md
Normal file
@@ -0,0 +1,19 @@
|
|||||||
|
# Intro
|
||||||
|
Public contributions to the documentation are welcome. When contributing, please help with consistency and clarity by adhering to the below guidelines.
|
||||||
|
|
||||||
|
### Disambiguation
|
||||||
|
* Strive for brevity and clarity. Avoid jargon and use a professional writing tone.
|
||||||
|
* When referring to the software `xahaud`, use a lowercase "x" and include the 'd'. When referring to the broader `Xahau Network`, capitalize both terms and,if appropriate, subsequently use the capitalized term "the Network". Use the capitalized `Xahau` or the all caps abbreviation `XAH` when referring to the currency.
|
||||||
|
* Be mindful that this documentation is shared by a global community. Avoid culture-specific jargon or slang.
|
||||||
|
|
||||||
|
### Formatting
|
||||||
|
* Relative and absolute linking are both permitted. When changing the directory structure or renaming individual pages, use grep to ensure all links are updated. Header, footer, index page, navigation bar, and links on other pages all need to be updated manually.
|
||||||
|
* The use of second person ("you") is permitted.
|
||||||
|
* Individual webpages may be formatted using Markdown, HTML, CSS, and JavaScript in any combination. To the extent possible, favor style templates and avoid inline CSS.
|
||||||
|
* When using bulleted or numbered lists end sentences with a period ('.'), unless doing so interferes with content. For example, if a bulleted list item ends with a link to a webpage, do not add a '.' at the end of the link, as doing so breaks the link. Similarly, do not add a '.' after code snippets.
|
||||||
|
* Capitalize proper nouns, including "Testnet" and "Mainnet". Prefer single word for these terms.
|
||||||
|
* Use square brackets inside code snippets to offset user specific information, such as file names and paths. For example: `cd [/path/to/xahaud] && ./xahaud server_info`
|
||||||
|
* Wrap multi-line code examples in three backticks: "```".
|
||||||
|
|
||||||
|
### General Guidelines
|
||||||
|
* Include meaningful commit messages.
|
||||||
@@ -34,3 +34,7 @@ All commands are run from the root of the project, from a terminal:
|
|||||||
| `npm run preview` | Preview your build locally, before deploying |
|
| `npm run preview` | Preview your build locally, before deploying |
|
||||||
| `npm run astro ...` | Run CLI commands like `astro add`, `astro check` |
|
| `npm run astro ...` | Run CLI commands like `astro add`, `astro check` |
|
||||||
| `npm run astro -- --help` | Get help using the Astro CLI |
|
| `npm run astro -- --help` | Get help using the Astro CLI |
|
||||||
|
|
||||||
|
## Standards for Formatting Contributions
|
||||||
|
|
||||||
|
When contributing, please adhere to the standards defined in "[contributing.md](contributing.md)".
|
||||||
|
|||||||
@@ -280,15 +280,11 @@ export default defineConfig({
|
|||||||
{
|
{
|
||||||
label: 'Infrastructure',
|
label: 'Infrastructure',
|
||||||
items: [
|
items: [
|
||||||
'docs/infrastructure/node-requirements',
|
'docs/infrastructure/system-requirements',
|
||||||
{
|
'docs/infrastructure/installing-xahaud',
|
||||||
label: 'Running a Node',
|
'docs/infrastructure/updating-xahaud',
|
||||||
collapsed: true,
|
'docs/infrastructure/enabling-validation',
|
||||||
items: [
|
'docs/infrastructure/interacting',
|
||||||
'docs/infrastructure/running-a-node/running-a-mainnet-node',
|
|
||||||
'docs/infrastructure/running-a-node/running-a-testnet-node',
|
|
||||||
],
|
|
||||||
},
|
|
||||||
{
|
{
|
||||||
label: 'Building Xahau (Dev)',
|
label: 'Building Xahau (Dev)',
|
||||||
collapsed: true,
|
collapsed: true,
|
||||||
|
|||||||
46
package-lock.json
generated
46
package-lock.json
generated
@@ -2800,13 +2800,13 @@
|
|||||||
}
|
}
|
||||||
},
|
},
|
||||||
"node_modules/astro": {
|
"node_modules/astro": {
|
||||||
"version": "5.10.1",
|
"version": "5.13.2",
|
||||||
"resolved": "https://registry.npmjs.org/astro/-/astro-5.10.1.tgz",
|
"resolved": "https://registry.npmjs.org/astro/-/astro-5.13.2.tgz",
|
||||||
"integrity": "sha512-DJVmt+51jU1xmgmAHCDwuUgcG/5aVFSU+tcX694acAZqPVt8EMUAmUZcJDX36Z7/EztnPph9HR3pm72jS2EgHQ==",
|
"integrity": "sha512-yjcXY0Ua3EwjpVd3GoUXa65HQ6qgmURBptA+M9GzE0oYvgfuyM7bIbH8IR/TWIbdefVUJR5b7nZ0oVnMytmyfQ==",
|
||||||
"dependencies": {
|
"dependencies": {
|
||||||
"@astrojs/compiler": "^2.12.2",
|
"@astrojs/compiler": "^2.12.2",
|
||||||
"@astrojs/internal-helpers": "0.6.1",
|
"@astrojs/internal-helpers": "0.7.2",
|
||||||
"@astrojs/markdown-remark": "6.3.2",
|
"@astrojs/markdown-remark": "6.3.6",
|
||||||
"@astrojs/telemetry": "3.3.0",
|
"@astrojs/telemetry": "3.3.0",
|
||||||
"@capsizecss/unpack": "^2.4.0",
|
"@capsizecss/unpack": "^2.4.0",
|
||||||
"@oslojs/encoding": "^1.1.0",
|
"@oslojs/encoding": "^1.1.0",
|
||||||
@@ -2849,6 +2849,7 @@
|
|||||||
"rehype": "^13.0.2",
|
"rehype": "^13.0.2",
|
||||||
"semver": "^7.7.1",
|
"semver": "^7.7.1",
|
||||||
"shiki": "^3.2.1",
|
"shiki": "^3.2.1",
|
||||||
|
"smol-toml": "^1.3.4",
|
||||||
"tinyexec": "^0.3.2",
|
"tinyexec": "^0.3.2",
|
||||||
"tinyglobby": "^0.2.12",
|
"tinyglobby": "^0.2.12",
|
||||||
"tsconfck": "^3.1.5",
|
"tsconfck": "^3.1.5",
|
||||||
@@ -2862,7 +2863,7 @@
|
|||||||
"xxhash-wasm": "^1.1.0",
|
"xxhash-wasm": "^1.1.0",
|
||||||
"yargs-parser": "^21.1.1",
|
"yargs-parser": "^21.1.1",
|
||||||
"yocto-spinner": "^0.2.1",
|
"yocto-spinner": "^0.2.1",
|
||||||
"zod": "^3.24.2",
|
"zod": "^3.24.4",
|
||||||
"zod-to-json-schema": "^3.24.5",
|
"zod-to-json-schema": "^3.24.5",
|
||||||
"zod-to-ts": "^1.2.0"
|
"zod-to-ts": "^1.2.0"
|
||||||
},
|
},
|
||||||
@@ -2893,6 +2894,39 @@
|
|||||||
"astro": "^4.0.0-beta || ^5.0.0-beta || ^3.3.0"
|
"astro": "^4.0.0-beta || ^5.0.0-beta || ^3.3.0"
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
|
"node_modules/astro/node_modules/@astrojs/internal-helpers": {
|
||||||
|
"version": "0.7.2",
|
||||||
|
"resolved": "https://registry.npmjs.org/@astrojs/internal-helpers/-/internal-helpers-0.7.2.tgz",
|
||||||
|
"integrity": "sha512-KCkCqR3Goym79soqEtbtLzJfqhTWMyVaizUi35FLzgGSzBotSw8DB1qwsu7U96ihOJgYhDk2nVPz+3LnXPeX6g=="
|
||||||
|
},
|
||||||
|
"node_modules/astro/node_modules/@astrojs/markdown-remark": {
|
||||||
|
"version": "6.3.6",
|
||||||
|
"resolved": "https://registry.npmjs.org/@astrojs/markdown-remark/-/markdown-remark-6.3.6.tgz",
|
||||||
|
"integrity": "sha512-bwylYktCTsLMVoCOEHbn2GSUA3c5KT/qilekBKA3CBng0bo1TYjNZPr761vxumRk9kJGqTOtU+fgCAp5Vwokug==",
|
||||||
|
"dependencies": {
|
||||||
|
"@astrojs/internal-helpers": "0.7.2",
|
||||||
|
"@astrojs/prism": "3.3.0",
|
||||||
|
"github-slugger": "^2.0.0",
|
||||||
|
"hast-util-from-html": "^2.0.3",
|
||||||
|
"hast-util-to-text": "^4.0.2",
|
||||||
|
"import-meta-resolve": "^4.1.0",
|
||||||
|
"js-yaml": "^4.1.0",
|
||||||
|
"mdast-util-definitions": "^6.0.0",
|
||||||
|
"rehype-raw": "^7.0.0",
|
||||||
|
"rehype-stringify": "^10.0.1",
|
||||||
|
"remark-gfm": "^4.0.1",
|
||||||
|
"remark-parse": "^11.0.0",
|
||||||
|
"remark-rehype": "^11.1.2",
|
||||||
|
"remark-smartypants": "^3.0.2",
|
||||||
|
"shiki": "^3.2.1",
|
||||||
|
"smol-toml": "^1.3.4",
|
||||||
|
"unified": "^11.0.5",
|
||||||
|
"unist-util-remove-position": "^5.0.0",
|
||||||
|
"unist-util-visit": "^5.0.0",
|
||||||
|
"unist-util-visit-parents": "^6.0.1",
|
||||||
|
"vfile": "^6.0.3"
|
||||||
|
}
|
||||||
|
},
|
||||||
"node_modules/astro/node_modules/semver": {
|
"node_modules/astro/node_modules/semver": {
|
||||||
"version": "7.7.2",
|
"version": "7.7.2",
|
||||||
"resolved": "https://registry.npmjs.org/semver/-/semver-7.7.2.tgz",
|
"resolved": "https://registry.npmjs.org/semver/-/semver-7.7.2.tgz",
|
||||||
|
|||||||
@@ -25,7 +25,7 @@ import logo from '../assets/xahau-logo.svg'
|
|||||||
<a href="/docs/protocol-reference/transactions">Protocol Reference</a>
|
<a href="/docs/protocol-reference/transactions">Protocol Reference</a>
|
||||||
<a href="/docs/hooks">Hooks</a>
|
<a href="/docs/hooks">Hooks</a>
|
||||||
<a href="/docs/data-apis">Data APIs</a>
|
<a href="/docs/data-apis">Data APIs</a>
|
||||||
<a href="/docs/infrastructure/node-requirements">Infrastructure</a>
|
<a href="/docs/infrastructure/system-requirements">Infrastructure</a>
|
||||||
<a href="/docs/resources/whitepaper">Whitepaper</a>
|
<a href="/docs/resources/whitepaper">Whitepaper</a>
|
||||||
</div>
|
</div>
|
||||||
<div class="col-span-1 md:col-span-2 flex flex-col gap-3">
|
<div class="col-span-1 md:col-span-2 flex flex-col gap-3">
|
||||||
|
|||||||
@@ -29,7 +29,7 @@ const docs = [
|
|||||||
{ name: 'Protocol Reference', href: '/docs/protocol-reference/transactions' },
|
{ name: 'Protocol Reference', href: '/docs/protocol-reference/transactions' },
|
||||||
{ name: 'Hooks', href: '/docs/hooks' },
|
{ name: 'Hooks', href: '/docs/hooks' },
|
||||||
{ name: 'Data APIs', href: '/docs/data-apis' },
|
{ name: 'Data APIs', href: '/docs/data-apis' },
|
||||||
{ name: 'Infrastructure', href: '/docs/infrastructure/node-requirements' },
|
{ name: 'Infrastructure', href: '/docs/infrastructure/system-requirements' },
|
||||||
{ name: 'Whitepaper', href: '/docs/resources/whitepaper' },
|
{ name: 'Whitepaper', href: '/docs/resources/whitepaper' },
|
||||||
]
|
]
|
||||||
|
|
||||||
|
|||||||
@@ -90,7 +90,7 @@ deb http://apt.llvm.org/ llvm-toolchain-- main
|
|||||||
# Add the apt-repo directly with add-apt-repository "deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-14 main"
|
# Add the apt-repo directly with add-apt-repository "deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-14 main"
|
||||||
```
|
```
|
||||||
|
|
||||||
### Install Rippled Dependencies
|
### Install Xahaud Dependencies
|
||||||
|
|
||||||
Install CMake
|
Install CMake
|
||||||
|
|
||||||
|
|||||||
39
src/content/docs/docs/infrastructure/enabling-validation.mdx
Normal file
39
src/content/docs/docs/infrastructure/enabling-validation.mdx
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: Enabling Validations in xahaud
|
||||||
|
---
|
||||||
|
Validators are xahaud nodes that are configured with an additional public/private keypair, which is used to sign each proposed ledger. Thus, validators are the primary mechanism used to achieve consensus regarding the order in which transactions are applied on the Xahau Network.
|
||||||
|
|
||||||
|
### Security and Availability
|
||||||
|
When running xahaud as a validator, system security and availability are critical. Validator operators are expected to actively monitor their servers and to respond quickly to outages. Some validator operators choose to host standby machines in diverse data centers, so they can quickly recover from outages. While it is possible to host a reliable validator in one's home, it is unlikely that such a setup could provide sufficient stability and security for the validator to gain broader trust (e.g., inclusion on published UNLs). Similarly, validator operators are strongly discouraged from running software other than xahaud on a machine used as a xahaud validator, since this increases the probability of running out of resources or exposing a security vulnerability. System administrators who require websocket or RPC access to a server are encouraged to run different machines for queries, so resources are not taken away from the critical task of validating ledgers.
|
||||||
|
<br></br>
|
||||||
|
The private/public validation keypair should be stored and backed up in a secure, offline environment. Anyone with access to the keys of a trusted validator has potential to harm the network. After installing a validation token into the xahaud.cfg file, it is advised to restrict read access (`chmod 400 xahaud.cfg`) and change ownership of the file to "root" or "xahaud", depending on the type of install (`chown root:root xahaud.cfg`).
|
||||||
|
|
||||||
|
### Identity Attestation
|
||||||
|
To avoid a [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack) and build trust, validating xahaud nodes attest to their identity by cryptographically signing a domain name with their validation keys. This signature is then hosted at the same domain, in a TOML format file. In addition to verifying the identity of a validator, this TOML file can also be used to verify the identity of individual account holders on the Xahau Network, by providing an attestation signed by the private account key instead of the private validation key. The TOML file should be hosted on a web server with TLS encryption enabled at:<br></br><code>https://[your-domain.com]/.well-known/xah-ledger.toml</code><br></br>
|
||||||
|
|
||||||
|
### Peering
|
||||||
|
To maintain a high level of security, xahaud nodes that are configured as validators should only peer with known, trusted peers. Enabling the `peer_private` setting and explicitly defining `ips_fixed` in the xahaud.cfg file will force a server to only connect to defined peers. Operating system and hardware level protections, such as firewalls, provide additional reassurance that the server is only connecting to defined peers. However, this can be a challenge, as validators with too few peers, typically less than about five, are at risk of falling out of sync with the rest of the network.
|
||||||
|
|
||||||
|
### Governance and Trust
|
||||||
|
The Xahau Network utilizes the [Governance Game](../../features/governance-game) as a democratic method for managing the Network. Additionally, each xahaud instance participating in the Network is required to install a list of trusted validating servers, called a Unique Node List or UNL. Thus, the existing governance participants can vote a new validator into a seat at the governance table. Separately, trusted UNL publishers, such as the [InFTF](https://inftf.org), can choose to include a validator in their recommended list of trusted validators. Running a validator does not guarantee inclusion in either the Governance Game or any UNL. Typically, validating servers that are selected for inclusion in the governance process have:
|
||||||
|
1. High availability
|
||||||
|
- Effective 24/7/365 monitoring with rapid responses to outages
|
||||||
|
2. High agreement with the rest of the network
|
||||||
|
3. An identified owner/operator and a clear geographic location
|
||||||
|
4. A proactive approach to updating and voting for [amendments](../../features/amendments) and fees
|
||||||
|
- This requires taking the time to watch what is in development
|
||||||
|
|
||||||
|
### Building the Validation Keys Tool
|
||||||
|
At this time, there is not a packaged tool for generating validation keys. Thus, users can either build the tool from scratch or rely on a packaged version provided with rippled (this tool is not packaged with the xahaud binary). The instructions for building the tool are the same as the instructions for building rippled, and they are provided on the [ripple/validator-keys-tool](https://github.com/ripple/validator-keys-tool) repository page. There are also some [packaged binaries](https://github.com/jscottbranson/rippled-examples/blob/master/validator-keys) available on unofficial repositories.
|
||||||
|
|
||||||
|
### Generating and Installing Validation Keys
|
||||||
|
Consider using an offline machine to generate validation keys and a validation token.
|
||||||
|
1. Navigate to the directory containing the validation keys tool: `cd [/path/to/tool]`
|
||||||
|
2. Generate a new keypair: `./validator-keys create_keys`
|
||||||
|
3. The newly generated keypair is stored in `/home/[username]/.ripple/validator-keys.json`.
|
||||||
|
4. Ideally, validators should provide identity attestation. To do so, set your domain in the validator-keys.json file: `./validator-keys set_domain [example.com]`
|
||||||
|
- If you do not wish to provide an identifying domain, generate a validation token without a domain: `./validator-keys create_token --keyfile /home/[username]/.ripple/validator-keys.json`
|
||||||
|
5. Review the output of the previous command. Note the `[validator_token]`, as this will be installed in xahaud.cfg to enable validation. If a domain was set, note the `attestation=""` line, as it will need to be added into the TOML file served at your domain.
|
||||||
|
6. Open xahaud.cfg and paste in the `[validation_token]`, then restart the xahaud service.
|
||||||
|
7. Paste the `attestation=""` into your TOML file to prove the identity of your validator.
|
||||||
|
|
||||||
61
src/content/docs/docs/infrastructure/installing-xahaud.mdx
Normal file
61
src/content/docs/docs/infrastructure/installing-xahaud.mdx
Normal file
@@ -0,0 +1,61 @@
|
|||||||
|
---
|
||||||
|
title: Installing xahaud
|
||||||
|
description: >-
|
||||||
|
The software behind Xahau is open source, and anyone can run a node locally. Users can run a Docker container, a local instance, or a binary file.
|
||||||
|
---
|
||||||
|
When running a node, users will have to configure settings based on whether the node will run on the test network or the main network. When transitioning a single node from one network to the other, database files must be wiped, except wallet.db, which contains the server's identity credentials.
|
||||||
|
|
||||||
|
In addition to [building from scratch](../building-xahau), there are three ways to install xahaud: Docker, locally, and using a portable binary. The below install methods all rely on the xahaud builds published at: [https://build.xahau.tech](https://build.xahau.tech), though the end result is different.
|
||||||
|
## Docker Container
|
||||||
|
|
||||||
|
To run xahaud in a Docker Container:
|
||||||
|
|
||||||
|
1. Clone the appropriate (Mainnet or Testnet) Xahau Docker GitHub repository using the URL in the table below: <code>git clone [repository-url]</code>
|
||||||
|
2. Navigate to the repository directory: <code>cd [repository-name]</code>
|
||||||
|
3. Run: <code>./build</code>
|
||||||
|
4. Run: <code>./up</code>
|
||||||
|
5. Commands and additional information are located in the README.md file in the Docker repository. Configuration files and databases are located in the `store` directory inside the Docker directory.
|
||||||
|
|
||||||
|
## Local Install
|
||||||
|
The Xahau Docker repositories (Mainnet and Testnet) each contains a script to automate the local install process, so that xahaud can be run outside of Docker. These scripts will create systemd files, a 'xahaud' user, and default configuration files. The URLs for these scripts are in the table at the bottom of this page. To install locally:
|
||||||
|
|
||||||
|
1. Download and run the install script: <code>curl -sL [https://link-to-script] | bash</code>
|
||||||
|
2. Edit the configuration file: <code>/opt/xahahud/etc/xahaud.cfg</code>
|
||||||
|
3. Verify and, if needed, edit the contents of the trusted validators file: <code>/opt/xahaud/etc/validators-xahau.txt</code>
|
||||||
|
4. Start and enable xahaud to run automatically: <code>systemctl enable --now xahaud</code>
|
||||||
|
5. Verify xahaud is running: <code>/opt/xahaud/bin/xahaud server_info</code>
|
||||||
|
|
||||||
|
## Binary Files
|
||||||
|
Users seeking to install xahaud in non-traditional environments (e.g., outside Ubuntu) may benefit from the binary release packages, which are built with necessary dependencies. This install process is essentially the same as the "Local Install", however, xahaud is not configured as a systemd service and config files are not installed in default directories.
|
||||||
|
1. Download the latest release from [https://build.xahau.tech](https://build.xahau.tech)
|
||||||
|
2. Download and edit the relevant configuration and trusted validators files (see the table below for links to Mainnet and Testnet configurations). Ensure the paths to the validators-xahau.txt file, the database directory, and the logfile are accessible.
|
||||||
|
3. Change permissions on the downloaded binary, so it is executable: <code>chmod 500 [/path/to/xahaud]</code>
|
||||||
|
4. Consider restricting access to xahaud.cfg and validators-xahau.txt: <code>chmod 400 xahaud.cfg validators-xahau.txt</code>
|
||||||
|
5. Run the binary: <code>./[path/to/xahaud] --net --conf [path to xahaud.cfg]</code>
|
||||||
|
6. Verify xahaud is running: <code>./[path/to/xahaud] server_info</code>
|
||||||
|
|
||||||
|
## Resources, Peering, and Configurations
|
||||||
|
This peering is relevant for both Docker containers and local installations.
|
||||||
|
|
||||||
|
<table style="width: 100%; table-layout: fixed;">
|
||||||
|
<thead><tr><th>Resource</th><th>Main Network</th><th>Test Network</th></tr></thead>
|
||||||
|
<tbody>
|
||||||
|
<tr><td>Documentation and Resources</td><td><a href="https://xahau.network/">https://xahau.network/</a></td><td>Same as Mainnet</td></tr>
|
||||||
|
<tr><td>Hooks Smart Contract Documentation</td><td><a href="https://xrpl-hooks.readme.io/">https://xrpl-hooks.readme.io</a></td><td>Same as Mainnet</td></tr>
|
||||||
|
<tr><td>Explorer</td><td><a href="https://explorer.xahau.network/">https://explorer.xahau.network/</a></td><td><a href="https://explorer.xahau-test.net/">https://explorer.xahau-test.net</a></td></tr>
|
||||||
|
<tr><td>Public WebSocket URL</td><td><a href="wss://xahau.network">wss://xahau.network</a></td><td><a href="wss://xahau-test.net">wss://xahau-test.net</a></td></tr>
|
||||||
|
<tr><td>Network ID and Peer Listening Port</td><td>21337</td><td>21338</td></tr>
|
||||||
|
<tr>
|
||||||
|
<td>Peering and Bootstrap Servers</td>
|
||||||
|
<td>bacab.alloy.ee 21337<br></br>hubs.xahau.as16089.net 21337</td>
|
||||||
|
<td>79.110.60.122 21338<br></br>79.110.60.124 21338<br></br>79.110.60.125 21338<br></br>79.110.60.121 21338<br></br><br></br>2a0c:3bc0::1c74 21338<br></br>2a0c:3bc0::169d 21338<br></br>2a0c:3bc0::1aaf 21338<br></br>2a0c:3bc0::1d78 21338</td>
|
||||||
|
</tr>
|
||||||
|
<tr><td>Docker Container</td><td><a href="https://github.com/Xahau/mainnet-docker">https://github.com/Xahau/mainnet-docker</a></td><td><a href="https://github.com/Xahau/Xahau-Testnet-Docker">https://github.com/Xahau/Xahau-Testnet-Docker</a></td></tr>
|
||||||
|
<tr><td>Local Install Scripts</td><td><a href="https://raw.githubusercontent.com/Xahau/mainnet-docker/refs/heads/main/xahaud-install-update.sh">https://raw.githubusercontent.com/Xahau/mainnet-docker/refs/heads/main/xahaud-install-update.sh</a></td><td><a href="https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/xahaud-install-update.sh">https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/xahaud-install-update.sh</a></td></tr>
|
||||||
|
<tr><td>Binary Releases</td><td><a href="https://build.xahau.tech">https://build.xahau.tech</a></td><td>Same as Mainnet</td></tr>
|
||||||
|
<tr><td>Sample Configuration File</td><td><a href="https://github.com/Xahau/mainnet-docker/blob/main/store/etc/xahaud.sample.cfg">https://github.com/Xahau/mainnet-docker/blob/main/store/etc/xahaud.sample.cfg</a></td><td><a href="https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/store/etc/xahaud.cfg">https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/store/etc/xahaud.cfg</a></td></tr>
|
||||||
|
<tr><td>Sample Trusted Validators (UNL) File</td><td><a href="https://github.com/Xahau/mainnet-docker/blob/main/store/etc/validators-xahau.sample.txt">https://github.com/Xahau/mainnet-docker/blob/main/store/etc/validators-xahau.sample.txt</a></td><td><a href="https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/store/etc/validators-xahau.txt">https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/store/etc/validators-xahau.txt</a></td></tr>
|
||||||
|
<tr><td>Documented Configuration Files</td><td><a href="https://github.com/Xahau/xahaud/tree/dev/cfg">https://github.com/Xahau/xahaud/tree/dev/cfg</a></td><td>Same as Mainnet</td></tr>
|
||||||
|
<tr><td>Github Build Actions (release numbers)</td><td style="word-break: break-all;"><a href="https://github.com/Xahau/xahaud/actions?query=branch%3Arelease+is%3Asuccess+build+using+docker">https://github.com/Xahau/xahaud/actions?query=branch%3Arelease+is%3Asuccess+build+using+docker</a></td><td>Same as Mainnet</td></tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
34
src/content/docs/docs/infrastructure/interacting.mdx
Normal file
34
src/content/docs/docs/infrastructure/interacting.mdx
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
title: Interacting With xahaud Using Websocket and RPC
|
||||||
|
---
|
||||||
|
The xahaud software provides both websocket and RPC interfaces that can be configured for a variety of use cases, such as submitting transactions or querying ledger history. Some users may choose to place proxy software in front of xahaud to provide encryption, load balancing, or other benefits. It is possible to install TLS certificates in the xahaud.cfg file using parameters such as `ssl_key = [/path/to/key]`.
|
||||||
|
|
||||||
|
### Configuring Websocket and RPC Ports
|
||||||
|
To enable listening ports, edit the `xahaud.cfg` file. Enabled ports are listed under the `[server]` stanza in the configuration file. Each port listed under the `[server]` section must be further defined via it's own stanza. In addition to configuring websocket or RPC ports, administrators can also configure the port used to listen for incoming peer connections (`port_peer`). On validating servers, it is ideal to remove `port_peer` from the configuration file, to avoid incoming connections. A configuration file with the peer protocol, one websocket port, and one RPC port might look like:<br></br><br></br>
|
||||||
|
|
||||||
|
```
|
||||||
|
[server]
|
||||||
|
port_peer
|
||||||
|
port_ws_public
|
||||||
|
port_rpc_public
|
||||||
|
|
||||||
|
[port_peer] # Name of the port.
|
||||||
|
protocol = peer # Required field.
|
||||||
|
port = 21337 # Required field.
|
||||||
|
ip = :: # Address of interface to bind to.
|
||||||
|
|
||||||
|
[port_ws_public]
|
||||||
|
protocol = ws
|
||||||
|
port = 16006
|
||||||
|
ip = ::
|
||||||
|
limit = 150 # Maximum number of clients allowed to connect to a given port. "0" is unlimited.
|
||||||
|
admin = [ 10.10.10.5, 10.11.11.0/24 ] # IP addresses or subnets allowed to submit [admin](../../features/http-websocket-apis/admin-api-methods) requests.
|
||||||
|
secure_gateway = [ 10.10.10.20, 10.15.15.0/24 ] # Addresses allowed to send X-Forwarded-For and X-User headers.
|
||||||
|
|
||||||
|
[port_rpc_public]
|
||||||
|
protocol = http
|
||||||
|
port = 16007
|
||||||
|
ip = ::
|
||||||
|
```
|
||||||
|
<br></br>
|
||||||
|
Additional configuration options for websocket and RPC connections are available in the [Example Configuration File](https://github.com/Xahau/xahaud/blob/dev/cfg/rippled-example.cfg).
|
||||||
@@ -1,21 +0,0 @@
|
|||||||
---
|
|
||||||
title: Node Requirements
|
|
||||||
---
|
|
||||||
Hardware requirements for nodes (RPC, validator, ...) should be generally along the lines of the specs outlined below.
|
|
||||||
|
|
||||||
For specific node use cases (e.g. full history) specs may differ (and grow) over time.
|
|
||||||
|
|
||||||
### Nodes should run (reasonably) well for own use with:
|
|
||||||
|
|
||||||
* CPU: 6+ cores
|
|
||||||
* Memory: 16GB+ (32GB advised)
|
|
||||||
* Disk IO: 10k random RW
|
|
||||||
* Disk size: 100GB+
|
|
||||||
* Filesystem: EXT4/XFS/...
|
|
||||||
* Network IO: 100Mbit+
|
|
||||||
|
|
||||||
***As of August 6, 2025 the full history for the Xahau Network is approximately 8TB***
|
|
||||||
|
|
||||||
### Nodes for future (network growth) production use:
|
|
||||||
|
|
||||||
<table><thead><tr><th width="140"></th><th width="200">Minimum</th><th width="199">Preferred</th><th>Ideal</th></tr></thead><tbody><tr><td>CPU</td><td>16 cores</td><td>20+ cores</td><td>40+ cores</td></tr><tr><td>Memory</td><td>32GB</td><td>64GB</td><td>128GB+</td></tr><tr><td>Disk IO</td><td>15k random RW</td><td>20k random RW</td><td>30k random RW</td></tr><tr><td>Disk Size</td><td>500GB</td><td>1TB</td><td>2TB</td></tr><tr><td>Filesystem</td><td>XFS</td><td>XFS</td><td>XFS</td></tr><tr><td>Network IO</td><td>500Mbit+</td><td>1Gbit</td><td>10Gbit</td></tr></tbody></table>
|
|
||||||
@@ -1,26 +0,0 @@
|
|||||||
---
|
|
||||||
title: Running a Mainnet Node
|
|
||||||
description: >-
|
|
||||||
Xahau Mainnet allows for running your own local node. You can run a Docker
|
|
||||||
Container or connect with your own local running instance.
|
|
||||||
---
|
|
||||||
### Connecting to the Xahau Mainnet with Docker
|
|
||||||
|
|
||||||
To connect to the Xahau Mainnet you can use this docker container:
|
|
||||||
|
|
||||||
[https://github.com/Xahau/mainnet-docker](https://github.com/Xahau/mainnet-docker)
|
|
||||||
|
|
||||||
1. Clone the repository
|
|
||||||
2. Run `./build`
|
|
||||||
3. Run `./up`
|
|
||||||
4. Check the README for commands, etc. [https://github.com/Xahau/mainnet-docker/blob/main/README.md](https://github.com/Xahau/mainnet-docker/blob/main/README.md)
|
|
||||||
5. Connect using WebSockets or RPC:\
|
|
||||||
WebSocket: `ws://localhost:16006`\
|
|
||||||
RPC (HTTP POST): `http://localhost:16007`
|
|
||||||
|
|
||||||
## Local instance
|
|
||||||
|
|
||||||
### Peering info
|
|
||||||
|
|
||||||
<table data-header-hidden><thead><tr><th width="236.34908136482937"></th><th></th></tr></thead><tbody><tr><td>Info</td><td><a href="https://xahau.network/">https://xahau.network/</a></td></tr><tr><td>Explorer</td><td><a href="https://explorer.xahau.network/">https://explorer.xahau.network/</a></td></tr><tr><td>Technical docs</td><td><a href="https://xrpl-hooks.readme.io/">https://xrpl-hooks.readme.io</a></td></tr><tr><td>WebSocket URL</td><td><a href="wss://xahau.network">wss://xahau.network</a></td></tr><tr><td>Public peering </td><td>Network ID: <strong><code>21337</code></strong></td></tr><tr><td></td><td>- Hub (Cluster) 1: <code>bacab.alloy.ee 21337</code></td></tr><tr><td></td><td>- Hub (Cluster) 2: <code>hubs.xahau.as16089.net 21337</code></td></tr><tr><td></td><td>- Hub 3: <code>xahau-1.cabbit.tech 21337</code></td></tr><tr><td></td><td>- Hub 4: <code>xahau-2.cabbit.tech 21337</code></td></tr><tr><td>Binary & config</td><td><p>For ubuntu 22.04:<br /><br /><strong>Download:</strong></p><p><a href="https://build.xahau.tech"><strong>https://build.xahau.tech</strong></a></p><p></p><p>For the latest release build numbers, see the <a href="https://github.com/Xahau/xahaud/actions?query=branch%3Arelease+is%3Asuccess+build+using+docker"><strong>Github Build Actions</strong></a>.</p><p><br />Extract, then run:<br /><code>./xahaud --net --conf xahaud.cfg</code> Config file sample (to be saved as <code>xahaud.cfg</code>):</p><ul><li><p><a href="https://github.com/Xahau/mainnet-docker/blob/main/store/etc/xahaud.sample.cfg">https://github.com/Xahau/mainnet-docker/blob/main/store/etc/xahaud.cfg</a></p><ul><li>Edit the database path, etc if needed.</li></ul></li><li>In the same folder as the <code>xahaud.cfg</code> config, the <code>validators-xahau.txt</code> file should be stored:<br /><br /><a href="https://github.com/Xahau/mainnet-docker/blob/main/store/etc/validators-xahau.sample.txt">https://github.com/Xahau/mainnet-docker/blob/main/store/etc/validators-xahau.txt</a></li></ul></td></tr><tr><td>UNL (VL)</td><td><a href="https://vl.xahau.org/">https://vl.xahau.org/</a></td></tr></tbody></table>
|
|
||||||
|
|
||||||
@@ -1,36 +0,0 @@
|
|||||||
---
|
|
||||||
title: Running a Testnet Node
|
|
||||||
description: >-
|
|
||||||
Xahau Testnet allows for running your own local node. You can run a Docker
|
|
||||||
Container or connect with your own local running instance.
|
|
||||||
---
|
|
||||||
### Connecting to the Xahau Testnet with Docker
|
|
||||||
|
|
||||||
To connect to the Xahau Testnet (Hooks V3 testnet) you can use this Docker container:
|
|
||||||
|
|
||||||
[https://github.com/Xahau/Xahau-Testnet-Docker/](https://github.com/Xahau/Xahau-Testnet-Docker/)
|
|
||||||
|
|
||||||
1. Clone the repository
|
|
||||||
2. Run `./build`
|
|
||||||
3. Run `./up`
|
|
||||||
4. Check the README for commands, etc.\
|
|
||||||
[https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/README.md](https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/README.md)
|
|
||||||
5. Connect using WebSockets or RPC:\
|
|
||||||
WebSocket: `ws://localhost:16006`\
|
|
||||||
RPC (HTTP POST): `http://localhost:16007`
|
|
||||||
|
|
||||||
## Local instance
|
|
||||||
|
|
||||||
### Peering info
|
|
||||||
|
|
||||||
<table data-header-hidden><thead><tr><th width="181"></th><th></th></tr></thead><tbody><tr><td>Info & Faucet</td><td><a href="https://xahau-test.net/">https://xahau-test.net</a></td></tr><tr><td>Explorer</td><td><a href="https://explorer.xahau-test.net/">https://explorer.xahau-test.net</a></td></tr><tr><td>Technical docs</td><td><a href="https://xrpl-hooks.readme.io/">https://xrpl-hooks.readme.io</a></td></tr><tr><td>WebSocket URL</td><td><a href="https://xahau-test.net/">wss://xahau-test.net</a></td></tr><tr><td>Public peering V4</td><td>Network ID: <strong><code>21338</code></strong><br /><br /><code>79.110.60.122</code> Port: 21338<br /><code>79.110.60.124</code> Port: 21338<br /><code>79.110.60.125</code> Port: 21338<br /><code>79.110.60.121</code> Port: 21338</td></tr><tr><td>Public peering V4</td><td><p><code>2a0c:3bc0::1c74</code> Port: 21338</p><p><code>2a0c:3bc0::169d</code> Port: 21338</p><p><code>2a0c:3bc0::1aaf</code> Port: 21338</p><p><code>2a0c:3bc0::1d78</code> Port: 21338</p></td></tr><tr><td>Binary & config</td><td><p>For ubuntu 22.04:<br /><br /><strong>Download:</strong></p><p><a href="https://build.xahau.tech/2023.9.25-dev%2B336"><strong>https://build.xahau.tech</strong></a> <strong>- fetch the latest RELEASE version</strong><br /></p><p>Extract, then run: <br /><code>./xahaud --net --quorum=2 --conf xahaud.cfg</code> Config file sample (to be saved as <code>xahaud.cfg</code>):</p><ul><li><p><a href="https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/store/etc/xahaud.cfg">https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/store/etc/xahaud.cfg</a></p><ul><li>Edit the database path, etc if needed.</li></ul></li><li>In the same folder as the <code>xahaud.cfg</code> config, the <code>validators-xahau.txt</code> file should be stored:<br /><br /><a href="https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/store/etc/validators-xahau.txt">https://github.com/Xahau/Xahau-Testnet-Docker/blob/main/store/etc/validators-xahau.txt</a></li></ul></td></tr><tr><td>Validators</td><td><code>[validators]</code><br /><code>nHBoJCE3wPgkTcrNPMHyTJFQ2t77EyCAqcBRspFCpL6JhwCm94VZ</code><br /><code>nHUVv4g47bFMySAZFUKVaXUYEmfiUExSoY4FzwXULNwJRzju4XnQ</code><br /><code>nHBvr8avSFTz4TFxZvvi4rEJZZtyqE3J6KAAcVWVtifsE7edPM7q</code><br /><code>nHUH3Z8TRU57zetHbEPr1ynyrJhxQCwrJvNjr4j1SMjYADyW1WWe</code></td></tr></tbody></table>
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### Integrating Xumm with Hooks V3
|
|
||||||
|
|
||||||
<figure>
|
|
||||||
|
|
||||||
</figure>
|
|
||||||
|
|
||||||
To connect Xumm to the Hooks V3 staging net, scan this QR with the QR scanner in Xumm to add the endpoint (above) to the Xumm node list.
|
|
||||||
24
src/content/docs/docs/infrastructure/system-requirements.mdx
Normal file
24
src/content/docs/docs/infrastructure/system-requirements.mdx
Normal file
@@ -0,0 +1,24 @@
|
|||||||
|
---
|
||||||
|
title: System Requirements
|
||||||
|
---
|
||||||
|
Hardware requirements for nodes customized for various tasks (e.g., RPC/WS, hubs, validators, etc.) should be consistent with the specs outlined below. Consider tailoring your individual system based on your intended use case.
|
||||||
|
|
||||||
|
### Types of Nodes
|
||||||
|
It is possible to run xahaud in diverse configurations, based on a users needs. Similarly, one xahaud server can be configured for multiple purposes, such as a full history server that is also used for RPC/WS calls. The server's purpose dictates necessary system requirements. Some xahaud configurations might include:
|
||||||
|
1. Stock server - This term is commonly used to refer to any xahaud node that is not configured as a validator. A stock server generally has very few changes from the default configuration.
|
||||||
|
2. Full history servers - Are useful for querying historic data. In addition to a large amount of storage space, potentially higher disk IOPS and network bandwidth are needed, depending on the number of users querying the server.
|
||||||
|
3. RPC/Websocket servers - Are tailored for tasks such as submitting transactions or querying current ledger data, like order books or the validation stream. Nginx or other proxy sofware is often placed in front of RPC/WS servers to provide load balancing, encryption, and other benefits.
|
||||||
|
4. Hub server - Peering between nodes is critical for relaying messages across the Xahau Network, and a single server can be configured to provide peering for hundreds of peers. However, a large amount of bandwidth can be required (10 Gbit+).
|
||||||
|
5. [Validating servers](../enabling-validation) - Validators differ from other types of nodes, in that they require an additional cryptographic key to be installed, so they can sign off on the sequence of transactions in a proposed ledger. As availability and security are critical, it is not recommended to use a validator for other functions.
|
||||||
|
|
||||||
|
### General Notes
|
||||||
|
* Builds are typically tested on Ubuntu LTS. However, Docker, portable binaries, custom builds, and other install methods allow for diverse operating system support.
|
||||||
|
* Typically one IPv4 and/or IPv6 address is needed for each xahaud instance. Running multiple instances behind one IPv4 address is not recommended.
|
||||||
|
* Machines storing full history must use XFS or similar to avoid limitations with single file size in EXT4 (max. file size of 16TB). If storing less history, EXT4 is sufficient.
|
||||||
|
* It may be possible to run xahaud on machines that do not meet the below "Minimum" specifications for production servers. However, doing so risks instability.
|
||||||
|
* These system requirements may grow over time. For example, disk space for full history servers is consistently increasing.
|
||||||
|
* As of August 6, 2025 <strong>the full history for the Xahau Network is approximately 8TB</strong>.
|
||||||
|
|
||||||
|
### Recommended Specs for Production xahaud Servers
|
||||||
|
|
||||||
|
<table><thead><tr><th width="140"></th><th width="200">Minimum</th><th width="199">Preferred</th><th>Ideal</th></tr></thead><tbody><tr><td>CPU (2.5+ GHz x86_64)</td><td>8 cores</td><td>20 cores</td><td>40+ cores</td></tr><tr><td>Memory</td><td>32GB</td><td>64GB</td><td>128GB+</td></tr><tr><td>Disk IO (sustained)</td><td>15k random RW</td><td>20k random RW</td><td>30k random RW</td></tr><tr><td>Disk Size</td><td>500GB</td><td>1TB</td><td>20TB+</td></tr><tr><td>Filesystem</td><td>XFS</td><td>XFS</td><td>XFS</td></tr><tr><td>Network IO</td><td>500Mbit+</td><td>1Gbit</td><td>10Gbit</td></tr></tbody></table>
|
||||||
49
src/content/docs/docs/infrastructure/updating-xahaud.mdx
Normal file
49
src/content/docs/docs/infrastructure/updating-xahaud.mdx
Normal file
@@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
title: Updating xahaud
|
||||||
|
---
|
||||||
|
The process for updating xahaud varies depending on the install method used, however, all three methods rely on the releases published at [https://build.xahau.tech](https://build.xahau.tech). When updating a validator, hub, or other 'critical' infrastructure, please check the network health prior to restarting a server to install an update. It is possible to automate the update process using a crontab entry and an update script, however, administrators are discouraged from doing so, as automatic updates may result in restarts at times when the network is unstable. Similarly, human presence allows operators to ensure updates are successful, thereby minimizing downtime.
|
||||||
|
|
||||||
|
### Backup
|
||||||
|
Users should always keep backups of:
|
||||||
|
1. The primary configuration file: `xahaud.cfg`
|
||||||
|
- Location varies based on install type.
|
||||||
|
2. The trusted validators file: `validators-xahau.txt`
|
||||||
|
- Location is specified in 'xahaud.cfg'.
|
||||||
|
3. The server's identity credentials: `wallet.db`
|
||||||
|
- Located in the database directory defined in 'xahaud.cfg'.
|
||||||
|
4. Validators must keep their validation private key backed up in a secure, offline location.
|
||||||
|
|
||||||
|
### Updating Docker Containers
|
||||||
|
Updating xahaud inside a Docker container involves replacing the currently running binary with the new version, downloaded from [https://build.xahau.tech](https://build.xahau.tech). This can be accomplished either by replacing the xahaud binary inside the container or by updating the entire container.
|
||||||
|
<br></br>
|
||||||
|
To update the xahaud binary inside a running Docker container:
|
||||||
|
1. Download the [script](https://gist.githubusercontent.com/WietseWind/2ed35d85dcd056d82645de2958934f86/raw/34be773fd6af42e82cc3a21baf70bfb1e2a6c583/update.sh): `wget https://gist.githubusercontent.com/WietseWind/2ed35d85dcd056d82645de2958934f86/raw/34be773fd6af42e82cc3a21baf70bfb1e2a6c583/update.sh`
|
||||||
|
2. Edit the script and change the first line to the [release version](https://build.xahau.tech) you would like to install.
|
||||||
|
3. Run the script: `bash ./update.sh`
|
||||||
|
4. Verify xahaud is running: `docker exec xahaud-[mainnet/testnet] xahaud server_info`
|
||||||
|
<br></br>
|
||||||
|
To replace the current Docker image with a new version, without overwriting databases or configuration files (which are ignored via the .gitignore file):
|
||||||
|
1. Navigate to the repository: `cd [/path/to/docker-repo]`
|
||||||
|
2. Update to the latest version `git pull`
|
||||||
|
3. List running Docker containers and note the name of the xahaud container: `docker ps`
|
||||||
|
4. Stop the old xahaud instance: `docker stop xahaud-[mainnet/testnet]`
|
||||||
|
5. Remove the old instance: `docker rm xahaud-[mainnet/testnet]`
|
||||||
|
6. Start the new instance: `./build && ./up`
|
||||||
|
|
||||||
|
### Updating Local Installations
|
||||||
|
To update a locally installed version of xahaud, simply replace the current binary with a new binary:
|
||||||
|
1. Download the new binary from: [https://build.xahau.tech](https://build.xahau.tech)
|
||||||
|
2. Mark the new binary executable: `chmod +x [/path/to/download]`
|
||||||
|
3. Stop the currently running xahaud instance: `/opt/xahaud/bin/xahaud stop`
|
||||||
|
4. Replace the old binary with the new: `mv [/path/to/download] /opt/xahaud/bin/xahaud`
|
||||||
|
5. Start xahaud: `systemctl start xahaud`
|
||||||
|
6. Verify xahaud is running: `/opt/xahaud/bin/xahaud server_info`
|
||||||
|
<br></br>
|
||||||
|
A [script](https://gist.githubusercontent.com/WietseWind/9480a4fc95e904e54524406005c8c963/raw/2b200fdc2e5b471ae4f6625674aff1765d63e744/update.sh) that automates the above steps is available.
|
||||||
|
|
||||||
|
### Updating Binary Files
|
||||||
|
Updating the xahaud binary files is essentially the same as the original install instructions:
|
||||||
|
1. Remove the currently running version: `rm [/path/to/xahaud]`
|
||||||
|
2. Download the new version: [https://build.xahau.tech](https://build.xahau.tech)
|
||||||
|
3. Mark the download as executable: `chmod 500 [/path/to/xahaud]`
|
||||||
|
4. Start xahaud: `./[path/to/xahud] --net --conf [/path/to/xahaud.cfg]`
|
||||||
@@ -64,9 +64,9 @@ Xahau's governance structure differs from XRPL's. Xahau has its own approach to
|
|||||||
|
|
||||||
#### Node Requirements
|
#### Node Requirements
|
||||||
|
|
||||||
Running a Xahau node has different requirements compared to an XRPL node. These differences could be related to the technical specifications needed to support Xahau's unique features and network demands.
|
Running a Xahau node has different requirements compared to an XRPL node. These differences relate to the technical specifications needed to support Xahau's unique features and network demands.
|
||||||
|
|
||||||
<LinkCard title="Node Requirements" href="../infrastructure/node-requirements" />
|
<LinkCard title="System Requirements" href="../infrastructure/system-requirements" />
|
||||||
|
|
||||||
#### Native Token
|
#### Native Token
|
||||||
|
|
||||||
|
|||||||
@@ -78,7 +78,7 @@ const { frontmatter } = Astro.props
|
|||||||
<h3 class="text-xl md:text-2xl font-semibold">Ledgers closed</h3>
|
<h3 class="text-xl md:text-2xl font-semibold">Ledgers closed</h3>
|
||||||
<h4 class="text-4xl md:text-6xl font-extrabold">16M+</h4>
|
<h4 class="text-4xl md:text-6xl font-extrabold">16M+</h4>
|
||||||
</div>
|
</div>
|
||||||
<a href="/docs/infrastructure/node-requirements/" class="col-span-6 row-start-auto md:row-start-2 px-10 h-12 flex items-center justify-center bg-xahau-green text-black text-base font-bold hover:bg-black hover:text-white transition">Want to run a node?</a>
|
<a href="/docs/infrastructure/system-requirements/" class="col-span-6 row-start-auto md:row-start-2 px-10 h-12 flex items-center justify-center bg-xahau-green text-black text-base font-bold hover:bg-black hover:text-white transition">Want to run a node?</a>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|||||||
Reference in New Issue
Block a user