DEV Community: Aniket Misra

Before Solana Went Native: What the EVM Actually Is (And Why It Was Built to Be Slow)

Aniket Misra — Mon, 13 Jul 2026 18:04:17 +0000

To understand why Solana's decision to repurpose BPF was radical, you first need to understand what it was radical against. That's the Ethereum Virtual Machine — the thing every other "VM for smart contracts" design, Solana included, is implicitly arguing with.

The EVM isn't slow because Ethereum's engineers were careless. It's slow because of a set of design choices that made total sense in 2014, when the problem being solved wasn't "how do we get 50,000 TPS" — it was "how do we get a global network of mutually distrusting strangers to agree on the exact same computation, byte for byte, forever." Every property that makes the EVM feel heavy today is downstream of that one requirement.

This is the prequel to a piece I wrote on how Solana re-engineered a Linux kernel packet filter into its execution layer. Before we get to what Solana did differently, here's what it was different from.

1. A Stack Machine, Not a Register Machine

The EVM is a 256-bit stack-based virtual machine. There are no general-purpose registers. Every operation — arithmetic, comparisons, memory access — pushes and pops values from a stack, one instruction at a time.

PUSH1 0x05
PUSH1 0x03
ADD

That's the entire bytecode for "5 + 3." No register allocation, no scheduling — the EVM interprets it top to bottom, exactly as written. This is also why Solidity compiles down to something conceptually close to this, opcode by opcode, rather than to a register-mapped instruction set the way a Rust program compiling to BPF does.

The 256-bit word size isn't an accident either — it matches the output width of Keccak-256, the hash function baked into almost everything Ethereum does (addresses, storage slots, opcodes like SHA3). The VM's fundamental data type was chosen to fit the cryptography, not the hardware.

Compare that to a register machine like BPF or SBF, where the instruction set is designed to map closely to what a real CPU already does. The EVM was never trying to be fast on real silicon. It was trying to be unambiguous — every implementation, on every machine, computing the exact same stack transitions.

2. Interpreted, All the Way Down

There's no JIT. No AOT compilation to native code. Every EVM opcode, on every node, for every transaction, gets interpreted at runtime, instruction by instruction, by whatever client software that node happens to run (Geth, Nethermind, Besu — doesn't matter, they all have to agree).

This is a deliberate constraint, not an oversight. If clients were free to JIT-compile bytecode to native machine code, you'd be trusting each client's compiler to preserve exact semantics across compilation — including edge cases like integer overflow behavior and gas accounting quirks. One divergent optimization and the network forks. Interpretation is slow, but it's slow in a way that's trivially auditable: the reference behavior is the implementation.

Some newer EVM implementations do experiment with JIT compilation for performance, but the base protocol was never designed assuming it — correctness came first, speed was whatever was left over.

3. Gas: Metering Before Execution, Not Verification Before Execution

The EVM has no static verifier checking that your bytecode terminates before it runs — there's no equivalent of eBPF's compile-time proof-of-termination. Instead, every single opcode has a fixed gas cost, charged as execution proceeds. Run out of gas, execution halts immediately and any state changes revert.

function withdraw(uint amount) public {
    require(amount <= balances[msg.sender], "insufficient balance");
    balances[msg.sender] -= amount;
    payable(msg.sender).transfer(amount);
}

Every line here costs gas — SLOAD to read balances[msg.sender], SSTORE to write it back, CALL to send funds. The sender pre-pays an upper bound before the transaction even starts, and unused gas gets refunded. This is a fundamentally different safety model than a verifier: instead of proving a program can't misbehave, you make misbehaving economically self-limiting. An infinite loop doesn't hang the network — it just burns through the caller's gas and reverts, at their expense.

4. Account-Based State and Why Everything Runs in Order

Ethereum's state is a giant key-value mapping — accounts to balances, contract storage slots to values — represented as a Merkle Patricia Trie so any node can cryptographically prove the current state root. Crucially, a transaction doesn't declare up front which storage slots it's going to touch. It just runs, and reads/writes whatever it wants as it goes, including calling into other contracts that touch state you couldn't have predicted ahead of time.

That's the detail that quietly determines Ethereum's entire concurrency story. If you don't know in advance what a transaction will touch, you can't safely run two transactions at once without risking a race on shared state. So the EVM, as a base protocol, executes transactions strictly sequentially, one at a time, in block order. Parallel execution research exists (both inside and outside core Ethereum client teams), but it's an optimization bolted on after the fact, not a property the VM was built around.

This is precisely the constraint Solana's Sealevel runtime sidesteps — by requiring transactions to declare their account access lists upfront, Solana's runtime can prove non-overlap before execution and schedule accordingly. That's not a coincidence; it's a direct response to this exact bottleneck.

Why It's Built This Way

None of this is Ethereum "doing it wrong." A stack machine with no JIT, gas-metered instead of statically verified, sequential by default — every one of these was the correct trade-off for a network whose founding problem was trustless consensus among strangers, not raw throughput. Determinism and auditability were the product. Speed was never the spec.

That's exactly the gap Solana's architects looked at and decided to close from a completely different direction — not by making a better stack machine, but by throwing the stack-machine model out and grabbing a register-based, hardware-native VM that Linux had already spent two decades optimizing. What that actually involved — stripping the kernel verifier, zero-copy account access, AOT compilation to native code, and the account-declaration trick that unlocks parallelism — is the subject of the piece this one precedes.

If you haven't read it yet: From Packet Filter to High-Performance Execution Layer: How Solana Re-Engineered BPF.

Kill the Server: Why Holepunch Threw Away Node.js and Built 'Bare'

Aniket Misra — Sat, 11 Jul 2026 03:07:00 +0000

When the Holepunch team set out to build Pear—a decentralized, peer-to-peer application runtime—they started with the obvious choice: Node.js.

Node is the undisputed king of JavaScript outside the browser. It has a massive ecosystem, a battle-tested asynchronous event loop (libuv), and the raw execution speed of Google's V8 engine. It seemed like the perfect foundation for a P2P stack.

But as they dug deeper into cross-platform routing, NAT traversal, and mobile embedding, they hit a fundamental architectural roadblock: Node.js makes too many assumptions, and the biggest assumption it makes is that you are running a server.

Node was built for the data center. It carries decades of legacy APIs (http, net, tls) that are tightly coupled to centralized, client-server web architecture. When you want to build a purely peer-to-peer, serverless network where devices connect directly via a Distributed Hash Table (DHT), all of that built-in Node bloat becomes dead weight.

So, they did what any obsessive systems engineering team does. They stripped Node down to its studs, threw away the bloated standard library, and built Bare.

Here is a technical look at the Bare runtime, and why throwing away Node’s HTTP assumptions is the key to true P2P applications.

1. Deconstructing the Runtime: What is Bare?

At its core, Bare is a minimalist JavaScript runtime designed specifically for desktop, mobile, and IoT embedding.

It keeps the best parts of Node's foundational architecture but aggressively decouples the JavaScript engine from the system APIs.

