From the zk-wg call regarding Option 5:
- Client Integration and Standardization Issues: Ensuring different rollups agree on a nonce management standard could be difficult and require significant effort from client integration teams. This complexity may hinder interoperability and user experience.
- The idea to overcome this was using multiple nonces, let’s say 16 per account. The rebuttal was that while introducing multiple nonces or “sequence lanes” might offer a solution, it could also introduce arbitrary limits on parallelism. Future applications or use cases might encounter these constraints, leading to unforeseen complications or user friction.
New Option 6: Combine option 3 with option 4.
The main way to withdraw is with option 4, but you also have the option of posting a zkp alongside the blob to do it in the same block.
This pattern naturally leads to posting a zkp alongside any transaction type where the verification of the zkp is necessary before the transaction is being accepted into the block.
You could see currently designed withdraws as a transfer function being gated by a ZKP. Now instead of calling it withdraws it could be stakig, bridging or blob posting. What other applications this could unlock I go into detail in this post. That post also covers how to deal with the woods attack, trying to solve one of OP’s open questions.