9 Commits
Author SHA1 Message Date
giteadmin eb829d6441 v1.3 2025-08-15 22:01:16 +02:00
giteadmin cd253ad6bb v1.2 2025-08-15 21:53:01 +02:00
giteadmin 7ac0ae3188 v1.1 2025-08-15 21:33:26 +02:00
giteadmin 1eda777047 rewrite 2025-08-15 21:08:13 +02:00
giteadminandJulesCrown e21ddf45a4 improve vision doc (#16)
Co-authored-by: JulesCrown <admin@noip.localhost>
Reviewed-on: http://gitea.loseyourip.com:4000/giteadmin/SoLUSH-3/pulls/16
2024-12-30 14:36:04 +00:00
giteadminandJulesCrown 2a4f01481b merge interpreter.md into readme (#4)
Co-authored-by: JulesCrown <admin@noip.localhost>
Reviewed-on: http://gitea.loseyourip.com:4000/giteadmin/SoLUSH-3/pulls/4
2024-12-26 10:30:26 +00:00
giteadmin 1079129e48 Merge pull request 'scaffolding' (#1) from scaffolding into main
reviewed scaffolding
2024-12-24 12:02:50 +00:00
giteadmin e668fcf9a0 Merge pull request 'interpreter-expansion' (#2) from interpreter-expansion into scaffolding
reviewed bunch of new int operations
2024-12-24 12:02:08 +00:00
giteadmin a1890e650b Merge pull request 'refactor-dirs' (#3) from refactor-dirs into interpreter-expansion
reviewed logic move to dir
2024-12-24 12:00:57 +00:00
22 changed files with 493 additions and 5837 deletions
-1
View File
@@ -1 +0,0 @@
use flake
+3 -5
View File
@@ -1,7 +1,5 @@
onchain/cache/
onchain/out/
offchain/target/
.direnv
.env
out/
cache/
lib/forge-std
+47
View File
@@ -0,0 +1,47 @@
me: Bounty
about: Bounty
title: ''
labels: bounty
assignees: ''
---
# Bounty
## Scope
<!-- A list of specific things which should be done to deliver the bounty. These could be seen as requirements to verify/review bounty against -->
-
-
-
## Deliverables
<!-- Artifacts produced as the result of this bounty. Something that could be verified/reviewed. Some examples: updated code, deployment made, blog post published, public event conducted etc -->
-
-
## Bounty Owner/Gardener
<!-- The Role who is responsible for the bounty. -->
<@your github username> as **<Role>**
## Gain for the Role
<!-- How the completion of this bounty helps to pursue the Role's purpose -->
## Roles
bounty gardener: <@your git username> / X DAI <!-- likely shouldn't be a % but rather flat -->
bounty worker: name / share
bounty reviewer: name / share
## Gardener checklist
- [ ] I have attached one of the `size-` labels to this bounty
<!--
# Bounty sizes
XS / 200 DAI / effort ~ 3h
S / 350 DAI / effort ~5h
M / 550 DAI / effort ~8h
L / 900 DAI / effort ~13h
XL / 1400 DAI / effort ~21h
-->
-124
View File
@@ -1,124 +0,0 @@
# Interpreter.md
## Overview
This repository provides a **Push3-like interpreter** implemented in Solidity. It uses a _token-based bytecode_ approach to parse programs from a `bytes` array (the `code`) into typed **descriptors**, which are then executed by the interpreter.
**Push3** is a stack-based language originally designed for genetic programming and autoconstructive evolution. Each data type (e.g. `INT_LITERAL`, `FLOAT`, `BOOLEAN`, etc.) has its own stack. The **`EXEC`** stack manages the flow of execution.
**In this implementation**:
- We store code in a single `bytes` array (`code`).
- We parse sublists and integer literals from that array.
- We push instructions and literals onto an execution stack.
- We pop them in LIFO order and execute them.
### Key Features
1. **Token-Based Parsing**: We define small tokens (`0x00` => NOOP, `0x01` => INTEGER_PLUS, `0x02` => INT_LITERAL, `0x03` => SUBLIST). If we see `INT_LITERAL`, we read 4 bytes for a 32-bit integer; if we see `SUBLIST`, we read 2 bytes for the sublist length, then parse it recursively.
2. **Descriptor System**: We represent instructions, literals, and sublists using 256-bit “descriptors.” Each descriptor encodes:
- A `tag` (top 8 bits): e.g. `INT_LITERAL`, `INSTRUCTION`, `SUBLIST`.
- `offset` and `length` for sublists.
- A leftover field (e.g. for storing integer data).
3. **Reversing Items**: When we pop a sublist descriptor, we parse it into descriptors and then push them onto the `EXEC` stack in reverse order. This ensures the list’s leftmost token executes first, consistent with the Push3 spec.
4. **Separation of Parsing and Execution**:
- **Parsing**: Transforms raw byte tokens into typed descriptors (instructions, literals, or nested sublists).
- **Execution**: The `runInterpreter` function repeatedly pops from `EXEC`, decides if it’s an instruction or literal or sublist, and acts accordingly.
## Code Structure
### 1. **Enums**
- **`CodeTag`**:
- `NO_TAG` (unused),
- `INSTRUCTION`,
- `INT_LITERAL`,
- `SUBLIST`.
- **`OpCode`**:
- `NOOP`,
- `INTEGER_PLUS`.
### 2. **Descriptor Layout**
A **256-bit** word has:
```
[ top 8 bits | offset(32 bits) | length(32 bits) | leftover(184 bits) ]
```
- `tag`: The top 8 bits (e.g. `INT_LITERAL`).
- `offset, length`: If `tag = SUBLIST`, these define which bytes in `code` represent the sub-sublists.
- `leftover`: If `tag = INT_LITERAL`, we store the 32-bit integer in the bottom 32 bits of leftover. If `tag = INSTRUCTION`, we store the opcode (`NOOP`, `INTEGER_PLUS`) in the lowest 8 bits of leftover.
### 3. **Helper Reads**
- **`readUint32(code, start)`**: Copies 4 bytes from calldata into a small buffer, returns the final `uint32`. By shifting bits if needed, we ensure we get the integer from the correct part of the loaded word.
- **`readUint16(code, start)`**: Similar logic for 2 bytes.
### 4. **`parseSublist` Function**
When we see a sublist descriptor (`tag=SUBLIST`), we parse the slice `[off..off+len]` in the `bytes code`. We iterate token by token:
- `0x00` => `NOOP`
- `0x01` => `INTEGER_PLUS`
- `0x02` => read 4 bytes => `INT_LITERAL`
- `0x03` => read 2 bytes => sub-sublist length => build a sub-descriptor
We accumulate these descriptors in an array. Then, later, we push them _in reverse_ onto the `EXEC` stack.
### 5. **`runInterpreter` Function**
1. Loads initial CODE, EXEC, and INT stacks from the provided arrays.
2. While `EXEC` is non-empty:
- Pop the top descriptor.
- If `INSTRUCTION`, decode the opcode (e.g. `INTEGER_PLUS`) and do it (pop top 2 ints, push their sum).
- If `INT_LITERAL`, push that integer onto the int stack.
- If `SUBLIST`, parse that sublist into descriptors, then push those in reverse.
## How to Contribute
1. **Add New Instructions**
- Expand `OpCode` enum (e.g. `INTEGER_MINUS`, `INTEGER_MUL`, etc.).
- Write a `makeInstruction` or `makeIntLiteral` function to build the descriptor for it.
- In the main loop, implement the logic (pop the correct number of integers, do the operation, push the result).
2. **Support More Data Types**
- For instance, a `FLOAT` or `BOOLEAN` stack.
- Add a new tag (`FLOAT_LITERAL`?), new instructions (`FLOAT.PLUS`?), etc.
3. **Improve Parsing**
- If you want 256-bit literals, define a new token that reads 32 bytes, or do other expansions (like `CODE` type).
- Or define advanced sublist structures (like nested `( ( ) )` expansions).
4. **Gas Optimization**
- Check how large arrays are allocated (like in `parseSublist`).
- Possibly implement step-by-step execution if large code exceeds block gas limits.
5. **Add Logging & Debug Tools**
- Use `console.log(...)` to trace tokens, track final states, or measure performance.
6. **Test Coverage**
- Provide more unit tests in Foundry for advanced instructions, nested sublists, edge cases with zero-length sublists, etc.
## Next Steps
### A. Extending the VM
A “full” Push3 VM might include:
- **Multiple Data Stacks**: `BOOLEAN`, `FLOAT`, `NAME`, etc.
- **NAME Binding**: Let `NAME`s reference values or code.
- **Control Structures**: `EXEC.IF`, `EXEC.DO*COUNT`, or combinators like `EXEC.Y`.
### B. Example Project
You could use this interpreter in:
- A genetic programming environment, where random code is generated and mutated.
- A puzzle solver that runs tiny “scripts” in EVM-like constraints.
## Conclusion
This `Push3Interpreter` is a **minimal** scaffold for a token-based, list-expanding interpreter with typed descriptors. By following the patterns for instructions, sublists, and typed stacks, you can easily expand it into a more complete VM. We welcome contributions in the form of new instructions, data types, and performance optimizations.
1. **Clone** this repo.
2. **Check** the `test/` folder for Foundry-based tests.
3. **Add** or modify instructions & sublists in `parseSublist` and `runInterpreter`.
4. **Run** `forge test --via-ir -vv` to see logs and confirm your changes.
Enjoy exploring the **Push3** style VM in Solidity!
+95 -9
View File
@@ -1,6 +1,14 @@
# **SoLUSH**: A Push 3 Virtual Machine in Solidity
Welcome to **SoLUSH 3** (pronounced like **"slush"** without the "o", composed from **S**o**L**idity and p**USH** 3), a Solidity implementation of the [Push 3 stack machine](http://faculty.hampshire.edu/lspector/push3-description.html), designed to bring evolved genetic algorithms on-chain. By enabling the execution of Push 3 programs directly within Ethereum smart contracts, SoLush 3 paves the way for decentralized, adaptive systems to address complex optimization problems.
Welcome to **SoLUSH 3** (pronounced like **"slush"** without the "o", composed from **S**o**L**idity and p**USH** 3), a **Push3-like interpreter** implemented in Solidity. It uses a _token-based bytecode_ approach to parse programs from a `bytes` array (the `code`) into typed **descriptors**, which are then executed by the interpreter.
**Push3** is a stack-based language originally designed for genetic programming and autoconstructive evolution. Each data type (e.g. `INT_LITERAL`, `FLOAT`, `BOOLEAN`, etc.) has its own stack. The **`EXEC`** stack manages the flow of execution.
**In this implementation**:
- We store code in a single `bytes` array (`code`).
- We parse sublists and integer literals from that array.
- We push instructions and literals onto an execution stack.
- We pop them in LIFO order and execute them.
## 🌟 Vision
@@ -12,19 +20,97 @@ SoLUSH is a key step toward realizing the vision of running decentralized evolut
To understand the broader vision, check out the [Vision Document](vision.md).
### Key Features
1. **Token-Based Parsing**: We define small tokens (`0x00` => NOOP, `0x01` => INTEGER_PLUS, `0x02` => INT_LITERAL, `0x03` => SUBLIST). If we see `INT_LITERAL`, we read 4 bytes for a 32-bit integer; if we see `SUBLIST`, we read 2 bytes for the sublist length, then parse it recursively.
2. **Descriptor System**: We represent instructions, literals, and sublists using 256-bit “descriptors.” Each descriptor encodes:
- A `tag` (top 8 bits): e.g. `INT_LITERAL`, `INSTRUCTION`, `SUBLIST`.
- `offset` and `length` for sublists.
- A leftover field (e.g. for storing integer data).
3. **Reversing Items**: When we pop a sublist descriptor, we parse it into descriptors and then push them onto the `EXEC` stack in reverse order. This ensures the list’s leftmost token executes first, consistent with the Push3 spec.
4. **Separation of Parsing and Execution**:
- **Parsing**: Transforms raw byte tokens into typed descriptors (instructions, literals, or nested sublists).
- **Execution**: The `runInterpreter` function repeatedly pops from `EXEC`, decides if it’s an instruction or literal or sublist, and acts accordingly.
## Code Structure
### 1. **Enums**
- **`CodeTag`**:
- `NO_TAG` (unused),
- `INSTRUCTION`,
- `INT_LITERAL`,
- `SUBLIST`.
- **`OpCode`**:
- `NOOP`,
- `INTEGER_PLUS`.
### 2. **Descriptor Layout**
A **256-bit** word has:
```
[ top 8 bits | offset(32 bits) | length(32 bits) | leftover(184 bits) ]
```
- `tag`: The top 8 bits (e.g. `INT_LITERAL`).
- `offset, length`: If `tag = SUBLIST`, these define which bytes in `code` represent the sub-sublists.
- `leftover`: If `tag = INT_LITERAL`, we store the 32-bit integer in the bottom 32 bits of leftover. If `tag = INSTRUCTION`, we store the opcode (`NOOP`, `INTEGER_PLUS`) in the lowest 8 bits of leftover.
### 3. **Helper Reads**
- **`readUint32(code, start)`**: Copies 4 bytes from calldata into a small buffer, returns the final `uint32`. By shifting bits if needed, we ensure we get the integer from the correct part of the loaded word.
- **`readUint16(code, start)`**: Similar logic for 2 bytes.
### 4. **`parseSublist` Function**
When we see a sublist descriptor (`tag=SUBLIST`), we parse the slice `[off..off+len]` in the `bytes code`. We iterate token by token:
- `0x00` => `NOOP`
- `0x01` => `INTEGER_PLUS`
- `0x02` => read 4 bytes => `INT_LITERAL`
- `0x03` => read 2 bytes => sub-sublist length => build a sub-descriptor
We accumulate these descriptors in an array. Then, later, we push them _in reverse_ onto the `EXEC` stack.
### 5. **`runInterpreter` Function**
1. Loads initial CODE, EXEC, and INT stacks from the provided arrays.
2. While `EXEC` is non-empty:
- Pop the top descriptor.
- If `INSTRUCTION`, decode the opcode (e.g. `INTEGER_PLUS`) and do it (pop top 2 ints, push their sum).
- If `INT_LITERAL`, push that integer onto the int stack.
- If `SUBLIST`, parse that sublist into descriptors, then push those in reverse.
## Next Steps
### A. Extending the VM
A “full” Push3 VM might include:
- **Multiple Data Stacks**: `BOOLEAN`, `FLOAT`, `NAME`, etc.
- **NAME Binding**: Let `NAME`s reference values or code.
- **Control Structures**: `EXEC.IF`, `EXEC.DO*COUNT`, or combinators like `EXEC.Y`.
### B. Example Project
You could use this interpreter in:
- A genetic programming environment, where random code is generated and mutated.
- A puzzle solver that runs tiny “scripts” in EVM-like constraints.
## 🚀 Getting Started
SoLUSH 3 is in active development. To contribute or test the functionality, follow these steps:
This `Push3Interpreter` is a **minimal** scaffold for a token-based, list-expanding interpreter with typed descriptors. By following the patterns for instructions, sublists, and typed stacks, you can easily expand it into a more complete VM. We welcome contributions in the form of new instructions, data types, and performance optimizations.
1. Clone the repository:
```bash
git clone https://github.com/your-username/SoLUSH.git
cd SoLUSH
```
2. Install dependencies (if applicable).
3. Review the examples and test cases to understand how Push 3 programs are executed on the VM.
1. **Clone** this repo.
2. **Check** the `test/` folder for Foundry-based tests.
3. **Add** or modify instructions & sublists in `parseSublist` and `runInterpreter`.
4. **Run** `forge test --via-ir -vv` to see logs and confirm your changes.
### How to contribute
Check the [Issues](../../../issues) section to find tasks to tackle.
## 🛠️ Roadmap
- **Core Features:**
BIN
View File
Binary file not shown.

Before

Width:  |  Height:  |  Size: 92 KiB

After

Width:  |  Height:  |  Size: 113 KiB

-3
View File
@@ -23,9 +23,6 @@
# ... any other dependencies we need
solc
cargo
rustc
rust-analyzer
];
# Decorative prompt override so we know when we're in a dev shell
-4627
View File
File diff suppressed because it is too large Load Diff
-18
View File
@@ -1,18 +0,0 @@
[package]
name = "offchain"
version = "0.1.0"
edition = "2021"
[dependencies]
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
rand = "0.8"
hex = "0.4"
# ethers = { version = "2.0", features = ["abi"] }
anyhow = "1.0"
revm = { git = "https://github.com/bluealloy/revm.git", rev = "03ea24bd9550e93b08f343e0b410725557c1adb4", features = ["std"] }
database = { git = "https://github.com/bluealloy/revm.git", rev = "03ea24bd9550e93b08f343e0b410725557c1adb4", package = "revm-database" }
ethers = "2.0"
-530
View File
@@ -1,530 +0,0 @@
// pub trait Push3Ast {
// /// Convert this AST into a bytecode array (Push3 tokens).
// fn to_bytecode(&self) -> Vec<u8>;
// // Parse an AST from bytecode (the "decompiler"), if possible.
// // Possibly returns a Result in case of partial/invalid parse.
// // fn from_bytecode(data: &[u8]) -> Self
// // where
// // Self: Sized;
// // Randomly mutate this AST in-place (GP mutation).
// // fn mutate(&mut self, rng: &mut impl rand::Rng);
// // Possibly a "crossover" method, or we do it externally.
// // fn crossover(&self, other: &Self, rng: &mut impl rand::Rng) -> Self;
// // Evaluate the AST with some input(s).
// // Optionally do we want this or do we always run in EVM?
// // We can stub it or do an interpret approach for local test.
// // fn interpret_locally(&self, inputs: &[i32]) -> Vec<i32>;
// }
// #[derive(Debug, Clone)]
// pub enum TypedAst {
// IntLiteral(i32),
// Instruction(InstructionKind),
// }
// #[derive(Debug, Clone)]
// pub enum InstructionKind {
// Plus(Box<TypedAst>, Box<TypedAst>),
// Minus(Box<TypedAst>, Box<TypedAst>),
// Mult(Box<TypedAst>, Box<TypedAst>),
// Dup, // 0 children
// Pop, // 0 children
// }
// impl Push3Ast for TypedAst {
// fn to_bytecode(&self) -> Vec<u8> {
// // do typed encoding:
// // - for Plus(e1, e2): e1 -> bytecode, e2 -> bytecode, then PLUS opcode
// unimplemented!()
// }
// // fn from_bytecode(data: &[u8]) -> Self {
// // // parse in a strictly typed manner; might fail or panic
// // // if the code doesn't line up properly
// // unimplemented!()
// // }
// // fn mutate(&mut self, rng: &mut impl rand::Rng) {
// // // e.g. randomly pick a node, replace it with something
// // // that respects the typed structure
// // unimplemented!()
// // }
// // fn interpret_locally(&self, inputs: &[i32]) -> Vec<i32> {
// // // do a normal expression evaluation. If a node is "Plus(a,b)",
// // // interpret (a) + interpret(b).
// // unimplemented!()
// // }
// }
// #[derive(Debug, Clone)]
// pub enum UntypedAst {
// /// A single token in a list-based approach, e.g. "Integer literal"
// IntLiteral(i32),
// /// "Instruction" might be a simple variant with no children,
// /// because the stack-based evaluation decides how many arguments it consumes.
// Instruction(OpCode),
// /// A sublist of tokens, e.g. "( 2 3 DUP + )"
// Sublist(Vec<UntypedAst>),
// }
// /// Possibly an enum for OpCode:
// #[derive(Debug, Clone)]
// pub enum OpCode {
// Noop,
// Plus,
// Minus,
// Mult,
// Dup,
// Pop,
// // maybe Unknown => treat as no-op
// }
// // impl Push3Ast for UntypedAst {
// // fn to_bytecode(&self) -> Vec<u8> {
// // // flatten out sublists vs instructions
// // unimplemented!()
// // }
// // // fn from_bytecode(data: &[u8]) -> Self {
// // // // parse "0x02 => INT_LITERAL => read next 4 bytes"
// // // // instructions might have no subchildren
// // // unimplemented!()
// // // }
// // // fn mutate(&mut self, rng: &mut impl rand::Rng) {
// // // // can randomly insert unknown tokens, reorder sublists, etc.
// // // // possibly produce "invalid ops => noops"
// // // unimplemented!()
// // // }
// // // fn interpret_locally(&self, inputs: &[i32]) -> Vec<i32> {
// // // // push-based interpretation:
// // // // sublist => interpret each item in sequence
// // // // if an instruction sees insufficient args => no-op
// // // unimplemented!()
// // // }
// // }
// use crate::compiler::ast::Push3Ast;
// /// An untyped AST node, matching your Push3 structure.
// #[derive(Debug, Clone)]
// pub enum UntypedAst {
// /// A single integer literal.
// IntLiteral(i32),
// /// A single push instruction (no subchildren).
// Instruction(OpCode),
// /// A sublist of items, each of which is another UntypedAst.
// Sublist(Vec<UntypedAst>),
// }
// /// Your Push3 opcodes in an untyped form.
// #[derive(Debug, Clone)]
// pub enum OpCode {
// Noop,
// Plus,
// Minus,
// Mult,
// Dup,
// Pop,
// }
// /// Implementation of `Push3Ast` for `UntypedAst`.
// ///
// /// This will produce **bytecode** compatible with your Solidity `Push3Interpreter`:
// ///
// /// - `0x00` => NOOP
// /// - `0x01` => INTEGER_PLUS
// /// - `0x02` => INT_LITERAL => next 4 bytes (little-endian i32)
// /// - `0x03` => SUBLIST => next 2 bytes (big-endian `u16` length), then the sublist contents
// /// - `0x04` => INTEGER_MINUS
// /// - `0x05` => INTEGER_MULT
// /// - `0x06` => INTEGER_DUP
// /// - `0x07` => INTEGER_POP
// ///
// /// In the Solidity parser, `SUBLIST (0x03)` consumes two bytes to determine
// /// how many bytes of tokens to read in that sublist.
// impl Push3Ast for UntypedAst {
// /// Convert this untyped AST into a flattened push3 bytecode sequence.
// fn to_bytecode(&self) -> Vec<u8> {
// match self {
// UntypedAst::IntLiteral(val) => {
// // 0x02 followed by 4 bytes of i32 (little-endian)
// let mut bytes = Vec::with_capacity(1 + 4);
// bytes.push(0x02);
// bytes.extend_from_slice(&val.to_le_bytes());
// bytes
// }
// UntypedAst::Instruction(op) => {
// // Single opcode byte
// let opcode_byte = match op {
// OpCode::Noop => 0x00,
// OpCode::Plus => 0x01,
// OpCode::Minus => 0x04,
// OpCode::Mult => 0x05,
// OpCode::Dup => 0x06,
// OpCode::Pop => 0x07,
// };
// vec![opcode_byte]
// }
// UntypedAst::Sublist(children) => {
// // 0x03 => SUBLIST
// // Then 2 bytes for length (big-endian u16),
// // Then the concatenated bytecode for all children.
// let mut payload = Vec::new();
// for child in children {
// let child_bytes = child.to_bytecode();
// payload.extend_from_slice(&child_bytes);
// }
// let sub_len = payload.len() as u16; // assume it fits in 65535
// let mut bytes = Vec::with_capacity(1 + 2 + payload.len());
// bytes.push(0x03);
// // Store the sublist length as big-endian, because readUint16 in solidity
// // does `val = uint16(word >> 240)` (effectively big-endian).
// bytes.extend_from_slice(&sub_len.to_be_bytes());
// // Then the actual sublist payload
// bytes.extend_from_slice(&payload);
// bytes
// }
// }
// }
// }
// #[derive(Debug, Clone, PartialEq)]
// pub enum SExpr {
// Atom(String), // e.g. "3", "DUP", "+"
// List(Vec<SExpr>), // e.g. (3 5 +)
// }
// fn tokenize(s: &str) -> Vec<String> {
// let mut tokens = Vec::new();
// let mut current = String::new();
// for c in s.chars() {
// match c {
// '(' | ')' => {
// // If we were building up an atom, push it first
// if !current.trim().is_empty() {
// tokens.push(current.trim().to_string());
// }
// current.clear();
// // Then push the single-char token
// tokens.push(c.to_string());
// }
// ' ' | '\t' | '\n' | '\r' => {
// // Whitespace => if we have an atom, finish it
// if !current.trim().is_empty() {
// tokens.push(current.trim().to_string());
// current.clear();
// }
// }
// _ => {
// // Part of an atom
// current.push(c);
// }
// }
// }
// // If something is left in 'current' at the end
// if !current.trim().is_empty() {
// tokens.push(current.trim().to_string());
// }
// tokens
// }
// fn parse_sexpr(tokens: &[String], pos: &mut usize) -> Result<SExpr, String> {
// // If we’re out of tokens, error
// if *pos >= tokens.len() {
// return Err("Unexpected end of tokens".into());
// }
// let token = &tokens[*pos];
// match token.as_str() {
// "(" => {
// // Parse a list
// *pos += 1; // consume '('
// let mut list_items = Vec::new();
// while *pos < tokens.len() && tokens[*pos] != ")" {
// let expr = parse_sexpr(tokens, pos)?;
// list_items.push(expr);
// }
// if *pos >= tokens.len() {
// return Err("Missing closing parenthesis".into());
// }
// // consume ")"
// *pos += 1;
// Ok(SExpr::List(list_items))
// }
// ")" => {
// // Should never parse_sexpr starting with ')'
// Err("Unexpected ')'".into())
// }
// _ => {
// // Atom
// let atom_str = token.clone();
// *pos += 1;
// Ok(SExpr::Atom(atom_str))
// }
// }
// }
// /// Parse an entire string into a single top-level `SExpr`.
// fn parse_string_to_sexpr(s: &str) -> Result<SExpr, String> {
// let tokens = tokenize(s);
// let mut pos = 0;
// let expr = parse_sexpr(&tokens, &mut pos)?;
// // If there's leftover tokens, optionally check
// if pos < tokens.len() {
// return Err(format!("Extra tokens after parse: {:?}", &tokens[pos..]));
// }
// Ok(expr)
// }
// fn sexpr_to_untyped(expr: &SExpr) -> Result<UntypedAst, String> {
// match expr {
// SExpr::Atom(text) => {
// // 1) try to parse as i32
// if let Ok(val) = text.parse::<i32>() {
// Ok(UntypedAst::IntLiteral(val))
// } else {
// // 2) otherwise parse as OpCode symbol
// match text.to_uppercase().as_str() {
// "+" => Ok(UntypedAst::Instruction(OpCode::Plus)),
// "-" => Ok(UntypedAst::Instruction(OpCode::Minus)),
// "*" => Ok(UntypedAst::Instruction(OpCode::Mult)),
// "DUP" => Ok(UntypedAst::Instruction(OpCode::Dup)),
// "POP" => Ok(UntypedAst::Instruction(OpCode::Pop)),
// // more opcodes ...
// _ => Ok(UntypedAst::Instruction(OpCode::Noop))
// }
// }
// }
// SExpr::List(list) => {
// // parse each child into UntypedAst
// let mut result = Vec::new();
// for child in list {
// result.push(sexpr_to_untyped(child)?);
// }
// Ok(UntypedAst::Sublist(result))
// }
// }
// }
// src/compiler/ast.rs
pub trait Push3Ast {
/// Convert this AST into a bytecode array (Push3 tokens).
fn to_bytecode(&self) -> Vec<u8>;
}
/* --------------------------------------------
1) TypedAst stubs (optional)
-------------------------------------------- */
#[derive(Debug, Clone)]
pub enum TypedAst {
IntLiteral(i32),
Instruction(InstructionKind),
}
#[derive(Debug, Clone)]
pub enum InstructionKind {
Plus(Box<TypedAst>, Box<TypedAst>),
Minus(Box<TypedAst>, Box<TypedAst>),
Mult(Box<TypedAst>, Box<TypedAst>),
Dup,
Pop,
}
// Example stub; not fully implemented
impl Push3Ast for TypedAst {
fn to_bytecode(&self) -> Vec<u8> {
unimplemented!("TypedAst::to_bytecode not yet implemented");
}
}
/* --------------------------------------------
2) UntypedAst + OpCode
-------------------------------------------- */
#[derive(Debug, Clone)]
pub enum UntypedAst {
IntLiteral(i32),
Instruction(OpCode),
Sublist(Vec<UntypedAst>),
}
#[derive(Debug, Clone)]
pub enum OpCode {
Noop,
Plus,
Minus,
Mult,
Dup,
Pop,
}
/// Implementation of `Push3Ast` for `UntypedAst`.
/// Matches the Solidity-based Push3Interpreter token IDs.
impl Push3Ast for UntypedAst {
fn to_bytecode(&self) -> Vec<u8> {
match self {
UntypedAst::IntLiteral(val) => {
// 0x02 => INT_LITERAL => next 4 bytes (little-endian i32)
let mut bytes = Vec::with_capacity(1 + 4);
bytes.push(0x02);
bytes.extend_from_slice(&val.to_be_bytes());
bytes
}
UntypedAst::Instruction(op) => {
let opcode_byte = match op {
OpCode::Noop => 0x00,
OpCode::Plus => 0x01,
OpCode::Minus => 0x04,
OpCode::Mult => 0x05,
OpCode::Dup => 0x06,
OpCode::Pop => 0x07,
};
vec![opcode_byte]
}
UntypedAst::Sublist(children) => {
// 0x03 => SUBLIST => next 2 bytes = big-endian length, then sub-payload
let mut payload = Vec::new();
for child in children {
payload.extend(child.to_bytecode());
}
let sub_len = payload.len() as u16;
let mut bytes = Vec::with_capacity(1 + 2 + payload.len());
bytes.push(0x03);
bytes.extend_from_slice(&sub_len.to_be_bytes()); // big-endian
bytes.extend_from_slice(&payload);
bytes
}
}
}
}
/* --------------------------------------------
3) S-expression parsing helpers
-------------------------------------------- */
#[derive(Debug, Clone, PartialEq)]
pub enum SExpr {
Atom(String),
List(Vec<SExpr>),
}
pub fn tokenize(s: &str) -> Vec<String> {
let mut tokens = Vec::new();
let mut current = String::new();
for c in s.chars() {
match c {
'(' | ')' => {
if !current.trim().is_empty() {
tokens.push(current.trim().to_string());
}
current.clear();
tokens.push(c.to_string());
}
' ' | '\t' | '\n' | '\r' => {
if !current.trim().is_empty() {
tokens.push(current.trim().to_string());
current.clear();
}
}
_ => {
current.push(c);
}
}
}
if !current.trim().is_empty() {
tokens.push(current.trim().to_string());
}
tokens
}
fn parse_sexpr_internal(tokens: &[String], pos: &mut usize) -> Result<SExpr, String> {
if *pos >= tokens.len() {
return Err("Unexpected end of tokens".into());
}
let token = &tokens[*pos];
match token.as_str() {
"(" => {
*pos += 1; // consume '('
let mut items = Vec::new();
while *pos < tokens.len() && tokens[*pos] != ")" {
let expr = parse_sexpr_internal(tokens, pos)?;
items.push(expr);
}
if *pos >= tokens.len() {
return Err("Missing closing parenthesis".into());
}
*pos += 1; // consume ')'
Ok(SExpr::List(items))
}
")" => {
Err("Unexpected ')'".into())
}
_ => {
let atom = token.clone();
*pos += 1;
Ok(SExpr::Atom(atom))
}
}
}
/// Parse an entire string into a single top-level `SExpr`.
pub fn parse_string_to_sexpr(s: &str) -> Result<SExpr, String> {
let tokens = tokenize(s);
let mut pos = 0;
let expr = parse_sexpr_internal(&tokens, &mut pos)?;
if pos < tokens.len() {
return Err(format!("Extra tokens after parse: {:?}", &tokens[pos..]));
}
Ok(expr)
}
/// Convert an SExpr => UntypedAst
pub fn sexpr_to_untyped(expr: &SExpr) -> Result<UntypedAst, String> {
match expr {
SExpr::Atom(text) => {
if let Ok(val) = text.parse::<i32>() {
Ok(UntypedAst::IntLiteral(val))
} else {
match text.to_uppercase().as_str() {
"+" => Ok(UntypedAst::Instruction(OpCode::Plus)),
"-" => Ok(UntypedAst::Instruction(OpCode::Minus)),
"*" => Ok(UntypedAst::Instruction(OpCode::Mult)),
"DUP" => Ok(UntypedAst::Instruction(OpCode::Dup)),
"POP" => Ok(UntypedAst::Instruction(OpCode::Pop)),
_ => Ok(UntypedAst::Instruction(OpCode::Noop)),
}
}
}
SExpr::List(items) => {
let mut sub_asts = Vec::new();
for child in items {
sub_asts.push(sexpr_to_untyped(child)?);
}
Ok(UntypedAst::Sublist(sub_asts))
}
}
}
-1
View File
@@ -1 +0,0 @@
pub mod ast;
-1
View File
@@ -1 +0,0 @@
pub mod revm_runner;
-10
View File
@@ -1,10 +0,0 @@
// use crate::compiler::ast::{Expr};
// pub fn crossover(a: &Expr, b: &Expr) -> (Expr, Expr) {
// // stub
// (a.clone(), b.clone())
// }
// pub fn mutate(expr: &mut Expr) {
// // stub
// }
-13
View File
@@ -1,13 +0,0 @@
pub mod population;
pub mod genetic_ops;
// pub mod fitness;
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn test_dummy() {
assert_eq!(2+2, 4);
}
}
-9
View File
@@ -1,9 +0,0 @@
#[derive(Debug, Clone)]
pub struct Individual {
pub fitness: f64,
// your Expr or bytecode or both
}
pub struct Population {
pub individuals: Vec<Individual>,
}
File diff suppressed because one or more lines are too long
+13 -21
View File
@@ -28,9 +28,9 @@ contract Push3IntAdapter {
view
returns (uint256)
{
// CodeTag.SUBLIST is typically enum = 4, but
// let's fetch it via
// (uint8)Push3Interpreter.CodeTag.SUBLIST
// CodeTag.SUBLIST is typically enum = 3, but
// let's fetch it via
// (uint8)Push3Interpreter.CodeTag.SUBLIST
// or we can directly pass 3 if we know the numeric value.
// We'll do:
@@ -69,12 +69,9 @@ contract Push3IntAdapter {
int256[] memory initIntStack = new int256[](1);
initIntStack[0] = in1;
// No bool stack
bool[] memory initBoolStack = new bool[](0);
// 4) Run
(, , int256[] memory finalIntStack,) =
interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
(, , int256[] memory finalIntStack) =
interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
// 5) Return top of final int stack
require(finalIntStack.length > 0, "No integer output produced");
@@ -99,13 +96,11 @@ contract Push3IntAdapter {
initIntStack[0] = in1;
initIntStack[1] = in2;
bool[] memory initBoolStack = new bool[](0);
(, , int256[] memory finalIntStack,) =
interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
(, , int256[] memory finalIntStack) =
interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
require(finalIntStack.length > 0, "No integer output");
out1 = finalIntStack[finalIntStack.length - 1];
}
@@ -126,10 +121,8 @@ contract Push3IntAdapter {
int256[] memory initIntStack = new int256[](1);
initIntStack[0] = in1;
bool[] memory initBoolStack = new bool[](0);
(, , int256[] memory finalIntStack,) =
interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
(, , int256[] memory finalIntStack) =
interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
require(finalIntStack.length >= 2, "Not enough outputs");
out1 = finalIntStack[finalIntStack.length - 1];
@@ -137,7 +130,7 @@ contract Push3IntAdapter {
}
/**
* @notice Zero int input, returns entire final int stack
* @notice Zero int input, returns entire final int stack
*/
function run0InNOut(bytes calldata code)
external
@@ -150,10 +143,9 @@ contract Push3IntAdapter {
uint256[] memory initCodeStack = new uint256[](0);
int256[] memory initIntStack = new int256[](0);
bool[] memory initBoolStack = new bool[](0);
(, , int256[] memory finalIntStack,) =
interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
(, , int256[] memory finalIntStack) =
interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
return finalIntStack;
}
+98 -183
View File
@@ -9,15 +9,6 @@ import "forge-std/console.sol";
* a token-based bytecode approach.
*/
contract Push3Interpreter {
// ReadUint`numBits` out of the code range.
error ReadUintOutOfRange(uint256 numBits);
// -----------------------------------------------------
// 0. CONSTANTS
// -----------------------------------------------------
uint8 internal constant OPCODE_INTEGER_OFFSET = 0x05;
uint8 internal constant OPCODE_BOOL_OFFSET = 0x0a;
uint8 internal constant OPCODE_LAST = OPCODE_BOOL_OFFSET + 0x10;
// -----------------------------------------------------
// 1. ENUMS
// -----------------------------------------------------
@@ -25,38 +16,16 @@ contract Push3Interpreter {
NO_TAG, // 0
INSTRUCTION, // 1
INT_LITERAL, // 2
BOOL_LITERAL, // 3
SUBLIST // 4
SUBLIST // 3
}
enum OpCode {
NOOP, // 0
NOOP_1, // 1 - empty for INSTRUCTION
NOOP_2, // 2 - empty for INT_LITERAL
NOOP_3, // 3 - empty for BOOL_LITERAL
NOOP_4, // 4 - empty for SUBLIST
INTEGER_PLUS, // 5 - OPCODE_INTEGER_OFFSET
INTEGER_MINUS, // OPCODE_INTEGER_OFFSET + 1
INTEGER_MULT, // OPCODE_INTEGER_OFFSET + 2
INTEGER_DUP, // OPCODE_INTEGER_OFFSET + 3
INTEGER_POP, // OPCODE_INTEGER_OFFSET + 4
BOOL_DUP, // 10 - OPCODE_BOOL_OFFSET
BOOL_POP, // OPCODE_BOOL_OFFSET + 1
BOOL_SWAP, // OPCODE_BOOL_OFFSET + 2
BOOL_FLUSH, // OPCODE_BOOL_OFFSET + 3
BOOL_STACKDEPTH, // OPCODE_BOOL_OFFSET + 4
BOOL_NOT, // OPCODE_BOOL_OFFSET + 5
BOOL_AND, // OPCODE_BOOL_OFFSET + 6
BOOL_OR, // OPCODE_BOOL_OFFSET + 7
BOOL_EQ, // OPCODE_BOOL_OFFSET + 8
BOOL_FROMFLOAT, // OPCODE_BOOL_OFFSET + 9
BOOL_FROMINTEGER,// OPCODE_BOOL_OFFSET + 10
BOOL_ROT, // OPCODE_BOOL_OFFSET + 11
BOOL_SHOVE, // OPCODE_BOOL_OFFSET + 12
BOOL_YANK, // OPCODE_BOOL_OFFSET + 13
BOOL_YANKDUP, // OPCODE_BOOL_OFFSET + 14
BOOL_DEFINE, // OPCODE_BOOL_OFFSET + 15
BOOL_RAND // OPCODE_BOOL_OFFSET + 16
NOOP, // 0
INTEGER_PLUS, // 1
INTEGER_MINUS, // 2
INTEGER_MULT, // 3
INTEGER_DUP, // 4
INTEGER_POP // 5
}
// -----------------------------------------------------
@@ -116,81 +85,56 @@ contract Push3Interpreter {
return makeDescriptor(CodeTag.INT_LITERAL, 0, 0, masked);
}
function makeBoolLiteral(bool val) internal pure returns (uint256) {
uint256 masked;
if (val) masked = uint256(1);
return makeDescriptor(CodeTag.BOOL_LITERAL, 0, 0, masked);
}
function extractInt32(uint256 desc) internal pure returns (int32) {
// read the low 32 bits
return int32(uint32(getLow184(desc)));
}
function extractBool(uint256 desc) internal pure returns (bool) {
return desc & 1 == 1;
}
// -----------------------------------------------------
// 3. HELPER READS
// -----------------------------------------------------
/**
* @dev Read `x` bytes from `code` at `start` as uint.
*/
function readUint(bytes calldata code, uint32 start, uint256 numBytes) internal pure returns (uint256 word) {
uint256 numBits = numBytes * 8;
if (start + numBytes > code.length) revert ReadUintOutOfRange(numBits);
assembly {
let buf := mload(0x40) // free memory
// copy exactly x bytes from code into buf
calldatacopy(buf, add(code.offset, start), numBytes)
word := mload(buf)
}
word >>= 256 - numBits;
}
/**
* @dev Read 4 bytes from `code` at `start` as uint32.
*/
function readUint32(bytes calldata code, uint32 start) internal pure returns (uint32 val) {
val = uint32(readUint(code, start, 4));
require(start + 4 <= code.length, "readUint32 out of range");
uint256 word;
assembly {
let buf := mload(0x40) // free memory
// copy exactly 4 bytes from code into buf
calldatacopy(buf, add(code.offset, start), 4)
word := mload(buf)
}
val = uint32(word >> 224);
}
/**
* @dev Read 2 bytes from `code` at `start` as uint16.
*/
function readUint16(bytes calldata code, uint32 start) internal pure returns (uint16 val) {
val = uint16(readUint(code, start, 2));
}
/**
* @dev Read 1 byte from `code` at `start` as uint8.
*/
function readUint8(bytes calldata code, uint32 start) internal pure returns (uint8 val) {
val = uint8(readUint(code, start, 1));
}
/**
* @dev Read 1 byte from `code` at `start` as bool.
*/
function readBool(bytes calldata code, uint32 start) internal pure returns (bool val) {
val = readUint(code, start, 1) & 1 == 1;
require(start + 2 <= code.length, "readUint16 out of range");
uint256 word;
assembly {
let buf := mload(0x40)
calldatacopy(buf, add(code.offset, start), 2)
word := mload(buf)
val := and(word, 0xffff)
}
// Not sure this is correct
val = uint16(word >> 240);
}
// -----------------------------------------------------
// 4. SUBLIST PARSING
// -----------------------------------------------------
/**
* Token format is combination of ordered CodeTag and OpCode:
* 0x00 => NOOP/NO_TAG
* 0x01 => INSTRUCTION => read next 1 byte => OpCode
* Token format:
* 0x00 => NOOP
* 0x01 => INTEGER_PLUS
* 0x02 => INT_LITERAL => read next 4 bytes => int32
* 0x03 => BOOL_LITERAL => read next 1 byte => bool
* 0x04 => SUBLIST => read next 2 bytes => subLen => parse that
* 0x05 => INTEGER_PLUS
* 0x06 => INTEGER_MINUS
* ... opcode list with type offsets
* 0x03 => SUBLIST => read next 2 bytes => subLen => parse that
* 0x04 => INTEGER_MINUS
*/
function parseSublist(bytes calldata code, uint32 off, uint32 len)
internal
@@ -216,15 +160,9 @@ contract Push3Interpreter {
count++;
}
else if (tokenType == 0x01) {
// INSTRUCTION
if (cur + 1 <= endPos && (cur + 1) <= code.length) {
uint8 opcode = readUint8(code,cur);
if (opcode < OPCODE_INTEGER_OFFSET || opcode > OPCODE_LAST) opcode = uint8(0); // NOOP
temp[count] = makeInstruction(OpCode(opcode));
count++;
} else {
break;
}
// INTEGER_PLUS
temp[count] = makeInstruction(OpCode.INTEGER_PLUS);
count++;
}
else if (tokenType == 0x02) {
// INT_LITERAL => 4 bytes
@@ -239,17 +177,6 @@ contract Push3Interpreter {
}
}
else if (tokenType == 0x03) {
// BOOL_LITERAL
if (cur + 1 <= endPos && (cur + 1) <= code.length) {
bool val = readBool(code, cur);
cur += 1;
temp[count] = makeBoolLiteral(val);
count++;
} else {
break;
}
}
else if (tokenType == 0x04) {
// SUBLIST => read 2 bytes => length
if (cur + 2 <= endPos && (cur + 2) <= code.length) {
uint16 subLen = readUint16(code, cur);
@@ -267,9 +194,22 @@ contract Push3Interpreter {
break;
}
}
else if (tokenType <= OPCODE_LAST) {
// OPCODE
temp[count] = makeInstruction(OpCode(tokenType));
else if (tokenType == 0x04) {
// INTEGER_PLUS
temp[count] = makeInstruction(OpCode.INTEGER_MINUS);
count++;
}
else if (tokenType == 0x05) {
// INTEGER_PLUS
temp[count] = makeInstruction(OpCode.INTEGER_MULT);
count++;
}
else if (tokenType == 0x06) {
temp[count] = makeInstruction(OpCode.INTEGER_DUP);
count++;
}
else if (tokenType == 0x07) {
temp[count] = makeInstruction(OpCode.INTEGER_POP);
count++;
}
else {
@@ -289,19 +229,17 @@ contract Push3Interpreter {
// 5. MAIN INTERPRETER
// -----------------------------------------------------
function runInterpreter(
bytes calldata code, // non-empty - genetic agent (DNA)
uint256[] calldata initCodeStack, // empty
uint256[] calldata initExecStack, // descriptors
int256[] calldata initIntStack, // 32bit word
bool[] calldata initBoolStack // bool array
bytes calldata code,
uint256[] calldata initCodeStack,
uint256[] calldata initExecStack,
int256[] calldata initIntStack
)
external
pure
returns (
uint256[] memory finalCodeStack,
uint256[] memory finalExecStack,
int256[] memory finalIntStack,
bool[] memory finalBoolStack
int256[] memory finalIntStack
)
{
// A) CODE STACK
@@ -325,13 +263,6 @@ contract Push3Interpreter {
intStack[k] = initIntStack[k];
}
// D) BOOL STACK
bool[] memory boolStack = new bool[](initBoolStack.length + 256);
uint256 boolTop = initBoolStack.length;
for (uint256 k = 0; k < initBoolStack.length; k++) {
boolStack[k] = initBoolStack[k];
}
// D) MAIN LOOP
while (execTop > 0) {
uint256 topDesc = execStack[execTop - 1];
@@ -341,56 +272,50 @@ contract Push3Interpreter {
if (tag == CodeTag.INSTRUCTION) {
OpCode op = getOpCode(topDesc);
if (uint8(op) < OPCODE_INTEGER_OFFSET) {
// NOOP, do nothing
if (op == OpCode.NOOP) {
// do nothing
}
else if (uint8(op) < OPCODE_BOOL_OFFSET) {
// INTEGER OPCODES
if (op == OpCode.INTEGER_PLUS) {
// pop top 2 => sum
if (intTop >= 2) {
int256 a = intStack[intTop - 1];
int256 b = intStack[intTop - 2];
intTop -= 2;
intStack[intTop] = b + a;
intTop++;
}
}
else if (op == OpCode.INTEGER_MINUS) {
// pop top 2 => minus
if (intTop >= 2) {
int256 a = intStack[intTop - 1];
int256 b = intStack[intTop - 2];
intTop -= 2;
intStack[intTop] = b - a;
intTop++;
}
}
else if (op == OpCode.INTEGER_MULT) {
// pop top 2 => minus
if (intTop >= 2) {
int256 a = intStack[intTop - 1];
int256 b = intStack[intTop - 2];
intTop -= 2;
intStack[intTop] = b * a;
intTop++;
}
}
else if (op == OpCode.INTEGER_DUP) {
if (intTop >= 1) {
int256 a = intStack[intTop - 1];
intStack[intTop] = a;
intTop++;
}
}
else if (op == OpCode.INTEGER_POP) {
if (intTop >= 1) {
intTop -= 1;
}
else if (op == OpCode.INTEGER_PLUS) {
// pop top 2 => sum
if (intTop >= 2) {
int256 a = intStack[intTop - 1];
int256 b = intStack[intTop - 2];
intTop -= 2;
intStack[intTop] = b + a;
intTop++;
}
}
else if (uint8(op) <= OPCODE_LAST) {
// BOOL OPCODES
else if (op == OpCode.INTEGER_MINUS) {
// pop top 2 => minus
if (intTop >= 2) {
int256 a = intStack[intTop - 1];
int256 b = intStack[intTop - 2];
intTop -= 2;
intStack[intTop] = b - a;
intTop++;
}
}
else if (op == OpCode.INTEGER_MULT) {
// pop top 2 => minus
if (intTop >= 2) {
int256 a = intStack[intTop - 1];
int256 b = intStack[intTop - 2];
intTop -= 2;
intStack[intTop] = b * a;
intTop++;
}
}
else if (op == OpCode.INTEGER_DUP) {
if (intTop >= 1) {
int256 a = intStack[intTop - 1];
intStack[intTop] = a;
intTop++;
}
}
else if (op == OpCode.INTEGER_POP) {
if (intTop >= 1) {
intTop -= 1;
}
}
}
else if (tag == CodeTag.INT_LITERAL) {
@@ -398,11 +323,6 @@ contract Push3Interpreter {
intStack[intTop] = int256(val);
intTop++;
}
else if (tag == CodeTag.BOOL_LITERAL) {
bool val = extractBool(topDesc);
boolStack[boolTop] = val;
boolTop++;
}
else if (tag == CodeTag.SUBLIST) {
// parse sublist => push in reverse
uint32 off = getOffset(topDesc);
@@ -410,8 +330,8 @@ contract Push3Interpreter {
if (off + len <= code.length) {
uint256[] memory parsed = parseSublist(code, off, len);
for (uint256 p = 0; p < parsed.length; p++) { // index 0 1 2
execStack[execTop] = parsed[parsed.length - 1 - p]; // [0x01, 0x20, 0x0a]
for (uint256 p = 0; p < parsed.length; p++) {
execStack[execTop] = parsed[parsed.length - 1 - p];
execTop++;
}
}
@@ -436,10 +356,5 @@ contract Push3Interpreter {
for (uint256 i = 0; i < intTop; i++) {
finalIntStack[i] = intStack[i];
}
finalBoolStack = new bool[](boolTop);
for (uint256 i = 0; i < boolTop; i++) {
finalBoolStack[i] = boolStack[i];
}
}
}
+11 -11
View File
@@ -23,12 +23,12 @@ contract Push3IntAdapterTest is Test {
}
/**
* @notice Test run1In1Out with a minimal code array.
* For example, we might do a program that just leaves its input unchanged
* (like a NOOP).
* @notice Test run1In1Out with a minimal code array.
* For example, we might do a program that just leaves its input unchanged
* (like a NOOP).
*/
function test_run1In1Out_noop() public view {
bytes memory code = hex"04000100";
bytes memory code = hex"03000100";
int256 inputVal = 123;
int256 result = adapter.run1In1Out(code, inputVal);
@@ -41,21 +41,21 @@ contract Push3IntAdapterTest is Test {
* @notice Test run2In1Out. We'll push 5, 7, do an op that leaves 12.
*/
function test_run2In1Out_plus() public view {
bytes memory code = hex"04000105";
bytes memory code = hex"03000101";
int256 in1 = 5;
int256 in2 = 7;
int256 result = adapter.run2In1Out(code, in1, in2);
assertEq(result, 12, "Expected 5 + 7 = 12");
}
/**
* @notice Test run1In2Out. Push a constant to a stack with 1.
* For now, we do a placeholder code.
* For now, we do a placeholder code.
*/
function test_run1In2Out() public view {
bytes memory code = hex"0400050200000003";
bytes memory code = hex"0300050200000003";
int256 inVal = 42;
(int256 top, int256 secondTop) = adapter.run1In2Out(code, inVal);
@@ -65,12 +65,12 @@ contract Push3IntAdapterTest is Test {
}
/**
* @notice Test run0InNOut.
* @notice Test run0InNOut.
* We'll feed a code that pushes some constants, and see the final stack.
*/
function test_run0InNOut() public view {
bytes memory code = hex"04000A02000000030200000005";
bytes memory code = hex"03000A02000000030200000005";
int256[] memory stackResult = adapter.run0InNOut(code);
+48 -66
View File
@@ -23,30 +23,30 @@ contract Push3InterpreterTest is Test {
* 3) Calls INTEGER_PLUS
*
* We'll store everything in a single SUBLIST:
* 0x04 => SUBLIST
* 0x03 => SUBLIST
* 0x00 0x0B => subLen=11
* Then the next 11 bytes are:
* 0x02 + (00 00 00 0A) => INT_LITERAL(10)
* 0x02 + (00 00 00 20) => INT_LITERAL(32)
* 0x05 => INTEGER_PLUS
* 0x01 => INTEGER_PLUS
*
* So total = 1 + 2 + (1+4 + 1+4 + 1) = 14 bytes
* => 0x04 00 0B 02 00 00 00 0A 02 00 00 00 20 05
* => 0x03 00 0B 02 00 00 00 0A 02 00 00 00 20 01
*/
function test_LiteralsAndPlus() public view {
// The final code array (14 bytes):
// [0] = 0x04
// [0] = 0x03
// [1..2] = 0x000B
// [3] = 0x02
// [4..7] = 0x0000000A => 10
// [8] = 0x02
// [9..12] = 0x00000020 => 32
// [13] = 0x05 => plus
// [13] = 0x01 => plus
bytes memory code = hex"04000B020000000A020000002005";
bytes memory code = hex"03000B020000000A020000002001";
// Or fully concatenated:
// 0x04 00 0B 02 00 00 00 0A 02 00 00 00 20 05
// 0x03 00 0B 02 00 00 00 0A 02 00 00 00 20 01
// We'll parse offset=0, length=14
uint256 sublistDesc = interpreter.makeDescriptor(
@@ -61,15 +61,13 @@ contract Push3InterpreterTest is Test {
initExecStack[0] = sublistDesc;
int256[] memory initIntStack = new int256[](0);
bool[] memory initBoolStack = new bool[](0);
// Run it
(
,
,
int256[] memory finalIntStack
,
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
// Should produce finalIntStack = [42]
assertEq(finalIntStack.length, 1, "finalIntStack should have length 1");
@@ -80,25 +78,25 @@ contract Push3InterpreterTest is Test {
* @notice Test pushing literal 10, literal 3, then INTEGER_MINUS => (10 - 3) = 7
*
* The plan:
* 0x04 => SUBLIST token
* 0x03 => SUBLIST token
* 0x00 0x0B => subLen=11
*
* Then 11 bytes:
* 0x02 + (00 00 00 0A) => INT_LITERAL(10)
* 0x02 + (00 00 00 03) => INT_LITERAL(3)
* 0x06 => INTEGER_MINUS (assuming 0x06 is assigned to minus)
* 0x04 => INTEGER_MINUS (assuming 0x04 is assigned to minus)
*/
function test_Minus() public view {
// We'll produce 14 total bytes, same structure as the plus example
// Format: [0x04, 0x000B, 0x02(10), 0x03(3), 0x06 => minus]
// Format: [0x03, 0x000B, 0x02(10), 0x03(3), 0x04 => minus]
bytes memory code = hex"04000B020000000A020000000306";
bytes memory code = hex"03000B020000000A020000000304";
// Breaking it down:
// 0x04 => SUBLIST
// 0x03 => SUBLIST
// 0x00 0x0B => length=11
// 0x02 0000000A => INT_LITERAL(10)
// 0x02 00000003 => INT_LITERAL(3)
// 0x06 => INTEGER_MINUS
// 0x04 => INTEGER_MINUS
// We'll parse offset=0, length=14
uint256 sublistDesc = interpreter.makeDescriptor(
@@ -113,15 +111,13 @@ contract Push3InterpreterTest is Test {
initExecStack[0] = sublistDesc;
int256[] memory initIntStack = new int256[](0);
bool[] memory initBoolStack = new bool[](0);
// Run
(
,
,
int256[] memory finalIntStack
,
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
// Check final result => should be [7]
assertEq(finalIntStack.length, 1, "finalIntStack should have length 1");
@@ -132,25 +128,25 @@ contract Push3InterpreterTest is Test {
* @notice Test pushing literal 10, literal 3, then INTEGER_MULT => (10 * 3) = 30
*
* The plan:
* 0x04 => SUBLIST token
* 0x03 => SUBLIST token
* 0x00 0x0B => subLen=11
*
* Then 11 bytes:
* 0x02 + (00 00 00 0A) => INT_LITERAL(10)
* 0x02 + (00 00 00 03) => INT_LITERAL(3)
* 0x07 => INTEGER_MULT
* 0x05 => INTEGER_MULT
*/
function test_Mult() public view {
// We'll produce 14 total bytes, same structure as the plus example
// Format: [0x04, 0x000B, 0x02(10), 0x02(3), 0x07 => mul]
// Format: [0x03, 0x000B, 0x02(10), 0x03(3), 0x05 => mul]
bytes memory code = hex"04000B020000000A020000000307";
bytes memory code = hex"03000B020000000A020000000305";
// Breaking it down:
// 0x04 => SUBLIST
// 0x03 => SUBLIST
// 0x00 0x0B => length=11
// 0x02 0000000A => INT_LITERAL(10)
// 0x02 00000003 => INT_LITERAL(3)
// 0x07 => INTEGER_MUL
// 0x05 => INTEGER_MUL
// We'll parse offset=0, length=14
uint256 sublistDesc = interpreter.makeDescriptor(
@@ -165,15 +161,13 @@ contract Push3InterpreterTest is Test {
initExecStack[0] = sublistDesc;
int256[] memory initIntStack = new int256[](0);
bool[] memory initBoolStack = new bool[](0);
// Run
(
,
,
int256[] memory finalIntStack
,
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
// Check final result => should be [30]
assertEq(finalIntStack.length, 1, "finalIntStack should have length 1");
@@ -182,12 +176,12 @@ contract Push3InterpreterTest is Test {
function test_Dup() public view {
bytes memory code = hex"040006020000000A08";
bytes memory code = hex"030006020000000A06";
uint256 sublistDesc = interpreter.makeDescriptor(
Push3Interpreter.CodeTag.SUBLIST,
0,
9,
0,
9,
0
);
@@ -196,15 +190,13 @@ contract Push3InterpreterTest is Test {
initExecStack[0] = sublistDesc;
int256[] memory initIntStack = new int256[](0);
bool[] memory initBoolStack = new bool[](0);
// Run
(
,
,
int256[] memory finalIntStack
,
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
assertEq(finalIntStack.length, 2, "finalIntStack should have length 1");
assertEq(finalIntStack[0], finalIntStack[1], "The top 2 values on the stack should be equal.");
@@ -212,12 +204,12 @@ contract Push3InterpreterTest is Test {
function test_Pop() public view {
bytes memory code = hex"040006020000000A09";
bytes memory code = hex"030006020000000A07";
uint256 sublistDesc = interpreter.makeDescriptor(
Push3Interpreter.CodeTag.SUBLIST,
0,
9,
0,
9,
0
);
@@ -226,35 +218,33 @@ contract Push3InterpreterTest is Test {
initExecStack[0] = sublistDesc;
int256[] memory initIntStack = new int256[](0);
bool[] memory initBoolStack = new bool[](0);
// Run
(
,
,
int256[] memory finalIntStack
,
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
assertEq(finalIntStack.length, 0, "finalIntStack should be empty");
}
/**
* @notice Test with an unknown token (0xF0).
* We expect the parser to treat it as "unknown => NOOP"
* We expect the parser to treat it as "unknown => NOOP"
* and produce a NOOP instruction descriptor.
* We'll confirm finalIntStack remains empty (or unchanged).
*/
function test_UnknownToken() public view {
// We'll create a 5-byte code:
// 0x04 => SUBLIST
// 0x03 => SUBLIST
// 0x00 0x01 => length=1
// 0xF0 => unknown token
bytes memory code = hex"040001F0";
bytes memory code = hex"030001F0";
// We'll parse offset=0, length=4
uint256 sublistDesc = interpreter.makeDescriptor(
Push3Interpreter.CodeTag.SUBLIST,
Push3Interpreter.CodeTag.SUBLIST,
0, // offset
4, // length
0
@@ -265,14 +255,12 @@ contract Push3InterpreterTest is Test {
uint256[] memory initExecStack = new uint256[](1);
initExecStack[0] = sublistDesc;
int256[] memory initIntStack = new int256[](0);
bool[] memory initBoolStack = new bool[](0);
(
,
,
int256[] memory finalIntStack
,
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
// finalIntStack should remain empty => no literal was pushed
assertEq(finalIntStack.length, 0, "Expected finalIntStack to remain empty with unknown token => NOOP");
@@ -280,18 +268,18 @@ contract Push3InterpreterTest is Test {
/**
* @notice Test a partial literal: we claim to have 4 bytes, but the code array ends early.
* This should trigger the `else { break; }` branch in parseSublist
* This should trigger the `else { break; }` branch in parseSublist
* when trying to read 4 bytes for the INT_LITERAL.
*/
function test_OutOfRangeLiteral() public view {
// 0x04 => SUBLIST
// 0x03 => SUBLIST
// 0x00 0x04 => length=4
// 0x02 => INT_LITERAL token
// Then we have only 1 byte left instead of 4 => insufficient
//
// total = 1 + 2 + 1 + 1 = 5 bytes
// The parser tries to read 4 bytes after seeing 0x04, fails, hits break.
bytes memory code = hex"04000402FF";
bytes memory code = hex"03000402FF";
// parse offset=0, length=5
uint256 sublistDesc = interpreter.makeDescriptor(
@@ -305,14 +293,12 @@ contract Push3InterpreterTest is Test {
uint256[] memory initExecStack = new uint256[](1);
initExecStack[0] = sublistDesc;
int256[] memory initIntStack = new int256[](0);
bool[] memory initBoolStack = new bool[](0);
(
,
,
int256[] memory finalIntStack
,
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
// Because the parse breaks early, we expect finalIntStack is empty or unchanged
assertEq(finalIntStack.length, 0, "Expected parse to break on out-of-range literal => no ints pushed");
@@ -324,12 +310,12 @@ contract Push3InterpreterTest is Test {
* In the main loop, it sees intTop < 2 => it does nothing.
*/
function test_NotEnoughIntArgs() public view {
bytes memory code = hex"040006020000000307";
bytes memory code = hex"030006020000000305";
// Breaking it down:
// 0x04 => SUBLIST
// 0x03 => SUBLIST
// 0x00 0x06 => length=6
// 0x02 00000003 => INT_LITERAL(3)
// 0x07 => INTEGER_MUL
// 0x05 => INTEGER_MUL
uint256 sublistDesc = interpreter.makeDescriptor(
Push3Interpreter.CodeTag.SUBLIST,
@@ -343,16 +329,14 @@ contract Push3InterpreterTest is Test {
uint256[] memory initExecStack = new uint256[](1);
initExecStack[0] = sublistDesc;
int256[] memory initIntStack = new int256[](0);
bool[] memory initBoolStack = new bool[](0);
(
,
,
int256[] memory finalIntStack
,
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
// We expect finalIntStack => [5],
// We expect finalIntStack => [5],
// because the PLUS instruction sees only 1 int => does nothing => 5 remains
assertEq(finalIntStack.length, 1, "Should have 1 int left");
assertEq(finalIntStack[0], 3, "Expected stack top=3 after insufficient-args plus");
@@ -360,12 +344,12 @@ contract Push3InterpreterTest is Test {
/**
* @notice Test sublist length overflow:
* subLen claims bigger than the code array. Should trigger else { break; }
* subLen claims bigger than the code array. Should trigger else { break; }
* in the sublist parsing for that sublist.
*/
function test_SublistLengthOverflow() public view {
bytes memory code = hex"050010FFFFFF";
bytes memory code = hex"050010FFFFFF";
uint256 sublistDesc = interpreter.makeDescriptor(
Push3Interpreter.CodeTag.SUBLIST,
@@ -379,14 +363,12 @@ contract Push3InterpreterTest is Test {
uint256[] memory initExecStack = new uint256[](1);
initExecStack[0] = sublistDesc;
int256[] memory initIntStack = new int256[](0);
bool[] memory initBoolStack = new bool[](0);
(
,
,
int256[] memory finalIntStack
,
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack, initBoolStack);
) = interpreter.runInterpreter(code, initCodeStack, initExecStack, initIntStack);
// Expect no items pushed => finalIntStack empty
assertEq(finalIntStack.length, 0, "Expected empty stack if sublist length is out of range => parse break");
+178 -29
View File
@@ -1,53 +1,202 @@
# SoLUSH: Running Intelligence On-Chain
# Sovraigns: Verifiable Optimization for DeFi Protocols
In decentralized finance, systems often involve tasks such as determining optimal liquidity ranges for automated market makers, allocating staking rewards in a way that balances fairness and participation incentives, or dynamically adjusting collateralization ratios to minimize risks in lending protocols. These challenges are critical for ensuring the efficiency and stability of protocols, yet they are particularly difficult to address without centralization. Off-chain solutions often rely on external computation and centralized entities or oracles, introducing trust dependencies and undermining the decentralized ethos of blockchain systems.
## The Problem
Artificial intelligence is increasingly being explored in decentralized finance to enhance token ecosystems and liquidity management. This shift represents a practical application of AI tools aimed at addressing complex optimization problems directly within blockchain ecosystems. While large language models (LLMs) dominate discussions around AI innovation due to their general-purpose capabilities, they are poorly suited to the demands of decentralized adaptive systems. In contrast, **genetic algorithms** (GAs) offer a more natural and efficient fit for systems requiring iterative improvements, combining computational simplicity with adaptive behavior.
DeFi protocols lose approximately $1.5B annually through inefficient parameter settings. Uniswap V3 liquidity providers lose ~$400M from suboptimal position ranges. Lending protocols forfeit ~$300M by maintaining overly conservative collateral ratios. MEV extraction costs protocols ~$800M due to predictable parameter updates.
## **Introduction to Genetic Algorithms**
Protocols need optimization algorithms, but current approaches require trust:
Genetic algorithms (GAs) are optimization techniques inspired by the process of natural selection. They operate by evolving a population of candidate solutions over multiple generations, using mechanisms such as mutation, crossover, and selection.
- External consultants (Gauntlet, Chaos Labs) operate as black boxes with enterprise-only access
- AI services require sharing sensitive protocol data with third parties
- On-chain execution is prohibitively expensive - a simple neural network would cost millions in gas
- **Population:** A set of potential solutions to a problem.
- **Fitness Function:** A way to evaluate how well each solution performs.
- **Selection:** The process of choosing the best-performing solutions to carry forward.
- **Crossover and Mutation:** Methods to combine and modify solutions, creating new ones that explore the problem space.
Protocols must choose between inefficiency or centralization.
Through repeated iterations, GAs converge toward optimal or near-optimal solutions, making them highly effective for solving complex, dynamic problems. GAs have recently gained momentum with the development of the [Push 3 language](http://faculty.hampshire.edu/lspector/push3-description.html) by Lee Spector. Push 3’s compact and efficient architecture shares similarities with stack-based virtual machine systems like the Ethereum Virtual Machine (EVM). Although not designed specifically for EVMs, Push 3’s simplicity and flexibility make it conceptually compatible with blockchain execution environments. Push 3 has achieved milestones such as evolving [programs for quantum computers](https://faculty.hampshire.edu/lspector/aqcp/) and supporting autoconstructive evolution. A Push 3 VM could facilitate the deployment of genetic algorithms in decentralized systems, leveraging Push 3’s support for expressive program evolution and adaptive behavior in tasks like resource optimization.
## Our Approach
## On Agents
Sovraigns enables verifiable optimization through genetic algorithms, zero-knowledge proofs, and based rollups:
An agent is defined as an entity capable of perceiving its environment, processing information, and taking autonomous actions to achieve specific objectives. LLMs can be structured into agents using frameworks that provide memory and feedback loops, but they do not fit on-chain and, at the same time, cannot securely manage secrets like private keys. Without either of these capabilities, LLM-based agents require external key management, increasing risks and undermining decentralized security principles. In contrast, genetic algorithms exhibit agentic characteristics by evolving their behavior over time to meet specific goals. When deployed on-chain within smart contracts, GAs can autonomously adapt to real-time inputs and optimize decisions, all while operating entirely within the secure and deterministic framework of blockchain systems.
1. Algorithms evolve off-chain through competition between optimizers
2. Zero-knowledge proofs verify correct execution without revealing the algorithm
3. A based rollup coordinates requests and stores proven results
---
Protocols receive optimized parameters with cryptographic proof of correctness, without trusting any party.
## **Genetic Algorithms vs. LLMs for Decentralized Systems**
## Market Size
1. **Efficiency and Feasibility for Blockchain Execution**
Current DeFi inefficiencies:
- **LLMs are resource-intensive:** The computational complexity and size of LLMs make them impractical for direct execution in decentralized environments, where every operation incurs costs. Running even the simplest inference for an LLM would require off-chain computation and trust in external oracles, undermining decentralization.
- **GAs are lightweight:** Genetic algorithms, by design, are computationally efficient. Their iterative, population-based approach to optimization fits naturally into resource-constrained environments. This efficiency ensures GAs can evolve and execute entirely on-chain, preserving transparency and trustless execution.
| **DeFi Inefficiency** | **Annual Value Lost** | **Root Cause** |
|---|---|---|
| Uniswap V3 LP Losses | ~$400M | Suboptimal position management |
| Lending Protocol Inefficiency | ~$300M | Conservative parameters |
| MEV/Arbitrage Extraction | ~$800M | Predictable protocol behavior |
| **Total Market** | **$1.5B+** | **Lack of intelligent optimization** |
2. **Evolution vs. Training**
With DeFi TVL at $50B, we estimate the optimization market at $2-3B annually today, potentially reaching $10B as protocols become more complex.
- **GAs evolve in parallel:** Genetic algorithms enable evolutionary processes to run across distributed populations simultaneously. This parallelism contrasts with the centralized training required for deep neural networks, which demand synchronized computation and significant infrastructure. GAs’ decentralized nature aligns well with blockchain environments.
### Current Solutions vs. Sovraigns
- **Deep neural networks require centralized training:** Neural networks demand substantial computational resources and centralized coordination to train effectively.
| **Aspect** | **Current Solutions** | **Sovraigns** |
|---|---|---|
| **Trust Model** | Centralized (Gauntlet, Chaos Labs) | Trustless ZK proofs |
| **Accessibility** | Enterprise contracts only | Permissionless for all protocols |
| **Transparency** | Black box optimization | Fully auditable algorithms |
| **Cost** | High consulting fees | Pay-per-optimization |
| **Adaptability** | Manual updates | Continuous evolution |
| **Security** | Single point of failure | Decentralized validation |
3. **Auditability of Evolution vs Training**
- **Training LLMs is opaque:** The progress of training deep neural networks is often difficult to evaluate and verify because testing its capabilities relies on secret data, which cannot be audited by external parties.
- **GAs offer transparent evolution:** Genetic algorithms allow the progress of evolution to be easily audited against a target fitness function. This process is fully observable and can be verified at each step with minimal effort.
## Why Genetic Algorithms Over LLMs
---
Technical comparison for decentralized systems:
## **Theoretical Framework for Decentralized Algorithm Evolution**
| **Aspect** | **LLMs** | **Genetic Algorithms** |
|---|---|---|
| **Computational Requirements** | GPUs, massive memory, centralized inference | Lightweight, runs anywhere |
| **Blockchain Compatibility** | Impossible on-chain, requires external APIs | Efficient ZK-proof verification |
| **Trust Model** | Black box, external dependencies | Fully verifiable with cryptographic proofs |
| **Cost** | $1000s per complex optimization | Pennies per optimization |
| **Adaptability** | Fixed after training | Continuously evolves to market conditions |
| **Determinism** | Non-deterministic, unreliable | Deterministic, predictable outputs |
| **Decentralization** | Requires centralized providers | Fully decentralized execution |
A protocol providing agents as a service could leverage genetic algorithms to address complex problems within blockchain environments. Read through this [real-life usecase explaining the applicability of agents to DeFi](example.md). Central to such a system would be the development of a Push 3 Virtual Machine (VM), enabling efficient execution of genetic algorithms. An "Optimizer Pool", an network of nodes could collaboratively train and evolve these algorithms offchain. These nodes would compete to improve the fitness of the algorithms. Once an improvement, a measuruable better solution to the fitness function is found in off-chain computation, a node would submit it to be accepted into the population of solutions registered on chain, in exchange for a rewards payment by the protocol. The nodes of the optimizer pool would run under an incentivization model simira to proof-of-work systems.
Genetic algorithms provide the optimization capabilities of LLMs while remaining verifiable, deterministic, and cost-effective for blockchain environments.
![Components](/components.png)
## Technical Architecture
Three core components enable verifiable optimization on Ethereum:
1. **Based Rollup Coordination**
- Manages algorithm registry and optimization requests
- Batches proofs for cost-effective verification
- Inherits Ethereum's security model
2. **OpenVM Execution Environment**
- Runs genetic algorithms in a provable VM
- Generates STARK proofs for each optimization
- Ensures deterministic execution
3. **Optimizer Network**
- Independent nodes compete to evolve better algorithms
- Council validates quality before on-chain registration
- Economic incentives tied to algorithm performance
### Architecture Overview
The protocol operates across three layers:
```
┌─────────────────────────────────────────────────────────────────┐
│ ETHEREUM L1 │
│ • Final Settlement • Proof Verification • Protocol Updates │
└────────────────────────────┬───────────────────────────────────┘
│ State Bridge
┌────────────────────────────┴───────────────────────────────────┐
│ BASED ROLLUP (Sidechain) │
│ • Task Registry • Algorithm Storage • Coordination │
│ • Reward Pools • Version History • Batch Requests │
└────────────────────────────┬───────────────────────────────────┘
│ ZK Proofs
┌────────────────────────────┴───────────────────────────────────┐
│ OFF-CHAIN COMPUTE │
│ • Algorithm Evolution • OpenVM Execution • Proof Generation │
│ • Council Validation • Optimizer Competition │
└─────────────────────────────────────────────────────────────────┘
```
| **Layer** | **Purpose** | **Key Components** |
|---|---|---|
| **Ethereum L1** | Final settlement and security | Smart contracts, State verification |
| **Based Rollup** | Decentralized coordination | Task registry, Algorithm storage |
| **Off-Chain** | Computation and evolution | OpenVM, Genetic algorithms, ZK proofs |
### Based Rollup: Decentralized Coordination
1. **Task Registration**: DeFi protocols register optimization tasks on the based rollup, including:
- Fitness functions (optimization goals)
- Evaluation parameters and constraints
- Reward pools for successful optimizations
2. **Algorithm Registry**: The best algorithms for each task are registered on-chain after council validation
- Algorithm hashes stored on-chain for verification
- ZK proofs verify the exact algorithm (matching hash) was executed
- Version history maintained for auditability
- Permissionless access for all protocols
3. **Execution Requests**: When protocols need optimization:
- Send request to based rollup with current data
- Request triggers off-chain execution
- Multiple requests batched for efficiency
### Off-Chain: Evolution and Zero-Knowledge Execution
1. **Algorithm Evolution**:
- Optimizers run genetic algorithms using standard Push 3 implementations
- Evolution happens on local high-performance infrastructure
- Best solutions submitted to council for validation
- No ZK proofs needed during evolution phase
2. **Zero-Knowledge Proof Generation** (triggered by on-chain requests):
- Registered algorithms execute in OpenVM with request data
- OpenVM verifies the algorithm matches the on-chain hash
- STARK proofs generated via Plonky3
- Proofs include complete execution trace and results
- Multiple proofs batched into rollup blocks
3. **Council Validation**:
- Distributed validators verify algorithm improvements
- Consensus required before on-chain registration
- Ensures quality without centralized control
### L1 Integration: Trustless Protocol Updates
1. **State Bridge**: Based rollup posts state roots to Ethereum
2. **Proof Verification**: Smart contracts verify STARK proofs
3. **Action Execution**: DeFi protocols execute optimizations based on verified results
### Key Components
- **Registry (based rollup)**: Task and algorithm management with ZK verification
- **OpenVM Runtime**: Custom Push 3 implementation for genetic programming
- **Optimizers (off-chain)**: Compete to evolve better solutions
- **Council (distributed)**: Validates algorithm quality before registration
- **Proof Aggregator**: Batches multiple ZK proofs for efficient verification
- **State Bridge**: Synchronizes rollup state with Ethereum L1
## Timing
Three technical developments make this feasible now:
1. **ZK Infrastructure**
- STARK proving systems now production-ready
- Proof generation costs decreased 100x since 2022
- OpenVM provides suitable execution environment
2. **Based Rollups**
- Ethereum's rollup infrastructure mature enough for production
- Provides coordination without sacrificing decentralization
- Cost structure makes continuous optimization viable
3. **Market Demand**
- Protocols reaching limits of manual parameter tuning
- Increased scrutiny requires auditable optimization
- Competition driving need for efficiency gains
## Competitive Position
**Technical Differentiation:**
- First implementation of ZK-verified genetic algorithms for DeFi
- Custom VM optimized for this use case
- Integration with Ethereum's rollup infrastructure
**Network Effects:**
- More protocols using the system improves algorithm quality
- Optimizer competition creates continuous improvement
- Registry accumulates valuable optimization history
**Barriers to Entry:**
- Requires expertise in genetic programming, zero-knowledge systems, and DeFi mechanics
- Complex coordination between multiple system layers
- Significant development time to reach production quality
We aim to become the standard optimization layer for DeFi protocols, addressing a multi-billion dollar inefficiency.
To evaluate the effectiveness of distributed evolution, a "Council" mechanism needs to be created. This Council would consist of validators who execute the latest evolved algorithms and assess their performance against a predefined target fitness function. Validators would then cast votes on whether the new algorithms deliver measurable improvements. This transparent voting process ensures that only the most effective solutions are rewarded and integrated, fostering trust and collaboration across the Optimizer Pool. By aligning incentives with measurable progress, such a framework provides a reliable and decentralized method for advancing algorithmic evolution.
Ultimately, this system creates a foundation for scalable agent development, aligning with the broader concept of agents as a service, where users and protocols in DeFi can deploy and leverage optimized, evolving algorithms tailored to specific tasks.