onchain-development intro-to-onchain updated (#344)

* onchain intro-to-onchain updated

* some refactors

* Update content/courses/onchain-development/intro-to-onchain.md

---------

Co-authored-by: Mike MacCana <[email protected]>

content/courses/onchain-development/intro-to-onchain.md

@@ -1,44 +1,57 @@
 ---
-title: Intro to onchain development
+title: Intro to Solana Onchain Development
 objectives:
   - Understand how Solana onchain programs work
-  - Describe the structure and operation of onchain programs
+  - Know about the structure and operation of Solana programs
   - Build a basic program
 description:
-  "How onchain programs (often called 'smart contracts') work on Solana."
+  "Discover how onchain programs ( often called 'smart contracts') work on
+  Solana and learn to build your own."
 ---
 
 ## Summary
 
-- **Onchain programs** are programs that run on Solana.
-- Programs have one or more **instruction handlers**. Instruction handlers are
-  functions that process the **instructions** in Solana transactions.
-- Instruction handlers write their data to Solana **accounts** and then either
-  succeed or fail.
-- Solana programs are most commonly written in **Rust**, typically with the
-  **Anchor** framework.
-- Anchor programs have IDLs, which are small JSON files describing programs.
-  IDLs can be used to automatically create JS/TS libraries for a program.
+- **Onchain programs** (sometimes called 'smart contracts') run directly on Solana, just like programs on your
+  computer.
+- These programs consist of **instruction handlers** - functions that process
+  instructions from transactions.
+- Programs interact with the blockchain by reading from and writing to Solana
+  **accounts**.
+- Solana programs are most commonly written in **Rust**, often using the
+  **Anchor** framework for simplified development.
+- Anchor generates **Interface Description Language (IDL)** files, which:
+  - Describe the program's structure and functionality
+  - Enable automatic creation of JavaScript/TypeScript client libraries
+- Solana's architecture allows for parallel execution of non-overlapping
+  transactions, contributing to its high speed and efficiency.
+- Rent is a concept in Solana where accounts must maintain a minimum balance to
+  stay alive on the blockchain.
 
 ## Overview
 
-Each Solana cluster (`mainnet-beta`, `testnet`, `devnet`, `localnet`) is
-effectively a single computer with a globally synchronized state. The programs
-that run on Solana - the ones that create tokens, swap tokens, art marketplaces,
-escrows, market makers, DePIN apps, auctions, retail payments platforms, etc -
-are called **Solana apps**.
+Solana operates on various clusters, each functioning as a unified, globally
+synchronized system:
 
-The most popular way to build onchain apps is using **Rust** language and the
-**Anchor** framework.
+- **mainnet-beta**: The main production network
+- **testnet**: For testing new features
+- **devnet**: For application development
+- **localnet**: For local testing
+
+The program that run on Solana - the ones that create tokens, swap tokens, art
+marketplaces, escrows, market makers, DePIN apps, auctions, retail payments
+platforms, etc - are called **Solana apps**.
 
-These frameworks implement common security checks automatically, and handle
-common tasks like:
+The most popular way to build onchain apps is using **Rust** language and the
+**Anchor** framework. There is also another way of developing Solana programs
+that is, by using the **native onchain program development**, however **Anchor**
+makes things a lot simpler and safer. Some pros of using Anchor are:
 
-- sending incoming instructions to the right instruction handlers
-- deserializing data from incoming transactions
-- checking the accounts provided with incoming instructions, for example, to
-  check that certain accounts are of a particular type, or are distinct from
-  other accounts.
+- Security checks are implemented automatically
+- Automatic routing of incoming instructions to the correct instruction handler
+- Automatic serialization and deserialization of the data inside transactions
+- Account validation, including:
+  - Type checking
+  - Ensuring account uniqueness
 
 Regardless of the language and framework you choose, Solana works the same.
 Let's refresh how programs work on Solana.
@@ -53,6 +66,8 @@ created during `anchor init`, and the private key is saved in the
 `target/deploy` directory of your project.
 
 A program's public key is sometimes called a 'program ID' or 'program address'.
+Which can be seen in the `programs/<insert_project_name>/src/lib.rs` and
+`Anchor.toml` files.
 
 ### Programs have instruction handlers
 
@@ -71,48 +86,75 @@ functionality by instruction handlers.
 
 ### Instruction handlers write their state to Solana accounts
 
-If you have previously done web development, you can think of instruction
-handlers like an HTTP route handler, and incoming instructions like HTTP
-requests.
+If you have done web development before, think of instruction handlers like HTTP
+route handlers, and incoming instructions like HTTP requests.
+
+However, unlike HTTP route handlers, Solana instruction handlers don't return
+data. Instead, they write their data to accounts on Solana.
 
-But unlike HTTP route handlers, Solana instruction handlers don't return data.
-Instead, the instruction handlers write their data to accounts on Solana.
+Programs on Solana can transfer tokens to user wallet addresses (for SOL) or
+user token accounts (for other tokens).
 
-Programs on Solana can transfer tokens, which end up in user wallet addresses
-(for SOL) for the user's token accounts (for other tokens).
+More importantly, programs can create additional addresses to store data as
+needed.
 
-But more importantly, programs on Solana can create additional addresses as
-needed, to store items of data.
+This is how Solana programs store their state.
 
-### Programs store data in Program Derived Addresses (PDAs), a key-value store
+### Program Derived Addresses (PDAs): Solana's Key-Value Store
 
 Data for Solana programs are stored in **program-derived addresses (PDAs)**.
-Solana's PDAs can be thought of as a **key/value store**:
-
-- The 'key' is the address of the PDA, which is determined by `seeds` chosen by
-  you, the programmer.
-  - Want an account to store USD to AUD exchange rate? Your program can use the
-    seeds `USD` and `AUD` to make a Program Derived Address
-  - Want to store information about the relationship of two users? You can use
-    **both those users' wallet addresses** as seeds to make a PDA to store that
-    information.
-  - Want an account to store Steve's review of Titanic? Your program can use
-    Steve's **wallet address** and the string `titanic` (or maybe the IMDB ID if
-    you prefer) to make a Program Derived Address.
-  - Want some global information for your entire program? You can use a string
-    like `'config'`. Your program's PDAs are unique, so they won't conflict with
-    other programs.
-- The value is the data inside the account at the given address.
-  - The data inside the PDA is determined by you, the programmer.
-
-Key value stores allow your onchain program, and client software, to
-consistently determine the address for a data item because the same seeds will
-always return the same address.
+Solana's PDAs can be thought of as a **key/value store**. A PDA can be designed
+to store any form of data as required by the program.
+
+#### Key Concepts
+
+1. **Structure**
+
+   - **Key**: The PDA's address
+   - **Value**: Data stored in the account at that address
+
+2. **Address Generation**
+
+   - **Seed**: chosen by the programmer
+   - **Bump**: An additional value to ensure unique PDA creation
+   - **Deterministic**: Same combination of seed and bump always produce the
+     same address. This helps the program and the client to accurately determine
+     the address of the data.
+
+3. **Data Storage**
+
+   - Programmers define the structure of data stored in PDAs
+   - Can store any type of program-specific information
+
+4. **Some properties**:
+   - PDAs are off the Ed25519 elliptic curve. While the data type web3.js uses
+     is a `PublicKey`, PDA addresses are not public keys and do not have a
+     matching private key.
+   - A program's PDAs are unique so, they won't conflict with other programs.
+   - PDAs can also act as signer in an instruction. We'll learn more about this
+     in further lessons.
+
+#### Examples of PDA Usage
+
+| Purpose           | Seeds                      | Resulting PDA                |
+| ----------------- | -------------------------- | ---------------------------- |
+| Exchange Rate     | `"USD"`, `"AUD"`           | Stores USD to AUD rate       |
+| User Relationship | User1 wallet, User2 wallet | Stores relationship data     |
+| Product Review    | User wallet, Product ID    | Stores user's review         |
+| Global Config     | `"config"`                 | Stores program-wide settings |
+
+#### Benefits
+
+1. **Uniqueness**: PDAs are specific to your program, avoiding conflicts
+2. **Determinism**: Consistent address generation across clients and on-chain
+   programs
+3. **Flexibility**: Can store various types of data structures
+4. **Efficiency**: Quick lookup and access to program-specific data
 
 ### Solana instructions need to specify all the accounts they will use
 
 As you may already know, Solana is fast because it can process transactions that
-don't overlap at the same time. I.e., just like in the real world, Alice sending
+don't overlap at the same time i.e., just like in the real world, Alice sending
 to Bob doesn't stop Chris from sending something to Diana. Your front-end apps
 need to specify the addresses of all the accounts they will use.