En los últimos años, el ecosistema de Ethereum ha enfrentado desafíos significativos relacionados con la escalabilidad, impulsando la necesidad de buscar soluciones innovadoras que puedan optimizar los costos de operación mientras se mantiene la integridad y descentralización de la red. Entre estas soluciones, el OP Stack y la Máquina Virtual de Pruebas de Fallas Canon (Canon Fault Proofs VM) han surgido como elementos clave en los esfuerzos continuos por mejorar el rendimiento y la eficiencia de los rollups de Capa 2 de Ethereum.

En este sentido, esta investigación profundiza en los aspectos teóricos y prácticos del OP Stack y la VM de Pruebas de Fallos Canon, proporcionando hallazgos valiosos sobre su implementación, puntos de referencia de rendimiento y posibles mejoras futuras. Además, reúne las contribuciones y conocimientos necesarios para alcanzar los objetivos de OP city, recopilando los documentos realizados desde diciembre de 2023 hasta 2024. Su propósito es servir como punto de partida para que investigadores y estudiantes exploren y prueben la implementación de rollups del OP stack, superando sus límites a través del stack de OP city.

1. Marco Teórico del OP Stack

Basado en el repositorio OP City

Esta sección establece las bases para comprender el OP Stack y las Pruebas de Falla, elementos clave en las soluciones de escalabilidad para Ethereum. Empezamos con un análisis de los problemas de escalabilidad inherentes a Ethereum y cómo los rollups, soluciones de Capa 2, ofrecen estrategias para abordar estos desafíos. Se destaca cómo el desarrollo del OP Stack, junto con el concepto de supercadena y las pruebas de falla, son cruciales para optimizar los costos operativos en tecnologías descentralizadas. Este análisis está respaldado con referencias académicas y URLs relevantes, proporcionando una visión general de los fundamentos teóricos que impulsan estos avances.

1.1 Escalabilidad de Ethereum

Ethereum se ha consolidado como una de las plataformas blockchain más importantes, transformando la manera en que se desarrollan y operan las aplicaciones. A diferencia de los sistemas tradicionales, Ethereum es una red de computación descentralizada y de código abierto que permite a los desarrolladores crear y ejecutar contratos inteligentes, soportando una amplia gama de aplicaciones descentralizadas (dApps).

Ethereum funciona como un sistema de transición de estados, donde las transacciones modifican el estado global de las cuentas y los saldos. Esto es impulsado por la Máquina Virtual de Ethereum (EVM), un entorno de programación flexible diseñado para ejecutar contratos inteligentes y dApps complejas[1]. Los contratos inteligentes, una característica clave de Ethereum, son acuerdos autoejecutables registrados en blockchain que permiten interacciones automatizadas y de confianza implícita. Estos contratos son ampliamente utilizados en casoso como tokens personalizados, productos financieros, Organizaciones Autónomas Descentralizadas (DAOs), soluciones de almacenamiento de archivos, entre otros. La inmutabilidad e irreversibilidad de blockchain garantizan que estos contratos operen con alta integridad, resiliencia y transparencia[2].

Sin embargo, Ethereum se enfrenta al “trilema de blockchain,” un desafío que consiste en alcanzar simultáneamente escalabilidad, descentralización y seguridad, donde la mejora de un aspecto a menudo compromete a los otros. La escalabilidad se mide en transacciones por segundo (TPS), la descentralización distribuye el control a través de la red, previniendo la censura y la manipulación, y la seguridad se centra en la capacidad de resistir ataques [3].

1.2 Rollups como solución de Capa (L2)

Las blockchains tradicionales, como Bitcoin y Ethereum, son reconocidas por su seguridad y descentralización, pero enfrentan limitaciones significativas en cuanto a escalabilidad. Para abordar este desafío, Ethereum ha explorado "técnicas simples" como soluciones de Capa 2, que buscan aumentar la capacidad de la red permitiendo que diferentes aplicaciones operen en múltiples cadenas interconectadas a través de un protocolo de comunicación entre cadenas, logrando así la interoperabilidad. Aunque este enfoque es descentralizado y escalable, presenta vulnerabilidades de seguridad, ya que un atacante podría comprometer la cadena principal al obtener el control de la mayoría de los nodos de consenso en una sola cadena, generando efectos colaterales en otras cadenas interconectadas [4].

