docs: Change pronouns from one to you (#355)
This commit is contained in:
parent
72122b883d
commit
9224e0fa99
|
@ -65,7 +65,7 @@ accounts, we skip this (important) detail.
|
||||||
|
|
||||||
## Building and Emitting an IDL
|
## Building and Emitting an IDL
|
||||||
|
|
||||||
After creating a program, one can use the `anchor` CLI to build and emit an IDL, from which clients
|
After creating a program, you can use the `anchor` CLI to build and emit an IDL, from which clients
|
||||||
can be generated.
|
can be generated.
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
|
|
|
@ -38,19 +38,19 @@ pick it up.
|
||||||
:::
|
:::
|
||||||
|
|
||||||
Additionally,
|
Additionally,
|
||||||
notice how we take a mutable reference to `my_account` and assign the `data` to it. This leads us
|
notice how we take a mutable reference to `my_account` and assign the `data` to it. This leads us to
|
||||||
the `Initialize` struct, deriving `Accounts`. There are three things to notice about `Initialize`.
|
the `Initialize` struct, deriving `Accounts`. There are three things to notice about `Initialize`.
|
||||||
|
|
||||||
1. The `my_account` field is of type `ProgramAccount<'info, MyAccount>`, telling the program it *must*
|
1. The `my_account` field is of type `ProgramAccount<'info, MyAccount>`, telling the program it *must*
|
||||||
be **owned** by the currently executing program, and the deserialized data structure is `MyAccount`.
|
be **owned** by the currently executing program, and the deserialized data structure is `MyAccount`.
|
||||||
2. The `my_account` field is marked with the `#[account(init)]` attribute. This should be used
|
2. The `my_account` field is marked with the `#[account(init)]` attribute. This should be used
|
||||||
in one situation: when a given `ProgramAccount` is newly created and is being used by the program
|
in one situation: when a given `ProgramAccount` is newly created and is being used by the program
|
||||||
for the first time (and thus it's data field is all zero). If `#[account(init)]` is not used
|
for the first time (and thus its data field is all zero). If `#[account(init)]` is not used
|
||||||
when account data is zero initialized, the transaction will be rejected.
|
when account data is zero initialized, the transaction will be rejected.
|
||||||
3. The `Rent` **sysvar** is required for the rent exemption check, which the framework enforces
|
3. The `Rent` **sysvar** is required for the rent exemption check, which the framework enforces
|
||||||
by default for any account marked with `#[account(init)]`. To be more explicit about the check,
|
by default for any account marked with `#[account(init)]`. To be more explicit about the check,
|
||||||
one can specify `#[account(init, rent_exempt)]`. To skip this check, (and thus
|
one can specify `#[account(init, rent_exempt)]`. To skip this check, (and thus
|
||||||
allowing one to omit the `Rent` acccount) one can specify
|
allowing you to omit the `Rent` acccount), you can specify
|
||||||
`#[account(init, rent_exempt = skip)]` on the account being initialized (here, `my_account`).
|
`#[account(init, rent_exempt = skip)]` on the account being initialized (here, `my_account`).
|
||||||
|
|
||||||
::: details
|
::: details
|
||||||
|
@ -75,7 +75,7 @@ Marking an account as `mut` persists any changes made upon exiting the program.
|
||||||
|
|
||||||
Here we've covered the basics of how to interact with accounts. In a later tutorial,
|
Here we've covered the basics of how to interact with accounts. In a later tutorial,
|
||||||
we'll delve more deeply into deriving `Accounts`, but for now, just know
|
we'll delve more deeply into deriving `Accounts`, but for now, just know
|
||||||
one must mark their accounts `init` when using an account for the first time and `mut`
|
you must mark an account `init` when using it for the first time and `mut`
|
||||||
for persisting changes.
|
for persisting changes.
|
||||||
|
|
||||||
## Creating and Initializing Accounts
|
## Creating and Initializing Accounts
|
||||||
|
|
|
@ -5,7 +5,7 @@ somewhat unique to the parallel nature of Solana.
|
||||||
|
|
||||||
On Solana, a transaction must specify all accounts required for execution. And because an untrusted client specifies those accounts, a program must responsibly validate all such accounts are what the client claims they are--in addition to any instruction specific access control the program needs to do.
|
On Solana, a transaction must specify all accounts required for execution. And because an untrusted client specifies those accounts, a program must responsibly validate all such accounts are what the client claims they are--in addition to any instruction specific access control the program needs to do.
|
||||||
|
|
||||||
For example, one could imagine easily writing a faulty token program that forgets to check if the **signer** of a transaction claiming to be the **owner** of a Token `Account` actually matches the **owner** on that account. Furthermore, imagine what might happen if the program expects a `Mint` account but a malicious user gives a token `Account`.
|
For example, you could imagine easily writing a faulty token program that forgets to check if the **signer** of a transaction claiming to be the **owner** of a Token `Account` actually matches the **owner** on that account. Furthermore, imagine what might happen if the program expects a `Mint` account but a malicious user gives a token `Account`.
|
||||||
|
|
||||||
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
|
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
|
||||||
|
|
||||||
|
|
|
@ -26,7 +26,7 @@ We start with the program that will be called by another program, the puppet.
|
||||||
If you've followed along the other tutorials, this should be straight forward. We have
|
If you've followed along the other tutorials, this should be straight forward. We have
|
||||||
a program with two instructions, `initialize`, which does nothing other than the
|
a program with two instructions, `initialize`, which does nothing other than the
|
||||||
initialization of the account (remember, the program *transparently* prepends a unique 8
|
initialization of the account (remember, the program *transparently* prepends a unique 8
|
||||||
byte discriminator the first time an account is used). and `set_data`, which takes a previously
|
byte discriminator the first time an account is used), and `set_data`, which takes a previously
|
||||||
initialized account, and sets its data field.
|
initialized account, and sets its data field.
|
||||||
|
|
||||||
Now, suppose we wanted to call `set_data` from another program.
|
Now, suppose we wanted to call `set_data` from another program.
|
||||||
|
@ -65,7 +65,7 @@ For more background on signing with program derived addresses, see the official
|
||||||
|
|
||||||
## Return values
|
## Return values
|
||||||
|
|
||||||
Solana currently has no way to return values from CPI, alas. However, one can approximate this
|
Solana currently has no way to return values from CPI, alas. However, you can approximate this
|
||||||
by having the callee write return values to an account and the caller read that account to
|
by having the callee write return values to an account and the caller read that account to
|
||||||
retrieve the return value. In future work, Anchor should do this transparently.
|
retrieve the return value. In future work, Anchor should do this transparently.
|
||||||
|
|
||||||
|
|
|
@ -43,7 +43,7 @@ to the full power of the lower level Solana accounts API. Of course, Anchor will
|
||||||
|
|
||||||
### Invoke the constructor
|
### Invoke the constructor
|
||||||
|
|
||||||
To access the `#[state]` account and associated instructions, one can use the
|
To access the `#[state]` account and associated instructions, you can use the
|
||||||
`anchor.state` namespace on the client. For example, to invoke the constructor,
|
`anchor.state` namespace on the client. For example, to invoke the constructor,
|
||||||
|
|
||||||
<<< @/../examples/tutorial/basic-4/tests/basic-4.js#ctor
|
<<< @/../examples/tutorial/basic-4/tests/basic-4.js#ctor
|
||||||
|
@ -69,7 +69,7 @@ To invoke an instruction,
|
||||||
Performing CPI from one Anchor program to another's state methods is very similar to performing CPI to normal Anchor instructions, except for two differences:
|
Performing CPI from one Anchor program to another's state methods is very similar to performing CPI to normal Anchor instructions, except for two differences:
|
||||||
|
|
||||||
1. All the generated instructions are located under the `<my_program>::cpi::state` module.
|
1. All the generated instructions are located under the `<my_program>::cpi::state` module.
|
||||||
2. One must use a [CpiStateContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiStateContext.html), instead of a `[CpiContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiContext.html).
|
2. You must use a [CpiStateContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiStateContext.html), instead of a `[CpiContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiContext.html).
|
||||||
|
|
||||||
For a full example, see the `test_state_cpi` instruction, [here](https://github.com/project-serum/anchor/blob/master/examples/misc/programs/misc/src/lib.rs#L39).
|
For a full example, see the `test_state_cpi` instruction, [here](https://github.com/project-serum/anchor/blob/master/examples/misc/programs/misc/src/lib.rs#L39).
|
||||||
|
|
||||||
|
|
|
@ -32,7 +32,7 @@ pub enum ErrorCode {
|
||||||
|
|
||||||
Observe the [#[error]](https://docs.rs/anchor-lang/latest/anchor_lang/attr.error.html) attribute on the `ErrorCode` enum. This macro generates two types: an `Error` and a `Result`, both of which can be used when returning from your program.
|
Observe the [#[error]](https://docs.rs/anchor-lang/latest/anchor_lang/attr.error.html) attribute on the `ErrorCode` enum. This macro generates two types: an `Error` and a `Result`, both of which can be used when returning from your program.
|
||||||
|
|
||||||
To use the `Error`, one can simply use the user defined `ErrorCode` with Rust's [From](https://doc.rust-lang.org/std/convert/trait.From.html) trait. If you're unfamiliar with `From`, no worries. Just know that you need to either call
|
To use the `Error`, you can simply use the user defined `ErrorCode` with Rust's [From](https://doc.rust-lang.org/std/convert/trait.From.html) trait. If you're unfamiliar with `From`, no worries. Just know that you need to either call
|
||||||
`.into()` when using your `ErrorCode`. Or use Rust's `?` operator, when returning an error.
|
`.into()` when using your `ErrorCode`. Or use Rust's `?` operator, when returning an error.
|
||||||
Both of these will automatically convert *into* the correct `Error`.
|
Both of these will automatically convert *into* the correct `Error`.
|
||||||
|
|
||||||
|
|
|
@ -16,10 +16,10 @@ address for every SPL token? Now generalize this. For every program you use, do
|
||||||
want a single account, i.e. your SOL wallet, to define your application state? Or do
|
want a single account, i.e. your SOL wallet, to define your application state? Or do
|
||||||
you want to keep track of all your account addresses, separately, for every program in existance?
|
you want to keep track of all your account addresses, separately, for every program in existance?
|
||||||
|
|
||||||
Associated accounts allow your users to reason about a single address, their main SOL wallet,
|
Associated accounts allow your users to reason about a single address, their main SOL wallet. This is
|
||||||
a huge improvement on the account model introduced thus far.
|
a huge improvement on the account model introduced thus far.
|
||||||
|
|
||||||
Luckily, Anchor provides the ability to easily created associated program accounts for your program.
|
Luckily, Anchor provides the ability to easily create associated program accounts for your program.
|
||||||
|
|
||||||
::: details
|
::: details
|
||||||
If you've explored Solana, you may have come across the [Associated Token Account Program](https://spl.solana.com/associated-token-account) which uniquely and deterministically defines
|
If you've explored Solana, you may have come across the [Associated Token Account Program](https://spl.solana.com/associated-token-account) which uniquely and deterministically defines
|
||||||
|
@ -31,7 +31,7 @@ Unfortunately, the SPL token program doesn't do this, strictly. It was built *be
|
||||||
of associated token accounts (associated token accounts were built as an add-on).
|
of associated token accounts (associated token accounts were built as an add-on).
|
||||||
So in reality, there are non associated token accounts floating around Solanaland.
|
So in reality, there are non associated token accounts floating around Solanaland.
|
||||||
However, for new programs, this isn't necessary, and it's recommend to only use associated
|
However, for new programs, this isn't necessary, and it's recommend to only use associated
|
||||||
accounts, when creating accounts on behalf of users, for example, a token account.
|
accounts when creating accounts on behalf of users, such as a token account.
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## Clone the Repo
|
## Clone the Repo
|
||||||
|
@ -62,7 +62,7 @@ Two new keywords are introduced to the `CreateToken` account context:
|
||||||
* `associated = <target>`
|
* `associated = <target>`
|
||||||
* `with = <target>`
|
* `with = <target>`
|
||||||
|
|
||||||
Both of these allow one to define input "seeds" that
|
Both of these allow you to define input "seeds" that
|
||||||
uniquely define the associated account. By convention, `associated` is used to define
|
uniquely define the associated account. By convention, `associated` is used to define
|
||||||
the main address to associate, i.e., the wallet, while `with` is used to define an
|
the main address to associate, i.e., the wallet, while `with` is used to define an
|
||||||
auxilliary piece of metadata which has the effect of namespacing the associated account.
|
auxilliary piece of metadata which has the effect of namespacing the associated account.
|
||||||
|
@ -86,7 +86,7 @@ For more details on how to use `#[account(associated)]`, see [docs.rs](https://d
|
||||||
### Defining an Associated Account
|
### Defining an Associated Account
|
||||||
|
|
||||||
The new `#[acount(associated)]` attribute will allow you to create a new associated account similar to `#[account(init)]`, but
|
The new `#[acount(associated)]` attribute will allow you to create a new associated account similar to `#[account(init)]`, but
|
||||||
to actually define an account as associated, one must use the `#[associated]` attribute *instead* of the `#[account]` attribute.
|
to actually define an account as associated, you must use the `#[associated]` attribute *instead* of the `#[account]` attribute.
|
||||||
|
|
||||||
This new `#[associated]` attribute extends `#[account]` to include two things
|
This new `#[associated]` attribute extends `#[account]` to include two things
|
||||||
|
|
||||||
|
|
|
@ -84,7 +84,7 @@ a single admin, or the zero address--in which case the authority ceases to exist
|
||||||
program will reject transactions signing from that address. Although the **authority** can never
|
program will reject transactions signing from that address. Although the **authority** can never
|
||||||
move a **Vesting** account's funds, whoever controls the **authority** key
|
move a **Vesting** account's funds, whoever controls the **authority** key
|
||||||
controls the whitelist. So when using the **Lockup** program, one should always be
|
controls the whitelist. So when using the **Lockup** program, one should always be
|
||||||
cognizant of it's whitelist governance, which ultimately anchors one's trust in the program,
|
cognizant of its whitelist governance, which ultimately anchors one's trust in the program,
|
||||||
if any at all.
|
if any at all.
|
||||||
|
|
||||||
## Creating a Whitelisted Program
|
## Creating a Whitelisted Program
|
||||||
|
|
|
@ -89,7 +89,7 @@ from the stake pool is complete, and the funds are ready to be used again.
|
||||||
Feel free to skip this section and jump to the **Reward Vendors** section if you want to
|
Feel free to skip this section and jump to the **Reward Vendors** section if you want to
|
||||||
just see how rewards work.
|
just see how rewards work.
|
||||||
|
|
||||||
One could imagine several ways to drop rewards onto a staking pool, each with their own downsides.
|
One could imagine several ways to drop rewards onto a staking pool, each with there own downsides.
|
||||||
Of course what you want is, for a given reward amount, to atomically snapshot the state
|
Of course what you want is, for a given reward amount, to atomically snapshot the state
|
||||||
of the staking pool and to distribute it proportionally to all stake holders. Effectively,
|
of the staking pool and to distribute it proportionally to all stake holders. Effectively,
|
||||||
an on chain program such as
|
an on chain program such as
|
||||||
|
|
Loading…
Reference in New Issue