# Solana Notes By [hatem.eth](https://paragraph.com/@hatem) ยท 2024-05-16 --- _Notes I put together on Solana in 2022. Lots of the ecosystem stuff is outdated now._ Overview -------- * over 60,000 tps * $0.00025 transaction fees * 800 ms blocktime Sets of validators called clusters work together to validate client transactions. Different clusters may coexist and are identified by their genesis block. Two clusters that share the same genesis block will attempt to merge, otherwise they will ignore each other. Differs from traditional blockchains in that actions across nodes can be synchronized using proof of history (PoH). * leader creates cryptographic proof with entries that some duration has passed since the last proof * leader shares new entries with validator nodes which verify those proofs * verifiable timestamps allow entries to arrive at validators in any order since the validators can reconstruct their order * "blocks" are a set of entries that have been confirmed together. * validator nodes optimistically process transactions in entries and roll back changes in the event that consensus wasn't achieved. ### Miscellaneous * end users can create atomic transactions to multiple programs. On Ethereum this is only possible through a smart contract router. * account model was designed to be easily parallelized * _programs_ are _completely immutable_ accounts that store executable byte code. Programs store their state in non-executable accounts. * Accounts can specify an owner which is the only program allowed to make modifications to the account * to parallelize transactions, transactions specify all the accounts they will read from or write to so that validators know ahead of time which transactions can be parallelized and which conflict. Enabling programs to store data in different accounts allows devs to optimize for parallelization so that as many transactions can be parallelized as possible. * transaction signatures * an array of signatures is passed to solana transactions so if on chain programs are looking for more than one signature (say for a multisig wallet), all the signatures can efficiently be verified by a GPU instead of within a program * `recentBlockhash` vs `nonce` * solana transactions sign a recent blockhash and old transactions cannot be verified. This solves the same problem as an Ethereum nonce while also ensuring old transactions can't be run * sol transfers * there's a solana program, the system program, which allows users to transfer sol * transactions roughly have a fixed cost and there is a limit to the compute cost a transaction can use * solana `instructions` (think Ethereum tx data) are commands for on chain programs. Transactions can include multiple instructions (executed atomically). The encoded size of a transaction is 1232 bytes so instructions cannot become too large. * solana has special programs for deploying programs and transferring sol. * account ownership * all accounts have an owner. By default their owner is the system program. When a program owns an account it is able to change its data. When an program does not own an account, it can merely read the account's data **Terminology** * Account: record on the ledger that holds data or is an executable program * Bank State: state of all programs on the ledger at a given tick height * entry: an entry on the ledger which is either a tick or a transaction entry. Blocks consist of entries which are smaller smaller batches of transactions. * tick: an entry that estimates wallclock duration (timestamp) ### Usage Notes * super fast, feels basically instant ### Smart Contract Development + Developer Tools * programs compiled via [LLVM compiler infrastructure](https://llvm.org/) to [Executable and Linkable Format](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) (standard binary file format for Unix) containing [Berkeley Packet Filter (BPF)](https://en.wikipedia.org/wiki/Berkeley_Packet_Filter) bytecode * smart contracts can be written in any language that can be compiled down to solana's backend. Rust is popular. ### Deposits/Withdrawals * FTX * Coinbase ### Login/Wallets * magic.link * phantom Existing Smart Contract Infrastructure -------------------------------------- ### Conditional Token Contracts ### AMMs * [Token Swap Program](https://github.com/solana-labs/solana-program-library/tree/master/token-swap) ### Order Book * [Serum](https://docs.projectserum.com/) ### Gas Station Network * we'd have to create our own custom solution ### Proxy Wallets * Solana uses a proxy-wallet like architecture by default for their tokens because user token data is stored in an Account that is controlled by the program ### Oracles * [https://solana.com/ecosystem/bandprotocol](https://solana.com/ecosystem/bandprotocol) * [https://solana.com/ecosystem/chainlink](https://solana.com/ecosystem/chainlink) ### Blockchain Indexers * [https://aleph.im/#/](https://aleph.im/#/) ### Cross Chain Communication with Ethereum * [https://wormholenetwork.com/en/](https://wormholenetwork.com/en/) whose docs can be found [here](https://github.com/certusone/wormhole/blob/dev.v2/design/0001_generic_message_passing.md). * wormhole allows for generic message passing between solana and ethereum * network of (currently 19) guardians watches wormhole contracts. When enough guardians sign an observation, the message is then posted on the destination chain Resources: * [https://docs.solana.com/](https://docs.solana.com/) * [https://2501babe.github.io/posts/solana101.html](https://2501babe.github.io/posts/solana101.html) * [https://solana.wiki/zh-cn/docs/ethereum-comparison/](https://solana.wiki/zh-cn/docs/ethereum-comparison/) * [https://dev.to/cogoo/solana-teardown-walkthrough-of-the-example-helloworld-program-18m4](https://dev.to/cogoo/solana-teardown-walkthrough-of-the-example-helloworld-program-18m4) * [https://github.com/solana-labs/solana-program-library](https://github.com/solana-labs/solana-program-library) * [https://docs.solana.com/developing/on-chain-programs/developing-rust](https://docs.solana.com/developing/on-chain-programs/developing-rust) Dev Notes --------- ### SPL Token ### State Separate accounts for * Mint info * defines total supply, decimals, who can optionally mint, and who can optionally freeze * Account for each address with a token balance * defines the owner, mint, and amount held by the account among other things * Multisig * struct enables many diff ### Life Cycle * create an account for the new token's Mint storage. This includes creating a new key pair or passing in an existing key pair for the new account. This key pair will be one of signers of the transaction. The address of the spl token will be the owner of the account. Importantly, there is one piece of code that manages how many different tokens operate. * creating the account includes transferring the minimum balance the account needs for 2 years of rent exemption * client specifies a fixed storage size preallocated to the account * initialize\_mint to define the account that can mint new tokens * initialize the user's account * use `create_associated_token_account` to deterministically create an account for the user's token data * initialize the account. Write the initial data to the account. * mint tokens to the users account * update Mint account with the updated supply * update Account account with it's updated token amount * transfer tokens * if the recipient account isn't created, create an associated token account for the recipient * use `create_associated_token_account` to create the account * process the transfer * ensure the Mint account of both Accounts is the same (i.e. it is the same token) and a bunch of other checks * update the balances in both accounts * approve an account to spend your tokens --- *Originally published on [hatem.eth](https://paragraph.com/@hatem/solana-notes)*