Use an ethereum block as a timeout instead of a rollup batch
Rationale
User could add a timeout in his transaction by signing the maxNumBatch field. This gives the user the confidence that the transaction cannot be forged if currentNumBatch > maxNumBatch.
This approach implies relying on the batch number in order to setup a timeout. Batch number could be manipulated by the coordinators since they are the ones that could forge batches and thus increase the batch number.
If there is just one only coordinator in the protocol, batch number manipulation is straightforward since no competitors will forge any batches.
If we assume a bunch of coordinators in the protocol, the maxNumBatch field fixes a deadline of _slotDeadline defined in the smart contract, which dteemrines the number of blocks after the beginning of a slot after which any coordinator can forge. Current protocol parameters determines that _slotDeadline = 20 blocks = 5 min. Therefore, timeout guarantees for a user would be set at 5 minutes.
That timeout may not be enough to prevent high price changes when submitting atomic swaps. Then, moving to maxNumBlock would give to user more confidence in terms of timeout.
Drawback
If we took maxBlockNum as a timeout parameter, coordinaotr could not know exactly in which etehreum block the forgeBatch transaction will be inserted. This could lead to wrong proof generation due to high peak demand on ethereum.
A coordinator should perform the following tasks before insert a user transaction in ethereum:
generate proof
submit forgeBatch transaction and get mined
Assuming a very well estimation of when the forgeBatch would be mined, at least the coordinator should wait for the proof to be build and one block for his transaction to be mined. Given that current proof generation cost around 1 minute to compute, this would give a user a timeout assurance of 75 seconds.
From user perspective, user would be more confident regarding timeout precision but from coordinator perspective it could led to break the proof computation pipeline and adds complexity at the time to estimate forgeBatch transaction mining. A regular coordinator will not incur in non-profitable proof generation, so coordinator could only accept wide maxBlockNum timeouts just to not break its pipeline. That leads to not have any gain in terms of timeout accuracy if we change from maxNumBatch to maxBlockNum
Summary
Use an ethereum block as a timeout instead of a rollup batch
Rationale
User could add a timeout in his transaction by signing the
maxNumBatch
field. This gives the user the confidence that the transaction cannot be forged ifcurrentNumBatch > maxNumBatch
. This approach implies relying on the batch number in order to setup a timeout. Batch number could be manipulated by the coordinators since they are the ones that could forge batches and thus increase the batch number. If there is just one only coordinator in the protocol, batch number manipulation is straightforward since no competitors will forge any batches. If we assume a bunch of coordinators in the protocol, themaxNumBatch
field fixes a deadline of_slotDeadline
defined in the smart contract, which dteemrines the number of blocks after the beginning of a slot after which any coordinator can forge. Current protocol parameters determines that_slotDeadline = 20 blocks = 5 min
. Therefore, timeout guarantees for a user would be set at 5 minutes. That timeout may not be enough to prevent high price changes when submitting atomic swaps. Then, moving tomaxNumBlock
would give to user more confidence in terms of timeout.Drawback
If we took
maxBlockNum
as a timeout parameter, coordinaotr could not know exactly in which etehreum block theforgeBatch
transaction will be inserted. This could lead to wrong proof generation due to high peak demand on ethereum. A coordinator should perform the following tasks before insert a user transaction in ethereum:forgeBatch
transaction and get minedAssuming a very well estimation of when the
forgeBatch
would be mined, at least the coordinator should wait for the proof to be build and one block for his transaction to be mined. Given that current proof generation cost around 1 minute to compute, this would give a user a timeout assurance of 75 seconds. From user perspective, user would be more confident regarding timeout precision but from coordinator perspective it could led to break the proof computation pipeline and adds complexity at the time to estimateforgeBatch
transaction mining. A regular coordinator will not incur in non-profitable proof generation, so coordinator could only accept widemaxBlockNum
timeouts just to not break its pipeline. That leads to not have any gain in terms of timeout accuracy if we change frommaxNumBatch
tomaxBlockNum