Una de las soluciones más importantes de Capa 2, es el rollup. Los rollups agrupan múltiples transacciones fuera de la cadena principal (Capa 1) y las procesan en lotes, lo que reduce la carga de trabajo de Ethereum, permite manejar más transacciones por segundo, disminuye los costos de gas, datos y cálculo requeridos [1], sin comprometer seguridad o descentralización. Existen dos tipos principales de rollups:

1. Rollups Optimistas (Optimistic Rollups): Asumen que todas las transacciones son válidas por defecto y emplean pruebas de fraude para identificar transacciones falsas dentro de un periodo de siete días.

2. Rollups de Conocimiento Cero (Zero Knowledge ZK Rollups): Proporcionan una verificación instantánea de la validez de las transacciones utilizando pruebas de validez.

La debilidad principal en términos de seguridad se encuentra en el proceso de verificación de los bloques generados por estas tecnologías de Capa 2. A diferencia de la Capa 1, donde los bloques son completamente verificados, los bloques de Capa 2 solo contienen solo las partes del estado necesarias para procesar el bloque, junto con algunos hashes que demuestran que estas partes proporcionadas representan el estado reclamado en el bloque. Esta solución implica la verificación de cálculos y la disponibilidad de datos para asegurar que el sistema ha realizado los cálculos correctamente, asumiendo que los validadores de bloques tienen acceso a todos los inputs necesarios y que éstos están almacenados de manera accesible para que cualquiera pueda descargarlos si es necesario [5].

En los Optimistic Rollups, las pruebas de fraude o falla entran en juego si surge una disputa, detectando y demostrando que un bloque o transacción específico es inválido utilizando datos merklizados. Esto permite a los nodos de la red recibir y verificar los estados de los bloques sin necesidad de descargar toda la blockchain, asumiendo que al menos un nodo honesto está dispuesto a generar estas pruebas [6]. Este mecanismo también se conoce como juego interactivo [7], donde un participante asume optimistamente que cada resultado propuesto es válido por defecto[8]. Este enfoque facilita una escalabilidad más rápida y rentable, al asumir que las transacciones son válidas por defecto [9].

1.3 Optimism y el OP stack

Optimism, una solución de escalabilidad de Capa 2 para Ethereum, utiliza Rollups Optimistas para mejorar la escalabilidad, reducir tiempo y costos de las transacciones, y mantener una seguridad robusta [10]. El núcleo de este ecosistema es OP Mainnet, una blockchain de Capa 2 equivalente a la EVM (Ethereum Virtual Machine), conectada directamente a Ethereum y muy similar a la red principal de esta, con pequeñas diferencias principalmente relacionadas con la especificación de diferentes puntos finales de red [11].

La OP Mainnet aprovecha el OP Stack, un stack modular de software de código abierto que facilita la creación de Rollups Optimistas y blockchains de Capa 2 listas para producción. Esto permite que los desarrolladores personalizar y actualizar de forma independiente componentes como las capas de consenso, ejecución y liquidación, fomentando la innovación y garantizando la adaptabilidad a largo plazo. Además, el OP Stack es compatible con la Optimism Superchain, una red de cadenas OP Stack interoperables con estándares y protocolos comunes. Este diseño modular facilita la escalabilidad, personalización, interoperabilidad e innovación, ayudando a evitar el desarrollo repetitivo de software similar desde cero [12].

Un avance importante hacia la descentralización total ha sido la introducción de un Sistema de Pruebas de Falla en OP Mainnet. Lo que elimina la dependencia de roles privilegiados para los retiros y permite que cualquier usuario desafíe y verifique transacciones, reduciendo la centralización y fomentando una mayor seguridad en la red.

Conforme el OP Stack continúa evolucionando, se espera la incorporación de funcionalidades adicionales, como sistemas de pruebas de fallas más avanzados y mejores funciones de interoperabilidad. Esto allanará el camino para un ecosistema más robusto e interconectado de aplicaciones descentralizadas en Ethereum. La versión actual del OP Stack, conocida como Optimism Bedrock, no solo impulsa la OP Mainnet sino que también simplifica el despliegue de rollups optimistas y respalda el concepto de Superchain. Esta visión busca construir un ecosistema blockchain escalable e interconectado, donde múltiples cadenas de Capa 2 (L2) puedan interactuar sin problemas, aprovechando estándares compartidos de seguridad y desarrollo.

