From 1ba6db0afe2276002c426535435518b0ee580d9a Mon Sep 17 00:00:00 2001 From: Camden Clark Date: Sat, 23 Oct 2021 16:40:36 -0700 Subject: [PATCH] docs: Update tutorial 2 with Signer changes (#917) --- docs/src/tutorials/tutorial-2.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/src/tutorials/tutorial-2.md b/docs/src/tutorials/tutorial-2.md index d634792d9..87506e93b 100644 --- a/docs/src/tutorials/tutorial-2.md +++ b/docs/src/tutorials/tutorial-2.md @@ -52,11 +52,13 @@ pub struct Increment<'info> { } ``` -Here, several `#[account(..)]` attributes are used. +Here, a couple `#[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. + +Another new concept here is the `Signer` type. This enforces the constraint that the `authority` +account **signed** the transaction. However, anchor doesn't fetch the data on that account. 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