51 publicaciones etiquetados con "Blockchain"

¡Nos complace anunciar el lanzamiento del staking de token SUI en BlockEden.xyz! A partir de hoy, puedes hacer staking de tus tokens SUI directamente a través de nuestra plataforma y ganar un 2.08% APY mientras apoyas la seguridad y descentralización de la red SUI.

Novedades: Una Experiencia de Staking SUI sin Fricciones​

Nuestra nueva función de staking lleva staking de nivel institucional a todos, con una interfaz simple e intuitiva que hace que ganar recompensas sea sin esfuerzo.

Características Clave​

Staking con Un Clic
El staking de SUI nunca ha sido tan fácil. Simplemente conecta tu billetera Suisplash, ingresa la cantidad de SUI que deseas stakear y aprueba la transacción. Comenzarás a ganar recompensas casi de inmediato sin procedimientos complejos.

Recompensas Competitivas
Gana un 2.08% APY competitivo sobre tu SUI stakeado. Nuestra comisión del 8% es transparente, asegurando que sepas exactamente qué esperar. Las recompensas se distribuyen diariamente al completarse cada epoch.

Validador de Confianza
Únete a una comunidad en crecimiento que ya ha stakeado más de 22 millones de SUI con el validador de BlockEden.xyz. Tenemos un historial probado de servicios de validación fiables, respaldados por infraestructura de nivel empresarial que garantiza un tiempo de actividad del 99.9%.

Gestión Flexible
Tus activos siguen siendo flexibles. El staking es instantáneo, lo que significa que tus recompensas comienzan a acumularse de inmediato. Si necesitas acceder a tus fondos, puedes iniciar el proceso de unstaking en cualquier momento. Tu SUI estará disponible después del período estándar de desbloqueo de la red SUI de 24-48 horas. Puedes rastrear tus stakes y recompensas en tiempo real a través de nuestro panel.

¿Por Qué Hacer Staking de SUI con BlockEden.xyz?​

Confiabilidad en la que Puedes Confiar​

BlockEden.xyz ha sido una piedra angular de la infraestructura blockchain desde nuestros inicios. Nuestra infraestructura de validadores impulsa aplicaciones empresariales y ha mantenido un tiempo de actividad excepcional en múltiples redes, garantizando una generación constante de recompensas.

Transparente y Justo​

Creemos en la total transparencia. No hay tarifas ocultas, solo una comisión del 8% clara sobre las recompensas que ganas. Puedes monitorear tu desempeño de staking con reportes en tiempo real y verificar la actividad de nuestro validador en cadena.

• Open Address: 0x0000000000000000000000000000000000000000

Integración Sin Fricciones​

Nuestra plataforma está diseñada para la simplicidad. No es necesario crear una cuenta; puedes hacer staking directamente desde tu billetera. La experiencia está optimizada para la billetera Suisplash, y nuestra interfaz limpia e intuitiva está construida tanto para principiantes como para expertos.

Cómo Empezar​

Paso 1: Visita la Página de Staking​

Visita blockeden.xyz/dash/stake. Puedes iniciar el proceso de inmediato sin necesidad de registrar una cuenta.

Paso 2: Conecta tu Billetera​

Si aún no la tienes, instala la billetera Suisplash. Haz clic en el botón "Conectar Billetera" en nuestra página de staking y aprueba la conexión en la extensión de la billetera. Tu saldo de SUI se mostrará automáticamente.

Paso 3: Elige la Cantidad a Stakear​

Ingresa la cantidad de SUI que deseas stakear (mínimo 1 SUI). Puedes usar el botón "MAX" para stakear convenientemente todo tu saldo disponible, dejando una pequeña cantidad para tarifas de gas. Un resumen mostrará tu cantidad stakeada y las recompensas anuales estimadas.

Paso 4: Confirma y Comienza a Ganar​

Haz clic en "Stake SUI" y aprueba la transacción final en tu billetera. Tu nuevo stake aparecerá en el panel en tiempo real, y comenzarás a acumular recompensas de inmediato.

Economía del Staking: Lo Que Necesitas Saber​

Estructura de Recompensas​

• APY Base: 2.08% anual
• Frecuencia de Recompensas: Distribuida cada epoch (aproximadamente cada 24 horas)
• Comisión: 8% de las recompensas ganadas
• Capitalización: Las recompensas se añaden a tu billetera y pueden ser re‑stakeadas para lograr crecimiento compuesto.

Ejemplo de Ganancias​

Nota: Estas son estimaciones. Las recompensas reales pueden variar según las condiciones de la red.

Consideraciones de Riesgo​

• Período de Desbloqueo: Cuando haces unstake, tu SUI está sujeto a un período de desbloqueo de 24-48 horas en el que no es accesible y no genera recompensas.
• Riesgo del Validador: Aunque mantenemos altos estándares, cualquier validador conlleva riesgos operativos. Elegir un validador reputado como BlockEden.xyz es importante.
• Riesgo de Red: El staking es una forma de participación en la red y está sujeto a los riesgos inherentes al protocolo blockchain subyacente.
• Riesgo de Mercado: El valor de mercado del token SUI puede fluctuar, lo que afectará el valor total de tus activos stakeados.

Excelencia Técnica​

Infraestructura Empresarial​

Nuestros nodos validadores están construidos sobre una base de excelencia técnica. Utilizamos sistemas redundantes distribuidos en múltiples regiones geográficas para garantizar alta disponibilidad. Nuestra infraestructura está bajo monitoreo 24/7 con capacidades de conmutación automática, y un equipo profesional de operaciones gestiona el sistema las 24 horas. También realizamos auditorías de seguridad y verificaciones de cumplimiento de forma regular.

Código Abierto y Transparencia​

Estamos comprometidos con los principios de código abierto. Nuestra integración de staking está construida para ser transparente, permitiendo a los usuarios inspeccionar los procesos subyacentes. Métricas en tiempo real están disponibles públicamente en los exploradores de la red SUI, y nuestra estructura de tarifas es completamente abierta sin costos ocultos. También participamos activamente en la gobernanza comunitaria para apoyar el ecosistema SUI.

Apoyando el Ecosistema SUI​

• Seguridad de la Red: Tu stake se suma al total que asegura la red SUI, haciéndola más robusta contra posibles ataques.
• Descentralización: Apoyar validadores independientes como BlockEden.xyz mejora la resiliencia de la red y previene la centralización.
• Crecimiento del Ecosistema: Las comisiones que ganamos se reinvierten en mantener y desarrollar infraestructura crítica.
• Innovación: Los ingresos respaldan nuestra investigación y desarrollo de nuevas herramientas y servicios para la comunidad blockchain.

Seguridad y Mejores Prácticas​

Seguridad de la Billetera​

• Nunca compartas tus claves privadas o frase semilla con nadie.
• Utiliza una billetera hardware para almacenar y stakear grandes cantidades.
• Siempre verifica los detalles de la transacción en tu billetera antes de firmar.
• Mantén tu software de billetera actualizado a la última versión.

Seguridad del Staking​

• Si eres nuevo en el staking, comienza con una pequeña cantidad para familiarizarte con el proceso.
• Considera diversificar tu stake entre varios validadores reputados para reducir el riesgo.
• Monitorea regularmente tus activos stakeados y recompensas.
• Asegúrate de comprender el período de desbloqueo antes de comprometer tus fondos.

Únete al Futuro del Staking SUI​

El lanzamiento del staking SUI en BlockEden.xyz es más que una nueva función; es una puerta de entrada a la participación activa en la economía descentralizada. Ya seas un usuario experimentado de DeFi o estés comenzando tu camino, nuestra plataforma ofrece una forma simple y segura de ganar recompensas mientras contribuyes al futuro de la red SUI.

¿Listo para comenzar a ganar?
Visita blockeden.xyz/dash/stake y stakea tus primeros tokens SUI hoy!

Acerca de BlockEden.xyz​

BlockEden.xyz es un proveedor líder de infraestructura blockchain que ofrece servicios fiables, escalables y seguros a desarrolladores, empresas y a la comunidad Web3 en general. Desde servicios API hasta operaciones de validadores, estamos comprometidos a construir la base para un futuro descentralizado.

• Fundado: 2021
• Redes Soportadas: más de 15 redes blockchain
• Clientes Empresariales: más de 500 empresas en todo el mundo
• Valor Total Asegurado: más de $100M en todas las redes

Síguenos en Twitter, únete a nuestro Discord y explora nuestra suite completa de servicios en BlockEden.xyz.

Aviso: Esta publicación del blog es solo con fines informativos y no constituye asesoramiento financiero. El staking de criptomonedas implica riesgos, incluida la posible pérdida del capital. Por favor, realiza tu propia investigación y considera tu tolerancia al riesgo antes de hacer staking.

Introducción​

Los mercados descentralizados de inferencia/entrenamiento de IA buscan aprovechar los recursos de cómputo globales y los modelos comunitarios de una manera sin confianza (trustless). Proyectos como Bittensor, Gensyn y Cuckoo Network (Cuckoo AI) ilustran cómo la tecnología blockchain puede potenciar mercados abiertos de IA. Cada plataforma tokeniza activos clave de IA —poder de cómputo, modelos de aprendizaje automático y, a veces, datos— en unidades económicas en la cadena. A continuación, profundizamos en las arquitecturas técnicas que sustentan estas redes, cómo tokenizan los recursos, sus estructuras de gobernanza e incentivos, los métodos para rastrear la propiedad de los modelos, los mecanismos de reparto de ingresos y las superficies de ataque (por ejemplo, ataques Sybil, colusión, parasitismo, envenenamiento) que surgen. Una tabla comparativa al final resume todas las dimensiones clave entre Bittensor, Gensyn y Cuckoo AI.

Arquitecturas Técnicas​

Bittensor: “Internet Neuronal” Descentralizado en Subredes​

Bittensor está construido sobre una blockchain de Capa 1 personalizada (la cadena Subtensor, basada en Substrate) que coordina una red de nodos de modelos de IA a través de muchas subredes especializadas. Cada subred es una minirred independiente que se enfoca en una tarea de IA particular (por ejemplo, una subred para la generación de lenguaje, otra para la generación de imágenes, etc.). Los participantes en Bittensor asumen roles distintos:

• Mineros – ejecutan modelos de aprendizaje automático en su hardware y proporcionan respuestas de inferencia (o incluso realizan entrenamiento) para la tarea de la subred. En esencia, un minero es un nodo que aloja un modelo de IA que responderá a las consultas.
• Validadores – consultan los modelos de los mineros con prompts y evalúan la calidad de las respuestas, formando una opinión sobre qué mineros están contribuyendo con resultados valiosos. Los validadores califican efectivamente el rendimiento de los mineros.
• Propietarios de Subred – crean y definen subredes, estableciendo las reglas sobre qué tareas se realizan y cómo se lleva a cabo la validación en esa subred. Un propietario de subred podría, por ejemplo, especificar que una subred es para un cierto conjunto de datos o modalidad y definir el procedimiento de validación.
• Delegadores – los poseedores de tokens que no ejecutan nodos pueden delegar (hacer stake) sus tokens de Bittensor (TAO) a mineros o validadores para respaldar a los de mejor rendimiento y ganar una parte de las recompensas (similar al staking en redes de prueba de participación).

El mecanismo de consenso de Bittensor es novedoso: en lugar de la validación de bloques tradicional, Bittensor utiliza el consenso Yuma, que es una forma de "prueba de inteligencia". En el consenso Yuma, las evaluaciones de los validadores sobre los mineros se agregan en la cadena para determinar la distribución de recompensas. Cada bloque de 12 segundos, la red acuña nuevos tokens TAO y los distribuye según el consenso de los validadores sobre qué mineros proporcionaron trabajo útil. Las puntuaciones de los validadores se combinan en un esquema de mediana ponderada por participación (stake): las opiniones atípicas se recortan y prevalece la opinión de la mayoría honesta. Esto significa que si la mayoría de los validadores están de acuerdo en que un minero fue de alta calidad, ese minero obtendrá una fuerte recompensa; si un validador se desvía mucho de los demás (posiblemente debido a colusión o error), ese validador es penalizado ganando menos. De esta manera, la blockchain de Bittensor coordina un bucle de retroalimentación minero-validador: los mineros compiten para producir los mejores resultados de IA, y los validadores curan y clasifican esos resultados, ganando ambas partes tokens proporcionales al valor que agregan. Esta arquitectura a menudo se describe como una "red neuronal descentralizada" o "cerebro global", donde los modelos aprenden de las señales de los demás y evolucionan colectivamente. Notablemente, Bittensor actualizó recientemente su cadena para admitir la compatibilidad con EVM (para contratos inteligentes) e introdujo dTAO, un sistema de tokens y staking específicos de subred (explicado más adelante) para descentralizar aún más el control de la asignación de recursos.

Gensyn: Protocolo de Cómputo Distribuido sin Confianza (Trustless)​

Gensyn aborda la IA descentralizada desde el ángulo de un protocolo de computación distribuida para el aprendizaje automático. Su arquitectura conecta a desarrolladores (solicitantes) que tienen tareas de IA (como entrenar un modelo o ejecutar un trabajo de inferencia) con proveedores de cómputo (resolutores) de todo el mundo que tienen recursos de GPU/TPU de sobra. Originalmente, Gensyn planeaba una cadena L1 en Substrate, pero giró hacia la construcción en Ethereum como un rollup para una mayor seguridad y liquidez. La red Gensyn es, por lo tanto, una Capa 2 de Ethereum (un rollup de Ethereum) que coordina la publicación de trabajos y los pagos, mientras que la computación ocurre fuera de la cadena en el hardware de los proveedores.

Una innovación central del diseño de Gensyn es su sistema de verificación para el trabajo fuera de la cadena. Gensyn utiliza una combinación de verificación optimista (pruebas de fraude) y técnicas criptográficas para garantizar que cuando un resolutor afirma haber ejecutado una tarea de entrenamiento/inferencia, el resultado sea correcto. En la práctica, el protocolo involucra múltiples roles de participantes:

• Solicitante – la parte que solicita un trabajo (por ejemplo, alguien que necesita entrenar un modelo). Pagan la tarifa de la red y proporcionan el modelo/datos o la especificación de la tarea.
• Resolutor – un nodo que puja y ejecuta la tarea de ML en su hardware. Entrenarán el modelo o ejecutarán la inferencia según lo solicitado, luego enviarán los resultados y una prueba de computación.
• Verificador/Desafiador – nodos que pueden auditar o verificar aleatoriamente el trabajo del resolutor. Gensyn implementa un esquema al estilo de Truebit donde, por defecto, el resultado de un resolutor se acepta, pero un verificador puede desafiarlo dentro de una ventana si sospecha una computación incorrecta. En un desafío, se utiliza una "búsqueda binaria" interactiva a través de los pasos de la computación (un protocolo de prueba de fraude) para señalar cualquier discrepancia. Esto permite que la cadena resuelva disputas realizando solo una parte crítica mínima de la computación en la cadena, en lugar de rehacer toda la costosa tarea.

Crucialmente, Gensyn está diseñado para evitar la redundancia masiva de los enfoques ingenuos. En lugar de tener muchos nodos repitiendo el mismo trabajo de ML (lo que destruiría los ahorros de costos), el enfoque de "prueba de aprendizaje" de Gensyn utiliza metadatos de entrenamiento para verificar que se ha progresado en el aprendizaje. Por ejemplo, un resolutor podría proporcionar hashes criptográficos o puntos de control de los pesos intermedios del modelo y una prueba sucinta de que estos progresaron de acuerdo con las actualizaciones de entrenamiento. Esta prueba probabilística de aprendizaje se puede verificar de manera mucho más económica que volver a ejecutar todo el entrenamiento, lo que permite una verificación sin confianza sin replicación completa. Solo si un verificador detecta una anomalía se activaría una computación más pesada en la cadena como último recurso. Este enfoque reduce drásticamente la sobrecarga en comparación con la verificación por fuerza bruta, haciendo que el entrenamiento de ML descentralizado sea más factible. La arquitectura de Gensyn, por lo tanto, enfatiza fuertemente el diseño de juegos criptoeconómicos: los resolutores depositan una participación o fianza, y si hacen trampa (enviando resultados incorrectos), pierden esa participación a favor de los verificadores honestos que los atrapan. Al combinar la coordinación de la blockchain (para pagos y resolución de disputas) con el cómputo fuera de la cadena y una verificación inteligente, Gensyn crea un mercado para el cómputo de ML que puede aprovechar las GPU inactivas en cualquier lugar mientras mantiene la falta de confianza. El resultado es un "protocolo de cómputo" a hiperescala donde cualquier desarrollador puede acceder a un poder de entrenamiento asequible y distribuido globalmente bajo demanda.

Cuckoo AI: Plataforma de Servicios de IA Descentralizada Full-Stack​

Cuckoo Network (o Cuckoo AI) adopta un enfoque más integrado verticalmente, con el objetivo de proporcionar servicios de IA descentralizados de extremo a extremo en lugar de solo cómputo en bruto. Cuckoo construyó su propia blockchain (inicialmente una Capa 1 llamada Cuckoo Chain en Arbitrum Orbit, un marco de rollup compatible con Ethereum) para orquestar todo: no solo empareja trabajos con GPU, sino que también aloja aplicaciones de IA y maneja pagos en un solo sistema. El diseño es full-stack: combina una blockchain para transacciones y gobernanza, una capa de recursos de GPU/CPU descentralizada y aplicaciones y API de IA orientadas al usuario en la parte superior. En otras palabras, Cuckoo integra las tres capas —blockchain, cómputo y aplicación de IA— dentro de una única plataforma.

Los participantes en Cuckoo se dividen en cuatro grupos:

• Constructores de Aplicaciones de IA (Coordinadores) – son desarrolladores que despliegan modelos o servicios de IA en Cuckoo. Por ejemplo, un desarrollador podría alojar un generador de imágenes Stable Diffusion o un chatbot LLM como servicio. Ejecutan Nodos Coordinadores, que son responsables de gestionar su servicio: aceptar solicitudes de usuarios, dividirlas en tareas y asignar esas tareas a los mineros. Los coordinadores hacen stake del token nativo ($CAI) para unirse a la red y obtener el derecho a utilizar mineros. Esencialmente, actúan como orquestadores de capa 2 que interactúan entre los usuarios y los proveedores de GPU.
• Mineros de GPU/CPU (Nodos de Tarea) – son los proveedores de recursos. Los mineros ejecutan el cliente de tareas de Cuckoo y contribuyen con su hardware para realizar tareas de inferencia para las aplicaciones de IA. Por ejemplo, a un minero se le podría asignar una solicitud de generación de imágenes (con un modelo y prompt dados) por parte de un coordinador y usar su GPU para calcular el resultado. Los mineros también deben hacer stake de $CAI para garantizar el compromiso y el buen comportamiento. Ganan recompensas en tokens por cada tarea que completan correctamente.
• Usuarios Finales – los consumidores de las aplicaciones de IA. Interactúan a través del portal web o las API de Cuckoo (por ejemplo, generando arte a través de CooVerse o chateando con personalidades de IA). Los usuarios pueden pagar con criptomonedas por cada uso o posiblemente contribuir con su propio cómputo (o stake) para compensar los costos de uso. Un aspecto importante es la resistencia a la censura: si un coordinador (proveedor de servicios) es bloqueado o se cae, los usuarios pueden cambiar a otro que sirva la misma aplicación, ya que múltiples coordinadores podrían alojar modelos similares en la red descentralizada.
• Stakers (Delegadores) – los miembros de la comunidad que no ejecutan servicios de IA o hardware de minería aún pueden participar haciendo stake de $CAI en aquellos que sí lo hacen. Al votar con su stake en coordinadores o mineros de confianza, ayudan a señalar la reputación y, a cambio, ganan una parte de las recompensas de la red. Este diseño construye una capa de reputación Web3: los buenos actores atraen más stake (y por lo tanto, confianza y recompensas), mientras que los malos actores pierden stake y reputación. Incluso los usuarios finales pueden hacer stake en algunos casos, alineándolos con el éxito de la red.

La cadena Cuckoo (ahora en proceso de transición de una cadena independiente a un rollup de seguridad compartida) rastrea todas estas interacciones. Cuando un usuario invoca un servicio de IA, el nodo coordinador crea asignaciones de tareas en la cadena para los mineros. Los mineros ejecutan las tareas fuera de la cadena y devuelven los resultados al coordinador, que los valida (por ejemplo, verificando que la imagen o el texto de salida no sean galimatías) y entrega el resultado final al usuario. La blockchain se encarga de la liquidación de pagos: por cada tarea, el contrato inteligente del coordinador paga al minero en $CAI (a menudo agregando micropagos en pagos diarios). Cuckoo enfatiza la falta de confianza y la transparencia – todos los participantes hacen stake de tokens y todas las asignaciones y finalizaciones de tareas se registran, por lo que se desalienta el engaño por la amenaza de perder el stake y por la visibilidad pública del rendimiento. El diseño modular de la red significa que se pueden agregar fácilmente nuevos modelos de IA o casos de uso: aunque comenzó con la generación de texto a imagen como prueba de concepto, su arquitectura es lo suficientemente general como para admitir otras cargas de trabajo de IA (por ejemplo, inferencia de modelos de lenguaje, transcripción de audio, etc.).

Un aspecto notable de la arquitectura de Cuckoo es que inicialmente lanzó su propia blockchain de Capa 1 para maximizar el rendimiento de las transacciones de IA (alcanzando un pico de 300k transacciones diarias durante las pruebas). Esto permitió optimizaciones personalizadas para la programación de tareas de IA. Sin embargo, el equipo encontró que mantener una L1 independiente era costoso y complejo, y a mediados de 2025 decidieron descontinuar la cadena personalizada y migrar a un modelo de rollup/AVS (Servicio Validado Activo) en Ethereum. Esto significa que Cuckoo heredará la seguridad de Ethereum o de una L2 como Arbitrum, en lugar de ejecutar su propio consenso, pero continuará operando su mercado de IA descentralizado en esa capa de seguridad compartida. El cambio tiene como objetivo mejorar la seguridad económica (aprovechando la robustez de Ethereum) y permitir que el equipo de Cuckoo se concentre en el producto en lugar del mantenimiento de la cadena de bajo nivel. En resumen, la arquitectura de Cuckoo crea una plataforma de servicio de IA descentralizada donde cualquiera puede conectar hardware o desplegar un servicio de modelo de IA, y los usuarios de todo el mundo pueden acceder a aplicaciones de IA con un costo menor y menos dependencia de la infraestructura de las grandes tecnológicas.

Mecanismos de Tokenización de Activos​

Un tema común en estas redes es la conversión de cómputo, modelos y datos en activos en la cadena o unidades económicas que pueden ser comercializadas o monetizadas. Sin embargo, cada proyecto se enfoca en tokenizar estos recursos de diferentes maneras:

• Poder de Cómputo: Las tres plataformas convierten el trabajo de cómputo en tokens de recompensa. En Bittensor, la computación útil (inferencia o entrenamiento realizado por un minero) se cuantifica a través de las puntuaciones de los validadores y se recompensa con tokens TAO en cada bloque. Esencialmente, Bittensor "mide" la inteligencia aportada y acuña TAO como una mercancía que representa esa contribución. Gensyn trata explícitamente el cómputo como una mercancía – su protocolo crea un mercado donde el tiempo de GPU es el producto, y el precio se establece por la oferta y la demanda en términos de tokens. Los desarrolladores compran cómputo usando el token, y los proveedores ganan tokens vendiendo los ciclos de su hardware. El equipo de Gensyn señala que cualquier recurso digital (cómputo, datos, algoritmos) puede ser representado y comercializado en un mercado sin confianza similar. Cuckoo tokeniza el cómputo a través de un token ERC-20 $CAI emitido como pago por tareas completadas. Los proveedores de GPU esencialmente "minan" CAI al realizar trabajos de inferencia de IA. El sistema de Cuckoo crea registros en la cadena de las tareas, por lo que se puede pensar en cada tarea de GPU completada como una unidad atómica de trabajo que se paga en tokens. La premisa en los tres es que el poder de cómputo, que de otro modo estaría inactivo o inaccesible, se convierte en un activo tokenizado y líquido, ya sea a través de emisiones de tokens a nivel de protocolo (como en Bittensor y el Cuckoo inicial) o a través de un mercado abierto de órdenes de compra/venta para trabajos de cómputo (como en Gensyn).

• Modelos de IA: Representar los modelos de IA como activos en la cadena (por ejemplo, NFT o tokens) todavía es incipiente. Bittensor no tokeniza los modelos en sí mismos; los modelos permanecen fuera de la cadena bajo la propiedad de los mineros. En cambio, Bittensor valora indirectamente los modelos al recompensar a los que tienen un buen rendimiento. En efecto, la "inteligencia" de un modelo se convierte en ganancias de TAO, pero no hay un NFT que represente los pesos del modelo o permita a otros usarlo. El enfoque de Gensyn está en las transacciones de cómputo, no explícitamente en la creación de tokens para modelos. Un modelo en Gensyn es típicamente proporcionado por un desarrollador fuera de la cadena (quizás de código abierto o propietario), entrenado por resolutores y devuelto; no hay un mecanismo incorporado para crear un token que posea el modelo o su propiedad intelectual. (Dicho esto, el mercado de Gensyn podría facilitar potencialmente el comercio de artefactos o puntos de control de modelos si las partes lo eligen, pero el protocolo en sí ve los modelos como el contenido de la computación en lugar de un activo tokenizado). Cuckoo se encuentra en un punto intermedio: habla de "agentes de IA" y modelos integrados en la red, pero actualmente no hay un token no fungible que represente cada modelo. En cambio, un modelo es desplegado por un constructor de aplicaciones y luego servido a través de la red. Los derechos de uso de ese modelo se tokenizan implícitamente en el sentido de que el modelo puede ganar $CAI cuando se utiliza (a través del coordinador que lo despliega). Las tres plataformas reconocen el concepto de tokenización de modelos —por ejemplo, dar a las comunidades la propiedad de los modelos a través de tokens— pero las implementaciones prácticas son limitadas. Como industria, la tokenización de modelos de IA (por ejemplo, como NFT con derechos de propiedad y participación en los beneficios) todavía se está explorando. El enfoque de Bittensor de que los modelos intercambien valor entre sí es una forma de "mercado de modelos" sin un token explícito por modelo. El equipo de Cuckoo señala que la propiedad descentralizada de modelos es prometedora para reducir las barreras frente a la IA centralizada, pero requiere métodos efectivos para verificar los resultados y el uso de los modelos en la cadena. En resumen, el poder de cómputo se tokeniza inmediatamente (es sencillo pagar tokens por el trabajo realizado), mientras que los modelos se tokenizan indirecta o aspiracionalmente (recompensados por sus resultados, posiblemente representados por stake o reputación, pero aún no tratados como NFT transferibles en estas plataformas).

• Datos: La tokenización de datos sigue siendo lo más difícil. Ninguno de los proyectos, Bittensor, Gensyn o Cuckoo, tiene mercados de datos en la cadena completamente generalizados e integrados (donde los conjuntos de datos se comercializan con derechos de uso exigibles). Los nodos de Bittensor pueden entrenar con varios conjuntos de datos, pero esos conjuntos de datos no forman parte del sistema en la cadena. Gensyn podría permitir que un desarrollador proporcione un conjunto de datos para el entrenamiento, pero el protocolo no tokeniza esos datos; simplemente se proporcionan fuera de la cadena para que el resolutor los use. Cuckoo tampoco tokeniza los datos del usuario; maneja principalmente los datos (como los prompts o resultados del usuario) de manera transitoria para las tareas de inferencia. El blog de Cuckoo declara explícitamente que "los datos descentralizados siguen siendo difíciles de tokenizar" a pesar de ser un recurso crítico. Los datos son sensibles (problemas de privacidad y propiedad) y difíciles de manejar con la tecnología blockchain actual. Por lo tanto, mientras que el cómputo se está mercantilizando y los modelos comienzan a serlo, los datos permanecen en gran medida fuera de la cadena, excepto en casos especiales (algunos proyectos fuera de estos tres están experimentando con uniones de datos y recompensas en tokens por contribuciones de datos, pero eso está fuera de nuestro alcance actual). En resumen, el poder de cómputo es ahora una mercancía en la cadena en estas redes, los modelos se valoran a través de tokens pero aún no se tokenizan individualmente como activos, y la tokenización de datos sigue siendo un problema abierto (más allá de reconocer su importancia).

Gobernanza e Incentivos​

Un diseño robusto de gobernanza e incentivos es crucial para que estas redes de IA descentralizadas funcionen de manera autónoma y justa. Aquí examinamos cómo cada plataforma se gobierna a sí misma (quién toma las decisiones, cómo ocurren las actualizaciones o los cambios de parámetros) y cómo alinean los incentivos de los participantes a través de la economía de tokens.

• Gobernanza de Bittensor: En sus primeras etapas, el desarrollo y los parámetros de las subredes de Bittensor estaban en gran medida controlados por el equipo central y un conjunto de 64 validadores "raíz" en la subred principal. Esto era un punto de centralización: unos pocos validadores poderosos tenían una influencia desproporcionada en la asignación de recompensas, lo que llevó a lo que algunos llamaron un "sistema de votación oligárquico". Para abordar esto, Bittensor introdujo la gobernanza dTAO (TAO descentralizado) en 2025. El sistema dTAO cambió la asignación de recursos para que fuera impulsada por el mercado y controlada por la comunidad. Concretamente, los poseedores de TAO pueden hacer stake de sus tokens en pools de liquidez específicos de subred (esencialmente, "votan" sobre qué subredes deberían obtener más emisiones de la red) y reciben tokens alfa que representan la propiedad en esos pools de subred. Las subredes que atraen más stake tendrán un precio de token alfa más alto y obtendrán una mayor parte de la emisión diaria de TAO, mientras que las subredes impopulares o de bajo rendimiento verán cómo el capital (y por lo tanto las emisiones) se aleja. Esto crea un bucle de retroalimentación: si una subred produce servicios de IA valiosos, más personas hacen stake de TAO en ella (buscando recompensas), lo que le da a esa subred más TAO para recompensar a sus participantes, fomentando el crecimiento. Si una subred se estanca, los stakers se retiran a subredes más lucrativas. En efecto, los poseedores de TAO gobiernan colectivamente el enfoque de la red al señalar financieramente qué dominios de IA merecen más recursos. Esta es una forma de gobernanza en la cadena por peso de token, alineada con los resultados económicos. Aparte de la asignación de recursos, las principales actualizaciones del protocolo o los cambios de parámetros probablemente todavía pasan por propuestas de gobernanza donde los poseedores de TAO votan (Bittensor tiene un mecanismo para propuestas y referendos en la cadena gestionados por la Fundación Bittensor y un consejo electo, similar a la gobernanza de Polkadot). Con el tiempo, se puede esperar que la gobernanza de Bittensor se vuelva cada vez más descentralizada, con la fundación dando un paso atrás a medida que la comunidad (a través del stake de TAO) dirige cosas como la tasa de inflación, la aprobación de nuevas subredes, etc. La transición a dTAO es un gran paso en esa dirección, reemplazando a los tomadores de decisiones centralizados con un mercado de partes interesadas de tokens alineado con incentivos.

• Incentivos de Bittensor: La estructura de incentivos de Bittensor está estrechamente entrelazada con su consenso. Cada bloque (12 segundos), se acuña exactamente 1 TAO nuevo y se divide entre los contribuyentes de cada subred según el rendimiento. La división predeterminada para la recompensa de bloque de cada subred es 41 % para los mineros, 41 % para los validadores y 18 % para el propietario de la subred. Esto asegura que todos los roles sean recompensados: los mineros ganan por hacer el trabajo de inferencia, los validadores ganan por su esfuerzo de evaluación, y los propietarios de subredes (que pueden haber iniciado los datos/tarea para esa subred) ganan un residual por proporcionar el "mercado" o el diseño de la tarea. Esos porcentajes están fijados en el protocolo y tienen como objetivo alinear los incentivos de todos hacia una producción de IA de alta calidad. El mecanismo de consenso Yuma refina aún más los incentivos al ponderar las recompensas según las puntuaciones de calidad: un minero que proporciona mejores respuestas (según el consenso de los validadores) obtiene una porción mayor de ese 41 %, y un validador que sigue de cerca el consenso honesto obtiene más de la porción del validador. Los de bajo rendimiento son eliminados económicamente. Además, los delegadores (stakers) que respaldan a un minero o validador generalmente recibirán una parte de las ganancias de ese nodo (los nodos a menudo establecen una comisión y dan el resto a sus delegadores, similar al staking en redes PoS). Esto permite a los poseedores pasivos de TAO apoyar a los mejores contribuyentes y obtener rendimiento, reforzando aún más la meritocracia. El token de Bittensor (TAO) es, por lo tanto, un token de utilidad: se requiere para el registro de nuevos mineros (los mineros deben gastar una pequeña cantidad de TAO para unirse, lo que combate el spam Sybil) y se puede hacer stake para aumentar la influencia o ganar a través de la delegación. También se prevé como un token de pago si los usuarios externos quieren consumir servicios de la red de Bittensor (por ejemplo, pagando TAO para consultar un modelo de lenguaje en Bittensor), aunque el mecanismo de recompensa interno ha sido la "economía" principal hasta ahora. La filosofía general de incentivos es recompensar la "inteligencia valiosa" —es decir, modelos que ayudan a producir buenos resultados de IA— y crear una competencia que mejore continuamente la calidad de los modelos en la red.

• Gobernanza de Gensyn: El modelo de gobernanza de Gensyn está estructurado para evolucionar desde el control del equipo central al control de la comunidad a medida que la red madura. Inicialmente, Gensyn tendrá una Fundación Gensyn y un consejo electo que supervisarán las actualizaciones del protocolo y las decisiones del tesoro. Se espera que este consejo esté compuesto por miembros del equipo central y líderes comunitarios tempranos al principio. Gensyn planea un Evento de Generación de Tokens (TGE) para su token nativo (a menudo referido como GENS), después del cual el poder de gobernanza estaría cada vez más en manos de los poseedores de tokens a través de la votación en la cadena. El papel de la fundación es representar los intereses del protocolo y asegurar una transición suave hacia la descentralización total. En la práctica, Gensyn probablemente tendrá mecanismos de propuesta en la cadena donde los cambios en los parámetros (por ejemplo, la duración del juego de verificación, las tasas de comisión) o las actualizaciones se votan por la comunidad. Debido a que Gensyn se está implementando como un rollup de Ethereum, la gobernanza también podría vincularse a la seguridad de Ethereum (por ejemplo, usando claves de actualización para el contrato del rollup que eventualmente se entregan a una DAO de poseedores de tokens). La sección de descentralización y gobernanza del litepaper de Gensyn enfatiza que el protocolo debe ser en última instancia de propiedad global, alineándose con el ethos de que la "red para la inteligencia de máquinas" debería pertenecer a sus usuarios y contribuyentes. En resumen, la gobernanza de Gensyn comienza semi-centralizada pero está diseñada para convertirse en una DAO donde los poseedores de tokens GENS (potencialmente ponderados por stake o participación) toman decisiones colectivamente.

• Incentivos de Gensyn: Los incentivos económicos en Gensyn son dinámicas de mercado sencillas complementadas con seguridad criptoeconómica. Los desarrolladores (clientes) pagan por las tareas de ML en el token de Gensyn, y los Resolutores ganan tokens al completar esas tareas correctamente. El precio de los ciclos de cómputo se determina en un mercado abierto; presumiblemente, los desarrolladores pueden publicar tareas con una recompensa y los resolutores pueden pujar o simplemente tomarla si el precio cumple con sus expectativas. Esto asegura que mientras haya oferta de GPU inactivas, la competencia reducirá el costo a una tasa justa (el equipo de Gensyn proyecta una reducción de costos de hasta el 80 % en comparación con los precios de la nube, ya que la red encuentra el hardware disponible más barato a nivel mundial). Por otro lado, los resolutores tienen el incentivo de ganar tokens por su trabajo; su hardware que de otro modo estaría inactivo ahora genera ingresos. Para garantizar la calidad, Gensyn requiere que los resolutores hagan stake de una garantía cuando aceptan un trabajo: si hacen trampa o producen un resultado incorrecto y son atrapados, pierden esa garantía (puede ser recortada y otorgada al verificador honesto). Los verificadores son incentivados por la posibilidad de ganar una recompensa "jackpot" si atrapan a un resolutor fraudulento, similar al diseño de Truebit de recompensar periódicamente a los verificadores que identifican con éxito una computación incorrecta. Esto mantiene a los resolutores honestos y motiva a algunos nodos a actuar como vigilantes. En un escenario óptimo (sin trampas), los resolutores simplemente ganan la tarifa de la tarea y el rol de verificador está mayormente inactivo (o uno de los resolutores participantes podría actuar también como verificador de otros). El token de Gensyn sirve así tanto como moneda de gas para comprar cómputo como garantía de stake que asegura el protocolo. El litepaper menciona una testnet con tokens no permanentes y que los participantes tempranos de la testnet serán recompensados en el TGE con tokens reales. Esto indica que Gensyn asignó parte del suministro de tokens para el arranque —recompensando a los primeros adoptantes, resolutores de prueba y miembros de la comunidad. A largo plazo, las tarifas de los trabajos reales deberían sostener la red. También puede haber una pequeña tarifa de protocolo (un porcentaje de cada pago de tarea) que va a un tesoro o se quema; este detalle aún no está confirmado, pero muchos protocolos de mercado incluyen una tarifa para financiar el desarrollo o la recompra y quema de tokens. En resumen, los incentivos de Gensyn se alinean en torno a la finalización honesta de los trabajos de ML: haz el trabajo, te pagan; intenta hacer trampa, pierdes el stake; verifica a otros, ganas si atrapas a los tramposos. Esto crea un sistema económico de autovigilancia destinado a lograr una computación distribuida confiable.

