Saltar al contenido principal

28 publicaciones etiquetados con "Web3"

Ver Todas las Etiquetas

Hackathons Web3, Bien Hechos: Un Manual Pragmático para 2025

· 12 min de lectura
Dora Noda
Software Engineer

Si buscas una ruta rápida para afinar tus habilidades, conocer co‑fundadores y probar una idea bajo presión, pocos entornos superan a un hackathon web3. Pero la diferencia entre un “fin de semana divertido” y un “lanzamiento que cambia la carrera” es un plan.

Esta guía te ofrece un manual concreto, pensado primero para los constructores: cómo elegir el evento correcto, prepararte de forma inteligente, construir rápido y presentar con claridad—además de listas de verificación que puedes copiar y pegar en tu próximo hack.

TL;DR

  • Elige los eventos de forma intencional. Favorece los ecosistemas en los que ya trabajas, o aquellos con jueces y patrocinadores alineados perfectamente con tu idea.
  • Define tu condición de victoria. ¿Estás allí para aprender, por una recompensa específica o por un puesto de finalista? Cada elección cambia tu equipo, alcance y stack.
  • Prepara lo aburrido con antelación. Ten listos los esqueletos del proyecto, flujos de autenticación, conexiones de wallet, sistema de diseño y un esquema del guion de demo antes de que empiece el reloj.
  • Construye la demo más pequeña pero adorable. Muestra un bucle de funcionalidad clave funcionando de extremo a extremo. Todo lo demás es narrativa y diapositivas.
  • Entrega como un profesional. Respeta las reglas de “empezar desde cero”, regístrate formalmente en cada pista de recompensa que apuntas y reserva tiempo suficiente para un video conciso y un README claro.

Por qué los hackathons web3 valen tu fin de semana

  • Aprendizaje comprimido: En un solo fin de semana tocarás infraestructura, contratos inteligentes, UX front‑end y pipelines de despliegue. Es un ciclo completo de desarrollo en 48 horas, una curva de aprendizaje que normalmente tomaría meses.
  • Networking de alto valor: Los mentores, jueces y ingenieros patrocinadores no son solo nombres en una web; están concentrados en una sala o servidor de Discord, listos para dar feedback. Esta es tu oportunidad de conectar con los desarrolladores centrales de los protocolos que usas a diario.
  • Rutas reales de financiación: No se trata solo de presumir. Los premios y subvenciones posteriores pueden proporcionar capital significativo para mantener vivo un proyecto. Eventos como el Summer Camp de Solana han ofrecido hasta 5 M USD en premios y financiación semilla, convirtiendo proyectos de fin de semana en startups viables.
  • Un portafolio de prueba: Un repositorio público en GitHub con una demo funcional vale infinitamente más que un punto en tu currículum. Es prueba tangible de que puedes construir, lanzar y articular una idea bajo presión.

Dónde encontrar los buenos

  • ETHGlobal: El estándar de oro tanto para eventos presenciales como asíncronos. Ofrecen procesos de evaluación robustos, participantes de alta calidad y exhibiciones públicas de proyectos perfectas para inspirarse.
  • Devpost: Un amplio mercado de hackathons de todo tipo, con filtros potentes para blockchain, protocolos específicos y pistas de premios. Es un gran lugar para descubrir eventos enfocados en ecosistemas concretos.
  • DoraHacks: Plataforma centrada en hackathons web3 impulsados por ecosistemas y rondas de subvenciones, con frecuencia un enfoque global y comunitario.

Consejo: La duración varía mucho. Un evento asíncrono de larga duración como ETHOnline se extiende por varias semanas, mientras que un sprint presencial como el #BUIDLathon de ETHDenver puede durar hasta nueve días. Debes planear el alcance de tu proyecto en consecuencia.


Decodifica las reglas (para que no te descalifiquen)

  • “Empezar desde cero”. Es la regla más común y crítica. La mayoría de los eventos exigen que todo trabajo sustancial comience después del kickoff oficial. Usar código antiguo para la lógica central puede descalificarte de la final y de premios de socios. Boilerplate suele estar permitido, pero la “salsa secreta” debe ser nueva.
  • Estructura de evaluación. Entiende el embudo. A menudo, una ronda de pre‑selección asíncrona reduce cientos de proyectos a un grupo de finalistas antes de que empiece la evaluación en vivo. Saber esto te ayuda a enfocar tu video de presentación y README para esa primera fase.
  • Tamaño del equipo. No te presentes con un equipo de diez. Muchos eventos establecen límites, como los típicos equipos de 2‑4 personas en ETHDenver. Esto garantiza igualdad de condiciones y fomenta la colaboración estrecha.
  • Mecánica de recompensas. No puedes ganar un premio al que no te hayas inscrito. Si apuntas a recompensas de patrocinadores, normalmente debes registrar formalmente tu proyecto para cada premio específico a través de la plataforma del evento. Es un paso sencillo que muchos equipos olvidan.

Rubrica de evaluación: cómo se ve lo “bueno”

Los organizadores principales suelen evaluar los proyectos en cuatro áreas recurrentes. Diseña tu alcance y demo para obtener puntos en cada una.

  • Tecnicalidad: ¿El problema es no trivial? ¿La solución implica un uso ingenioso o elegante de la tecnología? ¿Fuiste más allá de un simple wrapper front‑end sobre un contrato inteligente?
  • Originalidad: ¿Hay un mecanismo novedoso, una experiencia de usuario única o una remix inteligente de primitivas existentes? ¿Lo hemos visto cientos de veces o presenta una visión fresca?
  • Practicidad: ¿Alguien puede usar esto hoy? Un recorrido completo de usuario, aunque estrecho, vale mucho más que un proyecto amplio con funcionalidades a medio terminar.
  • Usabilidad (UI/UX/DX): ¿La interfaz es clara, rápida y agradable? Para herramientas de desarrollador, ¿qué tan buena es la experiencia de desarrollo? Un onboarding fluido y manejo claro de errores pueden marcar la diferencia.

Diseño del equipo: pequeño, afilado, complementario

Para velocidad y alineación, un equipo de dos a cuatro personas es el punto óptimo. Es suficientemente grande para paralelizar trabajo y lo bastante pequeño para tomar decisiones sin debates interminables.

  • Contratos inteligentes / protocolo: Responsable de la lógica on‑chain. Escribe, prueba y despliega los contratos.
  • Front‑end / DX: Construye la interfaz de usuario. Gestiona conexiones de wallet, obtención de datos, estados de error y el pulido final de la demo que hace que el proyecto se sienta real.
  • Producto / historia: Guardián del alcance y narrador. Se asegura de que el equipo se mantenga enfocado en el bucle central, escribe la descripción del proyecto y dirige la demo final.
  • (Opcional) Diseñador: Un diseñador dedicado puede ser un arma secreta, preparando componentes, íconos y micro‑interacciones que elevan la calidad percibida del proyecto.

Selección de ideas: el filtro P‑A‑C‑E

Usa este filtro sencillo para probar tus ideas antes de escribir una sola línea de código.

  • Dolor (Pain): ¿Resuelve un punto de dolor real para desarrolladores o usuarios? Piensa en UX de wallets, indexación de datos, protección contra MEV o abstracción de tarifas. Evita soluciones que buscan un problema.
  • Atomicidad: ¿Puedes construir y demostrar un bucle atómico completo en 48 horas? No toda la visión—solo una acción de usuario completa y satisfactoria.
  • Componibilidad: ¿Tu idea se apoya en primitivas existentes como oráculos, abstracción de cuentas o mensajería cross‑chain? Usar bloques de lego probados te ayuda a avanzar más rápido.
  • Ajuste al ecosistema: ¿Tu proyecto es visible y relevante para los jueces, patrocinadores y audiencia del evento? No propongas un protocolo DeFi complejo en una pista centrada en juegos.

Si persigues recompensas, elige una pista principal de patrocinador y una secundaria. Dispersar tu foco en demasiadas recompensas diluye tu profundidad y tus posibilidades de ganar alguna.


Stacks predeterminados que te facilitan la vida

Tu novedad debe estar en qué construyes, no en cómo lo construyes. Quédate con tecnologías aburridas y fiables.

Pista EVM (ruta rápida)

  • Contratos: Foundry (por su velocidad en pruebas, scripts y ejecución de nodo local).
  • Front‑end: Next.js o Vite, combinados con wagmi o viem y un kit de wallet como RainbowKit o ConnectKit para modales y conectores.
  • Datos / indexación: Un indexador alojado o servicio de subgraph si necesitas consultar datos históricos. Evita montar tu propia infraestructura.
  • Triggers off‑chain: Un job runner sencillo o un servicio de automatización dedicado.
  • Almacenamiento: IPFS o Filecoin para activos y metadatos; una KV store simple para estado de sesión.

Pista Solana (ruta rápida)

  • Programas: Anchor (para reducir boilerplate y beneficiarse de defaults más seguros).
  • Cliente: React o un framework móvil con los SDK móviles de Solana. Usa hooks simples para RPC y llamadas a programas.
  • Datos: Confía en llamadas RPC directas o indexadores del ecosistema. Cachea agresivamente para mantener la UI ágil.
  • Almacenamiento: Arweave o IPFS para almacenamiento permanente de activos, si es relevante.

Plan realista de 48 horas

T‑24 a T‑0 (antes del kickoff)

  • Alinea tu condición de victoria (aprendizaje, recompensa, final) y las pistas objetivo.
  • Esboza el bucle completo de la demo en papel o pizarra. Ten claro qué se hará clic y qué ocurrirá on‑chain y off‑chain en cada paso.
  • Forkea una plantilla monorepo limpia que incluya boilerplate tanto para contratos como para la app front‑end.
  • Pre‑escribe el esquema de tu README y un borrador del guion de demo.

Hora 0‑6

  • Valida tu alcance con mentores y patrocinadores del evento. Confirma los criterios de la recompensa y asegura que tu idea encaje.
  • Define restricciones duras: una cadena, un caso de uso principal y un “momento wow” para la demo.
  • Divide el trabajo en sprints de 90 min. Tu objetivo es entregar el primer slice vertical completo de tu bucle central antes de la Hora 6.

Hora 6‑24

  • Endurece el camino crítico. Prueba tanto el happy path como casos límite comunes.
  • Añade observabilidad. Implementa logs básicos, toasts UI y boundaries de error para depurar rápido.
  • Crea una landing page mínima que explique claramente el “por qué” de tu proyecto.

Hora 24‑40

  • Graba un video de demo backup tan pronto como la funcionalidad clave sea estable. No esperes al último minuto.
  • Empieza a redactar y editar tu texto de entrega final, video y README.
  • Si el tiempo lo permite, añade uno o dos toques pensados, como estados vacíos elegantes, una transacción sin gas o un snippet de código útil en la documentación.

Hora 40‑48

  • Congela todas las funcionalidades. No más código nuevo.
  • Pulir tu video y paquete de entrega. Los ganadores experimentados recomiendan reservar 15 % del tiempo total para el pulido y crear un video con una división clara 60/40 entre explicar el problema y demostrar la solución.

Demo y entrega: facilita el trabajo de los jueces

  • Abre con el “por qué”. Inicia tu video y README con una sola frase que explique el problema y el resultado de tu solución.
  • Vive el bucle. Muestra, no solo cuentes. Recorrido completo de un usuario creíble de inicio a fin sin saltarse pasos.
  • Narrativa de limitaciones. Reconoce lo que no construiste y por qué. Decir “Limitamos el alcance a un caso de uso para asegurar que usuarios reales puedan completar el flujo hoy” muestra foco y madurez.
  • Deja marcadores claros. Tu README debe incluir un diagrama de arquitectura, enlaces a la demo en vivo y a los contratos desplegados, y pasos simples de un clic para ejecutar el proyecto localmente.
  • Fundamentos de video. Planifica tu video temprano, escribe un guion ajustado y asegúrate de que destaque claramente qué hace el proyecto, qué problema resuelve y cómo funciona bajo el capó.

Recompensas sin agotamiento

  • Regístrate en cada premio que apuntas. En algunas plataformas, esto implica pulsar explícitamente el botón “Start Work”.
  • No persigas más de dos recompensas de patrocinadores a menos que sus tecnologías se solapen naturalmente en tu stack.
  • En tu entrega, refleja su rubrica. Usa sus palabras clave, referencia sus APIs por nombre y explica cómo cumpliste sus métricas de éxito específicas.

Después del hackathon: convierte el impulso en tracción

  • Publica un breve post en tu blog y un hilo en redes sociales con el enlace a la demo y al repositorio GitHub. Etiqueta al evento y a los patrocinadores.
  • Aplica a subvenciones y rondas de aceleración diseñadas específicamente para alumni de hackathons y proyectos open‑source en fase temprana.
  • Si la recepción es fuerte, crea una hoja de ruta simple de una semana enfocada en corrección de bugs, una pasada de UX y un piloto pequeño con algunos usuarios. Fija una fecha límite para un lanzamiento v0.1 y mantén el impulso.

Errores comunes (y su solución)

  • Violación de la regla “empezar desde cero”. Solución: Mantén cualquier código previo fuera del alcance o decláralo explícitamente como una biblioteca preexistente que utilizas.
  • Sobrecarga de alcance. Solución: Si tu demo planeada tiene tres pasos mayores, elimina uno. Sé despiadado con el foco en el bucle central.
  • Ir multichain demasiado pronto. Solución: Lanza perfectamente en una cadena. Habla de tus planes de puentes y soporte cross‑chain en la sección “Qué sigue” del README.
  • Impuestos de último minuto al video. Solución: Reserva tiempo suficiente para la edición y pulido; un video bien editado evita penalizaciones.
  • No reservar tiempo para el README. Solución: Incluye al menos 30 minutos al final del cronograma para revisar y formatear el README.

Listas de verificación (copy‑paste)

Antes del kickoff

  • Definir condición de victoria.
  • Seleccionar evento alineado con el objetivo.
  • Registrar en todas las pistas de recompensa.
  • Preparar boilerplate de contrato y front‑end.
  • Esbozar guion de demo y estructura de README.

Durante las primeras 6 horas

  • Validar alcance con mentores.
  • Establecer restricciones de cadena, caso de uso y momento wow.
  • Dividir trabajo en sprints de 90 min.
  • Entregar primer slice vertical completo.

Entre la hora 6 y 24

  • Probar happy path y casos límite.
  • Añadir logs y notificaciones de error.
  • Crear landing page mínima.

Entre la hora 24 y 40

  • Grabar video de demo backup.
  • Redactar borrador de README y guion de video.
  • Añadir toques de pulido (estados vacíos, snippets, etc.).

Entre la hora 40 y 48

  • Congelar código.
  • Pulir video y README.
  • Reservar 15 % del tiempo total para pulido final.

Entrega final

Dos Vías para un Ethereum más Amigable: Cuentas Inteligentes ERC‑4337 + ERC‑4804 URLs Web3

· 9 min de lectura
Dora Noda
Software Engineer

TL;DR

Ethereum acaba de obtener dos primitivas poderosas que llevan la experiencia de usuario más allá de las frases semilla y las dapps marcables, hacia “experiencias en cadena clicables”.

  • ERC-4337 trae abstracción de cuentas al Ethereum actual sin cambios en el protocolo base. Esto hace que funciones como cuentas de contrato inteligente, patrocinio de gas, llamadas agrupadas y autenticación al estilo de passkey sean nativas de las carteras.
  • ERC-4804 introduce URLs web3:// — enlaces legibles por humanos que se resuelven directamente en llamadas de lectura a contratos y pueden incluso renderizar HTML o SVG en cadena, todo sin un servidor web tradicional como intermediario. Piensa en ello como “HTTP para el EVM”.

Cuando se usan juntos, ERC-4337 maneja las acciones, mientras que ERC-4804 maneja las direcciones. Esta combinación permite compartir un enlace que extrae verificablemente su interfaz de usuario de un contrato inteligente. Cuando el usuario está listo para actuar, el flujo pasa a una cuenta inteligente que puede patrocinar el gas y agrupar varios pasos en un solo clic sin fisuras.


Por Qué Importa Ahora

No es solo un futuro teórico; estas tecnologías están en vivo y ganando tracción significativa. ERC-4337 ya está escalado y probado en producción. El contrato canónico EntryPoint se desplegó en la mainnet de Ethereum el 1 de marzo de 2023 y desde entonces ha impulsado decenas de millones de cuentas de contrato inteligente y procesado más de 100 millones de operaciones de usuario.

Simultáneamente, el protocolo base está convergiendo con estas ideas. La actualización Pectra, lanzada en mayo de 2025, incluyó EIP-7702, que permite que las cuentas externas estándar (EOA) se comporten temporalmente como cuentas inteligentes. Esto complementa a ERC-4337 al facilitar la transición para usuarios existentes, en lugar de reemplazar el estándar.

En el frente de direccionamiento, web3:// ya está formalizado. ERC-4804 especifica exactamente cómo una URL se traduce en una llamada EVM, y web3 ha sido listado por IANA como un esquema URI provisional. Las herramientas y pasarelas necesarias para hacer prácticas estas URLs ya están disponibles, convirtiendo datos en cadena en recursos compartibles y enlazables.


Introducción: ERC-4337 en una Página

En su esencia, ERC-4337 introduce una vía de transacción paralela a Ethereum, construida para flexibilidad. En lugar de transacciones tradicionales, los usuarios envían objetos UserOperation a un mempool alternativo. Estos objetos describen lo que la cuenta quiere hacer. Nodos especializados llamados “Bundlers” recogen estas operaciones y las ejecutan a través de un contrato global EntryPoint.

Esto habilita tres componentes clave:

  1. Cuentas de Contrato Inteligente (SCAs): Estas cuentas contienen su propia lógica. Definen qué hace válida una transacción, permitiendo esquemas de firma personalizados (como passkeys o multisig), claves de sesión para juegos, límites de gasto y mecanismos de recuperación social. La cuenta, no la red, impone las reglas.
  2. Paymasters: Estos contratos especiales pueden patrocinar las tarifas de gas para los usuarios o permitirles pagar con tokens ERC‑20. Esta es la clave para desbloquear una incorporación real de “sin ETH en la cartera” y crear experiencias de un solo clic al agrupar múltiples llamadas en una única operación.
  3. Seguridad DoS y Reglas: El mempool público de ERC‑4337 está protegido por reglas de validación off‑chain estandarizadas (definidas en ERC‑7562) que evitan que los Bundlers desperdicien recursos en operaciones destinadas a fallar. Si bien pueden existir mempools alternativos para casos de uso especializados, estas reglas compartidas mantienen el ecosistema coherente y seguro.

Modelo mental: ERC‑4337 convierte las carteras en aplicaciones programables. En lugar de solo firmar transacciones crudas, los usuarios envían “intenciones” que el código de su cuenta valida y el contrato EntryPoint ejecuta — de forma segura y atómica.


Introducción: ERC-4804 en una Página

ERC‑4804 ofrece un mapeo simple y directo de una URL web3:// a una llamada solo de lectura en EVM. La gramática de la URL es intuitiva: web3://<nombre-o-dirección>[:chainId]/<método>/<arg0>?returns=(tipos). Los nombres pueden resolverse mediante sistemas como ENS, y los argumentos se tipan automáticamente según el ABI del contrato.

Algunos ejemplos:

  • web3://uniswap.eth/ llamaría al contrato en la dirección uniswap.eth con calldata vacío.
  • web3://.../balanceOf/vitalik.eth?returns=(uint256) codificaría en ABI una llamada a la función balanceOf con la dirección de Vitalik y devolvería un resultado JSON tipado correctamente.

Crucialmente, este estándar es actualmente para llamadas solo de lectura (equivalentes a funciones view de Solidity). Cualquier acción que cambie el estado sigue requiriendo una transacción — justo donde entran ERC‑4337 o EIP‑7702. Con web3 registrado como esquema URI provisional en IANA, el camino está abierto para soporte nativo en navegadores y clientes, aunque por ahora a menudo depende de extensiones o pasarelas.

Modelo mental: ERC‑4804 convierte recursos en cadena en objetos web enlazables. “Compartir esta vista de contrato como URL” se vuelve tan natural como compartir un enlace a un panel de control.


Juntos: “Experiencias En Cadena Clicables”

Combinar estos dos estándares desbloquea un patrón poderoso para construir aplicaciones descentralizadas hoy.

Primero, entregas una UI verificable vía web3://. En lugar de alojar tu frontend en un servidor centralizado como S3, puedes almacenar una interfaz HTML o SVG mínima directamente en cadena. Un enlace como web3://app.eth/render permite al cliente resolver la URL y renderizar la UI directamente desde el contrato, asegurando que el usuario vea exactamente lo que el código dicta.

Desde esa interfaz verificable, puedes disparar una acción de un solo clic vía ERC‑4337. Un botón “Mint” o “Subscribe” puede compilar una UserOperation que un paymaster patrocina. El usuario aprueba con una passkey o un simple prompt biométrico, y el contrato EntryPoint ejecuta una llamada agrupada que despliega su cuenta inteligente (si es su primera vez) y completa la acción deseada en un solo paso atómico.

Esto crea una transferencia profunda de enlace. La UI puede incrustar enlaces basados en intención que son manejados directamente por la cartera del usuario, eliminando la necesidad de enviarlos a un sitio externo que pueda no ser de confianza. El contenido es el contrato, y la acción es la cuenta.

Esto habilita:

  • Pruebas sin gas y onboarding “just works”: Los nuevos usuarios no necesitan adquirir ETH para comenzar. Tu aplicación puede patrocinar sus primeras interacciones, reduciendo drásticamente la fricción.
  • Estado compartible: Un enlace web3:// es una consulta al estado de la blockchain. Perfecto para dashboards, pruebas de propiedad o cualquier contenido que deba ser verificablemente a prueba de manipulaciones.
  • Flujos amigables para agentes: Los agentes de IA pueden obtener estado verificable vía URLs web3:// y enviar intenciones transaccionales a través de ERC‑4337 usando claves de sesión limitadas, todo sin scraping de pantalla frágil o manejo inseguro de claves privadas.

Notas de Diseño para Constructores

Al implementar estos estándares, hay algunas decisiones arquitectónicas a considerar. Para ERC‑4337, es aconsejable comenzar con plantillas mínimas de cuentas inteligentes y añadir capacidades mediante módulos guardados para mantener la lógica de validación central simple y segura. Tu política de paymaster debe ser robusta, con límites claros en el gas patrocinado y listas blancas de métodos aprobados para prevenir ataques de griefing.

Para ERC‑4804, prioriza enlaces legibles usando nombres ENS. Sé explícito con el chainId para evitar ambigüedades e incluye el parámetro returns=(…) para asegurar que los clientes reciban respuestas tipadas y predecibles. Aunque puedes renderizar UI completas, suele ser mejor mantener HTML/SVG en cadena al mínimo, usándolos como shells verificables que pueden obtener activos más pesados de almacenamiento descentralizado como IPFS.

Finalmente, recuerda que EIP‑7702 y ERC‑4337 trabajan juntos, no en contra. Con EIP‑7702 activo en la actualización Pectra, los usuarios de EOAs existentes pueden delegar acciones a lógica de contrato sin desplegar una cuenta inteligente completa. Las herramientas del ecosistema de abstracción de cuentas ya se están alineando para soportar esto, suavizando la ruta de migración para todos.


Seguridad, Realidad y Limitaciones

Aunque potentes, estos sistemas tienen compensaciones. El contrato EntryPoint es un punto de estrangulamiento central por diseño; simplifica el modelo de seguridad pero también concentra riesgo. Siempre utiliza versiones auditadas y canónicas. Las reglas de validación del mempool de ERC‑7562 son una convención social, no una regla impuesta on‑chain, así que no asumas que todo mempool alternativo ofrece la misma resistencia a censura o protección DoS.

Además, web3:// sigue madurando. Sigue siendo un estándar de solo lectura, y cualquier operación de escritura requiere una transacción. Si bien el protocolo es descentralizado, las pasarelas y clientes que resuelven estas URLs pueden ser puntos potenciales de falla o censura. La verdadera “desbloqueabilidad” dependerá de un soporte nativo amplio en clientes.


Un Plano Concreto

Imagina que quieres construir un club de membresía impulsado por NFT con una UI verificable y un proceso de unión de un solo clic. Así podrías implementarlo este trimestre:

  1. Compartir la UI: Distribuye un enlace como web3://club.eth/home. Cuando un usuario lo abre, su cliente resuelve la URL, llama al contrato y renderiza una UI en cadena que muestra la lista de miembros permitidos y el precio de mint.
  2. Unión de Un Solo Clic: El usuario pulsa un botón “Unirse”. Su cartera compila una UserOperation de ERC‑4337 patrocinada por tu paymaster. Esta única operación agrupa tres llamadas: desplegar la cuenta inteligente del usuario (si no la tiene), pagar la tarifa de mint y registrar sus datos de perfil.
  3. Recibo Verificable: Tras la confirmación de la transacción, al usuario se le muestra una vista de confirmación que es otro enlace web3://, como web3://club.eth/receipt/<tokenId>, creando un vínculo permanente en cadena a su prueba de membresía.

El Gran Panorama

Estos dos estándares señalan un cambio fundamental en cómo construimos sobre Ethereum. Las cuentas se están convirtiendo en software. ERC‑4337 y EIP‑7702 están transformando la “UX de la cartera” en un espacio para verdadera innovación de producto, yendo más allá de las lecciones sobre gestión de claves. Al mismo tiempo, los enlaces se están convirtiendo en consultas. ERC‑4804 devuelve la URL como un primitivo para direccionar hechos verificables en cadena, no solo los frontends que los proxy.

Juntos, acortan la brecha entre lo que los usuarios hacen clic y lo que los contratos ejecutan. Esa brecha antes estaba llena por servidores web centralizados y suposiciones de confianza. Ahora puede ser cubierta por rutas de código verificables y mempools abiertos y sin permisos.

Si construyes aplicaciones cripto de consumo, esta es tu oportunidad de hacer que el primer minuto del usuario sea encantador. Comparte un enlace, muestra la verdad, patrocina la primera acción y mantén a tus usuarios dentro de un bucle verificable. Las vías están aquí — ahora es momento de lanzar las experiencias.

Presentando el Panel de Control de BlockEden.xyz v3: Una Experiencia Moderna, Más Rápida y Más Intuitiva

· 5 min de lectura
Dora Noda
Software Engineer

Resumen de una frase: Hemos rediseñado completamente nuestro panel de control con Next.js App Router, componentes shadcn-ui y Tailwind CSS para ofrecer una experiencia más rápida, más receptiva y visualmente atractiva al gestionar el acceso a tu API de blockchain.

Hoy, estamos emocionados de anunciar el lanzamiento del Panel de Control de BlockEden.xyz v3, que representa nuestra mayor actualización de interfaz de usuario desde el inicio de la plataforma. No se trata solo de una renovación visual, sino de una reestructuración arquitectónica completa diseñada para que tu interacción con nuestros servicios de API de blockchain sea más fluida, rápida y más intuitiva que nunca.

Qué hay de nuevo en el Panel de Control v3

1. Stack tecnológico moderno para un rendimiento mejorado

El Panel de Control v3 está construido sobre Next.js App Router, reemplazando la arquitectura anterior de Pages Router. Este cambio fundamental aporta mejoras significativas de rendimiento mediante:

  • Componentes del servidor: Cargas de página más rápidas con menos JavaScript del lado del cliente
  • Enrutamiento mejorado: Navegación más intuitiva con diseños anidados
  • SEO mejorado: Mayor visibilidad en motores de búsqueda mediante un manejo mejorado de metadatos

También hemos migrado de Ant Design y Styletron a componentes shadcn-ui impulsados por Tailwind CSS, lo que resulta en:

  • Tamaño de paquete reducido: Tiempos de carga más rápidos en todas las páginas
  • Lenguaje de diseño consistente: Una experiencia visual más cohesionada
  • Mejor accesibilidad: Navegación con teclado mejorada y soporte para lectores de pantalla

2. Gestión simplificada de claves de acceso

Hemos rediseñado completamente la experiencia de gestión de claves de acceso:

  • Creación intuitiva de claves: Genera nuevas claves API con solo unos clics
  • Visibilidad mejorada: Distingue fácilmente entre diferentes tipos de claves y permisos
  • Seguridad mejorada: Mejor aislamiento entre entornos de clientes con una gestión adecuada de inquilinos
  • Copiado con un clic: Copia sin problemas las claves al portapapeles para integrarlas en tus proyectos

[PLACEHOLDER DE IMAGEN: Captura de pantalla de la nueva interfaz de gestión de claves de acceso]

3. Sección de cuenta y facturación rediseñada

Gestionar tu cuenta y suscripciones ahora es más sencillo:

  • Gestión simplificada de suscripciones: Actualiza, reduce o cancela tu plan fácilmente
  • Información de facturación más clara: Precios más transparentes y estadísticas de uso
  • Proceso de pago simplificado: Manejo seguro y eficiente de pagos con integración mejorada de Stripe
  • Integración de billetera mejorada: Mejor conexión con tus billeteras cripto

