Esta es una traducción del artículo inicialmente publicado en inglés en el mirror oficial de Optimism.

To understand what is in the Bedrock release, keep reading. To develop on Optimism Mainnet, which will upgrade its infrastructure to the Bedrock release, read the docs. To contribute to the OP Stack, see the contribution guidelines on the ethereum-optimism monorepo. #Summary of Improvements

Bedrock es el nombre del primer lanzamiento oficial de la OP Stack, que es un conjunto de componentes modulares gratuitos, y de código abierto que trabajan juntos para potenciar Optimism.

• Para entender qué hay en el lanzamiento de Bedrock, sigue leyendo.

• Para desarrollar en el Optimism Mainnet, que actualizará su infraestructura al lanzamiento de Bedrock, lea los documentos.

• Para contribuir a la OP Stack, consulte las pautas de contribución en el monorepo de ethereum-optimism.

Bedrock mejora a su predecesor al reducir las tarifas de transacción utilizando compresión por lotes optimizada, y Ethereum como capa de disponibilidad de datos; acortando los retrasos de incluir transacciones L1 en rollups mediante el manejo de reorganizaciones L1 con más gracia; habilitando sistemas de prueba modulares a través de la reutilización de código; y mejorando el rendimiento de los nodos mediante la eliminación de la deuda técnica.

Además, Bedrock implementa una estrategia de compresión de datos optimizada para minimizar los costos de datos. Actualmente, estamos evaluando el impacto de este cambio, pero esperamos que reduzca significativamente las tarifas.

Bedrock también elimina todos los costos de gas asociados con la ejecución de EVM al enviar datos a L1. Esto reduce las tarifas en un 10% adicional con respecto a la versión anterior del protocolo.

Bedrock introduce soporte para reorganizaciones L1 en el software del nodo, lo que reduce significativamente la cantidad de tiempo que los usuarios deben esperar para los depósitos. Las versiones anteriores del protocolo podían tardar hasta 10 minutos en confirmar los depósitos. Con Bedrock, esperamos que los depósitos se confirmen en 3 minutos.

Bedrock abstrae el sistema de prueba de la OP Stack para que un resumen pueda usar una prueba de falla o una prueba de validez (por ejemplo, un zk-SNARK) para probar la ejecución correcta de las entradas en el resumen. Esta abstracción permite utilizar sistemas como Cannon (se abre en una ventana nueva) para probar fallas en el sistema.

Improved node performance

The node software performance has been significantly improved by enabling execution of several transactions in a single rollup "block" as opposed to the prior "one transaction per block" model in the previous version. This allows the cost of merkle trie updates to be amortized across multiple transactions. At current transaction volume, this reduces state growth by approximately 15GB/year.

Node performance is further improved by removing technical debt from the previous version of the protocol. This includes removing the need for a separate "data transport layer" node to index L1, and updating the node software to efficiently query for transaction data from L1.

El rendimiento del software del nodo se ha mejorado significativamente al permitir la ejecución de varias transacciones en un solo "bloque" del rollup en comparación con el modelo anterior de "una transacción por bloque" en la versión anterior. Esto permite que el costo de las actualizaciones de merkle trie se amortice en múltiples transacciones. Con el volumen de transacciones actual, esto reduce el crecimiento estatal en aproximadamente 15 GB/año.

El rendimiento del nodo se mejora aún más al eliminar la deuda técnica de la versión anterior del protocolo. Esto incluye eliminar la necesidad de un nodo de "layer de transporte de datos" separado para indexar L1, y actualizar el software del nodo para consultar de manera eficiente los datos de transacción de L1.

Bedrock fue diseñado desde cero para estar lo más cerca posible de Ethereum. Se han eliminado múltiples desviaciones de Ethereum en la versión anterior del protocolo, incluyendo:

• El modelo de una transacción por bloque.

• Códigos de operación personalizados para obtener información del bloque L1.

• Separa los campos de tarifa L1/L2 en la API JSON-RPC.

• Una representación ERC20 personalizada de los balances de ETH.

Bedrock también agrega soporte para EIP-1559, reorganizaciones en cadena y otras características de Ethereum presentes en L1.

Bedrock fue construido para ser modular y actualizable, para reutilizar el código existente de Ethereum, y para ser lo más cercano posible al 100% equivalente a Ethereum.

Bedrock también agrega soporte para EIP-1559, reorganizaciones en cadena y otras características de Ethereum presentes en L1.

Bedrock facilita el intercambio de diferentes componentes en la OP Stack, y agrega nuevas capacidades mediante el uso de interfaces, y esquemas de control de versiones bien definidos. Esto permite una arquitectura flexible que puede adaptarse a futuros desarrollos en el ecosistema Ethereum.

Ejemplos:

• Separación del nodo de rollup, y el cliente de ejecución.

• Diseño modular a prueba de fallas.

Bedrock utiliza la arquitectura y la infraestructura de Ethereum existentes lo más que pueda. Este enfoque permite que la OP Stack herede la seguridad, y los beneficios "lindy" de las bases de código probadas en batalla que se utilizan en la producción en Mainnet de Ethereum. Encontrará ejemplos de esto a lo largo del diseño, incluyendo:

Ejemplos:

• Clientes de ejecución modificados mínimamente.

• Contratos EVM en lugar de código de cliente precompilado.

Bedrock está diseñado para tener la máxima compatibilidad con la experiencia de desarrollador de Ethereum existente. Existen algunas excepciones debido a las diferencias fundamentales entre un L1 y un resumen: un modelo de tarifa alterado, un tiempo de bloqueo más rápido (2 s frente a 12 s) y un tipo de transacción especial para incluir transacciones de depósito L1.

Ejemplos:

• Prueba de fallas diseñada para probar fallas del cliente de ejecución de Ethereum mínimamente modificado.

• Reutilización de código del cliente de ejecución de Ethereum para uso de nodos en la red L2 y secuenciadores.

Los rollups se derivan de una fuente de disponibilidad de datos (generalmente una cadena de bloques L1 como Ethereum). En su configuración más común, los protocolos de rollup derivan una "cadena L2 canónica" de dos fuentes principales de información:

• Datos de transacciones publicados por secuenciadores en L1 y;

• Transacciones de depósito contabilizadas por cuentas y contratos a un contrato puente en L1.

Los siguientes son los componentes fundamentales del protocolo:

• Los depósitos son escritos en la cadena L2 canónica al interactuar directamente con los contratos inteligentes en la L1.

• Los retiros son escritos en la cadena L2 canónica que desencadenan implícitamente interacciones con contratos y cuentas en la L1.

