Forem: Hemapriya Kanagala

Gemma 4 and the Return of Personal Computing

Hemapriya Kanagala — Thu, 07 May 2026 16:56:19 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

TL;DR

AI already feels much more integrated into everyday computing than it did even a couple years ago.

What makes models like Gemma 4 interesting is not just the benchmarks or the technical improvements, but how quickly capable local AI is becoming practical across different kinds of hardware.

We’re starting to move from a world where advanced AI mostly existed through websites and cloud services into one where parts of those workflows can also happen directly on personal devices.

That probably doesn’t replace cloud AI anytime soon.

But it does change how these systems start fitting into normal workflows.

And over time, I think that may end up feeling less like “using an AI tool” and more like AI simply becoming part of the computing environment itself.

⏱️ Estimated read time: ~9 minutes

AI already feels different now
What open models actually are
Why Gemma 4 feels important
What starts feeling different
Understanding context windows, multimodal AI, and model sizes
Why smaller models are becoming more useful
Local AI still has real limitations
Why this matters beyond AI itself
Where this may be heading
References
🤝 Stay in Touch

AI already feels different now

A year or two ago, most people still treated AI as something separate from normal computing.

You opened a chatbot website.

Asked a question.

Generated an image.

Then moved on.

That already feels outdated now.

AI has started showing up inside everyday software much more naturally.

We now see AI integrated into:

code editors
search engines
design tools
note-taking apps
office software
accessibility tools
research workflows
operating systems
and increasingly into AI agents that can perform multi-step tasks across different tools

In many ways, AI is no longer becoming “a product.”

It’s becoming part of the computing environment itself.

At the same time, another important shift has been happening quietly underneath all of this.

For the last few years, most advanced AI systems mainly existed through cloud infrastructure.

We accessed them remotely:

through APIs
websites
subscriptions
and internet-connected services

That model made complete sense.

Large AI systems require enormous amounts of computational power, and centralized infrastructure allowed advanced capabilities to scale quickly to millions of users.

But now we’re starting to see capable models become practical across a much wider range of hardware environments too.

And that’s where models like Gemma 4 start becoming really interesting.

What open models actually are

Before going further, it’s probably worth explaining what people mean when they say “open models.”

For people newer to AI, open models are systems whose model weights are publicly available for developers to download and run themselves.

The easiest way to think about it is this:

Instead of only accessing AI through someone else’s platform, developers can also run the system directly on their own hardware.

That hardware might be:

a laptop
a desktop
a workstation
a server
a phone
or an edge device

Different environments benefit from different approaches.

Some applications work best through large cloud infrastructure.

Others benefit from:

offline access
lower latency
faster responsiveness
tighter integration with local software
or more control over deployment environments

Gemma 4 is part of a broader movement in this direction alongside models like:

Llama
Mistral
Qwen
Phi
and other increasingly capable open models

What makes Gemma 4 interesting is how it continues pushing capable multimodal AI into a wider range of practical environments.

For developers especially, that flexibility matters because it creates more choices around deployment, privacy, latency, and integration.

Why Gemma 4 feels important

A lot of AI releases improve technical benchmarks without necessarily changing how the technology feels in everyday use.

Gemma 4 feels important for a slightly different reason.

It reflects how quickly local AI has matured.

A few years ago, running AI locally often involved major compromises:

slow responses
limited reasoning
small context windows
high hardware requirements
or systems that felt more experimental than practical

But newer generations of models are steadily changing that experience.

Gemma 4 includes:

smaller models optimized for efficient local execution
larger models designed for stronger reasoning
multimodal capabilities for understanding text and images together
long context windows
support for coding workflows
and increasingly agent-oriented capabilities like function calling

For people unfamiliar with the term, “function calling” allows AI systems to interact with external tools and software in a more structured way.

That’s part of what enables many modern AI agents to:

retrieve information
use tools
execute tasks
or work across multiple systems more reliably

What feels significant is not simply that these capabilities exist.

It’s that they’re becoming available across more kinds of hardware and computing environments than before.

What starts feeling different

I think this is the part that’s easiest to underestimate.

For a long time, powerful AI mostly existed inside large centralized infrastructure.

And honestly, that will continue to matter enormously.

Cloud AI remains incredibly important for:

large-scale reasoning
enterprise systems
collaborative workflows
massive computational workloads
and many advanced AI services we use every day

But now capable models can also increasingly run:

on laptops
on consumer GPUs
on workstations
on mobile hardware
and on edge devices

That doesn’t replace cloud AI.

But it does expand where AI can exist.

And over time, that changes how these systems fit into everyday workflows.

A few years ago, asking an AI system to analyze a long PDF, help write code, summarize notes, understand screenshots, and assist inside a local workflow would usually require sending everything to a large remote service.

