Diferentes tipos de capa 2

Un agradecimiento especial a Karl Floersch por sus comentarios y revisión.

El ecosistema de capa 2 de Ethereum se ha expandido rápidamente durante el último año. El ecosistema acumulativo de EVM, que tradicionalmente presenta Arbitrum, Optimism y Scroll, y más recientemente Kakarot y Taiko, ha progresado rápidamente y ha logrado grandes avances en la mejora de su seguridad; la página L2beat hace un buen trabajo al resumir el estado de cada proyecto. Además, hemos visto equipos que crean cadenas laterales y que también comienzan a crear acumulaciones (Polygon), proyectos de capa 1 que buscan avanzar hacia validiums (Celo) y esfuerzos totalmente nuevos (Linea, Zeth…). Finalmente, está el ecosistema que no es solo EVM: “casi-EVM” 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 a que los proyectos de capa 2 se vuelvan más heterogéneos. Espero que esta tendencia continúe, por algunas razones clave:

• Algunos proyectos que actualmente son capas 1 independientes buscan acercarse al ecosistema Ethereum y posiblemente convertirse en capas 2. Es probable que estos proyectos requieran una transición paso a paso. Hacer la transición ahora de una vez causaría una disminución en la usabilidad, ya que la tecnología aún no está lista para agruparlo todo. Hacer una transición toda de una vez más adelante corre el riesgo de sacrificar el impulso y llegar demasiado tarde para ser significativa.
• Algunos proyectos centralizados quieren brindar a sus usuarios más garantías de seguridad y están explorando rutas basadas en blockchain para lograrlo. En muchos casos, estos son proyectos que habrían explorado “cadenas de consorcio autorizadas” en una era anterior. Siendo realistas, probablemente sólo necesiten un nivel de descentralización “intermedio”. Además, su nivel de rendimiento, a menudo muy alto, los hace inadecuados incluso para acumulaciones, al menos a corto plazo.
• Las aplicaciones no financieras, como los juegos o las redes sociales, quieren estar descentralizadas, pero sólo necesitan un nivel medio de seguridad. En el caso de las redes sociales, esto implica de manera realista tratar diferentes partes de la aplicación de manera diferente: las actividades raras y de alto valor, como el registro de nombre de usuario y la recuperación de cuentas, deben realizarse en un resumen, pero las actividades frecuentes y de bajo valor, como las publicaciones y los votos, necesitan menos seguridad. . Si una falla en la cadena hace que su publicación desaparezca, ese es un costo aceptable. Si una falla en la cadena le hace perder su cuenta, ese es un problema mucho mayor.

Un gran tema es que, si bien las aplicaciones y los usuarios que se encuentran hoy en la capa 1 de Ethereum estarán bien pagando tarifas acumulativas más pequeñas pero aún visibles en el corto plazo, los usuarios del mundo que no es blockchain no lo harán: es más fácil justificar el pago de $0,10 si pagaba $1 antes que si pagaba $0 antes. Esto se aplica tanto a las aplicaciones que hoy están centralizadas como a las capas 1 más pequeñas, que normalmente tienen tarifas muy bajas mientras su base de usuarios sigue siendo pequeña.

Una pregunta natural que surge es: ¿cuál de estas complicadas compensaciones entre resúmenes, validiums y otros sistemas tiene sentido para una aplicación determinada?

Rollups vs validiums vs sistemas desconectados

La primera dimensión de seguridad versus escala que exploraremos se puede describir de la siguiente manera: si tiene un activo que se emite en L1, luego se deposita en L2 y luego se le transfiere, ¿qué nivel de garantía tiene de que será ¿Podrá llevar el activo de vuelta a la L1?

También existe una pregunta paralela: ¿cuál es la elección tecnológica que da como resultado ese nivel de garantía y cuáles son las ventajas y desventajas de esa elección tecnológica?

Podemos describir esto simplemente usando un gráfico:

https://s3.ap-northeast-1.amazonaws.com/gimg.gateimg.com/learn/b05ca283dcc74f262ac7a71f340dc85fb3a13b11.png

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

• Entre rollup y validium: un validium en el que 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 perdería un depósito.
• Entre plasma y validium: un sistema Plasma ofrece garantías de seguridad tipo resumen con disponibilidad de datos fuera de la cadena, pero solo admite una cantidad limitada de aplicaciones. Un sistema podría ofrecer un EVM completo y ofrecer garantías de nivel Plasma a los usuarios que no utilizan esas aplicaciones más complicadas y garantías de nivel Validium a los usuarios que sí lo hacen.

Estas opciones intermedias pueden considerarse como parte de un espectro entre un rollup y un validium. Pero, ¿qué motiva a las aplicaciones a elegir un punto particular de ese espectro y no algún punto más a la izquierda o más a la derecha? Aquí hay dos factores principales:

