5 ms·

I guess couple of questions out of curiosity: - machine dies at 4am, what happens? do you manually restart process when you wake up? does this down time cause

by e9 4y ago

I guess couple of questions out of curiosity: - machine dies at 4am, what happens? do you manually restart process when you wake up? does this down time cause slashing? - what mechanism prevents you from running 2 identical validators by accident?

3np 4y ago
An explicit goal is that running a validator at home for the enthusiast should be feasible. A couple of days total downtime per year for an individual validator should approximately only miss out on the rewards it would have generated by being available for the same period. Penalties increase non-linearly with downtime and number of validators unavailable at the same time (meaning assuming all else equal, being down for 100h at once is worse than being down 1h/d for 100 days, and a whale with 10 validators going down for 10h at the same time will lose more than an individual validator going down 10h at 10 different occasions. This is not contingent on those validators being attributable to the same entity) If you have monitoring that alerts you for updates and when your node is unresponsive and can respond to downtime requiting intervention within a day or two you should still end up ETH-positive.
- e9 4y ago
  Thank you so much for this information
pa7x1 4y ago
The rough breakeven time is 42% of the time. If your validator is online more than that you are making money, less than that you lose it. So the protocol is rather forgiving in uptime. That's why it's much better to not run failover of any kind. You can afford to be offline without problems but if your failover fails and you run two instances you get slashed. There is also a penalty that kicks in if many validators fail at the same time resulting in over 1/3 of the network not being available. In that case penalties are also increased significantly. So if over 1/3 of the network were to be run in AWS those validators would risk heavy penalties if the region were to suffer some downtime.

by e9 4y ago

3np 4y ago

An explicit goal is that running a validator at home for the enthusiast should be feasible. A couple of days total downtime per year for an individual validator should approximately only miss out on the rewards it would have generated by being available for the same period. Penalties increase non-linearly with downtime and number of validators unavailable at the same time (meaning assuming all else equal, being down for 100h at once is worse than being down 1h/d for 100 days, and a whale with 10 validators going down for 10h at the same time will lose more than an individual validator going down 10h at 10 different occasions. This is not contingent on those validators being attributable to the same entity) If you have monitoring that alerts you for updates and when your node is unresponsive and can respond to downtime requiting intervention within a day or two you should still end up ETH-positive.

e9 4y ago
Thank you so much for this information

pa7x1 4y ago

The rough breakeven time is 42% of the time. If your validator is online more than that you are making money, less than that you lose it. So the protocol is rather forgiving in uptime. That's why it's much better to not run failover of any kind. You can afford to be offline without problems but if your failover fails and you run two instances you get slashed. There is also a penalty that kicks in if many validators fail at the same time resulting in over 1/3 of the network not being available. In that case penalties are also increased significantly. So if over 1/3 of the network were to be run in AWS those validators would risk heavy penalties if the region were to suffer some downtime.