Optimism 技術文書

Resumen

El documento aborda el problema de la escalabilidad en blockchains descentralizados analizando la compensación entre el rendimiento de las transacciones y los requisitos de hardware para ejecutar un nodo. Los rollups, es decir, tecnologías para la verificación en cadena de bloques ejecutados fuera de la cadena, se presentan en forma de pruebas de falla o validez. Comparamos los rollups optimistas y los rollups de validez con respecto al tiempo de retiro, los costos de transacción, las técnicas de optimización y la compatibilidad con el ecosistema Ethereum. Nuestro análisis revela que Optimism Bedrock tiene actualmente una tasa de compresión de gas de aproximadamente 20:1, mientras que StarkNet logra una tasa de compresión del costo de escritura de almacenamiento de alrededor de 24:1. También analizamos técnicas para optimizar aún más estas tasas, como el uso de contratos de caché y filtros Bloom. En última instancia, nuestras conclusiones resaltan las compensaciones entre complejidad y agilidad en la elección entre Optimistic y Validity Rollups. Palabras clave Blockchain, Escalabilidad, Rollup 1. Introducción La tecnología Blockchain ha ganado una atención significativa debido a su potencial para revolucionar diversas industrias. Sin embargo, la escalabilidad sigue siendo un desafío importante, ya que la mayoría de los blockchain__ se enfrentan a un equilibrio entre escalabilidad, descentralización y seguridad, comúnmente conocido como el trilema de la escalabilidad [1, 2]. Para aumentar el rendimiento de un blockchain, una solución trivial es aumentar el tamaño de su bloque. En el contexto de Ethereum, esto significa aumentar la cantidad máxima de gas que puede contener un bloque. Como cada nodo completo debe validar cada transacción de cada bloque, a medida que aumenta el rendimiento, también aumentan los requisitos de hardware, lo que lleva a una mayor centralización de la red. Algunos blockchains, como Bitcoin y Ethereum, optimizan su diseño para maximizar su descentralización arquitectónica, mientras que otros, como Binance Smart Chain y Solana, están diseñados para ser lo más rápidos y económicos posible. Las redes descentralizadas limitan artificialmente el rendimiento del blockchain para reducir los requisitos de hardware para participar en la red. A lo largo de los años, se han realizado intentos para encontrar una solución al Trilema, como los canales estatales [3] y Plasma [4, 5]. Estas soluciones tienen la característica de mover alguna actividad fuera de la cadena, vincular la actividad dentro de la cadena con la actividad fuera de la cadena usando smart contracts y verificar DLT 2023: 5to Taller de tecnología de contabilidad distribuida, 25 y 26 de mayo de 2023, Bolonia, Italia $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Copyright de este artículo por parte de sus autores. Uso permitido bajo la Licencia Creative Commons Attribution 4.0 International (CC BY 4.0). Actas del taller CEUR http://ceur-ws.org ISSN 1613-0073 Actas del taller CEUR (CEUR-WS.org) dentro de la cadena, qué está sucediendo fuera de la cadena. Sin embargo, tanto los canales Plasma como los estatales tienen un soporte limitado para los smart contracts generales. Los rollups son blockchains (llamados Layer 2 o L2) que publican sus bloques en otro blockchain (Layer 1 o L1) y por lo tanto heredan sus propiedades de consenso, disponibilidad de datos y seguridad. A diferencia de otras soluciones, admiten el cálculo arbitrario. Los rollups tienen tres componentes principales: • Secuenciadores: nodos que reciben transacciones Rollup de los usuarios y las combinan en un bloque que se envía a Layer 1. El bloque consta de al menos la raíz del estado (por ejemplo, una raíz de Merkle) y los datos necesarios para reconstruir y validar el estado. El Layer 1 define el...

Introducción

