Introducción: El subtexto de Blast enfrentando a Capa 2 ortodoxas como Polygon zkEVM podría ser, "¿Preferirían los príncipes, generales y ministros tener a los suyos?" Dado que no todos son lo suficientemente confiables y básicamente dependen del consenso social para garantizar la seguridad, ¿por qué criticar a Blast? La concentración de Capa 2 no es lo suficientemente alta, ¿entonces por qué apresurarse?

Es cierto que la dependencia de Blast de las firmas múltiples 3/5 para controlar las direcciones de recarga ha sido ampliamente criticada, pero la mayoría de Capa 2 también se basa en firmas múltiples para gestionar contratos. Anteriormente, Optimism incluso utilizaba solo una dirección EOA para controlar los permisos de actualización del contrato. En un momento en el que casi todas las Capas 2 principales tienen riesgos de seguridad como la firma múltiple, criticar a Blast por no ser lo suficientemente seguro es más como 'despreciar' un proyecto de minería de oro por parte de los élites técnicos.

Pero aparte de la cuestión de cuál es mejor entre los dos anteriores, la importancia de la existencia de la cadena de bloques es más para resolver el problema de la opacidad de la información en el consenso social/gobernanza democrática. Al abogar por la supremacía de la tecnología, debemos admitir que el consenso social en sí mismo es más importante que la tecnología, es importante porque es la base para garantizar el funcionamiento efectivo de todos los proyectos Web3. En última instancia, la tecnología sirve al consenso social. Un proyecto que no puede ser reconocido por la mayoría de las personas, no importa lo superior que sea la tecnología, es esencialmente solo un apéndice magnífico.

Texto: Recientemente, el nuevo proyecto Blast lanzado por el fundador de Blur se ha vuelto popular en todo Internet. Este protocolo de "interés de activos" bajo la bandera de Capa 2 ha establecido una dirección de recarga en la cadena ETH. Después de que los usuarios depositen fondos en la dirección de Blast, estos fondos se utilizarán para el staking nativo en la red ETH, colocándolos en MakerDAO para ganar interés, etc. Las ganancias se devolverán a los usuarios.

Basándose en la aura del fundador y el atractivo juego, Blast recibió 20 millones de dólares en financiación de inversores liderados por Paradigm, y también atrajo la participación de innumerables inversores minoristas. En menos de 5 días desde su lanzamiento, la dirección de recarga de Blast ha atraído más de 400 millones de dólares en TVL. No es exagerado decir que Blast es como una fuerte dosis de medicina en el largo mercado bajista, despertando instantáneamente el entusiasmo de la gente.

Sin embargo, aunque Blast logró un éxito inicial, también atrajo las dudas de muchos expertos. Por ejemplo, los ingenieros de L2BEAT y Polygon lo dicen sin rodeos: el Blast actual solo despliega el contrato de depósito para recibir recargas en Ethereum. Este contrato se puede actualizar bajo el control de 3/5 firmas múltiples. En otras palabras, la lógica del código del contrato puede ser reescrita, si quieres alfombrar, todavía puedes alfombrar. Al mismo tiempo, Blast solo afirma implementar la estructura Rollup, pero ahora es solo una cáscara vacía, e incluso la función de retiro no se lanzará hasta febrero del próximo año.

La firma múltiple de Capa 2 es un problema de larga data

De hecho, la firma múltiple de contratos de Capa 2 es un problema de larga data. Ya en julio de este año, L2BEAT realizó una encuesta especial sobre la capacidad de actualización del contrato Rollup. La llamada 'capacidad de actualización' significa cambiar la dirección lógica del contrato apuntada por el contrato agente para lograr el efecto de cambiar la lógica del contrato. Si el nuevo contrato modificado contiene lógica maliciosa, los funcionarios de Capa 2 pueden robar los activos de los usuarios.

(Fuente: academia wtf)

Según los datos de L2BEAT, las soluciones de capa 2 actuales como Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM, etc. todas utilizan contratos autorizados de firma múltiple actualizables, que pueden evitar las restricciones de bloqueo temporal y actualizarse inmediatamente. (Puedes leer los artículos anteriores de Geek Web3: El Juego del Crédito: Rollups Controlados por Multifirmas y Comités )

Lo sorprendente es que Optimism solía usar solo una dirección EOA para gestionar las actualizaciones del contrato, e incluso las firmas múltiples solo se agregaron en octubre de este año. En cuanto a Polygon zkEVM, que ha criticado Blast, también puede llevar a cabo una “toma de control de emergencia” del contrato Rollup bajo la autorización de firmas múltiples 6/8, transformando Capa 2 de gobernanza de contratos a gobernanza humana “desnuda”. Curiosamente, el ingeniero de Polygon que criticó a Blast anteriormente también mencionó esto, aunque fue vago.

Entonces, ¿cuál es la importancia de este “modo de emergencia”? ¿Por qué la mayoría de los Rollups se dejan un botón de pánico o una puerta trasera? Según la declaración anterior de Vitalik, Rollup necesita actualizar frecuentemente los contratos desplegados en ETH durante el proceso de iteración. Sin la introducción de medios actualizables como contratos de agencia, será difícil iterar eficientemente.

Además, los contratos inteligentes que albergan una gran cantidad de activos pueden tener errores sutiles, y el equipo de desarrollo de Capa 2 es inevitablemente negligente. Si ciertas vulnerabilidades son explotadas por hackers, se pueden robar una gran cantidad de activos. Por lo tanto, ya sea Capa 2 o protocolos DeFi, a menudo se establece un botón de emergencia, y los "miembros del comité" intervienen cuando es necesario para evitar que ocurran ciertos eventos malignos.

Por supuesto, el comité establecido por la Capa 2 a menudo puede evitar las restricciones de bloqueo de tiempo y actualizar inmediatamente el código del contrato. Desde cierta perspectiva, parecen ser más tabú que los factores externos como los hackers. En otras palabras, en cualquier caso, los contratos inteligentes que albergan grandes cantidades de activos son difíciles de evitar un cierto grado de "suposición de confianza", es decir, se asume que el controlador de firma múltiple detrás del contrato no hace el mal. A menos que el contrato esté diseñado para no ser actualizable y no haya errores que puedan amenazar la seguridad de los activos del usuario.

La situación real es que la Capa 2 principal actual permite que su propio comité actualice inmediatamente el contrato, o introduce restricciones de bloqueo de tiempo relativamente corto (por ejemplo, cualquier persona que quiera actualizar el contrato de dYdX tendrá un retraso de al menos 48 horas). Si se descubre que el comité tiene la intención de incorporar lógica maliciosa en la nueva versión del código del contrato para robar activos, teóricamente los usuarios tendrán tiempo de reacción suficiente para retirar urgentemente sus activos de la Capa 1.

