solana应用开发1

executing smart contract

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）