base element： Account
Data being stored in the blockchain is living inside the account
Data into Account Account in blockchain
Account holds money
Smart Contract （Program）inside the account
Smart Contract in its binary form is data of some account
Account must be owned by a program
only way be debited the account owner is the one doing the actions
2. Rent
3. Compute Limit
Structure
Transaction
Block
Transaction：Metadata Accounts Instructions
1） Array of signatures（that may be needed in order to get the permissions to do various tasks within the transaction
for example， crediting the lamports that is taking it out of one account
and sending it off to another account
+ writing into the data of an account and modifying that data
2） message
（a）top：header（bunch of metadata，count of signatures， count of read-only addresses that require signatures，count of read-only addresses that do not require signatures）
（b）middle： array of account addresses
（required because when you launch your individual instructions， these are the calls being made to the specific program that need to do work
so those programs will make a claim about what accounts they are going to accessing for various reasons during their run）
（Check：these account they claimed access to must be listed out in the
total array of all account addresses being accessed in the message
so within that transaction）
（c） previous block hash：a big element of how solana works and how solana creates consensus and maintains its security is by using time as a mechanism in part to do that work
they have something called proof of history as their consensus mechanism
（proof of stake）allow other nodes to check the validity
check previous block hash to see whatever is requested during this transaction is neither too old or way into the future
either every
if one fails others fail。one instruction fails the whole thing fails
（理解）
（d） instructions
1-ProgramID （pointing the account parent that is holding the program inside its data
2-List of Accounts you are claiming your program is going to need access to（accounts must be in the master list in order for instructions to be valid）
3-Checks （owner check。 specific：program acting on the correct set of accounts）
4- data u8 byte array （open ended） any type of data including objects
lib.rs
program entrypoint
mirror of program_id, accounts and instruction data
accounts:list of accounts that your specific program need access to
instruction data u8:
//Iterating accounts is safer then indexing!
let accounts_iter = &mut accounts.iter();
(iterable , you take the first element you take the entire array then you take the next on it which gives you the initial next element.
Getting reference to the mutable array)
//Get the account to say hello to
let account = next_account_info(accounts_iter)?;
// instead of calling next, next, next we just use this helper tool
//grab the right specific account in the right order
//everytime this get called, it just gives me the immediate next account
3) The account must be owned by program in order to modify its data
if account.owner != program_id { return Err(ProgramError::IncorrectProgramId};
4)Increment and store the number of times the account has been greeted
let mut greeting_account = GreetingAccount::try_from_slice(&account.data.borrow())?;
//data, whatever data we want. we need to encode and decode properly
//went from byte array and it decoded it into its actual type instance
//then after doing whatever it is that it needed to do it's now taking it and encoding it back into the data
let mut greeting_account = GreetingAccount :: try_from_slice(&account.data.borrow())?
//bytearray then decode it into its actual type instance
let data = &mut &mut account.data.borrow_mut()[..];
greeting_account.serialize(data)
//taking it and encoding it
让GreetingAccount inherit from derive后面的那些，不需要写代码
automatically apply to this type（traits in rust）
by doing this give greetingaccount ability to encode and decode itself
2）
