Validator hardware requirements

Hello,

Could anyone please specify what are the optimal hardware requirements for running a validator server/node?

Is there any slashing of the staked tokens for server/node downside? Or the only punishment for downside can be negative votes from Guardians?

Thank you for clarification.

2 Likes

Regarding the node hardware requirements, using m4.2xlarge would suffice

2 Likes

Right now slashing validators is not yet enabled (but it should be enabled sometime at the future).

Like you said, Guardians can vote out validators that they dislike. That would, in turn, deprive validators of future rewards and would enter validators into a cool-down period in which their deposit will be locked.

Here is a post that you might find useful: link

3 Likes

Thanks for the question.

As @avilanthe1 mentioned, currently, the only punishment for misbehaving Validators is that they risk being voted-out by Guardians, and losing future rewards.
When locking is introduced, a Validator that was voted out would have to wait (a cool-down period of around 1 month) before she could pull her locked coins. During the cool-down period, Validators do not have control over their coins (they are still locked), but they don’t get any rewards for their locked coins (because they were voted out). This is a form of “soft slashing” if you will.

In any case, future slashing would probably not punish for downtime. It is very hard to determine whether a Validator was actually down or whether the other Validators are trying to have that Validator slashed by ignoring her block. Slashing would take place only when a Validator was malicious beyond any doubt, for instance, if she signed two conflicting blocks.

3 Likes

Regarding the hardware requirements for validator:

It’s important to understand that Orbs is a very high scale network… this means that unlike a Bitcoin/Ethereum node that run on one machine, an Orbs node is actually a cluster of many machines. This means that a validator would normally create a cluster of multiple machines in some datacenter to run their node (one node = multiple machines).

The easiest approach is of course for the validator to use one of the standard cloud providers for this task and run their node over AWS, Azure, Google Cloud, etc.

Using this approach, when new virtual chains are created by apps and more compute resources are required to run them, the system can automatically spawn more machines in the cloud to support the node and make it more powerful. Orbs nodes actually do this automatically when deployed with Nebula: https://github.com/orbs-network/nebula . The system uses Terraform to allocate the resources automatically on the cloud account of the validator.

2 Likes