api endpoints deprecation list for annoucements

[g11tech]

following apis should be cleanuped up just post deneb releases for mainnet are made and hence should be announced accordingly.

coordination with other clients via spec is not required but still desired since most of the clients and toolsets would have migrated and no known dependency is known.

• getBlock v1
• produceBlock v1 (v2 might also be scrapped with just v1)
• publishblock v1

cc @philknows

[nflaig]

(v2 might also be scrapped with just v1)

Since v2 was just deprecated in Capella I'd suggest it is removed in Deneb + 1 hard fork

[g11tech]

(v2 might also be scrapped with just v1)

Since v2 was just deprecated in Capella I'd suggest it is removed in Deneb + 1 hard fork

why? could you elaborate why softwares that have updagraded to capella will need it 2 hfs post capella.

[nflaig]

why? could you elaborate why softwares that have updagraded to capella will need it 2 hfs post capella.

Just to give tooling and clients enough time to update their implementation. There is no strong relation between API version upgrades and hard forks and if you'd deprecate produceblockv2 already in deneb, then the deprecation notice would be really short.

[g11tech]

for hardfork dependent tooling it won't be the case (they can always pin older versions) for e.g. produceblock and publish block v1 will not work post deneb. we go off specs when a spec compatible way when we make older versions also compatible, but that doesn't stop us from cleaning the supposedly dead code

also a hardfork is 1 year , too big a timeline to keep the dead code around.

Plus these problems belong to the majority clients, us being a minority gives us advantage to be lean/mean machine which we should be.

[g11tech]

so the real question is if there is a compelling reason you would like to keep any of the above listed endpoints and why? we can decide to retain something if we have a good enough reason.

A deprecation annoucement now and cleanup on the next release post deneb (2-3 months go live) should be good enough. Can't see why anyone needs more time for that

[nflaig]

so the real question is if there is a compelling reason you would like to keep any of the above listed endpoints and why?

I feel like looking at specific endpoint does not make sense, there just needs to be a defined procedure in the api spec that every client follows. This gives stability to client interop and makes the whole process more transparent and predictable for users. This topic needs coordination with other client teams to come up with a solid solution.

[wemeetagain]

is this issue stale?

[nflaig]

this was discussed on beacon-api spec with other client teams, the spec will dictate when we can remove apis, usually one hard fork after an api is deprecated it can be removed