• Gobernanza de Cuckoo: Cuckoo Network incorporó la gobernanza en su ecosistema desde el primer día, aunque todavía está en fase de desarrollo. El token $CAI es explícitamente un token de gobernanza además de sus roles de utilidad. La filosofía de Cuckoo es que los operadores de nodos de GPU, los desarrolladores de aplicaciones e incluso los usuarios finales deberían tener voz en la evolución de la red, lo que refleja su visión impulsada por la comunidad. En la práctica, las decisiones importantes (como actualizaciones del protocolo o cambios económicos) se decidirían mediante votos ponderados por tokens, presumiblemente a través de un mecanismo de DAO. Por ejemplo, Cuckoo podría realizar votaciones en la cadena para cambiar la distribución de recompensas o adoptar una nueva característica, y los poseedores de$CAI (incluidos mineros, desarrolladores y usuarios) votarían. La votación en la cadena ya se utiliza como un sistema de reputación: Cuckoo requiere que cada rol haga stake de tokens, y luego los miembros de la comunidad pueden votar (quizás delegando stake o a través de módulos de gobernanza) sobre qué coordinadores o mineros son de confianza. Esto afecta las puntuaciones de reputación y podría influir en la programación de tareas (por ejemplo, un coordinador con más votos podría atraer a más usuarios, o un minero con más votos podría recibir más tareas). Es una mezcla de gobernanza e incentivo: usar tokens de gobernanza para establecer la confianza. La Fundación Cuckoo o el equipo central ha guiado la dirección del proyecto hasta ahora (por ejemplo, tomando la reciente decisión de descontinuar la cadena L1), pero su blog indica un compromiso de avanzar hacia la propiedad descentralizada. Identificaron que operar su propia cadena incurría en altos costos generales y que pivotar hacia un rollup permitirá un desarrollo más abierto y la integración con los ecosistemas existentes. Es probable que una vez en una capa compartida (como Ethereum), Cuckoo implemente una DAO más tradicional para las actualizaciones, con la comunidad votando usando CAI.

• Incentivos de Cuckoo: El diseño de incentivos para Cuckoo tiene dos fases: la fase inicial de arranque con asignaciones de tokens fijas, y un estado futuro con reparto de ingresos impulsado por el uso. En su lanzamiento, Cuckoo realizó una distribución de "lanzamiento justo" de 1 mil millones de tokens CAI. El 51 % del suministro se reservó para la comunidad, asignado como:

• Recompensas de Minería: 30 % del suministro total reservado para pagar a los mineros de GPU por realizar tareas de IA.

• Recompensas de Staking: 11 % del suministro para aquellos que hacen stake y ayudan a asegurar la red.

• Airdrops: 5 % para los primeros usuarios y miembros de la comunidad como incentivo de adopción.

• (Otro 5 % fue para subvenciones a desarrolladores para fomentar la construcción en Cuckoo).

Esta gran asignación significa que en la red inicial, los mineros y stakers fueron recompensados de un pool de emisiones, incluso si la demanda real de los usuarios era baja. De hecho, la fase inicial de Cuckoo presentó altos rendimientos APY para el staking y la minería, lo que atrajo con éxito a los participantes, pero también a los "yield farmers" que solo estaban allí por los tokens. El equipo notó que muchos usuarios se fueron una vez que las tasas de recompensa cayeron, lo que indica que esos incentivos no estaban ligados a un uso genuino. Habiendo aprendido de esto, Cuckoo está cambiando a un modelo donde las recompensas se correlacionan directamente con la carga de trabajo real de IA. En el futuro (y parcialmente ya), cuando un usuario final paga por una inferencia de IA, ese pago (en CAI o posiblemente otro token aceptado convertido a CAI) se dividirá entre los contribuyentes:

• Los mineros de GPU recibirán la mayor parte por el cómputo que proporcionaron.
• El Coordinador (desarrollador de la aplicación) tomará una porción como el proveedor de servicios que suministró el modelo y manejó la solicitud.
• Los Stakers que han delegado a esos mineros o coordinadores podrían obtener una pequeña parte o una recompensa inflacionaria, para continuar incentivando el respaldo de nodos confiables.
• La Red/Tesorería podría retener una tarifa para el desarrollo continuo o para financiar futuros incentivos (o la tarifa podría ser cero/nominal para maximizar la asequibilidad para el usuario).

Esencialmente, Cuckoo se está moviendo hacia un modelo de reparto de ingresos: si una aplicación de IA en Cuckoo genera ganancias, esas ganancias se distribuyen a todos los contribuyentes de ese servicio de manera justa. Esto alinea los incentivos para que los participantes se beneficien del uso real en lugar de solo de la inflación. La red ya requería que todas las partes hicieran stake de CAI; esto significa que los mineros y coordinadores no solo ganan una recompensa plana, sino también posiblemente recompensas basadas en el stake (por ejemplo, un coordinador podría ganar mayores recompensas si muchos usuarios hacen stake en ellos o si ellos mismos hacen más stake, similar a cómo ganan los validadores de prueba de participación). En cuanto a los incentivos para los usuarios, Cuckoo también introdujo cosas como un portal de airdrops y faucets (que algunos usuarios explotaron) para sembrar la actividad inicial. En el futuro, los usuarios podrían ser incentivados a través de reembolsos en tokens por usar los servicios o a través de recompensas de gobernanza por participar en la curación (por ejemplo, quizás ganando pequeños tokens por calificar resultados o contribuir con datos). La conclusión es que el token de Cuckoo ($CAI) es multipropósito: es el token de gas/tarifa en la cadena (todas las transacciones y pagos lo usan), se usa para staking y votación, y es la unidad de recompensa por el trabajo realizado. Cuckoo menciona explícitamente que quiere vincular las recompensas de tokens a KPIs a nivel de servicio (indicadores clave de rendimiento) —por ejemplo, tiempo de actividad, rendimiento de consultas, satisfacción del usuario— para evitar incentivos puramente especulativos. Esto refleja una maduración de la economía de tokens desde la simple minería de liquidez a un modelo más sostenible e impulsado por la utilidad.

Propiedad de Modelos y Atribución de PI​

Manejar la propiedad intelectual (PI) y los derechos de propiedad de los modelos de IA es un aspecto complejo de las redes de IA descentralizadas. Cada plataforma ha adoptado una postura ligeramente diferente, y en general esta es un área en evolución sin una solución completa todavía:

• Bittensor: Los modelos en Bittensor son proporcionados por los nodos mineros, y esos mineros retienen el control total sobre los pesos de sus modelos (que nunca se publican en la cadena). Bittensor no rastrea explícitamente quién "posee" un modelo más allá del hecho de que se está ejecutando en una cierta dirección de billetera. Si un minero se va, su modelo se va con él. Por lo tanto, la atribución de PI en Bittensor es fuera de la cadena: si un minero usa un modelo propietario, no hay nada en la cadena que lo haga cumplir o incluso lo sepa. La filosofía de Bittensor fomenta las contribuciones abiertas (muchos mineros podrían usar modelos de código abierto como GPT-J u otros) y la red recompensa el rendimiento de esos modelos. Se podría decir que Bittensor crea una puntuación de reputación para los modelos (a través de las clasificaciones de los validadores), y esa es una forma de reconocer el valor del modelo, pero los derechos sobre el modelo en sí no están tokenizados ni distribuidos. Notablemente, los propietarios de subred en Bittensor podrían ser vistos como dueños de una pieza de PI: definen una tarea (que podría incluir un conjunto de datos o un método). El propietario de la subred acuña un NFT (llamado UID de subred) al crear una subred, y ese NFT les da derecho al 18 % de las recompensas en esa subred. Esto tokeniza efectivamente la creación de un mercado de modelos (la subred), si no las instancias del modelo. Si se considera la definición de la subred (digamos una tarea de reconocimiento de voz con un conjunto de datos particular) como PI, eso al menos se registra y recompensa. Pero los pesos individuales del modelo que los mineros entrenan, no hay un registro de propiedad en la cadena de ellos. La atribución viene en forma de recompensas pagadas a la dirección de ese minero. Bittensor actualmente no implementa un sistema donde, por ejemplo, varias personas puedan poseer conjuntamente un modelo y obtener un reparto automático de ingresos; la persona que ejecuta el modelo (minero) obtiene la recompensa y depende de ellos fuera de la cadena honrar cualquier licencia de PI del modelo que usaron.

• Gensyn: En Gensyn, la propiedad del modelo es sencilla en el sentido de que el solicitante (el que quiere que se entrene un modelo) proporciona la arquitectura del modelo y los datos, y después del entrenamiento, recibe el artefacto del modelo resultante. Los resolutores que realizan el trabajo no tienen derechos sobre el modelo; son como contratistas que reciben un pago por un servicio. El protocolo de Gensyn asume así el modelo de PI tradicional: si tenías derechos legales sobre el modelo y los datos que enviaste, todavía los tienes después de que se entrene; la red de cómputo no reclama ninguna propiedad. Gensyn menciona que el mercado también podría comerciar algoritmos y datos como cualquier otro recurso. Esto sugiere un escenario en el que alguien podría ofrecer un modelo o algoritmo para su uso en la red, posiblemente por una tarifa, tokenizando así el acceso a ese modelo. Por ejemplo, un creador de modelos podría poner su modelo preentrenado en Gensyn y permitir que otros lo ajusten a través de la red por una tarifa (esto monetizaría efectivamente la PI del modelo). Si bien el protocolo no hace cumplir los términos de la licencia, se podrían codificar los requisitos de pago: un contrato inteligente podría requerir una tarifa para desbloquear los pesos del modelo para un resolutor. Sin embargo, estos son casos de uso especulativos; el diseño principal de Gensyn se trata de habilitar trabajos de entrenamiento. En cuanto a la atribución, si varias partes contribuyen a un modelo (digamos que una proporciona datos, otra proporciona cómputo), eso probablemente se manejaría mediante cualquier contrato o acuerdo que establezcan antes de usar Gensyn (por ejemplo, un contrato inteligente podría dividir el pago entre el proveedor de datos y el proveedor de cómputo). Gensyn en sí no rastrea "este modelo fue construido por X, Y, Z" en la cadena más allá del registro de qué direcciones se pagaron por el trabajo. En resumen, la PI del modelo en Gensyn permanece con el solicitante, y cualquier atribución o licencia debe manejarse a través de los acuerdos legales fuera del protocolo o a través de contratos inteligentes personalizados construidos sobre él.

• Cuckoo: En el ecosistema de Cuckoo, los creadores de modelos (constructores de aplicaciones de IA) son participantes de primera clase: ellos despliegan el servicio de IA. Si un constructor de aplicaciones ajusta un modelo de lenguaje o desarrolla un modelo personalizado y lo aloja en Cuckoo, ese modelo es esencialmente su propiedad y actúan como el propietario del servicio. Cuckoo no se apropia de ninguna propiedad; en cambio, proporciona la infraestructura para que moneticen su uso. Por ejemplo, si un desarrollador despliega una IA de chatbot, los usuarios pueden interactuar con ella y el desarrollador (más los mineros) ganan CAI por cada interacción. La plataforma atribuye así los ingresos por uso al creador del modelo, pero no publica explícitamente los pesos del modelo ni los convierte en un NFT. De hecho, para ejecutar el modelo en las GPU de los mineros, el nodo coordinador probablemente tenga que enviar el modelo (o el tiempo de ejecución) al minero de alguna forma. Esto plantea preguntas sobre la PI: ¿podría un minero malicioso copiar los pesos del modelo y distribuirlos? En una red descentralizada, ese riesgo existe si se utilizan modelos propietarios. El enfoque actual de Cuckoo ha sido en modelos bastante abiertos (Stable Diffusion, modelos derivados de LLaMA, etc.) y en construir una comunidad, por lo que aún no hemos visto una aplicación de los derechos de PI a través de contratos inteligentes. La plataforma podría integrar potencialmente herramientas como la ejecución de modelos encriptados o enclaves seguros en el futuro para la protección de la PI, pero no se menciona nada específico en la documentación. Lo que sí rastrea es quién proporcionó el servicio del modelo para cada tarea: dado que el coordinador es una identidad en la cadena, todo el uso de su modelo se le atribuye, y obtienen automáticamente su parte de las recompensas. Si alguien entregara o vendiera un modelo a otra persona, efectivamente transferiría el control del nodo coordinador (quizás incluso simplemente dándoles la clave privada o el NFT si el rol de coordinador estuviera tokenizado). En la actualidad, la propiedad comunitaria de modelos (a través de participaciones en tokens) no está implementada, pero la visión de Cuckoo sugiere una IA descentralizada impulsada por la comunidad, por lo que podrían explorar permitir que las personas financien o gobiernen colectivamente un modelo de IA. La tokenización de modelos más allá de la propiedad individual sigue siendo un área abierta en estas redes; se reconoce como un objetivo (permitir que las comunidades posean modelos de IA en lugar de las corporaciones), pero en la práctica requiere soluciones para los desafíos de PI y verificación mencionados anteriormente.

En resumen, la propiedad de los modelos en Bittensor, Gensyn y Cuckoo se maneja fuera de la cadena por medios tradicionales: la persona o entidad que ejecuta o envía el modelo es efectivamente el propietario. Las redes proporcionan atribución en forma de recompensas económicas (pagando al contribuyente del modelo por su PI o esfuerzo). Ninguno de los tres tiene una licencia incorporada o una aplicación de regalías sobre el uso del modelo a nivel de contrato inteligente todavía. La atribución proviene de la reputación y la recompensa: por ejemplo, los mejores modelos de Bittensor obtienen altas puntuaciones de reputación (que es un registro público) y más TAO, lo que es un crédito implícito para sus creadores. Con el tiempo, podemos ver características como pesos de modelo vinculados a NFT o licencias descentralizadas para rastrear mejor la PI, pero actualmente la prioridad ha sido hacer que las redes funcionen e incentiven las contribuciones. Todos están de acuerdo en que verificar la procedencia y los resultados de los modelos es clave para permitir verdaderos mercados de activos de modelos, y la investigación en esta dirección está en curso.

Estructuras de Reparto de Ingresos​

Las tres plataformas deben decidir cómo dividir el pastel económico cuando varias partes colaboran para producir un resultado de IA valioso. ¿Quién recibe el pago y cuánto, cuando se utiliza un servicio de IA o cuando se emiten tokens? Cada una tiene un modelo de reparto de ingresos distinto:

• Bittensor: Como se mencionó en la sección de incentivos, la distribución de ingresos de Bittensor está definida por el protocolo a nivel de bloque: 41 % para los mineros, 41 % para los validadores, 18 % para el propietario de la subred por cada emisión de TAO del bloque. Esto es efectivamente un reparto de ingresos incorporado para el valor generado en cada subred. La parte del propietario de la subred (18 %) actúa como una regalía por el "diseño del modelo/tarea" o por iniciar el ecosistema de esa subred. El hecho de que mineros y validadores obtengan partes iguales asegura que sin validación, los mineros no son recompensados (y viceversa); son simbióticos y cada uno obtiene una porción igual de las recompensas acuñadas. Si consideramos a un usuario externo que paga TAO para consultar un modelo, el whitepaper de Bittensor prevé que ese pago también se divida de manera similar entre el minero que responde y los validadores que ayudaron a verificar la respuesta (la división exacta podría ser determinada por el protocolo o las fuerzas del mercado). Además, los delegadores que hacen stake en mineros/validadores son efectivamente socios; típicicamente, un minero/validador compartirá un porcentaje de su TAO ganado con sus delegadores (esto es configurable, pero a menudo la mayoría va a los delegadores). Así, si un minero ganó 1 TAO de un bloque, eso podría dividirse 80/20 entre sus delegadores y ellos mismos, por ejemplo, según el stake. Esto significa que incluso los no operadores obtienen una parte de los ingresos de la red proporcional a su apoyo. Con la introducción de dTAO, se agregó otra capa de reparto: aquellos que hacen stake en el pool de una subred obtienen tokens alfa, que les dan derecho a parte de las emisiones de esa subred (como el yield farming). En efecto, cualquiera puede tomar una participación en el éxito de una subred particular y recibir una fracción de las recompensas de mineros/validadores al poseer tokens alfa (los tokens alfa se aprecian a medida que la subred atrae más uso y emisiones). En resumen, el reparto de ingresos de Bittensor está fijado por código para los roles principales, y se comparte aún más mediante acuerdos sociales/de staking. Es una división relativamente transparente y basada en reglas: cada bloque, los participantes saben exactamente cómo se asigna el 1 TAO, y por lo tanto conocen sus "ganancias" por contribución. Esta claridad es una de las razones por las que Bittensor a veces se compara con Bitcoin para la IA: una emisión monetaria determinista donde la recompensa de los participantes se establece matemáticamente.

• Gensyn: El reparto de ingresos en Gensyn es más dinámico e impulsado por el mercado, ya que las tareas tienen un precio individual. Cuando un solicitante crea un trabajo, adjunta una recompensa (digamos X tokens) que está dispuesto a pagar. Un resolutor que completa el trabajo obtiene esa X (menos cualquier tarifa de red). Si un verificador está involucrado, típicamente hay una regla como: si no se detecta fraude, el resolutor se queda con el pago completo; si se detecta fraude, el resolutor es penalizado con slashing —perdiendo parte o la totalidad de su stake— y esa cantidad recortada se le da al verificador como recompensa. Así que los verificadores no ganan de cada tarea, solo cuando atrapan un mal resultado (además de posiblemente una pequeña tarifa base por participar, dependiendo de la implementación). No hay un concepto incorporado de pagar al propietario de un modelo aquí porque se asume que el solicitante es el propietario del modelo o tiene derechos para usarlo. Uno podría imaginar un escenario donde un solicitante está ajustando el modelo preentrenado de otra persona y una porción del pago va al creador original del modelo, pero eso tendría que manejarse fuera del protocolo (por ejemplo, mediante un acuerdo o un contrato inteligente separado que divida el pago del token en consecuencia). El reparto a nivel de protocolo de Gensyn es esencialmente cliente -> resolutor (-> verificador). El modelo de token probablemente incluye alguna asignación para el tesoro o la fundación del protocolo; por ejemplo, un pequeño porcentaje del pago de cada tarea podría ir a una tesorería que podría usarse para financiar el desarrollo o pools de seguros (esto no se indica explícitamente en los documentos disponibles, pero muchos protocolos lo hacen). Además, al principio, Gensyn puede subsidiar a los resolutores a través de la inflación: a los usuarios de la testnet se les prometen recompensas en el TGE, lo que es efectivamente un reparto de ingresos de la distribución inicial de tokens (los primeros resolutores y partidarios obtienen una parte de los tokens por ayudar a arrancar, similar a un airdrop o recompensa de minería). Con el tiempo, a medida que los trabajos reales dominen, las recompensas inflacionarias disminuirían, y los ingresos de los resolutores provendrían principalmente de los pagos de los usuarios. El enfoque de Gensyn se puede resumir como un modelo de ingresos de pago por servicio: la red facilita un pago directo de aquellos que necesitan que se haga un trabajo a aquellos que lo hacen, con los verificadores y posiblemente los stakers de tokens tomando una parte solo cuando desempeñan un papel en la seguridad de ese servicio.

• Cuckoo: El reparto de ingresos de Cuckoo ha evolucionado. Inicialmente, debido a que no había muchos usuarios finales que pagaran, el reparto de ingresos era esencialmente un reparto de inflación: las asignaciones del 30 % para minería y del 11 % para staking del suministro de tokens significaban que los mineros y stakers compartían los tokens emitidos por el pool de lanzamiento justo de la red. En la práctica, Cuckoo realizaba cosas como pagos diarios de CAI a los mineros proporcionales a las tareas completadas. Esos pagos provenían en gran medida de la asignación de recompensas de minería (que es parte del suministro fijo reservado). Esto es similar a cómo muchas blockchains de Capa 1 distribuyen recompensas de bloque a mineros/validadores; no estaba ligado al uso real por parte de usuarios externos, era más para incentivar la participación y el crecimiento. Sin embargo, como se destaca en su blog de julio de 2025, esto llevó a un uso incentivado por el farming de tokens en lugar de la demanda real. La siguiente etapa para Cuckoo es un verdadero modelo de reparto de ingresos basado en tarifas de servicio. En este modelo, cuando un usuario final usa, digamos, el servicio de generación de imágenes y paga $1 (en términos de cripto), ese valor de$1 en tokens se dividiría quizás así: 0.70 para el minero que hizo el trabajo de GPU, 0.20 para el desarrollador de la aplicación (coordinador) que proporcionó el modelo y la interfaz, y 0.10 para los stakers o la tesorería de la red. (Nota: las proporciones exactas son hipotéticas; Cuckoo no las ha especificado públicamente todavía, pero esto ilustra el concepto). De esta manera, todos los contribuyentes a la prestación del servicio obtienen una parte de los ingresos. Esto es análogo, por ejemplo, a una economía de viajes compartidos pero para la IA: el vehículo (minero de GPU) obtiene la mayoría, el conductor o la plataforma (coordinador que construyó el servicio del modelo) obtiene una parte, y quizás la gobernanza/stakers de la plataforma obtienen una pequeña tarifa. La mención de Cuckoo de "modelos de reparto de ingresos y recompensas de tokens vinculados directamente a métricas de uso" sugiere que si un servicio o nodo en particular maneja mucho volumen, sus operadores y partidarios ganarán más. Se están alejando de los rendimientos planos por simplemente bloquear tokens (que era el caso con su APY de staking inicialmente). En términos concretos: si haces stake en un coordinador que termina impulsando una aplicación de IA muy popular, podrías ganar una porción de las tarifas de esa aplicación, un verdadero escenario de staking como inversión en utilidad, en lugar de hacer stake solo por la inflación. Esto alinea los incentivos de todos para atraer a usuarios reales que pagan por los servicios de IA, lo que a su vez devuelve valor a los poseedores de tokens. Vale la pena señalar que la cadena de Cuckoo también tenía tarifas por transacciones (gas), por lo que los mineros que producían bloques (inicialmente los mineros de GPU también contribuían a la producción de bloques en la cadena de Cuckoo) también obtenían tarifas de gas. Con el cierre de la cadena y la migración a un rollup, las tarifas de gas probablemente serán mínimas (o en Ethereum), por lo que los ingresos principales se convierten en las propias tarifas del servicio de IA. En resumen, Cuckoo está en transición de un modelo impulsado por subsidios (la red paga a los participantes de su pool de tokens) a un modelo impulsado por la demanda (los participantes ganan de los pagos reales de los usuarios). El token seguirá desempeñando un papel en el staking y la gobernanza, pero las ganancias diarias de los mineros y los desarrolladores de aplicaciones deberían provenir cada vez más de los usuarios que compran servicios de IA. Este modelo es más sostenible a largo plazo y se asemeja mucho al reparto de ingresos de SaaS de la Web2, pero implementado a través de contratos inteligentes y tokens para mayor transparencia.

Superficies de Ataque y Vulnerabilidades​

La descentralización de la IA introduce varios desafíos de incentivos y seguridad. Ahora analizamos los vectores de ataque clave —ataques Sybil, colusión, parasitismo (freeloading) y envenenamiento de datos/modelos— y cómo cada plataforma los mitiga o permanece vulnerable a ellos:

• Ataques Sybil (identidades falsas): En una red abierta, un atacante podría crear muchas identidades (nodos) para obtener recompensas o influencia desproporcionadas.

• Bittensor: La resistencia a los ataques Sybil se proporciona principalmente por el costo de entrada. Para registrar un nuevo minero o validador en Bittensor, uno debe gastar o hacer stake de TAO; esto podría ser una quema o un requisito de fianza. Esto significa que crear N nodos falsos incurre en N veces el costo, lo que hace que los grandes enjambres Sybil sean caros. Además, el consenso de Bittensor vincula la influencia al stake y al rendimiento; un Sybil sin stake o con bajo rendimiento gana poco. Un atacante tendría que invertir mucho y también hacer que sus nodos Sybil contribuyan con trabajo útil para obtener una recompensa significativa (lo cual no es una estrategia Sybil típica). Dicho esto, si un atacante sí tiene mucho capital, podría adquirir la mayoría de los TAO y registrar muchos validadores o mineros, efectivamente un Sybil por riqueza. Esto se superpone con el escenario de ataque del 51 %: si una sola entidad controla >50 % del TAO en stake en una subred, pueden influir fuertemente en el consenso. La introducción de dTAO por parte de Bittensor ayuda un poco aquí: distribuye la influencia entre las subredes y requiere el apoyo de la comunidad en el staking para que las subredes prosperen, lo que dificulta que una entidad controle todo. Aún así, los ataques Sybil por parte de un adversario bien financiado siguen siendo una preocupación; el análisis de Arxiv señala explícitamente que el stake está bastante concentrado ahora, por lo que la barrera para un ataque mayoritario no es tan alta como se desearía. Para mitigar esto, se han sugerido propuestas como límites de stake por billetera (por ejemplo, limitar el stake efectivo en el percentil 88 para evitar que una billetera domine). En resumen, Bittensor se basa en la identidad ponderada por stake (no se pueden generar identidades baratas sin un stake proporcional) para manejar los Sybils; es razonablemente efectivo excepto bajo un atacante muy ingenioso.

• Gensyn: Los ataques Sybil en Gensyn se manifestarían como un atacante creando muchos nodos de resolutor o verificador para manipular el sistema. La defensa de Gensyn es puramente económica y criptográfica: las identidades en sí no importan, pero hacer el trabajo o depositar una garantía sí. Si un atacante crea 100 nodos de resolutor falsos pero no tienen trabajos ni stake, no logran nada. Para ganar tareas, un nodo Sybil tendría que pujar competitivamente y tener el hardware para hacer el trabajo. Si pujan por debajo sin capacidad, fallarán y perderán el stake. De manera similar, un atacante podría crear muchas identidades de verificador con la esperanza de ser elegido para verificar (si el protocolo selecciona verificadores al azar). Pero si hay demasiados, la red o el solicitante del trabajo podrían limitar el número de verificadores activos. Además, los verificadores necesitan potencialmente realizar la computación para verificarla, lo cual es costoso; tener muchos verificadores falsos no ayuda a menos que realmente puedas verificar los resultados. Un ángulo Sybil más pertinente en Gensyn es si un atacante intenta llenar la red con trabajos o respuestas falsas para hacer perder el tiempo a otros. Eso se mitiga requiriendo también un depósito de los solicitantes (un solicitante malicioso que publica trabajos falsos pierde su pago o depósito). En general, el uso de stakes/fianzas requeridas y la selección aleatoria para la verificación por parte de Gensyn significa que un atacante gana poco al tener múltiples identidades a menos que también traiga recursos proporcionales. Se convierte en un ataque más costoso en lugar de uno barato. El modelo de seguridad optimista asume al menos un verificador honesto; los Sybils tendrían que abrumar y ser todos los verificadores para hacer trampa consistentemente, lo que nuevamente nos lleva a poseer la mayoría del stake o del poder de cómputo. La resistencia Sybil de Gensyn es, por lo tanto, comparable a la de un rollup optimista: mientras haya un actor honesto, los Sybils no pueden causar un daño sistémico fácilmente.

• Cuckoo: La prevención de ataques Sybil en Cuckoo se basa en el staking y la investigación de la comunidad. Cada rol en Cuckoo (minero, coordinador, incluso usuario en algunos casos) requiere hacer stake de $CAI. Esto eleva inmediatamente el costo de las identidades Sybil: un atacante que crea 100 mineros falsos necesitaría adquirir y bloquear stake para cada uno. Además, el diseño de Cuckoo tiene un elemento humano/comunitario: los nuevos nodos necesitan ganar reputación a través de la votación en la cadena. Es poco probable que un ejército Sybil de nodos nuevos sin reputación reciba muchas tareas o la confianza de los usuarios. Los coordinadores en particular tienen que atraer usuarios; un coordinador falso sin historial no obtendría uso. Para los mineros, los coordinadores pueden ver sus estadísticas de rendimiento (tareas exitosas, etc.) en Cuckoo Scan y preferirán mineros confiables. Cuckoo también tenía un número relativamente pequeño de mineros (40 GPU en un momento en la beta), por lo que cualquier afluencia extraña de muchos nodos sería notable. El punto débil potencial es si el atacante también manipula el sistema de reputación, por ejemplo, haciendo un gran stake de CAI en sus nodos Sybil para que parezcan reputables o creando cuentas de "usuario" falsas para votarse a sí mismos. Esto es teóricamente posible, pero como todo está curado por tokens, cuesta tokens hacerlo (esencialmente estarías votando con tu propio stake en tus propios nodos). El equipo de Cuckoo también puede ajustar los parámetros de staking y recompensa si se observa un comportamiento Sybil (especialmente ahora que se está convirtiendo en un servicio de rollup más centralizado; pueden pausar o aplicar slashing a los malos actores). En resumen, los Sybils se mantienen a raya al requerir tener algo en juego (stake) y necesitar la aprobación de la comunidad. Nadie puede simplemente entrar con cientos de GPU falsas y cosechar recompensas sin una inversión significativa que los participantes honestos podrían gastar mejor en hardware real y stake.

• Colusión: Aquí consideramos a múltiples participantes que se confabulan para manipular el sistema, por ejemplo, validadores y mineros que coluden en Bittensor, o resolutores y verificadores que coluden en Gensyn, etc.

• Bittensor: La colusión ha sido identificada como una preocupación real. En el diseño original, un puñado de validadores podía coludir para siempre votar a favor de ciertos mineros o de ellos mismos, sesgando injustamente la distribución de recompensas (esto se observó como una concentración de poder en la subred raíz). El consenso Yuma proporciona cierta defensa: al tomar una mediana de las puntuaciones de los validadores y penalizar a los que se desvían, evita que un pequeño grupo en colusión impulse dramáticamente a un objetivo a menos que sean la mayoría. En otras palabras, si 3 de 10 validadores coluden para dar a un minero una puntuación súper alta pero los otros 7 no lo hacen, las puntuaciones atípicas de los coludidos se recortan y la recompensa del minero se basa en la puntuación mediana (por lo que la colusión no ayuda significativamente). Sin embargo, si los coludidos forman >50 % de los validadores (o >50 % del stake entre los validadores), efectivamente son el consenso: pueden acordar puntuaciones altas falsas y la mediana reflejará su opinión. Este es el clásico escenario de ataque del 51 %. Desafortunadamente, el estudio de Arxiv encontró algunas subredes de Bittensor donde una coalición de solo el 1-2 % de los participantes (en términos de número) controlaba la mayoría del stake, debido a la fuerte concentración de tokens. Esto significa que la colusión de unos pocos grandes poseedores era una amenaza creíble. La mitigación que Bittensor está persiguiendo a través de dTAO es democratizar la influencia: al permitir que cualquier poseedor de TAO dirija el stake a las subredes, diluye el poder de los grupos cerrados de validadores. Además, propuestas como el staking cóncavo (rendimientos decrecientes para un stake desproporcionado) y los límites de stake tienen como objetivo romper la capacidad de una entidad en colusión para acumular demasiado poder de voto. La suposición de seguridad de Bittensor ahora es similar a la prueba de participación: ninguna entidad única (o cartel) controla >50 % del stake activo. Mientras eso se mantenga, la colusión es limitada porque los validadores honestos anularán las malas puntuaciones y los propietarios de subredes en colusión no pueden aumentar arbitrariamente sus propias recompensas. Finalmente, sobre la colusión entre propietarios de subredes y validadores (por ejemplo, un propietario de subred sobornando a los validadores para que califiquen altamente a los mineros de su subred), dTAO elimina el control directo de los validadores, reemplazándolo con decisiones de los poseedores de tokens. Es más difícil coludir con "el mercado" a menos que compres todo el suministro de tokens, en cuyo caso no es realmente colusión, es una toma de control. Así que la principal técnica anti-colusión de Bittensor es el consenso algorítmico (recorte de mediana) y la amplia distribución de tokens.

• Gensyn: La colusión en Gensyn probablemente involucraría a un resolutor y un verificador (o múltiples verificadores) coludiendo para engañar al sistema. Por ejemplo, un resolutor podría producir un resultado falso y un verificador en colusión podría intencionalmente no desafiarlo (o incluso atestiguar que es correcto si el protocolo pidiera a los verificadores que lo aprobaran). Para mitigar esto, el modelo de seguridad de Gensyn requiere al menos un verificador honesto. Si todos los verificadores están en colusión con el resolutor, entonces un mal resultado no es desafiado. Gensyn aborda esto fomentando muchos verificadores independientes (cualquiera puede verificar) y por la teoría de juegos de que un verificador podría ganar una gran recompensa rompiendo la colusión y desafiando (porque obtendrían el stake del resolutor). Esencialmente, incluso si hay un grupo que acuerda coludir, cada miembro tiene un incentivo para desertar y reclamar la recompensa por sí mismo; esta es una configuración clásica del Dilema del Prisionero. La esperanza es que esto mantenga los grupos de colusión pequeños o ineficaces. Otra colusión potencial es entre múltiples resolutores para subir los precios o monopolizar las tareas. Sin embargo, dado que los desarrolladores pueden elegir dónde publicar las tareas (y las tareas no son unidades idénticas que se puedan monopolizar fácilmente), la colusión de resolutores en el precio sería difícil de coordinar globalmente; cualquier resolutor que no esté en colusión podría pujar por debajo para ganar el trabajo. La dinámica del mercado abierto contrarresta la colusión de precios, asumiendo al menos algunos participantes competitivos. Un ángulo más: colusión de verificadores para perjudicar a los resolutores, por ejemplo, verificadores acusando falsamente a resolutores honestos para robar su stake. La prueba de fraude de Gensyn es binaria y en la cadena; una acusación falsa fallaría cuando la re-computación en la cadena no encuentre ningún error, y presumiblemente el verificador malicioso perdería algo (quizás un depósito o reputación). Así que una colusión de verificadores tratando de sabotear a los resolutores sería atrapada por el proceso de verificación del protocolo. En resumen, la arquitectura de Gensyn es robusta siempre que al menos una parte en cualquier conjunto en colusión tenga un incentivo para ser honesta, una propiedad de la verificación optimista similar a requerir un minero honesto en Bitcoin para eventualmente exponer un fraude. La colusión es teóricamente posible si un atacante pudiera controlar a todos los verificadores y resolutores en una tarea (como la mayoría de la red), pero entonces podrían simplemente hacer trampa sin necesidad de colusión per se. Los incentivos criptoeconómicos están dispuestos para hacer que mantener la colusión sea irracional.

• Cuckoo: La colusión en Cuckoo podría ocurrir de varias maneras:

1. Un coordinador coludiendo con mineros: por ejemplo, un coordinador podría asignar siempre tareas a un conjunto de mineros amigos y repartir las recompensas, ignorando a otros mineros honestos. Dado que los coordinadores tienen discreción en la programación de tareas, esto puede suceder. Sin embargo, si los mineros amigos son de baja calidad, los usuarios finales podrían notar un servicio lento o deficiente y marcharse, por lo que el coordinador está desincentivado de un favoritismo puro que perjudique la calidad. Si la colusión es para manipular las recompensas (digamos, enviando tareas falsas para dar tokens a los mineros), eso se detectaría en la cadena (muchas tareas con quizás entradas idénticas o sin un usuario real) y puede ser penalizado. La transparencia en la cadena de Cuckoo significa que cualquier patrón inusual podría ser señalado por la comunidad o el equipo central. Además, debido a que todos los participantes hacen stake, un anillo de coordinador-minero en colusión se arriesga a perder su stake si son atrapados abusando del sistema (por ejemplo, si la gobernanza decide aplicarles slashing por fraude).
2. Mineros coludiendo entre ellos: podrían compartir información o formar un cartel para, digamos, votarse todos entre sí en reputación o todos negarse a servir a un coordinador en particular para extraer tarifas más altas. Estos escenarios son menos probables: la votación de reputación la realizan los stakers (incluidos los usuarios), no los propios mineros votando entre sí. Y negarse a prestar servicio solo llevaría a los coordinadores a encontrar otros mineros o a dar la alarma. Dada la escala relativamente pequeña actual, cualquier colusión sería difícil de ocultar.
3. Colusión para manipular la gobernanza: grandes poseedores de CAI podrían coludir para aprobar propuestas a su favor (como establecer una tarifa exorbitante o redirigir la tesorería). Este es un riesgo en cualquier gobernanza de tokens. La mejor mitigación es distribuir ampliamente el token (el lanzamiento justo de Cuckoo dio el 51 % a la comunidad) y tener una supervisión comunitaria activa. Además, dado que Cuckoo se alejó de la L1, la gobernanza inmediata en la cadena podría ser limitada hasta que se reasienten en una nueva cadena; el equipo probablemente retiene un control multisig en el ínterin, lo que irónicamente previene la colusión de extraños maliciosos a expensas de ser centralizado temporalmente. En general, Cuckoo se apoya en la transparencia y el staking para manejar la colusión. Hay un elemento de confianza en que los coordinadores se comporten porque quieren atraer usuarios en un entorno competitivo. Si la colusión conduce a un servicio más deficiente o a una manipulación obvia de las recompensas, las partes interesadas pueden votar en contra o dejar de hacer stake en los malos actores, y la red puede aplicarles slashing o bloquearlos. La naturaleza bastante abierta (cualquiera puede convertirse en coordinador o minero si hace stake) significa que la colusión requeriría un gran esfuerzo coordinado que sería evidente. No está tan matemáticamente prevenida como en Bittensor o Gensyn, pero la combinación de stake económico y gobernanza comunitaria proporciona un control.

• Freeloading (Problemas de parasitismo): Esto se refiere a los participantes que intentan obtener recompensas sin contribuir con un valor equivalente, por ejemplo, un validador que en realidad no evalúa pero aún así gana, o un minero que copia las respuestas de otros en lugar de computar, o usuarios que farmean recompensas sin proporcionar una entrada útil.