4. Aislamiento estricto de inquilinos

Para usuarios empresariales que gestionan múltiples proyectos, hemos implementado un aislamiento estricto de inquilinos:

  • Configuraciones específicas por cliente: Cada ID de cliente tiene su propio entorno aislado
  • Seguridad mejorada: Aplicación adecuada de límites entre diferentes inquilinos
  • Seguimiento mejorado: Mayor visibilidad de los patrones de uso en diferentes proyectos

Detrás de cámaras: Mejoras técnicas

Aunque los cambios visuales son evidentes de inmediato, hemos realizado mejoras significativas bajo el capó:

1. Cambio arquitectónico

La migración de Pages Router a App Router representa un cambio fundamental en la estructura de nuestra aplicación:

  • Arquitectura basada en componentes: Código más modular y mantenible
  • Obtención de datos mejorada: Renderizado del lado del servidor y carga de datos más eficientes
  • Mejor gestión del estado: Separación de responsabilidades más clara y actualizaciones de estado más predecibles

2. Flujo de autenticación mejorado

Hemos simplificado nuestro sistema de autenticación:

  • Proceso de inicio de sesión simplificado: Autenticación más rápida y fiable
  • Gestión de sesiones mejorada: Mejor manejo de tokens de autenticación
  • Seguridad mejorada: Protección más robusta contra vulnerabilidades de seguridad comunes

3. Integración de API optimizada

Nuestra integración GraphQL ha sido completamente renovada:

  • Proveedor Apollo Client: Configurado con manejo adecuado de ID de cliente
  • Política de obtención network-only: Actualizaciones de datos en tiempo real para información crítica
  • Consultas optimizadas: Reducción de transferencia de datos y mejora de tiempos de respuesta

Cómo comenzar con el Panel de Control v3

Todos los usuarios existentes han sido migrados automáticamente al Panel de Control v3. Simplemente inicia sesión en https://BlockEden.xyz/dash para experimentar la nueva interfaz.

Si eres nuevo en BlockEden.xyz, ahora es el momento perfecto para registrarte y experimentar nuestros servicios de API de blockchain de última generación a través de nuestro panel de control moderno.

¿Qué sigue?

Esta actualización representa un hito importante en nuestro camino, pero no nos detenemos aquí. En los próximos meses, presentaremos:

  • Analíticas mejoradas: Información más detallada sobre el uso de tu API
  • Integraciones de redes adicionales: Soporte para más redes blockchain
  • Herramientas de desarrollo mejoradas: Mejor documentación y soporte de SDK
  • Alertas personalizadas: Notificaciones configurables para eventos críticos

Valoramos tus comentarios

Como con cualquier actualización importante, tus comentarios son invaluables. Si encuentras algún problema o tienes sugerencias de mejora, por favor contacta a nuestro equipo de soporte o únete a nuestra comunidad de Discord.

Gracias por ser parte del viaje de BlockEden.xyz. Estamos entusiasmados de seguir construyendo la infraestructura que impulsa el futuro descentralizado.

Conectando la IA y la Web3 a través de MCP: Un Análisis Panorámico

· 20 min de lectura
Dora Noda
Software Engineer

Introducción

La IA y la Web3 están convergiendo de maneras poderosas, con las interfaces generales de IA ahora concebidas como un tejido conectivo para la web descentralizada. Un concepto clave que emerge de esta convergencia es MCP, que se refiere a “Model Context Protocol” (Protocolo de Contexto de Modelo, introducido por Anthropic) o se describe vagamente como un Protocolo de Conexión del Metaverso en discusiones más amplias. En esencia, MCP es un marco estandarizado que permite a los sistemas de IA interactuar con herramientas y redes externas de una manera natural y segura, potencialmente “conectando” agentes de IA a cada rincón del ecosistema Web3. Este informe proporciona un análisis exhaustivo de cómo las interfaces generales de IA (como los agentes de modelos de lenguaje grandes y los sistemas neuro-simbólicos) podrían conectar todo en el mundo Web3 a través de MCP, cubriendo los antecedentes históricos, la arquitectura técnica, el panorama de la industria, los riesgos y el potencial futuro.

1. Antecedentes del Desarrollo

1.1 La Evolución de la Web3 y sus Promesas Incumplidas

El término “Web3” fue acuñado alrededor de 2014 para describir una web descentralizada impulsada por blockchain. La visión era ambiciosa: una internet sin permisos centrada en la propiedad del usuario. Los entusiastas imaginaron reemplazar la infraestructura centralizada de la Web2 con alternativas basadas en blockchain, como Ethereum Name Service (para DNS), Filecoin o IPFS (para almacenamiento) y DeFi para los rieles financieros. En teoría, esto arrebataría el control a las grandes plataformas tecnológicas y otorgaría a los individuos autosoberanía sobre sus datos, identidad y activos.

La realidad se quedó corta. A pesar de años de desarrollo y expectación, el impacto general de la Web3 siguió siendo marginal. Los usuarios promedio de internet no acudieron en masa a las redes sociales descentralizadas ni comenzaron a gestionar claves privadas. Las razones clave incluyeron una mala experiencia de usuario, transacciones lentas y costosas, estafas de alto perfil e incertidumbre regulatoria. La “web de propiedad” descentralizada en gran medida “no logró materializarse” más allá de una comunidad de nicho. A mediados de la década de 2020, incluso los defensores de las criptomonedas admitieron que la Web3 no había supuesto un cambio de paradigma para el usuario promedio.

Mientras tanto, la IA estaba experimentando una revolución. A medida que el capital y el talento de los desarrolladores se desplazaban de las criptomonedas a la IA, los avances transformadores en el aprendizaje profundo y los modelos fundacionales (GPT-3, GPT-4, etc.) capturaron la imaginación del público. La IA generativa demostró una utilidad clara —produciendo contenido, código y decisiones— de una manera que las aplicaciones cripto habían tenido dificultades para lograr. De hecho, el impacto de los modelos de lenguaje grandes en solo un par de años superó con creces una década de adopción de usuarios de blockchain. Este contraste llevó a algunos a bromear diciendo que “la Web3 se desperdició en las criptomonedas” y que la verdadera Web 3.0 está emergiendo de la ola de la IA.

1.2 El Auge de las Interfaces Generales de IA

A lo largo de décadas, las interfaces de usuario evolucionaron desde páginas web estáticas (Web1.0) hasta aplicaciones interactivas (Web2.0), pero siempre dentro de los confines de hacer clic en botones y rellenar formularios. Con la IA moderna, especialmente los modelos de lenguaje grandes (LLM), ha llegado un nuevo paradigma de interfaz: el lenguaje natural. Los usuarios pueden simplemente expresar su intención en lenguaje sencillo y hacer que los sistemas de IA ejecuten acciones complejas en muchos dominios. Este cambio es tan profundo que algunos sugieren redefinir “Web 3.0” como la era de los agentes impulsados por IA (“la Web Agéntica”) en lugar de la definición anterior centrada en blockchain.

Sin embargo, los primeros experimentos con agentes de IA autónomos expusieron un cuello de botella crítico. Estos agentes —por ejemplo, prototipos como AutoGPT— podían generar texto o código, pero carecían de una forma robusta de comunicarse con sistemas externos y entre sí. No había “un lenguaje común nativo de IA” para la interoperabilidad. Cada integración con una herramienta o fuente de datos era un apaño a medida, y la interacción de IA a IA no tenía un protocolo estándar. En términos prácticos, un agente de IA podría tener una gran capacidad de razonamiento pero fallar en la ejecución de tareas que requerían el uso de aplicaciones web o servicios on-chain, simplemente porque no sabía cómo hablar con esos sistemas. Este desajuste —cerebros potentes, E/S primitiva— era similar a tener un software súper inteligente atrapado detrás de una torpe GUI.

1.3 Convergencia y el Surgimiento de MCP

Para 2024, se hizo evidente que para que la IA alcanzara su máximo potencial (y para que la Web3 cumpliera su promesa), se necesitaba una convergencia: los agentes de IA requieren un acceso fluido a las capacidades de la Web3 (aplicaciones descentralizadas, contratos, datos), y la Web3 necesita más inteligencia y usabilidad, que la IA puede proporcionar. Este es el contexto en el que nació MCP (Model Context Protocol). Introducido por Anthropic a finales de 2024, MCP es un estándar abierto para la comunicación entre IA y herramientas que resulta natural para los LLM. Proporciona una forma estructurada y reconocible para que los “hosts” de IA (como ChatGPT, Claude, etc.) encuentren y utilicen una variedad de herramientas y recursos externos a través de servidores MCP. En otras palabras, MCP es una capa de interfaz común que permite a los agentes de IA conectarse a servicios web, APIs e incluso funciones de blockchain, sin codificar a medida cada integración.

Piense en MCP como “el USB-C de las interfaces de IA”. Así como el USB-C estandarizó cómo se conectan los dispositivos (para que no necesite cables diferentes para cada dispositivo), MCP estandariza cómo los agentes de IA se conectan a herramientas y datos. En lugar de codificar diferentes llamadas a API para cada servicio (Slack vs. Gmail vs. nodo de Ethereum), un desarrollador puede implementar la especificación MCP una vez, y cualquier IA compatible con MCP puede entender cómo usar ese servicio. Los principales actores de la IA vieron rápidamente la importancia: Anthropic hizo de código abierto a MCP, y empresas como OpenAI y Google están desarrollando soporte para él en sus modelos. Este impulso sugiere que MCP (o “Protocolos de Meta Conectividad” similares) podría convertirse en la columna vertebral que finalmente conecte la IA y la Web3 de una manera escalable.

Cabe destacar que algunos tecnólogos argumentan que esta conectividad centrada en la IA es la verdadera realización de la Web3.0. En palabras de Simba Khadder, “MCP tiene como objetivo estandarizar una API entre los LLM y las aplicaciones”, de manera similar a cómo las APIs REST permitieron la Web 2.0, lo que significa que la próxima era de la Web3 podría definirse por interfaces de agentes inteligentes en lugar de solo por blockchains. En lugar de la descentralización por sí misma, la convergencia con la IA podría hacer que la descentralización sea útil, al ocultar la complejidad detrás del lenguaje natural y los agentes autónomos. El resto de este informe profundiza en cómo, técnica y prácticamente, las interfaces generales de IA (a través de protocolos como MCP) pueden conectar todo en el mundo Web3.

2. Arquitectura Técnica: Interfaces de IA Uniendo Tecnologías Web3

Incrustar agentes de IA en la pila de Web3 requiere integración en múltiples niveles: redes de blockchain y contratos inteligentes, almacenamiento descentralizado, sistemas de identidad y economías basadas en tokens. Las interfaces generales de IA —desde grandes modelos fundacionales hasta sistemas híbridos neuro-simbólicos— pueden servir como un “adaptador universal” que conecta estos componentes. A continuación, analizamos la arquitectura de dicha integración:

Figura: Un diagrama conceptual de la arquitectura de MCP, que muestra cómo los hosts de IA (aplicaciones basadas en LLM como Claude o ChatGPT) utilizan un cliente MCP para conectarse a varios servidores MCP. Cada servidor proporciona un puente a alguna herramienta o servicio externo (por ejemplo, Slack, Gmail, calendarios o datos locales), análogo a los periféricos que se conectan a través de un concentrador universal. Esta interfaz MCP estandarizada permite a los agentes de IA acceder a servicios remotos y recursos on-chain a través de un protocolo común.

2.1 Agentes de IA como Clientes Web3 (Integración con Blockchains)

En el núcleo de la Web3 se encuentran las blockchains y los contratos inteligentes, máquinas de estado descentralizadas que pueden hacer cumplir la lógica sin necesidad de confianza. ¿Cómo puede una interfaz de IA interactuar con estos? Hay dos direcciones a considerar:

  • IA leyendo de la blockchain: Un agente de IA puede necesitar datos on-chain (por ejemplo, precios de tokens, saldo de activos de un usuario, propuestas de DAO) como contexto para sus decisiones. Tradicionalmente, recuperar datos de la blockchain requiere interactuar con APIs RPC de nodos o bases de datos de subgrafos. Con un marco como MCP, una IA puede consultar un servidor MCP estandarizado de “datos de blockchain” para obtener información on-chain en tiempo real. Por ejemplo, un agente habilitado para MCP podría solicitar el último volumen de transacciones de un determinado token, o el estado de un contrato inteligente, y el servidor MCP se encargaría de los detalles de bajo nivel para conectarse a la blockchain y devolver los datos en un formato que la IA pueda usar. Esto aumenta la interoperabilidad al desacoplar la IA del formato de API de cualquier blockchain específica.

  • IA escribiendo en la blockchain: De manera más potente, los agentes de IA pueden ejecutar llamadas a contratos inteligentes o transacciones a través de integraciones Web3. Una IA podría, por ejemplo, ejecutar autónomamente una operación en un exchange descentralizado o ajustar parámetros en un contrato inteligente si se cumplen ciertas condiciones. Esto se logra mediante la invocación por parte de la IA de un servidor MCP que encapsula la funcionalidad de transacción de la blockchain. Un ejemplo concreto es el servidor MCP de thirdweb para cadenas EVM, que permite a cualquier cliente de IA compatible con MCP interactuar con Ethereum, Polygon, BSC, etc., abstrayendo la mecánica específica de la cadena. Usando una herramienta así, un agente de IA podría desencadenar acciones on-chain “sin intervención humana”, permitiendo dApps autónomas; por ejemplo, una bóveda DeFi impulsada por IA que se reequilibra a sí misma firmando transacciones cuando cambian las condiciones del mercado.

Bajo el capó, estas interacciones todavía dependen de wallets, claves y tarifas de gas, pero a la interfaz de IA se le puede dar acceso controlado a un wallet (con sandboxes de seguridad adecuados) para realizar las transacciones. Los oráculos y los puentes entre cadenas también entran en juego: redes de oráculos como Chainlink sirven como un puente entre la IA y las blockchains, permitiendo que los resultados de la IA sean introducidos on-chain de manera confiable. El Protocolo de Interoperabilidad entre Cadenas (CCIP) de Chainlink, por ejemplo, podría permitir que un modelo de IA considerado confiable desencadene múltiples contratos en diferentes cadenas simultáneamente en nombre de un usuario. En resumen, las interfaces generales de IA pueden actuar como un nuevo tipo de cliente Web3, uno que puede tanto consumir datos de la blockchain como producir transacciones de la blockchain a través de protocolos estandarizados.

2.2 Sinergia Neuro-Simbólica: Combinando el Razonamiento de la IA con los Contratos Inteligentes

Un aspecto intrigante de la integración IA-Web3 es el potencial de las arquitecturas neuro-simbólicas que combinan la capacidad de aprendizaje de la IA (redes neuronales) con la lógica rigurosa de los contratos inteligentes (reglas simbólicas). En la práctica, esto podría significar que los agentes de IA manejen la toma de decisiones no estructurada y pasen ciertas tareas a los contratos inteligentes para una ejecución verificable. Por ejemplo, una IA podría analizar el sentimiento del mercado (una tarea difusa), pero luego ejecutar operaciones a través de un contrato inteligente determinista que sigue reglas de riesgo preestablecidas. El marco MCP y los estándares relacionados hacen factibles tales transferencias al darle a la IA una interfaz común para llamar a funciones de contrato o para consultar las reglas de una DAO antes de actuar.

Un ejemplo concreto es el AI-DSL (Lenguaje Específico de Dominio de IA) de SingularityNET, que tiene como objetivo estandarizar la comunicación entre agentes de IA en su red descentralizada. Esto puede verse como un paso hacia la integración neuro-simbólica: un lenguaje formal (simbólico) para que los agentes soliciten servicios de IA o datos entre sí. De manera similar, proyectos como AlphaCode de DeepMind u otros podrían eventualmente conectarse para que los contratos inteligentes llamen a modelos de IA para la resolución de problemas on-chain. Aunque ejecutar grandes modelos de IA directamente on-chain es impráctico hoy en día, están surgiendo enfoques híbridos: por ejemplo, ciertas blockchains permiten la verificación de cálculos de ML a través de pruebas de conocimiento cero o ejecución confiable, lo que permite la verificación on-chain de resultados de IA off-chain. En resumen, la arquitectura técnica concibe los sistemas de IA y los contratos inteligentes de blockchain como componentes complementarios, orquestados a través de protocolos comunes: la IA se encarga de la percepción y las tareas abiertas, mientras que las blockchains proporcionan integridad, memoria y el cumplimiento de las reglas acordadas.

2.3 Almacenamiento Descentralizado y Datos para la IA

La IA prospera con los datos, y la Web3 ofrece nuevos paradigmas para el almacenamiento y el intercambio de datos. Las redes de almacenamiento descentralizado (como IPFS/Filecoin, Arweave, Storj, etc.) pueden servir tanto como repositorios para artefactos de modelos de IA como fuentes de datos de entrenamiento, con control de acceso basado en blockchain. Una interfaz general de IA, a través de MCP o similar, podría obtener archivos o conocimiento del almacenamiento descentralizado con la misma facilidad que desde una API de Web2. Por ejemplo, un agente de IA podría extraer un conjunto de datos del mercado de Ocean Protocol o un archivo cifrado de un almacenamiento distribuido, si tiene las claves o los pagos adecuados.

Ocean Protocol en particular se ha posicionado como una plataforma de “economía de datos de IA”, utilizando blockchain para tokenizar datos e incluso servicios de IA. En Ocean, los conjuntos de datos están representados por datatokens que controlan el acceso; un agente de IA podría obtener un datatoken (quizás pagando con criptomonedas o a través de algún derecho de acceso) y luego usar un servidor MCP de Ocean para recuperar los datos reales para su análisis. El objetivo de Ocean es desbloquear “datos inactivos” para la IA, incentivando el intercambio mientras se preserva la privacidad. Por lo tanto, una IA conectada a la Web3 podría acceder a un vasto corpus descentralizado de información —desde bóvedas de datos personales hasta datos gubernamentales abiertos— que antes estaba aislado. La blockchain asegura que el uso de los datos sea transparente y pueda ser recompensado de manera justa, alimentando un ciclo virtuoso donde más datos están disponibles para la IA y más contribuciones de IA (como modelos entrenados) pueden ser monetizadas.

Los sistemas de identidad descentralizada también juegan un papel aquí (discutido más en la siguiente subsección): pueden ayudar a controlar quién o qué tiene permitido acceder a ciertos datos. Por ejemplo, a un agente de IA médico se le podría exigir que presente una credencial verificable (prueba on-chain de cumplimiento con HIPAA o similar) antes de que se le permita descifrar un conjunto de datos médicos del almacenamiento IPFS personal de un paciente. De esta manera, la arquitectura técnica asegura que los datos fluyan hacia la IA cuando sea apropiado, pero con gobernanza y registros de auditoría on-chain para hacer cumplir los permisos.

2.4 Identidad y Gestión de Agentes en un Entorno Descentralizado

Cuando los agentes de IA autónomos operan en un ecosistema abierto como la Web3, la identidad y la confianza se vuelven primordiales. Los marcos de identidad descentralizada (DID) proporcionan una forma de establecer identidades digitales para agentes de IA que pueden ser verificadas criptográficamente. Cada agente (o el humano/organización que lo despliega) puede tener un DID y credenciales verificables asociadas que especifican sus atributos y permisos. Por ejemplo, un bot de trading de IA podría llevar una credencial emitida por un sandbox regulatorio que certifique que puede operar dentro de ciertos límites de riesgo, o un moderador de contenido de IA podría demostrar que fue creado por una organización de confianza y ha sido sometido a pruebas de sesgo.

A través de registros de identidad y sistemas de reputación on-chain, el mundo Web3 puede hacer cumplir la responsabilidad por las acciones de la IA. Cada transacción que realiza un agente de IA puede ser rastreada hasta su ID, y si algo sale mal, las credenciales te dicen quién lo construyó o quién es responsable. Esto aborda un desafío crítico: sin identidad, un actor malicioso podría crear agentes de IA falsos para explotar sistemas o difundir desinformación, y nadie podría distinguir los bots de los servicios legítimos. La identidad descentralizada ayuda a mitigar eso al permitir una autenticación robusta y distinguir los agentes de IA auténticos de las falsificaciones.

En la práctica, una interfaz de IA integrada con la Web3 usaría protocolos de identidad para firmar sus acciones y solicitudes. Por ejemplo, cuando un agente de IA llama a un servidor MCP para usar una herramienta, podría incluir un token o firma vinculada a su identidad descentralizada, para que el servidor pueda verificar que la llamada proviene de un agente autorizado. Los sistemas de identidad basados en blockchain (como el ERC-725 de Ethereum o los DID de W3C anclados en un ledger) aseguran que esta verificación sea sin confianza y verificable globalmente. El concepto emergente de “wallets de IA” se relaciona con esto: esencialmente, dar a los agentes de IA wallets de criptomonedas que están vinculados con su identidad, para que puedan gestionar claves, pagar por servicios o hacer staking de tokens como una fianza (que podría ser recortada por mal comportamiento). ArcBlock, por ejemplo, ha discutido cómo “los agentes de IA necesitan un wallet” y un DID para operar de manera responsable en entornos descentralizados.

En resumen, la arquitectura técnica prevé a los agentes de IA como ciudadanos de primera clase en la Web3, cada uno con una identidad on-chain y posiblemente una participación en el sistema, utilizando protocolos como MCP para interactuar. Esto crea una red de confianza: los contratos inteligentes pueden requerir las credenciales de una IA antes de cooperar, y los usuarios pueden optar por delegar tareas solo a aquellas IA que cumplan con ciertas certificaciones on-chain. Es una mezcla de la capacidad de la IA con las garantías de confianza de la blockchain.

2.5 Economías de Tokens e Incentivos para la IA

La tokenización es un sello distintivo de la Web3, y se extiende también al dominio de la integración de la IA. Al introducir incentivos económicos a través de tokens, las redes pueden fomentar comportamientos deseados tanto de los desarrolladores de IA como de los propios agentes. Están surgiendo varios patrones:

  • Pago por Servicios: Los modelos y servicios de IA pueden ser monetizados on-chain. SingularityNET fue pionero en esto al permitir a los desarrolladores desplegar servicios de IA y cobrar a los usuarios en un token nativo (AGIX) por cada llamada. En un futuro habilitado para MCP, uno podría imaginar cualquier herramienta o modelo de IA como un servicio plug-and-play donde el uso se mide a través de tokens o micropagos. Por ejemplo, si un agente de IA utiliza una API de visión de terceros a través de MCP, podría manejar automáticamente el pago transfiriendo tokens al contrato inteligente del proveedor de servicios. Fetch.ai de manera similar visualiza mercados donde “agentes económicos autónomos” intercambian servicios y datos, con su nuevo LLM de Web3 (ASI-1) presumiblemente integrando transacciones cripto para el intercambio de valor.

  • Staking y Reputación: Para asegurar la calidad y la fiabilidad, algunos proyectos requieren que los desarrolladores o agentes hagan staking de tokens. Por ejemplo, el proyecto DeMCP (un mercado descentralizado de servidores MCP) planea usar incentivos de tokens para recompensar a los desarrolladores por crear servidores MCP útiles, y posiblemente hacer que hagan staking de tokens como señal de compromiso con la seguridad de su servidor. La reputación también podría estar vinculada a los tokens; por ejemplo, un agente que se desempeña consistentemente bien podría acumular tokens de reputación o reseñas positivas on-chain, mientras que uno que se comporta mal podría perder su stake o ganar marcas negativas. Esta reputación tokenizada puede luego retroalimentar el sistema de identidad mencionado anteriormente (los contratos inteligentes o los usuarios verifican la reputación on-chain del agente antes de confiar en él).

  • Tokens de Gobernanza: Cuando los servicios de IA se convierten en parte de plataformas descentralizadas, los tokens de gobernanza permiten a la comunidad dirigir su evolución. Proyectos como SingularityNET y Ocean tienen DAOs donde los poseedores de tokens votan sobre cambios en el protocolo o la financiación de iniciativas de IA. En la Alianza de Superinteligencia Artificial (ASI) combinada —una fusión recientemente anunciada de SingularityNET, Fetch.ai y Ocean Protocol— un token unificado (ASI) está destinado a gobernar la dirección de un ecosistema conjunto de IA+blockchain. Dichos tokens de gobernanza podrían decidir políticas como qué estándares adoptar (por ejemplo, soportar MCP o protocolos A2A), qué proyectos de IA incubar o cómo manejar las directrices éticas para los agentes de IA.

  • Acceso y Utilidad: Los tokens pueden controlar el acceso no solo a los datos (como con los datatokens de Ocean) sino también al uso de modelos de IA. Un escenario posible son los “NFTs de modelos” o similares, donde poseer un token te otorga derechos sobre los resultados de un modelo de IA o una participación en sus ganancias. Esto podría sustentar los mercados de IA descentralizados: imagina un NFT que representa la propiedad parcial de un modelo de alto rendimiento; los propietarios ganan colectivamente cada vez que el modelo se utiliza en tareas de inferencia, y pueden votar sobre su ajuste fino. Aunque experimental, esto se alinea con el ethos de la Web3 de propiedad compartida aplicada a los activos de IA.

En términos técnicos, integrar tokens significa que los agentes de IA necesitan funcionalidad de wallet (como se señaló, muchos tendrán sus propios wallets de criptomonedas). A través de MCP, una IA podría tener una “herramienta de wallet” que le permita verificar saldos, enviar tokens o llamar a protocolos DeFi (quizás para intercambiar un token por otro para pagar un servicio). Por ejemplo, si un agente de IA que se ejecuta en Ethereum necesita algunos tokens de Ocean para comprar un conjunto de datos, podría intercambiar automáticamente algunos ETH por $OCEAN a través de un DEX usando un plugin de MCP, y luego proceder con la compra, todo sin intervención humana, guiado por las políticas establecidas por su propietario.

En general, la economía de tokens proporciona la capa de incentivos en la arquitectura IA-Web3, asegurando que los contribuyentes (ya sea que proporcionen datos, código de modelo, poder de cómputo o auditorías de seguridad) sean recompensados, y que los agentes de IA tengan “algo en juego” que los alinee (hasta cierto punto) con las

NameFi.io: Convertir cada dominio en un activo programable

· 5 min de lectura
Zainan Zhou
Zainan Zhou
Founder of Namefi.io

NameFi.io: Convertir cada dominio en un activo programable

Resumen de una frase para desarrolladores de BlockEden.xyz: NameFi acuña tus dominios familiares de Web2 (.com, .xyz y más de 300 TLDs) directamente en NFTs, preservando la compatibilidad total con DNS mientras desbloquea nuevas posibilidades para el comercio en cadena, la colateralización y la identidad.

Para los desarrolladores que construyen sobre BlockEden.xyz, esto representa una gran oportunidad para cerrar la brecha entre Web2 y Web3. Imagina un mundo donde tus usuarios ya no copian y pegan direcciones hexadecimales largas, sino que pueden enviar fondos directamente a tuempresa.com. Ese es el futuro que NameFi está construyendo hoy.

Por qué NameFi es un cambio de juego

1. Registra una vez, usa en todas partes: el puente fluido entre Web2 y Web3

A diferencia de muchas soluciones de dominios Web3 que requieren migrar fuera de la infraestructura existente, NameFi respeta y se construye sobre el legado del sistema DNS. Cuando registras o importas un dominio en NameFi, sus funciones DNS tradicionales continúan funcionando sin problemas, asegurando que tu sitio web, correo electrónico y otros servicios operen sin interrupciones. Simultáneamente, la propiedad del dominio se registra de forma inmutable como un NFT en cadena, abriendo la puerta al mundo descentralizado.

2. Seguridad respaldada por la acreditación de ICANN

La confianza es la base de la web descentralizada. NameFi es uno de los pocos registradores de dominios acreditados oficialmente por ICANN (Internet Corporation for Assigned Names and Numbers). Esto significa que, aunque NameFi ofrece servicios innovadores en cadena, también cumple con los más altos estándares globales para la infraestructura de internet, combinando flexibilidad descentralizada con cumplimiento y seguridad de nivel empresarial.

3. “DNSSEC sin gas” con AutoENS

Para muchos desarrolladores y usuarios, las altas tarifas de gas son una barrera importante para interactuar con blockchain. La función AutoENS de NameFi resuelve elegantemente este problema. A través de su innovadora tecnología “DNSSEC sin gas”, puedes mapear tu dominio a un subdominio ENS con un solo clic. Cuando un usuario envía cripto a esa dirección (p. ej., tudominio.xyz), la firma criptográfica se verifica automáticamente, sin requerir tarifas de gas ni de ti ni del usuario. Esto reduce drásticamente la barrera de entrada para la adopción masiva.

4. Desbloqueando la composibilidad financiera