A medida que la tecnología se consolide en términos de seguridad y fiabilidad, el plan es extender estas capacidades, incluidas las Pruebas de Fraude, a otras redes dentro del ecosistema de Optimism, como Base, Metal, Mode y Zora. Esta expansión reforzará el concepto de Superchain y ampliará los límites de escalabilidad e interoperabilidad de Capa 2  [13].

1.4 Capas del OP Stack

Basado en la documentación de Optimism

El OP Stack se puede entender como un conjunto de componentes de software que definen nuevas capas o se integran como módulos dentro de stack, permitiendo construir un ecosistema de blockchain de Capa 2. A continuación, se presenta un desglose detallado de sus capas:

1.4.1. Capa de Disponibilidad de Datos (Data Availability)

La Capa de Disponibilidad de Datos define dónde se publican las entradas en bruto de una cadena basada en OP Stack. Una cadena OP Stack puede utilizar uno o más módulos de disponibilidad de datos para obtener sus datos de entrada. Estos módulos utilizados tienen un impacto significativo en el modelo de seguridad del sistema. Actualmente, el módulo de Disponibilidad de Datos más utilizado es el de Ethereum, lo que permite que los datos de origen provengan de cualquier información accesible en la blockchain de Ethereum, incluyendo calldata de Ethereum, eventos y blobs de datos 4844.

1.4.2. Capa de Secuenciación (Sequencing Layer)

La Capa de Secuenciación determina cómo se recopilan y publican las transacciones de los usuarios en una cadena OP Stack hacia los módulos de disponibilidad de datos en uso. En la configuración predeterminada de rollups del OP Stack, la secuenciación es manejada generalmente por un único secuenciador dedicado. Las reglas definidas en la Capa de Derivación limitan la capacidad del secuenciador para retener transacciones más allá de un período específico de tiempo.

1.4.3. Capa de Derivación (Derivation Layer)

La Capa de Derivación define cómo se procesan los datos en bruto de la Capa de Disponibilidad de Datos para formar las entradas procesadas que se envían a la Capa de Ejecución a través de la API estándar de Ethereum Engine. Esta capa también puede usar el estado del sistema actual, tal como lo define la Capa de Ejecución, para informar el análisis de los datos de entrada en bruto. Se puede ajustar para derivar entradas de API de diversas fuentes de datos y está estrechamente vinculada a la Capa de Disponibilidad de Datos.

1.4.4. Capa de Ejecución (Execution Layer)

La Capa de Ejecución define la estructura del estado dentro de un sistema OP Stack y establece la función de transición de estado que modifica este estado. Las transiciones de estado se activan cuando se reciben entradas de la Capa de Derivación a través de la API de Engine. La abstracción de esta capa permite modificaciones en la EVM o en diferentes máquinas virtuales subyacentes.

EVM

La EVM es un módulo de la Capa de Ejecución que utiliza la misma representación de estado y función de transición de estado que la Máquina Virtual de Ethereum. El módulo EVM en la configuración de Rollup de Ethereum de la OP Stack es una versión ligeramente modificada que añade soporte para transacciones de Capa 2 iniciadas en Ethereum y agrega una tarifa de datos L1 a cada transacción para cubrir el costo de publicar transacciones en Ethereum.

1.4.5. Capa de Liquidación (Settlement Layer)

La Capa de Liquidación es un mecanismo que se encuentra en blockchains externas y establece una vista del estado de una cadena OP Stack en dichas cadenas (incluyendo otras cadenas OP Stack). Para cada cadena OP Stack, puede haber uno o más mecanismos de Liquidación en una o más cadenas externas. Los mecanismos de esta capa son solo de lectura y permiten que partes externas a la blockchain tomen decisiones basadas en el estado de una cadena OP Stack.

