Libros blancos Artículos Figuras Glosario Gráfico Buscar

Optimism Technische Dokumentation

Por Optimism Collective · 2021

Modo único community.optimism.io

Optimism no cuenta con un whitepaper tradicional. Como rollup optimista de Capa 2 (Layer 2) de Ethereum, su diseño y especificaciones están documentados a través de documentación técnica, la especificación del OP Stack y publicaciones de investigación, en lugar de un único artículo académico formal.

🇺🇸 English (Original)
🇩🇪 Deutsch (Traducción)

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...

Zusammenfassung

Das Papier befasst sich mit dem Problem der Skalierbarkeit in dezentralen blockchains, indem es den Kompromiss zwischen Transaktionsdurchsatz und Hardwareanforderungen zum Betrieb eines Knotens analysiert. Rollups, also Technologien zur On-Chain-Verifizierung von außerhalb der Kette ausgeführten Blöcken, werden in Form von Fehler- oder Gültigkeitsnachweisen dargestellt. Wir vergleichen Optimistic Rollups und Validity Rollups im Hinblick auf Auszahlungszeit, Transaktionskosten, Optimierungstechniken und Kompatibilität mit dem Ethereum-Ökosystem. Unsere Analyse zeigt, dass Optimism Bedrock derzeit eine Gaskomprimierungsrate von etwa 20:1 aufweist, während StarkNet eine Speicherschreibkosten-Komprimierungsrate von etwa 24:1 erreicht. Wir diskutieren auch Techniken zur weiteren Optimierung dieser Raten, wie zum Beispiel die Verwendung von Cache-Verträgen und Bloom-Filtern. Letztendlich verdeutlichen unsere Schlussfolgerungen die Kompromisse zwischen Komplexität und Agilität bei der Wahl zwischen Optimistic Rollups und Validity Rollups. Schlüsselwörter Blockchain, Skalierbarkeit, Rollup 1. Einführung Die Blockchain-Technologie hat aufgrund ihres Potenzials, verschiedene Branchen zu revolutionieren, große Aufmerksamkeit erlangt. Allerdings bleibt die Skalierbarkeit eine große Herausforderung, da die meisten blockchains mit einem Kompromiss zwischen Skalierbarkeit, Dezentralisierung und Sicherheit konfrontiert sind, der allgemein als Skalierbarkeitstrilemma bezeichnet wird [1, 2]. Um den Durchsatz eines blockchain zu erhöhen, besteht eine triviale Lösung darin, seine Blockgröße zu erhöhen. Im Zusammenhang mit Ethereum bedeutet dies eine Erhöhung der maximalen Gasmenge, die ein Block aufnehmen kann. Da jeder vollständige Knoten jede Transaktion jedes Blocks validieren muss, steigen mit zunehmendem Durchsatz auch die Hardwareanforderungen, was zu einer stärkeren Zentralisierung des Netzwerks führt. Einige blockchains, wie zum Beispiel Bitcoin und Ethereum, optimieren ihr Design, um ihre architektonische Dezentralisierung zu maximieren, während andere, wie zum Beispiel die Binance Smart Chain und Solana, so konzipiert sind, dass sie so schnell und günstig wie möglich sind. Dezentrale Netzwerke begrenzen künstlich den Durchsatz des blockchain, um die Hardwareanforderungen für die Teilnahme am Netzwerk zu senken. Im Laufe der Jahre wurden Versuche unternommen, eine Lösung für das Trilemma zu finden, beispielsweise mit den staatlichen Kanälen [3] und Plasma [4, 5]. Diese Lösungen zeichnen sich dadurch aus, dass sie einige Aktivitäten außerhalb der Kette verlagern, On-Chain-Aktivitäten mit Off-Chain-Aktivitäten mithilfe von smart contracts verknüpfen und DLT 2023 verifizieren: 5. Distributed Ledger Technology Workshop, 25.–26. Mai 2023, Bologna, Italien $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Das Urheberrecht für dieses Papier liegt bei den Autoren. Die Nutzung ist unter der Creative Commons-Lizenz Namensnennung 4.0 International (CC BY 4.0) gestattet. CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) On-Chain, was außerhalb der Chain passiert. Sowohl Plasma- als auch Staatskanäle unterstützen jedoch nur begrenzt allgemeine smart contracts. Rollups sind blockchains (genannt Layer 2 oder L2), die ihre Blöcke auf einem anderen blockchain (Layer 1 oder L1) veröffentlichen und daher dessen Konsens-, Datenverfügbarkeits- und Sicherheitseigenschaften erben. Im Gegensatz zu anderen Lösungen unterstützen sie willkürliche Berechnungen. Rollups bestehen aus drei Hauptkomponenten: • Sequenzer: Knoten, die Rollup-Transaktionen von Benutzern empfangen und sie in einem Block zusammenfassen, der an Layer 1 gesendet wird. Der Block besteht mindestens aus der Statuswurzel (z. B. einer Merkle-Wurzel) und den Daten, die zur Rekonstruktion und Validierung des Status erforderlich sind. Der Layer 1 definiert die...

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.

