In this blog, we will cover the basic building blocks of Solana, specifically: Accounts, Programs, Instructions, Transactions, RPCs, and Subscriptions.

What is Solana?

• Solana is an open-source blockchain optimized for speed and cost, allowing information and state to be globally synchronized.

• Solana utilizes a unique version of Proof of Stake consensus called Proof of History, which uses a granular verifiable delay function to effectively timestamp and order transactions sent to the network.

Building blocks of Solana

Accounts

Like files in an operating system, accounts are used to run the system, store data or state, and execute code.

• 3 main types of accounts on Solana

  • Data accounts (2 types)

    1. System-owned acocunts (most commonly recognized as wallets)

    2. Program-dereived accounts (often referred to as PDAs)

  • Program accounts

    • Hold executable code

    • Stateless (meaning data passes through them but does not update them)

  • Native System Accounts

• Every account has:

  • a unique address, or public key

  • a set of associated metadata

    • lamports

    • owner

    • executable

    • data

    • rent_epoch

Programs

• Programs are what Solana calls Smart Contracts--they are the engine that handles information and requests.

  • programs are stateless accounts flagged as "executable”

  • Programs can use "Cross-Program Invocation" to use or build upon other Solana Programs. This is often referred to as composability.

  • Unlike many other popular chains, programs are upgradeable.

  • Most Programs are user-generated, but Solana Labs has built and maintains a number of on-chain programs known as the Solana Program Library.

Program Derived Address Accounts

• A Program Derived Address (PDA) is an account created and controlled by a specific program. PDAs:

  • Allow programs to control specific addresses, called program addresses, so no external user can generate valid transactions with signatures for those addresses.

  • Allow programs to programmatically sign for program addresses that are present in instructions invoked via Cross-Program Invocations. Solana deterministically derives PDAs based on seeds defined by the program and the program ID. More information about generated Program Addresses can be found at docs.solana.

Instructions

• Instructions, at their core, tell a Program to do something. Solana defines instructions as "The smallest contiguous unit of execution logic in a program."

  • An instruction consists of 3 parts:

    1. The public key of the program that you will be invoking,

    2. An array of Accounts that it will read or modify,

    3. A byte array of any additional data that is necessary for the program’s execution (program-specific)

  • Transaction instruction example in Javascript:

      new TransactionInstruction({
        programId: new PublicKey(PROGRAM_ID),
        keys: [
            { pubkey: signerKeypair.publicKey, isSigner: true, isWritable: true },
            { pubkey: pda, isSigner: false, isWritable: true },  
            { pubkey: SystemProgram.programId, isSigner: false, isWritable: false }      
        ],
        data: Buffer.from(SOME_ENCODED_DATA),
      })
    

Transactions

• Transactions are the means of delivering instructions to a program on the network.

• Transactions can package multiple instructions together for processing multiple operations simultaneously.

• Each transaction must include the following:

  • an array of one or more transaction instruction

  • an array of all account addresses the program will be interacting with

  • an array of signatures

  • a recent blockhash: a blockhash is basically a PoH timestamp.

RPC

JSON-RPC is a Remote Procedure Call protocol encoded in JSON that enables users to send information to a Solana cluster and get a response from the network.

• Solana currently maintains three network clusters:

  • Devnet: a playground to test the functionality of applications and methods

  • Testnet: a development environment used to stress test all of the latest planned upgrades to the system

  • Mainnet Beta: production environment

• Clients connect to Solana nodes through the Solana Web3 Connection class:

  const HTTP_ENDPOINT = 'https://example.solana-devnet.quiknode.pro/000/';
  const SOLANA_CONNECTION = new Connection(HTTP_ENDPOINT);
  

Subscriptions

Subscriptions are a special kind of RPC request where we make a WebSocket (WSS) request instead of using an HTTP endpoint.

Pull it All Together

let's do a quick recap before connecting all of the pieces together:

• Almost every on Solana is an Account: user wallets, programs, system programs, program data, etc.

• Programs are stateless--they process instructions and can call other programs and change the state of data accounts they own.

• Instructions are program-specific and tell a program what to do.

• Transactions package one or more instructions with a signature to authorize a program to execute one or more tasks.

• RPC Protocols allow clients to send read/write requests to one of Solana's three clusters through a node, like QuickNode.

• Clients can subscribe to network changes using WebSocket requests through the RPC provider.

Let's walk through an illustrative example. Imagine a Program called "GM" that holds a counter that logs anytime a user sends a "GM" message to the Program.

In the example above, a client creates a Transaction that includes several Transaction Instructions. The instructions are program specific, so they need to match the expected structure of the GM Program. The Client signs and sends the Transaction to a Solana cluster through an RPC provider, like QuickNode, using the Connection class. The RPC provider routes the request to the cluster. The Program account executes and processes the input instructions received. The Program account is stateless and does not change but authorizes a change in the data of the PDA to increment the value of the GM counter. A subscription created by the client listens for changes to the PDA; then, the network alerts the client that the account has been changed.