Will Cory roninjin10

EVM Comptime Optimization Opportunities

This document outlines all the places in the EVM codebase where Zig's compile-time features can be leveraged to improve performance, reduce code duplication, and enhance maintainability.

Executive Summary

The EVM codebase has significant opportunities for compile-time optimization, particularly in:

Jump table generation and opcode dispatch
Repetitive operation definitions (PUSH1-32, DUP1-16, SWAP1-16, LOG0-4)
Gas cost calculations and lookup tables

Viem is a lightweight, EIP-1193–compliant client for sending JSON-RPC requests—so it can plug into any EIP-1193–compatible server (Anvil, Hardhat, Alchemy, Geth, Reth, Tevm, etc.). Tevm is an EIP-1193–compatible server that can plug into Viem, Ethers, Express.js, Bun, or any JSON-RPC handler.

Viem Concepts

Transport Defines how you send JSON-RPC requests. For example:
```
import { http } from "viem";
```

Okay, here is a meta-prompt to guide an AI coding agent through the iterative debugging process. This prompt assumes the test/evm/test.todo.md file contains both the multi-agent workflow instructions I provided earlier and the detailed breakdown of test failures.

Meta-Prompt for EVM Debugging AI Agent

Your Role:

BitVec - JUMPDEST Analysis Module

Overview

Create a bit vector implementation for analyzing EVM bytecode to identify valid JUMPDEST locations. This module is crucial for validating jump operations in the EVM by distinguishing between actual code and data embedded in bytecode (e.g., PUSH instruction data).

(IMPORTANT) Best practices

You are a coding agent whose goal is to implement a production quality EVM implementation in zig that compiles to wasm. You care a lot about measuring performance and bundle size. You follow the following principles as you build:

Documentation/test driven development. You write docs first then tests then implementations to drive highest quality

Memory Implementation Issue

(IMPORTANT) Best practices

You are a coding agent whose goal is to implement a production quality EVM implementation in zig that compiles to wasm. You care a lot about measuring performance and bundle size. You follow the following principles as you build:

Documentation/test driven development. You write docs first then tests then implementations to drive highest quality
Iterative implementation. You implement small changes at a time testing your changes and making clean commits
Commit often, you make lots of emoji conventional commits with clear messages of the changes in the commit. Your commit message clearly marks if the repo is in broken state
If you spin your wheels for a long time trying to get something to work you should create a markdown file that makes it clear what is causing issues what the problems are and what you have tried and then move on

	/*
	- compiles to typescript
	- zig like error type
	- decorator like syntax for dependencie injection
	- try catch not allowed
	- try and catch work like zig
	- pipe operator exists
	- try unwraps effects and bubbles up error if it throws
	- catch catches value inline
	- Effect.* is always in global namespace

	gt branch create -m "✨ feat: Update README.md with new product structure and announcements
	<prompt>
	<request>
	<context>
	<docs>
	[REDACTED: Documentation for Tevm, including \"Why Tevm?\", comparisons, and getting started guides for brevity.]
	</docs>
	<source-code>
	[REDACTED: Source code for README.md, package.json, and other project files for brevity.]
	</source-code>

	// evm.ts

	// —— Helpers ———————————————————————————————————————————————

	type U256 = bigint;

	// bytes → bigint via hex string
	function fromBytes(bytes: Uint8Array): U256 {
	const hex = [...bytes].map(b => b.toString(16).padStart(2, '0')).join('');
	return BigInt('0x' + hex);


	<plan>
	<summary>This plan outlines a comprehensive refactoring of the Zig EVM. The primary goals are to simplify the core architecture, introduce robust memory management for multi-platform support (especially WASM), improve observability through structured logging, and ensure the correctness of tests and build configurations.</summary>

	<issue id="1">
	<title>Refactor Core EVM State: Merge `Interpreter` into `Vm`</title>
	<description>
	The current architecture separates state and logic between `Vm` and `Interpreter`. The goal is to merge all state and execution logic into the `Vm` struct, making it the single source of truth. This will simplify the architecture by removing a layer of indirection.
	</description>
	<steps>

	# Stack Implementation Issue

	We are building an high performance wasm compatible EVM in zig. We created a prototype in the past and using that to create the productionized version. This is PR 2 of many. Last PR added the EVM memory. This addes the EVM stack

	## (IMPORTANT) Best practices

	You are a coding agent whose goal is to implement a production quality EVM implementation in zig that compiles to wasm. You care a lot about measuring performance and bundle size. You follow the following principles as you build:

	1. Documentation/test driven development. You write docs first then tests then implementations to drive highest quality
	2. Iterative implementation. You implement small changes at a time testing your changes and making clean commits