I know currently this serves /eth/v2/debug/beacon/states/..., but I was wondering if it'd be possible to serve
/eth/v1/config/spec, either from a static yaml file or from a connected server...
I guess what I'm interested in ultimately, is a scenario where we could initialise just using checkpointz, reading the network configuration from the spec endpoint, and the state from the states endpoint. Imagining something like holesky where we update checkpointz to serve the updated configuration without doing a release of all nodes...
So maybe if a client was initialised with
./cl_client --checkpointz-server https://my-checkpointz-server.io
and the client can download network config, genesis if it needs it, finalized if it needs it.... whatever the client needs, just with that initial information of the base url of the checkpointz server...
Another scenario may be a custom network, where they want to spin up servers and just configure separately. I'd assume that clients would download the spec once, and store it, downloading the spec each startup may drive undesirable load on the checkpointz instances, but maybe it's more desirable (although you could brick your nodes).
Anyway, it's probably worth a discussion, and this seems like a good place to have it :)
I know currently this serves
/eth/v2/debug/beacon/states/..., but I was wondering if it'd be possible to serve/eth/v1/config/spec, either from a static yaml file or from a connected server...I guess what I'm interested in ultimately, is a scenario where we could initialise just using checkpointz, reading the network configuration from the spec endpoint, and the state from the states endpoint. Imagining something like holesky where we update checkpointz to serve the updated configuration without doing a release of all nodes...
So maybe if a client was initialised with
./cl_client --checkpointz-server https://my-checkpointz-server.ioand the client can download network config, genesis if it needs it, finalized if it needs it.... whatever the client needs, just with that initial information of the base url of the checkpointz server...
Another scenario may be a custom network, where they want to spin up servers and just configure separately. I'd assume that clients would download the spec once, and store it, downloading the spec each startup may drive undesirable load on the checkpointz instances, but maybe it's more desirable (although you could brick your nodes).
Anyway, it's probably worth a discussion, and this seems like a good place to have it :)