(Para obtener información sobre la retirada forzada y las funciones de la cabina de escape, puede leer nuestro artículo anterior " ¿Qué tan importante son las funciones de retiro forzoso y escape de cabina para la Capa 2?“

(El bloqueo temporal te permite realizar ciertas operaciones después de un retraso)

Pero la clave del problema es que muchas Capa 2 ni siquiera tienen una función de retiro forzado que pueda pasar por alto al Secuenciador. Si los funcionarios de la Capa 2 quieren hacer algo malo, primero pueden hacer que el Secuenciador rechace las solicitudes de retiro de todos, y luego dividir los activos del usuario. Ve al cuenta L2 controlada por los propios funcionarios de la Capa 2. Después, el oficial actualizará el contrato Rollup según sus propias necesidades. Después de que el bloqueo de tiempo haya terminado, todos los activos de los usuarios pueden transferirse a la cadena ETH.

Por supuesto, la situación real puede ser peor de lo que dije, porque la mayoría de los funcionarios de Rollup pueden actualizar contratos sin restricciones de bloqueo de tiempo, lo que significa que las alfombras por valor de cientos de millones de dólares pueden completarse casi al instante.

Una Capa 2 verdaderamente sin confianza debería hacer que la demora en la actualización del contrato sea mayor que la demora en la retirada forzada.

De hecho, para resolver el problema de confianza / seguridad de Capa 2, se deben hacer las siguientes cosas:

Establezca una salida de retiro resistente a la censura en Capa 1, y los usuarios pueden retirar activos directamente de la Capa 2 a la cadena ETH sin permiso del secuenciador. El retraso para el retiro forzado no debe ser demasiado largo, para asegurar que los activos del usuario puedan ser retirados de L2 rápidamente;

Cualquiera que desee actualizar el contrato de Capa 2 debe estar sujeto al límite de retraso de bloqueo temporal, y la actualización del contrato debe tener efecto posterior al retiro obligatorio. Por ejemplo, la actualización del contrato de dYdX ahora tiene un retraso de al menos 48 horas, por lo que el retraso para que el retiro forzado/modo de escape tenga efecto debe reducirse a menos de 48 horas. De esta manera, después de que los usuarios descubran que el equipo del proyecto dYdX quiere incorporar código malicioso en la nueva versión del contrato, pueden retirar sus activos de Capa 2 a Capa 1 antes de que se actualice el contrato.

Actualmente, la gran mayoría de los rollups que han lanzado un mecanismo de cabina de retirada/escape forzada no cumplen las condiciones anteriores. Por ejemplo, la retirada forzada/escape de dYdX tiene un plazo máximo de 7 días, pero el retraso de la actualización del contrato del comité de dYdX es solo de 48 horas. En otras palabras, el comité puede completar la implementación del nuevo contrato antes de que la retirada forzada del usuario entre en vigor. Robar activos antes de que el usuario escape.

Desde esta perspectiva, excepto por Fuel, ZKSpace y Degate, otros Rollups no pueden garantizar que las retiradas forzosas de los usuarios se procesarán antes de la actualización del contrato, y hay un alto grado de suposición de confianza.

Aunque muchos proyectos que utilizan la solución Validium (DA se implementa fuera de la cadena Ethereum) tienen largos retrasos en la actualización del contrato (como 8 días o más), Validium a menudo se basa en los nodos DAC fuera de la cadena para publicar los datos más recientes, y DAC puede lanzar ataques de retención de datos, deshabilitar la función de retiro forzado y, por lo tanto, no cumplir con el modelo de seguridad discutido anteriormente. (Puedes leer nuestro artículo anterior " ¿Despedir a Validium? Reentendiendo la Capa 2 desde la perspectiva del proponente de Danksharding“ )

En este punto, parece que podemos llegar a una conclusión concisa y clara: Las soluciones de Capa 2 que no sean Fuel, ZKSpace y DeGate no son confiables. Los usuarios confían en el partido del proyecto de Capa 2 o en el comité de seguridad establecido por él para no hacer el mal, confían en que los nodos DAC fuera de la cadena no coludan, o confían en que el secuenciador no revise su transacción (rechace su solicitud). Actualmente, solo las tres Capas 2 mencionadas anteriormente cumplen verdaderamente con los requisitos de seguridad, resistencia a la censura y falta de confianza.

La seguridad no solo se logra con la tecnología, sino que también debe introducir el consenso social

De hecho, el tema del que estamos hablando hoy no es nuevo. La esencia de Capa 2 señalada en este artículo depende de la credibilidad del partido del proyecto, lo cual ha sido señalado por innumerables personas. Por ejemplo, los fundadores de Avalanche y Solana han criticado ferozmente esto, pero el problema es que estas suposiciones de confianza que existen en la Capa 2 también existen en la Capa 1 e incluso en todos los proyectos de blockchain.

Por ejemplo, necesitamos asumir que los nodos Validadores que representan 2/3 del peso de la apuesta en la red de Solana no coludan, y necesitamos asumir que los dos principales grupos mineros que representan la mayoría del poder de cómputo de Bitcoin no se unen para lanzar un ataque del 51% para revertir la cadena más larga. Si bien estas suposiciones son difíciles de romper, "difícil" no significa "no se puede."

Una vez que una cadena pública tradicional de capa 1 comete un acto malvado que causa daños a una gran cantidad de activos de usuario, a menudo abandonará la cadena problemática y bifurcará una nueva cadena a través del consenso social (consulte el incidente de DAO en 2016 que llevó a la bifurcación de Ethereum en ETH y ETC). Si alguien intenta una bifurcación maliciosa, todos deben elegir qué bifurcación "más confiable" seguir a través del consenso social. (Por ejemplo, la mayoría de la gente no sigue el partido del proyecto ETHW)

El consenso social es la raíz para garantizar el funcionamiento ordenado de los proyectos de blockchain e incluso los protocolos DeFi que llevan consigo. Incluso los mecanismos de corrección de errores como las auditorías de código de contrato y la divulgación de problemas por parte de los miembros de la comunidad en un proyecto también forman parte del consenso social. Sin embargo, la descentralización lograda únicamente a través de la tecnología a menudo no logra desempeñar su mayor papel y suele quedarse en un nivel teórico.

Lo que realmente entra en juego en momentos críticos suele ser el consenso social que no tiene nada que ver con la tecnología, la supervisión de la opinión pública que no tiene nada que ver con los documentos académicos y el reconocimiento masivo que no tiene nada que ver con las narrativas técnicas.

Podemos imaginar el siguiente escenario: una cadena pública de POW de la que solo unos pocos cientos de personas han oído hablar está temporalmente en un estado altamente descentralizado porque aún no ha habido una situación en la que una empresa sea dominante. Pero si una empresa minera invierte repentinamente toda su potencia informática en la cadena POW, su potencia informática será muchas veces mayor que la de todos los demás mineros. En este momento, la descentralización de esta cadena de POW se colapsará al instante. Si la empresa minera tiene la intención de hacer el mal, las personas solo pueden corregir el error a través del consenso social.

Por otro lado, el llamado Capa 2, por muy sofisticado que sea su diseño de mecanismo, no puede evitar el vínculo del consenso social. Incluso los L2s como Fuel, DeGate y ZKSpace, que son casi imposibles de corromper por parte de los funcionarios, la Capa 1-Ethereum en la que se basan también depende en gran medida del consenso social/supervisión de la opinión pública de la comunidad.

Además, creemos que el contrato no se puede mejorar porque escuchamos las presentaciones de la agencia de auditoría del contrato y L2BEAT, pero estas agencias pueden ser negligentes o mentir. Aunque esta probabilidad es extremadamente baja, tenemos que admitir que se introduce una pequeña suposición de confianza.

Sin embargo, la naturaleza de datos de código abierto de la propia cadena de bloques permite a cualquiera, incluidos los piratas informáticos, comprobar si el contrato contiene lógica maliciosa. De hecho, se ha minimizado la presunción de confianza, lo que reduce en gran medida el costo del consenso social. Si este costo se reduce a un nivel lo suficientemente bajo, podemos optar por defecto a la "falta de confianza".

Por supuesto, excepto por las tres compañías mencionadas anteriormente, otros Capa 2 no tienen ninguna llamada confianza en absoluto. Lo que realmente garantiza la seguridad en momentos críticos sigue siendo el consenso social. El componente técnico a menudo solo sirve para facilitar que las personas lleven a cabo la supervisión del consenso social. Si la tecnología de un proyecto es superior, pero no es ampliamente reconocida y no puede atraer a un gran grupo de la comunidad, entonces su gobernanza descentralizada y el propio consenso social serán difíciles de desarrollar de manera efectiva.

La tecnología es, de hecho, importante, pero más a menudo que no, si puede ser ampliamente reconocida y si puede desarrollar una cultura comunitaria sólida son factores que son más importantes, más valiosos y más propicios para el desarrollo del proyecto que la tecnología.

Podríamos tomar zkRollup como ejemplo. Actualmente, muchos zkRollups solo implementan el sistema de certificación de validez y los datos DA en cadena. Puede demostrar externamente que las transacciones de usuario que maneja y todas las transferencias realizadas son válidas y no están falsificadas por el secuenciador. En "No hay maldad en este asunto de "transición de estado", pero este no es el único escenario en el que los funcionarios de Capa 2 o secuenciadores hacen el mal.

Podemos aproximar que el sistema de prueba ZK básicamente solo reduce en gran medida el costo de la supervisión de las personas de la Capa 2, pero hay muchas cosas que no pueden ser resueltas por la tecnología misma y deben depender de la intervención de la gobernanza humana o del consenso social.

Si los funcionarios de Capa 2 no establecen salidas anticensura como retiros forzados, o si los funcionarios intentan actualizar el contrato e incorporar lógica que pueda robar los activos de los usuarios, los miembros de la comunidad tendrán que depender del consenso social y la fermentación de la opinión pública para corregir errores. En este momento, si la tecnología es superior o no, ya no parece ser lo más importante. En lugar de decir que la tecnología es importante para la seguridad, es más importante decir que el diseño del mecanismo en sí que facilita

Desde Blast, que depende puramente del consenso social para la supervisión, deberíamos observar la relación entre el consenso social y la implementación técnica de manera más directa, en lugar de simplemente juzgar "qué Capa 2 está más cerca de la Capa 2 mencionada por Vitalik que la otra Capa 2" para determinar los méritos de un proyecto. Cuando un proyecto ha ganado reconocimiento y atención de millones de personas, se ha formado un consenso social. No importa si se basa en marketing o narrativa técnica, porque el resultado en sí es más importante que el proceso.

Es cierto que el consenso social en sí mismo es una extensión de la política democrática, y el mundo real ha confirmado las deficiencias de la gobernanza democrática. Sin embargo, la fuente abierta y la transparencia de datos de la cadena de bloques han reducido enormemente el costo del consenso social. Por lo tanto, hay una diferencia esencial en Web3 entre 'gobernar por el hombre' y 'gobernar por el hombre' en los estados soberanos reales.

Si consideramos la cadena de bloques en sí misma como un medio técnico para mejorar los problemas de transparencia de la información en la gobernanza democrática, en lugar de simplemente perseguir la 'confianza lograda puramente por código' que nunca está al alcance, todo parece volverse mucho más optimista y claro. Solo al deshacernos de la arrogancia y los prejuicios inherentes a la élite técnica y abrazar a una audiencia más amplia, el sistema Capa 2 de Ethereum puede convertirse verdaderamente en una infraestructura financiera de clase mundial con una adopción masiva.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [Cuenta oficial de WeChat: Geek Web3]. Todos los derechos de autor pertenecen al autor original [Faust]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y se encargarán de ello rápidamente.
2. Renuncia de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.