El valor de la Cadena de bloques no radica en si puede o no congelarse, sino en que incluso si el grupo tiene la capacidad de congelar, elige no hacerlo.
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 acción que sacude la industria descentralizada genera una fe más fuerte en Bitcoin.
El mundo no solo necesita un mejor infraestructura financiera global, sino que siempre habrá un grupo de personas que necesita un espacio de libertad.
Hace algún tiempo, la cadena de bloques de consorcio era más popular que la cadena de bloques pública, precisamente porque satisfacía las necesidades regulatorias de esa época. Hoy en día, el declive de los consorcios significa que simplemente cumplir con estas necesidades no es lo que realmente demandan los usuarios. Los usuarios que estaban regulados se han perdido, ¿entonces qué herramientas regulatorias se necesitan?
1、Antecedentes del evento
El 22 de mayo de 2025, el mayor intercambio descentralizado de la ecosistema de la cadena pública Sui, (DEX) Cetus, sufrió un ataque de hackers, lo que provocó una drástica reducción de la liquidez en cuestión de segundos, múltiples pares de comercio colapsaron en precio, y las pérdidas superaron 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, los hackers atacaron a Cetus para robar 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 la cadena de bloques, mientras que otros 162 millones de dólares aún permanecen en la dirección de la cadena Sui. Los nodos de validación de Sui tomaron medidas rápidas, agregando la dirección del hacker a la "lista de negación de servicio (Deny List)", congelando los fondos.
La noche del 22 de mayo, el CPO de Sui @emanabio confirmó en Twitter: los fondos han sido congelados, el reembolso comenzará pronto.
23 de mayo, Cetus comenzó a reparar vulnerabilidades y actualizar el contrato
24 de mayo, Sui código abierto PR, explica que pronto se llevará a cabo la recuperación de fondos a través del mecanismo de alias (aliasing) y la lista blanca (whitelist)
26 de mayo, Sui inició la votación de gobernanza en la cadena, proponiendo si ejecutar la actualización del protocolo y transferir los activos de los hackers a una dirección de custodia.
El 29 de mayo, se anunciaron los resultados de la votación, con más de 2/3 del peso de los nodos de validación a favor; 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 son "legalmente transferidos"
2, Principio de ataque
Relación con el principio del evento, la industria ya cuenta con múltiples descripciones, aquí solo se presenta un resumen sobre el principio central:
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 hizo que el precio del grupo de transacciones cayera instantáneamente.
99.90%. Esta enorme orden de venta hizo que el precio del bloque objetivo cayera de aproximadamente 1.8956×10^19 a 1.8425×10^19, casi vaciándose completamente.
Luego, el atacante creó posiciones de liquidez en Cetus en un rango extremadamente estrecho (límite inferior del Tick 300000, límite superior 300200, con un ancho de rango de solo 1.00496621%). Un rango tan estrecho amplificó el impacto del error de cálculo posterior sobre la cantidad de tokens requeridos.
Y el principio central del ataque:
Hay una vulnerabilidad de desbordamiento entero en la función get_delta_a de Cetus, que se utiliza para calcular la cantidad de tokens necesarios. Un atacante declara intencionadamente que desea agregar una gran 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 sufrió un truncamiento de bits al calcular el desplazamiento a la izquierda, lo que llevó a que el sistema subestimara gravemente la cantidad necesaria de haSUI, obteniendo así una enorme liquidez a un costo muy bajo.
Desde un punto de vista técnico, la vulnerabilidad mencionada proviene de que Cetus utilizó una máscara y condiciones de juicio incorrectas en el contrato inteligente Move, lo que permitió que cualquier valor menor que 0xffffffffffffffff << 192 pudiera eludir la detección; además, después de desplazar 64 bits a la izquierda, los datos de los bits altos se truncaron, y el sistema solo recibió una cantidad mínima de tokens y consideró que había obtenido una gran liquidez.
Después de que ocurrió el evento, surgieron 2 operaciones oficiales: "Congelar" vs "Recuperar", son dos fases:
La fase de congelación se completa mediante Deny List + consenso de nodos;
La fase de recuperación requiere una actualización del protocolo en la cadena de bloques + votación de la comunidad + ejecución de transacciones designadas para eludir la lista negra.
3、Mecanismo de congelación de Sui
Hay una lista de denegación especial ( un mecanismo de ) de lista de denegación en la propia cadena Sui, que realiza la congelación de los fondos del pirata informático. No solo eso, sino que el estándar de tokens de Sui también tiene un modelo de "token regulado" con una función de congelación incorporada.
Esta congelación de emergencia aprovechó precisamente esta característica: los nodos de validadores añadieron rápidamente las direcciones relacionadas con los fondos robados en su archivo de configuración local. Teóricamente, cada operador de nodo puede modificar por sí mismo TransactionDenyConfig para actualizar la lista negra, pero para garantizar la coherencia de la red, la Fundación Sui, como el organismo que publicó la configuración inicial, realizó una coordinación centralizada.
La fundación primero publicó oficialmente una actualización de configuración que incluía la dirección del hacker, los validadores sincronizaron y aplicaron la configuración por defecto, lo que permitió que los fondos del hacker estuvieran temporalmente "bloqueados" en la cadena, detrás de esto en realidad existe un alto grado de factores de concentración.
Para rescatar a las víctimas de los fondos congelados, el equipo de Sui lanzó inmediatamente un parche de mecanismo de lista blanca (Whitelist).
Esta es una operación para la posterior devolució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 agregar transacciones específicas previamente a la "lista de exención de verificación", lo que permite que estas transacciones omitan todas las verificaciones de seguridad, incluidas las firmas, permisos, listas negras, etc.
Es importante tener en cuenta que el parche de lista blanca no puede robar directamente 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 del sistema adicional para completarse.
En realidad, las soluciones de congelación más comunes en la industria a menudo ocurren a nivel de contrato de token, y son controladas por múltiples firmas del emisor.
Tomando como ejemplo el USDT emitido por Tether, su contrato incorpora una función de lista negra, lo que permite a la empresa emisora congelar direcciones en violación, impidiendo que estas transfieran USDT. Este esquema requiere que se inicie una solicitud de congelación en la cadena con múltiples firmas, y solo se ejecuta realmente una vez que se alcanza un consenso entre las firmas, por lo que existe un retraso en la ejecución.
El mecanismo de congelación de Tether, aunque efectivo, las estadísticas muestran que el proceso de múltiples firmas a menudo presenta "períodos de vacío", lo que deja oportunidades para que los delincuentes actúen.
En comparación, el congelamiento de Sui ocurre a nivel de 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 ordinario.
En este modelo, para que la ejecución sea lo suficientemente rápida, significa que la gestión de estos nodos validador debe ser altamente unificada.
3. El principio de implementación de "reciclaje por transferencia" de Sui
Lo más sorprendente es que Sui no solo congeló los activos de los hackers, sino que también planea "transferir recuperación" de los fondos robados a través de una actualización en la cadena.
El 27 de mayo, Cetus propuso un plan de votación comunitaria que solicita una actualización del protocolo para enviar los fondos congelados a una billetera de custodia multifirma. 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, aproximadamente el 90.9% de los validadores con peso apoyaron la propuesta. Sui anunció oficialmente que, una vez que la propuesta sea aprobada, "todos los fondos congelados en las dos cuentas de los hackers serán recuperados en una billetera multi-firma sin necesidad de la firma de los hackers."
No se necesita la firma del hacker, qué característica tan diferente, nunca ha habido un método de reparación así en la industria de la cadena de bloques.
Desde el PR oficial de Sui en GitHub, se sabe que 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 el ProtocolConfig, de modo que ciertas transacciones permitidas puedan considerar las firmas válidas como enviadas desde cuentas de hackers.
En concreto, se vincula la lista de hashes de las 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 transacción fijos será considerado como un propietario válido de la dirección del hacker que ha iniciado la transacción. Para estas transacciones específicas, el sistema de nodos validadores pasará por alto la verificación de la lista de denegación.
Desde el punto de vista del código, Sui ha añadido la siguiente verificación en la lógica de validación de transacciones: cuando una transacción es interceptada por la lista negra, el sistema recorre sus firmantes y verifica si protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) son verdaderos.
Siempre que exista un firmante que cumpla con las reglas del alias, es decir, que marque esta transacción como permitida, se ignorarán los errores de interceptación anteriores y se continuará con la ejecución normal del empaquetado.
4, Opiniones
160 millones, lo que revela la creencia más profunda de la industria
El evento Cetus, desde mi perspectiva personal, puede que esta tormenta pase rápidamente, pero este modelo no será olvidado, ya que ha revolucionado los fundamentos de la industria y ha roto el consenso tradicional de la cadena de bloques de ser inmutable bajo el mismo libro mayor.
En el diseño de la cadena de bloques, el contrato es la ley, el código es el árbitro.
Pero en este evento, el código falló, la intervención de gobernanza y el poder prevalecieron, formando un patrón de conducta de votación que decide los resultados del código.
Es precisamente porque la práctica de Sui de desviar directamente las transacciones tiene una gran diferencia con el manejo de problemas de hackers en las cadenas de bloques principales.
Esta no es la primera vez que "se altera el consenso", pero sí es la más silenciosa
Desde una perspectiva histórica:
Ethereum en 2016, el evento The DAO se recuperó de las pérdidas mediante un hard fork que retrocedió las transacciones, pero esta decisión llevó a la división de Ethereum y Ethereum Classic en dos cadenas, un proceso muy controvertido, pero finalmente se formaron diferentes consensos de fe por diferentes grupos.
La comunidad de Bitcoin también ha enfrentado desafíos técnicos similares: en 2010, la vulnerabilidad de desbordamiento de valor fue reparada urgentemente por los desarrolladores y se actualizaron las reglas de consenso, eliminando por completo alrededor de 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.
A diferencia de la bifurcación dura de DAO, Sui no eligió dividir la cadena, sino que abordó este evento de manera precisa mediante la actualización del protocolo y la configuración de alias. Al hacer esto, Sui mantiene la continuidad de la cadena y la mayor parte de las reglas de consenso sin cambios, pero al mismo tiempo también indica que el protocolo subyacente puede ser utilizado para llevar a cabo "acciones de rescate" específicas.
El problema es que el "retroceso en forma de bifurcación" en la historia es una elección de fe del usuario; la "corrección por protocolo" de Sui es una decisión tomada por la cadena por ti.
¿No es tu clave, no es tu moneda? Temor, no más.
A largo plazo, esto significa que la filosofía de "Not your keys, not your coins" se ve desmantelada en la cadena Sui: incluso si la clave privada del usuario está completa, la red aún puede impedir el movimiento de activos y redirigirlos a través de cambios en el protocolo colectivo.
Si esto se convierte en un precedente para que la cadena de bloques enfrente grandes incidentes de seguridad en el futuro, e incluso se considere una norma que se pueda seguir nuevamente.
"Cuando una cadena puede romper las reglas por la justicia, también tiene el precedente para romper cualquier regla."
Una vez que haya éxito en una "captura de dinero para la caridad", la próxima vez podría ser una operación en la "zona de ambigüedad moral".
¿Qué ocurrirá?
Si los hackers realmente robaron el dinero de los usuarios, ¿entonces una votación colectiva podría 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 ganan los que tienen más dinero, entonces el productor final descrito por Liu Cixin llegará pronto; si ganan los que tienen más personas, entonces la multitud desorganizada también hará mucho ruido.
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 la teoría técnica no se puede realizar esto, ¿no es la raíz del desarrollo de la Cadena de bloques?
Ahora la vara de cumplimiento de la industria sigue fermentando. Hoy se puede congelar y modificar el saldo de la cuenta por un hacker, y mañana se puede hacer cualquier modificación por factores geopolíticos o de conflicto. Si la cadena se convierte en una herramienta regional.
Entonces el valor de la industria se ve drásticamente reducido, siendo a lo sumo otro sistema financiero más ineficaz.
Esta es también la razón por la que el autor está firme en la industria: "La cadena de bloques no tiene valor porque no se puede congelar, sino porque incluso si lo odias, no cambia por ti."
La regulación es una tendencia inevitable, ¿podrá la cadena mantener su propia alma?
Una vez, las cadenas de bloques de consorcio eran más populares que las cadenas de bloques públicas, precisamente porque satisfacían las necesidades de regulación de esa época. Hoy en día, el declive de las alianzas implica que simplemente cumplir con esta necesidad no es la verdadera demanda de los usuarios. Los usuarios regulados que se han perdido, ¿qué herramientas de regulación se necesitan entonces?
desde la perspectiva del desarrollo de la industria
¿Es la centralización eficiente una etapa necesaria en el desarrollo de la Cadena de bloques? Si el objetivo final de la descentralización es proteger los intereses de los usuarios, ¿podemos entonces 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 algún día un DAO es hackeado y el hacker controla los derechos de voto), ¿también podría "votar legalmente para blanquearse"?
Al final, el valor de la cadena de bloques no radica en si se puede congelar o no, sino en que, incluso si el grupo tiene la capacidad de congelar, 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: ¿Los hackers robaron el dinero, así que Sui puede robar?
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 acción que sacude la industria descentralizada genera una fe más fuerte en Bitcoin.
El mundo no solo necesita un mejor infraestructura financiera global, sino que siempre habrá un grupo de personas que necesita un espacio de libertad.
Hace algún tiempo, la cadena de bloques de consorcio era más popular que la cadena de bloques pública, precisamente porque satisfacía las necesidades regulatorias de esa época. Hoy en día, el declive de los consorcios significa que simplemente cumplir con estas necesidades no es lo que realmente demandan los usuarios. Los usuarios que estaban regulados se han perdido, ¿entonces qué herramientas regulatorias se necesitan?
1、Antecedentes del evento
El 22 de mayo de 2025, el mayor intercambio descentralizado de la ecosistema de la cadena pública Sui, (DEX) Cetus, sufrió un ataque de hackers, lo que provocó una drástica reducción de la liquidez en cuestión de segundos, múltiples pares de comercio colapsaron en precio, y las pérdidas superaron los 220 millones de dólares.
Hasta el momento de la publicación, la línea de tiempo es la siguiente:
2, Principio de ataque
Relación con el principio del evento, la industria ya cuenta con múltiples descripciones, aquí solo se presenta un resumen sobre el principio central:
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 hizo que el precio del grupo de transacciones cayera instantáneamente.
99.90%. Esta enorme orden de venta hizo que el precio del bloque objetivo cayera de aproximadamente 1.8956×10^19 a 1.8425×10^19, casi vaciándose completamente.
Luego, el atacante creó posiciones de liquidez en Cetus en un rango extremadamente estrecho (límite inferior del Tick 300000, límite superior 300200, con un ancho de rango de solo 1.00496621%). Un rango tan estrecho amplificó el impacto del error de cálculo posterior sobre la cantidad de tokens requeridos.
Y el principio central del ataque:
Hay una vulnerabilidad de desbordamiento entero en la función get_delta_a de Cetus, que se utiliza para calcular la cantidad de tokens necesarios. Un atacante declara intencionadamente que desea agregar una gran 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 sufrió un truncamiento de bits al calcular el desplazamiento a la izquierda, lo que llevó a que el sistema subestimara gravemente la cantidad necesaria de haSUI, obteniendo así una enorme liquidez a un costo muy bajo.
Desde un punto de vista técnico, la vulnerabilidad mencionada proviene de que Cetus utilizó una máscara y condiciones de juicio incorrectas en el contrato inteligente Move, lo que permitió que cualquier valor menor que 0xffffffffffffffff << 192 pudiera eludir la detección; además, después de desplazar 64 bits a la izquierda, los datos de los bits altos se truncaron, y el sistema solo recibió una cantidad mínima de tokens y consideró que había obtenido una gran liquidez.
Después de que ocurrió el evento, surgieron 2 operaciones oficiales: "Congelar" vs "Recuperar", son dos fases:
3、Mecanismo de congelación de Sui
Hay una lista de denegación especial ( un mecanismo de ) de lista de denegación en la propia cadena Sui, que realiza la congelación de los fondos del pirata informático. No solo eso, sino que el estándar de tokens de Sui también tiene un modelo de "token regulado" con una función de congelación incorporada.
Esta congelación de emergencia aprovechó precisamente esta característica: los nodos de validadores añadieron rápidamente las direcciones relacionadas con los fondos robados en su archivo de configuración local. Teóricamente, cada operador de nodo puede modificar por sí mismo TransactionDenyConfig para actualizar la lista negra, pero para garantizar la coherencia de la red, la Fundación Sui, como el organismo que publicó la configuración inicial, realizó una coordinación centralizada.
La fundación primero publicó oficialmente una actualización de configuración que incluía la dirección del hacker, los validadores sincronizaron y aplicaron la configuración por defecto, lo que permitió que los fondos del hacker estuvieran temporalmente "bloqueados" en la cadena, detrás de esto en realidad existe un alto grado de factores de concentración.
Para rescatar a las víctimas de los fondos congelados, el equipo de Sui lanzó inmediatamente un parche de mecanismo de lista blanca (Whitelist).
Esta es una operación para la posterior devolució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 agregar transacciones específicas previamente a la "lista de exención de verificación", lo que permite que estas transacciones omitan todas las verificaciones de seguridad, incluidas las firmas, permisos, listas negras, etc.
Es importante tener en cuenta que el parche de lista blanca no puede robar directamente 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 del sistema adicional para completarse.
En realidad, las soluciones de congelación más comunes en la industria a menudo ocurren a nivel de contrato de token, y son controladas por múltiples firmas del emisor.
Tomando como ejemplo el USDT emitido por Tether, su contrato incorpora una función de lista negra, lo que permite a la empresa emisora congelar direcciones en violación, impidiendo que estas transfieran USDT. Este esquema requiere que se inicie una solicitud de congelación en la cadena con múltiples firmas, y solo se ejecuta realmente una vez que se alcanza un consenso entre las firmas, por lo que existe un retraso en la ejecución.
El mecanismo de congelación de Tether, aunque efectivo, las estadísticas muestran que el proceso de múltiples firmas a menudo presenta "períodos de vacío", lo que deja oportunidades para que los delincuentes actúen.
En comparación, el congelamiento de Sui ocurre a nivel de 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 ordinario.
En este modelo, para que la ejecución sea lo suficientemente rápida, significa que la gestión de estos nodos validador debe ser altamente unificada.
3. El principio de implementación de "reciclaje por transferencia" de Sui
Lo más sorprendente es que Sui no solo congeló los activos de los hackers, sino que también planea "transferir recuperación" de los fondos robados a través de una actualización en la cadena.
El 27 de mayo, Cetus propuso un plan de votación comunitaria que solicita una actualización del protocolo para enviar los fondos congelados a una billetera de custodia multifirma. 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, aproximadamente el 90.9% de los validadores con peso apoyaron la propuesta. Sui anunció oficialmente que, una vez que la propuesta sea aprobada, "todos los fondos congelados en las dos cuentas de los hackers serán recuperados en una billetera multi-firma sin necesidad de la firma de los hackers."
No se necesita la firma del hacker, qué característica tan diferente, nunca ha habido un método de reparación así en la industria de la cadena de bloques.
Desde el PR oficial de Sui en GitHub, se sabe que 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 el ProtocolConfig, de modo que ciertas transacciones permitidas puedan considerar las firmas válidas como enviadas desde cuentas de hackers.
En concreto, se vincula la lista de hashes de las 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 transacción fijos será considerado como un propietario válido de la dirección del hacker que ha iniciado la transacción. Para estas transacciones específicas, el sistema de nodos validadores pasará por alto la verificación de la lista de denegación.
Desde el punto de vista del código, Sui ha añadido la siguiente verificación en la lógica de validación de transacciones: cuando una transacción es interceptada por la lista negra, el sistema recorre sus firmantes y verifica si protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) son verdaderos.
Siempre que exista un firmante que cumpla con las reglas del alias, es decir, que marque esta transacción como permitida, se ignorarán los errores de interceptación anteriores y se continuará con la ejecución normal del empaquetado.
4, Opiniones
160 millones, lo que revela la creencia más profunda de la industria
El evento Cetus, desde mi perspectiva personal, puede que esta tormenta pase rápidamente, pero este modelo no será olvidado, ya que ha revolucionado los fundamentos de la industria y ha roto el consenso tradicional de la cadena de bloques de ser inmutable bajo el mismo libro mayor.
En el diseño de la cadena de bloques, el contrato es la ley, el código es el árbitro.
Pero en este evento, el código falló, la intervención de gobernanza y el poder prevalecieron, formando un patrón de conducta de votación que decide los resultados del código.
Es precisamente porque la práctica de Sui de desviar directamente las transacciones tiene una gran diferencia con el manejo de problemas de hackers en las cadenas de bloques principales.
Esta no es la primera vez que "se altera el consenso", pero sí es la más silenciosa
Desde una perspectiva histórica:
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.
A diferencia de la bifurcación dura de DAO, Sui no eligió dividir la cadena, sino que abordó este evento de manera precisa mediante la actualización del protocolo y la configuración de alias. Al hacer esto, Sui mantiene la continuidad de la cadena y la mayor parte de las reglas de consenso sin cambios, pero al mismo tiempo también indica que el protocolo subyacente puede ser utilizado para llevar a cabo "acciones de rescate" específicas.
El problema es que el "retroceso en forma de bifurcación" en la historia es una elección de fe del usuario; la "corrección por protocolo" de Sui es una decisión tomada por la cadena por ti.
¿No es tu clave, no es tu moneda? Temor, no más.
A largo plazo, esto significa que la filosofía de "Not your keys, not your coins" se ve desmantelada en la cadena Sui: incluso si la clave privada del usuario está completa, la red aún puede impedir el movimiento de activos y redirigirlos a través de cambios en el protocolo colectivo.
Si esto se convierte en un precedente para que la cadena de bloques enfrente grandes incidentes de seguridad en el futuro, e incluso se considere una norma que se pueda seguir nuevamente.
"Cuando una cadena puede romper las reglas por la justicia, también tiene el precedente para romper cualquier regla."
Una vez que haya éxito en una "captura de dinero para la caridad", la próxima vez podría ser una operación en la "zona de ambigüedad moral".
¿Qué ocurrirá?
Si los hackers realmente robaron el dinero de los usuarios, ¿entonces una votación colectiva podría 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 ganan los que tienen más dinero, entonces el productor final descrito por Liu Cixin llegará pronto; si ganan los que tienen más personas, entonces la multitud desorganizada también hará mucho ruido.
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 la teoría técnica no se puede realizar esto, ¿no es la raíz del desarrollo de la Cadena de bloques?
Ahora la vara de cumplimiento de la industria sigue fermentando. Hoy se puede congelar y modificar el saldo de la cuenta por un hacker, y mañana se puede hacer cualquier modificación por factores geopolíticos o de conflicto. Si la cadena se convierte en una herramienta regional.
Entonces el valor de la industria se ve drásticamente reducido, siendo a lo sumo otro sistema financiero más ineficaz.
Esta es también la razón por la que el autor está firme en la industria: "La cadena de bloques no tiene valor porque no se puede congelar, sino porque incluso si lo odias, no cambia por ti."
La regulación es una tendencia inevitable, ¿podrá la cadena mantener su propia alma?
Una vez, las cadenas de bloques de consorcio eran más populares que las cadenas de bloques públicas, precisamente porque satisfacían las necesidades de regulación de esa época. Hoy en día, el declive de las alianzas implica que simplemente cumplir con esta necesidad no es la verdadera demanda de los usuarios. Los usuarios regulados que se han perdido, ¿qué herramientas de regulación se necesitan entonces?
desde la perspectiva del desarrollo de la industria
¿Es la centralización eficiente una etapa necesaria en el desarrollo de la Cadena de bloques? Si el objetivo final de la descentralización es proteger los intereses de los usuarios, ¿podemos entonces 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 algún día un DAO es hackeado y el hacker controla los derechos de voto), ¿también podría "votar legalmente para blanquearse"?
Al final, el valor de la cadena de bloques no radica en si se puede congelar o no, sino en que, incluso si el grupo tiene la capacidad de congelar, 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.