El término "Capa de Liquidación" tiene su origen en el hecho de que los mecanismos de la Capa de Liquidación se utilizan a menudo para manejar retiros de ETH y tokens fuera de una blockchain. Este proceso de retiro implica primero verificar el estado de la blockchain objetivo en alguna cadena de terceros y luego procesar el retiro basado en dicho estado. En esencia, la Capa de Liquidación permite que una cadena de terceros tome conocimiento del estado de la cadena objetivo.

Un mecanismo de Prueba de Falla basado en atestaciones utiliza un protocolo optimista para establecer una vista del estado de una cadena OP Stack. En los mecanismos de liquidación optimistas, las entidades proponentes pueden proponer lo que consideran que es el estado válido actual de la cadena OP Stack. Si estas propuestas no son invalidadas dentro de un período determinado de tiempo (el "período de desafío"), entonces el mecanismo asume que las propuestas son correctas. En particular, en el mecanismo de Prueba de Atestación, una propuesta puede ser invalidada si un cierto umbral de participantes predefinidos proporciona atestaciones de un estado válido que es diferente al estado de la propuesta. Esto supone la confianza en la honestidad de al menos un número umbral de estos participantes predefinidos.

1.4.6. Capa de Gobernanza (Governance Layer)

La Capa de Gobernanza se refiere al conjunto general de herramientas y procesos utilizados para gestionar la configuración del sistema, las actualizaciones y las decisiones de diseño. Es una capa relativamente abstracta, que puede incluir una amplia variedad de mecanismos tanto en una cadena OP Stack objetivo como en cadenas de terceros, impactando en muchas de las otras capas del OP Stack.

2. Configuración de Nodo y Rollup

Basado en el Repositorio de OP City

Esta sección proporciona una explicación completa de nuestra experiencia al configurar y ejecutar un nodo, así como desplegar un rollup utilizando el OP Stack. Llevamos a cabo el proceso de configuración utilizando dos dispositivos Intel NUC 13 PRO NUC13ANHi7 Arena Canyon, cada uno equipado con un CPU Intel Core i7-1360P de 13ª generación, 32GB de RAM y un SSD de 4TB que ejecuta Linux (Ubuntu).

En las pruebas realizadas en diciembre, utilizamos una VM remota y un servicio RPC de terceros. Sin embargo, esta configuración presentó desafíos importantes, principalmente en relación a las limitaciones de las llamadas RPC y las restricciones impuestas por el hardware propietario. Además, el uso de servicios RPC de terceros generó tiempos de espera y planteó preocupaciones de seguridad, afectando negativamente el rendimiento general de nuestro entorno de prueba. La dependencia a una VM remota limitó nuestro control sobre el hardware, lo que causó problemas de escalabilidad y confiabilidad durante la fase de pruebas.

Para superar estos desafíos, migramos a una configuración de entorno local utilizando los dispositivos Intel NUC. Esta transición nos permitió eliminar las limitaciones de los servicios RPC de terceros y obtener un control total sobre el hardware, lo que resultó en un entorno de prueba más confiable y eficiente. Documentamos todo el proceso de configuración en nuestro repositorio de GitHub, incluyendo los comandos y capturas de pantalla para guiar a otros desarrolladores en el despliegue de un rollup, que se divide en dos etapas principales para su implementación en la testnet Holesky.

2.1 Iniciar un nodo L1 (Testnet Holesky)

• Instrucciones de configuración de Geth (Capa de Ejecución)

• Instrucciones de configuración de Prysm (Capa de Consenso)

Esta etapa detalla los pasos para configurar un nodo L1, comenzando con la adquisición del hardware necesario. Los dispositivos Intel NUC proporcionaron la potencia de cómputo adecuada para la instalación de Linux (Ubuntu) y configurar las dependencias de Geth y Prysm. Posteriormente, instalamos y ejecutamos Geth, que forma la capa base de la red Ethereum, seguido de la instalación e inicialización de Prysm, lo que facilitó la ejecución del mecanismo de consenso de prueba de participación. Esta resultó en un nodo L1 robusto, capaz de soportar despliegues posteriores de rollups.

2.2 Desplegar un rollup L2 desde la OP Stack

• Instrucciones de configuración y despliegue del OP Stack

• Configuración del tablero de visualización de datos del OP Stack

