Solana is not an easy blockchain to learn, let alone master. First, Solana uses Rust, which is an unfamiliar and difficult language to learn. Second, the environment of Solana is entirely different from Ethereum.
Here are some major differences:
Solana has no notion of a storage variable. Solana smart contracts (known as “programs”) are completely stateless.
Everything is a file in Solana. Programs are files. Programs store data in files. Every user account has an associated file. Didn’t we just say above that programs are stateless? Well, the executable files are stateless, but the files they store data to are not.
Ethereum can grow arrays and mappings without limit (as long as you can afford the gas fee). Solana files cannot exceed 10 MB. If you need to store more than that, your architecture needs to create more files.
Here’s a surprising one: programs are not immutable by default. To upgrade smart contracts in Solidity, you need to use a proxy pattern to delegate calls to a new smart contract. In Solana, you just upload a new file to the same spot! Solana does allow for files to be immutable, but you must explicitly designate it so upon deployment. This means you can’t rely on smart contracts you interact with to not change their behavior.
When making a call to a Solana program, you have to tell it in advance which files it’s going to access. If the program tries to access a file that wasn’t designated in advance, then the execution will fail. This might seem like a strange requirement, but this allows the Solana runtime to pre-fetch the files and thus run faster.
In Ethereum, you can simply use the web3.js or ethers.js library to invoke a function that looks like the one in your smart contract (Solidity does have an uncanny resemblance to javascript). In Solana, “function” arguments are passed as byte arrays.
By the way, we’ve been using the world “file” but Solana calls them “accounts” which is very confusing. Accounts only have a weak relationship with the traditional blockchain notion of an account. Accounts are files and files are accounts on Solana.
This is not a complete list!
The journey of most Ethereum developers is to play around in Remix to build tokens, then migrate to building websites and developing the smart contract in hardhat or foundry.
If you directly start writing contracts in rust, you’re going to have a bad time.
Don’t touch Rust yet: learn Solana web3 js first
Although Solana does have a remix-like ide beta.solpg.io, it’s not as seamless as entering your function arguments in and clicking “execute.”
All Solana invocations must be done though the RPC, which is typically handled by Solana web3js. Unless you are handy with this library, you won’t be able to execute your smart contracts.
Get comfortable with creating accounts using Solana web3js. Get comfortable transferring Sol. Get comfortable invoking programs you didn’t write. Get comfortable encoding the program parameters and specifying which accounts (files) the program will access. Get comfortable interacting with Solana’s ERC20 and ERC721 equivalent through the Solana web3js library.
Then when it comes time to testing your own contracts, you won’t spend an extra hour trying to debug the test rather than the contract.
Get comfortable with Rust on easy leetcode-like problems before writing smart contracts
Rust has some strange syntaxes that are off-putting at first, but in reality are not hard to read if you’ve been using the language for some time. Trying to learn Rust and Solana smart contract programming at the same time is going to create a lot of distractions that slow you down. If you are determined and have a lot of time, I think most programmers can get “good enough” with rust after two weeks.
Trust me, you don’t want to learn how to fight the borrow checker and write smart contracts in an unfamiliar environment at the same time.
Skip the parts of rust that aren’t immediately relevant, especially concurrent programming. The benchmark I use is that if you can solve easy leetcode questions with the traditional and basic data structures, you are ready. Don’t try to master the entire Rust language. Just enough so you feel comfortable with doing basic things. After all, smart contracts tend not to be complicated.
Write programs without the anchor framework first, then use Anchor
Obviously, the anchor framework exists for a reason, so get comfortable with it. But having written programs without it, you’ll be able to understand the motivation behind the syntactic sugar and “magic” that happens at various points. Remember how everything is a file? If you want to store variables statelessly, they all need to lay out the variables end-to-end in the account. Borsh serialization library handles this for you, but you need to be comfortable using it before delegating the hard work to magic attributes.
Build simple web-apps with Solana web3js
Up until this point, you’ve been executing javascript or typescript files to trigger your smart contracts. This if of course not the end goal. Transitioning from executing scripts to moving it to the browser is not too hard, but a few things change. In scripts, you have access to the private keys, in the browser, you must go through the wallet (like Phantom) API. If you are not a front-end developer by training (many of the students at RareSkills come from backend), then making the frontend work is going to be another source of distractions that slow you down. So we recommend saving it for the end so it’s own source of problems can be dealt with in isolation.
Conclusion
Solana has a lot of separate parts that the programmer needs to be proficient with before they can do something useful. The strategy recommended here is to break down the parts into sensible partitions, get “good enough” at each aspect without being distracted by the other aspects, then bring them together at the end. Trying to learn two things at the same time is slower than learning them individually in a sensible order.
Top comments (0)