Este incidente es una victoria para el capital, no para los usuarios, y es un retroceso para el desarrollo de la industria.
Bitcoin a la izquierda, Sui a la derecha, cada movimiento en la industria descentralizada trae una creencia más fuerte en Bitcoin.
El mundo no solo necesita una mejor infraestructura financiera global, sino que siempre habrá un grupo de personas que necesita un espacio libre.
Érase una vez, las cadenas de consorcio eran más populares que las cadenas públicas porque satisfacían las necesidades regulatorias de esa época. Hoy en día, el declive de las cadenas de consorcio significa que simplemente cumplir con este requisito no refleja las verdaderas necesidades de los usuarios. Con la pérdida de usuarios regulados, ¿cuál es la necesidad de herramientas regulatorias?
El 22 de mayo de 2025, Cetus, el mayor intercambio descentralizado (DEX) en el ecosistema de la cadena pública Sui, sufrió un ataque de hackers, lo que resultó en una caída instantánea de la liquidez, el colapso de los precios de múltiples pares de negociación y pérdidas que superaron los 220 millones de dólares.
A partir del momento de la publicación, la cronología es la siguiente:
En cuanto a los principios de los eventos, la industria ya ha publicado varias declaraciones. Aquí, solo proporcionamos un resumen de los principios básicos:
Desde la perspectiva del proceso de ataque:
El atacante primero pidió prestados aproximadamente 10,024,321.28 haSUI utilizando un préstamo flash, lo que provocó instantáneamente que el precio en el pool de trading cayera.
99.90%. Esta masiva orden de venta hizo que el precio del pool objetivo cayera de aproximadamente 1.8956×10^19 a 1.8425×10^19, casi agotándose.
Posteriormente, el atacante creó una posición de liquidez en Cetus dentro de un rango muy estrecho (límite inferior de Tick 300000, límite superior 300200, con un ancho de rango de solo 1.00496621%). Un rango tan estrecho amplifica el impacto de los errores de cálculo subsiguientes en la cantidad de tokens requerida.
El principio básico del ataque:
Hay una vulnerabilidad de desbordamiento de enteros en la función get_delta_a utilizada por Cetus para calcular el número requerido de tokens. Un atacante afirma intencionalmente agregar una gran liquidez (aproximadamente 10^37 unidades), pero en realidad solo contribuye con 1 token al contrato.
Debido a la condición incorrecta de detección de desbordamiento de checked_shlw, el contrato experimentó truncamiento de bits altos durante los cálculos de desplazamiento a la izquierda, lo que causó que el sistema subestimara gravemente la cantidad requerida de haSUI, obteniendo así una cantidad masiva de liquidez a un costo extremadamente bajo.
Técnicamente, la vulnerabilidad mencionada anteriormente proviene de que Cetus utiliza máscaras incorrectas y condiciones de juicio en el contrato inteligente Move, lo que permite que cualquier valor menor que 0xffffffffffffffff << 192 evite la detección; además, los datos de orden superior se truncan después de un desplazamiento a la izquierda de 64 bits, lo que hace que el sistema crea que ha ganado una liquidez significativa con solo una pequeña cantidad de tokens recolectados.
Después de que ocurrió el incidente, surgieron dos operaciones oficiales: "Congelar" vs "Recuperar", que son dos fases:
La cadena Sui en sí tiene un mecanismo especial de Lista de Denegación que ha permitido la congelación de los fondos de este hacker. Además, el estándar de token de Sui también tiene un modelo de "token regulado", que incluye una función de congelación incorporada.
Este congelamiento de emergencia utiliza esta característica: los nodos validadores añadieron rápidamente las direcciones relacionadas con los fondos robados en sus archivos de configuración locales. En teoría, cada operador de nodo puede modificar TransactionDenyConfig para actualizar la lista negra, pero para garantizar la consistencia de la red, la Fundación Sui, como el publicador original de la configuración, coordinó de manera central.
La fundación publicó oficialmente una actualización de configuración que contenía la dirección del hacker, y los validadores se sincronizaron de acuerdo con la configuración predeterminada, sellando temporalmente los fondos del hacker en la cadena. De hecho, hay factores altamente centralizados detrás de esto.
Para rescatar a las víctimas de fondos congelados, el equipo de Sui lanzó rápidamente un parche de mecanismo de lista blanca.
Esto es para la operación de transferir fondos de vuelta en el futuro. Puedes preconstruir transacciones legítimas y registrarlas en la lista blanca. Incluso si la dirección de los fondos todavía está en la lista negra, aún se puede ejecutar forzosamente.
Esta nueva función transaction_allow_list_skip_all_checks permite que transacciones específicas se añadan previamente a la "lista de exenciones", permitiendo que estas transacciones omitan todos los controles de seguridad, incluidos las firmas, permisos, listas negras, etc.
Es importante señalar que el parche de lista blanca no confisca directamente los activos de los hackers; solo otorga a ciertas transacciones la capacidad de eludir los congelamientos, mientras que la transferencia real de activos aún requiere una firma legal o módulos de permisos adicionales del sistema para completarse.
De hecho, las soluciones de congelación más comunes en la industria a menudo ocurren a nivel del contrato de token y son controladas por múltiples firmas del emisor.
Tomando el USDT emitido por Tether como ejemplo, su contrato tiene una función de lista negra incorporada, que permite a la empresa emisora congelar direcciones no conformes, impidiendo que estas transfieran USDT. Este esquema requiere una firma múltiple para iniciar la solicitud de congelación en la cadena, y solo se ejecuta después de que la firma múltiple alcanza un consenso, por lo que hay un retraso en la ejecución.
El mecanismo de congelación de Tether es efectivo, pero las estadísticas muestran que el proceso de firma múltiple a menudo tiene "ventanas de oportunidad", dejando espacio para que los criminales se aprovechen.
En contraste, la congelación de Sui ocurre a nivel de protocolo subyacente, operada colectivamente por nodos validadores, con una velocidad mucho más rápida que la de las llamadas de contrato regulares.
En este modelo, ejecutar rápidamente significa que la gestión de estos nodos validador en sí misma está altamente unificada.
Aún más asombroso, Sui no solo congeló los activos del hacker, sino que también planea implementar una actualización en la cadena para "devolver" los fondos robados.
El 27 de mayo, Cetus propuso un plan de votación comunitaria para actualizar el protocolo y enviar los fondos congelados a una billetera de custodia de múltiples firmas. 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 ponderados apoyando la propuesta. Los funcionarios de Sui anunciaron que una vez que la propuesta sea aprobada, "todos los fondos congelados en las dos cuentas de Hacker serán recuperados a una billetera de firma múltiple sin necesidad de las firmas de los Hacker."
No se requiere firma de hacker, qué característica tan única, la industria de blockchain nunca ha tenido un método de reparación así.
Desde el PR oficial de Sui en GitHub, queda claro que el protocolo ha introducido un mecanismo de aliasing de direcciones. La actualización incluye: la pre-especificación de reglas de alias en ProtocolConfig, permitiendo que ciertas transacciones permitidas consideren firmas válidas como enviadas desde cuentas de Hacker.
Específicamente, la lista de hashes de transacciones de rescate que se ejecutarán está vinculada a la dirección objetivo (es decir, la dirección del Hacker). Cualquier ejecutor que firme y publique estos resúmenes de transacciones fijos 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 validador eludirá la verificación de la Lista de Negación.
Desde una perspectiva de 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 itera sobre sus firmantes para comprobar si protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) es verdadero.
Mientras haya un firmante que cumpla con la regla del alias, la transacción marcada como permitida para pasar ignorará los errores de interceptación anteriores y continuará siendo empaquetada y ejecutada normalmente.
El incidente de Cetus, desde mi perspectiva personal, puede pasar rápidamente, pero este modelo no será olvidado, ya que socava la base de la industria y rompe el consenso tradicional de inmutabilidad en blockchain bajo el mismo libro mayor.
En el diseño de blockchain, los contratos son la ley y el código es el árbitro.
Sin embargo, en este incidente, el código falló, la gobernanza intervino y el poder prevaleció, formando un patrón de "comportamiento de votación que adjudica los resultados del código."
La razón es que la apropiación directa de transacciones por parte de Sui contrasta marcadamente con la forma en que las blockchains tradicionales manejan los problemas de hackers.
Históricamente:
Este es el mismo patrón de bifurcación dura, retrocediendo el libro mayor a antes del problema, después del cual los usuarios aún pueden decidir qué sistema de libro mayor continuar utilizando.
A diferencia del hard fork de DAO, Sui no eligió dividir la cadena, sino que en cambio dirigió este evento a través de actualizaciones de protocolo y alias de configuración. Al hacer esto, Sui mantiene la continuidad de la cadena y mantiene la mayoría de las reglas de consenso sin cambios, mientras que también indica que el protocolo subyacente puede ser utilizado para implementar "operaciones de rescate" específicas.
El problema es que, históricamente, los "retrocesos basados en forks" son una cuestión de elección del usuario; las "correcciones basadas en el protocolo" de Sui son decisiones tomadas en nombre de la cadena.
A largo plazo, esto significa que la idea de "No tus llaves, no tus monedas" se está socavando en la cadena Sui: incluso si los usuarios tienen las claves privadas completas, la red aún puede impedir el movimiento de activos y redirigir activos a través de cambios protocolarios colectivos.
Si esto se convierte en un precedente para que la blockchain responda a incidentes de seguridad importantes en el futuro, o incluso se considere una práctica a la que se puede adherir nuevamente.
"Cuando una cadena puede romper las reglas por la justicia, sienta un precedente para romper cualquier regla."
Una vez que hay un "agujero de dinero de bienestar público" exitoso, la próxima vez puede ser una operación en el "área gris moral".
¿Qué pasará entonces?
El hacker efectivamente robó el dinero del usuario, ¿así que puede la votación grupal quitarle su dinero?
¿La votación se basa en quién tiene más dinero (pos) o quién tiene más gente? Si el que tiene más dinero gana, entonces el productor último en la escritura de Liu Cixin llegará pronto. Si el que tiene más gente gana, entonces la multitud caótica también hará oír sus voces.
En los sistemas tradicionales, es muy normal que las ganancias ilegales no estén protegidas, y el congelamiento y la transferencia son operaciones rutinarias de los bancos tradicionales.
Pero desde una perspectiva teórica técnica, esto no se puede lograr, ¿no es la raíz del desarrollo de la industria blockchain?
El palo de la conformidad industrial está fermentando continuamente. Hoy puede congelar y modificar los saldos de las cuentas de los hackers, y mañana puede hacer modificaciones arbitrarias por factores geopolíticos y factores de conflicto. Si la cadena se convierte en una herramienta regional.
El valor de esa industria también se ha visto significativamente comprimido, en el mejor de los casos es solo otro conjunto de un sistema financiero menos útil.
Esta es también la razón por la cual el autor es firme en la industria: "La blockchain es valiosa no porque no se pueda congelar, sino porque no cambia por ti incluso si lo odias."
Había una vez que las cadenas de consorcio eran más populares que las cadenas públicas porque satisfacían las necesidades regulatorias de esa época. Hoy en día, el declive de los consorcios significa que simplemente adherirse a estas necesidades no refleja las verdaderas necesidades de los usuarios. Los usuarios que se perdieron debido a la regulación plantean la pregunta de qué herramientas regulatorias son necesarias.
Desde la perspectiva del desarrollo de la industria
"Centralización eficiente"—¿es una etapa necesaria en el desarrollo de la blockchain? Si el objetivo final de la descentralización es proteger los intereses del usuario, ¿podemos tolerar la centralización como un medio transitorio?
El término "democracia" en el contexto de la gobernanza en cadena es en realidad ponderado por tokens. Entonces, si un hacker posee una gran cantidad de SUI (o un día un DAO es hackeado y el hacker controla los derechos de voto), ¿pueden también "votar legalmente para exonerarse a sí mismos"?
En última instancia, el valor de la blockchain no radica en si puede ser congelada, sino en la elección de no hacerlo incluso cuando el grupo tiene la capacidad de congelarla.
El futuro de una cadena no está determinado por su arquitectura técnica, sino por el conjunto de creencias que elige mantener.
Este incidente es una victoria para el capital, no para los usuarios, y es un retroceso para el desarrollo de la industria.
Bitcoin a la izquierda, Sui a la derecha, cada movimiento en la industria descentralizada trae una creencia más fuerte en Bitcoin.
El mundo no solo necesita una mejor infraestructura financiera global, sino que siempre habrá un grupo de personas que necesita un espacio libre.
Érase una vez, las cadenas de consorcio eran más populares que las cadenas públicas porque satisfacían las necesidades regulatorias de esa época. Hoy en día, el declive de las cadenas de consorcio significa que simplemente cumplir con este requisito no refleja las verdaderas necesidades de los usuarios. Con la pérdida de usuarios regulados, ¿cuál es la necesidad de herramientas regulatorias?
El 22 de mayo de 2025, Cetus, el mayor intercambio descentralizado (DEX) en el ecosistema de la cadena pública Sui, sufrió un ataque de hackers, lo que resultó en una caída instantánea de la liquidez, el colapso de los precios de múltiples pares de negociación y pérdidas que superaron los 220 millones de dólares.
A partir del momento de la publicación, la cronología es la siguiente:
En cuanto a los principios de los eventos, la industria ya ha publicado varias declaraciones. Aquí, solo proporcionamos un resumen de los principios básicos:
Desde la perspectiva del proceso de ataque:
El atacante primero pidió prestados aproximadamente 10,024,321.28 haSUI utilizando un préstamo flash, lo que provocó instantáneamente que el precio en el pool de trading cayera.
99.90%. Esta masiva orden de venta hizo que el precio del pool objetivo cayera de aproximadamente 1.8956×10^19 a 1.8425×10^19, casi agotándose.
Posteriormente, el atacante creó una posición de liquidez en Cetus dentro de un rango muy estrecho (límite inferior de Tick 300000, límite superior 300200, con un ancho de rango de solo 1.00496621%). Un rango tan estrecho amplifica el impacto de los errores de cálculo subsiguientes en la cantidad de tokens requerida.
El principio básico del ataque:
Hay una vulnerabilidad de desbordamiento de enteros en la función get_delta_a utilizada por Cetus para calcular el número requerido de tokens. Un atacante afirma intencionalmente agregar una gran liquidez (aproximadamente 10^37 unidades), pero en realidad solo contribuye con 1 token al contrato.
Debido a la condición incorrecta de detección de desbordamiento de checked_shlw, el contrato experimentó truncamiento de bits altos durante los cálculos de desplazamiento a la izquierda, lo que causó que el sistema subestimara gravemente la cantidad requerida de haSUI, obteniendo así una cantidad masiva de liquidez a un costo extremadamente bajo.
Técnicamente, la vulnerabilidad mencionada anteriormente proviene de que Cetus utiliza máscaras incorrectas y condiciones de juicio en el contrato inteligente Move, lo que permite que cualquier valor menor que 0xffffffffffffffff << 192 evite la detección; además, los datos de orden superior se truncan después de un desplazamiento a la izquierda de 64 bits, lo que hace que el sistema crea que ha ganado una liquidez significativa con solo una pequeña cantidad de tokens recolectados.
Después de que ocurrió el incidente, surgieron dos operaciones oficiales: "Congelar" vs "Recuperar", que son dos fases:
La cadena Sui en sí tiene un mecanismo especial de Lista de Denegación que ha permitido la congelación de los fondos de este hacker. Además, el estándar de token de Sui también tiene un modelo de "token regulado", que incluye una función de congelación incorporada.
Este congelamiento de emergencia utiliza esta característica: los nodos validadores añadieron rápidamente las direcciones relacionadas con los fondos robados en sus archivos de configuración locales. En teoría, cada operador de nodo puede modificar TransactionDenyConfig para actualizar la lista negra, pero para garantizar la consistencia de la red, la Fundación Sui, como el publicador original de la configuración, coordinó de manera central.
La fundación publicó oficialmente una actualización de configuración que contenía la dirección del hacker, y los validadores se sincronizaron de acuerdo con la configuración predeterminada, sellando temporalmente los fondos del hacker en la cadena. De hecho, hay factores altamente centralizados detrás de esto.
Para rescatar a las víctimas de fondos congelados, el equipo de Sui lanzó rápidamente un parche de mecanismo de lista blanca.
Esto es para la operación de transferir fondos de vuelta en el futuro. Puedes preconstruir transacciones legítimas y registrarlas en la lista blanca. Incluso si la dirección de los fondos todavía está en la lista negra, aún se puede ejecutar forzosamente.
Esta nueva función transaction_allow_list_skip_all_checks permite que transacciones específicas se añadan previamente a la "lista de exenciones", permitiendo que estas transacciones omitan todos los controles de seguridad, incluidos las firmas, permisos, listas negras, etc.
Es importante señalar que el parche de lista blanca no confisca directamente los activos de los hackers; solo otorga a ciertas transacciones la capacidad de eludir los congelamientos, mientras que la transferencia real de activos aún requiere una firma legal o módulos de permisos adicionales del sistema para completarse.
De hecho, las soluciones de congelación más comunes en la industria a menudo ocurren a nivel del contrato de token y son controladas por múltiples firmas del emisor.
Tomando el USDT emitido por Tether como ejemplo, su contrato tiene una función de lista negra incorporada, que permite a la empresa emisora congelar direcciones no conformes, impidiendo que estas transfieran USDT. Este esquema requiere una firma múltiple para iniciar la solicitud de congelación en la cadena, y solo se ejecuta después de que la firma múltiple alcanza un consenso, por lo que hay un retraso en la ejecución.
El mecanismo de congelación de Tether es efectivo, pero las estadísticas muestran que el proceso de firma múltiple a menudo tiene "ventanas de oportunidad", dejando espacio para que los criminales se aprovechen.
En contraste, la congelación de Sui ocurre a nivel de protocolo subyacente, operada colectivamente por nodos validadores, con una velocidad mucho más rápida que la de las llamadas de contrato regulares.
En este modelo, ejecutar rápidamente significa que la gestión de estos nodos validador en sí misma está altamente unificada.
Aún más asombroso, Sui no solo congeló los activos del hacker, sino que también planea implementar una actualización en la cadena para "devolver" los fondos robados.
El 27 de mayo, Cetus propuso un plan de votación comunitaria para actualizar el protocolo y enviar los fondos congelados a una billetera de custodia de múltiples firmas. 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 ponderados apoyando la propuesta. Los funcionarios de Sui anunciaron que una vez que la propuesta sea aprobada, "todos los fondos congelados en las dos cuentas de Hacker serán recuperados a una billetera de firma múltiple sin necesidad de las firmas de los Hacker."
No se requiere firma de hacker, qué característica tan única, la industria de blockchain nunca ha tenido un método de reparación así.
Desde el PR oficial de Sui en GitHub, queda claro que el protocolo ha introducido un mecanismo de aliasing de direcciones. La actualización incluye: la pre-especificación de reglas de alias en ProtocolConfig, permitiendo que ciertas transacciones permitidas consideren firmas válidas como enviadas desde cuentas de Hacker.
Específicamente, la lista de hashes de transacciones de rescate que se ejecutarán está vinculada a la dirección objetivo (es decir, la dirección del Hacker). Cualquier ejecutor que firme y publique estos resúmenes de transacciones fijos 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 validador eludirá la verificación de la Lista de Negación.
Desde una perspectiva de 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 itera sobre sus firmantes para comprobar si protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) es verdadero.
Mientras haya un firmante que cumpla con la regla del alias, la transacción marcada como permitida para pasar ignorará los errores de interceptación anteriores y continuará siendo empaquetada y ejecutada normalmente.
El incidente de Cetus, desde mi perspectiva personal, puede pasar rápidamente, pero este modelo no será olvidado, ya que socava la base de la industria y rompe el consenso tradicional de inmutabilidad en blockchain bajo el mismo libro mayor.
En el diseño de blockchain, los contratos son la ley y el código es el árbitro.
Sin embargo, en este incidente, el código falló, la gobernanza intervino y el poder prevaleció, formando un patrón de "comportamiento de votación que adjudica los resultados del código."
La razón es que la apropiación directa de transacciones por parte de Sui contrasta marcadamente con la forma en que las blockchains tradicionales manejan los problemas de hackers.
Históricamente:
Este es el mismo patrón de bifurcación dura, retrocediendo el libro mayor a antes del problema, después del cual los usuarios aún pueden decidir qué sistema de libro mayor continuar utilizando.
A diferencia del hard fork de DAO, Sui no eligió dividir la cadena, sino que en cambio dirigió este evento a través de actualizaciones de protocolo y alias de configuración. Al hacer esto, Sui mantiene la continuidad de la cadena y mantiene la mayoría de las reglas de consenso sin cambios, mientras que también indica que el protocolo subyacente puede ser utilizado para implementar "operaciones de rescate" específicas.
El problema es que, históricamente, los "retrocesos basados en forks" son una cuestión de elección del usuario; las "correcciones basadas en el protocolo" de Sui son decisiones tomadas en nombre de la cadena.
A largo plazo, esto significa que la idea de "No tus llaves, no tus monedas" se está socavando en la cadena Sui: incluso si los usuarios tienen las claves privadas completas, la red aún puede impedir el movimiento de activos y redirigir activos a través de cambios protocolarios colectivos.
Si esto se convierte en un precedente para que la blockchain responda a incidentes de seguridad importantes en el futuro, o incluso se considere una práctica a la que se puede adherir nuevamente.
"Cuando una cadena puede romper las reglas por la justicia, sienta un precedente para romper cualquier regla."
Una vez que hay un "agujero de dinero de bienestar público" exitoso, la próxima vez puede ser una operación en el "área gris moral".
¿Qué pasará entonces?
El hacker efectivamente robó el dinero del usuario, ¿así que puede la votación grupal quitarle su dinero?
¿La votación se basa en quién tiene más dinero (pos) o quién tiene más gente? Si el que tiene más dinero gana, entonces el productor último en la escritura de Liu Cixin llegará pronto. Si el que tiene más gente gana, entonces la multitud caótica también hará oír sus voces.
En los sistemas tradicionales, es muy normal que las ganancias ilegales no estén protegidas, y el congelamiento y la transferencia son operaciones rutinarias de los bancos tradicionales.
Pero desde una perspectiva teórica técnica, esto no se puede lograr, ¿no es la raíz del desarrollo de la industria blockchain?
El palo de la conformidad industrial está fermentando continuamente. Hoy puede congelar y modificar los saldos de las cuentas de los hackers, y mañana puede hacer modificaciones arbitrarias por factores geopolíticos y factores de conflicto. Si la cadena se convierte en una herramienta regional.
El valor de esa industria también se ha visto significativamente comprimido, en el mejor de los casos es solo otro conjunto de un sistema financiero menos útil.
Esta es también la razón por la cual el autor es firme en la industria: "La blockchain es valiosa no porque no se pueda congelar, sino porque no cambia por ti incluso si lo odias."
Había una vez que las cadenas de consorcio eran más populares que las cadenas públicas porque satisfacían las necesidades regulatorias de esa época. Hoy en día, el declive de los consorcios significa que simplemente adherirse a estas necesidades no refleja las verdaderas necesidades de los usuarios. Los usuarios que se perdieron debido a la regulación plantean la pregunta de qué herramientas regulatorias son necesarias.
Desde la perspectiva del desarrollo de la industria
"Centralización eficiente"—¿es una etapa necesaria en el desarrollo de la blockchain? Si el objetivo final de la descentralización es proteger los intereses del usuario, ¿podemos tolerar la centralización como un medio transitorio?
El término "democracia" en el contexto de la gobernanza en cadena es en realidad ponderado por tokens. Entonces, si un hacker posee una gran cantidad de SUI (o un día un DAO es hackeado y el hacker controla los derechos de voto), ¿pueden también "votar legalmente para exonerarse a sí mismos"?
En última instancia, el valor de la blockchain no radica en si puede ser congelada, sino en la elección de no hacerlo incluso cuando el grupo tiene la capacidad de congelarla.
El futuro de una cadena no está determinado por su arquitectura técnica, sino por el conjunto de creencias que elige mantener.