1. Introducción La tecnología Blockchain ha ganado mucha atención debido a su potencial para revolucionar diversas industrias. Sin embargo, la escalabilidad sigue siendo un desafío importante, ya que la mayoría de los blockchains enfrentan un equilibrio entre escalabilidad, descentralización y seguridad, comúnmente conocido como el Trilema de escalabilidad [1, 2]. Para aumentar el rendimiento de un blockchain, una solución trivial es para aumentar el tamaño de su bloque. En el contexto de Ethereum, esto significa aumentar el máximo cantidad de gas que puede contener un bloque. Como cada nodo completo debe validar cada transacción de cada bloque, a medida que aumenta el rendimiento, los requisitos de hardware también aumentan, lo que lleva a una mayor centralización de la red. Algunos blockchains, como Bitcoin y Ethereum, optimizan su diseño para maximizar su descentralización arquitectónica, mientras que otros, como Binance Smart Chain y Solana, están diseñados para ser lo más rápidos y económicos posible. Redes descentralizadas limitar artificialmente el rendimiento del blockchain para reducir los requisitos de hardware a participar en la red. A lo largo de los años, se ha intentado encontrar una solución al Trilema, como por ejemplo la canales [3] y Plasma [4, 5]. Estas soluciones tienen la característica de mover alguna actividad fuera de la cadena, vinculando la actividad dentro de la cadena con la actividad fuera de la cadena usando smart contracts y verificando DLT 2023: 5.º taller sobre tecnología de contabilidad distribuida, 25 y 26 de mayo de 2023, Bolonia, Italia $ [email protected] (L.Donno) https://lucadonnoh.github.io/ (L.Donno) 0000-0001-9221-3529 (L.Donno) © 2023 Copyright de este artículo por parte de sus autores. Uso permitido bajo la Licencia Creative Commons Attribution 4.0 International (CC BY 4.0). EUR Taller Procedimientos http://ceur-ws.org ISSN 1613-0073 Actas del taller CEUR (CEUR-WS.org)dentro de la cadena lo que está sucediendo fuera de la cadena. Sin embargo, tanto los canales de plasma como los estatales están limitados en su apoyo al general smart contracts. Los rollups son blockchains (llamados Layer 2 o L2) que publican sus bloques en otro blockchain (Layer 1 o L1) y por lo tanto hereda sus propiedades de consenso, disponibilidad de datos y seguridad. Ellos, a diferencia de otras soluciones, admite cálculo arbitrario. Los rollups tienen tres componentes principales: • Secuenciadores: nodos que reciben transacciones acumuladas de los usuarios y las combinan en un bloque que se envía a Layer 1. El bloque consta de al menos la raíz del estado (por ejemplo, un Merkle root) y los datos necesarios para reconstruir y validar el estado. El Layer 1 define el canónico blockchain de la L2 estableciendo el ordenamiento de los datos publicados. • Nodos Rollup completos: nodos que obtienen, procesan y validan bloques Rollup de Layer. 1 verificando que la raíz sea correcta. Si un bloque contiene transacciones no válidas, entonces es descartados, lo que evita que los secuenciadores creen bloques válidos que incluyan bloques no válidos. transacciones. • Nodos ligeros de resumen: nodos que obtienen bloques de resumen de Layer 1 pero no calculan el nuevo Estado ellos mismos. Verifican que el nuevo estado raíz sea válido mediante técnicas como pruebas de error o validez. Los rollups logran escalabilidad al disminuir el costo amortizado de las transacciones a medida que aumenta el número. de usuarios aumenta. Esto se debe a que el costo de garantizar la validez de blockchain crece de manera sublineal. con respecto al costo de verificar las transacciones individualmente. Los rollups difieren según el mecanismo por el cual aseguran la validez de la ejecución de transacciones en los nodos ligeros: en Los Rollups Optimistas están garantizados por un modelo económico y por pruebas de fallos, mientras que en Validez Los rollups se aseguran criptográficamente mediante pruebas de validez. Los nodos ligeros se pueden implementar como smart contracts en Layer 1. Aceptan la raíz de la nuevo estado y verificar la validez o las pruebas de fallas: estos Rollup se denominan por lo tanto Smart Contract Acumulados. Si los nodos ligeros son independientes, se denominan Sovereign Rollups [6]. La ventaja de Usar un Smart Contract Rollup es poder construir un puente de confianza minimizada entre los dos. blockchains: dado que se prueba la validez del estado L2 para L1, se crea un sistema de transacciones desde Se pueden implementar L2 a L1, permitiendo retiros. La desventaja es que el costo del Las transacciones dependen del costo de verificar el estado en L1: si la capa base está saturada por otras actividades, el costo de las transacciones en el Rollup también aumenta. Las capas de datos y consenso son las que determinan la seguridad del sistema como Definen el orden de las transacciones, previenen ataques y ponen a disposición datos para probar el estado. validez. Contribución en papel En este artículo, estudiamos Optimistic y Validity Rollups, dos innovadores soluciones al Trilema de escalabilidad, con un enfoque en implementaciones notables, como Optimism Bedrock y StarkNet. Nuestras contribuciones incluyen una comparación exhaustiva de estos soluciones, un análisis de los tiempos de retiro y una discusión de un posible ataque a Optimism Base rocosa. Además, calculamos sus relaciones de compresión de gas, proporcionamos optimizaciones específicas de la aplicación y presentamos las ventajas y desventajas de alejarnos del Ethereum. Máquina virtual (EVM).

Estructura del papel El documento está organizado de la siguiente manera. En la sección 2 se muestran los resúmenes optimistas. introducido analizando Optimism Bedrock. En la sección 3, los acumuladores de validez se introducen por analizando StarkNet. En la sección 4 comparamos las dos soluciones. Finalmente, en la sección 5 dibujamos algunas conclusiones.

Acumulaciones optimistas