Históricamente, el comercio de dominios ha sido lento, opaco e ineficiente. Al acuñar dominios como NFTs ERC‑721, NameFi lo cambia todo. Tu nombre de dominio ahora es un activo líquido y programable que puede ser:

  • Comercializado en cualquier mercado importante de NFTs como OpenSea y Blur.
  • Utilizado como colateral en protocolos DeFi para pedir prestado activos y mejorar la eficiencia de capital.
  • Aprovechado como token de gobernanza en DAOs, representando identidad y poder de voto.

Como destacan informes de analistas de la industria como Messari, esto inyecta liquidez y utilidad sin precedentes al mercado tradicional de dominios, que mueve miles de millones de dólares.

El flujo de trabajo principal: de DNS a NFT

  1. Registrar / Importar → Acuñar NFT: Cuando registras un nuevo dominio o importas uno existente a través de NameFi, los contratos inteligentes de la plataforma acuñan automáticamente un NFT correspondiente en Ethereum, registrando la propiedad y la fecha de expiración en cadena.
  2. Sincronización DNS ↔ Cadena: Los registros DNS se firman criptográficamente mediante DNSSEC y se sincronizan con el contrato inteligente, garantizando la integridad de los datos. A su vez, cuando el NFT del dominio se transfiere en cadena, NameFi asegura que el control DNS permanezca activo y disponible para el nuevo propietario.
  3. Comerciar / Colateralizar / Integrar: Como token ERC‑721 estándar, tu dominio NFT puede listarse en cualquier marketplace o integrarse con cualquier protocolo compatible, desde plataformas de préstamo DeFi hasta herramientas DAO.

Sinergia con BlockEden.xyz: escenarios prácticos de integración

La visión de NameFi complementa perfectamente la misión de BlockEden.xyz de ofrecer infraestructura multi‑cadena robusta y de alto rendimiento. Aquí tienes algunas formas en que los desarrolladores pueden comenzar a construir hoy:

  • Direcciones de cartera legibles por humanos: En el frontend de tu dApp, usa un endpoint RPC de BlockEden para resolver un dominio .com o .xyz directamente a su dirección de cartera correspondiente. Esto crea una experiencia de “enviar‑a‑dominio” sin fricción.

  • Monitoreo de riesgo de dominios: Aprovecha el Indexador de BlockEden para suscribirte a eventos de Transferencia del contrato NFT de dominios de NameFi. Así podrás vigilar en tiempo real el movimiento de dominios de alto valor o de marca, detectar posibles ataques de phishing o transferencias maliciosas y generar alertas.

  • Entrega de API todo‑en‑uno: NameFi planea listar sus API principales —registro, renovación y gestión DNS— en el Marketplace de API de BlockEden. Esto significará que los desarrolladores pronto necesitarán solo una clave API de BlockEden para acceder tanto a la infraestructura de nodos multi‑cadena como a potentes servicios de dominio, simplificando drásticamente la pila de desarrollo.

Comienza hoy

Un nombre de dominio ya no es solo una cadena de caracteres; es un activo programable y composable. Es momento de incorporarlo en tus contratos inteligentes, integrarlo en tus carteras y crear un punto de entrada verdaderamente amigable para los humanos en tu dApp.

  1. Visita NameFi.io para solicitar acceso beta e importar o registrar tu primer dominio en cadena.
  2. Únete a la comunidad: Entra al Discord conjunto de BlockEden & NameFi para compartir ideas de integración y obtener acceso anticipado a SDKs y ejemplos.
  3. Sigue el blog: Mantente al tanto del blog oficial de BlockEden para futuros artículos sobre mejores prácticas y métricas de rendimiento de la API de NameFi.

Enso Network: El motor de ejecución unificado basado en intenciones

· 43 min de lectura

Arquitectura del Protocolo

Enso Network es una plataforma de desarrollo Web3 construida como un motor de ejecución unificado y basado en intenciones para operaciones en la cadena. Su arquitectura abstrae la complejidad de la blockchain al mapear cada interacción en la cadena a un motor compartido que opera a través de múltiples cadenas. Los desarrolladores y usuarios especifican intenciones de alto nivel (resultados deseados como un intercambio de tokens, provisión de liquidez, estrategia de rendimiento, etc.), y la red de Enso encuentra y ejecuta la secuencia óptima de acciones para cumplir esas intenciones. Esto se logra a través de un diseño modular de "Acciones" y "Atajos".

Las Acciones son abstracciones granulares de contratos inteligentes (por ejemplo, un intercambio en Uniswap, un depósito en Aave) proporcionadas por la comunidad. Múltiples Acciones pueden componerse en Atajos, que son flujos de trabajo reutilizables que representan operaciones comunes de DeFi. Enso mantiene una biblioteca de estos Atajos en contratos inteligentes, por lo que las tareas complejas pueden ejecutarse mediante una sola llamada a la API o transacción. Esta arquitectura basada en intenciones permite a los desarrolladores centrarse en los resultados deseados en lugar de escribir código de integración de bajo nivel para cada protocolo y cadena.

La infraestructura de Enso incluye una red descentralizada (construida sobre el consenso de Tendermint) que sirve como una capa unificadora que conecta diferentes blockchains. La red agrega datos (estado de varias L1, rollups y appchains) en un estado de red compartido o libro mayor, permitiendo la componibilidad entre cadenas y una ejecución precisa en múltiples cadenas. En la práctica, esto significa que Enso puede leer y escribir en cualquier blockchain integrada a través de una única interfaz, actuando como un único punto de acceso para los desarrolladores. Inicialmente centrado en cadenas compatibles con EVM, Enso ha ampliado su soporte a ecosistemas no-EVM; por ejemplo, la hoja de ruta incluye integraciones para Monad (una L1 similar a Ethereum), Solana y Movement (una cadena de lenguaje Move) para el primer trimestre de 2025.

Participantes de la Red: La innovación de Enso radica en su modelo de participantes de tres niveles, que descentraliza cómo se procesan las intenciones:

  • Proveedores de Acciones – Desarrolladores que contribuyen con abstracciones de contratos modulares ("Acciones") que encapsulan interacciones específicas de protocolos. Estos bloques de construcción se comparten en la red para que otros los usen. Los Proveedores de Acciones son recompensados cada vez que su Acción contribuida se utiliza en una ejecución, incentivándolos a publicar módulos seguros y eficientes.

  • Graphers – Solucionadores independientes (algoritmos) que combinan Acciones en Atajos ejecutables para cumplir las intenciones de los usuarios. Múltiples Graphers compiten para encontrar la solución más óptima (la ruta más barata, más rápida o de mayor rendimiento) para cada solicitud, de manera similar a cómo compiten los solucionadores en un agregador de DEX. Solo se selecciona la mejor solución para la ejecución, y el Grapher ganador obtiene una parte de las tarifas. Este mecanismo competitivo fomenta la optimización continua de las rutas y estrategias en la cadena.

  • Validadores – Operadores de nodos que aseguran la red de Enso verificando y finalizando las soluciones de los Graphers. Los Validadores autentican las solicitudes entrantes, verifican la validez y seguridad de las Acciones/Atajos utilizados, simulan transacciones y, en última instancia, confirman la ejecución de la solución seleccionada. Forman la columna vertebral de la integridad de la red, asegurando que los resultados sean correctos y previniendo soluciones maliciosas o ineficientes. Los Validadores ejecutan un consenso basado en Tendermint, lo que significa que se utiliza un proceso de prueba de participación BFT para llegar a un acuerdo sobre el resultado de cada intención y para actualizar el estado de la red.

Cabe destacar que el enfoque de Enso es agnóstico a la cadena y centrado en la API. Los desarrolladores interactúan con Enso a través de una API/SDK unificada en lugar de lidiar con las particularidades de cada cadena. Enso se integra con más de 250 protocolos DeFi en múltiples blockchains, convirtiendo efectivamente ecosistemas dispares en una plataforma componible. Esta arquitectura elimina la necesidad de que los equipos de dApps escriban contratos inteligentes personalizados o manejen la mensajería entre cadenas para cada nueva integración; el motor compartido de Enso y las Acciones proporcionadas por la comunidad se encargan de ese trabajo pesado. A mediados de 2025, Enso ha demostrado su escalabilidad: la red facilitó con éxito 3.1milmillonesdemigracioˊndeliquidezen3dıˊasparaellanzamientodeBerachain(unodelosmayoreseventosdemigracioˊndeDeFi)yhaprocesadomaˊsde3.1 mil millones de migración de liquidez en 3 días** para el lanzamiento de Berachain (uno de los mayores eventos de migración de DeFi) y ha procesado más de **15 mil millones en transacciones en la cadena hasta la fecha. Estas hazañas demuestran la robustez de la infraestructura de Enso en condiciones del mundo real.

En general, la arquitectura del protocolo de Enso ofrece un "middleware de DeFi" o un sistema operativo en la cadena para Web3. Combina elementos de indexación (como The Graph) y ejecución de transacciones (como puentes entre cadenas o agregadores de DEX) en una única red descentralizada. Esta pila única permite que cualquier aplicación, bot o agente lea y escriba en cualquier contrato inteligente en cualquier cadena a través de una sola integración, acelerando el desarrollo y habilitando nuevos casos de uso componibles. Enso se posiciona como una infraestructura crítica para el futuro multicadena: un motor de intenciones que podría potenciar una miríada de aplicaciones sin que cada una necesite reinventar las integraciones de blockchain.

Tokenomics

El modelo económico de Enso se centra en el token ENSO, que es integral para la operación y gobernanza de la red. ENSO es un token de utilidad y gobernanza con un suministro total fijo de 100 millones de tokens. El diseño del token alinea los incentivos para todos los participantes y crea un efecto flywheel de uso y recompensas:

  • Moneda de Tarifa ("Gas"): Todas las solicitudes enviadas a la red de Enso incurren en una tarifa de consulta pagadera en ENSO. Cuando un usuario (o dApp) activa una intención, se incrusta una pequeña tarifa en el bytecode de la transacción generada. Estas tarifas se subastan por tokens ENSO en el mercado abierto y luego se distribuyen a los participantes de la red que procesan la solicitud. En efecto, ENSO es el gas que impulsa la ejecución de intenciones en la cadena a través de la red de Enso. A medida que crece la demanda de los atajos de Enso, la demanda de tokens ENSO puede aumentar para pagar esas tarifas de red, creando un bucle de retroalimentación de oferta y demanda que respalda el valor del token.

  • Reparto de Ingresos y Recompensas por Staking: El ENSO recaudado de las tarifas se distribuye entre los Proveedores de Acciones, Graphers y Validadores como recompensa por sus contribuciones. Este modelo vincula directamente las ganancias de tokens con el uso de la red: más volumen de intenciones significa más tarifas para distribuir. Los Proveedores de Acciones ganan tokens cuando se utilizan sus abstracciones, los Graphers ganan tokens por soluciones ganadoras y los Validadores ganan tokens por validar y asegurar la red. Los tres roles también deben hacer staking de ENSO como garantía para participar (para ser penalizados por mala praxis), alineando sus incentivos con la salud de la red. Los poseedores de tokens también pueden delegar su ENSO a los Validadores, apoyando la seguridad de la red a través de la prueba de participación delegada. Este mecanismo de staking no solo asegura el consenso de Tendermint, sino que también otorga a los stakers de tokens una parte de las tarifas de la red, de manera similar a cómo los mineros/validadores ganan tarifas de gas en otras cadenas.

  • Gobernanza: Los poseedores de tokens ENSO gobernarán la evolución del protocolo. Enso se está lanzando como una red abierta y planea hacer la transición a una toma de decisiones impulsada por la comunidad. La votación ponderada por tokens permitirá a los poseedores influir en las actualizaciones, cambios de parámetros (como los niveles de tarifas o las asignaciones de recompensas) y el uso de la tesorería. Este poder de gobernanza asegura que los contribuyentes principales y los usuarios estén alineados en la dirección de la red. La filosofía del proyecto es poner la propiedad en manos de la comunidad de constructores y usuarios, lo cual fue una razón impulsora para la venta de tokens comunitaria en 2025 (ver más abajo).

  • Flywheel Positivo: La tokenomics de Enso está diseñada para crear un bucle que se auto-refuerza. A medida que más desarrolladores integran Enso y más usuarios ejecutan intenciones, las tarifas de red (pagadas en ENSO) crecen. Esas tarifas recompensan a los contribuyentes (atrayendo más Acciones, mejores Graphers y más Validadores), lo que a su vez mejora las capacidades de la red (ejecución más rápida, más barata y más confiable) y atrae más uso. Este efecto de red está respaldado por el papel del token ENSO como moneda de tarifa e incentivo para la contribución. La intención es que la economía del token escale de manera sostenible con la adopción de la red, en lugar de depender de emisiones insostenibles.

Distribución y Suministro de Tokens: La asignación inicial de tokens está estructurada para equilibrar los incentivos del equipo/inversores con la propiedad de la comunidad. La siguiente tabla resume la distribución de tokens ENSO en su génesis:

AsignaciónPorcentajeTokens (de 100M)
Equipo (Fundadores y Núcleo)25.0%25,000,000
Inversores Tempranos (VCs)31.3%31,300,000
Fundación y Fondo de Crecimiento23.2%23,200,000
Tesorería del Ecosistema (incentivos comunitarios)15.0%15,000,000
Venta Pública (CoinList 2025)4.0%4,000,000
Asesores1.5%1,500,000

Fuente: Tokenomics de Enso.

La venta pública en junio de 2025 ofreció el 5% (4 millones de tokens) a la comunidad, recaudando 5millonesaunpreciode5 millones a un precio de 1.25 por ENSO (lo que implica una valoración totalmente diluida de ~$125 millones). Notablemente, la venta comunitaria no tuvo bloqueo (100% desbloqueado en el TGE), mientras que el equipo y los inversores de capital de riesgo están sujetos a un calendario de vesting lineal de 2 años. Esto significa que los tokens de los insiders se desbloquean gradualmente bloque por bloque durante 24 meses, alineándolos con el crecimiento a largo plazo de la red y mitigando la presión de venta inmediata. La comunidad obtuvo así liquidez y propiedad inmediatas, reflejando el objetivo de Enso de una amplia distribución.

El calendario de emisiones de Enso más allá de la asignación inicial parece estar impulsado principalmente por las tarifas en lugar de ser inflacionario. El suministro total está fijado en 100 millones de tokens, y no hay indicación de inflación perpetua para las recompensas de bloque en este momento (los validadores son compensados con los ingresos de las tarifas). Esto contrasta con muchos protocolos de Capa 1 que inflan el suministro para pagar a los stakers; Enso aspira a ser sostenible a través de las tarifas de uso reales para recompensar a los participantes. Si la actividad de la red es baja en las fases iniciales, las asignaciones de la fundación y la tesorería pueden utilizarse para impulsar incentivos para el uso y subvenciones de desarrollo. Por el contrario, si la demanda es alta, la utilidad del token ENSO (para tarifas y staking) podría crear una presión de demanda orgánica.

En resumen, ENSO es el combustible de la Red Enso. Impulsa las transacciones (tarifas de consulta), asegura la red (staking y slashing) y gobierna la plataforma (votación). El valor del token está directamente ligado a la adopción de la red: a medida que Enso se utilice más ampliamente como la columna vertebral de las aplicaciones DeFi, el volumen de tarifas y staking de ENSO debería reflejar ese crecimiento. La cuidadosa distribución (con solo una pequeña porción circulando inmediatamente después del TGE) y el fuerte respaldo de los principales inversores (a continuación) proporcionan confianza en el soporte del token, mientras que la venta centrada en la comunidad señala un compromiso con la descentralización de la propiedad.

Equipo e Inversores

Enso Network fue fundada en 2021 por Connor Howe (CEO) y Gorazd Ocvirk, quienes trabajaron juntos previamente en Sygnum Bank en el sector de la criptobanca de Suiza. Connor Howe lidera el proyecto como CEO y es la cara pública en comunicaciones y entrevistas. Bajo su liderazgo, Enso se lanzó inicialmente como una plataforma de trading social DeFi y luego pivotó a través de múltiples iteraciones para llegar a la visión actual de infraestructura basada en intenciones. Esta adaptabilidad destaca la resiliencia empresarial del equipo: desde ejecutar un "ataque vampiro" de alto perfil a protocolos de índices en 2021 hasta construir una super-app agregadora de DeFi, y finalmente generalizar sus herramientas en la plataforma para desarrolladores de Enso. El cofundador Gorazd Ocvirk (PhD) aportó una profunda experiencia en finanzas cuantitativas y estrategia de productos Web3, aunque fuentes públicas sugieren que podría haber pasado a otras empresas (fue señalado como cofundador de otra startup de cripto en 2022). El equipo central de Enso hoy incluye ingenieros y operadores con sólidos antecedentes en DeFi. Por ejemplo, Peter Phillips y Ben Wolf están listados como ingenieros de "blockend" (backend de blockchain), y Valentin Meylan lidera la investigación. El equipo está distribuido globalmente pero tiene sus raíces en Zug/Zúrich, Suiza, un conocido centro para proyectos de cripto (Enso Finance AG se registró en 2020 en Suiza).

Más allá de los fundadores, Enso cuenta con asesores y patrocinadores notables que le otorgan una credibilidad significativa. El proyecto está respaldado por fondos de capital de riesgo de cripto de primer nivel y ángeles: cuenta con Polychain Capital y Multicoin Capital como inversores principales, junto con Dialectic y Spartan Group (ambos fondos de cripto prominentes), e IDEO CoLab. Una impresionante lista de inversores ángeles también participó en las rondas: más de 70 individuos de proyectos Web3 líderes han invertido en Enso. Estos incluyen fundadores o ejecutivos de LayerZero, Safe (Gnosis Safe), 1inch, Yearn Finance, Flashbots, Dune Analytics, Pendle, y otros. Incluso el luminario tecnológico Naval Ravikant (cofundador de AngelList) es un inversor y partidario. Tales nombres señalan una fuerte confianza de la industria en la visión de Enso.

Historial de financiación de Enso: el proyecto recaudó una ronda semilla de 5Maprincipiosde2021paraconstruirlaplataformadetradingsocial,ymaˊstardeunarondade5M a principios de 2021 para construir la plataforma de trading social, y más tarde una ronda de 4.2M (estratégica/VC) a medida que evolucionaba el producto (estas primeras rondas probablemente incluyeron a Polychain, Multicoin, Dialectic, etc.). A mediados de 2023, Enso había asegurado suficiente capital para construir su red; notablemente, operó relativamente bajo el radar hasta que su pivote de infraestructura ganó tracción. En el segundo trimestre de 2025, Enso lanzó una venta de tokens comunitaria de $5M en CoinList, que fue sobresuscrita por decenas de miles de participantes. El propósito de esta venta no era solo recaudar fondos (la cantidad era modesta dado el respaldo previo de VC) sino descentralizar la propiedad y dar a su creciente comunidad una participación en el éxito de la red. Según el CEO Connor Howe, "queremos que nuestros primeros partidarios, usuarios y creyentes tengan una propiedad real en Enso... convirtiendo a los usuarios en defensores". Este enfoque centrado en la comunidad es parte de la estrategia de Enso para impulsar el crecimiento de base y los efectos de red a través de incentivos alineados.

Hoy en día, el equipo de Enso es considerado uno de los líderes de opinión en el espacio de "DeFi basado en intenciones". Participan activamente en la educación de desarrolladores (por ejemplo, el Speedrun de Atajos de Enso atrajo a 700k participantes como un evento de aprendizaje gamificado) y colaboran con otros protocolos en integraciones. La combinación de un equipo central fuerte con una capacidad probada para pivotar, inversores de primer nivel y una comunidad entusiasta sugiere que Enso tiene tanto el talento como el respaldo financiero para ejecutar su ambiciosa hoja de ruta.

Métricas de Adopción y Casos de Uso

A pesar de ser una infraestructura relativamente nueva, Enso ha demostrado una tracción significativa en su nicho. Se ha posicionado como la solución de referencia para proyectos que necesitan integraciones complejas en la cadena o capacidades entre cadenas. Algunas métricas de adopción e hitos clave a mediados de 2025:

  • Integración del Ecosistema: Más de 100 aplicaciones en vivo (dApps, billeteras y servicios) están utilizando Enso bajo el capó para potenciar funciones en la cadena. Estas van desde paneles de DeFi hasta optimizadores de rendimiento automatizados. Debido a que Enso abstrae los protocolos, los desarrolladores pueden agregar rápidamente nuevas funciones de DeFi a su producto conectándose a la API de Enso. La red se ha integrado con más de 250 protocolos DeFi (DEXes, plataformas de préstamos, granjas de rendimiento, mercados de NFT, etc.) en las principales cadenas, lo que significa que Enso puede ejecutar prácticamente cualquier acción en la cadena que un usuario pueda desear, desde una operación en Uniswap hasta un depósito en una bóveda de Yearn. Esta amplitud de integraciones reduce significativamente el tiempo de desarrollo para los clientes de Enso: un nuevo proyecto puede soportar, por ejemplo, todos los DEXes en Ethereum, Capas 2 e incluso Solana usando Enso, en lugar de codificar cada integración de forma independiente.

  • Adopción de Desarrolladores: La comunidad de Enso ahora incluye a más de 1,900 desarrolladores que construyen activamente con su conjunto de herramientas. Estos desarrolladores pueden estar creando directamente Atajos/Acciones o incorporando Enso en sus aplicaciones. La cifra destaca que Enso no es solo un sistema cerrado; está habilitando un creciente ecosistema de constructores que utilizan sus atajos o contribuyen a su biblioteca. El enfoque de Enso de simplificar el desarrollo en la cadena (afirmando reducir los tiempos de construcción de más de 6 meses a menos de una semana) ha resonado entre los desarrolladores de Web3. Esto también se evidencia en hackatones y en la biblioteca de Plantillas de Enso, donde los miembros de la comunidad comparten ejemplos de atajos listos para usar.

  • Volumen de Transacciones: Más de 15milmillonesenvolumenacumuladodetransaccionesenlacadenasehanliquidadoatraveˊsdelainfraestructuradeEnso.Estameˊtrica,seguˊnseinformoˊenjuniode2025,subrayaqueEnsonosoloseejecutaenentornosdeprueba,sinoqueprocesavalorrealaescala.UnejemplodealtoperfilfuelamigracioˊndeliquidezdeBerachain:enabrilde2025,Ensoimpulsoˊelmovimientodeliquidezparalacampan~adetestnetdeBerachain("Boyco")yfacilitoˊ15 mil millones** en volumen acumulado de transacciones en la cadena se han liquidado a través de la infraestructura de Enso. Esta métrica, según se informó en junio de 2025, subraya que Enso no solo se ejecuta en entornos de prueba, sino que procesa valor real a escala. Un ejemplo de alto perfil fue la **migración de liquidez de Berachain**: en abril de 2025, Enso impulsó el movimiento de liquidez para la campaña de testnet de Berachain ("Boyco") y facilitó **3.1 mil millones en transacciones ejecutadas durante 3 días, uno de los mayores eventos de liquidez en la historia de DeFi. El motor de Enso manejó con éxito esta carga, demostrando fiabilidad y rendimiento bajo estrés. Otro ejemplo es la asociación de Enso con Uniswap: Enso construyó una herramienta de Migración de Posiciones de Uniswap (en colaboración con Uniswap Labs, LayerZero y Stargate) que ayudó a los usuarios a migrar sin problemas las posiciones de LP de Uniswap v3 de Ethereum a otra cadena. Esta herramienta simplificó un proceso entre cadenas típicamente complejo (con puentes y redespliegue de NFTs) en un atajo de un solo clic, y su lanzamiento mostró la capacidad de Enso para trabajar junto a los principales protocolos de DeFi.

  • Casos de Uso del Mundo Real: La propuesta de valor de Enso se entiende mejor a través de los diversos casos de uso que habilita. Los proyectos han utilizado Enso para ofrecer características que serían muy difíciles de construir por sí solos:

    • Agregación de Rendimiento entre Cadenas: Plume y Sonic utilizaron Enso para impulsar campañas de lanzamiento incentivadas donde los usuarios podían depositar activos en una cadena y desplegarlos en rendimientos en otra. Enso manejó la mensajería entre cadenas y las transacciones de múltiples pasos, permitiendo que estos nuevos protocolos ofrecieran experiencias fluidas entre cadenas a los usuarios durante sus eventos de lanzamiento de tokens.
    • Migración y Fusión de Liquidez: Como se mencionó, Berachain aprovechó Enso para una migración de liquidez similar a un "ataque vampiro" desde otros ecosistemas. De manera similar, otros protocolos podrían usar los Atajos de Enso para automatizar el movimiento de los fondos de los usuarios desde una plataforma competidora a la suya, agrupando aprobaciones, retiros, transferencias y depósitos entre plataformas en una sola intención. Esto demuestra el potencial de Enso en las estrategias de crecimiento de protocolos.
    • Funcionalidad de "Super App" DeFi: Algunas billeteras e interfaces (por ejemplo, el asistente de cripto Eliza OS y la plataforma de trading Infinex) integran Enso para ofrecer acciones DeFi todo en uno. Un usuario puede, con un solo clic, intercambiar activos a la mejor tasa (Enso enrutará a través de DEXes), luego prestar el resultado para ganar rendimiento, y quizás hacer staking de un token LP, todo lo cual Enso puede ejecutar como un solo Atajo. Esto mejora significativamente la experiencia del usuario y la funcionalidad de esas aplicaciones.
    • Automatización y Bots: La presencia de "agentes" e incluso bots impulsados por IA que utilizan Enso está emergiendo. Debido a que Enso expone una API, los traders algorítmicos o los agentes de IA pueden introducir un objetivo de alto nivel (por ejemplo, "maximizar el rendimiento del activo X en cualquier cadena") y dejar que Enso encuentre la estrategia óptima. Esto ha abierto la experimentación en estrategias de DeFi automatizadas sin necesidad de ingeniería de bots personalizada para cada protocolo.
  • Crecimiento de Usuarios: Aunque Enso es principalmente una infraestructura B2B/B2Dev, ha cultivado una comunidad de usuarios finales y entusiastas a través de campañas. El Shortcut Speedrun, una serie de tutoriales gamificados, tuvo más de 700,000 participantes, lo que indica un interés generalizado en las capacidades de Enso. El seguimiento social de Enso ha crecido casi 10 veces en unos pocos meses (248k seguidores en X a mediados de 2025), lo que refleja un fuerte reconocimiento entre los usuarios de cripto. Este crecimiento de la comunidad es importante porque crea una demanda de base: los usuarios conscientes de Enso animarán a sus dApps favoritas a integrarlo o utilizarán productos que aprovechen los atajos de Enso.

En resumen, Enso ha pasado de la teoría a la adopción real. Es confiable para más de 100 proyectos, incluyendo nombres conocidos como Uniswap, SushiSwap, Stargate/LayerZero, Berachain, zkSync, Safe, Pendle, Yearn y más, ya sea como socios de integración o usuarios directos de la tecnología de Enso. Este amplio uso en diferentes verticales (DEXs, puentes, capas 1, dApps) destaca el papel de Enso como infraestructura de propósito general. Su métrica clave de tracción, más de $15 mil millones en transacciones, es especialmente impresionante para un proyecto de infraestructura en esta etapa y valida el ajuste del mercado para un middleware basado en intenciones. Los inversores pueden estar tranquilos de que los efectos de red de Enso parecen estar activándose: más integraciones generan más uso, lo que a su vez genera más integraciones. El desafío por delante será convertir este impulso inicial en un crecimiento sostenido, lo que se relaciona con el posicionamiento de Enso frente a los competidores y su hoja de ruta.

Panorama Competitivo

