O problema
Os protocolos DEFI não podem otimizar seus parâmetros sem suposições de confiança. Eles pagam consultores como Gauntlet Millions por ano ou ficam com parâmetros estáticos que deixam dinheiro na mesa. Os números são substanciais – os LPs do UNISWAP V3 perdem centenas de milhões para o gerenciamento de baixa faixa, os protocolos de empréstimos mantêm parâmetros desnecessariamente conservadores.
A solução óbvia seria executar algoritmos de otimização na cadeia, mas isso não é viável. LLMS e redes neurais requerem operações de matriz de ponto flutuante, gigabytes de memória e amostragem não determinística. Mesmo modelos simples custariam milhões em gás.
Um caminho diferente: programação genética no conhecimento zero
Estou construindo ZK-Pushr A ZKVM para push3, uma linguagem baseada em pilha projetada para programação genética. A ideia é direta:
- Otimizadores evoluem algoritmos fora da cadeia usando técnicas de programação genética padrão
- Quando um protocolo precisa de otimização, o algoritmo é executado em um ZKVM
- O protocolo obtém resultados com uma comprovante de execução correta
Os algoritmos genéticos funcionam aqui porque são apenas operações aritméticas em pilhas – sem matrizes, sem loucura de ponto flutuante, apenas matemática inteira que mapeia de maneira limpa para circuitos aritméticos.
Abordagem técnica
Linguagem push3
Push3 é uma linguagem de pilha simples, com pilhas separadas para diferentes tipos (número inteiro, flutuador, booleano, código, executão, nome). Os programas são apenas sequências de operações e literais. Se uma operação não tiver argumentos suficientes na pilha, ela se tornará um NO-OP em vez de travar.
Exemplo de programa:
( PRICE VOLATILITY FLOAT.* 2.0 FLOAT./
RANGE.MIN FLOAT.- RANGE.MAX FLOAT.+ )
A implementação do ZKVM
A implementação pega programas push3 e gera provas de sua execução usando o OpenVM:
PUSH3 Program → Trace Recording → OpenVM Chips → STARK Proof
A geração de prova leva cerca de 2 minutos e produz ~ 500 KB de provas. Essas provas podem então ser enroladas em um Stark a ser enviado em corrente.
Estado atual
Trabalhando:
- Aritmética básica (add, sub, mul, div) em pilhas inteiras/flutuantes/booleanas
- Rastreamento de rastreamento que alimenta o OpenVM
- Geração de prova stark usando plonky3
Ainda não implementado:
- Código/Exec/Name Stacks (necessário para a programação genética real)
- A maioria da manipulação da pilha (dup, Yank, empurrão)
- Operações de fluxo de controle
A visão
Se isso for construído em um rollup, o Ethereum ganha algo interessante: qualquer protocolo que possa definir uma função de condicionamento físico pode desenvolver seus próprios algoritmos de otimização.
Eu imagino os seguintes efeitos:
- O AMMS evolui camadas de taxa e faixas de liquidez concentradas
- Protocolos de empréstimos evoluem parâmetros de risco e curvas de interesse
- Protocolos de opções evoluem modelos de preços
- A proteção do MEV evolui contra-estratégias
Tudo sem confiar em ninguém – apenas a matemática prove que o algoritmo funcionou corretamente.
Um possível caminho de desenvolvimento: termine o ZKVM e explore a implantação como um rollup baseado. A idéia seria um registro em que os protocolos solicitam otimizações com uma função de condicionamento físico, qualquer um pode enviar soluções, o melhor de acordo com a função de fitness é registrado e suas execuções são comprovadas e verificadas na cadeia.
Não se trata de substituir o julgamento humano ou a construção da AGI. Trata -se de fornecer aos recursos de otimização nativa do Ethereum que não exigem confiança. Outras cadeias estão adicionando coprocessadores de IA e oráculos LLM-o Etereum pode ter algo que realmente funciona na cadeia.
Seleção de perguntas abertas
- Os programas PUSH3 evoluídos são expressivos o suficiente para a otimização real de defi? A programação genética pode descobrir soluções surpreendentes, mas uma linguagem baseada em pilha pode realmente codificar as estratégias complexas necessárias para coisas como posicionamento concentrado de liquidez ou gerenciamento de riscos com vários ativos?
- Qual é o custo-benefício real aqui? A geração de uma prova gritante para cada execução de otimização adiciona sobrecarga. Para parâmetros frequentemente atualizados, o custo da verificação do gás vale a falta de confiança? Especialmente quando o algoritmo em si pode ser medíocre?
- Como você lida com entradas de algoritmo? A otimização do defi precisa de feeds de preços, dados de TVL, volatilidade histórica – todas as fontes de dados precisam de seu próprio adaptador ZKVM?
- Como você evita o excesso de ajuste? Um algoritmo evoluiu em dados históricos pode parecer perfeito, mas falha catastroficamente em novas condições de mercado.
- A otimização sem confiança é realmente valiosa se você ainda precisar confiar no design da função de fitness? As funções ruins de condicionamento físico podem ser piores que os parâmetros estáticos.
- Você poderia obter resultados semelhantes com algoritmos de otimização determinística que são mais fáceis de verificar?
Fontesethresear
