DEV Community: Aniket Misra

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.

Architecting Account Abstraction: EOA vs. ERC-4337 vs. zkSync Native AA

Aniket Misra — Sun, 24 May 2026 18:27:11 +0000

The default Ethereum account model is fundamentally flawed for mass adoption. If you want to interact with a decentralized system, you are forced into a rigid cryptographic box: the Externally Owned Account (EOA).

As we move toward protocol-level scaling, Account Abstraction (AA) has become the standard solution. But "Account Abstraction" is an umbrella term. The way it is architected on a standard EVM rollup like Arbitrum (via ERC-4337) is drastically different from how it is implemented on a ZK-rollup like zkSync Era (Native AA).

Here is a technical breakdown of the architectural leap from EOAs to Smart Accounts, and why protocol-level enshrinement matters.

1. The Legacy Architecture: EOAs

An Externally Owned Account (EOA) is simple, but structurally limited.

The Key is the Account: An EOA is strictly bound to a single ECDSA secp256k1 public-private key pair.
Execution: EOAs cannot contain code. They are passive entities that can only initiate transactions.
Gas: EOAs must hold the native network token (e.g., ETH) to pay for gas.

The Flow:
When an EOA sends a transaction, the protocol natively checks the ECDSA signature, verifies the nonce, deducts the gas fee from the balance, and executes the call. The logic is hardcoded into the EVM consensus layer. If you lose your private key, you lose the account. There is no programmability.

2. The Application-Layer Hack: ERC-4337 (EVM / Arbitrum)

Because changing the Ethereum base layer is notoriously difficult, the community rallied behind ERC-4337. This standard brings Account Abstraction to EVM-compatible chains (like Mainnet, Arbitrum, or Optimism) without altering the consensus protocol.

Instead of changing the EVM, ERC-4337 shifts the abstraction to a higher-level smart contract infrastructure.

The ERC-4337 Architecture

In this model, your account is a Smart Contract, not an EOA. But since smart contracts cannot initiate their own transactions, the architecture introduces several new off-chain and on-chain actors:

UserOperations (UserOps): Instead of standard transactions, users sign UserOperations—structs containing the execution instructions, signatures, and custom logic.
Alternative Mempool: UserOps do not go into the standard Ethereum mempool. They sit in a separate, specialized UserOp mempool.
Bundlers: Specialized nodes (Bundlers) listen to this mempool, pack multiple UserOps into a single standard Ethereum transaction, and submit them on-chain. The Bundler pays the ETH gas fee upfront.
The EntryPoint Contract: The Bundler sends the batch to a singleton EntryPoint smart contract. The EntryPoint is the global orchestrator; it verifies signatures, charges the Smart Accounts for the gas (refunding the Bundler), and routes the execution calls to the respective Smart Account contracts.
Paymasters (Optional): Third-party contracts that can sponsor gas fees for users or allow users to pay in ERC-20 tokens.

The Trade-off: ERC-4337 is highly flexible, but because it is an application-layer standard, it relies on a parallel mempool and introduces significant gas overhead due to the massive EntryPoint contract routing.

3. Protocol-Level Enshrinement: zkSync Native AA

Unlike Arbitrum or Ethereum Mainnet, zkSync Era was built with Native Account Abstraction enshrined directly into the protocol layer.

In zkSync, there is no distinction between an EOA and a Smart Contract at the architectural level. All accounts are treated as smart contracts.

The zkSync Architecture

Because AA is natively supported, zkSync eliminates the need for the clunky off-chain infrastructure required by ERC-4337.

Unified Mempool: There is no separate UserOp mempool. Smart contract transactions and traditional EOA transactions live in the exact same mempool.
No Bundlers: Because the protocol natively understands smart contract initiated transactions, there is no need for third-party Bundlers to wrap and submit them.
The Bootloader (The System EntryPoint): Instead of an application-layer EntryPoint contract, zkSync uses the Bootloader. The Bootloader is a system-level smart contract that handles block construction, transaction validation, and fee processing natively.
Enshrined Paymasters: Paymaster logic is built directly into the transaction processing flow, making gas sponsorship native and highly efficient.

When an EOA is used on zkSync, the protocol under the hood maps it to a default smart contract implementation that validates ECDSA signatures. If you upgrade to a custom Smart Account, the protocol simply points to your custom validation logic.

Architectural Comparison: ERC-4337 vs. zkSync Native AA

