DEV Community: Aniket Misra

Escaping the Event Loop — A Deep Dive into worker_threads (Part 3/3)

Aniket Misra — Tue, 04 Aug 2026 23:25:00 +0000

In part 1, we built the core stack/microtask/macrotask model. In part 2, we saw how the browser and Node implement that model differently — rendering interleaved with tasks in the browser, libuv's phase-based loop in Node.

Both of those posts share an unspoken assumption: your callbacks are fast. A few milliseconds, do their thing, return, let the loop move on. But what happens when that assumption breaks? What happens when you genuinely need to do slow, CPU-bound work — and there's no I/O to wait on, no callback to defer, just raw computation that has to happen?

That's what this post is about. No amount of clever queue ordering saves you here. You need actual parallelism, and in Node, that means worker_threads.

The problem worker_threads solves

Everything from parts 1 and 2 works because the actual JS execution — the code inside your callbacks — is assumed to be short. The event loop is brilliant at making single-threaded JS feel concurrent when the bottleneck is I/O: waiting on a database, a file read, a network response. While you wait, the thread is free to do other things.

But CPU-bound work is a different beast entirely. Consider this:

function fibonacci(n) {
  if (n < 2) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

const server = require('http').createServer((req, res) => {
  if (req.url === '/fib') {
    const result = fibonacci(40); // this takes a few seconds
    res.end(`Result: ${result}`);
    return;
  }
  res.end('OK');
});

server.listen(3000);

Hit /fib, and for however long that synchronous computation runs, the entire server is frozen. Not just that request — every request. No other client's /OK request gets served, no timers fire, no I/O callbacks run, because the single JS thread is stuck inside fibonacci(40) and the event loop can't do anything until the call stack unwinds.

This is the single most common misunderstanding about Node's concurrency model: async I/O doesn't make your CPU-bound code non-blocking. fs.readFile doesn't block because the actual disk read happens off the JS thread, in libuv's thread pool, and only the (fast) callback runs on the JS thread. But a tight synchronous loop, a big JSON parse, a hash computation, image processing — there's no I/O to hand off. It's just your code, doing math, on the one thread you've got.

You have three tools in Node for genuinely parallel work, and knowing which one to reach for actually matters.

worker_threads vs child_process vs cluster

These get confused constantly because they all sound like "run more stuff at once." They solve different problems.

child_process spawns an entirely separate OS process, potentially running a different program altogether (a shell command, a Python script, another Node script). Full isolation — separate memory space, separate V8 instance. Good for running external programs or when you want maximum isolation (a crash in the child can't take down the parent). Heavier to spin up, and communication happens via serialized IPC (stdin/stdout/message passing) — no shared memory.

cluster is built on top of child_process, specifically for scaling Node servers across multiple CPU cores. It forks multiple copies of your entire Node process, and the OS (or a Node-managed load balancer) distributes incoming connections across them. Great for "I have a web server and want to use all my CPU cores" — but each worker is a full separate process with its own memory, event loop, everything. It's about scaling throughput of independent requests, not about parallelizing a single computation.

worker_threads spawns actual OS-level threads within the same process — lighter weight than a full process, and critically, capable of sharing memory via SharedArrayBuffer. Each worker gets its own V8 instance and its own event loop, so it's still not shared-everything like threads in languages such as Java or C++, but message passing is fast and structured data doesn't need full IPC serialization to a separate process. This is the right tool when you have one chunk of CPU-heavy work you want to offload without blocking the main thread — image processing, cryptographic hashing, parsing a huge file, running a compute-heavy algorithm.

Quick way to decide: scaling a whole server across cores → cluster. Running an external program or needing hard process isolation → child_process. Offloading one CPU-bound task from inside your existing app → worker_threads.

The rest of this post is about that last one.

Anatomy of a worker

A worker is created from the main thread by pointing at a separate JS file:

// main.js
const { Worker } = require('worker_threads');

const worker = new Worker('./worker.js');

worker.on('message', (result) => {
  console.log('Got result:', result);
});

worker.on('error', (err) => {
  console.error('Worker error:', err);
});

worker.on('exit', (code) => {
  if (code !== 0) console.error(`Worker stopped with exit code ${code}`);
});

// worker.js
const { parentPort } = require('worker_threads');

// do some CPU-heavy work here
const result = heavyComputation();

parentPort.postMessage(result);

A few key pieces:

parentPort — the worker's side of the communication channel back to whoever created it. .postMessage() sends data out; listening on parentPort.on('message', ...) receives data in.
workerData — lets you pass initial data into the worker at creation time, instead of messaging it in after startup:

// main.js
const worker = new Worker('./worker.js', {
  workerData: { n: 40 }
});

// worker.js
const { workerData, parentPort } = require('worker_threads');

function fibonacci(n) {
  if (n < 2) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

parentPort.postMessage(fibonacci(workerData.n));

Message passing between main thread and worker uses the structured clone algorithm — the same mechanism postMessage uses in browsers between windows/iframes. It can handle most JS values (objects, arrays, Maps, Sets, dates, even ArrayBuffers by transfer), but not everything — functions and certain non-serializable values can't cross the boundary. Each message is cloned by default, which has a real memory/CPU cost for large payloads — that's part of why SharedArrayBuffer exists, more on that below.

Fixing the frozen server

Let's rewrite the earlier example properly:

// main.js
const http = require('http');
const { Worker } = require('worker_threads');

function runFibWorker(n) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./fib-worker.js', { workerData: { n } });
    worker.on('message', resolve);
    worker.on('error', reject);
    worker.on('exit', (code) => {
      if (code !== 0) reject(new Error(`Worker exited with code ${code}`));
    });
  });
}

