The Promise of Exact Gas Refunds
In the complex world of blockchain transactions, particularly those involving multiple operations batched together, accurately calculating and refunding gas costs is a critical but often overlooked detail. The developer behind the Legwork project, Edy Cutjong, initially marketed his system with a bold claim: the gas refunds were exact. This meant that any gas not utilized by the batched operations would be returned precisely, without any surplus or deficit. This claim, however, came under scrutiny during a subsequent audit, revealing a significant flaw in the refund mechanism.
The core of the issue lay in how Legwork handled batched orders. Instead of processing each order individually and calculating its specific gas usage, the system attempted to batch multiple orders into a single transaction. While this approach can improve efficiency, it introduced a complex challenge in accurately attributing gas costs and issuing refunds. The README explicitly stated the gas refund was exact. The audit, conducted the day after the system went live, demonstrated that this was not the case. The system was over-refunded by a substantial amount: 21,000 times the gas cost for each order, multiplied by (K - 1), where K represented the number of orders batched in a single transaction. This meant that for every batch of K orders, the system was effectively returning 21,000 gas units more than it should have for each order within that batch. Fortunately, the vulnerability was contained. It was bounded by each order's reserve, meaning the over-refund could not exceed the initial gas allocated to an order. Furthermore, no malicious actors had exploited this loophole, indicating it was a systemic flaw rather than an active exploit.
Understanding the Gas Refund Mechanism
To grasp the error, one must understand the intended operation. Legwork aimed to provide a decentralized task execution network, allowing users to create and execute tasks on-chain. For tasks that didn't require immediate execution or could be batched, a gas refund mechanism was implemented to ensure users were not overcharged. The ideal scenario for gas refunds involves precise tracking: if a transaction uses less gas than pre-paid, the remainder is returned. In Legwork's case, the system was designed to batch multiple 'create' operations into a single transaction. Each 'create' operation would reserve a certain amount of gas. If the batched transaction completed using less than the total reserved gas, the excess should have been refunded. The error occurred because the refund calculation did not correctly account for the gas used by each individual operation within the batch. Instead of calculating the precise gas used by the entire batch and refunding the difference from the total reserved, it seems the system was refunding a fixed amount of gas per order, irrespective of whether that gas was actually saved. This led to a scenario where, for a batch of K orders, the system would refund 21,000 gas for each of the K orders, effectively returning 21,000 * K gas when it should have returned only the unused portion of the total reserved gas for the batch.
The Technical Mistake and Its Scale
The specific technical mistake stemmed from a misunderstanding or misimplementation of how to calculate refunds when multiple independent operations are bundled into a single transaction. In a typical batched transaction scenario, the total gas consumed is the sum of the gas used by each operation, plus any overhead for the batching mechanism itself. The refund should be the total pre-paid gas minus the total gas consumed. The error in Legwork's implementation meant that a constant value of 21,000 gas was being factored into the refund calculation for each order within the batch, regardless of the actual gas expenditure of that specific order or the batch as a whole. This constant factor was likely an arbitrary or incorrectly derived value, perhaps intended as a baseline or a fixed cost, but its application within the refund loop for each individual order created the multiplicative over-refund. The scale of the error, 21,000 × (K − 1) gas, highlights the multiplicative nature of the bug. If K=2 (two orders in a batch), the over-refund was 21,000 gas. If K=10, it was 189,000 gas. While contained by the order's reserve, this could still represent a significant portion of the allocated gas, potentially leading to unexpected behavior or even failed transactions if the over-refund calculation was flawed in a way that reduced the available gas for essential parts of the transaction.
The Fix and the Receipts
Upon discovering the discrepancy, Cutjong promptly addressed the issue. The fix involved re-evaluating the gas refund calculation logic to ensure it accurately reflected the gas consumed by the batched transaction. This likely meant implementing a more robust method for tracking gas usage at the batch level and calculating the refund based on the precise difference between pre-paid and consumed gas. The corrected code ensures that the refund is no longer a fixed amount per order but is dynamically calculated based on actual usage. The developer also made the decision to keep the