Enso Network opera en la intersección de la agregación DeFi, la interoperabilidad entre cadenas y la infraestructura para desarrolladores, lo que hace que su panorama competitivo sea multifacético. Aunque ningún competidor único ofrece un producto idéntico, Enso se enfrenta a la competencia de varias categorías de protocolos Web3:

  • Middleware Descentralizado e Indexación: La analogía más directa es The Graph (GRT). The Graph proporciona una red descentralizada para consultar datos de blockchain a través de subgrafos. Enso de manera similar obtiene proveedores de datos de la comunidad (Proveedores de Acciones) pero va un paso más allá al permitir la ejecución de transacciones además de la obtención de datos. Mientras que la capitalización de mercado de ~$924M de The Graph se basa solo en la indexación, el alcance más amplio de Enso (datos + acción) lo posiciona como una herramienta más poderosa para captar la atención de los desarrolladores. Sin embargo, The Graph es una red bien establecida; Enso tendrá que demostrar la fiabilidad y seguridad de su capa de ejecución para lograr una adopción similar. Se podría imaginar que The Graph u otros protocolos de indexación se expandan hacia la ejecución, lo que competiría directamente con el nicho de Enso.

  • Protocolos de Interoperabilidad entre Cadenas: Proyectos como LayerZero, Axelar, Wormhole y Chainlink CCIP proporcionan infraestructura para conectar diferentes blockchains. Se centran en el paso de mensajes y el puenteo de activos entre cadenas. Enso en realidad utiliza algunos de estos bajo el capó (por ejemplo, LayerZero/Stargate para el puenteo en el migrador de Uniswap) y es más una abstracción de nivel superior. En términos de competencia, si estos protocolos de interoperabilidad comienzan a ofrecer APIs de "intención" de nivel superior o SDKs amigables para desarrolladores para componer acciones multicadena, podrían superponerse con Enso. Por ejemplo, Axelar ofrece un SDK para llamadas entre cadenas, y el CCIP de Chainlink podría permitir la ejecución de funciones entre cadenas. El diferenciador de Enso es que no solo envía mensajes entre cadenas; mantiene un motor unificado y una biblioteca de acciones DeFi. Se dirige a los desarrolladores de aplicaciones que desean una solución lista para usar, en lugar de obligarlos a construir sobre primitivas crudas entre cadenas. No obstante, Enso competirá por la cuota de mercado en el segmento más amplio de middleware de blockchain, donde estos proyectos de interoperabilidad están bien financiados e innovando rápidamente.

  • Agregadores de Transacciones y Automatización: En el mundo DeFi, existen agregadores como 1inch, 0x API o CoW Protocol que se centran en encontrar las rutas de intercambio óptimas a través de los exchanges. El mecanismo de Grapher de Enso para las intenciones es conceptualmente similar a la competencia de solucionadores de CoW Protocol, pero Enso lo generaliza más allá de los swaps a cualquier acción. La intención de un usuario de "maximizar el rendimiento" podría implicar intercambiar, prestar, hacer staking, etc., lo cual está fuera del alcance de un agregador de DEX puro. Dicho esto, Enso será comparado con estos servicios en eficiencia para casos de uso superpuestos (por ejemplo, Enso vs. 1inch para una ruta de intercambio de tokens compleja). Si Enso encuentra consistentemente mejores rutas o tarifas más bajas gracias a su red de Graphers, puede superar a los agregadores tradicionales. Gelato Network es otro competidor en automatización: Gelato proporciona una red descentralizada de bots para ejecutar tareas como órdenes límite, auto-compounding o transferencias entre cadenas en nombre de las dApps. Gelato tiene un token GEL y una base de clientes establecida para casos de uso específicos. La ventaja de Enso es su amplitud e interfaz unificada: en lugar de ofrecer productos separados para cada caso de uso (como lo hace Gelato), Enso ofrece una plataforma general donde cualquier lógica puede codificarse como un Atajo. Sin embargo, la ventaja inicial y el enfoque de Gelato en áreas como la automatización podrían atraer a desarrolladores que de otro modo usarían Enso para funcionalidades similares.

  • Plataformas para Desarrolladores (SDKs Web3): También existen plataformas para desarrolladores al estilo Web2 como Moralis, Alchemy, Infura y Tenderly que simplifican la construcción en blockchains. Estas suelen ofrecer acceso a API para leer datos, enviar transacciones y, a veces, puntos finales de nivel superior (por ejemplo, "obtener saldos de tokens" o "enviar tokens a través de la cadena"). Aunque estos son en su mayoría servicios centralizados, compiten por la misma atención de los desarrolladores. El punto de venta de Enso es que es descentralizado y componible: los desarrolladores no solo obtienen datos o una única función, sino que acceden a toda una red de capacidades en la cadena contribuidas por otros. Si tiene éxito, Enso podría convertirse en "el GitHub de las acciones en la cadena", donde los desarrolladores comparten y reutilizan Atajos, de manera muy similar al código de fuente abierta. Competir con empresas de infraestructura como servicio bien financiadas significa que Enso necesitará ofrecer una fiabilidad y facilidad de uso comparables, lo cual está tratando de lograr con una API y documentación extensas.

  • Soluciones Propias: Finalmente, Enso compite con el status quo: equipos que construyen integraciones personalizadas internamente. Tradicionalmente, cualquier proyecto que quisiera funcionalidad multiprotocolo tenía que escribir y mantener contratos inteligentes o scripts para cada integración (por ejemplo, integrar Uniswap, Aave, Compound por separado). Muchos equipos aún podrían elegir esta ruta para tener el máximo control o por consideraciones de seguridad. Enso necesita convencer a los desarrolladores de que externalizar este trabajo a una red compartida es seguro, rentable y está actualizado. Dada la velocidad de la innovación en DeFi, mantener las propias integraciones es una carga (Enso a menudo cita que los equipos gastan más de 6 meses y $500k en auditorías para integrar docenas de protocolos). Si Enso puede demostrar su rigor en seguridad y mantener su biblioteca de acciones actualizada con los últimos protocolos, puede convertir a más equipos para que dejen de construir en silos. Sin embargo, cualquier incidente de seguridad de alto perfil o tiempo de inactividad en Enso podría hacer que los desarrolladores vuelvan a preferir soluciones internas, lo cual es un riesgo competitivo en sí mismo.

Diferenciadores de Enso: La principal ventaja de Enso es ser el primero en el mercado con una red de ejecución centrada en intenciones e impulsada por la comunidad. Combina características que requerirían el uso de múltiples otros servicios: indexación de datos, SDKs de contratos inteligentes, enrutamiento de transacciones y puentes entre cadenas, todo en uno. Su modelo de incentivos (recompensar a desarrolladores de terceros por sus contribuciones) también es único; podría llevar a un ecosistema vibrante donde muchos protocolos de nicho se integren en Enso más rápido de lo que cualquier equipo podría hacerlo, de manera similar a cómo la comunidad de The Graph indexa una larga cola de contratos. Si Enso tiene éxito, podría disfrutar de un fuerte foso de efecto de red: más Acciones y Atajos lo hacen más atractivo para usar Enso en comparación con los competidores, lo que atrae a más usuarios y, por lo tanto, más Acciones contribuidas, y así sucesivamente.

Dicho esto, Enso todavía está en sus primeras etapas. Su análogo más cercano, The Graph, tardó años en descentralizarse y construir un ecosistema de indexadores. Enso necesitará de manera similar nutrir a su comunidad de Graphers y Validadores para garantizar la fiabilidad. Grandes jugadores (como una versión futura de The Graph, o una colaboración de Chainlink y otros) podrían decidir lanzar una capa de ejecución de intenciones competidora, aprovechando sus redes existentes. Enso tendrá que moverse rápidamente para consolidar su posición antes de que tal competencia se materialice.

En conclusión, Enso se encuentra en una encrucijada competitiva de varias verticales importantes de Web3: está creando un nicho como el "middleware de todo". Su éxito dependerá de superar a los competidores especializados en cada caso de uso (o agregarlos) y de continuar ofreciendo una solución integral convincente que justifique que los desarrolladores elijan Enso en lugar de construir desde cero. La presencia de socios e inversores de alto perfil sugiere que Enso tiene un pie en la puerta de muchos ecosistemas, lo que será ventajoso a medida que expanda su cobertura de integración.

Hoja de Ruta y Crecimiento del Ecosistema

La hoja de ruta de desarrollo de Enso (a mediados de 2025) describe un camino claro hacia la descentralización total, el soporte multicadena y el crecimiento impulsado por la comunidad. Los hitos clave e iniciativas planificadas incluyen:

  • Lanzamiento de la Mainnet (T3 2024) – Enso lanzó su red principal en la segunda mitad de 2024. Esto implicó el despliegue de la cadena basada en Tendermint y la inicialización del ecosistema de Validadores. Los primeros validadores probablemente fueron permissionados o socios seleccionados mientras la red se iniciaba. El lanzamiento de la mainnet permitió que las consultas de usuarios reales fueran procesadas por el motor de Enso (antes de esto, los servicios de Enso eran accesibles a través de una API centralizada mientras estaban en beta). Este hito marcó la transición de Enso de una plataforma interna a una red pública descentralizada.

  • Expansión de Participantes de la Red (T4 2024) – Después de la mainnet, el enfoque se desplazó a la descentralización de la participación. A finales de 2024, Enso abrió roles para Proveedores de Acciones y Graphers externos. Esto incluyó el lanzamiento de herramientas y documentación para que los desarrolladores crearan sus propias Acciones (adaptadores de contratos inteligentes) y para que los desarrolladores de algoritmos ejecutaran nodos de Grapher. Podemos inferir que se utilizaron programas de incentivos o competiciones en testnet para atraer a estos participantes. Para finales de 2024, Enso aspiraba a tener un conjunto más amplio de acciones de terceros en su biblioteca y múltiples Graphers compitiendo en intenciones, yendo más allá de los algoritmos internos del equipo central. Este fue un paso crucial para asegurar que Enso no sea un servicio centralizado, sino una verdadera red abierta donde cualquiera puede contribuir y ganar tokens ENSO.

  • Expansión entre Cadenas (T1 2025) – Enso reconoce que soportar muchas blockchains es clave para su propuesta de valor. A principios de 2025, la hoja de ruta apuntaba a la integración con nuevos entornos de blockchain más allá del conjunto inicial de EVM. Específicamente, Enso planeaba dar soporte a Monad, Solana y Movement para el primer trimestre de 2025. Monad es una próxima cadena de alto rendimiento compatible con EVM (respaldada por Dragonfly Capital); apoyarla tempranamente podría posicionar a Enso como el middleware de referencia allí. La integración con Solana es más desafiante (diferente tiempo de ejecución y lenguaje), pero el motor de intenciones de Enso podría funcionar con Solana utilizando graphers fuera de la cadena para formular transacciones de Solana y programas en la cadena que actúen como adaptadores. Movement se refiere a cadenas de lenguaje Move (quizás Aptos/Sui o una específica llamada Movement). Al incorporar cadenas basadas en Move, Enso cubriría un amplio espectro de ecosistemas (Solidity y Move, así como los rollups existentes de Ethereum). Lograr estas integraciones significa desarrollar nuevos módulos de Acción que entiendan las llamadas CPI de Solana o los scripts de transacción de Move, y probablemente colaborar con esos ecosistemas para oráculos/indexación. La mención de Enso en actualizaciones sugiere que estos estaban en camino; por ejemplo, una actualización de la comunidad destacó asociaciones o subvenciones (la mención de "Eclipse mainnet live + Movement grant" en un resultado de búsqueda sugiere que Enso estaba trabajando activamente con L1s novedosas como Eclipse y Movement a principios de 2025).

  • A Corto Plazo (Mediados/Finales de 2025) – Aunque no se detalla explícitamente en la hoja de ruta de una página, para mediados de 2025 el enfoque de Enso está en la madurez y descentralización de la red. La finalización de la venta de tokens en CoinList en junio de 2025 es un evento importante: los siguientes pasos serían la generación y distribución de tokens (esperada alrededor de julio de 2025) y el lanzamiento en exchanges o foros de gobernanza. Anticipamos que Enso implementará su proceso de gobernanza (Propuestas de Mejora de Enso, votación en la cadena) para que la comunidad pueda comenzar a participar en las decisiones utilizando sus tokens recién adquiridos. Además, Enso probablemente pasará de "beta" a un servicio totalmente listo para producción, si no lo ha hecho ya. Parte de esto será el endurecimiento de la seguridad: realizar múltiples auditorías de contratos inteligentes y quizás ejecutar un programa de recompensas por errores, considerando los grandes TVL involucrados.

  • Estrategias de Crecimiento del Ecosistema: Enso está fomentando activamente un ecosistema alrededor de su red. Una estrategia ha sido ejecutar programas educativos y hackatones (por ejemplo, el Shortcut Speedrun y talleres) para incorporar a los desarrolladores a la forma de construir de Enso. Otra estrategia es asociarse con nuevos protocolos en su lanzamiento; lo hemos visto con Berachain, la campaña de zkSync y otros. Es probable que Enso continúe con esto, actuando efectivamente como un "socio de lanzamiento en la cadena" para redes emergentes o proyectos DeFi, manejando sus complejos flujos de onboarding de usuarios. Esto no solo impulsa el volumen de Enso (como se vio con Berachain) sino que también integra a Enso profundamente en esos ecosistemas. Esperamos que Enso anuncie integraciones con más redes de Capa 2 (por ejemplo, Arbitrum, Optimism presumiblemente ya eran compatibles; quizás las más nuevas como Scroll o Starknet a continuación) y otras L1 (Polkadot a través de XCM, Cosmos a través de IBC u Osmosis, etc.). La visión a largo plazo es que Enso se vuelva ubicuo en todas las cadenas: cualquier desarrollador en cualquier cadena puede conectarse. Con ese fin, Enso también puede desarrollar una mejor ejecución entre cadenas sin puentes (utilizando técnicas como swaps atómicos o ejecución optimista de intenciones entre cadenas), lo que podría estar en la hoja de ruta de I+D más allá de 2025.

  • Perspectivas Futuras: Mirando más allá, el equipo de Enso ha insinuado la participación de agentes de IA como participantes de la red. Esto sugiere un futuro donde no solo los desarrolladores humanos, sino también los bots de IA (quizás entrenados para optimizar estrategias de DeFi) se conecten a Enso para proporcionar servicios. Enso podría desarrollar esta visión creando SDKs o marcos para que los agentes de IA interactúen de manera segura con el motor de intenciones, un desarrollo potencialmente innovador que fusiona la IA y la automatización de blockchain. Además, para finales de 2025 o 2026, anticipamos que Enso trabajará en la escalabilidad del rendimiento (quizás fragmentando su red o utilizando pruebas de conocimiento cero para validar la corrección de la ejecución de intenciones a escala) a medida que crezca el uso.

La hoja de ruta es ambiciosa, pero la ejecución hasta ahora ha sido sólida: Enso ha cumplido hitos clave como el lanzamiento de la mainnet y la entrega de casos de uso reales. Un hito importante próximo es la descentralización total de la red. Actualmente, la red está en transición: la documentación señala que la red descentralizada está en testnet y que se estaba utilizando una API centralizada para producción a principios de 2025. A estas alturas, con la mainnet en vivo y el token en circulación, Enso buscará eliminar gradualmente cualquier componente centralizado. Para los inversores, seguir este progreso de descentralización (por ejemplo, el número de validadores independientes, la incorporación de Graphers comunitarios) será clave para evaluar la madurez de Enso.

En resumen, la hoja de ruta de Enso se centra en escalar el alcance de la red (más cadenas, más integraciones) y escalar la comunidad de la red (más participantes de terceros y poseedores de tokens). El objetivo final es consolidar a Enso como infraestructura crítica en Web3, de manera muy similar a cómo Infura se volvió esencial para la conectividad de dApps o cómo The Graph se volvió integral para la consulta de datos. Si Enso puede alcanzar sus hitos, la segunda mitad de 2025 debería ver un ecosistema floreciente alrededor de la Red Enso, impulsando potencialmente un crecimiento exponencial en el uso.

Evaluación de Riesgos

Como cualquier protocolo en etapa inicial, Enso Network enfrenta una serie de riesgos y desafíos que los inversores deben considerar cuidadosamente:

  • Riesgos Técnicos y de Seguridad: El sistema de Enso es inherentemente complejo: interactúa con una miríada de contratos inteligentes en muchas blockchains a través de una red de solucionadores y validadores fuera de la cadena. Esta amplia superficie de ataque introduce un riesgo técnico. Cada nueva Acción (integración) podría tener vulnerabilidades; si la lógica de una Acción es defectuosa o un proveedor malicioso introduce una Acción con una puerta trasera, los fondos de los usuarios podrían estar en riesgo. Asegurar que cada integración sea segura requiere una inversión sustancial (el equipo de Enso gastó más de $500k en auditorías para integrar 15 protocolos en sus primeros días). A medida que la biblioteca crece a cientos de protocolos, mantener auditorías de seguridad rigurosas es un desafío. También existe el riesgo de errores en la lógica de coordinación de Enso; por ejemplo, un fallo en cómo los Graphers componen las transacciones o cómo los Validadores las verifican podría ser explotado. La ejecución entre cadenas, en particular, puede ser arriesgada: si una secuencia de acciones abarca múltiples cadenas y una parte falla o es censurada, podría dejar los fondos de un usuario en el limbo. Aunque Enso probablemente utiliza reintentos o swaps atómicos en algunos casos, la complejidad de las intenciones significa que podrían surgir modos de fallo desconocidos. El modelo basado en intenciones en sí mismo es relativamente poco probado a escala; puede haber casos límite en los que el motor produzca una solución incorrecta o un resultado que diverja de la intención del usuario. Cualquier explotación o fallo de alto perfil podría socavar la confianza en toda la red. La mitigación requiere auditorías de seguridad continuas, un programa robusto de recompensas por errores y quizás mecanismos de seguro para los usuarios (ninguno de los cuales se ha detallado todavía).

  • Riesgos de Descentralización y Operacionales: En la actualidad (mediados de 2025), la red de Enso todavía está en proceso de descentralizar a sus participantes. Esto significa que puede haber una centralización operacional no visible; por ejemplo, la infraestructura del equipo podría estar coordinando todavía gran parte de la actividad, o solo unos pocos validadores/graphers están genuinamente activos. Esto presenta dos riesgos: fiabilidad (si los servidores del equipo central caen, ¿se detendrá la red?) y confianza (si el proceso no es completamente sin confianza todavía, los usuarios deben tener fe en que Enso Inc. no hará front-running ni censurará transacciones). El equipo ha demostrado fiabilidad en grandes eventos (como manejar un volumen de $3B en días), pero a medida que el uso crece, escalar la red a través de más nodos independientes será crucial. También existe el riesgo de que los participantes de la red no aparezcan: si Enso no puede atraer suficientes Proveedores de Acciones o Graphers cualificados, la red podría seguir dependiendo del equipo central, limitando la descentralización. Esto podría ralentizar la innovación y también concentrar demasiado poder (y recompensas de tokens) en un grupo pequeño, lo contrario del diseño previsto.

  • Riesgos de Mercado y Adopción: Aunque Enso tiene una adopción temprana impresionante, todavía se encuentra en un mercado naciente para la infraestructura "basada en intenciones". Existe el riesgo de que la comunidad de desarrolladores en general sea lenta en adoptar este nuevo paradigma. Los desarrolladores arraigados en prácticas de codificación tradicionales pueden dudar en depender de una red externa para la funcionalidad principal, o pueden preferir soluciones alternativas. Además, el éxito de Enso depende del crecimiento continuo de los ecosistemas DeFi y multicadena. Si la tesis multicadena flaquea (por ejemplo, si la mayor parte de la actividad se consolida en una única cadena dominante), la necesidad de las capacidades entre cadenas de Enso podría disminuir. Por otro lado, si surge un nuevo ecosistema que Enso no logra integrar rápidamente, los proyectos en ese ecosistema no usarán Enso. Esencialmente, mantenerse actualizado con cada nueva cadena y protocolo es un desafío interminable: perder o retrasarse en una integración importante (digamos un nuevo DEX popular o una Capa 2) podría empujar a los proyectos hacia competidores o código personalizado. Además, el uso de Enso podría verse afectado por las condiciones macroeconómicas del mercado; en una grave recesión de DeFi, menos usuarios y desarrolladores podrían estar experimentando con nuevas dApps, reduciendo directamente las intenciones enviadas a Enso y, por lo tanto, las tarifas/ingresos de la red. El valor del token podría sufrir en tal escenario, haciendo potencialmente menos atractivo el staking y debilitando la seguridad o participación de la red.

  • Competencia: Como se discutió, Enso enfrenta competencia en múltiples frentes. Un riesgo importante es que un jugador más grande entre en el espacio de ejecución de intenciones. Por ejemplo, si un proyecto bien financiado como Chainlink introdujera un servicio de intenciones similar aprovechando su red de oráculos existente, podrían eclipsar rápidamente a Enso debido a la confianza de la marca y las integraciones. De manera similar, las empresas de infraestructura (Alchemy, Infura) podrían construir SDKs multicadena simplificados que, aunque no descentralizados, capturen el mercado de desarrolladores con conveniencia. También existe el riesgo de imitadores de código abierto: los conceptos centrales de Enso (Acciones, Graphers) podrían ser replicados por otros, quizás incluso como una bifurcación de Enso si el código es público. Si uno de esos proyectos forma una comunidad fuerte o encuentra un mejor incentivo de token, podría desviar a participantes potenciales. Enso necesitará mantener el liderazgo tecnológico (por ejemplo, teniendo la biblioteca más grande de Acciones y los solucionadores más eficientes) para defenderse de la competencia. La presión competitiva también podría afectar el modelo de tarifas de Enso: si un rival ofrece servicios similares más baratos (o gratis, subsidiados por VCs), Enso podría verse obligado a bajar las tarifas o aumentar los incentivos de tokens, lo que podría afectar su tokenomics.

  • Riesgos Regulatorios y de Cumplimiento: Enso opera en el espacio de la infraestructura DeFi, que es un área gris en términos de regulación. Aunque Enso en sí no custodia los fondos de los usuarios (los usuarios ejecutan intenciones desde sus propias billeteras), la red automatiza transacciones financieras complejas a través de protocolos. Existe la posibilidad de que los reguladores puedan ver los motores de composición de intenciones como facilitadores de actividad financiera sin licencia o incluso como ayuda al lavado de dinero si se utilizan para mover fondos entre cadenas de manera oculta. Podrían surgir preocupaciones específicas si Enso permite intercambios entre cadenas que tocan pools de privacidad o jurisdicciones bajo sanciones. Además, el token ENSO y su venta en CoinList reflejan una distribución a una comunidad global; los reguladores (como la SEC en los EE. UU.) podrían examinarlo como una oferta de valores (notablemente, Enso excluyó a EE. UU., Reino Unido, China, etc., de la venta, lo que indica cautela en este frente). Si ENSO fuera considerado un valor en jurisdicciones importantes, podría limitar las cotizaciones en exchanges o el uso por parte de entidades reguladas. La red descentralizada de validadores de Enso también podría enfrentar problemas de cumplimiento: por ejemplo, ¿podría un validador ser obligado a censurar ciertas transacciones debido a órdenes legales? Esto es en gran medida hipotético por ahora, pero a medida que crezca el valor que fluye a través de Enso, la atención regulatoria aumentará. La base del equipo en Suiza podría ofrecer un entorno regulatorio relativamente amigable con las criptomonedas, pero las operaciones globales significan riesgos globales. Mitigar esto probablemente implica asegurar que Enso esté suficientemente descentralizado (para que ninguna entidad sea responsable) y posiblemente geocercar ciertas características si es necesario (aunque eso iría en contra del espíritu del proyecto).

  • Sostenibilidad Económica: El modelo de Enso asume que las tarifas generadas por el uso recompensarán suficientemente a todos los participantes. Existe el riesgo de que los incentivos de las tarifas no sean suficientes para sostener la red, especialmente al principio. Por ejemplo, los Graphers y Validadores incurren en costos (infraestructura, tiempo de desarrollo). Si las tarifas de consulta se establecen demasiado bajas, estos participantes podrían no obtener ganancias, lo que los llevaría a abandonar. Por otro lado, si las tarifas son demasiado altas, las dApps pueden dudar en usar Enso y buscar alternativas más baratas. Lograr un equilibrio es difícil en un mercado de dos lados. La economía del token de Enso también depende en cierta medida del valor del token; por ejemplo, las recompensas por staking son más atractivas cuando el token tiene un alto valor, y los Proveedores de Acciones ganan valor en ENSO. Una fuerte caída en el precio de ENSO podría reducir la participación en la red o provocar más ventas (lo que deprime aún más el precio). Con una gran parte de los tokens en manos de inversores y el equipo (más del 56% combinado, con un vesting de 2 años), existe un riesgo de exceso de oferta: si estos interesados pierden la fe o necesitan liquidez, su venta podría inundar el mercado después del vesting y socavar el precio del token. Enso intentó mitigar la concentración con la venta comunitaria, pero sigue siendo una distribución de tokens relativamente centralizada a corto plazo. La sostenibilidad económica dependerá del crecimiento del uso genuino de la red a un nivel en el que los ingresos por tarifas proporcionen un rendimiento suficiente a los stakers y contribuyentes del token, convirtiendo esencialmente a Enso en un protocolo generador de flujo de caja en lugar de solo un token especulativo. Esto es alcanzable (piense en cómo las tarifas de Ethereum recompensan a los mineros/validadores), pero solo si Enso logra una adopción generalizada. Hasta entonces, existe una dependencia de los fondos de la tesorería (15% asignado) para incentivar y quizás para ajustar los parámetros económicos (la gobernanza de Enso puede introducir inflación u otras recompensas si es necesario, lo que podría diluir a los poseedores).

Resumen de Riesgos: Enso está abriendo nuevos caminos, lo que conlleva un riesgo proporcional. La complejidad tecnológica de unificar todo DeFi en una sola red es enorme: cada blockchain añadida o protocolo integrado es un punto potencial de fallo que debe ser gestionado. La experiencia del equipo navegando contratiempos anteriores (como el éxito limitado del producto inicial de trading social) muestra que son conscientes de los peligros y se adaptan rápidamente. Han mitigado activamente algunos riesgos (por ejemplo, descentralizando la propiedad a través de la ronda comunitaria para evitar una gobernanza excesivamente impulsada por VCs). Los inversores deben observar cómo Enso ejecuta la descentralización y si continúa atrayendo talento técnico de primer nivel para construir y asegurar la red. En el mejor de los casos, Enso podría convertirse en una infraestructura indispensable en todo Web3, generando fuertes efectos de red y acumulación de valor del token. En el peor de los casos, los contratiempos técnicos o de adopción podrían relegarlo a ser una herramienta ambiciosa pero de nicho.

Desde la perspectiva de un inversor, Enso ofrece un perfil de alto potencial, alto riesgo. Su estado actual (mediados de 2025) es el de una red prometedora con uso real y una visión clara, pero ahora debe endurecer su tecnología y superar un panorama competitivo y en evolución. La debida diligencia sobre Enso debe incluir el monitoreo de su historial de seguridad, el crecimiento de los volúmenes/tarifas de consulta a lo largo del tiempo y cuán efectivamente el modelo del token ENSO incentiva un ecosistema autosostenible. Por ahora, el impulso está a favor de Enso, pero una gestión de riesgos prudente y una innovación continua serán clave para convertir este liderazgo temprano en un dominio a largo plazo en el espacio del middleware de Web3.

Fuentes:

  • Documentación Oficial de Enso Network y Materiales de la Venta de Tokens

    • Página de Venta de Tokens de CoinList – Puntos Clave e Inversores
    • Documentos de Enso – Tokenomics y Roles de la Red
  • Entrevistas y Cobertura Mediática

    • Entrevista de CryptoPotato con el CEO de Enso (junio de 2025) – Antecedentes sobre la evolución de Enso y el diseño basado en intenciones
    • DL News (mayo de 2025) – Resumen de los atajos de Enso y el enfoque de estado compartido
  • Análisis de la Comunidad e Inversores

    • Hackernoon (I. Pandey, 2025) – Perspectivas sobre la ronda comunitaria de Enso y la estrategia de distribución de tokens
    • CryptoTotem / CoinLaunch (2025) – Desglose del suministro de tokens y cronograma de la hoja de ruta
  • Métricas del Sitio Oficial de Enso (2025) y Comunicados de Prensa – Cifras de adopción y ejemplos de casos de uso (migración de Berachain, colaboración con Uniswap).

Entornos de Ejecución Confiables (TEEs) en el Ecosistema Web3: Un Análisis Profundo

· 82 min de lectura

1. Descripción General de la Tecnología TEE

Definición y Arquitectura: Un Entorno de Ejecución Confiable (TEE) es un área segura de un procesador que protege el código y los datos cargados en su interior con respecto a la confidencialidad y la integridad. En términos prácticos, un TEE actúa como un "enclave" aislado dentro de la CPU, una especie de caja negra donde los cálculos sensibles pueden ejecutarse protegidos del resto del sistema. El código que se ejecuta dentro de un enclave TEE está protegido de tal manera que incluso un sistema operativo o hipervisor comprometido no puede leer ni manipular los datos o el código del enclave. Las propiedades clave de seguridad que proporcionan los TEEs incluyen:

  • Aislamiento: La memoria del enclave está aislada de otros procesos e incluso del kernel del sistema operativo. Incluso si un atacante obtiene privilegios de administrador completos en la máquina, no puede inspeccionar o modificar directamente la memoria del enclave.
  • Integridad: El hardware garantiza que el código que se ejecuta en el TEE no pueda ser alterado por ataques externos. Cualquier manipulación del código del enclave o del estado de ejecución será detectada, evitando resultados comprometidos.
  • Confidencialidad: Los datos dentro del enclave permanecen cifrados en la memoria y solo se descifran para su uso dentro de la CPU, por lo que los datos secretos no se exponen en texto plano al mundo exterior.
  • Atestación Remota: El TEE puede producir pruebas criptográficas (atestaciones) para convencer a una parte remota de que es genuino y que un código de confianza específico se está ejecutando en su interior. Esto significa que los usuarios pueden verificar que un enclave se encuentra en un estado confiable (por ejemplo, ejecutando el código esperado en hardware genuino) antes de proporcionarle datos secretos.

