問題
DeFi協議無法在不需要信任假設的情況下最佳化其引數。他們要麼每年向像Gauntlet這樣的諮詢公司支付數百萬美元，要麼使用靜態引數，導致資金利用不充分。這些數字相當可觀——Uniswap V3的流動性提供者因糟糕的範圍管理損失了數億美元，借貸協議維持了不必要的保守引數。
顯而易見的解決方案是在鏈上執行最佳化演算法，但這是不可行的。大語言模型和神經網路需要浮點矩陣運算、數千兆位元組的記憶體和非確定性取樣。即使是簡單的模型也會產生數百萬的gas費用。
不同的路徑：零知識遺傳程式設計
我正在構建一個用於PUSH3的zkVM，這是一種專為遺傳程式設計設計的基於棧的語言。其思路很直接：
- 最佳化器使用標準遺傳程式設計技術在鏈下進化演算法
- 當協議需要最佳化時，演算法在zkVM中執行
- 協議透過正確執行的STARK證明獲得結果
遺傳演算法在這裡適用，因為它們只是對棧進行算術運算——沒有矩陣，沒有浮點複雜性，只有可以清晰對映到算術電路的整數數學運算。
技術方法
PUSH3語言
PUSH3是一種簡單的棧語言，對不同型別有獨立的棧（整數、浮點數、布林值、程式碼、執行、名稱）。程式只是操作和文字的序列。如果一個操作沒有足夠的引數在棧上，它會變成空操作而不是崩潰。
示例程式：
( 價格 波動性 浮點數.* 2.0 浮點數./範圍.最小 浮點數.- 範圍.最大 浮點數.+ )zkVM實現
該實現獲取PUSH3程式並使用OpenVM生成其執行的STARK證明：
PUSH3程式 → 軌跡記錄 → OpenVM晶片 → STARK證明證明生成大約需要2分鐘，併產生約500KB的證明。這些證明可以被捲入STARK並在鏈上提交。
當前狀態
已完成：
- 整數/浮點數/布林值棧上的基本算術運算（加、減、乘、除）
- 饋送到OpenVM的軌跡記錄
- 使用Plonky3的STARK證明生成
尚未實現：
- 程式碼/執行/名稱棧（實際遺傳程式設計所需）
- 大多數棧操作（複製、移動、推送）
- 控制流操作
願景
如果這被建設成一個Rollup，以太坊將獲得一些有趣的東西：任何可以定義適應度函式的協議都可以進化自己的最佳化演算法。
我設想以下效果：
- AMM進化費用層和集中流動性範圍
- 借貸協議進化風險引數和利率曲線
- 期權協議進化定價模型
- MEV保護進化對抗策略
所有這些都無需信任任何人——只需證明演算法正確執行的數學證明。
一個可能的發展路徑：完成zkVM，然後探索作為基礎Rollup部署。其想法是建立一個登錄檔，協議使用適應度函式請求最佳化，任何人都可以提交解決方案，根據適應度函式最佳的方案被註冊，並在鏈上證明和驗證其執行。
這不是為了取代人類判斷或構建通用人工智慧。而是為以太坊提供原生最佳化能力，且不需要信任。其他鏈正在新增人工智慧協處理器和大語言模型預言機——以太坊可以擁有真正在鏈上工作的東西。
未解決問題選集
- 進化的PUSH3程式是否足夠表達複雜的DeFi最佳化？ 遺傳程式設計可以發現令人驚訝的解決方案，但基於棧的語言是否真的能編碼諸如集中流動性定位或多資產風險管理等複雜策略所需的內容？
- 這裡的實際成本效益是什麼？ 為每次最佳化執行生成STARK證明會增加開銷。對於頻繁更新的引數，驗證的gas成本是否值得無需信任？尤其是當演算法本身可能很平庸時？
- 如何處理演算法輸入？ DeFi最佳化需要價格饋送、總鎖倉量資料、歷史波動性——每個資料來源是否都需要自己的zkVM介面卡？
- 如何防止過度擬合？ 在歷史資料上進化的演算法可能看起來完美，但在新的市場條件下可能會災難性地失敗。
- 如果仍然需要信任適應度函式設計，無需信任的最佳化是否真的有價值？ 糟糕的適應度函式可能比靜態引數更糟。
- 是否可以使用更容易驗證的確定性最佳化演算法獲得類似結果？