[ Traditional Node.js Stack ]        [ The Bare Runtime Stack ]
┌─────────────────────────┐          ┌─────────────────────────┐
│     User Application    │          │     User Application    │
├─────────────────────────┤          ├─────────────────────────┤
│ Node Standard Library   │          │     Userland Modules    │
│ (http, fs, net, crypto) │          │ (HyperDHT, Hyperdrive)  │
├─────────────────────────┤          ├─────────────────────────┤
│    Node C++ Bindings    │          │           Bare          │
├────────────┬────────────┤          ├────────────┬────────────┤
│     V8     │   libuv    │          │    libjs   │   libuv    │
└────────────┴────────────┘          ├────────────┴────────────┤
                                     │V8/ QuickJS / JerryScript│
                                     └─────────────────────────┘

Notice the key difference at the bottom of the stack: libjs.

Node is rigidly bound to Google’s V8 engine. Bare abstracts the JavaScript engine behind a C-API wrapper called libjs. This is a massive systems-level advantage. While Bare runs V8 by default for desktop performance, libjs allows developers to swap out the engine entirely. If you are deploying a P2P application to a highly constrained LTE router or a microcontroller, you can swap V8 for lightweight engines like QuickJS or JerryScript without changing the core runtime architecture.

2. The Missing Standard Library (A Feature, Not a Bug)

If you install Bare and try to spin up a quick web server, it will fail:

// This works in Node. It fails in Bare.
const http = require('http'); 
// Error: Cannot find module 'http'

Bare intentionally ships with almost nothing. There is no http. There is no net. There is no crypto.

Why? Because in a true peer-to-peer architecture, standard HTTP is an anti-pattern. If you rely on http, you are relying on DNS routing, centralized Certificate Authorities (TLS), and exposed public IP addresses.

Instead of forcing a heavy standard library into the binary, Bare leaves feature implementation entirely to userland modules. The runtime provides only three core primitives:

1.A module system (with bidirectional CJS and ESM interoperability).

2.A native addon system (for linking low-level C/C++ libraries).

3.Lightweight threads (with SharedArrayBuffer support).

Everything else is imported a-la-carte. When you want to build a network connection in Bare, you don't use http. You use Holepunch's hyperdht, utilizing cryptographic keys instead of IPs.

3.Bare-Metal Embedding (Desktop to Mobile)

Node is notoriously difficult to embed cleanly into mobile applications. If you want to run a Node instance inside an iOS app, you end up wrestling with massive binaries, battery drain, and messy IPC (Inter-Process Communication) bridges.

Because Bare shed the standard library, its memory footprint is drastically reduced. It treats mobile as a first-class citizen.

Through Bare Kit, developers can spin up "worklets"—isolated Bare threads running directly inside native mobile frameworks (SwiftUI for iOS, or Android Services).

// Spawning a Bare worklet for background P2P sync
import { Worklet } from 'bare-kit'

const syncThread = new Worklet('/hyperdrive-sync.js')

syncThread.on('message', (msg) => {
  console.log('Mobile UI received state update from P2P swarm:', msg)
})

syncThread.postMessage({ command: 'START_SYNC' })

This allows a React Native or Swift frontend to offload all the heavy lifting—DHT routing, UDP hole punching, and data replication—to a highly efficient, native background thread that won't freeze the mobile UI.

The Takeaway: Stop Building Servers

When you look at Bare, you realize that the Node.js architecture we’ve been using for 15 years has subtly brainwashed us. We assume that writing backend JavaScript inherently means writing server logic.Bare proves that JavaScript can be used for something far more resilient. By stripping away the bloated legacy of the Web2 data center, Holepunch has created a runtime that actually belongs on the edge. It forces you to stop thinking about endpoints and status codes, and start thinking about swarms, peers, and cryptographic tunnels. If you want to build systems that governments can't block and cloud providers can't crash, you have to kill the server. Bare is the runtime designed to do exactly that.

The Dark Art of UDP Hole Punching: How to Build a Serverless Web

Aniket Misra — Fri, 10 Jul 2026 19:57:35 +0000

If you want to build a truly decentralized application—one that doesn't rely on AWS, Vercel, or a centralized RPC node—you immediately run into a brick wall of network physics.

You want User A to talk directly to User B.
The problem? Neither of them has a public IP address.

Because we ran out of IPv4 addresses decades ago, ISPs placed almost every consumer device on earth behind a NAT (Network Address Translation) router. NAT is a one-way mirror. You can send outbound requests to a public server, and the router will allow the response back in. But if an external device tries to initiate a connection with you, the NAT drops the packet immediately. It assumes it is hostile.

This single piece of hardware killed the peer-to-peer internet.

To build a sovereign, serverless application layer (like what Holepunch and Pear are doing), you have to bypass the NAT. You have to trick the router into letting inbound traffic through. This technique is called UDP Hole Punching.

Here is the architectural deep dive into how it works, and how modern cryptographic routing makes it scalable.

1. The Mechanics of the "Hole Punch"

Unlike TCP, which requires a rigid 3-way handshake, UDP is connectionless. It just fires raw datagrams into the void.

When your laptop sends a UDP packet to an external server, your NAT router intercepts it, temporarily maps your local IP/port to its public IP/port, and adds a record to its State Table. For the next 30 to 60 seconds, it leaves a "hole" open. If any UDP packet hits that specific public port, the NAT assumes it is a valid response and forwards it to your laptop.

If Alice and Bob are both behind strict NATs, they cannot ping each other. But if they coordinate, they can exploit the state table.

The Signaling Phase: Alice and Bob both connect to a third-party relay to discover their own respective public IP addresses and ports.
The Simultaneous Strike: Alice fires a UDP packet directly at Bob's public IP. Bob fires a UDP packet directly at Alice's public IP.
The Rejection: Alice's first packet hits Bob's router and gets instantly dropped, because Bob's router hasn't opened a hole yet.
The Breakthrough: But when Alice fired that packet, her router opened a hole, expecting a response from Bob's IP. A millisecond later, Bob's packet arrives at Alice's router. Because the IP and port match the state table, the router lets it through.

The hole is punched. Alice and Bob now have a direct, peer-to-peer data stream.