1. Resúmenes optimistas La idea de aceptar con optimismo la salida de bloques sin verificar su ejecución es ya presente en el documento técnico Bitcoin [7], que analiza los nodos de luz. Estos nodos sólo siguen la cadena de encabezado verificando la regla de consenso, haciéndolos vulnerables para aceptar bloques que contengan transacciones no válidas en caso de un ataque del 51%. Nakamoto propone solucionar esto problema mediante el uso de un sistema de "alerta" para advertir a los nodos ligeros que un bloque contiene transacciones no válidas. Este mecanismo fue implementado por primera vez por Al-Bassam, Sonnino y Buterin [8] en el que una falla Se utiliza un sistema de prueba basado en códigos de corrección de errores [9]. Para permitir la creación de pruebas de fallas, es necesario que los datos de todos los bloques, incluidos los bloques no válidos, estén disponibles para la red: este es el problema de disponibilidad de datos, que se resuelve utilizando un análisis de datos probabilístico mecanismo de muestreo. El primer diseño Optimistic Rollup fue presentado por John Adler y Mikerah Quintyne-Collins en 2019 [10], en el que se publican bloques en otro blockchain que define su consenso sobre el pedido. 2.1. Optimism Base de roca Bedrock [11] es la última versión de Optimism, un paquete acumulativo de contratos inteligentes. La versión anterior, La Máquina Virtual Optimista (OVM) requería un compilador ad hoc para compilar Solidity en su propio código de bytes: por el contrario, Bedrock es totalmente equivalente al EVM en que el motor de ejecución sigue la especificación de papel amarillo Ethereum [12]. 2.1.1. Depósitos Los usuarios pueden depositar transacciones a través de un contrato en Ethereum, el Portal Optimism, llamando a la función depositTransaction. Cuando se ejecuta una transacción, un Se emite el evento TransactionDeposited, que cada nodo del Rollup escucha para procesar depósitos. Una transacción depositada es una transacción L2 que se deriva de L1. Si la persona que llama del función es un contrato, la dirección se transforma añadiéndole un valor constante: esto evita Ataques en los que un contrato en L1 tiene la misma dirección que un contrato en L2 pero un código diferente. La inclusión en L2 de una transacción depositada está garantizada por la especificación dentro de una secuencia ventana. Las transacciones depositadas son un nuevo tipo de transacción compatible con EIP-2718 [13] con prefijo 0x7E, donde los campos codificados en rlp son: • bytes32 sourceHash: hash que identifica de forma única el origen de la transacción. • dirección de: la dirección del remitente. • dirección a: la dirección del destinatario, o la dirección cero si la transacción depositada es una creación de contrato.• uint256 mint: el valor que se creará en L2. • valor uint256: el valor que se enviará al destinatario. • bytes de datos: los datos de entrada. • bytes gasLimit: el límite de gas de la transacción. El sourceHash se calcula como keccak256 hash del bloque L1 hash y el registro L1 índice, que identifica de forma única un evento en un bloque. Dado que las transacciones depositadas se inician en L1 pero se ejecutan en L2, el sistema necesita un mecanismo para pagar en L1 el gas gastado en L2. Una solución es enviar ETH a través del Portal, pero esto implica que todas las personas que llaman (incluso las que llaman indirectamente) deben marcarse como pagaderas, y esto es Esto no es posible para muchos proyectos existentes. La alternativa es quemar el gas correspondiente en L1. El gas 𝑔 asignado a la transacción depositada se denomina gas garantizado. El precio del gas L2 en L1 no se sincroniza automáticamente, sino que se estima mediante un mecanismo similar al EIP-1559 [14]. La cantidad máxima de gas garantizada por bloque Ethereum es de 8 millones, con un objetivo de 2 millones. La cantidad 𝑐de ETH necesaria para pagar el gas en L2 es 𝑐= 𝑔𝑏L2 donde 𝑏L2 es el tarifa base en L2. El contrato en L1 quema una cantidad de gas igual a 𝑐/𝑏L2. El gas gastado para llamar. depositTransaction se reembolsa en L2: si esta cantidad es mayor que el gas garantizado, no se quema ningún gas. La primera transacción de un bloque rollup es una transacción depositada con atributos L1, utilizada para registrar en una L2, implemente previamente los atributos de los bloques Ethereum. Los atributos que otorga el predespliegue acceso son el número de bloque, la marca de tiempo, la tarifa base, el bloque hash y la secuencia número, que es el número de bloque de L2 en relación con el bloque L1 asociado (también llamado época); este número se restablece cuando comienza una nueva época. 2.1.2. Secuenciación Los nodos acumulativos derivan la cadena Optimism completamente de Ethereum. Esta cadena se extiende cada vez que se publican nuevas transacciones en L1, y sus bloques se reorganizan cada vez Se reorganizan Ethereum bloques. El Rollup blockchain se divide en épocas. Por cada 𝑛 número de bloque de Ethereum, hay una 𝑛época correspondiente. Cada época contiene al menos una bloque, y cada bloque en una época contiene una transacción depositada con atributos L1. el primer bloque en una época contiene todas las transacciones depositadas a través del Portal. Los bloques Layer 2 también pueden contenía transacciones secuenciadas, es decir, transacciones enviadas directamente al secuenciador. El secuenciador acepta transacciones de usuarios y construye bloques. Para cada bloque, construye un lote que se publicará el Ethereum. Se pueden publicar varios lotes de forma comprimida, tomando el nombre de canal. Un canal se puede dividir en varios fotogramas, en caso de que sea demasiado grande para una sola transacción. Un canal se define como la compresión con ZLIB [15] de archivos codificados en rlp. lotes. Los campos de un lote son el número de época, la época hash, el padre hash, el marca de tiempo y la lista de transacciones. Una ventana de secuenciación, identificada por una época, contiene un número fijo 𝑤 de L1 consecutivos bloques que un paso de derivación toma como entrada para construir un número variable de bloques L2. Para época 𝑛, la ventana de secuenciación 𝑛incluye los bloques [𝑛, 𝑛+𝑤). Esto implica que el pedido de transacciones y bloques L2 dentro de una ventana de secuenciación no se fija hasta que finaliza la ventana. Una transacción rollup se considera segura si el lote que la contiene ha sido confirmado en L1. Marcosse leen de los bloques L1 para reconstruir lotes. La implementación actual no permite La descompresión de un canal comienza hasta que se hayan recibido todas las tramas correspondientes. Inválido los lotes se ignoran. Las transacciones en bloque individuales se obtienen de los lotes, que se utilizado por el motor de ejecución para aplicar transiciones de estado y obtener el estado del Rollup. 2.1.3. Retiros Para procesar retiros, se implementa un sistema de mensajería L2 a L1. Ethereum necesita conocer el estado de L2 para poder aceptar retiros, y esto se hace publicando en el Oracle de salida L2 smart contract en L1, la raíz del estado de cada bloque L2. Estas raíces se aceptan con optimismo como válidos (o finalizados) si no se realiza ninguna prueba de fallo durante el período de disputa. Sólo las direcciones designadas como Proponentes pueden publicar raíces de salida. la validez de raíces productivas se incentiva haciendo que los Proponentes depositen una participación que se reduce drásticamente si son Se muestra que propuso una raíz no válida. Las transacciones se inician llamando a la función. iniciar el retiro en una implementación previa en L2 y luego finalizar en L1 llamando a la función finalizeWithdrawalTransaction en el Portal Optimism mencionado anteriormente. La raíz de salida correspondiente al bloque L2 se obtiene del Oráculo de salida L2; es verificado que está finalizado, es decir, que ha pasado el período de disputa; se verifica que la Salida La prueba raíz coincide con la prueba de Oracle; se verifica que el hash del retiro está incluido en él utilizando una Prueba de Retiro; que el retiro aún no se ha concretado; y luego el Se ejecuta la llamada a la dirección de destino, con el límite de gas, la cantidad de Ether y los datos especificados. 2.1.4. Cannon: el sistema a prueba de fallos Si un Rollup Full Node, al ejecutar localmente lotes y transacciones depositadas, descubre que el estado Layer 2 no coincide con la raíz del estado publicada en la cadena por un Proponente, puede ejecutarse una prueba de falla en L1 para demostrar que el resultado de la transición del bloque es incorrecto. debido a la gastos generales, procesar un bloque Rollup completo en L1 es demasiado costoso. La solución implementada por Bedrock es ejecutar en cadena solo la primera instrucción de desacuerdo de minigeth, compilándolo en una arquitectura MIPS que se ejecuta en un intérprete en cadena y se publica en L1. minigeth es una versión simplificada de geth 1 en la que el consenso, RPC y la base de datos han sido eliminados. Para encontrar la primera instrucción en desacuerdo, se realiza una búsqueda binaria interactiva entre el que inició la prueba de fallas y el que publicó la raíz de salida. cuando la prueba comienza, ambas partes publican la raíz del estado de memoria MIPS a mitad de la ejecución de el bloque en el contrato Challenge: si el hash coincide significa que ambas partes están de acuerdo en el primera mitad de la ejecución publicando así la raíz de la mitad de la segunda mitad, en caso contrario la mitad del primer semestre se publica y así sucesivamente. Al hacerlo se logra la primera instrucción de desacuerdo. en un número logarítmico de pasos en comparación con la ejecución original. Si uno de los dos se detiene interactuando, al final del período de disputa el otro participante gana automáticamente. Para procesar la instrucción, el intérprete MIPS necesita acceso a su memoria: dado que la raíz es disponibles, se pueden publicar las celdas de memoria necesarias demostrando su inclusión. Para acceder el estado del EVM, se hace uso del Oráculo Preimagen: dado el hash de un bloque devuelve 1https://geth.ethereum.org/docs

