Vitalik: Analizando las diferencias entre varios tipos de L2

Los proyectos L2 tenderán cada vez más hacia la heterogeneidad.

Título original: 《Different types of layer 2s》

Autor: Vitalik Buterin

Traducción: BlockBeats

El ecosistema se ha expandido rápidamente en el último año. Tradicionalmente representado por StarkNet, Arbitrum, Optimism y Scroll, el ecosistema de ZK-EVM rollup ha avanzado rápidamente, mejorando continuamente su seguridad. La página de L2beat resume muy bien el estado de cada proyecto.

Además, hemos visto algunos equipos construyendo sidechains y, al mismo tiempo, comenzando a desarrollar soluciones rollup (como Polygon), algunos proyectos L1 intentando avanzar hacia la validación de validez (como Celo), y nuevos intentos (como Linea, Zeth…).

Uno de los resultados inevitables de esto es que vemos que los proyectos L2 tienden a ser cada vez más heterogéneos (heterogeneous). Nota del traductor: en el ámbito cripto, "heterogeneidad" se refiere a la coexistencia o mezcla de cosas de diferentes tipos o naturalezas. Este término suele usarse para describir diferentes blockchains, protocolos, tecnologías o activos que poseen distintas características, reglas o atributos). Preveo que esta tendencia continuará por las siguientes razones:

Actualmente, algunos proyectos L1 independientes buscan una relación más estrecha con el ecosistema de Ethereum y podrían transformarse en proyectos L2. Estos proyectos pueden querer adoptar una transición gradual. Una transición total e inmediata reduciría la usabilidad, ya que la tecnología aún no está lista para poner todo en una solución rollup. Por otro lado, una transición total tardía podría sacrificar el impulso y no llegar a tiempo para tener un impacto real.

Algunos proyectos centralizados quieren ofrecer mayor seguridad a sus usuarios y están explorando vías basadas en blockchain. En muchos casos, estos proyectos antes habrían estudiado "cadenas de consorcio con permisos". En realidad, solo necesitan alcanzar un nivel de "semi-centralización". Además, suelen tener un rendimiento muy alto, lo que al menos a corto plazo no es adecuado para soluciones rollup.

Aplicaciones no financieras, como juegos o redes sociales, desean descentralizarse, pero solo requieren cierto grado de seguridad.

En el caso de las redes sociales, en realidad implica tratar diferentes partes de la aplicación de distintas maneras: actividades poco frecuentes y de alto valor, como el registro de nombres de usuario y la recuperación de cuentas, deberían realizarse en una solución rollup, pero actividades frecuentes y de bajo valor, como publicaciones y votos, requieren menos seguridad; si la blockchain falla y tu publicación desaparece, es un coste aceptable; pero si la blockchain falla y pierdes tu cuenta, es un problema mucho mayor.

Un tema importante es que, aunque actualmente las aplicaciones y usuarios en Ethereum L1 están dispuestos a pagar tarifas rollup pequeñas pero visibles a corto plazo, los usuarios que vienen del mundo no blockchain son menos propensos a hacerlo: si antes pagabas 1 dólar, pagar 0,10 dólares es más aceptable, pero si antes pagabas 0 dólares, es difícil de aceptar.

Esto se aplica a aplicaciones que hoy siguen siendo centralizadas, así como a proyectos L1 más pequeños que suelen tener tarifas extremadamente bajas cuando su base de usuarios es pequeña.

Una pregunta natural es: para una aplicación concreta, ¿cuál es la opción razonable entre las complejas compensaciones de rollup, validiums (validación de validez) y otros sistemas?

Rollups vs Validiums vs Sistemas Desconectados

La primera dimensión de seguridad y escalabilidad que vamos a explorar puede describirse así: si tienes un activo emitido en L1, lo depositas en L2 y luego lo transfieres a tu posesión, ¿qué grado de garantía tienes de poder recuperar el activo en L1?

