-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Description
Why Trait Based?
Making anchor trait based adds a lot of advantages in tradeoff with more design challenges. It unlocks the ability to customize small parts of the framework without throwing it all out. We've shown this in star_frame and used it to great effect. It also reduces the amount of code in macros, making it far easier to audit as you don't have to generate code to check everything.
Macros don't have to be updated with new features, instead those features are all normal rust code. For example, adding a new constraint would be writing a struct and implementing traits rather than needing to edit macro code. All macros do is generate calls to traits, making this far more rust-y in function. Programs would also be able to make their own constraints like the token program has now.
This also enables library support since macros no longer rely on anything beyond their isolated inputs.
Key Points for this Design
Constraints that can only be executed once (init/seeds) need to be converted to wrapper types. This can be done by the macro automagically, but would probably want to mark that syntax as deprecated. This also removes the bump struct as they are moved into the actual accounts struct instead.
has_one is a nightmare but possible (so many assumptions about how data is laid out). The new version should be far more useful as well by allowing different field names.
Accounts structs can be cascaded and require arguments from upper types. Instruction data is no longer passed in and re-deserialized, it's passed in as an argument.
This will support the current syntax but not all new features will be supported in the current syntax. There will be an easy conversion from the current sytax to the new syntax, will have an example of what I'm thinking for new syntax soon. Updating to the new version of anchor therefore should be quite easy, new syntax will not be required unless you want to use new features within that specific instruction.
Things we can use from star_frame
Arbitrary funder support (funders that need to cpi or other non-system funders)
Unsized type system (zero copy accounts with the full rust type system including enums and multiple lists/lists of lists)
TODO
Add a builder pattern for constraints to help with macros
Actual macro implementations w/ new and current syntax.
CPI support
Program macro
IDL traits (this is relatively easy, check star_frame for a example).
Data-holding accounts (will do this :soontm:)
Metadata
Metadata
Assignees
Labels
Type
Projects
Status