Open jimmygchen opened 2 years ago
We are planning to expose a new endpoint with the network and application information which teku can use.
We are planning to expose a new endpoint with the network and application information which teku can use.
do you mind sharing where we can learn more about this?
@james-prysm I believe this ticket is the extent of the plan so far :) It's in our backlog, so will be able to provide more details when we get to it.
Unrelatedly to this issue, but in case you're interested, there is a healthcheck endpoint being added already: https://github.com/ConsenSys/web3signer/pull/610 The intention being so things like Kubernetes can react (reroute traffic etc) to situations where the DB is down for example.
Related to this we've just released https://github.com/ConsenSys/web3signer/releases/tag/22.10.0 which includes a change to log the network details on web3signer startup: https://github.com/ConsenSys/web3signer/issues/640
Not quite what this issue was requesting, but it should help nonetheless. cc @james-prysm
Hi,
Is there a way for validator client / web3signer to pick up a network config mismatch early? (e.g. web3signer is configured with a network different to the validator client)
I noticed that web3signer is able to sign attestations even with incorrect network configured (different network to VC, Teku in my case), but will fail to sign a block proposal.
It would be useful if Web3Signer exposes some info about the network / configuration, so that a network mismatch can be picked up early by the VC.
@ajsutton from Teku team suggested this:
Even if it doesn't cover fork schedule (i assume this would require the teku lib to be in sync with Teku), I think having a network check would be super helpful.