Now, parts of those workflows can increasingly happen directly on personal hardware.

For example, a developer might now use a local model to:

summarize project notes
understand screenshots
search through documentation
assist with coding
or organize research material

all without constantly switching between external services and browser tabs.

That kind of integration changes the feeling of the workflow itself.

That doesn’t sound dramatic at first.

But small shifts like that gradually reshape how technology fits into everyday work.

The transition usually feels slow while it’s happening.

Then suddenly it feels normal.

I think that’s part of why local AI feels surprisingly interesting the first time you experience it regularly.

Not because it suddenly feels futuristic.

But because it starts feeling ordinary.

Almost the same way we stopped thinking about browsers, Wi-Fi, cloud sync, or search engines as remarkable technologies once they became naturally integrated into computing itself.

Understanding context windows, multimodal AI, and model sizes

A lot of modern AI terminology can sound intimidating at first, so it’s worth slowing down and explaining a few ideas that matter for systems like Gemma 4.

Context windows

A “context window” is essentially the amount of information a model can actively keep track of while working.

You can think of it like a working desk.

A small desk forces you to constantly remove papers to make room for new ones.

A larger desk lets you keep more documents open at once, which makes it easier to work on:

long conversations
large codebases
research material
PDFs
or multi-step reasoning tasks

Gemma 4 supports very large context windows compared to earlier generations of smaller local models, which helps make longer and more complex workflows more practical.

Multimodal AI

Gemma 4 is also multimodal.

That simply means the model can work with more than one kind of input.

Instead of only reading text, multimodal systems can also understand things like:

images
screenshots
charts
documents
and in some cases audio or video

The easiest way to think about multimodal AI is that the system is no longer interacting with only words.

It can process multiple forms of information together in a single workflow.

Model sizes and parameters

You’ll often see models described using names like:

The “B” stands for billions of parameters.

Parameters are essentially part of the internal structure the model uses to recognize patterns and relationships in data.

The exact mathematics behind them is complex, but a useful way to think about parameters is as part of the model’s learned pattern-recognition ability.

In general:

larger models tend to be more capable
but they also require significantly more memory and computational power to run

That’s why smaller efficient models matter so much for local AI.

Why smaller models are becoming more useful

One of the most interesting developments in AI right now is how capable smaller models are becoming.

For years, progress in AI mostly meant building larger and larger systems.

And larger models still matter enormously.

But practical computing is not only about maximum capability.

It’s also about:

speed
accessibility
responsiveness
portability
energy usage
cost
and integration into real workflows

A model that responds quickly on local hardware can sometimes feel more useful in everyday work than a larger system that depends entirely on remote infrastructure.

Especially for:

coding assistance
local productivity workflows
summarization
document understanding
accessibility tools
education
and offline applications

And smaller models also change where AI can realistically exist.

If capable models can run efficiently across many kinds of devices, then these systems become easier to integrate directly into the environments where people already work and create.

And honestly, some of the most interesting applications of local AI probably haven’t been built yet.

Local AI still has real limitations

At the same time, local AI still comes with real limitations.

Running larger models locally can require:

powerful hardware
significant memory
specialized GPUs
and careful optimization

Some advanced systems still perform much better through large cloud infrastructure with access to enormous computational resources.

And even though smaller models are improving rapidly, there are still many areas where larger cloud-based systems remain stronger, especially for highly complex reasoning and large-scale workloads.

That’s important to acknowledge.

Because this probably isn’t a story about local AI replacing cloud AI.

At least not anytime soon.

What feels more significant is that capable AI is becoming available across a broader range of environments instead of existing primarily in one place.

And that flexibility opens up new possibilities for:

developers
researchers
students
creators
companies
and everyday users

Why this matters beyond AI itself

Benchmarks matter.

Reasoning quality matters.

Coding ability matters.

Accuracy matters.

But technology history repeatedly shows that accessibility matters too.

Some technologies become transformative not only because they improve technically, but because they become easier to integrate into ordinary life.

Personal computers became transformative because people could own them directly.

Smartphones became transformative because they became portable and always available.

The internet became transformative because connectivity became widely accessible.

AI may be entering a similar phase now.

Not because one single model suddenly changes everything overnight.

But because capable models are gradually becoming:

more flexible
more efficient
more integrated
and available across more kinds of hardware and software environments

And that may quietly shape the next stage of everyday computing in ways we still don’t fully understand yet.

Where this may be heading

Maybe that’s why models like Gemma 4 feel important right now.

Not because one model suddenly changes everything overnight.

But because they reflect a broader shift already happening across AI.

These systems are becoming:

more capable
more accessible
more efficient
and easier to integrate into the tools people already use every day

We’re already seeing AI become part of:

coding workflows
creative tools
operating systems
search
productivity software
communication platforms
research workflows
and increasingly autonomous agents capable of handling more complex tasks

The technologies that last usually stop feeling like separate tools after a while and start feeling like part of the environment itself.

AI still has real limitations.

Cloud systems still matter enormously.

And nobody fully knows what the next few years will look like.

But it does feel like we’re entering a phase where AI is no longer only something we visit through websites and apps.

It’s increasingly becoming part of the computing experience itself.

References

For a deeper look at Gemma 4 and the ideas mentioned in this post:

🤝 Stay in Touch

We are all watching AI become part of everyday computing in real time, and honestly, it’s interesting seeing how quickly the experience is changing.

I’d love to hear how local models and AI tools are fitting into your own workflows lately.

-> Follow me on GitHub for the things I’m building and experimenting with

-> Connect with me on LinkedIn

And seriously, if something here made sense or didn’t, drop a comment. The interesting part of all this is comparing notes.

Your AI Agent Crashed at 2 AM. Here’s How Google Fixes It.

Hemapriya Kanagala — Wed, 29 Apr 2026 07:15:28 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

TL;DR

AI agents don’t just fail like traditional software. They fail because of how they reason.

At Google Cloud NEXT '26, Google introduced Agent Observability (to see what your agent was thinking) and Gemini Cloud Assist (to diagnose and fix issues directly in your code).

Together, they make debugging AI agents in production faster, clearer, and far less painful.

⏱️ Estimated read time: ~8 minutes

The Reality of AI Agents in Production
First, let's understand what "debugging an AI agent" even means
What is Agent Observability?
What is Gemini Cloud Assist?
The demo: a marathon simulation that broke mid-race
What even is a token limit?
How Cloud Assist fixed it
Why this matters for every developer building with AI
One thing to keep in mind
The real shift happening right now
References
🤝 Stay in Touch

The Reality of AI Agents in Production

It’s 2 AM. Your AI agent just crashed in production.

And the worst part? You don’t even know why.

You've spent weeks building it. It works great on your laptop. You deploy it. Customers start using it. And then, one random Tuesday, it just... dies. No clear error. No "you forgot a semicolon" message. Just a broken agent, confused logs, and you staring at your screen wondering what on earth it was thinking.

The problem isn’t just failure. It’s understanding why the agent failed.

This is the part nobody really talks about when we get excited about building AI agents. Building them is the fun part. Running them, keeping them alive, understanding why they fail, and fixing them fast, that is where things get genuinely hard.

At Google Cloud NEXT '26, Megan O'Keefe put it really well. The real challenge of putting agents into production isn't just scaling your infrastructure. It's "managing the reasoning, the tool calls, and all the places in the whole system where something can go wrong."

And Google showed two tools built exactly for this moment: Agent Observability and Gemini Cloud Assist.

First, let's understand what "debugging an AI agent" even means

With a traditional application, debugging is kind of like fixing a broken pipe. You find the leak, you patch it, you're done. The pipe either works or it doesn't. There's no in-between.

Debugging an AI agent is completely different. It's less like fixing a pipe and more like being a therapist for a robot. The agent isn't just crashing because of a typo or a missing database connection. It's crashing, or misbehaving, because of how it reasoned. It made a decision. That decision was wrong. And you need to understand why it made that decision so you can help it not do it again.

This is where AI systems are fundamentally different from traditional software.

That's a whole new discipline. And without the right tools, it's like trying to find a needle in a haystack while blindfolded.

What is Agent Observability?

Think about a flight data recorder, the black box on an airplane. After something goes wrong, investigators pull that box and replay everything: every reading, every signal, every action the pilots took. They don't have to guess. They have a record.

Agent Observability is that black box for your AI agent.

When a normal app has a problem, you check if a server crashed or if a response was slow. That's enough. But when an AI agent has a problem, you need to know something much deeper: what was it thinking? What tools did it call? What information did it look at? Where exactly did its reasoning go off track?

Agent Observability records all of this. It uses open standards, specifically OTel-compliant telemetry, which is the same kind of telemetry the broader software industry already uses for observability, to give you a visual trace of your agent's full execution path. Every step, in order, clearly laid out.

This matters because AI agents can fail in ways that are genuinely strange. They can get stuck in reasoning loops. Imagine someone pacing back and forth trying to solve a problem, taking the same wrong step over and over because they can't see that it's wrong. Or they can crash because they tried to hold too much information in memory at once. Both of these failures are invisible without observability. With it, you can actually see what happened.

What is Gemini Cloud Assist?

Now, once you see what happened, you still have to fix it. And this is where Gemini Cloud Assist comes in.

If Agent Observability is the black box, Cloud Assist is the investigator who reads it for you, connects it to everything else, and tells you exactly what to do.