• Bittensor: Un problema conocido de parasitismo en Bittensor es la "copia de pesos" por parte de validadores perezosos. Un validador podría simplemente copiar la opinión de la mayoría (o las puntuaciones de otro validador) en lugar de evaluar independientemente a los mineros. Al hacerlo, evitan el costo de ejecutar consultas de IA pero aún así obtienen recompensas si sus puntuaciones enviadas parecen alineadas con el consenso. Bittensor combate esto midiendo la alineación con el consenso y la contribución informativa de cada validador. Si un validador siempre copia a otros, puede que se alinee bien (por lo que no es penalizado fuertemente), pero no agrega ningún valor único. Los desarrolladores del protocolo han discutido dar mayores recompensas a los validadores que proporcionan evaluaciones precisas pero no puramente redundantes. Técnicas como la infusión de ruido (dar deliberadamente a los validadores consultas ligeramente diferentes) podrían obligarlos a trabajar realmente en lugar de copiar, aunque no está claro si eso está implementado. El artículo de Arxiv sugiere emisiones ponderadas por rendimiento y métodos de puntuación compuesta para vincular mejor el esfuerzo del validador con la recompensa. En cuanto a los mineros, un posible comportamiento de parasitismo sería si un minero consulta a otros mineros y retransmite la respuesta (una forma de plagio). El diseño de Bittensor (con consultas descentralizadas) podría permitir que el modelo de un minero llame a otros a través de su propia dendrita. Si un minero simplemente retransmite la respuesta de otro, un buen validador podría detectarlo porque la respuesta podría no coincidir consistentemente con las capacidades del modelo declaradas por el minero. Es difícil de detectar algorítmicamente, pero un minero que nunca computa resultados originales debería eventualmente obtener una puntuación baja en algunas consultas y perder reputación. Otro escenario de parasitismo eran los delegadores que ganaban recompensas sin hacer trabajo de IA. Eso es intencional (para involucrar a los poseedores de tokens), por lo que no es un ataque, pero sí significa que algunas emisiones de tokens van a personas que solo hicieron stake. Bittensor lo justifica como una alineación de incentivos, no como recompensas desperdiciadas. En resumen, Bittensor reconoce el problema de los validadores parásitos y está ajustando los incentivos (como dar puntuaciones de confianza de validador que impulsan a aquellos que no se desvían ni copian). Su solución es esencialmente recompensar el esfuerzo y la corrección de manera más explícita, para que no hacer nada o copiar ciegamente produzca menos TAO con el tiempo.

• Gensyn: En Gensyn, a los parásitos les resultaría difícil ganar, porque uno debe proporcionar cómputo o atrapar a alguien haciendo trampa para obtener tokens. Un resolutor no puede "fingir" el trabajo; tiene que presentar una prueba válida o arriesgarse al slashing. No hay mecanismo para recibir un pago sin hacer la tarea. Un verificador podría teóricamente permanecer inactivo y esperar que otros atrapen fraudes, pero entonces no ganaría nada (porque solo el que presenta la prueba de fraude obtiene la recompensa). Si demasiados verificadores intentan parasitar (no re-computando realmente las tareas), entonces un resolutor fraudulento podría pasar desapercibido porque nadie está verificando. El diseño de incentivos de Gensyn aborda esto con la recompensa jackpot: solo se necesita un verificador activo para atrapar a un tramposo y obtener un gran pago, por lo que es racional que al menos uno siempre haga el trabajo. Otros que no trabajan no dañan la red, excepto por ser inútiles; tampoco obtienen recompensa. Así que el sistema filtra naturalmente a los parásitos: solo aquellos verificadores que realmente verifican obtendrán ganancias a largo plazo (otros gastan recursos en nodos para nada o muy raramente obtienen una recompensa por casualidad). El protocolo también podría aleatorizar qué verificador tiene la oportunidad de desafiar para desalentar que todos los verificadores asuman que "alguien más lo hará". Dado que las tareas se pagan individualmente, no hay un análogo de "recompensas de staking sin trabajo" aparte de los incentivos de la testnet que son temporales. Un área a observar es la optimización de múltiples tareas: un resolutor podría intentar reutilizar el trabajo entre tareas o subcontratarlo en secreto a alguien más barato (como usar una nube centralizada), pero eso no es realmente un parasitismo dañino; si entregan resultados correctos a tiempo, no importa cómo lo hicieron. Eso es más como arbitraje que un ataque. En resumen, el diseño del mecanismo de Gensyn deja poco espacio para que los parásitos ganen, porque cada token distribuido corresponde a un trabajo hecho o a un tramposo castigado.

• Cuckoo: La fase inicial de Cuckoo creó inadvertidamente un problema de parasitismo: el airdrop y el staking de alto rendimiento atrajeron a usuarios que solo estaban allí para farmear tokens. Estos usuarios ciclaban tokens a través de faucets o manipulaban las tareas del airdrop (por ejemplo, usando continuamente prompts de prueba gratuitos o creando muchas cuentas para reclamar recompensas) sin contribuir al valor a largo plazo de la red. Cuckoo reconoció esto como un problema: esencialmente, la gente estaba "usando" la red no por el resultado de la IA, sino para obtener una ganancia especulativa. La decisión de terminar la cadena L1 y reenfocarse fue en parte para deshacerse de estas desalineaciones de incentivos. Al vincular las futuras recompensas de tokens al uso real (es decir, ganas porque el servicio está siendo utilizado por clientes que pagan), el atractivo del parasitismo disminuye. También existe un escenario de parasitismo por parte de los mineros: un minero podría unirse, recibir tareas y de alguna manera no realizarlas pero aún así reclamar la recompensa. Sin embargo, el coordinador está verificando los resultados; si un minero no devuelve ninguna salida o una salida incorrecta, el coordinador no lo contará como una tarea completada, por lo que el minero no recibiría pago. Los mineros también podrían intentar seleccionar las tareas fáciles y abandonar las difíciles (por ejemplo, si algunos prompts son más lentos, un minero podría desconectarse para evitarlos). Esto podría ser un problema, pero los coordinadores pueden notar la fiabilidad de un minero. Si un minero se desconecta con frecuencia, el coordinador puede dejar de asignarle tareas o aplicar slashing a su stake (si existe tal mecanismo o simplemente no recompensarlo). El parasitismo de los usuarios: dado que muchos servicios de IA tienen pruebas gratuitas, un usuario podría enviar spam de solicitudes para obtener resultados sin pagar (si hay un modelo subsidiado). Eso no es tanto un problema a nivel de protocolo como a nivel de servicio; cada coordinador puede decidir cómo manejar el uso gratuito (por ejemplo, requiriendo un pequeño pago o limitando la velocidad). Debido a que Cuckoo inicialmente regaló cosas (como generaciones de imágenes de IA gratuitas para atraer usuarios), algunos se aprovecharon, pero eso era parte del marketing de crecimiento esperado. A medida que esas promociones terminen, los usuarios tendrán que pagar, por lo que no habrá almuerzo gratis que explotar. En general, la nueva estrategia de Cuckoo de mapear la distribución de tokens a la utilidad real está explícitamente dirigida a eliminar el problema del parasitismo de "minar tokens por hacer bucles sin sentido".

• Envenenamiento de Datos o Modelos: Esto se refiere a la introducción maliciosa de datos o comportamientos incorrectos de tal manera que los modelos de IA se degradan o los resultados se manipulan, así como problemas de contenido dañino o sesgado que se contribuye.

• Bittensor: El envenenamiento de datos en Bittensor significaría que un minero da intencionalmente respuestas incorrectas o dañinas, o que los validadores evalúan a propósito las buenas respuestas como malas. Si un minero produce basura o contenido malicioso de manera consistente, los validadores le darán puntuaciones bajas, y ese minero ganará poco y eventualmente se retirará; el incentivo económico es proporcionar calidad, por lo que "envenenar" a otros no produce ningún beneficio para el atacante (a menos que su objetivo sea puramente el sabotaje a su propio costo). ¿Podría un minero malicioso envenenar a otros? En Bittensor, los mineros no se entrenan directamente entre sí (al menos no por diseño; no hay un modelo global que se esté actualizando que pueda ser envenenado). El modelo de cada minero es independiente. Sí aprenden en el sentido de que un minero podría tomar muestras interesantes de otros para ajustarse, pero eso es completamente opcional y depende de cada uno. Si un actor malicioso enviara spam de respuestas sin sentido, los validadores honestos lo filtrarían (le darían una puntuación baja), por lo que no influiría significativamente en el proceso de entrenamiento de ningún minero honesto (además, un minero probablemente usaría el conocimiento de sus pares con alta puntuación, no de los de baja puntuación). Así que el envenenamiento de datos clásico (inyectar datos de entrenamiento malos para corromper un modelo) es mínimo en la configuración actual de Bittensor. El riesgo más relevante es la manipulación de la respuesta del modelo: por ejemplo, un minero que produce contenido sutilmente sesgado o peligroso que no es obvio para los validadores. Sin embargo, dado que los validadores también son diseñados por humanos o al menos agentes algorítmicos, es probable que se detecte la toxicidad o el error flagrante (algunas subredes incluso podrían tener validadores de IA que verifiquen contenido inseguro). Un escenario del peor de los casos es si un atacante de alguna manera tuviera la mayoría de los validadores y mineros coludiendo para impulsar una cierta salida incorrecta como "correcta"; entonces podrían sesgar el consenso de la red sobre las respuestas (como todos los validadores en colusión votando a favor de una respuesta maliciosa). Pero para que un usuario externo se vea perjudicado por eso, tendría que consultar realmente la red y confiar en la salida. Bittensor todavía está en una fase en la que está construyendo capacidad, no siendo ampliamente utilizado para consultas críticas por parte de los usuarios finales. Para cuando lo sea, se espera que tenga filtrado de contenido y diversidad de validadores para mitigar tales riesgos. Por el lado del validador, un validador malicioso podría alimentar evaluaciones envenenadas, por ejemplo, votando consistentemente en contra de un cierto minero honesto para eliminar la competencia. Con suficiente stake, podrían tener éxito en expulsar a ese minero (si las recompensas del minero caen tan bajo que se van). Este es un ataque al mecanismo de incentivos. Nuevamente, si no son mayoría, el recorte de la mediana frustrará a un validador atípico. Si son mayoría, se fusiona con el escenario de colusión/51 %: cualquier mayoría puede reescribir las reglas. La solución vuelve a la descentralización: evitar que una sola entidad domine. En resumen, el diseño de Bittensor inherentemente penaliza las contribuciones de datos/modelos envenenados a través de su sistema de puntuación: las malas contribuciones obtienen un peso bajo y, por lo tanto, una baja recompensa. No hay un repositorio de modelos permanente que envenenar; todo es dinámico y se evalúa continuamente. Esto proporciona resiliencia: la red puede "olvidar" o ignorar gradualmente a los malos actores a medida que sus contribuciones son filtradas por los validadores.

• Gensyn: Si un resolutor quisiera envenenar un modelo que se está entrenando (como introducir una puerta trasera o un sesgo durante el entrenamiento), podría intentar hacerlo de forma encubierta. El protocolo de Gensyn verificaría que el entrenamiento procedió de acuerdo con el algoritmo especificado (pasos de descenso de gradiente estocástico, etc.), pero no necesariamente detectaría si el resolutor introdujo un sutil activador de puerta trasera que no aparece en las métricas de validación normales. Este es un problema más insidioso: no es un fallo de la computación, es una manipulación dentro de los grados de libertad permitidos del entrenamiento (como ajustar los pesos hacia una frase activadora). Detectar eso es un problema de investigación activo en seguridad de ML. Gensyn no tiene un mecanismo especial para el envenenamiento de modelos más allá del hecho de que el solicitante podría evaluar el modelo final en un conjunto de prueba de su elección. Un solicitante inteligente siempre debería probar el modelo devuelto; si encuentra que falla en algunas entradas o tiene un comportamiento extraño, puede disputar el resultado o negarse a pagar. Quizás el protocolo podría permitir que un solicitante especifique ciertos criterios de aceptación (como "el modelo debe alcanzar al menos una precisión X en este conjunto de prueba secreto") y si el resultado del resolutor falla, el resolutor no recibe el pago completo. Esto disuadiría el envenenamiento porque el atacante no cumpliría los criterios de evaluación. Sin embargo, si el veneno no afecta la precisión en las pruebas normales, podría pasar desapercibido. Los verificadores en Gensyn solo comprueban la integridad de la computación, no la calidad del modelo, por lo que no detectarían un sobreajuste intencional o troyanos siempre que los registros de entrenamiento parezcan válidos. Por lo tanto, esto sigue siendo un problema de confianza a nivel de tarea: el solicitante tiene que confiar en que el resolutor no envenenará el modelo o usar métodos como el ensamblaje de múltiples resultados de entrenamiento de diferentes resolutores para diluir la influencia de un solo resolutor. Otro ángulo es el envenenamiento de datos: si el solicitante proporciona datos de entrenamiento, un resolutor malicioso podría ignorar esos datos y entrenar con otra cosa o agregar datos basura. Pero eso probablemente reduciría la precisión, lo que el solicitante notaría en el rendimiento del modelo de salida. El resolutor entonces no recibiría el pago completo (ya que presumiblemente quieren cumplir un objetivo de rendimiento). Así que el envenenamiento que degrada el rendimiento es contraproducente para la recompensa del resolutor. Solo un veneno que es neutral en rendimiento pero malicioso (una puerta trasera) es un peligro real, y eso está fuera del alcance de la verificación típica de blockchain; es un desafío de seguridad del aprendizaje automático. La mejor mitigación de Gensyn es probablemente social: usar modelos de reputación conocida, tener múltiples ejecuciones de entrenamiento, usar herramientas de código abierto. En tareas de inferencia (si Gensyn también se usa para trabajos de inferencia), un resolutor en colusión podría devolver salidas incorrectas que sesguen una cierta respuesta. Pero los verificadores detectarían las salidas incorrectas si ejecutan el mismo modelo, por lo que eso es menos un envenenamiento y más simplemente hacer trampa, lo que las pruebas de fraude abordan. En resumen, Gensyn asegura el proceso, no la intención. Asegura que el entrenamiento/inferencia se realizó correctamente, pero no que el resultado sea bueno o libre de maldades ocultas. Eso sigue siendo un problema abierto, y el whitepaper de Gensyn probablemente no lo resuelve por completo todavía (pocos lo hacen).

• Cuckoo: Dado que Cuckoo actualmente se enfoca en la inferencia (servir modelos existentes), el riesgo de envenenamiento de datos/modelos se limita relativamente a la manipulación de la salida o al envenenamiento de contenido. Un minero malicioso podría intentar manipular el modelo que se le da para ejecutar; por ejemplo, si se le proporciona un punto de control de Stable Diffusion, podría cambiarlo por un modelo diferente que quizás inserte alguna marca de agua sutil o publicidad en cada imagen. Sin embargo, el coordinador (que es el propietario del modelo) típicamente envía tareas con una expectativa del formato de salida; si un minero devuelve salidas fuera de especificación de manera consistente, el coordinador marcará y prohibirá a ese minero. Además, los mineros no pueden modificar fácilmente un modelo sin afectar notablemente sus salidas. Otro escenario es si Cuckoo introduce modelos entrenados por la comunidad: entonces los mineros o proveedores de datos podrían intentar envenenar los datos de entrenamiento (por ejemplo, introduciendo muchas etiquetas incorrectas o texto sesgado). Cuckoo necesitaría implementar la validación de datos de crowdsourcing o la ponderación de los contribuyentes. Esto aún no es una característica, pero el interés del equipo en la IA personalizada (como su mención de un entrenador de vida de IA o aplicaciones de aprendizaje) significa que eventualmente podrían manejar datos de entrenamiento proporcionados por el usuario, lo que requerirá verificaciones cuidadosas. En cuanto a la seguridad del contenido, dado que los mineros de Cuckoo realizan inferencias, uno podría preocuparse de que produzcan contenido dañino incluso si el modelo normalmente no lo haría. Pero los mineros no tienen un incentivo para alterar las salidas arbitrariamente; se les paga por la computación correcta, no por la creatividad. En todo caso, un minero malicioso podría saltarse la computación completa para ahorrar tiempo (por ejemplo, devolver una imagen borrosa o una respuesta genérica). El coordinador o el usuario verían eso y calificarían negativamente a ese minero (y probablemente no pagarían por esa tarea). La privacidad es otra faceta: un minero malicioso podría filtrar o registrar datos del usuario (como si un usuario ingresara texto o imágenes sensibles). Esto no es envenenamiento, pero es un ataque a la confidencialidad. La postura de privacidad de Cuckoo es que está explorando métodos de preservación de la privacidad (la mención de una VPN que preserva la privacidad en el ecosistema sugiere un enfoque futuro). Podrían incorporar técnicas como enclaves seguros o inferencia dividida para mantener los datos privados de los mineros. Aún no está implementado, pero es una consideración conocida. Finalmente, el blog de Cuckoo enfatiza la verificación efectiva de los resultados del modelo y la garantía de una operación segura del modelo descentralizado como clave para hacer viable la tokenización de modelos. Esto indica que son conscientes de que para descentralizar verdaderamente la IA, uno debe protegerse contra cosas como salidas envenenadas o modelos que funcionan mal. Posiblemente, tienen la intención de usar una combinación de incentivos criptoeconómicos (slashing de stake para malos actores) y sistemas de calificación de usuarios (los usuarios pueden marcar salidas incorrectas, y esos mineros pierden reputación). El sistema de reputación puede ayudar aquí: si un minero devuelve incluso un resultado obviamente malicioso o incorrecto, los usuarios/coordinadores pueden votarlos negativamente, afectando fuertemente su capacidad de ganancia futura. Sabiendo esto, los mineros están incentivados a ser consistentemente correctos y no introducir ningún veneno. En esencia, Cuckoo se basa en la confianza pero verifica: es más tradicional en el sentido de que si alguien se comporta mal, lo identificas y lo eliminas (con la pérdida de stake como castigo). Todavía no tiene defensas especializadas para el envenenamiento sutil de modelos, pero la estructura de tener propietarios de aplicaciones específicos (coordinadores) a cargo agrega una capa de supervisión; esos propietarios estarán motivados para asegurarse de que nada comprometa la integridad de su modelo, ya que sus propios ingresos y reputación dependen de ello.

En conclusión, si bien las redes de IA descentralizadas introducen nuevas superficies de ataque, también despliegan una mezcla de defensas criptográficas, de teoría de juegos y de gobernanza comunitaria: La resistencia Sybil se maneja en gran medida requiriendo una participación económica para la participación. La resistencia a la colusión proviene de la alineación de incentivos (el comportamiento honesto es más rentable) y mecanismos de consenso que limitan el impacto de pequeños grupos en colusión. La prevención del parasitismo (freerider) se logra vinculando estrechamente las recompensas con el trabajo útil real y penalizando o eliminando a aquellos que no contribuyen en nada. El envenenamiento y ataques relacionados siguen siendo desafiantes, pero los sistemas mitigan los casos flagrantes a través de la evaluación continua y la capacidad de aplicar slashing o expulsar a los actores maliciosos. Estas plataformas están investigando e iterando activamente en estos diseños, como lo demuestran los continuos ajustes de Bittensor a Yuma y dTAO, y el cambio de Cuckoo en la economía de sus tokens, para garantizar un ecosistema de IA descentralizado, seguro y autosostenible.

Evaluación Comparativa​

Para resaltar las diferencias y similitudes de Bittensor, Gensyn y Cuckoo AI, la siguiente tabla proporciona una comparación lado a lado a través de dimensiones clave:

Tabla: Comparación de características de Bittensor, Gensyn y Cuckoo AI en arquitectura, enfoque, roles, consenso, tokens, tokenización de activos, gobernanza, incentivos y seguridad.

El Valor Máximo Extraíble (MEV) se refiere al beneficio que un "insider" de la blockchain (minero/validador u otro actor privilegiado) puede obtener al reordenar, incluir o excluir arbitrariamente transacciones en un bloque. La extracción de MEV sin control puede llevar a una ordenación injusta de transacciones, altas comisiones (debido a las subastas de gas prioritarias) y la centralización del poder en la producción de bloques. Han surgido varios protocolos para suprimir el MEV perjudicial o aplicar una ordenación justa de las transacciones. Este informe compara cuatro enfoques prominentes: Flashbots v2 (el sistema MEV-Boost de Flashbots post-Merge para Ethereum), SUAVE (la próxima Subasta Única Unificadora para la Expresión de Valor de Flashbots), Anoma (una arquitectura centrada en intenciones que reimagina cómo se emparejan y ordenan las transacciones) y Skip Protocol (un conjunto de herramientas basado en Cosmos para la gestión soberana de MEV dentro del protocolo). Examinamos cada uno en términos de sus algoritmos de encolado/ordenación de transacciones, mecanismos de mitigación o extracción de MEV, modelos de incentivos, características de cumplimiento y neutralidad, arquitectura técnica (consenso y criptografía) y progreso de desarrollo. Se proporcionan resúmenes estructurados y una tabla comparativa para destacar sus fortalezas y debilidades en la búsqueda de la equidad y la reducción de las externalidades negativas del MEV.

Flashbots v2 (MEV-Boost y BuilderNet en Ethereum)​

Flashbots v2 denota el ecosistema actual de Flashbots en Ethereum después de la transición a Proof-of-Stake, centrado en MEV-Boost e iniciativas recientes como BuilderNet. Flashbots v2 se basa en el paradigma de separación proponente/constructor (PBS) para abrir la construcción de bloques a un mercado competitivo de constructores mientras protege a los usuarios de Ethereum de los ataques de MEV en el mempool público.

• Ordenación de Transacciones (Encolado y Algoritmo): Flashbots MEV-Boost introduce un mercado de construcción de bloques fuera de la cadena. Los validadores (proponentes) externalizan la construcción de bloques a constructores especializados a través de un relay, en lugar de ordenar las transacciones localmente. Múltiples constructores compiten para proporcionar el bloque que más paga, y el validador firma a ciegas la cabecera del bloque con la oferta más alta (un enfoque PBS). Este diseño reemplaza eficazmente la ordenación de 'primero en llegar, primero en ser servido' del mempool público con una subasta a sobre cerrado para bloques enteros. Los constructores determinan internamente la ordenación de las transacciones para maximizar los pagos totales (incluidas las oportunidades de MEV), prefiriendo típicamente bundles con arbitrajes rentables o liquidaciones en la parte superior del bloque. Al usar MEV-Boost, Ethereum evitó las caóticas subastas de gas prioritarias (PGA) que anteriormente determinaban la ordenación; en lugar de que los usuarios y bots pujaran a través de las comisiones de gas en tiempo real (aumentando la congestión), MEV-Boost centraliza la ordenación por bloque al constructor más competitivo. Las colas de transacciones son, por lo tanto, gestionadas de forma privada por los constructores, quienes pueden ver los bundles o transacciones entrantes y organizarlos para obtener el máximo beneficio. Una desventaja es que esta ordenación impulsada por el beneficio no impone inherentemente la "equidad" para los usuarios; por ejemplo, los constructores aún pueden incluir flujos de órdenes tóxicos como los ataques sándwich si son rentables, pero sí optimiza la eficiencia al extraer MEV a través de una subasta controlada en lugar de guerras de gas ad-hoc. Desarrollos recientes han buscado hacer la ordenación más neutral: por ejemplo, la nueva BuilderNet de Flashbots (lanzada a finales de 2024) permite que múltiples constructores colaboradores compartan el flujo de órdenes y construyan bloques colectivamente en un Entorno de Ejecución Confiable (TEE), introduciendo reglas de ordenación verificables para mejorar la equidad. Esto aleja la ordenación de bloques de un único constructor centralizado hacia una red de construcción de bloques descentralizada con reglas que pueden ser auditadas para garantizar la neutralidad.

• Mecanismos de Supresión vs. Extracción de MEV: Flashbots v2 facilita principalmente la extracción de MEV en una forma más benigna en lugar de eliminarlo. El sistema original de Flashbots (v1) en 2021 permitía a los searchers enviar bundles (conjuntos de transacciones preferidas) directamente a los mineros, lo que suprimía las externalidades perjudiciales (sin front-running público, sin transacciones fallidas debido a la competencia) mientras seguía extrayendo MEV. En la era de MEV-Boost, el MEV es extraído por constructores que agrupan transacciones rentables, pero se reduce la competencia de suma negativa: los searchers ya no saturan el mempool con transacciones competidoras y comisiones de gas exorbitantes, lo que mitiga la congestión de la red y las comisiones excesivas para los usuarios. Flashbots v2 también proporciona herramientas de mitigación de MEV para los usuarios: por ejemplo, Flashbots Protect RPC permite a los usuarios enviar transacciones de forma privada a un relay, evitando el front-running en el mempool público (nadie puede ver o reordenar la transacción antes de su inclusión). Otra iniciativa, MEV-Share, permite a los usuarios compartir la información justa sobre sus transacciones para atraer ofertas de MEV mientras capturan una parte del valor para sí mismos. Sin embargo, Flashbots v2 no "previene" el MEV como los sándwiches o el arbitraje; canaliza estas actividades a través de una subasta eficiente que podría decirse que democratiza quién puede extraer el MEV. Recientemente, el diseño de BuilderNet tiene el objetivo explícito de "neutralizar los juegos de flujo de órdenes de suma negativa" y compartir el MEV con la comunidad a través de reglas de reembolso en la cadena. BuilderNet calcula los reembolsos pagados a los proveedores de flujo de órdenes de transacciones (como billeteras o DApps) en proporción al MEV que sus transacciones generaron, redistribuyendo el valor que de otro modo sería puro beneficio para los constructores. En resumen, Flashbots v2 maximiza la eficiencia de la extracción de MEV (asegurando que casi todo el valor extraíble en un bloque sea capturado) mientras introduce medidas para frenar las peores externalidades y devolver algo de valor a los usuarios. No llega a imponer una ordenación justa (las transacciones todavía se ordenan por el beneficio del constructor), pero a través del envío privado, la construcción multipartita y los reembolsos, suprime el daño negativo al usuario (como el slippage por front-running y los efectos de censura) tanto como sea posible dentro del modelo de subasta.

• Estructura de Incentivos Económicos: Flashbots v2 alinea los incentivos entre validadores, constructores y searchers a través de la subasta PBS. Los validadores se benefician al externalizar la producción de bloques: simplemente aceptan la oferta más alta y reciben el monto de la oferta (además de las recompensas de consenso), lo que aumentó drásticamente la parte del MEV que va a los validadores en comparación con la era en la que los mineros no tenían tales subastas. Los constructores están incentivados a competir entre sí encontrando la ordenación más rentable de las transacciones (a menudo incorporando estrategias de los searchers), y se quedan con cualquier beneficio de MEV que quede después de pagar la oferta del validador. En la práctica, la competencia obliga a los constructores a pagar la mayor parte del MEV a los validadores (a menudo >90% del beneficio), quedándose solo con un margen delgado. Los searchers (que ahora interactúan con los constructores a través de bundles o transacciones directas) todavía ganan al descubrir oportunidades de MEV (arbitraje, liquidación, etc.), pero deben ofrecer la mayor parte de su beneficio para ganar la inclusión; en efecto, los beneficios de los searchers se transfieren a los validadores a través de las ofertas de los constructores. Este equilibrio competitivo maximiza los ingresos totales de la red (beneficiando a los validadores/stakers) pero reduce los márgenes de los searchers individuales. Flashbots v2, por lo tanto, desincentiva los acuerdos exclusivos: cualquier searcher o constructor con una estrategia de MEV privada está incentivado a ofertarla a través del relay abierto para evitar ser superado, lo que conduce a un mercado más abierto. La introducción de BuilderNet añade un incentivo para los originadores de flujo de órdenes (como DEXs o billeteras): al darles reembolsos por el MEV que crean sus transacciones, anima a los usuarios y aplicaciones a enviar su flujo de órdenes al ecosistema de BuilderNet. Este mecanismo alinea a los usuarios con el sistema: en lugar de ser adversarios (usuarios vs. extractores de MEV), los usuarios comparten el MEV, por lo que están más dispuestos a participar en la subasta de manera justa. En general, la economía de Flashbots v2 favorece la colaboración sobre la competencia en la construcción de bloques: los validadores obtienen ingresos máximos sin riesgo, los constructores compiten en la calidad de la ejecución, y los searchers innovan para encontrar MEV pero renuncian a la mayoría de los beneficios para ganar las ofertas, mientras que los usuarios obtienen protección y posiblemente reembolsos.

• Cumplimiento y Resistencia a la Censura: El cumplimiento normativo se convirtió en un tema polémico para Flashbots después del Merge de Ethereum. El relay predeterminado de Flashbots implementó inicialmente el cumplimiento de las sanciones de la OFAC (censurando ciertas transacciones como las de Tornado Cash), lo que llevó a que aproximadamente el 80% de los bloques de Ethereum a finales de 2022 fueran "compatibles con la OFAC" y generó preocupaciones sobre centralización/censura en la comunidad. Flashbots v2 abordó esto fomentando un ecosistema de múltiples relays donde los validadores pueden elegir relays no censuradores (por ejemplo, UltraSound, Agnostic) o incluso ejecutar los suyos. Flashbots hizo público el código de su relay a mediados de 2022 para fomentar la competencia global de relays y la transparencia. Además, MEV-Boost v1.4 introdujo características como un ajuste de oferta mínima para que los proponentes pudieran rechazar ofertas bajas de constructores censuradores y recurrir a bloques locales, sacrificando algo de beneficio por la inclusión de todas las transacciones. Esta característica dio explícitamente a los validadores una forma de mejorar la resistencia a la censura de Ethereum a un pequeño costo. A finales de 2024, Flashbots dio un paso más al descontinuar su propio constructor centralizado en favor de BuilderNet, una red colaborativa destinada a ser "incensurable y neutral". BuilderNet utiliza TEEs (Intel SGX) para mantener el flujo de órdenes de transacciones encriptado y se compromete verificablemente a una regla de ordenación, lo que puede ayudar a evitar que los constructores individuales censuren transacciones específicas. Con múltiples participantes construyendo bloques conjuntamente dentro de enclaves seguros, ninguna parte puede excluir fácilmente una transacción sin ser detectada. En resumen, Flashbots v2 ha evolucionado de un único relay (e inicialmente censurador) a una infraestructura más descentralizada con participación abierta y objetivos explícitos de neutralidad. El cumplimiento se deja a las políticas de los relays/constructores individuales (y los validadores pueden elegir), en lugar de ser impuesto por el protocolo. La trayectoria es hacia la neutralidad creíble: eliminar cualquier punto de estrangulamiento controlado por Flashbots que pueda ser presionado por los reguladores. Flashbots se ha comprometido públicamente a eliminarse a sí mismo como operador central y a descentralizar todos los aspectos de la cadena de suministro de MEV a largo plazo.

• Arquitectura Técnica y Criptografía: Flashbots v2 opera de forma híbrida, fuera de la cadena y en el protocolo. La subasta principal (MEV-Boost) ocurre fuera de la cadena a través de la red de constructores y relays, pero se conecta directamente al consenso de Ethereum: los validadores ejecutan un cliente sidecar (mev-boost) que interactúa con los relays utilizando la API de Constructor estandarizada. En cuanto al consenso, Ethereum todavía utiliza PoS estándar (Casper/Hotstuff); MEV-Boost no altera las reglas de consenso de L1, solo cambia quién ensambla el bloque. Inicialmente, la subasta de Flashbots requería confiar en que el relay y el constructor no robarían transacciones ni censurarían; no había garantías criptográficas (el sistema se basaba en el incentivo económico de que los constructores deben entregar una carga útil válida que coincida con su oferta o pierden el espacio). Con el tiempo, Flashbots v2 ha integrado más tecnología de seguridad. La introducción de Entornos de Ejecución Confiable (TEE) a través de BuilderNet es un cambio arquitectónico notable: los constructores se ejecutan dentro de enclaves SGX para que incluso el operador del constructor no pueda ver el flujo de órdenes de transacciones en bruto (evitando que lo filtren o le hagan front-running). Estos enclaves siguen colectivamente un protocolo para producir bloques, lo que puede permitir una equidad verificable (por ejemplo, demostrar que las transacciones se ordenaron según una regla comprometida o que ninguna entidad no autorizada las vio antes de la inclusión). Aunque se utiliza SGX (un enfoque basado en hardware), la investigación de Flashbots también está explorando primitivas criptográficas puras, como el cifrado de umbral para la privacidad del mempool y la computación segura multipartita, para eventualmente reemplazar o complementar los TEEs y reducir aún más la confianza. La pila de software de Flashbots v2 incluye clientes personalizados como MEV-geth (ahora obsoleto) y constructores basados en Rust (por ejemplo, rbuilder), y se adhiere a las especificaciones de constructor de Ethereum para la interoperabilidad. En resumen, la arquitectura es modular: una red de relays, constructores y ahora enclaves, que se sitúa entre los usuarios y los proponentes de Ethereum. Prioriza el rendimiento (ofertas rápidas, entrega de bloques) y está añadiendo gradualmente garantías criptográficas de privacidad y ordenación justa. No se introduce ningún nuevo algoritmo de consenso; en su lugar, Flashbots v2 funciona junto con el consenso de Ethereum, evolucionando el pipeline de producción de bloques en lugar de las reglas de consenso.

• Hoja de Ruta de Desarrollo y Hitos: Flashbots ha progresado a través de fases iterativas. Flashbots v1 (2020–2021) implicó el lanzamiento de MEV-geth y las primeras subastas de bundles fuera de la cadena con mineros. A mediados de 2021, más del 80% del hashrate de Ethereum ejecutaba MEV-geth de Flashbots, confirmando la adopción del enfoque. Flashbots v2 (2022) fue concebido antes del Merge: en noviembre de 2021, Flashbots publicó la arquitectura MEV-Boost para Ethereum PoS. Después de que Ethereum cambiara a PoS (15 de septiembre de 2022), MEV-Boost se activó en cuestión de días y alcanzó rápidamente la adopción mayoritaria por parte de los validadores. Hitos posteriores incluyeron la publicación del código del relay (agosto de 2022) y del constructor de bloques interno de Flashbots (noviembre de 2022) para estimular la competencia. A finales de 2022, Flashbots también añadió características centradas en la resistencia a la censura y la resiliencia (por ejemplo, min-bid para proponentes) y escribió sobre el "Costo de la Resiliencia" para alentar a los validadores a preferir a veces la inclusión sobre el beneficio. A lo largo de 2023, mejorar la descentralización de los constructores se convirtió en un enfoque clave: Flashbots lanzó "rbuilder" (un constructor de Rust de alto rendimiento) en julio de 2024 como una implementación de referencia para reducir la barrera para nuevos constructores. Finalmente, a finales de 2024, Flashbots lanzó BuilderNet (alfa) en colaboración con socios (Beaverbuild, Nethermind). En diciembre de 2024, Flashbots cerró su constructor centralizado y migró todo el flujo de órdenes a BuilderNet, un paso significativo hacia la descentralización. A principios de 2025, se lanzó BuilderNet v1.2 con mejoras de seguridad e incorporación (incluidas compilaciones de enclaves reproducibles). Estos hitos marcan la transición de Flashbots de una solución centralizada conveniente a un protocolo más abierto y gestionado por la comunidad. Mirando hacia el futuro, Flashbots está convergiendo con su visión de próxima generación (SUAVE) para descentralizar completamente la capa de construcción de bloques e incorporar tecnología de privacidad avanzada. Muchas lecciones de Flashbots v2 (por ejemplo, la necesidad de neutralidad, el alcance multicadena y la inclusión de los usuarios en las recompensas de MEV) informan directamente la hoja de ruta de SUAVE.

SUAVE (Subasta Única Unificadora para la Expresión de Valor de Flashbots)​

SUAVE es el ambicioso siguiente protocolo de Flashbots, diseñado como un mercado de MEV descentralizado y multidominio y una capa de secuenciación justa de transacciones. Su objetivo es desvincular los mempools y la construcción de bloques de las blockchains individuales y proporcionar una plataforma unificada donde los usuarios expresan preferencias, una red descentralizada ejecuta transacciones de manera óptima y los constructores de bloques producen bloques para muchas cadenas de una manera creíblemente neutral. En resumen, SUAVE busca maximizar la extracción total de valor mientras devuelve valor a los usuarios y preserva la descentralización de la blockchain. Flashbots introdujo SUAVE a finales de 2022 como "el futuro del MEV" y lo ha estado desarrollando de forma abierta desde entonces.

• Encolado y Ordenación de Transacciones: Desde un alto nivel, SUAVE funciona como una red de blockchain independiente que otras cadenas pueden usar como un mempool y constructor de bloques plug-and-play. En lugar de que las transacciones se pongan en cola en el mempool de cada cadena y sean ordenadas por mineros o validadores locales, los usuarios pueden enviar sus transacciones (o, más generalmente, preferencias) al mempool de la red SUAVE. El mempool de SUAVE sirve entonces como un pool de subasta global de preferencias de todas las cadenas participantes. La ordenación de las transacciones se determina a través de esta subasta y la posterior optimización de la ejecución. Específicamente, SUAVE introduce el concepto de preferencias: el envío de un usuario no es solo una transacción en bruto para una cadena, sino que puede codificar un objetivo o un intercambio condicional (posiblemente abarcando múltiples cadenas) y una oferta asociada que el usuario está dispuesto a pagar por su cumplimiento. El algoritmo de ordenación/encolado en SUAVE tiene múltiples etapas: Primero, los usuarios publican sus preferencias en el mempool de SUAVE (el "Entorno de Preferencia Universal"), que agrega todas las órdenes de forma privada y global. A continuación, nodos especializados llamados ejecutores (análogos a los searchers/solvers) monitorean este mempool y compiten en un Mercado de Ejecución Óptima para cumplir estas preferencias. Efectivamente, "ponen en cola" las transacciones encontrando coincidencias u ordenaciones de ejecución óptimas para ellas. Finalmente, SUAVE produce salidas de bloque para cada cadena conectada a través de una capa de Construcción de Bloques Descentralizada: muchos constructores (o ejecutores de SUAVE actuando como constructores) colaboran para construir bloques utilizando el orden de transacciones (ahora optimizado) derivado de las preferencias de los usuarios. En términos prácticos, la ordenación de SUAVE es flexible y dirigida por el usuario: un usuario puede especificar condiciones como "ejecutar mi operación solo si el precio < X" o incluso expresar una intención abstracta ("intercambiar token A por B a la mejor tasa en 1 minuto") en lugar de una transacción estricta. El sistema pone en cola estas intenciones hasta que un ejecutor encuentra una ordenación o coincidencia óptima (posiblemente agrupándola con otras). Debido a que SUAVE es agnóstico a la blockchain, puede coordinar la ordenación entre cadenas (evitando escenarios donde los arbitrajes entre cadenas se pierden debido a mempools separados y no coordinados). En esencia, SUAVE implementa una subasta global de MEV: todos los participantes comparten una capa de secuenciación, que ordena las transacciones basándose en preferencias y ofertas agregadas en lugar de un simple orden de llegada o precio del gas. Esto tiene el efecto de nivelar el campo de juego: todo el flujo de órdenes pasa por una cola transparente (aunque encriptada para la privacidad, como se discute a continuación) en lugar de acuerdos exclusivos o mempools privados. El algoritmo de ordenación de SUAVE todavía se está refinando, pero es probable que involucre subastas por lotes que preservan la privacidad y algoritmos de emparejamiento para que se puedan lograr resultados "justos" (como el máximo excedente total o precios óptimos para el usuario) en lugar de un puro "primero en llegar, primero en ser servido". Notablemente, SUAVE tiene la intención de evitar que cualquier actor único manipule la ordenación: es nativo de Ethereum y consciente del MEV, con un mempool encriptado que prioriza la privacidad y protege contra cualquier punto central de control. En resumen, la cola de SUAVE es un pool de flujo de órdenes unificado donde la ordenación está determinada por una combinación de ofertas de los usuarios, estrategia de los ejecutores y (eventualmente) restricciones de equidad criptográficas, en lugar de por proponentes de bloques compitiendo por la prioridad.

