Charging Invariant Violation Errors
AIP-35 - Charging Invariant Violation Errors
Section titled “AIP-35 - Charging Invariant Violation Errors”Summary
Section titled “Summary”Charge transactions that trigger invariant violation errors instead of discarding them.
Motivation
Section titled “Motivation”An invariant violation error is a special type of error that gets triggered in the Aptos VM when some unexpected invariants are being violated. Right now, transactions that trigger such errors will be marked as discarded, which could potentially be a DDoS vector for our network as it allows users to submit computations without being charged.
An example of transactions that could trigger an invariant violation error are transactions that violate MoveVM’s paranoid type checker.
Impact
Section titled “Impact”User shouldn’t be expecting any impact as this is just a precautionary change. We expect that transactions that are compiled from Move compiler to not be affected by this change.
Rationale
Section titled “Rationale”The concern that this AIP is trying to address is that if user finds a way to create an invariant violation error deterministically (which usually indicates a bug in our own implementation), users can send a number of transactions that trigger this behavior without being charged. This would easily consume our computation resources and potentially cause the network to halt.
Specification
Section titled “Specification”The change itself should be straightforward. We just need to change the status of invariant violation transactions from discard to keep and make sure we invoke the proper epilogue. The only thing we need to make sure is that we don’t mess up with the error translation logic in other error categories, which may cause backward compatibility issues.
Reference Implementation
Section titled “Reference Implementation”https://github.com/aptos-labs/aptos-core/pull/8213/files
Risks and Drawbacks
Section titled “Risks and Drawbacks”The potential risk is on the overall maintainablity of the node software. Now that we start to persist TXNs that cause invariant violation errors, we will need to reproduce the “error” behavior when there is such error. This is mitigatable though as we can mark such transactions to be no longer reproduceable in our testing pipeline.
Future Potential
Section titled “Future Potential”N/A
Timeline
Section titled “Timeline”Suggested implementation timeline
Section titled “Suggested implementation timeline”We plan to fix it with https://github.com/aptos-labs/aptos-core/pull/8213/files.
Suggested developer platform support timeline
Section titled “Suggested developer platform support timeline”N/A
Suggested deployment timeline
Section titled “Suggested deployment timeline”We are looking to activate this change in the 1.5 release on testnet/mainnet.
Security Considerations
Section titled “Security Considerations”The change will be gated under a feature flag so it won’t be activated until a governance proposal has been set.
Testing (optional)
Section titled “Testing (optional)”See the PR’s testing section. A failpoint injection was used to make sure the change is protected by a feature flag.