Last week we had our wonder kid @mjlee221 presenting "Neighbourhood Solanaland" as part of our Slam Tech Poetry Friday sessions. He is one of our Rust devs, having worked with various open-source projects in the @solana ecosystem such as @Backpack and @bonfida. As we are seeing increased interest from Clients looking to build in Solana, he gave the team deep-dive on building Solana and how it differs to building EVM dApps. 1/ 🧵 Thread with plenty of insights:
- Solana is mempooless via Gulf Stream (transactions are not queued like Ethereum does and waits for nodes to pick it up) - Performs transactions in parallel (Solana's Proof of History encodes a verifiable proof of ordering for each transactions) - DeFi dApps mostly leverage globally synced open order book systems (@openbookdex, @PhoenixTrade) vs Ethereum’s AMM based DEXes. 2/
Smart Contracts: As opposed to EVM's where we deploy contracts and the code along with its state is stored at one address, of which we can use to refer to the contract to read/write to it: In @solana, contracts are called Programs: - Programs are stateless, they just hold “instructions”, and no data/state - When you call a function in Solana, you must pass the data to the function which is then stored in a separate “account” An Account just means a storage unit for storing arbitrary data. There are 2 types of accounts: - Data Accounts ▶️ Store data for programs - Program Accounts ▶️ Store the code of program 3/
Storage on Solana is not free, you must pay rent to “host” your account: Accounts can store balances in Lamports. 1 SOL = 10^9 Lamports (similar to how Wei is to ETH) Garbage collector may remove your account once you have exhausted your Lamport balance. - You pay 2 years worth of rent in advance to be rent exempt. - It introduces concepts like withdrawing ‘rent’ from accounts to delete them (e.g. Burning scam tokens). This helps relieve the need to store unnecessary data from the network. 4/
Program Derived Addresses (PDAs) PDAs are deterministic derived addresses from a program id (address) and a collection of seeds. - Basically, we mix the addresses and seeds through a hash function (SHA-512) until it generates a public key that is not on the elliptic curve (ED25519) via special bump seed. - Use PDAs to derive an address to store our accounts for a program. - For most apps, a common practice is to generate PDAs using the public key of the user as the seed. This is how a USDC transfer works in Solana with Typescript and Solana’s Web3.Js 👇 - This is a common pattern when interacting with a token program. - `getAssociatedTokenAddress` is a function primarily used to derive a PDA for token accounts. - Remember that the PDA in this example is what holds the balance of our USDC balance. 5/
Solana’s Fee Model Base fees are determined, based on set base fee per signature and computational units used to perform the transaction. - Priority fees: extra fees paid to be prioritised when transactions are executed. - 50% of these fees are burned (similar to Ethereum’s EIP-1559 model). - Fee markets are localised per program rather than globalised. - Think these fee markets as a highway with multiple lanes rather than one lane. - This means the fees could skyrocket for users interacting with a program if demand for that program increases, but, everyone else in the network would be unaffected. 6/
Anchor Development Framework @anchorlang is an open-source development framework for Solana, similar to what @HardhatHQ is for Ethereum. - From unit testing in typescript, forking, to boilerplating a lot of low level rust code. 7/
Some potential caveats as a Solana developer It's generally harder to integrate with DeFi protocols due to a few reasons: - Most DeFi infrastructure is not deployed on Solana Devnets. Reason for this is many things: - Swap aggregators like Solana’s @JupiterExchange (@0xProject, @1inch equivalent on Ethereum) or most of Solana DeFi can’t function properly without functioning market makers in an open order book system (active volume, liquidity, etc.), and other dependency protocols. - Most DeFi protocols cannot be bothered maintaining a devnet version of it. - Some DeFi protocols are closed source so cannot replicate as easily :( 8/
What’s a solution? Test integration locally by forking mainnet via Anchor - Forking requires manually specifying programs and accounts in anchor's configuration file (.toml file). - Some negatives: requires maintaining a list of all accounts we are interacting with. Regardless, testing on a localnet is not as ideal, as our project managers and engineers need to be able to perform an easy-to-access integration tests at all times. - One solution, while not ideal, is to test in mainnet. 9/
Addressing the Elephant in the Room Programs are stateless: upgrading is actually easy (natively) without the much added side effects akin to Ethereum smart contract proxy upgrades. This allows flexible development cycles and slowly mature your protocol. For certain cases, you would not need to redeploy the same code over again, as it's a matter of creating a PDA for a program. However, this can often lead to programs being centralised by default due to the ease of upgradability, and encourages program monoliths: - Excessive reliance on specific programs that has achieved the most adoption and usage in the ecosystem. - You can create your own standard, but it could see some difficulty in terms of integration, (with existing protocols and wallet service providers), which could isolate newer contenders in the market, without a prepared, community driven effort in place. - Monoliths and centralisation can be a bit of a recipe for disaster. - Serum would be an example of this, as the upgrade keys were known to be exposed in the FTX backend, and was unideal for existing DeFi protocols to continue using it. This led to a community driven fork called Openbook and the development of other order books. Program upgradeability is dangerous in the wrong hands but, as a deployer, you can also set it to be immutable as well. - It is also easy to check if a program is mutable or not via Solana blockchain explorers. - Interface like standards are being worked on (similar to ERCs in Ethereum). This should allow wallets and protocols to have more flexibility when it comes to integrating new programs and relieve some of the monolith issues that plague the ecosystem. 10/
Program Deployment The cost of program deployments are calculated based on how much computational units of storage it occupies based in SOL value, but do not scale well in terms of Solana's soaring token valuation, and may prove to be unaffordable for new developers joining the ecosystem. This, however, is being continuously debated among the community to actively change this. 11/
Contract Verification Contract verification exists on Solana… but it’s not clear cut like Ethereum’s @etherscan. Verifying contracts on Solana is possible but it requires multiple steps to do so. The binaries for deployed programs are reproducible if these are available: - The source code - Version - Compiler version, - Toolchain This requires the protocol to be open source on Github for us to manually build, and compare the binaries of. 12/
Block Explorers While block explorers have been improving (Xray, @solanafm, @solscanofficial) for viewing transactions, not much has been achieved in terms of verification. - Ethereum has a centralised third party (Etherscan) facilitating this process by allowing us to upload contracts, which they build and verify against the on-chain contract. - Given that you CAN verify programs on Solana, nothing actually stops this from happening on Solana too. It’s a matter of someone actually building the infrastructure for it. - Etherscan recently acquired Solscan, which could open up new opportunities 👀 13/
Storage Bloat - Solana’s blockchain size grows at tremendous rate in size (grows at 4 petabytes per year, that’s 4K Terrabyte). - Validators do not actually store this much data, and they can control how much of the ledger to store, with a default value around ~400-500GB of storage space. The reset is offloaded to Archival nodes and solutions. - Some of Solana's Archival solutions are @google's BigTable and @Filecoin. - Ethereum tries to address storage bloat through the Verkle tree roadmap and reducing proof sizes. 14/
Compressed NFTs (cNFTs) Uses clever magic of merkle trees to compress data, where only essential information is stored on-chain and additional data off-chain while ensuring data integrity. - Metaplex launched the 'Bubblegum' program, which brings down the cost of minting 1 million NFTs from 12K SOL to only 5.35 SOL cNFTs, which may be useful for managing bulks of digital assets such as in Web3 gaming. 15/
Solang (Solidity compiler for Solana) Solana supports solidity contract development with Solang but it’s still very different and not directly transferable from the standard stack that Ethereum developers are familiar with. - Requires understanding of how Solana accounts work, and knowledge of Solana specific annotations. - Unit testing is done through Anchor (not Hardhat) 16/
Client Development Brief overview: Firedancer ▶️ Second validator client on Solana written in C assembly, which only requires a consumer level hardware, and “1,000,000” TPS. - Tinydancer ▶️ A light client on Solana that uses DAS (Data Availability Sampling), which should allow cheap verification without requiring crazy specs. 17/