• Mecanismos de Supresión/Extracción de MEV: La filosofía de SUAVE es que el MEV puede ser aprovechado en beneficio de los usuarios y para la seguridad de la red si se hace de manera cooperativa y descentralizada. En lugar de ignorar el MEV o dejar que se concentre en unas pocas manos, SUAVE explícitamente saca a la luz las oportunidades de MEV y devuelve el valor a quienes lo crean (los usuarios) tanto como sea posible. El mecanismo principal es la subasta de flujo de órdenes: cada vez que la transacción (preferencia) de un usuario tiene MEV —por ejemplo, podría ser objeto de back-running para obtener un beneficio— SUAVE llevará a cabo una subasta entre los ejecutores (searchers) por el derecho a ejecutar esa oportunidad de MEV. Los searchers (ejecutores) pujan prometiendo una parte del beneficio de vuelta al usuario como pago (este es el campo de "oferta" del usuario en su preferencia, que va a quien la cumpla). El resultado es una extracción de MEV competitiva que dirige los ingresos hacia el usuario en lugar del extractor. Por ejemplo, si una gran operación DEX de un usuario crea una oportunidad de arbitraje de 100 $, los searchers en SUAVE podrían reducir el beneficio ofreciendo, digamos, 90$ de vuelta al usuario como reembolso, quedándose solo con 10 $. Esto suprime los aspectos negativos del MEV como la extracción de valor del usuario, y convierte el MEV en un beneficio para el usuario (los usuarios obtienen efectivamente una mejora de precio o reembolsos). El diseño de SUAVE también suprime el front-running y otros MEV maliciosos: las transacciones en el mempool de SUAVE pueden mantenerse encriptadas hasta que se esté construyendo un bloque (usando enclaves SGX inicialmente, y avanzando hacia la criptografía de umbral). Esto significa que ningún actor externo puede ver las transacciones pendientes para hacerles front-running; solo cuando se recopilan suficientes transacciones y se finaliza un bloque, se desencriptan y ejecutan, similar en espíritu a las subastas por lotes o mempools encriptados que eliminan la ventaja de prioridad temporal de los bots. Además, como los ejecutores optimizan la ejecución a través de muchas preferencias, SUAVE puede eliminar la competencia ineficiente (como dos bots luchando por el mismo arbitraje mediante spam). En su lugar, SUAVE selecciona al mejor ejecutor a través de la subasta y ese ejecutor realiza la operación una vez, con el resultado beneficiando al usuario y a la red. SUAVE actúa así como un agregador de MEV y una "hada madrina": no elimina el MEV (las oportunidades rentables todavía se aprovechan), pero esas oportunidades se realizan bajo reglas transparentes y con las ganancias distribuidas en gran medida a los usuarios y validadores (y no desperdiciadas en comisiones de gas o guerras de latencia). Al unificar los mempools, SUAVE también aborda el MEV multidominio de una manera fácil de usar; por ejemplo, un arbitraje entre Uniswap en Ethereum y un DEX en Arbitrum podría ser capturado por un ejecutor de SUAVE y una parte pagada a los usuarios de ambos lados, en lugar de perderse o requerir un arbitrajista centralizado. Es importante destacar que SUAVE suprime las fuerzas centralizadoras del MEV: los acuerdos de flujo de órdenes exclusivos (donde entidades privadas capturan MEV) se vuelven innecesarios si todos usan la subasta común. La visión final de SUAVE es reducir la extracción de MEV perjudicial (como los ataques sándwich que causan slippage) ya sea haciéndolos no rentables o reembolsando el slippage, y usar el "buen MEV" (arbitraje, liquidaciones) para fortalecer las redes (a través del reparto de ingresos y la ejecución óptima). En palabras de Flashbots, el objetivo de SUAVE es asegurar que "los usuarios realicen transacciones con la mejor ejecución y las mínimas comisiones" mientras que "los validadores obtienen los máximos ingresos", es decir, cualquier MEV presente se extrae de la manera más alineada con el usuario.

• Estructura de Incentivos Económicos: SUAVE introduce nuevos roles y flujos de incentivos en la cadena de suministro de MEV. Los principales participantes son los usuarios, los ejecutores, los constructores/validadores de bloques y los operadores de la red SUAVE (validadores de la cadena SUAVE). Los usuarios establecen una oferta (pago) en su preferencia, que se pagará si se cumplen sus condiciones. Esta oferta es el anzuelo para los ejecutores: un ejecutor que cumple la intención del usuario (por ejemplo, hace back-running a su operación para obtener un mejor precio) puede reclamar la oferta como recompensa. Por lo tanto, los usuarios están directamente pagando por la calidad de la ejecución, de forma similar a publicar una recompensa. Los ejecutores (Searchers) están motivados a tomar las preferencias de los usuarios del mempool de SUAVE y optimizarlas porque ganan la oferta del usuario más cualquier beneficio de arbitraje extra inherente a la transacción. Los ejecutores competirán para ofrecer el mejor resultado al usuario porque el usuario puede establecer su oferta de manera que solo pague si el ejecutor realmente logra el resultado deseado (la oferta puede ser condicional a los resultados en la cadena a través de oráculos). Por ejemplo, un usuario podría decir: "Pagaré 0.5 ETH a quien ejecute esta transacción de tal manera que obtenga al menos X de salida; si no, no hay pago". Esto alinea los incentivos de los ejecutores con el éxito del usuario. Validadores/Constructores de SUAVE: La propia cadena SUAVE probablemente será una red Proof-of-Stake (diseño por determinar), por lo que los validadores (que producen bloques en SUAVE) ganan comisiones de transacción en SUAVE (que provienen de los usuarios que publican ofertas y otras operaciones). Dado que SUAVE es una cadena compatible con EVM, también puede haber un token nativo o un sistema de comisiones de gas para esas transacciones. Estos validadores también desempeñan un papel en la secuenciación de bloques multidominio; sin embargo, la inclusión final del bloque en cada L1 todavía la realiza el validador de esa L1. En muchos casos, SUAVE producirá una plantilla de bloque parcial o completa que un proponente de Ethereum u otra cadena puede adoptar. Ese constructor podría pagar a SUAVE (o a los ejecutores de SUAVE) una parte del MEV. Flashbots ha mencionado que los validadores de SUAVE son incentivados por las comisiones normales de la red, mientras que los ejecutores son incentivados por las ofertas. Distribución de Valor: El enfoque de SUAVE tiende a empujar el valor hacia los extremos: los usuarios capturan valor (a través de mejores precios o reembolsos directos), y los validadores capturan valor (a través de mayores comisiones/ofertas). En teoría, si SUAVE cumple su misión, la mayor parte del MEV será devuelta a los usuarios o utilizada para compensar a los validadores por asegurar la red, en lugar de concentrarse en los searchers. Flashbots ha indicado que no planea buscar rentas de SUAVE y no tomará una parte más allá de lo necesario para arrancar; quieren diseñar el mercado, no monopolizarlo. Otra consideración de incentivos son los constructores entre cadenas: SUAVE permite a los constructores de bloques acceder al MEV multidominio, lo que significa que un constructor en una cadena puede ganar comisiones adicionales al incluir transacciones que completan un arbitraje con otra cadena. Esto anima a los constructores/validadores de diferentes cadenas a participar en SUAVE, porque quedarse fuera significa perder ingresos. En esencia, el diseño económico de SUAVE intenta alinear a todos los participantes para que se unan a la subasta común: los usuarios porque obtienen una mejor ejecución (y quizás reembolsos de MEV), los validadores porque obtienen los máximos ingresos, y los searchers porque ahí es donde se agrega el flujo de órdenes. Al concentrar el flujo de órdenes, SUAVE también obtiene una ventaja de información sobre cualquier actor aislado (todas las preferencias en un solo lugar), lo que presiona económicamente a todos a cooperar dentro de SUAVE en lugar de separarse. En resumen, los incentivos de SUAVE promueven un ciclo virtuoso: más flujo de órdenes → mejores oportunidades de MEV combinadas → ofertas más altas para usuarios/validadores → más flujo de órdenes. Esto contrasta con la competencia de suma cero y los acuerdos exclusivos del pasado, apuntando en cambio a la "coopetición" donde el MEV es un valor compartido para crecer y distribuir.

• Cumplimiento y Consideraciones Regulatorias: SUAVE se está construyendo con la neutralidad creíble y la resistencia a la censura como principios fundamentales. Por diseño, SUAVE elimina intermediarios centrales: no hay un único mempool o un único constructor para atacar o regular. Las transacciones (preferencias) en SUAVE pueden ser totalmente encriptadas y privadas hasta que se ejecutan, utilizando enclaves seguros y, eventualmente, técnicas criptográficas. Esto significa que la censura a nivel de contenido de la transacción es impracticable, ya que los validadores/constructores ni siquiera pueden leer los detalles de la transacción antes de finalizar el orden. SUAVE esencialmente fuerza un enfoque de "no confíes, verifica": los participantes no necesitan confiar en que una entidad no censure, porque la propia arquitectura del sistema (red descentralizada + encriptación) asegura que las preferencias de todos se incluyan de manera justa. Además, SUAVE está destinado a ser una red abierta y sin permisos: Flashbots invita explícitamente a todas las partes (usuarios, searchers, billeteras, otras blockchains) a participar. No hay KYC ni barreras de permiso en su diseño. Esto podría plantear preguntas a los reguladores (por ejemplo, el protocolo podría facilitar la extracción de MEV en transacciones sancionadas), pero como SUAVE es solo una plataforma descentralizada, la aplicación sería difícil y análoga a tratar de regular el mempool de una blockchain. El enfoque de SUAVE en la privacidad (a través de SGX y más tarde la criptografía) también protege los datos de los usuarios y el flujo de órdenes de un monitoreo no deseado, lo cual es positivo para la seguridad del usuario pero podría entrar en conflicto con los deseos regulatorios de transparencia. Por otro lado, el enfoque de SUAVE podría verse como más justo y conforme con el espíritu de los mercados abiertos: al crear un campo de juego nivelado y devolver valor a los usuarios, reduce los aspectos explotadores del MEV que podrían atraer la ira regulatoria (como hacer back-running a los usuarios sin su consentimiento). SUAVE también puede ayudar a eliminar los dark pools no regulados: una razón por la que los reguladores podrían estar preocupados por el MEV son las ventas de flujo de órdenes exclusivas (que se asemejan al uso de información privilegiada). SUAVE las reemplaza con una subasta pública transparente, una estructura de mercado posiblemente más compatible. En términos de características de cumplimiento explícitas, SUAVE podría permitir múltiples políticas de ordenación: por ejemplo, las comunidades o jurisdicciones podrían desplegar sus propios ejecutores con ciertos filtros o preferencias. Sin embargo, la base es que SUAVE intentará ser máximamente neutral: "eliminar cualquier punto central de control, incluido Flashbots" y evitar incrustar decisiones de política a nivel de protocolo. Flashbots ha enfatizado que no controlará el mercado de SUAVE a medida que madure, lo que significa que no habrá un interruptor de apagado central o un conmutador de censura. La gobernanza (si la hay) de SUAVE aún no está definida públicamente, pero se puede esperar que involucre a la comunidad en general y posiblemente a un token, en lugar de la decisión de una empresa. En resumen, SUAVE está diseñado para alinearse con los principios descentralizados, lo que por naturaleza resiste cierto control regulatorio (censura), mientras que potencialmente alivia algunas preocupaciones regulatorias al hacer que la extracción de MEV sea más equitativa y transparente.

• Arquitectura Técnica (Consenso y Criptografía): SUAVE operará su propio entorno de blockchain, al menos inicialmente. Se describe como una cadena compatible con EVM especializada en preferencias y MEV. La arquitectura tiene tres componentes principales: (1) el Entorno de Preferencia Universal (la cadena SUAVE + mempool, donde se publican y agregan las preferencias), (2) el Mercado de Ejecución (ejecutores fuera o dentro de la cadena que resuelven/optimizan las preferencias, similar a un "motor de emparejamiento de órdenes" descentralizado), y (3) la Construcción de Bloques Descentralizada (una red de participantes de SUAVE que ensamblan bloques para varios dominios). En su núcleo, el consenso de SUAVE probablemente será un consenso BFT de Prueba de Participación (similar a Ethereum o Cosmos) para operar la propia cadena SUAVE, aunque todavía se está decidiendo si SUAVE se convertirá en una L1, una L2 de Ethereum o un conjunto de contratos de "restaking". Una posibilidad es que SUAVE pueda comenzar como una capa 2 o sidechain que utiliza Ethereum para la finalidad, o aprovechar conjuntos de validadores existentes. El modelo de seguridad está por determinar, pero las discusiones han incluido convertirlo en una L3 de Ethereum o una cadena de Cosmos. Criptográficamente, SUAVE se apoya fuertemente en Hardware Confiable y encriptación en su hoja de ruta inicial. La fase SUAVE Centauri implementa una "subasta de flujo de órdenes consciente de la privacidad" en la que Flashbots (de forma centralizada) opera enclaves SGX para mantener privados los flujos de órdenes de los searchers y usuarios. En SUAVE Andromeda, planean usar subastas y construcción de bloques basadas en SGX sin confiar en Flashbots (los enclaves proporcionan confidencialidad para que ni siquiera Flashbots pueda espiar). Para SUAVE Helios, el objetivo es tener una red de construcción descentralizada basada en SGX, lo que significa que muchas partes independientes ejecutan enclaves que construyen bloques colectivamente, logrando tanto privacidad como descentralización. A largo plazo, Flashbots está investigando enclaves seguros personalizados y reemplazos criptográficos como el descifrado de umbral y la computación multipartita para reducir la dependencia del SGX de Intel. Por ejemplo, podrían usar un esquema de cifrado de umbral donde los validadores de SUAVE mantienen conjuntamente una clave para descifrar transacciones solo después de que se decide la ordenación (asegurando que nadie pueda hacer front-running). Este concepto es similar a Ferveo de Anoma u otras ideas de "ordenación justa a través de cifrado de umbral". Además, SUAVE trata las preferencias del usuario como contratos inteligentes en su cadena. La preferencia de un usuario podría contener un predicado de validez y una condición de pago; esto es esencialmente un fragmento de código que dice "si se logra el resultado X en la cadena Y, entonces paga al ejecutor Z esta cantidad". La cadena SUAVE necesita manejar oráculos y verificación entre cadenas para saber cuándo se ha cumplido una preferencia (por ejemplo, leyendo el estado de Ethereum para ver si ocurrió un intercambio). Esto implica que la arquitectura de SUAVE involucrará clientes ligeros en cadena o sistemas de oráculos para las cadenas conectadas, así como potencialmente liquidación atómica entre cadenas (para asegurar, por ejemplo, que un ejecutor pueda ejecutar en Ethereum y Arbitrum y reclamar la oferta atómicamente). SUAVE planea ser altamente extensible: al ser compatible con EVM, contratos arbitrarios (preferencias nativas de SUAVE o incluso dapps normales) podrían ejecutarse en él, aunque la intención es mantenerlo enfocado en la coordinación del flujo de órdenes. En cuanto al consenso, SUAVE podría innovar al ser una cadena centrada en intenciones en lugar de una centrada en transacciones, pero en última instancia debe ordenar mensajes (preferencias) y producir bloques como cualquier cadena. Uno puede imaginar que SUAVE adopte un algoritmo de consenso optimizado para rendimiento y finalidad de baja latencia, ya que se situará en la ruta crítica de las transacciones para muchas cadenas. Quizás se podría usar una finalidad instantánea al estilo de Tendermint o incluso un consenso basado en DAG para confirmar rápidamente las preferencias. Independientemente, las características distintivas de SUAVE están en la capa de transacción, no en la capa de consenso: el uso de tecnología de privacidad (SGX, cifrado de umbral) para la ordenación, la comunicación multidominio y la lógica de enrutamiento de órdenes inteligentes integrada en el protocolo. Esto lo convierte en una especie de "meta-capa" sobre las blockchains existentes. Técnicamente, cada cadena participante necesitará confiar en las salidas de SUAVE hasta cierto punto (por ejemplo, un proponente de Ethereum necesitaría aceptar un bloque construido por SUAVE o incluir sugerencias de SUAVE). Flashbots ha indicado que SUAVE se introducirá gradualmente y será opcional: los dominios pueden elegir adoptar la secuenciación de SUAVE para sus bloques. Si se adopta ampliamente, SUAVE podría convertirse en una red de enrutamiento de transacciones consciente del MEV de facto para Web3. En resumen, la arquitectura de SUAVE es un matrimonio entre blockchain y subasta fuera de la cadena: una cadena especializada para la coordinación, casada con la computación segura fuera de la cadena entre ejecutores, todo anclado por garantías criptográficas de equidad y privacidad.

• Hoja de Ruta de Desarrollo y Hitos: Flashbots delineó la hoja de ruta de SUAVE en tres hitos principales, nombrados como sistemas estelares: Centauri, Andromeda y Helios. Centauri (la primera fase, en desarrollo en 2023) se enfoca en construir una subasta de flujo de órdenes centralizada pero que preserva la privacidad. En esta fase, Flashbots ejecuta el servicio de subasta (probablemente en SGX) que permite a los searchers pujar para hacer back-running a las transacciones de los usuarios, devolviendo el MEV a los usuarios de forma privada. También incluye el lanzamiento de una devnet de SUAVE para pruebas iniciales. De hecho, en agosto de 2023, Flashbots publicó un cliente temprano de SUAVE (suave-geth) y lanzó Toliman, la primera testnet pública de SUAVE. Esta testnet se ha utilizado para experimentar con la expresión de preferencias y la lógica básica de subastas. Andromeda (la siguiente fase) lanzará la primera mainnet de SUAVE. Aquí, los usuarios podrán expresar preferencias en una red en vivo, y el Mercado de Ejecución operará (ejecutores cumpliendo intenciones). Andromeda también introduce subastas y construcción de bloques basadas en SGX de una manera más distribuida, eliminando la necesidad de confiar en Flashbots como operador y haciendo el sistema verdaderamente sin permisos para searchers y constructores. Un entregable en esta fase es usar SGX para encriptar el flujo de órdenes de manera que incluso los constructores de bloques no puedan espiar pero aún puedan construir bloques (es decir, un flujo de órdenes "abierto pero privado"). Helios es la ambiciosa tercera fase donde SUAVE alcanza la descentralización total y la funcionalidad entre cadenas. En Helios, una red descentralizada de constructores en SGX produce bloques de forma colaborativa (sin dominio de un solo constructor). Además, SUAVE "incorporará un segundo dominio" más allá de Ethereum, lo que significa que manejará el MEV para al menos dos cadenas, demostrando subastas de MEV entre cadenas. Adicionalmente, se habilitará la expresión y ejecución de MEV multidominio (los usuarios pueden publicar intenciones verdaderamente multicadena y hacer que se ejecuten atómicamente). Más allá de Helios, Flashbots anticipa explorar hardware personalizado y criptografía avanzada (como pruebas zk o MPC) para endurecer aún más las garantías de confianza. Actualizaciones y hitos clave hasta ahora: Noviembre de 2022 – se anuncia SUAVE; Agosto de 2023 – primer lanzamiento de código de SUAVE y testnet (Toliman); en curso en 2024 – fase Centauri de subasta de flujo de órdenes en ejecución (Flashbots ha insinuado que esto se está probando con transacciones de usuarios en un entorno cerrado). Un hito notable será el lanzamiento de la mainnet de SUAVE (Andromeda), que a mediados de 2025 está en el horizonte. Flashbots se ha comprometido a construir SUAVE de forma abierta e invitar a la colaboración de todo el ecosistema. Esto se refleja en la investigación y las discusiones del foro, como las publicaciones de la serie "Stargazing" que actualizan sobre la evolución del diseño de SUAVE. El objetivo final de SUAVE es que se convierta en una pieza de infraestructura propiedad de la comunidad: la "capa de secuenciación descentralizada" para todo el mundo cripto. Lograr esto marcará un hito importante en la lucha por la ordenación justa: si SUAVE tiene éxito, el MEV ya no sería un bosque oscuro sino una fuente de valor transparente y compartida, y ninguna cadena tendría que sufrir por sí sola los efectos centralizadores del MEV.

Anoma (Arquitectura Centrada en Intenciones para el Descubrimiento Justo de Contrapartes)​

Anoma es un enfoque radicalmente diferente para permitir la ordenación justa y la mitigación de MEV: es una arquitectura completa para una infraestructura de blockchain basada en intenciones. En lugar de añadir una subasta a las cadenas existentes, Anoma replantea el paradigma de las transacciones desde cero. En Anoma, los usuarios no transmiten transacciones concretas; transmiten intenciones, declaraciones del estado final que desean, y la propia red descubre contrapartes y forma transacciones que cumplen estas intenciones. Al integrar el descubrimiento de contrapartes, la ordenación justa y la privacidad a nivel de protocolo, Anoma tiene como objetivo eliminar virtualmente ciertas formas de MEV (como el front-running) y permitir un intercambio y liquidación descentralizados "libres de front-runners". Anoma es más un marco que una sola cadena: cualquier blockchain puede ser una "instancia fractal" de Anoma adoptando su arquitectura de gossip de intenciones y emparejamiento. Para esta discusión, nos centramos en la primera implementación de Anoma (a veces llamada Anoma L1) y sus características de protocolo principales, en lo que respecta a la equidad y el MEV.

• Encolado y Ordenación de Transacciones: Anoma descarta el mempool convencional de transacciones; en su lugar, tiene una red de gossip de intenciones. Los usuarios transmiten una intención, por ejemplo, "Quiero cambiar 100 DAI por al menos 1 ETH" o "Quiero pedir prestado contra colateral a la mejor tasa". Estas intenciones son órdenes parciales: no especifican rutas de ejecución exactas, solo el resultado deseado y las restricciones. Todas las intenciones se transmiten por toda la red y se recopilan. Ahora, la ordenación en Anoma funciona en dos etapas: (1) Descubrimiento/Emparejamiento de Contrapartes, y (2) Ejecución de Transacciones con Ordenación Justa. En la etapa 1, nodos especializados llamados solvers monitorean continuamente el pool de intenciones e intentan encontrar conjuntos de intenciones que se complementen entre sí para formar una transacción válida. Por ejemplo, si Alice tiene la intención de cambiar DAI por ETH y Bob tiene la intención de cambiar ETH por DAI, un solver puede emparejarlos. Si múltiples intenciones son compatibles (como un libro de órdenes de ofertas y demandas), los solvers pueden encontrar un emparejamiento o precio de compensación óptimo. Es importante destacar que esto sucede fuera de la cadena en la red de solvers, efectivamente un emparejamiento algorítmico. Una vez que un solver (o grupo de solvers) ha construido una transacción completa (o un conjunto de transacciones) que cumple algunas intenciones, la envía a la cadena para su ejecución. Aquí es donde entra la etapa 2: el consenso de Anoma entonces ordenará estas transacciones enviadas por los solvers en bloques. Sin embargo, el consenso de Anoma está diseñado para ser justo en el orden: utiliza técnicas criptográficas (cifrado de umbral) para asegurar que las transacciones se ordenen sin ser influenciadas por su contenido o el momento preciso de su envío. Específicamente, Anoma planea usar Ferveo, un esquema de cifrado de umbral, a nivel de mempool. La forma en que funciona es: los solvers encriptan las transacciones que quieren proponer usando una clave pública colectiva de los validadores. Los validadores incluyen estas transacciones encriptadas en los bloques sin conocer sus detalles. Solo después de que una transacción se finaliza en un bloque, los validadores la desencriptan colectivamente (cada uno contribuyendo con una parte de la clave de descifrado). Esto asegura que ningún validador pueda hacer front-running selectivamente o reordenar basándose en el contenido de una transacción; se comprometen a una ordenación a ciegas. El algoritmo de consenso ordena efectivamente las transacciones (en realidad, las intenciones) de una manera más cercana a un orden de primera vista o por lotes, ya que todas las transacciones en un "lote" dado (bloque) se encriptan y revelan simultáneamente. En la práctica, Anoma puede implementar subastas por lotes para ciertas aplicaciones: por ejemplo, una intención de comerciar puede recopilarse durante N bloques (manteniéndose encriptada), luego todas se desencriptan juntas después de N bloques y son emparejadas por los solvers en un solo lote. Esto evita que los actores rápidos vean las órdenes de otros y reaccionen dentro de ese lote, una gran ventaja para la equidad (esta técnica está inspirada en las Subastas por Lotes Frecuentes y se ha propuesto para eliminar las ventajas del trading de alta frecuencia). Además, los predicados de validez de Anoma (contratos inteligentes a nivel de aplicación) pueden imponer restricciones de equidad en el resultado de la ordenación. Por ejemplo, una aplicación DEX de Anoma podría tener una regla: "todas las operaciones en un lote obtienen el mismo precio de compensación, y los solvers no pueden insertar transacciones adicionales para explotar a los usuarios". Debido a que estas reglas son parte de la validez del estado, cualquier bloque que contenga un emparejamiento injusto (digamos, un solver intentó colar una operación propia a un mejor precio) sería inválido y rechazado por los validadores. En resumen, la ordenación en Anoma ocurre como emparejar y luego encriptar+ordenar: las intenciones se ponen conceptualmente en cola hasta que un solver forma una transacción, y luego esa transacción es ordenada por un consenso de ordenación justa (evitando el MEV típico). Efectivamente, no hay una carrera en el mempool, ya que las intenciones de los usuarios no compiten directamente por el precio del gas o la prioridad temporal. En cambio, la competencia es para que los solvers encuentren coincidencias, y luego esas coincidencias se ejecutan de una manera que nadie puede cambiar el orden o interceptarlas mientras están en tránsito. Esta arquitectura promete neutralizar muchos vectores de MEV: no existe el concepto de hacer front-running a una intención porque las intenciones no son accionables hasta que el solver las ensambla, y para entonces ya están encriptadas en el bloque. Es un modelo de encolado fundamentalmente diferente destinado a eliminar las explotaciones de prioridad basadas en el tiempo.

• Mecanismos de Supresión/Extracción de MEV: Anoma está diseñado para minimizar el "mal MEV" por construcción. Al resolver las operaciones a través de la resolución por lotes y el cifrado de umbral, los ataques de MEV típicos como el sándwich son imposibles: nadie ve una intención y puede insertar la suya antes, porque las intenciones no son transacciones que viven en un mempool transparente. Los solvers solo emiten transacciones emparejadas finales después de que la oportunidad de inserción ha pasado (debido a la encriptación y el procesamiento por lotes). En un DEX basado en Anoma, los usuarios no serían objeto de front-running o back-running en el sentido tradicional, porque todas las operaciones en un lote se ejecutan juntas a un precio uniforme (evitando que un atacante explote el cambio de precio entre ellas). Esto esencialmente suprime el MEV depredador como el arbitraje DEX o el sándwich; el valor que habría sido tomado por un bot es retenido por los usuarios (obtienen un precio justo). El enfoque de Anoma sobre el arbitraje también es notable: en muchos casos, si múltiples intenciones crean una oportunidad de arbitraje, el solver que las empareja incorporará ese beneficio en el emparejamiento (por ejemplo, emparejar diferentes precios y obtener un beneficio neto). Pero como múltiples solvers pueden competir para proporcionar el mejor emparejamiento, la competencia puede forzar a los solvers a devolver la mayor parte de esa ventaja a los usuarios en forma de mejores términos de llenado. Por ejemplo, si un usuario quiere vender al precio A y otro quiere comprar al precio B (B > A implica una brecha), un solver podría cumplir ambos a un precio intermedio y capturar la diferencia como beneficio, pero si otro solver ofrece a los usuarios un precio aún más cercano entre sí (dejando menos beneficio), ganará la intención. Así, los solvers compiten para reducir los márgenes de MEV en beneficio de los usuarios, de manera similar a cómo los searchers en Flashbots compiten a través de las comisiones. La diferencia es que esto sucede algorítmicamente a través del emparejamiento de intenciones en lugar de la puja por el gas. Todavía puede haber "MEV extraído" en Anoma, pero es probable que se limite a que los solvers ganen comisiones modestas por su servicio. Notablemente, Anoma espera que la mayor parte del flujo de órdenes sea internalizado por el protocolo o la lógica de la aplicación. En algunos casos, esto significa que lo que sería una oportunidad de MEV se convierte simplemente en una comisión normal del protocolo. Por ejemplo, la primera instancia fractal de Anoma (Namada) implementa un AMM de curva de enlace en la cadena; el arbitraje en ese AMM es capturado por el mecanismo del AMM (como un reequilibrador incorporado) en lugar de por arbitrajistas externos. Otro ejemplo: una intención de préstamo que ofrece un alto interés podría ser emparejada con una intención de préstamo; no se necesita un liquidador de terceros si el colateral cae, porque las propias intenciones podrían manejar el reequilibrio o el protocolo podría autoliquidar a un precio justo. Al eliminar a los extractores de terceros, Anoma reduce la prevalencia de la extracción de MEV fuera de la cadena. Además, Anoma enfatiza la privacidad (a través del subsistema Taiga de circuitos ZK). Los usuarios pueden optar por mantener sus intenciones parcial o totalmente protegidas (por ejemplo, ocultando cantidades o tipos de activos). Esto suprime aún más el MEV: si los detalles de una orden grande están ocultos, nadie puede apuntar a ella para la extracción de valor. Solo después del emparejamiento y la ejecución podrían surgir los detalles, momento en el cual es demasiado tarde para explotar. En resumen, el mecanismo de Anoma se trata en gran medida de prevenir el MEV en lugar de extraerlo: al agrupar transacciones, encriptar el mempool y incorporar la alineación económica en el emparejamiento, intenta asegurar que haya pocas oportunidades para el arbitraje malicioso o el front-running. El MEV necesario (como el arbitraje para igualar precios entre mercados) es manejado por solvers o la lógica del protocolo de una manera con confianza minimizada. Se podría decir que Anoma apunta a la "minimización del MEV", esforzándose por obtener resultados como si cada usuario tuviera acceso a la contraparte perfecta al instante y sin fugas. Cualquier valor extraído para facilitar eso (la recompensa del solver) es similar a una pequeña comisión de servicio, no una ganancia inesperada por explotar la asimetría.

• Estructura de Incentivos Económicos: En Anoma, los solvers asumen el papel análogo tanto a los intermediarios como a los constructores de bloques. Incurren en costos (computación, quizás depositar colateral) para encontrar coincidencias de intenciones, y son recompensados cuando proponen con éxito transacciones que se incluyen. Los solvers pueden ganar de varias maneras: podrían cobrar una comisión o un diferencial dentro de la transacción que construyen (por ejemplo, dando a los usuarios términos ligeramente menos favorables y quedándose con la diferencia, similar a cómo un agregador de DEX podría tomar una pequeña parte). O bien, ciertas intenciones podrían incluir explícitamente una recompensa para el solver (como "estoy dispuesto a pagar hasta 0.01 ETH para que esto se haga"). El modelo de compensación exacto es flexible, pero la clave es que los solvers compiten. Si un solver intenta tomar una comisión demasiado alta, otro puede proponer una solución con un mejor resultado para el usuario y ganar la inclusión. Esta dinámica competitiva tiene como objetivo mantener los beneficios de los solvers bajo control y alineados con la provisión de valor. Validadores (Productores de Bloques): Los validadores de Anoma ejecutan el consenso que ordena y ejecuta las transacciones. Son incentivados por recompensas de bloque y comisiones, como en cualquier blockchain. Notablemente, si las intenciones se emparejan entre múltiples usuarios, la transacción resultante podría tener múltiples fuentes de comisiones (cada usuario podría contribuir con una comisión o una porción de los activos). Es posible que el modelo de comisiones de Anoma permita la división de comisiones, pero típicicamente los validadores obtendrán las comisiones de gas estándar por procesar transacciones. En fases futuras, Anoma planea un "consenso bajo demanda" y un token nativo. La idea es que muchas instancias de Anoma (o shards) podrían existir, y algunas podrían activarse temporalmente para tareas específicas ("consenso ad-hoc" para necesidades particulares de la aplicación). El token probablemente se usaría para hacer staking y asegurar estas instancias. Los incentivos aquí aseguran que la red tenga suficientes validadores para procesar todas las transacciones emparejadas de manera confiable y que se comporten honestamente en el proceso de descifrado de umbral (quizás con condiciones de slashing si intentan descifrar antes de tiempo o censurar). Usuarios: Los usuarios en Anoma potencialmente ahorran dinero y obtienen mejores resultados en lugar de pagar MEV implícitamente. Por ejemplo, podrían obtener consistentemente mejores precios de operación que en una cadena tradicional, lo que significa que el valor se queda con ellos. En algunos casos, los usuarios también podrían pagar comisiones explícitas para incentivar a los solvers, especialmente para intenciones complejas o cuando desean un emparejamiento más rápido. Pero como los usuarios pueden expresar intenciones sin especificar cómo hacerlo, delegan el trabajo pesado a los solvers y solo pagan si vale la pena. También existe la noción de que "los propietarios de intenciones pueden definir sus propios compromisos de seguridad/rendimiento": por ejemplo, un usuario podría decir "esperaré más tiempo por un mejor precio" o "pagaré más por una ejecución inmediata". Esta flexibilidad permite a los propios usuarios decidir cuánto ofrecer a los solvers o validadores, alineando los incentivos económicos con sus necesidades. Redistribución de MEV: Si ocurre algún MEV (como ARB entre cadenas), la arquitectura de Anoma podría permitir capturarlo en el sistema. Por ejemplo, múltiples shards o instancias de Anoma podrían coordinarse para liquidar un arbitraje atómico multicadena, y el beneficio podría ser compartido o quemado (dependiendo del diseño) en lugar de dejar que un arbitrajista externo se lo quede todo. En general, como Anoma da a las aplicaciones control sobre el flujo de transacciones, es posible implementar estrategias de MEV propiedad del protocolo (similar a la filosofía de Skip) a nivel de aplicación. Por ejemplo, una aplicación DeFi en Anoma podría enrutar automáticamente todas las operaciones de los usuarios a través de un solver dentro del protocolo que garantice la mejor ejecución y comparta cualquier beneficio adicional con los usuarios o los proveedores de liquidez. El efecto neto es que los extractores de MEV de terceros son desintermediados. Económicamente, esto es de suma positiva para los participantes honestos (usuarios, LPs, etc.), pero podría reducir las oportunidades para los searchers clásicos. Sin embargo, surgirán nuevos roles como solvers especializados (quizás uno se centre en el emparejamiento de NFT, otro en swaps de divisas, etc.). Estos solvers son análogos a los searchers de MEV de hoy, pero operan dentro de las reglas del sistema y probablemente tengan márgenes de beneficio menos descabellados debido a la competencia y las restricciones del protocolo. Por último, la visión de la Fundación Anoma sugiere que Anoma será una infraestructura de bien público. Habrá un token nativo, presumiblemente ANOMA, que podría capturar valor a través de comisiones o ser requerido para el staking. Se pueden prever incentivos de token (recompensas inflacionarias, etc.) para validadores y quizás incluso para solvers para impulsar la actividad. En el momento de escribir esto, los detalles sobre la economía del token no son finales, pero la hoja de ruta confirma que un token Anoma y un consenso nativo bajo demanda están planeados en fases futuras. Para resumir, el modelo de incentivos de Anoma fomenta el comportamiento cooperativo: los solvers ganan ayudando a los usuarios a obtener lo que quieren, no explotándolos; los validadores ganan asegurando la red y ordenando de manera justa; y los usuarios "pagan" principalmente cediendo algo de MEV a los solvers o comisiones, pero idealmente mucho menos que el MEV implícito que perderían en otros sistemas.

• Cumplimiento y Neutralidad: Anoma, al ser un marco, no una red única, puede ser instanciado de varias maneras; algunas podrían ser permisionadas, pero la L1 de Anoma y otras instancias similares están destinadas a ser sin permisos y con privacidad mejorada. Al incorporar fuertes características de privacidad (como intenciones protegidas usando pruebas de conocimiento cero en Taiga), Anoma se alinea con la visión de que la privacidad financiera es un derecho. Esto podría ponerlo en conflicto con ciertos regímenes regulatorios que exigen una visibilidad abierta de las transacciones. Sin embargo, el diseño de Anoma también podría evitar ciertos escollos regulatorios. Por ejemplo, si se eliminan el front-running y la selección injusta de órdenes, se mitigan las preocupaciones sobre la manipulación del mercado; un regulador podría apreciar que los usuarios no están siendo explotados sistemáticamente por insiders. Además, el concepto de "modelos de seguridad definidos por el usuario" implica que los usuarios o las comunidades podrían optar por diferentes supuestos de confianza. Potencialmente, una aplicación regulada podría construirse sobre Anoma donde, por ejemplo, el solver o un subconjunto de validadores sean entidades con KYC que garanticen el cumplimiento para ese dominio de intención particular. Anoma como capa base no impondría KYC a todos, pero se podrían implementar predicados de validez que requieran (por ejemplo) una prueba de elegibilidad para ciertas transacciones (como una prueba de no ser una dirección sancionada, o una verificación de credenciales) si una aplicación lo necesitara. La arquitectura es lo suficientemente flexible como para soportar el cumplimiento a nivel de aplicación sin comprometer la neutralidad de la capa base. En cuanto a la censura: el cifrado de umbral de Anoma significa que incluso si los validadores quisieran censurar, no pueden apuntar a intenciones específicas porque no las ven en texto plano. Lo único que podrían hacer es negarse a incluir transacciones encriptadas de ciertos solvers o usuarios, pero eso sería obvio (y en contra de las reglas del protocolo si se hace arbitrariamente). La expectativa es que las reglas de consenso desalienten la censura; por ejemplo, quizás si un bloque no incluye todas las intenciones desencriptadas disponibles del último lote, podría considerarse inválido o menos preferible. En cualquier caso, la descentralización de los validadores y la naturaleza encriptada de las cargas útiles aseguran un alto grado de resistencia a la censura. Sobre la neutralidad: Anoma aspira a ser una plataforma general no controlada por ninguna entidad única. La investigación y el desarrollo están liderados por Heliax (el equipo detrás de Anoma y Namada), pero una vez en vivo, una red Anoma sería gestionada por la comunidad. Es probable que haya una gobernanza en cadena para las actualizaciones, etc., lo que podría plantear cuestiones de cumplimiento (por ejemplo, ¿podría un gobierno subvertir la gobernanza para cambiar las reglas?), pero ese es un problema general de las blockchains. Una característica interesante relacionada con el cumplimiento es que Anoma admite múltiples instancias paralelas, lo que significa que se podría tener un pool de intenciones o shard aislado para ciertos tipos de activos o jurisdicciones. Esto no es explícitamente para la regulación, pero podría permitir, por ejemplo, un pool de intenciones de CBDC donde solo los bancos autorizados ejecuten solvers, coexistiendo con un pool DeFi libre. La modularidad de la arquitectura proporciona flexibilidad para segregar si es necesario, al tiempo que permite la interoperabilidad a través de puentes de intenciones. Finalmente, en términos de compatibilidad legal, todo el concepto de intenciones de Anoma podría evitar algunas clasificaciones que acosan a las criptomonedas tradicionales: dado que una intención no es una transacción vinculante hasta que se empareja, se podría argumentar que los usuarios mantienen más control (es como publicar una orden en un exchange, que tiene un precedente legal más claro, en lugar de ejecutar directamente una operación). Esto podría ayudar con cosas como el tratamiento fiscal (el sistema podría potencialmente dar un recibo unificado de una operación de varios pasos en lugar de muchas transacciones), aunque esto es especulativo. En general, Anoma prioriza la descentralización, la privacidad y la autonomía del usuario, lo que históricamente puede chocar con las expectativas regulatorias, pero las ganancias en equidad y transparencia podrían ganar favor. Esencialmente, trae la sofisticación de los motores de emparejamiento financiero tradicionales a la cadena, pero sin operadores centralizados. Si los reguladores llegan a entender ese modelo, podrían verlo como una estructura de mercado más ordenada y justa que el caos de los mempools.

• Arquitectura Técnica (Consenso y Criptografía): La arquitectura de Anoma es compleja y comprende varios componentes: Typhon (red, mempool, consenso, ejecución) y Taiga (la capa de privacidad de conocimiento cero). El núcleo de Typhon es la capa de gossip de intenciones y un enfoque novedoso para el consenso + emparejamiento combinados. El protocolo de consenso de Anoma extiende el consenso BFT típico con el concepto de "Predicados de Validez" y "Prueba de Emparejamiento de Órdenes". Esencialmente, cada aplicación en Anoma puede definir un predicado de validez que debe satisfacerse para las transacciones (piense en ello como condiciones de contrato inteligente que se aplican a nivel de bloque, no solo a nivel de transacción). Esto permite imponer propiedades como los precios de compensación de subastas por lotes, etc., como se describió. El algoritmo de consenso en sí mismo probablemente se basa en BFT al estilo de Tendermint o HotStuff (ya que Anoma está en el ámbito de Cosmos y admite IBC). De hecho, la testnet inicial de Anoma (Feigenbaum en 2021) y Namada usan un consenso al estilo de Tendermint con modificaciones. Una modificación importante es la integración del cifrado de umbral (Ferveo) en el pipeline del mempool. Típicamente, Tendermint selecciona un proponente que ordena las transacciones. En Anoma, el proponente ordenaría intenciones/transacciones encriptadas. Ferveo probablemente funciona haciendo que los validadores acuerden periódicamente una clave pública de umbral, y cada intención enviada por los solvers se encripta con esa clave. Durante la propuesta de bloque, se incluyen todas las transacciones encriptadas; después de la propuesta, los validadores ejecutan un protocolo para desencriptarlas (quizás el siguiente bloque contiene las salidas desencriptadas o algún esquema similar). Esto añade una fase al consenso pero asegura la equidad en el orden. Criptográficamente, esto utiliza la generación de claves distribuidas y el descifrado de umbral (por lo que se basa en supuestos como que al menos 2/3 de los validadores son honestos para no filtrar o descifrar datos antes de tiempo). En el lado de la privacidad, Taiga proporciona pruebas zkSNARK o zk-STARK que permiten que las intenciones permanezcan parcial o totalmente protegidas. Por ejemplo, un usuario podría enviar una intención de intercambio sin revelar el tipo de activo o la cantidad; proporciona una prueba ZK de que tiene saldo suficiente y que la transacción será válida si se empareja, sin revelar detalles específicos. Esto es análogo a cómo funcionan las transacciones protegidas en Zcash, pero extendido a las intenciones. Se menciona el uso de pruebas recursivas, lo que significa que múltiples pasos de una transacción (o múltiples intenciones) pueden probarse en una sola prueba sucinta para mayor eficiencia. La interacción de Taiga y Typhon significa que algunos solvers y validadores podrían estar operando con texto cifrado o compromisos en lugar de valores en texto plano. Por ejemplo, un solver podría emparejar intenciones que se expresan de manera confidencial, resolviendo una ecuación de compromisos. Esto es criptografía de vanguardia y va más allá de lo que hacen la mayoría de las blockchains actuales. Otra pieza clave es la integración de IBC: las instancias de Anoma pueden comunicarse con otras cadenas (especialmente las cadenas de Cosmos) a través del protocolo de Comunicación Inter-Blockchain. Esto significa que una intención en Anoma podría potencialmente desencadenar una acción en otra cadena (a través de un mensaje IBC) o consumir datos del estado de otra cadena. La Fase 1 de la Mainnet en la hoja de ruta de Anoma menciona específicamente un "adaptador" en Ethereum y rollups para permitir que las intenciones de Anoma aprovechen la liquidez de EVM. Probablemente, un solver de Anoma podría componer una transacción que, por ejemplo, use Uniswap en Ethereum, creando una intención que, al ser emparejada, envíe un mensaje a Ethereum para ejecutar un intercambio (quizás a través de un relayer o algo como un puente IBC). El consenso debe garantizar la atomicidad: presumiblemente, la salida de Anoma podría ser como una única transacción que abarca múltiples cadenas (algo como iniciar una transacción en la cadena A y esperar un resultado en la cadena B). Lograr una liquidación atómica entre cadenas es difícil; posiblemente Anoma comenzará liquidando en una cadena a la vez (la Fase 1 se centra en el ecosistema de Ethereum, lo que probablemente significa que las intenciones de Anoma se liquidarán en la L1 o L2 de Ethereum de una sola vez). Más tarde, las "cadenas Quimera" y el consenso bajo demanda podrían permitir que sidechains personalizadas se activen para manejar emparejamientos particulares entre cadenas. En cuanto al rendimiento, el enfoque de Anoma podría ser más intensivo computacionalmente (solvers resolviendo problemas de emparejamiento NP-difíciles, validadores haciendo criptografía pesada). Pero la compensación es una experiencia de usuario enormemente mejorada (sin transacciones fallidas, mejores precios, etc.). El desarrollo de Anoma requiere construir estos componentes novedosos casi desde cero: Heliax ha estado creando Juvix, un nuevo lenguaje para escribir predicados de validez e intenciones, y mucha investigación (algunas referencias del sitio de Anoma hablan de estos conceptos en detalle). Hitos principales: La primera testnet pública de Anoma, Feigenbaum, se lanzó en noviembre de 2021 como una demostración del gossip básico de intenciones. Posteriormente, Heliax cambió su enfoque al lanzamiento de Namada (una L1 centrada en la privacidad que puede verse como una instancia de Anoma centrada en las transferencias de activos); Namada se lanzó en 2023 e incluye características como transferencias protegidas y cifrado de umbral Ferveo para su mempool. Esto muestra la tecnología en acción en un caso de uso más limitado. Mientras tanto, las testnets de la visión completa de Anoma se han estado implementando por etapas ("testnet de verano de 2023" mencionada en la comunidad también). La hoja de ruta indica que la mainnet de la Fase 1 integrará Ethereum, la Fase 2 añadirá más cadenas y criptografía avanzada, y eventualmente llegarán el consenso nativo y el token. La separación de "consenso y token en una fase futura" sugiere que la mainnet inicial de Anoma podría depender de Ethereum (por ejemplo, aprovechando la seguridad de Ethereum o los tokens existentes en lugar de tener uno propio desde el primer día). Posiblemente lancen una L2 o una sidechain que publique en Ethereum. Y más tarde activen su propia red PoS con un token. Este enfoque por fases es interesante: podría ser para reducir la barrera de adopción (usar el capital existente en Ethereum en lugar de lanzar una nueva moneda inicialmente). En conclusión, la arquitectura de Anoma es novedosa y completa: combina la equidad criptográfica (cifrado de umbral, pruebas ZK) con un nuevo paradigma de transacciones (emparejamiento basado en intenciones) y capacidades entre cadenas. Es posiblemente el intento más agresivo de erradicar el MEV tradicional a nivel de protocolo, haciendo lo que ninguna cadena heredada hace: motores de emparejamiento justo incorporados. La complejidad es alta, pero si tiene éxito, una cadena Anoma podría proporcionar a los usuarios garantías de ejecución casi similares a las de un CEX en un entorno descentralizado, lo cual es un santo grial en la UX y la equidad de la blockchain.

Skip Protocol (Control Soberano de MEV y Conjunto de Herramientas de Ordenación Justa en Cosmos)​

Skip Protocol es una solución líder de MEV en el ecosistema de Cosmos, enfocada en dar a cada blockchain ("app-chain") las herramientas para gestionar la ordenación de transacciones y la captura de MEV en sus propios términos. A diferencia de Flashbots o Anoma, que proponen sistemas que abarcan toda la red, Skip se alinea con la filosofía de soberanía de Cosmos: cada cadena puede integrar los módulos de Skip para aplicar reglas de ordenación justa personalizadas, ejecutar subastas de espacio de bloque dentro del protocolo y capturar MEV para los stakeholders o usuarios de la cadena. Skip puede considerarse como un conjunto de módulos del SDK de Cosmos e infraestructura que juntos permiten la Construcción de Bloques Propiedad del Protocolo (POB) y una secuenciación de transacciones flexible. Ha sido adoptado en cadenas como Osmosis, Juno, Terra y otras en Cosmos, y también está colaborando con proyectos como la próxima cadena de dYdX para la mitigación de MEV. Los elementos clave incluyen un mecanismo de subasta en cadena para transacciones prioritarias, lógica de ordenación de transacciones a nivel de consenso y mecanismos dentro de la aplicación para reciclar el MEV ("buen MEV") en beneficio del protocolo.

• Algoritmos de Encolado y Ordenación de Transacciones: En una cadena típica de Cosmos (usando consenso Tendermint/BFT), el mempool ordena las transacciones aproximadamente por comisión y hora de llegada, y el proponente del bloque puede elegir cualquier ordenación al crear un bloque (sin restricciones algorítmicas más allá de incluir transacciones válidas). Skip cambia esto introduciendo reglas de ordenación impuestas por consenso y mempools de múltiples carriles. Usando la nueva interfaz ABCI++ de Cosmos (que permite personalizar la propuesta y el procesamiento de bloques), el módulo Protocol-Owned Builder (POB) de Skip puede particionar el bloque en carriles distintos con diferentes políticas de ordenación. Por ejemplo, un carril podría ser un carril de subasta de la parte superior del bloque donde las transacciones con la oferta más alta (quizás de bots de arbitraje o operaciones urgentes) se colocan primero en el bloque en un orden fijo, otro carril podría ser un carril gratuito para transacciones de usuarios ordinarios sin comisiones, y un carril predeterminado para transacciones normales con comisiones. El componente BlockBuster del módulo de Skip permite a los desarrolladores definir estos carriles y su lógica de ordenación de manera modular. Crucialmente, estas reglas son impuestas por todos los validadores: cuando un proponente construye un bloque, los otros validadores verificarán que las transacciones del bloque se adhieran a las reglas de ordenación acordadas (a través de las comprobaciones de ProcessProposal ABCI). Si no es así, pueden rechazar el bloque. Esto significa que incluso un proponente malicioso o que busca beneficios no puede desviarse (por ejemplo, no puede colar su propia transacción de front-running antes de un postor ganador de la subasta, porque eso violaría la regla de ordenación). Algunos ejemplos de reglas de ordenación que Skip permite: (a) Ordenar transacciones por precio de gas descendente (comisión), asegurando que la transacción con la comisión más alta siempre tenga prioridad. Esto formaliza un esquema justo de "pago por prioridad" en lugar de uno aleatorio o basado en el tiempo. (b) Debe incluir al menos una transacción de actualización de precios de oráculo antes de cualquier operación, asegurando que las fuentes de datos se actualicen, lo que evita escenarios en los que un proponente podría ignorar las actualizaciones de oráculos para explotar precios obsoletos. (c) Limitar el número de transacciones especiales en la parte superior del bloque, por ejemplo, solo un bundle ganador de la subasta puede ocupar la parte superior, para evitar el spam de muchas pequeñas capturas de MEV. (d) Ninguna transacción que viole una propiedad del estado: Skip permite reglas de ordenación con estado, como "después de construir el bloque, asegurar que ninguna operación DEX se ejecutó a un precio peor que si estuviera al final del bloque" (una forma de asegurar que no ocurrió un ataque sándwich). Una regla concreta descrita es una "condición de cero front-running en todos los DEXs", lo que podría significar que si alguna transacción se hubiera visto afectada por otras posteriores de una manera que indique front-running, el bloque es inválido. Esto es poderoso: es esencialmente hacer que la equidad sea parte de la validez del bloque. Las cadenas de Cosmos pueden implementar tales reglas porque controlan su pila completa. El marco de Skip proporciona una forma estructurada de hacerlo a través del AuctionDecorator en el SDK, que puede verificar cada transacción contra las reglas configuradas. Además, Skip proporciona mejoras en el mempool: el mempool del nodo puede simular bloques con antelación, filtrar transacciones fallidas, etc., para ayudar a los proponentes a seguir las reglas de manera eficiente. Por ejemplo, si el carril de subasta de un bloque debe tener las ofertas más altas, el mempool puede ordenarse por ofertas para ese carril. Si un bloque debe incluir solo transacciones que resulten en una cierta condición de estado, el nodo del proponente puede simular las transacciones a medida que las elige para asegurar que la condición se cumpla. En resumen, Skip permite una ordenación determinista y definida por la cadena en lugar de dejarla completamente al capricho del proponente o a la simple prioridad del precio del gas. Las cadenas adoptan el módulo de constructor de Skip para efectivamente codificar su política de ordenación de transacciones en el protocolo. Esto fomenta la equidad porque todos los validadores imponen las mismas reglas, eliminando la oportunidad de que un solo proponente realice una reordenación arbitraria para MEV a menos que esté dentro del mecanismo permitido (como la subasta, donde es transparente y competitivo). El encolado de transacciones en el modelo de Skip podría implicar colas separadas por carril. Por ejemplo, un carril de subasta podría encolar transacciones de oferta especiales (Skip usa un tipo especial MsgAuctionBid para pujar por la inclusión en la parte superior del bloque). Esas ofertas se recopilan en cada bloque y se selecciona la más alta. Mientras tanto, las transacciones normales se encolan en el mempool predeterminado. Esencialmente, Skip introduce una cola estructurada: una para ofertas prioritarias, otra para gratuitas u otras, etc., cada una con sus propios criterios de ordenación. Este enfoque modular significa que cada cadena puede personalizar cómo equilibra la equidad y los ingresos; por ejemplo, Osmosis podría decir "no queremos ninguna subasta de MEV, pero imponemos la equidad en el orden a través del cifrado de umbral" (implementaron el cifrado de umbral con la ayuda de Skip y otros), mientras que otra cadena podría decir "permitimos subastas para MEV pero requerimos que parte de las ganancias se quemen". Skip admite ambos. Esta configurabilidad de la ordenación es el sello distintivo de Skip.

• Mecanismos de Mitigación y Extracción de MEV: El enfoque de Skip hacia el MEV a menudo se describe como "MEV propiedad del protocolo" y "multiplicidad". El MEV propiedad del protocolo significa que el propio protocolo de la blockchain, a través de su código y gobernanza, captura o redistribuye el MEV en lugar de dejarlo en manos de validadores individuales o externos. La multiplicidad se refiere a asegurar que se incluyan las transacciones "correctas" (múltiples), esencialmente no excluyendo transacciones legítimas de usuarios en favor de solo transacciones de MEV, y quizás incluyendo múltiples oportunidades de MEV en un bloque si es posible (para que ningún searcher monopolice). Concretamente, Skip proporciona herramientas para capturar MEV de maneras que benefician a la red: una es Skip Select, un sistema de subasta de espacio de bloque para la inclusión en la parte superior del bloque. En Skip Select, los searchers (como los bots de arbitraje) envían bundles con propinas a los validadores, de forma similar a los bundles de Flashbots, excepto que se hace de forma nativa en la cadena a través de los módulos de Skip. El bundle (o bundles) que más paga se inserta automáticamente en la parte superior del bloque en el orden especificado. Esto garantiza que esas transacciones se ejecuten como se pretende, y el validador (o la cadena) cobra la propina. Este mecanismo toma lo que era un proceso OTC fuera de la cadena (en Ethereum) y lo convierte en una subasta abierta y en la cadena, mejorando la transparencia y el acceso. Otro mecanismo es ProtoRev (Módulo de Ingresos Prototipo), que Skip desarrolló para Osmosis. ProtoRev es un módulo de arbitraje en la cadena que detecta y ejecuta automáticamente arbitrajes cíclicos (como los que involucran múltiples pools) dentro de la ejecución del bloque y acumula el beneficio en la tesorería de la cadena o en el pool comunitario. Esencialmente, Osmosis decidió que cierto "buen MEV" (como el arbitraje que mantiene los precios alineados) debería seguir ocurriendo (por eficiencia del mercado) pero el propio protocolo realiza el arbitraje y captura el beneficio, para luego distribuirlo (por ejemplo, a los stakers o como incentivos de minería de liquidez). Esto elimina la necesidad de bots de arbitraje externos en esas oportunidades y asegura que el valor permanezca en el ecosistema. ProtoRev fue el primero de su tipo en una cadena importante y demuestra cómo la integración profunda puede mitigar las externalidades del MEV: los usuarios que operan en Osmosis enfrentan menos slippage porque si existe un arbitraje después de su operación, el protocolo lo cerrará y esencialmente reembolsará el valor a Osmosis (lo que podría beneficiar indirectamente a los usuarios a través de comisiones más bajas o recompras de tokens, etc.). Además, Skip capacita a las cadenas para implementar medidas anti-MEV como el cifrado de umbral para el mempool. Por ejemplo, Osmosis, en colaboración con Skip y otros, está implementando la encriptación del mempool donde las transacciones se envían encriptadas y solo se revelan después de un tiempo fijo (similar a la idea de Anoma, pero a nivel de cadena). Aunque no es un producto de Skip per se, la arquitectura de Skip es compatible: la subasta de Skip puede ejecutarse en transacciones encriptadas basando la subasta en las ofertas declaradas en lugar de leer el contenido de la transacción. En términos de suprimir el MEV perjudicial: las reglas de consenso de Skip como "no se permite el front-running" (impuestas por verificaciones de estado) son una medida directa para detener el comportamiento malicioso. Si un validador intenta incluir un ataque sándwich, otros validadores detectarían que el resultado del estado viola la regla de no front-running (por ejemplo, podrían verificar que ninguna operación fue inmediatamente precedida y seguida por otra de la misma dirección de una manera que se aprovechó). Ese bloque sería rechazado. Sabiendo esto, los validadores ni siquiera intentarán incluir tales patrones, por lo que los usuarios están protegidos por la ley del protocolo. Skip también fomenta la quema o redistribución de los ingresos de MEV para evitar incentivos perversos. Por ejemplo, una cadena podría optar por quemar todas las ganancias de la subasta o ponerlas en un fondo comunitario en lugar de dárselas todas al proponente del bloque. Esto reduce el incentivo para que los validadores reordenen las transacciones ellos mismos, ya que podrían no beneficiarse personalmente de ello (dependiendo de la elección de la cadena). En resumen, el conjunto de herramientas de Skip permite a cada cadena extraer quirúrgicamente el MEV donde es beneficioso (por ejemplo, arbitraje para mantener la eficiencia del mercado, liquidaciones para mantener saludables los mercados de préstamos) y asegurar que ese valor sea capturado por el protocolo o los usuarios, mientras prohíbe y previene estrictamente el MEV malicioso (como el front-running perjudicial para el usuario). Es una mezcla pragmática de extracción y supresión, adaptada por la gobernanza: en lugar de una solución única para todos, Skip capacita a las comunidades para decidir qué MEV es "bueno" (y automatizar su captura) y cuál es "malo" (y prohibirlo a través de reglas de consenso). El resultado es un entorno de trading más justo en las cadenas habilitadas por Skip y una fuente de ingresos adicional que puede financiar bienes públicos o reducir costos (una de las publicaciones del blog de Skip señala que la captura justa de MEV puede usarse para "distribuir ingresos de manera justa entre todos los participantes de la red").

• Estructura de Incentivos Económicos: La introducción de Skip cambia fundamentalmente los incentivos, especialmente para los validadores y las comunidades de la cadena en Cosmos. Tradicionalmente, un validador en Cosmos podría extraer MEV reordenando privadamente las transacciones en su bloque (ya que Cosmos carece de una subasta de MEV por defecto). Con Skip, los validadores acuerdan un protocolo donde el MEV se captura a través de subastas o módulos y a menudo se comparte. Los validadores todavía se benefician: pueden recibir una parte de las ganancias de la subasta o comisiones adicionales de los mecanismos de Skip, pero es importante destacar que todos los validadores (no solo el proponente) pueden beneficiarse si se diseña de esa manera. Por ejemplo, algunas subastas de Skip pueden configurarse para que los ingresos se dividan entre todos los stakers o según las decisiones de la gobernanza, en lugar de que el proponente se lo lleve todo. Esto alinea a los validadores colectivamente para ejecutar el software de Skip porque incluso los no proponentes obtienen seguridad (sabiendo que si alguien intenta un bloque inválido, no valdrá la pena) y posiblemente ingresos. Algunas cadenas aún podrían dar al proponente la mayor parte de la comisión de la subasta de MEV (para maximizar el incentivo inmediato de incluirla), pero incluso entonces es transparente y competitivo, lo que podría decirse que reduce la posibilidad de acuerdos bajo la mesa. Cadena/Comunidad: El concepto de MEV propiedad del protocolo significa que la blockchain y sus stakeholders capturan el MEV. Por ejemplo, Osmosis dirige las ganancias de ProtoRev a su pool comunitario, convirtiendo efectivamente el MEV en un ingreso adicional del protocolo que podría financiar el desarrollo o distribuirse a los stakers de OSMO. Esto convierte a la comunidad en general en "propietaria" de ese MEV, alineando el interés de todos en extraer MEV de manera saludable. Si los usuarios saben que el MEV se destina a mejorar la cadena o la tokenómica, podrían aceptarlo más que si va a un bot aleatorio. Searchers: En el modelo de Skip, los searchers/bots independientes pueden tener menos que hacer en la cadena porque algunas oportunidades son tomadas por la lógica del protocolo (como ProtoRev) y otras se canalizan a través de subastas. Sin embargo, Skip no elimina a los searchers, sino que los canaliza para que pujen a través de las rutas adecuadas. Un searcher todavía puede intentar una estrategia compleja, pero para garantizar la inclusión en un lugar particular, debe participar en la subasta de Skip (Skip Select) enviando su bundle con una oferta. Si no lo hacen, corren el riesgo de que un validador los ignore en favor de alguien que sí pujó o que el propio mecanismo de la cadena aproveche la oportunidad. Así que los searchers en Cosmos están evolucionando para trabajar con Skip: por ejemplo, muchos arbitrajistas en Osmosis ahora envían sus arbitrajes a través del sistema de Skip. Pagan una parte a la cadena, quedándose con menos beneficio, pero es el precio a pagar. Con el tiempo, algunos roles de "searcher" podrían ser completamente absorbidos (como el arbitraje de back-running: ProtoRev lo maneja, por lo que ningún searcher externo puede competir). Esto podría reducir el spam y el esfuerzo desperdiciado en la red (no más múltiples bots compitiendo; solo una ejecución del protocolo). Usuarios: Los usuarios finales salen ganando porque tienen un entorno más justo (sin ataques de MEV sorpresa). Además, algunas configuraciones de Skip recompensan explícitamente a los usuarios: la redistribución de MEV a los usuarios es posible. Por ejemplo, una cadena podría decidir reembolsar parte de los ingresos de la subasta de MEV a los usuarios cuyas operaciones crearon ese MEV (similar a la idea de reembolso de Flashbots). Astroport, un DEX en Terra, integró Skip para compartir los ingresos de MEV con los swappers, lo que significa que si la operación de un usuario tenía MEV, parte de ese valor se le devuelve por defecto. Esto se alinea con la ética de que el MEV debe ir a los usuarios. Aunque no todas las cadenas hacen esto, la opción existe a través de la infraestructura de Skip para implementar tales esquemas. El propio Skip Protocol (la empresa/equipo) tiene un modelo de negocio en el que proporcionan estas herramientas a menudo de forma gratuita a los validadores (para fomentar la adopción), y monetizan asociándose con cadenas (B2B). Por ejemplo, Skip podría tomar una pequeña comisión del MEV capturado o cobrar a las cadenas por características avanzadas/soporte. Se menciona que Skip es gratuito para los validadores pero utiliza un modelo B2B con las cadenas. Esto significa que Skip tiene un incentivo para maximizar el MEV capturado por la cadena y la comunidad (para que la cadena esté contenta y quizás comparta una parte según el acuerdo). Pero como la gobernanza está involucrada, cualquier comisión que Skip tome suele ser acordada por la comunidad. El efecto económico es interesante: profesionaliza la extracción de MEV como un servicio proporcionado a las cadenas. Al hacerlo, desincentiva el comportamiento deshonesto: los validadores no necesitan hacer tratos turbios individualmente, pueden simplemente usar Skip y obtener un flujo fiable de ingresos adicionales que es socialmente aceptado. El comportamiento honesto (seguir las reglas del protocolo) rinde casi tanto o más beneficio que intentar hacer trampa, porque si haces trampa, tu bloque podría ser inválido o podrías ser sancionado socialmente, etc. La gobernanza juega un papel significativo: adoptar el módulo de Skip o establecer los parámetros (como el porcentaje de la subasta, la distribución de las ganancias) se hace a través de propuestas en la cadena. Esto significa que los resultados económicos (quién obtiene el MEV) son determinados en última instancia por el voto de la comunidad. Por ejemplo, el Cosmos Hub está debatiendo la adopción del SDK de constructor de Skip para posiblemente redirigir el MEV a la tesorería o a los stakers del Hub. Esta alineación a través de la gobernanza asegura que el uso del MEV sea visto como legítimo por la comunidad. Convierte el MEV de un subproducto tóxico en un recurso público que puede ser asignado (a la seguridad, usuarios, desarrolladores, etc.). En resumen, Skip remodela los incentivos de tal manera que los validadores colectivamente y los usuarios/comunidad se benefician, mientras que los tomadores de MEV oportunistas son cooptados en el sistema (como postores) o eliminados por diseño. En teoría, todos están mejor: los usuarios pierden menos valor por el MEV, los validadores siguen siendo compensados (incluso posiblemente más en total, debido a las subastas), y la red en su conjunto puede usar el MEV para fortalecerse (financieramente o a través de una experiencia más justa). Los únicos perdedores son aquellos que prosperaron con la extracción de suma cero sin devolver valor.

• Compatibilidad con Cumplimiento y Regulaciones: El marco de Skip, al empoderar la gobernanza de la cadena, en realidad facilita que las cadenas aseguren el cumplimiento o políticas específicas si lo desean. Debido a que Skip opera a nivel de protocolo, una cadena podría optar por imponer ciertas reglas de filtrado u ordenación de transacciones para cumplir con las regulaciones. Por ejemplo, si una cadena quisiera bloquear direcciones sancionadas, podría integrar una regla AnteHandler o AuctionDecorator en el módulo de Skip que invalide los bloques que contengan direcciones en la lista negra. Esto es posiblemente más simple que en Ethereum, donde la censura es una elección fuera de la cadena por parte de validadores individuales; en Cosmos con Skip, podría ser una regla para toda la cadena (aunque sería controvertido y va en contra de los ideales de descentralización para muchos). Alternativamente, una cadena podría imponer algo como "las transacciones de rampa de entrada de FIAT deben aparecer antes que otras" si así lo exige alguna ley. El conjunto de herramientas de Skip no viene con reglas de cumplimiento preestablecidas, pero es lo suficientemente flexible como para implementarlas si una comunidad se ve obligada a hacerlo (a través de la gobernanza). Por otro lado, Skip puede reforzar la resistencia a la censura: al distribuir los ingresos de MEV y dar acceso igualitario, reduce la ventaja de cualquier validador único que podría censurar para obtener beneficios. Además, si los mempools con cifrado de umbral (como el que Osmosis está añadiendo) se vuelven estándar con Skip, eso ocultará el contenido de las transacciones, dificultando la censura (como en Anoma). Skip es una infraestructura neutral: puede usarse para cumplir o resistir, dependiendo de la gobernanza. Dado que las cadenas de Cosmos a menudo son específicas de una jurisdicción (la comunidad de Terra podría preocuparse por las leyes coreanas, Kava podría preocuparse por las leyes de EE. UU., etc.), tener la opción de configurar el cumplimiento es valioso. Por ejemplo, una cadena de Cosmos permisionada (como una cadena institucional) aún podría usar el módulo de constructor de Skip, pero quizás requerir que solo las direcciones en la lista blanca puedan pujar en las subastas, etc., alineándose con sus regulaciones. La compatibilidad regulatoria también se trata de transparencia: las subastas en cadena de Skip producen un registro público de las transacciones de MEV y quién pagó qué. Esto podría satisfacer algunas preocupaciones regulatorias sobre la equidad (todos tuvieron la oportunidad de pujar, y es auditable). Es más transparente que los pagos bajo la mesa a los validadores. Además, al capturar el MEV en la cadena, Skip reduce la probabilidad de cárteles fuera de la cadena o dark pools, que los reguladores temen debido a la opacidad. Por ejemplo, sin Skip, los validadores podrían hacer tratos privados con los searchers (como se vio con los problemas de censura de los relays). Con Skip, la expectativa es que uses la subasta oficial, que es abierta y registrada, para obtener prioridad. Esto fomenta un mercado abierto accesible a todos los bots por igual, lo que es posiblemente más justo y menos propenso a la colusión (la colusión es posible, pero existe la supervisión de la gobernanza). Otro ángulo de cumplimiento: dado que Skip se ocupa de la captura de valor, si los ingresos de MEV van a un pool comunitario o tesorería, eso podría plantear preguntas (¿es una comisión, es imponible, etc.?). Pero son similares a cómo se manejan las comisiones de transacción, por lo que no hay nada fundamentalmente nuevo legalmente. En Cosmos, las comunidades de la cadena también pueden decidir cómo usar ese fondo (quemar, distribuir, etc.), lo que pueden alinear con cualquier guía legal si es necesario (por ejemplo, podrían evitar enviarlo a una fundación si eso desencadena problemas fiscales y en su lugar quemarlo). En términos de resistencia a la censura, una nota interesante: al imponer reglas de validez de bloque, Skip evita que los validadores censuren ciertas transacciones si eso rompiera las reglas. Por ejemplo, si una cadena tuviera una regla "debe incluir al menos una actualización de oráculo", un validador censor no podría simplemente omitir todas las transacciones de oráculo (que podrían provenir de ciertas fuentes) porque su bloque sería inválido. Así que, irónicamente, las reglas de Skip pueden forzar la inclusión de transacciones críticas (anti-censura) de la misma manera que podrían usarse para forzar la exclusión de las no permitidas. Todo depende de lo que establezca la comunidad. Neutralidad: La postura predeterminada de Skip es empoderar a las cadenas para "proteger a los usuarios del MEV negativo y mejorar la experiencia del usuario", lo que implica neutralidad y amigabilidad con el usuario. No hay una red central de Skip tomando decisiones; cada cadena es soberana. Skip como empresa podría asesorar o proporcionar valores predeterminados (como un formato de subasta recomendado), pero en última instancia, los poseedores de tokens de la cadena deciden. Esta descentralización de la política de MEV a la gobernanza de cada cadena puede verse como más compatible con la diversidad regulatoria: por ejemplo, una cadena con sede en EE. UU. podría implementar el cumplimiento de la OFAC si se ve presionada legalmente, sin afectar a otras cadenas. No es un solo relay censurando a través de muchas cadenas; es una elección por cadena. Desde la perspectiva de un regulador, Skip no introduce ninguna actividad ilícita adicional, simplemente reorganiza cómo se ordenan las transacciones. En todo caso, podría reducir la volatilidad (menos guerras de gas) y crear una ejecución más predecible, lo que podría ser una ventaja. En resumen, la arquitectura de Skip es altamente adaptable a las necesidades de cumplimiento mientras preserva la opción de una máxima resistencia a la censura si las comunidades priorizan eso. Mantiene el MEV a la luz del día y bajo control colectivo, lo que probablemente hace que los ecosistemas de blockchain sean más robustos contra actores maliciosos y represiones regulatorias, ya que la autogobernanza puede abordar proactivamente los peores abusos.

