Key Takeaways
The technical review concerns BlockSTM V2, the parallel execution system in Polygon PoS’s Bor client. The bugs did not change transaction results or threaten consensus. Their risk was availability: a node could calculate the correct result yet spend too long processing a block to keep up with the network.
Why serial execution finishing first did not end the delay
Bor processes incoming blocks through both serial and parallel execution, using whichever route finishes first. Serial execution follows transaction order. Parallel execution tries to process transactions concurrently, then checks whether their assumed dependencies were correct.
This can speed up ordinary workloads when transactions do not depend on one another. But it also creates speculative work that needs to stop promptly once it is no longer useful.
Polygon’s repeated-code-hashing test exposed the gap. Serial execution completed the transaction in tens of milliseconds, but the parallel route continued working for about 11 seconds. At the time, cancellation was checked only between transactions, meaning an expensive transaction already running in parallel still had to finish even after serial execution had produced the result.
That is why the test mattered: the transaction was valid, and Bor could determine its final state quickly, but the node still had to wait for unnecessary processing to end.
Two flaws created work gas did not fully price
The two vulnerabilities came from different sources of excess work. One let speculative execution retain too much calculated data. The other repeatedly recalculated a contract’s code hash when it could have reused an earlier result.
| Unbounded shared cache | Speculative execution could retain excessive calculated data. | Caps the cache size. |
| Repeated code hashing | Repeated reads recalculated a contract’s code hash. | Reuses the result while it remains valid. |
Gas limits charge users for specified transaction operations, but they do not always capture every cost introduced by a client’s implementation. In these cases, cache growth and redundant hashing could create node-side work that was disproportionate to the transaction’s apparent cost.
The v2.10.3 fixes constrain that overhead without changing execution outcomes. Polygon classified both bugs as medium severity and said neither was consensus-affecting.
What the Bor v2.10.3 patch changes
The update limits the shared cache used during speculative execution and enables Bor to reuse a code-hash result instead of recalculating it during repeated reads. The aim is to prevent a valid but awkward workload from consuming excessive resources or extending block-processing time unnecessarily.
According to the Bor v2.10.3 release notes, the public release requires no hardfork, database migration or node resynchronisation. Operators can upgrade their nodes individually.
Polygon patched privately before publishing the details
Polygon said it distributed a private build for the Amoy testnet on October 5, followed by a private mainnet build on October 8. It published the technical disclosure on October 15 after upgrades had reached most of the network.
The release notes state that most validators and major RPC providers already ran the private version. That does not mean every connected node had upgraded, which is why Polygon’s operator announcement urges users of Bor v2.10.2 or earlier to update promptly. Operators on the private builds can move to the public release during their next maintenance window.
The remaining issue is patch coverage
For wallets, applications and other services, nodes that fall behind can return delayed chain information or take longer to submit transactions. Polygon’s disclosure does not establish that users experienced such disruption, and the company says it knows of no exploitation on mainnet or Amoy.
Polygon’s broader work on faster processing and payment infrastructure makes that operational reliability relevant. The patch removes the two identified sources of excess work; the practical next step is for remaining Bor operators to apply it.
This article is provided for informational purposes only. Vulnerability descriptions and exploitation assessments reflect Polygon’s published disclosure.
The post Polygon Patches Bugs That Let Valid Transactions Slow Nodes appeared first on Coindoo.


Bengali (Bangladesh) ·
English (United States) ·