Full Draft Report Full Draft Report code: https://github.com/developeruche/riscv-evm-experiment/tree/main/crates/research-draft Developeruche https://x.com/developeruche Abstract This research explores the technical feasibility and performance implications of integrating the RISC-V instruction set architecture with the Ethereum Virtual Machine (EVM). As blockchain platforms seek improved efficiency and accessibility, this work examines whether RISC-V's open architecture can provide a viable alternative execution environment for smart contracts. Through experimental implementation and benchmarking, we evaluate both the technical challenges of this integration and its potential benefits, including multi-language smart contract development, execution efficiency, and architectural compatibility. My findings indicate that while RISC-V integration presents promising opportunities for blockchain development diversity, significant challenges remain in reconciling RISC-V's register limitations with complex EVM operations and preserving the security guarantees of traditional EVM environments. This work contributes to the ongoing discourse on blockchain virtual machine evolution and provides empirical insights into the future architectural directions for Ethereum and similar platforms. 1. Introduction

Dive into the instruction set of powerful, general-purpose virtual machines like WebAssembly (WASM) or RISC-V, and you'll find commands for arithmetic, logic, and memory operations – the building blocks of computation. 1 But search for specific opcodes designed to directly read from or write to a blockchain's state, like the EVM's famous SLOAD or SSTORE, and you'll come up empty. This presents a fascinating paradox: if the VMs running smart contracts on many innovative blockchains lack these native state-handling instructions, how do these platforms actually manage the crucial tasks of reading account balances or writing data to contract storage? This post unravels the essential mechanism that bridges the gap between general-purpose computation and blockchain-specific state management. This VM is not the blockchain, but rather a component of the blockchain The VM is a powerful component of the blockchain, tasked with state transition function of the blockchain among other features. It is important to note that this VM does not run in Isolation. This engine, be it powered by WASM or RISC-V, doesn't operate in a vacuum. Instead, it thrives within a "host environment," the very blockchain node software itself. This environment provides a set of specialized tools, the Host Functions or APIs, that the VM can utilize. Think of them as bridges, allowing the code within the VM to interact with the broader blockchain ecosystem. These host functions are crucial, as they connect the general-purpose computational capabilities of the VM to the blockchain's unique functionalities, enabling smart contracts to read and write ledger data, interact with other accounts, and ultimately, drive the blockchain's logic. When a smart contract, compiled into bytecode for a virtual machine (VM) like WASM or RISC-V, needs to interact with the blockchain—whether to transfer tokens, modify storage, call another contract, or read block information—it doesn’t rely on native VM instructions tailored for those specific actions. Instead, the contract invokes predefined host functions provided by the blockchain’s runtime environment. For example, a function like env.transfer_balance(recipient_address, amount) might be called to send tokens to a recipient, or env.storage_write(key, value) to update the contract’s persistent storage. The VM identifies these as external calls, passing them to the host environment, which securely executes the requested blockchain operation and updates the system state. This design keeps the VM focused on computation while delegating blockchain-specific tasks to the runtime, ensuring both flexibility and security. When a smart contract executes within a virtual machine (VM), such as WASM or RISC-V, and invokes a blockchain-specific operation, the VM’s execution pauses temporarily. At this point, control shifts to the host environment—the blockchain node running the network’s software. The node takes over, natively executing the requested operation by interpreting the call and interacting with the blockchain’s infrastructure. This process involves accessing the blockchain’s state (e.g., the state trie or database), performing necessary checks (such as verifying an account has sufficient balance for a transaction), and updating relevant data structures like account balances or contract storage tries. All actions adhere strictly to the blockchain’s consensus rules, ensuring consistency and security. Though this execution occurs outside the VM’s core instruction processing, it is seamlessly triggered by the VM’s code, bridging the contract’s logic with the blockchain’s state management. Returning Control & Results

This is a key component of the PLONK protocol, before diving in, let's explore the term "Arithmetization" in the context of Zero Knowledge; Arithmetization is the process of converting computational statements into mathematical equations, specifically polynomial equations, that can be efficiently proven and verified. It's like translating a computer program into a mathematical language that zero-knowledge proofs can understand. Here is the basic building blocks of the concept of Arithmetization; Variables: Represent values in computation Constraints: Mathematical relationships between variables Polynomials: Used to encode relationships and checks Fields: Mathematical structures where computation occurs