Basándonos en la infraestructura del nodo L1, documentamos el proceso de despliegue de un rollup L2 utilizando el OP Stack. Comenzamos instalando las dependencias necesarias de Optimism y compilando el código fuente. Luego procedimos a desplegar los contratos en L1 e iniciamos la instancia de OP-GETH, lo que implicó configurar y ejecutar componentes clave como op-geth y op-node. El proceso culminó con la obtención de Holesky ETH en la red L2 y el envío de transacciones de prueba, demostrando el despliegue exitoso de un rollup en un entorno local controlado.

3. Benchmark de versiones del OP Stack

Basado en el Repositorio de OP City

Esta sección presenta los resultados de tres despliegues de prueba realizados, uno en diciembre 2023 y dos en junio de 2024. Los análisis exhiben una reducción significativa en los costos de operación del batcher y del proposer al usar el OP Stack V4.0.0 Canyon en diciembre, en comparación con los despliegues con OP Stack V7.0.0. Fjord, realizados en junio de 2024 . La diferencia más notable entre estas versiones, es la reducción en las tarifas totales de gas utilizadas por el rollup con la V7.0.0 aproximadamente un 75% menos de los costos de operación que con la V4.0.0. Además, en los despliegues de junio se compararon el uso del método calldata versus data blobs, para registrar datos en la Capa 1, revelando que los data blobs consumen aproximadamente un 60% menos recursos que el call data.

3.1 Despliegue de Prueba 1: OP stack V4.0.0 (diciembre 2023)

Del 4 al 11 de diciembre de 2023, realizamos una evaluación exploratoria del rendimiento de los costos operativos del OP Stack en un entorno de testnet, enfocándonos específicamente en el gasto de gas del batcher y proposer. Esta fase de pruebas fue programada estratégicamente antes de las actualizaciones Dencun, Ecotone y Fjord, con el fin de prepararnos para la implementación de características avanzadas como span batches, data blobs y fault proofs, que aún no estaban implementadas. Durante el despliegue de 7 días del OP stack en la Testnet Sepolia, el batcher generó un número significativo de transacciones (~27,000), lo que resultó en un gasto importante de gas (~9.5 ETH), a pesar de no haber interacciones adicionales de usuarios o contratos.

Utilizamos una Máquina Virtual en Google Cloud para desplegar un rollup OP con la siguiente configuración:

• Tipo de máquina: e2-standard-2

• Núcleos: 2 vCPU

• Memoria: 8 GB

Después de conectarnos a un nodo de Sepolia a través de Alchemy, instalamos las dependencias y construimos el Optimism Monorepo y op-geth. Posteriormente, creamos las cuatro cuentas que gestionan la operación del rollup:

• La cuenta de Admin (0x…92D5) puede actualizar contratos.

• La cuenta de Batcher(0x…898ce) publica los datos de transacciones del secuenciador en L1.

• La cuenta de Proposer(0x…B561) publica los resultados de las transacciones de L2 en L1.

• La cuenta de Sequencer(0x…3868) firma bloques en la red p2p.

Adicionalmente, se creó un contrato Bridge para la transferencia de fondos al rollup.

3.1.1. Hallazgos principales

Durante este despliegue inicial, nos enfrentamos a varias limitaciones relacionadas con los costos operativos del batcher y proposer, así como restricciones derivadas del servicio RPC. Estas dificultades se hicieron evidentes durante un despliegue de 7 días del rollup del OP Stack en la Testnet Sepolia, donde el batcher generó un alto número de transacciones (~27,000) y un consumo considerable de gas (~9.5 ETH). Como se mencionó anteriormente, esta actividad fue exclusivamente la predeterminada del rollup, sin interacciones adicionales de usuarios o contratos. Este gasto se atribuyó a las limitaciones en las llamadas RPC del proveedor (Alchemy), lo que provocó una cadena de bloques vacíos desde el secuenciador hasta el batcher, incrementando la tasa de transacciones y gasto de gas. Este comportamiento resaltó la necesidad de abordar los problemas de escalabilidad en el OP stack para soportar eficientemente un alto rendimiento y diversas interacciones de usuarios.

