¡Bienvenido nuevamente!

🧠Luego de una primera edición con preguntas esenciales para entender cómo y porqué están las L2 en Ethereum, es momento de una segunda compilación de preguntas y curiosidades sobre esta tecnología. Recomiendo leer dicha primera parte antes de continuar leyendo los tópicos a abordar a continuación.

17. ¿Cómo son las confirmaciones de transacciones en L2?

Es sabido en que redes como Bitcoin y Ethereum L1, las confirmaciones son la señal que nos ayuda a interpretar cuán segura está una trasacción una vez que ha sido procesada. Las confirmaciones son el número de bloques incluidos después del bloque en el que está tu transacción.

Si tu transacción tiene 10 confirmaciones, implica que han pasado 10 nuevos bloques, así que habría que romper este ordenamiento para que tu transacción pudiese quedar en riesgo, por lo cual, mientras más confirmaciones, mejor, y dependiendo siempre del grado de seguridad de la cadena.

Esto es relativamente fácil de entender para una L1, pero para L2 y más puntualmente los Rollups, la finalidad es mucho más complicada.

En Rollups, los operadores que construyen los bloques o dan secuencia al procesamiento de transacciones, luego tienen que publicarlas en Ethereum, y más tarde Ethereum provee alguna forma de validación final.

Por lo tanto, en este tipo de L2 existen diferentes niveles de confirmación que determinan el grado de certeza de que tu transacción enviada está siendo incluida y no será alterada o removida en un futuro. Advertimos que en Rollups, este proceso no es tan rápido como se creería.

Existen 3 etapas:

1. Confirmación suave (soft): acabas de mandar una transacción a la red L2 (una transferencia ERC20, un swap, lo que sea) desde tu walleta través de un RPC. En este punto sucederá que:

   - La transacción es propagada en la red L2.

   - Un secuenciador lo toma y lo procesa para sí.

   - Confirma al usuario que la transacción se pone en cola y a ser publicada en un futuro.

   Dado que las L2 no son redes independientes, en esta etapa, esta confirmación se denomina suave (soft) ya que se considera como una promesa de parte del secuenciador a publicar tu transacción en Ethereum en algún punto del futuro. Es decir que hasta este punto Ethereum no tiene idea de que tu transacción existe, por lo tanto su inclusión y orden podría no suceder si el secuenciador falla.

2. Confirmación dura (hard): el secuenciador ahora a apunta un buen número de transacciones, incluyendo la tuya, por lo que ahora le es factible publicarlas en Ethereum, en forma de batches. Para alcanzar este nivel se tiene que:

   - El secuenciador ha armado el batch (paquete) con el orden de transacciones correcto.

   - Lo publica en el contrato del Rollup en Ethereum, con la famosa función de calldata. Una vez publicada esta información en Ethereum, no se puede retroceder.

   - De la misma manera, se actualiza el state root (estados de cuenta) luego de 1 o más batches.

   Las transacciones publicadas en Ethereum son la garantía de que no serán olvidadas o alteradas de su orden previsto. Para modificar este ordenamiento o retroceder en el tiempo, la red Ethereum completa deberá ser atacada con este fin. En este sentido la L1 representa la única fuente de la verdad sobre el paso e historia de la L2. A su vez, cualquier usuario corriendo un nodo completo de rollup+L1, podría potencialmente determinar si la transacción posteada será validado en el futuro (dependiendo de las especificaciones del rollup).

3. Finalidad final: posteadas las transacciones, Ethereum también proporciona un escenario para que desde la misma se implementen mecanismos de validación que dependan única y exclusivamente de la L1. Esto es:

   - Los batches publicados requieren una señal de validación final para que se consideren correctas y finalizadas las transacciones y estado.

   - Alcanzar la finalidad completa permite que, por ejemplo, fondos puedan retirarse de forma segura de L2 a L1.

   - En un ZK Rollup, es necesario esperar a que la prueba de validez sea generada, posteada y verificada por el prover, referente a una porción de transacciones o historial pasado del Rollup.

   - En un Optimistic Rollup, deberá esperarse la ventana de tiempo de 7 días en la que potencialmente se puede comprobar una transacción y estado incorrecto y realizar un rollback.

