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

Explore instruction constraints #78

Open
lorisleiva opened this issue Jun 19, 2024 · 0 comments
Open

Explore instruction constraints #78

lorisleiva opened this issue Jun 19, 2024 · 0 comments
Labels
proposal Suggesting a change / new feature

Comments

@lorisleiva
Copy link
Member

lorisleiva commented Jun 19, 2024

This is a proposal that needs further discussion before implementing.


It would be useful for the accounts and arguments of an InstructionNode to optionally contain a InstructionConstraintNode. These constraints would define rules for these accounts or arguments such that, if that constraint fails, the provided account or argument will fail to pass the instruction's checks.

Ideas for such constraints could be:

  • PdaConstraintNode: The account or argument (of type PublicKey) must follow the describe derivation.
  • PublicKeyConstraintNode: The account or argument (of type PublicKey) must be equal to the provided address.
  • PublicKeyListConstraintNode: The account or argument (of type PublicKey) must be included in the provided array of addresses.
  • ValueConstraintNode: The argument must be equal to the provided value.
  • HasOneConstraintNode: The account or argument must be present in the provided account and match the value of its attribute.
  • AndConstraintNode: All nested constraints must be valid.
  • OrConstraintNode: At least one nested constraint must be valid.
  • NotConstraintNode: The nested constraint must fail.

Side node: Currently, every account or argument in an InstructionNode has the potential to include a defaultValue which can either be a simple ValueNode or more contextual nodes such as ArgumentValueNode (to default to another argument), AccountValueNode (to default to another account), PdaValueNode (to default to a PDA derivation with seeds coming from other accounts or arguments), ConditionalValueNode (to provide simple if/else values), etc.

That defaultValue is mostly useful for renderers and documentation visitors as they allow the generated helper functions to require as little information as possible.

The constraint nodes cannot replace this defaultValue since constraints alone are not enough to decide which value an account or argument should default to. However, there could be some redundancy here to tackle such as the PdaConstraintNode and the PdaValueNode.

@lorisleiva lorisleiva added the proposal Suggesting a change / new feature label Jun 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Suggesting a change / new feature
Projects
None yet
Development

No branches or pull requests

1 participant