Superfluid: Reduce epoch time

[ValarDragon]

Joe abbey very helpfully got pprof results of the post-superfluid epoch https://twitter.com/JoeAbbey/status/1503072747349499905?s=20&t=fLB87nwcpX7kFigVoR9O1A (We've all been surprised at why it wasn't sub one minute)

Turns out the answer was that we're doing too many calls to GetSyntheticLock! We call this function right here: https://github.com/osmosis-labs/osmosis/blob/main/x/incentives/keeper/distribute.go#L235

Whats happening is in the distribution code for superfluid delegations to Atom/Osmo, we do one distribute for every superfluid delegated-to validator. Right now we do one distribute per validator / superfluid denom pair. Each distribute iterates over all L lockups of sufficient length in the Atom/Osmo pool, and checks if it has a superlfuid delegation to the respective validator. This causes L * # num validators calls here.

We actually index lockups by synthetic denom as well. We reverted a change that was using that previously, due to some uncertainty around correctness pre-feature shipping, I'm now pretty sure post refactors to the module we did, that its correct. This would reduce the number of data iterations to the ideal of # superfluid locks.

To fix this, we should get all locks with unbonding period duration, of the synthetic lockup duration length. A couple ways to do this, but they basically all involve changing the calls here: https://github.com/osmosis-labs/osmosis/blob/main/x/incentives/keeper/distribute.go#L370-L384 . The underlying locks are keyed as 'normal', so you can do k.lk.GetLocksLongerThanDurationDenom(ctx, distrTo.Denom, distrTo.Duration) with the synthetic denom.

[ValarDragon]

I've made a branch dev/v7-epoch-speedup, and am testing it on a full node on mainnet to see if its still compatible.

I believe this patch should fix the immediate amplification overhead here.

cc @joeabbey

[ValarDragon]

Forgot to update this yesterday, the first attempt in that branch was not state compatible. TBD why it wasn't!

[mattverse]

I'm surprised that this one-line fix is not state compatible. By what method did you find out that this wasn't state compatible?

[ValarDragon]

Me and @hleb-albau tried it on a node, and got a state hash error :/

[mattverse]

Tried changing binary from v7.x -> dev/v7-epoch-speedup on a testnet with default genesis, it seems to build blocks, should I try to do it off mainnet?

[hleb-albau]

it did work, but not survive epoch blocks

[mattverse]

I see i see, does that mean the fix needs more reduce in epoch time?

[ValarDragon]

Its not state compatible with the existing binary, meaning that if you had a v7.0.4 node, and this node, they will not get the same app hash

[ValarDragon]

Closed by #2214