Delay deposits

[MartinOndejka]

• [ ] incorporate delaying of deposits into the test

[L-as]

I think I understand what you're trying to do. This isn't about delaying, but about allowing reusing an old proof for the rollup even if action states go forward by attaching one more extension "proof", right? I thought it was about delaying processing of transfers given the name.

I'm not sure you really need this even then though.

Say I'm the sequencer, I've done a bunch of work, I create the rollup commitment transaction, and I begin working on the next portion.

Let's say this has happened a few times, but something happens, one of my previous commitments is no longer accepted! This could be due to a rollback, or perhaps we optimistically assumed it was accepted by any block producer when it wasn't.

The solution here isn't necessarily making the old proof submissible again, after all we have new commits now.

What we really want is to reuse the old wrapper proofs (and extension proofs too, but that's less problematic). The issue then is that we've already added an inner step, worked on it, and now we need a new inner step.

Solution is then to allow more than one inner step by #112 .

I'll try to get it done soonish.

[MartinOndejka]

I think I understand what you're trying to do. This isn't about delaying, but about allowing reusing an old proof for the rollup even if action states go forward by attaching one more extension "proof", right? I thought it was about delaying processing of transfers given the name.

It is, the problem you've described is a separate one. Currently the only way the sequencer can be forced to throw away the work, is if the L1 forks and deposits action state changes. What I'm trying to do here, is to allow sequencer update the deposits state in inner account, only if there is enough certainty based on the consensus rules that the state won't change. With the previous circuit, deposits state has to be in the last 5 slots to set the precondition. Updating inner account multiple times won't help with this.

[L-as]

Where do you check which slots the actions come from?

[MartinOndejka]

Where do you check which slots the actions come from?

Why would that be needed? We don't need to enforce the delay, it's just for the sequencer's convenience, so that it doesn't have to throw away the work. The only concern is that the sequencer might be ignoring deposits, which I don't think is a major issue because it doesn't save the sequencer any resources to do so.

[L-as]

Ah I see the issue. Makes sense.

[L-as]

Sequencer not moving forward deposits enough is essentially the same risk as with sequencer ignoring transactions in general.

[L-as]

I feel like there's a more general solution here.

[L-as]

The more general solution is, can we make wrappers have preconditions and postconditions, that is, input and output states, more complex than simple ledger hashes? Or can we somehow merge "mismatching" batches where no true conflict exists?

[L-as]

Action states aren't the last place where we will have this issue. The core issue is that we want to witness L1 state #138 , yet that L1 state might change due to rollbacks or other issues.

[MartinOndejka]

Action states aren't the last place where we will have this issue. The core issue is that we want to witness L1 state #138 , yet that L1 state might change due to rollbacks or other issues.

That's much more annoying to solve than actions

[MartinOndejka]

Action states aren't the last place where we will have this issue. The core issue is that we want to witness L1 state #138 , yet that L1 state might change due to rollbacks or other issues.

That's much more annoying to solve than actions

Or no, we can make the user commit the L1 state by submitting an action and then we don't have to set the precondition, the user sets the precondition when submitting an action. It plays nicely to this delay extension solution.

[L-as]

Depending on whether we want to support network preconditions or not, our approach changes heavily. Whether we go with the approach of this PR depends on that.