Summary

If the ERA chain decides to migrate the settlement layer from GW to L1 the same priority operations will be executed in the GW and L1 which is not the intended behavior

Vulnerability Details

The ERA chain is planned for migration to the Gateway (GW), but it presents a unique scenario due to the priority queue. To integrate the ERA chain into the ZK Chains ecosystem, the GatewayUpgrade will be applied. The following code snippet outlines this upgrade:

This upgrade performs several configurations, including initializing the priority tree. As of this report, the ERA diamond chain has the following data:

But let's suppose that before migration all priority operations have been executed and both tail and head are the same.
Thus, the setup of the priority tree will set the _startIndex to 3264282 in the diamond proxy on Layer 1 (L1). Upon migration to the GW, this _startIndex will be transferred from the priority tree as follows:

However, the data from the priority queue in the L1 diamond will not be transferred, and every time a priority operation is initiated on the GW, the following process will occur:

Since the startIndex is 3264282 and the firstUnprocessedPriorityTx is 0 (due to non-initialization on the GW), a large number of priority transactions will be added to both the priority queue and tree. Specifically, 3264282 operations will be required to populate the priority tree. When executing these priority operations, the following will take place:

As mentioned earlier, the startIndex will be 3264282, and the firstUnprocessedPriorityTx will be 0. Consequently, the batch execution will process the priority queue for the next 3264282 priority transactions. Since all these priority operations will not make the priority tree unprocessedIndex increment, if the ERA chain is migrated back to L1 this index will remain to 0 even though some priority operations have been executed. So the L1 will enforce that the priority operations that have been already executed on the GW to be executed again on L1 because they have been registered on the priority tree and the unprocessedIndex is 0. Notice that this happens because in the GW the s.priorityQueue.getFirstUnprocessedPriorityTx was 0 but 3264282 in L1.

Impact

High, priority operations will be enforced to be reexecuted leading to serious problems like double spendings

Tools Used

Manual review

Recommendations

When the ERA chain is settled on the GW it will push the priority operations in both data structures, so I would increment the unprocessedIndex from the priority tree regardless from which data structure is executing the operations. Because since operations will be duplicated in both data structures, once the priority tree will have finished to process all his operations, the unprocessedIndex will already point to the correct priority operation to process. This way since the unprocessedIndex will be up to date, when migrating back to L1 it will be correct and L1 will process priority operations properly.