update set up validator doc #1037
Conversation
|
Skipping AI review because this PR is from a fork. A maintainer can start the review by commenting /review in this PR. |
|
To fix the spell checker, add To fix the formatter, install dependencies with |
reveloper
requested review from
reveloper
and removed request for
hacker-volodya
| --- | ||
| title: "Run a node with MyTonCtrl" | ||
| description: "Provision hardware, install MyTonCtrl, and follow runbooks for validator, liteserver, or archive roles." | ||
| title: "Run a validator node with MyTonCtrl" |
There was a problem hiding this comment.
Since we rolled back to the split-by-nodes guide structure in node section, I suggest renaming the file to run-a-validator.mdx
| The TON Foundation validates the following instances for validator-class workloads: | ||
| Learn more about the [slashing policy](/v3/documentation/nodes/validation/staking-incentives#decentralized-system-of-penalties). | ||
|
|
||
| | Cloud Provider | Instance Type | CPU | RAM | Storage | Network | Public IP | Traffic | |
There was a problem hiding this comment.
This section seems very useful. Can we align validator-recommended environments in this guide?
| All types of nodes require a static external IP address, one UDP port forwarded for incoming connections, and all outgoing connections to be open—the node uses random ports for new outgoing connections. The node must also be visible to the outside world over the NAT. | ||
|
|
||
| > Disk latency is the common bottleneck. Benchmark storage before going live (`MyTonCtrl> benchmark`). | ||
| You can work with your network provider or [rent a server](/v3/guidelines/nodes/running-nodes/full-node#recommended-providers) to run a node. |
There was a problem hiding this comment.
The link is broken. We need to transfer this table.
| If a validator processes less than 90% of the expected blocks during a validation round, they will be fined by 101 TON. | ||
|
|
||
| The TON Foundation validates the following instances for validator-class workloads: | ||
| Learn more about the [slashing policy](/v3/documentation/nodes/validation/staking-incentives#decentralized-system-of-penalties). |
| sudo bash install.sh -d | ||
| sudo bash install.sh | ||
| ``` | ||
| After that the wizard (interactive CLI installer) will be launched, choose `validator` mode and **Single pool** staking mode or other desired [staking mode](#staking-types). |
There was a problem hiding this comment.
We create a point of weakness here if we discuss various ways for the installation validator. We should be very strict and declare only one way. Don't skip "obvious steps". Example:
- Select validator in the mode list
- Select Mainnet
- Select Single pool
Extra: I strongly suggest reordering the staking option list. We should hide the validator wallet mode from the default installation workflow.
| wget https://raw.githubusercontent.com/ton-blockchain/mytonctrl/master/scripts/install.sh | ||
| sudo bash install.sh -d | ||
| sudo bash install.sh | ||
| ``` |
There was a problem hiding this comment.
I think we should just specify a ready-made command ONLY in this guideline.
Mainnet
sudo bash install.sh -m single-nominator -n mainnet
Testnet
sudo bash install.sh -m single-nominator -n testnet
When we discuss other options, we just confuse our users. For sure, these modes should be specified in the documentation.
| - `status_fast` prints live metrics such as `timeDiff` and `Local validator out of sync`; both should trend toward zero on a healthy node. | ||
| - `status_modes` confirms which modes are currently enabled. | ||
|
|
||
| After installation, verify ownership so MyTonCtrl and validator processes can access state and keys: |
There was a problem hiding this comment.
We need recomendation/explanation for these steps:
Extra: I think most users prefer to just see the installation log with default settings chosed after executing the command:
sudo bash install.sh -m single-nominator -n mainnet
3 participants
Closes #996