14 min read

What is Web3?

Web3 represents the third era of the web. While the early internet (Web1) gave us static pages and read-only content, and Web2 brought us interactive social media platforms and user-generated content, Web3 pushes the boundaries further. It is the decentralized web. Powered by blockchain technology, Web3 offers a platform where users have direct control over their data, assets, and transactions without intermediaries.

Web3's backbone is a technology known as blockchain. At its core, a blockchain is a distributed ledger or database maintained across multiple computers (often called nodes) linked in a peer-to-peer network. Each piece of data, called a block, is chained to the previous one, ensuring transparency and security. This decentralized nature means no single entity has control, making it resistant to censorship and centralized authority. Instead of relying on a central point of verification, like a bank in financial transactions, blockchain employs consensus algorithms to validate and record data in a nearly tamper-proof way. As the foundational technology behind cryptocurrencies like Bitcoin and Ethereum, blockchain is revolutionizing how we think about trust, value, and data ownership in the digital age.

Just as many from our community embraced the earlier evolutions of the web, Web3 is catching the attention of developers and enthusiasts worldwide. With its promise of more transparent, secure, and user-centric online interactions, Web3 is not just a buzzword—it's the next phase of the internet's evolution.

What is Solana?

Solana is a high-performance blockchain platform known for its speed, scalability, and low transaction costs. Unlike some of its counterparts, Solana can process thousands of transactions per second, making it an ideal choice for developers aiming for efficient decentralized applications and crypto projects.

The rise of Solana can be attributed to its unique architecture and innovative solutions that address some of the most pressing challenges in the blockchain world. Solana's architecture is based on a Proof-of-History (PoH) consensus mechanism, which enables the network to process transactions in parallel rather than sequentially. This approach allows Solana to achieve high throughput without compromising security, decentralization, or cost.

If it helps, think of Solana as a global computer (or state machine) that anyone can use. Developers can build and deploy programs onto the Solana Virtual Machine (SVM) and interact with them through Decentralized Applications (also known as "Dapps"). These Dapps can be anything from a simple game to a complex financial application. The possibilities are endless! Solana's native token, SOL, is used to pay for transaction fees and storing data on the network (almost like paying to lease space on a network drive). SOL is also used to reward validators for securing the network and processing transactions.

Throughout this lesson, you'll delve deep into the world of Solana, understanding its key features, benefits, and why it's rapidly gaining traction in the decentralized tech space. Embark on this exciting journey with us and discover Solana's endless possibilities in the Web3 landscape!

Let's get started!

Accounts

One of the most important concepts to understand when building on Solana is the concept of accounts. Accounts are the fundamental building blocks of the Solana blockchain. Like files in an operating system, accounts are used to run the system, store data or state, and execute code.

There are three main types of accounts on Solana:

1. Data accounts that store information and manage the state of the network. There are two types of data accounts:
   • System-owned accounts (most commonly recognized as wallets--among other things, the data stored in these accounts is the amount of SOL in the account).
   • Program-derived accounts (often referred to as PDAs) - a common example is a user's token account for a specific token. The Solana SPL Token Program derives it. PDAs store any kind of state data that is defined in a program.
2. Program accounts that hold executable code. This code defines instructions for processing data and updating the network's state. We will discuss these in the following section, but these accounts are stateless (meaning data passes through them but does not update them).
3. Native System Accounts (e.g., System Program, Voting, Staking, BPF Loader) that are used to run the network the network.

In short, almost everything on Solana is an account. Every account has a unique address, or public key (much like a file path), and a set of associated metadata:

Property	Description
lamports	The number of lamports owned by this account (64-bit unsigned integer)*
owner	The program owner this account is assigned to (string address of the owner Program)
executable	Whether this account can process instructions (boolean). An account with an executable value of true is actually a Program (or Smart Contract)--we will discuss these in the next section.
data	Any additional data associated with the account, stored as a raw data byte array
rent_epoch	The next epoch that this account will owe rent (64-bit unsigned integer)

* lamports are the smallest denomination of SOL, Solana's native token (representing one billionth of one SOL)

Let's visualize an example of all of the account types:

A lot is happening here, but everything you see in this figure is an Account. On the left-hand side, we have a System Account called System Program governing all of the user wallets. We also have an executable Program Account, called Solana SPL Token Program, that users can use to mint, burn, and transfer SPL tokens. Finally, we have Program Derived Accounts. In this case, token accounts are owned by the Token Program and associated with a User's Account. Notice how one user wallet can have multiple token accounts.

