feat(docs): Notes page

docs/docs/aztec/concepts/storage/notes.md

@@ -0,0 +1,25 @@
+---
+title: Notes (UTXOs)
+sidebar_position: 5
+tags: [notes, storage]
+---
+
+import Image from "@theme/IdealImage";
+
+The [state model page](./state_model.md) explains that there is a difference between public and private state. Private state uses UTXOs, also known as notes. This page introduces the concept of UTXOs and how notes are abstracted on Aztec.
+
+## What are notes?
+
+In an account-based model such as Ethereum, each account owns a specific amount of asset. In a UTXO model, each note has an owner. Notes are encrypted pieces of data that can only be decrypted by their owner. To change the owner of a note, Aztec destroys the original note, creates a nullifier, and creates a new note that is encrypted to the new owner. This helps to maintain privacy.
+
+ <Image img={require("/img/public-and-private-state-diagram.png")} />
+
+Notes are comparable to cash. When you want to spend $3.50 USD in real life, you give your $5 note to a cashier who will keep $3.50 and give you separate notes that add up to $1.50. Only you and the cashier are aware of this transaction.
+
+## Abstracting notes from from apps & users
+
+When using the Aztec protocol, users may not be aware of the specific notes that they own. Their experience should be similar to Ethereum, and should instead see the amount of their assets inside their account. 
+
+This is accomplished through the smart contract library, Aztec.nr, which abstracts notes by allowing developers to specify their own note types. This means they can specify how they are interacted with, nullified, transferred, and displayed. 
+
+To understand note abstraction in Aztec.nr, you can read the [Build section](../../../developers/guides/smart_contracts/writing_contracts/notes/index.md).

docs/docs/aztec/concepts/storage/state_model.md

@@ -14,24 +14,13 @@ Internal to the Aztec network, public state is stored and updated by the sequenc
 
 ## Private State
 
-Private state must be treated differently from public state and this must be expressed in the semantics of Aztec.nr.
-
-Private state is encrypted and therefore is "owned" by a user or a set of users (via shared secrets) that are able to decrypt the state.
+Private state must be treated differently from public state. Private state is encrypted and therefore is "owned" by a user or a set of users (via shared secrets) that are able to decrypt the state.
 
 Private state is represented in an append-only database since updating a record would leak information about the transaction graph.
 
 The act of "deleting" a private state variable can be represented by adding an associated nullifier to a nullifier set. The nullifier is generated such that, without knowing the decryption key of the owner, an observer cannot link a state record with a nullifier.
 
-Modification of state variables can be emulated by nullifying the state record and creating a new record to represent the variable. Private state has an intrinsic UTXO structure and this must be represented in the language semantics of manipulating private state.
-
-### Abstracting UTXO's from App's / Users
-
-The goal of the Aztec.nr smart contract library is to abstract the UTXO model away from an app user / developer, contract developers are the only actor who should have to think about UTXO's.
-
-This is achieved with two main features:
-
-1. Users sign over transactions, not over specific UTXO's
-2. Aztec.nr contracts support developer defined `unconstrained` getter functions to help dApp's make sense of UTXO's. e.g `getBalance()`. These functions can be called outside of a transaction context to read private state.
+Modification of state variables can be emulated by nullifying the state record and creating a new record to represent the variable. Private state has an intrinsic UTXO structure.
 
 ## Further reading
 

docs/docs/aztec/concepts/wallets/index.md

@@ -58,7 +58,7 @@ Due to limitations in the current architecture, privacy keys need to be availabl
 
 ## Recipient encryption keys
 
-Wallets are also expected to manage the public encryption keys of any recipients of local transactions. When creating an encrypted note for a recipient given their address, the wallet needs to provide their [complete address](../accounts/keys.md#complete-address). Recipients broadcast their complete addresses when deploying their account contracts, and wallets collect this information and save it in a local registry for easy access when needed.
+Wallets are also expected to manage the public encryption keys of any recipients of local transactions. When creating an encrypted note for a recipient given their address, the wallet needs to provide their [complete address](../accounts/keys.md#address-keys). Recipients broadcast their complete addresses when deploying their account contracts, and wallets collect this information and save it in a local registry for easy access when needed.
 
 Note that, in order to interact with a recipient who has not yet deployed their account contract (and thus not broadcasted their complete address), it must also be possible to manually add an entry to a wallet's local registry of complete addresses.
 

docs/docs/developers/guides/smart_contracts/writing_contracts/notes/index.md

@@ -4,4 +4,6 @@ sidebar_position: 3
 tags: [contracts, notes]
 ---
 
-Notes are the fundamental data structure in Aztec when working with private state. In this section there are guides about how to work with `AddressNote`, `ValueNote`, and custom notes in Aztec.nr. You can learn more about notes in the [concepts section](../../../../../aztec/concepts/storage/state_model.md).
+Notes are the fundamental data structure in Aztec when working with private state. Using Aztec.nr, developers can define note types which allow flexibility in how notes are stored and nullified.
+
+In this section there are guides about how to work with `AddressNote`, `ValueNote`, and custom notes in Aztec.nr. You can learn more about notes in the [concepts section](../../../../../aztec/concepts/storage/notes.md).