A comprehensive security audit of Polygon zkEVM began in December. Two security teams have been independently stress-testing all components, including the prover and smart contracts for Polygon zkEVM.

The result of the audit by one of those security teams, Hexens, is now available. (You can view the full report here.) In keeping with Polygon zkEVM’s built-in-public ethos, we wanted to outline the findings.

‍In total, Hexens found nine vulnerabilities, ranging in severity from critical to low—and seven additional recommendations related to informational gaps in Polygon zkEVM’s documentation.

‍As of this writing, all 16 issues have been fixed.

Those fixes related to the network were made available on the audit-upgraded testnet that went live earlier this month.

Polygon zkEVM: Setting the Standard

The security audit for Polygon zkEVM has been thorough, rigorous, and is not even finished. In addition to Hexens, another security team, Spearbit, conducted a parallel audit of Polygon zkEVM’s smart contracts. The Polygon Hermez team also conducted its own internal audit. Last week, Spearbit began yet another audit, focused on the ZK circuits and cryptography.

‍No technology, especially novel technology like Polygon zkEVM, can be entirely de-risked. However, Polygon Labs is establishing best practices for securing zkEVMs. When Mainnet Beta for Polygon zkEVM launches, all 35 components will have been audited three times, by 26 researchers, over the course of nearly four months. ‍

In the coming weeks, we will share the findings of the remaining audits as the reports are finalized.

Audit Scope

Hexens’ security review focused on the client stack. This includes the RPC node, sequencer, and aggregator, where proofs are generated. Hexens also reviewed PIL, the language for creating polynomial identities, and the smart contract for bridging assets to Ethereum.

Audit Findings

In total, four critical vulnerabilities were found in Hexens’ audit. One relied on an exploitation of the mechanism that makes Polygon zkEVM censorship resistant. Another used the extended features of ERC-777 tokens to launch a re-entrancy attack on the bridge smart contract. The other two critical vulnerabilities relied on manipulation of missing binary constraints: one in the Storage state machine and one in the ROM.

The remaining vulnerabilities were non-critical. Two in particular are worth highlighting because they illustrate the technical complexity of designing a rollup that increases Ethereum’s throughput without sacrificing EVM-equivalence.

In the EVM, the ecrecover function is used to recover the public key of a transaction sender from the transaction signature. This is an important function for verifying the authenticity of a transaction. A discrepancy with how ecrecover is implemented in zkASM, the assembly language used to implement the EVM in Polygon zkEVM, could have allowed a dishonest user to generate a proof for a transaction that is not compliant with the EVM.

Another non-critical vulnerability would have relied on a difference in the maximum size allowed for gas limits and chain IDs between Polygon zkEVM and EVM implementations, allowing a dishonest user to spam the sequencer and potentially interrupt the network’s availability.

For a comprehensive resource on Polygon zkEVM, check out the documentation wiki. And if you’re interested in (or perplexed by) Zero Knowledge, follow Polygon Labs’ dedicated ZK handle, @0xPolygonZK, and head over to our ZK forum.

Read more: https://polygon.technology/blog/polygon-zkevm-results-of-hexens-security-audit