el encabezado del bloque, desde el cual se puede obtener el hash del bloque anterior y regresar al cadena, u obtenga el hash del estado y los registros de los cuales se puede obtener la imagen previa. El oracle Es implementado por minigeth y reemplaza la base de datos. Se realizan consultas a otros nodos para obtener las preimágenes.

Resúmenes de validez

1. Resúmenes de validez El objetivo de un Validity Rollup es demostrar criptográficamente la validez de la transición de estado. dada la secuencia de transacciones con una prueba breve que se puede verificar en comparación sublineal al momento de los cálculos originales. Este tipo de certificados se denominan pruebas de integridad computacional y se implementan prácticamente con SNARK (Succint Non-interactive ARgument of Knowledge), que utilizan aritmética. circuitos como su modelo computacional. Las diferentes implementaciones de SNARK difieren en el tiempo de prueba, tiempo de verificación, la necesidad de una configuración confiable y resistencia cuántica [16, 17]. STARK (Escalable Argumento transparente de conocimiento) [18] son un tipo de SNARK que no requiere una persona confiable configuración y son resistentes a los cuánticos, al tiempo que renuncian a cierta eficiencia en la prueba y verificación en comparación con otras soluciones. 3.1. StarkNet StarkNet es un paquete acumulativo de validez de contrato inteligente desarrollado por StarkWare que utiliza STARK sistema de prueba para validar su estado a Ethereum. Para facilitar la construcción de pruebas de validez, se Se utiliza una máquina virtual diferente a la EVM, cuyo lenguaje de alto nivel es Cairo. 3.1.1. Depósitos Los usuarios pueden depositar transacciones a través de un contrato en Ethereum llamando a sendMessageToL2 función. El mensaje se registra calculando su hash y aumentando un contador. Secuenciadores escuche el evento LogMessageToL2 y codifique la información en una transacción StarkNet que llama a una función de un contrato que tiene el decorador l1_handler. Al final de la ejecución, cuando se produce la prueba de transición de estado, se le adjunta el consumo del mensaje y se elimina disminuyendo su contador. La especificación StarkNet no requiere la inclusión de transacciones depositadas, por lo que un gas Se necesita mercado para incentivar a los secuenciadores a publicarlos en L2. En la versión actual, porque el secuenciador está centralizado y administrado por StarkWare, el costo de las transacciones depositadas sólo está determinado por el coste de ejecución del depósito. Este costo se paga enviando ETH a enviar mensaje a L2. Estos Éteres permanecen bloqueados en L1 y se transfieren al Secuenciador en L1, cuando la transacción depositada se incluye en una transición de estado. La cantidad de ETH enviada, si la transacción depositada está incluida, se gasta en su totalidad, independientemente de la cantidad de gas consumido en L2. StarkNet no tiene un sistema que haga que los atributos del bloque L1 estén disponibles automáticamente. Alternativamente, Fossil es un protocolo desarrollado por Oiler Network 2 que permite, dado un hash de un bloque, cualquier información se obtendrá de Ethereum mediante la publicación de preimágenes. 2https://www.oiler.network/3.1.2. Secuenciación El estado actual de StarkNet se puede derivar completamente de Ethereum. Cualquier diferencia de estado entre transiciones se publica en L1 como datos de llamada. Se publican las diferencias para cada contrato. y se guardan como uint256[] con la siguiente codificación: • Número de campos relativos a implementaciones de contratos. • Para cada contrato publicado: – La dirección del contrato publicado. – El hash del contrato publicado. – El número de argumentos del constructor del contrato. – La lista de argumentos del constructor. • Número de contrato cuyo almacenamiento ha sido modificado. • Por cada contrato que haya sido modificado: – La dirección del contrato modificado. – El número de actualizaciones de almacenamiento. – Los pares clave-valor de las direcciones de almacenamiento con los nuevos valores. Las diferencias de estado se publican en orden, por lo que basta con leerlas secuencialmente para reconstruir el estado. 3.1.3. Retiros Para enviar un mensaje de L2 a L1, se utiliza la llamada al sistema send_message_to_L1. El mensaje es publicado en L1 aumentando su contador hash junto con la prueba y finalizado llamando al función consumeMessageFromL2 en StarkGate smart contract en L1, que disminuye el mostrador. Cualquiera puede finalizar cualquier retiro. 3.1.4. Pruebas de validez La Máquina Virtual Cairo [19] está diseñada para facilitar la construcción de pruebas STARK. El lenguaje Cairo permite describir el cómputo con una programación de alto nivel. lenguaje, y no directamente como un circuito. Esto se logra mediante un sistema de ecuaciones polinómicas. 3 que representa un cálculo único: el ciclo FDE de una arquitectura von Neumann. el numero de restricciones es, por tanto, fija e independiente del tipo de cálculo, permitiendo sólo una Programa verificador para cada programa cuyo cálculo deba ser probado. StarkNet agrega múltiples transacciones en una única prueba STARK utilizando un probador compartido llamado AGUDO. Las pruebas se envían a un smart contract el Ethereum, que verifica su validez. y actualiza la raíz de Merkle correspondiente al nuevo estado. El coste sublineal de verificar una La prueba de validez permite que su costo se amortice en múltiples transacciones. 3llamada Representación Algebraica Intermedia (AIR)