Here's the old way of doing things: something breaks in production. You get an alert. You open logs. You stare at thousands of lines of dense, intimidating text. You copy chunks of it into a chat window somewhere, try to make sense of it, go back to your code, try to figure out where the problem lives, and maybe fix the wrong thing first. It's exhausting and slow.

Cloud Assist changes this. It doesn't just summarize the logs. It reads them, identifies the exact error, and then connects directly to your source code in your IDE (your code editor) through something called the Model Context Protocol (MCP). It reads both the production logs and your actual code at the same time. And then it suggests a specific, concrete fix.

Not a vague "maybe try this." An actual code change.

The demo: a marathon simulation that broke mid-race

To show how this all works together, Google ran a live simulation at the keynote (Google Cloud Next '26 Developer Keynote). Imagine a Las Vegas marathon. An AI agent is running the simulation of race logistics in real time. And mid-demo, the "Simulator Agent" crashes and starts causing high latency.

Here's how the debugging played out:

Megan got an alert in her Gmail. She opened the Cloud Monitoring console and looked at the trace view, the visual record of what the agent had done. She could see it had successfully called a few tools, and then it just died. Unexpectedly. No obvious reason in the trace itself.

Instead of scrolling through a massive wall of error text, she clicked one button to start a Cloud Assist investigation.

Cloud Assist found a 400 request error. The agent had tried to talk to the Gemini API and got rejected. But why?

Megan opened her code editor. Cloud Assist analyzed the source code (a file called agent.py) and figured out what happened: the agent had exceeded the 1 million context token limit.

What even is a token limit?

This is worth slowing down on, because it's one of those concepts that sounds technical but is actually very intuitive once you see it.

An AI's "context window" is basically its short-term memory. "Tokens" are the pieces of data it's holding in that memory, roughly speaking, the words and information it's actively working with.

Now imagine you're a student trying to memorize an encyclopedia in one sitting. You keep reading and reading, adding more and more to your working memory, and at some point your brain just gives up. It hits a limit. You can't hold any more.

That's exactly what happened to this agent. It had been running for a while, accumulating information, and it never stopped to summarize what it had learned. Its memory filled up. It hit the token limit. It crashed.

This is a real problem in production AI systems, and it's becoming one of the new bottlenecks in software development. "Token scale," managing how much information an agent holds and when it should compress its memory, is something developers now have to think about the same way they used to think about RAM or database size.

How Cloud Assist fixed it

This is the part that genuinely impressed me.

Cloud Assist didn't just say "your token limit was exceeded, good luck." It looked at the code, understood the architecture, and suggested a specific fix: add a token_threshold parameter to a feature called Event Compaction.

What Event Compaction does is force the agent to summarize its memory more frequently, before it gets dangerously close to the limit. By adding a threshold, you're essentially telling the agent: "don't wait until your memory is full. Start summarizing earlier and keep things manageable."

Megan approved the change, committed it, and the system automatically deployed the fixed agent.

The whole process, from alert to deployed fix, was remarkably fast. And more importantly, the fix was accurate. It wasn't a guess. It was based on reading the actual production error and the actual source code together.

Why this matters for every developer building with AI

Here's my honest take on all of this.

We're entering a genuinely new era of software development. A lot of us are building agents and excited about what they can do. But we haven't fully reckoned with the fact that agents are still just software. They still break. They still crash. They still misbehave in production.

They just break in completely new ways.

A traditional bug is usually deterministic. The same input gives you the same broken output every time. An agent bug can be non-deterministic. It might only happen under certain conditions, after a certain amount of time, or when the agent has accumulated a certain kind of context. That's much harder to reproduce and debug without proper tooling.

The moment you move an AI agent from a local experiment to a real environment where real users depend on it, you need observability. Not eventually. Immediately.

And tools like these fill a gap that genuinely needed filling. The IDE integration especially, being able to see the production error and the source code in the same place, at the same time, with suggested fixes, that's not just convenient. It's a fundamentally better workflow.

One thing to keep in mind

I want to be real with you about something, because I think it's worth saying.

We're now in a world where AI is diagnosing and writing code to fix other AI. That's remarkable. But it also means you should never just approve a suggested fix without understanding what it does.

Cloud Assist suggested the token_threshold change because it read the code and understood the architecture. But you, as the developer, need to review that change with your own understanding too. An AI can misread context. It can suggest a fix that solves the symptom but misses the root cause. Or worse, it could push a fix that quietly breaks something else.

Human-in-the-loop isn't just a nice phrase here. In production systems, it's genuinely important. Approve changes you understand. Don't just click accept because the AI was confident.

That said, the fact that we have these tools at all is genuinely exciting. Used thoughtfully, they make debugging AI systems faster and less painful than it's ever been.

The real shift happening right now

AI agents don’t just fail. They fail in ways you can’t see without the right tools.

The conversation in AI development is moving. A year ago, everyone was talking about building agents. Now the real challenge is running them safely, understanding them when they fail, and fixing them quickly.

Agent Observability and Gemini Cloud Assist are Google's answer to that challenge. And based on what was shown at NEXT '26, it's a thoughtful one.

If you're building AI agents, even small ones or experimental ones, start thinking about observability now. Not when something breaks. Now.

Because when an AI agent fails at 2 AM, you don’t just need logs. You need answers.

References

For a deeper look at the announcements and demos mentioned in this post:

🤝 Stay in Touch

We’re all figuring this out in real time.

If you’re working with AI agents, I’d really like to know:

Have you seen weird, hard-to-explain failures in production?
What’s been the hardest part, debugging, scaling, or just trusting the system?

-> Follow me on GitHub for the things I’m building and experimenting with

-> Connect with me on LinkedIn

And seriously, if something here made sense or didn’t, drop a comment. The interesting part of all this is comparing notes.

How I Built a Blockchain User Profile with Solidity (and You Can Too)

Hemapriya Kanagala — Tue, 29 Jul 2025 03:57:11 +0000

This is a smart contract I wrote using Solidity that lets people register and update their profile on the blockchain. It was one of the first contracts I built to understand how user data works on Ethereum.

The idea is simple:

Everyone has a wallet address. What if we could let each address store their name, age, and email - all saved on-chain?

So I built that.

Here is the GitHub link if you want to check out the code.

I wrote just one file: UserProfile.sol.

What This Contract Does

This smart contract lets a user:

Register their name, age, and email
Update that information later
View their own profile (no one else can access it)

Everything is connected to their Ethereum wallet address, so you don’t need to log in - your wallet is your ID.

Concepts I Used

If you're new to Solidity or smart contracts, these are the main building blocks I used:

Concept	What It Does
`struct`	Groups related data - like name, age, and email - into a single object
`mapping`	Stores info for each user using their wallet address as the key
`require()`	Adds checks so people don’t register twice or update before registering
`block.timestamp`	Saves the time a user registered, using the blockchain’s clock

Each time someone registers, their info is stored on the blockchain - and only they can update or view it.

How It Works

Here’s what the contract does in plain English:

1. `register(name, age, email)`

This function saves your profile to the blockchain - but only if you haven’t registered before. If you try again, it gives an error.

2. `updateProfile(name, age, email)`

If you already registered, this lets you change your info anytime.

3. `getProfile()`

This function shows your current profile - your name, age, email, and the time you first registered. Only you can see it (based on your wallet).

How to Try It Yourself (Beginner-Friendly)

You don’t need a real wallet or ETH to test this. Remix IDE runs everything in your browser using fake ETH.

Steps to Test the User Profile Contract

Go to Remix

→ https://remix.ethereum.org
Create a new file

→ Click “+” → Name it UserProfile.sol
Paste in the contract code

→ You can find it here on GitHub
Compile it

→ Go to the Solidity Compiler tab

→ Make sure version is 0.8.0 or higher

→ Click Compile
Deploy it

→ Go to the Deploy & Run Transactions tab

→ Select Remix VM (Prague) as environment

→ Leave Value as 0

→ Click Deploy
Register yourself

→ Fill in name, age, and email

→ Click register()

✅ You’ll see a green checkmark
Check your profile

→ Click getProfile()

✅ Your info will appear: name, age, email, and timestamp
Try updating it

→ Enter new name, age, or email

→ Click updateProfile()

→ Then click getProfile() again to see the updated info

What I Learned

Lesson	How I Used It
Structs in Solidity	Grouped user info like name, age, email
Mappings	Stored each user's profile by their address
Access control with `msg.sender`	Made sure only the owner of a profile can update or view it
Blockchain timestamp	Recorded when each user registered
Remix testing	Quickly deployed and tested without real ETH

Common Mistakes to Avoid

Mistake	Why It’s a Problem	How I Solved It
Registering twice	Contract would overwrite data	Used `require()` to block double registration
Updating before registering	User wouldn’t exist in mapping yet	Added `require()` to check registration first
Returning too much data	Could make `view` functions heavy	Kept `getProfile()` simple and clear

Up Next

I’d really appreciate your questions or feedback. Did something confuse you? Let me know. Your insights help shape the next articles.

Also, if there’s a non-Web3 topic you want me to cover (open source, side projects, etc), drop a comment below. If I know it, I’ll write about it. If not, I’ll point you to a good place to begin.

🤝 Stay in Touch

Check out the GitHub repo
Follow me on GitHub for projects and experiments
Connect with me on LinkedIn - I’d love to hear from you
Drop a comment if you tried this or have questions - I’d love to help!

Thanks for reading!

What Actually Happens When You Make a Blockchain Transaction?

Hemapriya Kanagala — Fri, 25 Jul 2025 06:33:31 +0000

Welcome back! If you read Article 1: A Beginner’s Guide to How Blockchain Actually Works, we walked through what a blockchain is, how blocks form, and why decentralization matters.

Now let’s get a little more hands-on.

You’ve probably heard things like:

“Just send me crypto.”

“It’s on the blockchain.”

“Check your wallet.”

But what does that actually mean? What happens under the hood when you send a transaction?

This article takes you behind the scenes - from clicking “Send” in your wallet to seeing the transaction confirmed on a blockchain explorer.

Step-by-Step: How a Blockchain Transaction Works

Let’s follow a single transaction from start to finish. We’ll use a simple example:

You want to send 1 token to a friend using a wallet like MetaMask.

Here’s what happens behind the scenes:

1. You Create the Transaction in Your Wallet

A wallet is an interface that lets you interact with the blockchain. It stores your private key (securely) and helps you sign transactions.

You enter:

Your friend’s public address
Amount to send
Optional message or data (depends on blockchain)
The gas fee you're willing to pay

Your wallet then signs the transaction using your private key. This proves it came from you, without ever revealing your key.

📌 Signing means creating a unique digital signature based on your private key and the transaction data.

2. Your Wallet Broadcasts the Transaction to the Network

Once signed, the transaction is broadcast to the network. This means it’s sent to nearby nodes (computers running the blockchain software).

Those nodes check if:

Your signature is valid
You have enough balance
The transaction is formatted correctly

If it looks good, they pass it on to more nodes - spreading it across the network, like sharing a file with everyone.

📌 Nodes are participants in the blockchain network. They validate transactions and keep a full copy of the blockchain.

3. The Transaction Enters the Mempool

Valid transactions are stored in something called the mempool - short for memory pool. Think of it as a waiting room where pending transactions sit before being added to a block.

Every node maintains its own mempool, but they’re usually very similar.

Inside the mempool:

Transactions are ranked (usually by fee amount)
Miners or validators pick from the top

📌 The mempool is like a “to-do list” for the network.

4. A Validator Picks It Up and Adds It to a Block

Depending on the blockchain’s consensus method, a participant is selected to propose the next block. This could be a miner (Proof of Work) or validator (Proof of Stake).

They:

Pick high-fee transactions from the mempool
Group them into a block
Validate and order them
Propose the block to the network

If accepted, the block is added to the chain - and your transaction is officially recorded.

📌 A block contains many transactions, plus metadata like timestamp, block number, and a hash of the previous block.

5. You See the Transaction Confirmed

Once included in a block, your transaction gets a confirmation.

Over time, more blocks are added after it - which makes your transaction harder to reverse. That’s why you’ll hear things like:

“Wait for 3 confirmations.”

“It’s confirmed on-chain.”

You (or anyone) can view it on a blockchain explorer like LiskScan or Etherscan. These tools let you search by:

Wallet address
Transaction hash
Block number

A Real-World Analogy: Certified Mail

Here’s a way to picture the entire process using something familiar — mailing a certified letter.

Blockchain Step	Certified Mail Equivalent
Create transaction in wallet	Write a letter, sign the envelope
Broadcast to network	Drop it at your local post office
Mempool	Letter goes into a mail sorting facility
Validator adds it to block	A courier picks it up and delivers it
Confirmed on-chain	Recipient signs for it, and delivery is logged

Both systems involve signing, routing, validation, and a final delivery record.

Wait... What’s This “Gas Fee” I’m Paying?

On most blockchains, every transaction requires a small payment - called a gas fee.

You’re paying the network to:

Validate your transaction
Store it in a block
Broadcast it across the chain

Fees vary based on:

Network congestion (how full the mempool is)
Complexity of your transaction (simple send vs smart contract)
Priority (higher fee = faster confirmation)

On Ethereum, gas is measured in gwei. On Lisk, it’s based on LSK token units.

Here’s a quick comparison:

Transaction Type	Typical Gas Fee (Estimates)
Simple token transfer	Low
NFT mint or marketplace buy	Medium
Complex smart contract call	Higher (depends on logic & storage)

Tip: Always check the fee before sending - wallets like MetaMask show it clearly.

How Long Does It Take?

Transaction time depends on:

The blockchain’s block time (e.g. Ethereum ~12s, Lisk ~10s)
Network traffic
Your fee

Blockchain	Avg Block Time	Confirm Time (1 block)	Notes
Ethereum (PoS)	~12 sec	~12 sec	High usage = higher fees
Bitcoin (PoW)	~10 min	~10 min	Slower but more secure
Lisk (PoS)	~10 sec	~10 sec	Fast and energy-efficient

More confirmations = stronger finality (i.e. harder to reverse).

What If Two People Try to Send the Same Coins?

The blockchain uses the nonce (a number that increases with each transaction) to prevent double spending.

If someone tries to send the same coins twice, only the valid transaction with the correct nonce will be accepted. The rest will be ignored.

Why Transactions Sometimes Fail

Here are common reasons a transaction doesn’t go through:

Problem	Cause
“Out of gas” error	You didn’t pay enough to complete it
“Nonce too low”	Another transaction was already sent before this one
Stuck in mempool	Gas fee too low, not attractive to validators
Wrong network selected	You sent tokens on the wrong chain

Always double-check your settings before hitting Send.

Can I Try This Myself?

Yes, if you’re curious and want to see this in action, here’s a safe, free way to experiment using a test network.

Install MetaMask browser extension
Create a new wallet and save your secret phrase securely
Add Lisk Sepolia as a custom network
Get free test tokens from the L2 Faucet
Use MetaMask to send a small token to yourself
Go to LiskScan and look up your wallet address
See your transaction as it appears on-chain

This gives you a hands-on feel for how blockchain transactions work.

Or, if this still feels early, you can just keep learning. Later articles will help build your confidence.

What’s Next?

I’d really appreciate your questions or feedback. Did something confuse you? Let me know. Your insights help shape the next articles.

🤝 Stay in Touch

Follow me on GitHub for projects and experiments
Connect with me on LinkedIn - I’d love to hear from you
Drop a comment or message if something clicked or confused; I read all of them.

A Beginner’s Guide to How Blockchain Actually Works

Hemapriya Kanagala — Fri, 18 Jul 2025 22:44:47 +0000

If you've ever heard the word "blockchain" and thought, “Sounds complicated... probably not for me,” you're not alone. That was me too, not long ago. But the more I dug in, the more I realized it’s not some far-off concept meant only for coders or finance experts. It’s actually a simple idea that has the potential to change how we do things online, from sending money to keeping records and building apps.

What Is Blockchain?

Think of a digital notebook shared by many people at once. Every time someone records a transaction, it shows up instantly in everyone’s copy. No one can delete past entries or alter them without being noticed.

That unchangeable, transparent, shared structure is essentially what blockchain is. The participants all maintain it - no single person owns it. That’s what “decentralized” means.

Why Does It Matter?

Today, we depend on systems like banks, messaging platforms, or organizations to handle transactions, verify identities, or secure agreements. These intermediaries add layers of trust, fees, and delays.

Blockchain removes those layers by embedding trust in the system itself. People call it “trustless,” meaning you don’t have to rely on a central authority. The rules are enforced by the entire network.

How Blocks Form a Chain

A block is simply a collection of data - commonly a group of transactions. Inside each block you’ll find:

The details of what happened
A timestamp
A unique digital signature (called a hash)
A reference to the previous block’s hash

Linking blocks this way creates a chain. If someone tampers with a block, its hash changes and eventually the links break. That’s what makes the blockchain secure.

How the Network Decides What’s Real

Without a central authority, blockchains rely on a system called consensus. All participants (called nodes) follow a set of rules to verify transactions and add new blocks.

Here are two popular methods:

Proof of Work

Miners compete to solve a math problem. Whoever solves it adds the next block and earns a reward. This method secures the network but uses a lot of energy.

Proof of Stake

Participants lock up some of their coins as collateral. The network chooses one to add the next block. This method is faster and uses far less energy.

Most newer networks like Ethereum and Lisk use Proof of Stake today.

Public vs. Private Blockchains: What’s the Difference?

Some blockchains are open to anyone. Others are private and used within companies.

Feature	Public Blockchain	Private Blockchain
Who can use it?	Anyone	Only approved users
Who controls it?	No one	One organization
Examples	Bitcoin, Ethereum	Hyperledger, Corda

Public ones are like a public park. Anyone can enter and use it.

Private ones are more like an office building. You need a keycard.

Quick Pause: What About Security?

One word: cryptography.

Blockchains use strong math-based tools to keep things safe. Each user has two keys:

A public key, which is like your email address (you can share it)
A private key, which is like your password (you never share it)

Together, these keys help verify that transactions are real. If someone sends money, their private key is used to “sign” the transaction, proving it came from them.

Smart Contracts: Programs That Run Themselves

This part blew my mind the first time I understood it.

Smart contracts are self-executing agreements written in code. They live on the blockchain, and when conditions are met, they act on their own.

Example:

Let’s say you hire a freelancer online. Instead of using a middleman to hold the payment, you create a smart contract. When the work is marked as done, the money automatically goes to the freelancer.

No one can interfere. The contract is the boss.

Smart contracts are being used in:

DeFi (decentralized finance)
NFT marketplaces
Blockchain-based games
Digital voting

Challenges and Real Solutions

Blockchain sounds amazing, but it’s not perfect. Here are a few issues and how developers are solving them.

1. Scalability

Popular blockchains can get congested and slow.

Solution:

Use Layer 2 tools, like rollups, which process transactions more efficiently. Think of it like adding an express lane to a busy highway.

2. Energy Use

Proof of Work blockchains use a ton of power.

Solution:

Moving to Proof of Stake reduces energy use by over 90 percent. Ethereum already made this change.

3. Regulations

Governments are still figuring out how to handle crypto and blockchain legally.

Solution:

New laws are being written, and tools like Decentralized Identity (DID) are helping users stay compliant while protecting privacy.

What Is the Superchain?

Some projects, like those based on the OP Stack, aim to connect blockchains together so they can share updates and improvements. Lisk is part of this vision. The idea is a flexible, scalable, cooperative network of blockchains.

How to Begin Yourself

You don’t need coding skills to try it:

Install MetaMask
Create a wallet and save your recovery phrase
Add the Lisk Sepolia test network
Get free tokens from L2 Faucet
Send a token to yourself or a friend
See the transaction on a blockchain explorer

You’ve now used a blockchain.

Summary

Blockchain is a secure, shared digital record
It’s decentralized - no single owner
Blockchains use cryptography and consensus to stay honest
Smart contracts let you automate agreements
There are challenges, but active solutions exist
You can try blockchain yourself without cost

What Comes Next

In the next article, we’ll dive into what happens when you send a transaction - from your wallet all the way to confirmation on the blockchain.

I’d really appreciate your questions or feedback. Did something confuse you? Let me know. Your insights help shape the next articles.

🤝 Stay in Touch

Follow me on GitHub for projects and experiments
Connect with me on LinkedIn - I’d love to hear from you
Drop a comment or message if something clicked or confused; I read all of them.

See you in Article 2.

Forem: Hemapriya Kanagala

Gemma 4 and the Return of Personal Computing

TL;DR

Table of Contents

AI already feels different now

What open models actually are

Why Gemma 4 feels important

What starts feeling different

Understanding context windows, multimodal AI, and model sizes

Context windows

Multimodal AI

Model sizes and parameters

Why smaller models are becoming more useful

Local AI still has real limitations

Why this matters beyond AI itself

Where this may be heading

References

🤝 Stay in Touch

Your AI Agent Crashed at 2 AM. Here’s How Google Fixes It.

TL;DR

Table of Contents

The Reality of AI Agents in Production

First, let's understand what "debugging an AI agent" even means

What is Agent Observability?

What is Gemini Cloud Assist?

The demo: a marathon simulation that broke mid-race

What even is a token limit?

How Cloud Assist fixed it

Why this matters for every developer building with AI

One thing to keep in mind

The real shift happening right now

References

🤝 Stay in Touch

How I Built a Blockchain User Profile with Solidity (and You Can Too)

What This Contract Does

Concepts I Used

How It Works

1. register(name, age, email)

2. updateProfile(name, age, email)

3. getProfile()

How to Try It Yourself (Beginner-Friendly)

Steps to Test the User Profile Contract

What I Learned

Common Mistakes to Avoid

Up Next

🤝 Stay in Touch

What Actually Happens When You Make a Blockchain Transaction?

Step-by-Step: How a Blockchain Transaction Works

1. You Create the Transaction in Your Wallet

2. Your Wallet Broadcasts the Transaction to the Network

3. The Transaction Enters the Mempool

4. A Validator Picks It Up and Adds It to a Block

5. You See the Transaction Confirmed

A Real-World Analogy: Certified Mail

Wait... What’s This “Gas Fee” I’m Paying?

How Long Does It Take?

What If Two People Try to Send the Same Coins?

Why Transactions Sometimes Fail

Can I Try This Myself?

What’s Next?

🤝 Stay in Touch

A Beginner’s Guide to How Blockchain Actually Works

What Is Blockchain?

Why Does It Matter?

How Blocks Form a Chain

How the Network Decides What’s Real

Proof of Work

Proof of Stake

Public vs. Private Blockchains: What’s the Difference?

Quick Pause: What About Security?

Smart Contracts: Programs That Run Themselves

Challenges and Real Solutions

1. Scalability

2. Energy Use

3. Regulations

What Is the Superchain?

How to Begin Yourself

Summary

What Comes Next

🤝 Stay in Touch

1. `register(name, age, email)`

2. `updateProfile(name, age, email)`

3. `getProfile()`