Lamports and Rent Epoch Accounts and account data are stored in the validator's memory and are required to pay "rent" in lamports (denoted in the accounts lamports metadata field) to remain there. The more data stored in your account, the more rent required (note: the current maximum account size is 10-MB). Validators are responsible for periodically scanning all accounts and collecting rent--accounts are checked on the epoch identified in the rent_epoch metadata field. If an account drops to a zero-lamport balance, the network will purge the account, and the data will be lost. At the time of this writing, all new accounts are required to maintain rent-exempt status, which is granted by holding 2-years' worth of rent in the account. Source: https://docs.solana.com/developing/programming-model/accounts Epochs are a measure of time on Solana, currently representing about 2.5 days.

Keypairs and Wallets

A keypair is composed of two intertwined elements:

1. Public Key (or Address): This is a unique identifier for an account, similar to an account number in traditional banking. It's visible to everyone on the network and is used to receive transactions (like sending and receiving tokens).

2. Private Key: This is a secret key known only to the account's owner. It is used to sign transactions, essentially providing a digital signature to prove the authenticity of a transaction. Without the private key, one cannot authorize actions associated with the public key.

Solana uses the Ed25519 cryptographic signature scheme for key generation and signing.

A wallet in the Solana ecosystem is essentially a user-friendly interface for managing one's keypairs. Think of it as a digital interface to access and manage your assets on the blockchain, safeguarded by your private key. Every time you initiate a transaction from your wallet, it uses the private key to sign the transaction, proving that it comes from you. We will talk more about signing in subsequent sections.

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." (Source: docs.solana.com/terminology).

An instruction consists of 3 parts:

1. The Public Key of the Program that you will be invoking,
2. An array of Accounts that the instruction will read or modify, and
3. A byte array of any additional data that is necessary for the program's execution

Instructions are program-specific. The transaction will fail if you enter the wrong program ID or do not know the expected data structure to pass into the program.

In JavaScript, a transaction instruction looks something like this:

  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),
  })

It is worth mentioning here the Account information required for a Transaction Instruction. We must provide the public key of every account involved in the instruction, whether or not that account is a signer on the transaction, and whether the account will be written as a part of the transaction (this helps contribute to Solana's ability to execute quickly). In the example above, a user signs the wallet, and data is written to a PDA. It's commonly necessary to include system program accounts as well (e.g., for creating a new account). Finally, we pass SOME_ENCODED_DATA. The type of data required is defined inside the program. The program must deserialize the input data to process it correctly.

Transactions

Transactions are the means of delivering instructions to a program on the network. Transactions can package multiple instructions together for processing multiple operations atomically. For example, imagine an instance when you have three different instructions: an instruction for Wallet A to send Wallet B 1 $SOL, an instruction for Wallet B to Send Wallet A 33 $USDC, and an instruction to log a memo to the transaction that states "Wallet A Swap 1 $SOL for 33 $USDC with Wallet B on YYYY-MM-DD." Though those could each be sent to the network separately, what would happen if one instruction failed but the others succeeded? You could have a scenario where one person got their tokens and another did not. By bundling instructions into a package, we can ensure that all of our transactions succeed or fail together.

Transactions are currently limited to 1,232 byes. 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 subset of the accounts we pass into our transaction must also include a signature. "Those signatures signal on-chain programs that the account holder has authorized the transaction. Typically, the program uses the authorization to permit debiting the account or modifying its data." (Source: docs.solana.com). For example, this could also be necessary for a creator to verify that an NFT is genuine.
• a recent blockhash: a blockhash is basically a PoH timestamp. Solana, by default, drops "old" transactions to prevent double counting, to allow validators to only check transactions against a very recent batch, and to give users quick certainty if their transaction has been processed (or failed so that they can try again). Fetching a recent blockhash before submitting a transaction allows the network to know the age of our transaction and when it should expire (if ever needed).

Once the network receives a transaction, it returns a transaction ID (base-58 encoded string), which can be used to look up the transaction details.

Let's discuss how to get your transaction to the network!

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

We will also discuss later how you can run your own local cluster for development purposes.

Clients can make read or write requests to any of the three clusters using JSON-RPC requests through a Solana node. Nodes kind of act as "air traffic control" for handling requests to the network. 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);

In the sample above, HTTP_ENDPOINT is an HTTP URL that points to a Solana node that will ultimately route your request to one of the three clusters.

Every request requires an API endpoint to connect with the network. This is where Quicknode comes in! Head over to your Quicknode Dashboard to get your HTTP endpoint--this is kind of like your API key to the Solana network.

Simply sign in and update the HTTP_ENDPOINT in your app with the one provided in your account dashboard, and you are good to go!

Once you have established a Connection to a Solana cluster, you can perform many read or write methods to the network. A complete list of RPC methods and documentation is available on Quicknode Docs. Though every method has its purpose, a few that are relevant to the discussion so far in this guide are:

• sendTransaction - sends a Transaction to the Solana network
• getAccountInfo - fetches metadata associated with any Account
• getLatestBlockhash - returns the latest blockhash from the network

We will cover these and many others throughout this course.

