carp funnel stake delegation cde epoch tracking

[ecioppettini]

About

Problem

With the current implementation there is no way to figure out if the delegation has any effect, since there has to be an epoch boundary before that happens.

Changes

This changes the getCardanoAddressDelegation to return either:

1. The last delegation event, if we crossed an epoch boundary already.
2. Both the delegation of the current epoch, plus the previous one.

The current epoch is now stored in the new cardano_last_epoch table.

Also cde_cardano_pool_delegation now stores the epoch. The epoch is part of the primary key, so only the last event for a certain epoch is in the db. But also only a maximum of 2 rows per address are stored. If the current epoch is greater than both of the epochs in those rows, the earliest one of those is actually ignored in the query, but it's not removed until another delegation tx is indexed for that address.

[SebastienGllmt]

Are you sure this if condition shouldn't be flipped?

I think probably we don't even need this if/else. We can use the same code and then just use Math.min(0, results.length - 1) for the index

[ecioppettini]

Flipped? Like negating the condition?

This is checking if one of the entries is for the current epoch, in which case all the entries are returned (there can be 2 max), so in this branch events is the entire list.

In the other branch instead there is only one result, because both have to be < currentEpoch.

We could simplify the logic by just always returning all of the entries though. I just thought it was leaking implementation details.

Also this Math.min(0, results.length - 1) would be always 0, since there is already an early return for the case when there are no delegations, so I'm not sure what you mean.

[SebastienGllmt]

Okay, I think I misunderstood the code originally

We should have a comment block that explains what is going on here

something like

/**
 * If the most recent delegation is the current epoch, we need to return the list of recent delegations so the app can know what delegation the user had beforehand since delegations only matters once they cross an epoch boundary
 * If the most recent delegation isn't from the current epoch, we know it's the one that is active now
*/

either that, or we explain this in the Paima Engine docs and then put a link to the docs as the comment (to avoid the same explanation being in both places)

[ecioppettini]

I did put an explanation of the result at PaimaStudios/paima-engine-docs#19

So I could link to that. Although I would be a bit concerned about the domain/url changing if I link to the public version, so I feel like it's better to just replicate it here, maybe a shorter version.

[SebastienGllmt]

do we want to update the cache like this for every iteration of this loop? (genuine question)

[ecioppettini]

Not really, but afaik the cache it's just another object in memory, so I'm not sure why that would be a problem. Otherwise I could change it to a local variable and then just update it at the end.

Or I can wrap the update in the epoch !== prevEpoch condition.

[SebastienGllmt]

yeah it's less about performance and more about understanding when the cache is meant to be updated. If we only care about updating it when epoch !== prevEpoch we should put it in the same condition so it's clear when this cache is mean to be updated at a glance