Remediating a potential sequencer-prover inconsistency in the Cairo VM

🤷‍♀️ All-Purpose Hangout
1

This post presents the disclosure process of a subtle issue in the Cairo VM which was discovered during the Starknet OS audit.

The transaction execution in SN is done in 2 phases: Sequencing and proving. During a Starknet OS audit done by @fcremo from @Zellic_io a concern was raised that one of the Cairo opcodes may be unsafe. We conducted a thorough investigation and ruled out the safety concern that was initially raised. However, we did find a potential inconsistency between the checks done in the sequencing part (RustVM) and the prover (the Cairo AIR) with regards to this opcode.

Since the missing check was in the sequencer and not the prover this has no implication whatsoever on the correctness or security of Starknet. In theory, it could have created a situation that a transaction that appears to have passed will later be reverted (reorg). However, the bug only applies to deprecated CairoZero contracts, which in any case can no longer be declared in Starknet (unrelated to this issue).

Although our analysis showed that this inconsistency could not have been exploited in Staknet, we took immediate action and fixed the bug as an immediate patch to Staknet’s current version 0.13.3 without waiting for the next version upgrade. The fix was done by adding the necessary checks to the Cairo RustVM. This thorough and immediate analysis and fix are inline with our ongoing commitment to Starknet’s security and liveness.

We would like to thank @fcremo from @Zellic_io for his ongoing partnership and commitment to Starknet security.

2

This disclosure highlights the importance of rigorous security audits and the layered approach Starknet takes to ensure both safety and liveness. The proactive response in identifying and patching the inconsistency despite it having no direct security implications is commendable and reinforces trust in the network’s robustness.

The distinction between the sequencer (RustVM) and the prover (Cairo AIR) is crucial, and it’s interesting to see how subtle mismatches between these layers can create unexpected edge cases, even if they don’t translate into practical exploits. Addressing this at the RustVM level was the right call, as it ensures consistency across execution and proof generation while maintaining a seamless developer experience.

My key lesson from this incident is that security doesn’t just mean preventing attacks it also involves preventing unintended behavior that could affect network reliability. Kudos to the Starknet and Zellic teams for their diligence in auditing, investigating, and swiftly resolving the issue. I’m looking forward to continued improvements and security-first innovations in Starknet OS.