Diagrama conceptual de un Entorno de Ejecución Confiable como un enclave seguro tipo "caja negra" para la ejecución de contratos inteligentes. Las entradas cifradas (datos y código del contrato) se descifran y procesan dentro del enclave seguro, y solo los resultados cifrados salen del enclave. Esto garantiza que los datos sensibles del contrato permanezcan confidenciales para todos fuera del TEE.

Bajo el capó, los TEEs son posibles gracias al cifrado de memoria basado en hardware y al control de acceso en la CPU. Por ejemplo, cuando se crea un enclave TEE, la CPU le asigna una región de memoria protegida y utiliza claves dedicadas (grabadas en el hardware o gestionadas por un coprocesador seguro) para cifrar/descifrar datos sobre la marcha. Cualquier intento de software externo de leer la memoria del enclave solo obtiene bytes cifrados. Esta protección única a nivel de CPU permite que incluso el código a nivel de usuario defina regiones de memoria privadas (enclaves) que el malware privilegiado o incluso un administrador de sistema malicioso no puede espiar o modificar. En esencia, un TEE proporciona un nivel de seguridad más alto para las aplicaciones que el entorno operativo normal, al tiempo que es más flexible que los elementos seguros dedicados o los módulos de seguridad de hardware.

Implementaciones Clave de Hardware: Existen varias tecnologías de TEE de hardware, cada una con diferentes arquitecturas pero con el objetivo similar de crear un enclave seguro dentro del sistema:

  • Intel SGX (Software Guard Extensions): Intel SGX es una de las implementaciones de TEE más utilizadas. Permite a las aplicaciones crear enclaves a nivel de proceso, con cifrado de memoria y controles de acceso aplicados por la CPU. Los desarrolladores deben dividir su código en código "confiable" (dentro del enclave) y código "no confiable" (mundo normal), utilizando instrucciones especiales (ECALL/OCALL) para transferir datos dentro y fuera del enclave. SGX proporciona un fuerte aislamiento para los enclaves y admite la atestación remota a través del Servicio de Atestación de Intel (IAS). Muchos proyectos de blockchain, especialmente Secret Network y Oasis Network, construyeron funcionalidades de contratos inteligentes que preservan la privacidad sobre enclaves SGX. Sin embargo, el diseño de SGX en arquitecturas x86 complejas ha llevado a algunas vulnerabilidades (ver §4), y la atestación de Intel introduce una dependencia de confianza centralizada.

  • ARM TrustZone: TrustZone adopta un enfoque diferente al dividir todo el entorno de ejecución del procesador en dos mundos: un Mundo Seguro y un Mundo Normal. El código sensible se ejecuta en el Mundo Seguro, que tiene acceso a cierta memoria y periféricos protegidos, mientras que el Mundo Normal ejecuta el sistema operativo y las aplicaciones regulares. Los cambios entre mundos son controlados por la CPU. TrustZone se utiliza comúnmente en dispositivos móviles e IoT para cosas como una interfaz de usuario segura, procesamiento de pagos o gestión de derechos digitales. En un contexto de blockchain, TrustZone podría habilitar aplicaciones Web3 orientadas a móviles al permitir que las claves privadas o la lógica sensible se ejecuten en el enclave seguro del teléfono. Sin embargo, los enclaves de TrustZone suelen ser de grano más grueso (a nivel de SO o VM) y no son tan comúnmente adoptados en los proyectos Web3 actuales como SGX.

  • AMD SEV (Secure Encrypted Virtualization): La tecnología SEV de AMD se dirige a entornos virtualizados. En lugar de requerir enclaves a nivel de aplicación, SEV puede cifrar la memoria de máquinas virtuales enteras. Utiliza un procesador de seguridad integrado para gestionar claves criptográficas y realizar el cifrado de memoria para que la memoria de una VM permanezca confidencial incluso para el hipervisor anfitrión. Esto hace que SEV sea muy adecuado para casos de uso en la nube o en servidores: por ejemplo, un nodo de blockchain o un trabajador off-chain podría ejecutarse dentro de una VM totalmente cifrada, protegiendo sus datos de un proveedor de nube malicioso. El diseño de SEV significa menos esfuerzo para el desarrollador para particionar el código (se puede ejecutar una aplicación existente o incluso un sistema operativo completo en una VM protegida). Iteraciones más nuevas como SEV-SNP añaden características como la detección de manipulaciones y permiten a los propietarios de VM atestiguar sus VM sin depender de un servicio centralizado. SEV es muy relevante para el uso de TEE en la infraestructura de blockchain basada en la nube.

Otras implementaciones de TEE emergentes o de nicho incluyen Intel TDX (Trust Domain Extensions, para una protección similar a un enclave en VMs en chips Intel más nuevos), TEEs de código abierto como Keystone (RISC-V), y chips de enclave seguro en móviles (como el Secure Enclave de Apple, aunque generalmente no está abierto para código arbitrario). Cada TEE viene con su propio modelo de desarrollo y supuestos de confianza, pero todos comparten la idea central de la ejecución segura aislada por hardware.

2. Aplicaciones de los TEEs en Web3

Los Entornos de Ejecución Confiables se han convertido en una herramienta poderosa para abordar algunos de los desafíos más difíciles de Web3. Al proporcionar una capa de computación segura y privada, los TEEs habilitan nuevas posibilidades para las aplicaciones de blockchain en áreas de privacidad, escalabilidad, seguridad de oráculos e integridad. A continuación, exploramos los principales dominios de aplicación:

Contratos Inteligentes que Preservan la Privacidad

Uno de los usos más prominentes de los TEEs en Web3 es habilitar contratos inteligentes confidenciales, programas que se ejecutan en una blockchain pero que pueden manejar datos privados de forma segura. Las blockchains como Ethereum son transparentes por defecto: todos los datos de las transacciones y el estado de los contratos son públicos. Esta transparencia es problemática para casos de uso que requieren confidencialidad (por ejemplo, transacciones financieras privadas, votaciones secretas, procesamiento de datos personales). Los TEEs proporcionan una solución al actuar como un enclave de computación que preserva la privacidad conectado a la blockchain.

En un sistema de contratos inteligentes impulsado por TEE, las entradas de las transacciones pueden enviarse a un enclave seguro en un nodo validador o trabajador, procesarse dentro del enclave donde permanecen cifradas para el mundo exterior, y luego el enclave puede emitir un resultado cifrado o hasheado de vuelta a la cadena. Solo las partes autorizadas con la clave de descifrado (o la propia lógica del contrato) pueden acceder al resultado en texto plano. Por ejemplo, Secret Network utiliza Intel SGX en sus nodos de consenso para ejecutar contratos inteligentes CosmWasm sobre entradas cifradas, de modo que cosas como los saldos de las cuentas, los montos de las transacciones o el estado del contrato pueden mantenerse ocultos al público mientras siguen siendo utilizables en los cálculos. Esto ha permitido aplicaciones de DeFi secreto, por ejemplo, intercambios de tokens privados donde los montos son confidenciales, o subastas secretas donde las ofertas están cifradas y solo se revelan después del cierre de la subasta. Otro ejemplo es Parcel de Oasis Network y su ParaTime confidencial, que permiten que los datos se tokenicen y se utilicen en contratos inteligentes bajo restricciones de confidencialidad, habilitando casos de uso como la calificación crediticia o los datos médicos en la blockchain con cumplimiento de la privacidad.

Los contratos inteligentes que preservan la privacidad a través de TEEs son atractivos para la adopción empresarial e institucional de la blockchain. Las organizaciones pueden aprovechar los contratos inteligentes mientras mantienen la lógica empresarial y los datos sensibles confidenciales. Por ejemplo, un banco podría usar un contrato habilitado para TEE para manejar solicitudes de préstamos o liquidaciones de operaciones sin exponer los datos de los clientes en la cadena, pero aún así beneficiarse de la transparencia y la integridad de la verificación de la blockchain. Esta capacidad aborda directamente los requisitos de privacidad regulatorios (como GDPR o HIPAA), permitiendo el uso compatible de la blockchain en la atención médica, las finanzas y otras industrias sensibles. De hecho, los TEEs facilitan el cumplimiento de las leyes de protección de datos al garantizar que los datos personales puedan procesarse dentro de un enclave con solo salidas cifradas, satisfaciendo a los reguladores de que los datos están salvaguardados.

Más allá de la confidencialidad, los TEEs también ayudan a hacer cumplir la equidad en los contratos inteligentes. Por ejemplo, un exchange descentralizado podría ejecutar su motor de emparejamiento dentro de un TEE para evitar que los mineros o validadores vean las órdenes pendientes y realicen front-running de manera injusta. En resumen, los TEEs aportan una muy necesaria capa de privacidad a Web3, desbloqueando aplicaciones como DeFi confidencial, votación/gobernanza privada y contratos empresariales que antes eran inviables en los registros públicos.

Escalabilidad y Computación Off-Chain

Otro papel crítico para los TEEs es mejorar la escalabilidad de la blockchain al descargar cálculos pesados fuera de la cadena a un entorno seguro. Las blockchains tienen dificultades con tareas complejas o computacionalmente intensivas debido a los límites de rendimiento y los costos de la ejecución en la cadena. La computación off-chain habilitada por TEE permite que estas tareas se realicen fuera de la cadena principal (por lo tanto, sin consumir gas de bloque ni ralentizar el rendimiento en la cadena) mientras se conservan las garantías de confianza sobre la corrección de los resultados. En efecto, un TEE puede servir como un acelerador de computación off-chain verificable para Web3.

Por ejemplo, la plataforma iExec utiliza TEEs para crear un mercado descentralizado de computación en la nube donde los desarrolladores pueden ejecutar cálculos off-chain y obtener resultados que son confiables para la blockchain. Una dApp puede solicitar que una computación (digamos, una inferencia de un modelo de IA complejo o un análisis de big data) sea realizada por los nodos trabajadores de iExec. Estos nodos trabajadores ejecutan la tarea dentro de un enclave SGX, produciendo un resultado junto con una atestación de que el código correcto se ejecutó en un enclave genuino. El resultado se devuelve luego en la cadena, y el contrato inteligente puede verificar la atestación del enclave antes de aceptar la salida. Esta arquitectura permite que las cargas de trabajo pesadas se manejen off-chain sin sacrificar la confianza, aumentando efectivamente el rendimiento. La integración del Orquestador de iExec con Chainlink demuestra esto: un oráculo de Chainlink obtiene datos externos, luego entrega una computación compleja a los trabajadores TEE de iExec (por ejemplo, agregando o puntuando los datos), y finalmente el resultado seguro se entrega en la cadena. Los casos de uso incluyen cosas como cálculos de seguros descentralizados (como demostró iExec), donde se puede realizar una gran cantidad de procesamiento de datos off-chain y de manera económica, con solo el resultado final yendo a la blockchain.

La computación off-chain basada en TEE también sustenta algunas soluciones de escalado de Capa 2. El prototipo temprano de Oasis Labs, Ekiden (el precursor de Oasis Network), utilizó enclaves SGX para ejecutar transacciones off-chain en paralelo, y luego confirmar solo las raíces de estado en la cadena principal, de manera efectiva similar a las ideas de rollup pero utilizando la confianza del hardware. Al realizar la ejecución de contratos en TEEs, lograron un alto rendimiento mientras dependían de los enclaves para preservar la seguridad. Otro ejemplo es la próxima L2 Op-Succinct de Sanders Network, que combina TEEs y zkSNARKs: los TEEs ejecutan transacciones de forma privada y rápida, y luego se generan pruebas ZK para demostrar la corrección de esas ejecuciones a Ethereum. Este enfoque híbrido aprovecha la velocidad de los TEE y la verificabilidad de ZK para una solución L2 escalable y privada.

En general, los TEEs pueden ejecutar cálculos con un rendimiento casi nativo (ya que utilizan instrucciones reales de la CPU, solo con aislamiento), por lo que son órdenes de magnitud más rápidos que las alternativas puramente criptográficas como el cifrado homomórfico o las pruebas de conocimiento cero para lógica compleja. Al descargar el trabajo a los enclaves, las blockchains pueden manejar aplicaciones más complejas (como aprendizaje automático, procesamiento de imágenes/audio, análisis grandes) que serían imprácticas en la cadena. Los resultados regresan con una atestación, que el contrato en la cadena o los usuarios pueden verificar como originarios de un enclave de confianza, preservando así la integridad de los datos y la corrección. Este modelo a menudo se llama "computación off-chain verificable", y los TEEs son una piedra angular para muchos de estos diseños (por ejemplo, el Trusted Compute Framework de Hyperledger Avalon, desarrollado por Intel, iExec y otros, utiliza TEEs para ejecutar bytecode de EVM off-chain con una prueba de corrección publicada en la cadena).

Oráculos Seguros e Integridad de Datos

Los oráculos conectan las blockchains con datos del mundo real, pero introducen desafíos de confianza: ¿cómo puede un contrato inteligente confiar en que una fuente de datos off-chain es correcta y no ha sido manipulada? Los TEEs proporcionan una solución al servir como un sandbox seguro para los nodos de oráculo. Un nodo de oráculo basado en TEE puede obtener datos de fuentes externas (APIs, servicios web) y procesarlos dentro de un enclave que garantiza que los datos no han sido manipulados por el operador del nodo o un malware en el nodo. El enclave puede luego firmar o atestiguar la veracidad de los datos que proporciona. Esto mejora significativamente la integridad y confiabilidad de los datos del oráculo. Incluso si un operador de oráculo es malicioso, no puede alterar los datos sin romper la atestación del enclave (que la blockchain detectará).

Un ejemplo notable es Town Crier, un sistema de oráculo desarrollado en Cornell que fue uno de los primeros en utilizar enclaves Intel SGX para proporcionar datos autenticados a los contratos de Ethereum. Town Crier recuperaría datos (por ejemplo, de sitios web HTTPS) dentro de un enclave SGX y los entregaría a un contrato junto con una prueba (una firma del enclave) de que los datos provenían directamente de la fuente y no fueron falsificados. Chainlink reconoció el valor de esto y adquirió Town Crier en 2018 para integrar oráculos basados en TEE en su red descentralizada. Hoy en día, Chainlink y otros proveedores de oráculos tienen iniciativas de TEE: por ejemplo, DECO y Fair Sequencing Services de Chainlink involucran TEEs para garantizar la confidencialidad de los datos y el ordenamiento justo. Como se señaló en un análisis, "TEE revolucionó la seguridad de los oráculos al proporcionar un entorno a prueba de manipulaciones para el procesamiento de datos... incluso los propios operadores de nodos no pueden manipular los datos mientras se están procesando". Esto es particularmente crucial para las fuentes de datos financieros de alto valor (como los oráculos de precios para DeFi): un TEE puede prevenir incluso manipulaciones sutiles que podrían llevar a grandes exploits.

Los TEEs también permiten a los oráculos manejar datos sensibles o propietarios que no podrían publicarse en texto plano en una blockchain. Por ejemplo, una red de oráculos podría usar enclaves para agregar datos privados (como libros de órdenes de acciones confidenciales o datos de salud personales) y alimentar solo resultados derivados o pruebas validadas a la blockchain, sin exponer las entradas sensibles en bruto. De esta manera, los TEEs amplían el alcance de los datos que pueden integrarse de forma segura en los contratos inteligentes, lo cual es crítico para la tokenización de activos del mundo real (RWA), la calificación crediticia, los seguros y otros servicios en cadena intensivos en datos.

En el tema de los puentes cross-chain, los TEEs mejoran de manera similar la integridad. Los puentes a menudo dependen de un conjunto de validadores o una multifirma para custodiar activos y validar transferencias entre cadenas, lo que los convierte en objetivos principales para ataques. Al ejecutar la lógica del validador del puente dentro de TEEs, se pueden asegurar las claves privadas y los procesos de verificación del puente contra la manipulación. Incluso si el sistema operativo de un validador está comprometido, el atacante no debería poder extraer claves privadas o falsificar mensajes desde dentro del enclave. Los TEEs pueden hacer cumplir que las transacciones del puente se procesen exactamente de acuerdo con las reglas del protocolo, reduciendo el riesgo de que operadores humanos o malware inyecten transferencias fraudulentas. Además, los TEEs pueden permitir que los atomic swaps y las transacciones cross-chain se manejen en un enclave seguro que completa ambos lados o se aborta limpiamente, evitando escenarios donde los fondos se quedan atascados debido a interferencias. Varios proyectos de puentes y consorcios han explorado la seguridad basada en TEE para mitigar la plaga de hackeos de puentes que han ocurrido en los últimos años.

Integridad de Datos y Verificabilidad Off-Chain

En todos los escenarios anteriores, un tema recurrente es que los TEEs ayudan a mantener la integridad de los datos incluso fuera de la blockchain. Debido a que un TEE puede probar qué código está ejecutando (a través de la atestación) y puede garantizar que el código se ejecute sin interferencias, proporciona una forma de computación verificable. Los usuarios y los contratos inteligentes pueden confiar en los resultados que provienen de un TEE como si se hubieran calculado en la cadena, siempre que la atestación sea válida. Esta garantía de integridad es la razón por la que a veces se hace referencia a los TEEs como un "ancla de confianza" para los datos y la computación off-chain.

Sin embargo, vale la pena señalar que este modelo de confianza traslada algunas suposiciones al hardware (ver §4). La integridad de los datos es tan fuerte como la seguridad del TEE. Si el enclave se ve comprometido o la atestación se falsifica, la integridad podría fallar. No obstante, en la práctica, los TEEs (cuando se mantienen actualizados) hacen que ciertos ataques sean significativamente más difíciles. Por ejemplo, una plataforma de préstamos DeFi podría usar un TEE para calcular puntajes de crédito a partir de los datos privados de un usuario off-chain, y el contrato inteligente aceptaría el puntaje solo si va acompañado de una atestación de enclave válida. De esta manera, el contrato sabe que el puntaje fue calculado por el algoritmo aprobado sobre datos reales, en lugar de confiar ciegamente en el usuario o en un oráculo.

Los TEEs también juegan un papel en los sistemas emergentes de identidad descentralizada (DID) y autenticación. Pueden gestionar de forma segura claves privadas, datos personales y procesos de autenticación de una manera que la información sensible del usuario nunca se exponga a la blockchain o a los proveedores de dApps. Por ejemplo, un TEE en un dispositivo móvil podría manejar la autenticación biométrica y firmar una transacción de blockchain si la verificación biométrica pasa, todo sin revelar los datos biométricos del usuario. Esto proporciona tanto seguridad como privacidad en la gestión de la identidad, un componente esencial si Web3 va a manejar cosas como pasaportes, certificados o datos KYC de una manera soberana para el usuario.

En resumen, los TEEs sirven como una herramienta versátil en Web3: permiten la confidencialidad para la lógica en la cadena, permiten el escalado a través de la computación segura off-chain, protegen la integridad de los oráculos y puentes, y abren nuevos usos (desde la identidad privada hasta el intercambio de datos compatible). A continuación, veremos proyectos específicos que aprovechan estas capacidades.

3. Proyectos Web3 Notables que Aprovechan los TEEs

Varios proyectos líderes de blockchain han construido sus ofertas principales en torno a los Entornos de Ejecución Confiables. A continuación, nos sumergimos en algunos de los más notables, examinando cómo cada uno utiliza la tecnología TEE y qué valor único añade:

Secret Network

Secret Network es una blockchain de capa 1 (construida sobre el SDK de Cosmos) que fue pionera en los contratos inteligentes que preservan la privacidad utilizando TEEs. Todos los nodos validadores en Secret Network ejecutan enclaves Intel SGX, que ejecutan el código del contrato inteligente de modo que el estado del contrato y las entradas/salidas permanecen cifrados incluso para los operadores de los nodos. Esto convierte a Secret en una de las primeras plataformas de contratos inteligentes con privacidad por defecto: la privacidad no es un complemento opcional, sino una característica predeterminada de la red a nivel de protocolo.

En el modelo de Secret Network, los usuarios envían transacciones cifradas, que los validadores cargan en su enclave SGX para su ejecución. El enclave descifra las entradas, ejecuta el contrato (escrito en un tiempo de ejecución CosmWasm modificado) y produce salidas cifradas que se escriben en la blockchain. Solo los usuarios con la clave de visualización correcta (o el propio contrato con su clave interna) pueden descifrar y ver los datos reales. Esto permite que las aplicaciones utilicen datos privados en la cadena sin revelarlos públicamente.

La red ha demostrado varios casos de uso novedosos:

  • DeFi Secreto: por ejemplo, SecretSwap (un AMM) donde los saldos de las cuentas de los usuarios y los montos de las transacciones son privados, mitigando el front-running y protegiendo las estrategias de trading. Los proveedores de liquidez y los traders pueden operar sin transmitir cada uno de sus movimientos a la competencia.
  • Subastas Secretas: Contratos de subasta donde las ofertas se mantienen en secreto hasta que finaliza la subasta, evitando el comportamiento estratégico basado en las ofertas de otros.
  • Votación y Gobernanza Privada: Los poseedores de tokens pueden votar sobre propuestas sin revelar sus opciones de voto, mientras que el recuento aún puede ser verificado, asegurando una gobernanza justa y libre de intimidación.
  • Mercados de datos: Conjuntos de datos sensibles pueden ser transaccionados y utilizados en cálculos sin exponer los datos brutos a compradores o nodos.

Secret Network esencialmente incorpora TEEs a nivel de protocolo para crear una propuesta de valor única: ofrece privacidad programable. Los desafíos que abordan incluyen la coordinación de la atestación de enclaves en un conjunto de validadores descentralizado y la gestión de la distribución de claves para que los contratos puedan descifrar las entradas mientras las mantienen en secreto para los validadores. A todas luces, Secret ha demostrado la viabilidad de la confidencialidad impulsada por TEE en una blockchain pública, estableciéndose como un líder en el espacio.

Oasis Network

Oasis Network es otra capa 1 orientada a la escalabilidad y la privacidad, que utiliza extensivamente TEEs (Intel SGX) en su arquitectura. Oasis introdujo un diseño innovador que separa el consenso de la computación en diferentes capas llamadas la Capa de Consenso y la Capa ParaTime. La Capa de Consenso se encarga del ordenamiento y la finalidad de la blockchain, mientras que cada ParaTime puede ser un entorno de ejecución para contratos inteligentes. Notablemente, el Emerald ParaTime de Oasis es un entorno compatible con EVM, y Sapphire es un EVM confidencial que utiliza TEEs para mantener privado el estado de los contratos inteligentes.

El uso de TEEs por parte de Oasis se centra en la computación confidencial a escala. Al aislar la computación pesada en ParaTimes paralelizables (que pueden ejecutarse en muchos nodos), logran un alto rendimiento, y al usar TEEs dentro de esos nodos ParaTime, aseguran que los cálculos puedan incluir datos sensibles sin revelarlos. Por ejemplo, una institución podría ejecutar un algoritmo de calificación crediticia en Oasis alimentando datos privados en un ParaTime confidencial: los datos permanecen cifrados para el nodo (ya que se procesan en el enclave), y solo sale la puntuación. Mientras tanto, el consenso de Oasis solo registra la prueba de que la computación se realizó correctamente.

Técnicamente, Oasis añadió capas adicionales de seguridad más allá de SGX estándar. Implementaron una "raíz de confianza en capas": utilizando el Enclave de Cotización SGX de Intel y un kernel ligero personalizado para verificar la confiabilidad del hardware y para aislar las llamadas al sistema del enclave. Esto reduce la superficie de ataque (al filtrar qué llamadas al SO pueden hacer los enclaves) y protege contra ciertos ataques conocidos de SGX. Oasis también introdujo características como enclaves duraderos (para que los enclaves puedan persistir el estado a través de reinicios) y registro seguro para mitigar los ataques de reversión (donde un nodo podría intentar reproducir un estado de enclave antiguo). Estas innovaciones se describieron en sus documentos técnicos y son parte de por qué Oasis es visto como un proyecto impulsado por la investigación en la computación de blockchain basada en TEE.

Desde una perspectiva de ecosistema, Oasis se ha posicionado para cosas como DeFi privado (permitiendo que los bancos participen sin filtrar los datos de los clientes) y la tokenización de datos (donde individuos o empresas pueden compartir datos con modelos de IA de manera confidencial y ser compensados, todo a través de la blockchain). También han colaborado con empresas en proyectos piloto (por ejemplo, trabajando con BMW en la privacidad de datos, y otros en el intercambio de datos de investigación médica). En general, Oasis Network muestra cómo la combinación de TEEs con una arquitectura escalable puede abordar tanto la privacidad como el rendimiento, convirtiéndolo en un actor significativo en las soluciones Web3 basadas en TEE.

Sanders Network

Sanders Network es una red de computación en la nube descentralizada en el ecosistema de Polkadot que utiliza TEEs para proporcionar servicios de computación confidenciales y de alto rendimiento. Es una parachain en Polkadot, lo que significa que se beneficia de la seguridad e interoperabilidad de Polkadot, pero introduce su propio tiempo de ejecución novedoso para la computación off-chain en enclaves seguros.

La idea central de Sanders es mantener una gran red de nodos trabajadores (llamados mineros de Sanders) que ejecutan tareas dentro de TEEs (específicamente, Intel SGX hasta ahora) y producen resultados verificables. Estas tareas pueden variar desde ejecutar segmentos de contratos inteligentes hasta computación de propósito general solicitada por los usuarios. Debido a que los trabajadores se ejecutan en SGX, Sanders asegura que los cálculos se realizan con confidencialidad (los datos de entrada están ocultos para el operador del trabajador) e integridad (los resultados vienen con una atestación). Esto crea efectivamente una nube sin confianza donde los usuarios pueden desplegar cargas de trabajo sabiendo que el anfitrión no puede espiar ni manipularlas.

Se puede pensar en Sanders como análogo a Amazon EC2 o AWS Lambda, pero descentralizado: los desarrolladores pueden desplegar código en la red de Sanders y hacer que se ejecute en muchas máquinas habilitadas para SGX en todo el mundo, pagando con el token de Sanders por el servicio. Algunos casos de uso destacados:

  • Análisis e IA en Web3: Un proyecto podría analizar datos de usuarios o ejecutar algoritmos de IA en enclaves de Sanders, de modo que los datos brutos de los usuarios permanezcan cifrados (protegiendo la privacidad) mientras que solo las ideas agregadas salen del enclave.
  • Backends de juegos y Metaverso: Sanders puede manejar lógica de juego intensiva o simulaciones de mundos virtuales off-chain, enviando solo compromisos o hashes a la blockchain, permitiendo una jugabilidad más rica sin confiar en un solo servidor.
  • Servicios en cadena: Sanders ha construido una plataforma de computación off-chain llamada Sanders Cloud. Por ejemplo, puede servir como backend para bots, servicios web descentralizados, o incluso un libro de órdenes off-chain que publica operaciones en un contrato inteligente de DEX con atestación TEE.

Sanders enfatiza que puede escalar la computación confidencial horizontalmente: ¿necesitas más capacidad? Añade más nodos trabajadores TEE. Esto es diferente a una sola blockchain donde la capacidad de cómputo está limitada por el consenso. Así, Sanders abre posibilidades para dApps computacionalmente intensivas que aún desean seguridad sin confianza. Es importante destacar que Sanders no se basa únicamente en la confianza del hardware; se está integrando con el consenso de Polkadot (por ejemplo, staking y slashing por resultados incorrectos) e incluso explorando una combinación de TEE con pruebas de conocimiento cero (como se mencionó, su próxima L2 utiliza TEE para acelerar la ejecución y ZKP para verificarla de manera sucinta en Ethereum). Este enfoque híbrido ayuda a mitigar el riesgo de cualquier compromiso de un solo TEE al agregar verificación criptográfica por encima.

En resumen, Sanders Network aprovecha los TEEs para ofrecer una nube descentralizada y confidencial para Web3, permitiendo la computación off-chain con garantías de seguridad. Esto libera una clase de aplicaciones de blockchain que necesitan tanto cómputo pesado como privacidad de datos, cerrando la brecha entre los mundos on-chain y off-chain.

iExec

iExec es un mercado descentralizado para recursos de computación en la nube construido sobre Ethereum. A diferencia de los tres anteriores (que son sus propias cadenas o parachains), iExec opera como una red de capa 2 o off-chain que se coordina con los contratos inteligentes de Ethereum. Los TEEs (específicamente Intel SGX) son una piedra angular del enfoque de iExec para establecer la confianza en la computación off-chain.