1. El costo de la disponibilidad de datos nativos de Ethereum, que disminuirá con el tiempo a medida que mejore la tecnología. La próxima bifurcación dura de Ethereum, Dencun, presenta EIP-4844 (también conocido como "proto-danksharding"), que proporciona ~32 kB/seg de disponibilidad de datos en cadena. En los próximos años, se espera que esto aumente gradualmente a medida que se implemente <a href="https://hackmd.io/@vbuterin/sharding_proposal"> danksharding completo, con el objetivo final de alcanzar alrededor de ~1,3 MB/s 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.
2. Las propias necesidades de la aplicación: ¿cuánto sufrirían los usuarios por las altas tarifas, en comparación con si algo en la aplicación saliera mal? Las aplicaciones financieras perderían más por fallas en las aplicaciones; Los juegos y las redes sociales implican mucha actividad por usuario y una actividad de valor relativamente bajo, por lo que para ellos tiene sentido una compensación de seguridad diferente.

Aproximadamente, esta compensación se parece a esto:

Otro tipo de garantía parcial a destacar son las preconfirmaciones. Las preconfirmaciones son mensajes firmados por un conjunto de participantes en un rollup o validium que dicen "damos fe de que estas transacciones están incluidas en este orden, y la raíz posterior al estado es esta". Es posible que estos participantes firmen una preconfirmación que no se corresponda con alguna realidad posterior, pero si lo hacen, se quema un depósito. Esto es útil para aplicaciones de bajo valor, como pagos de consumidores, mientras que aplicaciones de mayor valor, como transferencias financieras multimillonarias, probablemente esperarán una confirmación "regular" respaldada por la seguridad total del sistema.

Las confirmaciones previas 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 total pero alta latencia, y un sistema con una nivel de seguridad mucho más bajo que tiene baja latencia. Las aplicaciones que necesitan una latencia más baja obtienen una seguridad menor, pero pueden vivir en el mismo ecosistema que las aplicaciones que aceptan una latencia más alta a cambio de la máxima seguridad.

Leyendo Ethereum sin confianza

Otra forma de conexión menos considerada, pero aún muy importante, tiene que ver con la capacidad de un sistema para leer la cadena de bloques Ethereum. En particular, esto incluye poder revertir si Ethereum se revierte. Para ver por qué esto es valioso, considere la siguiente situación:

Supongamos que, como se muestra en el diagrama, la cadena Ethereum se revierte. Esto podría ser un problema temporal dentro de una época, mientras la cadena no ha finalizado, o podría ser un período de fuga de inactividad en el que la cadena no finaliza durante un período prolongado porque hay demasiados validadores fuera de línea.

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 de la cadena Ethereum. Por ejemplo, alguien en Ethereum deposita 100 ETH en la cadena superior. Entonces, Ethereum se revierte. Sin embargo, la cadena superior no se revierte. Como resultado, los bloques futuros de la cadena superior siguen correctamente a los nuevos bloques de la cadena Ethereum recientemente correcta, pero las consecuencias del enlace antiguo ahora erróneo (es decir, el depósito de 100 ETH) siguen siendo parte de la cadena superior. Este exploit podría permitir imprimir dinero, convirtiendo el ETH puenteado en la cadena superior en una reserva fraccionaria.

Hay dos formas de resolver este problema:

1. La cadena superior solo podía leer bloques finalizados de Ethereum, por lo que nunca necesitaría revertirse.
2. La cadena superior podría revertirse si Ethereum se revierte. Ambos previenen este problema. El primero es más fácil de implementar, pero puede causar una pérdida de funcionalidad durante un período prolongado si Ethereum entra en un período de fuga de inactividad. Este último es más difícil de implementar, pero garantiza la mejor funcionalidad posible en todo momento.

Tenga en cuenta que (1) tiene un caso límite. Si un ataque del 51% a Ethereum crea dos nuevos bloques incompatibles y ambos parecen finalizados al mismo tiempo, entonces la cadena superior puede bloquearse en la incorrecta (es decir, el que el consenso social de Ethereum finalmente no favorece), y tendría que revertir para cambiar al correcto. Podría decirse que no es necesario escribir código para manejar este caso con anticipación; simplemente podría manejarse bifurcando la cadena superior.

La capacidad de una cadena para leer Ethereum sin confianza es valiosa por dos razones:

1. Reduce los problemas de seguridad involucrados al conectar tokens emitidos en Ethereum (u otros L2) a esa cadena.
2. Permite que las billeteras de abstracción de cuentas que utilizan la arquitectura de almacén de claves compartidas mantengan activos en esa cadena de forma segura.
3. es importante, aunque podría decirse que esta necesidad ya está ampliamente reconocida. (2) también es importante, porque significa que puede tener una billetera que permita cambios de clave fáciles y que contenga activos en una gran cantidad de cadenas diferentes.

