hatem.ethUnlocking Web3 for the Masses: Introduction
Innovators have started building NFT marketplaces, prediction markets, web3 gaming applications, etc. for everyday users, but these applications are held back by the complexity of using web3. Before using a web3 application, users must set up an exchange account, buy crypto, set up a wallet, write down their seed phrase, transfer crypto to their wallet, figure out how to bridge between chains, hold a native token on every chain to pay transaction fees, and more. It's an intimidating and ...
hatem.ethBecoming an EVM Expert
Becoming an EVM Expert - The Hard WayThere’s a large learning curve to learning blockchain development because it’s so different than web2 programming paradigms. Instead of writing code that runs on one computer, you’re writing and interacting with code that runs on a distributed network To deeply understand blockchain development, we’ll want to look at the virtual machine (VM) that’s used. There’s a couple different virtual machines that different blockchain’s use including Sealevel (Solana)...
hatem.ethUnlocking Web3 for the Masses: Private Key Management
To enable the average person to hold cryptoassets, we need solutions to manage private keys that are easier to use and more secure. The current solutions offer easy-to-use key management but make concessions on security and privacy. Fortunately new technology will enable private key management solutions that are still seamless but without the drawbacks of legacy solutions.Legacy SolutionsA handful of private key management solutions have been around for years including Magic Link, Web3Auth, V...
hatem.ethUnlocking Web3 for the Masses: Introduction
Innovators have started building NFT marketplaces, prediction markets, web3 gaming applications, etc. for everyday users, but these applications are held back by the complexity of using web3. Before using a web3 application, users must set up an exchange account, buy crypto, set up a wallet, write down their seed phrase, transfer crypto to their wallet, figure out how to bridge between chains, hold a native token on every chain to pay transaction fees, and more. It's an intimidating and ...
hatem.ethBecoming an EVM Expert
Becoming an EVM Expert - The Hard WayThere’s a large learning curve to learning blockchain development because it’s so different than web2 programming paradigms. Instead of writing code that runs on one computer, you’re writing and interacting with code that runs on a distributed network To deeply understand blockchain development, we’ll want to look at the virtual machine (VM) that’s used. There’s a couple different virtual machines that different blockchain’s use including Sealevel (Solana)...
hatem.ethUnlocking Web3 for the Masses: Private Key Management
To enable the average person to hold cryptoassets, we need solutions to manage private keys that are easier to use and more secure. The current solutions offer easy-to-use key management but make concessions on security and privacy. Fortunately new technology will enable private key management solutions that are still seamless but without the drawbacks of legacy solutions.Legacy SolutionsA handful of private key management solutions have been around for years including Magic Link, Web3Auth, V...
Subscribe to hatem.eth
Subscribe to hatem.eth
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
Notes I put together on Solana in 2022. Lots of the ecosystem stuff is outdated now.
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.
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)
super fast, feels basically instant
programs compiled via LLVM compiler infrastructure to Executable and Linkable Format (standard binary file format for Unix) containing Berkeley Packet Filter (BPF) bytecode
smart contracts can be written in any language that can be compiled down to solana's backend. Rust is popular.
FTX
Coinbase
magic.link
phantom
we'd have to create our own custom solution
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
https://wormholenetwork.com/en/ whose docs can be found here.
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://dev.to/cogoo/solana-teardown-walkthrough-of-the-example-helloworld-program-18m4
https://docs.solana.com/developing/on-chain-programs/developing-rust
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
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
Notes I put together on Solana in 2022. Lots of the ecosystem stuff is outdated now.
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.
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)
super fast, feels basically instant
programs compiled via LLVM compiler infrastructure to Executable and Linkable Format (standard binary file format for Unix) containing Berkeley Packet Filter (BPF) bytecode
smart contracts can be written in any language that can be compiled down to solana's backend. Rust is popular.
FTX
Coinbase
magic.link
phantom
we'd have to create our own custom solution
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
https://wormholenetwork.com/en/ whose docs can be found here.
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://dev.to/cogoo/solana-teardown-walkthrough-of-the-example-helloworld-program-18m4
https://docs.solana.com/developing/on-chain-programs/developing-rust
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
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
approve an account to spend your tokens
No activity yet