La red iExec consta de nodos trabajadores contribuidos por varios proveedores. Estos trabajadores pueden ejecutar tareas solicitadas por los usuarios (desarrolladores de dApps, proveedores de datos, etc.). Para garantizar que estos cálculos off-chain sean confiables, iExec introdujo un marco de "Computación Off-chain Confiable": las tareas pueden ejecutarse dentro de enclaves SGX, y los resultados vienen con una firma de enclave que prueba que la tarea se ejecutó correctamente en un nodo seguro. iExec se asoció con Intel para lanzar esta función de computación confiable e incluso se unió al Confidential Computing Consortium para avanzar en los estándares. Su protocolo de consenso, llamado Prueba de Contribución (PoCo), agrega votos/atestaciones de múltiples trabajadores cuando es necesario para alcanzar un consenso sobre el resultado correcto. En muchos casos, la atestación de un solo enclave puede ser suficiente si el código es determinista y la confianza en SGX es alta; para una mayor seguridad, iExec puede replicar tareas en varios TEEs y usar un consenso o un voto mayoritario.

La plataforma de iExec permite varios casos de uso interesantes:

  • Computación de Oráculos Descentralizados: Como se mencionó anteriormente, iExec puede trabajar con Chainlink. Un nodo de Chainlink podría obtener datos brutos, luego entregarlos a un trabajador SGX de iExec para realizar un cálculo (por ejemplo, un algoritmo propietario o una inferencia de IA) sobre esos datos, y finalmente devolver un resultado en la cadena. Esto amplía lo que los oráculos pueden hacer más allá de simplemente retransmitir datos: ahora pueden proporcionar servicios computados (como llamar a un modelo de IA o agregar muchas fuentes) con TEE garantizando la honestidad.
  • IA y DePIN (Red de Infraestructura Física Descentralizada): iExec se está posicionando como una capa de confianza para aplicaciones de IA descentralizadas. Por ejemplo, una dApp que utiliza un modelo de aprendizaje automático puede ejecutar el modelo en un enclave para proteger tanto el modelo (si es propietario) como los datos del usuario que se introducen. En el contexto de DePIN (como las redes de IoT distribuidas), los TEEs se pueden utilizar en dispositivos de borde para confiar en las lecturas de los sensores y los cálculos sobre esas lecturas.
  • Monetización Segura de Datos: Los proveedores de datos pueden hacer que sus conjuntos de datos estén disponibles en el mercado de iExec en forma cifrada. Los compradores pueden enviar sus algoritmos para que se ejecuten sobre los datos dentro de un TEE (de modo que los datos brutos del proveedor de datos nunca se revelen, protegiendo su propiedad intelectual, y los detalles del algoritmo también pueden ocultarse). El resultado del cálculo se devuelve al comprador, y el pago apropiado al proveedor de datos se maneja a través de contratos inteligentes. Este esquema, a menudo llamado intercambio seguro de datos, es facilitado por la confidencialidad de los TEEs.

En general, iExec proporciona el pegamento entre los contratos inteligentes de Ethereum y la ejecución segura off-chain. Demuestra cómo los "trabajadores" TEE pueden conectarse en red para formar una nube descentralizada, completa con un mercado (utilizando el token RLC de iExec para el pago) y mecanismos de consenso. Al liderar el grupo de trabajo de Computación Confiable de la Enterprise Ethereum Alliance y contribuir a los estándares (como Hyperledger Avalon), iExec también impulsa una adopción más amplia de los TEEs en escenarios de blockchain empresarial.

Otros Proyectos y Ecosistemas

Más allá de los cuatro anteriores, hay algunos otros proyectos que vale la pena señalar:

  • Integritee – otra parachain de Polkadot similar a Sanders (de hecho, surgió del trabajo de TEE de la Energy Web Foundation). Integritee utiliza TEEs para crear "parachain-como-servicio" para empresas, combinando el procesamiento de enclaves on-chain y off-chain.
  • Automata Network – un protocolo de middleware para la privacidad en Web3 que aprovecha los TEEs para transacciones privadas, votación anónima y procesamiento de transacciones resistente a MEV. Automata funciona como una red off-chain que proporciona servicios como un relé RPC privado y se mencionó que utiliza TEEs para cosas como identidad protegida y transacciones privadas sin gas.
  • Hyperledger Sawtooth (PoET) – en el ámbito empresarial, Sawtooth introdujo un algoritmo de consenso llamado Prueba de Tiempo Transcurrido que se basaba en SGX. Cada validador ejecuta un enclave que espera un tiempo aleatorio y produce una prueba; el que tiene la espera más corta "gana" el bloque, una lotería justa impuesta por SGX. Aunque Sawtooth no es un proyecto Web3 per se (más bien blockchain empresarial), es un uso creativo de los TEEs para el consenso.
  • Cadenas Empresariales/de Consorcio – Muchas soluciones de blockchain empresarial (por ejemplo, ConsenSys Quorum, IBM Blockchain) incorporan TEEs para permitir transacciones de consorcio confidenciales, donde solo los nodos autorizados ven ciertos datos. Por ejemplo, el plan del Trusted Compute Framework (TCF) de la Enterprise Ethereum Alliance utiliza TEEs para ejecutar contratos privados off-chain y entregar pruebas de Merkle en la cadena.

Estos proyectos muestran colectivamente la versatilidad de los TEEs: impulsan L1s enteras centradas en la privacidad, sirven como redes off-chain, aseguran piezas de infraestructura como oráculos y puentes, e incluso sustentan algoritmos de consenso. A continuación, consideramos los beneficios y desafíos más amplios del uso de TEEs en entornos descentralizados.

4. Beneficios y Desafíos de los TEEs en Entornos Descentralizados

La adopción de Entornos de Ejecución Confiables en sistemas de blockchain conlleva importantes beneficios técnicos, así como notables desafíos y compromisos. Examinaremos ambos lados: lo que los TEEs ofrecen a las aplicaciones descentralizadas y qué problemas o riesgos surgen de su uso.

Beneficios y Fortalezas Técnicas

  • Fuerte Seguridad y Privacidad: El principal beneficio son las garantías de confidencialidad e integridad. Los TEEs permiten que el código sensible se ejecute con la seguridad de que no será espiado ni alterado por malware externo. Esto proporciona un nivel de confianza en la computación off-chain que antes no estaba disponible. Para la blockchain, esto significa que se pueden utilizar datos privados (mejorando la funcionalidad de las dApps) sin sacrificar la seguridad. Incluso en entornos no confiables (servidores en la nube, nodos validadores gestionados por terceros), los TEEs mantienen los secretos a salvo. Esto es especialmente beneficioso para gestionar claves privadas, datos de usuario y algoritmos propietarios dentro de los sistemas cripto. Por ejemplo, una billetera de hardware o un servicio de firma en la nube podría usar un TEE para firmar transacciones de blockchain internamente para que la clave privada nunca se exponga en texto plano, combinando conveniencia con seguridad.

  • Rendimiento Casi Nativo: A diferencia de los enfoques puramente criptográficos para la computación segura (como las pruebas ZK o el cifrado homomórfico), la sobrecarga de los TEE es relativamente pequeña. El código se ejecuta directamente en la CPU, por lo que un cálculo dentro de un enclave es aproximadamente tan rápido como ejecutarlo fuera (con cierta sobrecarga por las transiciones del enclave y el cifrado de memoria, típicicamente ralentizaciones de un solo dígito porcentual en SGX). Esto significa que los TEEs pueden manejar tareas computacionalmente intensivas de manera eficiente, permitiendo casos de uso (como fuentes de datos en tiempo real, contratos inteligentes complejos, aprendizaje automático) que serían órdenes de magnitud más lentos si se hicieran con protocolos criptográficos. La baja latencia de los enclaves los hace adecuados donde se necesita una respuesta rápida (por ejemplo, bots de trading de alta frecuencia asegurados por TEEs, o aplicaciones y juegos interactivos donde la experiencia del usuario sufriría con grandes retrasos).

  • Escalabilidad Mejorada (a través de la Descarga): Al permitir que los cálculos pesados se realicen de forma segura off-chain, los TEEs ayudan a aliviar la congestión y los costos de gas en las cadenas principales. Habilitan diseños de Capa 2 y protocolos secundarios donde la blockchain se utiliza solo para verificación o liquidación final, mientras que la mayor parte de la computación ocurre en enclaves paralelos. Esta modularización (lógica computacionalmente intensiva en TEEs, consenso en la cadena) puede mejorar drásticamente el rendimiento y la escalabilidad de las aplicaciones descentralizadas. Por ejemplo, un DEX podría hacer el emparejamiento en un TEE off-chain y solo publicar las operaciones emparejadas en la cadena, aumentando el rendimiento y reduciendo el gas en la cadena.

  • Mejor Experiencia de Usuario y Funcionalidad: Con los TEEs, las dApps pueden ofrecer características como confidencialidad o análisis complejos que atraen a más usuarios (incluidas las instituciones). Los TEEs también permiten transacciones sin gas o meta-transacciones al ejecutarlas de forma segura off-chain y luego enviar los resultados, como se señaló en el uso de TEEs por parte de Automata para reducir el gas en transacciones privadas. Además, almacenar el estado sensible off-chain en un enclave puede reducir los datos publicados en la cadena, lo cual es bueno para la privacidad del usuario y la eficiencia de la red (menos datos en la cadena para almacenar/verificar).

  • Composabilidad con Otras Tecnologías: Curiosamente, los TEEs pueden complementar otras tecnologías (no es estrictamente un beneficio inherente a los TEEs solos, sino en combinación). Pueden servir como el pegamento que une soluciones híbridas: por ejemplo, ejecutar un programa en un enclave y también generar una prueba ZK de su ejecución, donde el enclave ayuda con partes del proceso de prueba para acelerarlo. O usar TEEs en redes MPC para manejar ciertas tareas con menos rondas de comunicación. Discutiremos las comparaciones en el §5, pero muchos proyectos destacan que los TEEs no tienen que reemplazar la criptografía, pueden trabajar junto a ella para reforzar la seguridad (el mantra de Sanders: "La fuerza de los TEEs radica en apoyar a otros, no en reemplazarlos").

Supuestos de Confianza y Vulnerabilidades de Seguridad

A pesar de sus fortalezas, los TEEs introducen supuestos de confianza específicos y no son invulnerables. Es crucial entender estos desafíos:

  • Confianza en el Hardware y Centralización: Al usar TEEs, uno está depositando inherentemente confianza en el proveedor de silicio y en la seguridad de su diseño de hardware y cadena de suministro. Por ejemplo, usar Intel SGX significa confiar en que Intel no tiene puertas traseras, que su fabricación es segura y que el microcódigo de la CPU implementa correctamente el aislamiento del enclave. Este es un modelo de confianza más centralizado en comparación con la criptografía pura (que se basa en supuestos matemáticos distribuidos entre todos los usuarios). Además, la atestación para SGX históricamente depende de contactar al Servicio de Atestación de Intel, lo que significa que si Intel se desconectara o decidiera revocar claves, los enclaves a nivel mundial podrían verse afectados. Esta dependencia de la infraestructura de una sola empresa plantea preocupaciones: podría ser un único punto de fallo o incluso un objetivo de regulación gubernamental (por ejemplo, los controles de exportación de EE. UU. podrían en teoría restringir quién puede usar TEEs fuertes). AMD SEV mitiga esto al permitir una atestación más descentralizada (los propietarios de VM pueden atestiguar sus VM), pero aún así se confía en el chip y el firmware de AMD. El riesgo de centralización a menudo se cita como algo antitético a la descentralización de la blockchain. Proyectos como Keystone (TEE de código abierto) y otros están investigando formas de reducir la dependencia de cajas negras propietarias, pero aún no son de uso generalizado.

  • Canal Lateral y Otras Vulnerabilidades: Un TEE no es una bala de plata; puede ser atacado a través de medios indirectos. Los ataques de canal lateral explotan el hecho de que incluso si el acceso directo a la memoria está bloqueado, la operación de un enclave podría influir sutilmente en el sistema (a través del tiempo, el uso de la caché, el consumo de energía, las emisiones electromagnéticas, etc.). En los últimos años, se han demostrado numerosos ataques académicos a Intel SGX: desde Foreshadow (extracción de secretos del enclave a través de fugas de tiempo de la caché L1) hasta Plundervolt (inyección de fallos de voltaje a través de instrucciones privilegiadas) y SGAxe (extracción de claves de atestación), entre otros. Estos ataques sofisticados muestran que los TEEs pueden ser comprometidos sin necesidad de romper las protecciones criptográficas, sino explotando comportamientos microarquitectónicos o fallos en la implementación. Como resultado, se reconoce que "los investigadores han identificado varios vectores de ataque potenciales que podrían explotar vulnerabilidades de hardware o diferencias de tiempo en las operaciones de TEE". Aunque estos ataques no son triviales y a menudo requieren acceso local o hardware malicioso, son una amenaza real. Los TEEs tampoco protegen generalmente contra ataques físicos si un adversario tiene el chip en sus manos (por ejemplo, decapsular el chip, sondear buses, etc., puede derrotar a la mayoría de los TEEs comerciales).

    Las respuestas de los proveedores a los descubrimientos de canales laterales han sido parches de microcódigo y actualizaciones del SDK del enclave para mitigar las fugas conocidas (a veces a costa del rendimiento). Pero sigue siendo un juego del gato y el ratón. Para Web3, esto significa que si alguien encuentra un nuevo canal lateral en SGX, un contrato DeFi "seguro" que se ejecuta en SGX podría ser explotado (por ejemplo, para filtrar datos secretos o manipular la ejecución). Por lo tanto, depender de los TEEs significa aceptar una superficie de vulnerabilidad potencial a nivel de hardware que está fuera del modelo de amenaza típico de la blockchain. Es un área activa de investigación para fortalecer los TEEs contra estos (por ejemplo, diseñando código de enclave con operaciones de tiempo constante, evitando patrones de acceso a memoria dependientes de secretos y utilizando técnicas como la RAM ajena). Algunos proyectos también aumentan los TEEs con verificaciones secundarias, por ejemplo, combinándolos con pruebas ZK, o haciendo que múltiples enclaves se ejecuten en hardware de diferentes proveedores para reducir el riesgo de un solo chip.

  • Rendimiento y Restricciones de Recursos: Aunque los TEEs se ejecutan a una velocidad casi nativa para tareas ligadas a la CPU, tienen algunas sobrecargas y límites. Entrar en un enclave (un ECALL) y salir (OCALL) tiene un costo, al igual que el cifrado/descifrado de las páginas de memoria. Esto puede afectar el rendimiento en cruces de límites de enclave muy frecuentes. Los enclaves también suelen tener limitaciones de tamaño de memoria. Por ejemplo, los primeros SGX tenían una Caché de Páginas de Enclave limitada y cuando los enclaves usaban más memoria, las páginas tenían que ser intercambiadas (con cifrado), lo que ralentizaba masivamente el rendimiento. Incluso los TEEs más nuevos a menudo no permiten usar toda la RAM del sistema fácilmente; hay una región de memoria segura que podría estar limitada. Esto significa que los cálculos o conjuntos de datos a muy gran escala podrían ser difíciles de manejar por completo dentro de un TEE. En contextos de Web3, esto podría limitar la complejidad de los contratos inteligentes o los modelos de ML que pueden ejecutarse en un enclave. Los desarrolladores tienen que optimizar la memoria y posiblemente dividir las cargas de trabajo.

  • Complejidad de la Atestación y la Gestión de Claves: Usar TEEs en un entorno descentralizado requiere flujos de trabajo de atestación robustos: cada nodo necesita demostrar a los demás que está ejecutando un enclave auténtico con el código esperado. Configurar esta verificación de atestación en la cadena puede ser complejo. Generalmente implica codificar la clave pública de atestación o el certificado del proveedor en el protocolo y escribir la lógica de verificación en contratos inteligentes o clientes off-chain. Esto introduce una sobrecarga en el diseño del protocolo, y cualquier cambio (como que Intel cambie su formato de clave de firma de atestación de EPID a DCAP) puede causar cargas de mantenimiento. Además, la gestión de claves dentro de los TEEs (para descifrar datos o firmar resultados) añade otra capa de complejidad. Los errores en la gestión de claves del enclave podrían socavar la seguridad (por ejemplo, si un enclave expone inadvertidamente una clave de descifrado a través de un error, todas sus promesas de confidencialidad se derrumban). Las mejores prácticas implican el uso de las API de sellado del TEE para almacenar claves de forma segura y rotar las claves si es necesario, pero de nuevo, esto requiere un diseño cuidadoso por parte de los desarrolladores.

  • Denegación de Servicio y Disponibilidad: Un problema quizás menos discutido: los TEEs no ayudan con la disponibilidad e incluso pueden introducir nuevas vías de DoS. Por ejemplo, un atacante podría inundar un servicio basado en TEE con entradas que son costosas de procesar, sabiendo que el enclave no puede ser inspeccionado o interrumpido fácilmente por el operador (ya que está aislado). Además, si se encuentra una vulnerabilidad y un parche requiere actualizaciones de firmware, durante ese ciclo muchos servicios de enclave podrían tener que pausarse (por seguridad) hasta que los nodos estén parcheados, causando tiempo de inactividad. En el consenso de la blockchain, imagina si se encontrara un error crítico en SGX: redes como Secret podrían tener que detenerse hasta que haya una solución, ya que la confianza en los enclaves se rompería. La coordinación de tales respuestas en una red descentralizada es un desafío.

Composabilidad y Limitaciones del Ecosistema

  • Composabilidad Limitada con Otros Contratos: En una plataforma de contratos inteligentes pública como Ethereum, los contratos pueden llamar fácilmente a otros contratos y todo el estado está abierto, lo que permite los legos de dinero de DeFi y una rica composición. En un modelo de contrato basado en TEE, el estado privado no se puede compartir o componer libremente sin romper la confidencialidad. Por ejemplo, si el Contrato A en un enclave necesita interactuar con el Contrato B, y ambos tienen algunos datos secretos, ¿cómo colaboran? O deben realizar un complejo protocolo seguro multipartita (lo que niega parte de la simplicidad de los TEEs) o se combinan en un solo enclave (reduciendo la modularidad). Este es un desafío que Secret Network y otros enfrentan: las llamadas entre contratos con privacidad no son triviales. Algunas soluciones implican tener un solo enclave que maneje la ejecución de múltiples contratos para que pueda gestionar internamente los secretos compartidos, pero eso puede hacer que el sistema sea más monolítico. Por lo tanto, la composabilidad de los contratos privados es más limitada que la de los públicos, o requiere nuevos patrones de diseño. De manera similar, la integración de módulos basados en TEE en dApps de blockchain existentes requiere un diseño de interfaz cuidadoso: a menudo solo el resultado de un enclave se publica en la cadena, que podría ser un snark o un hash, y otros contratos solo pueden usar esa información limitada. Esto es ciertamente un compromiso; proyectos como Secret proporcionan claves de visualización y permiten compartir secretos según sea necesario, pero no es tan fluido como la composabilidad normal en la cadena.

  • Estandarización e Interoperabilidad: El ecosistema TEE actualmente carece de estándares unificados entre los proveedores. Intel SGX, AMD SEV, ARM TrustZone tienen todos diferentes modelos de programación y métodos de atestación. Esta fragmentación significa que una dApp escrita para enclaves SGX no es trivialmente portable a TrustZone, etc. En la blockchain, esto puede atar un proyecto a un hardware específico (por ejemplo, Secret y Oasis están atados a servidores x86 con SGX en este momento). Si en el futuro quisieran admitir nodos ARM (digamos, validadores en móviles), requeriría un desarrollo adicional y quizás una lógica de verificación de atestación diferente. Hay esfuerzos (como el CCC – Confidential Computing Consortium) para estandarizar la atestación y las API de enclaves, pero aún no hemos llegado a ese punto. La falta de estándares también afecta las herramientas para desarrolladores: uno podría encontrar el SDK de SGX maduro pero luego necesitar adaptarse a otro TEE con un SDK diferente. Este desafío de interoperabilidad puede ralentizar la adopción y aumentar los costos.

  • Curva de Aprendizaje para Desarrolladores: Construir aplicaciones que se ejecutan dentro de TEEs requiere un conocimiento especializado que muchos desarrolladores de blockchain pueden no tener. A menudo se necesita programación de bajo nivel en C/C++ (para SGX/TrustZone) o comprensión de la seguridad de la memoria y la codificación resistente a canales laterales. La depuración del código del enclave es notoriamente complicada (¡no se puede ver fácilmente dentro de un enclave mientras se está ejecutando por razones de seguridad!). Aunque existen frameworks y lenguajes de nivel superior (como el uso de Rust por parte de Oasis para su tiempo de ejecución confidencial, o incluso herramientas para ejecutar WebAssembly en enclaves), la experiencia del desarrollador sigue siendo más difícil que el desarrollo típico de contratos inteligentes o el desarrollo web2 off-chain. Esta curva de aprendizaje pronunciada y las herramientas inmaduras pueden disuadir a los desarrolladores o llevar a errores si no se manejan con cuidado. También está el aspecto de necesitar hardware para probar: ejecutar código SGX necesita una CPU habilitada para SGX o un emulador (que es más lento), por lo que la barrera de entrada es más alta. Como resultado, relativamente pocos desarrolladores hoy en día están profundamente familiarizados con el desarrollo de enclaves, lo que hace que las auditorías y el apoyo de la comunidad sean más escasos que en, digamos, la bien transitada comunidad de Solidity.

  • Costos Operativos: Ejecutar una infraestructura basada en TEE puede ser más costoso. El hardware en sí podría ser más caro o escaso (por ejemplo, ciertos proveedores de la nube cobran una prima por las VM con capacidad SGX). También hay una sobrecarga en las operaciones: mantener el firmware actualizado (para parches de seguridad), gestionar la red de atestación, etc., lo que los proyectos pequeños podrían encontrar oneroso. Si cada nodo debe tener una cierta CPU, podría reducir el grupo potencial de validadores (no todos tienen el hardware requerido), afectando así la descentralización y posiblemente llevando a un mayor uso de alojamiento en la nube.

En resumen, aunque los TEEs desbloquean características potentes, también traen compromisos de confianza (confianza en el hardware vs. confianza en las matemáticas), debilidades de seguridad potenciales (especialmente canales laterales) y obstáculos de integración en un contexto descentralizado. Los proyectos que utilizan TEEs deben ingeniárselas cuidadosamente en torno a estos problemas, empleando defensa en profundidad (no asumir que el TEE es inquebrantable), manteniendo la base de computación confiable al mínimo y siendo transparentes sobre los supuestos de confianza para los usuarios (para que quede claro, por ejemplo, que se está confiando en el hardware de Intel además del consenso de la blockchain).

5. TEEs vs. Otras Tecnologías que Preservan la Privacidad (ZKP, FHE, MPC)

Los Entornos de Ejecución Confiables son un enfoque para lograr la privacidad y la seguridad en Web3, pero existen otras técnicas importantes que incluyen las Pruebas de Conocimiento Cero (ZKPs), el Cifrado Totalmente Homomórfico (FHE) y la Computación Segura Multipartita (MPC). Cada una de estas tecnologías tiene un modelo de confianza y un perfil de rendimiento diferentes. En muchos casos, no son mutuamente excluyentes, pueden complementarse entre sí, pero es útil comparar sus compromisos en rendimiento, confianza y usabilidad para el desarrollador:

Para definir brevemente las alternativas:

  • ZKPs: Pruebas criptográficas (como zk-SNARKs, zk-STARKs) que permiten a una parte demostrar a otras que una afirmación es verdadera (por ejemplo, "conozco un secreto que satisface este cálculo") sin revelar por qué es verdadera (ocultando la entrada secreta). En la blockchain, las ZKPs se utilizan para transacciones privadas (por ejemplo, Zcash, Aztec) y para la escalabilidad (rollups que publican pruebas de ejecución correcta). Garantizan una fuerte privacidad (no se filtra ningún dato secreto, solo pruebas) y una integridad garantizada por las matemáticas, pero generar estas pruebas puede ser computacionalmente pesado y los circuitos deben diseñarse cuidadosamente.
  • FHE: Esquema de cifrado que permite la computación arbitraria sobre datos cifrados, de modo que el resultado, al ser descifrado, coincide con el resultado de computar sobre textos planos. En teoría, el FHE proporciona la máxima privacidad: los datos permanecen cifrados en todo momento, y no es necesario confiar en nadie con los datos brutos. Pero el FHE es extremadamente lento para cálculos generales (aunque está mejorando con la investigación); todavía se encuentra principalmente en uso experimental o especializado debido al rendimiento.
  • MPC: Protocolos donde múltiples partes calculan conjuntamente una función sobre sus entradas privadas sin revelar esas entradas entre sí. A menudo implica compartir secretos de los datos entre las partes y realizar operaciones criptográficas para que la salida sea correcta pero las entradas individuales permanezcan ocultas. El MPC puede distribuir la confianza (ningún punto único ve todos los datos) y puede ser eficiente para ciertas operaciones, pero típicamente incurre en una sobrecarga de comunicación y coordinación y puede ser complejo de implementar para redes grandes.

A continuación se presenta una tabla comparativa que resume las diferencias clave:

TecnologíaModelo de ConfianzaRendimientoPrivacidad de DatosUsabilidad para el Desarrollador
TEE (Intel SGX, etc.)Confianza en el fabricante del hardware (servidor de atestación centralizado en algunos casos). Asume que el chip es seguro; si el hardware se ve comprometido, la seguridad se rompe.Velocidad de ejecución casi nativa; sobrecarga mínima. Bueno para computación en tiempo real y grandes cargas de trabajo. La escalabilidad está limitada por la disponibilidad de nodos habilitados para TEE.Los datos están en texto plano dentro del enclave, pero cifrados para el mundo exterior. Fuerte confidencialidad si el hardware se mantiene, pero si el enclave es vulnerado, los secretos quedan expuestos (sin protección matemática adicional).Complejidad moderada. A menudo se puede reutilizar código/lenguajes existentes (C, Rust) y ejecutarlo en un enclave con modificaciones menores. La barrera de entrada más baja entre estos: no es necesario aprender criptografía avanzada, pero requiere programación de sistemas y conocimiento específico del SDK del TEE.
ZKP (zk-SNARK/STARK)Confianza en supuestos matemáticos (por ejemplo, la dureza de los problemas criptográficos) y a veces una configuración confiable (para SNARKs). Sin dependencia de ninguna parte única en tiempo de ejecución.La generación de pruebas es computacionalmente pesada (especialmente para programas complejos), a menudo órdenes de magnitud más lenta que la nativa. La verificación en la cadena es rápida (pocos ms). No es ideal para grandes cálculos de datos debido al tiempo de prueba. Escalabilidad: buena para la verificación sucinta (rollups) pero el probador es el cuello de botella.Privacidad muy fuerte: se puede probar la corrección sin revelar ninguna entrada privada. Solo se filtra información mínima (como el tamaño de la prueba). Ideal para la privacidad financiera, etc.Alta complejidad. Requiere aprender lenguajes especializados (circuitos, zkDSLs como Circom o Noir) y pensar en términos de circuitos aritméticos. La depuración es difícil. Menos expertos disponibles.
FHEConfianza en las matemáticas (problemas de retículos). Sin parte confiable; la seguridad se mantiene mientras el cifrado no se rompa.Muy lento para uso general. Las operaciones sobre datos cifrados son varios órdenes de magnitud más lentas que en texto plano. Mejora algo con avances de hardware y mejores algoritmos, pero actualmente es impráctico para uso en tiempo real en contextos de blockchain.Máxima privacidad: los datos permanecen cifrados todo el tiempo, incluso durante la computación. Esto es ideal para datos sensibles (por ejemplo, médicos, análisis interinstitucionales) si el rendimiento lo permitiera.Muy especializado. Los desarrolladores necesitan conocimientos de criptografía. Existen algunas bibliotecas (como Microsoft SEAL, TFHE), pero escribir programas arbitrarios en FHE es difícil y tortuoso. Aún no es un objetivo de desarrollo rutinario para dApps.
MPCConfianza distribuida entre múltiples partes. Asume que un umbral de partes es honesto (sin colusión más allá de cierto número). No se necesita confianza en el hardware. Falla la confianza si demasiados coluden.Típicamente más lento que el nativo debido a las rondas de comunicación, pero a menudo más rápido que el FHE. El rendimiento varía: operaciones simples (suma, multiplicación) pueden ser eficientes; la lógica compleja puede disparar el costo de comunicación. La latencia es sensible a las velocidades de la red. La escalabilidad puede mejorarse con sharding o supuestos de confianza parcial.Fuerte privacidad si se cumplen los supuestos: ningún nodo ve la entrada completa. Pero algo de información puede filtrarse a través de la salida o si las partes se caen (además, carece de la sucinta de ZK: obtienes el resultado pero no una prueba fácilmente compartible sin ejecutar el protocolo de nuevo).Alta complejidad. Requiere diseñar un protocolo personalizado para cada caso de uso o usar frameworks (como SPDZ, o la oferta de Partisia). Los desarrolladores deben razonar sobre protocolos criptográficos y a menudo coordinar el despliegue de múltiples nodos. La integración en aplicaciones de blockchain puede ser compleja (necesita rondas off-chain).

