Implement fuzzing plans to fuzz multiple contracts at a time

[BowTiedRadone]

To prevent exploits from interactions of multiple contracts, one idea came to mind to implement fuzzing plans. For example, if the clarinet project's contracts directory looks like this:

contracts
├─ contract1.clar
├─ contract2.clar
└─ contract3.clar

We could allow the user to setup a fuzzing plan by specifying the interconnected contracts. For example, if contract1 contains action1 entry points (e.g. deposit into protocol), contract2 contains action2 entry points (e.g. withdraw from protocol), and contract3 is a registry that has data structures for storage integrity of the protocol, the user could create a fuzzing plan named action1action2fuzzing pointing to [contract1, contract2].

The custom plan, according to the testing routine, will:

• call public functions and check invariants for both contracts during invariant testing
• run stateful tests for both contracts during property testing

Based on how the majority of Stacks protocols business logic looks like, this could be a nice improvement. Open to brainstorming, refinement, simplification.

P.S. To simplify the user onboarding process to Rendezvous, we could make use of <contract-name> = * command-line argument to check all the contracts in the Clarinet project at a time.

[moodmosaic]

How is that different from simply running all invariants across all contracts in the Clarinet.toml?

[BowTiedRadone]

This runs them at a time, so both action1 and action2 type of events happen at a time. For the deposits and withdrawals example, let's say withdrawals cannot happen without deposits.

[moodmosaic]

How does that plan looks like syntactically? Could it be similar to how madhouse-rs scenario works? (Can it be expressed in Clarity? Or at least, TypeScript?)

[BowTiedRadone]

The first phase of this feature would be a way to just specify a collection of names of interconnected contracts that will be fuzzed in parallel. A nice example would be, for sBTC, sbtc-withdrawal and sbtc-registry. sbtc-registry has an invariant checking that the last withdrawal ID (defined as a data var in sbtc-registry) is always less than or equal to the number of calls of registry withdraw. But the registry withdrawal function is gated and only sbtc-withdrawal is allowed to call it. This means Rendezvous cannot create state transitions in the withdrawal part of the registry, while picking a random contract from the withdrawal = [sbtc-withdrawal, sbtc-registry] fuzzing plan for each run and calling a public function from it can.

Then, when the user runs npx rv . withdrawal invariant, Rendezvous will not find a contract named withdrawal, but it will find an entry that points to a list of contracts that can be selected for each run.

[moodmosaic]

How and where is withdrawal = [sbtc-withdrawal, sbtc-registry] specified?

[BowTiedRadone]

Can be wherever. For example a file called Rendezvous.toml at the same level with Clarinet.toml. That file can be used further if we decide to support other user customizations.

[moodmosaic]

Could it be defined inside Clarinet.toml under a section called rendezvous?

[BowTiedRadone]

Yes. That makes sense and simplifies the onboarding!