• Arquitectura Técnica e Implementación: Skip Protocol está estrechamente integrado en la pila del SDK de Cosmos. La entrega principal es un conjunto de módulos (por ejemplo, x/builder) y modificaciones como la implementación del mempool BlockBuster. Las cadenas de Cosmos ejecutan un consenso (Tendermint/CometBFT) que ofrece ganchos ABCI para preparar y procesar propuestas. Skip aprovecha las extensiones ABCI++ que permiten ejecutar código entre la propuesta de bloque y la finalización. Así es como impone la ordenación: PrepareProposal puede reordenar las transacciones del bloque según las reglas de los carriles antes de transmitir la propuesta, y ProcessProposal en los validadores receptores puede verificar que la ordenación y la validez del estado coincidan con las expectativas. Esta es una característica moderna (SDK de Cosmos v0.47+), y el POB de Skip es compatible con las versiones recientes del SDK. Internamente, los módulos de Skip mantienen estructuras de datos para las subastas (por ejemplo, un libro de órdenes en cadena de ofertas para la parte superior del bloque). También es probable que usen tipos de transacciones prioritarias. El README muestra un MsgAuctionBid especial y lógica personalizada para manejarlo. Así que los searchers interactúan enviando estos mensajes a través de transacciones normales de Cosmos, que luego el módulo intercepta y coloca en consecuencia. El AnteHandler del módulo de constructor (el AuctionDecorator) puede consumir ofertas de subasta y decidir los ganadores en la fase de ensamblaje del bloque. Criptográficamente, Skip no añade inherentemente nuevos requisitos criptográficos (aparte de lo que la cadena elija, como la criptografía de umbral para el mempool, que es independiente). Se basa en la honestidad de >2/3 de los validadores para hacer cumplir las reglas y no coludir para romperlas. Si una mayoría coludiera, técnicamente podrían cambiar las reglas a través de la gobernanza o ignorarlas convirtiéndola en la nueva regla de facto. Pero ese es el caso con cualquier lógica de cadena. El diseño de Skip intenta que sea mecánicamente imposible que un solo validador haga trampa a pequeña escala. Por ejemplo, cualquier intento de desviar la ordenación será detectado por otros porque es objetivo. Por lo tanto, reduce la confianza en los proponentes individuales. En términos de rendimiento, ejecutar subastas y verificaciones adicionales añade sobrecarga. Sin embargo, los bloques de Cosmos son relativamente pequeños y el tiempo entre bloques suele ser de un par de segundos, lo que es suficiente para estas operaciones en la mayoría de los casos. La simulación (pre-ejecutar transacciones para asegurar que no fallen y se cumplan las restricciones de ordenación) podría ser la parte más pesada, pero los validadores ya ejecutan los bloques normalmente, por lo que esto es similar. La presencia de múltiples carriles significa la separación del mempool: por ejemplo, una transacción podría necesitar especificar a qué carril se dirige (subasta vs. gratuito vs. predeterminado). El diseño de Skip BlockBuster de hecho tenía carriles separados como lanes/auction, lanes/free, etc., probablemente colas de mempool separadas. Eso asegura, por ejemplo, que las transacciones gratuitas no retrasen ni interfieran con las de la subasta. Es un poco como tener múltiples clases de prioridad en la programación. Otro aspecto es la seguridad y el mal comportamiento: si un proponente intenta manipular la subasta (por ejemplo, incluir su propia transacción pero afirmar que siguió las reglas), otros validadores rechazarán el bloque. El consenso de Cosmos entonces probablemente pasará al siguiente proponente, sancionando al anterior por doble firma o simplemente por fallar (dependiendo del escenario). Así que el modelo de seguridad de la cadena se encarga de eso, no se necesita una sanción especial por parte de Skip más allá del consenso existente. Se podría extender Skip para sancionar por ordenación maliciosa, pero probablemente sea innecesario si el bloque simplemente falla. Desarrollo y Herramientas: El código de Skip ha sido de código abierto (inicialmente en skip-mev/pob y ahora probablemente movido a un nuevo repositorio después de lanzamientos estables). Han pasado por testnets e iteraciones con cadenas asociadas. En la hoja de ruta, hemos visto: la Propuesta 341 de Osmosis (aprobada en otoño de 2022) para integrar ProtoRev y subastas con Skip, entregada a principios de 2023. Astroport de Terra integró el reparto de MEV con Skip en 2023. El Cosmos Hub está evaluando el "Block SDK" de Skip, que traería características similares al Hub. Otra frontera interesante es el MEV entre cadenas a través del Interchain Scheduler: la comunidad del Cosmos Hub está explorando una subasta de MEV entre cadenas donde el MEV de muchas cadenas podría negociarse en el Hub, y Skip está involucrado en esas discusiones (la investigación de Zerocap señaló el planificado programador entre cadenas de IBC). La tecnología de Skip podría servir como la columna vertebral para tales subastas entre cadenas porque ya está haciendo subastas en cadenas individuales. Eso sería análogo al objetivo multidominio de SUAVE pero dentro de Cosmos. En cuanto a las actualizaciones clave: Skip se lanzó a mediados de 2022. A mediados de 2023, tenían un lanzamiento estable de POB para el SDK v0.47+ (al que muchas cadenas se están actualizando). También recaudaron financiación inicial, lo que indica un desarrollo activo. Otro competidor en Cosmos, Mekatek, ofrece una funcionalidad similar. Esto quizás ha acelerado la hoja de ruta de Skip para mantenerse a la vanguardia. Skip continúa refinando características como carriles de transacciones privadas (quizás para ocultar tu transacción hasta que se incluya) y reglas de validez más complejas a medida que surgen casos de uso. Debido a que es modular, una cadena como dYdX (que tendrá un libro de órdenes) podría usar Skip para asegurar la equidad en el emparejamiento de órdenes en la cadena, etc., por lo que las herramientas de Skip podrían adaptarse a diferentes lógicas de aplicación. Técnicamente, la solución de Skip es más simple que construir una cadena completamente nueva: está actualizando las capacidades de las cadenas existentes. Este enfoque incremental y opcional ha permitido una adopción bastante rápida; por ejemplo, habilitar subastas en Osmosis no requirió un nuevo algoritmo de consenso, solo añadir un módulo y coordinar a los validadores para que ejecuten el software actualizado (lo cual hicieron, ya que era beneficioso y fue aprobado por la gobernanza). En resumen, la arquitectura de Skip está incrustada en el software de nodo de cada cadena, personalizando el mempool y el pipeline de propuesta de bloques. Es un enfoque de ingeniería pragmático para la ordenación justa: usar lo que ya existe (Tendermint BFT), añadir lógica para guiarlo. El trabajo pesado (como encontrar arbitrajes) puede incluso ser realizado por el propio módulo de la cadena (ProtoRev usa el código Wasm y Rust incorporado de Osmosis para escanear los pools). Así que gran parte del manejo de MEV se traslada a la cadena. Este enfoque en la cadena debe ser codificado cuidadosamente para la eficiencia y la seguridad, pero está bajo el escrutinio de la comunidad. Si alguna regla es problemática (demasiado estricta, etc.), la gobernanza puede ajustarla. Por lo tanto, técnica y socialmente, Skip convierte el MEV en solo otro parámetro de la cadena para ser optimizado y gobernado, en lugar de un salvaje oeste. Esta es una postura única habilitada por la flexibilidad de Cosmos.

Análisis Comparativo de SUAVE, Anoma, Skip y Flashbots v2​

Estos cuatro protocolos abordan el problema del MEV y la ordenación justa desde diferentes ángulos, adaptados a sus respectivos ecosistemas y filosofías de diseño. Flashbots v2 es una solución incremental y pragmática para la arquitectura actual de Ethereum: adopta las subastas de MEV pero intenta democratizar y suavizar su impacto (a través de la coordinación fuera de la cadena, la privacidad de SGX y los mecanismos de reparto). SUAVE es el plan a futuro de Flashbots para crear una plataforma de MEV entre cadenas que maximice el valor total y los beneficios para el usuario, esencialmente escalando el modelo de subasta a una red global descentralizada y que preserva la privacidad. Anoma es una reimaginación desde cero de cómo se formulan y ejecutan las transacciones, con el objetivo de eliminar las causas raíz de la ordenación injusta mediante el uso de intenciones, emparejamiento mediado por solvers y equidad criptográfica en el consenso. Skip es un enfoque de cadena soberana, que integra la equidad y la captura de MEV a nivel de protocolo por cadena, especialmente en Cosmos, a través de reglas y subastas configurables.

Cada uno tiene fortalezas y debilidades:

• Equidad y Garantías de Ordenación: Anoma ofrece la equidad teórica más fuerte (sin front-running por diseño, lotes encriptados), pero requiere un nuevo paradigma y una tecnología compleja que aún se está probando. Skip puede imponer reglas de equidad concretas en las cadenas existentes (evitando el front-running o imponiendo el primero en entrar, primero en salir dentro de los carriles), pero está limitado por lo que cada comunidad elige imponer. SUAVE y Flashbots v2 mejoran la equidad en términos de acceso (subastas abiertas en lugar de acuerdos secretos, protección contra el sniping en el mempool público), pero no evitan inherentemente que se ejecute una estrategia de MEV determinada; solo se aseguran de que pague a los usuarios o se haga de manera neutral.
• Redistribución de MEV: SUAVE y Flashbots tienen como objetivo explícito devolver el MEV a los usuarios/validadores: SUAVE a través de ofertas/reembolsos de los usuarios, Flashbots a través de competiciones de constructores y reembolsos. Skip puede canalizar el MEV a los usuarios (según se configure, por ejemplo, el caso de Astroport) o a fondos comunitarios. Anoma evita la redistribución explícita porque el objetivo es evitar la extracción en primer lugar; idealmente, los usuarios simplemente obtienen precios justos, lo que equivale a no perder valor por el MEV.
• Alcance (Dominio Único vs. Múltiple): Flashbots v2 y Skip se centran en sus propios dominios (Ethereum y cadenas individuales de Cosmos, respectivamente). SUAVE es inherentemente multidominio: ve el MEV entre cadenas como una motivación principal. Anoma también considera eventualmente intenciones multicadena, pero en las fases iniciales podría ser dentro de una instancia fractal a la vez, y luego conectarse a través de adaptadores. La subasta entre cadenas de SUAVE podría desbloquear arbitrajes y coordinación que otros no pueden hacer tan fácilmente (excepto quizás un Interchain Scheduler con la ayuda de Skip en Cosmos).
• Complejidad y Adopción: Flashbots v2 fue relativamente fácil de adoptar (un sidecar de cliente) y capturó rápidamente la mayoría de los bloques de Ethereum. Skip también aprovecha la tecnología existente y está viendo adopción en Cosmos con propuestas de gobernanza sencillas. SUAVE y Anoma son más revolucionarios: requieren nuevas redes o cambios importantes. El desafío de SUAVE será conseguir que muchas cadenas y usuarios opten por una nueva capa; el desafío de Anoma es crear un nuevo ecosistema y convencer a los desarrolladores de construir en un modelo centrado en intenciones.
• Cumplimiento y Neutralidad: Los cuatro ofrecen mejoras en la transparencia. Flashbots v2/SUAVE eliminan los elementos del bosque oscuro pero han tenido que gestionar problemas de censura; SUAVE se está construyendo explícitamente para evitar esos puntos centrales. Anoma, con privacidad por defecto, protege al máximo a los usuarios (pero podría preocupar a los reguladores debido a la actividad encriptada). El modelo de Skip da a cada cadena autonomía para encontrar un equilibrio en el cumplimiento. Si un regulador exigiera "no subastas de MEV" o "no privacidad", un Ethereum usando Flashbots podría enfrentar un conflicto, mientras que una cadena de Cosmos usando Skip podría simplemente no implementar esas características o ajustarlas. En términos de neutralidad: SUAVE y Anoma aspiran a la neutralidad creíble (todos acceden a un sistema en igualdad de condiciones; ambos son esencialmente redes de bienes públicos). Flashbots v2 es neutral al ofrecer acceso abierto, pero existe cierta centralización en el mercado de constructores (aunque mitigada por los esfuerzos de buildernet). La neutralidad de Skip depende de la gobernanza; idealmente, hace que el MEV no favorezca a ningún insider, pero podría configurarse mal y dañar la neutralidad (aunque es poco probable, ya que requeriría un consenso de gobernanza para hacerlo).
• Diferencias en la Arquitectura Técnica: Flashbots v2 y SUAVE son mercados fuera de la cadena superpuestos a la cadena: introducen roles especializados (constructores, relays, ejecutores) y usan hardware o criptografía para asegurarlos. Anoma y Skip se integran directamente en el consenso o la máquina de estados. Anoma altera el ciclo de vida de la transacción y el propio consenso (con cifrado de umbral e intenciones unificadas). Skip se engancha al consenso de Tendermint a través de ABCI++, pero no cambia el algoritmo fundamental; es un ajuste a nivel de aplicación. Esta diferencia significa que SUAVE/Flashbots pueden teóricamente servir a muchas cadenas sin que cada una se actualice (funcionan en paralelo a ellas), mientras que Anoma/Skip requieren que cada cadena o instancia use el nuevo software. SUAVE está en un punto intermedio: es una cadena separada, pero para usarla eficazmente, otras cadenas necesitan ajustes menores (para aceptar bloques construidos por SUAVE o enviar salidas a SUAVE). La sofisticación criptográfica es más alta en Anoma (ZK, MPC, criptografía de umbral, todo en uno), moderada en SUAVE (criptografía de umbral y SGX, más criptografía normal para puentes), y relativamente baja en Flashbots v2 (SGX, firmas estándar) y Skip (principalmente firmas estándar, más lo que la cadena use, como el descifrado de umbral si se opta por él).
• Etapa de Desarrollo: Flashbots v2 está en producción en Ethereum (desde septiembre de 2022). Skip está en producción en múltiples cadenas de Cosmos (desde 2022-2023 en adelante). SUAVE está en fase de testnet/devnet con partes implementándose (alguna funcionalidad de subasta en pruebas, testnet Toliman en vivo). Anoma también está en fase de testnet (un documento de visión, implementaciones parciales como la mainnet de Namada, y probablemente una testnet de Anoma que requiere códigos de invitación en 2023). Así que, en términos de datos del mundo real: Flashbots v2 y Skip han demostrado resultados (por ejemplo, Flashbots v2 entregó millones a los validadores y redujo los precios promedio del gas durante períodos de alto MEV; ProtoRev de Skip generó fondos significativos para la comunidad de Osmosis y evitó muchos ataques sándwich a medida que comenzó el cifrado de umbral). SUAVE y Anoma son prometedores pero tienen que demostrar su valía operativa y económica.

Para cristalizar estas comparaciones, la siguiente tabla resume los aspectos clave de cada protocolo lado a lado:

Cada solución aborda el problema del MEV desde una capa diferente: Flashbots v2 funciona alrededor del consenso L1, SUAVE propone una nueva capa L1.5, Anoma rediseña la propia L1, y Skip aprovecha la personalización modular de L1. En la práctica, estos enfoques no son mutuamente excluyentes e incluso podrían complementarse (por ejemplo, una cadena de Cosmos podría usar Skip internamente y también enviar intenciones a SUAVE para el MEV entre cadenas, o Ethereum podría implementar alguna equidad de orden tipo Anoma en el futuro mientras sigue usando Flashbots para los mercados de constructores). La tabla ilustra sus propiedades comparativas: Flashbots v2 ya está ofreciendo mejoras en Ethereum pero todavía extrae MEV (solo que de manera más equitativa y eficiente); SUAVE apunta a un resultado de sinergia máxima donde todos cooperan a través de una red; su éxito dependerá de la adopción generalizada y la entrega técnica de la privacidad y descentralización prometidas; Anoma ofrece quizás la represión de MEV más poderosa al cambiar completamente cómo funcionan las transacciones, pero enfrenta el gran desafío de arrancar un nuevo ecosistema y probar su complejo protocolo; Skip logra un equilibrio pragmático para Cosmos, permitiendo a las comunidades gobernar activamente el MEV y la equidad en sus propios términos; es menos radical que Anoma pero más integrado que Flashbots, y ya está mostrando resultados tangibles en Cosmos.

Conclusión y Perspectivas​

La supresión de MEV y la ordenación justa siguen siendo uno de los "Problemas del Milenio de las criptomonedas". Los cuatro protocolos analizados —Flashbots v2, SUAVE, Anoma y Skip— representan un espectro de soluciones: desde mitigaciones inmediatas en marcos existentes hasta cambios de paradigma totales en el procesamiento de transacciones. Flashbots v2 ha demostrado el poder de los mercados de MEV abiertos para reducir el caos y redistribuir el valor, aunque navegando por compromisos como la censura, que se están abordando a través de la descentralización. Muestra que los cambios incrementales (como las subastas PBS y los mempools privados) pueden reducir significativamente el dolor del MEV a corto plazo. SUAVE, el siguiente paso de Flashbots, lleva esa ética hacia un escenario unificado entre cadenas; si tiene éxito, podríamos ver un futuro en el que los usuarios reciban pagos rutinariamente por el MEV que crean sus operaciones y donde la producción de bloques en muchas redes sea colaborativa y encriptada para la equidad. Anoma apunta a una evolución más fundamental: al eliminar el concepto de transacciones prioritarias y reemplazarlo con un sistema de emparejamiento de intenciones, podría eliminar clases enteras de MEV y desbloquear dApps financieras más expresivas. Su ordenación justa a nivel de consenso (a través de cifrado de umbral y subastas por lotes) es un vistazo de cómo las propias blockchains pueden proporcionar garantías de equidad, no solo complementos fuera de la cadena. Skip Protocol, mientras tanto, ejemplifica un término medio en un contexto multicadena: da a las cadenas individuales la agencia para decidir cómo equilibrar los ingresos de MEV y la protección del usuario. Su adopción temprana en Cosmos muestra que muchos de los efectos nocivos del MEV pueden abordarse hoy con una ingeniería de protocolo reflexiva y el consentimiento de la comunidad.

De cara al futuro, podemos esperar una polinización cruzada de ideas: los investigadores de Ethereum están estudiando el consenso de ordenación justa y el cifrado de umbral (inspirados por proyectos como Anoma y el mempool encriptado de Osmo) para su posible inclusión en soluciones L1 o L2. SUAVE de Flashbots podría interactuar con las cadenas de Cosmos (quizás incluso a través de Skip) mientras busca ser agnóstico a la cadena. El concepto de intención de Anoma podría influir en el diseño de aplicaciones incluso en plataformas tradicionales (por ejemplo, CoW Swap en Ethereum ya utiliza un modelo de solver; se puede ver como una dApp "tipo Anoma"). El éxito de Skip puede alentar a otros ecosistemas (Polkadot, Solana, etc.) a adoptar controles de MEV similares dentro del protocolo. Un tema clave es la alineación económica: todos estos protocolos se esfuerzan por alinear los incentivos de quienes aseguran la red con el bienestar de los usuarios, de modo que explotar a los usuarios no sea rentable o no sea posible. Esto es crucial para la salud a largo plazo de los ecosistemas de blockchain y para evitar la centralización.

En resumen, SUAVE, Anoma, Skip y Flashbots v2 contribuyen cada uno con piezas del rompecabezas hacia la ordenación justa y la mitigación de MEV. Flashbots v2 ha establecido una plantilla para las subastas de MEV que otros emulan, Skip ha demostrado que la imposición en la cadena es viable, Anoma ha expandido la imaginación de lo que es posible al reconstruir el modelo de transacción, y SUAVE busca unificar y descentralizar las ganancias de los últimos años. La solución definitiva puede implicar elementos de todos: subastas globales que preservan la privacidad, interfaces de usuario centradas en intenciones, reglas de equidad a nivel de cadena y construcción de bloques colaborativa. A partir de 2025, la lucha contra la injusticia inducida por el MEV está en pleno apogeo: estos protocolos están convirtiendo el MEV de una inevitabilidad oscura en una parte gestionada, incluso productiva, de la economía cripto, mientras se acercan cada vez más al ideal de "la mejor ejecución para los usuarios con la infraestructura más descentralizada".

Aquí tienes un resumen consolidado del informe sobre innovaciones en la Experiencia de Desarrollador Web3 (DevEx).

Resumen Ejecutivo​

La experiencia de desarrollador Web3 ha avanzado significativamente en 2024‑2025, impulsada por innovaciones en lenguajes de programación, cadenas de herramientas e infraestructura de despliegue. Los desarrolladores reportan mayor productividad y satisfacción gracias a herramientas más rápidas, lenguajes más seguros y flujos de trabajo simplificados. Este resumen consolida hallazgos sobre cinco cadenas de herramientas clave (Solidity, Move, Sway, Foundry y Cairo 1.0) y dos tendencias principales: despliegue de rollup con “un clic” y recarga en caliente de contratos inteligentes.

Comparación de Cadenas de Herramientas para Desarrolladores Web3​

Cada cadena de herramientas ofrece ventajas distintas, adaptándose a diferentes ecosistemas y filosofías de desarrollo.

• Solidity (EVM): Sigue siendo el lenguaje más dominante gracias a su enorme ecosistema, bibliotecas extensas (p. ej., OpenZeppelin) y frameworks maduros como Hardhat y Foundry. Aunque carece de características nativas como macros, su adopción masiva y fuerte apoyo comunitario lo convierten en la opción predeterminada para Ethereum y la mayoría de las L2 compatibles con EVM.
• Move (Aptos / Sui): Prioriza seguridad y verificación formal. Su modelo basado en recursos y la herramienta Move Prover ayudan a prevenir errores comunes como la reentrancia por diseño. Esto lo hace ideal para aplicaciones financieras de alta seguridad, aunque su ecosistema es más pequeño y está centrado en las blockchains Aptos y Sui.
• Sway (FuelVM): Diseñado para máxima productividad del desarrollador, permitiendo escribir contratos, scripts y pruebas en un solo lenguaje similar a Rust. Aprovecha la arquitectura de alto rendimiento y basada en UTXO de la Fuel Virtual Machine, lo que lo convierte en una opción poderosa para aplicaciones intensivas en rendimiento en la red Fuel.
• Foundry (Toolkit EVM): Un conjunto de herramientas transformador para Solidity que ha revolucionado el desarrollo en EVM. Ofrece compilación y pruebas extremadamente rápidas, permitiendo escribir pruebas directamente en Solidity. Funciones como fuzz testing, fork de mainnet y “cheatcodes” lo han convertido en la elección principal de más de la mitad de los desarrolladores de Ethereum.
• Cairo 1.0 (Starknet): Representa una gran mejora de DevEx para el ecosistema Starknet. La transición a una sintaxis de alto nivel inspirada en Rust y herramientas modernas (como el gestor de paquetes Scarb y Starknet Foundry) ha hecho que desarrollar para ZK‑rollups sea mucho más rápido e intuitivo. Aunque algunas herramientas, como depuradores, aún están madurando, la satisfacción de los desarrolladores ha aumentado notablemente.

Innovaciones Clave de DevEx​

Dos tendencias principales están cambiando la forma en que los desarrolladores construyen y despliegan aplicaciones descentralizadas.

Despliegue de Rollup con “Un Clic”​

Lanzar una blockchain personalizada (L2 / appchain) se ha vuelto radicalmente más sencillo.

• Fundamento: Frameworks como el OP Stack de Optimism proporcionan un plano modular y de código abierto para construir rollups.
• Plataformas: Servicios como Caldera y Conduit han creado plataformas de Rollup‑as‑a‑Service (RaaS). Ofrecen paneles web que permiten a los desarrolladores desplegar una rollup de mainnet o testnet personalizada en minutos, con mínima experiencia en ingeniería de blockchain.
• Impacto: Facilita la experimentación rápida, reduce la barrera de entrada para crear cadenas específicas de aplicaciones y simplifica DevOps, permitiendo que los equipos se concentren en su aplicación en lugar de en la infraestructura.

Recarga en Caliente de Contratos Inteligentes​

Esta innovación lleva el bucle de retroalimentación instantáneo del desarrollo web moderno al espacio blockchain.

• Concepto: Herramientas como Scaffold‑ETH 2 automatizan el ciclo de desarrollo. Cuando un desarrollador guarda un cambio en un contrato inteligente, la herramienta recompila automáticamente, lo redeploya a una red local y actualiza el front‑end para reflejar la nueva lógica.
• Impacto: La recarga en caliente elimina pasos manuales repetitivos y acorta drásticamente el bucle de iteración. Hace que el proceso sea más atractivo, reduce la curva de aprendizaje para nuevos desarrolladores y fomenta pruebas frecuentes, lo que lleva a código de mayor calidad.

Conclusión​

El panorama de desarrollo Web3 está madurando a un ritmo acelerado. La convergencia de lenguajes más seguros, herramientas más rápidas como Foundry y despliegues de infraestructura simplificados mediante plataformas RaaS está cerrando la brecha entre blockchain y desarrollo de software tradicional. Estas mejoras de DevEx son tan críticas como las innovaciones a nivel de protocolo, ya que empoderan a los desarrolladores para crear aplicaciones más complejas y seguras en menos tiempo. Esto, a su vez, impulsa el crecimiento y la adopción de todo el ecosistema blockchain.

Fuentes:

• Solidity Developer Survey 2024 – Soliditylang (2025)
• Moncayo Labs on Aptos Move vs Solidity (2024)
• Aptos Move Prover intro – Monethic (2025)
• Fuel Labs – Fuel & Sway Documentation (2024); Fuel Book (2024)
• Spearmanrigoberto – Foundry vs Hardhat (2023)
• Medium (Rosario Borgesi) – Building Dapps with Scaffold‑ETH 2 (2024)
• Starknet/Cairo developer survey – Cairo‑lang.org (2024)
• Starknet Dev Updates – Starknet.io (2024–2025)
• Solidity forum – Macro preprocessor discussion (2023)
• Optimism OP Stack overview – CoinDesk (2025)
• Caldera rollup platform overview – Medium (2024)
• Conduit platform recap – Conduit Blog (2025)
• Blockchain DevEx literature review – arXiv (2025)

Introducción​

El rápido crecimiento de las blockchains de Capa 1 y Capa 2 ha fragmentado la experiencia de usuario de Web3. Hoy en día, los usuarios hacen malabares con múltiples wallets, redes y puentes de tokens solo para realizar tareas complejas que abarcan varias cadenas. La abstracción de cadena y la arquitectura centrada en la intención han surgido como paradigmas clave para simplificar este panorama. Al abstraer los detalles específicos de cada cadena y permitir a los usuarios actuar sobre intenciones (resultados deseados) en lugar de crear transacciones explícitas por cadena, estos enfoques prometen una experiencia cross-chain unificada y sin interrupciones. Este informe profundiza en los principios básicos de la abstracción de cadena, el diseño de modelos de ejecución centrados en la intención, implementaciones del mundo real (como Wormhole y Etherspot), los fundamentos técnicos (relayers, smart wallets, etc.) y los beneficios de UX para desarrolladores y usuarios finales. También resumimos las ideas de EthCC 2025, donde la abstracción de cadena y las intenciones fueron temas candentes, y proporcionamos una tabla comparativa de los diferentes enfoques de los protocolos.

Principios de la Abstracción de Cadena​

La abstracción de cadena se refiere a cualquier tecnología o marco que presenta múltiples blockchains a los usuarios y desarrolladores como si fueran un único entorno unificado. La motivación es eliminar la fricción causada por la heterogeneidad de las cadenas. En la práctica, la abstracción de cadena significa:

• Interfaces Unificadas: En lugar de gestionar wallets y endpoints RPC separados para cada blockchain, los usuarios interactúan a través de una única interfaz que oculta los detalles de la red. Los desarrolladores pueden construir dApps sin desplegar contratos separados en cada cadena o escribir lógica de puente personalizada para cada red.
• Sin Puentes Manuales: Mover activos o datos entre cadenas ocurre en segundo plano. Los usuarios no ejecutan manualmente transacciones de puente de bloqueo/acuñación (lock/mint) ni intercambian por tokens de puente; la capa de abstracción lo maneja automáticamente. Por ejemplo, un usuario podría proporcionar liquidez en un protocolo independientemente de en qué cadena resida la liquidez, y el sistema enrutará los fondos apropiadamente.
• Abstracción de las Tarifas de Gas: Los usuarios ya no necesitan tener el token nativo de cada cadena para pagar el gas en esa cadena. La capa de abstracción puede patrocinar las tarifas de gas o permitir que el gas se pague en un activo de la elección del usuario. Esto reduce la barrera de entrada, ya que no es necesario adquirir ETH, MATIC, SOL, etc., por separado.
• Lógica Agnóstica a la Red: La lógica de la aplicación se vuelve agnóstica a la cadena. Los contratos inteligentes o los servicios fuera de la cadena se coordinan para ejecutar las acciones del usuario en cualquier cadena(s) necesaria(s), sin requerir que el usuario cambie manualmente de red o firme múltiples transacciones. En esencia, la experiencia del usuario es la de una "meta-cadena" o una capa de aplicación agnóstica a la blockchain.

La idea central es permitir que los usuarios se centren en qué quieren lograr, no en qué cadena o cómo lograrlo. Una analogía familiar son las aplicaciones web que abstraen la ubicación del servidor: así como un usuario no necesita saber qué servidor o base de datos toca su solicitud, un usuario de Web3 no debería necesitar saber qué cadena o puente se utiliza para una acción. Al enrutar las transacciones a través de una capa unificada, la abstracción de cadena reduce la fragmentación del ecosistema multi-cadena actual.

Motivación: El impulso hacia la abstracción de cadena proviene de los puntos débiles en los flujos de trabajo cross-chain actuales. Gestionar wallets separadas por cadena y realizar operaciones cross-chain de varios pasos (intercambiar en la Cadena A, puentear a la Cadena B, volver a intercambiar en la Cadena B, etc.) es tedioso y propenso a errores. La liquidez fragmentada y las wallets incompatibles también limitan el crecimiento de las dApps en todos los ecosistemas. La abstracción de cadena aborda esto conectando cohesivamente los ecosistemas. Es importante destacar que trata a Ethereum y sus muchas L2s y sidechains como parte de una única experiencia de usuario. EthCC 2025 enfatizó que esto es crítico para la adopción masiva: los ponentes argumentaron que un futuro de Web3 verdaderamente centrado en el usuario "debe abstraer las blockchains", haciendo que el mundo multi-cadena se sienta tan fácil como una sola red.

Arquitectura Centrada en la Intención: De Transacciones a Intenciones​

Las interacciones tradicionales de blockchain están centradas en la transacción: un usuario crea y firma explícitamente una transacción que ejecuta operaciones específicas (llama a una función de contrato, transfiere un token, etc.) en una cadena elegida. En un contexto multi-cadena, lograr un objetivo complejo podría requerir muchas de estas transacciones en diferentes redes, cada una iniciada manualmente por el usuario en la secuencia correcta. La arquitectura centrada en la intención invierte este modelo. En lugar de microgestionar transacciones, el usuario declara una intención —un objetivo de alto nivel o un resultado deseado— y deja que un sistema automatizado descubra las transacciones necesarias para cumplirla.

Bajo un diseño basado en la intención, un usuario podría decir: "Intercambiar 100 USDC en Base por 100 USDT en Arbitrum". Esta intención encapsula el qué (intercambiar un activo por otro en una cadena de destino) sin prescribir el cómo. Un agente especializado (a menudo llamado solver) se encarga de completarlo. El solver determinará cómo ejecutar mejor el intercambio entre cadenas; por ejemplo, podría puentear el USDC de Base a Arbitrum usando un puente rápido y luego realizar un intercambio a USDT, o usar un protocolo de intercambio cross-chain directo, lo que sea que produzca el mejor resultado. El usuario firma una única autorización, y el solver maneja la secuencia compleja en el backend, incluyendo encontrar la ruta óptima, enviar las transacciones necesarias en cada cadena, e incluso adelantar las tarifas de gas requeridas o asumir el riesgo intermedio.

Cómo las Intenciones Empoderan la Ejecución Flexible: Al dar al sistema la libertad de decidir cómo cumplir una solicitud, el diseño centrado en la intención permite capas de ejecución mucho más inteligentes y flexibles que las transacciones de usuario fijas. Algunas ventajas:

• Enrutamiento Óptimo: Los solvers pueden optimizar por costo, velocidad o fiabilidad. Por ejemplo, múltiples solvers podrían competir para cumplir la intención de un usuario, y una subasta on-chain puede seleccionar al que ofrece el mejor precio (p. ej., la mejor tasa de cambio o las tarifas más bajas). Esta competencia reduce los costos para el usuario. El protocolo Mayan Swift de Wormhole es un ejemplo que incorpora una subasta inglesa on-chain en Solana para cada intención, cambiando la competencia de una carrera de "el primero en llegar" a una oferta basada en el precio para mejores resultados para el usuario. El solver que puede ejecutar el intercambio de manera más rentable para el usuario gana la oferta y lleva a cabo el plan, asegurando que el usuario obtenga el mayor valor. Este tipo de descubrimiento dinámico de precios no es posible cuando un usuario pre-especifica una única ruta en una transacción regular.
• Resiliencia y Flexibilidad: Si un puente o DEX no está disponible o es subóptimo en el momento, un solver puede elegir una ruta alternativa. La intención sigue siendo la misma, pero la capa de ejecución puede adaptarse a las condiciones de la red. Las intenciones, por lo tanto, permiten estrategias de ejecución programable —p. ej., dividir una orden o reintentar por otra ruta— todo invisible para el usuario final, a quien solo le importa que se logre su objetivo.
• Acciones Atómicas Multi-Cadena: Las intenciones pueden abarcar lo que tradicionalmente serían múltiples transacciones en diferentes cadenas. Los marcos de ejecución se esfuerzan por hacer que toda la secuencia tenga una sensación atómica o al menos sea gestionada en caso de fallo. Por ejemplo, el solver podría considerar la intención cumplida solo cuando todas las sub-transacciones (puente, intercambio, etc.) están confirmadas, y revertir o compensar si algo falla. Esto asegura que la acción de alto nivel del usuario se complete en su totalidad o no se complete en absoluto, mejorando la fiabilidad.
• Descarga de Complejidad: Las intenciones simplifican drásticamente el papel del usuario. El usuario no necesita entender qué puentes o intercambios usar, cómo dividir la liquidez o cómo programar las operaciones; todo eso se descarga a la infraestructura. Como dice un informe, "los usuarios se centran en el qué, no en el cómo". Un beneficio directo es la experiencia del usuario: interactuar con aplicaciones de blockchain se vuelve más como usar una aplicación Web2 (donde un usuario simplemente solicita un resultado y el servicio maneja el proceso).

En esencia, una arquitectura centrada en la intención eleva el nivel de abstracción de transacciones de bajo nivel a objetivos de alto nivel. La comunidad de Ethereum está tan interesada en este modelo que la Fundación Ethereum ha introducido el Open Intents Framework (OIF), un estándar abierto y una arquitectura de referencia para construir sistemas de intención cross-chain. El OIF define interfaces estándar (como el formato de intención ERC-7683) sobre cómo se crean, comunican y liquidan las intenciones entre cadenas, para que muchas soluciones diferentes (puentes, relayers, mecanismos de subasta) puedan conectarse modularmente. Esto fomenta todo un ecosistema de solvers y protocolos de liquidación que pueden interoperar. El auge de las intenciones se basa en la necesidad de hacer que Ethereum y sus rollups se sientan "como una sola cadena" desde una perspectiva de UX: lo suficientemente rápido y sin fricciones como para que moverse entre L2s o sidechains ocurra en segundos sin dolores de cabeza para el usuario. Estándares tempranos como ERC-7683 (para un formato y ciclo de vida de intención estandarizados) incluso han obtenido el apoyo de líderes como Vitalik Buterin, lo que subraya el impulso detrás de los diseños centrados en la intención.

Resumen de Beneficios Clave: Para resumir, las arquitecturas centradas en la intención aportan varios beneficios clave: (1) UX Simplificada – los usuarios declaran lo que quieren y el sistema se encarga del resto; (2) Fluidez Cross-Chain – las operaciones que abarcan múltiples redes se manejan sin problemas, tratando efectivamente a muchas cadenas como una sola; (3) Escalabilidad para Desarrolladores – los desarrolladores de dApps pueden llegar a usuarios y liquidez en muchas cadenas sin reinventar la rueda para cada una, porque la capa de intención proporciona ganchos estandarizados para la ejecución cross-chain. Al desacoplar qué se necesita hacer de cómo/dónde se hace, las intenciones actúan como el puente entre la innovación amigable para el usuario y la compleja interoperabilidad detrás de escena.

Bloques de Construcción Técnicos de la Abstracción Cross-Chain​

Implementar la abstracción de cadena y la ejecución basada en intenciones requiere una pila de mecanismos técnicos que trabajen en conjunto. Los componentes clave incluyen:

• Relayers de Mensajería Cross-Chain: En el núcleo de cualquier sistema multi-cadena hay una capa de mensajería que puede transportar datos y valor de manera fiable entre blockchains. Protocolos como Wormhole, Hyperlane, Axelar, LayerZero y otros proporcionan esta capacidad retransmitiendo mensajes (a menudo con pruebas o atestaciones de validadores) desde una cadena de origen a una o más cadenas de destino. Estos mensajes pueden llevar comandos como "ejecuta esta intención" o "acuña este activo" en la cadena de destino. Una red de relayers robusta es crucial para el enrutamiento unificado de transacciones: sirve como el "servicio postal" entre cadenas. Por ejemplo, la red de 19 nodos Guardian de Wormhole observa eventos en las cadenas conectadas y firma un VAA (aprobación de acción verificable) que puede ser enviado a cualquier otra cadena para probar que un evento ocurrió. Esto desacopla la acción de cualquier cadena única, permitiendo un comportamiento agnóstico a la cadena. Los relayers modernos se centran en ser agnósticos a la cadena (soportando muchos tipos de cadenas) y descentralizados por seguridad. Wormhole, por ejemplo, se extiende más allá de las cadenas basadas en EVM para soportar Solana, cadenas de Cosmos, etc., lo que lo convierte en una opción versátil para la comunicación cross-chain. La capa de mensajería a menudo también maneja el ordenamiento, los reintentos y las garantías de finalidad para las transacciones cross-chain.

• Wallets de Contrato Inteligente (Abstracción de Cuentas): La abstracción de cuentas (p. ej., ERC-4337 de Ethereum) reemplaza las cuentas de propiedad externa con cuentas de contrato inteligente que pueden ser programadas con lógica de validación personalizada y capacidades de transacción de múltiples pasos. Esto es una base para la abstracción de cadena porque una smart wallet puede servir como la única meta-cuenta del usuario que controla los activos en todas las cadenas. Proyectos como Etherspot utilizan wallets de contrato inteligente para habilitar características como la agrupación de transacciones (batching) y las claves de sesión entre cadenas. La intención de un usuario podría ser empaquetada como una única operación de usuario (en términos de 4337) que el contrato de la wallet luego expande en múltiples sub-transacciones en diferentes redes. Las smart wallets también pueden integrar paymasters (patrocinadores) para pagar las tarifas de gas en nombre del usuario, permitiendo una verdadera abstracción de gas (el usuario podría pagar en una stablecoin o no pagar en absoluto). Mecanismos de seguridad como las claves de sesión (claves temporales con permisos limitados) permiten a los usuarios aprobar intenciones que involucran múltiples acciones sin múltiples solicitudes, mientras limitan el riesgo. En resumen, la abstracción de cuentas proporciona el contenedor de ejecución programable que puede interpretar una intención de alto nivel y orquestar los pasos necesarios como una serie de transacciones (a menudo a través de los relayers).

• Orquestación de Intenciones y Solvers: Por encima de la capa de mensajería y de la wallet vive la red de solvers de intenciones – los cerebros que descubren cómo cumplir las intenciones. En algunas arquitecturas, esta lógica está on-chain (p. ej., un contrato de subasta on-chain que empareja órdenes de intención con solvers, como en la subasta de Solana de Wormhole para Mayan Swift). En otras, son agentes fuera de la cadena que monitorean un mempool de intenciones o un libro de órdenes (por ejemplo, el Open Intents Framework proporciona un solver de referencia en TypeScript que escucha nuevos eventos de intención y luego envía transacciones para cumplirlos). Los solvers típicamente deben manejar: encontrar rutas de liquidez (a través de DEXes, puentes), descubrimiento de precios (asegurando que el usuario obtenga una tasa justa), y a veces cubrir costos intermedios (como publicar colateral o asumir el riesgo de finalidad – entregando fondos al usuario antes de que la transferencia cross-chain esté completamente finalizada, acelerando así la UX a cierto riesgo para el solver). Un sistema centrado en la intención bien diseñado a menudo implica competencia entre solvers para asegurar que la intención del usuario se ejecute de manera óptima. Los solvers pueden ser incentivados económicamente (p. ej., ganan una tarifa o un beneficio de arbitraje por cumplir la intención). Mecanismos como las subastas de solvers o la agrupación (batching) pueden ser utilizados para maximizar la eficiencia. Por ejemplo, si múltiples usuarios tienen intenciones similares, un solver podría agruparlas para minimizar las tarifas de puente por usuario.