Al comparar los datos con el batcher de OP Sepolia, observamos una diferencia significativa en el número de transacciones realizadas durante las mismas fechas (~11,000, equivalente al 40% del periodo de referencia de 7 días), pero no en el mayor consumo de gas (~12 ETH). Esto es atribuible a que la testnet es utilizada por un gran volumen de usuarios y contratos reales. Sin embargo, esta circunstancia podría poner en riesgo la visión de Superchain, que aspira a sostener múltiples cadenas derivadas del OP Stack, las cuales no necesariamente tendrían el mismo volumen de usuarios o rendimiento, especialmente aquellas destinadas a aplicaciones no DeFi que no dependen de los ingresos del secuenciador para ser rentables.

3.2 Despliegue de Prueba 2: OP stack V7.0.0 (junio 2024)

Basado en el repositorio OP City

Tras los problemas detectados con el uso de un proveedor RPC en el primer despliegue, decidimos configurar un nodo local que proporcionara una fuente confiable de llamadas RPC. Esto nos permitió observar y medir el impacto en el número de transacciones y las tarifas de gas asociadas a cada una. El proceso de configuración se detalla en la sección anterior y en el repositorio de OP City.

Con el nodo ya configurado, desplegamos un rollup desde la OP stack en la testnet Holesky, utilizando la versión 7.0.0 Fjord y el método calldata para publicar transacciones desde el Batcher y el Proposer. Este despliegue de prueba duró 20 días y ocurrió tras múltiples actualizaciones de red, incluidas span batches, compatibilidad con data blobs y otras optimizaciones, que redujeron considerablemente los costos operativos del rollup en comparación con la prueba realizada en diciembre. Utilizando el mismo método de publicación de datos que en dicho despliegue, durante los primeros siete días, las tarifas de gas totales utilizadas en las transacciones de operación predeterminadas del rollup se redujeron en aproximadamente un 75%, pasando de 10.63 a 2.59 ETH, mientras que el costo diario disminuyó de 1.5 a 0.37 ETH.

Los datos de las direcciones del rollup están disponibles en:

• Dirección del Sequencer (0x...D4A0)

• Dirección del Batcher (0x...AD1F)

• Dirección del Proposer (0x...15C9)

• Dirección del Admin (0x...A771)

3.3 Despliegue de Prueba 3: OP stack V7.0.0 (junio 2024)

Basado en el repositorio de OP City

Aunque la reducción en las tarifas totales de gas utilizando Calldata fue significativa, la implementación de data blobs como método de publicación de datos ofrece una alternativa con el potencial de reducir aún más los costos operativo del rollup. Para demostrarlo, una semana después desplegamos un tercer rollup de testnet, utilizando la misma versión V7.0.0 y data blobs. Al comparar el rendimiento de este despliegue con respecto al anterior, identificamos lo siguiente:

• Una reducción notable en el número de transacciones realizadas por las direcciones del Batcher y el Proposer, con aproximadamente un 50% menos de actividad (más de 100k txn con calldata frente a 50k con data blobs).