HTTP calls allow us to tell the network to do something (e.g., process a transaction and its instructions, return current state information about an account, etc.), but what if we want the network to alert us about changes to an account state?

Subscriptions

Subscriptions are a special kind of RPC request where we make a WebSocket (WSS) request instead of an HTTP endpoint. Solana Web3 JSON RPC includes several subscription methods (e.g., accountSubscribe, which will listen for changes to an account's lamports or data). We can then subscribe to these events with a callback function, allowing some desired action to happen whenever the network changes.

The Connection class constructor allows us to pass an optional commitmentOrConfig. Within it, we can pass a wsEndpoint. This is an option for you to provide an endpoint URL to the full node JSON RPC WebSocket Endpoint. If you have created a Quicknode Endpoint, you should see this option on the right side of your endpoint's page.

const HTTP_ENDPOINT = 'https://example.solana-devnet.quiknode.pro/000/';
const WSS_ENDPOINT = 'wss://example.solana-devnet.quiknode.pro/000/'; 
const solanaConnection = new Connection(
  HTTP_ENDPOINT,
  { wsEndpoint: WSS_ENDPOINT }
);

What happens if you don't pass a wsEndpoint? Well, Solana accounts for that with a function, makeWebsocketUrl, that replaces your endpoint URL's https with wss or http with ws (source). Because all Quicknode HTTP endpoints have a corresponding WSS endpoint with the same authentication token, it is acceptable for you to omit this parameter unless you would like to use a separate endpoint for your Websocket queries.

We won't do too much with WebSockets in this course--to dive deeper into creating WebSocket subscriptions, check out our Guide: How to Create Solana WebSocket Subscriptions.

Explorers

Solana is a public blockchain, meaning anyone can view the data on the network. There are several ways to view the data on the Solana blockchain, but the most common way is through an Explorer. An explorer is essentially a database GUI that allows you to view the data on the blockchain. There are several different Explorers available, but we will predominantly use Solana Explorer in this course. Solana Explorer is maintained by Solana Labs and has some features that will help in your development journey. We have included a list of some other Explorers in the (Resources) section below.

We will use Solana Explorer a lot during this course. Let's take a moment to familiarize ourselves with the interface. Head to https://explorer.solana.com/:

There are a few essential elements that we want to point out:

1. Search Bar: - allows you to search a given account, transaction, block, program, or token.
2. Network Stats: - provides a high-level overview of the state and health of the network, including the current block height, slot, epoch, and live transaction stats.
3. Network Selector: - allows you to select the cluster (or network) you want to view/query. On click, you will be prompted to select 'Mainnet', 'Testnet', 'Devnet', or a custom cluster (we will use this later for local development):

Block View

You can search in the Explorer to view details of any given Block. Try, for example, searching "224911320". You should be directed to the page for slot # 224,911,320. This will yield information such as date/epoch information, the blockhash, validator rewards, programs/accounts used, and the number of transactions in the block (and links to each). You can also view the transactions in the block by clicking the "Transactions" tab.

Account View

You can search in the Explorer to view details of any given Account. Try, for example, searching "E645TckHQnDcavVv92Etc6xSWQaq8zzPtPRGBheviRAk". You should be directed to the account page for that wallet address. You should see basic account balance and other metadata (e.g., executable, owner program, etc.). You will also see a transaction history for the account:

Transaction View

Similarly, you can search for a transaction hash to get details about a given transaction. Try searching "2SJQRxh6nsgZPV6hvTQZS2CdsBY7dCeZX5hoQJpZWiFbWb37Rf432GUNhmMFpc91b8vmcPhSoxDJ3p2WFC3bzdTA". You should be taken to the transaction details page for that transaction. You will see details about the transaction, including the block it was included in, the accounts involved in the transaction, the instructions, changes in account balances, the signatures, and any program logs. This transaction includes a small transfer of SOL from one account to another:

Pull it All Together

Okay! That's a lot of information--you have probably started to see some connective tissue between these primitives, but 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 of the program that we will build together. Imagine a Program called "Tic Tac Toe" that tracks the number of wins a user has (our program will do more than this, but this is an example for illustrative purposes).

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 Tic Tac Toe 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 user's win count. A subscription created by the client listens for changes to the user's PDA; then, the network alerts the client that the account has been changed.

Knowledge Check

Whew! That was a lot of information. Don't worry; we will get our hands dirty next lesson and start building! Before moving on, let's take a moment to test your knowledge.

Sign in to track your course progress and interact with quizzes

Create a free Quicknode account to save your progress, complete knowledge checks, and mark lessons complete.

Create AccountSign In

Resources

• Solana Fundamentals Reference Guide
• Solana Cookbook
• Solana Homepage
• Explorers:
  • Solana Explorer
  • SolScan
  • SolanaFM
  • Solana Beach
  • Xray
  • Guide: Create Your Own Solana Explorer