• Liquidez Unificada y Abstracción de Tokens: Mover activos entre cadenas introduce el clásico problema de la liquidez fragmentada y los tokens envueltos (wrapped tokens). Las capas de abstracción de cadena a menudo abstraen los tokens mismos – con el objetivo de dar al usuario la experiencia de un único activo que puede ser utilizado en muchas cadenas. Un enfoque son los tokens omnichain (donde un token puede existir nativamente en múltiples cadenas bajo un suministro total único, en lugar de muchas versiones envueltas incompatibles). Wormhole introdujo las Transferencias de Tokens Nativos (NTT) como una evolución de los puentes tradicionales de bloqueo y acuñación (lock-and-mint): en lugar de infinitos tokens IOU "puenteados", el marco NTT trata a los tokens desplegados en varias cadenas como un solo activo con controles compartidos de acuñación/quema. En la práctica, puentear un activo bajo NTT significa quemar en el origen y acuñar en el destino, manteniendo un único suministro circulante. Este tipo de unificación de liquidez es crucial para que la abstracción de cadena pueda "teletransportar" activos sin confundir al usuario con múltiples representaciones de tokens. Otros proyectos utilizan redes o pools de liquidez (p. ej., Connext o Axelar) donde los proveedores de liquidez suministran capital en cada cadena para intercambiar activos, de modo que los usuarios puedan efectivamente comerciar un activo por su equivalente en otra cadena en un solo paso. El ejemplo del fondo Securitize SCOPE es ilustrativo: un token de fondo institucional se hizo multichain de tal manera que los inversores pueden suscribir o redimir en Ethereum u Optimism, y detrás de escena el protocolo de Wormhole mueve el token e incluso lo convierte en formas que generan rendimiento, eliminando la necesidad de puentes manuales o múltiples wallets para los usuarios.

• Capas de Ejecución Programables: Finalmente, ciertas innovaciones on-chain potencian flujos de trabajo cross-chain más complejos. El soporte para multi-llamadas atómicas y la programación de transacciones ayudan a coordinar intenciones de múltiples pasos. Por ejemplo, los Bloques de Transacciones Programables (PTBs) de la blockchain Sui permiten agrupar múltiples acciones (como intercambios, transferencias, llamadas) en una única transacción atómica. Esto puede simplificar el cumplimiento de intenciones cross-chain en Sui al asegurar que todos los pasos ocurran o ninguno lo haga, con una sola firma del usuario. En Ethereum, propuestas como EIP-7702 (código de contrato inteligente para EOAs) extienden las capacidades de las cuentas de usuario para soportar cosas como gas patrocinado y lógica de múltiples pasos incluso en la capa base. Además, se pueden emplear entornos de ejecución especializados o enrutadores cross-chain – p. ej., algunos sistemas enrutan todas las intenciones a través de una L2 o hub particular que coordina las acciones cross-chain (el usuario podría simplemente interactuar con ese hub). Ejemplos incluyen proyectos como la L1 de Push Protocol (Push Chain) que está siendo diseñada como una capa de liquidación dedicada para operaciones agnósticas a la cadena, con contratos inteligentes universales y finalidad de sub-segundo para acelerar las interacciones cross-chain. Aunque no son universalmente adoptados, estos enfoques ilustran el espectro de técnicas utilizadas para realizar la abstracción de cadena: desde la orquestación puramente fuera de la cadena hasta el despliegue de nueva infraestructura on-chain construida específicamente para la ejecución de intenciones cross-chain.

En resumen, la abstracción de cadena se logra superponiendo estos componentes: una capa de enrutamiento (relayers que envían mensajes entre cadenas), una capa de cuenta (smart wallets que pueden iniciar acciones en cualquier cadena), y una capa de ejecución (solvers, liquidez y contratos que llevan a cabo las intenciones). Cada pieza es necesaria para asegurar que, desde la perspectiva del usuario, interactuar con una dApp a través de múltiples blockchains sea tan fluido como usar una aplicación de una sola cadena.

Caso de Estudio 1: Wormhole – Enrutamiento Basado en Intenciones y Agnóstico a la Cadena​

Wormhole es un protocolo de interoperabilidad cross-chain líder que ha evolucionado de un puente de tokens a una red integral de paso de mensajes con funcionalidad basada en intenciones. Su enfoque hacia la abstracción de cadena es proporcionar una capa de enrutamiento de mensajes uniforme que conecta más de 20 cadenas (incluyendo cadenas EVM y no-EVM como Solana), y sobre eso, construir protocolos de aplicación agnósticos a la cadena. Los elementos clave de la arquitectura de Wormhole incluyen:

• Capa de Mensajes Genérica: En su núcleo, Wormhole es un puente genérico de publicación/suscripción. Los validadores (Guardianes) observan eventos en cada cadena conectada y firman un VAA (acción verificable) que puede ser enviado en cualquier otra cadena para reproducir el evento o llamar a un contrato de destino. Este diseño genérico significa que los desarrolladores pueden enviar instrucciones o datos arbitrarios cross-chain, no solo transferencias de tokens. Wormhole asegura que los mensajes se entreguen y verifiquen de manera consistente, abstrayendo si el origen fue Ethereum, Solana u otra cadena.

• Transferencias de Tokens Agnósticas a la Cadena: El Token Bridge original de Wormhole (Portal) utilizaba un enfoque de bloqueo y acuñación. Recientemente, Wormhole introdujo las Transferencias de Tokens Nativos (NTT), un marco mejorado para tokens multichain. Con NTT, los activos pueden ser emitidos nativamente en cada cadena (evitando tokens envueltos fragmentados), mientras que Wormhole maneja la contabilidad de las quemas y acuñaciones entre cadenas para mantener el suministro sincronizado. Para los usuarios, esto se siente como si un token se "teletransportara" entre cadenas: depositan en una cadena y retiran el mismo activo en otra, con Wormhole gestionando la contabilidad de acuñación/quema. Esta es una forma de abstracción de tokens que oculta la complejidad de los diferentes estándares de tokens y direcciones en cada cadena.

• Protocolos xApp Basados en la Intención: Reconociendo que puentear tokens es solo una parte de la UX cross-chain, Wormhole ha desarrollado protocolos de nivel superior para cumplir las intenciones de los usuarios, como intercambios o transferencias con gestión de tarifas de gas. En 2023–2024, Wormhole colaboró con el agregador de DEX cross-chain Mayan para lanzar dos protocolos centrados en la intención, a menudo llamados xApps (aplicaciones cross-chain) en el ecosistema de Wormhole: Mayan Swift y Mayan MCTP (Protocolo de Transferencia Multichain).

  • Mayan Swift se describe como un "protocolo de intención cross-chain flexible" que esencialmente permite a un usuario solicitar un intercambio de tokens de la Cadena A a la Cadena B. El usuario firma una única transacción en la cadena de origen bloqueando sus fondos y especificando su resultado deseado (p. ej., "quiero al menos X cantidad del token Y en la cadena de destino para el tiempo T"). Esta intención (la orden) es luego recogida por solvers. De manera única, Wormhole Swift utiliza una subasta on-chain en Solana para llevar a cabo un descubrimiento de precios competitivo para la intención. Los solvers monitorean un contrato especial de Solana; cuando se crea una nueva orden de intención, ofertan comprometiendo cuánto del token de salida pueden entregar. Durante un corto período de subasta (p. ej., 3 segundos), las ofertas compiten para subir el precio. El mejor postor (quien ofrece la tasa más favorable al usuario) gana y se le concede el derecho de cumplir el intercambio. Wormhole luego lleva un mensaje a la cadena de destino autorizando a ese solver a entregar los tokens al usuario, y otro mensaje de vuelta para liberar los fondos bloqueados del usuario al solver como pago. Este diseño asegura que la intención del usuario se cumpla al mejor precio posible de manera descentralizada, mientras que el usuario solo tuvo que interactuar con su cadena de origen. También desacopla el intercambio cross-chain en dos pasos (bloquear fondos, luego cumplir en el destino) para minimizar el riesgo. El diseño centrado en la intención aquí muestra cómo la abstracción permite una ejecución inteligente: en lugar de que un usuario elija un puente o DEX en particular, el sistema encuentra la ruta y el precio óptimos automáticamente.

  • Mayan MCTP se centra en transferencias de activos cross-chain con gestión de gas y tarifas. Aprovecha el CCTP (Protocolo de Transferencia Cross-Chain) de Circle —que permite que el USDC nativo se queme en una cadena y se acuñe en otra— como base para la transferencia de valor, y utiliza la mensajería de Wormhole para la coordinación. En una transferencia MCTP, la intención de un usuario podría ser simplemente "mover mi USDC de la Cadena A a la Cadena B (y opcionalmente intercambiarlo por otro token en B)". El contrato de la cadena de origen acepta los tokens y un destino deseado, luego inicia una quema a través de CCTP y simultáneamente publica un mensaje de Wormhole que lleva metadatos como la dirección de destino del usuario, el token deseado en el destino, e incluso una entrega de gas (gas drop) (una cantidad de los fondos puenteados para convertir en gas nativo en el destino). En la cadena de destino, una vez que Circle acuña el USDC, un relayer de Wormhole asegura que los metadatos de la intención se entreguen y verifiquen. El protocolo puede entonces, por ejemplo, intercambiar automáticamente una porción de USDC por el token nativo para pagar el gas, y entregar el resto a la wallet del usuario (o a un contrato especificado). Esto proporciona un puente de un solo paso con gas incluido: el usuario no tiene que ir a adquirir gas en la nueva cadena o realizar un intercambio separado por gas. Todo está codificado en la intención y manejado por la red. MCTP demuestra así cómo la abstracción de cadena puede manejar la abstracción de tarifas y transferencias fiables en un solo flujo. El papel de Wormhole es transmitir de forma segura la intención y la prueba de que los fondos se movieron (a través de CCTP) para que la solicitud del usuario se cumpla de extremo a extremo.

Ilustración de la arquitectura de intercambio centrada en la intención de Wormhole (Mayan Swift). En este diseño, el usuario bloquea activos en la cadena de origen y define un resultado (intención). Los solvers pujan en una subasta on-chain por el derecho a cumplir esa intención. El solver ganador utiliza mensajes de Wormhole para coordinar el desbloqueo de fondos y la entrega del resultado en la cadena de destino, todo mientras se asegura de que el usuario reciba el mejor precio por su intercambio.

• UX Unificada y Flujos de un Solo Clic: Las aplicaciones basadas en Wormhole ofrecen cada vez más acciones cross-chain de un solo clic. Por ejemplo, Wormhole Connect es un SDK de frontend que las dApps y wallets integran para permitir a los usuarios puentear activos con un solo clic; detrás de escena, llama al puente de tokens de Wormhole y (opcionalmente) a relayers que depositan gas en la cadena de destino. En el caso de uso del fondo Securitize SCOPE, un inversor en Optimism puede comprar tokens del fondo que originalmente residen en Ethereum, sin puentear nada manualmente; la capa de liquidez de Wormhole mueve automáticamente los tokens y incluso los convierte en una forma que genera rendimiento, de modo que el usuario solo ve un producto de inversión unificado. Tales ejemplos resaltan el ethos de la abstracción de cadena: el usuario realiza una acción de alto nivel (invertir en un fondo, intercambiar X por Y) y la plataforma maneja la mecánica cross-chain silenciosamente. La retransmisión de mensajes estándar de Wormhole y la entrega automática de gas (a través de servicios como el Automatic Relayer de Wormhole o el Gas Service de Axelar integrado en algunos flujos) significan que el usuario a menudo firma solo una transacción en su cadena de origen y recibe el resultado en la cadena de destino sin más intervención. Desde la perspectiva del desarrollador, Wormhole proporciona una interfaz uniforme para llamar a contratos entre cadenas, por lo que construir lógica cross-chain es más simple.

En resumen, el enfoque de Wormhole hacia la abstracción de cadena es proporcionar la infraestructura (relayers descentralizados + contratos estandarizados en cada cadena) sobre la cual otros pueden construir para crear experiencias agnósticas a la cadena. Al soportar una amplia variedad de cadenas y ofrecer protocolos de nivel superior (como la subasta de intenciones y la transferencia con gestión de gas), Wormhole permite a las aplicaciones tratar el ecosistema blockchain como un todo conectado. Los usuarios se benefician al no tener que preocuparse más por en qué cadena están o cómo puentear; ya sea moviendo liquidez o haciendo un intercambio multi-cadena, las xApps centradas en la intención de Wormhole buscan hacerlo tan fácil como una interacción de una sola cadena. El cofundador de Wormhole, Robinson Burkey, señaló que este tipo de infraestructura ha alcanzado una "madurez a escala institucional", permitiendo incluso a los emisores de activos regulados operar sin problemas a través de las redes y abstraer las restricciones específicas de la cadena para sus usuarios.

Caso de Estudio 2: Etherspot – La Abstracción de Cuentas se Une a las Intenciones​

Etherspot aborda el problema de la UX cross-chain desde la perspectiva de las wallets y las herramientas para desarrolladores. Proporciona un SDK de Abstracción de Cuentas y una pila de protocolos de intención que los desarrolladores pueden integrar para dar a sus usuarios una experiencia multi-cadena unificada. En efecto, Etherspot combina wallets de contrato inteligente con lógica de abstracción de cadena para que la única cuenta inteligente de un usuario pueda operar en muchas redes con una fricción mínima. Las características clave de la arquitectura de Etherspot incluyen:

• Wallet Inteligente Modular (Abstracción de Cuentas): Cada usuario de Etherspot obtiene una wallet de contrato inteligente (estilo ERC-4337) que puede ser desplegada en múltiples cadenas. Etherspot contribuyó a estándares como ERC-7579 (interfaz mínima de cuentas inteligentes modulares) para asegurar que estas wallets sean interoperables y actualizables. El contrato de la wallet actúa como el agente del usuario y puede ser personalizado con módulos. Por ejemplo, un módulo podría habilitar una vista de saldo unificada – la wallet puede reportar el agregado de los fondos de un usuario en todas las cadenas. Otro módulo podría habilitar claves de sesión, para que el usuario pueda aprobar una serie de acciones con una sola firma. Debido a que la wallet está presente en cada cadena, puede iniciar directamente transacciones localmente cuando sea necesario (con los bundlers y relayers del backend de Etherspot orquestando la coordinación cross-chain).

• Agrupador de Transacciones (Bundler) y Paymasters: Etherspot opera un servicio de agrupador (llamado Skandha) que recolecta operaciones de usuario de las smart wallets, y un servicio de paymaster (Arka) que puede patrocinar las tarifas de gas. Cuando un usuario activa una intención a través de Etherspot, efectivamente firma un mensaje a su contrato de wallet. La infraestructura de Etherspot (el bundler) luego traduce eso en transacciones reales en las cadenas relevantes. Crucialmente, puede agrupar múltiples acciones – p. ej., un intercambio en un DEX en una cadena y una transferencia de puente a otra cadena – en una meta-transacción que el contrato de la wallet del usuario ejecutará paso a paso. El paymaster significa que el usuario podría no necesitar pagar ningún gas de L1; en su lugar, la dApp o un tercero podría cubrirlo, o la tarifa podría tomarse en otro token. Esto realiza la abstracción de gas en la práctica (una gran victoria en usabilidad). De hecho, Etherspot destaca que con las próximas características de Ethereum como EIP-7702, incluso las Cuentas de Propiedad Externa podrían ganar capacidades sin gas similares a las wallets de contrato, pero las cuentas inteligentes de Etherspot ya permiten intenciones sin gas a través de paymasters hoy.

• API de Intención y Solvers (Pulse): Sobre la capa de cuenta, Etherspot proporciona una API de Intención de alto nivel conocida como Etherspot Pulse. Pulse es el motor de abstracción de cadena de Etherspot que los desarrolladores pueden usar para habilitar intenciones cross-chain en sus dApps. En una demostración de Etherspot Pulse a finales de 2024, mostraron cómo un usuario podía realizar un intercambio de tokens de Ethereum a un activo en Base, usando una interfaz de aplicación React simple con un solo clic. Bajo el capó, Pulse manejó la transacción multi-cadena de forma segura y eficiente. Las características clave de Pulse incluyen Saldos Unificados (el usuario ve todos los activos como una sola cartera independientemente de la cadena), Seguridad con Claves de Sesión (privilegios limitados para ciertas acciones para evitar aprobaciones constantes), Swaps Basados en Intención e Integración de Solvers. En otras palabras, el desarrollador solo llama a una intención como swap(tokenA en Cadena1 -> tokenB en Cadena2 para el usuario) a través del SDK de Etherspot, y Pulse descubre cómo hacerlo, ya sea enrutando a través de una red de liquidez como Socket o llamando a un DEX cross-chain. Etherspot se ha integrado con varios puentes y agregadores de DEX para encontrar rutas óptimas (es probable que también utilice algunos de los conceptos del Open Intents Framework, dada la participación de Etherspot en la comunidad de intenciones de Ethereum).

• Educación y Estándares: Etherspot ha sido un defensor vocal de los estándares de abstracción de cadena. Ha publicado contenido educativo explicando las intenciones y cómo "los usuarios declaran su resultado deseado, mientras que los solvers manejan el proceso de backend", enfatizando la UX simplificada y la fluidez cross-chain. Enumeran beneficios como que los usuarios no necesitan preocuparse por puentes o gas, y las dApps ganan escalabilidad al acceder fácilmente a múltiples cadenas. Etherspot también está colaborando activamente con proyectos del ecosistema: por ejemplo, hace referencia al Open Intents Framework de la Fundación Ethereum y explora la integración de nuevos estándares de mensajería cross-chain (ERC-7786, 7787, etc.) a medida que surgen. Al alinearse con estándares comunes, Etherspot asegura que su formato de intención o interfaz de wallet pueda funcionar en conjunto con otras soluciones (como Hyperlane, Connext, Axelar, etc.) elegidas por el desarrollador.

• Casos de Uso y UX para Desarrolladores: Para los desarrolladores, usar Etherspot significa que pueden agregar características cross-chain sin reinventar la rueda. Una dApp de DeFi puede permitir a un usuario depositar fondos en cualquier cadena en la que tenga activos, y Etherspot abstraerá las diferencias de cadena. Una aplicación de juegos podría permitir a los usuarios firmar una transacción para reclamar un NFT en una L2 y que se puentee automáticamente a Ethereum si es necesario para el comercio. El SDK de Etherspot esencialmente ofrece llamadas a funciones agnósticas a la cadena – los desarrolladores llaman a métodos de alto nivel (como un transfer() o swap() unificado) y el SDK se encarga de localizar los fondos del usuario, moverlos si es necesario y actualizar el estado en todas las cadenas. Esto reduce significativamente el tiempo de desarrollo para el soporte multi-cadena (el equipo afirma una reducción de hasta el 90% en el tiempo de desarrollo al usar su plataforma de abstracción de cadena). Otro aspecto es el RPC Playground y las herramientas de depuración que Etherspot construyó para los flujos de AA, que facilitan la prueba de operaciones de usuario complejas que pueden involucrar múltiples redes. Todo esto está orientado a hacer que la integración de la abstracción de cadena sea tan sencilla como integrar una API de pagos en Web2.

Desde la perspectiva del usuario final, una aplicación impulsada por Etherspot puede ofrecer una incorporación y una experiencia diaria mucho más fluidas. Los nuevos usuarios pueden iniciar sesión con inicio de sesión social o correo electrónico (si la dApp utiliza el módulo de cuenta social de Etherspot) y obtener una cuenta inteligente automáticamente, sin necesidad de gestionar frases semilla para cada cadena. Pueden recibir tokens de cualquier cadena en su única dirección (la dirección de la smart wallet es la misma en todas las cadenas compatibles) y verlos en una sola lista. Si quieren realizar una acción (intercambiar, prestar, etc.) en una cadena donde no tienen el activo o el gas, el protocolo de intención enrutará automáticamente sus fondos y acciones para que suceda. Por ejemplo, un usuario con USDC en Polygon que quiera participar en un pool de DeFi de Ethereum podría simplemente hacer clic en "Invertir en el Pool"; la aplicación (a través de Etherspot) intercambiará el USDC por el activo requerido, lo puenteará a Ethereum, lo depositará en el contrato del pool e incluso manejará las tarifas de gas tomando una pequeña porción del USDC, todo en un solo flujo. El usuario nunca se enfrenta a errores de "por favor, cambie a la red X" o "necesita ETH para el gas"; esos se manejan detrás de escena. Esta experiencia de un solo clic es exactamente lo que busca la abstracción de cadena.

El CEO de Etherspot, Michael Messele, habló en EthCC 2025 sobre la "abstracción de cadena avanzada" y destacó que hacer que Web3 sea verdaderamente agnóstico a la blockchain puede empoderar tanto a usuarios como a desarrolladores al mejorar la interoperabilidad, la escalabilidad y la UX. Las propias contribuciones de Etherspot, como la demostración de Pulse de intercambios cross-chain con una sola intención, muestran que la tecnología ya está aquí para simplificar drásticamente las interacciones cross-chain. Como lo posiciona Etherspot, las intenciones son el puente entre las posibilidades innovadoras de un ecosistema multi-cadena y la usabilidad que los usuarios finales esperan. Con soluciones como la suya, las dApps pueden ofrecer experiencias "sin fricción" donde las diferencias de cadena desaparecen en el fondo, acelerando la adopción masiva de Web3.

Mejoras en la Experiencia de Usuario y Desarrollador​

Tanto la abstracción de cadena como las arquitecturas centradas en la intención están, en última instancia, al servicio de una mejor experiencia de usuario (UX) y experiencia de desarrollador (DX) en un mundo multi-cadena. Algunas de las mejoras notables incluyen:

• Incorporación Fluida (Onboarding): Los nuevos usuarios pueden ser incorporados sin preocuparse por en qué blockchain están. Por ejemplo, a un usuario se le podría dar una única cuenta inteligente que funcione en todas partes, posiblemente creada con un inicio de sesión social. Pueden recibir cualquier token o NFT en esta cuenta desde cualquier cadena sin confusión. Ya no es necesario que un recién llegado aprenda a cambiar de red en MetaMask o a proteger múltiples frases semilla. Esto reduce significativamente la barrera de entrada, ya que usar una dApp se siente más cercano al registro en una aplicación Web2. Los proyectos que implementan la abstracción de cuentas a menudo permiten la creación de wallets basadas en correo electrónico u OAuth, siendo la cuenta inteligente resultante agnóstica a la cadena.

• Acciones Cross-Chain con un Solo Clic: Quizás la ganancia de UX más visible es condensar lo que solían ser flujos de trabajo de múltiples pasos y múltiples aplicaciones en uno o dos clics. Por ejemplo, un intercambio de tokens cross-chain anteriormente podría requerir: intercambiar el Token A por un activo puenteable en la Cadena 1, ir a una interfaz de puente para enviarlo a la Cadena 2, luego intercambiarlo por el Token B en la Cadena 2, y gestionar las tarifas de gas en ambas cadenas. Con los sistemas centrados en la intención, el usuario simplemente solicita "Intercambiar A en la Cadena 1 por B en la Cadena 2" y confirma una vez. Todos los pasos intermedios (incluida la adquisición de gas en la Cadena 2 si es necesario) se automatizan. Esto no solo ahorra tiempo, sino que también reduce las posibilidades de error del usuario (usar el puente incorrecto, enviar a la dirección incorrecta, etc.). Es similar a la conveniencia de reservar un vuelo con múltiples escalas a través de un solo sitio de viajes en lugar de comprar manualmente cada tramo por separado.

• Sin Ansiedad por el Gas Nativo: Los usuarios no necesitan intercambiar constantemente por pequeñas cantidades de ETH, MATIC, AVAX, etc., solo para pagar las transacciones. La abstracción de las tarifas de gas significa que o la dApp cubre el gas (y quizás cobra una tarifa en el token transaccionado o a través de un modelo de suscripción), o el sistema convierte un poco del activo del usuario automáticamente para pagar las tarifas. Esto tiene un gran impacto psicológico: elimina una clase de avisos confusos (no más errores de "gas insuficiente") y permite a los usuarios centrarse en las acciones que les importan. Varias charlas en EthCC 2025 señalaron la abstracción de gas como una prioridad, p. ej., el EIP-7702 de Ethereum incluso permitirá que las cuentas EOA tengan gas patrocinado en el futuro. En la práctica actual, muchos protocolos de intención entregan una pequeña cantidad del activo de salida como gas en la cadena de destino para el usuario, o utilizan paymasters conectados a las operaciones del usuario. El resultado: un usuario puede, por ejemplo, mover USDC de Arbitrum a Polygon sin tocar nunca ETH en ninguno de los lados, y aun así tener su wallet de Polygon capaz de realizar transacciones inmediatamente a su llegada.

• Gestión Unificada de Activos: Para los usuarios finales, tener una vista unificada de activos y actividades en todas las cadenas es una mejora importante en la calidad de vida. La abstracción de cadena puede presentar una cartera combinada, por lo que tu 1 ETH en la red principal y 2 ETH de stETH puenteado en Optimism podrían mostrarse simplemente como "saldo de ETH". Si tienes stablecoins en USD en cinco cadenas diferentes, una wallet agnóstica a la cadena podría mostrar tu valor total en USD y permitirte gastar de él sin que tengas que puentear manualmente. Esto se siente más como una aplicación bancaria tradicional que muestra un único saldo (incluso si los fondos están distribuidos en varias cuentas detrás de escena). Los usuarios pueden establecer preferencias como "usar la red más barata por defecto" o "maximizar el rendimiento" y el sistema podría asignar automáticamente las transacciones a la cadena apropiada. Mientras tanto, todo su historial de transacciones podría verse en una sola línea de tiempo, independientemente de la cadena. Tal coherencia es importante para una adopción más amplia: oculta la complejidad de la blockchain bajo metáforas familiares.

• Productividad Mejorada para Desarrolladores: Desde el lado del desarrollador, las plataformas de abstracción de cadena significan no más escribir código específico de la cadena para cada integración. En lugar de integrar cinco puentes diferentes y seis intercambios para asegurar la cobertura de activos y redes, un desarrollador puede integrar una API de protocolo de intención que los abstrae. Esto no solo ahorra esfuerzo de desarrollo, sino que también reduce el mantenimiento: a medida que surgen nuevas cadenas o puentes, los mantenedores de la capa de abstracción se encargan de la integración, y la dApp simplemente se beneficia de ello. El resumen semanal de Etherspot destacó que soluciones como la plataforma de abstracción de cadena de Okto afirman reducir el tiempo de desarrollo de dApps multi-cadena hasta en un 90% al proporcionar soporte listo para usar para las principales cadenas y características como la optimización de la liquidez. En esencia, los desarrolladores pueden centrarse en la lógica de la aplicación (p. ej., un producto de préstamos, un juego) en lugar de en las complejidades de las transferencias cross-chain o la gestión del gas. Esto abre la puerta para que más desarrolladores de Web2 entren en Web3, ya que pueden usar SDK de nivel superior en lugar de necesitar una profunda experiencia en blockchain para cada cadena.

• Nuevas Experiencias Componibles: Con las intenciones y la abstracción de cadena, los desarrolladores pueden crear experiencias que antes eran demasiado complejas de intentar. Por ejemplo, las estrategias de yield farming cross-chain pueden automatizarse: un usuario podría hacer clic en "maximizar el rendimiento de mis activos" y un protocolo de intención podría mover activos entre cadenas a las mejores granjas de rendimiento, incluso haciéndolo continuamente a medida que cambian las tasas. Los juegos pueden tener activos y misiones que abarcan múltiples cadenas sin requerir que los jugadores puenteeen manualmente los objetos; el backend del juego (usando un marco de intención) se encarga de la teletransportación de objetos o la sincronización de estado. Incluso la gobernanza puede beneficiarse: una DAO podría permitir a un usuario votar una vez y que ese voto se aplique en los contratos de gobernanza de todas las cadenas relevantes a través de mensajes cross-chain. El efecto general es la componibilidad: así como DeFi en una sola cadena permitió la composición de protocolos como si fueran piezas de Lego, las capas de intención cross-chain permiten que los protocolos en diferentes cadenas se compongan. Una intención de usuario podría desencadenar acciones en múltiples dApps a través de cadenas (p. ej., desenvolver un NFT en una cadena y venderlo en un mercado en otra), lo que crea flujos de trabajo más ricos que las operaciones aisladas de una sola cadena.

• Redes de Seguridad y Fiabilidad: Un aspecto de UX a menudo subestimado es el manejo de errores. En las primeras interacciones cross-chain, si algo salía mal (fondos atascados en un puente, una transacción que fallaba después de enviar fondos, etc.), los usuarios se enfrentaban a una pesadilla de solución de problemas en múltiples plataformas. Los marcos de intención pueden incorporar lógica de reintento, seguros o mecanismos de protección del usuario. Por ejemplo, un solver podría asumir el riesgo de finalidad, entregando los fondos del usuario en el destino de inmediato (en segundos) y esperando la finalidad más lenta de la cadena de origen por sí mismo. Esto significa que el usuario no se queda esperando minutos u horas para la confirmación. Si una intención falla parcialmente, el sistema puede revertir o reembolsar automáticamente. Debido a que todo el flujo está orquestado con pasos conocidos, hay más margen para compensar al usuario si algo se rompe. Algunos protocolos están explorando el depósito en garantía y los seguros para operaciones cross-chain como parte de la ejecución de la intención, lo que sería imposible si el usuario estuviera saltando manualmente a través de aros; soportaría ese riesgo solo. En resumen, la abstracción puede hacer que la experiencia general no solo sea más fluida, sino también más segura y confiable para el usuario promedio.

Todas estas mejoras apuntan a una única tendencia: reducir la carga cognitiva de los usuarios y abstraer la fontanería de la blockchain al fondo. Cuando se hace bien, los usuarios pueden ni siquiera darse cuenta de qué cadenas están utilizando; simplemente acceden a características y servicios. Los desarrolladores, por otro lado, pueden construir aplicaciones que aprovechan la liquidez y las bases de usuarios en muchas redes desde una única base de código. Es un cambio de complejidad desde los bordes (aplicaciones de usuario) hacia el medio (protocolos de infraestructura), lo cual es una progresión natural a medida que la tecnología madura. El tono de EthCC 2025 se hizo eco de este sentimiento, con la "infraestructura fluida y componible" citada como un objetivo primordial para la comunidad de Ethereum.

Perspectivas de EthCC 2025​

La conferencia EthCC 2025 (celebrada en julio de 2025 en Cannes) subrayó cuán centrales se han vuelto la abstracción de cadena y el diseño basado en intenciones en el ecosistema de Ethereum. Un bloque dedicado de sesiones se centró en unificar las experiencias de usuario a través de las redes. Las principales conclusiones del evento incluyen:

• Alineación de la Comunidad sobre la Abstracción: Múltiples charlas de líderes de la industria repitieron el mismo mensaje: simplificar la experiencia multi-cadena es crítico para la próxima ola de adopción de Web3. Michael Messele (Etherspot) habló sobre avanzar "hacia un futuro agnóstico a la blockchain", Alex Bash (wallet Zerion) discutió "unificar la UX de Ethereum con abstracción e intenciones", y otros introdujeron estándares concretos como ERC-7811 para la abstracción de cadena de stablecoins. El propio título de una charla, "No hay futuro para Web3 sin la Abstracción de Cadena", encapsuló el sentimiento de la comunidad. En otras palabras, hay un amplio acuerdo en que sin resolver la usabilidad cross-chain, Web3 no alcanzará su máximo potencial. Esto representa un cambio con respecto a años anteriores donde el escalado de L1 o L2 era el enfoque principal; ahora que muchas L2s están activas, conectarlas para los usuarios es la nueva frontera.

• El Papel de Ethereum como un Hub: Los paneles de EthCC destacaron que Ethereum se está posicionando no solo como una cadena entre muchas, sino como la base de un ecosistema multi-cadena. La seguridad de Ethereum y su abstracción de cuentas 4337 en la red principal pueden servir como la base común que subyace a la actividad en varias L2s y sidechains. En lugar de competir con sus rollups, Ethereum (y por extensión, la comunidad de Ethereum) está invirtiendo en protocolos que hacen que toda la red de cadenas se sienta unificada. Esto se ejemplifica con el apoyo de la Fundación Ethereum a proyectos como el Open Intents Framework, que abarca muchas cadenas y rollups. El ambiente en EthCC fue que la madurez de Ethereum se demuestra al abrazar un "ecosistema de ecosistemas", donde el diseño centrado en el usuario (independientemente de la cadena) es primordial.

• Stablecoins y Activos del Mundo Real (RWAs) como Catalizadores: Un tema interesante fue la intersección de la abstracción de cadena con stablecoins y RWAs (Activos del Mundo Real). Las stablecoins fueron señaladas repetidamente como una "fuerza de anclaje" en DeFi, y varias charlas (p. ej., sobre la abstracción de cadena de stablecoins ERC-7811) analizaron cómo hacer que el uso de stablecoins sea agnóstico a la cadena. La idea es que a un usuario promedio no debería importarle en qué cadena reside su USDC o DAI; debería tener el mismo valor y ser utilizable en cualquier lugar sin problemas. Vimos esto con el fondo de Securitize usando Wormhole para volverse multichain, abstrayendo efectivamente un producto institucional a través de las cadenas. Las discusiones en EthCC sugirieron que resolver la UX cross-chain para stablecoins y RWAs es un gran paso hacia finanzas basadas en blockchain más amplias, ya que estos activos demandan experiencias de usuario fluidas para su adopción por parte de instituciones y usuarios convencionales.

• Entusiasmo y Herramientas para Desarrolladores: Talleres y eventos paralelos (como el Multichain Day) presentaron a los desarrolladores las nuevas herramientas disponibles. Proyectos de hackathon y demostraciones mostraron cómo las APIs de intención y los SDKs de abstracción de cadena (de varios equipos) podían usarse para crear dApps cross-chain en días. Había una emoción palpable de que el "Santo Grial" de la UX de Web3 —usar múltiples redes sin darse cuenta— está al alcance. El equipo del Open Intents Framework realizó un taller para principiantes explicando cómo construir una aplicación habilitada para intenciones, probablemente usando su solver y contratos de referencia. Los desarrolladores que habían luchado con el puenteo y el despliegue multi-cadena en el pasado estaban interesados en estas soluciones, como lo demostraron las sesiones de preguntas y respuestas (según se informó informalmente en las redes sociales durante la conferencia).

• Anuncios y Colaboración: EthCC 2025 también sirvió como escenario para anunciar colaboraciones entre proyectos en este espacio. Por ejemplo, se insinuó una asociación entre un proveedor de wallets y un protocolo de intención o entre un proyecto de puente y un proyecto de abstracción de cuentas. Un anuncio concreto fue la integración de Wormhole con el ecosistema de Stacks (trayendo la liquidez de Bitcoin a los flujos cross-chain), que no era directamente abstracción de cadena para Ethereum, pero ejemplificaba la conectividad en expansión a través de ecosistemas cripto tradicionalmente separados. La presencia de proyectos como Zerion (wallet), Safe (cuentas inteligentes), Connext, Socket, Axelar, etc., todos discutiendo la interoperabilidad, señaló que muchas piezas del rompecabezas se están uniendo.

En general, EthCC 2025 pintó un cuadro de una comunidad que se une en torno a la innovación cross-chain centrada en el usuario. La frase "infraestructura componible" se usó para describir el objetivo: todas estas L1s, L2s y protocolos deberían formar un tejido cohesivo sobre el cual las aplicaciones puedan construir sin necesidad de unir las cosas ad-hoc. La conferencia dejó claro que la abstracción de cadena y las intenciones no son solo palabras de moda, sino áreas activas de desarrollo que atraen talento e inversión serios. El liderazgo de Ethereum en esto —a través de financiación, establecimiento de estándares y provisión de una capa base robusta— fue reafirmado en el evento.

Comparación de Enfoques para la Abstracción de Cadena e Intenciones​

La siguiente tabla compara varios protocolos y marcos prominentes que abordan la experiencia de usuario/desarrollador cross-chain, destacando su enfoque y características clave:

(Leyenda de la tabla: AA = Abstracción de Cuentas, ChA = Abstracción de Cadena, AMB = puente de mensajería arbitraria)

Cada uno de los enfoques anteriores aborda el desafío de la UX cross-chain desde un ángulo ligeramente diferente: algunos se centran en la wallet/cuenta del usuario, otros en la mensajería de la red, y otros en la capa de API para desarrolladores, pero todos comparten el objetivo de hacer que las interacciones de blockchain sean agnósticas a la cadena e impulsadas por la intención. Es importante destacar que estas soluciones no son mutuamente excluyentes; de hecho, a menudo se complementan entre sí. Por ejemplo, una aplicación podría usar la smart wallet + paymasters de Etherspot, con el estándar de Open Intents para formatear la intención del usuario, y luego usar Axelar o Connext bajo el capó como la capa de ejecución para puentear y realizar acciones. La tendencia emergente es la componibilidad entre las propias herramientas de abstracción de cadena, construyendo en última instancia hacia una Internet de las Blockchains donde los usuarios navegan libremente.

Conclusión​

La tecnología blockchain está experimentando un cambio de paradigma desde redes aisladas y operaciones manuales hacia una experiencia unificada e impulsada por la intención. La abstracción de cadena y la arquitectura centrada en la intención están en el corazón de esta transformación. Al abstraer las complejidades de múltiples cadenas, permiten una Web3 centrada en el usuario en la que las personas interactúan con aplicaciones descentralizadas sin necesidad de entender qué cadena están usando, cómo puentear activos o cómo adquirir gas en cada red. La infraestructura —relayers, cuentas inteligentes, solvers y puentes— maneja colaborativamente esos detalles, de manera muy similar a como los protocolos subyacentes de Internet enrutan paquetes sin que los usuarios conozcan la ruta.