• Los Batches son escritos de datos correspondientes a batches en el rollup.

• La derivación de bloques es cómo se interpretan las lecturas de datos en L1 para comprender la cadena L2 canónica.

• Los sistemas de prueba definen la finalidad de las roots de salida publicadas en la L1 de modo que puedan ejecutarse (por ejemplo, para ejecutar retiros).

Un depósito es una transacción en L1 que debe incluirse en el rollup. Los depósitos están garantizados por definición para ser incluidos en la cadena L2 canónica como un medio para evitar la censura o el control de la L2.

Una transacción depositada es la transacción en el rollup que se realiza como parte de un depósito. Con Bedrock, los depósitos son transacciones de Ethereum totalmente generalizadas. Por ejemplo, una cuenta o contrato en Ethereum puede "depositar" la creación de un contrato.

Bedrock define un contrato de depósito que está disponible en la L1: es un contrato inteligente con el que las cuentas y los contratos de la L1 pueden interactuar para escribir en la L2. Las transacciones depositadas en la L2, se derivan de los valores de los eventos emitidos por este contrato de depósito, que incluyen parámetros esperados como desde, hasta y datos.

Para obtener detalles completos, consulte la sección de contrato de depósito de las especificaciones del protocolo.

Bedrock también especifica un mecanismo de quema de gas y un mercado de tarifas para depósitos. El gas que gastan las transacciones depositadas en una L2 se compra en L1 a través de una quema de gas. Este gas se compra en un mercado de tarifa y existe un límite estricto en la cantidad de gas proporcionado a todos los depósitos en un solo bloque L1. Este mecanismo se utiliza para evitar ataques de denegación de servicio que podrían ocurrir al escribir transacciones en L2 desde L1 que son extremadamente intensivas en gas en L2, pero baratas en L1.

El gas proporcionado a las transacciones depositadas a veces se denomina "gas garantizado". El gas garantizado es único en el sentido de que se paga quemando gas en L1 y, por lo tanto, no es reembolsable. La cantidad total de gas L1 que se debe quemar por unidad de gas L2 garantizado solicitada depende del precio del gas L2, informado por un EIP-1559 Mecanismo de tarifa de estilo-. Además, los usuarios reciben un estipendio de gas dinámico basado en la cantidad de gas L1 gastado para calcular las actualizaciones del mecanismo de tarifas.

Para obtener una explicación más detallada, lea la sección de depósitos de las especificaciones del protocolo.

Los retiros son transacciones entre dominios que se inician en L2, y finalizan mediante una transacción ejecutada en L1. En particular, los retiros pueden ser utilizados por una cuenta L2 para llamar a un contrato L1 o para transferir ETH de una cuenta L2 a una cuenta L1.

Los retiros se inician en L2 a través de una llamada al contrato de implementación previa de Message Passer, que registra las propiedades importantes del mensaje en su almacenamiento. Los retiros se finalizan en L1 mediante una llamada al contrato OptimismPortal, que prueba la inclusión de este mensaje de retiro. De esta manera, los retiros son diferentes de los depósitos. En lugar de depender de la derivación de bloques, las transacciones de retiro deben usar contratos inteligentes en L1 para su finalización.

Los errores de validación de prueba de retiro han sido la causa raíz de muchos de los bridges hacks más grandes en los últimos años. El lanzamiento de Bedrock introduce un paso adicional en el proceso de retiro de versiones anteriores destinado a proporcionar una capa adicional de defensa contra este tipo de errores. En el proceso de retiro de dos pasos, se debe enviar una prueba de Merkle correspondiente al retiro 7 días antes de que se pueda finalizar el retiro. Este nuevo mecanismo de seguridad brinda a las herramientas de monitoreo 7 días completos para encontrar, y detectar pruebas de retiro no válidas. Si se determina que la prueba de retiro no es válida, se puede implementar una corrección de contrato antes de que se pierdan los fondos. Esto reduce drásticamente el riesgo de un bridge comprometido.

Para obtener detalles más completos, consulte la sección de retiros de la especificación del protocolo.

En Bedrock, se define un formato de conexión para la mensajería entre L1 y L2 (es decir, para que L2 derive bloques de L1 y para que L2 escriba transacciones en L1). Este formato de conexión está diseñado para minimizar los costos, y la complejidad del software para escribir en la L1.

Para optimizar la compresión de datos, las listas de transacciones L2 llamadas batches secuenciadores se organizan en grupos de objetos llamados canales, cada uno de los cuales tiene un tamaño máximo que se define en un parámetro configurable que inicialmente se establecerá en ~9.5Mb. Se espera que estos canales se compriman mediante una función de compresión y se envíen a L1.

Para paralelizar los mensajes de los secuenciadores que envían datos de canales comprimidos a L1, los canales se dividen aún más en los marcos de canales, que son fragmentos de datos de canales comprimidos que pueden caber dentro de una sola transacción de L1. Dado que los marcos de los canales son mutuamente independientes y se conoce el orden, las transacciones de Ethereum enviadas por el secuenciador a la L1 se pueden enviar en paralelo, lo que minimiza la complejidad del software del secuenciador, y permite llenar todo el espacio disponible para datos en la L1.

Bedrock elimina todo el gas de ejecución utilizado por el sistema L1 para enviar datos de canal a L1 en transacciones denominadas transacciones de batch. Toda la lógica de validación que sucedía anteriormente en los contratos inteligentes en la L1, se traslada a la lógica de derivación de bloques. En su lugar, las transacciones de batch se envían a un solo EOA en Ethereum denominado dirección de la bandeja de entrada del batch.

Los batches aún están sujetos a controles de validez (es decir, deben codificarse correctamente), al igual que las transacciones individuales dentro del batch (por ejemplo, las firmas deben ser válidas). Los batches no válidos, y las transacciones individuales no válidas dentro de un batch válido se consideran descartados e irrelevantes para el sistema.

Para obtener una explicación más detallada, lea las especificaciones de formato de conexión.

En Bedrock, el protocolo está diseñado para garantizar que se respete el tiempo de los depósitos en la L1 con respecto a la derivación de bloques de la cadena L2 canónica. Hacerlo es una función pura de los datos escritos en L1 por secuenciadores, depósitos y atributos de bloque L1. Para lograr esto, el protocolo define estrategias para garantizar la inclusión de depósitos, el manejo de las marcas de tiempo L1 y L2, y el procesamiento de ventanas de secuencia en una canalización para garantizar el orden correcto.

Un objetivo del protocolo de derivación de bloques es definirlo de tal manera que debe haber un bloque L2 cada número de segundos de "tiempo de bloque L2", y que la marca de tiempo de los bloques L2 permanece sincronizada con las marcas de tiempo de L1 (es decir, para garantizar que los depósitos están incluidos en un orden temporal lógico).

En Bedrock, se introduce el concepto de época de secuenciación: es un rango de bloques L2 derivados de un rango de bloques L1. Cada época se identifica mediante un número de época, que es igual al número de bloque del primer bloque L1 en la ventana de secuenciación. Las épocas pueden variar en tamaño, sujetas a algunas limitaciones.

La canalización de derivación por batches trata las marcas de tiempo de los bloques L1 asociados con el número de época como el punto de anclaje para determinar el orden de las transacciones en L2. El protocolo garantiza que, el primer bloque L2 de una época, nunca se retrase con respecto a la marca de tiempo del bloque L1 que coincide con la época. Los primeros bloques de una época deben contener depósitos en L1 para garantizar que se procesarán los depósitos.

Tenga en cuenta que la configuración objetivo para el tiempo de bloqueo en L2, en el lanzamiento de Bedrock, es de 2 segundos.

Bedrock intenta abordar el problema de conciliar las marcas de tiempo en L2 con las marcas de tiempo en L1 presentes en las transacciones depositadas. Lo hace al permitir una pequeña ventana de tiempo para que la secuencia aplique generosamente marcas de tiempo en transacciones L2 entre épocas.

Una ventana de secuenciación es una secuencia de bloques L1 a partir de la cual se puede derivar una época. Una ventana de secuenciación cuyo primer bloque L1 tiene el número “N” contiene transacciones de batch para la época “N”.

La ventana de secuenciación contiene bloques [N, N + SWS) donde “SWS” es el tamaño de la ventana del secuenciador: un parámetro de configuración de nivel de resumen fijo. Este parámetro debe ser al menos 2. Aumentarlo brinda más oportunidades para que los secuenciadores ordenen transacciones L2 con respecto a los depósitos, y reducirlo introduce ventanas de tiempo más estrictas para que los secuenciadores envíen transacciones de dosificador. Es una compensación entre la creación de oportunidades MEV y el aumento de la complejidad del software.

Una constante de protocolo llamada deriva máxima del secuenciador rige la marca de tiempo máxima que un bloque puede tener dentro de su época. Tener esta deriva permite que el secuenciador mantenga la vitalidad en caso de problemas temporales al conectarse a L1. La marca de tiempo de cada bloque L2 se ajusta al siguiente rango:

La cadena L2 canónica se puede procesar desde cero comenzando con el estado de génesis L2, configurando el inicio de la cadena L2 como la primera época y luego procesando todas las ventanas de secuenciación para determinar el orden correcto de los lotes y depósitos del secuenciador de acuerdo con lo siguiente simplificado tubería:

Notas de la etapa Leer desde L1 Las épocas están definidas por bloques L1. Dentro de un bloque L2 hay datos relacionados con las transacciones o depósitos del lote que deben incluirse en la cadena L2 canónica. Almacenamiento en búfer y decodificación en canales Los datos de los bloques L1 contienen tramas de canal no ordenadas, que deben recopilarse antes de reconstruirlas en canales. Descomprima los canales en lotes Dado que los canales se comprimen para minimizar los costos de las tarifas de datos en la L1, deben descomprimirse. Poner en cola los lotes en orden secuencial Con la información más reciente de L1, los lotes se pueden validar y procesar secuencialmente. Hay algunos matices sobre cuál es el orden correcto en relación con las épocas y las marcas de tiempo de L2, consulte la especificación completa aquí (se abre en una ventana nueva). Interpretar como bloques L2 En este punto, se puede determinar el orden correcto de los lotes.

Después de esto, el cliente de ejecución puede interpretarlos en bloques L2. Para obtener detalles de implementación relacionados con los clientes de ejecución, consulte la sección de la cola del motor (se abre en una ventana nueva) de las especificaciones del protocolo. #Pruebas de fallas Después de que un secuenciador procese uno o más bloques L2, las salidas calculadas a partir de la ejecución de transacciones en esos bloques deberán escribirse con L1 para la ejecución sin confianza de los mensajes L2 a L1, como los retiros.

En Bedrock, las salidas se codifican en forma de estructura de árbol, lo que minimiza el costo de probar cualquier dato capturado por las salidas. Los proponentes envían periódicamente raíces de salida que son raíces de Merkle de toda la cadena canónica L2 al L1.

Las actualizaciones futuras de OP Stack deben incluir una especificación para una variación de una prueba de fallas con vinculación incluida para crear incentivos para que los proponentes propongan raíces de salida correctas.

Para obtener detalles completos, lea la sección Propuestas de raíz de salida L2 (se abre en una ventana nueva) de las especificaciones del protocolo.

#Implementación Con Bedrock, OP Stack se apoya en gran medida en la separación técnica de preocupaciones especificada por Ethereum al reflejar la separación entre la capa de ejecución y la capa de consenso de Ethereum. Bedrock introduce la separación del cliente de ejecución y el nodo de resumen de la misma manera.

#Cliente de ejecución Un cliente de ejecución es el sistema que ejecutan los secuenciadores y otros tipos de operadores de nodos para determinar el estado de la cadena L2 canónica. También realiza otras funciones, como procesar transacciones entrantes y comunicarlas entre pares, y manejar el estado del sistema para procesar consultas en su contra.

Con Bedrock, OP Stack está diseñado para reutilizar las propias especificaciones del cliente de ejecución de Ethereum (se abre en una ventana nueva) y sus muchas implementaciones. En este lanzamiento, Bedrock ha demostrado una modificación extremadamente limitada de go-ethereum, el cliente de Ethereum más popular escrito en Go, a una diferencia de menos de 2000 líneas de código (se abre en una ventana nueva).

Hay dos razones fundamentales para tener alguna diferencia: manejar las transacciones depositadas y cobrar tarifas de transacción.

#Manejo de transacciones depositadas Para representar las transacciones depositadas en el resumen, se introdujo un tipo de transacción adicional. El cliente de ejecución implementa este nuevo tipo de transacción (se abre en una ventana nueva) de acuerdo con el estándar de transacciones tipeadas EIP-2718 (se abre en una ventana nueva).

#Cobro de tarifas de transacción Los rollups también tienen fundamentalmente dos tipos de tarifas asociadas con las transacciones:

Tarifas del secuenciador

El costo de operar un secuenciador se calcula utilizando la misma tabla de gases que Ethereum y con el mismo algoritmo EIP-1559 (se abre en una ventana nueva). Estas tarifas van al protocolo para operar secuenciadores y fluctúan según la congestión de la red.

