¿Cómo escala Ethereum a través de soluciones de layer 2?
En la layer 1 de Ethereum (layer de la blockchain en donde se asientan las transacciones finalizadas) la alta demanda viene conduciendo a transacciones más lentas y precios del gas inviables. El objetivo principal de escalar la red es reducir los costos del gas y aumentar el throughput (transacciones por segundo) pero sin sacrificar la descentralización ni la seguridad de L1.
Los rollups son soluciones de layer 2 que ejecutan las transacciones off chain (se implementan por separado de la layer 1; no requieren cambios en el protocolo Ethereum) pero llevan los datos de las transacciones a la layer 1. Como los datos de las transacciones se asientan sobre la layer 1, esto permite que compartan la misma seguridad.
Ya que el poder de cómputo (costo de realizar cálculos computacionales para la ejecución de smart contracts) es la parte más lenta y costosa del uso de Ethereum, y esto se realiza off chain, permite escalar la red mejorando las TPS (transacciones por segundo) y reduciendo el costo del gas.
Caracteristicas de un Rollup:
- Ejecución de la transacción off chain
- Los datos o ‘proof of transactions’ (prueba de validez de las transacciones en L2) se asientan sobre la layer 1.
os rollups requieren que los ‘operadores’ (validadores en PoS, mineros en PoW) bloqueen un depósito en garantía en el Rollup, el cual es susceptible de ser removido si actúan maliciosamente. Esto incentiva a los operadores a verificar y ejecutar transacciones correctamente.
Zero Knowledge Rollups
Una prueba de conocimiento cero (ZK proofs) demuestra que alguien posee la veracidad de una información a otra persona sin revelar la información en sí. A través de las matemáticas, el probador puede demostrar que posee la información correcta sin necesidad de revelarla al verificador. Esto es importante porque el hecho de no compartir la información, significa que no se puede robar.
El t?rmino ‘Zero Knowledge’ (conocimiento cero) se origina en el hecho de que no se revela ninguna información para realizar la verificación de los datos.
¿Cómo funciona?
Las transacciones se agrupan juntas, luego se firman y se envían al Layer 1 (Ethereum). Por lo tanto, se reduce la cantidad de datos almacenados en Ethereum. Todas las firmas se reemplazan por una prueba de conocimiento cero conocida como SNARK, que permite la compresión de las transacciones agregadas.
Créditos a Finematics por la imagen.
Modelo de seguridad en ZK Rollups
- Validity proof (prueba de validez): Un modelo de seguridad donde, para aumentar la velocidad, las transacciones se agrupan y se envían a Ethereum en una sola transacción. La transacción se realiza off chain y luego se envía a la main chain con una prueba de su validez. Este método aumenta la cantidad de transacciones posibles mientras mantiene la seguridad de la layer 1.
- SNARK: son pruebas criptográficas de validez con las que se puede probar la posesión de cierta información (una clave secreta, por ejemplo), sin revelar esa información, y sin ninguna interacción entre el probador y el verificador. Esta prueba criptográfica se asienta sobre la layer 1 en representación de todas las transacciones agrupadas en el ZK-Rollup.
Un SNARK incluye una prueba de validez para cada transacción que se incluye en un bloque.
Con los SNARKS es imposible que los retransmisores envíen información no válida o incorrecta. El SNARK prueba que la serie de transacciones enviadas, fueron correctamente firmadas por los propietarios y que las actualizaciones de los saldos de las cuentas son correctas.
Una vez que se envía una prueba de validez a la main chain y se verifica mediante el smart contract del Rollup, todas las transacciones en el bloque se finalizan y conllevan las mismas garantías de seguridad que las transacciones en la L1 de Ethereum.
El smart contract del ZK-rollup mantiene el estado de todas las transferencias en la layer 2, y este estado solo se puede actualizar con una prueba de validez. Esto significa que solo es necesaria la prueba de validez, en lugar de todos los datos de todas las transacciones.
No hay retrasos al mover fondos de la layer 2 a la layer 1 porque una prueba de validez aceptada por el contrato del ZK-Rollup ya ha verificado correctamente los fondos.
Ejemplo: La cueva de Alí Babá
Un ejemplo muy simple de este concepto se puede ver con la cueva de Ali Baba, que es una cueva circular con una entrada y una puerta que sella el túnel en la parte trasera de la cueva.
Alice quiere demostrarle a Bob que posee la llave secreta que abre la puerta de la cueva de Alí Babá, pero no quiere mostrársela. Para esto Alice y Bob van hacia la cueva. Ambos caminos en la cueva se comunican sólo a través de la puerta mágica.
1) Alice entra a la cueva por A o por B, mientras que Bob se queda esperando en la salida de la cueva.
2) Bob elije que Alice salga por A o por B
3) Si Alice tiene la llave que abre la puerta, puede salir por el lado que Bob le solicitó.
- Esto reduce a 50% las probabilidades de que Alice haya elegido en un primer intento el camino solicitado por Bob.
- La repetición de este esquema en varias ocasiones sirve entonces, para determinar que realmente Alice tiene la llave secreta para abrir la puerta, pero en ningún momento se la reveló a Bob.
Optimistic Rollups
Corre una EVM (Ethereum Virtual Machine) llamada OVM (Optimistic Virtual Machine) que permite ejecutar los mismos smart contracts que en la layer 1. Esto es importante ya que permite a las aplicaciones ya existentes conservar su composabilidad, dado que los smart contracts en Ethereum son públicos, los desarrolladores no necesitan escribir nuevamente el smart contract, solo necesitan saber interactuar con los ya existentes para deployar uno nuevo en la OVM.
Todos los fondos en un Rollup se mantienen mediante un solo smart contract, en el que los secuenciadores dejan un depósito en garantía que puede removerse si actúan maliciosamente. Se opera bajo el supuesto de que todos actúan de manera ética y correcta, pero se incluye una alternativa en caso de que llegue una parte malintencionada.
En un Optimistic Rollup, el nuevo state root es publicado por los secuenciadores sin ser verificado cada vez por el smart contract del Rollup. En cambio, todos esperan que la transición del estado sea correcta. Sin embargo, si se publica una transición de estado incorrecta, los verificadores o usuarios (que deben observar lo que está sucediendo en la layer 1 del Rollup, ejecutando cada transacción) podrán apuntar a la transacción no válida y revertir el bloqueo incorrecto (ganando recompensas por ello), reduciendo drásticamente a los operadores maliciosos.
El propósito de esto es simple: permite que un nodo teniendo solamente el último bloque, junto con cierta seguridad de que el último bloque es en realidad el bloque más reciente, se “sincronice” con la blockchain rápidamente sin verificar ninguna transacción histórica.
Conceptos a tener en cuenta:
State root: el hash raíz que almacena todo el estado del sistema de la blockchain: todos los saldos de cuenta, almacenamiento de contrato y código de contrato están adentro. Es de utilidad para verificar la autenticidad de los datos recibidos.
Fraud Proof (prueba de fraude): las transacciones en los OR se asume que son válidas, pero pueden cancelarse si se sospecha de fraude. Si esto sucede, una prueba de fraude ejecutará la transacción nuevamente para corroborar si ocurrió el fraude.
Secuenciador: Son responsables de almacenar y ejecutar las transacciones enviadas por los usuarios. Deben enviar periódicamente el estado de las transacciones que reciben y los state roots resultantes en Ethereum.
Verificadores: son responsables de buscar fraudes y, si hay una discrepancia entre el estado de la layer 1 y la layer 2, publican una prueba de fraude. Si alguien sospecha de fraude, puede probarlo alertando a un verificador en la red principal de Ethereum, que puede verificar la validez (o invalidez) de los resultados producidos por el secuenciador utilizando la OVM.
Secuencia de una transacción en un Optimistic Rollup
1) Se envía la transacción off chain (fuera de la blockchain principal de Ethereum) a un secuenciador para que ejecute la transaccion. 2) El secuenciador ejecuta la transacción y lo asienta en el nuevo state root. 3) El secuenciador envía una transacción de Ethereum (pagando el costo del gas correspondiente a la layer 1, esto es, una transaccion de Ethereum normal) que contiene la transacción y el nuevo state root (el bloque creado en el Optimistic Rollup). 4) La transacción ahora es asentada sobre la layer 1 de Ethereum y asegurada por la red. optimistic-rollups
Interdax.
Incentivos en Optimistic Rollups
La escalabilidad sobre L2 se basa en el hecho de que se intenta minimizar el número de transacciones on-chain (transacciones sobre la layer 1). Se usan pruebas de fraude para cancelar cualquier transición de estado inválida que pueda ocurrir. Pero dado que una prueba de fraude es una transacción on-chain, también es ideal minimizar la cantidad de pruebas de fraude que se ejecuten en Ethereum.
Esto se puede desincentivar mediante los requerimientos para ser un Secuenciador, explicado a continuación:
Para que un usuario se convierta en un secuenciador, primero debe depositar una garantía en Ethereum, que perderá si se prueba el fraude. Para incentivar a las personas a buscar fraudes, si el fraude es probado, la garantía del secuenciador se remueve y se distribuye a los verificadores. Cuanto mayor sea lo que el secuenciador deja en garantía, mayor será el incentivo para convertirse en verificador y menor será el incentivo para cometer fraude como secuenciador.
Es importante señalar que los secuenciadores y verificadores deben ejecutar un nodo completo de Ethereum y un nodo L2 completo, para producir el estado de L2. Los verificadores ejecutan el software responsable de crear pruebas de fraude y los secuenciadores ejecutan el software responsable de agrupar las transacciones de los usuarios y publicarlas.
Ben Jones de Optimism describe el bonding system (sistema de depósito en garantía):
Básicamente, los participantes son penalizados por cometer fraude y reembolsados por demostrar el fraude.
Seguridad y Disputa de transacciones
Es importante implementar correctamente este mecanismo de castigo, de lo contrario, podría explotarse en la práctica. Acá hay un ejemplo de una implementación ingenua que no funcionaría:
1) Alice deja en garantía 1 ETH para convertirse en secuenciador 2) Alice publica una actualización de estado fraudulenta/invalida 3) Bob se da cuenta de eso y publica una disputa. Si tiene éxito, esto debería otorgar el 1 ETH de la garantía de Alice a Bob y cancelar la actualización de estado fraudulenta 4) Alice se da cuenta de la disputa y también publica una disputa (disputándose ella misma) 5) Alice recibe su 1 ETH, sin pagar ninguna multa a pesar de que intentó cometer un fraude.
Alice puede montar este ataque a través del llamado ‘frontrunning’, es decir, enviando una transacción idéntica a la de Bob pero con un precio de gas más alto, lo que hace que la transacción de Alice se ejecute antes que la de Bob. Esto significa que Alice puede intentar engañar constantemente con costos mínimos (solo pagando el gas de Ethereum).
Arreglar esto es simple: en lugar de otorgar la garantía completa al disputador, un % se quema en su lugar. En el ejemplo anterior, si quemamos el 50%, Alice recibiría 0.5 ETH, lo que sería un desincentivo suficiente para no intentar cometer fraude en el Paso 2.
Es importante que exista un mecanismo para garantizar que las transacciones sean legítimas y no fraudulentas. Acá es donde entran las Fraud Proof. Si alguien nota una transacción fraudulenta, el Rollup realizará una prueba de fraude y ejecutará la transacción nuevamente, utilizando los datos de estado disponibles.
Cada vez que el secuenciador publica un conjunto de estado de transacciones, hay un “período de disputa” (rango de tiempo durante el cual se puede publicar una prueba de fraude, después del cual una transacción L2 se considera segura en L1) durante el cual cualquiera puede publicar una “prueba de fraude“. Esto se demuestra al reproducir nuevamente la transacción que causó la transición de estado y comparar el state root* resultante con el que publicó el secuenciador. Si los state root no coinciden, entonces la prueba de fraude es exitosa y la transición de estado se cancela.
Si hubo más transiciones de estado después de la inválida, también se cancelarán. Las transacciones que son anteriores al período de disputa ya no se pueden disputar y se consideran finalizadas.
Acá es necesario tener en cuenta que:
Un largo período de disputa proporciona mejores garantías de seguridad contra ataques de censura.
- Pero esto no es bueno para la adopción de Optimistic Rollups, ya que los usuarios que quieran retirar sus fondos de L2 a L1 tendrán que esperar, digamos, 7 días +/- para que puedan ser efectivizados.
Un período de disputa más corto crea una experiencia de usuario amigable para los usuarios que retiran fondos de L2 y vuelven a la L1 porque no necesitan esperar mucho antes de poder reutilizar sus fondos en la L1.
- Pero nuevamente, esto conlleva menor seguridad ya que se corre el riesgo de que ocurra un fraude y no se incluya ninguna disputa a tiempo.
El modelo de seguridad de OR se basa en el supuesto de que hay al menos 1 de N participantes honestos que ejecutan todas las transacciones del Rollup y enviarán una prueba de fraude en caso de que se publique una transición de estado no válida.
Es realista esperar que solo los secuenciadores de OR supervisen y ejecuten las transacciones. Los usuarios normales no tendrán incentivos para hacerlo, ni capacidades técnicas para procesar transacciones. Afortunadamente, los secuenciadores están naturalmente incentivados a verificar la corrección de los bloques de los demás, porque si crean un bloque encima de uno no valido los fondos que han dejado bloqueados les serán removidos.
Debido a los problemas mencionados en la sección de seguridad anterior, OR solo puede ser seguro con una ventana de tiempo de 1 a 2 semanas para ejecutar pruebas de fraude. Ninguna transacción se puede considerar finalizada hasta que pase este tiempo, ni una transferencia hacia el rollup ni una salida del mismo.
Críticas a la seguridad de Optimistic Rollups:
El dilema del verificador crea desincentivos para operar un verificador, rompiendo la seguridad:
Ed Felten escribió un análisis y una solución al dilema del verificador, resumida a continuación:
- Si los incentivos del sistema funcionan según lo previsto, nadie cometerá fraude
- Si nadie comete fraude, entonces no tiene sentido ejecutar un verificador porque no se gana dinero al operarlo.
- Dado que nadie ejecuta un verificador, eventualmente existe una oportunidad para que un secuenciador cometa fraude.
Para no alarga el artículo, pueden leer la resolución a este dilema (en inglés) desde aquí: Solución al dilema