Closed armaniferrante closed 3 years ago
One challenge here is considering what to do with the "nonce" that comes with the program derived address.
Three different solutions:
<header> || <discriminator> || <borsh-data>
, where the header has a nonce and a boolean, determining if the account data is associated or not. This is nice because it hides this implementation detail. We'd probably need to add some accessors for the nonce on the ProgramAccount
or on a new type, however.nonce
field in the deserialized borsh account data. This solution is much easier from an implementation point of view.#[associated]
attribute that is the same as #[account]
but 1) adds a private nonce
field and 2) implements a BumpSeed
trait implementation.I'm inclined to start with 2. And then move to 1 or 3 at some point in the future.
Addressed by https://github.com/project-serum/anchor/pull/186. Still need to make some ts
updates but one can find a working example there.
An
associated
account attribute should be provided to encourage application developers to use deterministic addressing in their programs by default.For example,
Should create the
exchange_account
located at a program-derived-address located at deterministic address as a function of the program id + theauthority
address.Note that the
payer = authority
argument can also be provided, to specify the account paying for the account creation. If payer is not specified, the payer will default to the authority. Similarly, space can be provided to specify the size of the account. If none is provided, the length of theDefault::default
implementation for the account will be used. Lastly,with = <target>
is an optional parameter to specify a seed, e.g., how the spl token program's associated token account is defined by both the user's sol address and the token mint. It would be more general to allow this to be an array of arbitrary seeds, but I found thewith = <target>
syntax to be more aesthetic. If there's demand for a more general array, we can change or add it, e.g.,with_seeds = [...]
.A simplified version of the above, using the defaults, would like like
Here, the
authority
would pay for the account creation and be used as the target for the associated address, which would apply globally to the program (since nowith
parameter is specified). Thespace
sued would be theAccount
'sDefault::default
implementation).One wart here is the fact that the
rent
andsystem_program
accounts are exposed. However, they are needed for creating the associated address, and the framework has precedent for using accounts like this (e.g., theinit
attribute also requiresrent
). In theory, we could remove the system_program and have it be transparently used by the program, but I'm happy to punt that for now, as it may create unforseen complications + corner cases for using features likeremaining_accounts
.Originally suggested in the conversation here https://github.com/project-serum/anchor/issues/150.
Note: I suspect the current use of
with = <target>
is not ideal. Additionally, we might want to expandassociated = <target>
to just allow multiple instances to be specified, where the order is preserved when constructing seeds.with = <target>
, if specified, can be at the end. Filing this feature under a separate issue.