Arquitectura de Optimism
Optimism es un protocolo de rollup optimista equivalente a EVM diseñado para escalar Ethereum. Escalar Ethereum significa aumentar la cantidad de transacciones útiles que la red Ethereum puede procesar. Un rollup optimista es una técnica de escalabilidad de capa 2 que incrementa la capacidad de cómputo y almacenamiento de Ethereum sin sacrificar seguridad ni descentralización. La equivalencia EVM es el cumplimiento total con la función de transición de estado descrita en el yellow paper de Ethereum, la definición formal del protocolo.
El rollup optimista funciona agrupando múltiples transacciones en una sola transacción, que luego es verificada por un contrato inteligente en la red Ethereum. Este proceso se llama “rolling up” porque las transacciones individuales se combinan en una transacción mayor que se envía a la red Ethereum. El término “optimista” se refiere al hecho de que el sistema asume que las transacciones son válidas a menos que se demuestre lo contrario, lo que permite un procesamiento más rápido y eficiente.
Arquitectura General
.png "Arquitectura de Optimism")
op-node + op-geth
El nodo rollup puede ejecutarse en modo validador o secuenciador:
- validador (también llamado verificador): Similar a ejecutar un nodo Ethereum, simula las transacciones L2 localmente, sin limitación de velocidad. También permite al validador verificar el trabajo del secuenciador, al volver a derivar los output roots y compararlos con los enviados por el secuenciador. En caso de discrepancia, el validador puede ejecutar una prueba de falla.
- secuenciador: El secuenciador es un actor privilegiado que recibe transacciones L2 de los usuarios L2, crea bloques L2 en consecuencia y luego los envía al proveedor de disponibilidad de datos (a través de un batcher). También envía los output roots a L1. Actualmente solo hay un secuenciador en toda la pila, y es aquí donde se critica que la stack de OP no esté descentralizada.
op-batcher
El batcher, también llamado batch submitter, es la entidad que envía los datos del secuenciador L2 a L1, para ponerlos a disposición de los verificadores.
op-proposer
El proponente genera y envía puntos de control de salida L2 al contrato oracle de salida L2 en Ethereum. Después de que pase el período de finalización, estos datos habilitan los retiros.
Tanto el batcher como el proposer envían estados a L1. ¿Por qué están separados?
El batcher recopila y envía los datos de transacciones a L1 en lotes, mientras que el proposer envía los compromisos (output roots) al estado de L2, lo que finaliza la vista de los estados de cuenta de L2. Están desacoplados para poder trabajar en paralelo y mejorar la eficiencia.
contracts-bedrock
Varios contratos para que L2 interactúe con L1:
- OptimismPortal: Un flujo de transacciones L2 que se originan como llamadas a contratos inteligentes en el estado de L1.
- Batch inbox: Una dirección L1 a la que el Batch Submitter envía lotes de transacciones.
- L2 output oracle: Un contrato inteligente que almacena los output roots de L2 para su uso en retiros y pruebas de falla.
¿Cómo depositar?
¿Cómo retirar?
Comentarios sobre la documentación de Optimism
Entender la stack de OP puede ser desafiante debido a varios factores. Uno de ellos es la gran cantidad de componentes que se mencionan múltiples veces con nombres ligeramente diferentes en el código y la documentación. Por ejemplo, los términos “op-batcher” y “batch‑submitter” o “verifiers” y “validators” pueden usarse indistintamente, lo que genera confusión y dificulta comprender la función exacta de cada componente.
Otro reto al comprender la stack de OP es la arquitectura en evolución, que puede hacer que algunos elementos de diseño queden obsoletos con el tiempo. Desafortunadamente, la documentación no siempre se actualiza para reflejar estos cambios, lo que puede generar más confusión al trabajar con información desactualizada o inexacta.
Para superar estos desafíos, es importante revisar cuidadosamente toda la documentación disponible, mantener la consistencia de conceptos en todos los lugares y mantenerse al día con cualquier cambio o actualización de la stack de OP. Esto puede requerir investigación adicional y colaboración con otros usuarios o desarrolladores, pero es esencial para comprender plenamente y utilizar eficazmente este complejo sistema.