Tarifas de disponibilidad de datos

Los costos de disponibilidad de datos están asociados con la escritura de transacciones de procesamiento por lotes en L1. Estas tarifas están destinadas a cubrir el costo que los secuenciadores deben pagar para enviar transacciones de procesamiento por lotes a la L1.

En Bedrock, la porción de disponibilidad de datos de la tarifa se determina en función de la información de un contrato de sistema en el resumen llamado GasPriceOracle (se abre en una ventana nueva). Este contrato se actualiza durante la derivación del bloque a partir de la información de precios del gas recuperada de los atributos del bloque L1 que se insertan al comienzo de cada época.

Bedrock especifica que ambas tarifas se suman en un solo campo gasPrice cuando se usa JSON-RPC.

#Nodo de resumen A diferencia de Ethereum, Bedrock no tiene un consenso de prueba de participación. En cambio, el consenso de la cadena L2 canónica se define por derivación de bloques. Un cliente de ejecución de OP Stack se comunica con un nuevo componente que implementa la derivación de bloques llamado nodo de resumen. Este nodo se comunica con el cliente de ejecución usando exactamente la misma API de motor (se abre en una ventana nueva) que usa Ethereum.

El nodo de resumen es un componente sin estado responsable de derivar el estado del sistema mediante la lectura de datos y depósitos en la L1. En Bedrock, un nodo de resumen puede usarse para secuenciar las transacciones entrantes de los usuarios u otros nodos de resumen o para verificar las transacciones confirmadas publicadas en L1 confiando singularmente en L1.

Los múltiples usos de un nodo de resumen se describen a continuación.

#Verificando la cadena L2 canónica El modo más simple de ejecutar un nodo de resumen es seguir solo la cadena L2 canónica. En este modo, el nodo de resumen no tiene pares y se usa estrictamente para leer datos de L1 e interpretarlos de acuerdo con las reglas del protocolo de derivación de bloques.

Uno de los propósitos de este tipo de nodo es verificar que las raíces de salida compartidas por otros nodos o publicadas en la L1 sean correctas de acuerdo con la definición del protocolo. Además, los proponentes que tengan la intención de enviar raíces de salida a la L1 pueden generar las raíces de salida que necesitan mediante el optimismo_outputAtBlock (se abre en una ventana nueva) del nodo que devuelve un hash de 32 bytes correspondiente a la raíz de salida L2.

Para este propósito, los nodos solo deberían necesitar seguir la cabeza finalizada. El término "finalizado" (se abre en una ventana nueva) se refiere al consenso de prueba de participación de Ethereum (es decir, canónico y prácticamente irreversible): el encabezado L2 finalizado es el encabezado de la cadena L2 canónica que se deriva solo de bloques L1 finalizados.

#Participando en la red L2 La forma más común de usar un nodo de resumen es participar en una red de otros nodos de resumen que rastrean la progresión y el estado de una L2. En este modo, un nodo de resumen lee los datos y los depósitos que observa desde la L1, los interpreta como bloques y acepta transacciones entrantes de usuarios y pares en una red de otros nodos de resumen.

Los nodos que participan en la red pueden hacer uso de los encabezados seguros e inseguros de la L2 que están sincronizando.

El encabezado L2 seguro representa el resumen que se puede construir donde cada bloque hasta el encabezado incluido se puede derivar completamente de la cadena L1 de referencia, antes de que L1 necesariamente haya finalizado (es decir, aún puede ocurrir una reorganización en L1). El encabezado L2 no seguro incluye bloques no seguros (se abre en una ventana nueva) que aún no se han derivado de L1. Estos bloqueos provienen de operar el nodo acumulativo como un secuenciador o de una sincronización no segura (se abre en una ventana nueva) con el secuenciador. Esto también se conoce como la cabeza "más reciente". El cabezal L2 seguro siempre se elige sobre el cabezal L2 inseguro en caso de desacuerdo. Cuando ocurren desacuerdos, la parte insegura de la cadena se reorganizará. Para la mayoría de los propósitos, los nodos en la red L2 se referirán al encabezado L2 inseguro para aplicaciones de usuario final.

#Secuenciación de transacciones La tercera forma de usar un nodo de resumen es secuenciar transacciones. En este modo, un nodo acumulativo creará nuevos bloques encima del encabezado L2 inseguro. Actualmente, solo hay un secuenciador por red OP Stack.

El secuenciador también es responsable de publicar lotes en L1 para que otros nodos de la red se sincronicen.

#dosificador El papel de un secuenciador es producir lotes. Para hacer esto, un secuenciador puede ejecutar nodos de resumen y tener procesos separados que realizan el procesamiento por lotes mediante la lectura de un nodo de resumen de confianza que ejecutan. Esto garantiza un componente adicional de OP Stack llamado dosificador (se abre en una ventana nueva) que lee datos de transacciones de un nodo de resumen y los interpreta en transacciones de dosificador para escribirlas en L1. El componente de procesamiento por lotes es responsable de leer el encabezado L2 inseguro de un nodo de resumen ejecutado por un secuenciador, crear transacciones de procesamiento por lotes y escribirlas en L1.

#Contratos puente estándar Bedrock también incluye un par de contratos puente utilizados para los tipos de depósitos más comunes llamados puentes estándar (se abre en una ventana nueva). Estos contratos envuelven los contratos de depósito y retiro para proporcionar interfaces simples para depositar y retirar tokens ETH y ERC-20.

Estos puentes están diseñados para involucrar un token nativo en un lado del puente y un token envuelto en el otro lado que puede gestionar la acuñación y la quema. Unir un token nativo implica bloquear el token nativo en un contrato y luego acuñar una cantidad equivalente de token minable en el otro lado del puente.

Para obtener detalles completos, consulte la sección puente estándar (se abre en una ventana nueva) de las especificaciones del protocolo.

#Cañón Aunque la construcción y verificación a prueba de fallas se implementa en el proyecto Cannon (se abre en una ventana nueva), la especificación del juego a prueba de fallas y la integración de un retador raíz de salida en el nodo acumulativo son parte de hitos de especificación posteriores.

#Otras lecturas #Especificación de protocolo La especificación del protocolo define los detalles técnicos del OP Stack. Es la fuente de información más actualizada sobre el funcionamiento interno del protocolo. La especificación del protocolo se encuentra en el monorepo de ethereum-optimism (se abre en una ventana nueva).

#Diferencias fundamentales Para profundizar en las diferencias entre Bedrock y las versiones anteriores del protocolo, consulte ¿En qué se diferencia Bedrock? página.