Comparación

1. Comparación 4.1. tiempo de retiro El aspecto más importante que distingue los rollups optimistas de los rollups de validez es la tiempo que transcurre entre la inicialización de un retiro y su finalización. En ambos casos, los retiros se inicializan en L2 y finalizan en L1. El StarkNet, la finalización es posible como tan pronto como se acepte la prueba de validez de la nueva raíz estatal el Ethereum: en teoría, es Es posible retirar fondos en el primer bloque de L1 después de la inicialización. En la práctica, el La frecuencia de envío de pruebas de validez el Ethereum es una compensación entre la velocidad del bloque. finalización y agregación de pruebas. Actualmente StarkNet proporciona pruebas de validez para su verificación. cada 10 horas 4, pero se pretende disminuir a medida que aumenta la actividad de transacciones. En Optimism Bedrock es posible finalizar un retiro solo al final de la disputa. período (actualmente 7 días), después del cual una raíz se considera automáticamente válida. la longitud de este período está determinado principalmente por el hecho de que las pruebas de fallas pueden ser censuradas el Ethereum hasta su fin. La probabilidad de éxito de este tipo de ataque disminuye exponencialmente a medida que aumenta el tiempo: E[valor restado] = 𝑉𝑝𝑛 donde 𝑛 es el número de bloques en un intervalo, 𝑉 es la cantidad de fondos que se pueden restar publicando una raíz no válida, y 𝑝 es la probabilidad de realizar con éxito una censura ataque en un solo bloque. Supongamos que esta probabilidad es del 99%, que el valor bloqueado en el Rollup es un millón de Ether, y que los bloques en un intervalo son 1800 (6 horas de bloques con un 12 Intervalo de segundos): el valor esperado es aproximadamente 0,01391 éter. El sistema se hace seguro mediante pedir a los proponentes que apuesten una cantidad de Ether mucho mayor que el valor esperado. Winzer et al. mostró cómo llevar a cabo un ataque de censura usando un simple smart contract eso asegura que ciertas áreas de memoria en el estado no cambien [20]. Modelando el ataque Como juego de Markov, el artículo muestra que la censura es la estrategia dominante para un sistema racional. productor del bloque si recibe una compensación mayor que la que incluye la transacción que cambia la memoria. El valor de 𝑝 discutido anteriormente se puede ver como el porcentaje del bloque racional productores de la red, donde “racional” no tiene en cuenta la posible penalización externalidades, como una menor confianza en el blockchain que disminuye su valor de criptomoneda. El siguiente código presenta un smart contract que puede usarse para realizar un ataque de censura. en Bedrock. El ataque explota los incentivos de los productores de bloques ofreciéndoles un soborno. censurar las transacciones que modificarían partes específicas del estado. El principal del contrato La función ClaimBribe permite a los productores de bloques reclamar el soborno si censuran con éxito. la transacción objetivo comprobando que la raíz de salida no válida no se haya tocado. función reclamoSoborno(bytes memoria almacenamientoPrueba) externo { require(!claimed[block.number], "soborno ya reclamado"); Memoria OutputProposal actual = StorageOracle.getStorage(L2_ORACLE, block.number, SLOT, prueba de almacenamiento); require(invalidOutputRoot == current.outputRoot, "ataque fallido"); reclamado[bloque.número] = verdadero; (bool enviado,) = block.coinbase.call{valor: sobornoAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(enviado, "no se pudo enviar ether"); } Listado 1: Ejemplo de un contrato que incentiva un ataque de censura a Bedrock. La duración del período de disputa también debe tener en cuenta el hecho de que la prueba de la culpa es una prueba interactiva y por lo tanto se debe proporcionar tiempo suficiente para que los participantes interactúen y que cualquier interacción podría ser censurada. Si el último movimiento ocurre en un momento muy cercano al Al final del período de disputa, el costo de la censura es significativamente menor. Aunque la censura es la estrategia dominante, la probabilidad de éxito es menor porque los nodos de censura son vulnerables a Ataques de denegación de servicio: un atacante puede generar transacciones muy complejas que terminan con el publicación de una prueba de culpa sin coste alguno, ya que no se pagarían tasas. En casos extremos, un largo período de disputa permite la coordinación en caso de una solución exitosa. Ataque de censura para organizar una bifurcación y excluir a los productores de bloques atacantes. otro posible ataque consiste en publicar más propuestas de raíz estatal de las que los litigantes pueden verificar, lo cual se puede evitar utilizando un límite de frecuencia. 4.1.1. Retiros rápidos y optimistas Dado que la validez de un Optimistic Rollup puede ser verificada en cualquier momento por cualquier Nodo Completo, un El oracle de confianza se puede utilizar para saber en L1 si el retiro se puede finalizar de forma segura. esto El mecanismo fue propuesto por primera vez por Maker [21]: un oracle verifica el retiro, publica el resultado en L1 sobre el cual se asigna al usuario un préstamo que devenga intereses, que se cerrado al final de 7 días, es decir, cuando realmente se puede finalizar el retiro. esta solución introduce una suposición de confianza, pero en el caso de Maker se minimiza ya que el operador oracle es gestionado por la misma organización que asume el riesgo al conceder el préstamo. 4.2. Costos de transacción El costo de las transacciones L2 está determinado principalmente por la interacción con la L1. En ambas soluciones El costo computacional de las transacciones es muy económico ya que se ejecuta completamente fuera de la cadena. Optimism publica datos de llamada de transacciones L2 como datos de llamada y rara vez (o nunca) ejecuta la falla pruebas, por lo tanto calldata es el recurso más caro. El 12 de enero de 2022 una red Bedrock se lanzó en la red de prueba Goerli de Ethereum. Se puede calcular la tasa de compresión del gas. rastreando la cantidad de gas utilizada en Bedrock en un período determinado y comparándola con la cantidad de gas gastado en L1 para los bloques correspondientes. Usando este método una compresión de gas Se encuentra una tasa de ∼20: 1, pero esta cifra puede diferir con la actividad real en la red principal. StarkNet publica el Ethereum cada cambio en el estado L2 como datos de llamada, por lo tanto, el almacenamiento es el recurso más caro. Dado que la red no utiliza el EVM, el costo de transacción la compresión no se puede estimar trivialmente. Asumiendo el costo de ejecución y calldata para ser insignificante, es posible calcular la relación de compresión de las escrituras de almacenamiento en comparación con L1. Suponiendo que no se implemente ningún contrato y que 10 celdas a las que no se accedió anteriormente en StarkNet están modificado, se encuentra una tasa de compresión del costo de escritura de almacenamiento de ~24:1. Si se sobrescribe una celda 𝑛veces entre publicaciones de datos, el costo de cada escritura será 1/𝑛en comparación con el costo de un solo escrito, ya que sólo se publica el último. El costo se puede minimizar aún más mediantecomprimir valores de uso frecuente. El costo de la verificación de la prueba de validez se divide entre las transacciones a las que se refiere: por ejemplo, StarkNet el bloque 4779 contiene 200 transacciones y su La prueba de validez consume 267830 unidades de gas, o 1339,15 gas por cada transacción. 4.2.1. Optimización de datos de llamada: contrato de caché A continuación se presenta un smart contract que implementa un caché de direcciones para uso frecuente direcciones aprovechando el hecho de que el almacenamiento y la ejecución son mucho menos costosos recursos, junto con un contrato de Friends que demuestra su uso. Este último realiza un seguimiento de la "amigos" de una dirección que se puede registrar llamando a la función addFriend. si una dirección ya se ha utilizado al menos una vez, se puede agregar llamando a addFriendWithCache función: los índices de caché son números enteros de 4 bytes mientras que las direcciones están representadas por 20 bytes, por lo que hay un ahorro de 5:1 en el argumento de la función. La misma lógica se puede utilizar para otros datos. tipos como números enteros o, más generalmente, bytes. contrato AddressCache { mapeo (dirección => uint32) dirección pública2clave; dirección[] clave pública2dirección; función cacheWrite(dirección _dirección) retornos internos (uint32) { require(key2address.length < type(uint32).max, "AddressCache: el caché está lleno"); require(address2key[_address] == 0, "AddressCache: dirección ya almacenada en caché"); // las claves deben comenzar desde 1 porque 0 significa "no encontrado" clave uint32 = uint32(clave2dirección.longitud + 1); dirección2clave[_dirección] = clave; key2address.push(_address); tecla de retorno; } función cacheRead(uint32 _key) vista pública devuelve (dirección) { require(_key <= key2address.length && _key > 0, "AddressCache: clave no encontrada"); devolver clave2dirección[_clave - 1]; } } Listado 2: Contrato de caché de direcciones. contrato Amigos es AddressCache { mapeo (dirección => dirección []) amigos públicos; función agregarAmigo(dirección _amigo) pública { amigos[msg.sender].push(_friend); cacheWrite(_amigo); } función addFriendWithCache (uint32 _friendKey) público { amigos[msg.sender].push(cacheRead(_friendKey)); } función getFriends() devuelve la vista pública (dirección[] memoria) { devolver amigos[msg.sender];} } Listado 3: Ejemplo de un contrato que hereda la caché de direcciones. El contrato admite en caché alrededor de 4 mil millones (232) direcciones y agregar un byte da alrededor de 1 billón (240). 4.2.2. Optimización del almacenamiento: los filtros de Bloom En StarkNet existen varias técnicas para minimizar el uso de almacenamiento. Si no es necesario garantizar la disponibilidad de los datos originales, entonces es suficiente guardar en cadena su hash: esto es el mecanismo utilizado para guardar datos para un ERC-721 (NFT) [22], es decir, un enlace IPFS que resuelve el hash de los datos si están disponibles. Para datos que se almacenan varias veces, es posible utilizar una búsqueda tabla similar al sistema de almacenamiento en caché introducido para Optimism, que requiere que todos los valores se guarden en menos una vez. Para algunas aplicaciones, se puede evitar guardar todos los valores utilizando un filtro Bloom. [23, 24, 25], es decir, una estructura de datos probabilística que permite saber con certeza si un elemento no pertenece a un conjunto pero admite una probabilidad pequeña pero no despreciable de ser falso positivos. Un filtro Bloom se inicializa como una matriz de 𝑚bits en cero. Para agregar un elemento, funciones 𝑘hash con una distribución aleatoria uniforme, cada uno de los cuales se asigna a un bit de la matriz que se establece a 1. Para comprobar si un elemento pertenece al conjunto ejecutamos las funciones 𝑘hash y verificamos que los 𝑘bits están establecidos en 1. En un filtro de Bloom simple no hay forma de distinguir si un elemento realmente pertenece al conjunto o es un falso positivo, una probabilidad que crece a medida que el número de entradas aumenta. Después de insertar 𝑛elementos: P[falso positivo] = (︃ 1- [︂ 1-1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 suponiendo independencia de la probabilidad de cada conjunto de bits. Si 𝑛elementos (¡de tamaño arbitrario!) son se espera que se incluya y la probabilidad de que se tolere un falso positivo es 𝑝, el tamaño de la matriz se puede calcular como: 𝑚= −𝑛ln 𝑝 (en 2)2 Mientras que el número óptimo de funciones hash es: 𝑘= 𝑚 𝑛ln 2 Si suponemos que insertamos 1000 elementos con una tolerancia del 1%, el tamaño de la matriz es de 9585 bits. con 𝑘= 6, mientras que para una tolerancia del 0,1% se convierte en 14377 bits con 𝑘= 9. Si un millón de elementos se espera que se inserten, el tamaño de la matriz es de aproximadamente 1170 kB para el 1% y 1775 kB para 0.1%, con los mismos valores de 𝑘, ya que depende únicamente de 𝑝[26]. En un juego en el que los jugadores no deben ser asignados a un oponente al que ya hayan desafiado, En lugar de guardar en el almacenamiento para cada jugador la lista de oponentes anteriores, se puede usar un Bloom. filtrar. El riesgo de no desafiar a algunos jugadores suele ser aceptable y el filtro se puede restablecer periódicamente.4.3. Ethereum compatibilidad La principal ventaja de ser compatible con EVM y Ethereum es la reutilización de todos los disponibles herramientas. Ethereum smart contracts pueden publicarse en Optimism sin ninguna modificación ni nuevas auditorías. Las billeteras siguen siendo compatibles, herramientas de desarrollo y análisis estático, análisis general herramientas, herramientas de indexación y oracles. Ethereum y Solidity tienen una larga historia de estudios bien estudiados. vulnerabilidades, como ataques de reentrada, desbordamientos y desbordamientos, préstamos flash y oracle manipulaciones. Debido a esto, Optimism pudo capturar una gran cantidad de valor en poco tiempo. tiempo. Elegir adoptar una máquina virtual diferente implica tener que reconstruir todo un ecosistema, con la ventaja de una mayor libertad de implementación. StarkNet implementa la cuenta de forma nativa abstracción, que es un mecanismo por el cual cada cuenta es un smart contract que puede implementar lógica arbitraria siempre que cumpla con una interfaz (de ahí el término abstracción): esto permite el uso de diferentes esquemas de firma digital, la capacidad de cambiar la clave privada utilizando el misma dirección o utilice una firma múltiple. La comunidad Ethereum propuso la introducción de este mecanismo con EIP-2938 en 2020, pero la propuesta ha permanecido obsoleta durante más de un año como A otras actualizaciones se les ha dado más prioridad [27]. Otro beneficio importante obtenido de la compatibilidad es la reutilización de clientes existentes: Optimism utiliza una versión de geth para su propio nodo con solo ~800 líneas de diferencia, que ha sido desarrollado, probado y mantenido desde 2014. Tener un cliente sólido es crucial ya que define lo que se acepta como válido o no en la red. Un error en la implementación de la prueba de fallos. El sistema podría hacer que una prueba incorrecta sea aceptada como correcta o una prueba correcta para una prueba no válida. bloque sea aceptado como incorrecto, comprometiendo el sistema. La probabilidad de este tipo de El ataque se puede limitar con una diversidad de clientes más amplia: Optimism puede reutilizar además de geth el otros Ethereum clientes ya mantenidos, y se está desarrollando otro cliente basado en Erigon. ya en marcha. En 2016, un problema en la gestión de la memoria de geth fue explotado durante un ataque DoS y la primera línea de defensa fue recomendar el uso de Parity, el segundo más cliente usado en ese momento 5. StarkNet enfrenta el mismo problema con las pruebas de validez, pero los clientes tienen que escribirse desde cero y el sistema de prueba es mucho más complejo, y en consecuencia También es mucho más complejo garantizar la corrección.

Conclusión

1. Conclusión Los rollups son la solución más prometedora disponible en la actualidad para resolver el problema de escalabilidad en blockchains descentralizados, allanando el camino para la era de los blockchains modulares en lugar de monolítico blockchains. Se muestra principalmente la elección de desarrollar un resumen optimista o un resumen de validez. como un equilibrio entre complejidad y agilidad. StarkNet tiene numerosas ventajas como la rapidez retiros, incapacidad estructural para tener transiciones de estado inválidas, menor costo de transacción en el a expensas de un período de desarrollo más largo e incompatibilidad con EVM, mientras que Optimism tiene aprovechó la economía de red para ganar rápidamente una porción importante del mercado. Optimism Bedrock, sin embargo, posee un diseño modular que le permite convertirse en Validity 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Resumen en el futuro: Cannon actualmente usa minigeth compilado en MIPS para su prueba de fallas sistema, pero se puede utilizar la misma arquitectura para obtener un circuito y producir pruebas de validez. Compilar una máquina compleja como la EVM para una microarquitectura resulta en una solución más simple. circuito que no necesita ser modificado y reverificado en caso de actualizaciones. RISC Cero es un microarquitectura verificable con pruebas STARK ya en desarrollo basadas en RISC-V que se puede utilizar para este propósito como alternativa a MIPS [28]. Un aspecto que no debe subestimarse es la complejidad para entender cómo funciona el La tecnología funciona. Una fortaleza de los blockchain tradicionales es poder verificar el estado de el blockchain sin confiar en ninguna entidad de terceros. Sin embargo, en el caso de StarkNet, es necesario confiar en la implementación cuando no es posible verificar los distintos componentes basado en criptografía y matemáticas avanzadas. Inicialmente esto puede crear fricción para el adopción de la tecnología, pero a medida que las herramientas y el uso de pruebas de integridad avanzan aún más fuera del campo blockchain, es de esperar que este problema se resuelva.