You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given some point (i.e. slot number + block header hash), it would be nice to have a way to query the direct ancestor of that point on-chain. This could be achieved through a simple GET HTTP query, provided that Kupo keeps track of on-chain points. At the moment, Kupo does only store checkpoints as, the last point of the batch that's just been processed. And, it discards past checkpoints that are too old based on protocol parameters.
Why is it a good idea?
Having such a feature would allow to combine Kupo with solutions such as Ogmios where having a point on-chain can be used to recover pretty much any data from the chain-sync protocol. Yet, the chain-sync protocol requires to know the previous point to the one we are interested about (because it seeks intersection from that point on, and keep streaming block starting with the following point). Thus, while we could technically enhance existing data to return not only points where events happen but also previous points, it is just awkward to explain and cumbersome to do overall. Instead, providing an easy way to lookup previous points feels more elegant.
Are you willing to work on it yourself?
Yes.
The text was updated successfully, but these errors were encountered:
Describe your idea, in simple words.
Given some point (i.e. slot number + block header hash), it would be nice to have a way to query the direct ancestor of that point on-chain. This could be achieved through a simple GET HTTP query, provided that Kupo keeps track of on-chain points. At the moment, Kupo does only store checkpoints as, the last point of the batch that's just been processed. And, it discards past checkpoints that are too old based on protocol parameters.
Why is it a good idea?
Having such a feature would allow to combine Kupo with solutions such as Ogmios where having a point on-chain can be used to recover pretty much any data from the chain-sync protocol. Yet, the chain-sync protocol requires to know the previous point to the one we are interested about (because it seeks intersection from that point on, and keep streaming block starting with the following point). Thus, while we could technically enhance existing data to return not only points where events happen but also previous points, it is just awkward to explain and cumbersome to do overall. Instead, providing an easy way to lookup previous points feels more elegant.
Are you willing to work on it yourself?
Yes.
The text was updated successfully, but these errors were encountered: