docs: Update tutorial 2 account explanation (#796)

docs/src/tutorials/tutorial-2.md

@@ -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.