Esta es una traducción del artículo inicialmente publicado en inglés en el mirror oficial de Optimism.

To understand what is in the Bedrock release, keep reading. To develop on Optimism Mainnet, which will upgrade its infrastructure to the Bedrock release, read the docs. To contribute to the OP Stack, see the contribution guidelines on the ethereum-optimism monorepo. #Summary of Improvements

Bedrock es el nombre del primer lanzamiento oficial de la OP Stack, que es un conjunto de componentes modulares gratuitos, y de código abierto que trabajan juntos para potenciar Optimism.

• Para entender qué hay en el lanzamiento de Bedrock, sigue leyendo.

• Para desarrollar en el Optimism Mainnet, que actualizará su infraestructura al lanzamiento de Bedrock, lea los documentos.

• Para contribuir a la OP Stack, consulte las pautas de contribución en el monorepo de ethereum-optimism.

Bedrock mejora a su predecesor al reducir las tarifas de transacción utilizando compresión por lotes optimizada, y Ethereum como capa de disponibilidad de datos; acortando los retrasos de incluir transacciones L1 en rollups mediante el manejo de reorganizaciones L1 con más gracia; habilitando sistemas de prueba modulares a través de la reutilización de código; y mejorando el rendimiento de los nodos mediante la eliminación de la deuda técnica.

Además, Bedrock implementa una estrategia de compresión de datos optimizada para minimizar los costos de datos. Actualmente, estamos evaluando el impacto de este cambio, pero esperamos que reduzca significativamente las tarifas.

Bedrock también elimina todos los costos de gas asociados con la ejecución de EVM al enviar datos a L1. Esto reduce las tarifas en un 10% adicional con respecto a la versión anterior del protocolo.

Bedrock introduce soporte para reorganizaciones L1 en el software del nodo, lo que reduce significativamente la cantidad de tiempo que los usuarios deben esperar para los depósitos. Las versiones anteriores del protocolo podían tardar hasta 10 minutos en confirmar los depósitos. Con Bedrock, esperamos que los depósitos se confirmen en 3 minutos.

Bedrock abstrae el sistema de prueba de la OP Stack para que un resumen pueda usar una prueba de falla o una prueba de validez (por ejemplo, un zk-SNARK) para probar la ejecución correcta de las entradas en el resumen. Esta abstracción permite utilizar sistemas como Cannon (se abre en una ventana nueva) para probar fallas en el sistema.

Improved node performance

The node software performance has been significantly improved by enabling execution of several transactions in a single rollup "block" as opposed to the prior "one transaction per block" model in the previous version. This allows the cost of merkle trie updates to be amortized across multiple transactions. At current transaction volume, this reduces state growth by approximately 15GB/year.

Node performance is further improved by removing technical debt from the previous version of the protocol. This includes removing the need for a separate "data transport layer" node to index L1, and updating the node software to efficiently query for transaction data from L1.

El rendimiento del software del nodo se ha mejorado significativamente al permitir la ejecución de varias transacciones en un solo "bloque" del rollup en comparación con el modelo anterior de "una transacción por bloque" en la versión anterior. Esto permite que el costo de las actualizaciones de merkle trie se amortice en múltiples transacciones. Con el volumen de transacciones actual, esto reduce el crecimiento estatal en aproximadamente 15 GB/año.

El rendimiento del nodo se mejora aún más al eliminar la deuda técnica de la versión anterior del protocolo. Esto incluye eliminar la necesidad de un nodo de "layer de transporte de datos" separado para indexar L1, y actualizar el software del nodo para consultar de manera eficiente los datos de transacción de L1.

Bedrock fue diseñado desde cero para estar lo más cerca posible de Ethereum. Se han eliminado múltiples desviaciones de Ethereum en la versión anterior del protocolo, incluyendo:

• El modelo de una transacción por bloque.

• Códigos de operación personalizados para obtener información del bloque L1.

• Separa los campos de tarifa L1/L2 en la API JSON-RPC.

• Una representación ERC20 personalizada de los balances de ETH.

Bedrock también agrega soporte para EIP-1559, reorganizaciones en cadena y otras características de Ethereum presentes en L1.

Bedrock fue construido para ser modular y actualizable, para reutilizar el código existente de Ethereum, y para ser lo más cercano posible al 100% equivalente a Ethereum.

Bedrock también agrega soporte para EIP-1559, reorganizaciones en cadena y otras características de Ethereum presentes en L1.

Bedrock facilita el intercambio de diferentes componentes en la OP Stack, y agrega nuevas capacidades mediante el uso de interfaces, y esquemas de control de versiones bien definidos. Esto permite una arquitectura flexible que puede adaptarse a futuros desarrollos en el ecosistema Ethereum.

Ejemplos:

• Separación del nodo de rollup, y el cliente de ejecución.

• Diseño modular a prueba de fallas.

Bedrock utiliza la arquitectura y la infraestructura de Ethereum existentes lo más que pueda. Este enfoque permite que la OP Stack herede la seguridad, y los beneficios "lindy" de las bases de código probadas en batalla que se utilizan en la producción en Mainnet de Ethereum. Encontrará ejemplos de esto a lo largo del diseño, incluyendo:

Ejemplos:

• Clientes de ejecución modificados mínimamente.

• Contratos EVM en lugar de código de cliente precompilado.

Bedrock está diseñado para tener la máxima compatibilidad con la experiencia de desarrollador de Ethereum existente. Existen algunas excepciones debido a las diferencias fundamentales entre un L1 y un resumen: un modelo de tarifa alterado, un tiempo de bloqueo más rápido (2 s frente a 12 s) y un tipo de transacción especial para incluir transacciones de depósito L1.

Ejemplos:

• Prueba de fallas diseñada para probar fallas del cliente de ejecución de Ethereum mínimamente modificado.

• Reutilización de código del cliente de ejecución de Ethereum para uso de nodos en la red L2 y secuenciadores.

Los rollups se derivan de una fuente de disponibilidad de datos (generalmente una cadena de bloques L1 como Ethereum). En su configuración más común, los protocolos de rollup derivan una "cadena L2 canónica" de dos fuentes principales de información:

• Datos de transacciones publicados por secuenciadores en L1 y;

• Transacciones de depósito contabilizadas por cuentas y contratos a un contrato puente en L1.

Los siguientes son los componentes fundamentales del protocolo:

• Los depósitos son escritos en la cadena L2 canónica al interactuar directamente con los contratos inteligentes en la L1.

• Los retiros son escritos en la cadena L2 canónica que desencadenan implícitamente interacciones con contratos y cuentas en la L1.

