What Happens When You Interact with an App on a Blockchain?

The digital economy is rapidly migrating and growing on blockchains. Soon, the Internet will live on the blockchain. Every app will be built on blockchain rails and all online activities will be done on the blockchain. This is the future of the digital economy so it might make sense to have a little bit of understanding about how it all works, don't you think? A lot of people already use blockchain applications, but very few understand the flow of things. You can't blame them. No one wants to burden themselves with the technicalities of these things. As long as it works, that's enough. But the thing is, the blockchain exists to eliminate the middlemen in traditional institutions, and give you control over data, finances and content. having this responsibility makes knowing a little bit about how stuff works under the hood very crucial. This is why I felt it was necessary to draw your attention to and explain the typical transaction flow when you interact with an application on the blockchain. But first, let's explain some terms you've probably heard or come across in your crypto journey but don't really know what they mean: Layer-1 (L1) - Main blockchain. Layer-2 (L2) - a mini blockchain built on top of an existing L1 to help improve the scalability and efficiency of the L1 without compromising on the security of the L1. If L1 is a busy main highway, L2s are additional express lanes that help relieve traffic congestion on the L1. Transactions on the L2s are ultimately secured by the L1. Sequencer - a sequencer is typically associated with L2s. Its primary responsibility is to order transactions submitted by users before they are processed and added to the main blockchain. Think of it like a traffic controller for transactions. Instead of every transaction individually trying to get onto the main road (L1), the sequencer gathers them, organizes them into a more efficient convoy, and then sends them onto L1 in a batch. Receive transactions — Order — Execute — Batch — Submit to L1 Sequencers are used by L2s to enable them process more transactions fast and at reduced costs. Validator - A validator is a participant in a blockchain network that is responsible for verifying and confirming transactions, and adding new blocks to the blockchain. RPC Node - An RPC (Remote Procedure Call) acts as an intermediary that allows the user's application to send requests (like submitting a transaction or querying data) to a blockchain node without needing to directly understand the underlying complex network protocols. Blockchain apps typically communicate with the blockchain infrastructure through an RPC. The RPC node receives these requests and relays them to the appropriate part of the blockchain network. Full Node - A full node is a program that fully validates transactions and blocks on a blockchain. It holds a complete copy of the blockchain's history. On L1: Full nodes are essential for the security and decentralization of the main blockchain. They independently verify every transaction and block against the network's consensus rules. They also relay transactions and blocks to other nodes in the network. RPC nodes are often run on top of full nodes to provide the API (Application Programming Interface) for applications to interact with the blockchain data. On L2 (with a sequencer): Full nodes might also exist. They can track the state of the L2, and verify the batches submitted by the sequencer to L1. Now that we have the basics down, let's walk through what happens when you interact with an application on a blockchain. In a typical L2 scenario, say you wanted to swap some tokens on a decentralized exchange (DEX) on Arbitrum: Once you interact with the dApp (say click “swap”), your transaction is sent via an RPC to a node on the L2. This node submits the transaction to the sequencer. The sequencer orders the transaction, executes it, and batches it with other transactions. The sequencer then submits this batch (along with data or proofs) to the L1 blockchain. Full nodes on L1 receive this batched transaction. Validators on L1 process the batch according to the L1 consensus rules, ensuring its validity and adding it to the L1 blockchain, thus providing finality (transactions can't be reversed) to the L2 transactions. Full nodes on both L1 and L2 can be queried via RPC to retrieve information about the state and history of the respective chains. Okay, but what does this flow look like directly on the L1 blockchain? Assuming you're interacting directly on an L1 like Solana directly, this is what it looks like: Just like on an L2, when you interact with an app, the app sends the transaction to an RPC node connected to the L1 network. This RPC node acts as the entry point for your request. The RPC node receives the transaction and then propagates it to other nodes (including full nodes and validators) across the L1 network. This ensures that multiple participants in the netwo

Apr 24, 2025 - 15:07

What Happens When You Interact with an App on a Blockchain?

The digital economy is rapidly migrating and growing on blockchains. Soon, the Internet will live on the blockchain. Every app will be built on blockchain rails and all online activities will be done on the blockchain. This is the future of the digital economy so it might make sense to have a little bit of understanding about how it all works, don't you think?

A lot of people already use blockchain applications, but very few understand the flow of things. You can't blame them. No one wants to burden themselves with the technicalities of these things. As long as it works, that's enough. But the thing is, the blockchain exists to eliminate the middlemen in traditional institutions, and give you control over data, finances and content. having this responsibility makes knowing a little bit about how stuff works under the hood very crucial.

This is why I felt it was necessary to draw your attention to and explain the typical transaction flow when you interact with an application on the blockchain. But first, let's explain some terms you've probably heard or come across in your crypto journey but don't really know what they mean:

Layer-1 (L1) - Main blockchain.
Layer-2 (L2) - a mini blockchain built on top of an existing L1 to help improve the scalability and efficiency of the L1 without compromising on the security of the L1. If L1 is a busy main highway, L2s are additional express lanes that help relieve traffic congestion on the L1. Transactions on the L2s are ultimately secured by the L1.
Sequencer - a sequencer is typically associated with L2s. Its primary responsibility is to order transactions submitted by users before they are processed and added to the main blockchain. Think of it like a traffic controller for transactions. Instead of every transaction individually trying to get onto the main road (L1), the sequencer gathers them, organizes them into a more efficient convoy, and then sends them onto L1 in a batch.

Receive transactions — Order — Execute — Batch — Submit to L1

Sequencers are used by L2s to enable them process more transactions fast and at reduced costs.

Validator - A validator is a participant in a blockchain network that is responsible for verifying and confirming transactions, and adding new blocks to the blockchain.
RPC Node - An RPC (Remote Procedure Call) acts as an intermediary that allows the user's application to send requests (like submitting a transaction or querying data) to a blockchain node without needing to directly understand the underlying complex network protocols. Blockchain apps typically communicate with the blockchain infrastructure through an RPC. The RPC node receives these requests and relays them to the appropriate part of the blockchain network.
Full Node - A full node is a program that fully validates transactions and blocks on a blockchain. It holds a complete copy of the blockchain's history.
- On L1: Full nodes are essential for the security and decentralization of the main blockchain. They independently verify every transaction and block against the network's consensus rules. They also relay transactions and blocks to other nodes in the network. RPC nodes are often run on top of full nodes to provide the API (Application Programming Interface) for applications to interact with the blockchain data.
- On L2 (with a sequencer): Full nodes might also exist. They can track the state of the L2, and verify the batches submitted by the sequencer to L1.

Now that we have the basics down, let's walk through what happens when you interact with an application on a blockchain.

In a typical L2 scenario, say you wanted to swap some tokens on a decentralized exchange (DEX) on Arbitrum:

Once you interact with the dApp (say click “swap”), your transaction is sent via an RPC to a node on the L2.
This node submits the transaction to the sequencer.
The sequencer orders the transaction, executes it, and batches it with other transactions.
The sequencer then submits this batch (along with data or proofs) to the L1 blockchain.
Full nodes on L1 receive this batched transaction.
Validators on L1 process the batch according to the L1 consensus rules, ensuring its validity and adding it to the L1 blockchain, thus providing finality (transactions can't be reversed) to the L2 transactions.
Full nodes on both L1 and L2 can be queried via RPC to retrieve information about the state and history of the respective chains.

Okay, but what does this flow look like directly on the L1 blockchain?

Assuming you're interacting directly on an L1 like Solana directly, this is what it looks like:

Just like on an L2, when you interact with an app, the app sends the transaction to an RPC node connected to the L1 network. This RPC node acts as the entry point for your request.
The RPC node receives the transaction and then propagates it to other nodes (including full nodes and validators) across the L1 network. This ensures that multiple participants in the network are aware of the pending transaction.
Each full node on the L1 maintains a transaction pool (also known as a mempool). This is where unconfirmed transactions wait to be included in a new block.
Validators are then selected to propose the next block of transactions.
The selected validator chooses a set of transactions from the mempool to include in a new block. The validator orders these transactions within the block. On L1, the ordering is done directly by the proposer of the block, not a separate sequencer.
The newly proposed block is then broadcast to the rest of the network.
Other full nodes and validators independently verify the validity of the block and the transactions within it according to the L1's consensus rules. This includes checking signatures, account balances, and the correctness of state transitions.
The network then reaches consensus on whether to accept this new block as the latest addition to the blockchain.
Once a sufficient number of subsequent blocks have been added to the chain after the block containing your transaction, the transaction is considered finalized (it can't be reversed). The exact number of confirmations required for finality varies depending on the L1 blockchain.
As each valid block is added to the chain, the global state of the L1 blockchain is updated to reflect the changes caused by the transactions in that block (e.g., updated account balances, contract storage).
Just like on L2, full nodes on L1 maintain the entire history and current state of the blockchain. Apps can query these full nodes via RPC to retrieve information about account balances, transaction history, smart contract data, and the overall state of the L1.

Here are some key differences here compared to what happens on an L2:

On L1, there isn't a dedicated "sequencer" that orders transactions before they reach the main chain. The ordering is done by the block proposer (validator) as part of the block creation process.
Transactions are directly submitted to the L1 network and propagated among nodes, rather than being first aggregated and ordered by a sequencer.
All transaction execution and validation happen directly on the L1 by all participating full nodes and validators. In L2s, much of the execution and initial validation usually happens off-chain by the sequencer, with only the final batched result being verified on L1.

In essence, on an L1, every transaction individually goes through the entire process of propagation, validation, and inclusion in a block that is agreed upon by the entire network. L2s, on the other hand, offload much of the processing and ordering to a separate entity (the sequencer) and then submit a summary of these transactions to the L1 for finality.

Hope this was helpful.