The PLONK (Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge) verification algorithm is a cornerstone of modern zk-SNARKs, enabling succinct, non-interactive proofs of arbitrary computations. In this blog, we’ll break down the PLONK verification algorithm step by step, demystifying its inner workings. What is PLONK Verification? At a high level, PLONK verification ensures that the proof generated by the prover is valid for a specific computation. The verifier performs various checks, leveraging cryptographic commitments and field operations to validate the integrity of the proof without needing to re-execute the computation. Key Preliminaries Before diving into the steps, let’s clarify the inputs and mathematical tools involved: • Verifier Preprocessed Input: Preprocessed elements include commitments to selector polynomials $[qM]1, [qL]1, [qR]1, [qO]1, [qC]1$, permutation polynomials $[sσ1]1, [sσ2]1, [sσ3]1$, and a generator $x$. • Proof Elements $(π_{SNARK})$:

Kademlia is a Distributed Hash Table (DHT) protocol designed for decentralized peer-to-peer (P2P) networks. It enables efficient storage and retrieval of key-value pairs without relying on a central authority. It is widely used in file-sharing networks (e.g., BitTorrent’s DHT), blockchain networks, and decentralized applications. Some things you should note: Every node of data has a 160bit or 20bytes unique ID The node that is the closest to a key would be responsible for storing this data. the term closest is obtained by the distance metric, this quantify the disstance between nodes. This netwrok make use of the XOR operator to perform this distance metric;d(x, x) = x xor x = 0 d(x,y) = x xor y > 0 d(x,y) + d(y, z) = (x xor y) xor (y xor z) = x xor z = d(x, z) Every node in the network would need to keep track of a feew nodes, and hope they keep track of others and so on

is a clever trick used in polynomial-based set equality checks. Let’s break it down step by step with an example. Here is what we've got; Polynomials $f(X)$ and $g(X)$ : These interpolate values from the sets $A = {a_0, a_1, \ldots, a_{k-1}}$ and $B = {b_0, b_1, \ldots, b_{k-1}}$ , respectively. For example: $f(X) = (a_0 + X)(a_1 + X)\cdots(a_{k-1} + X)$, $g(X) = (b_0 + X)(b_1 + X)\cdots(b_{k-1} + X)$. Roots of Unity $\omega$ : The domain $H = {1, \omega, \omega^2, \ldots, \omega^{k-1}}$ is built from a primitive $k -th$ root of unity $\omega$ , such that $\omega^k = 1$ . For example:

This is the rust target I am interested in; riscv32im-risc0-zkvm-elf riscv32im-unknown-none-elf #resources https://github.com/0xPolygonHermez/zisk/tree/develop/riscv ELF: The Extensible and Linkable Format The main uses of ELF are for;

At the heart of the PLONK protocol lies one of its most fascinating components: the prover. After the universal trusted setup and the arithmetic representation of our computation, the prover takes center stage in constructing a convincing zero-knowledge proof that will persuade the verifier without revealing any sensitive information. The prover's role in PLONK represents a remarkable achievement in zero-knowledge proof systems, offering a delicate balance between efficiency and security. Unlike its predecessors, PLONK's prover leverages the protocol's universal preprocessing to generate proofs that are both compact and computationally efficient, while maintaining the critical property of zero-knowledge. The PLONK prover is broken down into rounds and using this rounds, we would be understanding how the PLONK proof is genearted; As the protocol progresses, we would be creating some polynomials and also for polynomial mathematical relationships which would be examine and sealed(polynomail commitment schemes) to be used to create the PLONK protocol's Proof. Recall: CommonPreprocessedInput { $S_\sigma^1$, $S_\sigma^2$, $S_\sigma^3$, $q_L$, $q_R$, $q_O$, $q_M$, $q_C$, $a$, $b$, $c$ } which was obtained when PLONKish arithmetization was applied to the circuit including the witness. Round One

Building a highly scalable, fault-tolerant relayer for EIP-2771 requires a robust architecture that can efficiently handle meta-transactions at scale. System Goals High Scalability: Handle thousands of concurrent meta-transactions with low latency. Fault Tolerance: No single point of failure; system should remain operational under load or partial outages. Security: Protect user data, ensure valid meta-transactions, and prevent abuse. Flexibility: Easy to integrate with various dApps and support future protocol upgrades. High-Level Overview The server will have two primary threads:

The multiset check IOP (Interactive Oracle Proof) is a cryptographic technique often used in zero-knowledge proof systems to verify that two collections (multisets) are identical, without directly revealing their contents. This approach is particularly valuable in protocols like PLONK, where the prover and verifier need to ensure consistency between certain sets of values derived during the computation. Multiset Basics A multiset is a collection of elements where repetition is allowed. For instance: • $A = {a, b, a, c}$ • $B = {c, a, b, a}$ The multisets A and B are equal if they contain the same elements with the same multiplicities, regardless of the order. Use Case in Cryptography

The native plonk equation covers how addtion and multiplication gates can be implemented and expressed by making use of function selector. The introduction of custom gates still relies on this idea of using selectors only that the selectors are now used to target "arbitrary linear combinations". Native plonk gate: $q_l \cdot x_a + q_r \cdot x_b + q_o \cdot x_c + q_m \cdot (x_ax_b)$; We can define a custom gate (arbitrary linear combinations): $q_{add} \cdot (a_0 + a_1 - a_2) + y \cdot q_{mul} \cdot (a_0 \cdot a_1 - a_2) + y^2 \cdot q_{bool} \cdot (a_0 + a_0 - a_0) = 0$ We have just define a custom gate that can express Add, Mul and Boolean expressions. In order to combine all these custom gate into a single expression like the native plonk custom gate, we need to introduce the use of a verifier challenge $y$ to keep gates linearly independent. The way we get $y$ is by committing the selectors $q_{add}, q_{mul}, q_{bool}$ to the Transcript this selectors discards the structure of the circuit, now we can sample $y$ from this Transcript. It is important to note that the powers of $y$ are what is used to keep this gates linearlly independent so that prover can't game the values to maybe cancel out some gates or in any way make that gate pass even if the values don't pass.

The ZeroCheck PIOP (Polynomial Interactive Oracle Protocol) is a subprotocol used in zero-knowledge proof systems to verify that a polynomial evaluates to zero over a specific domain. It is a critical building block in many zero-knowledge proof systems, particularly in protocols like Plonk, to check consistency or enforce certain constraints. Purpose of ZeroCheck PIOP In a zero-knowledge proof, the prover often needs to demonstrate that a polynomial $f(X)$: • Either evaluates to zero on certain inputs, such as all elements in a domain $D$, • Or satisfies specific conditions implying that some computation is correct. For instance: 1. $f(X) = 0$ might encode the correctness of a relation. 2. $f(X) = 0$ over all $X \in D$ might verify consistency with a pre-specified structure.

The Sum Check Protocol The sum-check protocol is a fundamental sub-protocol used in various zero-knowledge proofs, particularly in the context of interactive proofs and zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs). It was first introduced in the context of probabilistically checkable proofs (PCPs) by Lund, Fortnow, Karloff, and Nisan. The primary purpose of the sum-check protocol is to prove that a given polynomial, evaluated over a specified domain, sums to a particular value. The sum-check protocol has served as the single most important “hammer” in the design of efficient interactive proofs. (from ProofsArgsAndZk). Suppose we are given a v-variate polynomial $g$ defined over a finite field $F$. The purpose of the sum-check protocol is for the prover to provide the verifier with the following sum: <br/> $$S = \sum_{x_1 \in {0,1}} \sum_{x_2 \in {0,1}} \cdots \sum_{x_n \in {0,1}} f(x_1, x_2, \ldots, x_n) = T$$ Performing the sum of the evaluations of a polynomial over the boolean hypercube may seem like a very simple task and not so useful especially when the polynomial is represented in the `Evaluation` form, make no mistake, a good number of problems can be translated into this form, having polynomial so big we would have to apply this principle to take advantage of the computational efficiency it births. The Sum Check Protocol.

ProductCheck PIOP (Polynomial Interactive Oracle Proof) is a subprotocol commonly used in zero-knowledge proofs to verify the product relation of polynomials or polynomial evaluations efficiently. This verification is performed without revealing sensitive information about the underlying data. ProductCheck ensures that a claimed product relation holds between given polynomials or their evaluations. For example, suppose you have three polynomials $f(X)$, $g(X)$, and $h(X)$, and the prover claims: $$h(X) = f(X) \cdot g(X)$$ The ProductCheck PIOP is used to verify this claim interactively with the verifier without revealing the explicit form of these polynomials. Definition of ProductCheck Relation The relation $R_{\text{Prod}}$ in a ProductCheck PIOP is defined as follows:

The PermutationCheck PIOP is used in many zero knowledge protocol, this document would be looking into this PIOP from the light of the plonk protocol. The permutation check in the Plonk protocol is used to ensure that a set of variables or constraints satisfies a particular permutation argument. This is essential in Plonk to enforce consistency between “wires” (the inputs and outputs of arithmetic gates) across multiple constraints without explicitly revealing intermediate values. For example: Suppose you have variables $a, b, c$ in one gate and $x, y, z$ in another, and you want to enforce that $a$ is equal to $x$ , $b$ is equal to $y$ , and $c$ is equal to $z$ . Instead of explicitly encoding these equalities, Plonk ensures this by proving that ${a, b, c}$ is a permutation of ${x, y, z}$. How Does the Permutation Check Work?

The PLONK (Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge) protocol is a groundbreaking zero-knowledge proving system designed for scalability and efficiency in blockchain and cryptographic applications. Its modularity, simplicity, and reduced proving times make it a favored choice for developers and researchers working on zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge). Introduced in 2019, PLONK revolutionized the proving system landscape by addressing key limitations in previous protocols, such as the dependency on trusted setups for each application. PLONK employs universal trusted setups and leverages powerful cryptographic primitives, including polynomial commitment schemes, to achieve succinct, efficient, and highly verifiable proofs. This blog aims to provide a deep technical dive into the mechanics of the PLONK protocol, breaking down its components, theoretical underpinnings, and practical implementations. Whether you’re a researcher, a developer, or just someone passionate about cryptographic proving systems, this article will serve as a comprehensive guide to understanding and implementing PLONK. Similiar to a good number of zkSNARK protocols, this protocol life-cycle could be discribed as follows; Computation Algebraic circuit

Zero-knowledge proof systems have emerged as a cornerstone of modern cryptographic protocols, enabling privacy-preserving computation and verification without revealing sensitive information. At the heart of these systems lie several fundamental protocols that serve as building blocks for more complex applications. This series of articles explores four essential protocols that form the backbone of many zero-knowledge proof systems: Permutation Check Polynomial IOP ProductCheck Polynomial IOP SumCheck Polynomial IOP ZeroCheck Polynomial IOP Why These Protocols Matter Modern zero-knowledge proof systems, such as zkSNARKs, zkSTARKs, and Bulletproofs, rely heavily on polynomial-based techniques for efficient verification. The protocols we'll examine are the fundamental components that make these systems possible:

impl<P: Pairing> BatchKZGUnivariateInterface<P> for UnivariateKZG { fn open<F: PrimeField>( srs: &SRS<P>, poly: &UnivariantPolynomial<F>, point: &Vec<F>, ) -> (Vec<F>, <P as Pairing>::G1) { let point_evaluations: Vec<F> = point.iter().map(|point| poly.evaluate(point)).collect(); let i_poly = UnivariantPolynomial::interpolate(point_evaluations.clone(), point.clone()); let vanishing_polynomial = generate_vanishing_polynomial(&point); let quotient =

Polynomial commitment schemes are cryptographic primitives that allow one to commit to a polynomial and later reveal evaluations of the polynomial at various points, with the ability to verify these evaluations efficiently. There are two major families of polynomial commitment schemes based on different hardness assumptions: one based on discrete logarithms and the other based on pairings. This is a better introduction to the polynomial commitment scheme: Polynomial Commitment Schemes | Scroll Documentation KZG10, IPA, FRI, and DARKS: Analysis Of Polynomial Commitment Schemes | HackerNoon

Similar to the Univariate KZG Polynomial commitment scheme, this interface of this commitment scheme entails; Generate SRS Commit function Opening Verification Because we would be dealing with multiple variables, finding a way to efficiently find tone these functions to meet the demands placed my these multiple variables in terms of security and succinctness. KZG PCS on multilinear polynomials is quite different compare to that of the Univariate polynomial, first this multilinear polynomial is expressed as an evaluation of the polynomial of the bolean hypercube where the size of the boolean hypercube n is directly proportional to the number of variables n_var of the multilinear polynomial.