Skip to main content

Solana

Solana is a “high performance” network with roots in finance, smart contracts and NFTs. Solana has roots in other areas like gaming, but those won’t be covered in this guide.

Core Concepts

Solana runs on the following core concepts:
  1. Accounts
  2. Transactions
  3. Programs (smart contracts)

Accounts

In Solana, accounts are used to store data. Each account has a unique address which can be used to access the stored data. There are 3 types of accounts:
  1. Data accounts - they store data.
  2. Program accounts - they host program code
  3. Native accounts - native Solana programs, eg. the System account which is responsible for creating all accounts.
An account in Solana is like a file in a normal operating system, and it can contain any data as defined by a program. The account you create via a wallet is categorized as a data account owned by the System program. An account hosting your program code is a program account owned by you (your account). An account stores data that looks like this:
A lamport is the smallest unit of SOL (1 SOL = 1 billion lamports) [Accounts - Solana Cookbook] | [Accounts - Solana Docs]

Programs

A program is a smart contract running on the Solana network. Programs do not store data themselves, instead they store data in acccounts.

How Solana Handles Nonces

Contrary to other networks like Ethereum, Solana does not use an integer nonce. Instead, a recent block hash is used to invalidate old transactions (those signed more than 150 blocks ago). While this works well for most cases, it makes signing offline transactions impossible. Enter durable nonces. Durable nonces are 32-byte base58 encoded strings used in place of the recent block hash when signing a transaction. Durable nonces can only be advanced by broadcasting a transaction instruction to advance it. When signing a transaction using durable nonces, the first instruction is supposed to be the advance nonce instruction. How do they work? Durable nonces requires a separate nonce account which stores the current nonce value. The account can be created using the @solana/web3.js sdk as shown here. While durable nonces fix the initial problem of offline transactions, since these nonces are strings, we can’t advance them locally and thus we lose the ability to sign multiple offline transactions at the same time using nonces. Since a transaction needs to be broadcasted to advance the nonce, signing multiple transactions using a durable nonce would use the same value for all transactions causing only the first to be valid. [More on Durable Nonces]

Setting up your wallet

Install the Phantom wallet extension to create a new wallet. Then export your Solana secret key by going to Settings > Manage Accounts > {Wallet Name} > Show Private Key. Airdrop some test SOL from the Solana Faucet for testing.
The testnet faucet is empty (at the time of this writing), so you might need to use the devnet.

Using the Sdk

The solana sdk provides a utility function to get the rpc url.

Connecting your wallet

Pass the base58 representation of your private key to .connectWallet:
On the browser, you can also try to connect to the Phantom browser extension by calling .connectWallet without any argument.

Sending SOL

The signed transaction is a serialized form of itself (Uint8Array) that can now be sent to a DEMOS node for broadcasting.

Multi token send

The signed transactions will be signed using the recent block hash and therefore are only valid for the next few minutes.

Signing messages

Programs

To execute a program on solana, you need to have its address (program Id) and IDL. On Solana, an IDL (interface definition language) is what an ABI is to an EVM smart contract. It is a programs’s public interface. It define its methods, inputs and types.

When the IDL is available

Here’s an example IDL of a program running on the Solana Mainnet: https://explorer.solana.com/address/MarBmsSgKXdrN1egZf5sqe1TMai9K1rChYNDJgjq7aD/anchor-program
You can use the IDL to collect and convert user input to the type specified in the IDL.

The structure of the IDL

A typical IDL looks like this:
The instructions are a list of the methods defined on the program. An instruction can require arguments which are declared on the args property. When the instruction is reading data or modifying dadta, the data account’s address is needed. If data is being modified, the private key of the account’s owner is required to sign the transaction. You can determine the number of signers required by checking how many accounts have a isSigner flag. Invoking a program:
After broadcasting the transaction to the network, you can await its confirmation and then read an account data.
The IDL and accountName are needed to deserialize the account data

When the IDL is not available

When you don’t have the IDL, you need to know:
  1. The name of the instruction
  2. The index of the instruction on the program definition
  3. The proper format and type of the instruction parameters
  4. The accounts needed
  5. The signers needed by the instruction.
With all that in place, you can do the following:

Resources

  1. The Solana Cookbook
  2. The Solana Program Library
  3. ANCHOR - Solana Sealevel Framework
  4. Javascript Client
  5. Known Programs [Github]
  6. Interacting with Custom Programs

API Reference

https://kynesyslabs.github.io/demosdk-api-ref/classes/xmwebsdk.SOLANA.html