Los beneficios en la experiencia del usuario ya son tangibles: una incorporación más fluida, intercambios cross-chain con un solo clic e interacciones de dApps verdaderamente fluidas entre ecosistemas. Los desarrolladores también se ven empoderados por SDKs y estándares de nivel superior que simplifican drásticamente la construcción para un mundo multi-cadena. Como se vio en EthCC 2025, existe un fuerte consenso en la comunidad de que estos desarrollos no son solo mejoras emocionantes, sino requisitos fundamentales para la próxima fase de crecimiento de Web3. Proyectos como Wormhole y Etherspot demuestran que es posible mantener la descentralización y la confianza mientras se ofrece una facilidad de uso similar a la de Web2.

Mirando hacia el futuro, podemos esperar una mayor convergencia de estos enfoques. Estándares como las intenciones ERC-7683 y la abstracción de cuentas ERC-4337 probablemente se adoptarán ampliamente, asegurando la compatibilidad entre plataformas. Más puentes y redes se integrarán con marcos de intención abiertos, aumentando la liquidez y las opciones para que los solvers cumplan las intenciones de los usuarios. Eventualmente, el término "cross-chain" podría desaparecer, ya que las interacciones no se pensarán en términos de cadenas distintas en absoluto, de la misma manera que los usuarios de la web no piensan en qué centro de datos llegó su solicitud. En cambio, los usuarios simplemente invocarán servicios y gestionarán activos en un ecosistema de blockchain unificado.

En conclusión, la abstracción de cadena y el diseño centrado en la intención están convirtiendo el sueño multi-cadena en realidad: entregando los beneficios de la diversa innovación de blockchain sin la fragmentación. Al centrar los diseños en las intenciones del usuario y abstraer el resto, la industria está dando un paso importante hacia la creación de aplicaciones descentralizadas tan intuitivas y potentes como los servicios centralizados de hoy, cumpliendo la promesa de Web3 para una audiencia más amplia. La infraestructura aún está evolucionando, pero su trayectoria es clara: una experiencia Web3 fluida e impulsada por la intención está en el horizonte, y redefinirá cómo percibimos e interactuamos con las blockchains.

Fuentes: La información en este informe fue recopilada de una variedad de recursos actualizados, incluyendo documentación de protocolos, publicaciones de blogs de desarrolladores y charlas de EthCC 2025. Las referencias clave incluyen los documentos oficiales de Wormhole sobre sus protocolos de intención cross-chain, la serie de blogs técnicos de Etherspot sobre abstracción de cuentas y cadenas, y las notas de la versión del Open Intents Framework de la Fundación Ethereum, entre otros, como se cita a lo largo del texto. Cada cita se denota en el formato 【fuente†líneas】 para señalar el material original que respalda las afirmaciones realizadas.

Introducción​

Anunciado para su lanzamiento público el 3 de mayo de 2023, después de una extensa prueba de tres ondas, la cadena de bloques Sui introdujo un sistema de precios de gas innovador diseñado para beneficiar tanto a usuarios como a validadores. En su corazón está el Precio de Gas de Referencia (RGP), una tarifa base de gas a nivel de red que los validadores acuerdan al comienzo de cada época (aproximadamente 24 horas).

Este sistema busca crear un ecosistema mutuamente beneficioso para los poseedores del token SUI, los validadores y los usuarios finales al proporcionar costos de transacción bajos y predecibles mientras recompensa a los validadores por un comportamiento eficiente y fiable. Este informe ofrece un análisis profundo de cómo se determina el RGP, los cálculos que realizan los validadores, su impacto en la economía de la red, su evolución mediante la gobernanza y cómo se compara con otros modelos de gas de blockchain.

El Mecanismo de Precio de Gas de Referencia (RGP)​

El RGP de Sui no es un valor estático, sino que se restablece cada época mediante un proceso dinámico impulsado por los validadores.

• La Encuesta de Precio de Gas: Al inicio de cada época, cada validador envía su “precio de reserva”, es decir, el precio mínimo de gas que está dispuesto a aceptar para procesar transacciones. El protocolo ordena estas presentaciones por participación y fija el RGP de esa época en el percentil ponderado por participación del 2/3. Este diseño asegura que los validadores que representan una supermayoría (al menos dos tercios) del total de participación estén dispuestos a procesar transacciones a ese precio, garantizando un nivel fiable de servicio.

• Cadencia de Actualización y Requisitos: Aunque el RGP se establece cada época, los validadores deben gestionar activamente sus cotizaciones. Según la guía oficial, los validadores deben actualizar su cotización de precio de gas al menos una vez por semana. Además, si hay un cambio significativo en el valor del token SUI, como una fluctuación del 20 % o más, los validadores deben actualizar su cotización de inmediato para que el RGP refleje con precisión las condiciones de mercado actuales.

• Regla de Conteo y Distribución de Recompensas: Para garantizar que los validadores respeten el RGP acordado, Sui emplea una “regla de conteo”. A lo largo de una época, los validadores monitorizan el desempeño de sus pares, verificando si procesan puntualmente las transacciones con precio RGP. Este monitoreo genera una puntuación de desempeño para cada validador. Al final de la época, esas puntuaciones se usan para calcular un multiplicador de recompensa que ajusta la parte de recompensas de participación de cada validador.

  • Los validadores que tuvieron buen desempeño reciben un multiplicador de ≥ 1, aumentando sus recompensas.
  • Los validadores que se retrasaron, demoraron o no procesaron transacciones al precio RGP reciben un multiplicador de < 1, recortando efectivamente una parte de sus ganancias.

Este sistema de dos partes crea una poderosa estructura de incentivos. Disuade a los validadores de cotizar un precio irrealmente bajo que no puedan sostener, ya que la penalización financiera por bajo rendimiento sería severa. En su lugar, los validadores están motivados a presentar el precio más bajo que puedan manejar de forma sostenible y eficiente.

Operaciones de Validadores: Cálculo de la Cotización del Precio de Gas​

Desde la perspectiva de un validador, establecer la cotización del RGP es una tarea operativa crítica que impacta directamente la rentabilidad. Requiere construir pipelines de datos y capas de automatización para procesar una serie de entradas tanto on‑chain como off‑chain. Las entradas clave incluyen:

• Unidades de gas ejecutadas por época
• Recompensas y subsidios de participación por época
• Contribuciones al fondo de almacenamiento
• Precio de mercado del token SUI
• Gastos operativos (hardware, hosting en la nube, mantenimiento)

El objetivo es calcular una cotización que garantice recompensas netas positivas. El proceso implica varias fórmulas clave:

1. Calcular el Costo Operativo Total: Determina los gastos del validador en moneda fiat para una época dada.

   $$\text{Cost}_{\text{epoch}} = (\text{Total Gas Units Executed}_{\text{epoch}}) \times (\text{Cost in \$ per Gas Unit}_{\text{epoch}})$$

2. Calcular las Recompensas Totales: Determina los ingresos totales del validador en moneda fiat, provenientes tanto de subsidios del protocolo como de tarifas de transacción.

   $$\text{\$Rewards}_{\text{epoch}} = (\text{Total Stake Rewards in SUI}_{\text{epoch}}) \times (\text{SUI Token Price})$$

   Donde Total Stake Rewards es la suma de cualquier Stake Subsidies provisto por el protocolo y las Gas Fees recaudadas de las transacciones.

3. Calcular las Recompensas Netas: Medida definitiva de la rentabilidad para un validador.

   $$\text{\$Net Rewards}_{\text{epoch}} = \text{\$Rewards}_{\text{epoch}} - \text{\$Cost}_{\text{epoch}}$$

Al modelar sus costos y recompensas esperados a diferentes niveles de RGP, los validadores pueden determinar una cotización óptima para presentar en la Encuesta de Precio de Gas.

Tras el lanzamiento en mainnet, Sui fijó el RGP inicial en 1 000 MIST (1 SUI = 10⁹ MIST) durante la primera o segunda semana. Esto proporcionó un período operativo estable para que los validadores recopilaran datos suficientes de actividad de red y establecieran sus procesos de cálculo antes de que el mecanismo dinámico de encuesta entrara en pleno efecto.

Impacto en el Ecosistema Sui​

El mecanismo RGP moldea profundamente la economía y la experiencia del usuario en toda la red.

• Para los usuarios: Tarifas predecibles y estables El RGP actúa como una ancla creíble para los usuarios. La tarifa de gas de una transacción sigue una fórmula sencilla: Precio de Gas del Usuario = RGP + Propina. En condiciones normales, no se necesita propina. Durante congestión, los usuarios pueden añadir una propina para obtener prioridad, creando un mercado de tarifas sin alterar el precio base estable dentro de la época. Este modelo brinda una estabilidad de tarifas significativamente mayor que los sistemas donde la tarifa base cambia en cada bloque.

• Para los validadores: Una carrera hacia la eficiencia El sistema fomenta una competencia saludable. Los validadores están incentivados a reducir sus costos operativos (mediante optimización de hardware y software) para poder cotizar un RGP más bajo de forma rentable. Esta “carrera hacia la eficiencia” beneficia a toda la red al disminuir los costos de transacción. El mecanismo también empuja a los validadores a mantener márgenes de beneficio equilibrados; cotizar demasiado alto corre el riesgo de quedar fuera del cálculo del RGP, mientras que cotizar demasiado bajo genera pérdidas operativas y penalizaciones de desempeño.

• Para la red: Descentralización y sostenibilidad El mecanismo RGP ayuda a asegurar la salud a largo plazo de la red. La “amenaza de entrada” de nuevos validadores más eficientes impide que los validadores existentes coludan para mantener precios altos. Además, al ajustar sus cotizaciones según el precio de mercado del token SUI, los validadores garantizan colectivamente que sus operaciones sigan siendo sostenibles en términos reales, aislando la economía de tarifas de la volatilidad del precio del token.

Gobernanza y Evolución del Sistema: SIP‑45​

El mecanismo de gas de Sui no es estático y evoluciona mediante la gobernanza. Un ejemplo destacado es SIP‑45 (Envío Prioritario de Transacciones), propuesto para refinar la priorización basada en tarifas.

• Problema abordado: El análisis mostró que pagar un precio de gas alto no siempre garantizaba una inclusión más rápida de la transacción.
• Cambios propuestos: La propuesta incluye aumentar el precio máximo de gas permitido e introducir una “difusión amplificada” para transacciones que paguen significativamente por encima del RGP (p. ej., ≥ 5× RGP), asegurando que se propaguen rápidamente por la red para una inclusión prioritaria.

Esto demuestra el compromiso de iterar sobre el modelo de gas basándose en datos empíricos para mejorar su efectividad.

Comparación con Otros Modelos de Gas de Blockchain​

El modelo RGP de Sui es único, especialmente al compararlo con el EIP‑1559 de Ethereum.

Críticas Potenciales y Desafíos​

A pesar de su diseño innovador, el mecanismo RGP enfrenta posibles desafíos:

• Complejidad: El sistema de encuestas, reglas de conteo y cálculos off‑chain es intrincado y puede presentar una curva de aprendizaje para nuevos validadores.
• Reacción lenta a picos: El RGP está fijado por una época y no puede reaccionar a aumentos repentinos de demanda a mitad de época, lo que podría generar congestión temporal hasta que los usuarios añadan propinas.
• Potencial de colusión: En teoría, los validadores podrían coludirse para fijar un RGP alto. Este riesgo se mitiga principalmente por la naturaleza competitiva del conjunto de validadores sin permiso.
• Sin quema de tarifas: A diferencia de Ethereum, Sui recicla todas las tarifas de gas a los validadores y al fondo de almacenamiento. Esto recompensa a los operadores de la red pero no crea presión deflacionaria sobre el token SUI, una característica que algunos poseedores valoran.

Preguntas Frecuentes (FAQ)​

¿Por qué hacer staking de SUI? El staking de SUI asegura la red y genera recompensas. Inicialmente, estas recompensas están fuertemente subsidiadas por la Sui Foundation para compensar la baja actividad de la red. Estos subsidios disminuyen un 10 % cada 90 días, con la expectativa de que las recompensas de tarifas de transacción crezcan hasta convertirse en la principal fuente de rendimiento. El SUI en staking también otorga derechos de voto en la gobernanza on‑chain.

¿Puede ser slasheado mi SUI en staking? Sí. Mientras los parámetros aún se finalizan, se aplica el “Tally Rule Slashing”. Un validador que reciba una puntuación de desempeño cero de 2/3 de sus pares (por bajo rendimiento, comportamiento malicioso, etc.) verá sus recompensas slasheadas por una cantidad que se determinará. Los stakers también pueden perder recompensas si su validador elegido sufre tiempo de inactividad o cotiza un RGP subóptimo.

¿Se capitalizan automáticamente las recompensas de staking? Sí, las recompensas de staking en Sui se distribuyen y re‑stakean (capitalizan) automáticamente cada época. Para acceder a las recompensas, debes retirarlas explícitamente.

¿Cuál es el período de desbloqueo de SUI? Inicialmente, los stakers pueden desbloquear sus tokens de inmediato. Se espera implementar un período de desbloqueo en el que los tokens queden bloqueados por un tiempo determinado después del retiro, sujeto a gobernanza.

¿Mantengo la custodia de mis tokens SUI al hacer staking? Sí. Cuando haces staking de SUI, delegas tu participación pero mantienes el control total de tus tokens. Nunca transfieres la custodia al validador.

En los mundos cada vez más convergentes de la inteligencia artificial y la blockchain, la demanda de confianza y transparencia nunca ha sido tan alta. ¿Cómo podemos estar seguros de que la salida de un modelo de IA es precisa y no ha sido manipulada? ¿Cómo podemos realizar cálculos complejos sobre enormes conjuntos de datos on‑chain sin comprometer la seguridad o la escalabilidad? Lagrange Labs está abordando estas preguntas de frente con su suite de infraestructura de conocimiento cero (ZK), con el objetivo de construir un futuro de “IA que puedes probar”. Este artículo ofrece una visión objetiva de su misión, tecnología y avances recientes, culminando con su último paper sobre zk‑SNARKs dinámicos.

1. El equipo y su misión​

Lagrange Labs está construyendo la infraestructura fundamental para generar pruebas criptográficas para cualquier inferencia de IA o aplicación on‑chain. Su objetivo es hacer que el cómputo sea verificable, aportando una nueva capa de confianza al mundo digital. Su ecosistema se sustenta en tres líneas de producto principales:

• Red de Provers ZK: Una red descentralizada de más de 85 nodos de prueba que suministra la potencia computacional necesaria para una amplia gama de tareas de prueba, desde IA y rollups hasta aplicaciones descentralizadas (dApps).
• DeepProve (zkML): Un sistema especializado para generar pruebas ZK de inferencias de redes neuronales. Lagrange afirma que es hasta 158 veces más rápido que las soluciones competidoras, haciendo que la IA verificable sea una realidad práctica.
• ZK Coprocessor 1.0: El primer coprocesador ZK basado en SQL, que permite a los desarrolladores ejecutar consultas personalizadas sobre enormes conjuntos de datos on‑chain y recibir resultados verificablemente precisos.

2. Una hoja de ruta hacia la IA verificable​

Lagrange ha estado ejecutando metódicamente una hoja de ruta diseñada para resolver los desafíos de la verificabilidad de la IA paso a paso.

• Q3 2024: Lanzamiento del ZK Coprocessor 1.0: Esta versión introdujo circuitos recursivos hiper‑paralelos, que entregaron un aumento de velocidad promedio de aproximadamente 2×. Proyectos como Azuki y Gearbox ya están aprovechando el coprocesador para sus necesidades de datos on‑chain.
• Q1 2025: Presentación de DeepProve: Lagrange anunció DeepProve, su solución para Machine Learning de Conocimiento Cero (zkML). Soporta arquitecturas de redes neuronales populares como Perceptrones Multicapa (MLP) y Redes Neuronales Convolucionales (CNN). El sistema logra una aceleración significativa, de orden de magnitud, en las tres etapas críticas: configuración única, generación de pruebas y verificación, con mejoras de velocidad de hasta 158×.
• Q2 2025: Paper sobre zk‑SNARKs dinámicos (último hito): Este paper introduce un algoritmo de “actualización” revolucionario. En lugar de regenerar una prueba desde cero cada vez que los datos o el cómputo subyacente cambian, este método puede parchear una prueba antigua (π) en una nueva prueba (π′). Esta actualización se puede realizar con una complejidad de solo O(√n log³n), una mejora dramática respecto a la recomputación completa. Esta innovación es particularmente adecuada para sistemas dinámicos como modelos de IA que aprenden continuamente, lógica de juegos en tiempo real y contratos inteligentes en evolución.

3. Por qué los zk‑SNARKs dinámicos son importantes​

La introducción de pruebas actualizables representa un cambio fundamental en el modelo de costos de la tecnología de conocimiento cero.

• Un nuevo paradigma de costos: La industria pasa de un modelo de “recomputación total para cada prueba” a “pruebas incrementales basadas en el tamaño del cambio”. Esto reduce drásticamente el costo computacional y financiero para aplicaciones que sufren actualizaciones frecuentes y menores.
• Implicaciones para la IA:
  • Ajuste fino continuo: Cuando se ajusta menos del 1 % de los parámetros de un modelo, el tiempo de generación de la prueba crece casi linealmente con el número de parámetros cambiados (Δ parámetros), en lugar de con el tamaño total del modelo.
  • Inferencia en streaming: Esto permite generar pruebas concurrentemente con el propio proceso de inferencia. Reduce drásticamente la latencia entre que una IA toma una decisión y que esa decisión sea asentada y verificada on‑chain, abriendo casos de uso como servicios de IA on‑chain y pruebas comprimidas para rollups.
• Implicaciones para aplicaciones on‑chain:
  • Los zk‑SNARKs dinámicos ofrecen enormes optimizaciones de gas y tiempo para aplicaciones caracterizadas por cambios de estado frecuentes y pequeños. Esto incluye libros de órdenes de exchanges descentralizados (DEX), estados de juegos en evolución y actualizaciones de libros contables con adiciones o eliminaciones frecuentes.

4. Un vistazo al stack tecnológico​

La poderosa infraestructura de Lagrange se construye sobre un stack tecnológico sofisticado e integrado:

• Diseño de circuitos: El sistema es flexible, soportando la incorporación de modelos ONNX (Open Neural Network Exchange), parsers SQL y operadores personalizados directamente en sus circuitos.
• Recursión y paralelismo: La Red de Provers ZK facilita pruebas recursivas distribuidas, mientras que el ZK Coprocessor aprovecha el sharding de “micro‑circuitos” para ejecutar tareas en paralelo, maximizando la eficiencia.
• Incentivos económicos: Lagrange está planificando lanzar un token nativo, LA, que se integrará en un sistema Double‑Auction‑for‑Recursive‑Auction (DARA). Esto creará un mercado robusto para pujar por el cómputo de los probadores, con incentivos y penalizaciones que aseguren la integridad de la red.

5. Ecosistema y adopción en el mundo real​

Lagrange no está construyendo en un vacío; su tecnología ya está siendo integrada por un número creciente de proyectos en distintos sectores:

• IA y ML: Proyectos como 0G Labs y Story Protocol están usando DeepProve para verificar los resultados de sus modelos de IA, garantizando procedencia y confianza.
• Rollups e infraestructura: Jugadores clave como EigenLayer, Base y Arbitrum participan en la Red de Provers ZK como nodos de validación o socios de integración, contribuyendo a su seguridad y potencia computacional.
• Aplicaciones NFT y DeFi: Marcas como Azuki y protocolos DeFi como Gearbox están utilizando el ZK Coprocessor para mejorar la credibilidad de sus consultas de datos y mecanismos de distribución de recompensas.

6. Desafíos y el camino por delante​

A pesar de su impresionante progreso, Lagrange Labs y el campo más amplio de ZK enfrentan varios obstáculos:

• Cuellos de botella de hardware: Incluso con una red distribuida, los SNARKs actualizables siguen demandando gran ancho de banda y dependen de curvas criptográficas amigables con GPU para operar eficientemente.
• Falta de estandarización: El proceso de mapear frameworks de IA como ONNX y PyTorch a circuitos ZK aún carece de una interfaz universal y estandarizada, creando fricción para los desarrolladores.
• Un panorama competitivo: La carrera por construir zkVMs y plataformas zkCompute generalizadas se está intensificando. Competidores como Risc‑Zero y Succinct también están logrando avances significativos. El ganador final podría ser quien sea el primero en comercializar una cadena de herramientas amigable para desarrolladores y impulsada por la comunidad.

7. Conclusión​

Lagrange Labs está remodelando metódicamente la intersección de IA y blockchain a través del lente de la verificabilidad. Su enfoque ofrece una solución integral:

• DeepProve aborda el desafío de la inferencia confiable.
• El ZK Coprocessor resuelve el problema de los datos confiables.
• Los zk‑SNARKs dinámicos incorporan la necesidad del mundo real de actualizaciones continuas directamente en el sistema de pruebas.

Si Lagrange puede mantener su ventaja de rendimiento, resolver el desafío crítico de la estandarización y seguir ampliando su robusta red, estará bien posicionada para convertirse en un jugador fundamental en el emergente sector de “IA + Infraestructura ZK”.

Cómo eliminar la fricción de la cartera, mantener a los usuarios en flujo y pronosticar el potencial

¿Qué pasaría si tu aplicación Web3 tuviera el mismo flujo de registro sin fricciones que un servicio Web2 moderno? Esa es la promesa central de zkLogin en la blockchain Sui. Funciona como OAuth para Sui, permitiendo a los usuarios iniciar sesión con cuentas familiares de Google, Apple, X y más. Una prueba de conocimiento cero enlaza de forma segura esa identidad Web2 con una dirección Sui en cadena—sin ventanas emergentes de cartera, sin frases semilla, sin abandono de usuarios.

El impacto es real e inmediato. Con cientos de miles de cuentas zkLogin ya activas, los estudios de caso reportan ganancias masivas en la conversión de usuarios, pasando de un desalentador 17 % a un saludable 42 % después de eliminar las barreras tradicionales de la cartera. Analicemos cómo funciona y qué puede hacer por tu proyecto.

Por qué las carteras matan la conversión en el primer uso​

Has creado una dApp revolucionaria, pero tu embudo de adquisición de usuarios está perdiendo gente. El culpable casi siempre es el mismo: el botón “Conectar cartera”. La incorporación estándar en Web3 es un laberinto de instalaciones de extensiones, advertencias de frases semilla y cuestionarios de jerga cripto.

Es una barrera enorme para los recién llegados. Investigadores de UX observaron una caída asombrosa del 87 % en el momento en que apareció el aviso de la cartera. En un experimento revelador, simplemente reencaminar ese aviso a una etapa posterior del proceso de pago elevó la tasa de finalización al 94 %. Incluso para los usuarios curiosos por cripto, el miedo principal es: “Podría perder mis fondos si hago clic en el botón equivocado.” Eliminar ese único paso intimidante es la clave para desbloquear un crecimiento exponencial.

Cómo funciona zkLogin (en lenguaje sencillo)​

zkLogin elude elegantemente el problema de la cartera usando tecnologías en las que todo usuario de internet ya confía. La magia ocurre tras bambalinas en unos pocos pasos rápidos:

1. Par de claves efímero: Cuando un usuario quiere iniciar sesión, se genera localmente en su navegador un par de claves temporal de una sola sesión. Piensa en ello como una llave de paso temporal, válida solo para esa sesión.
2. Danza OAuth: El usuario inicia sesión con su cuenta de Google, Apple u otra red social. Tu aplicación inserta de forma inteligente un valor único (nonce) en esta solicitud de inicio de sesión.
3. Servicio ZKP: Tras un inicio de sesión exitoso, un servicio ZKP (Prueba de Conocimiento Cero) genera una prueba criptográfica. Esta prueba confirma, “Este token OAuth autoriza al propietario de la llave temporal,” sin revelar nunca la identidad personal del usuario en cadena.
4. Derivar dirección: El JWT (JSON Web Token) del proveedor OAuth se combina con una sal única para generar de forma determinista su dirección permanente en Sui. La sal se mantiene privada, ya sea del lado del cliente o en un backend seguro.
5. Enviar transacción: Tu aplicación firma transacciones con la llave temporal y adjunta la prueba ZK. Los validadores de Sui verifican la prueba en cadena, confirmando la legitimidad de la transacción sin que el usuario necesite una cartera tradicional.

Guía de integración paso a paso​

¿Listo para implementarlo? Aquí tienes una guía rápida usando el SDK de TypeScript. Los principios son idénticos para Rust o Python.

1. Instalar SDK​

El paquete @mysten/sui incluye todos los helpers zklogin que necesitarás.

pnpm add @mysten/sui

2. Generar claves y nonce​

Primero, crea un par de claves efímero y un nonce ligado a la época actual en la red Sui.

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(
  keypair.getPublicKey(),
  Number(epoch) + 2,
  generateRandomness(),
);

3. Redirigir a OAuth​

Construye la URL de inicio de sesión OAuth adecuada para el proveedor que estés usando (por ejemplo, Google, Facebook, Apple) y redirige al usuario.

4. Decodificar JWT y obtener la sal del usuario​

Después de que el usuario inicie sesión y sea redirigido de vuelta, captura el id_token de la URL. Úsalo para obtener la sal específica del usuario desde tu backend, y luego deriva su dirección Sui.

const jwt = new URLSearchParams(window.location.search).get("id_token")!;
const salt = await fetch("/api/salt?jwt=" + jwt).then((r) => r.text());
const address = jwtToAddress(jwt, salt);

5. Solicitar prueba ZK​

Envía el JWT a un servicio de pruebas para obtener la prueba ZK. Para desarrollo, puedes usar el probador público de Mysten. En producción, deberías alojar el tuyo propio o usar un servicio como Enoki.

const proof = await fetch('/api/prove', {
  method:'POST',
  body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. Firmar y enviar​

Ahora, construye tu transacción, establece al remitente la dirección zkLogin del usuario y ejecútala. El SDK se encarga de adjuntar automáticamente los zkLoginInputs (la prueba). ✨

const tx = new TransactionBlock();
tx.moveCall({ target: "0x2::example::touch_grass" }); // Any Move call
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof, // The magic happens here
});

7. Persistir la sesión​

Para una experiencia de usuario más fluida, cifra y almacena el par de claves y la sal en IndexedDB o local storage. Recuerda rotarlos cada pocas épocas para mejorar la seguridad.

Plantilla de proyección de KPI​

La diferencia que zkLogin genera no es solo cualitativa; es cuantificable. Compara un embudo de incorporación típico con uno potenciado por zkLogin:

👉 Qué significa esto: Para una campaña que atraiga 10 000 visitantes únicos, esa es la diferencia entre 300 acciones en cadena el primer día y más de 2 500.

Buenas prácticas y advertencias​

Para crear una experiencia aún más fluida, ten en cuenta estos consejos profesionales:

• Usa transacciones patrocinadas: Paga las primeras tarifas de transacción de tus usuarios. Esto elimina toda fricción y genera un momento “¡ajá!” increíble.
• Maneja las sales con cuidado: Cambiar la sal de un usuario generará una nueva dirección. Hazlo solo si controlas una ruta de recuperación fiable para él.
• Expón la dirección Sui: Después del registro, muestra a los usuarios su dirección en cadena. Esto empodera a los usuarios avanzados para importarla a una cartera tradicional más adelante, si lo desean.
• Previene bucles de recarga: Cachea el JWT y el par de claves efímero hasta que expiren para evitar pedir al usuario que inicie sesión repetidamente.
• Monitorea la latencia del probador: Vigila el tiempo de ida y vuelta de la generación de pruebas. Si supera los 2 segundos, considera alojar un probador regional para mantener la experiencia ágil.

Dónde BlockEden.xyz aporta valor​

Mientras zkLogin perfecciona el flujo de cara al usuario, escalarlo introduce nuevos retos de backend. Ahí es donde entra BlockEden.xyz.

• Capa API: Nuestros nodos RPC de alta capacidad y enrutamiento geográfico garantizan que tus transacciones zkLogin se procesen con latencia mínima, sin importar la ubicación del usuario.
• Observabilidad: Obtén paneles listos para usar que rastrean métricas clave como latencia de pruebas, ratios de éxito/fracaso y la salud de tu embudo de conversión.
• Cumplimiento: Para apps que conectan con fiat, nuestro módulo opcional de KYC brinda una incorporación regulada directamente desde la identidad verificada del usuario.

¿Listo para lanzar?​

La era de los flujos de cartera torpes e intimidantes ha terminado. Levanta un sandbox zkLogin, conecta el endpoint de nodo completo de BlockEden y observa cómo tu gráfico de registros se curva hacia arriba—mientras tus usuarios ni siquiera escuchan la palabra “cartera”. 😉

1. Liquidez y Crecimiento del DeFi de Sui​

Figura: TVL del DeFi de Sui (línea azul) y volumen de DEX (barras verdes) crecieron dramáticamente durante el Q2 2025.

Aumento del Valor Total Bloqueado (TVL): La liquidez DeFi de la red Sui ha crecido explosivamente durante el último año. De aproximadamente $600 M de TVL a finales de 2024, el TVL de Sui se disparó a más de $2 mil millones a mediados de 2025. De hecho, Sui alcanzó su pico en torno a $2.55 B de TVL el 21 de mayo de 2025 y se mantuvo bien por encima de los $2 B durante gran parte del Q2. Este incremento de más del 300 % (un aumento interanual del 480 % respecto a mayo 2023) posiciona firmemente a Sui entre las top 10 blockchains por TVL DeFi, superando el crecimiento de redes como Solana. Los principales catalizadores incluyeron adopción institucional y la integración del soporte nativo para la stablecoin USDC, que juntos atrajeron grandes flujos de capital. Notablemente, los volúmenes mensuales de trading en DEX de Sui han escalado al nivel superior de todas las cadenas – superando $7–8 mil millones al mes a mediados de 2025 (ranking \ 8.º a nivel de industria). La liquidez circulante de stablecoins en Sui superó los $1 mil millones a mediados de 2025, tras crecer un 180 % desde el inicio del año, lo que indica una profundización de la liquidez on‑chain. El capital cross‑chain también fluye; alrededor de $2.7 B de activos han sido puenteados al ecosistema de Sui, incluyendo liquidez de Bitcoin (detalles más abajo). Esta tendencia de rápido crecimiento subraya un año de entradas netas y expansión de usuarios para el DeFi de Sui.

Principales DEX y Proveedores de Liquidez: Los intercambios descentralizados forman la columna vertebral de la liquidez DeFi de Sui. El protocolo Cetus – un creador de mercado automatizado (AMM) y agregador – ha sido un DEX emblemático, ofreciendo swaps de stablecoins y pools de liquidez concentrada. Cetus lidera consistentemente en volumen (facilitando más de $12.8 B en operaciones durante el Q2 2025 solo) mientras mantiene alrededor de $80 M de TVL. Otro actor clave es Bluefin, un DEX multifacético que opera tanto un AMM spot como un intercambio de futuros perpetuos. A mediados de 2025, Bluefin lanzó Momentum, una funcionalidad institucional de RFQ que permite a los traders obtener precios en tiempo real con abstracción de liquidez. Momentum introdujo Liquidity 2.0, que concentra la liquidez en rangos estrechos, mejorando la eficiencia de capital. Momentum también lanzó Momentum CLMM, que ajusta dinámicamente la liquidez según la demanda. Además, DeepBook (parte de Bluefin) introdujo RFQ para traders institucionales, reduciendo la fricción entre makers y takers. DeepBook también añadió matching de órdenes sin MEV, creando un nuevo primitivo de intercambio. DeepBook y Cetus continúan expandiendo su presencia en Sui, impulsando la profundidad de mercado y la resiliencia contra la extracción de valor máximo (MEV).

Nuevos Primitivos de DEX y HFT: En julio de 2025, Bluefin anunció la incorporación de estrategias de trading de alta frecuencia de grado institucional a su DEX basado en Sui, aprovechando la ejecución paralela de Sui para lograr mejoras de rendimiento y latencia. Esta actualización reduce la brecha con los intercambios centralizados y podría atraer a firmas cuantitativas a proveer liquidez on‑chain. Las mejoras en velocidad de ejecución, bajo deslizamiento y protección contra MEV (la actualización Spot 2.0 de Bluefin destaca por su matching RFQ resistente al MEV) son nuevos primitivos en el diseño de intercambios que Sui está pionando.

Otros DEX y Primitivos: Momentum introdujo su CLMM (Creador de Liquidez Concentrada) que concentra la liquidez en rangos de precios específicos, mejorando la eficiencia de capital. Magma lanzó su ALMM (Creador de Mercado de Alta Liquidez) que ajusta dinámicamente la liquidez según la demanda, reduciendo el deslizamiento. DeepBook añadió matching RFQ sin MEV y protección contra front‑running, creando un nuevo modelo de intercambio para traders institucionales.

Préstamos y Mercados de Crédito: El protocolo Suilend se consolidó como la plataforma de préstamos líder, ofreciendo préstamos colaterales en SUI, BTC, ETH y stablecoins. A mediados de 2025, Suilend gestionó más de $102 M en activos derivados de Bitcoin, superando a cualquier otro prestamista en Sui. Otros prestamistas como Suifin y LendingHub ampliaron sus mercados a activos tokenizados como tBTC y sBTC, impulsando la diversificación de colaterales.

Resumen de Liquidez: En 2025, el DeFi de Sui maneja varios mil millones de dólares en TVL, respaldado por DEX de alto rendimiento y plataformas de préstamo robustas, alimentado por flujos constantes de capital cross‑chain y un crecimiento sostenido de usuarios.

2. Abstracción y Experiencia de Usuario​

Abstracción de Cuenta: Sui implementa abstracción de cuenta que permite a los usuarios interactuar con contratos sin poseer directamente SUI. Los usuarios pueden pagar tarifas de gas con stablecoins o con tokens de utilidad, simplificando la experiencia para nuevos participantes. La abstracción de cuenta también habilita firmas sociales, donde varias partes pueden autorizar una transacción conjunta, reduciendo la fricción para aplicaciones DeFi colaborativas.

Beneficios de la Abstracción:

• On‑boarding sin SUI: Los nuevos usuarios pueden crear una cuenta con una simple firma de email o wallet social, sin necesidad de adquirir SUI primero.
• Pagos de Gas Flexibles: Los contratos pueden pagar gas en USDC, USDT o incluso en tokens de proyecto, eliminando la barrera de poseer SUI para usar DEX o prestar.
• Seguridad Mejorada: Al separar la lógica de autorización del pago de gas, se reducen los vectores de ataque tradicionales asociados al manejo de claves privadas.

3. Primitivos Financieros Nativos​

Stablecoins Nativas​

• AUSD (Agora Finance): La primera stablecoin 100 % respaldada en USD nativa de Sui, lanzada en 2024, que rápidamente añadió liquidez al ecosistema.
• BUCK (Bucket Protocol): Stablecoin sobre‑colateralizada similar a DAI, con suministro de $60–66 M a mediados de 2025.
• USDY (Ondo Finance): Stablecoin generadora de rendimiento que tokeniza rendimientos de bonos del Tesoro de EE. UU., ofreciendo un activo de bajo riesgo con rendimiento integrado.

BTCfi e Integraciones​

• tBTC (Threshold Network): Token descentralizado 1:1 respaldado por Bitcoin, lanzado en julio de 2025, desbloqueando más de $500 M de liquidez BTC para protocolos de Sui.
• sBTC (Stacks): Representación 1:1 de Bitcoin a través de Stacks, que para mayo de 2025 constituía más del 10 % del TVL de Sui.

AMM Avanzados y HFT​

• Bluefin Institutional HFT: Estrategias de trading de alta frecuencia implementadas en Sui, aprovechando la ejecución paralela para lograr latencias sub‑segundo.
• Magma ALMM y Momentum CLMM: Diseños de AMM que concentran y ajustan dinámicamente la liquidez, mejorando la eficiencia de capital.

Plataformas Integradas​

• Graviton: Proyecto modular de trading, préstamo y margen cruzado con una financiación de $50 M (Series A), comparado con dYdX para traders profesionales.
• xMoney/xPortal MasterCard: Tarjeta MasterCard impulsada por cripto que permite gastar activos basados en SUI en comercios cotidianos, creando un puente CeFi‑DeFi.

4. Resumen​

En 2025, el ecosistema DeFi de Sui florece con innovación. La liquidez ha alcanzado niveles multimillonarios, impulsada por DEX de alto rendimiento y plataformas de préstamo robustas, mientras que la abstracción de cuenta y el diseño centrado en el usuario han mejorado drásticamente la experiencia, atrayendo a una audiencia más amplia. La próxima ola de primitivos – desde stablecoins nativas y la integración de Bitcoin hasta AMM avanzados, perps institucionales y tokens respaldados por activos reales – está ampliando lo que es posible en finanzas descentralizadas. Las alianzas estratégicas con proveedores de infraestructura, instituciones TradFi y redes cross‑chain continúan amplificando el impulso de Sui, consolidándola como un hub DeFi líder para 2025.

Fuentes:

• Sui Foundation – Resumen DeFi Q2 2025 de Sui (15 jul 2025)
• Sui Foundation – NEAR Intents trae swaps cross‑chain ultrarrápidos a Sui (17 jul 2025)
• Sui Foundation – Sui soportará sBTC y Stacks (casos de uso BTCfi) (1 may 2025)
• Sui Foundation – Todo sobre la Abstracción de Cuenta (4 oct 2023)
• Ainvest News – El TVL de Sui supera los $1.4 B impulsado por protocolos DeFi (14 jul 2025)
• Ainvest News – El TVL DeFi de Sui sube un 480 % a $1.8 B... (12 jul 2025)
• Suipiens (comunidad Sui) – Integración tBTC lleva liquidez Bitcoin a Sui (17 jul 2025)
• Suipiens – Dentro de Suilend: la plataforma de préstamos líder de Sui (3 jul 2025)
• The Defiant – Ondo lleva stablecoins respaldadas por RWA a Sui (7 feb 2024)
• Documentación oficial de Sui – Introducción a Sui: Experiencia de Usuario (funciones de abstracción de cuenta)