This PR adds additional safety checks to Execution verification. Previously we weren't explicitly checking the number of transition inputs/outputs; we were passing through the inputs and outputs to the Varuna proof verification as the guarantee. The problem is that the Varuna verifier pads the inputs with Field::zero. This means that malicious parties can craft a mutated transactions by taking an honest execution transaction, adding an extra Output::ExternalRecord(Field::zero)) output that uses the same proof (and different fee), and crafting a new transaction with a new ID that performs the same state transition.
We fix this by adding an explicit check against the number if inputs and the number of outputs in each transition.
TLDR:
This "attack" can NOT perform malicious state changes. It will be able to cause the honest transaction to be rejected, but still perform the same state changes. The risk is that this may cause a victim to be enticed/confused into re-executing their transaction.
Motivation
This PR adds additional safety checks to Execution verification. Previously we weren't explicitly checking the number of transition inputs/outputs; we were passing through the inputs and outputs to the Varuna proof verification as the guarantee. The problem is that the Varuna verifier pads the inputs with
Field::zero. This means that malicious parties can craft a mutated transactions by taking an honest execution transaction, adding an extraOutput::ExternalRecord(Field::zero))output that uses the same proof (and different fee), and crafting a new transaction with a new ID that performs the same state transition.We fix this by adding an explicit check against the number if inputs and the number of outputs in each transition.
TLDR: This "attack" can NOT perform malicious state changes. It will be able to cause the honest transaction to be rejected, but still perform the same state changes. The risk is that this may cause a victim to be enticed/confused into re-executing their transaction.
The CI run is here.
Test Plan
A test has been added to ensure that the mutated transaction fails to verify due to the newly added check against the number of outputs.
Related Issues
Partially related to possible transaction mutations discussed here - https://github.com/AleoNet/snarkVM/issues/2451.