Samlaf avs 291 docker compose up does not advance the chain

[samlaf]

Fixes #39 .

[wesfloyd]

Would changing the default batch size help?

https://book.getfoundry.sh/reference/cli/forge/script?highlight=batch%20100#forge-script

[samlaf]

@wesfloyd this was a separate issue. I linked the issue in the description.
The point here was just to fix the broken docker compose test, since we were merging other PRs with that test failing which is not great practice.

In which context are you recommending using batch here? Not sure I'm following.

[samlaf]

Merging because this is needed to unblock other PRs, but we can continue the conversation here or elsewhere @wesfloyd !

[wesfloyd]

@wesfloyd this was a separate issue. I linked the issue in the description. The point here was just to fix the broken docker compose test, since we were merging other PRs with that test failing which is not great practice.

In which context are you recommending using batch here? Not sure I'm following.

All good, no worries, my misunderstanding.

I thought you were needing to advance the chain here b/c of the default batch size (100), which could be reconfigured to "1".

However, I'm learning "some state depends on the block-number at which the interaction happened".

For my understanding/learning purposes - could you share which part of inc squaring is dependent on this "state dependent on block number" limitation? It would help to understand whether this is specific to Inc Sq's design or broadly applicable to all AVS testing.

[samlaf]

@wesfloyd this applies to all AVSs.
The main idea is that when we verify signatures, we need to lookup the stake and pubkeys of operators at a certain block.
When an operator registers with an AVS the aggregate pubkey is incremented, and stored for that given block. Hence when we fetch the quorum stake, it looks up the last update block where an operator registered. So if we register all operators with the avs and then stop the chain, when we restart it the chain is at block 0 and so we can't fetch the state. That's one issue but there are others that I'm forgetting right now.

The above logic would be nice to have, instead of needing to register the operator dynamically everytime we restart the chain. There must be another reason why I still need to advance the chain.... but I can't remember right now. Maybe when registering the avs looks at the block number at which an operator registered with eigenlayer? Not sure..