Al mismo tiempo, hay una pregunta relacionada: ¿qué elección tecnológica conduce a ese grado de garantía y cuáles son las compensaciones de esa elección?

Podemos describir este problema con un gráfico simple:

Vale la pena mencionar que este es un esquema simplificado, en el que existen muchas opciones intermedias. Por ejemplo:

Entre rollup y validium: en validium, cualquiera puede pagar en la cadena para cubrir las tarifas de transacción; en ese momento, el operador se ve obligado a proporcionar algunos datos en la cadena, o perderá su depósito.

Entre plasma y validium: un sistema Plasma proporciona garantías de seguridad similares a las de un rollup, con disponibilidad de datos fuera de la cadena, pero solo admite un número limitado de aplicaciones. Un sistema puede ofrecer una EVM completa y proporcionar garantías de nivel Plasma a los usuarios que no utilizan esas aplicaciones más complejas, y garantías de nivel validium a los usuarios que sí las usan.

Estas opciones intermedias pueden verse como un espectro entre rollup y validium. Pero, ¿qué motiva a una aplicación a elegir un punto específico en ese espectro, en lugar de uno más a la izquierda o a la derecha? Aquí hay dos factores principales:

1. El coste de la disponibilidad de datos nativa de Ethereum, que disminuirá con el tiempo a medida que avance la tecnología. El próximo hard fork de Ethereum, Dencun, introduce EIP-4844 (también conocido como "proto-danksharding"), que proporciona aproximadamente 32 kB/segundo de disponibilidad de datos en la cadena.

Se espera que en los próximos años, con la implementación completa de danksharding, esta disponibilidad de datos aumente gradualmente, con un objetivo final de unos 1,3 MB/segundo de disponibilidad de datos. Al mismo tiempo, las mejoras en la compresión de datos permitirán hacer más con la misma cantidad de datos.

2. Las propias necesidades de la aplicación: ¿cuán grave es la pérdida para los usuarios por tarifas altas en comparación con los problemas de la aplicación? Las aplicaciones financieras perderán más si la aplicación falla; los juegos y las redes sociales implican muchas actividades de usuario de bajo valor, por lo que para ellos tienen sentido diferentes compensaciones de seguridad.

Esta compensación se ve aproximadamente así:

Otro tipo que vale la pena mencionar son las pre-confirmaciones (pre-confirmations). Las pre-confirmaciones son mensajes firmados por un grupo de participantes en un rollup o validium, que indican "atestiguamos que estas transacciones están incluidas en este orden y que el post-state root es este". Estos participantes pueden firmar una pre-confirmación que no se corresponda con la realidad, pero si lo hacen, su depósito será destruido.

Esto es muy útil para aplicaciones de bajo valor (como pagos de consumo), mientras que las aplicaciones de alto valor (como transferencias financieras de millones de dólares) pueden esperar la confirmación "regular" respaldada por la seguridad completa del sistema.

Las pre-confirmaciones pueden verse como otro ejemplo de sistema híbrido, similar al "híbrido plasma/validium" mencionado anteriormente, pero esta vez mezclando un rollup (o validium) con seguridad completa pero alta latencia, y un sistema con menor nivel de seguridad pero baja latencia. Las aplicaciones que requieren baja latencia obtienen menor seguridad, pero pueden coexistir en el mismo ecosistema con aquellas que están dispuestas a soportar mayor latencia para obtener la máxima seguridad.

Lectura de Ethereum sin confianza

Otra forma de conexión, menos considerada pero igualmente importante, está relacionada con la capacidad de los sistemas para leer la blockchain de Ethereum. En concreto, esto incluye la capacidad de que el sistema pueda revertirse si Ethereum sufre un rollback. Para entender por qué esto es valioso, considera el siguiente escenario:

Supón que, como se muestra en la imagen, la blockchain de Ethereum sufre un rollback. Esto puede ser una interrupción temporal dentro de una época, cuando la blockchain aún no se ha finalizado; o puede deberse a que demasiados validadores están fuera de línea, lo que provoca un periodo de fuga de inactividad en el que la blockchain no puede finalizarse durante un tiempo prolongado.