Citas: La comparación anterior se basa en fuentes como el análisis de Sanders Network y otros, que destacan que los TEEs sobresalen en velocidad y facilidad de uso, mientras que ZK y FHE se centran en la máxima falta de confianza a costa de un cómputo pesado, y MPC distribuye la confianza pero introduce una sobrecarga de red.

De la tabla, algunos compromisos clave se vuelven claros:

  • Rendimiento: Los TEEs tienen una gran ventaja en velocidad bruta y baja latencia. El MPC a menudo puede manejar una complejidad moderada con cierta ralentización, ZK es lento para producir pero rápido para verificar (uso asíncrono), y FHE es actualmente el más lento con diferencia para tareas arbitrarias (aunque está bien para operaciones limitadas como sumas/multiplicaciones simples). Si tu aplicación necesita procesamiento complejo en tiempo real (como aplicaciones interactivas, decisiones de alta frecuencia), los TEEs o quizás el MPC (con pocas partes en buenas conexiones) son las únicas opciones viables hoy en día. ZK y FHE serían demasiado lentos en tales escenarios.

  • Modelo de Confianza: ZKP y FHE son puramente sin confianza (solo confían en las matemáticas). MPC traslada la confianza a supuestos sobre la honestidad de los participantes (que pueden reforzarse teniendo muchas partes o incentivos económicos). TEE deposita la confianza en el hardware y el proveedor. Esta es una diferencia fundamental: los TEEs introducen un tercero de confianza (el chip) en el mundo generalmente sin confianza de la blockchain. En contraste, ZK y FHE a menudo son elogiados por alinearse mejor con el ethos descentralizado: no hay entidades especiales en las que confiar, solo la dureza computacional. MPC se encuentra en el medio: la confianza está descentralizada pero no eliminada (si N de M nodos coluden, la privacidad se rompe). Así que para una máxima falta de confianza (por ejemplo, un sistema verdaderamente resistente a la censura y descentralizado), uno podría inclinarse hacia soluciones criptográficas. Por otro lado, muchos sistemas prácticos se sienten cómodos asumiendo que Intel es honesto o que un conjunto de validadores principales no coludirá, intercambiando un poco de confianza por enormes ganancias en eficiencia.

  • Seguridad/Vulnerabilidades: Los TEEs, como se discutió, pueden ser socavados por errores de hardware o canales laterales. La seguridad de ZK y FHE puede ser socavada si las matemáticas subyacentes (digamos, una curva elíptica o un problema de retículo) se rompen, pero esos son problemas bien estudiados y los ataques probablemente se notarían (además, las elecciones de parámetros pueden mitigar los riesgos conocidos). La seguridad de MPC puede ser rota por adversarios activos si el protocolo no está diseñado para eso (algunos protocolos de MPC asumen participantes "honestos pero curiosos" y podrían fallar si alguien hace trampa abiertamente). En el contexto de la blockchain, una brecha en un TEE podría ser más catastrófica (todos los contratos basados en enclaves podrían estar en riesgo hasta que se parcheen), mientras que una ruptura criptográfica de ZK (como descubrir un fallo en una función hash utilizada por un rollup ZK) también podría ser catastrófica, pero generalmente se considera menos probable dada la suposición más simple. La superficie de ataque es muy diferente: los TEEs tienen que preocuparse por cosas como el análisis de potencia, mientras que ZK tiene que preocuparse por los avances matemáticos.

  • Privacidad de Datos: FHE y ZK ofrecen las garantías de privacidad más fuertes: los datos permanecen protegidos criptográficamente. MPC asegura que los datos se comparten en secreto, por lo que ninguna parte los ve (aunque algo de información podría filtrarse si las salidas son públicas o si los protocolos no están diseñados cuidadosamente). TEE mantiene los datos privados del exterior, pero dentro del enclave los datos se descifran; si alguien de alguna manera obtiene el control del enclave, la confidencialidad de los datos se pierde. Además, los TEEs típicamente permiten que el código haga cualquier cosa con los datos (incluyendo filtrarlos inadvertidamente a través de canales laterales o la red si el código es malicioso). Por lo tanto, los TEEs requieren que también confíes en el código del enclave, no solo en el hardware. En contraste, las ZKPs prueban propiedades del código sin revelar nunca secretos, por lo que ni siquiera tienes que confiar en el código (más allá de que realmente tenga la propiedad probada). Si una aplicación de enclave tuviera un error que filtrara datos a un archivo de registro, el hardware del TEE no lo evitaría, mientras que un sistema de prueba ZK simplemente no revelaría nada excepto la prueba prevista. Este es un matiz: los TEEs protegen contra adversarios externos, pero no necesariamente contra errores lógicos en el propio programa del enclave, mientras que el diseño de ZK fuerza un enfoque más declarativo (pruebas exactamente lo que se pretende y nada más).

  • Composabilidad e Integración: Los TEEs se integran con bastante facilidad en los sistemas existentes: puedes tomar un programa existente, ponerlo en un enclave y obtener algunos beneficios de seguridad sin cambiar demasiado el modelo de programación. ZK y FHE a menudo requieren reescribir el programa en un circuito o forma restrictiva, lo que puede ser un esfuerzo masivo. Por ejemplo, escribir una verificación simple de un modelo de IA en ZK implica transformarlo en una serie de operaciones aritméticas y restricciones, lo que está muy lejos de simplemente ejecutar TensorFlow en un TEE y atestiguar el resultado. De manera similar, MPC puede requerir un protocolo personalizado por caso de uso. Así que desde el punto de vista de la productividad y el costo del desarrollador, los TEEs son atractivos. Hemos visto una adopción más rápida de los TEEs en algunas áreas precisamente porque se pueden aprovechar los ecosistemas de software existentes (muchas bibliotecas se ejecutan en enclaves con pequeños ajustes). ZK/MPC requieren talento de ingeniería especializado que es escaso. Sin embargo, la otra cara de la moneda es que los TEEs producen una solución que a menudo está más aislada (tienes que confiar en ese enclave o en ese conjunto de nodos), mientras que ZK te da una prueba que cualquiera puede verificar en la cadena, lo que la hace altamente componible (cualquier contrato puede verificar una prueba ZK). Así que los resultados de ZK son portátiles: producen una pequeña prueba que cualquier número de otros contratos o usuarios pueden usar para ganar confianza. Los resultados de TEE generalmente vienen en forma de una atestación vinculada a un hardware particular y posiblemente no sucinta; pueden no ser tan fácilmente compartibles o agnósticos a la cadena (aunque puedes publicar una firma del resultado y tener contratos programados para aceptarla si conocen la clave pública del enclave).

En la práctica, estamos viendo enfoques híbridos: por ejemplo, Sanders Network argumenta que TEE, MPC y ZK brillan cada uno en diferentes áreas y pueden complementarse entre sí. Un caso concreto es la identidad descentralizada: se podrían usar pruebas ZK para probar una credencial de identidad sin revelarla, pero esa credencial podría haber sido verificada y emitida por un proceso basado en TEE que verificó tus documentos de forma privada. O considera el escalado: los rollups ZK proporcionan pruebas sucintas para muchas transacciones, pero la generación de esas pruebas podría acelerarse utilizando TEEs para hacer algunos cálculos más rápido (y luego solo probar una afirmación más pequeña). La combinación a veces puede reducir el requisito de confianza en los TEEs (por ejemplo, usar TEEs para el rendimiento, pero aún así verificar la corrección final a través de una prueba ZK o mediante un juego de desafío en la cadena para que un TEE comprometido no pueda hacer trampa sin ser atrapado). Mientras tanto, el MPC se puede combinar con los TEEs haciendo que el nodo de cómputo de cada parte sea un TEE, añadiendo una capa extra para que incluso si algunas partes coluden, todavía no puedan ver los datos de los demás a menos que también rompan la seguridad del hardware.

En resumen, los TEEs ofrecen un camino muy práctico e inmediato hacia la computación segura con supuestos modestos (confianza en el hardware), mientras que ZK y FHE ofrecen un camino más teórico y sin confianza pero a un alto costo computacional, y MPC ofrece un camino de confianza distribuida con costos de red. La elección correcta en Web3 depende de los requisitos de la aplicación:

  • Si necesitas computación rápida y compleja sobre datos privados (como IA, grandes conjuntos de datos), los TEEs (o MPC con pocas partes) son actualmente la única forma factible.
  • Si necesitas máxima descentralización y verificabilidad, las pruebas ZK brillan (por ejemplo, las transacciones de criptomonedas privadas favorecen a ZKP como en Zcash, porque los usuarios no quieren confiar en nada más que en las matemáticas).
  • Si necesitas computación colaborativa entre múltiples partes interesadas, el MPC es naturalmente adecuado (como la gestión de claves multipartita o las subastas).
  • Si tienes datos extremadamente sensibles y la privacidad a largo plazo es una necesidad, el FHE podría ser atractivo si el rendimiento mejora, porque incluso si alguien obtuviera tus textos cifrados años después, sin la clave no aprenderían nada; mientras que un compromiso de enclave podría filtrar secretos retroactivamente si se guardaran registros.

Vale la pena señalar que el espacio de la blockchain está explorando activamente todas estas tecnologías en paralelo. Es probable que veamos combinaciones: por ejemplo, soluciones de Capa 2 que integran TEEs para secuenciar transacciones y luego usan un ZKP para probar que el TEE siguió las reglas (un concepto que se está explorando en algunas investigaciones de Ethereum), o redes MPC que usan TEEs en cada nodo para reducir la complejidad de los protocolos MPC (ya que cada nodo es internamente seguro y puede simular múltiples partes).

En última instancia, TEEs vs ZK vs MPC vs FHE no es una elección de suma cero: cada uno apunta a diferentes puntos en el triángulo de seguridad, rendimiento y falta de confianza. Como dijo un artículo, los cuatro enfrentan un "triángulo imposible" de rendimiento, costo y seguridad; ninguna solución única es superior en todos los aspectos. El diseño óptimo a menudo utiliza la herramienta adecuada para la parte correcta del problema.

6. Adopción en los Principales Ecosistemas de Blockchain

Los Entornos de Ejecución Confiables han visto niveles variables de adopción en diferentes ecosistemas de blockchain, a menudo influenciados por las prioridades de esas comunidades y la facilidad de integración. Aquí evaluamos cómo se están utilizando (o explorando) los TEEs en algunos de los principales ecosistemas: Ethereum, Cosmos y Polkadot, además de tocar otros.

Ethereum (y Capas 1 en General)

En la mainnet de Ethereum misma, los TEEs no son parte del protocolo central, pero se han utilizado en aplicaciones y Capas 2. La filosofía de Ethereum se inclina hacia la seguridad criptográfica (por ejemplo, los emergentes ZK-rollups), pero los TEEs han encontrado roles en oráculos y ejecución off-chain para Ethereum:

  • Servicios de Oráculo: Como se discutió, Chainlink ha incorporado soluciones basadas en TEE como Town Crier. Aunque no todos los nodos de Chainlink usan TEEs por defecto, la tecnología está ahí para fuentes de datos que requieren confianza extra. Además, API3 (otro proyecto de oráculo) ha mencionado el uso de Intel SGX para ejecutar APIs y firmar datos para garantizar la autenticidad. Estos servicios alimentan datos a los contratos de Ethereum con mayores garantías.

  • Capa 2 y Rollups: Hay una investigación y un debate en curso en la comunidad de Ethereum sobre el uso de TEEs en secuenciadores o validadores de rollups. Por ejemplo, el concepto de "ZK-Portal" de ConsenSys y otros han propuesto usar TEEs para hacer cumplir el ordenamiento correcto en rollups optimistas o para proteger al secuenciador de la censura. El artículo de Medium que vimos incluso sugiere que para 2025, los TEE podrían convertirse en una característica predeterminada en algunas L2 para cosas como la protección del trading de alta frecuencia. Proyectos como Catalyst (un DEX de trading de alta frecuencia) y Flashbots (para relés de MEV) han considerado los TEEs para hacer cumplir el ordenamiento justo de las transacciones antes de que lleguen a la blockchain.

  • Ethereum Empresarial: En redes de Ethereum de consorcio o permisionadas, los TEEs son más ampliamente adoptados. El Trusted Compute Framework (TCF) de la Enterprise Ethereum Alliance era básicamente un plan para integrar TEEs en los clientes de Ethereum. Hyperledger Avalon (anteriormente EEA TCF) permite que partes de los contratos inteligentes de Ethereum se ejecuten off-chain en un TEE y luego se verifiquen en la cadena. Varias empresas como IBM, Microsoft e iExec contribuyeron a esto. Aunque en el Ethereum público esto no se ha vuelto común, en despliegues privados (por ejemplo, un grupo de bancos usando Quorum o Besu), los TEEs pueden usarse para que incluso los miembros del consorcio no vean los datos de los demás, solo los resultados autorizados. Esto puede satisfacer los requisitos de privacidad en un entorno empresarial.

  • Proyectos Notables: Aparte de iExec que opera en Ethereum, hubo proyectos como Enigma (que originalmente comenzó como un proyecto de MPC en el MIT, luego pivotó para usar SGX; más tarde se convirtió en Secret Network en Cosmos). Otro fue Decentralized Cloud Services (DCS) en las primeras discusiones de Ethereum. Más recientemente, OAuth (Oasis Ethereum ParaTime) permite que los contratos de Solidity se ejecuten con confidencialidad utilizando el backend TEE de Oasis pero liquidando en Ethereum. Además, algunas dApps basadas en Ethereum como el intercambio de datos médicos o los juegos han experimentado con TEEs al tener un componente de enclave off-chain que interactúa con sus contratos.

Así que la adopción de Ethereum es algo indirecta: no ha cambiado el protocolo para requerir TEEs, pero tiene un rico conjunto de servicios y extensiones opcionales que aprovechan los TEEs para quienes los necesitan. Es importante destacar que los investigadores de Ethereum siguen siendo cautelosos: las propuestas para hacer una "shard solo de TEE" o para integrar profundamente los TEEs han encontrado escepticismo en la comunidad debido a preocupaciones de confianza. En cambio, los TEEs son vistos como "coprocesadores" para Ethereum en lugar de componentes centrales.

Ecosistema Cosmos

El ecosistema de Cosmos es amigable con la experimentación a través de su SDK modular y cadenas soberanas, y Secret Network (cubierto anteriormente) es un excelente ejemplo de la adopción de TEE en Cosmos. Secret Network es en realidad una cadena del SDK de Cosmos con consenso Tendermint, modificada para exigir SGX en sus validadores. Es una de las zonas de Cosmos más prominentes después del Cosmos Hub principal, lo que indica una adopción significativa de la tecnología TEE en esa comunidad. El éxito de Secret en proporcionar privacidad entre cadenas (a través de sus conexiones IBC, Secret puede servir como un centro de privacidad para otras cadenas de Cosmos) es un caso notable de integración de TEE en L1.

Otro proyecto relacionado con Cosmos es Oasis Network (aunque no está construido sobre el SDK de Cosmos, fue diseñado por algunas de las mismas personas que contribuyeron a Tendermint y comparte un ethos similar de arquitectura modular). Oasis es independiente pero puede conectarse a Cosmos a través de puentes, etc. Tanto Secret como Oasis muestran que en el mundo de Cosmos, la idea de "la privacidad como una característica" a través de TEEs ganó suficiente tracción como para justificar redes dedicadas.

Cosmos incluso tiene un concepto de "proveedores de privacidad" para aplicaciones entre cadenas; por ejemplo, una aplicación en una cadena puede llamar a un contrato en Secret Network a través de IBC para realizar un cálculo confidencial y luego recibir el resultado. Esta composabilidad está surgiendo ahora.

Además, el proyecto Anoma (no estrictamente de Cosmos, pero relacionado en el sentido de la interoperabilidad) ha hablado de usar TEEs para arquitecturas centradas en la intención, aunque es más teórico.

En resumen, Cosmos tiene al menos una cadena principal que abraza completamente los TEEs (Secret) y otras que interactúan con ella, lo que ilustra una adopción saludable en esa esfera. La modularidad de Cosmos podría permitir más cadenas de este tipo (por ejemplo, uno podría imaginar una zona de Cosmos especializada en oráculos o identidad basados en TEE).

Polkadot y Substrate

El diseño de Polkadot permite que las parachains se especialicen, y de hecho Polkadot alberga múltiples parachains que utilizan TEEs:

  • Sanders Network: Ya descrito; una parachain que ofrece una nube de cómputo basada en TEE. Sanders ha estado en vivo como parachain, proporcionando servicios a otras cadenas a través de XCMP (paso de mensajes entre cadenas). Por ejemplo, otro proyecto de Polkadot puede descargar una tarea confidencial a los trabajadores de Sanders y recibir una prueba o un resultado de vuelta. La economía de tokens nativa de Sanders incentiva la ejecución de nodos TEE, y tiene una comunidad considerable, lo que indica una fuerte adopción.
  • Integritee: Otra parachain que se centra en soluciones empresariales y de privacidad de datos utilizando TEEs. Integritee permite a los equipos desplegar sus propias side-chains privadas (llamadas Teewasms) donde la ejecución se realiza en enclaves. Se dirige a casos de uso como el procesamiento de datos confidenciales para corporaciones que aún desean anclarse a la seguridad de Polkadot.
  • /Root o Crust?: Hubo ideas sobre el uso de TEEs para almacenamiento descentralizado o balizas aleatorias en algunos proyectos relacionados con Polkadot. Por ejemplo, Crust Network (almacenamiento descentralizado) originalmente planeó una prueba de almacenamiento basada en TEE (aunque luego se movió a otro diseño). Y la parachain aleatoria de Polkadot (Entropy) consideró TEEs vs VRFs.

La dependencia de Polkadot de la gobernanza y las actualizaciones en la cadena significa que las parachains pueden incorporar nueva tecnología rápidamente. Tanto Sanders como Integritee han pasado por actualizaciones para mejorar su integración de TEE (como admitir nuevas características de SGX o refinar los métodos de atestación). La Web3 Foundation también financió esfuerzos anteriores en proyectos TEE basados en Substrate como SubstraTEE (un prototipo temprano que mostraba la ejecución de contratos off-chain en TEEs con verificación en la cadena).

El ecosistema de Polkadot muestra así múltiples equipos independientes apostando por la tecnología TEE, lo que indica una tendencia de adopción positiva. Se está convirtiendo en un punto de venta para Polkadot que "si necesitas contratos inteligentes confidenciales o cómputo off-chain, tenemos parachains para eso".

Otros Ecosistemas y Adopción General

  • Empresas y Consorcios: Fuera de la cripto pública, Hyperledger y las cadenas empresariales han adoptado constantemente los TEEs para entornos permisionados. Por ejemplo, el Comité de Basilea probó una blockchain de finanzas comerciales basada en TEE. El patrón general es: donde la privacidad o la confidencialidad de los datos es una necesidad, y los participantes son conocidos (por lo que incluso podrían invertir colectivamente en módulos de seguridad de hardware), los TEEs encuentran un hogar cómodo. Puede que no aparezcan en las noticias de cripto, pero en sectores como la cadena de suministro, los consorcios bancarios o las redes de intercambio de datos de salud, los TEEs son a menudo la opción preferida (como alternativa a simplemente confiar en un tercero o usar criptografía pesada).

  • Capas 1 fuera de Ethereum: Algunas L1 más nuevas han incursionado con TEEs. NEAR Protocol tuvo un concepto temprano de una shard basada en TEE para contratos privados (aún no implementado). Celo consideró los TEEs para pruebas de clientes ligeros (sus pruebas Plumo ahora se basan en snarks, pero en un momento consideraron SGX para comprimir datos de la cadena para móviles). Concordium, una L1 de privacidad regulada, utiliza ZK para el anonimato pero también explora TEEs para la verificación de identidad. Dfinity/Internet Computer utiliza enclaves seguros en sus máquinas de nodos, pero para el arranque de la confianza (no para la ejecución de contratos, ya que su criptografía "Chain Key" se encarga de eso).

  • Bitcoin: Aunque Bitcoin en sí no utiliza TEEs, ha habido proyectos paralelos. Por ejemplo, soluciones de custodia basadas en TEE (como sistemas de Bóveda) para claves de Bitcoin, o ciertas propuestas en DLC (Contratos de Registro Discreto) para usar oráculos que podrían estar asegurados por TEE. Generalmente, la comunidad de Bitcoin es más conservadora y no confiaría fácilmente en Intel como parte del consenso, pero como tecnología auxiliar (billeteras de hardware con elementos seguros) ya está aceptada.

  • Reguladores y Gobiernos: Una faceta interesante de la adopción: algunas investigaciones sobre CBDC (moneda digital de banco central) han considerado los TEEs para hacer cumplir la privacidad mientras permiten la auditabilidad. Por ejemplo, el Banco de Francia realizó experimentos en los que utilizaron un TEE para manejar ciertas verificaciones de cumplimiento en transacciones que de otro modo serían privadas. Esto muestra que incluso los reguladores ven los TEEs como una forma de equilibrar la privacidad con la supervisión: podrías tener una CBDC donde las transacciones están cifradas para el público pero un enclave regulador puede revisarlas bajo ciertas condiciones (esto es hipotético, pero se discute en círculos de políticas).

  • Métricas de Adopción: Es difícil cuantificar la adopción, pero podemos observar indicadores como: número de proyectos, fondos invertidos, disponibilidad de infraestructura. En ese frente, hoy (2025) tenemos: al menos 3-4 cadenas públicas (Secret, Oasis, Sanders, Integritee, Automata como off-chain) que utilizan explícitamente TEEs; las principales redes de oráculos lo incorporan; grandes empresas tecnológicas respaldan la computación confidencial (Microsoft Azure, Google Cloud ofrecen VMs TEE, y estos servicios están siendo utilizados por nodos de blockchain como opciones). El Confidential Computing Consortium ahora incluye miembros centrados en blockchain (Ethereum Foundation, Chainlink, Fortanix, etc.), lo que muestra una colaboración interindustrial. Todo esto apunta a una adopción creciente pero de nicho: los TEEs aún no son ubicuos en Web3, pero han encontrado nichos importantes donde se requiere privacidad y cómputo seguro off-chain.

7. Consideraciones Empresariales y Regulatorias

El uso de TEEs en aplicaciones de blockchain plantea varios puntos empresariales y regulatorios que las partes interesadas deben considerar:

Cumplimiento de la Privacidad y Adopción Institucional

Uno de los impulsores empresariales para la adopción de TEE es la necesidad de cumplir con las regulaciones de privacidad de datos (como GDPR en Europa, HIPAA en los EE. UU. para datos de salud) mientras se aprovecha la tecnología blockchain. Las blockchains públicas por defecto transmiten datos a nivel mundial, lo que entra en conflicto con las regulaciones que requieren que los datos personales sensibles estén protegidos. Los TEEs ofrecen una forma de mantener los datos confidenciales en la cadena y solo compartirlos de manera controlada, permitiendo así el cumplimiento. Como se señaló, "los TEEs facilitan el cumplimiento de las regulaciones de privacidad de datos al aislar los datos sensibles del usuario y garantizar que se manejen de forma segura". Esta capacidad es crucial para atraer a empresas e instituciones a Web3, ya que no pueden arriesgarse a violar las leyes. Por ejemplo, una dApp de atención médica que procesa información de pacientes podría usar TEEs para garantizar que ningún dato bruto de pacientes se filtre en la cadena, satisfaciendo los requisitos de HIPAA de cifrado y control de acceso. De manera similar, un banco europeo podría usar una cadena basada en TEE para tokenizar y comerciar activos sin exponer los detalles personales de los clientes, alineándose con el GDPR.

Esto tiene un ángulo regulatorio positivo: algunos reguladores han indicado que soluciones como los TEEs (y conceptos relacionados de computación confidencial) son favorables porque proporcionan una aplicación técnica de la privacidad. Hemos visto al Foro Económico Mundial y a otros destacar los TEEs como un medio para construir "privacidad por diseño" en los sistemas de blockchain (esencialmente incorporando el cumplimiento a nivel de protocolo). Por lo tanto, desde una perspectiva empresarial, los TEEs pueden acelerar la adopción institucional al eliminar uno de los bloqueadores clave (la confidencialidad de los datos). Las empresas están más dispuestas a usar o construir sobre blockchain si saben que hay una salvaguarda de hardware para sus datos.

Otro aspecto del cumplimiento es la auditabilidad y la supervisión. Las empresas a menudo necesitan registros de auditoría y la capacidad de demostrar a los auditores que tienen el control de los datos. Los TEEs pueden ayudar aquí al producir informes de atestación y registros seguros de lo que se accedió. Por ejemplo, el "registro duradero" de Oasis en un enclave proporciona un registro resistente a la manipulación de operaciones sensibles. Una empresa puede mostrar ese registro a los reguladores para demostrar que, por ejemplo, solo se ejecutó código autorizado y solo se realizaron ciertas consultas sobre los datos de los clientes. Este tipo de auditoría atestiguada podría satisfacer a los reguladores más que un sistema tradicional donde se confía en los registros del administrador del sistema.

Confianza y Responsabilidad

Por otro lado, la introducción de TEEs cambia la estructura de confianza y, por lo tanto, el modelo de responsabilidad en las soluciones de blockchain. Si una plataforma DeFi utiliza un TEE y algo sale mal debido a un fallo de hardware, ¿quién es responsable? Por ejemplo, considera un escenario en el que un error de Intel SGX conduce a una fuga de detalles de transacciones de intercambio secretas, lo que hace que los usuarios pierdan dinero (front-running, etc.). Los usuarios confiaron en las afirmaciones de seguridad de la plataforma. ¿Es culpa de la plataforma o de Intel? Legalmente, los usuarios podrían ir tras la plataforma (quien a su vez podría tener que ir tras Intel). Esto complica las cosas porque tienes un proveedor de tecnología de terceros (el proveedor de la CPU) profundamente involucrado en el modelo de seguridad. Las empresas que utilizan TEEs deben considerar esto en los contratos y las evaluaciones de riesgos. Algunas podrían buscar garantías o soporte de los proveedores de hardware si utilizan sus TEEs en infraestructura crítica.

También está la preocupación por la centralización: si la seguridad de una blockchain depende del hardware de una sola empresa (Intel o AMD), los reguladores podrían verlo con escepticismo. Por ejemplo, ¿podría un gobierno citar o coaccionar a esa empresa para comprometer ciertos enclaves? Esta no es una preocupación puramente teórica; considera las leyes de control de exportaciones: el hardware de cifrado de alto grado puede estar sujeto a regulación. Si una gran parte de la infraestructura cripto depende de los TEEs, es concebible que los gobiernos puedan intentar insertar puertas traseras (aunque no hay evidencia de ello, la percepción importa). Algunos defensores de la privacidad señalan esto a los reguladores: que los TEEs concentran la confianza y, en todo caso, los reguladores deberían examinarlos cuidadosamente. Por el contrario, los reguladores que desean más control podrían preferir los TEEs sobre la privacidad basada en matemáticas como ZK, porque con los TEEs hay al menos una noción de que las fuerzas del orden podrían acercarse al proveedor de hardware con una orden judicial si fuera absolutamente necesario (por ejemplo, para obtener una clave de atestación maestra o algo así, no es que sea fácil o probable, pero es una vía que no existe con ZK). Así que la recepción regulatoria puede dividirse: los reguladores de privacidad (agencias de protección de datos) están a favor de los TEE para el cumplimiento, mientras que las fuerzas del orden podrían ser cautelosamente optimistas ya que los TEEs no están "a oscuras" de la misma manera que el cifrado fuerte; hay una palanca teórica (el hardware) que podrían intentar usar.

Las empresas necesitan navegar esto posiblemente participando en certificaciones. Existen certificaciones de seguridad como FIPS 140 o Common Criteria para módulos de hardware. Actualmente, SGX y otros tienen algunas certificaciones (por ejemplo, SGX tuvo certificación Common Criteria EAL para ciertos usos). Si una plataforma de blockchain puede señalar que la tecnología del enclave está certificada con un alto estándar, los reguladores y socios podrían sentirse más cómodos. Por ejemplo, un proyecto de CBDC podría requerir que cualquier TEE utilizado esté certificado por FIPS para confiar en su generación de números aleatorios, etc. Esto introduce un proceso adicional y posiblemente restringe a ciertas versiones de hardware.

Consideraciones de Ecosistema y Costo

Desde una perspectiva empresarial, el uso de TEEs podría afectar la estructura de costos de una operación de blockchain. Los nodos deben tener CPUs específicas (que podrían ser más caras o menos eficientes energéticamente). Esto podría significar facturas de alojamiento en la nube más altas o gastos de capital. Por ejemplo, si un proyecto exige Intel Xeon con SGX para todos los validadores, eso es una restricción: los validadores no pueden ser cualquiera con una Raspberry Pi o una computadora portátil vieja; necesitan ese hardware. Esto puede centralizar quién puede participar (posiblemente favoreciendo a aquellos que pueden permitirse servidores de alta gama o que utilizan proveedores de la nube que ofrecen VMs SGX). En casos extremos, podría empujar a la red a ser más permisionada o a depender de proveedores de la nube, lo cual es un compromiso de descentralización y un compromiso empresarial (la red podría tener que subsidiar a los proveedores de nodos).