• Aproximadamente un 65% menos en tarifas de gas utilizadas por el rollup (2.59 ETH con calldata frente a 0.64 ETH con data blobs en una operación de 7 días, y 0.37 frente a 0.09 ETH por día, respectivamente.

Los datos de las direcciones del rollup están disponibles en:

• Dirección del Sequencer (0x...414E)

• Dirección del Batcher (0x...1c84)

• Dirección del Proposer (0x...F093)

• Dirección del Admin (0x...AABC)

4. Cambios propuestos a Canon FPVM

Propuesto durante la Temporada 5 de Gobernanza de OP y finalista en la asignación de fondos durante el ciclo 22

Además del benchmark de dos versiones del OP Stack, OP City también integra la investigación de la compatibilidad de la Máquina Virtual de Canon Fault Proof del OP stack con el protocolo Multifase Fault Proof del opML. El objetivo es implementar un Juego de Disputa de Fallas personalizado que aborde los desafíos relacionados con la disponibilidad de datos del rollup L2 y los resultados de cómputo de las Redes Neuronales Profundas (DNN) del opML multifase. Esto será posible mediante un mecanismo de incentivos para los verificadores de nodos que resuelvan disputas en ambas tecnologías.

4.1 Modificaciones Propuestas:

OpML utiliza una prueba de fraude multifase para garantizar la precisión de los resultados de aprendizaje automático en la cadena. Este mecanismo es similar a las Pruebas de Falla Canon experimentales del OP stack. Ambas tecnologías utilizan un Juego de Disputa de Fallas para que los verificadores resuelvan desafíos en un árbol de juego. Nuestro objetivo es expandir los datos merklizados en la Máquina Virtual de Prueba de Falla (FPVM) del OP stack para incluir la transición de estado en el juego de disputa Multifase de opML. Al hacerlo, buscamos generar un marco unificado capaz de procesar nativamente inferencias de aprendizaje automático en la cadena, para mejorar o sustituir las especificaciones actuales del FPVM.

4.1.1 Modelado de la función de transición de estado.

El FPVM funciona como un sistema de transición de estado donde una función ƒ mapea un estado previo $Spre$ a un estado posterior $Spost$ basado en una instrucción ejecutada:

$𝑓(𝑆𝑝𝑟𝑒)→𝑆𝑝𝑜𝑠𝑡$

Para la integración:

• Modificación del marco propuesto: Introducir una capa adicional que maneje árboles de decisión complejos o salidas de redes neuronales, ajustando cómo se calculan las transiciones de estado, especialmente en la gestión de estados de error o excepciones.

• Considerar una función de transición de estado modificada $𝑓(𝑆𝑝𝑟𝑒,𝐷)$, donde D representa datos o decisiones derivados de los procesos de opML, impactando la transición a $Spost$.

           Función modificada:  $$ 𝑓(𝑆𝑝𝑟𝑒,𝐷)→𝑆𝑝𝑜𝑠𝑡$$
  

• Definir un nuevo componente de estado que incluya los resultados de inferencia de redes neuronales, influyendo en el proceso de transición, particularmente en la gestión de excepciones.

4.1.2.    Análisis de gestión de memoria

Dadas las especificaciones detalladas de memoria:

• Operaciones de heap y memoria: Analizar las implicaciones de integrar un mecanismo para manejar grandes conjuntos de datos requeridos por los modelos de aprendizaje automático directamente dentro de la estructura de memoria de FPVM.

• Supongamos que $M(S)$ es la función de estado del uso de memoria. Se propone introducir $M´(S,D)$ para manejar estructuras de datos adicionales o mecanismos de almacenamiento en caché para optimizar el manejo de datos de ML.

  • Función de memoria: $𝑀(𝑆)→𝑀′(𝑆,𝐷)$

4.1.3.    Mejoras de Syscalls y Entrada/Salida (I/O)

El marco propuesto podría extender potencialmente las funcionalidades de syscall e I/O para mejorar el soporte al procesamiento de datos impulsado por ML:

• Syscalls extendidos para el ML: Introducir nuevos syscalls específicos para operaciones de ML, como el procesamiento por lotes de datos o la carga de modelos.

• Modelado de I/O: Ajustar el modelo de I/O para manejar eficientemente flujos de datos más grandes, cruciales para los procesos de ML. También se proponen modificaciones como mejorar la gestión de búfer u operaciones de I/O asincrónicas.

4.1.4.    Verificación formal y análisis de errores

Dada la complejidad de las integraciones de ML y el papel crítico de la prueba de fallo:

• Modelar cómo los errores en la fase de ML pueden propagarse a través del sistema, influyendo en las transiciones de estado y los estados de memoria.

• Utilizar métodos formales para verificar la corrección del sistema integrado bajo diversas condiciones operativas, asegurando que las modificaciones no introduzcan nuevas vulnerabilidades.

4.1.5.    Simulación y métricas de evaluación

Desarrollar simulaciones que imiten condiciones operativas del mundo real para evaluar la efectividad de las modificaciones propuestas:

• Crear escenarios donde los FPVM tradicionales y modificados por ML estén sujetos a cargas típicas y atípicas, midiendo métricas de rendimiento como throughput, tasa de error y tiempo de respuesta.

• Definir métricas específicas para evaluar mejoras o retrocesos en el comportamiento del sistema debido a la integración, como eficiencia de memoria, precisión en la detección de fallos y sobrecarga computacional.

Además, con la implementación de este marco, buscamos proporcionar la infraestructura necesaria para procesar en cadena los altos volúmenes de datos públicos generados en las ciudades y utilizar modelos en cadena para hacer inferencias de ML a partir de esos conjuntos de datos. Para proteger la privacidad de los datos sensibles de los ciudadanos, exploraramos la implementación de un zkML a través del marco oppAI de ORA. Esta extensión equilibra estratégicamente los compromisos entre privacidad y eficiencia computacional. AL combinar las fortalezas de las técnicas de preservación de la privacidad de zkML y la eficiencia de opML, oppAI permite un modelo híbrido para optimizar ambos aspectos para aplicaciones de IA en la cadena.

5. Conclusiones

OP City con su investigación sobre el OP Stack y la Máquina Virtual de Pruebas de Fallas Canon (Canon Fault Proofs VM) revela un avance significativo en la escalabilidad y eficiencia de las soluciones de Capa 2 en el ecosistema de Ethereum:

• La comparación entre las versiones 4.0.0 y 7.0.0 del OP Stack ha mostrado mejoras en el código, nuevas funcionalidades y una reducción sustancial en los costos de transacciones y consumo de gas para el batcher y proposer.

• La implementación de data blobs en la versión 7.0.0 ha demostrado una reducción adicional del 65% en los costos operativos, subrayando la importancia de la innovación continua en la arquitectura de infraestructura de Optimism.

• Los ejercicios prácticos de despliegue y benchmarking han permitido validar empíricamente las mejoras teóricas, identificar áreas de optimización adicionales, proporcionar datos concretos para guiar decisiones futuras y crear un conjunto de mejores prácticas.

• La integración de la Canon Fault Proofs VM con el protocolo Multifase Fault Proof de opML abre nuevas posibilidades para expandir las capacidades de la infraestructura de Capa 2, como la implementación de un Juego de Disputa de Fallas personalizado y la exploración de zkML a través del marco oppAI.

• Las modificaciones propuestas, como la introducción de capas adicionales para el manejo de árboles de decisión y el análisis de gestión de memoria, demuestran un compromiso con la mejora continua y la adaptabilidad a las necesidades emergentes en el ámbito de las redes neuronales profundas.

En conclusión, OP City no solo demuestra que, conforme las versiones del OP Stack evolucionan, se mejora la eficiencia de las transacciones y se reducen los costos de gas operativos, sino que también permitirá optimizar la gestión de los datos públicos generados en las ciudades. A través de la infraestructura proporcionada por este marco, se busca procesar grandes volúmenes de datos en la cadena y utilizar modelos de aprendizaje automático (opML) para hacer inferencias a partir de estos conjuntos de datos. Al mismo tiempo, se protegerá la privacidad de los ciudadanos mediante zkML, ofreciendo soluciones de inteligencia artificial seguras y efectivas en la cadena.

Referencias

Ethereum y Fault Proofs

[1] Buterin, V. (2015). A Next Generation Smart Contract & Decentralized Application Platform.

[2] Karbasi, A.H., Shahpasand, S. A post-quantum end-to-end encryption over smart contract-based blockchain for defeating man-in-the-middle and interception attacks. Peer-to-Peer Netw. Appl. 13, 1423–1441 (2020).

[3] Werth, J., Hajian Berenjestanaki, M., Barzegar, H. R., El Ioini, N., & Pahl, C. (2023). A review of blockchain platforms based on the scalability, security and decentralization trilemma. Proceedings of the 19th International Conference on Web Information Systems and Technologies (WEBIST 2023).

[4] Buterin, V. (2021). Why sharding is great: demystifying the technical properties.

[5] Buterin, V. (2018). A note on data availability and erasure coding.

[6] Mustafa Al-Bassam, Alberto Sonnino, Vitalik Buterin: Fraud Proofs and Data Availability: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. CoRRabs/1809.09044 (2018)

[7] Optimism. OP stack Specification.

[8] Conway, KD., So, C., Yu, X., & Wong, K. (2024). opML: Optimistic Machine Learning on Blockchain

OP Stack

[9] Poon, J., & Buterin, V. (2016). Plasma: Scalable Autonomous Smart Contracts.

[10] Buterin, v. (2021) An Incomplete Guide to Rollups.

[11] Optimism documents: Glossary.

[12] Getting started: OP Mainnet.

[13] Optimism Developer Blog. Protocol Development: The Fault Proof System is available for the OP Stack.