¿Tener un puente te convierte en validium?

Supongamos que la cadena superior comienza como una cadena separada y luego alguien coloca en Ethereum un contrato puente. Un contrato puente es simplemente un contrato que acepta encabezados de bloque de la cadena superior, verifica que cualquier encabezado enviado venga con 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 aprovechar esto para implementar funciones como depositar y retirar tokens. Una vez que dicho puente esté instalado, ¿ofrece alguna de las garantías de seguridad de activos que mencionamos anteriormente?

¡Hasta ahora, todavía no! Por dos razones:

1. Estamos validando que los bloques fueron firmados, pero no que las transiciones de estado sean correctas. Por lo tanto, si tiene 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 no válida que robe esos activos.
2. La cadena superior todavía no tiene forma de leer Ethereum. Por lo tanto, ni siquiera se pueden depositar activos nativos de Ethereum en la cadena superior sin depender de algún otro puente de terceros (posiblemente inseguro).

Ahora, hagamos del puente un puente de validación: verifica no solo el consenso, sino también un 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 podrán robar sus fondos. Pueden publicar un bloque con datos no disponibles, impidiendo que todos puedan realizar retiros, pero no pueden robar (excepto intentando extraer un rescate para los usuarios a cambio de revelar los datos que les permiten realizar retiros). 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:

1. Coloque un contrato puente que valide los bloques Ethereum finalizados dentro de la cadena superior.
2. Haga que cada bloque de la cadena superior contenga un hash de un bloque Ethereum reciente y tenga una regla de elección de bifurcación que aplique los enlaces hash. Es decir, un bloque de la cadena superior que se vincula 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 al principio era canónico, pero luego se vuelve no canónico, el bloque de cadena superior también debe volverse no canónico.

Los enlaces morados pueden ser enlaces hash o un contrato puente que verifica el consenso de Ethereum.

¿Es suficiente? Resulta que todavía no, debido a algunos pequeños casos extremos:

1. ¿Qué sucede si Ethereum sufre un ataque del 51%?
2. ¿Cómo se manejan las actualizaciones del hard fork de Ethereum?
3. ¿Cómo maneja las actualizaciones de bifurcación dura de su cadena?

Un ataque del 51% a Ethereum tendría consecuencias similares a un ataque del 51% a la cadena superior, pero a la inversa. Una bifurcación dura 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 de revertir si Ethereum revierte un bloque finalizado, y de realizar una bifurcación dura si Ethereum se bifurca, es la forma más limpia de resolver esto. Es posible que nunca sea necesario ejecutar tal compromiso: se podría activar un dispositivo de gobernanza en la cadena superior si ve pruebas de un posible ataque o bifurcación dura, y solo realizar una bifurcación dura en la cadena superior si el dispositivo de gobernanza falla.

Desafortunadamente, la única respuesta viable a (3) es tener algún tipo de dispositivo de gobernanza en Ethereum que pueda hacer que el contrato puente en Ethereum sea consciente de las actualizaciones 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 el compromiso social de que si sucede algo excepcional en Ethereum que haga que el puente ya no funcione, la otra cadena se bifurcará en respuesta.

Conclusiones

Hay dos dimensiones clave para la "conexión con Ethereum":

1. Seguridad de retirar a Ethereum
2. Seguridad de lectura de Ethereum

Ambos son importantes y tienen diferentes consideraciones. Hay un espectro en ambos casos:

Tenga en cuenta que ambas dimensiones tienen dos formas distintas de medirlas (¿entonces realmente hay cuatro dimensiones?): la seguridad del retiro se puede medir mediante (i) el nivel de seguridad y (ii) qué porcentaje de usuarios o casos de uso se benefician de la seguridad más alta. nivel, y la seguridad de la lectura se puede medir por (i) la rapidez con la que la cadena puede leer los bloques de Ethereum, particularmente los bloques finalizados versus cualquier bloque, y (ii) la fuerza del compromiso social de la cadena para manejar casos extremos como ataques del 51% y bifurcaciones duras.

Hay valor en proyectos en muchas regiones de este espacio de diseño. Para algunas aplicaciones, son importantes una alta seguridad y una conexión estrecha. Para otros, 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 un acoplamiento más estrecho durante la próxima década a medida que la tecnología mejore, puede ser lo óptimo.

Descargo de responsabilidad:

1. Este artículo está reimpreso de [Vitalik Buterin]. Todos los derechos de autor pertenecen al autor original [Vitalik Buterin]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.