Vitalik: Analizando las diferencias entre los distintos 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, el ecosistema de ZK-EVM rollup, representado por StarkNet, Arbitrum, Optimism y Scroll, ha avanzado rápidamente, mejorando constantemente su seguridad. La página de L2beat resume muy bien el estado de cada proyecto.

Además, hemos visto que algunos equipos están construyendo sidechains y, al mismo tiempo, comienzan a desarrollar soluciones rollup (como Polygon), algunos proyectos L1 intentan avanzar hacia la verificación de validez (como Celo), y también hay intentos completamente nuevos (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 blockchains, protocolos, tecnologías o activos diferentes, que tienen distintas características, reglas o atributos. Espero que esta tendencia continúe, por las siguientes razones:

Actualmente, algunos proyectos L1 independientes buscan una conexión más estrecha con el ecosistema de Ethereum y podrían convertirse en proyectos L2. Estos proyectos pueden querer adoptar una transición por etapas. Hacer una transición completa de inmediato 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 completa más 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 caminos basados en blockchain. En muchos casos, estos proyectos antes habrían considerado “cadenas de consorcio con permisos”. En realidad, solo necesitan alcanzar un nivel de “semi-centralización”. Además, suelen tener un throughput muy alto, por lo que al menos a corto plazo no son aptos para soluciones rollup.

Aplicaciones no financieras, como juegos o redes sociales, buscan descentralización, pero solo requieren cierto nivel de seguridad.

En el caso de las redes sociales, en realidad se trata de manejar 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 costo aceptable; pero si 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 no están tan dispuestos: si antes pagabas 1 dólar, pagar 0,10 dólares es más aceptable, pero si antes pagabas 0 dólares, cuesta mucho más aceptarlo.

Esto aplica tanto a aplicaciones que hoy siguen siendo centralizadas, como a proyectos L1 pequeños que suelen tener tarifas extremadamente bajas cuando su base de usuarios es reducida.

Una pregunta natural es: para una aplicación específica, ¿cuál es la opción razonable entre rollup, validiums (verificación de validez) y otros sistemas, considerando estos complejos trade-offs?

Rollups vs Validiums vs Sistemas Desconectados

La primera dimensión de seguridad y escalabilidad que exploraremos puede describirse así: si tienes un activo emitido en L1, lo depositás en L2 y luego lo transferís a tu cuenta, ¿qué nivel de garantía tenés de que podés recuperar ese activo en L1?

Al mismo tiempo, hay una pregunta relacionada: ¿qué decisiones técnicas llevan a ese nivel de garantía y cuáles son los trade-offs de esa elección?

Podemos describir este problema con un gráfico simple:

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

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

Entre plasma y validium: un sistema Plasma ofrece garantías de seguridad similares a los rollups, con disponibilidad de datos off-chain, pero solo soporta un número limitado de aplicaciones. Un sistema puede ofrecer EVM completo y, para usuarios que no usan esas aplicaciones más complejas, brindar garantías tipo Plasma, y para quienes sí las usan, garantías tipo validium.

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

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

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 aproximadamente 1.3 MB/segundo. Al mismo tiempo, las mejoras en la compresión de datos permitirán hacer más con la misma cantidad de datos.

2. Las necesidades propias de la aplicación: ¿qué tan grave es para los usuarios la pérdida por tarifas altas, en comparación con el daño si la aplicación falla? Las aplicaciones financieras perderán más si la aplicación falla; los juegos y redes sociales involucran muchas actividades de usuario de bajo valor, por lo que para ellos tienen sentido diferentes trade-offs de seguridad.

Este trade-off se ve aproximadamente así:

Otro tipo que vale la pena mencionar son las pre-confirmaciones. Las pre-confirmaciones son mensajes firmados por un grupo de participantes en un rollup o validium, que dicen: “Afirmamos 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 incorrecta, pero si lo hacen, su depósito será destruido.

Esto es muy útil para aplicaciones de bajo valor (como pagos de consumo), mientras que 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 antes, pero esta vez mezclando un rollup (o validium) con seguridad completa pero alta latencia, y un sistema con menor seguridad pero baja latencia. Las aplicaciones que necesitan baja latencia obtienen menor seguridad, pero pueden coexistir en el mismo ecosistema con aquellas que prefieren máxima seguridad a costa de mayor latencia.

Lectura de Ethereum sin confianza

Otra forma de conexión, menos considerada pero igualmente importante, está relacionada con la capacidad de un sistema de leer la blockchain de Ethereum. Específicamente, esto incluye la capacidad de que el sistema pueda hacer rollback si Ethereum hace rollback. Para entender por qué esto es valioso, considerá el siguiente caso:

Supongamos que, como se muestra en la imagen, la blockchain de Ethereum hace un rollback. Esto puede ser una interrupción temporal dentro de una época, cuando la blockchain aún no está finalizada; o puede deberse a que demasiados validadores están offline, lo que lleva a un período de inactivity leak donde la blockchain no puede finalizar durante un tiempo prolongado.

El peor caso posible es el siguiente: supongamos que el primer bloque de la cadena superior (top chain) lee ciertos 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 hace rollback, pero la cadena superior no. Como resultado, los bloques futuros de la cadena superior siguen correctamente los nuevos bloques correctos de Ethereum, pero la transacción incorrecta (el depósito de 100 ETH) sigue existiendo en la cadena superior. Esta vulnerabilidad puede llevar a la emisión excesiva de moneda, convirtiendo los ETH puenteados en la cadena superior en reservas fraccionarias.

Hay dos formas de resolver este problema:

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

2. Si Ethereum hace rollback, la cadena superior también puede hacer rollback. Ambas previenen este problema. La primera es más fácil de implementar, pero si Ethereum entra en un período de inactivity leak, puede llevar a una 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.

Notá que la primera opción tiene un caso especial. Si Ethereum sufre un ataque del 51% que resulta en dos bloques nuevos incompatibles, ambos aparentemente finalizados, la cadena superior podría elegir el bloque incorrecto (el que el consenso social de Ethereum finalmente no apoya) y necesitaría hacer rollback para cambiar al bloque correcto. Se puede argumentar que no es necesario escribir código para esto de antemano; se puede manejar con un hard fork en la cadena superior.

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

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

Segundo, permite que 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 debatido, la importancia de la primera opción ya ha sido ampliamente reconocida. Igualmente, la segunda opción es importante porque significa que podés tener una wallet que cambie fácilmente de clave y mantenga activos en muchas cadenas diferentes.

¿Tener un puente convierte a una cadena en validium?

Supongamos que la cadena superior se lanza inicialmente como una cadena independiente, y luego alguien despliega un contrato puente en Ethereum. El contrato puente simplemente acepta headers de bloques de la cadena superior, verifica que cualquier header presentado venga con un certificado válido que pruebe que fue aceptado por el consenso de la cadena superior, y lo agrega a la lista.

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

¡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 depositás 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 aún no puede leer Ethereum. Por lo tanto, no podés 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 verificación: no solo verifica el consenso, sino que también verifica que cualquier bloque nuevo presentado tenga un estado correcto, probado mediante ZK-SNARK.

Una vez hecho esto, los validadores de la cadena superior no podrán robar tus fondos. Pueden publicar un bloque con datos no disponibles y bloquear los retiros, pero no pueden robar fondos (a menos que intenten extorsionar a los usuarios para revelar los datos que permiten los retiros). Esto es igual al modelo de seguridad de validium.

Sin embargo, aún no resolvimos el segundo problema: la cadena superior no puede leer datos de Ethereum. Para lograr esto, necesitamos una de dos opciones:

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 usar una regla de selección de fork que obligue a mantener el enlace hash. Es decir, un bloque de la cadena superior que enlace a un bloque de Ethereum fuera de la cadena principal también es un bloque fuera de la cadena principal. Si el bloque de Ethereum al que enlaza un bloque de la cadena superior estaba en la cadena principal pero luego deja de estarlo, el bloque de la cadena superior también debe dejar de estarlo.

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

¿Esto es suficiente? En realidad, no, porque hay algunos casos límite:

1. ¿Qué pasa 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 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, la otra cadena también lo revierte, y si Ethereum hace un hard fork, la otra cadena también, es la forma más limpia de resolver esto.

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

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

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

Conclusión

“Conectarse a Ethereum” tiene dos dimensiones clave:

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:

Notá que cada dimensión tiene dos formas diferentes de medirse (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 más alto de seguridad;

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

Hay valor en proyectos en muchas áreas de este espacio de diseño. Para algunas aplicaciones, la alta seguridad y una conexión estrecha son esenciales. Para otras, se pueden aceptar condiciones más flexibles para lograr mayor escalabilidad. En muchos casos, comenzar hoy con condiciones más flexibles y, a medida que la tecnología mejora, pasar gradualmente a una mayor integración en la próxima década puede ser la mejor opción.