Submitted by xuwinnie
Attacker can manipulate the sorted queue in log sorter, as constraints are not strong enough and reverted l1 logs and events can still be emitted.
Lets see what we have enforced in this circuit. For a unique timestamp, either there is only a write log, we should add it to the queue; or there is a write log and a rollback log, which means revert took place, we should ignore it.
At first, we enforce the timestamps in the sorted queue are in ascending orders, which means write log and rollback log of the same timestamp should be adjacent.
Here, for two consecutive element A, B in the queue, if A is not rollback and B is rollback, we enforce that A, B shares the same timestamp.
Here, for two consecutive element A, B in the queue, if they share the same timestamp, we enforce that they have the same written value. (This is already guaranteed by the earlier circuits).
This is almost the same as the second one.
Finally, for two consecutive element A, B in the queue, if A is write and A, B are different, we add A to the result queue.
We use w to denote write and r to denote rollback, two adjacent letters share the same timestamp. An ideal sorted queue would be like wr wr w w w wr. The system worked well in this case. However, what if someone submit wr rw wr rw as the sorted queue? All the four logs here are reverted, so no log should be added to the result queue. However, this sorted queue satisfy all the constraints, and it will add the second and the fourth log to the result queue.
To conclude, the constraints are not strong enough and attacker can manipulate the sorted queue to emit already reverted l1 logs and events.
Enforce that the first popped element is write and there are no two consecutive rollbacks in the sorted queue.
Context
miladpiri (zkSync) confirmed
Alex the Entreprenerd (judge) commented:
