DEV Community: 1stOnwe

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

1stOnwe — Thu, 24 Apr 2025 13:41:35 +0000

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.

I Compared Four API Docs. Some Made Me Smile, Some Made Me Sigh

1stOnwe — Thu, 24 Apr 2025 01:08:11 +0000

So, I've been neck-deep in API documentation lately—part of my whole technical writing journey. I figured, why not check out some notable players and see who's doing it right (and who's making life harder than it needs to be)?

I dove into the docs for Paystack, PayPal, Spotify, and The Movie Database (TMDB). My criteria were simple yet crucial:

Structure and Organization: Is the information logically presented and easy to digest?
Ease of Navigation: Can developers quickly find what they need?
Clarity of Information: Is the language precise, concise, and understandable?
Completeness of Content: Does it cover all the essentials, from authentication to endpoints and beyond?

Here's the lowdown on what I found:

The Good Vibes: Paystack & Spotify

Landing on Paystack and Spotify's API docs felt surprisingly welcoming. They just get it.

Information was laid out logically. Paystack’s felt super intuitive, and even with tons of stuff, Spotify kept things clean and organized. No getting lost in a maze of links.

Finding stuff was quick. Paystack's sidebar was well-organized, with a search bar that actually worked. There was no immediate search bar on Spotify's doc site, which lost them some points.

The content on Spotify's API site was so well written. It felt like it was guiding you. It wasn't just a list of technical details; it had this "here's what you do next" kind of vibe. That makes a huge difference when you're a beginner.

They used plain language, no crazy tech jargon overload. Code examples were right there, easy to grasp, and often in different languages. Huge bonus for developers who aren't tied to one language.

Authentication was explained step-by-step. Endpoints were detailed with what info to send and what to expect back (often with clear examples of the data).

The Solid Performer: PayPal

PayPal's API is massive, no doubt. But their documentation was well-handled.

They broke things down into clear sections for different needs (payments, subscriptions, etc.). This kept the sheer amount of info from being overwhelming.

Finding your way around wasn't too bad, thanks to good search and clear menus. You could usually find what you needed, even if it took a little more digging than Paystack or Spotify.

They generally explained things well, though sometimes the complexity of their features meant more detailed (but still understandable) explanations. Lots of code examples were there too.

They covered all the important stuff – different ways to authenticate (cURL & Postman), tons of endpoints for all their features, and details on what to expect when things go right (and wrong).

While maybe not as hand-holdy as Spotify, PayPal's docs did a solid job of managing a complex API.

The Head-Scratcher: TMDB

Not gonna lie, TMDB's API docs left me a bit… confused at times.

The basic layout was there, but finding specific bits of info sometimes felt like a treasure hunt.

Explanations could be a bit vague, assuming you already knew some things. Response examples were okay, but could have been clearer.

While the technical details were mostly there (how to authenticate, basic endpoints), it felt like it was missing the "here's how you actually use this" guidance that Spotify nailed.

It wasn't a disaster, but it definitely felt like you were left to figure things out on your own more often.

What This Means for Anyone Writing API Docs (and Using APIs)

Good API documentation is about making it easy for developers to understand and use your API. Clear structure, simple language, working navigation, and guiding people through the process.

Paystack and Spotify showed that API docs can actually be… dare I say… pleasant to use. PayPal handled complexity well. TMDB? Well, there's room for improvement in making it more user-friendly.

As someone learning the ropes of technical writing, this little API documentation tour was a real eye-opener. It's about more than being accurate; you have to be helpful too.

What API docs have you loved (or loathed)?

The Ethereum Design: Understanding Governance

1stOnwe — Tue, 15 Apr 2025 09:47:00 +0000

You see governance being talked about in crypto a lot, but why does it matter so much?

A typical app or platform in web2 is run by a company with a CEO, board or shareholders who make decisions on the development and direction of the platform.

Governance defines who decides what changes, and how those decisions are made.

In crypto, decisions also need to be made about the rules, upgrades and direction of every app. But the goal of crypto is to hand that power to the community of users and ecosystem participants.

This is called decentralized governance, and to achieve this, you often need tokens.

Governance can be onchain or offchain

Onchain governance means you need tokens to vote on a given decision. Voting happens on the blockchain and smart contracts automatically tally votes and enforce results.

Offchain governance means discussions and decisions happen on forums, Discord, Github or Zoom calls, but implementation is done by devs and validators.

Ethereum uses offchain governance.

Ethereum's governance follows an informal, layered process based on open dialogue, rough consensus, and community coordination.

Who participates in the Ethereum governance?

Core Developers - write the Ethereum software, propose and implement changes to the Ethereum network.
Node Operators/Validators - choose whether or not to run the new software updates.
The Ethereum Foundation - an influential non-profit that provides funding, research, education and coordination.
DApp Developers - build on Ethereum and influence the ecosystem via code, discourse and user bases.
Users/ETH holders (also called the Social Layer) - exert public pressure and sentiment on social platforms and can steer the direction of governance.

How Governance Works on Ethereum

Step 1: EIP Process (Ethereum Improvement Proposals)
- Anyone can write an EIP proposing a change to Ethereum.
- The EIP is reviewed, debated, refined and tested.
Step 2: Core Dev Calls
- Core devs have regular open meetings where tbey discuss EIPs, network upgrades and timelines.
- Anyone can join these calls.
Step 3: Community Feedback/Social Layer Vibe Check
- Discourse on Twitter, Discord, Reddit and Ethereum forums like @EthMagicians usually shape which proposals gain traction.
- Public opinion carries a lot of weight in the Ethereum ecosystem. Your voice matter.
Step 4: Final Coordination
- Once an EIP is accepted, it is scheduled into a future network upgrade (hard fork).
- Node operators and validators must then update their software to adopt it.

The next network update is Pectra and its scheduled to go live in May.

Governance is how power works in a decentralized world. If crypto us about cutting out the middlemen, governance is about making sure the “crowd” can steer the ship.

Ethereum's governance isn't perfect. It is slow, messy and sometimes hard to follow. But this is a feature, not a bug. It avoids a situation where whales make all the decisions. It is fork-resistant due to a strong social layer, and it encourages meticulous, long-term upgrades that prioritises security over speed. That is not to say there's no room for improvement.

Follow @TimBeiko on X to learn more about efforts to make Ethereum’s governance more structured and efficient.

Do I Need to Know About Smart Contracts?

1stOnwe — Mon, 14 Apr 2025 20:09:44 +0000

When you order a food from McDonald's, do you care about what it is made from?

You may not prepare the food yourself, but you'd still like to know if it's made from quality ingredients, processed in a safe manner or contains stuff you're allergic to.

Knowing this informs your decision on where to eat, as well as the brands to trust.

I like to think of smart contracts as the “ingredients” of many digital products built on blockchain. Even if you're not writing the code, having a basic understanding of what smart contracts are and how they work is very important.

What are Smart Contracts?

Blockchains keep records of transactions so that anyone can verify these transactions. The Bitcoin blockchain was created to record and verify the transactions of bitcoins.

Now, if blockchains have the ability to record transactions in a way that they can't be altered then maybe blockchains shouldn't be limited to keeping records of digital assets sent and received.

Ethereum was created to make a blockchain keep records of more complex transactions like lending and borrowing. Ethereum does this with smart contracts.

Smart contracts are basically terms and conditions or instructions that know when to apply themselves. They are written in code and don't require any one to execute them.

A simple smart contract activity that every user interact with daily without even thinking about it is swapping one asset to another.

You open your crypto wallet, and like any other user friendly app, you click the “Swap” button to convert some USDC for some ETH.

What happens when you click the “Swap” button

When you click that swap button, an instruction has been given for the wallet to always check:

that you have enough gas fee
that there's enough liquidity to complete the transaction at that price without issues
and to only exchange the assets once these conditions are met.

The rules can vary depending on the service you are using or what you're trying to achieve but this is pretty much the gist.

Without smart contracts, you'd have to use a bank or a broker and incur exchange fees that you might not be aware of (you can't verify).

Why is it important to be aware of smart contracts and what they do?

Just as you trust that a restaurant follows food safety standards, you need to trust that the smart contracts governing your transactions are secure and reliable. When you're aware of what goes into your food, you can make healthier choices or avoid allergens. Similarly, a basic understanding of smart contracts enables you to make informed decisions about which protocols to use and which to be wary about.

This is why people with size keep a good chunk of their money on the Ethereum network. 😉