El peor caso posible resultante es el siguiente: supón que el primer bloque de la cadena superior (top chain) lee algunos datos del bloque más a la izquierda de la cadena de Ethereum. Por ejemplo, alguien deposita 100 ETH en la cadena superior desde Ethereum. Luego, Ethereum sufre un rollback, pero la cadena superior no lo hace. Como resultado, los bloques futuros de la cadena superior siguen correctamente los nuevos bloques correctos de la blockchain de Ethereum, pero la transacción errónea (el depósito de 100 ETH) sigue existiendo en la cadena superior. Esta vulnerabilidad podría provocar la emisión excesiva de moneda, convirtiendo el ETH puenteado en la cadena superior en reservas fraccionarias.

Hay dos formas de resolver este problema:

1. La cadena superior solo puede leer bloques de Ethereum que ya han sido finalizados, por lo que nunca necesita revertirse;

2. Si Ethereum sufre un rollback, la cadena superior también puede revertirse. Ambas soluciones previenen este problema. La primera es más fácil de implementar, pero si Ethereum entra en un periodo de fuga de inactividad, puede provocar la pérdida de funcionalidad durante un tiempo prolongado. La segunda es más difícil de implementar, pero garantiza la mejor funcionalidad en todo momento.

Ten en cuenta que la primera solución tiene un caso especial. Si Ethereum sufre un ataque del 51%, lo que da lugar a dos nuevos bloques incompatibles que parecen finalizados, la cadena superior podría elegir el bloque equivocado (es decir, el bloque que el consenso social de Ethereum finalmente no respalda) y necesitaría revertirse para cambiar al bloque correcto. Se podría decir que no es necesario escribir código para manejar este caso de antemano; se puede manejar mediante un hard fork en la cadena superior.

La capacidad de una blockchain para leer Ethereum sin confianza es importante por dos razones:

Primero, esta capacidad puede reducir los problemas de seguridad involucrados en puentear tokens emitidos en Ethereum (u otras soluciones de segunda capa) a esa cadena;

Segundo, esta capacidad permite que las wallets de abstracción de cuentas que usan estructuras de almacenamiento de claves compartidas puedan mantener activos de forma segura en esa cadena.

Aunque es controvertido, la importancia de la primera solución ya ha sido ampliamente reconocida. De igual forma, la segunda también es importante, ya que significa que puedes tener una wallet que cambie fácilmente de clave y mantenga activos en muchas cadenas diferentes.

¿Tener un puente puede convertirte en un validium?

Supón que la cadena superior se lanza inicialmente como una cadena independiente y luego alguien despliega un contrato puente en Ethereum. El contrato puente es simplemente un contrato que acepta cabeceras de bloque (block headers) de la cadena superior, verifica que cualquier cabecera enviada tenga un certificado válido que demuestre que ha sido aceptada por el consenso de la cadena superior y añade esa cabecera a la lista.

Las aplicaciones pueden construir funciones sobre esto, como depósitos y retiros de tokens. Una vez que este puente está establecido, ¿proporciona alguna de las garantías de seguridad de activos mencionadas anteriormente?

¡Hasta ahora, no! Hay dos razones:

1. Estamos verificando la firma del bloque, pero no si la transición de estado es correcta. Por lo tanto, si depositas un activo emitido en Ethereum en la cadena superior y los validadores de la cadena superior se vuelven deshonestos, pueden firmar una transición de estado inválida y robar esos activos;

2. La cadena superior todavía no puede leer Ethereum. Por lo tanto, no puedes depositar activos nativos de Ethereum en la cadena superior, a menos que dependas de otros puentes de terceros (posiblemente inseguros).

Ahora, construyamos el puente como un puente de validación: no solo verifica el consenso, sino que también verifica que cualquier nuevo bloque calculado usando una prueba ZK-SNARK tenga un estado correcto.

