Skip to content

Conversation

@murisi
Copy link
Contributor

@murisi murisi commented Oct 1, 2025

An attempt to try and generalize test transaction generation, the goal being to ultimately make ordinary and fuzz-based tests cover a larger transaction space. Amongst others, the following generalizations have been achieved:

  • Each action automatically has differing compliance unit counts.
  • Compliance units are now non-balancing by default.
  • The value commitment randomness is now actually random.

This generalization was achieved by making tests accept more randomness from the Solidity fuzz tester, and transforming that into well-formed transactions. Confirmed that the protocol adapter executes all these additional variations successfully. This PR is also being used to check the latest proposed changes to the protocol adapter.

@murisi murisi force-pushed the murisi/generalize-tx-generation branch from 2426270 to ee66d43 Compare October 2, 2025 06:28
@murisi murisi marked this pull request as ready for review October 2, 2025 06:29
@murisi murisi requested review from agureev and heueristik October 2, 2025 07:14
@murisi murisi force-pushed the murisi/generalize-tx-generation branch from ee66d43 to ad39471 Compare October 3, 2025 08:51
Comment on lines +24 to +25
uint256 public constant MAX_ACTIONS = 4;
uint256 public constant MAX_RESOURCES = 5;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really want to hardcode these parameters?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but only in the context of the approach taken by this PR. If there are no limits on action and resource counts, the generator will start sometimes generating transactions with 256 actions, each containing 256 resources (so 65536 resources total), and the fuzz tests, each of which has a 1000 iterations, take impractical amounts of time to complete. But maybe another approach could be taken like removing the limits only for (non-fuzzing) unit tests or something...

@heueristik heueristik closed this Nov 10, 2025
@heueristik heueristik reopened this Nov 10, 2025
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

Successfully merging this pull request may close these issues.

4 participants