! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-17bf55f5b7-dd1a6f-69ad2a.webp)
Un agradecimiento especial a Karl Floersch por los comentarios y la reseña
El ecosistema de la capa 2 de Ethereum se ha expandido rápidamente durante el último año. El ecosistema ZK-EVM Rollup, representado por StarkNet, Arbitrum, Optimism y Scroll, ha hecho grandes avances en la mejora de la seguridad, y la página L2beat proporciona un buen resumen del estado de cada proyecto. Además, hemos visto que algunos equipos que crean cadenas laterales comienzan a crear Rollups (Polygon), algunos proyectos de capa 1 intentan migrar a Validation (Celo) y realizan nuevos esfuerzos (Linea, Zeth, etc.).
Como resultado, los proyectos de capa 2 son cada vez más heterogéneos. Espero que esta tendencia continúe por las siguientes razones:
Algunos proyectos de capa 1 actualmente independientes buscan acercarse al ecosistema de Ethereum y potencialmente convertirse en capa 2. **Estos proyectos pueden requerir una transición gradual. El cambio ahora dará como resultado una disminución en la usabilidad porque la tecnología no está lista para poner todo en el rollup; Pero cambiar demasiado tarde puede costar impulso y es demasiado tarde para tener sentido.
Algunos proyectos centralizados quieren proporcionar a los usuarios más garantías de seguridad y están explorando vías basadas en blockchain. En muchos casos, estos proyectos pueden explorar previamente "cadenas de consorcios autorizados". De hecho, es posible que solo necesiten un nivel de descentralización de "nivel medio". Además, a menudo tienen un rendimiento muy alto, lo que los hace ni siquiera adecuados para rollups, al menos a corto plazo.
Las aplicaciones no financieras, como los juegos o las redes sociales, quieren ser descentralizadas, pero solo necesitan una "capa intermedia" de seguridad. Las redes sociales, por ejemplo, en realidad implican que diferentes partes de la aplicación se manejen de manera diferente: las actividades de baja frecuencia y alto valor, como el registro del nombre de usuario y la recuperación de la cuenta, deben realizarse en Rollup; Las actividades de alta frecuencia y bajo valor, como la publicación y el sondeo, requieren menos seguridad. Si su publicación desaparece debido a una falla en la cadena, ese es un precio aceptable; Pero si la falla de la cadena hace que pierdas tu cuenta, eso es un gran problema.
Un tema importante es que pagar una tarifa de acumulación más pequeña, pero aún visible, es aceptable para las aplicaciones y los usuarios de la capa 1 de Ethereum en este momento, pero no para los usuarios fuera del mundo de la cadena de bloques: si anteriormente pagó $ 1, entonces pagar $ 0.10 es más aceptable; Pero si anteriormente pagó $0, entonces pagar $0.10 es inaceptable. Esto se aplica tanto a las aplicaciones centralizadas actuales como a los proyectos de capa 1 más pequeños, que a menudo tienen tarifas muy bajas con una base de usuarios pequeña.
La pregunta que surge es: ¿Cuál de estas complejas compensaciones entre rollups, validiums y otros sistemas es razonable para una aplicación en particular?
Rollups、Validiums、Desconectados
La primera dimensión de seguridad y escala que exploraremos se puede describir de la siguiente manera: Si posee un activo que se emitió en la Capa 1 y luego lo depositó en la Capa 2 y luego se transfirió a su cuenta, ¿puede estar seguro de que puede devolver ese activo a la Capa 1? **
Al mismo tiempo, hay una pregunta similar: ¿cuáles son las opciones tecnológicas que conducen a esta garantía y cuáles son las compensaciones detrás de estas opciones tecnológicas? **
Simplemente podemos describir el problema usando una tabla:
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-144dab5eab-dd1a6f-69ad2a.webp)
Vale la pena mencionar que esta es una arquitectura simplificada y hay muchos elementos intermedios para elegir. Por ejemplo:
Entre Rollup y Validium: Un tipo de validium que permite a cualquier persona realizar pagos en cadena para cubrir las tarifas de transacción, momento en el que el operador se verá obligado a proporcionar algunos datos a la cadena o perder el depósito.
Entre Plasma y Validium: El sistema Plasma proporciona garantías de seguridad tipo rollup y disponibilidad de datos fuera de la cadena (DA), pero solo admite un número limitado de aplicaciones. Un sistema puede proporcionar una EVM completa y proporcionar garantías de nivel de plasma a los usuarios que no utilizan esas aplicaciones más complejas, y garantías de nivel de validez a los usuarios que utilizan esas aplicaciones.
Estas opciones intermedias pueden verse como un espectro de tecnologías entre los rollups y los validiums. Pero, ¿qué motiva a la aplicación a elegir un punto particular en el pedigrí, en lugar de la extrema izquierda o la extrema derecha? Aquí hay dos factores principales:
El costo de la disponibilidad de datos en Ethereum disminuirá gradualmente a medida que mejore la tecnología. La siguiente bifurcación dura de Ethereum, Dencun, introdujo EIP-4844 (también conocido como "proto-danksharding"), que proporciona un DA en cadena de alrededor de 32 kB/seg. En los próximos años, se espera que este número aumente gradualmente con la implementación completa de danksharding, alcanzando finalmente un objetivo de DA de alrededor de 1,3 MB/s. Al mismo tiempo, las mejoras en la compresión de datos nos permitirán hacer más con la misma cantidad de datos.
Las necesidades de la propia aplicación: ¿Cuánto pierde el usuario debido a las altas tarifas en comparación con los problemas con la aplicación? ** Las aplicaciones financieras pierden más debido a fallas en las aplicaciones; Los juegos y las redes sociales implican una gran cantidad de actividad por usuario y el valor de la actividad es relativamente bajo, por lo que la compensación entre la seguridad es diferente para ellos.
Esta compensación tiene un aspecto similar al siguiente:
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d6d63d0742-dd1a6f-69ad2a.webp)
Otra garantía parcial que vale la pena mencionar son las confirmaciones previas. Una preconfirmación es un mensaje firmado por algunos participantes en un rollup o validium que dice "hemos demostrado que estas transacciones están incluidas en este orden, y que la raíz posterior al estado es esta". Estos participantes pueden firmar una preconfirmación que no se corresponde con la situación real en una fecha posterior; Pero si lo hacen, queman un depósito. Esto es útil para aplicaciones de bajo valor, como los pagos de los consumidores, mientras que las aplicaciones de alto valor, como las transferencias financieras multimillonarias, pueden esperar una confirmación "regular" del soporte de seguridad completo del sistema.
La prevalidación puede verse como otro ejemplo de un sistema híbrido, similar al "sistema híbrido Plasma/Validium" mencionado anteriormente, pero esta vez entre un Rollup (o Validium) con seguridad total pero alta latencia y un sistema con un nivel de seguridad más bajo pero latencia más baja. Las aplicaciones que requieren una latencia más baja obtienen una seguridad más baja, pero pueden coexistir en el mismo ecosistema que las aplicaciones que requieren una latencia más alta a cambio de la máxima seguridad.
Leer Ethereum sin permiso
Otra forma de conexión menos considerada, pero aún muy importante, tiene que ver con la capacidad del sistema para leer la cadena de bloques de Ethereum. En particular, esto incluye la capacidad de retroceder cuando Ethereum necesita retroceder. Para comprender por qué esto es valioso, considere el siguiente escenario:
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-ccbb1fb3ee-dd1a6f-69ad2a.webp)
Supongamos, como se muestra en el diagrama, que se produce una reversión en la cadena Ethereum. Esto podría ser una falla temporal dentro de una época en la que la cadena no se finalizó, o podría ser que la red estaba inactiva y demasiados validadores estaban fuera de línea y la cadena no se finalizó durante un período prolongado de tiempo.
El peor de los casos al que esto puede conducir es el siguiente. Digamos 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 deposita 100 ETH en Ethereum en la cadena superior. A continuación, se produce un retroceso con Ethereum. Sin embargo, no hay retroceso de la cadena superior. Como resultado, el bloque futuro de la cadena superior siguió correctamente el nuevo bloque de la nueva cadena correcta de Ethereum, pero ahora el resultado de la cadena antigua incorrecta (es decir, un depósito de 100 ETH) todavía existe en la cadena superior. Esta vulnerabilidad podría permitir la creación de una moneda que convierta el ETH puenteado en la cadena superior en una reserva parcial.
Hay dos formas de resolver este problema:
La cadena superior solo puede leer los bloques de Ethereum que se han finalizado, por lo que no es necesario realizar una operación de reversión. **
Si se produce un retroceso en Ethereum, la cadena superior también puede retroceder. **
Ambos pueden evitar que esto suceda. El primero es más fácil de implementar, pero puede conducir a una pérdida prolongada de funcionalidad si Ethereum entra en un período de inactividad. Este último es más difícil de implementar, pero siempre garantiza una funcionalidad óptima.
Es importante tener en cuenta que hay un caso especial en el primer método (1). Si un ataque del 51% crea dos bloques incompatibles en Ethereum, y ambos bloques aparecen finalizados al mismo tiempo, entonces la cadena superior puede elegir el bloque equivocado (es decir, el bloque que el consenso de la comunidad de Ethereum finalmente no admite) y debe revertirse para cambiar al bloque correcto. Podría decirse que no es necesario escribir código con anticipación para manejar esta situación; Puede manejar esto haciendo una bifurcación dura de la cadena superior.
La capacidad de las cadenas para leer datos en Ethereum sin permiso es valiosa por las siguientes razones:
Reducir los problemas de seguridad involucrados al encadenar tokens emitidos en Ethereum (u otra capa 2) a esa cadena.
Permite que las billeteras de abstracción de cuentas que utilizan una estructura de almacenamiento de claves compartidas mantengan activos de forma segura en la cadena.
La primera razón es importante, aunque esta importancia ya sea ampliamente reconocida; Y la segunda razón es igual de importante, ya que significa que puede tener una billetera, cambiar fácilmente las claves y mantener activos en muchas cadenas diferentes.
¿Tener un puente hace que la cadena sea válida?
Digamos que la cadena superior comienza como una sola cadena, y luego alguien pone un contrato de cadena cruzada en Ethereum. Un contrato de cadena cruzada es simplemente un contrato que acepta el encabezado de bloque de la cadena superior, verificando que cualquier encabezado enviado a él viene con un certificado válido que indica que es aceptado por el consenso de la cadena superior y agrega ese encabezado a la lista. Las aplicaciones se pueden construir sobre esto para habilitar funciones como depositar y retirar tokens. Una vez que se ha establecido un puente de este tipo, ¿proporciona alguna de las garantías de seguridad de activos que mencionamos anteriormente?
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-77802047aa-dd1a6f-69ad2a.webp)
¡Hasta ahora, todavía no! Esto se debe a dos motivos:
Estamos verificando que el bloque esté firmado, pero no estamos verificando que la transición de estado no sea correcta. Por lo tanto, si emites activos en Ethereum que se depositan en la cadena superior, y los validadores de la cadena superior son pícaros, pueden firmar una transición de estado no válida y robar esos activos.
Todavía no hay forma de que la cadena superior lea los datos de Ethereum. Como resultado, ni siquiera puede depositar activos nativos de Ethereum en la cadena superior sin depender de otros puentes de terceros (y potencialmente inseguros).
Ahora, hagamos del puente un puente de validación: no solo verifica el consenso, sino también un ZK-SNARK que demuestra que el estado de cualquier bloque nuevo se calcula correctamente.
Una vez hecho esto, los validadores de la cadena superior ya no pueden robar sus fondos. Pueden publicar un bloque que contenga datos inutilizables, impidiendo que todos salgan, pero no pueden robarlos (a menos que intenten obtener un rescate para los usuarios a cambio de filtrar datos que les permitan salir). Este es el mismo modelo de seguridad que las validiums.
Sin embargo, todavía no hemos resuelto el segundo problema: la cadena superior no puede leer Ethereum.
Para hacer esto, necesitamos hacer una de dos cosas:
Coloque el contrato de cadena cruzada que valida el bloque final de Ethereum dentro de la cadena superior.
Hacer que cada bloque de la cadena superior contenga el hash del bloque de Ethereum más reciente y tener una regla de elección de bifurcación que aplique el enlace hash. Es decir, el bloque de la cadena superior vinculado a un bloque de Ethereum que no está en la cadena canónica es en sí mismo no canónico, y si la cadena de bloques de la cadena superior está conectada a un bloque de Ethereum que inicialmente era canónico, pero luego se convierte en no canónico, entonces el bloque de la cadena superior también debe convertirse en no canónico.
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-7340ab7dba-dd1a6f-69ad2a.webp)
El enlace púrpura en el diagrama puede ser un enlace hash o un contrato puente que verifica el consenso de Ethereum.
¿Es suficiente? Al final resultó que no fue suficiente, porque hubo algunos pequeños casos especiales:
¿Qué pasa si Ethereum es atacado por el 51%? **
¿Cómo manejar una actualización de hard fork de Ethereum? **
¿Cómo lidiar con una actualización de bifurcación dura de la cadena superior?**
El ataque del 51% de Ethereum tendría consecuencias similares al ataque del 51% de la cadena superior, pero en la dirección opuesta. Una bifurcación dura de Ethereum puede hacer que el puente de Ethereum dentro de la cadena superior ya no sea válido. La solución más limpia a este problema es prometer que si Ethereum revierte un bloque finalizado, la cadena superior también retrocederá, y si Ethereum hace una bifurcación dura, la cadena superior también hará una bifurcación dura. Es posible que nunca sea necesario hacer cumplir una promesa de este tipo: puede activar un mecanismo de gobernanza en la cadena superior y si ve evidencia de un posible ataque o bifurcación dura, y solo hacer una bifurcación dura en la cadena superior si falla el mecanismo de gobernanza.
La única respuesta viable a la pregunta (3) es que tener algún tipo de mecanismo de gobernanza en Ethereum haría que el contrato puente en Ethereum fuera consciente de la actualización de la bifurcación dura de la cadena superior.
Resumen: Un puente de validación bidireccional es casi suficiente para hacer que la cadena sea válida. El principal problema pendiente es que la otra cadena se comprometerá socialmente con una bifurcación dura cuando algo le suceda a Ethereum que haga que el puente no funcione.
Conclusión
Hay dos dimensiones clave para la "conexión a Ethereum":
Seguridad de los retiros a EthereumSeguridad de lectura de datos de Ethereum
Ambas dimensiones son importantes y tienen diferentes consideraciones. En ambos casos, existe un pedigrí:
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-be23ca98bb-dd1a6f-69ad2a.webp)
Tenga en cuenta que cada dimensión se mide de dos maneras diferentes (¿así que en realidad hay cuatro dimensiones?). ): La seguridad de extracción se puede medir por (i) el nivel de seguridad y (ii) el porcentaje de usuarios o casos de uso que se benefician del mayor nivel de seguridad, mientras que la seguridad de lectura se puede medir por (i) que el enlace sea capaz de leer rápidamente los bloques de Ethereum, específicamente la diferencia entre un bloque que se ha finalizado y cualquier bloque, y (ii) la fuerza del compromiso social del enlace cuando se trata de casos extremos como ataques del 51% y hard forks.
Son muchos los proyectos que tienen valor en este espacio de diseño. Para algunas aplicaciones, la alta seguridad y la conectividad estrecha son importantes. Para otras aplicaciones, es aceptable una conectividad más flexible para una mayor escalabilidad. En muchos casos, puede ser mejor comenzar con algunos de los métodos más indulgentes de hoy en día y hacer una transición gradual a conexiones más estrechas durante la próxima década a medida que la tecnología mejora.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
El Papa Vitalinck I redefine la L2
Autor original | Vitalik.eth
Compilar | Odiario 0xAyA
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-17bf55f5b7-dd1a6f-69ad2a.webp)
Un agradecimiento especial a Karl Floersch por los comentarios y la reseña
El ecosistema de la capa 2 de Ethereum se ha expandido rápidamente durante el último año. El ecosistema ZK-EVM Rollup, representado por StarkNet, Arbitrum, Optimism y Scroll, ha hecho grandes avances en la mejora de la seguridad, y la página L2beat proporciona un buen resumen del estado de cada proyecto. Además, hemos visto que algunos equipos que crean cadenas laterales comienzan a crear Rollups (Polygon), algunos proyectos de capa 1 intentan migrar a Validation (Celo) y realizan nuevos esfuerzos (Linea, Zeth, etc.).
Como resultado, los proyectos de capa 2 son cada vez más heterogéneos. Espero que esta tendencia continúe por las siguientes razones:
Algunos proyectos de capa 1 actualmente independientes buscan acercarse al ecosistema de Ethereum y potencialmente convertirse en capa 2. **Estos proyectos pueden requerir una transición gradual. El cambio ahora dará como resultado una disminución en la usabilidad porque la tecnología no está lista para poner todo en el rollup; Pero cambiar demasiado tarde puede costar impulso y es demasiado tarde para tener sentido. Algunos proyectos centralizados quieren proporcionar a los usuarios más garantías de seguridad y están explorando vías basadas en blockchain. En muchos casos, estos proyectos pueden explorar previamente "cadenas de consorcios autorizados". De hecho, es posible que solo necesiten un nivel de descentralización de "nivel medio". Además, a menudo tienen un rendimiento muy alto, lo que los hace ni siquiera adecuados para rollups, al menos a corto plazo. Las aplicaciones no financieras, como los juegos o las redes sociales, quieren ser descentralizadas, pero solo necesitan una "capa intermedia" de seguridad. Las redes sociales, por ejemplo, en realidad implican que diferentes partes de la aplicación se manejen de manera diferente: las actividades de baja frecuencia y alto valor, como el registro del nombre de usuario y la recuperación de la cuenta, deben realizarse en Rollup; Las actividades de alta frecuencia y bajo valor, como la publicación y el sondeo, requieren menos seguridad. Si su publicación desaparece debido a una falla en la cadena, ese es un precio aceptable; Pero si la falla de la cadena hace que pierdas tu cuenta, eso es un gran problema.
Un tema importante es que pagar una tarifa de acumulación más pequeña, pero aún visible, es aceptable para las aplicaciones y los usuarios de la capa 1 de Ethereum en este momento, pero no para los usuarios fuera del mundo de la cadena de bloques: si anteriormente pagó $ 1, entonces pagar $ 0.10 es más aceptable; Pero si anteriormente pagó $0, entonces pagar $0.10 es inaceptable. Esto se aplica tanto a las aplicaciones centralizadas actuales como a los proyectos de capa 1 más pequeños, que a menudo tienen tarifas muy bajas con una base de usuarios pequeña.
La pregunta que surge es: ¿Cuál de estas complejas compensaciones entre rollups, validiums y otros sistemas es razonable para una aplicación en particular?
Rollups、Validiums、Desconectados
La primera dimensión de seguridad y escala que exploraremos se puede describir de la siguiente manera: Si posee un activo que se emitió en la Capa 1 y luego lo depositó en la Capa 2 y luego se transfirió a su cuenta, ¿puede estar seguro de que puede devolver ese activo a la Capa 1? **
Al mismo tiempo, hay una pregunta similar: ¿cuáles son las opciones tecnológicas que conducen a esta garantía y cuáles son las compensaciones detrás de estas opciones tecnológicas? **
Simplemente podemos describir el problema usando una tabla:
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-144dab5eab-dd1a6f-69ad2a.webp)
Vale la pena mencionar que esta es una arquitectura simplificada y hay muchos elementos intermedios para elegir. Por ejemplo:
Estas opciones intermedias pueden verse como un espectro de tecnologías entre los rollups y los validiums. Pero, ¿qué motiva a la aplicación a elegir un punto particular en el pedigrí, en lugar de la extrema izquierda o la extrema derecha? Aquí hay dos factores principales:
El costo de la disponibilidad de datos en Ethereum disminuirá gradualmente a medida que mejore la tecnología. La siguiente bifurcación dura de Ethereum, Dencun, introdujo EIP-4844 (también conocido como "proto-danksharding"), que proporciona un DA en cadena de alrededor de 32 kB/seg. En los próximos años, se espera que este número aumente gradualmente con la implementación completa de danksharding, alcanzando finalmente un objetivo de DA de alrededor de 1,3 MB/s. Al mismo tiempo, las mejoras en la compresión de datos nos permitirán hacer más con la misma cantidad de datos. Las necesidades de la propia aplicación: ¿Cuánto pierde el usuario debido a las altas tarifas en comparación con los problemas con la aplicación? ** Las aplicaciones financieras pierden más debido a fallas en las aplicaciones; Los juegos y las redes sociales implican una gran cantidad de actividad por usuario y el valor de la actividad es relativamente bajo, por lo que la compensación entre la seguridad es diferente para ellos.
Esta compensación tiene un aspecto similar al siguiente:
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d6d63d0742-dd1a6f-69ad2a.webp)
Otra garantía parcial que vale la pena mencionar son las confirmaciones previas. Una preconfirmación es un mensaje firmado por algunos participantes en un rollup o validium que dice "hemos demostrado que estas transacciones están incluidas en este orden, y que la raíz posterior al estado es esta". Estos participantes pueden firmar una preconfirmación que no se corresponde con la situación real en una fecha posterior; Pero si lo hacen, queman un depósito. Esto es útil para aplicaciones de bajo valor, como los pagos de los consumidores, mientras que las aplicaciones de alto valor, como las transferencias financieras multimillonarias, pueden esperar una confirmación "regular" del soporte de seguridad completo del sistema.
La prevalidación puede verse como otro ejemplo de un sistema híbrido, similar al "sistema híbrido Plasma/Validium" mencionado anteriormente, pero esta vez entre un Rollup (o Validium) con seguridad total pero alta latencia y un sistema con un nivel de seguridad más bajo pero latencia más baja. Las aplicaciones que requieren una latencia más baja obtienen una seguridad más baja, pero pueden coexistir en el mismo ecosistema que las aplicaciones que requieren una latencia más alta a cambio de la máxima seguridad.
Leer Ethereum sin permiso
Otra forma de conexión menos considerada, pero aún muy importante, tiene que ver con la capacidad del sistema para leer la cadena de bloques de Ethereum. En particular, esto incluye la capacidad de retroceder cuando Ethereum necesita retroceder. Para comprender por qué esto es valioso, considere el siguiente escenario:
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-ccbb1fb3ee-dd1a6f-69ad2a.webp)
Supongamos, como se muestra en el diagrama, que se produce una reversión en la cadena Ethereum. Esto podría ser una falla temporal dentro de una época en la que la cadena no se finalizó, o podría ser que la red estaba inactiva y demasiados validadores estaban fuera de línea y la cadena no se finalizó durante un período prolongado de tiempo.
El peor de los casos al que esto puede conducir es el siguiente. Digamos 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 deposita 100 ETH en Ethereum en la cadena superior. A continuación, se produce un retroceso con Ethereum. Sin embargo, no hay retroceso de la cadena superior. Como resultado, el bloque futuro de la cadena superior siguió correctamente el nuevo bloque de la nueva cadena correcta de Ethereum, pero ahora el resultado de la cadena antigua incorrecta (es decir, un depósito de 100 ETH) todavía existe en la cadena superior. Esta vulnerabilidad podría permitir la creación de una moneda que convierta el ETH puenteado en la cadena superior en una reserva parcial.
Hay dos formas de resolver este problema:
La cadena superior solo puede leer los bloques de Ethereum que se han finalizado, por lo que no es necesario realizar una operación de reversión. ** Si se produce un retroceso en Ethereum, la cadena superior también puede retroceder. **
Ambos pueden evitar que esto suceda. El primero es más fácil de implementar, pero puede conducir a una pérdida prolongada de funcionalidad si Ethereum entra en un período de inactividad. Este último es más difícil de implementar, pero siempre garantiza una funcionalidad óptima.
Es importante tener en cuenta que hay un caso especial en el primer método (1). Si un ataque del 51% crea dos bloques incompatibles en Ethereum, y ambos bloques aparecen finalizados al mismo tiempo, entonces la cadena superior puede elegir el bloque equivocado (es decir, el bloque que el consenso de la comunidad de Ethereum finalmente no admite) y debe revertirse para cambiar al bloque correcto. Podría decirse que no es necesario escribir código con anticipación para manejar esta situación; Puede manejar esto haciendo una bifurcación dura de la cadena superior.
La capacidad de las cadenas para leer datos en Ethereum sin permiso es valiosa por las siguientes razones:
La primera razón es importante, aunque esta importancia ya sea ampliamente reconocida; Y la segunda razón es igual de importante, ya que significa que puede tener una billetera, cambiar fácilmente las claves y mantener activos en muchas cadenas diferentes.
¿Tener un puente hace que la cadena sea válida?
Digamos que la cadena superior comienza como una sola cadena, y luego alguien pone un contrato de cadena cruzada en Ethereum. Un contrato de cadena cruzada es simplemente un contrato que acepta el encabezado de bloque de la cadena superior, verificando que cualquier encabezado enviado a él viene con un certificado válido que indica que es aceptado por el consenso de la cadena superior y agrega ese encabezado a la lista. Las aplicaciones se pueden construir sobre esto para habilitar funciones como depositar y retirar tokens. Una vez que se ha establecido un puente de este tipo, ¿proporciona alguna de las garantías de seguridad de activos que mencionamos anteriormente?
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-77802047aa-dd1a6f-69ad2a.webp)
¡Hasta ahora, todavía no! Esto se debe a dos motivos:
Estamos verificando que el bloque esté firmado, pero no estamos verificando que la transición de estado no sea correcta. Por lo tanto, si emites activos en Ethereum que se depositan en la cadena superior, y los validadores de la cadena superior son pícaros, pueden firmar una transición de estado no válida y robar esos activos.
Ahora, hagamos del puente un puente de validación: no solo verifica el consenso, sino también un ZK-SNARK que demuestra que el estado de cualquier bloque nuevo se calcula correctamente.
Una vez hecho esto, los validadores de la cadena superior ya no pueden robar sus fondos. Pueden publicar un bloque que contenga datos inutilizables, impidiendo que todos salgan, pero no pueden robarlos (a menos que intenten obtener un rescate para los usuarios a cambio de filtrar datos que les permitan salir). Este es el mismo modelo de seguridad que las validiums.
Sin embargo, todavía no hemos resuelto el segundo problema: la cadena superior no puede leer Ethereum.
Para hacer esto, necesitamos hacer una de dos cosas:
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-7340ab7dba-dd1a6f-69ad2a.webp)
El enlace púrpura en el diagrama puede ser un enlace hash o un contrato puente que verifica el consenso de Ethereum.
¿Es suficiente? Al final resultó que no fue suficiente, porque hubo algunos pequeños casos especiales:
¿Qué pasa si Ethereum es atacado por el 51%? ** ¿Cómo manejar una actualización de hard fork de Ethereum? ** ¿Cómo lidiar con una actualización de bifurcación dura de la cadena superior?**
El ataque del 51% de Ethereum tendría consecuencias similares al ataque del 51% de la cadena superior, pero en la dirección opuesta. Una bifurcación dura de Ethereum puede hacer que el puente de Ethereum dentro de la cadena superior ya no sea válido. La solución más limpia a este problema es prometer que si Ethereum revierte un bloque finalizado, la cadena superior también retrocederá, y si Ethereum hace una bifurcación dura, la cadena superior también hará una bifurcación dura. Es posible que nunca sea necesario hacer cumplir una promesa de este tipo: puede activar un mecanismo de gobernanza en la cadena superior y si ve evidencia de un posible ataque o bifurcación dura, y solo hacer una bifurcación dura en la cadena superior si falla el mecanismo de gobernanza.
La única respuesta viable a la pregunta (3) es que tener algún tipo de mecanismo de gobernanza en Ethereum haría que el contrato puente en Ethereum fuera consciente de la actualización de la bifurcación dura de la cadena superior.
Resumen: Un puente de validación bidireccional es casi suficiente para hacer que la cadena sea válida. El principal problema pendiente es que la otra cadena se comprometerá socialmente con una bifurcación dura cuando algo le suceda a Ethereum que haga que el puente no funcione.
Conclusión
Hay dos dimensiones clave para la "conexión a Ethereum":
Seguridad de los retiros a Ethereum Seguridad de lectura de datos de Ethereum
Ambas dimensiones son importantes y tienen diferentes consideraciones. En ambos casos, existe un pedigrí:
! [El Papa Vitalinck I redefine la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-be23ca98bb-dd1a6f-69ad2a.webp)
Tenga en cuenta que cada dimensión se mide de dos maneras diferentes (¿así que en realidad hay cuatro dimensiones?). ): La seguridad de extracción se puede medir por (i) el nivel de seguridad y (ii) el porcentaje de usuarios o casos de uso que se benefician del mayor nivel de seguridad, mientras que la seguridad de lectura se puede medir por (i) que el enlace sea capaz de leer rápidamente los bloques de Ethereum, específicamente la diferencia entre un bloque que se ha finalizado y cualquier bloque, y (ii) la fuerza del compromiso social del enlace cuando se trata de casos extremos como ataques del 51% y hard forks.
Son muchos los proyectos que tienen valor en este espacio de diseño. Para algunas aplicaciones, la alta seguridad y la conectividad estrecha son importantes. Para otras aplicaciones, es aceptable una conectividad más flexible para una mayor escalabilidad. En muchos casos, puede ser mejor comenzar con algunos de los métodos más indulgentes de hoy en día y hacer una transición gradual a conexiones más estrechas durante la próxima década a medida que la tecnología mejora.