O criador do Ethereum, Vitalik Buterin, está investigando um novo conceito de como a computação moderna pode ser dividida em duas partes: um componente de “cola” e um “coprocessador”.
A ideia aqui é simples: dividir o trabalho. A cola faz as tarefas gerais, não tão intensas, enquanto o coprocessador cuida das computações pesadas e estruturadas.
Vitalik nos explica, dizendo que a maioria dos cálculos em sistemas como a Ethereum Virtual Machine (EVM) já são divididos dessa forma. Algumas partes do processo precisam de alta eficiência, enquanto outras são mais flexíveis, mas menos eficientes.
Tome Ethereum, por exemplo. Em uma transação recente onde Vitalik atualizou o hash IPFS do seu blog no Ethereum Name Service (ENS), o consumo de gás foi espalhado por diferentes tarefas. A transação queimou um total de 46.924 gás.
A repartição se parece com isso: 21.000 gás para o custo base, 1.556 para calldata e 24.368 para execução EVM. Operações específicas como SLOAD e SSTORE consumiram 6.400 e 10.100 gás, respectivamente. Operações LOG consumiram 2.149 gás, e o resto foi consumido por processos diversos.
Vitalik diz que cerca de 85% do gás dessa transação foi para algumas operações pesadas, como leituras e gravações de armazenamento, registro e criptografia.
O resto era o que ele chama de “lógica de negócios”, as coisas mais simples e de nível superior, como processar os dados que determinam qual registro atualizar.
Vitalik também aponta que você pode ver a mesma coisa em modelos de IA escritos em Python. Por exemplo, ao executar um passe para frente em um modelo de transformador, a maior parte do trabalho é feita por operações vetorizadas, como multiplicação de matrizes.
Essas operações são geralmente escritas em código otimizado, frequentemente CUDA rodando em GPUs. A lógica de alto nível, no entanto, está em Python — uma linguagem geral, mas lenta, que só toca uma pequena parte do custo computacional total.
O desenvolvedor do Ethereum também acredita que esse padrão está se tornando mais comum na criptografia programável moderna, como SNARKs.
Ele aponta tendências na comprovação STARK, onde equipes estão criando provadores de uso geral para máquinas virtuais mínimas como RISC-V.
Qualquer programa que precise ser provado pode ser compilado em RISC-V, e o provador prova a execução RISC-V. Essa configuração é conveniente, mas vem com sobrecarga. A criptografia programável já é cara, e adicionar o custo de executar o código dentro de um interpretador RISC-V é muito.
Então, o que os desenvolvedores fazem? Eles contornam o problema. Eles identificam as operações específicas e caras que ocupam a maior parte da computação — como hashes e assinaturas — e criam módulos especializados para provar essas operações de forma eficiente.
Então eles combinam o sistema geral de comprovação RISC-V com esses sistemas eficientes e especializados, obtendo o melhor dos dois mundos. Essa abordagem, Vitalik observa, provavelmente será vista em outras áreas da criptografia, como computação multipartidária (MPC) e criptografia totalmente homomórfica (FHE).
Onde entram a cola e o coprocessador
De acordo com Vitalik, o que estamos vendo é o surgimento de uma arquitetura de “cola e coprocessador” na computação. A cola é geral e lenta, responsável por manipular dados entre um ou mais coprocessadores, que são especializados e rápidos. GPUs e ASICs são exemplos perfeitos de coprocessadores.
Eles são menos gerais que CPUs, mas muito mais eficientes para certas tarefas. A parte complicada é encontrar o equilíbrio certo entre generalidade e eficiência.
No Ethereum, o EVM não precisa ser eficiente, ele só precisa ser familiar. Ao adicionar os coprocessadores ou pré-compilações corretos, você pode tornar uma VM ineficiente quase tão eficaz quanto uma nativamente eficiente.
Mas e se isso não importasse? E se aceitássemos que chips abertos seriam mais lentos e usássemos cola e arquitetura de coprocessador para compensar?
A ideia é que você possa projetar um chip principal otimizado para segurança e design de código aberto, usando módulos ASIC proprietários para os cálculos mais intensivos.
Tarefas sensíveis podem ser tratadas pelo chip principal seguro, enquanto o trabalho pesado, como processamento de IA ou comprovação de ZK, pode ser transferido para os módulos ASIC.
