Diferentes tipos de Layer2
El ecosistema de capas 2 de Ethereum ha estado expandiéndose rápidamente en el último año. El ecosistema de rollup EVM, que tradicionalmente incluye a Arbitrum, Optimism y Scroll, y más recientemente Kakarot y Taiko, ha estado progresando rápidamente y haciendo grandes avances en la mejora de su seguridad; la página de L2beat hace un buen trabajo resumiendo el estado de cada proyecto. Además, hemos visto equipos que construyen sidechains también comenzando a desarrollar rollups (Polygon), proyectos de capa 1 que buscan moverse hacia ser validiums (Celo), y esfuerzos completamente nuevos (Linea, Zeth...). Finalmente, está el ecosistema que no se limita solo a EVM: "casi-EVMs" como Zksync, extensiones como Arbitrum Stylus y esfuerzos más amplios como el ecosistema Starknet, Fuel y otros.
Una de las consecuencias inevitables de esto es que estamos viendo una tendencia de proyectos de capa 2 volviéndose más heterogéneos. Espero que esta tendencia continúe, por algunas razones clave:
Algunos proyectos que actualmente son capas 1 independientes están buscando acercarse al ecosistema de Ethereum y posiblemente convertirse en capas 2. Estos proyectos probablemente deseen una transición paso a paso. Realizar la transición de inmediato causaría una disminución en la usabilidad, ya que la tecnología aún no está lista para poner todo en un rollup. Realizar la transición de inmediato más adelante arriesga sacrificar el impulso y llegar demasiado tarde para ser significativo.
Algunos proyectos centralizados desean brindar a sus usuarios garantías de seguridad adicionales y están explorando rutas basadas en blockchain para lograrlo. En muchos casos, estos son proyectos que habrían explorado "cadenas de consorcio con permisos" en una era anterior. De forma realista, probablemente solo necesiten un nivel de descentralización intermedio. Además, su alto nivel de rendimiento a menudo los hace inadecuados incluso para los rollups, al menos a corto plazo.
Las aplicaciones no financieras, como juegos o redes sociales, desean ser descentralizadas pero solo necesitan un nivel de seguridad intermedio. En el caso de las redes sociales, esto implica tratar partes diferentes de la aplicación de manera distinta: actividades de alto valor como el registro de nombres de usuario y la recuperación de cuentas deberían realizarse en un rollup, pero actividades frecuentes y de bajo valor como publicaciones y votos requieren menos seguridad. Si una falla de la cadena hace que tu publicación desaparezca, ese es un costo aceptable. Si una falla de la cadena hace que pierdas tu cuenta, eso es un problema mucho más grande.
Un tema importante es que, mientras que las aplicaciones y los usuarios que están en la capa 1 de Ethereum estarán bien pagando tarifas de rollup más pequeñas pero aún visibles a corto plazo, los usuarios del mundo no blockchain no lo estarán: es más fácil justificar pagar $0.10 si antes pagabas $1 que si antes no pagabas nada. Esto aplica tanto para aplicaciones que son centralizadas hoy en día, como para capas 1 más pequeñas, que típicamente tienen tarifas muy bajas mientras su base de usuarios permanece pequeña.
Una pregunta natural que surge es: ¿cuál de estos complicados compromisos entre rollups, validiums y otros sistemas tiene sentido para una aplicación dada?
Rollups vs validiums vs sistemas desconectados
La primera dimensión de seguridad versus escalabilidad que exploraremos se puede describir de la siguiente manera: si tienes un activo que se emite en L1, luego se deposita en L2 y luego se te transfiere, ¿qué nivel de garantía tienes de que podrás llevar el activo de vuelta a L1?
También hay una pregunta paralela: ¿cuál es la elección tecnológica que resulta en ese nivel de garantía y cuáles son los compromisos de esa elección tecnológica?
Podemos describir esto simplemente usando el siguiente cuadro:
Vale la pena mencionar que este es un esquema simplificado, y hay muchas opciones intermedias. Por ejemplo:
Entre rollup y validium: un validium donde cualquiera podría realizar un pago en cadena para cubrir el costo de las tarifas de transacción, momento en el cual el operador se vería obligado a proporcionar algunos datos en la cadena o de lo contrario perder un depósito.
Entre plasma y validium: un sistema Plasma ofrece garantías de seguridad similares a las de un rollup con disponibilidad de datos fuera de la cadena, pero solo soporta un número limitado de aplicaciones. Un sistema podría ofrecer una EVM completa y ofrecer garantías al nivel de Plasma a los usuarios que no usen esas aplicaciones más complicadas, y garantías al nivel de validium a los usuarios que sí las usen.
Estas opciones intermedias pueden verse como un espectro entre un rollup y un validium. Pero, ¿qué motiva a las aplicaciones a elegir un punto particular en ese espectro, y no algún punto más a la izquierda o más a la derecha? Aquí hay dos factores principales:
El costo de la disponibilidad de datos nativa de Ethereum, que disminuirá con el tiempo a medida que la tecnología mejore. La próxima actualización importante de Ethereum, Dencun, introduce EIP-4844 (también conocido como "proto-danksharding"), que proporciona aproximadamente 32 kB/seg de disponibilidad de datos en cadena. En los próximos años, se espera que esto aumente por etapas a medida que se implemente completamente el danksharding, apuntando eventualmente a alrededor de ~1.3 MB/seg de disponibilidad de datos. Al mismo tiempo, las mejoras en la compresión de datos nos permitirán hacer más con la misma cantidad de datos.
Las propias necesidades de la aplicación: ¿cuánto sufrirían los usuarios por tarifas altas, en comparación con algo que salga mal en la aplicación? Las aplicaciones financieras perderían más por fallos en la aplicación; los juegos y las redes sociales implican mucha actividad por usuario, y actividad de relativamente bajo valor, por lo que un compromiso de seguridad diferente tiene sentido para ellos.
Aproximadamente, este compromiso parece algo así:
Otro tipo de garantía parcial que vale la pena mencionar son las pre-confirmaciones. Las pre-confirmaciones son mensajes firmados por algún conjunto de participantes en un rollup o validium que dicen "atestiguamos que estas transacciones están incluidas en este orden, y la raíz del estado posterior es esta". Estos participantes bien pueden firmar una pre-confirmación que no coincida con alguna realidad posterior, pero si lo hacen, se quema un depósito. Esto es útil para aplicaciones de bajo valor como los pagos al consumidor, mientras que aplicaciones de mayor valor como las transferencias financieras de millones de dólares probablemente esperarán una "confirmación regular" respaldada por la seguridad completa del sistema.
Las pre-confirmaciones pueden verse como otro ejemplo de un sistema híbrido, similar al "híbrido plasma/validium" mencionado anteriormente, pero esta vez hibridando entre un rollup (o validium) que tiene seguridad completa pero alta latencia, y un sistema con un nivel de seguridad mucho más bajo que tiene baja latencia. Las aplicaciones que necesitan menor latencia obtienen menor seguridad, pero pueden vivir en el mismo ecosistema que aplicaciones que están bien con una latencia más alta a cambio de la máxima seguridad.
Lectura sin confianza de Ethereum
Otra forma de conexión menos pensada, pero aún altamente importante, tiene que ver con la capacidad de un sistema para leer la cadena de bloques de Ethereum. Particularmente, esto incluye poder revertir si Ethereum se revierte. Para entender por qué esto es valioso, considera la siguiente situación:
Supongamos que, como se muestra en el diagrama, la cadena de Ethereum se revierte. Esto podría ser un contratiempo temporal dentro de una época, mientras la cadena no ha finalizado, o podría ser un período de fuga de inactividad donde la cadena no está finalizando durante una duración extendida porque demasiados validadores están desconectados.
El peor escenario que puede surgir de esto es el siguiente. Supongamos que el primer bloque de la cadena superior lee algunos datos del bloque más a la izquierda en la cadena de Ethereum. Por ejemplo, alguien en Ethereum deposita 100 ETH en la cadena superior. Luego, Ethereum se revierte. Sin embargo, la cadena superior no se revierte. Como resultado, los bloques futuros de la cadena superior siguen correctamente los nuevos bloques de la cadena de Ethereum ahora correcta, pero las consecuencias del enlace anterior ahora erróneo (es decir, el depósito de 100 ETH) siguen siendo parte de la cadena superior. Este exploit podría permitir la creación de dinero, convirtiendo el ETH puenteado en la cadena superior en una reserva fraccional.
Hay dos formas de resolver este problema:
La cadena superior podría leer solo los bloques finalizados de Ethereum, por lo que nunca necesitaría revertirse.
La cadena superior podría revertirse si Ethereum se revierte. Ambos evitan este problema. El primero es más fácil de implementar, pero puede causar una pérdida de funcionalidad durante una duración extendida si Ethereum entra en un período de fuga de inactividad. El segundo es más difícil de implementar, pero asegura la mejor funcionalidad posible en todo momento.
Nota que (1) tiene un caso límite. Si un ataque del 51% en Ethereum crea dos nuevos bloques incompatibles que parecen finalizados al mismo tiempo, entonces la cadena superior podría bien bloquearse en el equivocado (es decir, el que el consenso social de Ethereum eventualmente no favorezca), y tendría que revertirse para cambiar al correcto. Se podría argumentar que no hay necesidad de escribir código para manejar este caso de antemano; simplemente se podría manejar mediante un hard-fork de la cadena superior.
La capacidad de una cadena para leer Ethereum sin confianza es valiosa por dos razones:
Reduce los problemas de seguridad involucrados en el puenteo de tokens emitidos en Ethereum (u otras L2s) a esa cadena.
Permite que las billeteras de abstracción de cuenta que utilizan la arquitectura de almacenamiento de claves compartido mantengan de manera segura activos en esa cadena.
(1) Es importante, aunque se podría argumentar que esta necesidad ya es ampliamente reconocida. (2) también es importante, porque significa que puedes tener una billetera que permite cambios de clave fáciles y que mantiene activos en un gran número de cadenas diferentes.
¿Tener un puente te convierte en un validium?
Supongamos que la cadena superior comienza como una cadena separada, y luego alguien coloca en Ethereum un contrato de puente. Un contrato de puente es simplemente un contrato que acepta encabezados de bloque de la cadena superior, verifica que cualquier encabezado enviado tenga un certificado válido que demuestre que fue aceptado por el consenso de la cadena superior, y agrega ese encabezado a una lista. Las aplicaciones pueden construir sobre esto para implementar funcionalidades como depositar y retirar tokens. Una vez que tal puente está en su lugar, ¿proporciona alguna de las garantías de seguridad de activos que mencionamos anteriormente?
¡Hasta ahora, aún no! Por dos razones:
Estamos validando que los bloques fueron firmados, pero no que las transiciones de estado sean correctas. Por lo tanto, si tienes un activo emitido en Ethereum depositado en la cadena superior, y los validadores de la cadena superior se vuelven deshonestos, pueden firmar una transición de estado inválida que robe esos activos.
La cadena superior todavía no tiene forma de leer Ethereum. Por lo tanto, ni siquiera puedes depositar activos nativos de Ethereum en la cadena superior sin depender de algún otro puente de terceros (posiblemente inseguro).
Ahora, hagamos que el puente sea un puente validador: no solo verifica el consenso, sino también una ZK-SNARK que demuestra que el estado de cualquier bloque nuevo se calculó correctamente.
Una vez hecho esto, los validadores de la cadena superior ya no pueden robar tus fondos. Pueden publicar un bloque con datos no disponibles, impidiendo que todos retiren, pero no pueden robar (excepto tratando de extraer un rescate de los usuarios a cambio de revelar los datos que les permitan retirarse). Este es el mismo modelo de seguridad que un validium.
Sin embargo, todavía no hemos resuelto el segundo problema: la cadena superior no puede leer Ethereum.
Para hacer eso, necesitamos hacer una de dos cosas:
Poner un contrato de puente que valide los bloques finalizados de Ethereum dentro de la cadena superior.
Hacer que cada bloque en la cadena superior contenga un hash de un bloque reciente de Ethereum, y tener una regla de elección de bifurcación que haga cumplir los enlaces de hash. Es decir, un bloque de la cadena superior que se vincule a un bloque de Ethereum que no esté en la cadena canónica es en sí mismo no canónico, y si un bloque de la cadena superior se vincula a un bloque de Ethereum que inicialmente era canónico, pero luego se vuelve no canónico, el bloque de la cadena superior también debe volverse no canónico.
¿Es esto suficiente? Resulta que aún no, debido a algunos pequeños casos límite:
¿Qué sucede si Ethereum sufre un ataque del 51%?
¿Cómo manejas las actualizaciones de un hard fork de Ethereum?
¿Cómo manejas las actualizaciones de un hard fork de tu cadena?
Un ataque del 51% en Ethereum tendría consecuencias similares a un ataque del 51% en la cadena superior, pero al revés. Un hard fork de Ethereum corre el riesgo de hacer que el puente de Ethereum dentro de la cadena superior ya no sea válido. Un compromiso social para revertir si Ethereum revierte un bloque finalizado, y para hacer un hard fork si Ethereum hace un hard fork, es la forma más limpia de resolver esto. Tal compromiso bien podría no necesitar ser ejecutado en realidad: podrías tener un gadget de gobernanza en la cadena superior que se active si ve pruebas de un posible ataque o hard fork, y solo hacer un hard fork de la cadena superior si el gadget de gobernanza falla.
La única respuesta viable a (3) es, lamentablemente, tener alguna forma de gadget de gobernanza en Ethereum que pueda hacer que el contrato de puente en Ethereum sea consciente de las actualizaciones de hard fork de la cadena superior.
Resumen: los puentes de validación bidireccionales son casi suficientes para hacer de una cadena un validium. El principal ingrediente restante es un compromiso social de que si algo excepcional sucede en Ethereum que haga que el puente deje de funcionar, la otra cadena hará un hard fork en respuesta.
Conclusiones
Hay dos dimensiones clave para la "conectividad con Ethereum":
Seguridad al retirar a Ethereum
Seguridad al leer Ethereum
Tenga en cuenta que ambas dimensiones tienen cada una dos formas distintas de medirlas (¿así que realmente hay cuatro dimensiones?): la seguridad al retirar se puede medir por (i) nivel de seguridad, y (ii) qué porcentaje de usuarios o casos de uso se benefician del nivel de seguridad más alto, y la seguridad al leer se puede medir por (i) qué tan rápido la cadena puede leer los bloques de Ethereum, particularmente bloques finalizados frente a cualquier bloque, y (ii) la fuerza del compromiso social de la cadena para manejar casos límite como ataques del 51% y hard forks.
Hay valor en proyectos en muchas regiones de este espacio de diseño. Para algunas aplicaciones, la alta seguridad y la conexión estrecha son importantes. Para otras, algo más flexible es aceptable a cambio de una mayor escalabilidad. En muchos casos, comenzar con algo más flexible hoy y pasar a una unión más estrecha durante la próxima década a medida que la tecnología mejora, puede ser lo óptimo.
Last updated