Aunque en el 99% y más de los casos, las transacciones en la fase de confirmación dura llegarán con exito a la fase de finalización, no se debería considerar como una garantía absoluta, y menos cuando los rollups intenten descentralizarse. De todas maneras la idea los desarrollen idean mecanismos para que los Rollups no sufran de rollbacks o retraso en confirmaciones definitivas.

18. En los Optimistic Rollups “todo está correcto hasta que se demuestre lo contrario”… ¿Cuáles son los factores para que esto se cumpla y una prueba de fraude tenga éxito?

Los Optimistic Rollups no requieren consenso sobre el orden y validez de las transacciones, ya que ese servicio de seguridad es provisto de Ethereum. Pero tal y como se discutió en la primera parte, los Optimistic Rollups aun requieren de la existencia de 1 participante honesto vigilando la cadena y capaz de enviar una prueba de fraude para revertir estados incorrectos.

Por tanto, asumiendo un Optimistic Rollup estándar con pruebas de fraude activas, la clave está en que se sánamente estos 4 factores estén presentes consecutivamente:

1. Exista un participante honesto corriendo un nodo de L2 y vigile el estado del Rollup y la información publicada en Ethereum, atento en caso de comportamiento fraudulento o incorrecto.

2. Si existe un participante honesto, llamémoslo ahora verificador, es común que sea requerido que tenga un capital a disposición en stake o bond para participar subiendo una prueba fraude. Este requisito de capital variará según las reglas de funcionamiento de cada Optimistic Rollup, pero asegurará que no haya spam ni sea factible hacer intentos de saboteo a la red mendiante pruebas de fraude sin verdaderamente haber existido tal fraude.

3. Si existe un verificador y con capital, deberá enviar la prueba de fraude dentro de un periodo de 7 días. La idea es que este proceso sea bastante automático entre los clientes y software correspondientes, pero dependerá de cada Rollup.

4. Si existe un participante honesto y con capital y detecta fraude, es necesario que la red Ethereum sea resistente a censura para que el verificador efectivamente pueda incluir su transacción relacionada a la prueba de fraude y el proceso de disputa empiece a marchar y pueda resolverse. Según las especificaciones de cada Optimistic Rollup, este proceso puede conllevar un numero variado de transacciones hasta la resolución final.

19. ¿Pueden las L2 admitir otros lenguajes para contratos inteligentes?

Sí. Las L2 perfectamente pueden explorar lenguajes alternativos, admitir combinaciones y más. Lo único que importa es que la computación (ejecución de trasacciones) se puede probar correctamente en Ethereum mediante pruebas de validez o fraude, o sea hay que trabajar en su compatibilidad.

Algunos ejemplos ya existentes de este enfoque son:

• Starknet con Cairo

• Cartesi con C++ & Python

• zkSync 2.0 con Zinc (basado en Rust)

• Fuel V2 con Sway (basado en Rust)

• Aztec 3 con Noir (basado en Rust)

• Polygon Miden con Move (basado en Rust)

20. ¿Por qué las L2 crean sus propios tokens cuando es sabido que usan ETH para operar? ─ Idea por @Ivanovish10

Una extensión a la pregunta 11 de la parte 1.

Esta pregunta es absolutamente válida tomando en cuenta en que en otras redes como Bitcoin + Lightning Network, no hay necesidad alguna de crear un token adicional, basta con BTC.

No obstante, las L2 y particularmente las que cumplen roles específicos (como DEX) o propósito general (EVM u otra VM), con sus funcionalidades sofisticadas pueden abrir la puerta a requerir token adicionales para cubrir aspectos que ETH no resolvería bien por sí solo.

• Gobernanza: si la L2 está en desarrollo o algunos parámetros pueden ir cambiando con el tiempo, es preferible tener un activo isolado para esta misión. Ideal para votar actualizaciones, desde acciones de emergencia hasta parámetros específicos, como el caso de fees de trading para los L2 dedicados a ser exchanges descentralizados.

• Pago de comisiones: el caso de uso más cuestionado, algunas L2 han explorado la posibilidad de cobrar comisiones en su propio token en vez de en ETH. Esto tiene más sentido si por ejemplo, la L2 NO es un Rollup por lo que no necesita intensivamente ETH para funcionar. De todas maneras estos son modelos de negocios que cada proyecto debe cuidadosamente pensar, algunos pensados hasta el momento es el tip como pago extra por una inclusión prioritaria u derecho a descuento.