• Los Batches son escritos de datos correspondientes a batches en el rollup.

• La derivación de bloques es cómo se interpretan las lecturas de datos en L1 para comprender la cadena L2 canónica.

• Los sistemas de prueba definen la finalidad de las roots de salida publicadas en la L1 de modo que puedan ejecutarse (por ejemplo, para ejecutar retiros).

Un depósito es una transacción en L1 que debe incluirse en el rollup. Los depósitos están garantizados por definición para ser incluidos en la cadena L2 canónica como un medio para evitar la censura o el control de la L2.

Una transacción depositada es la transacción en el rollup que se realiza como parte de un depósito. Con Bedrock, los depósitos son transacciones de Ethereum totalmente generalizadas. Por ejemplo, una cuenta o contrato en Ethereum puede "depositar" la creación de un contrato.

Bedrock define un contrato de depósito que está disponible en la L1: es un contrato inteligente con el que las cuentas y los contratos de la L1 pueden interactuar para escribir en la L2. Las transacciones depositadas en la L2, se derivan de los valores de los eventos emitidos por este contrato de depósito, que incluyen parámetros esperados como desde, hasta y datos.

Para obtener detalles completos, consulte la sección de contrato de depósito de las especificaciones del protocolo.

Bedrock también especifica un mecanismo de quema de gas y un mercado de tarifas para depósitos. El gas que gastan las transacciones depositadas en una L2 se compra en L1 a través de una quema de gas. Este gas se compra en un mercado de tarifa y existe un límite estricto en la cantidad de gas proporcionado a todos los depósitos en un solo bloque L1. Este mecanismo se utiliza para evitar ataques de denegación de servicio que podrían ocurrir al escribir transacciones en L2 desde L1 que son extremadamente intensivas en gas en L2, pero baratas en L1.

El gas proporcionado a las transacciones depositadas a veces se denomina "gas garantizado". El gas garantizado es único en el sentido de que se paga quemando gas en L1 y, por lo tanto, no es reembolsable. La cantidad total de gas L1 que se debe quemar por unidad de gas L2 garantizado solicitada depende del precio del gas L2, informado por un EIP-1559 Mecanismo de tarifa de estilo-. Además, los usuarios reciben un estipendio de gas dinámico basado en la cantidad de gas L1 gastado para calcular las actualizaciones del mecanismo de tarifas.

Para obtener una explicación más detallada, lea la sección de depósitos de las especificaciones del protocolo.

Los retiros son transacciones entre dominios que se inician en L2, y finalizan mediante una transacción ejecutada en L1. En particular, los retiros pueden ser utilizados por una cuenta L2 para llamar a un contrato L1 o para transferir ETH de una cuenta L2 a una cuenta L1.

Los retiros se inician en L2 a través de una llamada al contrato de implementación previa de Message Passer, que registra las propiedades importantes del mensaje en su almacenamiento. Los retiros se finalizan en L1 mediante una llamada al contrato OptimismPortal, que prueba la inclusión de este mensaje de retiro. De esta manera, los retiros son diferentes de los depósitos. En lugar de depender de la derivación de bloques, las transacciones de retiro deben usar contratos inteligentes en L1 para su finalización.

Los errores de validación de prueba de retiro han sido la causa raíz de muchos de los bridges hacks más grandes en los últimos años. El lanzamiento de Bedrock introduce un paso adicional en el proceso de retiro de versiones anteriores destinado a proporcionar una capa adicional de defensa contra este tipo de errores. En el proceso de retiro de dos pasos, se debe enviar una prueba de Merkle correspondiente al retiro 7 días antes de que se pueda finalizar el retiro. Este nuevo mecanismo de seguridad brinda a las herramientas de monitoreo 7 días completos para encontrar, y detectar pruebas de retiro no válidas. Si se determina que la prueba de retiro no es válida, se puede implementar una corrección de contrato antes de que se pierdan los fondos. Esto reduce drásticamente el riesgo de un bridge comprometido.

Para obtener detalles más completos, consulte la sección de retiros de la especificación del protocolo.

En Bedrock, se define un formato de conexión para la mensajería entre L1 y L2 (es decir, para que L2 derive bloques de L1 y para que L2 escriba transacciones en L1). Este formato de conexión está diseñado para minimizar los costos, y la complejidad del software para escribir en la L1.

Para optimizar la compresión de datos, las listas de transacciones L2 llamadas batches secuenciadores se organizan en grupos de objetos llamados canales, cada uno de los cuales tiene un tamaño máximo que se define en un parámetro configurable que inicialmente se establecerá en ~9.5Mb. Se espera que estos canales se compriman mediante una función de compresión y se envíen a L1.

Para paralelizar los mensajes de los secuenciadores que envían datos de canales comprimidos a L1, los canales se dividen aún más en los marcos de canales, que son fragmentos de datos de canales comprimidos que pueden caber dentro de una sola transacción de L1. Dado que los marcos de los canales son mutuamente independientes y se conoce el orden, las transacciones de Ethereum enviadas por el secuenciador a la L1 se pueden enviar en paralelo, lo que minimiza la complejidad del software del secuenciador, y permite llenar todo el espacio disponible para datos en la L1.

Bedrock elimina todo el gas de ejecución utilizado por el sistema L1 para enviar datos de canal a L1 en transacciones denominadas transacciones de batch. Toda la lógica de validación que sucedía anteriormente en los contratos inteligentes en la L1, se traslada a la lógica de derivación de bloques. En su lugar, las transacciones de batch se envían a un solo EOA en Ethereum denominado dirección de la bandeja de entrada del batch.

Los batches aún están sujetos a controles de validez (es decir, deben codificarse correctamente), al igual que las transacciones individuales dentro del batch (por ejemplo, las firmas deben ser válidas). Los batches no válidos, y las transacciones individuales no válidas dentro de un batch válido se consideran descartados e irrelevantes para el sistema.

Para obtener una explicación más detallada, lea las especificaciones de formato de conexión.

En Bedrock, el protocolo está diseñado para garantizar que se respete el tiempo de los depósitos en la L1 con respecto a la derivación de bloques de la cadena L2 canónica. Hacerlo es una función pura de los datos escritos en L1 por secuenciadores, depósitos y atributos de bloque L1. Para lograr esto, el protocolo define estrategias para garantizar la inclusión de depósitos, el manejo de las marcas de tiempo L1 y L2, y el procesamiento de ventanas de secuencia en una canalización para garantizar el orden correcto.

