Artículos

Materiales educativos y tutoriales sobre Sui

Gana tu parte de 1000 Sui

Gana puntos de reputación y obtén recompensas por ayudar a crecer a la comunidad de Sui.

Publicaciones

Owen15
Jun 01, 2025
Artículo
Sui Cetus DeFi Hack: implicaciones globales para el ecosistema
En mayo de 2025, el ecosistema blockchain de Sui se enfrentó a una importante brecha de seguridad que conmocionó al mundo de las finanzas descentralizadas (DeFi). ElProtocolo Cetus, una bolsa descentralizada (DEX) emblemática de Sui, fue explotada en un devastador hackeo que agotó más de 220 millones de dólares**en activos digitales. Este incidente no solo generó serias preocupaciones sobre la seguridad de los protocolos DeFi dentro de la red Sui, sino que también puso de relieve vulnerabilidades más amplias en el panorama mundial de DeFi. ¿Qué pasó durante el hackeo de Cetus? Cetus Protocoles el protocolo de liquidez y DEX líder en Sui, y sirve como infraestructura clave para las permutas de fichas, la agricultura de rendimiento y la provisión concentrada de liquidez. Creado con el lenguaje de programaciónMove, fue elogiado por su arquitectura de alto rendimiento y su profunda integración con los tokens SUI nativos. El22 de mayo de 2025, una actividad anormal en los fondos de liquidez de Cetus activó las alarmas. La profundidad de las piscinas disminuyó rápidamente y pronto se confirmó que la plataforma había sido hackeada. Los atacantes agotaron activos de las reservas de liquidez por un valor comprendido entre 220 y 260 millones de dólares**. Si bien la vulnerabilidad exacta sigue siendo investigada, los primeros análisis sugieren que la vulnerabilidad podría haber implicado: Manipulación de los cálculos del fondo de liquidez Eludir los controles de gobernanza El equipo de Cetus detuvo rápidamente las operaciones e inició los esfuerzos de recuperación, trabajando en estrecha colaboración con losvalidadores de Sui y las empresas de análisis de cadenas de bloquespara rastrear y congelar los fondos robados. Las consecuencias inmediatas para los usuarios de Sui y Cetus Las repercusiones fueron inmediatas y graves: Caída del token CETUS: el token de gobernanza nativo de la plataforma perdió más del 60% de su valor**en cuestión de horas. Pérdidas de los proveedores de liquidez**: Muchos LP vieron desaparecer sus activos depositados. Pánico en todo el ecosistema**: varias otras plataformas DeFi de Sui interrumpieron temporalmente sus operaciones o se sometieron a auditorías de emergencia. A pesar de ello, había un resquicio de esperanza: la comunidad de validadoresSui consiguió congelar hasta 160 millones de dólaresde los fondos robados, lo que ofrecía la esperanza de una recuperación parcial. Qué significa el hackeo de Cetus para el ecosistema Sui 1.Descubriendo las brechas de seguridad en los contratos de Move Smart Si bien el lenguaje de programaciónMoveestá diseñado con sólidas garantías de seguridad (incluida una mejor gestión de la memoria y un mejor control de los recursos que Solidity), el hackeo de Cetus puso de manifiesto que incluso los sistemas bien estructurados pueden tener fallas críticas cuando se trata de una lógica compleja de DeFi, como las llamadas entre contratos, los módulos de gobierno o los mecanismos dinámicos de precios. Este evento sirvió como una llamada de atención para que los desarrolladores de Sui: Invierta más enverificaciones formales y auditorías de terceros Adoptemecanismos de gobernanza y actualizaciónmás estrictos Mejorar latransparencia en torno a la divulgación de riesgos 2.Potencial de un mayor control regulatorio A medida que DeFi continúa creciendo a nivel mundial, los reguladores están vigilando de cerca. Un hackeo de alto perfil como este puede provocar un mayor escrutinio de los protocolos de DeFi, especialmente aquellos que operan en cadenas de bloques emergentes como Sui. Las autoridades podrían presionar para que: Denunciar obligatoriamente los ataques informáticos Marcos de responsabilidad para los equipos de proyectos Requisitos de cumplimiento para las plataformas DeFi 3.Reevaluando la confianza en los ecosistemas emergentes de DeFi Sui se ha posicionado como una cadena de bloques de nivel 1 escalable y de alto rendimiento, que ha atraído una gran atención por parte de los desarrolladores e inversores de DeFi. Sin embargo, el incidente de Cetus puso de relieve los riesgos asociados a los ecosistemas más nuevos, en los que las herramientas de contratación inteligente y las prácticas de auditoría aún están madurando. Los inversores y desarrolladores ahora se están replanteando la forma en que abordan la evaluación de riesgos, y muchos abogan por: Mecanismos de seguro descentralizados Custodia de fondos con firmas múltiples Herramientas de monitoreo en tiempo real Lecciones para la industria global de DeFi 1.La complejidad aumenta el riesgo Los protocolos DeFi a menudo implementan modelos económicos y diseños algorítmicos novedosos, que pueden introducir consecuencias no deseadas. El hackeo de Cetus muestra que incluso los sistemas bien diseñados pueden verse comprometidos si los componentes principales, como los precios o la gobernanza, no se prueban y auditan rigurosamente. 2.La transparencia genera confianza Durante la crisis, el equipo de Cetus fue elogiado por su comunicación oportuna y su colaboración proactiva con el ecosistema Sui. Las actualizaciones transparentes ayudaron a mitigar los daños adicionales y a estabilizar la confianza de los usuarios. 3.La recuperación es posible, pero la confianza lleva tiempo Si bien una gran parte de los fondos robados se congelaron y es posible que se recuperen, restablecer la confianza llevará tiempo. Es probable que los usuarios exijan mayores garantías antes de volver a depositar fondos en los protocolos DeFi. Esto podría conducir a una mayor adopción de: Seguro integrado en cadena Herramientas de monitoreo en tiempo real Bases de código de código abierto para la auditabilidad pública De cara al futuro: ¿qué sigue para Sui y DeFi? A pesar del revés, el ecosistema Sui sigue siendo resiliente. La capacidad de los validadores para congelar y, potencialmente, recuperar los fondos robados demuestra el poder de la gobernanza coordinada en cadena y los mecanismos de respuesta rápida. En el futuro, podemos esperar ver: Mayor énfasis en lasauditorías de seguridad y la verificación formalpara los contratos basados en Move Máscolaboración entre los equipos de DeFi y las redes blockchainpara mejorar las capacidades de respuesta a incidentes Crecimiento de lasherramientas de mitigación de riesgos, incluidos los seguros descentralizados y la gestión de tesorería multifirma Conclusión: una dura lección para DeFi Elhackeo de Sui Cetus DeFifue un momento de aprendizaje doloroso pero necesario para toda la industria de la cadena de bloques. A medida que DeFi continúa evolucionando, también deben hacerlo nuestros enfoques de seguridad, gobernanza y gestión de riesgos. Solo mediante la mejora continua, la transparencia y la responsabilidad compartida, el ecosistema puede volverse más seguro y confiable para todos los participantes.
- Sui
0
harry phan421
May 31, 2025
Artículo
Analizando el exploit del protocolo Cetus en Sui
El 22 de mayo de 2025, un importante ataque tuvo como objetivo el Protocolo Cetus en la cadena de bloques Sui, lo que provocó daños estimados en 223 millones de dólares. Este incidente atrajo la atención inmediata de todo el ecosistema, especialmente de parte de los observadores técnicos, debido a la inusual mecánica que implicaba. Lo que sigue es un análisis exhaustivo del ataque, desde el intercambio flash y la manipulación de marcas hasta una vulnerabilidad silenciosa en la lógica de detección de desbordamientos. https://suiscan.xyz/mainnet/tx/DVMG3B2kocLEnVMDuQzTYRgjwuuFSfciawPvXXheB3x La configuración El atacante inició el exploit utilizando flash_swap para pedir prestada una gran cantidad de tokens SUI a cambio de HaSui. A diferencia de los flashloans tradicionales, flash_swap en Cetus permite al usuario recibir el token1 (SUI en este caso) por adelantado y luego reembolsar el token0 (HaSui) en la misma transacción. Este mecanismo es fundamental para la configuración del atacante. En este caso concreto, el atacante adquirió con éxito 5,76 millones de SUI y se vio obligado a reembolsar 10,02 millones de HaSui. Sin embargo, durante esta permuta, el precio de HaSui en el fondo de liquidez se manipuló drásticamente. El precio del pool bajó de un tic, que representaba una ratio de 1,056, a un precio tan bajo que el precio alcanzó tan solo el 0,0000009977, lo que supuso una enorme devaluación hasta el 0,00009% de su precio original. El rango de precios correspondiente al rango de garrapatas es: Inyección estratégica de liquidez Tras esta caída de precios, el atacante utilizó open_position para crear una posición de liquidez de rango estrecho y eligió un rango de cotización muy específico (TickLower: 300000, TickUpper: 300200). En este entorno manipulado, inyectaron una cantidad astronómica de liquidez: más de 10^34 unidades, todo ello dentro del rango de precios ultracomprimido creado por la caída del tic-tic. Esto fue posible gracias a una función aparentemente inocua: get_amount_by_liquidity. En condiciones normales, esta función calcula la cantidad de token A y B que se necesita para alcanzar un determinado nivel de liquidez. Para ello, utiliza funciones auxiliares como get_delta_a, que se basa en get_sqrt_price_at_tick. Sin embargo, dado que el tic actual manipulado es -138185 y que el rango de ticks elegido está muy por encima de ese valor (empezando en 300 000), la ruta lógica dentro de get_amount_by_liquidity garantizaba que los cálculos pasaran por una sección vulnerable del código en la que se realizaba una operación de desplazamiento a la izquierda (checked_shlw). Desbordamiento y truncamiento: la principal vulnerabilidad Aquí es donde el exploit se vuelve verdaderamente técnico. Se supone que la función checked_shlw permite desplazar a la izquierda un número de 256 bits por 64 bits. En entornos similares a Solidity, una operación de este tipo es arriesgada, ya que puede desbordarse. Esta implementación en particular intentó detectar los desbordamientos comprobando si la entrada superaba un umbral predefinido: 0xffffffffffffffffff << 192. El umbral real para detectar un cambio seguro en 64 bits debería ser 2^ (256 - 64) - 1. Sin embargo, (0xffffffffffffffff << 192) es mayor que 2^192. Esto significa que una entrada elegida con cuidado podría eludir la comprobación de desbordamiento al estar por debajo del umbral utilizado en el código, pero seguir siendo lo suficientemente grande como para provocar un desbordamiento durante la ejecución. El atacante proporcionó una entrada de este tipo, en la que la multiplicación de la liquidez y la diferencia de precio se desbordó silenciosamente, lo que arrojó un valor mucho menor al previsto (de hecho, casi cero). Como resultado, el protocolo calculó que el atacante solo tenía que pagar una cantidad insignificante de fichas (básicamente una unidad) para añadir una enorme liquidez a la reserva. Este error de cálculo permitió al atacante inyectar una enorme liquidez sin coste real. Posteriormente, el atacante eliminó la liquidez añadida a través de remove_liquidity y completó el ataque pagando las fichas impagadas de flash_swap a través de repay_flash_swap. El atacante obtuvo un beneficio de 5.765.124 SUI y 10.024.321 HaSUI. Finalmente, el equipo de Cetus solucionó la vulnerabilidad mediante dos RP: https://github.com/CetusProtocol/integer-mate/pull/6/files Cetus publicó rápidamente un parche en su repositorio de números enteros, y la primera solicitud de extracción intentaba refinar la detección de desbordamientos. Sin embargo, esa solución inicial era inadecuada. Utilizaba una máscara de 1 << 192, que aun así permitía que los valores en mayúsculas y minúsculas pasaran desapercibidos. Se realizó una segunda solicitud de extracción seguida de una comparación más estricta, en la que se comprobaba que la entrada era mayor o igual a 2^192, lo que garantizaba unos límites adecuados para desplazar a la izquierda de forma segura. Solo con esta corrección se mitigó la vulnerabilidad de manera efectiva. https://github.com/CetusProtocol/integer-mate/pull/7/files
- Sui
2
0xduckmove308
May 31, 2025
Artículo
Convertir las carteras en agentes inteligentes programables y componibles.
Account.tech es un marco de código abierto en la cadena de bloques Sui que introduce cuentas inteligentes altamente fluidas Objetos de cuenta flexibles, seguros y personalizables que pueden ejecutar acciones en cadena a través de una arquitectura modular basada en la intención. Piense en ello como carteras programables con soporte nativo para múltiples firmas, lógica DAO, ejecución programada, control de acceso dinámico y mucho más. ¿Por qué elegir cuentas inteligentes? Las cuentas tradicionales son solo contenedores pasivos. Mantienen activos y firman transacciones. Las cuentas inteligentes son entidades activas y programables que pueden definir la lógica de propiedad, automatizar los flujos de trabajo y administrar los activos en función de las reglas. Con Account.tech, estas reglas funcionan en cadena, se pueden personalizar a través de los módulos Move y se aplican mediante Intents. Conceptos clave Estructura de cuenta inteligente public struct Account has key, store { id: UID, metadata: Metadata, deps: Deps, intents: Intents, config: Config, } Una cuenta inteligente es un objeto compartido que contiene: Metadatos: información descriptiva Deps: paquetes de dependencia utilizados Intentos: solicitudes pendientes o activas para realizar acciones Configuración: el conjunto de reglas personalizado (p. ej., lógica DAO multifirma, basada en roles) Cada cuenta tiene un módulo de configuración único que determina cómo se resuelven las intenciones. Ejecución basada en la intención Una intención es una solicitud estructurada para realizar una o más acciones en cadena. Progresa a través de 3 etapas: [ ] Solicita al usuario que cree la intención con acciones [ ] Resolución: el módulo de configuración comprueba si se cumplen las condiciones [ ] Ejecución: cualquiera puede ejecutar la intención cuando es válida Ejemplo: una intención multifirma de transferir fondos solo se ejecutará una vez que un número suficiente de miembros la haya aprobado. Acciones = Unidades de ejecución modulares Cada acción es una estructura de movimiento independiente, como: struct WithdrawAction { object_id: ID } struct TransferAction { recipient: address } Puedes crear varias acciones en una sola intención. Por ejemplo: Withdraw → Transfer → Withdraw → Transfer Esto permite flujos de trabajo avanzados, como intercambios atómicos, transferencias por lotes, lanzamientos de bóvedas basados en el tiempo, etc. Configuración: lógica de propiedad personalizable El tipo de configuración define cómo se resuelven las intenciones. Puedes incluir lógica como la siguiente: ✅ Multisig con votos ponderados 🔐 Control de acceso basado en roles 🗳 Lógica de votación de DAO ⏳ Retrasos de tiempo o tareas recurrentes 💾 Flujos de recuperación Cada intención refleja un resultado, que representa el estado de la resolución (por ejemplo, los votos recopilados, las aprobaciones concedidas, etc.). Más información 🔗 Documentos: https://account-tech.gitbook.io/docs 🧑‍💻 GitHub: https://github.com/account-tech
- Sui
1
0xduckmove308
May 30, 2025
Artículo
Codificación BCS en Sui: qué es y por qué es importante
Si te estás basando en Sui o jugando con Move, es probable que hayas escuchado el término BCS por ahí. Es la abreviatura de la máquina formateadora de serialización canónica binaria creada originalmente para la cadena de bloques Diem, y ahora es la piedra angular de los ecosistemas basados en Move, como Sui, Aptos, Starcoin y 0L. Así que sí, es mejor que te sientas cómodo con ello si realmente quieres construir en este espacio. ¿Qué es BCS? La serialización canónica binaria (BCS) es un formato que se utiliza para serializar (codificar) y deserializar (decodificar) datos estructurados en bytes. Verás que se usa cuando: Codificar las transacciones antes de firmarlas. Emitir o analizar eventos desde la cadena de bloques. Interactuar con Move Smart Contracts fuera de la cadena a través de JavaScript. Sin embargo, BCS no incluye información de tipos en los bytes. Esto significa que debes conocer la estructura con antelación al decodificar, a diferencia de los formatos como JSON o Protocol Buffers, que se describen más por sí mismos. Características principales de BCS No hay ningún tipo de metadatos La salida serializada no contiene sugerencias sobre los tipos de campos. Debes saber a qué te enfrentas cuando decodificas. Serialización dependiente del pedido Las estructuras se codifican en el orden exacto de sus campos. Cambie el orden y la deserialización se interrumpirá. Esta es la razón por la que las funciones peel_* de Move deben coincidir con el diseño 1:1. Tipo genérico En una estructura como: struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata, generic: T } Solo puede deserializar de forma fiable hasta el metacampo. Los tipos genéricos estropean el análisis del BCS, así que póngalos siempre en último lugar si desea que sus datos se decodifiquen de forma segura. Uso de BCS en JavaScript Gracias a la biblioteca @mysten /bcs, puedes trabajar con BCS en JS como un profesional. npm i @mysten/bcs y un ejemplo básico: import { BCS, getSuiMoveConfig } from "@mysten/bcs"; const bcs = new BCS(getSuiMoveConfig()); const ser = bcs.ser(BCS.U16, 10); console.log(ser.toBytes()); // [0x0a, 0x00] const des = bcs.de(BCS.U16, ser.toBytes()); console.log(des); // 10 También puede serializar vectores y cadenas: bcs.ser("vector", [1, 2, 3, 4]); // 04 01 02 03 04 bcs.ser(BCS.STRING, "test string"); // 0b7465737420737472696e67 Registro de tipos personalizados Supongamos que tienes las siguientes estructuras de movimiento: struct Metadata has drop, copy { name: std::ascii::String } struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata } Puedes registrarlos así en JS: bcs.registerStructType("Metadata", { name: BCS.STRING, }); bcs.registerStructType("BCSObject", { id: BCS.ADDRESS, owner: BCS.ADDRESS, meta: "Metadata", }); Ejemplo de serialización y deserialización Serialización de JavaScript: const bytes = bcs .ser("BCSObject", { id: "0x0000000000000000000000000000000000000005", owner: "0x000000000000000000000000000000000000000a", meta: { name: "aaa" } }) .toString("hex"); console.log("Hex:", bytes); La salida puede ser: 0x0000000000000000000000000000000000000005000000000000000000000000000000000000000a03616161 Esto ahora puede transferirse a un contrato de Move o incluso probarse manualmente en la CLI de Sui. El BCS puede parecer de bajo nivel y con muchos bytes, pero una vez que comprendas cómo codifica los datos, comprenderás mejor cómo funcionan realmente los contratos inteligentes de Move y cómo conectar sistemas on-chain ↔ off-chain de forma segura. Y si estás depurando los bytes del BCS en Sui Explorer (como el que se muestra a continuación): Codificación BCS La serialización canónica binaria, o BCS, es un formato de serialización desarrollado en el contexto de la cadena de bloques Diem, y ahora se usa ampliamente en la mayoría de las cadenas de bloques basadas en Move (Sui, Starcoin, Aptos, 0L). El BCS no solo se usa en la máquina virtual Move, sino que también se usa en la codificación de transacciones y eventos, como la serialización de las transacciones antes de firmarlas o el análisis de datos de eventos. Saber cómo funciona BCS es crucial si quieres entender cómo funciona Move a un nivel más profundo y convertirte en un experto en Move. Vamos a sumergirnos. Especificaciones y propiedades del BCS Hay algunas propiedades de alto nivel de la codificación BCS que conviene tener en cuenta a medida que avancemos en el resto de la lección: El BCS es un formato de serialización de datos en el que los bytes de salida resultantes no contienen ningún tipo de información; por ello, la parte que reciba los bytes codificados necesitará saber cómo deserializar los datos En BCS no hay estructuras (ya que no hay tipos); la estructura simplemente define el orden en el que se serializan los campos Los tipos de contenedores se ignoran, por lo que OuterType y UnnestedType tendrán la misma representación de BCS: estructura: outerType { propietario: innerType } estructura InnerType { dirección: dirección } estructura UnnestedType { dirección: dirección } Los tipos que contienen los campos de tipo genérico se pueden analizar hasta el primer campo de tipo genérico. Por lo tanto, es una buena práctica poner los campos de tipo genérico en último lugar si se trata de un tipo personalizado que se va a ser/eliminar. struct bcSObject tiene drop, copy { id: ID, propietario: dirección, meta: metadatos, genérico: T } En este ejemplo, podemos deserializar todo hasta el metacampo. Los tipos primitivos, como las entradas sin signo, están codificados en formato Little Endian El vector se serializa con una longitud ULEB128 (con una longitud máxima de hasta u32) seguida del contenido del vector. La especificación BCS completa se encuentra en el repositorio BCS. Uso de la biblioteca de JavaScript @mysten /bcs Instalación La biblioteca que necesitará instalar para esta parte es la biblioteca @mysten /bcs. Puedes instalarla escribiendo en el directorio raíz de un proyecto de nodo: npm i @mysten /bcs Ejemplo básico Utilicemos primero la biblioteca de JavaScript para serializar y deserializar algunos tipos de datos simples: importar {BCS, getSuiMoveConfig} desde "@mysten /bcs «; //inicializa el serializador con las configuraciones predeterminadas de Sui Move const bcs = new BCS (getSuiMoveConfig ()); //Definir algunos tipos de datos de prueba entero constante = 10; matriz constante = [1, 2, 3, 4]; const string = «cadena de prueba» //usa bcs.ser () para serializar los datos const ser_integer = bcs.ser (BCS.U16, entero); const ser_array = bcs.ser («vector «, matriz); const ser_string = bcs.ser (BCS.STRING, cadena); //usa bcs.de () para deserializar datos const de_integer = bcs.de (BCS.U16, SER_Integer.toBytes ()); const de_array = bcs.de («vector «, ser_Array.toBytes ()); const de_string = bcs.de (BCS.STRING, ser_string.tobytes ()); Podemos inicializar la instancia del serializador con la configuración predeterminada integrada para Sui Move usando la sintaxis anterior, new BCS (getSuiMoveConfig ()). Hay enumeraciones integradas que se pueden usar para los tipos de Sui Move, como BCS.U16, BCS.STRING, etc. Para los tipos genéricos, se pueden definir usando la misma sintaxis que en Sui Move, como el vector del ejemplo anterior. Echemos un vistazo más de cerca a los campos serializados y deserializados: las entradas son hexadecimales mendianos 0a00 10 el primer elemento de un vector indica la longitud total, entonces son los elementos que están en el vector 0401020304 1,2,3,4 las cadenas son solo vectores de u8, con el primer elemento igual a la longitud de la cadena 0b7465737420737472696e67 cadena de prueba Escriba el registro Podemos registrar los tipos personalizados con los que trabajaremos usando la siguiente sintaxis: importar {BCS, getSuiMoveConfig} desde "@mysten /bcs «; const bcs = new BCS (getSuiMoveConfig ()); //Registrar el tipo de metadatos bcs.registerStructType («Metadatos», { nombre: BCS.STRING, }); //Lo mismo para el objeto principal que pretendemos leer bcs.registerStructType («bcsObject», { //BCS.ADDRESS se usa tanto para tipos de ID como para tipos de direcciones id: BCS.ADDRESS, propietario: BCS.ADDRESS, meta: «Metadatos», }); Uso de bcs en Sui Smart Contracts Continuemos con nuestro ejemplo de arriba con las estructuras. Definición de estructura Empezamos con las definiciones de estructura correspondientes en el contrato Sui Move. { //.. estructura Los metadatos han eliminado, copiado { nombre: std: :ascii: :String } struct bcSObject ha caído, copia { id: ID, propietario: dirección, meta: Metadatos } //.. } Deserialización Ahora, escribamos la función para deserializar un objeto en un contrato Sui. public fun object_from_bytes (bcs_bytes: vector): bcSObject { //Inicializa la instancia de bcs bytes let bcs = bcs: :new (bcs_bytes); //Usa peel_*funciones para eliminar los valores de los bytes serializados. //¡El orden tiene que ser el mismo que usamos en la serialización! let (id, owner, meta) = ( bcs: :peel_address (&mut bcs), bcs: :peel_address (&mut bcs), bcs: :peel_vec_u8 (&mut bcs) ); //Empaquete una estructura BCSObject con los resultados de la serialización BCSObject {id: object: :id_from_address (id), owner, meta: Metadata {name: std: :ascii: :string (meta)}} Los distintos métodos peel_* del módulo bcs de Sui Frame se utilizan para «separar» cada campo individual de los bytes serializados de BCS. Tenga en cuenta que el orden en que eliminamos los campos debe ser exactamente el mismo que el orden de los campos en la definición de la estructura. Cuestionario: ¿Por qué los resultados de las dos primeras llamadas a peel_address en el mismo objeto bcs no son los mismos? Observa también cómo convertimos los tipos de address a id y de vector a std: :ascii: :string con funciones auxiliares. Cuestionario: ¿Qué pasaría si BSCobject tuviera un tipo de UID en lugar de un tipo de ID? Ejemplo completo de Ser/De Encuentra los códigos de muestra completos de JavaScript y Sui Move en la carpeta example_projects. Primero, serializamos un objeto de prueba usando el programa JavaScript: //Construimos un objeto de prueba para serializarlo, ten en cuenta que podemos especificar el formato de la salida en hexadecimal let _bytes = bcs .ser («bcsObject», { id: «0x00000000000000000000000000000005", propietario: «0x0000000000000000000000000000000a», meta: {nombre: «aaa"} }) .toString («hexadecimal»); Queremos que la salida del escritor BCS esté en formato hexadecimal esta vez, que se puede especificar como se indica arriba. Añada el prefijo 0x a la cadena hexadecimal del resultado de la serialización y expórtela a una variable de entorno: export Object_hexstring=0x000000000000000000000000000000000005000000000000000000000000000000000000000000000000000A03616161 Ahora podemos ejecutar las pruebas unitarias de Move asociadas para comprobar que son correctas: Una prueba de movimiento adecuada Deberías ver esto en la consola: CONSTRUYENDO bcs_move Ejecutando pruebas unitarias de Move [PASS] 0x0: :bcs_object: :test_deserialization Resultado de la prueba: OK. Total de pruebas: 1; superadas: 1; fallidas: 0 O podemos publicar el módulo (y exportar el PACKAGE_ID) y llamar al método emit_object utilizando la cadena hexagonal serializada de BCS anterior: sui client call --function emit_object --module bcs_object --package $PACKAGE_ID --args $OBJECT_HEXSTRING A continuación, podemos comprobar la pestaña Eventos de la transacción en el explorador Sui para comprobar que hemos emitido el BCSObject deserializado correctamente:
- Sui
- SDKs and Developer Tools
1
Vens.sui134
May 29, 2025
Artículo
Hackeo del protocolo Cetus: el mayor exploit de DeFi en Sui
En mayo de 2025, el mundo de las DeFi se vio sacudido por una de las brechas de seguridad más importantes de la historia reciente. Cetus Protocol, uno de los principales protocolos de intercambio descentralizado (DEX) y liquidez de la cadena de bloques Sui, fue víctima de un sofisticado hackeo que provocó pérdidas que superaron los 200 millones de dólares. Este incidente no solo conmocionó a la comunidad de DeFi, sino que también generó serias preocupaciones sobre la seguridad de los contratos inteligentes y la solidez de los protocolos basados en cadenas de bloques emergentes como Sui. Cetus Protocol se había establecido como el principal DEX de la red Sui, ofreciendo a los usuarios una plataforma para intercambiar tokens y proporcionar liquidez. Como componente clave de la infraestructura dentro del ecosistema Sui, Cetus desempeñó un papel fundamental a la hora de facilitar el comercio descentralizado y contribuir a la liquidez general de la red. Su prominencia lo convirtió en un objetivo atractivo para los actores malintencionados que buscan explotar las vulnerabilidades en su base de código. Se desarrolla el hackeo de Cetus La violación se produjo el 22 de mayo de 2025, cuando los atacantes identificaron y explotaron una falla crítica en la lógica de los contratos inteligentes de Cetus. Concretamente, la vulnerabilidad se debía a un sutil error de desbordamiento aritmético que permitía al pirata informático manipular los mecanismos de contabilidad internos del protocolo. Al utilizar fichas falsas y manipular las curvas de precios de los fondos de liquidez, el atacante pudo drenar enormes cantidades de fondos sin activar sistemas de detección inmediata. Aproximadamente a las 3:52 a.m. PT (11:52 UTC), los monitores de la cadena de bloques comenzaron a detectar transacciones irregulares en varios fondos de liquidez de Cetus. En cuestión de horas, quedó claro el alcance de los daños: se habían desviado activos del protocolo por valor de más de 260 millones de dólares. Los fondos robados se intercambiaron rápidamente y se transfirieron a otras cadenas de bloques, lo que complicó los esfuerzos de recuperación. Impacto en el mercado y en el ecosistema Sui Las secuelas del hackeo fueron rápidas y graves. Las operaciones en Cetus se interrumpieron de inmediato, ya que los desarrolladores se apresuraron a evaluar la situación y mitigar las pérdidas adicionales. Mientras tanto, el valor de los tokens nativos asociados a la plataforma se desplomó, y algunos experimentaron caídas de hasta el 80% en cuestión de horas. Los inversores y los usuarios se enfrentaron a pérdidas masivas y la confianza en el ecosistema Sui se vio afectada. Un hecho particularmente alarmante se produjo cuando la red Sui intentó adoptar una controvertida contramedida: votar a favor de congelar la cartera del atacante que contenía 160 millones de dólares de los fondos robados. Si bien esta medida demostró un enfoque proactivo para la recuperación de activos, también generó debates sobre los principios de descentralización y sobre si tales acciones socavaban la confianza en la inmutabilidad de las transacciones basadas en la cadena de bloques. En un momento dado, el USD SUI perdió un 5% y el USD CETUS perdió un +- 40%, lo que supuso un salto increíble y aterrador a la vez. Detalles técnicos del exploit del protocolo Cetus Según el análisis proporcionado por la empresa de ciberseguridad Halborn, la causa principal del exploit radica en la forma en que Cetus validaba ciertas operaciones aritméticas durante el intercambio de tokens. Un descuido en la gestión de grandes cantidades provocó una situación de desbordamiento, que el atacante manipuló hábilmente para crear desequilibrios artificiales en los fondos de liquidez. Luego, estos desequilibrios se aprovecharon para extraer activos reales del sistema sin compensar adecuadamente a los proveedores de liquidez. Este tipo de vulnerabilidad es particularmente insidiosa porque no siempre se manifiesta en condiciones operativas normales; por el contrario, para activarla se requieren casos extremos específicos relacionados con valores muy elevados o secuencias de transacciones inusuales. Estos errores son notoriamente difíciles de detectar durante las auditorías y las fases de prueba estándar, lo que los convierte en los principales candidatos para que los exploten adversarios con muchos recursos. Esfuerzos de respuesta y recuperación de la Fundación Cetus y Sui (también conocida como Mysten Labs) Durante el ataque, según se informa, se congelaron alrededor de 160 millones de dólares que se devolverán a las piscinas de Cetus. Es por eso que toda la fundación Sui inició una votación para descongelar estos tokens. Tras el ataque, el equipo de Cetus emitió declaraciones públicas en las que reconocía la violación y describía los pasos a seguir para solucionarlo. Trabajaron en estrecha colaboración con empresas de análisis de cadenas de bloques como Elliptic y Chainalysis para rastrear el movimiento de los fondos robados e identificar posibles vías de recuperación. Además, surgieron debates sobre la implementación de actualizaciones de emergencia para corregir las vulnerabilidades existentes y mejorar la resiliencia futura contra ataques similares. Los miembros de la comunidad expresaron reacciones encontradas ante estos desarrollos. Si bien muchos elogiaron la transparencia demostrada por el liderazgo de Cetus tras el hackeo, otros criticaron la falta de preparación para estos escenarios y cuestionaron si se habían implementado suficientes salvaguardias antes del lanzamiento.
- Sui
- Security Protocols
1
HaGiang164
May 25, 2025
Artículo
Mi primer artículo ZKat: Autenticación que preserva la privacidad para cadenas de bloques públicas
Porque la transparencia no debería significar revelar tus secretos. En la mayoría de las cadenas de bloques públicas actuales, cada transacción e identidad de usuario es visible públicamente. Si bien la transparencia es una de las principales fortalezas de la cadena de bloques, se produce a costa de la privacidad, especialmente en lo que respecta a la autenticación. ZKat, abreviatura de autenticadores de conocimiento cero, es una primitiva criptográfica novedosa que lleva la autenticación que preserva la privacidad al mundo de la cadena de bloques. Con ZKat, los usuarios pueden demostrar que están autorizados a realizar una transacción sin revelar las reglas o políticas en las que se basa esa autorización. ##El problema de los enfoques tradicionales Los intentos anteriores de mantener la privacidad en la autenticación, como el uso defirmas umbrales, solo podían ocultar información limitada. Por ejemplo, podían ocultar qué usuarios habían firmado una transacción, pero no mucho más. También tenían problemas conpolíticas de autenticación más complejas(como combinaciones de roles, identidades o reglas). ZKat cambia el juego de la siguiente manera: Apoyando políticasarbitrariamente complejas Permitir estructuras flexibles, como lascombinaciones de firmas de múltiples esquemas Mantener lapolítica completa ocultaal público** ##Cómo funciona ZKat Para crear ZKat, los autores diseñaron uncompiladorque transforma el sistema zk-SNARKGroth16, ampliamente utilizado, en un nuevo tipo de pruebaNon-Interactive Zero-Knowledge (NIZK), que admiteclaves de verificación equívocas. ¿Qué significa eso? Significa que el verificadorno puede decirqué política se está utilizando, pero la prueba lo convence de que es válida. Se trata de una propiedad criptográfica completamente nueva que se presentó en el documento y es la base de cómo ZKat garantiza laprivacidad de las políticas. Pero los autores no se detuvieron en ZKat. Fueron un paso más allá conzKat, una versión que admiteactualizaciones ignoradas. En resumen: El emisor de una política puede actualizar la política de autenticación sin revelar nada nuevo Esto es muy poderoso en los sistemas de cadenas de bloques del mundo real, donde las políticas pueden necesitar evolucionar; por ejemplo, las DAO actualizan las reglas de votación o las instituciones rotan las teclas. También exploran el uso depruebas zk-recursivaspara hacer que zkatsea escalable y adecuado para la integración de la cadena de bloques. Los investigadores implementaron zKat en un prototipo de autenticación basada en umbrales. Su evaluación muestra: El rendimiento está a la par con el de los umbrales tradicionales ZKat admitepolíticas mucho más complejas ¡Todo eso, congastos generales mínimos
- Sui
- Architecture
1
0xduckmove308
May 19, 2025
Artículo
¿Qué es IKA? «No solo el bombo publicitario 👀»
(p/s: No es una de esas «actualizaciones de la web 3» que dan 3 líneas de tonterías y lo llaman alpha 😮‍💨) Lee el artículo completo: https://x.com/InternSui81687/status/1897309368644985108 ¿Alguna vez has movido activos entre cadenas y te has sentido como si fueras Indiana Jones esquivando trampas? ¿Sí?. Esto se debe a que la interoperabilidad en este momento = puentes riesgosos y puntos centrales de falla. Ika dice: «No, ya terminamos con eso». Están creando un sistema que ofrece un enfoque automático rápido y fiable, y que no le da las llaves a nadie. Basado en Sui, utiliza el cifrado Threshold y 2PC-MPC En el vídeo aquí, David Lash (cofundador de Ika) dice sin rodeos lo que todo el mundo piensa: la interoperabilidad es un enfoque automático roto. Y en lugar de escribir otro blog sobre «necesitamos una solución», como hacen la mayoría de los equipos, dedicaron dos años a buscar a expertos en seguridad, expertos en inteligencia artificial y académicos para crear una solución. ¿Qué se les ocurrió? Un sistema que utiliza MPC a dos jugadores y cifrado por umbral: palabras sofisticadas que básicamente significan: tus claves siguen siendo tuyas, tus activos no se vuelven a empaquetar como si fuera un regalo de Navidad de 2017 y todo va muy rápido. Por ejemplo, Ika no solo protege tus cosas. Realiza transacciones con una latencia inferior a un segundo y aún así permanece descentralizado. Mientras tanto, los puentes están aquí tardando 8 minutos y tu alma en confirmar un intercambio. Construyeron esto en Sui. Y si has dormido con Sui hasta ahora, esa siesta ha terminado. El modelo centrado en objetos de Sui, su vertiginosa finalidad y el Consenso de Mysticeti (sí, eso existe, no, no es inventado) son perfectos para lo que Ika está intentando hacer. David llegó a decir que la experiencia de Sui como desarrollador la convertía en una opción obvia, algo poco elogiado en el mundo de las criptomonedas, donde cada herramienta de desarrollo parece un pergamino antiguo. Pero lo que realmente me impresionó fue su opinión sobre la experiencia de usuario. ¿La mejor criptomoneda? Del tipo que es aburrido. No de mala manera, sino del tipo «simplemente funciona». Ika busca un futuro en el que ni siquiera sepas que estás haciendo cosas de cadenas cruzadas. Sin ventanas emergentes, sin puentes, sin fichas falsas. Solo tienes que abrir tu monedero, prestar tus BTC de forma nativa, hacer un intercambio entre cadenas y seguir adelante. Eso es lo que hemos estado pidiendo y, de alguna manera, nos olvidamos de exigirlo. Y no pienses que esto es solo para Degen Bros. Ika permite a los DAO, a los equipos independientes y a las empresas implementar sus propias soluciones de custodia (pensemos en el «paquete de inicio de Fireblocks»), pero con esteroides y de hecho accesibles. Ya no necesitas una configuración de 500 000 dólares para crear una infraestructura segura. Solo Sui, Ika y un poco de coraje. Ah, y no nos quedemos con Bitcoin. BTC ha estado al margen durante años, como ese tío que se niega a unirse al juego. Pero Ika lo está haciendo jugable. DeFi sin envoltorio ni movimiento: basta con guardarlo como garantía nativa y listo. A las instituciones les va a encantar porque les permite cumplir con las normas y ser eficientes. Sin fraude fiscal, sin trampas de custodia. Solo capital que fluye de forma limpia. Entonces, si alguien te pregunta: «¿Qué sigue para las criptomonedas?» no les envíes un hilo de tuits que diga «La interoperabilidad es el futuro»
- Sui
1
RogueRig134
May 13, 2025
Artículo
¿Qué es IKA y por qué tanta publicidad?
@ikadotxyz, la red MPC paralela ultrarrápida de la cadena de bloques Sui, está generando mucha expectación por su potencial para revolucionar la seguridad y la interoperabilidad de la Web3. Las publicaciones recientes en X destacan el sentimiento alcista: según se informa, IKA cotiza entre 4,90 y 10 dólares en plataformas previas a la comercialización, como Whales, a pesar de tener una oferta de mil millones de fichas. Esto apunta a una posible capitalización bursátil de miles de millones si se mantiene el impulso, impulsado por una inversión estratégica de 21 millones de dólares por parte de la Fundación Sui y una campaña artística sin precedentes de 1,4 millones de dólares en SUI NFT. La latencia de menos de un segundo de Ika y su capacidad para escalar cientos de nodos firmantes la convierten en un punto de inflexión para las aplicaciones DeFi, la custodia descentralizada y las aplicaciones entre cadenas. Se espera que el próximo lanzamiento del token IKA en Sui desbloquee una nueva utilidad, lo que impulsará una mayor adopción. Los usuarios de X están entusiasmados con el papel de IKA en el programa de fidelización @GiveRep, y algunos lo consideran una de las mayores oportunidades de lanzar desde el aire a Sui. Dicho esto, los precios previos a la comercialización pueden ser volátiles y especulativos, por lo que no se garantiza que el rango entre 4,90 y 10 dólares se mantenga después del lanzamiento. Investiga siempre los fundamentos del proyecto (consulta los canales oficiales de Ika para obtener información más detallada) y sopesa los riesgos antes de lanzarte. El ecosistema de Sui se está calentando, pero no hay nada seguro en el mundo de las criptomonedas
- Sui
- Architecture
1
Rogue129
May 13, 2025
Artículo
Configuración del nodo SUI: una guía detallada
Para configurar un nodo Sui, necesitarás instalar los binarios Sui, clonar el repositorio Sui y configurar el nodo. Puedes compilar desde el código fuente o usar Docker. Una vez que el nodo esté en ejecución, puedes supervisar su estado y sincronizar el progreso. Pasos detallados: Instale Sui Binaries: Siga las instrucciones de la documentación de Sui para instalar los binarios de Sui. Si utilizas Docker, sigue las instrucciones del archivo Readme de Docker del nodo completo de Sui. Si compilas desde el código fuente, tendrás que clonar el repositorio de Sui y compilarlo. Configure el nodo: Nodo completo: puedes configurar un nodo completo de Sui usando Docker o compilándolo desde el código fuente, de acuerdo con la documentación de Sui. Nodo validador: sigue las instrucciones de la configuración del nodo validador Sui para configurar un nodo validador. Esto incluye la instalación y configuración de la Sui, la administración de claves y la configuración del almacenamiento. Configuración completa del nodo: Cierre cualquier nodo completo en ejecución. Elimine la base de datos y el archivo genesis.blob. Obtenga el código fuente de la versión más reciente. Restablece tu sucursal. Descarga la última versión de Genesis Blob. Actualiza tu archivo de configuración fullnode.yaml, si es necesario. Reinicia tu nodo Sui Full. Ejecute el nodo: Inicie el nodo Sui con el comando apropiado para su método de configuración (por ejemplo, los comandos sui-node o Docker). Supervise el nodo: Supervisa el estado de tu nodo, sincroniza el progreso y los registros para asegurarte de que funciona correctamente. Usa herramientas como el registro, el seguimiento y las métricas para supervisar el nodo. El puerto de métricas predeterminado es el 9184, pero puedes cambiarlo en el archivo fullnode.yaml. Pasos adicionales: Registro del comité: si tienes un nodo validador, tendrás que registrarte en el comité. Liquid Staking: si gestionas un nodo, también puedes participar en el Liquid Staking. Sincroniza tu bifurcación: si contribuyes al proyecto Sui, tendrás que sincronizar tu bifurcación con el repositorio principal. Si sigues estos pasos, puedes configurar y ejecutar correctamente un nodo Sui.
- Sui
1
HaGiang164
May 12, 2025
Artículo
«Decodificando la trilogía Sui: pavimentando el futuro de la infraestructura Web3
Al explorar el mundo de la Web3, más allá de la búsqueda habitual de velocidades de transacción más rápidas y comisiones más bajas, surgen cada vez más desafíos estructurales más profundos. ¿Cómo se pueden almacenar cantidades masivas de datos de forma económica? ¿Cómo se puede proteger de forma segura la información confidencial en un entorno descentralizado? ¿Se pueden ejecutar de manera eficiente los cálculos complejos fuera de la cadena y, al mismo tiempo, tener sus resultados verificados y confiables dentro de la cadena? Muchos proyectos intentan abordar estos problemas mediante la combinación de varios servicios de terceros. Sin embargo, este camino suele conllevar una complejidad de integración, posibles problemas de confianza y una experiencia de usuario fragmentada. Ante estos desafíos a nivel de infraestructura, la cadena de bloques Sui y su equipo principal de desarrollo, Mysten Labs, han propuesto una solución más integrada. En lugar de basarse en un mosaico de herramientas externas, han diseñado una cadena de bloques con una arquitectura única, que incluye su modelo centrado en objetos y el lenguaje de programación Move, al tiempo que crean tres componentes de infraestructura nativa estrechamente conectados: Walrus, Seal y Nautilus. El objetivo de este artículo es analizar los conceptos de diseño en los que se basan estos tres componentes, explorar cómo funcionan, cómo se relacionan entre sí y qué cambios reales podrían aportar a las aplicaciones Web3. La arquitectura única de Sui Para entender cómo funcionan estas tres herramientas en Sui, primero debemos analizar algunas características clave de la propia plataforma Sui. Una de las principales innovaciones de Sui es su modelo orientado a objetos, un cambio fundamental con respecto a la arquitectura tradicional basada en cuentas. Sui trata los tokens, las NFT e incluso las estructuras de datos complejas como «objetos» independientes. Imagine administrar cada activo como una caja separada en lugar de registrar todo en un solo registro. Este diseño permite procesar en paralelo acciones no relacionadas (como la gestión de dos NFT no relacionadas), lo que mejora el rendimiento. Esta granularidad de los objetos crea una sinergia natural con Walrus y Seal: Walrus trata los datos almacenados como objetos, mientras que Seal puede adjuntar reglas de permisos directamente a objetos individuales. Además, Sui usa el lenguaje de programación Move, diseñado específicamente para administrar activos digitales. Move hace hincapié en la seguridad y tiene como objetivo reducir muchas vulnerabilidades comunes de los contratos inteligentes a nivel lingüístico. Esta sólida base hace que sea ideal para crear componentes de infraestructura sólidos. Al alinear el diseño de la cadena y el desarrollo de la infraestructura bajo un mismo techo (Mysten Labs), Sui tiene como objetivo ofrecer una experiencia de desarrollador más fluida y sinérgica. Walrus: almacenamiento descentralizado programable y económico Almacenar archivos grandes (imágenes, vídeos, modelos de IA, denominados colectivamente blobs) directamente en cadena es notoriamente caro. Cada una de las soluciones de almacenamiento descentralizado existentes tiene sus ventajas y desventajas, pero Walrus busca un nuevo equilibrio entre la rentabilidad y la interactividad de los contratos inteligentes, abordando directamente las barreras de costos que representan los datos en cadena a gran escala. La base de Walrus es la codificación de borrado, una ingeniosa técnica que «fragmenta» un archivo y añade «pistas de recuperación» para que el archivo pueda reconstruirse incluso si se pierden partes. Walrus llama a estos fragmentos adicionales «Red Stuff». Piénsalo de esta manera: si tienes dos números, digamos 3 y 5, y guardas ambos junto con su suma (8), perder el 3 no es catastrófico; puedes recuperarlo usando 8 - 5 = 3. Los fragmentos de recuperación adicionales desempeñan una función similar, ya que están matemáticamente relacionados con los originales. Tras fragmentarlos y codificarlos, Walrus distribuye estos fragmentos en muchos nodos. Incluso si faltan algunos fragmentos, el sistema puede reconstruir el archivo original siempre que se recupere un número límite de fragmentos, lo que ahorra mucho espacio en comparación con la replicación completa del archivo. Este enfoque reduce drásticamente los costos de almacenamiento y podría acercar los precios del almacenamiento descentralizado a los de los proveedores de nube centralizados. Aún más interesante, Walrus aprovecha el modelo de objetos de Sui: cada archivo almacenado se convierte en un objeto programable en cadena. Los desarrolladores pueden usar Move para redactar contratos inteligentes que administren estos objetos de almacenamiento: establecer reglas de acceso, actualizar automáticamente los metadatos, etc. El almacenamiento ya no es solo pasivo, sino que se convierte en un recurso programable de forma nativa. También hay una capa de utilidad basada en los tokens: para interactuar con los datos de Walrus en Sui, se necesitan tokens de SUI para registrar los metadatos (como los nombres de los archivos, los tamaños y las ubicaciones de almacenamiento) y, potencialmente, bloquear los tokens para pagar las tarifas de almacenamiento. Si la adopción de Walrus aumenta, la demanda de esta tecnología podría aumentar, lo que reduciría la oferta. Seal: La bóveda descentralizada y el guardián de acceso Muchas aplicaciones Web3 manejan datos confidenciales: identificaciones de usuario, detalles financieros, contenido de pago. En un contexto descentralizado, ¿cómo se almacenan los secretos de forma segura y se controla el acceso a ellos? Seal es una solución descentralizada de gestión de secretos (DSM) diseñada para responder a esa pregunta. Una de sus tecnologías principales es Threshold Encryption. Imagine una bóveda que requiere dos llaves para abrirse, cada una de las cuales está en manos de una persona diferente. Del mismo modo, el cifrado de umbral divide las claves de descifrado en varias partes y las distribuye a servidores de claves independientes. Solo cuando un número predefinido de ellas colaboran (el umbral) se pueden descifrar los datos; ningún servidor puede hacerlo por sí solo, lo que genera confianza y aumenta la tolerancia a errores. La otra característica inteligente de Seal es que la lógica de control de acceso está escrita como Move smart contracts on-chain. Los desarrolladores pueden definir reglas claras: por ejemplo, solo los usuarios que posean un determinado NFT o que hayan pagado una tarifa pueden acceder a ciertos datos. Esta transparencia y verificabilidad distinguen a Seal de los sistemas de acceso centralizado tradicionales. Cuando un usuario o una aplicación desean descifrar un secreto, envían una solicitud a los servidores clave. Estos servidores comprueban las reglas de la cadena. Solo si se cumplen las condiciones, publican sus fragmentos clave. El descifrado propiamente dicho se produce en el dispositivo cliente, por lo que los servidores de claves nunca tocan los datos originales. Seal puede proteger los datos almacenados en cualquier lugar: en Walrus, otras redes descentralizadas o incluso en nubes centralizadas. Esto lo hace ideal para la mensajería segura, los datos privados de los usuarios, la protección de contenido de pago, la votación confidencial y mucho más. Nautilus: Hacer que la computación fuera de cadena sea verificable en cadena Las cadenas de bloques no son excelentes para tareas complejas o que requieren muchos recursos. Hacerlas en cadena es lento, caro y compromete la privacidad. Las soluciones como Layer 2 o Oracles ayudan, pero Nautilus explora un camino diferente: posibilitar una computación fiable fuera de la cadena. Nautilus utiliza una solución basada en hardware denominada Trusted Execution Environments (TEEs). Piense en un TEE como una zona segura y aislada dentro de una CPU. El código y los datos de esta zona están protegidos del resto del sistema, incluido el propio sistema operativo. El flujo de trabajo básico es el siguiente: Un desarrollador implementa una tarea computacional (por ejemplo, modelos financieros, inferencia de IA, lógica de juego) en un TEE que controla. Cuando finaliza la tarea, el TEE produce una certificación criptográfica, una especie de «recibo» a prueba de manipulaciones que demuestra: la tarea se ejecutó en un TEE el código no fue alterado el proceso se completó correctamente. Esta certificación y el resultado se someten a un contrato inteligente de Move en Sui. El contrato verifica la certificación (por ejemplo, la validez de la firma y el hash del código). Solo si se aprueba la verificación, el contrato acepta el resultado y continúa con las acciones en cadena. Nautilus une la computación de alto rendimiento fuera de la cadena con la verificabilidad y la confianza dentro de la cadena, sin exponer detalles confidenciales. Nautilus en acción: el caso de Bluefin Un ejemplo concreto es Bluefin, una plataforma descentralizada de comercio de perpetuos. La mayoría de las plataformas de negociación de alto rendimiento se enfrentan a un dilema: mantener las carteras de pedidos totalmente integradas en la cadena ofrece transparencia, pero es lento y caro; moverlas fuera de la cadena mejora la velocidad, pero introduce problemas de confianza. Bluefin usa Nautilus para cerrar esta brecha: • La comparación de pedidos se realiza dentro de un TEE, lo que garantiza un procesamiento seguro y aislado. • Nautilus proporciona una prueba criptográfica de que la lógica coincidente se ejecutó correctamente. • Las pruebas y los resultados se envían en cadena, donde los contratos inteligentes los verifican antes de ejecutar la liquidación. Este enfoque permite a Bluefin ofrecer una combinación rápida fuera de la cadena con garantías de confianza dentro de la cadena, lo que lo hace viable para las operaciones con derivados de DeFi, que requieren un alto rendimiento, como las de DeFi. Por supuesto, esto hace que parte de la confianza pase del consenso puro sobre la cadena de bloques a centrarse en el hardware y la implementación de TEE.
- Sui
- Architecture
1