Submitted by minhtrng
https://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/system-contracts/bootloader/bootloader.yul#L1847
https://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/contracts/ethereum/contracts/zksync/libraries/TransactionValidator.sol#L145
The overhead can be calculated incorrectly for some transactions and the user will get charged 32 times more in those cases than what he ought to be charged.
The overhead is calculated as the maximum of:
2. is calculated like this:
Note: please see calculation in wardens original submission.
In other words, the overhead for 2. is proportional to the percentage of bootloader memory that the transaction will use.
The issue is that in the actual implementation the units used for EncodingLength and BootloaderMemory are different. EncodingLength is denominated in bytes, while BootloaderMemory is denominated in words (32 bytes).
Looking at the implementations:
_encodingLength/txEncodeLen are a result of abi.encode(transaction).length and are hence expressed in bytes. BOOTLOADER_TX_ENCODING_SPACE/BOOTLOADER_MEMORY_FOR_TXS() have the value 273132 in the current config. While the specific number may be subject to change, it is relevant that it is not expressed in bytes, but in words (32 bytes each).
The number 273132 is derived from the current occupation of the word indices  [250141...523261] (difference is slightly off with 273120). Note that this range is derived from my own tracing of the bootloaders memory slots with the current config, so there might be a minor error in either the configuration or my own attempt of enumerating the slots. The docs state that [252189..523261] should be the range (difference 271072). Either way the minor difference is negligible and does not affect the stated impact. Due to the different units used, the denominator in above formula is 32 times smaller than it should be, hence, calculating a 32 times larger overhead
Multiply BOOTLOADER_TX_ENCODING_SPACE and BOOTLOADER_MEMORY_FOR_TXS() by 32 when using them in the calculation. Alternatively, change those values to be in bytes from the get-go, which should be fine as they dont seem to be used anywhere else currently
miladpiri (zkSync) confirmed and commented:
