Introducción: desde el declive gradual de Solana y el lanzamiento de Token por parte de OP, Layer2 y Rollup parecen haberse convertido en los nuevos refugios para innumerables practicantes de Web3. A medida que el mercado bajista continúa extendiéndose, FTX está fuera del juego y Multicoin sufre grandes pérdidas, los competidores de Ethereum se han desvanecido gradualmente de la etapa Web3 y han perdido continuamente la confianza para competir con ETH. Más y más personas comenzaron a considerar a Rollup como el núcleo de una nueva ronda de narrativa, y más y más proyectos surgieron en L2 como hongos después de la lluvia.
Pero, ¿es toda esta "falsa prosperidad" o una "burbuja que puede reventar en cualquier momento"? ¿Son Rollup y L2 realmente tan buenos como la mayoría de la gente afirma? ¿Es realmente tan seguro como la gente piensa que es? Sin mencionar que muchos OP Rollups no tienen pruebas de fraude, ¿cuáles son los riesgos de seguridad de **Rollups? **
Inspirado en la "capacidad de actualización de Ethereum L2" lanzada recientemente por L2BEAT, este artículo se centra en los riesgos de confianza del comité y firmas múltiples detrás de la actualización de Rollup (actualizar inmediatamente el contrato de Rollup, quitando los activos del usuario) y los clichés anteriores sobre Rollup. Con reminiscencias de la reciente Multichain, hablaremos sobre por qué L2 no es tan "hermoso" como mucha gente piensa.
Breve descripción del principio de acumulación
Una breve descripción del principio de funcionamiento de Rollup:
**Ethereum Rollup = un conjunto de contratos en los nodos propios de la red Layer1 + Layer2. **
El grupo de nodos de red de Capa 2 se puede dividir en varios tipos de roles, el más importante de los cuales es el secuenciador (Sequencer). Recibe las solicitudes de transacción que ocurren en la Capa 2, determina su orden de ejecución y luego empaqueta la secuencia de la transacción en un lote (Lote), que se envía al contrato del proyecto de resumen en la Capa 1 (en lo sucesivo denominado colectivamente contrato de resumen).
El nodo completo de Layer2 puede obtener directamente la secuencia de transacciones del secuenciador, o leer el lote de transacciones (Batch) enviado por el secuenciador a Layer1, pero este último tiene mayor certeza final (inmutabilidad) que el primero. Por lo general, cuando el secuenciador envía un lote de transacciones a Layer1, el orden del lote de transacciones no se puede cambiar (siempre que no haya una reversión de bloques en Ethereum, la secuencia de transacciones de Rollup no cambiará).
Dado que la ejecución de transacciones cambiará el estado del libro mayor de la cadena de bloques, además del orden de las transacciones, el nodo completo de la Capa 2 también necesita sincronizar el estado del libro mayor con el secuenciador, para garantizar la coherencia.
Por lo tanto, el secuenciador no solo necesita transmitir lotes de transacciones al contrato de resumen de Layer1, sino que también transmite los resultados de la actualización de estado (Stateroot/State diff) después de la ejecución de la transacción a Layer1.
No es difícil ver que L1 (Ethereum) en realidad actúa como un tablón de anuncios para los nodos L2, que es mucho más descentralizado, confiable y más seguro que la propia red de L2. Para los nodos completos de L2, siempre que obtengan la secuencia de transacción de resumen en L1 + el Stateroot inicial, pueden restaurar el libro mayor de la cadena de bloques L2 y calcular el Stateroot más reciente. Si el Stateroot calculado por el nodo completo de L2 es inconsistente con el Stateroot publicado por el secuenciador en L1, significa que el secuenciador tiene fraude.
El caso hipotético más intuitivo es: El secuenciador de L2 puede robar activos del usuario. Por ejemplo, ¿puede falsificar algunas transacciones que no deberían haber ocurrido (ps: transfiera algunos tokens de usuario L2 a la dirección del operador del secuenciador y luego transfiera estos tokens a L1). Este tipo de pregunta se puede resumir en: ¿Qué hacer después de que el secuenciador publica datos de transacción incorrectos o Stateroot incorrecto? **
Para el riesgo de fraude del secuenciador, diferentes tipos de Rollup tienen diferentes contramedidas. Optimistic Rollup (Optimistic Rollup) permite que los nodos completos de L2 proporcionen pruebas de fraude (Fraud Proof), demostrando que los datos liberados por el secuenciador en L1 tienen errores. Por ejemplo, Arbitrum ha configurado una lista blanca de nodos, lo que permite que los nodos L2 en la lista blanca emitan pruebas de fraude.
Además, teniendo en cuenta que la mayoría de los intercambios y las partes privadas de proyectos de puentes entre cadenas ejecutarán nodos completos L2, los errores se pueden encontrar de inmediato, y la tasa de éxito de la mayoría de los secuenciadores de Rollup que roban monedas es básicamente 0 (debido a que debe cobrarse al final, aún debe completarse en el intercambio, o las monedas robadas se pueden transferir a L1 y luego encontrar otra salida).
(El agregador de la figura es en realidad un secuenciador)
Pero para Optimism sin prueba de fraude, el secuenciador puede robar monedas a través del propio contrato de puente de cadena cruzada de Rollup. Por ejemplo, el operador del secuenciador puede falsificar instrucciones de transacción, transferir los activos de otras personas en L2 a su propia dirección y luego transferir las monedas robadas a L1 a través del contrato puente integrado de Rollup. Debido a que no hay prueba de fraude, el nodo completo del OP no puede cuestionar la transacción incorrecta, por lo que, en teoría, el secuenciador del OP puede robar los activos del usuario en L2 (siempre que realmente quiera hacerlo).
La solución a este tipo de problema es "consenso social" (supervisado por la opinión pública, como los miembros de la comunidad y las redes sociales), o **confiar en el respaldo de crédito oficial de OP. **
Curiosamente, un intercambio ha reducido recientemente la demora para que los usuarios de Arbitrum y Optimism transfieran monedas al intercambio (de 100 bloques L2 a 1 bloque L2), lo que en realidad es confiar en que los secuenciadores de ARB y OP no harán nada malo** (por defecto son servidores centralizados con respaldo oficial)**.
A diferencia de Optimista Rollup, además de depender de los nodos completos L2, ZK Rollup resuelve el problema del fraude del secuenciador a través de Validity Proof (a menudo confundido con ZK Proof). Hay un nodo llamado Prover en la red ZK Rollup, que está diseñado para generar pruebas de validez para los lotes de transacciones emitidos por el secuenciador. Al mismo tiempo, existe un contrato (generalmente llamado Verifier) en L1 que verifica específicamente la validez del certificado, siempre que el lote de la transacción y el certificado correspondiente a Stateroot/State diff pasen la verificación del contrato Verifier, se finalizará (Finalizado). El puente oficial de ZK Rollup solo liberará las transacciones de retiro verificadas por el certificado de validez, que obviamente es mucho más confiable que Optimism.
En teoría, la seguridad de OP Rollup está garantizada por nodos completos L2 (al menos un nodo honesto que puede emitir pruebas de fraude). La seguridad de ZK Rollup está garantizada por el contrato Verifier en L1 (la transacción finalmente es confirmada por el nodo L1). En la superficie, todos pueden "heredar la seguridad de L1" (con la ayuda de L1 para completar la confirmación/liquidación final de la transacción), y los maximalistas de Ethereum incluso lo llaman "equivalente a la seguridad de L1" (de acuerdo con la finalidad de los resultados de la transacción de L1), pero la situación real no es el caso, o ni mucho menos.
Esos puntos "cliché"
En primer lugar, la velocidad de generación de prueba de validez de ZK Rollup es extremadamente lenta, el secuenciador puede ejecutar miles de transacciones en 1 segundo, pero puede llevar varias horas como máximo generar Prueba para estas miles de transacciones. Pero este problema también es fácil de resolver. El ZKR convencional básicamente divide las tareas de generación de Pruebas y las envía a diferentes nodos Prover para procesamiento paralelo para aumentar en gran medida la velocidad de generación de Pruebas.
En segundo lugar, es necesario considerar el retraso de los nodos L2 que publican datos en L1. Porque cada vez que el secuenciador o Prover envía datos a L1, habrá un costo fijo (como si se consumiera un contenedor por cada envío). La publicación frecuente de datos en L1 no es rentable o incluso genera pérdidas, por lo que el secuenciador y el probador minimizarán la frecuencia de publicación de datos en L1 y luego empaquetarán y liberarán una gran cantidad de datos a la vez.
En otras palabras, cuando el número de usuarios es insuficiente y el número de transacciones iniciadas es insuficiente, el secuenciador retrasará la liberación de datos a L1. Por ejemplo, cuando había pocos usuarios el año pasado, Optimism solo enviaba un lote de transacciones a L1 cada media hora. Ahora, debido a que la cantidad de usuarios ha aumentado, este problema se ha resuelto de manera efectiva. A diferencia del OP, Starknet ha adoptado un método para reducir la frecuencia de los lanzamientos de diferencias de estado para reducir los costos de datos, lo que hace que el retraso de la confirmación final de la transacción de Starknet se extienda a 7-8 horas.
Además, la mayoría de los ZK Rollups a menudo "agregan muchas pruebas y las envían a L1 al mismo tiempo" para reducir aún más los costos. Es decir, Prover no enviará a L1 inmediatamente después de generar una prueba, sino que esperará a que se generen varias pruebas, las agregará y luego las enviará al contrato Verifier de L1. (De hecho, el proceso de agregar Pruebas es usar una Prueba para incluir los pasos de cálculo generados al verificar múltiples Pruebas)
La consecuencia de esto es que la frecuencia de las liberaciones de prueba se reduce aún más y la demora desde el inicio de la transacción hasta la confirmación final se prolonga aún más.
Según el explorador de bloques, **el retraso en la confirmación de la transacción de Polygon ZKEVM es de aproximadamente 30-50 minutos, y Starknet y Zksync Era son más de 7 horas. **Obviamente, esto es solo "heredar parcialmente la seguridad de L1", que está lejos de la "seguridad equivalente a L1" que dicen los partidarios de Ethereum.
Por supuesto, todos los problemas anteriores pueden resolverse mediante el progreso tecnológico y se realizarán en un futuro próximo. Por ejemplo, muchas partes del proyecto están desarrollando hardware de alto rendimiento para reducir el tiempo de generación de las pruebas de validez; Optimism también promete lanzar pronto un sistema a prueba de fraudes; la solución Danksharding de Ethereum reducirá el costo de datos de Rollup docenas de veces o incluso más, lo que puede resolver de manera efectiva los problemas enumerados anteriormente.
Difícil de resolver el problema del "gobierno del hombre"
Al igual que los proyectos de aplicaciones como Defi, el funcionamiento de la red Rollup depende de los contratos relevantes en L1, y estos contratos son "actualizables", lo que significa que algunos códigos pueden reemplazarse (la mayoría de los Rollups usan contratos proxy) y pueden llevarse a cabo de inmediato bajo la autorización del comité de seguridad o multifirma. Permítanme hablar sobre la conclusión primero: ** Rollup puede cambiar rápidamente el código de contrato en L1 a través de un comité de seguridad o de múltiples firmas controlado por unas pocas personas, y luego robar los activos del usuario. **
En primer lugar, "por qué se debe actualizar el contrato de resumen" y "cómo se actualiza". El código del contrato en Ethereum no se puede cambiar después de la implementación, pero Rollup inevitablemente tiene varios errores durante el proceso de desarrollo, lo que puede conducir a resultados incorrectos; al mismo tiempo, Rollup también está experimentando iteraciones frecuentes del producto y se deben agregar nuevas funciones con frecuencia; en casos más extremos, puede haber piratas informáticos atacando el contrato de Rollup, por lo que el contrato de Rollup debe ser actualizable, lo que a menudo se logra a través de contratos de proxy.
El contrato de proxy es en realidad un método comúnmente utilizado en el desarrollo de contratos de Ethereum, que consiste en separar los datos del contrato de la lógica comercial y almacenarlos en diferentes contratos. Los datos (variables de estado) se almacenan en contratos de proxy y la lógica comercial (funciones) se almacena en contratos lógicos. El contrato de proxy (Proxy) confía el proceso de ejecución de la función al contrato lógico (Implementación) a través de la llamada delegada, y luego devuelve el resultado final a la persona que llama (Caller).
Para actualizar el contrato en el modo proxy, solo necesita apuntar el contrato proxy al nuevo contrato lógico (reescriba la dirección del contrato lógico almacenado en el contrato proxy). **La mayoría de los proyectos de resumen han adoptado este método de actualización de contrato, que puede describirse como simple y grosero. **
No es difícil imaginar que El contrato de Rollup se puede actualizar es en realidad un gran trueno: si el contrato actualizado contiene un código malicioso, como modificar las condiciones de liberación de retiro del contrato Bridge integrado de Rollup, o modificar las condiciones del contrato Verifier para determinar la validez y demostrar la corrección, el secuenciador puede robar monedas (el principio se mencionó anteriormente).
Pero el problema es que no se puede permitir la actualización del contrato Rollup, la razón es muy clara. En general, la gran mayoría de Rollup decidirá si actualizar el contrato de Rollup a través de la gobernanza de DAO, el comité de seguridad o la autorización de múltiples firmas. Además, el bloqueo de tiempo Timelock se utilizará para establecer un período de ventana de retraso para las actualizaciones de contrato.
Teniendo en cuenta que la mayoría de las propuestas de DAO tienen un proceso de ejecución automatizado (implementado a través de contratos en cadena), incluso si se va a actualizar el contrato, primero se deben obtener suficientes votos, y luego la operación de actualización del contrato solo se ejecutará después del retraso especificado por Timelock (a menudo muchos días). Si alguien quiere participar en actualizaciones de contratos maliciosos, debe superar la gobernabilidad de DAO a través de ataques de gobernabilidad (como los ataques de gobernabilidad que ocurrieron en Tornado Cash), pero el costo de hacerlo es muy alto y primero debe obtener suficientes Tokens, que no tendrán éxito en circunstancias normales. Incluso si el ataque de gobernabilidad tiene éxito, debido al bloqueo de tiempo, los usuarios tendrán tiempo suficiente para retirar activos de L2, y **los funcionarios de Rollup tendrán tiempo suficiente para tomar medidas de emergencia. **
Parece que los bloqueos de tiempo son el arma mágica contra las actualizaciones de contratos maliciosos. Pero el problema es que las llamadas "medidas de emergencia que pueden tomar los funcionarios de Rollup" en realidad están pasando por alto la gobernanza de DAO y los bloqueos de tiempo, y actualizan inmediatamente el contrato de Rollup a través de la autorización del comité de seguridad o de varias firmas. Teniendo en cuenta que el Rollup principal actual alberga miles de millones de dólares en activos de los usuarios, la "actualización inmediata del contrato" autorizada por el comité de seguridad y firmas múltiples es la última medida de emergencia, pero también es la espada de Damocles que pende sobre las cabezas de todos los usuarios.
Obviamente, se trata de maximizar la confianza: debe confiar en que los funcionarios de Rollup no tendrán la idea de robar sus activos. Si lo considera desde la perspectiva de Trustless (la perspectiva de Nick Szabo), **todos los Rollups controlados por comités de seguridad y firmas múltiples son inseguros. **Emin Gun Sirer, el fundador de Avalanche, Anatoly, el fundador de Solana, y Justin Bons, la famosa mancha solar, han enfatizado este tipo de problema.
¿Qué Rolllups son manipulados por multigrados/comités?
De acuerdo con el informe "Upgradeability of Ethereum L2s" publicado por la conocida institución de investigación L2 L2 BEAT y el sitio web de visualización de datos L2BEAT, **Arbitrum, Optimism, Loopring (Loopring), ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM y otros paquetes consolidados principales tienen contratos actualizables autorizados por comités o de múltiples firmas, y pueden eludir las restricciones de bloqueo de tiempo. **
Aunque dYdX tiene una dirección EOA que puede omitir el contrato de actualización de la gobernanza de DAO, está limitada por un bloqueo de tiempo (al menos 2 días de retraso). Immutable X tiene un retraso de actualización de contrato de 14 días. Por lo tanto, según L2BEAT, **dYdX e Immutable X son más confiables que otros paquetes acumulativos principales que han lanzado la red principal. **
** Entonces, ¿cómo reducir el riesgo de confianza que conlleva el comité de seguridad y firmas múltiples? **La respuesta es similar al incidente de Multichain: se puede atribuir al problema anti-brujas. Debe garantizarse que los multisigs/comités estén controlados por múltiples entidades diferentes sin un alto grado de superposición de intereses y bajo riesgo de colusión. En la actualidad, parece que no hay una buena manera excepto aumentar la madurez de la gobernanza descentralizada de DAO e invitar a celebridades o instituciones famosas y de buena reputación a participar en el comité/firma múltiple. El escenario anterior parece haber sido común en las democracias del mundo real.
Por supuesto, también es posible limitar el comportamiento de actualización del contrato administrado por el comité/firma múltiple a través del bloqueo de tiempo, pero esto debe sopesarse con muchos factores, porque el propósito del comité/firma múltiple es tratar rápidamente algunas situaciones de emergencia; al mismo tiempo, si la parte del proyecto Rollup no tiene una determinación firme sobre el tema de la falta de confianza, este problema no se puede resolver.
Por lo tanto, aunque diferentes proyectos de Rollup pueden garantizar la seguridad de los activos de los usuarios la mayor parte del tiempo a través del diseño de mecanismos sofisticados, la probabilidad de un evento de cisne negro en Rollup no es cero debido a la existencia de comités y firmas múltiples. Incluso si la probabilidad de colusión de múltiples firmas y miembros del comité es solo de 1 en 10,000, considerando el valor de los activos bajo la custodia de L2 (que se supone que es de 10 mil millones de dólares estadounidenses), el riesgo de los activos de los usuarios de L2 sigue siendo tan alto como 1 millón de dólares estadounidenses por día. Con reminiscencias del incidente de Multichain, es realmente espeluznante.
Así que personalmente creo que, como dijo antes Polynya, la mayoría de los fondos en el ecosistema Ethereum aún tenderán a circular y bloquearse en L1 en lugar de L2, y el ecosistema Rollup no podrá capturar la mayor parte del valor en el ecosistema Ethereum a largo plazo. Para los grandes inversores y las ballenas, la red principal de Ethereum es obviamente un lugar más adecuado y confiable para buscar fondos que L2. Por eso, muchas personas se han planteado “si el auge de L2 supondrá la deserción de L1”, de hecho, ya tienen la respuesta.
Como dijo Keigo Higashino en su libro, el corazón humano es mucho más elusivo, más difícil de entender, más complicado y más difícil de cambiar que las fórmulas matemáticas. Muchas cosas no pueden resolverse por medios puramente técnicos, pero cualquier factor que involucre a la "naturaleza humana" siempre será el problema más incontrolable, impredecible y más grave del mundo. Aquí, por favor, tengamos en cuenta la frase clásica en la lápida de Kant:
"Dos cosas siempre han rodeado mi mente, y cuanto más pienso en ellas, más asombro y asombro me provocan: la ley moral interior y el cielo estrellado arriba.
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 mayor riesgo de confianza de Rollup: el problema de la "regla del hombre" que no se puede ignorar
Autor: Enlace, Geek Web3
Introducción: desde el declive gradual de Solana y el lanzamiento de Token por parte de OP, Layer2 y Rollup parecen haberse convertido en los nuevos refugios para innumerables practicantes de Web3. A medida que el mercado bajista continúa extendiéndose, FTX está fuera del juego y Multicoin sufre grandes pérdidas, los competidores de Ethereum se han desvanecido gradualmente de la etapa Web3 y han perdido continuamente la confianza para competir con ETH. Más y más personas comenzaron a considerar a Rollup como el núcleo de una nueva ronda de narrativa, y más y más proyectos surgieron en L2 como hongos después de la lluvia.
Pero, ¿es toda esta "falsa prosperidad" o una "burbuja que puede reventar en cualquier momento"? ¿Son Rollup y L2 realmente tan buenos como la mayoría de la gente afirma? ¿Es realmente tan seguro como la gente piensa que es? Sin mencionar que muchos OP Rollups no tienen pruebas de fraude, ¿cuáles son los riesgos de seguridad de **Rollups? **
Inspirado en la "capacidad de actualización de Ethereum L2" lanzada recientemente por L2BEAT, este artículo se centra en los riesgos de confianza del comité y firmas múltiples detrás de la actualización de Rollup (actualizar inmediatamente el contrato de Rollup, quitando los activos del usuario) y los clichés anteriores sobre Rollup. Con reminiscencias de la reciente Multichain, hablaremos sobre por qué L2 no es tan "hermoso" como mucha gente piensa.
Breve descripción del principio de acumulación
Una breve descripción del principio de funcionamiento de Rollup:
**Ethereum Rollup = un conjunto de contratos en los nodos propios de la red Layer1 + Layer2. **
El grupo de nodos de red de Capa 2 se puede dividir en varios tipos de roles, el más importante de los cuales es el secuenciador (Sequencer). Recibe las solicitudes de transacción que ocurren en la Capa 2, determina su orden de ejecución y luego empaqueta la secuencia de la transacción en un lote (Lote), que se envía al contrato del proyecto de resumen en la Capa 1 (en lo sucesivo denominado colectivamente contrato de resumen).
El nodo completo de Layer2 puede obtener directamente la secuencia de transacciones del secuenciador, o leer el lote de transacciones (Batch) enviado por el secuenciador a Layer1, pero este último tiene mayor certeza final (inmutabilidad) que el primero. Por lo general, cuando el secuenciador envía un lote de transacciones a Layer1, el orden del lote de transacciones no se puede cambiar (siempre que no haya una reversión de bloques en Ethereum, la secuencia de transacciones de Rollup no cambiará).
Dado que la ejecución de transacciones cambiará el estado del libro mayor de la cadena de bloques, además del orden de las transacciones, el nodo completo de la Capa 2 también necesita sincronizar el estado del libro mayor con el secuenciador, para garantizar la coherencia.
Por lo tanto, el secuenciador no solo necesita transmitir lotes de transacciones al contrato de resumen de Layer1, sino que también transmite los resultados de la actualización de estado (Stateroot/State diff) después de la ejecución de la transacción a Layer1.
No es difícil ver que L1 (Ethereum) en realidad actúa como un tablón de anuncios para los nodos L2, que es mucho más descentralizado, confiable y más seguro que la propia red de L2. Para los nodos completos de L2, siempre que obtengan la secuencia de transacción de resumen en L1 + el Stateroot inicial, pueden restaurar el libro mayor de la cadena de bloques L2 y calcular el Stateroot más reciente. Si el Stateroot calculado por el nodo completo de L2 es inconsistente con el Stateroot publicado por el secuenciador en L1, significa que el secuenciador tiene fraude.
El caso hipotético más intuitivo es: El secuenciador de L2 puede robar activos del usuario. Por ejemplo, ¿puede falsificar algunas transacciones que no deberían haber ocurrido (ps: transfiera algunos tokens de usuario L2 a la dirección del operador del secuenciador y luego transfiera estos tokens a L1). Este tipo de pregunta se puede resumir en: ¿Qué hacer después de que el secuenciador publica datos de transacción incorrectos o Stateroot incorrecto? **
Para el riesgo de fraude del secuenciador, diferentes tipos de Rollup tienen diferentes contramedidas. Optimistic Rollup (Optimistic Rollup) permite que los nodos completos de L2 proporcionen pruebas de fraude (Fraud Proof), demostrando que los datos liberados por el secuenciador en L1 tienen errores. Por ejemplo, Arbitrum ha configurado una lista blanca de nodos, lo que permite que los nodos L2 en la lista blanca emitan pruebas de fraude.
Además, teniendo en cuenta que la mayoría de los intercambios y las partes privadas de proyectos de puentes entre cadenas ejecutarán nodos completos L2, los errores se pueden encontrar de inmediato, y la tasa de éxito de la mayoría de los secuenciadores de Rollup que roban monedas es básicamente 0 (debido a que debe cobrarse al final, aún debe completarse en el intercambio, o las monedas robadas se pueden transferir a L1 y luego encontrar otra salida).
(El agregador de la figura es en realidad un secuenciador)
Pero para Optimism sin prueba de fraude, el secuenciador puede robar monedas a través del propio contrato de puente de cadena cruzada de Rollup. Por ejemplo, el operador del secuenciador puede falsificar instrucciones de transacción, transferir los activos de otras personas en L2 a su propia dirección y luego transferir las monedas robadas a L1 a través del contrato puente integrado de Rollup. Debido a que no hay prueba de fraude, el nodo completo del OP no puede cuestionar la transacción incorrecta, por lo que, en teoría, el secuenciador del OP puede robar los activos del usuario en L2 (siempre que realmente quiera hacerlo).
La solución a este tipo de problema es "consenso social" (supervisado por la opinión pública, como los miembros de la comunidad y las redes sociales), o **confiar en el respaldo de crédito oficial de OP. **
Curiosamente, un intercambio ha reducido recientemente la demora para que los usuarios de Arbitrum y Optimism transfieran monedas al intercambio (de 100 bloques L2 a 1 bloque L2), lo que en realidad es confiar en que los secuenciadores de ARB y OP no harán nada malo** (por defecto son servidores centralizados con respaldo oficial)**.
A diferencia de Optimista Rollup, además de depender de los nodos completos L2, ZK Rollup resuelve el problema del fraude del secuenciador a través de Validity Proof (a menudo confundido con ZK Proof). Hay un nodo llamado Prover en la red ZK Rollup, que está diseñado para generar pruebas de validez para los lotes de transacciones emitidos por el secuenciador. Al mismo tiempo, existe un contrato (generalmente llamado Verifier) en L1 que verifica específicamente la validez del certificado, siempre que el lote de la transacción y el certificado correspondiente a Stateroot/State diff pasen la verificación del contrato Verifier, se finalizará (Finalizado). El puente oficial de ZK Rollup solo liberará las transacciones de retiro verificadas por el certificado de validez, que obviamente es mucho más confiable que Optimism.
En teoría, la seguridad de OP Rollup está garantizada por nodos completos L2 (al menos un nodo honesto que puede emitir pruebas de fraude). La seguridad de ZK Rollup está garantizada por el contrato Verifier en L1 (la transacción finalmente es confirmada por el nodo L1). En la superficie, todos pueden "heredar la seguridad de L1" (con la ayuda de L1 para completar la confirmación/liquidación final de la transacción), y los maximalistas de Ethereum incluso lo llaman "equivalente a la seguridad de L1" (de acuerdo con la finalidad de los resultados de la transacción de L1), pero la situación real no es el caso, o ni mucho menos.
Esos puntos "cliché"
En primer lugar, la velocidad de generación de prueba de validez de ZK Rollup es extremadamente lenta, el secuenciador puede ejecutar miles de transacciones en 1 segundo, pero puede llevar varias horas como máximo generar Prueba para estas miles de transacciones. Pero este problema también es fácil de resolver. El ZKR convencional básicamente divide las tareas de generación de Pruebas y las envía a diferentes nodos Prover para procesamiento paralelo para aumentar en gran medida la velocidad de generación de Pruebas.
En segundo lugar, es necesario considerar el retraso de los nodos L2 que publican datos en L1. Porque cada vez que el secuenciador o Prover envía datos a L1, habrá un costo fijo (como si se consumiera un contenedor por cada envío). La publicación frecuente de datos en L1 no es rentable o incluso genera pérdidas, por lo que el secuenciador y el probador minimizarán la frecuencia de publicación de datos en L1 y luego empaquetarán y liberarán una gran cantidad de datos a la vez.
En otras palabras, cuando el número de usuarios es insuficiente y el número de transacciones iniciadas es insuficiente, el secuenciador retrasará la liberación de datos a L1. Por ejemplo, cuando había pocos usuarios el año pasado, Optimism solo enviaba un lote de transacciones a L1 cada media hora. Ahora, debido a que la cantidad de usuarios ha aumentado, este problema se ha resuelto de manera efectiva. A diferencia del OP, Starknet ha adoptado un método para reducir la frecuencia de los lanzamientos de diferencias de estado para reducir los costos de datos, lo que hace que el retraso de la confirmación final de la transacción de Starknet se extienda a 7-8 horas.
Además, la mayoría de los ZK Rollups a menudo "agregan muchas pruebas y las envían a L1 al mismo tiempo" para reducir aún más los costos. Es decir, Prover no enviará a L1 inmediatamente después de generar una prueba, sino que esperará a que se generen varias pruebas, las agregará y luego las enviará al contrato Verifier de L1. (De hecho, el proceso de agregar Pruebas es usar una Prueba para incluir los pasos de cálculo generados al verificar múltiples Pruebas)
La consecuencia de esto es que la frecuencia de las liberaciones de prueba se reduce aún más y la demora desde el inicio de la transacción hasta la confirmación final se prolonga aún más.
Según el explorador de bloques, **el retraso en la confirmación de la transacción de Polygon ZKEVM es de aproximadamente 30-50 minutos, y Starknet y Zksync Era son más de 7 horas. **Obviamente, esto es solo "heredar parcialmente la seguridad de L1", que está lejos de la "seguridad equivalente a L1" que dicen los partidarios de Ethereum.
Por supuesto, todos los problemas anteriores pueden resolverse mediante el progreso tecnológico y se realizarán en un futuro próximo. Por ejemplo, muchas partes del proyecto están desarrollando hardware de alto rendimiento para reducir el tiempo de generación de las pruebas de validez; Optimism también promete lanzar pronto un sistema a prueba de fraudes; la solución Danksharding de Ethereum reducirá el costo de datos de Rollup docenas de veces o incluso más, lo que puede resolver de manera efectiva los problemas enumerados anteriormente.
Difícil de resolver el problema del "gobierno del hombre"
Al igual que los proyectos de aplicaciones como Defi, el funcionamiento de la red Rollup depende de los contratos relevantes en L1, y estos contratos son "actualizables", lo que significa que algunos códigos pueden reemplazarse (la mayoría de los Rollups usan contratos proxy) y pueden llevarse a cabo de inmediato bajo la autorización del comité de seguridad o multifirma. Permítanme hablar sobre la conclusión primero: ** Rollup puede cambiar rápidamente el código de contrato en L1 a través de un comité de seguridad o de múltiples firmas controlado por unas pocas personas, y luego robar los activos del usuario. **
En primer lugar, "por qué se debe actualizar el contrato de resumen" y "cómo se actualiza". El código del contrato en Ethereum no se puede cambiar después de la implementación, pero Rollup inevitablemente tiene varios errores durante el proceso de desarrollo, lo que puede conducir a resultados incorrectos; al mismo tiempo, Rollup también está experimentando iteraciones frecuentes del producto y se deben agregar nuevas funciones con frecuencia; en casos más extremos, puede haber piratas informáticos atacando el contrato de Rollup, por lo que el contrato de Rollup debe ser actualizable, lo que a menudo se logra a través de contratos de proxy.
El contrato de proxy es en realidad un método comúnmente utilizado en el desarrollo de contratos de Ethereum, que consiste en separar los datos del contrato de la lógica comercial y almacenarlos en diferentes contratos. Los datos (variables de estado) se almacenan en contratos de proxy y la lógica comercial (funciones) se almacena en contratos lógicos. El contrato de proxy (Proxy) confía el proceso de ejecución de la función al contrato lógico (Implementación) a través de la llamada delegada, y luego devuelve el resultado final a la persona que llama (Caller).
Para actualizar el contrato en el modo proxy, solo necesita apuntar el contrato proxy al nuevo contrato lógico (reescriba la dirección del contrato lógico almacenado en el contrato proxy). **La mayoría de los proyectos de resumen han adoptado este método de actualización de contrato, que puede describirse como simple y grosero. **
No es difícil imaginar que El contrato de Rollup se puede actualizar es en realidad un gran trueno: si el contrato actualizado contiene un código malicioso, como modificar las condiciones de liberación de retiro del contrato Bridge integrado de Rollup, o modificar las condiciones del contrato Verifier para determinar la validez y demostrar la corrección, el secuenciador puede robar monedas (el principio se mencionó anteriormente).
Pero el problema es que no se puede permitir la actualización del contrato Rollup, la razón es muy clara. En general, la gran mayoría de Rollup decidirá si actualizar el contrato de Rollup a través de la gobernanza de DAO, el comité de seguridad o la autorización de múltiples firmas. Además, el bloqueo de tiempo Timelock se utilizará para establecer un período de ventana de retraso para las actualizaciones de contrato.
Teniendo en cuenta que la mayoría de las propuestas de DAO tienen un proceso de ejecución automatizado (implementado a través de contratos en cadena), incluso si se va a actualizar el contrato, primero se deben obtener suficientes votos, y luego la operación de actualización del contrato solo se ejecutará después del retraso especificado por Timelock (a menudo muchos días). Si alguien quiere participar en actualizaciones de contratos maliciosos, debe superar la gobernabilidad de DAO a través de ataques de gobernabilidad (como los ataques de gobernabilidad que ocurrieron en Tornado Cash), pero el costo de hacerlo es muy alto y primero debe obtener suficientes Tokens, que no tendrán éxito en circunstancias normales. Incluso si el ataque de gobernabilidad tiene éxito, debido al bloqueo de tiempo, los usuarios tendrán tiempo suficiente para retirar activos de L2, y **los funcionarios de Rollup tendrán tiempo suficiente para tomar medidas de emergencia. **
Parece que los bloqueos de tiempo son el arma mágica contra las actualizaciones de contratos maliciosos. Pero el problema es que las llamadas "medidas de emergencia que pueden tomar los funcionarios de Rollup" en realidad están pasando por alto la gobernanza de DAO y los bloqueos de tiempo, y actualizan inmediatamente el contrato de Rollup a través de la autorización del comité de seguridad o de varias firmas. Teniendo en cuenta que el Rollup principal actual alberga miles de millones de dólares en activos de los usuarios, la "actualización inmediata del contrato" autorizada por el comité de seguridad y firmas múltiples es la última medida de emergencia, pero también es la espada de Damocles que pende sobre las cabezas de todos los usuarios.
Obviamente, se trata de maximizar la confianza: debe confiar en que los funcionarios de Rollup no tendrán la idea de robar sus activos. Si lo considera desde la perspectiva de Trustless (la perspectiva de Nick Szabo), **todos los Rollups controlados por comités de seguridad y firmas múltiples son inseguros. **Emin Gun Sirer, el fundador de Avalanche, Anatoly, el fundador de Solana, y Justin Bons, la famosa mancha solar, han enfatizado este tipo de problema.
¿Qué Rolllups son manipulados por multigrados/comités?
De acuerdo con el informe "Upgradeability of Ethereum L2s" publicado por la conocida institución de investigación L2 L2 BEAT y el sitio web de visualización de datos L2BEAT, **Arbitrum, Optimism, Loopring (Loopring), ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM y otros paquetes consolidados principales tienen contratos actualizables autorizados por comités o de múltiples firmas, y pueden eludir las restricciones de bloqueo de tiempo. **
Aunque dYdX tiene una dirección EOA que puede omitir el contrato de actualización de la gobernanza de DAO, está limitada por un bloqueo de tiempo (al menos 2 días de retraso). Immutable X tiene un retraso de actualización de contrato de 14 días. Por lo tanto, según L2BEAT, **dYdX e Immutable X son más confiables que otros paquetes acumulativos principales que han lanzado la red principal. **
** Entonces, ¿cómo reducir el riesgo de confianza que conlleva el comité de seguridad y firmas múltiples? **La respuesta es similar al incidente de Multichain: se puede atribuir al problema anti-brujas. Debe garantizarse que los multisigs/comités estén controlados por múltiples entidades diferentes sin un alto grado de superposición de intereses y bajo riesgo de colusión. En la actualidad, parece que no hay una buena manera excepto aumentar la madurez de la gobernanza descentralizada de DAO e invitar a celebridades o instituciones famosas y de buena reputación a participar en el comité/firma múltiple. El escenario anterior parece haber sido común en las democracias del mundo real.
Por supuesto, también es posible limitar el comportamiento de actualización del contrato administrado por el comité/firma múltiple a través del bloqueo de tiempo, pero esto debe sopesarse con muchos factores, porque el propósito del comité/firma múltiple es tratar rápidamente algunas situaciones de emergencia; al mismo tiempo, si la parte del proyecto Rollup no tiene una determinación firme sobre el tema de la falta de confianza, este problema no se puede resolver.
Por lo tanto, aunque diferentes proyectos de Rollup pueden garantizar la seguridad de los activos de los usuarios la mayor parte del tiempo a través del diseño de mecanismos sofisticados, la probabilidad de un evento de cisne negro en Rollup no es cero debido a la existencia de comités y firmas múltiples. Incluso si la probabilidad de colusión de múltiples firmas y miembros del comité es solo de 1 en 10,000, considerando el valor de los activos bajo la custodia de L2 (que se supone que es de 10 mil millones de dólares estadounidenses), el riesgo de los activos de los usuarios de L2 sigue siendo tan alto como 1 millón de dólares estadounidenses por día. Con reminiscencias del incidente de Multichain, es realmente espeluznante.
Así que personalmente creo que, como dijo antes Polynya, la mayoría de los fondos en el ecosistema Ethereum aún tenderán a circular y bloquearse en L1 en lugar de L2, y el ecosistema Rollup no podrá capturar la mayor parte del valor en el ecosistema Ethereum a largo plazo. Para los grandes inversores y las ballenas, la red principal de Ethereum es obviamente un lugar más adecuado y confiable para buscar fondos que L2. Por eso, muchas personas se han planteado “si el auge de L2 supondrá la deserción de L1”, de hecho, ya tienen la respuesta.
Como dijo Keigo Higashino en su libro, el corazón humano es mucho más elusivo, más difícil de entender, más complicado y más difícil de cambiar que las fórmulas matemáticas. Muchas cosas no pueden resolverse por medios puramente técnicos, pero cualquier factor que involucre a la "naturaleza humana" siempre será el problema más incontrolable, impredecible y más grave del mundo. Aquí, por favor, tengamos en cuenta la frase clásica en la lápida de Kant:
"Dos cosas siempre han rodeado mi mente, y cuanto más pienso en ellas, más asombro y asombro me provocan: la ley moral interior y el cielo estrellado arriba.