Einführung

  1. Einführung Aufgrund ihres revolutionären Potenzials hat die Blockchain-Technologie große Aufmerksamkeit erlangt verschiedene Branchen. Allerdings bleibt die Skalierbarkeit eine große Herausforderung, vor der die meisten blockchains stehen ein Kompromiss zwischen Skalierbarkeit, Dezentralisierung und Sicherheit, der allgemein als bezeichnet wird Skalierbarkeitstrilemma [1, 2]. Um den Durchsatz eines blockchain zu erhöhen, gibt es eine triviale Lösung um seine Blockgröße zu erhöhen. Im Kontext von Ethereum bedeutet dies eine Erhöhung des Maximums Menge an Gas, die ein Block aufnehmen kann. Da jeder vollständige Knoten jede Transaktion von jedem validieren muss Block: Mit zunehmendem Durchsatz steigen auch die Hardwareanforderungen, was zu einem höheren Durchsatz führt Zentralisierung des Netzwerks. Einige blockchains, wie Bitcoin und Ethereum, optimieren ihre Design, um ihre architektonische Dezentralisierung zu maximieren, während andere, wie der Binance Smart Chain und Solana sind darauf ausgelegt, so schnell und günstig wie möglich zu sein. Dezentrale Netzwerke Beschränken Sie den Durchsatz von blockchain künstlich, um die Hardwareanforderungen zu senken am Netzwerk teilnehmen. Im Laufe der Jahre wurde versucht, eine Lösung für das Trilemma zu finden, beispielsweise staatliche Kanäle [3] und Plasma [4, 5]. Diese Lösungen haben die Eigenschaft, bestimmte Aktivitäten zu verschieben Off-Chain, Verknüpfung von On-Chain-Aktivitäten mit Off-Chain-Aktivitäten mithilfe von smart contracts und Überprüfung DLT 2023: 5. Distributed Ledger Technology Workshop, 25.–26. Mai 2023, Bologna, Italien $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Das Urheberrecht für dieses Papier liegt bei den Autoren. Die Nutzung ist unter der Creative Commons-Lizenz Namensnennung 4.0 International (CC BY 4.0) gestattet. CEUR Werkstatt Verfahren http://ceur-ws.org ISSN 1613-0073 CEUR-Workshop-Beiträge (CEUR-WS.org)On-Chain, was außerhalb der Kette passiert. Allerdings sind sowohl Plasma- als auch Zustandskanäle begrenzt ihre Unterstützung allgemeiner smart contracts. Rollups sind blockchains (genannt Layer 2 oder L2), die ihre Blöcke auf einem anderen blockchain veröffentlichen. (Layer 1 oder L1) und erben daher dessen Konsens-, Datenverfügbarkeits- und Sicherheitseigenschaften. Sie, Im Gegensatz zu anderen Lösungen unterstützen sie beliebige Berechnungen. Rollups bestehen aus drei Hauptkomponenten: • Sequenzer: Knoten, die Rollup-Transaktionen von Benutzern empfangen und diese zu einem zusammenfassen Block, der an Layer 1 gesendet wird. Der Block besteht mindestens aus der Staatswurzel (z. B. einem Merkle root) und die Daten, die zur Rekonstruktion und Validierung des Status erforderlich sind. Der Layer 1 definiert die kanonischer blockchain des L2 durch Festlegen der Reihenfolge der veröffentlichten Daten. • Vollständige Rollup-Knoten: Knoten, die Rollup-Blöcke vom Layer abrufen, verarbeiten und validieren 1, indem Sie überprüfen, ob der Stamm korrekt ist. Wenn ein Block ungültige Transaktionen enthält, ist dies der Fall verworfen, was verhindert, dass Sequenzer gültige Blöcke erstellen, die ungültige enthalten Transaktionen. • Rollup-Light-Knoten: Knoten, die Rollup-Blöcke von Layer 1 erhalten, aber keine Berechnungen durchführen der neue Staat selbst. Mithilfe von Techniken überprüfen sie, ob die neue Statuswurzel gültig ist wie etwa Fehler- oder Gültigkeitsnachweise. Rollups erreichen Skalierbarkeit, indem sie die fortgeführten Anschaffungskosten der Transaktionen als Anzahl verringern der Nutzer steigt. Dies liegt daran, dass die Kosten für die Sicherstellung der Gültigkeit von blockchain sublinear ansteigen in Bezug auf die Kosten für die individuelle Überprüfung von Transaktionen. Rollups unterscheiden sich je nach der Mechanismus, mit dem sie die Gültigkeit der Transaktionsausführung an Light Nodes sicherstellen: in Optimistische Rollups werden durch ein Wirtschaftsmodell und durch Fehlernachweise gewährleistet, während die Gültigkeit gewährleistet ist Bei Rollups erfolgt die kryptografische Absicherung durch Gültigkeitsnachweise. Leichte Knoten können als smart contracts auf Layer 1 implementiert werden. Sie akzeptieren die Wurzel des neuen Zustand und überprüfen Gültigkeit oder Fehlernachweise: Diese Rollups werden daher Smart Contract genannt Rollups. Wenn Light Nodes unabhängig sind, werden sie Sovereign Rollups [6] genannt. Der Vorteil von Die Verwendung eines Smart Contract Rollups besteht darin, eine vertrauensminimierte Brücke zwischen beiden bauen zu können blockchains: Da die Gültigkeit des L2-Zustands auf L1 bewiesen ist, entsteht ein System von Transaktionen L2 bis L1 können implementiert werden, was Abhebungen ermöglicht. Der Nachteil besteht darin, dass die Kosten dafür Transaktionen hängen von den Kosten für die Überprüfung des Status auf L1 ab: wenn die Basisschicht gesättigt ist Bei anderen Aktivitäten steigen auch die Kosten für Transaktionen im Rollup. Die Daten- und Konsensebene bestimmt die Sicherheit des Systems Sie legen die Reihenfolge von Transaktionen fest, verhindern Angriffe und stellen Daten zum Nachweis des Staates zur Verfügung Gültigkeit. Papierbeitrag In diesem Artikel untersuchen wir Optimistic und Validity Rollups, zwei innovative Lösungen für das Skalierbarkeitstrilemma, mit Schwerpunkt auf bemerkenswerten Implementierungen wie Optimism Bedrock und StarkNet. Unsere Beiträge beinhalten einen umfassenden Vergleich dieser Lösungen, eine Analyse der Auszahlungszeiten und eine Diskussion eines möglichen Angriffs auf Optimism Grundgestein. Darüber hinaus berechnen wir deren Gasverdichtungsverhältnisse, liefern anwendungsspezifische Optimierungen und stellen die Vor- und Nachteile einer Abkehr vom Ethereum dar. Virtuelle Maschine (EVM).

Papierstruktur Der Aufsatz ist wie folgt aufgebaut. In Abschnitt 2 sind optimistische Rollups eingeführt durch die Analyse von Optimism Grundgestein. In Abschnitt 3 werden Validity Rollups vorgestellt Analyse von StarkNet. In Abschnitt 4 vergleichen wir die beiden Lösungen. Abschließend zeichnen wir in Abschnitt 5 einige Schlussfolgerungen.

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.