Un objetivo del protocolo de derivación de bloques es definirlo de tal manera que debe haber un bloque L2 cada número de segundos de "tiempo de bloque L2", y que la marca de tiempo de los bloques L2 permanece sincronizada con las marcas de tiempo de L1 (es decir, para garantizar que los depósitos están incluidos en un orden temporal lógico).

En Bedrock, se introduce el concepto de época de secuenciación: es un rango de bloques L2 derivados de un rango de bloques L1. Cada época se identifica mediante un número de época, que es igual al número de bloque del primer bloque L1 en la ventana de secuenciación. Las épocas pueden variar en tamaño, sujetas a algunas limitaciones.

La canalización de derivación por batches trata las marcas de tiempo de los bloques L1 asociados con el número de época como el punto de anclaje para determinar el orden de las transacciones en L2. El protocolo garantiza que, el primer bloque L2 de una época, nunca se retrase con respecto a la marca de tiempo del bloque L1 que coincide con la época. Los primeros bloques de una época deben contener depósitos en L1 para garantizar que se procesarán los depósitos.

Tenga en cuenta que la configuración objetivo para el tiempo de bloqueo en L2, en el lanzamiento de Bedrock, es de 2 segundos.

Bedrock intenta abordar el problema de conciliar las marcas de tiempo en L2 con las marcas de tiempo en L1 presentes en las transacciones depositadas. Lo hace al permitir una pequeña ventana de tiempo para que la secuencia aplique generosamente marcas de tiempo en transacciones L2 entre épocas.

Una ventana de secuenciación es una secuencia de bloques L1 a partir de la cual se puede derivar una época. Una ventana de secuenciación cuyo primer bloque L1 tiene el número “N” contiene transacciones de batch para la época “N”.

La ventana de secuenciación contiene bloques [N, N + SWS) donde “SWS” es el tamaño de la ventana del secuenciador: un parámetro de configuración de nivel de resumen fijo. Este parámetro debe ser al menos 2. Aumentarlo brinda más oportunidades para que los secuenciadores ordenen transacciones L2 con respecto a los depósitos, y reducirlo introduce ventanas de tiempo más estrictas para que los secuenciadores envíen transacciones de dosificador. Es una compensación entre la creación de oportunidades MEV y el aumento de la complejidad del software.

Una constante de protocolo llamada deriva máxima del secuenciador rige la marca de tiempo máxima que un bloque puede tener dentro de su época. Tener esta deriva permite que el secuenciador mantenga la vitalidad en caso de problemas temporales al conectarse a L1. La marca de tiempo de cada bloque L2 se ajusta al siguiente rango:

La cadena L2 canónica se puede procesar desde cero comenzando con el estado de génesis L2, configurando el inicio de la cadena L2 como la primera época y luego procesando todas las ventanas de secuenciación para determinar el orden correcto de los lotes y depósitos del secuenciador de acuerdo con lo siguiente simplificado tubería:

Notas de la etapa Leer desde L1 Las épocas están definidas por bloques L1. Dentro de un bloque L2 hay datos relacionados con las transacciones o depósitos del lote que deben incluirse en la cadena L2 canónica. Almacenamiento en búfer y decodificación en canales Los datos de los bloques L1 contienen tramas de canal no ordenadas, que deben recopilarse antes de reconstruirlas en canales. Descomprima los canales en lotes Dado que los canales se comprimen para minimizar los costos de las tarifas de datos en la L1, deben descomprimirse. Poner en cola los lotes en orden secuencial Con la información más reciente de L1, los lotes se pueden validar y procesar secuencialmente. Hay algunos matices sobre cuál es el orden correcto en relación con las épocas y las marcas de tiempo de L2, consulte la especificación completa aquí (se abre en una ventana nueva). Interpretar como bloques L2 En este punto, se puede determinar el orden correcto de los lotes.

Después de esto, el cliente de ejecución puede interpretarlos en bloques L2. Para obtener detalles de implementación relacionados con los clientes de ejecución, consulte la sección de la cola del motor (se abre en una ventana nueva) de las especificaciones del protocolo. #Pruebas de fallas Después de que un secuenciador procese uno o más bloques L2, las salidas calculadas a partir de la ejecución de transacciones en esos bloques deberán escribirse con L1 para la ejecución sin confianza de los mensajes L2 a L1, como los retiros.

En Bedrock, las salidas se codifican en forma de estructura de árbol, lo que minimiza el costo de probar cualquier dato capturado por las salidas. Los proponentes envían periódicamente raíces de salida que son raíces de Merkle de toda la cadena canónica L2 al L1.

Las actualizaciones futuras de OP Stack deben incluir una especificación para una variación de una prueba de fallas con vinculación incluida para crear incentivos para que los proponentes propongan raíces de salida correctas.

Para obtener detalles completos, lea la sección Propuestas de raíz de salida L2 (se abre en una ventana nueva) de las especificaciones del protocolo.

#Implementación Con Bedrock, OP Stack se apoya en gran medida en la separación técnica de preocupaciones especificada por Ethereum al reflejar la separación entre la capa de ejecución y la capa de consenso de Ethereum. Bedrock introduce la separación del cliente de ejecución y el nodo de resumen de la misma manera.

#Cliente de ejecución Un cliente de ejecución es el sistema que ejecutan los secuenciadores y otros tipos de operadores de nodos para determinar el estado de la cadena L2 canónica. También realiza otras funciones, como procesar transacciones entrantes y comunicarlas entre pares, y manejar el estado del sistema para procesar consultas en su contra.

Con Bedrock, OP Stack está diseñado para reutilizar las propias especificaciones del cliente de ejecución de Ethereum (se abre en una ventana nueva) y sus muchas implementaciones. En este lanzamiento, Bedrock ha demostrado una modificación extremadamente limitada de go-ethereum, el cliente de Ethereum más popular escrito en Go, a una diferencia de menos de 2000 líneas de código (se abre en una ventana nueva).

Hay dos razones fundamentales para tener alguna diferencia: manejar las transacciones depositadas y cobrar tarifas de transacción.

#Manejo de transacciones depositadas Para representar las transacciones depositadas en el resumen, se introdujo un tipo de transacción adicional. El cliente de ejecución implementa este nuevo tipo de transacción (se abre en una ventana nueva) de acuerdo con el estándar de transacciones tipeadas EIP-2718 (se abre en una ventana nueva).

#Cobro de tarifas de transacción Los rollups también tienen fundamentalmente dos tipos de tarifas asociadas con las transacciones:

Tarifas del secuenciador

El costo de operar un secuenciador se calcula utilizando la misma tabla de gases que Ethereum y con el mismo algoritmo EIP-1559 (se abre en una ventana nueva). Estas tarifas van al protocolo para operar secuenciadores y fluctúan según la congestión de la red.

