Single point of failure for ANY eth staker

[paulmillr]

You can launch the staking launchpad locally, but it does a few requests to external sites.

For example, there is an api call that sends all beacon chain validator pubkeys

https://github.com/ethereum/staking-launchpad/blob/d25870fabccdc9b896fa6d061bdfbc2f87990ec1/src/pages/UploadValidator/validateDepositKey.ts#L110

1. If the beaconchain scanner goes down, you are not able to deposit the eth!
2. If the beaconchain scanner goes hacked, they can output invalid data or maliciously track stakers
3. There are issues like #425 which make it impossible to make deposits

Assuming folks who want to stake run their own nodes, why isn't there a way to query local beacon node for the same node?

If there isn't a way to query local node right now, there should be an alternative way of making the query. If there was an offline way, that's ideal.

[samajammin]

@CarlBeek this seems worth investigation. Do you have capacity or would you appreciate help on this?

[CarlBeek]

Thanks for raising this @paulmillr!

1. I think it is important to point out that the failure mode here is not that a user is unable to make a deposit, but rather that the users sees a warning that the automated system for detecting double-deposits is unable to verify that this validator does not exist.
2. I agree. That said, it is not clear cut which is the lesser evil: risking users making double deposits or the risk that beaconcha.in gets pwned.
3. As mentioned in a reply to your issue in #425, a failure here does not stop a user from making deposits.

I like the idea of using a local node for checking for double-deposits, but the API provided by your local node is not the same as that provided by beaconcha.in. Specifically in relation to what is returned when there are new validators being added. Currently the delay between making a deposit and it being available via your local BN's API is 16 hours and it gets worse from time to time. So given the effort of connecting to a local BN and the marginal improvements against double-deposit footguns, I am not convinced that it is worth adding this functionality.

[paulmillr]

a failure here does not stop a user from making deposits

The application silently fails without any errors. What would a user think? Is there any possibility they would find a way to make an errorneus second deposit? Have you actually reproduced the error? It completely ruins the deposit process.

the API provided by your local node is not the same as that provided by beaconcha.in

Can be easily fixed in <100LOC python / node.js / whatever webserver. What's the point in aiming to have client diversity with 5+ consensus clients, and having the most important part of staking rely on one centralized website?