Optimistische Rollups

  1. Optimistische Rollups Die Idee, die Ausgabe von Blöcken optimistisch zu akzeptieren, ohne ihre Ausführung zu überprüfen, ist bereits im Whitepaper Bitcoin [7] enthalten, in dem es um Lichtknoten geht. Diese Knoten folgen nur die Header-Kette durch Überprüfung der Konsensregel, wodurch sie anfällig für die Annahme von Blöcken werden enthält ungültige Transaktionen im Falle eines 51 %-Angriffs. Nakamoto schlägt vor, dieses Problem zu lösen Problem, indem ein „Warnsystem“ verwendet wird, um Light-Knoten zu warnen, dass ein Block ungültige Transaktionen enthält. Dieser Mechanismus wurde erstmals von Al-Bassam, Sonnino und Buterin [8] in dem ein Fehler implementiert wurde Es wird ein Proofsystem verwendet, das auf den Fehlerkorrekturcodes [9] basiert. Um die Erstellung von zu ermöglichen Für Fehlernachweise ist es erforderlich, dass die Daten aller Blöcke, einschließlich ungültiger Blöcke, verfügbar sind das Netzwerk: Dies ist das Datenverfügbarkeitsproblem, das mithilfe probabilistischer Daten gelöst wird Probenahmemechanismus. Das erste Optimistic Rollup-Design wurde von John Adler und vorgestellt Mikerah Quintyne-Collins im Jahr 2019 [10], in dem Blöcke auf einem anderen blockchain veröffentlicht werden Das definiert ihren Konsens über die Bestellung. 2.1. Optimism Grundgestein Bedrock [11] ist die neueste Version von Optimism, einem Smart Contract Rollup. Die vorherige Version, Für die Optimistic Virtual Machine (OVM) war ein Ad-hoc-Compiler erforderlich, um Solidity in sie zu kompilieren Eigener Bytecode: Im Gegensatz dazu entspricht Bedrock in Bezug auf die Ausführungs-Engine vollständig dem EVM folgt der Ethereum Yellow Paper-Spezifikation [12]. 2.1.1. Einlagen Benutzer können Transaktionen über einen Vertrag auf Ethereum, dem Optimism-Portal, einzahlen, indem sie die Funktion „depositTransaction“ aufrufen. Wenn eine Transaktion ausgeführt wird, a Das TransactionDeposited-Ereignis wird ausgegeben, auf dessen Verarbeitung jeder Knoten im Rollup wartet Einlagen. Eine hinterlegte Transaktion ist eine L2-Transaktion, die von L1 abgeleitet ist. Wenn der Anrufer der Funktion ist ein Vertrag, die Adresse wird transformiert, indem ihr ein konstanter Wert hinzugefügt wird: Dies verhindert Angriffe, bei denen ein Vertrag auf L1 dieselbe Adresse wie ein Vertrag auf L2, aber einen anderen Code hat. Die Aufnahme einer hinterlegten Transaktion auf L2 wird durch die Spezifikation innerhalb einer Sequenzierung sichergestellt Fenster. Hinterlegte Transaktionen sind ein neuer EIP-2718-kompatibler Transaktionstyp [13] mit dem Präfix 0x7E. wobei die RLP-codierten Felder sind: • bytes32 sourceHash: hash, der die Quelle der Transaktion eindeutig identifiziert. • Adresse von: die Adresse des Absenders. • Adresse an: die Empfängeradresse oder die Nulladresse, wenn es sich bei der hinterlegten Transaktion um eine handelt Vertragserstellung.• uint256 mint: der Wert, der auf L2 erstellt werden soll. • uint256-Wert: der an den Empfänger zu sendende Wert. • Byte-Daten: die Eingabedaten. • Bytes gasLimit: das Gaslimit der Transaktion. Der sourceHash wird als keccak256 hash des L1-Blocks hash und des L1-Protokolls berechnet Index, der ein Ereignis in einem Block eindeutig identifiziert. Da hinterlegte Transaktionen auf L1 initiiert, aber auf L2 ausgeführt werden, benötigt das System eine Mechanismus, um L1 für das auf L2 ausgegebene Gas zu bezahlen. Eine Lösung besteht darin, ETH über das Portal zu senden. Dies bedeutet jedoch, dass jeder Anrufer (auch indirekte Anrufer) als zahlbar gekennzeichnet werden muss, und das ist auch der Fall ist bei vielen bestehenden Projekten nicht möglich. Die Alternative besteht darin, das entsprechende Gas auf L1 zu verbrennen. Das der hinterlegten Transaktion zugewiesene Gas wird als garantiertes Gas bezeichnet. Der L2-Gaspreis an L1 wird nicht automatisch synchronisiert, sondern mithilfe eines Mechanismus ähnlich EIP-1559 geschätzt [14]. Die maximale garantierte Gasmenge pro Ethereum-Block beträgt 8 Millionen, mit einem Ziel von 2 Millionen. Die Menge 𝑐an ETH, die zum Bezahlen von Gas auf L2 erforderlich ist, beträgt 𝑐= 𝑔𝑏L2, wobei 𝑏L2 ist Grundgebühr auf L2. Der Vertrag auf L1 verbrennt eine Gasmenge, die 𝑐/𝑏L2 entspricht. Das ausgegebene Gas zum Anrufen EinzahlungTransaktion wird auf L2 erstattet: Wenn dieser Betrag größer ist als das garantierte Gas, Es wird kein Gas verbrannt. Die erste Transaktion eines rollup-Blocks ist eine hinterlegte Transaktion mit L1-Attributen, die zur Registrierung verwendet wird Stellen Sie auf einem L2 die Attribute von Ethereum-Blöcken vorab bereit. Die Attribute, die das Predeploy bereitstellt Zugriff auf sind die Blocknummer, der Zeitstempel, die Grundgebühr, der Block hash und die Reihenfolge Zahl, die die Blocknummer von L2 relativ zum zugehörigen L1-Block (auch Epoche genannt) ist; Diese Zahl wird zurückgesetzt, wenn eine neue Epoche beginnt. 2.1.2. Sequenzierung Die Rollup-Knoten leiten die Kette Optimism vollständig von Ethereum ab. Diese Kette wird verlängert Jedes Mal, wenn neue Transaktionen auf L1 veröffentlicht werden, werden die Blöcke jedes Mal neu organisiert Ethereum Blöcke werden neu organisiert. Der Rollup blockchain ist in Epochen unterteilt. Für jeden 𝑛 Blocknummer Ethereum, es gibt eine entsprechende 𝑛Epoche. Jede Epoche enthält mindestens eine Block, und jeder Block in einer Epoche enthält eine hinterlegte Transaktion mit L1-Attributen. Der erste Block in einer Epoche enthält alle über das Portal hinterlegten Transaktionen. Layer 2-Blöcke können ebenfalls vorhanden sein enthielt sequenzierte Transaktionen, d. h. Transaktionen, die direkt an den Sequencer gesendet wurden. Der Sequencer akzeptiert Transaktionen von Benutzern und erstellt Blöcke. Für jeden Block wird konstruiert ein Stapel, der am Ethereum veröffentlicht werden soll. Mehrere Chargen können komprimiert veröffentlicht werden, den Namenskanal übernehmen. Ein Kanal kann in mehrere Frames unterteilt werden, falls er zu groß ist eine einzelne Transaktion. Ein Kanal wird als Komprimierung mit ZLIB [15] von rlp-encoded definiert Chargen. Die Felder eines Stapels sind die Epochennummer, die Epoche hash, die übergeordnete hash, die Zeitstempel und die Transaktionsliste. Ein durch eine Epoche identifiziertes Sequenzierungsfenster enthält eine feste Anzahl aufeinanderfolgender L1 Blöcke, die ein Ableitungsschritt als Eingabe verwendet, um eine variable Anzahl von L2-Blöcken zu erstellen. Für Epoche 𝑛, das Sequenzierungsfenster 𝑛enthält die Blöcke [𝑛, 𝑛+𝑤). Dies impliziert, dass die Bestellung Die Anzahl der L2-Transaktionen und -Blöcke innerhalb eines Sequenzierungsfensters wird erst am Ende des Fensters festgelegt. Eine rollup-Transaktion wird als sicher bezeichnet, wenn der Batch, der sie enthält, auf L1 bestätigt wurde. Rahmenwerden aus L1-Blöcken gelesen, um Stapel zu rekonstruieren. Die aktuelle Implementierung erlaubt dies nicht Die Dekomprimierung eines Kanals beginnt, bis alle entsprechenden Frames empfangen wurden. Ungültig Chargen werden ignoriert. Aus den Batches werden einzelne Blocktransaktionen gewonnen Wird von der Ausführungs-Engine verwendet, um Statusübergänge anzuwenden und den Rollup-Status zu erhalten. 2.1.3. Auszahlungen Um Abhebungen zu verarbeiten, ist ein L2-zu-L1-Nachrichtensystem implementiert. Ethereum muss den Status von L2 kennen, um Abhebungen zu akzeptieren, und dies geschieht durch Veröffentlichung auf der L2-Ausgabe Oracle smart contract auf L1 die Statuswurzel jedes L2-Blocks. Diese Wurzeln werden optimistisch als gültig (oder abgeschlossen) akzeptiert, wenn währenddessen kein Fehlernachweis durchgeführt wird Streitzeitraum. Nur als Antragsteller gekennzeichnete Adressen können Ausgabe-Roots veröffentlichen. Die Gültigkeit von Output-Wurzeln wird dadurch angeregt, dass Antragsteller einen Einsatz hinterlegen, der gekürzt wird, wenn sie es tun hat nachweislich eine ungültige Wurzel vorgeschlagen. Transaktionen werden durch den Aufruf der Funktion initiiert initialisieren Sie Withdrawal bei einer Vorbereitstellung auf L2 und finalisieren Sie es dann auf L1 durch Aufrufen der Funktion finalizeWithdrawalTransaction auf dem zuvor erwähnten Optimism-Portal. Die dem L2-Block entsprechende Ausgabewurzel wird vom L2-Ausgabe-Oracle abgerufen. es ist überprüft, dass es abgeschlossen ist, d. h. dass die Streitfrist abgelaufen ist; Es wird überprüft, ob die Ausgabe erfolgt Root Proof entspricht dem Oracle Proof; Es wird überprüft, dass der hash der Auszahlung enthalten ist darin unter Verwendung eines Auszahlungsnachweises; dass der Rückzug noch nicht abgeschlossen ist; und dann die Der Anruf an die Zieladresse wird mit dem angegebenen Gaslimit, der angegebenen Ethermenge und den angegebenen Daten ausgeführt. 2.1.4. Cannon: das fehlersichere System Wenn ein Rollup Full Node dies durch die lokale Ausführung von Batches und hinterlegten Transaktionen erkennt Wenn der Status Layer 2 nicht mit dem Statusstamm übereinstimmt, der von einem Antragsteller in der Kette veröffentlicht wurde, kann er ausgeführt werden ein Fehlernachweis auf L1, um zu beweisen, dass das Ergebnis des Blockübergangs falsch ist. Aufgrund der Aufgrund des Overheads ist die Verarbeitung eines gesamten Rollup-Blocks auf L1 zu teuer. Die Lösung umgesetzt von Bedrock besteht darin, in der Kette nur die erste Anweisung der Meinungsverschiedenheit von Minigeth auszuführen, Kompilieren in eine MIPS-Architektur, die auf einem On-Chain-Interpreter ausgeführt und veröffentlicht wird auf L1. Minigeth ist eine vereinfachte Version von Geth 1, in der Konsens, RPC und Datenbank enthalten sind wurden entfernt. Um die erste Anweisung der Meinungsverschiedenheit zu finden, wird eine interaktive binäre Suche zwischen durchgeführt derjenige, der den Fehlernachweis initiiert hat und derjenige, der den Ausgabestamm veröffentlicht hat. Wenn der Beweis Beginnt, veröffentlichen beide Parteien die Wurzel des Speicherstatus MIPS in der Mitte der Ausführung von der Block im Challenge-Vertrag: Wenn hash übereinstimmt, bedeutet dies, dass sich beide Parteien darauf einigen Die erste Hälfte der Ausführung veröffentlicht somit die Wurzel der Hälfte der zweiten Hälfte, andernfalls die Hälfte der ersten Hälfte veröffentlicht wird und so weiter. Dadurch wird die erste Anweisung zur Meinungsverschiedenheit erreicht in einer logarithmischen Anzahl von Schritten im Vergleich zur ursprünglichen Ausführung. Wenn einer der beiden stehen bleibt Durch die Interaktion gewinnt am Ende des Streitzeitraums automatisch der andere Teilnehmer. Um die Anweisung zu verarbeiten, benötigt der Interpreter MIPS Zugriff auf seinen Speicher: da der Root vorhanden ist Sind die notwendigen Speicherzellen vorhanden, können sie durch den Nachweis ihrer Einbindung veröffentlicht werden. Zugreifen B. den Status von EVM, wird das Preimage-Orakel verwendet: Angesichts des hash eines Blocks wird es zurückgegeben 1https://geth.ethereum.org/docs