Tarifas de disponibilidad de datos

Los costos de disponibilidad de datos están asociados con la escritura de transacciones de procesamiento por lotes en L1. Estas tarifas están destinadas a cubrir el costo que los secuenciadores deben pagar para enviar transacciones de procesamiento por lotes a la L1.

En Bedrock, la porción de disponibilidad de datos de la tarifa se determina en función de la información de un contrato de sistema en el resumen llamado GasPriceOracle (se abre en una ventana nueva). Este contrato se actualiza durante la derivación del bloque a partir de la información de precios del gas recuperada de los atributos del bloque L1 que se insertan al comienzo de cada época.

Bedrock especifica que ambas tarifas se suman en un solo campo gasPrice cuando se usa JSON-RPC.

#Nodo de resumen A diferencia de Ethereum, Bedrock no tiene un consenso de prueba de participación. En cambio, el consenso de la cadena L2 canónica se define por derivación de bloques. Un cliente de ejecución de OP Stack se comunica con un nuevo componente que implementa la derivación de bloques llamado nodo de resumen. Este nodo se comunica con el cliente de ejecución usando exactamente la misma API de motor (se abre en una ventana nueva) que usa Ethereum.

El nodo de resumen es un componente sin estado responsable de derivar el estado del sistema mediante la lectura de datos y depósitos en la L1. En Bedrock, un nodo de resumen puede usarse para secuenciar las transacciones entrantes de los usuarios u otros nodos de resumen o para verificar las transacciones confirmadas publicadas en L1 confiando singularmente en L1.

Los múltiples usos de un nodo de resumen se describen a continuación.

#Verificando la cadena L2 canónica El modo más simple de ejecutar un nodo de resumen es seguir solo la cadena L2 canónica. En este modo, el nodo de resumen no tiene pares y se usa estrictamente para leer datos de L1 e interpretarlos de acuerdo con las reglas del protocolo de derivación de bloques.

Uno de los propósitos de este tipo de nodo es verificar que las raíces de salida compartidas por otros nodos o publicadas en la L1 sean correctas de acuerdo con la definición del protocolo. Además, los proponentes que tengan la intención de enviar raíces de salida a la L1 pueden generar las raíces de salida que necesitan mediante el optimismo_outputAtBlock (se abre en una ventana nueva) del nodo que devuelve un hash de 32 bytes correspondiente a la raíz de salida L2.

Para este propósito, los nodos solo deberían necesitar seguir la cabeza finalizada. El término "finalizado" (se abre en una ventana nueva) se refiere al consenso de prueba de participación de Ethereum (es decir, canónico y prácticamente irreversible): el encabezado L2 finalizado es el encabezado de la cadena L2 canónica que se deriva solo de bloques L1 finalizados.

#Participando en la red L2 La forma más común de usar un nodo de resumen es participar en una red de otros nodos de resumen que rastrean la progresión y el estado de una L2. En este modo, un nodo de resumen lee los datos y los depósitos que observa desde la L1, los interpreta como bloques y acepta transacciones entrantes de usuarios y pares en una red de otros nodos de resumen.

Los nodos que participan en la red pueden hacer uso de los encabezados seguros e inseguros de la L2 que están sincronizando.

El encabezado L2 seguro representa el resumen que se puede construir donde cada bloque hasta el encabezado incluido se puede derivar completamente de la cadena L1 de referencia, antes de que L1 necesariamente haya finalizado (es decir, aún puede ocurrir una reorganización en L1). El encabezado L2 no seguro incluye bloques no seguros (se abre en una ventana nueva) que aún no se han derivado de L1. Estos bloqueos provienen de operar el nodo acumulativo como un secuenciador o de una sincronización no segura (se abre en una ventana nueva) con el secuenciador. Esto también se conoce como la cabeza "más reciente". El cabezal L2 seguro siempre se elige sobre el cabezal L2 inseguro en caso de desacuerdo. Cuando ocurren desacuerdos, la parte insegura de la cadena se reorganizará. Para la mayoría de los propósitos, los nodos en la red L2 se referirán al encabezado L2 inseguro para aplicaciones de usuario final.

#Secuenciación de transacciones La tercera forma de usar un nodo de resumen es secuenciar transacciones. En este modo, un nodo acumulativo creará nuevos bloques encima del encabezado L2 inseguro. Actualmente, solo hay un secuenciador por red OP Stack.

El secuenciador también es responsable de publicar lotes en L1 para que otros nodos de la red se sincronicen.

#dosificador El papel de un secuenciador es producir lotes. Para hacer esto, un secuenciador puede ejecutar nodos de resumen y tener procesos separados que realizan el procesamiento por lotes mediante la lectura de un nodo de resumen de confianza que ejecutan. Esto garantiza un componente adicional de OP Stack llamado dosificador (se abre en una ventana nueva) que lee datos de transacciones de un nodo de resumen y los interpreta en transacciones de dosificador para escribirlas en L1. El componente de procesamiento por lotes es responsable de leer el encabezado L2 inseguro de un nodo de resumen ejecutado por un secuenciador, crear transacciones de procesamiento por lotes y escribirlas en L1.

#Contratos puente estándar Bedrock también incluye un par de contratos puente utilizados para los tipos de depósitos más comunes llamados puentes estándar (se abre en una ventana nueva). Estos contratos envuelven los contratos de depósito y retiro para proporcionar interfaces simples para depositar y retirar tokens ETH y ERC-20.

Estos puentes están diseñados para involucrar un token nativo en un lado del puente y un token envuelto en el otro lado que puede gestionar la acuñación y la quema. Unir un token nativo implica bloquear el token nativo en un contrato y luego acuñar una cantidad equivalente de token minable en el otro lado del puente.

Para obtener detalles completos, consulte la sección puente estándar (se abre en una ventana nueva) de las especificaciones del protocolo.

#Cañón Aunque la construcción y verificación a prueba de fallas se implementa en el proyecto Cannon (se abre en una ventana nueva), la especificación del juego a prueba de fallas y la integración de un retador raíz de salida en el nodo acumulativo son parte de hitos de especificación posteriores.

#Otras lecturas #Especificación de protocolo La especificación del protocolo define los detalles técnicos del OP Stack. Es la fuente de información más actualizada sobre el funcionamiento interno del protocolo. La especificación del protocolo se encuentra en el monorepo de ethereum-optimism (se abre en una ventana nueva).

#Diferencias fundamentales Para profundizar en las diferencias entre Bedrock y las versiones anteriores del protocolo, consulte ¿En qué se diferencia Bedrock? página.