Add finalized flag to chain data requests
#254
Conversation
Whether or not a request pertains to the finalized section of the chain (per the view of the client fork choice) is somewhat cumbersome to discover. This PR adds a boolean that allows clients to distinguish a response that has been finalized and thus is unlikely to change from one that may still change over time (specially when using slot-based requests). A flag like this can also be used for the purpose of verifying that a checkpoint root indeed is part of chain history and is likely to remain as such, as discussed in ethereum#226
|
Makes sense to me. For most if not all of these APIs Teku already knows if it's finalized as part of gathering the data anyway so just a matter of plumbing to expose it. |
|
Is there demand for this feature outside of the Checkpoint Sync API? Shouldn't be too hard to support, but would appreciate more rationale |
well .. finalized data is .. final - means services that follow the chain can do the same optimizations as us when it comes to single vs multiple histories making it easier for them to correctly handle reorgs etc. ie many of the popular tools have had this wrong and it's extremely annoying when they don't display the correct information - this gives them a reliable source. |
There was a problem hiding this comment.
I'm on-board with the idea, and I guess we don't need new version numbers for the endpoints because we're just adding fields, like we did with execution_optimistic.
I think this would be easy to implement in Lighthouse but won't really know for sure until we dig into it. Would be happy to merge this PR in the meantime.
Whether or not a request pertains to the finalized section of the chain (per the view of the client fork choice) is somewhat cumbersome to discover.
This PR adds a boolean that allows clients to distinguish a response that has been finalized and thus is unlikely to change from one that may still change over time (specially when using slot-based requests).
A flag like this can also be used for the purpose of verifying that a checkpoint root indeed is part of chain history and is likely to remain as such, as discussed in
#226