Por otro lado, algunas empresas podrían encontrar esto aceptable porque quieren validadores conocidos o tienen una lista blanca (especialmente en consorcios empresariales). Pero en las redes cripto públicas, esto ha causado debates; por ejemplo, cuando se requería SGX, la gente preguntaba "¿significa esto que solo los grandes centros de datos ejecutarán nodos?". Es algo que afecta el sentimiento de la comunidad y, por lo tanto, la adopción del mercado. Por ejemplo, algunos puristas de las criptomonedas podrían evitar una cadena que requiere TEEs, etiquetándola como "menos sin confianza" o demasiado centralizada. Por lo tanto, los proyectos tienen que manejar las relaciones públicas y la educación de la comunidad, dejando claro cuáles son los supuestos de confianza y por qué sigue siendo seguro. Vimos a Secret Network abordar el FUD explicando el riguroso monitoreo de las actualizaciones de Intel y que los validadores son penalizados si no actualizan los enclaves, etc., creando básicamente una capa social de confianza sobre la confianza en el hardware.

Otra consideración son las asociaciones y el soporte. El ecosistema empresarial en torno a los TEEs incluye grandes empresas tecnológicas (Intel, AMD, ARM, Microsoft, Google, etc.). Los proyectos de blockchain que utilizan TEEs a menudo se asocian con estas (por ejemplo, iExec asociándose con Intel, Secret Network trabajando con Intel en mejoras de atestación, Oasis con Microsoft en IA confidencial, etc.). Estas asociaciones pueden proporcionar financiación, asistencia técnica y credibilidad. Es un punto estratégico: alinearse con la industria de la computación confidencial puede abrir puertas (para financiación o pilotos empresariales), pero también significa que un proyecto cripto podría alinearse con grandes corporaciones, lo que tiene implicaciones ideológicas en la comunidad.

Incertidumbres Regulatorias

A medida que crecen las aplicaciones de blockchain que utilizan TEEs, pueden surgir nuevas preguntas regulatorias. Por ejemplo:

  • Jurisdicción de Datos: Si los datos se procesan dentro de un TEE en un país determinado, ¿se considera que se "procesan en ese país" o en ninguna parte (ya que están cifrados)? Algunas leyes de privacidad requieren que los datos de los ciudadanos no salgan de ciertas regiones. Los TEEs podrían difuminar las líneas: podrías tener un enclave en una región de la nube, pero solo entran/salen datos cifrados. Es posible que los reguladores necesiten aclarar cómo ven dicho procesamiento.
  • Controles de Exportación: La tecnología de cifrado avanzada puede estar sujeta a restricciones de exportación. Los TEEs implican el cifrado de la memoria; históricamente esto no ha sido un problema (ya que las CPUs con estas características se venden a nivel mundial), pero si eso cambiara, podría afectar el suministro. Además, algunos países podrían prohibir o desalentar el uso de TEEs extranjeros debido a la seguridad nacional (por ejemplo, China tiene su propio equivalente a SGX, ya que no confían en el de Intel, y podrían no permitir SGX para usos sensibles).
  • Compulsión Legal: Un escenario: ¿podría un gobierno citar a un operador de nodo para extraer datos de un enclave? Normalmente no pueden porque incluso el operador no puede ver dentro. Pero, ¿y si citan a Intel por una clave de atestación específica? El diseño de Intel es tal que ni siquiera ellos pueden descifrar la memoria del enclave (emiten claves a la CPU que hace el trabajo). Pero si existiera una puerta trasera o un firmware especial pudiera ser firmado por Intel para volcar la memoria, esa es una hipótesis que preocupa a la gente. Legalmente, una empresa como Intel podría negarse si se le pidiera socavar su seguridad (probablemente lo harían, para no destruir la confianza en su producto). Pero la mera posibilidad podría aparecer en las discusiones regulatorias sobre el acceso legal. Las empresas que utilizan TEEs deben mantenerse al tanto de cualquier desarrollo de este tipo, aunque actualmente no existe un mecanismo público para que Intel/AMD extraigan datos de enclaves; ese es el punto de los TEEs.

Diferenciación de Mercado y Nuevos Servicios

En el lado positivo para los negocios, los TEEs permiten nuevos productos y servicios que pueden ser monetizados. Por ejemplo:

  • Mercados de datos confidenciales: Como han señalado iExec, Ocean Protocol y otros, las empresas tienen datos valiosos que podrían monetizar si tuvieran garantías de que no se filtrarán. Los TEEs permiten el "alquiler de datos" donde los datos nunca salen del enclave, solo las ideas lo hacen. Esto podría desbloquear nuevas fuentes de ingresos y modelos de negocio. Vemos startups en Web3 que ofrecen servicios de computación confidencial a empresas, esencialmente vendiendo la idea de "obtener ideas de la blockchain o de datos entre empresas sin exponer nada".
  • DeFi Empresarial: Las instituciones financieras a menudo citan la falta de privacidad como una razón para no participar en DeFi o en la blockchain pública. Si los TEEs pueden garantizar la privacidad de sus posiciones o transacciones, podrían participar, trayendo más liquidez y negocio al ecosistema. Los proyectos que atienden a esto (como los préstamos secretos de Secret, o el AMM privado de Oasis con controles de cumplimiento) se están posicionando para atraer a usuarios institucionales. Si tienen éxito, eso puede ser un mercado significativo (imagina pools de AMM institucionales donde las identidades y los montos están protegidos pero un enclave asegura que las verificaciones de cumplimiento como AML se realizan internamente; ese es un producto que podría traer mucho dinero a DeFi con comodidad regulatoria).
  • Seguros y Gestión de Riesgos: Con los TEEs reduciendo ciertos riesgos (como la manipulación de oráculos), podríamos ver primas de seguro más bajas o nuevos productos de seguro para plataformas de contratos inteligentes. Por el contrario, los TEEs introducen nuevos riesgos (como el fallo técnico de los enclaves) que podrían ser eventos asegurables. Hay un área incipiente de seguros cripto; cómo tratan los sistemas dependientes de TEE será interesante. Una plataforma podría comercializar que utiliza TEEs para reducir el riesgo de violación de datos, lo que la haría más fácil/barata de asegurar, dándole una ventaja competitiva.

En conclusión, el panorama empresarial y regulatorio de Web3 habilitado por TEE se trata de equilibrar la confianza y la innovación. Los TEEs ofrecen una ruta para cumplir con las leyes y desbloquear casos de uso empresariales (una gran ventaja para la adopción generalizada), pero también traen una dependencia de los proveedores de hardware y complejidades que deben gestionarse de forma transparente. Las partes interesadas deben interactuar tanto con los gigantes tecnológicos (para obtener soporte) como con los reguladores (para obtener claridad y seguridad) para realizar plenamente el potencial de los TEEs en la blockchain. Si se hace bien, los TEEs podrían ser una piedra angular que permita a la blockchain integrarse profundamente con industrias que manejan datos sensibles, expandiendo así el alcance de Web3 a áreas previamente fuera de los límites debido a preocupaciones de privacidad.

Conclusión

Los Entornos de Ejecución Confiables han surgido como un componente poderoso en la caja de herramientas de Web3, permitiendo una nueva clase de aplicaciones descentralizadas que requieren confidencialidad y computación segura off-chain. Hemos visto que los TEEs, como Intel SGX, ARM TrustZone y AMD SEV, proporcionan una "caja fuerte" aislada por hardware para la computación, y esta propiedad ha sido aprovechada para contratos inteligentes que preservan la privacidad, oráculos verificables, procesamiento escalable off-chain y más. Proyectos en todos los ecosistemas, desde los contratos privados de Secret Network en Cosmos, hasta los ParaTimes confidenciales de Oasis, la nube TEE de Sanders en Polkadot y el mercado off-chain de iExec en Ethereum, demuestran las diversas formas en que los TEEs se están integrando en las plataformas de blockchain.

Técnicamente, los TEEs ofrecen beneficios convincentes de velocidad y fuerte confidencialidad de datos, pero vienen con sus propios desafíos: la necesidad de confiar en los proveedores de hardware, posibles vulnerabilidades de canal lateral y obstáculos en la integración y la composabilidad. Comparamos los TEEs con alternativas criptográficas (ZKPs, FHE, MPC) y encontramos que cada uno tiene su nicho: los TEEs brillan en rendimiento y facilidad de uso, mientras que ZK y FHE proporcionan la máxima falta de confianza a un alto costo, y MPC distribuye la confianza entre los participantes. De hecho, muchas soluciones de vanguardia son híbridas, utilizando TEEs junto con métodos criptográficos para obtener lo mejor de ambos mundos.

La adopción de soluciones basadas en TEE está creciendo constantemente. Las dApps de Ethereum aprovechan los TEEs para la seguridad de los oráculos y los cálculos privados, Cosmos y Polkadot tienen soporte nativo a través de cadenas especializadas, y los esfuerzos de blockchain empresarial están adoptando los TEEs para el cumplimiento. Desde el punto de vista empresarial, los TEEs pueden ser un puente entre la tecnología descentralizada y la regulación, permitiendo que los datos sensibles se manejen en la cadena bajo las salvaguardas de la seguridad del hardware, lo que abre la puerta al uso institucional y a nuevos servicios. Al mismo tiempo, usar TEEs significa comprometerse con nuevos paradigmas de confianza y garantizar que el ethos de descentralización de la blockchain no se vea socavado por un silicio opaco.

En resumen, los Entornos de Ejecución Confiables están desempeñando un papel crucial en la evolución de Web3: abordan algunas de las preocupaciones más apremiantes de privacidad y escalabilidad, y aunque no son una panacea (y no están exentos de controversia), expanden significativamente lo que las aplicaciones descentralizadas pueden hacer. A medida que la tecnología madura, con mejoras en la seguridad del hardware y estándares para la atestación, y a medida que más proyectos demuestran su valor, podemos esperar que los TEEs (junto con la tecnología criptográfica complementaria) se conviertan en un componente estándar de las arquitecturas de blockchain destinadas a desbloquear todo el potencial de Web3 de una manera segura y confiable. El futuro probablemente depara soluciones en capas donde el hardware y la criptografía trabajen de la mano para ofrecer sistemas que sean tanto performantes como demostrablemente seguros, satisfaciendo las necesidades de usuarios, desarrolladores y reguladores por igual.

Fuentes: La información de este informe se recopiló de una variedad de fuentes actualizadas, incluyendo documentación y blogs oficiales de proyectos, análisis de la industria e investigación académica, como se cita a lo largo del texto. Las referencias notables incluyen la guía de Metaschool 2025 sobre TEEs en Web3, comparaciones de Sanders Network, conocimientos técnicos de ChainCatcher y otros sobre FHE/TEE/ZKP/MPC, y declaraciones sobre cumplimiento regulatorio de Binance Research, entre muchos otros. Estas fuentes proporcionan más detalles y se recomiendan para los lectores que deseen explorar aspectos específicos con mayor profundidad.

Soneium de Sony: Llevando la Blockchain al Mundo del Entretenimiento

· 6 min de lectura

En el panorama rápidamente evolutivo de la tecnología blockchain, un nombre familiar ha entrado en la arena con una visión audaz. Sony, el gigante del entretenimiento y la tecnología, ha lanzado Soneium — una blockchain Layer-2 de Ethereum diseñada para cerrar la brecha entre las innovaciones Web3 de vanguardia y los servicios de internet convencionales. Pero, ¿qué es exactamente Soneium y por qué debería importarte? Vamos a profundizar.

¿Qué es Soneium?

Soneium es una blockchain Layer-2 construida sobre Ethereum, desarrollada por Sony Block Solutions Labs — una empresa conjunta entre Sony Group y Startale Labs. Lanzada en enero de 2025 después de una fase de testnet exitosa, Soneium pretende “realizar el internet abierto que trasciende fronteras” al hacer que la tecnología blockchain sea accesible, escalable y práctica para el uso diario.

Piénsalo como el intento de Sony de hacer que la blockchain sea tan fácil de usar como sus PlayStation y Walkman lo fueron para los videojuegos y la música.

La Tecnología Detrás de Soneium

Para los curiosos de la tecnología, Soneium está construida sobre Optimism OP Stack, lo que significa que utiliza el mismo marco de rollup optimista que otras soluciones Layer-2 populares. En palabras sencillas, procesa transacciones fuera de la cadena y solo publica periódicamente datos comprimidos de vuelta a Ethereum, haciendo que las transacciones sean más rápidas y baratas mientras mantiene la seguridad.

Soneium es totalmente compatible con la Ethereum Virtual Machine (EVM), por lo que los desarrolladores familiarizados con Ethereum pueden desplegar sus aplicaciones fácilmente en la plataforma. También se une al ecosistema “Superchain” de Optimism, lo que le permite comunicarse sin problemas con otras redes Layer-2 como Base de Coinbase.

¿Qué Hace Especial a Soneium?

Aunque ya existen varias soluciones Layer-2 en el mercado, Soneium destaca por su enfoque en entretenimiento, contenido creativo y compromiso de fans, áreas donde Sony tiene décadas de experiencia y vastos recursos.

Imagina comprar una entrada de cine y recibir un coleccionable digital exclusivo que otorga acceso a contenido adicional. O asistir a un concierto virtual donde tu entrada NFT se convierte en un recuerdo con beneficios especiales. Ese es el tipo de experiencias que Sony visualiza construir sobre Soneium.

La plataforma está diseñada para soportar:

  • Experiencias de juegos con transacciones más rápidas para activos dentro del juego
  • Mercados de NFT para coleccionables digitales
  • Aplicaciones de compromiso de fans donde las comunidades pueden interactuar con creadores
  • Herramientas financieras para creadores y fans
  • Soluciones blockchain empresariales

Las Asociaciones de Sony Impulsan Soneium

Sony no lo hace sola. La compañía ha forjado alianzas estratégicas para reforzar el desarrollo y la adopción de Soneium:

  • Startale Labs, una startup de blockchain con sede en Singapur liderada por Sota Watanabe (cofundador de Astar Network), es el socio técnico clave de Sony
  • Optimism Foundation aporta la tecnología subyacente
  • Circle garantiza que USD Coin (USDC) sirva como moneda principal en la red
  • Samsung ha realizado una inversión estratégica a través de su brazo de capital de riesgo
  • Alchemy, Chainlink, Pyth Network y The Graph proporcionan servicios de infraestructura esenciales

Sony también está aprovechando sus divisiones internas —incluyendo Sony Pictures, Sony Music Entertainment y Sony Music Publishing— para pilotar proyectos de compromiso de fans Web3 en Soneium. Por ejemplo, la plataforma ya ha alojado campañas NFT para la franquicia “Ghost in the Shell” y varios artistas musicales bajo el sello de Sony.

Señales Tempranas de Éxito

A pesar de tener solo unos meses, Soneium ha mostrado una tracción prometedora:

  • Su fase de testnet registró más de 15 millones de billeteras activas y procesó más de 47 millones de transacciones
  • En el primer mes del lanzamiento de mainnet, Soneium atrajo más de 248 000 cuentas on‑chain y alrededor de 1,8 millones de direcciones interactuando con la red
  • La plataforma ha lanzado con éxito varios drops de NFT, incluida una colaboración con el sello musical Web3 Coop Records

Para impulsar el crecimiento, Sony y Astar Network lanzaron una campaña de incentivos de 100 días con un fondo de recompensas de 100 millones de tokens, animando a los usuarios a probar apps, aportar liquidez y ser activos en la plataforma.

Seguridad y Escalabilidad: Un Acto de Equilibrio

La seguridad es fundamental para Sony, especialmente al trasladar su marca de confianza al espacio blockchain. Soneium hereda la seguridad de Ethereum mientras añade sus propias medidas protectoras.

Curiosamente, Sony ha adoptado un enfoque algo controvertido al incluir en una lista negra ciertos contratos inteligentes y tokens que considera infracciones de propiedad intelectual. Aunque esto ha generado preguntas sobre la descentralización, Sony argumenta que cierta curación es necesaria para proteger a los creadores y generar confianza entre los usuarios convencionales.

En cuanto a la escalabilidad, el propio propósito de Soneium es mejorar el rendimiento de Ethereum. Al procesar transacciones fuera de la cadena, puede manejar un volumen mucho mayor de operaciones a costos significativamente menores —crucial para la adopción masiva de aplicaciones como juegos o grandes drops de NFT.

El Camino por Delante

Sony ha delineado una hoja de ruta de varias fases para Soneium:

  1. Primer año: Incorporar a entusiastas Web3 y adoptadores tempranos
  2. En dos años: Integrar productos Sony como Sony Bank, Sony Music y Sony Pictures
  3. En tres años: Expandirse a empresas y aplicaciones generales más allá del ecosistema Sony

La compañía está desplegando gradualmente su Plataforma de Marketing de Fans impulsada por NFT, que permitirá a marcas y artistas emitir NFTs a sus fans, ofreciendo beneficios como contenido exclusivo y acceso a eventos.

Aunque Soneium actualmente depende de ETH para las tarifas de gas y utiliza ASTR (el token de Astar Network) para incentivos, se rumorea la posible creación de un token nativo de Soneium en el futuro.

Comparación de Soneium con Otras Redes Layer‑2

En el concurrido mercado de Layer‑2, Soneium compite con jugadores consolidados como Arbitrum, Optimism y Polygon. Sin embargo, Sony está ocupando una posición única al aprovechar su imperio de entretenimiento y centrarse en casos de uso creativos.

A diferencia de redes Layer‑2 puramente impulsadas por la comunidad, Soneium se beneficia de la confianza de marca de Sony, el acceso a propiedad intelectual de contenido y una base de usuarios potencialmente enorme proveniente de los servicios existentes de Sony.

El compromiso es menor descentralización (al menos inicialmente) comparado con redes como Optimism y Arbitrum, que ya han emitido tokens y implementado gobernanza comunitaria.

La Gran Imagen

Soneium de Sony representa un paso significativo hacia la adopción masiva de blockchain. Al enfocarse en contenido y compromiso de fans —áreas donde Sony sobresale— la compañía está posicionando a Soneium como un puente entre entusiastas Web3 y consumidores cotidianos.

Si Sony logra convertir incluso una fracción de sus millones de clientes en participantes de Web3, Soneium podría convertirse en una de las primeras plataformas blockchain verdaderamente mainstream.

El experimento apenas comienza, pero el potencial es enorme. A medida que las líneas entre entretenimiento, tecnología y blockchain continúan difuminándose, Soneium podría estar al frente de esta convergencia, llevando la tecnología blockchain a las masas, un avatar de juego o un NFT musical a la vez.

Escalando Blockchains: Cómo Caldera y la Revolución RaaS están dando forma al futuro de Web3

· 8 min de lectura

El problema de escalado de Web3

La industria de blockchain enfrenta un desafío persistente: ¿cómo escalar para soportar millones de usuarios sin sacrificar seguridad ni descentralización?

Ethereum, la principal plataforma de contratos inteligentes, procesa aproximadamente 15 transacciones por segundo en su capa base. Durante periodos de alta demanda, esta limitación ha generado tarifas de gas exorbitantes —a veces superiores a 100 USD por transacción durante minting de NFT o frenéticas rondas de farming en DeFi.

Este cuello de botella de escalado representa una amenaza existencial para la adopción de Web3. Los usuarios acostumbrados a la respuesta instantánea de las aplicaciones Web2 no tolerarán pagar 50 USD y esperar 3 minutos solo para intercambiar tokens o crear un NFT.

Entra la solución que está remodelando rápidamente la arquitectura de blockchain: Rollups-as-a-Service (RaaS).

Escalando Blockchains

Entendiendo Rollups-as-a-Service (RaaS)

Las plataformas RaaS permiten a los desarrolladores desplegar sus propios rollups personalizados sin la complejidad de construir todo desde cero. Estos servicios convierten lo que normalmente requeriría un equipo de ingeniería especializado y meses de desarrollo en un proceso simplificado, a veces con un solo clic.

¿Por qué importa? Porque los rollups son la clave para escalar blockchain.

Los rollups funcionan al:

  • Procesar transacciones fuera de la cadena principal (Capa 1)
  • Agrupar esas transacciones en lotes
  • Enviar pruebas comprimidas de esas transacciones de vuelta a la cadena principal

¿El resultado? Aumento drástico del rendimiento y reducción significativa de costos mientras se hereda la seguridad de la cadena de bloques subyacente (como Ethereum).

"Los rollups no compiten con Ethereum — los extienden. Son como carriles exprés especializados construidos sobre la autopista de Ethereum."

Este enfoque de escalado es tan prometedor que Ethereum adoptó oficialmente una "hoja de ruta centrada en rollups" en 2020, reconociendo que el futuro no será una única cadena monolítica, sino un ecosistema de rollups interconectados y diseñados para propósitos específicos.

Caldera: Liderando la revolución RaaS

Entre los proveedores emergentes de RaaS, Caldera destaca como pionero. Fundada en 2023 y con una recaudación de 25 M USD de inversores prominentes como Dragonfly, Sequoia Capital y Lattice, Caldera se ha posicionado rápidamente como un proveedor de infraestructura líder en el espacio de rollups.

¿Qué hace a Caldera diferente?

Caldera se diferencia en varios aspectos clave:

  1. Soporte multimarco: A diferencia de competidores que se centran en un solo marco de rollup, Caldera soporta los principales marcos como OP Stack de Optimism y la tecnología Orbit/Nitro de Arbitrum, ofreciendo a los desarrolladores flexibilidad en su enfoque técnico.

  2. Infraestructura de extremo a extremo: Cuando despliegas con Caldera, obtienes un conjunto completo de componentes: nodos RPC confiables, exploradores de bloques, servicios de indexación e interfaces de puentes.

  3. Ecosistema de integración rico: Caldera viene preintegrada con más de 40 herramientas y servicios Web3, incluidos oráculos, faucets, wallets y puentes cross‑chain (LayerZero, Axelar, Wormhole, Connext, entre otros).

  4. Red Metalayer: Tal vez la innovación más ambiciosa de Caldera sea su Metalayer, una red que conecta todos los rollups impulsados por Caldera en un ecosistema unificado, permitiendo compartir liquidez y mensajes sin fricciones.

  5. Soporte multivirtual machine: A finales de 2024, Caldera se convirtió en el primer RaaS en soportar la Solana Virtual Machine (SVM) sobre Ethereum, habilitando cadenas de alto rendimiento al estilo Solana que aún se asientan en la capa base segura de Ethereum.

El enfoque de Caldera está creando lo que llaman una "capa de todo" para rollups — una red cohesiva donde diferentes rollups pueden interoperar en lugar de existir como islas aisladas.

Adopción en el mundo real: ¿Quién está usando Caldera?

Caldera ha ganado una tracción significativa, con más de 75 rollups en producción a finales de 2024. Algunos proyectos destacados incluyen:

  • Manta Pacific: Una red altamente escalable para desplegar aplicaciones de conocimiento cero que utiliza el OP Stack de Caldera combinado con Celestia para disponibilidad de datos.

  • RARI Chain: El rollup enfocado en NFT de Rarible que procesa transacciones en menos de un segundo y aplica regalías de NFT a nivel de protocolo.

  • Kinto: Una plataforma DeFi regulatoriamente compliant con KYC/AML on‑chain y capacidades de abstracción de cuentas.

  • inEVM de Injective: Un rollup compatible con EVM que extiende la interoperabilidad de Injective, conectando el ecosistema Cosmos con dApps basadas en Ethereum.

Estos proyectos demuestran cómo los rollups específicos de aplicación permiten personalizaciones imposibles en las cadenas de capa 1 de propósito general. A finales de 2024, los rollups colectivos de Caldera habrían procesado más de 300 millones de transacciones para más de 6 millones de wallets únicas, con casi 1 mil millones de dólares en valor total bloqueado (TVL).

Comparativa RaaS: Caldera vs. Competidores

El panorama RaaS se vuelve cada vez más competitivo, con varios jugadores notables:

Conduit

  • Se enfoca exclusivamente en los ecosistemas de Optimism y Arbitrum
  • Prioriza una experiencia totalmente autoservicio y sin código
  • Alimenta aproximadamente el 20 % de los rollups de la mainnet de Ethereum, incluido Zora

AltLayer

  • Ofrece "Flashlayers" — rollups desechables y bajo demanda para necesidades temporales
  • Se centra en escalado elástico para eventos específicos o periodos de alto tráfico
  • Demostró un rendimiento impresionante durante eventos de gaming (más de 180 000 transacciones diarias)

Sovereign Labs

  • Construye un SDK de Rollup enfocado en tecnologías de conocimiento cero
  • Busca habilitar ZK‑rollups en cualquier cadena base, no solo en Ethereum
  • Aún en desarrollo, posicionándose para la próxima ola de despliegues ZK multichain

Si bien estos competidores sobresalen en nichos específicos, el enfoque integral de Caldera —que combina una red de rollups unificada, soporte multivirtual machine y una fuerte orientación a la experiencia del desarrollador— la ha consolidado como líder de mercado.

El futuro de RaaS y el escalado de blockchain

RaaS está preparado para remodelar el panorama de blockchain de maneras profundas:

1. Proliferación de cadenas específicas de aplicación

Investigaciones de la industria sugieren que nos dirigimos a un futuro con potencialmente millones de rollups, cada uno sirviendo a aplicaciones o comunidades concretas. Con RaaS reduciendo las barreras de despliegue, cada dApp importante podría contar con su propia cadena optimizada.

2. Interoperabilidad como desafío crítico

A medida que los rollups se multiplican, la capacidad de comunicarse y compartir valor entre ellos se vuelve crucial. El Metalayer de Caldera representa un intento temprano de resolver este reto —creando una experiencia unificada a través de una red de rollups.

3. De cadenas aisladas a ecosistemas interconectados

El objetivo final es una experiencia multichain fluida donde los usuarios apenas necesiten saber en qué cadena están. Valor y datos fluirían libremente a través de una telaraña interconectada de rollups especializados, todos asegurados por robustas redes de capa 1.

4. Infraestructura de blockchain al estilo cloud

RaaS está convirtiendo efectivamente la infraestructura de blockchain en un servicio tipo cloud. El "Rollup Engine" de Caldera permite actualizaciones dinámicas y componentes modulares, tratando a los rollups como servicios configurables en la nube que pueden escalar bajo demanda.

Qué significa esto para desarrolladores y BlockEden.xyz

En BlockEden.xyz vemos un enorme potencial en la revolución RaaS. Como proveedor de infraestructura que conecta a los desarrolladores con nodos de blockchain de forma segura, estamos posicionados para jugar un papel crucial en este paisaje en evolución.

La proliferación de rollups implica que los desarrolladores necesiten infraestructura de nodos confiable más que nunca. Un futuro con miles de cadenas específicas de aplicación demanda servicios RPC robustos y de alta disponibilidad —exactamente lo que BlockEden.xyz se especializa en ofrecer.

Nos entusiasman particularmente las oportunidades en:

  1. Servicios RPC especializados para rollups: A medida que los rollups adoptan características y optimizaciones únicas, la infraestructura especializada se vuelve esencial.

  2. Indexación de datos cross‑chain: Con valor fluyendo entre múltiples rollups, los desarrolladores requieren herramientas para rastrear y analizar actividades intercadena.

  3. Herramientas de desarrollo mejoradas: Conforme el despliegue de rollups se simplifica, crece la necesidad de herramientas sofisticadas de monitoreo, depuración y analítica.

  4. Acceso API unificado: Los desarrolladores que trabajan en varios rollups necesitan un acceso simplificado y unificado a diversas redes blockchain.

Conclusión: El futuro modular de blockchain

El auge de Rollups-as-a-Service representa un cambio fundamental en cómo pensamos el escalado de blockchain. En lugar de forzar a todas las aplicaciones a una única cadena, nos dirigimos a un futuro modular con cadenas especializadas para casos de uso concretos, todas interconectadas y aseguradas por redes de capa 1 robustas.

El enfoque de Caldera —creando una red unificada de rollups con liquidez compartida y mensajería fluida— ofrece una visión de ese futuro. Al hacer que el despliegue de rollups sea tan sencillo como lanzar un servidor en la nube, los proveedores RaaS están democratizando el acceso a la infraestructura blockchain.

En BlockEden.xyz, estamos comprometidos a apoyar esta evolución proporcionando la infraestructura de nodos confiable y las herramientas de desarrollo necesarias para construir en este futuro multichain. Como solemos decir, el futuro de Web3 no es una sola cadena — son miles de cadenas especializadas trabajando juntas.


¿Quieres construir sobre un rollup o necesitas infraestructura de nodos confiable para tu proyecto blockchain? Correo de contacto: info@BlockEden.xyz para descubrir cómo podemos apoyar tu desarrollo con nuestra garantía de 99,9 % de tiempo activo y servicios RPC especializados en más de 27 blockchains.