Content
@
0 reply
0 recast
0 reaction
Samuel Chong
@stakesaurus
Realised that missed attestation alerts via beaconchain are less useful when running DVTs so I created a simple client-level downtime alerts Telegram chatbot for myself. Any solo stakers keen on a fun weekend project to share some feedback? - https://github.com/samuelclk/ETH-node-alerts-TG-bot
2 replies
3 recasts
4 reactions
Samuel Chong
@stakesaurus
Missed attestation alerts via the http://beaconcha.in watchlist occur on the onchain validator key level. However, using DVTs means that your node =/= validator. i.e. A cluster of X nodes is responsible for hosting Y validator keys.
1 reply
0 recast
0 reaction
Samuel Chong
@stakesaurus
This means that we either need to manually check on our nodes periodically (tedious) or act when the cluster fails to achieve consensus, leading to missed attestations (and free-rider problems).
1 reply
0 recast
0 reaction
Samuel Chong
@stakesaurus
As a solo staker using DVTs, I needed a way of being notified when my DVT-enabled node goes offline on the device/server level instead of on the onchain level. The http://beaconcha.in app does have a “machine offline” notifier but only for 1 machine on the free plan.
1 reply
0 recast
0 reaction
Samuel Chong
@stakesaurus
I wanted something that puts all DVT operators of a cluster in the same group chat and alerts everyone when any one of the nodes in the cluster goes down — keeping everyone accountable!
1 reply
0 recast
0 reaction
Samuel Chong
@stakesaurus
This lightweight Python script can be run externally on a small + low-powered device and scheduled as a CronJob to monitor as many nodes as you want. Running it externally (vs from your node) means that the risks/trust assumptions from running unknown scripts are much lower
1 reply
0 recast
0 reaction
Samuel Chong
@stakesaurus
The condition, however, is that the nodes you want to monitor this way need to be in the same VPN (e.g. Tailscale), which means it’s possible for a malicious cluster participant to DOS the other nodes by overwhelming them with pings. Although there are no benefits to doing so.
1 reply
0 recast
0 reaction
Samuel Chong
@stakesaurus
So how does this tool work? In 4 simple steps, 1) The script starts by making HTTP GET requests to the specified IP address and port. e.g. http://<external_IP>:9000. These requests are essentially asking the server, "Are you there?”
1 reply
0 recast
0 reaction
Samuel Chong
@stakesaurus
2) Next, for the script to consider the consensus or execution client to be "up," the service at the IP address and port must respond to the HTTP request. i.e. the client's API or health check endpoint responding with an HTTP status code of 200 OK
1 reply
0 recast
0 reaction