• Alineación de los incentivos y participación: dependiendo de como sea la producción de batches y procesamiento en general de transacciones, un token adicional puede servir como forma de staking, acceso a privilegios y para alcanzar la eficiencia. Subastas en MEV, subastas de secuenciación, modelo PoS/Tendermint son algunas ideas para hacer esto efectivo. Incluso la L2 podría implementar su propia red independiente, dedicada a guardar transacciones en este instancias más económica, implementando un token de staking.

21. ¿ Donde y cómo ubicamos las L3?

Una Layer 3 es simplemente una L2 sobre otra L2. Esto quiere decir la relación L2-L1, puede trasladarse ahora en términos de L3-L2. O sea, los mecanismo de prueba de validez y pruebas de fraude podrían ser alojadas en la L2, y lo mismo con los datos del conjunto de transacciones (aunque se preferiría en este caso hacerlo en una cadena independiente de data availability tal como un Validium u Optimistic Chain).

Si las transacciones en L2 son económicas, en L3 podrían perfectamente llegar a ser negligibles.

Desde una vista esquemática, se puede entender como un tercer piso.

Pero también se puede afirmar que una L2 podría tener sobre sí distintas L3, lo que abre aún más el árbol de redes conectadas y potencialmente aseguradas por Ethereum.

Repitiendo este proceso, es posible alcanzar la recursividad hasta donde se desee o sea factible.

22. Riesgos de frenado, hard fork y pérdida de fondos en un Rollup. ─ Idea por @juampiq6

Parte de la gracia de lo Rollups y L2 en general de Ethereum es que son una forma conceptualmente segura para usar fondos originarios de L1 en estas nuevas cadenas con muchas más funcionalidades y facilidades.

Dicho esto, en estos nuevos tipos de cadenas, no los deja exento de riesgos por desarrollo temprano y otras particularidades interesantes… abordemos cada punto:

• Frenado: si la L2 es centralizado y sólo el operador designado por el proyecto puede producir bloques, entonces si este actor sea cae, la L2 también (ejemplo ver caída de Arbitrum).

• Pérdida de fondos: dado que las L2 son sólo contratos inteligentes para Ethereum, no son ajenas a hackeos.

• Hard fork: para hacer un hard fork de una L2 es necesario actualizar sus contratos en L1. Por esta razón no hay tal cosa posible como “dividir la L2 en dos” semejante a la situación Bitcoin-Bitcoin Cash ó Ethereum-Ethereum Classic. Sólo una versión puede ser compatible con los contratos de la L2 en Ethereum y por ende los fondos bloqueados.

Más sobre los riesgos en el siguiente video 👇

23. ¿Qué pasa con las L2 con el merge?

En teoría no debería traer consecuencias ni preocupaciones significativas. Las L2 estarán activas y funcionando en Ethereum PoS.

Si existiese un periodo de downtime (caida) en Ethereum L1 durante o después del Merge, las L2 también podrían sufrirlo o no alcanzar la finalización de sus transacciones (ver pregunta 17).

El caso especulado de EthPoW sí representa una situación de hard fork que involucra intrínsecamente las L2, ya que potencialmente hace que las L2 se dupliquen (una versión para EthPoS y otra versión para EthPoW).

En este caso pueden presentarse 3 casos:

1. L2 centralizada y no soporte PoW: el equipo rechaza mantener activa la L2 en EthPoW. Acá los fondos duplicados quedarán atrapados dentro de la L2 a menos que existe un mecanismo de retiro de emergencia.

2. L2 centralizada y soporte PoW: el equipo acepta mantener activa la L2 en EthPoW. Habilitarán soporte y la infraestructura pertinente.

3. L2 descentralizada: dependerá de la comunidad si mantener activa la L2 en EthPoW. Lo mismo sobre soporte e infraestructura relacionada. Riesgo de replay attacks.

Por el momento, NO hay ninguna noticia relevante sobre L2 y el presunto futuro EthPoW.

Más sobre estas reflexiones y cuidados en el siguiente hilo de Twitter:

🎉 ¡Gracias por leer hasta el final! En L2 en Español estamos avocados en educar, aprender y estudiar juntos, sigue nuestras redes sociales y unite a la conversación en nuestra comunidad de Telegram!

Con 💗 desde DeFi LATAM 🤝 DeFi para principiantes