El ecosistema se ha expandido rápidamente durante el último año. El ecosistema de rollups ZK-EVM, tradicionalmente representado por StarkNet, Arbitrum, Optimism y Scroll, está progresando rápidamente, mejorando su seguridad, y la página L2beat proporciona un buen resumen del estado de cada proyecto.
Además, estamos viendo equipos que construyen sidechains y rollups (por ejemplo, Polygon), algunos proyectos L1 que intentan avanzar hacia la validación (por ejemplo, Celo) e intentos completamente nuevos (por ejemplo, Linea, Zeth...). ）。
Una de las consecuencias inevitables de esto es que vemos que los proyectos L2 tienden a ser más heterogéneos (es decir, "isomerizados"). En criptografía, la "heterogeneidad" se refiere a la coexistencia o mezcla de diferentes tipos de cosas o de diferente naturaleza. Este término se usa a menudo para describir diferentes cadenas de bloques, protocolos, tecnologías o activos que tienen diferentes características, reglas o atributos). Espero que esta tendencia continúe por las siguientes razones:
Actualmente, una serie de proyectos L1 independientes buscan involucrarse más estrechamente con el ecosistema Ethereum y potencialmente transformarse en proyectos L2. Es posible que estos proyectos quieran adoptar un enfoque gradual para la transición. Hacer una transición general inmediata reducirá la facilidad de uso porque la tecnología no está lista para poner todo en un escenario de acumulación. Y en la transición general posterior, puede ser demasiado tarde para sacrificar el impulso y tener sentido práctico.
Algunos proyectos centralizados quieren proporcionar más seguridad a sus usuarios y están explorando vías basadas en blockchain. En muchos casos, estos proyectos pueden haber buscado "cadenas de bloques de consorcio autorizadas" en el pasado. De hecho, es posible que solo necesiten alcanzar el nivel de "semicentralización". Además, suelen tener un rendimiento muy alto, lo que los hace inadecuados para esquemas de acumulación, al menos a corto plazo.
Las aplicaciones no financieras, como los juegos o las redes sociales, quieren estar descentralizadas, pero solo necesitan un cierto nivel de seguridad.
En el caso de las redes sociales, en realidad hay diferentes partes de la aplicación que se abordan de diferentes maneras: las actividades raras y de alto valor, como el registro de nombres de usuario y la recuperación de cuentas, deben realizarse en un esquema de acumulación, pero las actividades frecuentes y de bajo valor, como las publicaciones y las encuestas, requieren menos seguridad, lo cual es un precio aceptable a pagar si la cadena de bloques falla y hace que sus publicaciones desaparezcan; Pero si una falla en la cadena de bloques hace que pierdas tu cuenta, ese es un problema mayor.
Un tema importante es que, si bien las aplicaciones y los usuarios que actualmente se encuentran en Ethereum L1 están dispuestos a pagar tarifas de acumulación más pequeñas pero aún visibles a corto plazo, los usuarios del mundo que no es blockchain están menos dispuestos a hacerlo: si ha pagado anteriormente $ 1, entonces pagar $ 0.10 es más aceptable, y si ha pagado anteriormente $ 0, es difícil de aceptar.
Esto se aplica a las aplicaciones que todavía están centralizadas hoy en día, así como a los proyectos L1 más pequeños que a menudo tienen tarifas extremadamente bajas cuando su base de usuarios es pequeña.
Una pregunta natural es: ¿Cuál de estas complejas compensaciones entre esquemas de acumulación, validiums y otros sistemas es razonable para una aplicación en particular?
Rollups vs Validiums vs S desconectados
La primera dimensión de seguridad y escalabilidad que exploraremos se puede describir de la siguiente manera: Si posee un activo que se emite en L1, luego lo deposita en L2 y luego se lo transfiere, ¿cuánta seguridad tiene de que puede devolver el activo a L1?
También hay una pregunta relacionada: ¿qué elección de tecnología conduce a este nivel de seguridad, y cuáles son las ventajas y desventajas de esa elección de tecnología?
Podemos ilustrar el problema con un diagrama simple:
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/641c1134cde471478d058f6d0e2eaab1.jpg)
Cabe mencionar que se trata de un escenario simplificado en el que existen muchas opciones intermedias. Por ejemplo:
Entre rollup y validium: En validium, cualquiera puede realizar un pago 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: Un sistema de plasma proporciona garantías de seguridad tipo rollup con disponibilidad de datos fuera de la cadena, pero solo admite un número limitado de aplicaciones. Un sistema puede proporcionar una EVM completa con garantías a nivel de plasma para aquellos que no utilizan estas aplicaciones más complejas, así como garantías a nivel de validez para aquellos que utilizan esas aplicaciones.
Estas opciones intermedias se pueden considerar como un espectro entre el rollup y el validium. Pero, ¿qué motiva a la aplicación a elegir un punto específico en ese espectro, en lugar de un punto más a la izquierda o 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 evolucione la tecnología. La próxima bifurcación dura de Ethereum, Dencun, presenta EIP-4844 (también conocido como "proto-danksharding"), que proporciona aproximadamente 32 kB/s de disponibilidad de datos en cadena.
Se espera que esta disponibilidad de datos aumente gradualmente en los próximos años con el despliegue completo de danksharding, con el objetivo final de una disponibilidad de datos 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.
**2. Las necesidades propias de la aplicación: ¿Qué tan grave es la pérdida del usuario en términos de altos costos en relación con el problema con la aplicación? ** Las solicitudes financieras perderán más debido al fracaso de la solicitud; Los juegos y las redes sociales implican mucha actividad de los usuarios y actividades de valor relativamente bajo, por lo que las diferentes compensaciones de seguridad tienen sentido para ellos.
Esta compensación se ve más o menos así:
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/eb26cf8cf9fde9560ac2bdae8828a175.jpg)
Otro tipo que vale la pena mencionar son las preconfirmaciones. Una preconfirmación es un mensaje firmado por un grupo de participantes en un rollup o validium que dice "demostramos que estas transacciones están incluidas en este orden y que la raíz posterior al estado es esta". Estos participantes podrán firmar una preconfirmación que no se corresponda con la realidad, pero si lo hace, sus depósitos serán destruidos.
Esto es útil para aplicaciones de bajo valor, como los pagos de consumidores, mientras que las aplicaciones de alto valor, como las transferencias financieras multimillonarias, pueden esperar una confirmación "regular" respaldada por la integridad de la seguridad del sistema.
La preconfirmación puede verse como otro ejemplo de un sistema híbrido, similar al "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 baja latencia. Las aplicaciones que requieren una latencia más baja recibirán una seguridad más baja, pero pueden coexistir en el mismo ecosistema que aquellas que están dispuestas a tolerar una latencia más alta para obtener la máxima seguridad.
Lectura sin confianza de Ethereum
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. Específicamente, esto incluye la capacidad del sistema para retroceder cuando ocurre Ethereum. Para comprender por qué esto es valioso, considere el siguiente escenario:
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/4de6c8f1f9b77155639e6a286f4162a1.jpg)
Supongamos que se produce un retroceso en la cadena de bloques de Ethereum, como se muestra en el diagrama. Esto puede ser una interrupción temporal dentro de una época en la que la cadena de bloques aún no se ha finalizado; O podría deberse a que demasiados validadores están fuera de línea, lo que resulta en períodos de fuga inactivos que la cadena de bloques no puede finalizar durante un período de tiempo más largo.
El peor de los casos que puede resultar 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 deposita 100 ETH en Ethereum en la cadena superior. Luego, Ethereum retrocedió, pero la cadena superior no lo hizo. Como resultado, los bloques futuros en la cadena superior siguen correctamente los bloques nuevos y correctos en la cadena de bloques de Ethereum, pero la transacción incorrecta (es decir, un depósito de 100 ETH) todavía existe en la cadena superior. Esta vulnerabilidad podría dar lugar a una emisión adicional de monedas, convirtiendo los ETH puenteados en la cadena superior en reservas parciales.
Hay dos formas de resolver este problema:
La cadena superior solo puede leer bloques que han sido finalizados por Ethereum, por lo que nunca es necesario revertirla;
Si se produce un retroceso en Ethereum, también puede producirse un retroceso en la cadena superior. Ambos pueden prevenir este problema. El primero es más fácil de implementar, pero si Ethereum entra en un período de fuga inactivo, puede provocar una pérdida de funcionalidad durante un período prolongado de tiempo. Este último es más difícil de implementar, pero garantiza que siempre tenga las mejores características.
Tenga en cuenta que, de hecho, hay un caso especial para el primer método. Si hay un ataque del 51% a Ethereum, lo que resulta en la aparición de dos nuevos bloques incompatibles al mismo tiempo, los cuales parecen haber sido finalizados, entonces la cadena superior puede elegir el bloque equivocado (es decir, el bloque que el consenso social de Ethereum finalmente no admite) y necesita retroceder para cambiar al bloque correcto. Podría decirse que no es necesario escribir código de antemano para manejar esta situación; Esto se puede manejar haciendo una bifurcación dura de la cadena superior.
Hay dos razones importantes para la capacidad de la cadena de bloques para leer Ethereum sin confianza:
En primer lugar, esta capacidad puede reducir los problemas de seguridad relacionados con el puente de tokens emitidos en Ethereum (u otras soluciones de capa 2) a esa cadena;
En segundo lugar, esta capacidad 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.
A pesar de la controversia, la importancia del primer enfoque es ampliamente reconocida. Una vez más, el segundo método es importante porque significa que puede tener una billetera que puede cambiar fácilmente las claves y mantener activos en muchas cadenas diferentes.
¿Tener un puente hace una validez?
Digamos que la cadena superior se lanzó inicialmente como una cadena independiente, y luego alguien implementó un contrato puente en Ethereum. Un contrato puente es simplemente un contrato que acepta encabezados de bloque de la cadena superior, verificando que los encabezados de bloque que se le envíen vayan acompañados de un certificado válido que demuestre que el encabezado de bloque ha sido aceptado por el consenso de la cadena superior y agrega el encabezado de bloque a la lista.
La aplicación puede crear funciones además de esto, como el depósito y retiro de tokens. Una vez que se establece un puente de este tipo, ¿proporciona alguna de las garantías de seguridad de activos que mencionamos anteriormente?
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/f2e4d6973f59d0520636a41407c9a20a.jpg)
¡Hasta ahora, todavía no! Esto se debe a dos motivos:
Estamos verificando la firma del bloque, pero no estamos verificando que la transición de estado sea correcta. Por lo tanto, si deposita activos emitidos en Ethereum en la cadena superior y el validador de la cadena superior se vuelve deshonesto, puede firmar una transición de estado no válida, robando así esos activos;
La cadena superior sigue siendo Ethereum ilegible. Como resultado, no puedes depositar activos nativos de Ethereum en la cadena superior a menos que dependas de otros puentes de terceros (y potencialmente inseguros).
Ahora, construyamos el puente como un puente validador: no solo verifica el consenso, sino que también verifica que el estado de cualquier bloque nuevo calculado usando pruebas ZK-SNARK sea correcto.
Una vez completado este paso, los validadores de la cadena superior no podrán robar sus fondos. Pueden publicar un bloque que contenga datos inutilizables, impidiendo que todos retiren fondos, pero no pueden robar los fondos (a menos que intenten revelar los datos que permiten a los usuarios retirar sus fondos exigiendo un rescate). Esto tiene el mismo modelo de seguridad que las validiums.
Sin embargo, todavía no hemos resuelto el segundo problema: la cadena superior no puede leer los datos de Ethereum. Para lograr esto, necesitamos hacer una de dos cosas:
Coloque un contrato puente en la cadena superior que valide el bloque de Ethereum finalizado;
Incluya un hash del bloque de Ethereum más reciente en cada bloque de la cadena superior y emplee reglas de selección de bifurcación para hacer cumplir el enlace hash. Es decir, el bloque de la cadena superior en sí mismo que se vinculará a un bloque de Ethereum en una cadena no principal no es una cadena principal. Si el bloque de Ethereum conectado a la cadena de bloques de la cadena superior está inicialmente en la cadena principal, pero luego se convierte en una cadena no principal, el bloque de la cadena superior también debe convertirse en una cadena no principal.
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/5fa31bfce1306e3527691085ad238a99.jpg)
Estos enlaces morados pueden ser enlaces hash o contratos puente que verifican el consenso de Ethereum
¿Es suficiente? En realidad, no es suficiente, porque hay algunos pequeños casos extremos:
¿Qué pasa si Ethereum sufre un ataque del 51%?
¿Cómo lidiar con la actualización de la bifurcación dura de Ethereum?
¿Cómo manejar una actualización 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 sería todo lo contrario. Una bifurcación dura de Ethereum podría invalidar el puente de Ethereum dentro de la cadena superior. Un compromiso social, es decir, si Ethereum restaura un bloque finalizado, se restaurará, y si Ethereum hace una bifurcación dura, será bifurcado duro, es la forma más limpia de resolver este problema.
Es posible que nunca sea necesario hacer cumplir una promesa de este tipo: si el órgano de gobierno de la cadena superior encuentra pruebas de un posible ataque o bifurcación dura, puede activar el órgano de gobernanza y solo bifurcar la cadena superior si el órgano de gobernanza falla.
A la tercera pregunta, la única respuesta viable es tener alguna forma de gobernanza en Ethereum que haga que el contrato puente en Ethereum sea consciente de la actualización de la bifurcación dura de la cadena superior.
Resumen: Un puente de verificación bidireccional es casi suficiente para hacer que una cadena de bloques sea válida. El principal elemento restante es un compromiso social de que si algo inusual le sucede a Ethereum que hace que el contrato puente no funcione correctamente, otra cadena de bloques hará una bifurcación dura en respuesta.
Conclusión
"Conectarse con Ethereum" tiene dos dimensiones clave:
Seguridad de los retiros a Ethereum;
Lee la seguridad de Ethereum.
Ambos son muy importantes y tienen diferentes consideraciones. En ambos casos, hay un continuo:
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/8c582e1b1fa730531869238da7787bbc.jpg)
Tenga en cuenta que cada dimensión se mide de dos maneras diferentes (en realidad hay cuatro): la seguridad extraída se puede medir por (i) el nivel de seguridad y (ii) cuántos usuarios o uso se benefician del nivel más alto de seguridad;
La seguridad de lectura se puede medir por (i) la rapidez con la que el enlace puede leer los bloques de Ethereum y, en particular, cómo el bloque finalizado difiere de cualquier bloque, y (ii) el grado de compromiso del enlace cuando se trata de casos extremos como los ataques del 51% y las bifurcaciones duras.
Hay valor para el proyecto en muchas áreas de este espacio de diseño. Para algunas aplicaciones, un alto nivel de seguridad y una conectividad estrecha son esenciales. Para otras aplicaciones, las condiciones más indulgentes son aceptables para una mayor escalabilidad. En muchos casos, comenzando con condiciones más laxas en la actualidad, una transición gradual hacia un acoplamiento más estrecho durante la próxima década puede ser óptima 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.
Vitalik: Es hora de dejar de discutir, tengo algo que decir sobre la definición de Capa 2
Título original: "Diferentes tipos de capa 2"
Texto: Vitalik Buterin
Compilación: BlockBeats
El ecosistema se ha expandido rápidamente durante el último año. El ecosistema de rollups ZK-EVM, tradicionalmente representado por StarkNet, Arbitrum, Optimism y Scroll, está progresando rápidamente, mejorando su seguridad, y la página L2beat proporciona un buen resumen del estado de cada proyecto.
Además, estamos viendo equipos que construyen sidechains y rollups (por ejemplo, Polygon), algunos proyectos L1 que intentan avanzar hacia la validación (por ejemplo, Celo) e intentos completamente nuevos (por ejemplo, Linea, Zeth...). ）。
Una de las consecuencias inevitables de esto es que vemos que los proyectos L2 tienden a ser más heterogéneos (es decir, "isomerizados"). En criptografía, la "heterogeneidad" se refiere a la coexistencia o mezcla de diferentes tipos de cosas o de diferente naturaleza. Este término se usa a menudo para describir diferentes cadenas de bloques, protocolos, tecnologías o activos que tienen diferentes características, reglas o atributos). Espero que esta tendencia continúe por las siguientes razones:
Actualmente, una serie de proyectos L1 independientes buscan involucrarse más estrechamente con el ecosistema Ethereum y potencialmente transformarse en proyectos L2. Es posible que estos proyectos quieran adoptar un enfoque gradual para la transición. Hacer una transición general inmediata reducirá la facilidad de uso porque la tecnología no está lista para poner todo en un escenario de acumulación. Y en la transición general posterior, puede ser demasiado tarde para sacrificar el impulso y tener sentido práctico.
Algunos proyectos centralizados quieren proporcionar más seguridad a sus usuarios y están explorando vías basadas en blockchain. En muchos casos, estos proyectos pueden haber buscado "cadenas de bloques de consorcio autorizadas" en el pasado. De hecho, es posible que solo necesiten alcanzar el nivel de "semicentralización". Además, suelen tener un rendimiento muy alto, lo que los hace inadecuados para esquemas de acumulación, al menos a corto plazo.
Las aplicaciones no financieras, como los juegos o las redes sociales, quieren estar descentralizadas, pero solo necesitan un cierto nivel de seguridad.
En el caso de las redes sociales, en realidad hay diferentes partes de la aplicación que se abordan de diferentes maneras: las actividades raras y de alto valor, como el registro de nombres de usuario y la recuperación de cuentas, deben realizarse en un esquema de acumulación, pero las actividades frecuentes y de bajo valor, como las publicaciones y las encuestas, requieren menos seguridad, lo cual es un precio aceptable a pagar si la cadena de bloques falla y hace que sus publicaciones desaparezcan; Pero si una falla en la cadena de bloques hace que pierdas tu cuenta, ese es un problema mayor.
Un tema importante es que, si bien las aplicaciones y los usuarios que actualmente se encuentran en Ethereum L1 están dispuestos a pagar tarifas de acumulación más pequeñas pero aún visibles a corto plazo, los usuarios del mundo que no es blockchain están menos dispuestos a hacerlo: si ha pagado anteriormente $ 1, entonces pagar $ 0.10 es más aceptable, y si ha pagado anteriormente $ 0, es difícil de aceptar.
Esto se aplica a las aplicaciones que todavía están centralizadas hoy en día, así como a los proyectos L1 más pequeños que a menudo tienen tarifas extremadamente bajas cuando su base de usuarios es pequeña.
Una pregunta natural es: ¿Cuál de estas complejas compensaciones entre esquemas de acumulación, validiums y otros sistemas es razonable para una aplicación en particular?
Rollups vs Validiums vs S desconectados
La primera dimensión de seguridad y escalabilidad que exploraremos se puede describir de la siguiente manera: Si posee un activo que se emite en L1, luego lo deposita en L2 y luego se lo transfiere, ¿cuánta seguridad tiene de que puede devolver el activo a L1?
También hay una pregunta relacionada: ¿qué elección de tecnología conduce a este nivel de seguridad, y cuáles son las ventajas y desventajas de esa elección de tecnología?
Podemos ilustrar el problema con un diagrama simple:
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/641c1134cde471478d058f6d0e2eaab1.jpg)
Cabe mencionar que se trata de un escenario simplificado en el que existen muchas opciones intermedias. Por ejemplo:
Entre rollup y validium: En validium, cualquiera puede realizar un pago 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: Un sistema de plasma proporciona garantías de seguridad tipo rollup con disponibilidad de datos fuera de la cadena, pero solo admite un número limitado de aplicaciones. Un sistema puede proporcionar una EVM completa con garantías a nivel de plasma para aquellos que no utilizan estas aplicaciones más complejas, así como garantías a nivel de validez para aquellos que utilizan esas aplicaciones.
Estas opciones intermedias se pueden considerar como un espectro entre el rollup y el validium. Pero, ¿qué motiva a la aplicación a elegir un punto específico en ese espectro, en lugar de un punto más a la izquierda o 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 evolucione la tecnología. La próxima bifurcación dura de Ethereum, Dencun, presenta EIP-4844 (también conocido como "proto-danksharding"), que proporciona aproximadamente 32 kB/s de disponibilidad de datos en cadena.
Se espera que esta disponibilidad de datos aumente gradualmente en los próximos años con el despliegue completo de danksharding, con el objetivo final de una disponibilidad de datos 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.
**2. Las necesidades propias de la aplicación: ¿Qué tan grave es la pérdida del usuario en términos de altos costos en relación con el problema con la aplicación? ** Las solicitudes financieras perderán más debido al fracaso de la solicitud; Los juegos y las redes sociales implican mucha actividad de los usuarios y actividades de valor relativamente bajo, por lo que las diferentes compensaciones de seguridad tienen sentido para ellos.
Esta compensación se ve más o menos así:
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/eb26cf8cf9fde9560ac2bdae8828a175.jpg)
Otro tipo que vale la pena mencionar son las preconfirmaciones. Una preconfirmación es un mensaje firmado por un grupo de participantes en un rollup o validium que dice "demostramos que estas transacciones están incluidas en este orden y que la raíz posterior al estado es esta". Estos participantes podrán firmar una preconfirmación que no se corresponda con la realidad, pero si lo hace, sus depósitos serán destruidos.
Esto es útil para aplicaciones de bajo valor, como los pagos de consumidores, mientras que las aplicaciones de alto valor, como las transferencias financieras multimillonarias, pueden esperar una confirmación "regular" respaldada por la integridad de la seguridad del sistema.
La preconfirmación puede verse como otro ejemplo de un sistema híbrido, similar al "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 baja latencia. Las aplicaciones que requieren una latencia más baja recibirán una seguridad más baja, pero pueden coexistir en el mismo ecosistema que aquellas que están dispuestas a tolerar una latencia más alta para obtener la máxima seguridad.
Lectura sin confianza de Ethereum
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. Específicamente, esto incluye la capacidad del sistema para retroceder cuando ocurre Ethereum. Para comprender por qué esto es valioso, considere el siguiente escenario:
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/4de6c8f1f9b77155639e6a286f4162a1.jpg)
Supongamos que se produce un retroceso en la cadena de bloques de Ethereum, como se muestra en el diagrama. Esto puede ser una interrupción temporal dentro de una época en la que la cadena de bloques aún no se ha finalizado; O podría deberse a que demasiados validadores están fuera de línea, lo que resulta en períodos de fuga inactivos que la cadena de bloques no puede finalizar durante un período de tiempo más largo.
El peor de los casos que puede resultar 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 deposita 100 ETH en Ethereum en la cadena superior. Luego, Ethereum retrocedió, pero la cadena superior no lo hizo. Como resultado, los bloques futuros en la cadena superior siguen correctamente los bloques nuevos y correctos en la cadena de bloques de Ethereum, pero la transacción incorrecta (es decir, un depósito de 100 ETH) todavía existe en la cadena superior. Esta vulnerabilidad podría dar lugar a una emisión adicional de monedas, convirtiendo los ETH puenteados en la cadena superior en reservas parciales.
Hay dos formas de resolver este problema:
La cadena superior solo puede leer bloques que han sido finalizados por Ethereum, por lo que nunca es necesario revertirla;
Si se produce un retroceso en Ethereum, también puede producirse un retroceso en la cadena superior. Ambos pueden prevenir este problema. El primero es más fácil de implementar, pero si Ethereum entra en un período de fuga inactivo, puede provocar una pérdida de funcionalidad durante un período prolongado de tiempo. Este último es más difícil de implementar, pero garantiza que siempre tenga las mejores características.
Tenga en cuenta que, de hecho, hay un caso especial para el primer método. Si hay un ataque del 51% a Ethereum, lo que resulta en la aparición de dos nuevos bloques incompatibles al mismo tiempo, los cuales parecen haber sido finalizados, entonces la cadena superior puede elegir el bloque equivocado (es decir, el bloque que el consenso social de Ethereum finalmente no admite) y necesita retroceder para cambiar al bloque correcto. Podría decirse que no es necesario escribir código de antemano para manejar esta situación; Esto se puede manejar haciendo una bifurcación dura de la cadena superior.
Hay dos razones importantes para la capacidad de la cadena de bloques para leer Ethereum sin confianza:
En primer lugar, esta capacidad puede reducir los problemas de seguridad relacionados con el puente de tokens emitidos en Ethereum (u otras soluciones de capa 2) a esa cadena;
En segundo lugar, esta capacidad 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.
A pesar de la controversia, la importancia del primer enfoque es ampliamente reconocida. Una vez más, el segundo método es importante porque significa que puede tener una billetera que puede cambiar fácilmente las claves y mantener activos en muchas cadenas diferentes.
¿Tener un puente hace una validez?
Digamos que la cadena superior se lanzó inicialmente como una cadena independiente, y luego alguien implementó un contrato puente en Ethereum. Un contrato puente es simplemente un contrato que acepta encabezados de bloque de la cadena superior, verificando que los encabezados de bloque que se le envíen vayan acompañados de un certificado válido que demuestre que el encabezado de bloque ha sido aceptado por el consenso de la cadena superior y agrega el encabezado de bloque a la lista.
La aplicación puede crear funciones además de esto, como el depósito y retiro de tokens. Una vez que se establece un puente de este tipo, ¿proporciona alguna de las garantías de seguridad de activos que mencionamos anteriormente?
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/f2e4d6973f59d0520636a41407c9a20a.jpg)
¡Hasta ahora, todavía no! Esto se debe a dos motivos:
Estamos verificando la firma del bloque, pero no estamos verificando que la transición de estado sea correcta. Por lo tanto, si deposita activos emitidos en Ethereum en la cadena superior y el validador de la cadena superior se vuelve deshonesto, puede firmar una transición de estado no válida, robando así esos activos;
La cadena superior sigue siendo Ethereum ilegible. Como resultado, no puedes depositar activos nativos de Ethereum en la cadena superior a menos que dependas de otros puentes de terceros (y potencialmente inseguros).
Ahora, construyamos el puente como un puente validador: no solo verifica el consenso, sino que también verifica que el estado de cualquier bloque nuevo calculado usando pruebas ZK-SNARK sea correcto.
Una vez completado este paso, los validadores de la cadena superior no podrán robar sus fondos. Pueden publicar un bloque que contenga datos inutilizables, impidiendo que todos retiren fondos, pero no pueden robar los fondos (a menos que intenten revelar los datos que permiten a los usuarios retirar sus fondos exigiendo un rescate). Esto tiene el mismo modelo de seguridad que las validiums.
Sin embargo, todavía no hemos resuelto el segundo problema: la cadena superior no puede leer los datos de Ethereum. Para lograr esto, necesitamos hacer una de dos cosas:
Coloque un contrato puente en la cadena superior que valide el bloque de Ethereum finalizado;
Incluya un hash del bloque de Ethereum más reciente en cada bloque de la cadena superior y emplee reglas de selección de bifurcación para hacer cumplir el enlace hash. Es decir, el bloque de la cadena superior en sí mismo que se vinculará a un bloque de Ethereum en una cadena no principal no es una cadena principal. Si el bloque de Ethereum conectado a la cadena de bloques de la cadena superior está inicialmente en la cadena principal, pero luego se convierte en una cadena no principal, el bloque de la cadena superior también debe convertirse en una cadena no principal.
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/5fa31bfce1306e3527691085ad238a99.jpg)
Estos enlaces morados pueden ser enlaces hash o contratos puente que verifican el consenso de Ethereum
¿Es suficiente? En realidad, no es suficiente, porque hay algunos pequeños casos extremos:
¿Qué pasa si Ethereum sufre un ataque del 51%?
¿Cómo lidiar con la actualización de la bifurcación dura de Ethereum?
¿Cómo manejar una actualización 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 sería todo lo contrario. Una bifurcación dura de Ethereum podría invalidar el puente de Ethereum dentro de la cadena superior. Un compromiso social, es decir, si Ethereum restaura un bloque finalizado, se restaurará, y si Ethereum hace una bifurcación dura, será bifurcado duro, es la forma más limpia de resolver este problema.
Es posible que nunca sea necesario hacer cumplir una promesa de este tipo: si el órgano de gobierno de la cadena superior encuentra pruebas de un posible ataque o bifurcación dura, puede activar el órgano de gobernanza y solo bifurcar la cadena superior si el órgano de gobernanza falla.
A la tercera pregunta, la única respuesta viable es tener alguna forma de gobernanza en Ethereum que haga que el contrato puente en Ethereum sea consciente de la actualización de la bifurcación dura de la cadena superior.
Resumen: Un puente de verificación bidireccional es casi suficiente para hacer que una cadena de bloques sea válida. El principal elemento restante es un compromiso social de que si algo inusual le sucede a Ethereum que hace que el contrato puente no funcione correctamente, otra cadena de bloques hará una bifurcación dura en respuesta.
Conclusión
"Conectarse con Ethereum" tiene dos dimensiones clave:
Seguridad de los retiros a Ethereum;
Lee la seguridad de Ethereum.
Ambos son muy importantes y tienen diferentes consideraciones. En ambos casos, hay un continuo:
! [Vitalik: Es hora de detener las discusiones, tengo algo que decir sobre la definición de Capa 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/8c582e1b1fa730531869238da7787bbc.jpg)
Tenga en cuenta que cada dimensión se mide de dos maneras diferentes (en realidad hay cuatro): la seguridad extraída se puede medir por (i) el nivel de seguridad y (ii) cuántos usuarios o uso se benefician del nivel más alto de seguridad;
La seguridad de lectura se puede medir por (i) la rapidez con la que el enlace puede leer los bloques de Ethereum y, en particular, cómo el bloque finalizado difiere de cualquier bloque, y (ii) el grado de compromiso del enlace cuando se trata de casos extremos como los ataques del 51% y las bifurcaciones duras.
Hay valor para el proyecto en muchas áreas de este espacio de diseño. Para algunas aplicaciones, un alto nivel de seguridad y una conectividad estrecha son esenciales. Para otras aplicaciones, las condiciones más indulgentes son aceptables para una mayor escalabilidad. En muchos casos, comenzando con condiciones más laxas en la actualidad, una transición gradual hacia un acoplamiento más estrecho durante la próxima década puede ser óptima a medida que la tecnología mejora.