Este evento es una victoria del capital, no de los usuarios, y representa un retroceso para el desarrollo de la industria.
Bitcoin a la izquierda, Sui a la derecha, cada movimiento que sacude la industria descentralizada genera una fe más fuerte en Bitcoin.
El mundo no solo necesita un mejor sistema financiero global, sino que siempre habrá un grupo de personas que necesita un espacio de libertad.
Una vez, las cadenas de consorcio eran más populares que las cadenas públicas, precisamente porque satisfacían las necesidades de regulación de esa época. Hoy en día, el declive de las cadenas de consorcio significa que simplemente cumplir con esta necesidad no es realmente lo que los usuarios desean. ¿Entonces, qué herramientas de regulación se necesitan cuando se pierden los usuarios regulados?
Contexto del evento
El 22 de mayo de 2025, el mayor intercambio descentralizado del ecosistema de la cadena pública Sui, (DEX) Cetus, sufrió un ataque de hackers, lo que provocó una caída repentina de la liquidez y el colapso de los precios de varios pares de comercio, con pérdidas que superan los 220 millones de dólares.
Hasta el momento de la publicación, la línea de tiempo es la siguiente:
El 22 de mayo por la mañana, un hacker atacó a Cetus y sustrajo 230 millones de dólares. Cetus suspendió urgentemente el contrato y publicó un anuncio.
El 22 de mayo por la tarde, un hacker transfirió aproximadamente 60 millones de dólares a través de cadenas, mientras que otros 162 millones de dólares siguen en la dirección de la cadena Sui. Los nodos de validación de Sui tomaron medidas rápidamente, agregando la dirección del hacker a la "Lista de Denegación de Servicios (Deny List)" y congelando los fondos.
La noche del 22 de mayo, el CPO de Sui @emanabio tuiteó confirmando: los fondos han sido congelados, la devolución comenzará pronto.
El 23 de mayo, Cetus comenzó a reparar vulnerabilidades y actualizar el contrato.
El 24 de mayo, Sui abrió un PR, explicando que la recuperación de fondos se realizará próximamente a través del mecanismo de alias (aliasing) y la lista blanca (whitelist).
El 26 de mayo, Sui inició la votación de gobernanza en la cadena, proponiendo si se debe ejecutar la actualización del protocolo y transferir los activos del hacker a una dirección de custodia.
El 29 de mayo, se publicaron los resultados de la votación, con más del 2/3 del peso de los nodos de validación apoyando; la actualización del protocolo está lista para ejecutarse.
30 de mayo - principios de junio, la actualización del protocolo entra en vigor, se ejecuta el hash de la transacción designada, los activos del hacker fueron "legalmente transferidos".
Principio del ataque
Principios del evento relacionados, la industria ya tiene varios artículos al respecto, aquí solo se hace un resumen de los principios clave:
Desde la perspectiva del proceso de ataque:
El atacante primero utilizó un préstamo relámpago para pedir prestados aproximadamente 10,024,321.28 haSUI, lo que provocó instantáneamente una caída en el precio del grupo de negociación.
99.90%. Esta enorme orden de venta hizo que el precio del pool objetivo cayera de aproximadamente 1.8956×10^19 a 1.8425×10^19, casi vaciándose por completo.
Luego, el atacante creó posiciones de liquidez en Cetus en un rango extremadamente estrecho (límite inferior de Tick 300000, límite superior 300200, con un ancho de intervalo de solo 1.00496621%). Este rango tan estrecho amplificó el impacto del error de cálculo posterior en la cantidad de tokens requerida.
El principio central del ataque:
En la función get_delta_a de Cetus, que se utiliza para calcular la cantidad de tokens necesarios, existe una vulnerabilidad de desbordamiento de enteros. Un atacante declara intencionalmente que desea agregar una enorme liquidez (aproximadamente 10^37 unidades), pero en realidad solo aporta 1 token al contrato.
Debido a un error en la condición de detección de desbordamiento de checked_shlw, el contrato experimentó un truncamiento de bits altos durante el cálculo de desplazamiento a la izquierda, lo que llevó a que el sistema subestimara gravemente la cantidad de haSUI necesaria, obteniendo así una gran liquidez a un costo mínimo.
Técnicamente, la vulnerabilidad anterior se deriva del uso por parte de Cetus de máscaras y condiciones de juicio incorrectas en el contrato inteligente Move, lo que hace que cualquier valor inferior a 0xffffffffffffffff << 192 pueda eludir la detección; Sin embargo, después de mover 64 bits a la izquierda, los datos de alto nivel se truncan y el sistema solo cobra una cantidad muy pequeña de tokens para considerar que ha ganado mucha liquidez.
Después de que ocurrió el evento, surgieron 2 operaciones oficiales: "Congelar" vs "Recuperar", que son dos fases:
La fase de congelación se completa mediante la Deny List + consenso de nodos;
La fase de recuperación requiere una actualización del protocolo en la cadena + votación de la comunidad + ejecución de transacciones designadas para eludir la lista negra.
El mecanismo de congelación de Sui
La cadena Sui tiene en sí misma una lista de denegación especial ( que implementa el mecanismo de congelación de fondos de este hackeo. No solo eso, en realidad el estándar de token de Sui también tiene un modo de "token regulado", con una función de congelación incorporada.
Esta congelación de emergencia aprovecha esta característica: los nodos validadores agregan rápidamente direcciones relacionadas con fondos robados en sus archivos de configuración locales. Teóricamente, cada operador de nodo puede modificar TransactionDenyConfig para actualizar la lista negra por su cuenta, pero para garantizar la coherencia de la red, la Fundación Sui tiene una coordinación centralizada como editor de la configuración original.
La fundación primero publicó oficialmente una actualización de configuración que contiene la dirección del hacker, los validadores sincronizan y aplican la configuración predeterminada, lo que permite que los fondos del hacker estén temporalmente "sellados" en la cadena, y detrás de esto en realidad hay un alto grado de concentración.
Para rescatar a las víctimas de los fondos congelados, el equipo de Sui lanzó inmediatamente un parche del mecanismo de lista blanca )Whitelist(.
Esta es una operación para la posterior repatriación de fondos. Se pueden construir transacciones legales de antemano y registrarlas en la lista blanca, incluso si la dirección de esos fondos está en la lista negra, se puede ejecutar de manera forzada.
Esta nueva característica, transaction_allow_list_skip_all_checks permite que transacciones específicas se agreguen previamente a la lista "sin censura", de modo que estas transacciones puedan omitir todas las comprobaciones de seguridad, incluidas firmas, permisos, listas negras, etc.
Es importante tener en cuenta que el parche de lista blanca no puede simplemente robar los activos de un hacker; solo otorga a ciertas transacciones la capacidad de eludir el congelamiento, la verdadera transferencia de activos aún requiere una firma legal o un módulo de permisos de sistema adicional para completarse.
En realidad, las soluciones de congelación más comunes en la industria suelen ocurrir a nivel de contratos de tokens y están controladas por múltiples firmas del emisor.
Tomando como ejemplo el USDT emitido por Tether, su contrato tiene una función de lista negra integrada, lo que permite a la empresa emisora congelar direcciones infractoras, impidiéndoles transferir USDT. Este tipo de solución requiere que se inicie una solicitud de congelación en la cadena mediante múltiples firmas, y solo se ejecuta después de que se alcanza un consenso entre los firmantes, lo que genera un retraso en la ejecución.
El mecanismo de congelación de Tether, aunque es efectivo, las estadísticas muestran que el proceso de firma múltiple a menudo presenta "períodos de ventana", lo que deja oportunidades para los delincuentes.
En comparación, el congelamiento de Sui ocurre a nivel del protocolo subyacente, operado colectivamente por los nodos validadores, y su velocidad de ejecución es mucho más rápida que la de una llamada a contrato normal.
En este modelo, para que la ejecución sea lo suficientemente rápida, esto significa que la gestión de estos nodos de validadores debe ser altamente unificada.
Principio de funcionamiento de la "recuperación por transferencia" de Sui
Lo más sorprendente es que Sui no solo ha congelado los activos de los hackers, sino que también planea recuperar los fondos robados a través de una actualización en la cadena llamada "transferencia de recuperación".
El 27 de mayo, Cetus propuso un plan de votación de la comunidad, solicitando una actualización del protocolo para enviar los fondos congelados a una billetera de custodia de firma múltiple. La Fundación Sui inmediatamente inició una votación de gobernanza en la cadena.
El 29 de mayo, se anunciaron los resultados de la votación, con aproximadamente el 90.9% de los validadores apoyando la propuesta. Sui anunció que, una vez aprobada la propuesta, "todos los fondos congelados en las dos cuentas de los hackers serán recuperados en una billetera multisig sin necesidad de la firma de los hackers".
No se necesita la firma de un hacker, qué característica tan diferente, nunca ha habido una forma de reparación así en la industria de la blockchain.
Según el PR oficial de GitHub de Sui, el protocolo ha introducido el mecanismo de alias de dirección )address aliasing(. El contenido de la actualización incluye: especificar de antemano las reglas de alias en ProtocolConfig, de modo que ciertas transacciones permitidas puedan considerar las firmas legítimas como enviadas desde una cuenta de hacker.
Específicamente, se vincula la lista de hashes de transacciones de rescate que se van a ejecutar con la dirección objetivo (es decir, la dirección del hacker), y cualquier ejecutor que firme y publique estos resúmenes de transacciones fijas se considera que ha iniciado la transacción como un propietario válido de la dirección del hacker. Para estas transacciones específicas, el sistema de nodos validadores omite la verificación de la Lista de Denegación.
Desde el punto de vista del código, Sui ha añadido la siguiente comprobación en la lógica de verificación de transacciones: cuando una transacción es interceptada por la lista negra, el sistema recorre sus firmantes y comprueba si protocol_config.is_tx_allowed_via_aliasing)sender, signer, tx_digest( son verdaderos.
Siempre que haya un firmante que cumpla con las reglas del alias, se marcará que esta transacción está permitida y se ignorarán los errores de interceptación anteriores, continuando con el empaquetado y la ejecución normal.
Opiniones
160 millones, rasgando la creencia más profunda de la industria.
Desde la perspectiva personal del autor, el evento Cetus puede que pase rápidamente, pero este modelo no será olvidado, ya que ha revolucionado las bases de la industria y ha roto el consenso tradicional de la blockchain de ser inmutable bajo un mismo libro mayor.
En el diseño de blockchain, el contrato es la ley, el código es el juez.
Pero en este evento, el código falló, la intervención de la gobernanza y el poder prevalecieron, formando un patrón donde el comportamiento de votación decidía el resultado del código.
Es precisamente porque la forma en que Sui ha utilizado directamente las transacciones difiere enormemente de cómo las principales cadenas de bloques abordan los problemas de los hackers.
No es la primera vez que se "modifica el consenso", pero sí es la más silenciosa.
Desde una perspectiva histórica:
El evento The DAO de Ethereum en 2016 se compensó por las pérdidas mediante un hard fork que revertía las transacciones, pero esta decisión llevó a la división de Ethereum y Ethereum Classic en dos cadenas. El proceso fue muy controvertido, pero al final fue formado por diferentes grupos con distintas creencias de consenso.
La comunidad de Bitcoin también ha enfrentado desafíos técnicos similares: en 2010, la vulnerabilidad de desbordamiento de valor fue reparada de urgencia por los desarrolladores y se actualizaron las reglas de consenso, eliminando por completo aproximadamente 18.4 mil millones de bitcoins generados ilegalmente.
Este es el mismo patrón de bifurcación dura, que retrocede el libro mayor a antes del problema, y luego los usuarios aún pueden decidir por sí mismos en qué sistema de libro mayor continuar utilizando.
En comparación con la bifurcación dura DAO, Sui no optó por dividir la cadena, sino que se centró con precisión en este evento actualizando el protocolo y configurando alias. Al hacerlo, Sui mantiene la continuidad de la cadena y la mayoría de las reglas de consenso, pero también muestra que el protocolo subyacente se puede usar para implementar "operaciones de rescate" específicas.
El problema es que el "rollback por bifurcación" en la historia era una elección de fe del usuario; la "corrección por protocolo" de Sui es una decisión que la cadena toma por ti.
¿No es tu clave, no es tu moneda? Me temo que ya no.
A largo plazo, esto significa que la idea de "Not your keys, not your coins" se desmorona en la cadena Sui: incluso si la clave privada del usuario es completa, la red aún puede evitar el movimiento de activos y redirigirlos a través de cambios en el protocolo colectivo.
Si esto se convierte en un precedente para que blockchain responda a incidentes de seguridad a gran escala en el futuro, incluso se considera que es una práctica que se puede seguir nuevamente.
"Cuando una cadena puede romper las reglas en nombre de la justicia, también tiene un precedente para romper cualquier regla."
Una vez que hay un éxito en el "robo de dinero público", la próxima vez podría ser una operación en la "zona de ambigüedad moral".
¿Qué sucederá?
Si los hackers realmente robaron el dinero de los usuarios, ¿entonces puede un voto colectivo quitarle su dinero?
¿La votación se basa en quién tiene más dinero (pos) o en quién tiene más personas? Si gana el que tiene más dinero, entonces el último productor descrito por Liu Cixin llegará muy pronto; si gana el que tiene más personas, entonces la multitud desorganizada también levantará su voz.
En un sistema tradicional, es muy normal que los ingresos ilegales no estén protegidos; el congelamiento y la transferencia son operaciones rutinarias de los bancos tradicionales.
Pero desde un punto de vista técnico teórico, esto no se puede llevar a cabo, ¿no es esa la raíz del desarrollo de la industria blockchain?
Ahora la vara de cumplimiento en la industria sigue fermentando. Hoy se puede congelar y modificar el saldo de la cuenta debido a hackers, y mañana se pueden hacer modificaciones arbitrarias por factores geopolíticos o de conflicto. Si la cadena se convierte en una herramienta regional.
El valor de esa industria se ha visto significativamente reducido, y en el mejor de los casos, se trata de otro sistema financiero menos eficiente.
Esta también es la razón por la que el autor está firme en la industria: "La blockchain no tiene valor porque no se puede congelar, sino porque, aunque la odies, no cambia por ti."
¿Puede la cadena mantener su alma ante la tendencia de la regulación?
Una vez, las cadenas de consorcio eran más populares que las cadenas públicas, porque satisfacían las necesidades de regulación de esa época. Hoy en día, el declive de las cadenas de consorcio significa que simplemente cumplir con esa necesidad no es un verdadero requerimiento de los usuarios. Los usuarios regulados que se han perdido, ¿cuáles son las herramientas de regulación necesarias?
Desde la perspectiva del desarrollo de la industria
¿Es la centralización eficiente una etapa necesaria en el desarrollo de blockchain? Si el objetivo final de la descentralización es proteger los intereses del usuario, ¿podemos tolerar la centralización como un medio de transición?
La palabra "democracia" en el contexto de la gobernanza en la cadena, en realidad, es ponderada por tokens. Entonces, si un hacker posee una gran cantidad de SUI (o si un día el DAO es hackeado y el hacker controla los derechos de voto), ¿también podría "votar legítimamente para limpiar su nombre"?
Al final, el valor de la blockchain no radica en si puede o no congelarse, sino en que incluso si un grupo tiene la capacidad de congelarla, elige no hacerlo.
El futuro de una cadena no está determinado por la arquitectura técnica, sino por el conjunto de creencias que elige proteger.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Opinión: ¿Un hacker robó el dinero, así que Sui puede robarlo?
Escrito por: Catorce Jun
Este evento es una victoria del capital, no de los usuarios, y representa un retroceso para el desarrollo de la industria.
Bitcoin a la izquierda, Sui a la derecha, cada movimiento que sacude la industria descentralizada genera una fe más fuerte en Bitcoin.
El mundo no solo necesita un mejor sistema financiero global, sino que siempre habrá un grupo de personas que necesita un espacio de libertad.
Una vez, las cadenas de consorcio eran más populares que las cadenas públicas, precisamente porque satisfacían las necesidades de regulación de esa época. Hoy en día, el declive de las cadenas de consorcio significa que simplemente cumplir con esta necesidad no es realmente lo que los usuarios desean. ¿Entonces, qué herramientas de regulación se necesitan cuando se pierden los usuarios regulados?
El 22 de mayo de 2025, el mayor intercambio descentralizado del ecosistema de la cadena pública Sui, (DEX) Cetus, sufrió un ataque de hackers, lo que provocó una caída repentina de la liquidez y el colapso de los precios de varios pares de comercio, con pérdidas que superan los 220 millones de dólares.
Hasta el momento de la publicación, la línea de tiempo es la siguiente:
El 22 de mayo por la mañana, un hacker atacó a Cetus y sustrajo 230 millones de dólares. Cetus suspendió urgentemente el contrato y publicó un anuncio.
El 22 de mayo por la tarde, un hacker transfirió aproximadamente 60 millones de dólares a través de cadenas, mientras que otros 162 millones de dólares siguen en la dirección de la cadena Sui. Los nodos de validación de Sui tomaron medidas rápidamente, agregando la dirección del hacker a la "Lista de Denegación de Servicios (Deny List)" y congelando los fondos.
La noche del 22 de mayo, el CPO de Sui @emanabio tuiteó confirmando: los fondos han sido congelados, la devolución comenzará pronto.
El 23 de mayo, Cetus comenzó a reparar vulnerabilidades y actualizar el contrato.
El 24 de mayo, Sui abrió un PR, explicando que la recuperación de fondos se realizará próximamente a través del mecanismo de alias (aliasing) y la lista blanca (whitelist).
El 26 de mayo, Sui inició la votación de gobernanza en la cadena, proponiendo si se debe ejecutar la actualización del protocolo y transferir los activos del hacker a una dirección de custodia.
El 29 de mayo, se publicaron los resultados de la votación, con más del 2/3 del peso de los nodos de validación apoyando; la actualización del protocolo está lista para ejecutarse.
30 de mayo - principios de junio, la actualización del protocolo entra en vigor, se ejecuta el hash de la transacción designada, los activos del hacker fueron "legalmente transferidos".
Principios del evento relacionados, la industria ya tiene varios artículos al respecto, aquí solo se hace un resumen de los principios clave:
Desde la perspectiva del proceso de ataque:
El atacante primero utilizó un préstamo relámpago para pedir prestados aproximadamente 10,024,321.28 haSUI, lo que provocó instantáneamente una caída en el precio del grupo de negociación.
99.90%. Esta enorme orden de venta hizo que el precio del pool objetivo cayera de aproximadamente 1.8956×10^19 a 1.8425×10^19, casi vaciándose por completo.
Luego, el atacante creó posiciones de liquidez en Cetus en un rango extremadamente estrecho (límite inferior de Tick 300000, límite superior 300200, con un ancho de intervalo de solo 1.00496621%). Este rango tan estrecho amplificó el impacto del error de cálculo posterior en la cantidad de tokens requerida.
El principio central del ataque:
En la función get_delta_a de Cetus, que se utiliza para calcular la cantidad de tokens necesarios, existe una vulnerabilidad de desbordamiento de enteros. Un atacante declara intencionalmente que desea agregar una enorme liquidez (aproximadamente 10^37 unidades), pero en realidad solo aporta 1 token al contrato.
Debido a un error en la condición de detección de desbordamiento de checked_shlw, el contrato experimentó un truncamiento de bits altos durante el cálculo de desplazamiento a la izquierda, lo que llevó a que el sistema subestimara gravemente la cantidad de haSUI necesaria, obteniendo así una gran liquidez a un costo mínimo.
Técnicamente, la vulnerabilidad anterior se deriva del uso por parte de Cetus de máscaras y condiciones de juicio incorrectas en el contrato inteligente Move, lo que hace que cualquier valor inferior a 0xffffffffffffffff << 192 pueda eludir la detección; Sin embargo, después de mover 64 bits a la izquierda, los datos de alto nivel se truncan y el sistema solo cobra una cantidad muy pequeña de tokens para considerar que ha ganado mucha liquidez.
Después de que ocurrió el evento, surgieron 2 operaciones oficiales: "Congelar" vs "Recuperar", que son dos fases:
La fase de congelación se completa mediante la Deny List + consenso de nodos;
La fase de recuperación requiere una actualización del protocolo en la cadena + votación de la comunidad + ejecución de transacciones designadas para eludir la lista negra.
La cadena Sui tiene en sí misma una lista de denegación especial ( que implementa el mecanismo de congelación de fondos de este hackeo. No solo eso, en realidad el estándar de token de Sui también tiene un modo de "token regulado", con una función de congelación incorporada.
Esta congelación de emergencia aprovecha esta característica: los nodos validadores agregan rápidamente direcciones relacionadas con fondos robados en sus archivos de configuración locales. Teóricamente, cada operador de nodo puede modificar TransactionDenyConfig para actualizar la lista negra por su cuenta, pero para garantizar la coherencia de la red, la Fundación Sui tiene una coordinación centralizada como editor de la configuración original.
La fundación primero publicó oficialmente una actualización de configuración que contiene la dirección del hacker, los validadores sincronizan y aplican la configuración predeterminada, lo que permite que los fondos del hacker estén temporalmente "sellados" en la cadena, y detrás de esto en realidad hay un alto grado de concentración.
Para rescatar a las víctimas de los fondos congelados, el equipo de Sui lanzó inmediatamente un parche del mecanismo de lista blanca )Whitelist(.
Esta es una operación para la posterior repatriación de fondos. Se pueden construir transacciones legales de antemano y registrarlas en la lista blanca, incluso si la dirección de esos fondos está en la lista negra, se puede ejecutar de manera forzada.
Esta nueva característica, transaction_allow_list_skip_all_checks permite que transacciones específicas se agreguen previamente a la lista "sin censura", de modo que estas transacciones puedan omitir todas las comprobaciones de seguridad, incluidas firmas, permisos, listas negras, etc.
Es importante tener en cuenta que el parche de lista blanca no puede simplemente robar los activos de un hacker; solo otorga a ciertas transacciones la capacidad de eludir el congelamiento, la verdadera transferencia de activos aún requiere una firma legal o un módulo de permisos de sistema adicional para completarse.
En realidad, las soluciones de congelación más comunes en la industria suelen ocurrir a nivel de contratos de tokens y están controladas por múltiples firmas del emisor.
Tomando como ejemplo el USDT emitido por Tether, su contrato tiene una función de lista negra integrada, lo que permite a la empresa emisora congelar direcciones infractoras, impidiéndoles transferir USDT. Este tipo de solución requiere que se inicie una solicitud de congelación en la cadena mediante múltiples firmas, y solo se ejecuta después de que se alcanza un consenso entre los firmantes, lo que genera un retraso en la ejecución.
El mecanismo de congelación de Tether, aunque es efectivo, las estadísticas muestran que el proceso de firma múltiple a menudo presenta "períodos de ventana", lo que deja oportunidades para los delincuentes.
En comparación, el congelamiento de Sui ocurre a nivel del protocolo subyacente, operado colectivamente por los nodos validadores, y su velocidad de ejecución es mucho más rápida que la de una llamada a contrato normal.
En este modelo, para que la ejecución sea lo suficientemente rápida, esto significa que la gestión de estos nodos de validadores debe ser altamente unificada.
Lo más sorprendente es que Sui no solo ha congelado los activos de los hackers, sino que también planea recuperar los fondos robados a través de una actualización en la cadena llamada "transferencia de recuperación".
El 27 de mayo, Cetus propuso un plan de votación de la comunidad, solicitando una actualización del protocolo para enviar los fondos congelados a una billetera de custodia de firma múltiple. La Fundación Sui inmediatamente inició una votación de gobernanza en la cadena.
El 29 de mayo, se anunciaron los resultados de la votación, con aproximadamente el 90.9% de los validadores apoyando la propuesta. Sui anunció que, una vez aprobada la propuesta, "todos los fondos congelados en las dos cuentas de los hackers serán recuperados en una billetera multisig sin necesidad de la firma de los hackers".
No se necesita la firma de un hacker, qué característica tan diferente, nunca ha habido una forma de reparación así en la industria de la blockchain.
Según el PR oficial de GitHub de Sui, el protocolo ha introducido el mecanismo de alias de dirección )address aliasing(. El contenido de la actualización incluye: especificar de antemano las reglas de alias en ProtocolConfig, de modo que ciertas transacciones permitidas puedan considerar las firmas legítimas como enviadas desde una cuenta de hacker.
Específicamente, se vincula la lista de hashes de transacciones de rescate que se van a ejecutar con la dirección objetivo (es decir, la dirección del hacker), y cualquier ejecutor que firme y publique estos resúmenes de transacciones fijas se considera que ha iniciado la transacción como un propietario válido de la dirección del hacker. Para estas transacciones específicas, el sistema de nodos validadores omite la verificación de la Lista de Denegación.
Desde el punto de vista del código, Sui ha añadido la siguiente comprobación en la lógica de verificación de transacciones: cuando una transacción es interceptada por la lista negra, el sistema recorre sus firmantes y comprueba si protocol_config.is_tx_allowed_via_aliasing)sender, signer, tx_digest( son verdaderos.
Siempre que haya un firmante que cumpla con las reglas del alias, se marcará que esta transacción está permitida y se ignorarán los errores de interceptación anteriores, continuando con el empaquetado y la ejecución normal.
160 millones, rasgando la creencia más profunda de la industria.
Desde la perspectiva personal del autor, el evento Cetus puede que pase rápidamente, pero este modelo no será olvidado, ya que ha revolucionado las bases de la industria y ha roto el consenso tradicional de la blockchain de ser inmutable bajo un mismo libro mayor.
En el diseño de blockchain, el contrato es la ley, el código es el juez.
Pero en este evento, el código falló, la intervención de la gobernanza y el poder prevalecieron, formando un patrón donde el comportamiento de votación decidía el resultado del código.
Es precisamente porque la forma en que Sui ha utilizado directamente las transacciones difiere enormemente de cómo las principales cadenas de bloques abordan los problemas de los hackers.
No es la primera vez que se "modifica el consenso", pero sí es la más silenciosa.
Desde una perspectiva histórica:
El evento The DAO de Ethereum en 2016 se compensó por las pérdidas mediante un hard fork que revertía las transacciones, pero esta decisión llevó a la división de Ethereum y Ethereum Classic en dos cadenas. El proceso fue muy controvertido, pero al final fue formado por diferentes grupos con distintas creencias de consenso.
La comunidad de Bitcoin también ha enfrentado desafíos técnicos similares: en 2010, la vulnerabilidad de desbordamiento de valor fue reparada de urgencia por los desarrolladores y se actualizaron las reglas de consenso, eliminando por completo aproximadamente 18.4 mil millones de bitcoins generados ilegalmente.
Este es el mismo patrón de bifurcación dura, que retrocede el libro mayor a antes del problema, y luego los usuarios aún pueden decidir por sí mismos en qué sistema de libro mayor continuar utilizando.
En comparación con la bifurcación dura DAO, Sui no optó por dividir la cadena, sino que se centró con precisión en este evento actualizando el protocolo y configurando alias. Al hacerlo, Sui mantiene la continuidad de la cadena y la mayoría de las reglas de consenso, pero también muestra que el protocolo subyacente se puede usar para implementar "operaciones de rescate" específicas.
El problema es que el "rollback por bifurcación" en la historia era una elección de fe del usuario; la "corrección por protocolo" de Sui es una decisión que la cadena toma por ti.
¿No es tu clave, no es tu moneda? Me temo que ya no.
A largo plazo, esto significa que la idea de "Not your keys, not your coins" se desmorona en la cadena Sui: incluso si la clave privada del usuario es completa, la red aún puede evitar el movimiento de activos y redirigirlos a través de cambios en el protocolo colectivo.
Si esto se convierte en un precedente para que blockchain responda a incidentes de seguridad a gran escala en el futuro, incluso se considera que es una práctica que se puede seguir nuevamente.
"Cuando una cadena puede romper las reglas en nombre de la justicia, también tiene un precedente para romper cualquier regla."
Una vez que hay un éxito en el "robo de dinero público", la próxima vez podría ser una operación en la "zona de ambigüedad moral".
¿Qué sucederá?
Si los hackers realmente robaron el dinero de los usuarios, ¿entonces puede un voto colectivo quitarle su dinero?
¿La votación se basa en quién tiene más dinero (pos) o en quién tiene más personas? Si gana el que tiene más dinero, entonces el último productor descrito por Liu Cixin llegará muy pronto; si gana el que tiene más personas, entonces la multitud desorganizada también levantará su voz.
En un sistema tradicional, es muy normal que los ingresos ilegales no estén protegidos; el congelamiento y la transferencia son operaciones rutinarias de los bancos tradicionales.
Pero desde un punto de vista técnico teórico, esto no se puede llevar a cabo, ¿no es esa la raíz del desarrollo de la industria blockchain?
Ahora la vara de cumplimiento en la industria sigue fermentando. Hoy se puede congelar y modificar el saldo de la cuenta debido a hackers, y mañana se pueden hacer modificaciones arbitrarias por factores geopolíticos o de conflicto. Si la cadena se convierte en una herramienta regional.
El valor de esa industria se ha visto significativamente reducido, y en el mejor de los casos, se trata de otro sistema financiero menos eficiente.
Esta también es la razón por la que el autor está firme en la industria: "La blockchain no tiene valor porque no se puede congelar, sino porque, aunque la odies, no cambia por ti."
¿Puede la cadena mantener su alma ante la tendencia de la regulación?
Una vez, las cadenas de consorcio eran más populares que las cadenas públicas, porque satisfacían las necesidades de regulación de esa época. Hoy en día, el declive de las cadenas de consorcio significa que simplemente cumplir con esa necesidad no es un verdadero requerimiento de los usuarios. Los usuarios regulados que se han perdido, ¿cuáles son las herramientas de regulación necesarias?
Desde la perspectiva del desarrollo de la industria
¿Es la centralización eficiente una etapa necesaria en el desarrollo de blockchain? Si el objetivo final de la descentralización es proteger los intereses del usuario, ¿podemos tolerar la centralización como un medio de transición?
La palabra "democracia" en el contexto de la gobernanza en la cadena, en realidad, es ponderada por tokens. Entonces, si un hacker posee una gran cantidad de SUI (o si un día el DAO es hackeado y el hacker controla los derechos de voto), ¿también podría "votar legítimamente para limpiar su nombre"?
Al final, el valor de la blockchain no radica en si puede o no congelarse, sino en que incluso si un grupo tiene la capacidad de congelarla, elige no hacerlo.
El futuro de una cadena no está determinado por la arquitectura técnica, sino por el conjunto de creencias que elige proteger.