der Blockheader, aus dem man den hash des vorherigen Blocks abrufen und in den zurückkehren kann Kette, oder rufen Sie den hash des Status und der Protokolle ab, von denen man das Vorbild erhalten kann. Der oracle wird von minigeth implementiert und ersetzt die Datenbank. Es werden Anfragen an andere Knoten gestellt Holen Sie sich die Vorbilder.

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)

Gültigkeits-Rollups

  1. Gültigkeits-Rollups Das Ziel eines Validity Rollups besteht darin, die Gültigkeit des Zustandsübergangs kryptografisch nachzuweisen Angesichts der Abfolge von Transaktionen mit einem kurzen Beweis, der sublinear verglichen werden kann zum Zeitpunkt der ursprünglichen Berechnungen. Solche Zertifikate werden als Computational Integrity Proofs bezeichnet und werden praktisch mit SNARKs (Succint Non-interactive ARgument of Knowledge) umgesetzt, die Arithmetik verwenden Schaltkreise als ihr Rechenmodell. Verschiedene SNARK-Implementierungen unterscheiden sich in der Prüfzeit, Verifizierungszeit, die Notwendigkeit eines vertrauenswürdigen Aufbaus und Quantenwiderstand [16, 17]. STARKs (Skalierbar Transparentes ARgument des Wissens) [18] sind eine Art von SNARKs, für die kein vertrauenswürdiges Dokument erforderlich ist aufgebaut und sind quantenresistent, geben aber beim Nachweis und der Verifizierung etwas Effizienz ein im Vergleich zu anderen Lösungen. 3.1. StarkNet StarkNet ist ein von StarkWare entwickeltes Smart Contract Validity Rollup, das STARK verwendet Proof-System, um seinen Status auf Ethereum zu validieren. Um die Konstruktion von Gültigkeitsnachweisen zu erleichtern, a Es wird eine andere virtuelle Maschine als EVM verwendet, deren Hochsprache Cairo ist. 3.1.1. Einlagen Benutzer können Transaktionen über einen Vertrag auf Ethereum einzahlen, indem sie sendMessageToL2 aufrufen Funktion. Die Nachricht wird aufgezeichnet, indem ihr hash berechnet und ein Zähler erhöht wird. Sequenzer Warten Sie auf das LogMessageToL2-Ereignis und kodieren Sie die Informationen in einer StarkNet-Transaktion Das ruft eine Funktion eines Vertrags auf, der über den l1_handler-Dekorator verfügt. Am Ende der Ausführung, Wenn der Nachweis des Zustandsübergangs erbracht wird, wird der Verbrauch der Nachricht daran angehängt und es wird gelöscht, indem sein Zähler verringert wird. Die Einbeziehung hinterlegter Transaktionen ist in der StarkNet-Spezifikation nicht erforderlich, also ein Gas Der Markt ist erforderlich, um Sequenzern einen Anreiz zu geben, sie auf L2 zu veröffentlichen. In der aktuellen Version, weil Der Sequencer wird von StarkWare zentralisiert und verwaltet die Kosten der hinterlegten Transaktionen wird nur durch die Kosten für die Ausführung der Anzahlung bestimmt. Diese Kosten werden durch die Überweisung der ETH an bezahlt sendMessageToL2. Diese Ether bleiben auf L1 gesperrt und werden weiter an den Sequenzer übertragen L1, wenn die hinterlegte Transaktion in einen Zustandsübergang einbezogen wird. Der Betrag der gesendeten ETH, falls Die eingezahlte Transaktion ist im Preis enthalten und wird vollständig ausgegeben, unabhängig von der Menge des verbrauchten Gases auf L2. StarkNet verfügt nicht über ein System, das L1-Blockattribute automatisch verfügbar macht. Alternativ ist Fossil ein von Oiler Network 2 entwickeltes Protokoll, das bei gegebenem hash von a Block, alle Informationen, die von Ethereum durch Veröffentlichung von Vorbildern erhalten werden. 2https://www.oiler.network/3.1.2. Sequenzierung Der aktuelle Stand von StarkNet kann vollständig von Ethereum abgeleitet werden. Irgendein Zustandsunterschied zwischen Übergängen werden auf L1 als Anrufdaten veröffentlicht. Unterschiede werden für jeden Vertrag veröffentlicht und werden als uint256[] mit der folgenden Kodierung gespeichert: • Nummer des Feldes bezüglich Vertragsbereitstellungen. • Für jeden veröffentlichten Vertrag: – Die Adresse des veröffentlichten Vertrags. – Der hash des veröffentlichten Vertrags. – Die Anzahl der Argumente des Vertragskonstruktors. – Die Liste der Konstruktorargumente • Nummer des Vertrags, dessen Speicherung geändert wurde. • Für jeden Vertrag, der geändert wurde: – Die Adresse des geänderten Vertrags. – Die Anzahl der Speicheraktualisierungen. – Die Schlüssel-Wert-Paare der Speicheradressen mit den neuen Werten. Die Zustandsunterschiede werden der Reihe nach veröffentlicht, daher reicht es aus, sie nacheinander zu lesen den Staat neu aufbauen. 3.1.3. Auszahlungen Um eine Nachricht von L2 nach L1 zu senden, wird der Systemaufruf send_message_to_L1 verwendet. Die Botschaft ist auf L1 veröffentlicht, indem der Zähler hash zusammen mit dem Beweis erhöht und durch Aufrufen von abgeschlossen wird Funktion „consumeMessageFromL2“ auf dem StarkGate smart contract auf L1, die dekrementiert der Zähler. Jeder kann eine Auszahlung abschließen. 3.1.4. Gültigkeitsnachweise Die Cairo Virtual Machine [19] soll die Erstellung von STARK-Beweisen erleichtern. Die Kairo-Sprache ermöglicht die Beschreibung der Berechnung mit einer High-Level-Programmierung Sprache und nicht direkt als Schaltkreis. Dies wird durch ein System polynomialer Gleichungen erreicht 3 stellt eine einzelne Berechnung dar: den FDE-Zyklus einer von Neumann-Architektur. Die Nummer Die Anzahl der Einschränkungen ist somit fest und unabhängig von der Art der Berechnung, sodass nur eine zulässig ist Prüfprogramm für jedes Programm, dessen Berechnung bewiesen werden muss. StarkNet fasst mehrere Transaktionen mithilfe eines gemeinsamen Prüfers zu einem einzigen STARK-Beweis zusammen mit dem Namen SHARP. Die Nachweise werden an smart contract am Ethereum gesendet, der ihre Gültigkeit überprüft und aktualisiert die Merkle-Wurzel, die dem neuen Status entspricht. Die sublinearen Kosten für die Überprüfung von a Durch den Gültigkeitsnachweis können die Kosten über mehrere Transaktionen amortisiert werden. 3Algebraische Zwischendarstellung (AIR) genannt

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.

