[Sequencer] Replace vcounter values with real countes when we get a response from the executor

[V-Staykov]

This seems deprecated now that we don't wait for executor responses.

[hexoscott]

I'd agree yes, it won't save a batch if we've already moved on from it with the latest code changes

[eduadiez]

I disagree, the idea of this issue wasn't to improve the performance in terms of TPS but to maximize the use of Batches which currently I would say is below 60%, by implementing this we could even move to cheaper 2^24 provers. I would like you to reopen this issue

[hexoscott]

I see your point @eduadiez but we were asked to not wait for executors to seal a batch, so in a busy network the sequencer could be 2 or 3 batches ahead of the pending requests with executors, it's too late at this point to retrospectively add more to a batch. I think the way forwards is for virtual counters to more accurately represent what is happening in the executor.

[krlosMata]

Some questions to get more context on this topic:

• Once a batch X is closed

  • give confirmation/finality to users
  • in parallel that batch is sent to the legacy-executor to do the sanity check in terms of zk-counters
  • in parallel build batch X+1

  is this the flow ?

[hexoscott]

Not quite @krlosMata :

1. create a block
2. send block to executor
3. create more blocks and send them to the executor in order of creation
4. after each block is created check for executor responses and if OK add block to datastream.

So each block is sent to the executor in turn with a witness and DS bytes that covers the batch up to that point, so imagine batch 100 starts with block 1000, we send [1000] to the executor, then the next block we send [1000,1001] to the executor and so on until the batch is done, then we start on the next batch. So there is no "final" check at the end of a batch to make sure it's OK, we provide finality at the block level to keep the RPCs syncing as fast as possible from the sequencer. We effectively check the whole batch for each new block we add to it.

So because we don't wait at the end of a batch any more we can't retrospectively rebuild a batch because of a response from the executor. In faster / busier networks we could already be 2 batches ahead of the queue going to the executors. The aim is to not restrict the sequencer because of executors speed but to let it run as fast as possible and scale horizontally with more executors.

We have a lot of conflicting interests at the moment across different issues:

• maximise TPS
• maximise batch size to increase efficiency
• don't make users wait for large transactions and close batches faster for them

We can't have all 3, but hopefully can strike a balance.

[krlosMata]

Thanks for the detailed flow xD

I guess that virtual counters are tracked while you are sending blocks to the executor, like: Open a new batch (X available vc):

• block_A (X - A vc available): send [A] to executor --> response_A
• block_B (X - A - B vc available): send [A, B] to executor --> response_B
• and so on
• when vc are exhausted just open another batch

The idea here is take the real vc from response_A and adjust them while adding blocks to the batch. This will only work on batches that are not yet closed, so busy networks may not benefit from it, but low traffic networks or networks that do not require very high throughput could benefit from it. The flow will be like:

• block_A (X - A vc available): send [A] to executor --> response_A --> includes real_A
• block_B (X - A - B vc available): send [A, B] to executor --> response_B
• block_C (X - A - C vc available): send [A, B, C] to executor --> response_C ----> adjust cv with real_A
• block_D (real_A - C - D vc available): send [A, B, C, D] to executor --> response_D
• and so on
• when vc are exhausted just open another batch