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
|
||||
|
||||
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.
|
||||
|
||||
```bash
|
||||
|
|
|
@ -38,19 +38,19 @@ pick it up.
|
|||
:::
|
||||
|
||||
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`.
|
||||
|
||||
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`.
|
||||
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
|
||||
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.
|
||||
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,
|
||||
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`).
|
||||
|
||||
::: 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,
|
||||
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.
|
||||
|
||||
## 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.
|
||||
|
||||
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
|
||||
|
||||
|
|
|
@ -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
|
||||
a program with two instructions, `initialize`, which does nothing other than the
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
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,
|
||||
|
||||
<<< @/../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:
|
||||
|
||||
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).
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
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.
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
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).
|
||||
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
|
||||
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
|
||||
|
@ -62,7 +62,7 @@ Two new keywords are introduced to the `CreateToken` account context:
|
|||
* `associated = <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
|
||||
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.
|
||||
|
@ -86,7 +86,7 @@ For more details on how to use `#[account(associated)]`, see [docs.rs](https://d
|
|||
### Defining an Associated Account
|
||||
|
||||
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
|
||||
|
||||
|
|
|
@ -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
|
||||
move a **Vesting** account's funds, whoever controls the **authority** key
|
||||
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.
|
||||
|
||||
## 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
|
||||
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 the staking pool and to distribute it proportionally to all stake holders. Effectively,
|
||||
an on chain program such as
|
||||
|
|
Loading…
Reference in New Issue