Vergleich

  1. Vergleich 4.1. Auszahlungszeit Der wichtigste Aspekt, der optimistische Rollups von Validity Rollups unterscheidet, ist der Zeit, die zwischen der Initialisierung einer Auszahlung und ihrem Abschluss vergeht. In beiden Fällen Auszahlungen werden auf L2 initialisiert und auf L1 abgeschlossen. Am StarkNet ist die Finalisierung möglich als Sobald der Gültigkeitsnachweis der neuen Statuswurzel am Ethereum akzeptiert wird: Theoretisch ist dies der Fall Es ist möglich, nach der Initialisierung Geld im ersten Block von L1 abzuheben. In der Praxis ist die Die Häufigkeit des Sendens von Gültigkeitsnachweisen auf Ethereum ist ein Kompromiss zwischen der Blockgeschwindigkeit Finalisierung und Proof-Aggregation. Derzeit stellt StarkNet Gültigkeitsnachweise zur Überprüfung bereit alle 10 Stunden 4, soll aber mit zunehmender Transaktionsaktivität verringert werden. Auf Optimism Bedrock ist es möglich, eine Auszahlung erst am Ende des Streits abzuschließen Zeitraum (derzeit 7 Tage), nach dem ein Root automatisch als gültig gilt. Die Länge von Dieser Zeitraum wird hauptsächlich dadurch bestimmt, dass Fehlernachweise bis zum Ethereum zensiert werden können sein Ende. Die Erfolgswahrscheinlichkeit dieser Art von Angriff nimmt mit zunehmender Zeit exponentiell ab: E[subtrahierter Wert] = 𝑉𝑝𝑛 Dabei ist 𝑛 die Anzahl der Blöcke in einem Intervall und 𝑉 der Betrag, der abgezogen werden kann durch Veröffentlichung einer ungültigen Wurzel, und 𝑝ist die Wahrscheinlichkeit, eine Zensur erfolgreich durchzuführen Angriff in einem einzigen Block. Angenommen, diese Wahrscheinlichkeit beträgt 99 %, sodass der Wert im Rollup gesperrt ist eine Million Ether beträgt und dass die Blöcke in einem Intervall 1800 sind (6 Stunden Blöcke mit einer 12 Sekundenintervall): Der erwartete Wert liegt bei etwa 0,01391 Ether. Das System wird durch gesichert Bitten Sie die Antragsteller, eine viel größere Menge Ether als den erwarteten Wert einzusetzen. Winzer et al. zeigte, wie man einen Zensurangriff mit einem einfachen smart contract durchführt Dadurch wird sichergestellt, dass sich bestimmte Speicherbereiche im Status [20] nicht ändern. Den Angriff modellieren Als Markov-Spiel zeigt der Artikel, dass Zensur die vorherrschende Strategie für ein Rationales ist Blockproduzenten, wenn sie mehr Entschädigung erhalten, als die Transaktion, die sich ändert, einschließen die Erinnerung. Der oben besprochene 𝑝Wert kann als Prozentsatz der rationalen Blockade angesehen werden Produzenten im Netzwerk, wobei „rational“ mögliche Strafen nicht berücksichtigt Externalitäten, wie z. B. weniger Vertrauen in blockchain, das seinen Kryptowährungswert verringert. Der folgende Code stellt einen smart contract dar, der für einen Zensurangriff verwendet werden kann auf Grundgestein. Der Angriff nutzt die Anreize der Blockproduzenten aus, indem er ihnen Bestechungsgelder anbietet um die Transaktionen zu zensieren, die bestimmte Teile des Staates verändern würden. Der Hauptvertrag Mit der Funktion ClaimBribe können Blockproduzenten Bestechungsgelder einfordern, wenn sie erfolgreich zensieren die Zieltransaktion, indem überprüft wird, ob der ungültige Ausgabestamm nicht berührt wird. Funktion ClaimBribe(Bytes Speicher StorageProof) external { require(!claimed[block.number], „Bestechung bereits eingefordert“); OutputProposal-Speicherstrom = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, storageProof); require(invalidOutputRoot == current.outputRoot, "Angriff fehlgeschlagen"); beansprucht[block.nummer] = true; (bool sent, ) = block.coinbase.call{value: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(sent, „Ether konnte nicht gesendet werden“); } Listing 1: Beispiel eines Vertrags, der einen Anreiz für einen Zensurangriff auf Bedrock bietet. Bei der Länge der Streitfrist ist auch die Tatsache zu berücksichtigen, dass der Beweis des Verschuldens vorliegt ein interaktiver Beweis und daher muss den Teilnehmern genügend Zeit zur Interaktion zur Verfügung gestellt werden und dass jede Interaktion zensiert werden könnte. Wenn der letzte Zug zu einem Zeitpunkt sehr nahe am erfolgt Am Ende des Streitzeitraums sind die Zensurkosten deutlich geringer. Obwohl Zensur das ist Bei einer dominanten Strategie ist die Erfolgswahrscheinlichkeit geringer, da zensierende Knoten anfällig dafür sind Denial-of-Service-Angriffe: Ein Angreifer kann sehr komplexe Transaktionen generieren, die mit dem enden Die Veröffentlichung eines Fehlernachweises ist kostenfrei, da keine Gebühren anfallen. Im Extremfall ermöglicht eine lange Streitdauer eine Abstimmung im Erfolgsfall Zensurangriff, um einen Fork zu organisieren und die angreifenden Blockproduzenten auszuschließen. Ein anderer Ein möglicher Angriff besteht darin, mehr staatliche Stammvorschläge zu veröffentlichen, als die Streitparteien überprüfen können. was durch eine Frequenzbegrenzung vermieden werden kann. 4.1.1. Schnelle optimistische Abhebungen Da die Gültigkeit eines Optimistic Rollups jederzeit von jedem Full Node überprüft werden kann, a vertrauenswürdig oracle kann verwendet werden, um auf L1 zu erfahren, ob die Auszahlung sicher abgeschlossen werden kann. Dies Der Mechanismus wurde zuerst vom Hersteller [21] vorgeschlagen: Ein oracle überprüft die Auszahlung und veröffentlicht die Ergebnis auf L1, auf dem dem Benutzer automatisch ein verzinsliches Darlehen zugewiesen wird nach Ablauf von 7 Tagen geschlossen, d. h. wenn die Auszahlung tatsächlich abgeschlossen werden kann. Diese Lösung führt eine Vertrauensannahme ein, die im Fall von Maker jedoch durch den Operator oracle minimiert wird wird von derselben Organisation verwaltet, die das Risiko durch die Bereitstellung des Darlehens übernimmt. 4.2. Transaktionskosten Die Kosten von L2-Transaktionen werden hauptsächlich durch die Interaktion mit L1 bestimmt. In beiden Lösungen Der Rechenaufwand für Transaktionen ist sehr gering, da sie vollständig außerhalb der Kette ausgeführt werden. Optimism veröffentlicht L2-Transaktionsanrufdaten als Anrufdaten und führt selten (oder nie) einen Fehler aus Beweise, daher sind Anrufdaten die teuerste Ressource. Am 12. Januar 2022 ein Bedrock-Netzwerk wurde im Goerli-Testnetz von Ethereum gestartet. Es kann eine Gaskompressionsrate berechnet werden indem die in einem bestimmten Zeitraum auf Bedrock verbrauchte Gasmenge verfolgt und mit der Menge verglichen wird Menge an Gas, die für L1 für die entsprechenden Blöcke ausgegeben wird. Mit dieser Methode wird eine Gaskompression durchgeführt Es wurde eine Rate von ∼20 : 1 gefunden, diese Zahl kann jedoch je nach tatsächlicher Aktivität im Mainnet abweichen. StarkNet veröffentlicht am Ethereum jede Änderung im L2-Status als Aufrufdaten, daher erfolgt die Speicherung die teuerste Ressource. Da das Netzwerk EVM nicht verwendet, betragen die Transaktionskosten Die Komprimierung kann nicht trivial abgeschätzt werden. Durch die Übernahme der Ausführungskosten und der Anrufdaten vernachlässigbar sein, ist es möglich, das Komprimierungsverhältnis von Speicherschreibvorgängen im Vergleich zu zu berechnen L1. Es wird davon ausgegangen, dass kein Vertrag bereitgestellt wird und 10 Zellen, auf die zuvor nicht auf StarkNet zugegriffen wurde, vorhanden sind modifiziert, wird eine Komprimierungsrate der Speicherschreibkosten von ∼24:1 gefunden. Wenn eine Zelle überschrieben wird 𝑛Zeiten zwischen Datenveröffentlichungen betragen die Kosten für jeden Schreibvorgang 1/𝑛im Vergleich zu den Kosten eines einzelnen Schreibvorgangs, da nur der letzte veröffentlicht wird. Die Kosten können dadurch weiter minimiert werdenKomprimierung häufig verwendeter Werte. Die Kosten für die Überprüfung des Gültigkeitsnachweises werden aufgeteilt die Transaktionen, auf die es sich bezieht: zum Beispiel enthält StarkNet Block 4779 200 Transaktionen und seine Der Gültigkeitsnachweis verbraucht 267830 Gaseinheiten oder 1339,15 Gas pro Transaktion. 4.2.1. Anrufdaten optimieren: Cache-Vertrag Nachfolgend wird ein smart contract vorgestellt, der einen Adresscache für häufig verwendete Adressen implementiert Adressen unter Ausnutzung der Tatsache, dass Speicherung und Ausführung wesentlich kostengünstiger sind Ressourcen, zusammen mit einem Friends-Vertrag, der ihre Verwendung belegt. Letzterer behält den Überblick „Freunde“ einer Adresse, die durch Aufruf der Funktion addFriend registriert werden können. Wenn eine Adresse bereits mindestens einmal verwendet wurde, kann es durch den Aufruf von addFriendWithCache hinzugefügt werden Funktion: Die Cache-Indizes sind 4-Byte-Ganzzahlen, während die Adressen durch 20 Bytes dargestellt werden. es gibt also eine 5:1-Ersparnis beim Funktionsargument. Die gleiche Logik kann für andere Daten verwendet werden Typen wie Ganzzahlen oder allgemeiner Bytes. Vertrag AddressCache { Mapping(address => uint32) public address2key; Adresse[] öffentlicher Schlüssel2Adresse; Funktion CacheWrite(Adresse _Adresse) interne Rückgabe (uint32) { require(key2address.length < type(uint32).max, "AddressCache: Cache ist voll"); require(address2key[_address] == 0, "AddressCache: Adresse bereits zwischengespeichert"); // Schlüssel müssen bei 1 beginnen, da 0 „nicht gefunden“ bedeutet uint32 key = uint32(key2address.length + 1); address2key[_address] = Schlüssel; key2address.push(_address); Eingabetaste; } Funktion „cacheRead(uint32 _key)“ öffentliche Ansicht gibt (Adresse) { zurück require(_key <= key2address.length && _key > 0, "AddressCache: Schlüssel nicht gefunden"); return key2address[_key - 1]; } } Listing 2: Adress-Cache-Vertrag. Vertrag Freunde ist AddressCache { Mapping(Adresse => Adresse[]) öffentliche Freunde; Funktion addFriend(address _friend) public { friends[msg.sender].push(_friend); CacheWrite(_friend); } function addFriendWithCache(uint32 _friendKey) public { friends[msg.sender].push(cacheRead(_friendKey)); } Funktion getFriends() öffentliche Ansicht gibt (Adresse[] Speicher) { return friends[msg.sender];} } Listing 3: Beispiel für einen Vertrag, der den Adress-Cache erbt. Der Vertrag unterstützt im Cache etwa 4 Milliarden (232) Adressen, und das Hinzufügen eines Bytes ergibt etwa 1 Billion (240). 4.2.2. Speicher optimieren: Filter von Bloom Auf StarkNet gibt es mehrere Techniken zur Minimierung der Speichernutzung. Wenn es nicht nötig ist Um die Verfügbarkeit der Originaldaten zu gewährleisten, reicht es aus, deren hash: this in der Kette zu speichern ist der Mechanismus zum Speichern von Daten für einen ERC-721 (NFT) [22], d. h. eine IPFS-Verbindung, die das auflöst hash der Daten, sofern verfügbar. Bei mehrfach gespeicherten Daten besteht die Möglichkeit, eine Nachschlagefunktion zu nutzen Tabelle ähnlich dem für Optimism eingeführten Caching-System, bei dem alle Werte gespeichert werden müssen mindestens einmal. Bei einigen Anwendungen kann das Speichern aller Werte durch die Verwendung eines Bloom-Filters vermieden werden [23, 24, 25], d. h. eine probabilistische Datenstruktur, die es einem ermöglicht, mit Sicherheit zu wissen, ob Ein Element gehört nicht zu einer Menge, lässt aber eine kleine, aber nicht vernachlässigbare Wahrscheinlichkeit zu, dass es falsch ist Positives. Ein Bloom-Filter wird als Array von 𝑚Bits bei Null initialisiert. Um ein Element hinzuzufügen, funktioniert 𝑘hash mit einer gleichmäßigen Zufallsverteilung werden verwendet, die jeweils einem Bit des festgelegten Arrays zugeordnet sind zu 1. Um zu überprüfen, ob ein Element zur Menge gehört, führen wir die Funktionen 𝑘hash aus und überprüfen dass die 𝑘bits auf 1 gesetzt sind. In einem einfachen Bloom-Filter gibt es keine Möglichkeit zu unterscheiden, ob ein Das Element gehört tatsächlich zur Menge oder ist falsch positiv, eine Wahrscheinlichkeit, die mit der Zahl wächst der Einträge steigt. Nach dem Einfügen von 𝑛Elementen: P[falsch positiv] = (︃ 1 − [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 unter der Annahme, dass die Wahrscheinlichkeit jedes Bitsatzes unabhängig ist. Wenn 𝑛Elemente (beliebiger Größe!) sind Es wird erwartet, dass enthalten ist, und die Wahrscheinlichkeit eines tolerierten falschen Positivs beträgt 𝑝, die Größe des Arrays kann berechnet werden als: 𝑚= −𝑛ln 𝑝 (ln 2)2 Während die optimale Anzahl von hash-Funktionen ist: 𝑘= 𝑚 𝑛ln 2 Wenn wir davon ausgehen, dass 1000 Elemente mit einer Toleranz von 1 % eingefügt werden, beträgt die Größe des Arrays 9585 Bit mit 𝑘= 6, während es bei einer Toleranz von 0,1 % mit 𝑘= 9 zu 14377 Bits wird. Wenn eine Million Elemente erwartet werden, dass eingefügt wird, beträgt die Größe des Arrays etwa 1170 kB für 1 % und 1775 kB für 0,1 %, mit den gleichen Werten von 𝑘, da es nur von 𝑝[26] abhängt. In einem Spiel, in dem Spieler keinem Gegner zugewiesen werden dürfen, den sie bereits herausgefordert haben, Anstatt die Liste der früheren Gegner für jeden Spieler im Speicher zu speichern, kann man einen Bloom verwenden Filter. Das Risiko, einige Spieler nicht herauszufordern, ist oft akzeptabel und der Filter kann zurückgesetzt werden periodisch.4.3. Ethereum Kompatibilität Der Hauptvorteil der Kompatibilität mit EVM und Ethereum ist die Wiederverwendung aller verfügbaren Werkzeuge. Ethereum smart contracts können ohne jegliche Änderung auf Optimism veröffentlicht werden neue Prüfungen. Wallets bleiben kompatibel, Entwicklungs- und statische Analysetools, allgemeine Analyse Tools, Indizierungstools und oracles. Ethereum und Solidity haben eine lange, gut erforschte Geschichte Schwachstellen wie Wiedereintrittsangriffe, Über- und Unterläufe, schnelle Kredite und oracle Manipulationen. Aus diesem Grund konnte Optimism in kurzer Zeit einen großen Wert erzielen Zeit. Die Entscheidung für die Einführung einer anderen virtuellen Maschine bedeutet, dass ein gesamtes Ökosystem neu aufgebaut werden muss. mit dem Vorteil einer größeren Umsetzungsfreiheit. StarkNet implementiert das Konto nativ Abstraktion, ein Mechanismus, bei dem jedes Konto ein smart contract ist, das implementiert werden kann beliebige Logik, solange sie einer Schnittstelle entspricht (daher der Begriff Abstraktion): Dies ermöglicht die Verwendung verschiedener digitaler Signaturschemata, die Möglichkeit, den privaten Schlüssel mithilfe des zu ändern dieselbe Adresse oder verwenden Sie ein Multisig. Die Ethereum-Community hat die Einführung vorgeschlagen Mechanismus mit EIP-2938 im Jahr 2020, aber der Vorschlag ist seit mehr als einem Jahr veraltet Andere Updates haben höhere Priorität erhalten [27]. Ein weiterer wichtiger Vorteil der Kompatibilität ist die Wiederverwendung vorhandener Clients: Optimism verwendet eine Version von Geth für seinen eigenen Knoten mit nur ∼800 Zeilen Unterschied, was bisher der Fall war entwickelt, getestet und gewartet seit 2014. Ein robuster Client ist ausschlaggebend was im Netzwerk als gültig akzeptiert wird oder nicht. Ein Fehler in der Implementierung des Fehlernachweises Das System könnte dazu führen, dass ein falscher Beweis als richtig oder ein korrekter Beweis als ungültig akzeptiert wird Der Block wird als falsch akzeptiert und gefährdet das System. Die Wahrscheinlichkeit dieser Art von Der Angriff kann mit einer größeren Client-Vielfalt eingeschränkt werden: Optimism kann zusätzlich zu geth wiederverwendet werden andere Ethereum-Clients wurden bereits gepflegt, und die Entwicklung eines weiteren Erigon-basierten Clients ist im Gange bereits im Gange. Im Jahr 2016 wurde ein Problem in der Speicherverwaltung von Geth ausgenutzt DoS-Angriff und die erste Verteidigungslinie bestand darin, die Verwendung von Parity zu empfehlen, die zweithäufigste verwendeter Client zu der Zeit 5. StarkNet steht vor dem gleichen Problem mit Gültigkeitsnachweisen, aber die Clients müssen von Grund auf neu geschrieben werden und das Beweissystem ist viel komplexer und folglich Es ist auch viel komplexer, die Korrektheit sicherzustellen.

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.

Abschluss

  1. Fazit Rollups sind heute die vielversprechendste Lösung zur Lösung des Skalierbarkeitsproblems dezentrale blockchains, die den Weg für die Ära der modularen blockchains ebnen monolithische blockchains. Hauptsächlich wird die Wahl zwischen der Entwicklung eines Optimistic Rollup oder eines Validity Rollup gezeigt als Kompromiss zwischen Komplexität und Agilität. StarkNet bietet zahlreiche Vorteile wie z. B. schnell Abhebungen, strukturelle Unfähigkeit, ungültige Zustandsübergänge durchzuführen, niedrigere Transaktionskosten bei Kosten einer längeren Entwicklungszeit und Inkompatibilität mit EVM, während dies bei Optimism der Fall ist nutzte die Netzwerkwirtschaft, um schnell einen großen Marktanteil zu erobern. Optimism Bedrock verfügt jedoch über einen modularen Aufbau, der es ermöglicht, zu einer Gültigkeit zu werden 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Rollup in der Zukunft: Cannon verwendet derzeit Minigeth, kompiliert zu MIPS, für seinen Fehlernachweis System, aber dieselbe Architektur kann verwendet werden, um eine Schaltung zu erhalten und Gültigkeitsnachweise zu erstellen. Das Kompilieren einer komplexen Maschine wie EVM für eine Mikroarchitektur führt zu einer einfacheren Lösung Schaltkreis, der im Falle von Upgrades nicht geändert und erneut überprüft werden muss. RISC Zero ist ein überprüfbare Mikroarchitektur mit STARK-Beweisen, die sich bereits in der Entwicklung befinden, basierend auf RISC-V kann hierfür alternativ zu MIPS [28] verwendet werden. Ein nicht zu unterschätzender Aspekt ist die Komplexität des Verständnisses, wie das funktioniert Technik funktioniert. Eine Stärke herkömmlicher blockchains besteht darin, den Status von überprüfen zu können den blockchain, ohne einer Drittpartei zu vertrauen. Im Fall von StarkNet ist dies jedoch der Fall Es ist notwendig, der Implementierung zu vertrauen, wenn es nicht möglich ist, die verschiedenen Komponenten zu überprüfen basierend auf Kryptographie und fortgeschrittener Mathematik. Dies kann zunächst zu Reibungen führen Einführung der Technologie, aber da die Tools und die Verwendung von Integritätsnachweisen immer weiter voranschreiten Außerhalb des Feldes blockchain wird dieses Problem hoffentlich gelöst.