[Alice's Laptop] ──► (Local Port 3000)
       │
 [Alice's NAT] ────► Opens Hole: Public IP A, Port 50000 
       │ 
       ▼ (Direct UDP Stream) ▲
       │                     │
 [Bob's NAT] ◄─────► Opens Hole: Public IP B, Port 60000
       │
[Bob's Laptop] ◄─── (Local Port 4000)

2. The Holepunch Architecture: Cryptographic Routing

In traditional WebRTC architecture, the "Signaling Phase" requires centralized infrastructure: STUN servers (to find your public IP) and TURN servers (to relay traffic if hole punching fails). If you use STUN/TURN, you are back to relying on centralized cloud providers.The brilliance of the Holepunch stack (and its underlying engine, Bare) is that it throws out STUN and TURN entirely. Instead, it uses HyperDHT, a Kademlia-based Distributed Hash Table. In this architecture, your public cryptographic key is your IP address.

1.When Alice boots her application, she joins the DHT. The decentralized nodes in the DHT naturally observe her public IP and port, effectively doing the job of a STUN server without corporate ownership.

2.She announces her 32-byte public key (ed25519) to the swarm.
3.When Bob wants to connect, he doesn't query a DNS server. He searches the DHT for Alice's public key.
4.The DHT nodes coordinate the UDP hole punch. Once the connection is established, Alice and Bob perform a Noise IK handshake to generate a direct, end-to-end encrypted tunnel.

Visit documentation

3. The Code: Bare-Metal P2P

Because Holepunch uses the Bare runtime (stripping away Node.js's heavy HTTP server legacy), establishing this encrypted, serverless connection takes mere lines of code.

Here is what establishing a serverless, hole-punched P2P connection looks like using hyperdht:
Alice (The Target):

import DHT from 'hyperdht'

const node = new DHT()
const keyPair = DHT.keyPair() // Cryptographic identity

const server = node.createServer(socket => {
  console.log('Direct encrypted P2P stream established!')

  // The socket is a standard duplex stream. 
  // No server required.
  process.stdin.pipe(socket).pipe(process.stdout)
})

await server.listen(keyPair)
console.log('Listening on Public Key:', keyPair.publicKey.toString('hex'))

Bob (The Dialer):

import DHT from 'hyperdht'

const node = new DHT()
const alicePubKey = Buffer.from('<ALICE_PUBLIC_KEY_HEX>', 'hex')

// The DHT locates Alice, orchestrates the UDP hole punch, 
// and establishes the Noise IK encrypted tunnel natively.
const socket = node.connect(alicePubKey)

socket.on('open', () => {
  console.log('Punched through NAT. Connected to Alice.')
})

process.stdin.pipe(socket).pipe(process.stdout)

The Unstoppable Web

By utilizing UDP hole punching and a cryptographic DHT, you remove the ultimate single point of failure in modern architecture: the data center.

You cannot DDoS a network where every user is dynamically routing traffic. You cannot de-platform an application that has no static IP to block. When we talk about true decentralization, it isn't just about putting a financial ledger on a blockchain; it is about reclaiming the physical routing layer of the internet.

The Tether Paradox: Shitty ERC-20s, OpenZeppelin, and the Unstoppable Web

Aniket Misra — Fri, 10 Jul 2026 18:24:31 +0000

I have a confession to make. When I first saw that Tether—the behemoth behind the $110 billion USDT stablecoin—was the primary financial backer of Holepunch, Keet, and the Bare JavaScript runtime, my brain short-circuited.

I struggled with the cognitive dissonance. Why? Because if you have ever written a smart contract that interacts with USDT on Ethereum Mainnet, you know it is an absolute nightmare.

Before we can talk about Tether’s brilliant vision for a decentralized, serverless future, we have to talk about the trauma they inflicted on a generation of Solidity developers.

1. The Original Sin: USDT is not actually an ERC-20

When you are deep in protocol-level engineering, you rely on standards. EIP-20 explicitly states that a token's transfer and transferFrom functions must return a boolean value to indicate success or failure.

// The standard EIP-20 Interface
interface IERC20 {
    function transfer(address to, uint256 amount) external returns (bool);
}

Tether completely ignored this. When they deployed the USDT contract, they omitted the return value entirely. Their functions return void.

// The actual USDT Mainnet Implementation (simplified)
function transfer(address to, uint value) public {
    // ... logic ...
    // Notice: No return statement.
}

If you blindly write a vault or a swap contract using the standard IERC20 interface to move USDT, your transaction will seamlessly execute the logic, move the funds, and then violently revert at the very last microsecond.

Why? Because modern Solidity uses a strict ABI decoder. When your contract calls USDT.transfer(), the EVM executes a low-level CALL. When the call finishes, Solidity checks the RETURNDATASIZE. Since it expects a bool (32 bytes), but USDT returns absolutely nothing (0 bytes), the decoder panics and reverts the entire transaction.

For years, the only way to build DeFi safely with USDT has been to wrap it in OpenZeppelin's SafeERC20 library, which uses low-level assembly to explicitly check the return data size and bypass the strict ABI decoding:

import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";

contract Vault {
    using SafeERC20 for IERC20;
    IERC20 public usdt;

    function deposit(uint256 amount) external {
        // We have to use safeTransferFrom because USDT is non-compliant
        usdt.safeTransferFrom(msg.sender, address(this), amount);
    }
}

So, imagine my skepticism. The company that deployed a non-compliant proxy contract that breaks standard EVM interfaces is now funding the most radical, bare-metal, peer-to-peer web infrastructure of the decade?

It felt like a bad joke. Until I looked at the system architecture.

2. The Geopolitics of Decentralized Routing

Tether isn't funding Holepunch out of the goodness of their hearts. They are doing it out of existential necessity.

Look at the architectural dependency graph of the modern financial system. Tether has achieved incredible product-market fit; USDT is the shadow dollar of the global south. But no matter how secure the Ethereum, Tron, or Solana blockchains are, the access layer to those blockchains is controlled by a tiny cartel of Web2 tech monopolies.

[ Traditional Web3 Access Flow ]

User Wallet (Browser) 
      │
      ▼
Cloud-Hosted React Frontend (AWS / Vercel) ──► DNS Providers (Cloudflare)
      │
      ▼
Centralized RPC Node (Infura / Alchemy)
      │
      ▼
The Blockchain (Decentralized)

If a sovereign state decides to sanction Tether, they don't have to attack the blockchain. They just force Amazon Web Services to drop the frontend hosting, force Cloudflare to revoke the DNS, and force Infura to block the RPC requests. The blockchain keeps ticking, but the users go dark.

This is the exact vulnerability Tether is actively engineering out of existence.

3. Holepunch: Bypassing the Cloud

By funding the Bare runtime and the Holepunch protocol, Tether is building an application delivery layer that completely bypasses centralized cloud infrastructure.

The Bitfinex Blog

Instead of hosting a trading terminal on AWS, Tether can build a financial application where the binary, the UI, and the data are seeded via Hyperdrive (a BitTorrent-like distributed file system).

When a user opens the application, they connect directly to other users via a Kademlia Distributed Hash Table (DHT). There is no DNS. There is no cloud server.

[ Holepunch P2P Access Flow ]

Peer A (User) ◄──────── (Noise IK Handshake via UDP) ────────► Peer B (User)
      │                                                           │
      └──► Local Application Logic & State (Seeded via DHT) ◄─────┘

This isn't a blockchain. There is no global consensus, no blocks, and no gas fees. It is simply raw, encrypted, peer-to-peer data replication. Tether is building this to ensure that even if every cloud provider on earth blacklists them, people can still download, run, and communicate through their financial terminals.

The Architect's Realization

I spent hours frustrated by Tether's sloppy smart contract engineering. But looking at their macro-architecture, I have to respect the pivot.

They realized that putting a stablecoin on a decentralized ledger is completely useless if the physical wires connecting the users are owned by three centralized corporations. They are funding a non-blockchain JavaScript runtime because they understand that true decentralization requires severing the dependency on the server entirely.

We spend our time optimizing Solidity gas down to the byte and debating EVM storage slots. But if we don't start thinking about how our applications are actually distributed, we are just building decentralized sandcastles inside a centralized walled garden.

The Great Web3 Lie: AWS, Infura, and the Return of True Peer-to-Peer

Aniket Misra — Sat, 04 Jul 2026 18:26:20 +0000

There is a glaring, uncomfortable hypocrisy at the heart of modern Web3 engineering, and we all collectively agree to ignore it.

We preach the gospel of the "unstoppable web." We write endless threads about censorship resistance, decentralized consensus, and sovereign infrastructure. We build brilliant, mathematically flawless zero-knowledge circuits and deploy them to immutable ledgers.

And then, to actually let users interact with our cryptographic masterpieces, we wrap them in a React frontend, deploy it to Vercel, and route the transactions through an Infura RPC endpoint running on Amazon Web Services.

If a centralized cloud provider decides to pull the plug on a data center in us-east-1, half of the "unstoppable" decentralized web goes completely dark. We haven't actually decentralized the internet; we have just decentralized the backend database while leaving the entire application delivery mechanism firmly in the hands of three massive tech monopolies.

This architectural dissonance has been bothering me for a while. It is what happens when a financial movement (crypto) hijacks an architectural movement (distributed systems). But while digging through alternative runtimes outside of the EVM and Solana ecosystems, I stumbled onto something profoundly disruptive. It isn't a blockchain. It has no token. But it solves the exact infrastructural vulnerability that Web3 ignores.

It is a stack built by Holepunch—specifically, the Pear Runtime and its underlying engine, Bare.

When you strip away the marketing, Pear is essentially a modern, hyper-optimized resurrection of the 1990s BitTorrent ethos, applied directly to application development. It forces us to ask a terrifying question: what if true decentralization doesn't require global consensus at all?

To understand why this is so subversive, you have to look at the traditional deployment model. When you build a modern application, you assume the existence of a server. Even Node.js and Deno fundamentally assume they are running on a machine that will sit in a data center, listen on a port, and serve state to thin clients over HTTP.

The Holepunch architecture violently rejects this premise.

When you build an app on Pear, there is no web server. There is no cloud hosting. The application’s source code, assets, and state are distributed via Hyperdrive, a secure, real-time distributed peer-to-peer file system. When a user "downloads" a Pear application, they aren't fetching it from AWS; they are fetching the encrypted pieces from other users who are currently running the app.

The moment you open the application, you become a seeder. The deployment infrastructure scales infinitely, automatically, and at zero cost, entirely powered by the aggregate compute of the users themselves. It is serverless, not in the sanitized AWS Lambda sense of the word, but in the literal, anarchic Napster sense.

Under the hood, this requires a complete teardown of standard networking. You cannot rely on DNS to find a server that doesn't exist. Instead, Holepunch relies on Hyperswarm and a Kademlia-based Distributed Hash Table (DHT). In this architecture, cryptography isn't used to reach a global financial consensus; it is used purely for routing. Your public cryptographic key becomes your global, static IP address. Devices perform a Noise IK handshake across the DHT, punch through their local NAT firewalls via UDP, and establish a direct, end-to-end encrypted tunnel.

To make this viable, they had to ditch Node.js. Node is too bloated, carrying decades of legacy APIs designed for centralized web servers. Instead, they built Bare—a stripped-down, modular C-based JavaScript runtime. Bare throws away the HTTP server assumptions. It keeps the V8 engine and the asynchronous event loop, but optimizes entirely for low-level, peer-to-peer data streams across desktop and mobile.

This architecture fundamentally alters the threat model of the web. You cannot DDoS an application that has no central server. A government cannot compel a cloud provider to take down a user interface if that interface is being seeded dynamically by thousands of autonomous laptops across the globe.

Web3 promised us an apocalypse-proof internet, but handed us a decentralized ledger heavily tethered to Silicon Valley cloud infrastructure. Seeing a stack like Pear proves that the actual missing layer of the "unstoppable web" was never about consensus mechanisms or tokenomics. It was about raw data availability.

It turns out, if you want to build truly sovereign software, you have to stop trying to put the server on the blockchain, and simply kill the server altogether.

Next time, I am going to dive deeper into why the company behind the $100 billion stablecoin USDT (Tether) is the one secretly bankrolling this entire non-blockchain JavaScript ecosystem, because the geopolitical implications of that are wild.

The Architecture Spiral: RPC, SQL, and the Myth of Linear Evolution

Aniket Misra — Wed, 01 Jul 2026 12:42:20 +0000

If you sit in on enough system design meetings, you inevitably witness the exact same debate play out on a repeating loop. It usually starts when a team is breaking down a monolithic backend and trying to figure out how the new microservices should talk to each other.

Someone suggests standard REST. It’s stateless, ubiquitous, and deeply understood.
Then, a more performance-minded engineer interjects: "JSON over HTTP/1.1 is too heavy for internal service-to-service chatter. We need strict contracts and lower latency. Let's use gRPC."

It feels like a hyper-modern debate—the battle-tested standard of the 2010s versus the cutting-edge, high-performance tooling of the 2020s.

But if you zoom out, the illusion of modern innovation shatters. Remote Procedure Call (RPC) isn't new. It was conceptualized in the 1970s and standardized in the 1980s. We aren't inventing a new way for computers to communicate; we are just resurrecting a 50-year-old paradigm, dressing it in Protobufs, and multiplexing it over HTTP/2.

This is the quiet truth of software engineering: Technological progress is not a straight line. It is a spiral.

We rarely invent entirely new architectures. Instead, we revisit the exact same fundamental concepts, just one layer higher on the Z-axis of abstraction.

1. The REST vs. RPC Pendulum

To understand the spiral, look at how we got to REST in the first place.

In the late 90s and early 2000s, RPC implementations (like CORBA, DCOM, and SOAP) were miserable. They were tightly coupled, brittle, and notoriously difficult to debug across different languages. If a developer updated a method signature on a server, clients across the network would immediately fracture.

Roy Fielding’s REST (Representational State Transfer) won the web because it provided the ultimate decoupled escape hatch. Instead of executing remote actions, clients interacted with remote resources using standardized, predictable HTTP verbs. It was beautiful, cacheable, and heavily adopted.

But as we transitioned into the era of distributed microservices, REST hit a wall. When you have 40 internal services pinging each other to fulfill a single user request, the overhead of parsing massive JSON payloads and managing stateless HTTP connections becomes a devastating bottleneck.

So, what did we do? We went right back to RPC.

We realized that for internal, tightly-bound systems, we actually wanted strict coupling. We wanted type safety. We wanted binary serialization. Tools like gRPC and tRPC dominate modern backend discussions not because they are conceptually novel, but because they are the 1980s RPC architecture built with 2020s infrastructure.

2. The Return of the Relational Database

You can see this same spiral evolution in data storage.

If you were building a startup around 2012, you were explicitly told that relational databases were legacy tech. "SQL is dead," the thought leaders said. "Schema-less NoSQL is web-scale." We poured billions of dollars into document stores like MongoDB and wide-column stores like Cassandra, convinced that abandoning the rigid constraints of tables and foreign keys was the only way to achieve horizontal scalability.

Fast forward to today. What is the default, undisputed king of databases? PostgreSQL.

Not only has SQL made a dominant comeback, but the very NoSQL databases that tried to kill it have spent the last five years desperately bolting SQL-like query languages onto their engines.

Why did this happen? Because Edgar F. Codd’s "Relational Model of Data," published in 1970, wasn't just a technological trend. It was based on fundamental relational algebra. The math was always correct. The only problem in the 2010s was that the underlying storage engines struggled to distribute that math across multiple physical servers.

Once engineers figured out how to build distributed, globally consistent relational engines (like Google Spanner or CockroachDB), the need for NoSQL evaporated for 95% of use cases. We went right back to SQL.

3. Mainframes to Edge: The Physics of Compute

Perhaps the most massive spiral is where compute actually happens.

The 1970s (Centralized): The era of the Mainframe. Massive central computers handled all the logic. Users interacted via "dumb terminals" on their desks that did nothing but render the output.
The 1990s (Decentralized): The era of the Personal Computer. Moore’s Law made chips cheap. We moved compute away from the center and put it directly on the user's desk.
The 2010s (Centralized): The era of the Cloud. We realized managing thousands of local machines was a nightmare. So, we moved the compute back to massive centralized data centers (AWS, GCP). Our high-powered laptops essentially became very expensive, glowing dumb terminals for web browsers.
The 2020s (Decentralized): The era of the Edge. The cloud is now too slow for AI inference and high-performance UX. So, via WebAssembly (Wasm), local-first databases (SQLite in the browser), and edge networking, we are pushing the compute right back down to the user's local machine.

Mainframe to PC. Cloud to Edge. It is the exact same architectural breath, inhaling and exhaling across decades.

Why the Spiral?

Why do we constantly go backwards to move forwards? Is it just a lack of imagination? Are we victims of sunk cost, clinging to the paradigms we learned in university?

No. The spiral exists because software architecture is ultimately bound by physical reality.

We are constantly negotiating between conflicting, immutable constraints: the speed of light (network latency), the cost of silicon (compute power), and the CAP theorem (consistency vs. availability).

When we invent a "new" paradigm, we are usually just optimizing for one of these constraints by willingly sacrificing another. When we moved to NoSQL, we sacrificed consistency for availability. When we moved to the Cloud, we sacrificed latency for centralized management.

Eventually, we push a paradigm to its absolute breaking point. We hit the physical limit of what it can do. And the only way out is to flip the trade-off, looking back into the past for the architecture that optimized for the exact thing we are now starving for.

We aren't failing to innovate. We are just maturing. We are slowly realizing that the engineers of the 1970s weren't primitive; they were dealing with the exact same fundamental laws of computer science that we are. We just happen to have faster Wi-Fi.

The Rhythm of the Primitives: Cryptography, Poisson, and the False Memory of the 90s

Aniket Misra — Tue, 30 Jun 2026 18:28:59 +0000

When we look back at the 1990s, our collective cultural memory betrays us. We retroactively paint the decade as an era of primitive digital toys—a neon-tinted landscape of screeching dial-up modems, bulky pagers, and kids feeding pixelated Tamagotchis. We treat it like the infancy of the digital age, a time before real engineering took hold.

But a funny thing happens when you step away from modern abstractions, sit down with a Rust compiler, and read Satoshi Nakamoto’s 2008 whitepaper in its original context. The illusion shatters. You realize that the foundational architecture of decentralized consensus wasn't invented in the wake of the 2008 financial crisis. Every single piece of the cryptographic puzzle was already breathing, compiling, and thriving in that exact "primitive" decade.

Satoshi didn't invent Web3. He was just the ultimate systems integrator.

Digging into the cypherpunk archives of early Usenet groups is like walking into an ancient library and finding the blueprints for a spaceship. The intellectual breeding ground for decentralized technology was fully formed while the rest of the world was struggling to load JPEGs. The concept of sovereign-less "electronic money" was relentlessly debated. Wei Dai’s B-money and Nick Szabo’s Bit Gold laid the philosophical groundwork. The data structures required to keep a ledger lightweight—Merkle Trees—had already been patented by Ralph Merkle back in 1979.

The missing link was always sybil resistance. How do you stop a malicious actor from spinning up a million fake identities to rewrite the ledger? The answer was sitting in 1997 with Adam Back’s Hashcash. Hashcash wasn't designed for global finance; it was a clever, brute-force hack to make email spam economically unviable by forcing a computer to expend CPU cycles to calculate a cryptographic hash.

Satoshi took this anti-spam mechanism, lifted it from the forgotten corners of the 90s internet, and weaponized it into the heartbeat of global consensus.

But where the whitepaper transitions from a clever engineering integration into an absolute masterpiece is in its mathematical rigor. Satoshi didn't just theorize that a decentralized network was secure; he proved it statistically. In the quietest, most devastatingly elegant section of the paper, he addresses the system's core vulnerability—a 51% attack—by framing it as a Binomial Random Walk.

It is the classic Gambler’s Ruin problem applied to global finance. If an honest node has a probability (p) of finding the next block, and a malicious attacker has a probability (q, which is 1-p, that is, unless we are in a universe with probabilities>100%), the math becomes a beautiful, brutal reality. Because block discovery is probabilistic, Satoshi maps the attacker's potential progress to a Poisson distribution.

He proves, with cold mathematical certainty, that as long as honest nodes control more CPU power (p > q), the probability of an attacker successfully rewriting history drops exponentially with every passing block. It is a masterpiece of statistical poetry. He built a trustless system by mathematically proving that betrayal is too expensive.

Uncovering these anachronisms in technology—realizing that the heavy cryptographic lifting was happening parallel to the Tamagotchi—triggered a weird cognitive dissonance. It made me question what else I was misremembering about that era. Being a musician, I naturally turned to the rhythm of the decade.

For my entire life, I have retrospectively framed the 90s as the decade of relentless, underground Eurotechno. In my head, the soundtrack of that era was an endless loop of Haddaway’s "What is Love" thumping out of a dark, synthesized European club basement. I equated the 90s with the four-on-the-floor kick drum of early electronic dance music.

I was completely wrong. Look at the actual cultural footprint of the decade. It wasn't defined by cold European synthesizers; it was a massively hispanophile era. The Macarena didn't just exist; it conquered the globe. Latin pop exploded into the global mainstream. The rhythm of the decade was fundamentally organic, percussive, and intensely Latin. The aesthetic I had projected onto the past was a complete fabrication.

This historical unearthing has bled into my own physical reality. I’ve realized that my own rhythms need a structural shift. The tabla is a beautiful, complex instrument, and it will always be a part of my percussive foundation. But you cannot lug a heavy set of brass and wood up a mountain on a hike. It is geographically anchoring.

So, I’m reviving my old school assembly chops. I am packing up the bongos. They fit in a backpack. They carry that organic, Afro-Cuban groove that actually defined the era I’ve been misremembering. And to make sure I’m not just an isolated rhythm section on the trail, I’ve picked up a harmonica to build out some melodic grit.

Afro-Cuban percussion and delta Blues are officially on. It turns out, whether you are integrating 1990s cypherpunk primitives to build decentralized state machines, or blending bongos with a blues harp on a hiking trail, the magic is never in inventing something entirely new. The magic is in the assembly.

Time to get back to the Rust compiler.

The Architecture of Trust: Reading Satoshi’s Whitepaper in an Era of Category Errors

Aniket Misra — Tue, 23 Jun 2026 20:26:28 +0000

Immediately after putting down my Rust compiler, I did something I should have done years ago: I sat down and read Satoshi Nakamoto’s original 2008 Bitcoin whitepaper from start to finish.

If you spend any time in the modern Web3 ecosystem, opening that 11-page document is an absolute culture shock.

There are no modern buzzwords. You won't find the terms "blockchain," "smart contracts," "layer-2s," "tokenomics," or "decentralized applications." Instead, you are met with a masterclass in pragmatic, systems-level engineering terminology. Nakamoto doesn't write like a venture capitalist or a hype-merchant; he writes like a practical systems architect solving a structural database flaw.

1. The Simplistic Language of a Systems Engineer

The language of the whitepaper is strikingly plain, almost archaic by today’s standards. What we now call a blockchain, Satoshi simply calls a "peer-to-peer distributed timestamp server."

[ Transactions ] ──► [ Hashed into a Block ] ──► [ Timestamped ] ──► [ Broadcast to Network ]

plaintext

He doesn’t rely on abstract philosophy to justify the system. He frames the entire invention around a single, concrete engineering problem: eliminating the double-spending problem without relying on a trusted third party.

The beauty of the whitepaper lies in how it constructs a massive trust network entirely out of simple, existing components:

A chain of digital signatures to track ownership vectors.
A Proof-of-Work hash puzzle (borrowed from Adam Back's Hashcash) to achieve distributed consensus.
An incentive loop (block rewards and transaction fees) to align the self-interest of independent hardware operators with the security of the network.

Satoshi’s genius wasn't inventing a single new cryptographic primitive; it was the brilliant coordination of existing primitives into an elegant, self-sustaining loop. It is a reminder that great architecture isn't about complexity—it’s about minimizing structural dependencies.

2. Has Modern Banking Fixed its 2008 Structural Flaws?

Satoshi famously carved the message "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" into Bitcoin's genesis block. It was a direct response to the systemic counterparty risk that triggered the 2008 financial crisis.

Nearly two decades later, the question arises: has modern commercial banking actually solved the structural vulnerability that Bitcoin was built to bypass?

From a technical and regulatory standpoint, the system has introduced massive patches:

Basel III & IV Compliance: Imposing significantly higher capital reserve requirements, stricter liquidity ratios, and rigorous stress-testing on global systemically important banks (G-SIBs).
Real-Time Gross Settlement (RTGS): Systems like FedNow or instant-payment rails have optimized transaction speed, reducing the clearing windows where systemic settlement risk can accumulate.

But beneath these operational optimizations, the fundamental architecture remains unchanged. The modern banking system still runs on fractional reserves, ledger opacity, and centralized, institutional trust layers. As we saw during the banking failures of early 2023 (Silicon Valley Bank, Signature Bank, Credit Suisse), risk hasn't been engineered out of the system; it has simply been heavily managed, subsidized, and backstopped by central bank liquidity. When confidence drops, the centralized ledger remains vulnerable to old-school bank runs, accelerated by modern digital speeds.

3. The Category Error: Demanding Trustlessness from Commercial Systems

This brings us to a fundamental architectural misunderstanding often made when comparing traditional finance (TradFi) to decentralized protocols: looking for "trustlessness" in a non-blockchain commercial banking system is a complete category error.

Commercial banking and public blockchains are built on entirely distinct, non-overlapping design philosophies.

┌─────────────────────────────────┐       ┌─────────────────────────────────┐
│     COMMERCIAL BANKING L3       │       │       BLOCKCHAIN PROTOCOLS      │
├─────────────────────────────────┤       ├─────────────────────────────────┤
│ • Optimization: Speed & Credit  │       │ • Optimization: Fault Tolerance │
│ • Core Mechanism: Legal Trust   │       │ • Core Mechanism: Computation   │
│ • State: Subjective / Reversible│       │ • State: Objective / Immutable  │
└─────────────────────────────────┘       └─────────────────────────────────┘

Legal Trust vs. Computational Verification

Commercial banking is explicitly engineered to maximize capital efficiency, credit expansion, and transaction throughput. To achieve this, it relies on an architectural layer of subjective trust backed by legal frameworks, identity verification, state enforcement, and human mediation. If a transaction is fraudulent, a centralized authority can manually reverse the state of the ledger. Reversibility requires trust.

Bitcoin and decentralized protocols optimize for fault tolerance, censorship resistance, and absolute settlement finality. To achieve this, they purposefully sacrifice raw speed and capital flexibility. The state transitions are objective—enforced strictly by mathematics and distributed physical computation.

The Conclusion

You cannot build a trustless commercial bank because the moment you introduce credit issuance, debt underwriting, and subjective dispute resolution, you require a centralized trusted human arbiter.

Conversely, the moment you introduce a trusted human arbiter to a blockchain protocol, you break its entire security model.

Reading Satoshi’s whitepaper highlights that Web3 shouldn't try to replicate the subjective, credit-driven architecture of modern commercial systems. Our objective as protocol engineers is to build clean, immutable, deterministic execution environments where trust is completely offloaded to math and code.

This concludes my two-part reflection on systems thinking—from the raw event-driven instincts of a child hacking Lua in a sandbox, to the elegant, buzzword-free architecture laid down by Satoshi in 2008. Time to get back to writing Rust. I'm targeting writing a reverse proxy in rust to get the feel of it, maybe compare it to a similar construct in typescript, and finally clarify my knowledge on reverse proxy vs api gateway vs load balancer by writing them.

The Sandbox Prodigies: Roblox, Event-Driven Logic, and the Future of Engineering

Aniket Misra — Tue, 23 Jun 2026 20:18:17 +0000

A few days ago, my 11-year-old relative showed me a snippet of code he was hacking together for a custom game in Roblox. It wasn't clean, syntactically valid Lua—it was a chaotic, stream-of-consciousness pseudo-script mashed into his editor.

It looked exactly like this:

setmetatable.random.match(rawequal)
config.path=(real.parent)=checkpoint
can collide.(false)
anchored(true)
and then.cooldown=(3)
concat=and then.can run in loop
if parent.control player

If you feed this into a compiler, it throws a syntax error on line one. But if you look past the malformed syntax and analyze the structural intent, it is absolutely fascinating.

An 11-year-old kid is organically reasoning about complex computer science paradigms that university students struggle with in sophomore year systems classes.

Deconstructing the 11-Year-Old's System Design

Look at what is actually happening in that broken snippet:

Metatables and OOP Overrides: He kicks off with setmetatable and rawequal. In Lua, metatables are the underlying mechanism used to implement Object-Oriented Programming, operator overloading, and prototype inheritance. He doesn't know the academic definition of a prototype pattern, but he intuitively understands that he needs to override default behaviors to match specific data conditions.
State Management and Properties: can collide.(false) and anchored(true). He is explicitly manipulating the physics engine properties of a 3D environment—turning off collision matrices and locking spatial vectors in world space.
Asynchronous Flow and Loop Logic: and then.cooldown=(3) followed by concat=and then.can run in loop. This is the most striking part. He is conceptualizing a state machine that handles debouncing (cooldowns), asynchronous continuation (and then resembles a JavaScript Promise abstraction), and recursive execution loops.
Conditional Execution Hooks: if parent.control player. He is defining a conditional interceptor based on an object's hierarchical structural tree to determine identity and execution control.

The Power of the Enshrined Event-Driven Sandbox

What enables a child to reason like this before they even understand basic algebraic geometry? The sandbox environment.

Platforms like Roblox and Minecraft have done something incredible: they have wrapped high-performance, event-driven game engines in low-friction, highly interactive playgrounds. Kids aren't learning programming by printing "Hello World" to a static terminal. They are learning programming by modifying live, reactive systems.

They learn through a pure event-driven feedback loop. They change a property, an object falls through the floor, and they immediately understand the physical consequence of their logic. The event loop is no longer an abstract thread management concept discussed in systems architecture books; it is the concrete reality of their game world.

The Structural Implications on a Future Career

When a kid starts thinking in terms of state manipulation, loops, overrides, and inheritance models at age 11, it completely rewires their cognitive approach to engineering.

By the time this kid sits down in a university or corporate setting, the hard part of software engineering—structural systems thinking—will be second nature. He won't see code as a sequence of text strings; he will see it as a reactive architecture of interlocking components.

Whether he ends up writing low-level protocol engines, designing high-throughput distributed systems, or building smart contracts, or ends up a neovim larper like this guy ThePrimeAgen the foundation is the same. He is already building the mental scaffolding required to manage complex state transitions in public sandboxes.

The tools change, the syntax hardens, but the core engineering instinct remains identical. The sandbox prodigies aren't just playing games—they are subtly training to become the systems architects of tomorrow.

This is Part 1 of a loose series of reflections on how we learn, read, and build systems. Part 2 will dive into a completely different kind of foundational architecture: my recent breakdown of Satoshi Nakamoto's original Bitcoin whitepaper and its surprisingly archaic systems language.

The Pivot: Learning Rust with Intention (Solana, Noir, and Systems-Level Web3)

Aniket Misra — Fri, 19 Jun 2026 18:07:16 +0000

I’m finally learning Rust, but not for the sake of adding another language to my resume. I’m doing it with clear, concrete architectural intentions: to build high-performance smart contracts on Solana and write Zero-Knowledge Proof (ZKP) circuits using Noir.

To transition effectively into low-level protocol engineering, high-level web abstractions won't suffice. You have to understand how memory maps to hardware.

This post marks the start of a public learning thread where I will document my engineering insights, technical hurdles, and core architectural takeaways as I build systems-level Web3 infrastructure. Here is the roadmap and the foundational stack I'm tackling first.

1. The Strategy: No Fluff, Pure Implementations

Learning a language through syntax drills or standard "To-Do app" tutorials is a waste of time. To understand a system, you have to build systems. My learning roadmap is structured around two rigorous phases:

Phase 1: Bare-Metal Fundamentals via Bitcoin

To grasp Rust's ownership model, memory layout, and concurrency paradigms without high-level scaffolding, I am starting with the book "Building Bitcoin in Rust" by Lukas Hozda.

Instead of jumping straight into a framework, this project forces me to build core blockchain primitives from the ground up:

Direct TCP/IP socket networking for peer-to-peer communication.
Implementing low-level cryptographic hashing and serialized script verification.
Manual byte-level manipulation of blocks, inputs, outputs, and mempool mechanics.

By building Bitcoin natively in Rust, I have to fight the borrow checker on structural, multi-threaded networking logic before writing a single line of smart contract code.

Phase 2: Production Protocols via Cyfrin Updraft

Once the raw language mechanics are locked in, I’m shifting directly to advanced smart contract engineering via Cyfrin Updraft. This phase will focus heavily on production-ready patterns, deep-diving into:

The Solana Virtual Machine (SVM): Mastering the account model, program architecture, and severe compute unit optimization.
Noir: Designing private, verifiable Zero-Knowledge circuits and compiling them down to efficient Web3 verification layers.

2. Day 1 Realizations: The Rust Memory Paradigm Shift

Coming from higher-level runtime environments, the immediate realization when writing systems-level Rust is how explicit you must be about data allocations.

When building low-level protocol logic, every byte matters. You are forced to shift your mental model away from implicit garbage collection to explicit memory constraints:

Stack vs. Heap Allocation: Understanding exactly when data can sit on the fast CPU stack versus when it requires dynamic heap allocation (Box, Vec). On high-throughput networks like Solana, minimizing heap allocations is a primary execution optimization strategy.
The Borrow Checker is a Compile-Time Static Analyzer: It isn't a runtime constraint; it is a rigid system that enforces reference safety at compile time. It guarantees data-race-free memory access without the massive runtime overhead of a garbage collector.
Data Serialization: When writing raw bytes across a P2P socket (like in the Bitcoin implementation), data packing and alignment are handled manually. This maps directly to understanding how Solana organizes account data vectors or how ZK circuits handle constraints over finite fields.

Intent to Build in Public

This isn't a diary; it's an engineering log. As I work through this curriculum, I will be posting highly technical breakdowns of specific roadblocks I encounter—covering things like Rust thread synchronization, SVM execution nuances, gas/compute optimization, and ZK proof generation.

If you are currently building with Rust, Solana, or Zero-Knowledge systems, let's connect. Time to open the editor and write the code.

From Packet Filter to High-Performance Execution Layer: How Solana Re-Engineered BPF

Aniket Misra — Sat, 06 Jun 2026 06:14:33 +0000

To understand why Solana can process tens of thousands of transactions per second while maintaining sub-second finality, you have to look past the marketing buzzwords like "Proof of History." The real workhorse of Solana's throughput is its execution layer: the Solana Virtual Machine (SVM).

Unlike Ethereum, which designed a custom, interpreted virtual machine from scratch (the EVM), Solana did something radically practical: they grabbed an existing, heavily optimized Linux kernel technology called BPF (Berkeley Packet Filter) and turned it into an efficient runtime smart contract engine.

Here is how a technology designed to filter network packets in the 1990s became the backbone of a high-performance monolithic blockchain.

1. What is BPF and Why Did Solana Choose It?

Originally introduced in 1992, BPF was designed to analyze and filter network packets directly inside the Linux kernel without copying data across the user-kernel boundary. It evolved into eBPF (Extended BPF), turning the kernel into a programmable environment where developers could run sandboxed bytecode safely at near-native speeds.

When Solana's architects were designing the network, they looked at the landscape of virtual machines and noticed a fatal flaw in traditional blockchain runtimes: they were too high-level, interpreted, and detached from the underlying CPU hardware.

Solana chose a variation of eBPF (termed Solana Bytecode Format or SBF) for three core architectural reasons:

Hardware-Friendly Architecture: BPF’s instruction set maps directly to modern x86-64 and ARM64 CPU instructions. Running a BPF instruction often translates to a single native CPU instruction.
Deterministic Sandboxing: BPF was built from day one to be strictly constrained. It guarantees that code cannot access arbitrary memory or crash the host system—vital for a validator running untrusted untrusted smart contract code.
A Ready-Made LLVM Compiler Toolchain: Instead of inventing a new programming language and building a compiler from scratch, Solana could leverage the massive LLVM infrastructure. This allowed developers to write smart contracts in standard Rust or C and compile them directly down to BPF bytecode.

2. Turning a Packet Filter into a VM: The SVM Modifications

You cannot just drop a standard Linux kernel packet filter onto a global ledger and call it a blockchain runtime. Solana had to modify and extend BPF into SBF (Solana Bytecode Format) to handle the unique demands of state mutation and consensus.

A. Striking Out the In-Kernel Verifier Restrictions

In the Linux kernel, the eBPF verifier is notoriously strict: loops are highly restricted, and programs must statically prove they will terminate quickly to prevent freezing the operating system kernel.

Solana stripped these rigid static analysis constraints. Instead of forcing the compiler to prove a program will terminate before running, Solana introduced a Compute Budget (gas). The VM counts instructions dynamically at runtime. If a contract loops endlessly, it simply runs out of compute units and halts.

B. Serialization and Zero-Copy Memory Access

In standard BPF, data packets are passed into the program via a sequential memory buffer. In a blockchain, a smart contract needs to read and write to global state accounts.

Initially, Solana used a naive serialization mechanism: when a transaction hit a contract, the runtime copied all required account data into a single, contiguous byte array, passed it to the BPF program, and copied the modified data back out to state storage. This serialization overhead was a massive performance bottleneck.

To achieve true performance, the SVM utilizes Zero-Copy Serialization. Using direct memory alignment, the SVM maps the account data layout directly into the BPF virtual machine's memory space. The Rust contract references the data directly in memory via pointers, completely avoiding expensive allocation and copying steps during execution.

C. JIT vs. AOT Compilation

Interpreted virtual machines are slow because every bytecode instruction must be evaluated by software at runtime.

To bypass this, Solana utilizes Ahead-of-Time (AOT) Compilation. When a program is deployed to the cluster, validators compile the BPF bytecode directly into native x86 machine code before it ever executes in a live block. When a transaction calls that program, the validator CPU runs native assembly instructions directly on the bare metal.

3. The Ultimate Superpower: Parallel Execution via Sealevel

The EVM is single-threaded. Because Ethereum transactions do not declare which state storage slots they will touch, the EVM must execute every transaction sequentially to avoid race conditions.

Because Solana's VM is based on a low-level memory model, it requires transactions to explicitly declare a structured list of every account they intend to read or write to before execution begins. This architecture is called Sealevel.

If Transaction A wants to transfer funds from Account 1 to Account 2, and Transaction B wants to swap tokens between Account 3 and Account 4, the Sealevel runtime looks at the accounts, recognizes there is zero overlap, and dispatches them to separate physical CPU cores simultaneously.

[ Incoming Transactions ] 
         │
         ▼
[ Sealevel Static Analysis Engine ]
         │
         ├───► Tx 1 (Accounts A, B) ───► CPU Core 0 (Native BPF Execution)
         │
         └───► Tx 2 (Accounts C, D) ───► CPU Core 1 (Native BPF Execution)

By combining native BPF execution speeds with parallel CPU scheduling, Solana turns the validator's hardware into a highly parallel processing machine.

Conclusion

Solana's performance isn't magic; it is pragmatic systems engineering. By repurposing Linux BPF, the architects of Solana bypassed the need to optimize a custom VM interpreter and inherited decades of hardware-level optimization.

As I dive further into Solana and Rust-based development, understanding how the code maps down to this low-level SBF runtime is essential for maximizing compute efficiency and writing highly optimized smart contracts. In my upcoming posts, I'll be breaking down specific Rust optimization patterns to minimize compute unit consumption within the SVM. Stay tuned.

Architecting Web3 Frontends: Client State vs. Blockchain Server State

Aniket Misra — Sun, 31 May 2026 17:41:34 +0000

In traditional Web2 development, the line between client state and server state is well-defined. You fetch data from a REST or GraphQL API, cache it locally using tools like TanStack Query or Redux Toolkit, and push mutations back to a centralized database.

In Web3, this paradigm breaks down completely. The blockchain is a global, asynchronous, distributed state machine with high latency, probabilistic finality, and variable gas costs. To make matters more complex, your app doesn't just talk to a server; it interacts with a local wallet extension (the client signer), individual RPC nodes, and decentralized indexers.

If you don't cleanly decouple your Client State from your Server (Chain) State, your frontend will suffer from race conditions, out-of-sync UIs, and terrible user experiences. Here is how to architect the split.

1. Client State: Local UI and Wallet Context

Client state is data that lives entirely within the browser memory or local storage. It is synchronous, ephemeral, and changes instantly based on user interaction.

In a Web3 application, client state includes:

UI Toggles: Modals, themes, sidebar states, active tabs.
Form Inputs: Unsubmitted transaction parameters, raw token amounts entered by the user.
Wallet Connection Context: Is the user connected? What is their current address? What chain ID is their wallet currently set to?

The Pitfall: Treating Wallet State as Immutable

A common mistake is storing the user's wallet address in a global Redux or Zustand store and assuming it remains static. Wallets are external actors; a user can change accounts or switch networks directly within their MetaMask or Phantom extension without interacting with your dapp UI.

Architectural Rule: Always treat wallet connection state as an externally managed stream of data. Use reactive hooks (like those provided by wagmi or @solana/wallet-adapter-react) to listen to account changes directly rather than trying to sync them manually into your local state managers.

2. Server State: The Blockchain and Indexers

Server state in Web3 is the global state of the ledger. Unlike a Web2 database, you do not own it, it is not instantaneous, and reading data requires navigating distinct architectural layers.

Web3 server state is split into two categories:

A. Core On-Chain State (The RPC Layer)

This is raw data sitting inside smart contract storage slots (e.g., token balances, protocol parameters, AMM pool liquidity).

The Reality: You fetch this via JSON-RPC calls (eth_call).
The Problem: It is pull-based and discrete. You only get the state at the specific block number you queried. To keep it accurate, you must constantly poll or subscribe to new block events (eth_blockNumber).

B. Indexer State (The Graph / Custom Indexers)

Raw blockchain storage is optimized for execution, not querying. If you need to show a user their historical transaction logs, portfolio performance over time, or filtered NFT metadata, querying an RPC node directly is functionally impossible.

The Reality: You query indexed databases (GraphQL entities via The Graph, or proprietary APIs like Goldsky or Envio).
The Problem: Indexers introduce propagation lag. A transaction might be confirmed on-chain in block $N$, but the indexer might not process that block until seconds later.

3. The Synchronization Gap: Handling Async Mutations

The true engineering challenge lies in the delta between sending a transaction (mutating server state) and the frontend reflecting that change.

When a user executes a smart contract write operation, the state transitions through four distinct phases:

[ 1. Client Signed ] ──► [ 2. Broadcasted (Mempool) ] ──► [ 3. Included in Block ] ──► [ 4. Indexed ]

If your frontend relies solely on reading on-chain state to update the UI, the user will experience a jarring delay after signing a transaction, leading them to believe the app is frozen or the action failed.

Architectural Strategies to Bridge the Gap

1. Decouple Transaction Tracking from State Fetching

Do not block your UI thread waiting for the transaction receipt to fetch new balances. Use explicit transaction notification systems (e.g., toast alerts tracking the transaction hash life cycle) while allowing your data-fetching hooks to handle cache invalidation independently.

2. Optimistic Updates

For low-stakes interactions or fast L2s/L3s, modify the client state immediately to assume success before the transaction is finalized on-chain. If the transaction reverts, roll back the client state to the previous server state snapshot.

3. Smart Cache Invalidation (TanStack Query + Wagmi)

Leverage declarative queries where the query key is tied directly to the current block number or the user’s address. When a transaction succeeds, programmatically invalidate the specific cache keys to force an immediate RPC refetch.

// Example pattern using wagmi & tanstack query
const { writeContractAsync } = useWriteContract();
const queryClient = useQueryClient();

const handleSwap = async () => {
  const txHash = await writeContractAsync({ ...config });

  // Wait for block inclusion
  await waitForTransactionReceipt(config, { hash: txHash });

  // Invalidate the exact server state cache key to trigger an explicit reload
  queryClient.invalidateQueries({ queryKey: ['balance', userAddress] });
};

Conclusion

Building clean Web3 frontends requires recognizing that you do not own the backend database. Your client state must remain lean, highly reactive, and decoupled from the slow asynchronous reality of the blockchain. The server state must be treated as a delayed, eventually consistent cache that requires explicit invalidation strategies.

I will be expanding on these frontend architecture choices as I document the progress of my protocol-level builds. Up next, I'll be looking into performance optimizations when managing high-frequency RPC polling vs. WebSocket subscriptions. Stay tuned.