Update - 12/18/20

ref: solana docs and helpful articles from solong


With solana "smart contracts" are called programs. I think this makes sense because the idea of a smart contract has a lot of baggage and maybe limiting in scope from the ethereum implementation.

I'm only a little familiar with the smart contracts, so I'm approaching solana program development as a novice.

I'm still fuzzy on how the following items interact. Here's me thinking out loud while reading solana docs:

  • Transactions - so transactions outside of their obvious function encapsulate instructions
  • Accounts - encapsulate programs and serve as the inputs and outputs of the program, so they essentially serve as a way to address and interact with a deployed on-chain program
  • Programs - programs essentially hang out in state, on chain, once deployed, they're kept alive by the accounts that own them and pay rent for them
  • Instructions - instructions are txns and data that gets sent to on-chain programs, so an instruction is essentially a call to an existing program

Program development lifecycle:

  1. write/edit your program in rust (or c++)
  2. build and test by deploying to localnet (you need to use the custom bpf builder to build your program), iterate back to 1 as necessary
  3. deploy program to devnet, test with instructions or the app you're making in parallel, iterate back to 1
  4. deploy program to mainnet once testing/development is complete

...the BPF thing

So your program gets compiled to or using BPF (Berkeley Packet Filter) which I don't really know what it is yet. But it's used in the context of Solana to help with high performance transaction processing by validators from what I understand. From what I've read, the linux and container communities are excited about it. I may be wrong but I think BPF allows high-level instructions to be passed to the linux kernel more easily which results in higher performance, but I could be wrong.


Clusters are instances of solana protocol based networks. Like mainnet, testnet etc...

As a developer you will interact with the following network instances:

  • local: a cluster running on your computer, good for live development, is included in the solana primary repo
  • devnet: good first remote deployment target for a program, once things seem to be working locally with your program next step would be devnet
  • mainnet: I think mainnet would theoretically be your next step once you've fully developed and tested on devnet, obviously everything here is live with 'real money' so you'll need to spend whatever amount of sol your program needs to run
  • testnet: testnet is more of a test environment for the protocol than for your own programs, new versions of solana are tested on testnet, so if there were features your program relied on maybe you would want to test here first prior to deploying to mainnet