docs: Update tutorial 2 account explanation (#796)
This commit is contained in:
parent
f4fee46ea5
commit
f9cf3cf47c
|
@ -9,11 +9,11 @@ For example, you could imagine easily writing a faulty token program that forget
|
|||
|
||||
To address these problems, Anchor provides several types, traits, and macros. It's easiest to understand by seeing how they're used in an example, but a couple include
|
||||
|
||||
* [Accounts](https://docs.rs/anchor-lang/latest/anchor_lang/derive.Accounts.html): derive macro implementing the `Accounts` [trait](https://docs.rs/anchor-lang/latest/anchor_lang/trait.Accounts.html), allowing a struct to transform
|
||||
from the untrusted `&[AccountInfo]` slice given to a Solana program into a validated struct
|
||||
of deserialized account types.
|
||||
* [#[account]](https://docs.rs/anchor-lang/latest/anchor_lang/attr.account.html): attribute macro implementing [AccountSerialize](https://docs.rs/anchor-lang/latest/anchor_lang/trait.AccountSerialize.html) and [AccountDeserialize](https://docs.rs/anchor-lang/latest/anchor_lang/trait.AnchorDeserialize.html), automatically prepending a unique 8 byte discriminator to the account array. The discriminator is defined by the first 8 bytes of the `Sha256` hash of the account's Rust identifier--i.e., the struct type name--and ensures no account can be substituted for another.
|
||||
* [Account](https://docs.rs/anchor-lang/latest/anchor_lang/struct.Account.html): a wrapper type for a deserialized account implementing `AccountDeserialize`. Using this type within an `Accounts` struct will ensure the account is **owned** by the currently executing program.
|
||||
- [Accounts](https://docs.rs/anchor-lang/latest/anchor_lang/derive.Accounts.html): derive macro implementing the `Accounts` [trait](https://docs.rs/anchor-lang/latest/anchor_lang/trait.Accounts.html), allowing a struct to transform
|
||||
from the untrusted `&[AccountInfo]` slice given to a Solana program into a validated struct
|
||||
of deserialized account types.
|
||||
- [#[account]](https://docs.rs/anchor-lang/latest/anchor_lang/attr.account.html): attribute macro implementing [AccountSerialize](https://docs.rs/anchor-lang/latest/anchor_lang/trait.AccountSerialize.html) and [AccountDeserialize](https://docs.rs/anchor-lang/latest/anchor_lang/trait.AnchorDeserialize.html), automatically prepending a unique 8 byte discriminator to the account array. The discriminator is defined by the first 8 bytes of the `Sha256` hash of the account's Rust identifier--i.e., the struct type name--and ensures no account can be substituted for another.
|
||||
- [Account](https://docs.rs/anchor-lang/latest/anchor_lang/struct.Account.html): a wrapper type for a deserialized account implementing `AccountDeserialize`. Using this type within an `Accounts` struct will ensure the account is **owned** by the address defined by `declare_id!` where the inner account was defined.
|
||||
|
||||
With the above, we can define preconditions for our any instruction handler expecting a certain set of
|
||||
accounts, allowing us to more easily reason about the security of our programs.
|
||||
|
@ -48,16 +48,15 @@ Let's focus on the `increment` instruction, specifically the `Increment` struct
|
|||
pub struct Increment<'info> {
|
||||
#[account(mut, has_one = authority)]
|
||||
pub counter: Account<'info, Counter>,
|
||||
#[account(signer)]
|
||||
pub authority: AccountInfo<'info>,
|
||||
pub authority: Signer<'info>,
|
||||
}
|
||||
```
|
||||
|
||||
Here, several `#[account(..)]` attributes are used.
|
||||
|
||||
* `mut`: tells the program to persist all changes to the account.
|
||||
* `has_one`: enforces the constraint that `Increment.counter.authority == Increment.authority.key`.
|
||||
* `signer`: enforces the constraint that the `authority` account **signed** the transaction.
|
||||
- `mut`: tells the program to persist all changes to the account.
|
||||
- `has_one`: enforces the constraint that `Increment.counter.authority == Increment.authority.key`.
|
||||
- `signer`: enforces the constraint that the `authority` account **signed** the transaction.
|
||||
|
||||
If any of these constraints do not hold, then the `increment` instruction will never be executed.
|
||||
This allows us to completely separate account validation from our program's business logic, allowing us
|
||||
|
@ -66,5 +65,5 @@ to reason about each concern more easily. For more, see the full [list](https://
|
|||
## Next Steps
|
||||
|
||||
We've covered the basics for writing a single program using Anchor on Solana. But the power of
|
||||
blockchains come not from a single program, but from combining multiple *composable* programs
|
||||
blockchains come not from a single program, but from combining multiple _composable_ programs
|
||||
(buzzword...check). Next, we'll see how to call one program from another.
|
||||
|
|
Loading…
Reference in New Issue