const server = http.createServer(async (req, res) => {
  if (req.url === '/fib') {
    const result = await runFibWorker(40);
    res.end(`Result: ${result}`);
    return;
  }
  res.end('OK');
});

server.listen(3000);

// fib-worker.js
const { workerData, parentPort } = require('worker_threads');

function fibonacci(n) {
  if (n < 2) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

parentPort.postMessage(fibonacci(workerData.n));

Now hitting /fib spins up a worker thread to do the computation, and the main thread's event loop stays completely free to keep serving other requests while it waits for the message event. This is the actual fix — not a clever async trick, but real parallel execution on a separate thread.

Don't spin up a worker per request — use a pool

The example above works, but spawning a brand-new Worker (and its own V8 instance) for every single request is expensive — worker startup isn't free. In any real system, you want a worker pool: a fixed set of long-lived workers that pick up jobs from a queue, so you pay the startup cost once and reuse threads across many tasks.

Here's a reasonably complete pool implementation:

// worker-pool.js
const { Worker } = require('worker_threads');
const os = require('os');

class WorkerPool {
  constructor(workerScript, poolSize = os.cpus().length) {
    this.workerScript = workerScript;
    this.poolSize = poolSize;
    this.workers = [];
    this.freeWorkers = [];
    this.taskQueue = [];

    for (let i = 0; i < poolSize; i++) {
      this._addWorker();
    }
  }

  _addWorker() {
    const worker = new Worker(this.workerScript);
    worker.on('message', (result) => {
      const { resolve } = worker.currentTask;
      worker.currentTask = null;
      resolve(result);
      this._takeNextTask(worker);
    });
    worker.on('error', (err) => {
      const { reject } = worker.currentTask || {};
      if (reject) reject(err);
      // Replace the crashed worker so the pool stays at full size
      this.workers = this.workers.filter((w) => w !== worker);
      this._addWorker();
    });
    this.workers.push(worker);
    this.freeWorkers.push(worker);
  }

  _takeNextTask(worker) {
    if (this.taskQueue.length === 0) {
      this.freeWorkers.push(worker);
      return;
    }
    const { data, resolve, reject } = this.taskQueue.shift();
    worker.currentTask = { resolve, reject };
    worker.postMessage(data);
  }

  runTask(data) {
    return new Promise((resolve, reject) => {
      const freeWorker = this.freeWorkers.pop();
      if (freeWorker) {
        freeWorker.currentTask = { resolve, reject };
        freeWorker.postMessage(data);
      } else {
        this.taskQueue.push({ data, resolve, reject });
      }
    });
  }

  async destroy() {
    await Promise.all(this.workers.map((w) => w.terminate()));
  }
}

module.exports = WorkerPool;

// pool-worker.js
const { parentPort } = require('worker_threads');

function fibonacci(n) {
  if (n < 2) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

parentPort.on('message', (n) => {
  parentPort.postMessage(fibonacci(n));
});

// main.js
const http = require('http');
const WorkerPool = require('./worker-pool');

const pool = new WorkerPool('./pool-worker.js');

const server = http.createServer(async (req, res) => {
  if (req.url === '/fib') {
    const result = await pool.runTask(40);
    res.end(`Result: ${result}`);
    return;
  }
  res.end('OK');
});

server.listen(3000);

Sizing the pool to os.cpus().length is a sensible default — one worker per logical core, so you're not oversubscribing the CPU with more compute-bound threads than you have cores to run them on. This pattern (or a maintained library like piscina, which does essentially this with more polish) is genuinely how you'd offload CPU work in production Node.

SharedArrayBuffer and Atomics — when message passing isn't enough

By default, data sent between the main thread and a worker is cloned. For most use cases that's fine, but for large datasets — a big typed array you want multiple workers reading and writing without copying gigabytes back and forth — cloning becomes the bottleneck itself.

SharedArrayBuffer gives you a chunk of memory that's genuinely shared between threads — no cloning, both sides see the same bytes:

// main.js
const { Worker } = require('worker_threads');

const sharedBuffer = new SharedArrayBuffer(4); // 4 bytes = one Int32
const sharedArray = new Int32Array(sharedBuffer);

const worker = new Worker('./increment-worker.js', {
  workerData: { sharedBuffer }
});

worker.on('exit', () => {
  console.log('Final value:', sharedArray[0]); // both threads touched the same memory
});

// increment-worker.js
const { workerData, parentPort } = require('worker_threads');

const sharedArray = new Int32Array(workerData.sharedBuffer);
Atomics.add(sharedArray, 0, 1);
parentPort.close();

Note the use of Atomics.add rather than sharedArray[0]++. This matters: when multiple threads can touch the same memory simultaneously, plain read-modify-write operations are subject to race conditions — two threads can both read the same old value before either writes back, and one increment gets silently lost. Atomics provides operations (add, sub, compareExchange, load, store, and more) that are guaranteed to be indivisible at the hardware level, so concurrent access doesn't corrupt the value. Atomics.wait and Atomics.notify go further, letting threads actually block and signal each other — a real synchronization primitive, not just safe arithmetic.

This is a genuinely deep topic on its own — safe concurrent memory access is one of the harder problems in any multithreaded system, not a JS-specific quirk — so treat this section as "know it exists and roughly what it's for," not a complete guide. Most real workloads are well served by message passing through a pool; reach for SharedArrayBuffer specifically when you've profiled and confirmed that cloning large data is the actual bottleneck.

When to actually reach for worker_threads

Worth being honest about the tradeoffs before you reach for this in your own code:

Worker startup has real cost. Spinning up a V8 instance per thread isn't free — this is exactly why pooling matters for anything beyond a one-off script.
Not everything benefits. If your bottleneck is I/O (database calls, network requests, file reads), workers don't help — that's exactly what the async event loop from parts 1 and 2 already handles well, without the overhead of a thread.
Message passing has a cost too. For small payloads it's negligible; for large ones, either restructure to send less data or use SharedArrayBuffer.
Debugging is harder. Errors in a worker don't naturally propagate the way synchronous exceptions do — you have to explicitly listen for 'error' events, and stack traces across threads are less convenient to work with.

The honest heuristic: profile first. If your server is slow because it's waiting on a database, adding worker threads won't fix anything — that's an I/O problem, and the event loop already handles it well. Worker threads earn their complexity specifically when you've identified genuine CPU-bound work — a synchronous computation heavy enough to visibly block the main thread — and optimizing the algorithm itself isn't enough.

Tying the series together

Three parts, one throughline:

Part 1 gave you the spec-level model — stack, microtask queue, macrotask queue, and the rule that microtasks always drain first.
Part 2 showed that model isn't implemented identically everywhere — the browser interleaves it with rendering, Node runs it through libuv's ordered phases, and Node adds process.nextTick() as a queue-jumper the browser doesn't have.
Part 3 showed the model's actual limit — a single thread, no matter how cleverly you schedule callbacks on it, can't parallelize genuine CPU-bound work. worker_threads is Node's way out of that constraint.

Put together, this is really the full picture of "how does async JS work" — from the queue ordering that decides what runs next, to the runtime-specific machinery underneath it, to the point where you need real threads instead of clever scheduling. If you made it through all three, you're in a genuinely small group of JS developers who could actually explain why setImmediate and setTimeout(fn, 0) race unpredictably at the top level of a script, or why a recursive .then() chain can freeze a browser tab without ever blocking the call stack.

That's the kind of understanding that turns "the event loop is confusing" into "the event loop is just a queue, some phases, and a very specific set of rules about what runs first" — which, at the end of the day, it is.

Browser vs Node — Where the Event Loop Actually Diverges (Part 2/3)

Aniket Misra — Tue, 04 Aug 2026 18:21:11 +0000

In part 1, we built the shared mental model: call stack, microtask queue, macrotask queue, and the rule that microtasks fully drain before the next macrotask runs. That model is spec-level JavaScript behavior — but it's not the whole story once you actually run code.

The event loop isn't part of the JS language spec. It's part of the host environment — the browser or Node — and each one implements it differently around that shared core. This is the post most "event loop" explainers skip, because it means going past the diagram and into how each runtime is actually built.

The browser: event loop meets rendering

In a browser, the event loop isn't just juggling callbacks — it's also responsible for keeping the page visually responsive. That means rendering has to get a turn too, and the browser has to decide when.

Here's the roughly accurate sequence per loop iteration:

Execute one macrotask (a click handler, a setTimeout callback, a network event, whatever's next in the queue)
Drain the entire microtask queue
Maybe render a frame — the browser doesn't render after every single task; it tries to hit ~60fps and will batch work between paints
Go back to step 1

The "maybe render" part is where two APIs come in that don't exist in Node at all:

requestAnimationFrame(callback) — schedules a callback to run right before the next repaint. It's not a macrotask or microtask in the queue sense — it's tied directly to the rendering pipeline. Use it for anything visual (animations, DOM measurements) instead of setTimeout, because it's synced to when the browser is actually about to paint, not an arbitrary delay.

requestIdleCallback(callback) — schedules a callback to run when the browser is idle, after layout and paint, with a deadline. Meant for low-priority work you don't want competing with rendering — analytics, prefetching, non-urgent DOM updates.

Here's the key interaction that's easy to miss: microtasks can starve rendering. If a promise chain keeps queueing more microtasks, the browser can't get to the paint step, because microtasks always drain fully before rendering gets a turn. This is a real, debuggable performance bug — a runaway .then() chain can visibly freeze a page even though "nothing is blocking the main thread" in the traditional sync-loop sense.

function recursiveMicrotask() {
  Promise.resolve().then(recursiveMicrotask);
}
recursiveMicrotask();
// Page becomes unresponsive — not because the stack is blocked,
// but because the microtask queue never empties long enough for a paint.

Compare that to a setTimeout-based recursive loop — because each iteration is a separate macrotask, the browser gets a chance to render between them.

Node: no rendering, but a much more structured loop

Node doesn't render anything, so it doesn't need the "maybe paint" logic. Instead, it's built on libuv, a C library that gives Node its event loop, thread pool, and async I/O. libuv organizes the loop into distinct phases, each with its own FIFO queue of callbacks. This is a meaningfully different shape from the browser's single task queue.

The phases, in order, each loop tick:

timers — runs callbacks scheduled by setTimeout / setInterval whose threshold has elapsed
pending callbacks — executes I/O callbacks deferred from the previous loop iteration (some system-level TCP errors, etc.)
idle, prepare — internal use only
poll — the big one: retrieves new I/O events, executes I/O-related callbacks (almost everything — file reads, network requests). Node will block here waiting for new events if there's nothing else scheduled
check — setImmediate() callbacks run here, specifically after poll
close callbacks — e.g. socket.on('close', ...)

Then it loops back to timers.

Between every single callback — not just between phases, but between individual callbacks within a phase — Node drains the microtask queue. Same drain-fully rule as the browser, just applied at a finer grain because there's no rendering to interleave with.

`process.nextTick()` — Node's queue-jumper

Node has a queue that doesn't exist in the browser at all: process.nextTick(). Despite the name, it doesn't queue for "next tick" of the event loop — it runs before microtasks, after the current operation finishes, no matter what.

Priority order in Node, after any synchronous code completes:

process.nextTick() queue (fully drained)
Promise microtask queue (fully drained)
Next macrotask/phase callback

setTimeout(() => console.log('timeout'), 0);

process.nextTick(() => console.log('nextTick'));

Promise.resolve().then(() => console.log('promise'));

console.log('sync');

Output: sync, nextTick, promise, timeout

nextTick beats the promise every time, because Node checks and drains the nextTick queue first, and — same recursion risk as the microtask-starvation example above — a recursive process.nextTick() call can starve I/O entirely, since Node won't proceed past it to the poll phase.

`setImmediate()` vs `setTimeout(fn, 0)` — the ambiguous one

This is the example that shows up in almost every Node interview, and the honest answer is: it depends on where you call it from.

setTimeout(() => console.log('timeout'), 0);
setImmediate(() => console.log('immediate'));

Run this at the top level of a script, and the order is not guaranteed — it depends on process startup timing, specifically whether the timers phase's threshold has already elapsed by the time the loop starts. You'll see it flip between runs.

But inside an I/O callback, the order is deterministic:

const fs = require('fs');

fs.readFile(__filename, () => {
  setTimeout(() => console.log('timeout'), 0);
  setImmediate(() => console.log('immediate'));
});

Output is always immediate, then timeout. Why? Because fs.readFile's callback runs in the poll phase. From there, the loop moves to check next — where setImmediate lives — before it wraps back around to timers. The phase order guarantees it here, where at the top level there's no such guarantee.

This is a genuinely useful thing to internalize: setImmediate means "run in the check phase, this loop iteration," while setTimeout(fn, 0) means "run in the timers phase, next time the loop gets there" — and those are different guarantees depending on what phase you're currently in when you schedule them.

Side-by-side: browser vs Node

Concept	Browser	Node
Underlying engine	V8 (Chrome), SpiderMonkey (Firefox), etc.	V8 + libuv
Queue structure	Single task queue + microtask queue	Multiple phase-specific queues (libuv) + microtask queue
Rendering concern	Yes — interleaved between tasks	No rendering at all
`setTimeout(fn, 0)`	Runs as next macrotask, after microtasks drain	Runs in the timers phase, next time loop reaches it
`setImmediate()`	Doesn't exist	Runs in the check phase
`process.nextTick()`	Doesn't exist	Runs before microtasks, after current operation
Idle/low-priority work	`requestIdleCallback()`	No direct equivalent — usually just `setImmediate()` or offloading
Animation timing	`requestAnimationFrame()`	No equivalent — no rendering to sync to
I/O model	Web APIs (fetch, XHR, DOM events)	libuv (thread pool for fs, async for network)

What carries over, and what doesn't

The stack/microtask/macrotask model from part 1 is real in both environments — that part's spec-driven and doesn't change. But the shape of the macrotask side is genuinely different: the browser has one queue and a rendering step to juggle; Node has an ordered set of phases with distinct semantics per phase, plus process.nextTick() sitting in front of everything.

If you've been assuming "the event loop" is one universal thing you can reason about the same way in a React component and an Express handler, this is usually where that assumption breaks — and where subtle bugs (starved I/O from recursive nextTick, or a setTimeout-vs-setImmediate race at startup) actually come from in production code.

Coming up next

Both of these models assume your callbacks are fast. But what happens when you genuinely have CPU-heavy work — image processing, large computations, parsing — that can't be broken into tiny async chunks? No amount of clever queue ordering saves you if a single synchronous function blocks the thread for 500ms.

Part 3 covers Node's answer to that: worker_threads — real OS-level threads, how to actually use them, and when reaching for a worker beats just optimizing your algorithm.

The JS Event Loop — Core Mental Model (Part 1/3)

Aniket Misra — Tue, 04 Aug 2026 18:13:49 +0000

JavaScript is single-threaded. One call stack, one thing happening at a time. And yet your code fetches data, sets timers, listens for clicks, and handles I/O — all without blocking. How?

The answer is the event loop, and it's one of those concepts every JS developer thinks they understand until someone asks them to predict the output of five nested setTimeout and Promise calls.

This is part 1 of a 3-part series:

The core event loop model (this post)
Where Node and the browser actually diverge
Escaping the event loop with worker_threads

Let's build the mental model properly.

JS is single-threaded — so what's actually running your async code?

The JS engine (V8, SpiderMonkey, etc.) only executes one thing at a time on the call stack. There's no multithreading inside the engine itself.

But the runtime around the engine — the browser or Node — provides extra machinery: Web APIs in the browser (timers, DOM events, fetch), or C++ APIs via libuv in Node (timers, file I/O, network). These run outside the JS thread. When they finish, they don't just barge into your running code — they queue up a callback to be run later.

That queueing and "run later" part is the event loop's job.

The three pieces: stack, queue, loop

Call stack — where synchronous code executes, frame by frame. If a function calls another function, it stacks. When a function returns, it pops.

Queue(s) — where callbacks wait after some async operation completes. There isn't just one queue (more on that in a second).

Event loop — a simple, repeating check: "Is the call stack empty? If yes, take the next thing from a queue and push it onto the stack."

That's genuinely most of it. The complexity comes from which queue goes first.

Macrotasks vs microtasks

This is the part that trips people up, so let's be precise.

Macrotasks (aka "tasks") include:

setTimeout / setInterval callbacks
I/O callbacks
UI rendering-related callbacks (browser)

Microtasks include:

Promise.then / .catch / .finally callbacks
queueMicrotask()
async/await continuations (they're sugar over promises)

The rule that matters: after every single macrotask, the event loop fully drains the microtask queue before it does anything else — including before rendering a frame or running the next macrotask.

Not "checks it once." Drains it completely. If a microtask queues another microtask, that runs too, before moving on.

The classic gotcha, explained properly

console.log('1');

setTimeout(() => console.log('2'), 0);

Promise.resolve().then(() => console.log('3'));

console.log('4');

Try to predict the order before reading on.

Here's what happens, step by step:

console.log('1') runs synchronously → prints 1
setTimeout(...) hands its callback off to the runtime's timer API and registers a macrotask for later — even with a 0ms delay, it doesn't run immediately
Promise.resolve().then(...) queues a microtask
console.log('4') runs synchronously → prints 4
Call stack is now empty. Event loop checks the microtask queue first → runs it → prints 3
Microtask queue is empty. Event loop moves to the macrotask queue → runs the timeout callback → prints 2

Output: 1, 4, 3, 2

The part people get wrong is assuming setTimeout(fn, 0) means "run next." It doesn't mean "run next" — it means "run next macrotask turn," and microtasks always cut the line first.

Why this ordering exists at all

It's not arbitrary. Microtasks are meant for finishing up work that's already in flight — resolving a promise chain, reacting to something that just happened — before the system moves on to genuinely new, separately-scheduled work like a timer firing or an I/O event arriving. It keeps related async logic coherent and predictable, rather than letting it get interleaved with unrelated queued tasks.

Quick check — predict the output

console.log('start');

setTimeout(() => console.log('timeout'), 0);

Promise.resolve()
  .then(() => console.log('promise 1'))
  .then(() => console.log('promise 2'));

console.log('end');

Drop your answer in the comments before scrolling through devtools to check — this is exactly the kind of ordering that gets asked in interviews, and exactly the kind of bug that shows up in real async code when you assume timers run "immediately."

Answer

start, end, promise 1, promise 2, timeout

Both .then() callbacks are microtasks and both drain before the macrotask queue is touched — even though the second .then() is only queued once the first one runs.

What's next

This model — stack, microtask queue, macrotask queue, drain-before-next-task — is the shared spec-level behavior both browsers and Node implement. But they don't implement the runtime around it the same way.

Browsers have to interleave this with rendering. Node runs on libuv with distinct phases (timers, I/O, setImmediate, close callbacks) and has its own microtask-like queue via process.nextTick() that jumps the line even ahead of promises.

That's where things get genuinely different — and where most "event loop" explanations stop short. Part 2 goes there.

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.