From 0f14be0422e60b08add60a785c0b5c9581d41b06 Mon Sep 17 00:00:00 2001 From: mennatabuelnaga Date: Thu, 11 Jan 2024 15:34:48 +0200 Subject: [PATCH] docs: initialize validator docs fix docs fix docs --- run_a_node.md | 254 ++++++++++++++++++++++++++++++++++++++++++++++ validators_faq.md | 252 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 506 insertions(+) create mode 100644 run_a_node.md create mode 100644 validators_faq.md diff --git a/run_a_node.md b/run_a_node.md new file mode 100644 index 00000000..340c35ea --- /dev/null +++ b/run_a_node.md @@ -0,0 +1,254 @@ +# Running a Node + +This section is for: + +* Users who want to connect to a remote node. +* Users who want to run a node. +* Users who want to run a Validator . + +## Configure Environment Variables + +After installing Go, it is recommended to configure related environment variables: + +``` +# ~/.bashrc +export GOROOT=/usr/local/go +export GOPATH=$HOME/.go +export GOBIN=$GOPATH/bin +export PATH=$PATH:$GOPATH/bin:$GOROOT/bin +``` + +The provided code block is a set of environment variable assignments in a bash configuration file (~/.bashrc). These environment variables are commonly used in Go programming and their purpose is to specify the location of Go installation, workspace, and executable files: + +* export GOROOT=/usr/local/go assigns the location of the Go installation directory to the GOROOT environment variable. The export keyword ensures that this variable is accessible to child processes. If using a package manager such as homebrew, this location may vary. +* export GOPATH=$HOME/.go assigns the location of the Go workspace directory to the GOPATH environment variable. The workspace is where Go source code and its dependencies are stored. By default, the workspace is located in $HOME/go but can be customized using this environment variable. +* export GOBIN=$GOPATH/bin assigns the location of the Go executable files to the GOBIN environment variable. This variable specifies the directory where Go binary files will be installed when using go install command. +* Finally, export PATH=\$PATH:\$GOPATH/bin:$GOROOT/bin adds the directories specified in GOPATH/bin and GOROOT/bin to the system's PATH variable This makes it possible to execute Go binaries from any directory in the terminal by simply typing their name. +Overall, this is a convenient way to set up the Go development environment by specifying the important directories and their locations as environment variables. + +## Installing seda-chaind + +seda-chaind (short for seda-chain daemon”) is the command line interface that connects with SEDA and allows you to interact with the SEDA blockchain. Every node operator and active validator uses seda-chaind to interact with their node. + +To install seda-chaind, clone the seda-chain repository, checkout the latest tag, and compile the code: + +git clone :sedaprotocol/seda-chain.git
+git checkout [latest-tag]
+make install
+A seda-chaind executable will be created in the $GOBIN directory.
+ +## Generate Operator Key + +Each node comes with three private keys: an operator key, a consensus key, and a node key. At this point, you only need an operator key to transact using seda-chaind (which can be achieved by connecting to a remote node). Later sections will cover consensus and node keys as well. + +To generate your operator key, run the following command: + +``` +seda-chaind keys add +``` + +Make sure you save the mnemonics! After you end your terminal session, your keys cannot be recovered. + +To use an existing seed phrase, run the following command: + +``` +seda-chaind keys add --recover +``` + +## Connecting to a Remote Node + +Users who prefer to not operate a node or Validator can connect to a remote node with seda-chaind by appending the --node flag at the end of requests along with an RPC endpoint in the https://: format. Alternatively, Users can configure a default node using the following command: + +``` +seda-chaind config node https://[host]:[port] +``` + +If you are connecting to a remote node, select a node operator that you can trust. Malicious operators can alter query results and censor transactions. SEDA currently maintaisn the following RPC endpoints for public use: + +* Testnet (TODO): TODO +* Devnet (seda-1): TODO + +At this point, you can begin interacting with the SEDA blockchain through a remote node. To learn about the list of available commands, run seda-chaind --help in your terminal. For more information about a specific command, append the --help flag at the end of your request, for example: + +``` +seda-chaind query --help +seda-chaind query bank --help +``` + +## Joining Testnet/Devnet + +### Initialize your node + +``` + +$BIN tendermint unsafe-reset-all +rm -rf ~/.seda-chain || true + + + + +seda-chaind join --network [--recover] +``` + +Replace \ with any string you’d like. This is the name to identify your server. For prospective Validators, this is NOT your validator's moniker, which we will create later. + +Running this command also creates your consensus and node keys, as well as a .seda-chain folder under your home directory with some config files for your node: + +``` +~/.seda-chain +├─┬ config +│ ├── app.toml +│ ├── client.toml +│ ├── config.toml +│ ├── genesis.json +│ ├── node_key.json +│ ├── priv_validator_key.json +└─┬ data + └── priv_validator_state.json +``` + +Let's walk over each file created: + +* app.toml - Used to specify application-level settings, such as gas price, API endpoints to serve, and so on +* client.toml - The config for the app’s command line interface. This is where you can set defaul parameters, such as a default --chain-id. +* config.toml - Used to specify settings for the underlying Tendermint consensus engine, which handles networking, P2P connections, and consensus. +* genesis.json - Contains the initial set of transactions that defines the state of the blockchain at its inception. +* node_key.json - Contains a private key that is used for node authentication in the peer-to-peer (p2p) protocol. priv_validator_key.json - Contains the private key for Validators, which is used to sign blocks and votes. You should back up this file and don't show anyone else its content. +* priv_validator_state.json - used to store the current state of the private validator. This includes information such as the current round and height of the validator, as well as the latest signed vote and block. This file is typically managed by the Tendermint consensus engine and used to prevent your node from double-signing. + +### Run the Node + +You can now launch the network with seda-chaind start! + +However, running the network this way requires a shell to always be open. You can, instead, create a service file that will manage running the network for you. + +Once you’ve started your node, you will need to wait for the node to sync up to the latest block. To check the node's sync status, you can run the following command: + +``` +seda-chaind status 2>&1 | jq +``` + +jq formats the output into a more readable format. 2>&1 is necessary due to a bug where Cosmos SDK mistakenly outputs the status to stderr instead of stdout. Your node is synced up if SyncInfo.catching_up is false. + +## Running as a service + +We will now run our executable as a service in order for it to be easily managed. In your system directory as a root user at /etc/systemd/system create a new service file named validator.service + +``` +nano validator.service +``` + +Use the below service file and change any specific parameters respective to your setup. + +``` +[Unit] +Description=SEDA Testnet Validator +After=network-online.target + +[Service] +User=validator +ExecStart=/home/validator/go/bin/seda-chaind start --x-crisis-skip-assert-invariants +Restart=always +RestartSec=3 +LimitNOFILE=4096 + +[Install] +WantedBy=multi-user.target +``` + +The following are systemd commands, used to manage your service: + +``` + +systemctl enable validator.service + + +systemctl daemon-reload + + +systemctl restart validator.service + + +systemctl start validator.service + + +systemctl stop validator.service + + +journalctl -u validator.service -f + +``` + +## Create Validator + +In order to create your validator, make sure you are fully synced to the latest block height of the network. + +You can check by using the following command: + +``` +curl -s localhost:26657/status | jq .result | jq .sync_info +``` + +In the output of the above command make sure catching_up is false + +``` +“catching_up”: false +``` + +Create a validator.json file and fill in the create-validator tx parameters: + +``` +{ + "pubkey": {"@type":"/cosmos.crypto.ed25519.PubKey","key":"$(seda-chaind tendermint show-validator)"}, + "amount": "1000000000000000000000000000000000aseda", + "moniker": "the moniker for your validator", + "identity": "optional identity signature (ex. UPort or Keybase) This key will be used by block explorers to identify the validator.", + "website": "validator's (optional) website", + "security": "validator's (optional) security contact email", + "details": "validator's (optional) details", + "commission-rate": "0.1", + "commission-max-rate": "0.2", + "commission-max-change-rate": "0.01", + "min-self-delegation": "1" +} +``` + +Let’s go through some flags: + +* amount: The amount of aseda (the cryptocurrency used on the SEDA network) that the validator will stake as part of its candidacy. +* identity: The [Keybase](https://keybase.io/) PGP key associated with the validator's keybase.io account. This key will be used by block explorers to identify the validator. +* commission-rate: The percentage of rewards that the validator charges for its services.
+Note: The commission-rate value must adhere to the following rules:
+1- Must be between 0 and the validator's commission-max-rate.
+2- Must not exceed the validator's commission-max-change-rate which is maximum % point change rate per day. In other words, a validator can only change its commission once per day and within commission-max-change-rate bounds.
+Warning: Please note that some parameters such as commission-max-rate and commission-max-change-rate cannot be changed once your validator is up and running.
+* commission-max-rate: The maximum percentage that the validator can charge for its services. This number can not be changed and is meant to increase trust between you and your delegators. If you wish to go above this limit, you will have to create a new validator. +* commission-max-change-rate: The maximum percentage that the validator can increase or decrease its commission rate by. +* min-self-delegation: The minimum amount of the validator's own tokens that the validator must hold in order to remain active. If you withdraw your self-delegation below this threshold, your validator will be immediately removed from the active set. Your validator will not be slashed, but will stop earning staking rewards. This is considered the proper way for a validator to voluntarily cease operation. NOTE: If you intend to shut down your Validator, make sure to communicate with your delegators at least 14 days before withdrawing your self-delegation so that they have sufficient time to redelegate and not miss out on staking rewards. + +Create a validator using the following command: + +``` +seda-chaind tx staking create-validator validator.json --from --chain-id --node +``` + +That’s it now you can find your validator operator address using the following command, which you can advertise to receive delegations: + +``` +seda-chaind keys show --bech val -a +``` + +## Useful Commands + +``` + +seda-chaind q staking params | grep max_validators + + +seda-chaind q staking validators -o json --limit=1000 | jq '.validators[] | select(.status=="BOND_STATUS_BONDED")' | jq -r '.tokens + " - " + .description.moniker' | sort -gr | nl + + +seda-chaind q staking validators -o json --limit=1000 | jq '.validators[] | select(.status=="BOND_STATUS_UNBONDED")' | jq -r '.tokens + " - " + .description.moniker' | sort -gr | nl +``` + +## Useful Scripts: TODO diff --git a/validators_faq.md b/validators_faq.md new file mode 100644 index 00000000..9a58b605 --- /dev/null +++ b/validators_faq.md @@ -0,0 +1,252 @@ +# Validators FAQ + +*Disclaimer: This is work in progress. Mechanisms and values are susceptible to change* + +## General concepts + +### What is a validator? + +SEDA is based on Tendermint, which relies on a set of validators to secure the network. The role of validators is to run a full-node and participate in consensus by broadcasting votes which contain cryptographic signatures signed by their private key. Validators commit new blocks in the blockchain and receive revenue in exchange for their work. They must also participate in governance by voting on proposals. Validators are weighted according to their total stake. + +### What is 'staking'? + +SEDA is a public Proof-Of-Stake (PoS) blockchain, meaning that validator's weight is determined by the amount of staking tokens (Seda) bonded as collateral. These Sedas can be staked directly by the validator or delegated to them by Seda holders. +Any user in the system can declare its intention to become a validator by sending a "create-validator" transaction. From there, they become validator candidates. +The weight (i.e. total stake) of a candidate determines wether or not it is a validator, and also how frequently this node will have to propose a block and how much revenue it will obtain. Initially, only the top 100 validator candidates with the most weight will be validators. If validators double sign, are frequently offline or do not participate in governance, their staked Seda (including Sedas of users that delegated to them) can be destroyed, or 'slashed'. + +### What is a full-node? + +A full-node is a program that fully validates transactions and blocks of a blockchain. It is distinct from a light-node that only processes block headers and a small subset of transactions. Running a full-node requires more resources than a light-node but is necessary in order to be a validator. In practice, running a full-node only implies running a non-compromised and up-to-date version of the software with low network latency and without downtime. +Of course, it is possible and encouraged for any user to run full-nodes even if they do not plan to be validators. + +### What is a delegator? + +Delegators are Seda holders who cannot, or do not want to run validator operations themselves. A user can delegate Sedas m to a validator and obtain a part of its revenue in exchange (for more detail on how revenue is distributed, see **What is the incentive to stake?** and **What is a validator's commission?** sections below). +Because they share revenue with their validators, delegators also share responsiblity. Should a validator misbehave, each of its delegators will be partially slashed in proportion to their stake. This is why delegators should perform due diligence on validator candidates before delegating, as well as spreading their stake over multiple validators. +Delegators play a critical role in the system, as they are responsible for choosing validators. Being a delegator is not a passive role: Delegators should actively monitor the actions of their validators and participate in governance. + +## Becoming a validator + +### How to become a validator? + +Any participant in the network can signal that they want to become a validator by sending a “create-validator” transaction. Once the validator has been created, Seda holders can delegate Sedas to it, effectively adding stake to this pool. The total stake of an address is the combination of Sedas bonded by delegators and Sedas self-bonded by the entity which designated itself. + +Out of all the candidates that signaled themselves, the 100 with the most stake are the ones who are designated as validators. If a validator’s total stake falls below the top 100 then that validator loses its validator privileges. + +### Is there a faucet? + +If you want to obtain coins, you can do so by using this [faucet](https://ping-api.testnet.seda.xyz/faucet) + +### Is there a minimum amount of Sedas that must be staked to be a validator? + +There is no minimum. The top 100 validator candidates with the highest total stake (where total stake = self-bonded stake + delegators stake) are the validators. + +### How will delegators choose their validators? + +Delegators are free to choose validators according to their own subjective criteria. This said, criteria anticipated to be important include: + +* **Amount of self-bonded Sedas:** Number of Sedas a validator self-bonded to its staking pool. A validator with higher amount of self-bonded Sedas has more skin in the game, making it more liable for its actions. +* **Amount of delegated Sedas:** Total number of Sedas delegated to a validator. A high stake shows that the community trusts this validator, but it also means that this validator is a bigger target for hackers. Indeed, hackers are incentivized to hack bigger validators as they receive a reward proportionate to the stake of the validator they can prove to have compromised. Validators are expected to become less and less attractive as their amount of delegated Sedas grows. +* **Commission rate:** Commission applied on revenue by validators before it is distributed to their delegators +* **Track record:** Delegators will likely look at the track record of the validators they plan to delegate to. This includes seniority, past votes on proposals, historical average uptime and how often the node was compromised. + +Apart from these criteria that will be displayed in the SEDA UI, there will be a possibility for validators to signal a website address to complete their resume. Validators will need to build reputation one way or another to attract delegators. For example, it would be a good practice for validators to have their setup audited by third parties. + +## Validator directives + +### Do validators need to be publicly identified? + +No, they do not. Each delegator will value validators based on their own criteria. Validators will be able (and are advised) to register a website address when they nominate themselves so that they can advertise their operation as they see fit. Some delegators may prefer a website that clearly displays the team running the validator and their resume, while others might prefer anonymous validators with positive track records. Most likely both identified and anonymous validators will coexist in the validator set. + +### What are the responsiblities of a validator? + +Validators have two main responsibilities: + +* **Be able to constantly run a correct version of the software:** validators need to make sure that their servers are always online and their private keys are not compromised. +* **Actively participate in governance:** validators are required to vote on every proposal. + +Additionally, validators are expected to be active members of the community. They should always be up-to-date with the current state of the ecosystem so that they can easily adapt to any change. + +### What does ‘participate in governance’ entail? + +Validators and delegators on SEDA can vote on proposals to change operational parameters (such as the block gas limit), coordinate upgrades, as well as vote on amendments to the human-readable constitution that govern SEDA. + +Validators play a special role in the governance system. Being the pillars of the system, they are required to vote on every proposal. It is especially important since delegators who do not vote will inherit the vote of their validator. Each time a validator does not vote on a proposal, it will get slashed by a minimal amount. + +### What does staking imply? + +Staking Sedas can be thought of as a safety deposit on validation activities. When a validator or a delegator wants to retrieve part or all of their deposit, they send an unbonding transaction. Then, Sedas undergo a *three weeks unbonding period* during which they are liable to being slashed for potential misbehaviors committed by the validator before the unbonding process started. + +Validators, and by association delegators, receive block provisions, block rewards, fee rewards, and the right to participate in governance. If a validator misbehaves, a certain portion of its total stake is slashed (the severity of the penalty depends on the type of misbehavior). This means that every user that bonded Sedas to this validator gets penalized in proportion to its stake. Delegators are therefore incentivized to delegate to validators that they anticipate will function safely. + +### Can a validator run away with its delegators' Sedas? + +By delegating to a validator, a user delegates staking power. The more staking power a validator has, the more weight it has in the consensus and governance processes. This does not mean that the validator has custody of its delegators' Sedas. *By no means can a validator run away with its delegator’s funds*. + +Even though delegated funds cannot be stolen by their validators, delegators are still liable if their validators misbehave. In such case, each delegators' stake will be partially slashed in proportion to their relative stake. + +### How often will a validator be chosen to propose the next block? Does it go up with the quantity of Sedas staked? + +The validator that is selected to propose the next block is called proposer. Each proposer is selected deterministically, and the frequency of being chosen is equal to the relative total stake (where total stake = self-bonded stake + delegators stake) of the validator. For example, if the total bonded stake across all validators is 100 Sedas and a validator's total stake is 10 Sedas, then this validator will be chosen 10% of the time as the next proposer. + +## Staking and incentives + +### What is the incentive to stake? TODO + +``` + + +Each member of a validator’s staking pool earns different types of revenue: +* **Block provisions:** Native tokens of applications run by validators (e.g. Atoms on the Cosmos Hub) are inflated to produce block provisions. These provisions exist to incentivize Atom holders to bond their stake, as non-bonded Atom will be diluted over time. +* **Block rewards:** For the Ethermint zone, block rewards are paid in Photons. Initial distribution of Photons will be hard spooned from Ethereum. This means Photons will be emitted 1:1 to Ether. +* **Transaction fees:** The Cosmos Hub maintains a whitelist of token that are accepted as fee payment. + +This total revenue is divided among validators' staking pools according to each validator’s weight. Then, within each validator's staking pool the revenue is divided among delegators in proportion to each delegator’s stake. Note that a commission on delegators' revenue is applied by the validator before it is distributed. +``` + +### What is the incentive to run a validator? + +Validators earn proportionally more revenue than their delegators because of commissions. + +Validators also play a major role in governance. If a delegator does not vote, it inherits the vote from its validator. This gives validators a major responsibility in the ecosystem. + +### What is a validator's commission? + +Revenue received by a validator’s pool is split between the validator and its delegators. The validator can apply a commission on the part of the revenue that goes to its delegators. This commission is set as a percentage. Each validator is free to set its initial commission, maximum daily commission change rate and maximum commission. SEDA enforces the parameter that each validator sets. These parameters can only be defined when initially creating the validator, and may only be constrained further after being created. + +### How are block provisions distributed? TODO + +``` + +Block provisions are distributed proportionally to all validators relative to their total stake. This means that even though each validator gains Sedas with each provision, all validators will still maintain equal weight. + +Let us take an example where we have 10 validators with equal staking power and a commission rate of 1%. Let us also assume that the provision for a block is 1000 Sedas and that each validator has 20% of self-bonded Sedas. These tokens do not go directly to the proposer. Instead, they are evenly spread among validators. So now each validator’s pool has 100 Sedas. These 100 Sedas will be distributed according to each participant’s stake: + +* Commission: 100*80%*1% = 0.8 Sedas +* Validator gets: 100*20% + Commission = 20.8 Sedas +* All delegators get: 100*80% - Commission = 79.2 Sedas + +Then, each delegator can claim its part of the 79.2 Sedas in proportion to their stake in the validator’s staking pool. Note that the validator's commission is not applied on block provisions. Note that block rewards (paid in Photons) are distributed according to the same mechanism. +``` + +### How are fees distributed? TODO + +``` + +Fees are similarly distributed with the exception that the block proposer can get a bonus on the fees of the block it proposes if it includes more than the strict minimum of required precommits. + +When a validator is selected to propose the next block, it must include at least 2/3 precommits for the previous block in the form of validator signatures. However, there is an incentive to include more than 2/3 precommits in the form of a bonus. The bonus is linear: it ranges from 1% if the proposer includes 2/3rd precommits (minimum for the block to be valid) to 5% if the proposer includes 100% precommits. Of course the proposer should not wait too long or other validators may timeout and move on to the next proposer. As such, validators have to find a balance between wait-time to get the most signatures and risk of losing out on proposing the next block. This mechanism aims to incentivize non-empty block proposals, better networking between validators as well as to mitigate censorship. + +Let’s take a concrete example to illustrate the aforementioned concept. In this example, there are 10 validators with equal stake. Each of them applies a 1% commission and has 20% of self-bonded Sedas. Now comes a successful block that collects a total of 1025.51020408 Sedas in fees. + +First, a 2% tax is applied. The corresponding Sedas go to the reserve pool. Reserve pool's funds can be allocated through governance to fund bounties and upgrades. + +* 2% * 1025.51020408 = 20.51020408 Sedas go to the reserve pool. + +1005 Sedas now remain. Let’s assume that the proposer included 100% of the signatures in its block. It thus obtains the full bonus of 5%. + +We have to solve this simple equation to find the reward R for each validator: + +`9*R + R + R*5% = 1005 ⇔ R = 1005/10.05 = 100` + +* For the proposer validator + * The pool obtains R + R*5%: 105 Sedas + * Commission: 105*80%*1% = 0.84 Sedas + * Validator's reward: 105 * 20% + Commission = 21.84 Sedas + * Delegators' rewards: 105 * 80% - Commission = 83.16 Sedas (each delegator will be able to claim its portion of these rewards in proportion to their stake) +* For each non-proposer validator + * The pool obtains R: 100 Sedas + * Commission: 100*80%*1% = 0.8 Sedas + * Validator's reward: 100 * 20% + Commission = 20.8 Sedas + * Delegators' rewards: 100 * 80% - Commission = 79.2 Sedas (each delegator will be able to claim its portion of these rewards in proportion to their stake) +``` + +### What are the slashing conditions? TODO +``` + +If a validator misbehaves, its bonded stake along with its delegators' stake and will be slashed. The severity of the punishment depends on the type of fault. There are 3 main faults that can result in slashing of funds for a validator and its delegators: + +* **Double signing:** If someone reports on chain A that a validator signed two blocks at the same height on chain A and chain B, this validator will get slashed on chain A +* **Unavailability:** If a validator’s signature has not been included in the last X blocks, the validator will get slashed by a marginal amount proportional to X. If X is above a certain limit Y, then the validator will get unbonded +* **Non-voting:** If a validator did not vote on a proposal and once the fault is reported by a someone, its stake will receive a minor slash. + +Note that even if a validator does not intentionally misbehave, it can still be slashed if its node crashes, looses connectivity, gets DDOSed, or if its private key is compromised. A complete document on the economics of the network will be published soon. +``` + +### Do validators need to self-bond Sedas? + +No, they do not. A validators total stake is equal to the sum of its own self-bonded stake and of its delegated stake. This means that a validator can compensate its low amount of self-bonded stake by attracting more delegators. This is why reputation is very important for validators. + +Even though there is no obligation for validators to self-bond Sedas, delegators should want their validator to have self-bonded Sedas in their staking pool. In other words, validators should have skin in the game. + +In order for delegators to have some guarantee about how much skin-in-the-game their validator has, the latter can signal a minimum amount of self-bonded Sedas. If a validator's self-bond goes below the limit that it predefined, this validator and all of its delegators will unbond. + +### How to prevent concentration of stake in the hands of a few top validators? TODO +``` + +For now the community is expected to behave in a smart and self-preserving way. When a mining pool in Bitcoin gets too much mining power the community usually stops contributing to that pool. The SEDA network will rely on the same effect initially. In the future, other mechanisms will be deployed to smoothen this process as much as possible: + +* **Penalty-free re-delegation:** This is to allow delegators to easily switch from one validator to another, in order to reduce validator stickiness. +* **Hack bounty:** This is an incentive for the community to hack validators. There will be bounties proportionate to the size of the validator, so that a validator becomes a bigger target as its stake grows. +* **UI warning:** Users will be warned by the SEDA UI if they want to delegate to a validator that already has a significant amount of staking power. +``` + +## Technical requirements + +### What are hardware requirements? TODO + +A production-ready server typically requires: + +* 8-core x86 CPU +* 64 GB RAM - Cosmos apps typically use less than 32 GB under normal conditions, but during events such as chain upgrades, up to 64 GB is usually needed. +* 4 TB NVME SSD. Hard drive I/O speed is crucial! Validators who run on HDD or SATA SSD often find themselves missing blocks. The requirement for disk space can depend on your pruning settings, but generally, at least 2 TB is recommended. +* Linux or macOS operating system +* Go v1.19+ +Note that requirements may be significantly lower for SEDA during the chains early stages. As the blockchain matures, a higher performing server will be needed. + + +### What are software requirements? + +In addition to running a SEDA network node, validators should develop monitoring, alerting and management solutions. + +### What are bandwidth requirements? TODO + +The SEDA network has the capacity for very high throughput relative to chains like Ethereum or Bitcoin. +We recommend that the data center nodes only connect to trusted full-nodes in the cloud or other validators that know each other socially. This relieves the data center node from the burden of mitigating denial-of-service attacks. +Ultimately, as the network becomes more heavily used, multigigabyte per day bandwidth is very realistic. + +### What does running a validator imply in terms of logistics? + +A successful validator operation will require the efforts of multiple highly skilled individuals and continuous operational attention. This will be considerably more involved than running a bitcoin miner for instance. + +### How to handle key management? TODO + +Validators should expect to run an HSM that supports ed25519 keys. Here are potential options: + +* YubiHSM 2 +* Ledger Nano S +* Ledger BOLOS SGX enclave +* Thales nShield support +* Tendermint SGX enclave + +The SEDA Team does not recommend one solution above the other. The community is encouraged to bolster the effort to improve HSMs and the security of key management. + +### What can validators expect in terms of operations? + +Running effective operation is the key to avoiding unexpectedly unbonding or being slashed. This includes being able to respond to attacks, outages, as well as to maintain security and isolation in your data center. + +### What are the maintenance requirements? + +Validators should expect to perform regular software updates to accommodate upgrades and bug fixes. There will inevitably be issues with the network early in its bootstrapping phase that will require substantial vigilance. + +### How can validators protect themselves from denial-of-service attacks? TODO + +Denial-of-service attacks occur when an attacker sends a flood of internet traffic to an IP address to prevent the server at the IP address from connecting to the internet. +An attacker scans the network, tries to learn the IP address of various validator nodes and disconnect them from communication by flooding them with traffic. + +One recommended way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture. +Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator's node directly to its sentry nodes, and may require new sentry nodes be spun up or activated to mitigate attacks on existing ones. + +Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet based attacked cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network. + +It is expected that good operating procedures on that part of validators will completely mitigate these threats.