Una vez hecho esto, los validadores de la cadena superior no podrán robar tus fondos. Pueden publicar un bloque con datos no disponibles, impidiendo que todos retiren fondos, pero no pueden robarlos (a menos que intenten extorsionar a los usuarios para revelar los datos que permiten retirar los fondos). Esto tiene el mismo modelo de seguridad que validium.

Sin embargo, aún no hemos resuelto el segundo problema: la cadena superior no puede leer los datos de Ethereum. Para lograr esto, necesitamos una de las siguientes dos formas:

1. Colocar un contrato puente en la cadena superior que verifique bloques de Ethereum ya finalizados;

2. Incluir en cada bloque de la cadena superior el hash de un bloque reciente de Ethereum y adoptar una regla de selección de bifurcación que obligue a mantener el enlace hash. Es decir, un bloque de la cadena superior que enlace a un bloque de Ethereum que no esté en la cadena principal, será también un bloque fuera de la cadena principal. Si el bloque de Ethereum al que enlaza el bloque de la cadena superior estaba inicialmente en la cadena principal pero luego deja de estarlo, el bloque de la cadena superior también debe dejar de estarlo.

Estos enlaces morados pueden ser enlaces hash o contratos puente que verifican el consenso de Ethereum

¿Es esto suficiente? En realidad, no, porque existen algunos casos límite:

1. ¿Qué sucede si Ethereum sufre un ataque del 51%?

2. ¿Cómo se manejan las actualizaciones de hard fork de Ethereum?

3. ¿Cómo se manejan las actualizaciones de hard fork de tu propia cadena?

Un ataque del 51% a Ethereum tendría consecuencias similares a un ataque del 51% a la cadena superior, pero al revés. Un hard fork de Ethereum podría invalidar el puente de Ethereum dentro de la cadena superior. Un compromiso social, es decir, que si Ethereum revierte un bloque finalizado, también se revierte, y si Ethereum hace un hard fork, también se hace un hard fork, es la forma más limpia de resolver este problema.

En realidad, tal compromiso puede que nunca necesite ejecutarse: si la gobernanza de la cadena superior detecta pruebas de un posible ataque o hard fork, puede activar la gobernanza, y solo si esta falla, se hace un hard fork en la cadena superior.

Para el tercer problema, la única respuesta viable es establecer algún tipo de gobernanza en Ethereum para que el contrato puente en Ethereum pueda ser consciente de las actualizaciones de hard fork en la cadena superior.

En resumen: un puente de validación bidireccional es casi suficiente para que una blockchain sea un validium. El principal elemento restante es un compromiso social de que, si ocurre una anomalía en Ethereum que impide que el contrato puente funcione correctamente, la otra blockchain hará un hard fork en respuesta.

Conclusión

Hay dos dimensiones clave para "conectarse con Ethereum":

1. Seguridad de extracción hacia Ethereum;

2. Seguridad de lectura de Ethereum.

Ambas son muy importantes y tienen consideraciones diferentes. En ambos casos existe un espectro continuo:

Ten en cuenta que cada dimensión tiene dos formas diferentes de medición (en realidad hay cuatro dimensiones): la seguridad de extracción puede medirse por (i) el nivel de seguridad y (ii) cuántos usuarios o casos de uso se benefician del nivel de seguridad más alto;

Mientras que la seguridad de lectura puede medirse por (i) la rapidez con la que el enlace puede leer bloques de Ethereum, especialmente la diferencia entre bloques finalizados y cualquier bloque, y (ii) el grado de compromiso social del enlace al manejar casos límite como ataques del 51% y hard forks.

En muchas áreas de este espacio de diseño existen proyectos valiosos. Para algunas aplicaciones, la alta seguridad y una conexión estrecha son cruciales. Para otras, se pueden aceptar condiciones más flexibles para lograr mayor escalabilidad. En muchos casos, comenzar hoy con condiciones más flexibles y pasar gradualmente a un acoplamiento más estrecho a lo largo de la próxima década a medida que la tecnología mejore puede ser la mejor opción.