Feature	EVM / Arbitrum (ERC-4337)	zkSync Era (Native AA)
Protocol Integration	Application layer (Smart Contracts)	Enshrined at the Protocol level
Mempool	Requires an alternative UserOp mempool	Single, unified mempool
Transaction Initiation	Requires third-party Bundlers	Handled natively by the protocol
Gas Overhead	High (Routing via `EntryPoint`)	Low (Handled by the system `Bootloader`)
EOA Treatment	EOAs and Smart Accounts are entirely separate	EOAs are just default Smart Accounts

Building at the Protocol Level

Understanding the difference between application-layer workarounds (ERC-4337) and protocol-layer enshrinement (zkSync) is critical when designing low-level blockchain infrastructure. Native AA offers a glimpse into what the future of Ethereum must look like to achieve true mainstream viability without sacrificing decentralization or UX.

As I continue to dive deeper into protocol engineering and ZKP implementations, analyzing these architectural trade-offs is step one. I’ll be sharing more code-level deep dives into building custom validators and Paymasters soon.

The End of Blind Signing: Deep Diving into ERC-7730, ERC-8213, and Clear Signing

Aniket Misra — Tue, 19 May 2026 18:16:51 +0000

For years, the status quo of interacting with Ethereum protocols has been a security nightmare masquerading as a routine task. You open a frontend, click "Swap" or "Stake," and your hardware wallet prompts you to sign a blob of unreadable hexadecimal data.

You are blind signing. You are trusting that the frontend hasn't been compromised, that the RPC URL hasn't been poisoned, and that a malicious actor hasn't swapped out the destination address or function arguments. When the Lazarus Group drained $1.4 billion from Bybit, they didn't break cryptography; they exploited this exact UI gap. They tricked users into blind signing data that did something entirely different from what was shown on the screen.

The Ethereum Foundation, alongside an industry working group (including Ledger, Cyfrin, MetaMask, and Trezor), launched Clear Signing—a unified security standard designed to enforce the principle of "What You See Is What You Sign" (WYSIWYS).

This deep dive breaks down the technical layer of this release: ERC-7730, ERC-8213, and how they work together to eliminate blind signing without forcing on-chain breaking changes.

1. ERC-7730: The Clear Signing Metadata Standard

Originally proposed by Ledger and now under the stewardship of the Ethereum Foundation’s Trillion Dollar Security Initiative, ERC-7730 establishes a standardized, machine-readable JSON format that describes exactly what a smart contract’s function calls and EIP-712 typed messages mean in plain text.

Because this metadata lives entirely off-chain, it requires zero changes to existing smart contracts.

How It Works Under the Hood

Wallets and hardware devices cannot natively store the ABIs and translation logic for millions of deployed contracts. ERC-7730 solves this by creating a highly structured schema that maps raw calldata bytes to human-readable display formats.

An ERC-7730 file is broken down into three core blocks:

Context: Binds the descriptor to specific contract deployments across multiple EVM chain IDs.
Metadata: Contains high-level project data (e.g., protocol name, official legal entity, canonical URLs).
Display: The execution mapping logic. It dictates how function selectors and specific parameters are parsed and rendered on a wallet UI.

Here is a simplified architectural look at how a descriptor file (calldata-SwapRouter.json) maps execution data:

{
  "$schema": "[https://eips.ethereum.org/assets/eip-7730/erc7730-v2.schema.json](https://eips.ethereum.org/assets/eip-7730/erc7730-v2.schema.json)",
  "context": {
    "$id": "uniswap-v3-router",
    "contract": {
      "deployments": [
        { "chainId": 1, "address": "0xE592427A0AEce92De3Edee1F18E0157C05861564" }
      ]
    }
  },
  "metadata": {
    "owner": "Uniswap Labs",
    "info": { "url": "[https://uniswap.org](https://uniswap.org)" },
    "contractName": "SwapRouter"
  },
  "display": {
    "formats": {
      "0x415565b0": {
        "title": "Swap Exact Tokens for Tokens",
        "description": "Swaps {amountIn} of {tokenIn} for at least {amountOutMin} of {tokenOut} via route {path}."
      }
    }
  }
}

The Neutral Registry and Attestation (ERC-8176)

Metadata files are a security asset in their own right. If a malicious actor submits a fraudulent ERC-7730 file that translates a transferFrom(all_your_tokens) call into a display message that says "Claim Free Airdrop", the system breaks.

To prevent this:

The Ethereum Foundation hosts a central, open-source registry at Clearsigning.org.
ERC-8176 introduces an attestation framework built on top of the Ethereum Attestation Service (EAS). Independent security firms and auditors review these JSON files against verified on-chain code and cryptographically attest to their validity. Wallets can then choose which independent auditors they trust before displaying the translation to the user.

2. ERC-8213: The Bytes-Level Fallback

ERC-7730 works perfectly when a contract is known, indexed, and audited. But what happens when you are interacting with an immutable, freshly deployed contract, a highly custom gas-optimized protocol using packed encodings, or an air-gapped system where the wallet cannot fetch the latest JSON descriptor?

If ERC-7730 cannot resolve the metadata, the wallet falls back to ERC-8213.

Authored by Cyfrin, ERC-8213 addresses a physical human vulnerability: eyeballing raw hex data fails. Humans cannot effectively verify 500 bytes of calldata on a small hardware wallet screen without missing an altered character.

Instead of displaying the entire unreadable byte string, ERC-8213 enforces that wallets calculate and display short, reproducible cryptographic fingerprints called Digests.

The Calldata Digest Formula

For standard transactions containing calldata, ERC-8213 specifies a strict, length-prefixed hash calculation:

$$\text{calldataDigest} = \text{keccak256}(\text{uint256}(\text{len}(\text{calldata})) \mathbin{\Vert} \text{calldata})$$

By prefixing the raw calldata bytes with their explicit 32-byte length representation before hashing, it eliminates length-extension vulnerabilities and provides a deterministic snapshot of the execution vector.

The EIP-712 Digest

For off-chain signatures (like those used in snapshot voting, Permit2 allowances, or Safe multi-sig tracking), ERC-8213 mandates the standard exposure of the EIP-712 structured digest:

$$\text{EIP712Digest} = \text{0x1901} \mathbin{\Vert} \text{domainSeparator} \mathbin{\Vert} \text{hashStruct}(\text{message})$$

Why This Matters for Hardware Verification

If a frontend gets compromised via an XSS injection, the attacker will swap out the underlying transaction parameters (e.g., modifying the recipient address in the transaction payload).

Because the frontend is compromised, the user's browser extension might lie about what is happening. However, the hardware wallet calculates the ERC-8213 Calldata Digest directly from the raw bytes sent over the USB/Bluetooth line.

By comparing the digest shown on the physical screen with an independent source (like a block explorer, a separate terminal tool, or local execution), the user has deterministic proof that the data was not modified in transit.

3. The Clear Signing Workflow

When an application triggers a signing event, the execution pipeline functions as follows:

[ Frontend Action ] 
        │
        ▼
[ Raw Calldata / EIP-712 Struct Generated ]
        │
        ▼
[ Wallet Interception ]
        │
        ├───► Has ERC-7730 Metadata & Valid ERC-8176 Attestation?
        │           │
        │           ├───► YES: Display Human-Readable UI ("Swap 1 ETH for 3,000 USDC")
        │
        └───► NO (Fallback to ERC-8213)
                    │
                    └───► Compute deterministic Keccak256 Calldata/EIP-712 Digest
                    └───► Render concise cryptographic fingerprint on screen

Intent to Build

Clear signing closes one of the oldest attack surfaces in the EVM ecosystem. Moving forward, security is no longer just about writing secure Solidity or Rust circuits; it includes ensuring that the execution intent matches the user's perception at the exact millisecond they hit "Sign."

As I focus on building protocol-level infrastructure, implementing ERC-7730 descriptors and ensuring ERC-8213 compatibility will be core to the development lifecycle of my applications. I will be documenting my project implementations, gas considerations, and architectural patterns here in public. Stay tuned for the engineering updates.

0 to 1: notes to future blockchain dev self

Aniket Misra — Sat, 25 Apr 2026 23:29:38 +0000

I’m starting this blog to document my transition into protocol-level blockchain development.

My upcoming work will focus exclusively on:

Solidity & Solana: High-performance smart contract development. Often comparative and learnings to be fossilized for self.

Zero-Knowledge Proofs: Research and application of ZKP systems.

This will be a space for tracking progress, detailing project roadblocks, and sharing architectural notes as I build these systems in public.

Though not limited to given topics, as general and adjacent webdev intrigues keep me occupied, purpose of blogging for me is to keep grounded in the field i expect to be my profession.

No polish though. Just notes out of a register.