El creador de Ethereum, Vitalik Buterin, está investigando un nuevo concepto sobre cómo la informática moderna puede dividirse en dos partes: un componente “pegamento” y un “coprocesador”.
La idea aquí es simple: dividir el trabajo. El pegamento hace las tareas generales, no tan intensas, mientras que el coprocesador se encarga de los cálculos pesados y estructurados.
Vitalik nos lo explica, diciendo que la mayoría de los cálculos en sistemas como la máquina virtual Ethereum (EVM) ya están divididos de esta manera. Algunas partes del proceso necesitan una alta eficiencia, mientras que otras son más flexibles pero menos eficientes.
Tomemos Ethereum como ejemplo. En una transacción reciente en la que Vitalik actualizó el hash IPFS de su blog en el Ethereum Name Service (ENS), el consumo de gas se distribuyó entre diferentes tareas. La transacción consumió un total de 46.924 gas.
El desglose se ve así: 21.000 gas para el costo base, 1.556 para calldata y 24.368 para la ejecución de EVM. Las operaciones específicas como SLOAD y SSTORE consumieron 6.400 y 10.100 gas, respectivamente. Las operaciones LOG consumieron 2.149 gas y el resto fue consumido por procesos diversos.
Vitalik dice que alrededor del 85% del gas en esa transacción se destinó a unas pocas operaciones pesadas, como lecturas y escrituras de almacenamiento, registro y criptografía.
El resto era lo que él llama “lógica empresarial”, las cosas más simples y de alto nivel, como procesar los datos que dictan qué registro actualizar.
Vitalik también señala que se puede ver lo mismo en los modelos de IA escritos en Python. Por ejemplo, cuando se ejecuta un paso hacia adelante en un modelo de transformador, la mayor parte del trabajo se realiza mediante operaciones vectorizadas, como la multiplicación de matrices.
Estas operaciones suelen estar escritas en código optimizado, a menudo CUDA ejecutándose en GPU. Sin embargo, la lógica de alto nivel está en Python, un lenguaje general pero lento que solo afecta a una pequeña parte del costo computacional total.
El desarrollador de Ethereum también cree que este patrón se está volviendo más común en la criptografía programable moderna, como SNARKs.
Señala las tendencias en las pruebas STARK, donde los equipos están construyendo probadores de propósito general para máquinas virtuales mínimas como RISC-V.
Cualquier programa que necesite ser probado puede compilarse en RISC-V, y el probador prueba la ejecución en RISC-V. Esta configuración es conveniente, pero conlleva gastos generales. La criptografía programable ya es costosa, y agregar el costo de ejecutar código dentro de un intérprete RISC-V es mucho.
Entonces, ¿qué hacen los desarrolladores? Solucionan el problema. Identifican las operaciones específicas y costosas que ocupan la mayor parte del cálculo (como los hashes y las firmas) y crean módulos especializados para demostrar que estas operaciones son eficientes.
Luego, combinan el sistema de prueba general RISC-V con estos sistemas especializados y eficientes, obteniendo lo mejor de ambos mundos. Este enfoque, señala Vitalik, probablemente se verá en otras áreas de la criptografía, como la computación multipartita (MPC) y el cifrado completamente homomórfico (FHE).
¿Dónde entran en juego el pegamento y el coprocesador?
Según Vitalik, lo que estamos viendo es el auge de una arquitectura de “pegamento y coprocesador” en informática. El pegamento es general y lento, responsable de manejar datos entre uno o más coprocesadores, que son especializados y rápidos. Las GPU y los ASIC son ejemplos perfectos de coprocesadores.
Son menos generales que las CPU, pero mucho más eficientes para determinadas tareas. La parte complicada es encontrar el equilibrio adecuado entre generalidad y eficiencia.
En Ethereum, la máquina virtual de Ethereum no necesita ser eficiente, solo necesita ser familiar. Al agregar los coprocesadores o precompilaciones correctos, puede hacer que una máquina virtual ineficiente sea casi tan efectiva como una nativamente eficiente.
Pero ¿qué pasaría si esto no importara? ¿Qué pasaría si aceptáramos que los chips abiertos serían más lentos y usáramos una arquitectura de pegamento y coprocesador para compensar?
La idea es que puedas diseñar un chip principal optimizado para la seguridad y el diseño de código abierto mientras utilizas módulos ASIC propietarios para los cálculos más intensivos.
Las tareas sensibles podrían ser manejadas por el chip principal seguro, mientras que el trabajo pesado, como el procesamiento de IA o la prueba ZK, podría ser descargado a los módulos ASIC.
