Begin your Solana journey by evaluating programming fashions of Ethereum vs Solana
When you’re acquainted with Ethereum and Solidity, you could be that means to dip your toes into the Solana ecosystem. Solana’s quick blockchain is promising and thrilling. Plus you improve the floor space of your web3 data.
However should you’ve by no means seen a Solana program, its syntax is freaking scary and the docs appear to be one dev’s repurposed notes. There isn’t a coherence and also you gained’t perceive some elements till later sections.
Because of this I created this “Solana Ramp for Solidity Devs” series for introducing you gently and with out ache and frustration to Solana. The primary article on this collection (this one) is the “Programming mannequin comparability of Ethereum vs Solana” which is actually simply conceptual variations in the way you write a program in ETH vs SOL.
We gained’t go into how Solana works behind the scenes like its proof of historical past, and many others. That is going to be in one other article.
Right here is the define of this text:
- Storing state in Ethereum vs Solana
- Solana accounts
- Program Derived Addresses
In Ethereum, you’re used to storing state proper within the sensible contract itself. Check out this easy contract:
It simply shops one variable
creator and has a helper
publish perform which mutates the
creator variable. You deploy this contract and the code together with its state is saved at one tackle. You should utilize that tackle to check with the contract and browse its knowledge (on Etherscan for instance).
However Solana is totally different.
Solana contracts are stateless. Consider them as simply directions. They don’t retailer any knowledge/state. The place is the information saved then? It’s saved in separate “accounts”. Accounts maintain the information. Once you name a Solana contract’s perform, it is advisable to go within the knowledge to the perform.
publish perform above would require a reference to the account that shops the information. The perform would increment the variety of publications, however the
creator variable would nonetheless be saved in the identical account (not within the contract). The state of the contract didn’t change. When you’re from the Java world, a Solana contract is sort of a static class in Java.
BTW, sensible contracts are referred to as packages in Solana.
Here’s what the straightforward contract above would appear to be in Solana:
Discover how the information is saved in a separate
AuthorAccount and this knowledge is handed in by reference to the
publish perform (by way of
solana_example program doesn’t retailer something by itself. It simply operates on the passed-in knowledge. (
AuthorData is kinda like a wrapper wanted to go within the
AuthorAccount to the
The syntax is freaking scary, I do know. That is Rust and Anchor (Solana framework). It jogs my memory of the times I began iOS growth and encountered Goal C for the primary time. Don’t fear, we’ll take a look at the syntax in additional element within the second article of this series. It should make extra sense, I promise.
Separating the code from knowledge makes it straightforward to improve packages. In Solana, it’s doable to redeploy a brand new model of a program to the identical tackle whereas reusing the identical knowledge account — an improve with out lack of knowledge. (That is a lot more durable to do in Ethereum).
“Account” is an ambiguous phrase. It means a number of issues in numerous contexts. In Solana, an account simply means a storage unit. It’s only a container to retailer arbitrary knowledge.
There are 2 sorts of accounts. First is a “knowledge account” which simply shops knowledge for packages just like the
AuthorAccount that we already talked about. The second kind is a “program account” and is used for “internet hosting” the code of packages. Once you deploy a program on Solana, its code is saved in a “program account”.
An instance: if in case you have a counter program that permits you to increment a counter, you could create two accounts: one account to retailer this system’s code, and one to retailer the counter worth.
Accounts have public keys/addresses so as to have the ability to reference them they usually have personal keys that are utilized in signatures to show authority to change accounts
The phrase “authority” is used quite a bit in Solana world. It simply means the proprietor — the holder of personal keys.
Accounts additionally retailer balances. Solana balances. Solana’s native forex unit is SOL and Lamport (named in honor of Solana’s greatest technical affect, Leslie Lamport). 1 SOL = 10⁹ Lamports. These are analogs of ETH and wei.
So as to create an account, Solana must allocate house on its storage. Storage on Solana will not be free, so creating an account will not be free. It’s essential pay lease to Solana for “internet hosting” your account. However don’t fear. When you deposit 2 years’ value of lease to your account, you’ll be exempt from lease. Everybody simply does that so storage basically turns into free on Solana.
Here’s a abstract of every part saved in a Solana account:
knowledge area both shops the code or arbitrary knowledge relying on whether or not the account is
executable. We are going to speak in regards to the
proprietor area in a bit.
Ethereum additionally has 2 sorts of accounts:
- externally owned — common accounts that may be generated by your pockets (simply have to generate a non-public key, then derive the general public key and tackle, and you’ve got an account). These accounts merely retailer the stability and nonce.
- Sensible contract account — these retailer EVM code and in addition has a storage map that can be utilized for storing arbitrary knowledge.
Here’s what’s saved within the Ethereum account, for comparability:
codeHash is for storing the code and
storageRoot is for storing arbitrary knowledge. For non-executable accounts, the
storageRoot is ready to a particular “null” hash which signifies the account has no storage.
In Ethereum, solely “executable accounts” have storage. However in Solana, all accounts can retailer knowledge. Nevertheless, executable account knowledge is used solely for immutable byte code. All different knowledge is saved in non-executable accounts that are owned by the executable account.
Now, let’s speak in regards to the
proprietor area of Solana accounts.
To make sure that contracts can’t modify one other contract’s state, every knowledge account assigns an proprietor program that has unique management over state mutations. By default, the proprietor program is Solana’s system program (kinda like an Working System).
Nobody apart from the proprietor can modify the state of the information account. Anybody can deposit cash to an account however solely the proprietor can withdraw the stability.
At this level, you know-how packages and accounts work on Solana. However there’s a little awkwardness in Solana that isn’t current in Ethereum.
Think about you deployed a program to Solana and also you additionally deployed a standard web2 frontend to AWS for interacting with this system. Each time you name this system, it is advisable to go within the knowledge account (to change state). It’s essential personal the personal keys of the information account so as to have the ability to change the state of the information account.
The managing of the keys falls on you. The place are you going to retailer it? in web2 servers as atmosphere variables? This isn’t very web3. It might be good to retailer this key in this system itself to make it extra like Ethereum — a method to connect storage to this system.
Program Derived Addresses (PDAs) clear up this.
PDAs basically can help you connect a knowledge storage account to a stateless program account. A method to make Solana Ethereum-like.
How does it work? In this system, you simply generate an tackle from the variables managed by this system. This turns into a derived account (a program-derived tackle). The Solana OS gives a helper perform to derive this tackle.
Extra particularly, PDAs are derived from a program ID and a group of seeds. This system ID is the tackle of the Solana program. The seeds will be chosen arbitrarily by this system (we’ll see the place seeds turn into helpful).
The method is deterministic: the mix of seeds and a program ID is run via a sha256 hash perform to see whether or not or not they generate a public key that lies on the elliptic curve (there’s a ~50% that the ensuing public key will lie on the elliptic curve). If it does lie on the elliptic curve, we merely add one thing to fudge our enter slightly bit and check out once more. The technical time period for this fudge issue is a
bump . In Solana, we begin with
bump = 255 and easily iterate down via
bump = 254 ,
bump = 253 , and many others. till we get an tackle that isn’t on the elliptic curve
What does “lie on the elliptic curve imply”? When a public key lies on the elliptic curve, it signifies that there exists a corresponding personal key that can make the entire private-key-cryptography algorithms work.
There’s a perform referred to as
findProgramDerivedAddress that abstracts away the whole course of.