Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for invariant testing #1317

Open
leighmcculloch opened this issue Aug 16, 2024 · 0 comments
Open

Add support for invariant testing #1317

leighmcculloch opened this issue Aug 16, 2024 · 0 comments

Comments

@leighmcculloch
Copy link
Member

leighmcculloch commented Aug 16, 2024

What problem does your feature solve?

Invariants are statements that can be made about a program that should always be true. All programs have invariants, and contracts being largely state machines, it is very achievable for contract developers to write statements for their programs that certain things are always true.

What would you like to see?

I'd like to see the SDK provide a standard way to write invariants for a contract, so that the invariants could be automatically used in a variety of ways to detect unexpected behavior:

  • Use in standard test runs, by running the invariants after every invocation (not just after every test) to ensure that the contract state didn't end up in a state that is invalid.
  • Use in fuzz tests.
  • Potentially in the future as something that can be exported and used in monitoring of on chain contracts.
  • Potentially in the future as something that can be exported and used for validating the affects of upcoming protocol changes.

What alternatives are there?

It could be argued that some invariants can be written as efficient assertions, and as such the infrastructure for invariants isn't necessary since assertions can be littered throughout the program code gaining the benefit that it is running on chain too. However, invariants can be more powerful than assertions because an invariant might operate on all state that a contract has, which an assertion in the standard program execution would never have access to.

Fuzz tests typically contain invariants, and people already write fuzz tests for Soroban contracts, so it could be argued we don't need new infrastructure/features for invariants, but I think the potential for wider use of invariants in most places makes this valuable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
@leighmcculloch and others