51 publicaciones etiquetados con "Blockchain"

¿Qué es un DAG y en qué se diferencia de una blockchain?​

Un gráfico acíclico dirigido (Directed Acyclic Graph, DAG) es un tipo de estructura de datos formada por vértices (nodos) conectados por aristas dirigidas que nunca forman un ciclo. En el contexto de los libros mayores distribuidos, un ledger basado en DAG organiza transacciones o eventos en una red tipo telaraña en lugar de en una cadena secuencial única. Esto significa que, a diferencia de una blockchain tradicional donde cada nuevo bloque referencia solo a un predecesor (formando una cadena lineal), un nodo en un DAG puede referenciar múltiples transacciones o bloques anteriores. Como resultado, muchas transacciones pueden confirmarse en paralelo, en vez de estrictamente una por una en bloques cronológicos.

Para ilustrar la diferencia, si una blockchain se parece a una larga cadena de bloques (cada bloque contiene muchas transacciones), un ledger basado en DAG se asemeja más a un árbol o red de transacciones individuales. Cada nueva transacción en un DAG puede anexarse a (y por tanto validar) una o más transacciones anteriores, en lugar de esperar a ser empaquetada en el siguiente bloque único. Esta diferencia estructural genera varias distinciones clave:

• Validación paralela: En las blockchains, los mineros/validadores añaden un bloque a la vez a la cadena, por lo que las transacciones se confirman en lotes por cada nuevo bloque. En los DAG, múltiples transacciones (o pequeños “bloques” de transacciones) pueden añadirse de forma concurrente, ya que cada una puede adjuntarse a diferentes partes del grafo. Esta paralelización implica que las redes DAG no tienen que esperar a que una cadena larga crezca bloque a bloque.
• Sin orden secuencial global: Una blockchain crea inherentemente un orden total de las transacciones (cada bloque ocupa un lugar definido en una única secuencia). Un ledger DAG, en cambio, forma un orden parcial de las transacciones. No existe un único “último bloque” en el que todas las transacciones hagan fila; en su lugar, muchos extremos del grafo pueden coexistir y ampliarse simultáneamente. Luego se necesitan protocolos de consenso para ordenar o acordar el orden o la validez de las transacciones en el DAG.
• Confirmación de transacciones: En una blockchain, las transacciones se confirman cuando se incluyen en un bloque minado/validado y ese bloque pasa a formar parte de la cadena aceptada (a menudo tras añadirse más bloques encima). En los sistemas DAG, una nueva transacción ayuda por sí misma a confirmar transacciones previas al referenciarlas. Por ejemplo, en el Tangle de IOTA (un DAG), cada transacción debe aprobar dos transacciones anteriores, logrando que los usuarios validen colaborativamente las transacciones de los demás. Esto elimina la división estricta entre “creadores de transacciones” y “validadores” que existe en la minería blockchain: cada participante que emite una transacción también realiza parte del trabajo de validación.

Es importante destacar que una blockchain es en realidad un caso especial de DAG: un DAG restringido a una sola cadena de bloques. Ambos son formas de tecnología de registro distribuido (DLT) y comparten objetivos como la inmutabilidad y la descentralización. Sin embargo, los ledgers basados en DAG son “sin bloques” o multiparentales en su estructura, lo que les da propiedades diferentes en la práctica. Las blockchains tradicionales como Bitcoin y Ethereum usan bloques secuenciales y suelen descartar los bloques competidores (forks), mientras que los ledgers DAG intentan incorporar y ordenar todas las transacciones sin descartar ninguna, siempre que no entren en conflicto. Esta diferencia fundamental sienta las bases de los contrastes de rendimiento y diseño detallados a continuación.

Comparación técnica: arquitectura DAG vs. blockchain​

Para entender mejor los DAG frente a las blockchains, podemos comparar sus arquitecturas y procesos de validación:

• Estructura de datos: Las blockchains almacenan datos en bloques enlazados en una secuencia lineal (cada bloque contiene muchas transacciones y apunta a un único bloque previo, formando una larga cadena). Los ledgers DAG usan una estructura de grafo: cada nodo del grafo representa una transacción o un bloque de eventos, y puede enlazarse a múltiples nodos anteriores. Este grafo dirigido no tiene ciclos, lo que significa que si sigues los enlaces “hacia atrás” nunca volverás a la transacción de la que partiste. La ausencia de ciclos permite un orden topológico de las transacciones (una forma de ordenarlas de modo que cada referencia aparezca después de la transacción referenciada). En resumen, blockchains = cadena unidimensional, DAG = grafo multidimensional.
• Rendimiento y concurrencia: Debido a las diferencias estructurales, las blockchains y los DAG manejan el rendimiento de manera distinta. Una blockchain, incluso en condiciones óptimas, añade bloques uno por uno (a menudo esperando a que cada bloque se valide y propague por toda la red antes de crear el siguiente). Esto limita inherentemente el rendimiento de transacciones: por ejemplo, Bitcoin promedia 5–7 transacciones por segundo (TPS) y Ethereum alrededor de 15–30 TPS bajo el diseño clásico de proof-of-work. Los sistemas basados en DAG, en cambio, permiten que muchas nuevas transacciones/bloques entren en el ledger simultáneamente. Múltiples ramas de transacciones pueden crecer a la vez y luego entrelazarse, incrementando drásticamente el rendimiento potencial. Algunas redes DAG modernas afirman alcanzar miles de TPS, acercándose o superando la capacidad de las redes de pago tradicionales.
• Proceso de validación de transacciones: En las redes blockchain, las transacciones esperan en el mempool y se validan cuando un minero o validador las empaqueta en un nuevo bloque, que luego es verificado por otros nodos frente al historial. En las redes DAG, la validación suele ser más continua y descentralizada: cada transacción nueva realiza una acción de validación al referenciar (aprobar) transacciones anteriores. Por ejemplo, cada transacción en el Tangle de IOTA debe confirmar dos transacciones previas comprobando su validez y ejecutando una pequeña prueba de trabajo, “votando” por esas transacciones. En el DAG block-lattice de Nano, las transacciones de cada cuenta forman su propia cadena y se validan mediante votos de nodos representantes (lo explicamos más adelante). El resultado neto es que los DAG distribuyen el trabajo de validación: en lugar de que un único productor de bloques valide un lote de transacciones, cada participante o muchos validadores validan distintas transacciones en paralelo.
• Mecanismo de consenso: Tanto las blockchains como los DAG necesitan un modo de que la red esté de acuerdo sobre el estado del ledger (qué transacciones están confirmadas y en qué orden). En las blockchains, el consenso suele provenir de la Prueba de Trabajo o la Prueba de Participación generando el siguiente bloque y la regla de “la cadena más larga (o más pesada) gana”. En los ledgers DAG, el consenso puede ser más complejo porque no existe una única cadena. Diferentes proyectos DAG usan distintos enfoques: algunos emplean protocolos gossip y votación virtual (como Hedera Hashgraph) para acordar el orden de las transacciones, otros usan selección de puntas con cadenas de Markov Monte Carlo (el enfoque inicial de IOTA) u otros esquemas de votación para decidir qué ramas del grafo se prefieren. Más adelante detallamos métodos de consenso específicos. En general, alcanzar un acuerdo en toda la red en un DAG puede ser más rápido en términos de rendimiento, pero requiere un diseño cuidadoso para manejar conflictos (como intentos de doble gasto), dado que múltiples transacciones pueden existir en paralelo antes de ordenarse definitivamente.
• Gestión de forks: En una blockchain, un “fork” (dos bloques minados casi al mismo tiempo) provoca que una rama termine ganando (la cadena más larga) y la otra sea huérfana (descartada), desperdiciando el trabajo realizado en el bloque huérfano. En un DAG, la filosofía es aceptar los forks como ramas adicionales del grafo en lugar de desaprovecharlos. El DAG incorpora ambos forks; el algoritmo de consenso determina qué transacciones se confirman (o cómo se resuelven las que entran en conflicto) sin desechar toda una rama. Esto significa que no se desperdicia energía de minado ni esfuerzo en bloques obsoletos, contribuyendo a la eficiencia. Por ejemplo, el Tree-Graph de Conflux (un DAG de PoW) intenta incluir todos los bloques en el ledger y ordenarlos, en lugar de huérfanar alguno, utilizando así el 100% de los bloques producidos.

En resumen, las blockchains ofrecen una estructura más simple y estrictamente ordenada donde la validación es bloque a bloque, mientras que los DAG proporcionan una estructura de grafo más compleja que permite un procesamiento asíncrono y paralelo de las transacciones. Los ledgers basados en DAG deben emplear lógica de consenso adicional para gestionar esta complejidad, pero prometen una mayor capacidad y eficiencia al utilizar todo el potencial de la red en lugar de obligarla a avanzar en fila india bloque a bloque.

Beneficios de los sistemas blockchain basados en DAG​

Las arquitecturas DAG se introdujeron principalmente para superar las limitaciones de las blockchains tradicionales en escalabilidad, velocidad y coste. Estos son los beneficios clave de los ledgers distribuidos basados en DAG:

• Alta escalabilidad y rendimiento: Las redes DAG pueden lograr altos volúmenes de transacciones porque gestionan muchas operaciones en paralelo. Al no existir un cuello de botella de cadena única, las TPS (transacciones por segundo) pueden escalar con la actividad de la red. De hecho, algunos protocolos DAG han demostrado rendimientos del orden de miles de TPS. Por ejemplo, Hedera Hashgraph tiene capacidad para procesar más de 10.000 transacciones por segundo en la capa base, superando con creces a Bitcoin o Ethereum. En la práctica, Hedera ha demostrado finalizar transacciones en unos 3–5 segundos, frente a los minutos o más que tardan las blockchains PoW. Incluso plataformas de contratos inteligentes basadas en DAG como Fantom han logrado finalidades casi instantáneas (~1–2 segundos) bajo cargas normales. Esta escalabilidad hace que los DAG sean atractivos para aplicaciones que requieren un alto volumen, como microtransacciones IoT o flujos de datos en tiempo real.
• Costes de transacción bajos (sin comisiones o mínimas): Muchos ledgers DAG presumen de comisiones insignificantes o incluso transacciones sin coste. Por diseño, suelen no depender de mineros que esperen recompensas de bloque o comisiones; por ejemplo, en IOTA y Nano no existen tarifas obligatorias, lo que es crucial para micropagos en IoT y usos cotidianos. Cuando sí hay tarifas (p. ej., en Hedera o Fantom), suelen ser muy bajas y predecibles, ya que la red puede manejar la carga sin guerras de pujas por espacio limitado en bloques. Las transacciones en Hedera cuestan alrededor de 0,0001 dólares (una diezmilésima parte de un dólar), una fracción mínima respecto a las comisiones típicas en blockchain. Este coste reducido abre la puerta a casos de uso como transacciones de alta frecuencia o pagos diminutos inviables en cadenas con tarifas elevadas. Además, como los DAG incluyen todas las transacciones válidas en lugar de descartar algunas en caso de forks, se desperdicia menos trabajo, lo que indirectamente ayuda a mantener bajos los costes aprovechando los recursos con eficiencia.
• Confirmación rápida y baja latencia: En los ledgers DAG, las transacciones no tienen que esperar a ser incluidas en un bloque global, por lo que la confirmación puede ser más rápida. Muchos sistemas DAG logran finalidad rápida, el punto en el que una transacción se considera permanentemente confirmada. Por ejemplo, el consenso de Hedera Hashgraph suele finalizar transacciones en pocos segundos con certeza del 100% (finalidad ABFT). La red de Nano suele ver transacciones confirmadas en <1 segundo gracias a su proceso de votación ligero. Esta baja latencia mejora la experiencia del usuario, haciendo que las operaciones parezcan casi instantáneas, algo importante para pagos reales y aplicaciones interactivas.
• Eficiencia energética: Las redes basadas en DAG a menudo no requieren la minería intensiva en pruebas de trabajo que usan muchas blockchains, lo que las hace mucho más eficientes energéticamente. Incluso comparadas con blockchains proof-of-stake, algunas redes DAG consumen energía mínima por transacción. Por ejemplo, una sola transacción en Hedera Hashgraph consume alrededor de 0,0001 kWh (kilovatios-hora). Esto es varios órdenes de magnitud menor que Bitcoin (que puede consumir cientos de kWh por transacción) o incluso que muchas cadenas PoS. La eficiencia proviene de eliminar cálculos desperdiciados (no hay carrera de minado) y de no descartar intentos de transacción. Si las redes blockchain adoptaran modelos basados en DAG de forma generalizada, el ahorro energético sería monumental. La huella de carbono de redes DAG como Hedera es tan baja que el conjunto de la red es carbono-negativa cuando se consideran las compensaciones. Esta eficiencia energética es cada vez más crucial para una infraestructura Web3 sostenible.
• Sin minería y validación democratizada: En muchos modelos DAG no existe un rol de minero/validador distinto que los usuarios corrientes no puedan desempeñar. Por ejemplo, cada usuario de IOTA que emite una transacción también ayuda a validar otras dos, descentralizando el trabajo de validación hacia los extremos de la red. Esto puede reducir la necesidad de hardware de minería potente o de apostar grandes cantidades de capital para participar en el consenso, lo que potencialmente hace la red más accesible. (Sin embargo, algunas redes DAG siguen usando validadores o coordinadores; más adelante abordamos el consenso y la descentralización).
• Gestión fluida del alto tráfico: Las blockchains suelen sufrir atascos en el mempool y picos de comisiones bajo alta carga (ya que solo puede añadirse un bloque a la vez). Las redes DAG, debido a su naturaleza paralela, generalmente manejan mejor los picos de tráfico. A medida que más transacciones inundan la red, simplemente crean más ramas paralelas en el DAG, que el sistema puede procesar de forma concurrente. Hay menos un límite rígido de rendimiento (la escalabilidad es más “horizontal”). Esto se traduce en una mejor escalabilidad bajo carga, con menos retrasos y solo incrementos moderados en los tiempos de confirmación o en las tarifas, hasta el límite de la capacidad de red y procesamiento de los nodos. En esencia, un DAG puede absorber ráfagas de transacciones sin congestionar tan rápido, lo que lo hace adecuado para casos de uso con picos de actividad (por ejemplo, dispositivos IoT enviando datos simultáneamente o un evento viral de una DApp).

En resumen, los ledgers basados en DAG prometen transacciones más rápidas, baratas y escalables que el enfoque blockchain clásico. Pretenden soportar escenarios de adopción masiva (micropagos, IoT, trading de alta frecuencia, etc.) con los que las blockchains principales actuales tienen dificultades debido a limitaciones de rendimiento y coste. Sin embargo, estos beneficios vienen acompañados de ciertos compromisos y desafíos de implementación, que abordamos en secciones posteriores.

Mecanismos de consenso en plataformas basadas en DAG​

Como los ledgers DAG no producen naturalmente una única cadena de bloques, requieren mecanismos de consenso innovadores para validar transacciones y asegurar que todos acuerdan el estado del ledger. Diferentes proyectos han desarrollado soluciones adaptadas a su arquitectura DAG. Aquí resumimos algunos enfoques notables utilizados por plataformas basadas en DAG:

• Tangle de IOTA – selección de puntas y votación ponderada: El Tangle de IOTA es un DAG de transacciones diseñado para el Internet de las Cosas (IoT). En el modelo original de IOTA no hay mineros; en su lugar, cada nueva transacción debe realizar una pequeña prueba de trabajo y aprobar dos transacciones previas (las “puntas” del grafo). Esta selección de puntas suele hacerse mediante un algoritmo de Markov Chain Monte Carlo (MCMC) que elige probabilísticamente qué puntas aprobar, favoreciendo el subtangle más pesado para evitar la fragmentación. El consenso en la primera versión de IOTA se lograba en parte por este peso acumulado de aprobaciones: cuantas más transacciones futuras aprueban indirectamente la tuya, más “confirmada” se vuelve. No obstante, para asegurar la red en sus inicios, IOTA dependía de un nodo centralizado temporal, el Coordinator, que emitía transacciones de hito para finalizar el Tangle. Esta centralización recibió críticas y está siendo eliminada en la actualización conocida como “Coordicide” (IOTA 2.0). En IOTA 2.0, un nuevo modelo de consenso aplica un consenso tipo Nakamoto sin líderes sobre un DAG. En esencia, los nodos realizan votación en el propio Tangle: cuando un nodo adjunta un nuevo bloque, ese bloque vota implícitamente sobre la validez de las transacciones que referencia. Un comité de validadores (elegidos mediante un mecanismo de staking) emite bloques de validación como votos, y una transacción se confirma cuando acumula suficientes aprobaciones ponderadas (concepto denominado approval weight). Este enfoque combina la idea del DAG más pesado (similar a la cadena más larga) con una votación explícita para lograr consenso sin un coordinador. En resumen, el consenso de IOTA evolucionó de la selección de puntas + Coordinador a una votación descentralizada sobre las ramas del DAG, buscando seguridad y acuerdos rápidos sobre el estado del ledger.
• Hedera Hashgraph – gossip y votación virtual (aBFT): Hedera Hashgraph usa un DAG de eventos junto con un algoritmo de consenso asíncrono tolerante a fallas bizantinas (aBFT). La idea central es “gossip about gossip”: cada nodo difunde rápidamente información firmada sobre las transacciones y sobre su historial de gossip a otros nodos. Esto crea un Hashgraph (el DAG de eventos) donde cada nodo termina sabiendo qué ha difundido cada otro nodo, incluyendo la estructura de quién oyó qué y cuándo. A partir de este DAG de eventos, Hedera implementa votación virtual. En lugar de enviar mensajes de voto reales para ordenar las transacciones, los nodos simulan localmente un algoritmo de votación analizando el grafo de conexiones de gossip. El algoritmo Hashgraph de Leemon Baird puede calcular de forma determinista cómo se desarrollaría una ronda teórica de votos sobre el orden de las transacciones, examinando la “red de gossip” registrada en el DAG. Esto produce una marca de tiempo de consenso y un orden total de transacciones que es justo y definitivo (las transacciones se ordenan por la mediana del momento en que la red las recibió). El consenso de Hashgraph es sin líderes y logra aBFT, lo que significa que puede tolerar hasta 1/3 de nodos maliciosos sin comprometerse. En la práctica, la red de Hedera está gobernada por un conjunto de 39 nodos operados por organizaciones conocidas (el Consejo de Hedera), por lo que es permisionada pero geográficamente distribuida. El beneficio es un consenso extremadamente rápido y seguro: Hedera alcanza la finalidad en segundos con consistencia garantizada. El mecanismo de consenso Hashgraph es patentado pero fue abierto en 2024, y muestra cómo un DAG sumado a un consenso innovador (gossip y votación virtual) puede reemplazar un protocolo blockchain tradicional.
• Lachesis de Fantom – PoS aBFT sin líderes: Fantom es una plataforma de contratos inteligentes que usa un consenso basado en DAG llamado Lachesis. Lachesis es un protocolo PoS aBFT inspirado en Hashgraph. En Fantom, cada validador agrupa las transacciones recibidas en un bloque de eventos y lo añade a su propio DAG local de eventos. Estos bloques contienen transacciones y referencias a eventos anteriores. Los validadores difunden estos bloques de eventos entre sí de forma asíncrona: no hay una secuencia única en la que deban producirse o acordarse los bloques. Conforme los bloques se propagan, los validadores identifican periódicamente ciertos eventos como hitos (o “bloques raíz”) cuando una supermayoría de nodos los ha visto. Lachesis ordena estos eventos finalizados y los compromete en una Opera Chain final (una estructura de blockchain tradicional) que actúa como ledger de bloques confirmados. En esencia, el DAG de bloques de eventos permite a Fantom lograr consenso de forma asíncrona y muy rápida, y luego el resultado final se linealiza para compatibilidad. Esto brinda una finalidad de ~1–2 segundos por transacción en Fantom. Lachesis no tiene mineros ni líderes que propongan bloques; todos los validadores aportan bloques de eventos y el protocolo los ordena determinísticamente. El consenso está asegurado por un modelo PoS (los validadores deben hacer staking de tokens FTM y están ponderados por su stake). Lachesis también es aBFT, tolerando hasta 1/3 de nodos defectuosos. Al combinar la concurrencia del DAG con una salida en cadena final, Fantom logra un alto rendimiento (varios miles de TPS en pruebas) mientras sigue siendo compatible con la EVM para contratos inteligentes. Es un buen ejemplo de usar un DAG internamente para aumentar el rendimiento sin exponer su complejidad a la capa de aplicación (los desarrolladores siguen viendo una cadena normal de transacciones).
• Votación de Representantes Abiertos (ORV) de Nano: Nano es una criptomoneda orientada a pagos que emplea una estructura DAG única llamada block-lattice. En Nano, cada cuenta tiene su propia blockchain (account-chain) que solo su propietario puede actualizar. Todas esas cadenas individuales forman un DAG, ya que las transacciones de distintas cuentas se enlazan de forma asíncrona (un envío en la cadena de una cuenta referencia una recepción en otra, etc.). El consenso en Nano se logra mediante un mecanismo llamado Open Representative Voting (ORV). Los usuarios designan un nodo representante para su cuenta (una delegación de peso, sin bloquear fondos) y estos representantes votan sobre la validez de las transacciones. Cada transacción se liquida individualmente (no hay bloques que agrupen múltiples tx) y se considera confirmada cuando una supermayoría (por ejemplo, >67%) del peso de voto (de los representantes) está de acuerdo. Dado que los titulares honestos no intentarán gastar dos veces sus propios fondos, los forks son raros y suelen deberse a intentos maliciosos, que los representantes pueden rechazar rápidamente. La finalidad suele alcanzarse en menos de un segundo por transacción. ORV es similar a la Prueba de Participación en que el peso del voto se basa en los saldos (stake), pero no hay recompensas de staking ni comisiones: los representantes son nodos voluntarios. La ausencia de minería y producción de bloques permite a Nano operar sin comisiones y con eficiencia. Sin embargo, depende de que un conjunto de representantes confiables esté en línea para votar, y existe una centralización implícita en los nodos que acumulan gran peso de voto (aunque los usuarios pueden cambiar de representante en cualquier momento, manteniendo el control de la descentralización en manos de la comunidad). El consenso de Nano es liviano y optimizado para la velocidad y eficiencia energética, en línea con su objetivo de ser un dinero digital rápido y sin comisiones.
• Otros enfoques destacados: Existen otros protocolos de consenso basados en DAG. Además de Hedera Hashgraph y Fantom Lachesis:
  • Consenso Avalanche (Avalanche/X-Chain): Avalanche emplea un consenso basado en DAG donde los validadores se muestrean repetidamente entre sí de forma aleatoria para decidir qué transacciones o bloques preferir. La X-Chain de Avalanche (cadena de intercambio) es un DAG de transacciones (UTXO) y alcanza consenso mediante este muestreo de red. El protocolo de Avalanche es probabilístico pero extremadamente rápido y escalable: puede finalizar transacciones en ~1 segundo y, según se informa, manejar hasta 4.500 TPS por subred. Su enfoque es único al combinar estructuras DAG con un consenso metastable (protocolo Snowball), y está asegurado por Proof-of-Stake (cualquiera puede ser validador con stake suficiente).
  • Tree-Graph de Conflux: Conflux es una plataforma que extendió el PoW de Bitcoin a un DAG de bloques. Utiliza una estructura Tree-Graph donde los bloques referencian no solo a un padre sino a todos los bloques previos conocidos (sin huerfanar). Esto permite a Conflux usar minería PoW pero mantener todos los forks como parte del ledger, logrando mucho mayor rendimiento que una cadena típica. Así, Conflux puede alcanzar teóricamente entre 3.000 y 6.000 TPS usando PoW, permitiendo que los mineros produzcan bloques continuamente sin esperar a una sola cadena. Su consenso ordena estos bloques y resuelve conflictos mediante una regla de subárbol más pesado. Es un ejemplo de DAG híbrido con PoW.
  • Variantes de Hashgraph y protocolos académicos: Hay numerosos protocolos DAG académicos (algunos implementados en proyectos recientes): SPECTRE y PHANTOM (protocolos blockDAG orientados a alto rendimiento y confirmación rápida, de DAGlabs), Aleph Zero (un consenso DAG aBFT usado en la blockchain Aleph Zero), Parallel Chains / Prism (proyectos de investigación que separan la confirmación en subcadenas paralelas y DAGs), y avances recientes como Narwhal & Bullshark de Sui, que usan un mempool en DAG para alto rendimiento y un consenso separado para la finalidad. Aunque no todos tienen despliegues a gran escala, indican un campo de investigación vibrante. Muchos de estos protocolos distinguen entre disponibilidad (escribir datos rápidamente en un DAG) y consistencia (ponerse de acuerdo en una historia), buscando obtener lo mejor de ambas.

Cada plataforma DAG adapta su consenso a sus necesidades —ya sean micropagos sin comisiones, ejecución de contratos inteligentes o interoperabilidad—. Un tema común, sin embargo, es evitar un cuello de botella serial único: los mecanismos de consenso basados en DAG buscan permitir mucha actividad concurrente y luego usan algoritmos ingeniosos (gossip, votación, muestreo, etc.) para ordenar todo, en vez de limitar la red a un único productor de bloques por turno.

Estudios de caso: ejemplos de proyectos blockchain basados en DAG​

Varios proyectos han implementado ledgers basados en DAG, cada uno con decisiones de diseño y casos de uso específicos. A continuación analizamos algunas plataformas DAG destacadas:

• IOTA (The Tangle): IOTA es una de las primeras criptomonedas basadas en DAG, diseñada para el Internet de las Cosas. Su ledger, llamado Tangle, es un DAG de transacciones donde cada nueva transacción confirma dos anteriores. El objetivo de IOTA es habilitar microtransacciones sin comisiones entre dispositivos IoT (pagos diminutos por datos o servicios). Lanzada en 2016, para arrancar con seguridad usó un Coordinador (ejecutado por la Fundación IOTA) que prevenía ataques en la red temprana. IOTA ha estado trabajando en “Coordicide” para descentralizar completamente la red introduciendo un consenso por votación (como describimos antes) donde los nodos votan transacciones conflictivas usando un consenso tipo Nakamoto sin líderes sobre el DAG más pesado. En términos de rendimiento, IOTA puede, en teoría, lograr un rendimiento muy alto (el protocolo no impone un límite rígido de TPS; mayor actividad incluso ayuda a confirmar más rápido). En la práctica, las testnets han demostrado cientos de TPS, y se espera que IOTA 2.0 escale bien para la demanda IoT. Los casos de uso de IOTA giran en torno al IoT y la integridad de datos: por ejemplo, transmisión de datos de sensores con pruebas de integridad, pagos entre vehículos, trazabilidad en la cadena de suministro e incluso identidad descentralizada (el marco IOTA Identity permite emitir y verificar credenciales/identificadores descentralizados en el Tangle). IOTA no admite contratos inteligentes en su capa base, pero el proyecto introdujo un marco paralelo de Smart Contracts y tokens en una capa secundaria para habilitar DApps más complejas. Una característica destacada de IOTA es su ausencia de comisiones, habilitada al requerir una pequeña prueba de trabajo del emisor en lugar de cobrar una tarifa, lo cual es atractivo para transacciones de bajo valor y alto volumen (p. ej., un sensor enviando datos cada pocos segundos a coste insignificante).
• Hedera Hashgraph (HBAR): Hedera es un ledger público distribuido que usa el algoritmo de consenso Hashgraph (inventado por Leemon Baird). Hedera comenzó en 2018 y está gobernada por un consejo de grandes organizaciones (Google, IBM, Boeing y otras) que operan el conjunto inicial de nodos. A diferencia de la mayoría, Hedera es permisionada en la gobernanza (solo miembros aprobados del consejo ejecutan nodos de consenso actualmente, hasta 39 nodos), aunque cualquiera puede utilizar la red. Su DAG Hashgraph permite altísimo rendimiento y finalidad rápida: Hedera puede procesar más de 10.000 TPS con finalidad en 3-5 segundos en condiciones óptimas. Lo consigue gracias al consenso aBFT basado en gossip que describimos antes. Hedera enfatiza casos de uso empresariales y Web3 que necesitan fiabilidad a escala: la red ofrece servicios de tokenización (Hedera Token Service), un Servicio de Consenso para registro inmutable de eventos y un servicio de Smart Contracts (compatible con la EVM). Aplicaciones notables en Hedera incluyen trazabilidad en la cadena de suministro (p. ej., seguimiento de prendas por Avery Dennison), minting masivo de NFT (las bajas comisiones abaratan el proceso), pagos y micropagos (como micropagos en ad tech) e incluso soluciones de identidad descentralizada. Hedera tiene un método DID registrado en el W3C y marcos como Hedera Guardian para admitir credenciales verificables y cumplimiento normativo (por ejemplo, seguimiento de créditos de carbono). Un aspecto clave es el fuerte rendimiento de Hedera combinado con la estabilidad declarada (el algoritmo Hashgraph garantiza ausencia de forks y una equidad matemática en el orden). El compromiso es que Hedera es menos descentralizada en número de nodos que redes abiertas (por diseño, con su modelo de gobernanza), aunque los nodos del consejo están distribuidos globalmente y el plan es aumentar la apertura con el tiempo. En resumen, Hedera Hashgraph es un ejemplo destacado de DLT basada en DAG orientada a aplicaciones empresariales, con énfasis en alto rendimiento, seguridad y gobernanza.
• Fantom (FTM): Fantom es una plataforma de contratos inteligentes (blockchain de Capa 1) que utiliza un consenso basado en DAG llamado Lachesis. Lanzada en 2019, Fantom ganó popularidad especialmente durante el auge DeFi de 2021-2022 como una cadena compatible con Ethereum pero con mayor rendimiento. La red Opera de Fantom ejecuta el consenso Lachesis aBFT (ya detallado), donde los validadores mantienen un DAG local de bloques de eventos, logran consenso de forma asíncrona y luego finalizan las transacciones en una cadena principal. Esto otorga a Fantom un tiempo de finalidad de ~1 segundo por transacción y la capacidad de manejar miles de TPS. Fantom es compatible con la EVM, lo que permite a los desarrolladores desplegar contratos Solidity y usar las mismas herramientas que Ethereum, facilitando su adopción en DeFi. De hecho, Fantom se convirtió en hogar de numerosos proyectos DeFi (DEX, protocolos de préstamos, yield farms) atraídos por su velocidad y bajas comisiones. También alberga proyectos NFT y DApps de gaming, prácticamente cualquier aplicación Web3 que se beneficie de transacciones rápidas y baratas. Un punto notable es que Fantom alcanzó un alto grado de descentralización para una plataforma DAG: cuenta con decenas de validadores independientes que aseguran la red (sin permisos, cualquiera puede ejecutar un validador con el stake mínimo), a diferencia de algunas redes DAG que restringen los validadores. Esto posiciona a Fantom como una alternativa creíble a blockchains más tradicionales para aplicaciones descentralizadas, aprovechando la tecnología DAG para superar el cuello de botella del rendimiento. El token FTM se usa para staking, gobernanza y comisiones (solo unos céntimos por transacción, mucho menos que el gas de Ethereum). Fantom demostró que el consenso basado en DAG puede integrarse con plataformas de contratos inteligentes para lograr simultáneamente velocidad y compatibilidad.
• Nano (XNO): Nano es una criptomoneda ligera lanzada en 2015 (originalmente como RaiBlocks) que usa una estructura DAG block-lattice. El enfoque principal de Nano es ser dinero digital punto a punto: transacciones instantáneas, sin comisiones y con un consumo mínimo de recursos. En Nano, cada cuenta tiene su propia cadena de transacciones, y las transferencias entre cuentas se gestionan mediante un bloque de envío en la cadena del remitente y un bloque de recepción en la del destinatario. Este diseño asíncrono permite que la red procese transacciones de forma independiente y en paralelo. El consenso se logra mediante la votación de representantes abiertos (ORV), donde la comunidad designa nodos representantes delegando su saldo. Los representantes votan en transacciones conflictivas (lo cual es raro, generalmente solo en intentos de doble gasto) y, una vez que una mayoría cualificada (67% del peso) está de acuerdo, la transacción se consolida (confirmada irrevocablemente). Los tiempos típicos de confirmación en Nano son muy inferiores a un segundo, lo que la hace sentir instantánea en el uso cotidiano. Al no existir recompensas de minería ni comisiones, operar un nodo o representante Nano es un esfuerzo voluntario, pero el diseño de la red minimiza la carga (cada transacción pesa apenas 200 bytes y se procesa rápidamente). El enfoque DAG y el consenso de Nano le permiten ser extremadamente eficiente energéticamente: existe una pequeña prueba de trabajo realizada por los remitentes (principalmente como medida antispam), pero es trivial comparada con la PoW blockchain. Los casos de uso de Nano son sencillos por diseño: está pensada para transferencias monetarias, desde compras diarias hasta remesas, donde la velocidad y la ausencia de tarifas son su propuesta de valor. Nano no admite contratos inteligentes ni scripting complejo; se centra en hacer muy bien una sola cosa. Un desafío de su modelo es que se basa en la honestidad de la mayoría de los representantes; al no haber incentivos monetarios, el modelo de seguridad se apoya en la suposición de que los grandes tenedores actuarán en beneficio de la red. Hasta ahora, Nano ha mantenido un conjunto bastante descentralizado de representantes principales y ha visto uso en pagos comerciales, propinas y otros micropagos en línea.
• Comparativa rápida Hedera vs IOTA vs Fantom vs Nano: La siguiente tabla resume algunas características clave de estos proyectos basados en DAG:

(Tabla: comparación de proyectos de ledger basados en DAG seleccionados y sus características. TPS = transacciones por segundo.)

Otros proyectos basados en DAG no detallados incluyen Obyte (Byteball) – un ledger DAG para pagos condicionales y almacenamiento de datos, IoT Chain (ITC) – un proyecto DAG orientado al IoT, Avalanche – que ya mencionamos por usar DAG en su consenso y se ha convertido en una plataforma DeFi importante, Conflux – un DAG PoW de alto rendimiento en China, y prototipos académicos como SPECTRE/PHANTOM. Cada uno explora el espacio de diseño de los ledgers DAG de distintas maneras, pero los cuatro ejemplos anteriores (IOTA, Hedera, Fantom, Nano) ilustran la diversidad: desde microtransacciones IoT sin comisiones hasta redes empresariales y cadenas de contratos inteligentes DeFi, todos aprovechando estructuras DAG.

Casos de uso de la tecnología DAG en el ecosistema Web3​

Los sistemas blockchain basados en DAG desbloquean determinados casos de uso gracias a su alto rendimiento y propiedades únicas. Estos son algunos casos de uso actuales y potenciales en los que los DAG están impactando en Web3:

• Internet de las Cosas (IoT): El IoT implica millones de dispositivos transmitiendo datos y potencialmente transaccionando entre sí (pagos máquina a máquina). Ledgers DAG como IOTA se diseñaron explícitamente para este escenario. Con microtransacciones sin comisiones y la capacidad de manejar frecuencias altas de pagos pequeños, un ledger DAG puede permitir que dispositivos IoT paguen por servicios o ancho de banda sobre la marcha. Por ejemplo, un coche eléctrico inteligente podría pagar automáticamente a una estación de carga unos céntimos por la energía, o los sensores podrían vender datos a una plataforma en tiempo real. El Tangle de IOTA se ha usado en pilotos de ciudades inteligentes, integraciones de IoT en cadenas de suministro (seguimiento de mercancías y condiciones ambientales) y mercados descentralizados de datos donde se registran y comercian los datos de sensores de forma inmutable. La escalabilidad de los DAG aborda el enorme volumen que generan las redes IoT masivas, y su bajo coste se ajusta a la economía de los micropagos.
• Finanzas descentralizadas (DeFi): Aplicaciones DeFi como los exchanges descentralizados (DEX), plataformas de préstamos y redes de pagos se benefician de un alto rendimiento y baja latencia. Las plataformas de smart contracts basadas en DAG (p. ej., Fantom, y en cierta medida la X-Chain de Avalanche para transferencias simples de activos) ofrecen la ventaja de liquidar operaciones más rápido y mantener comisiones bajas incluso durante alta demanda. En 2021, Fantom experimentó un aumento de actividad DeFi (yield farming, market makers automatizados, etc.) y pudo manejarlo con mucha menos congestión que Ethereum en ese momento. Además, la finalidad rápida de los DAG reduce el riesgo de incertidumbre en la ejecución de operaciones (en cadenas lentas, los usuarios esperan varios bloques para la finalidad, lo que introduce riesgo en el trading veloz). Otra perspectiva son las redes de pagos descentralizados: Nano, por ejemplo, puede considerarse parte del espectro DeFi, habilitando transferencias peer-to-peer y posiblemente actuando como carril de micropagos para capas 2 de otros sistemas. El rendimiento de los DAG también podría soportar trading de alta frecuencia o transacciones DeFi complejas multi-paso ejecutándose con mayor fluidez.
• NFT y gaming: El boom de los NFT evidenció la necesidad de minting y transferencias de bajo coste. En Ethereum, acuñar NFT se volvió costoso cuando el gas se disparó. Redes DAG como Hedera y Fantom se han planteado como alternativas donde acuñar un NFT cuesta una fracción de centavo, haciéndolas viables para activos en juegos, coleccionables o lanzamientos a gran escala. El Token Service de Hedera permite la emisión nativa de tokens y NFT con tarifas bajas y predecibles, y ha sido usado por plataformas de contenido e incluso empresas (p. ej., artistas musicales emitiendo tokens o universidades registrando títulos). En gaming, donde abundan las microtransacciones, un ledger DAG rápido puede gestionar frecuentes intercambios de activos o distribución de recompensas sin ralentizar el juego ni arruinar a los jugadores con comisiones. El alto rendimiento garantiza que, incluso si un juego o colección NFT popular atrae a millones de usuarios, la red pueda soportar la carga (hemos visto juegos en Ethereum congestionar la red en el pasado). Por ejemplo, un juego basado en NFT en Fantom puede actualizar el estado lo suficientemente rápido como para ofrecer una experiencia casi en tiempo real.
• Identidad descentralizada (DID) y credenciales: Los sistemas de identidad se benefician de un ledger inmutable para anclar identidades, credenciales y atestaciones. Las redes DAG se exploran aquí porque ofrecen escalabilidad para potencialmente miles de millones de transacciones de identidad (cada login, emisión de certificado, etc.) y bajo coste, crucial si, por ejemplo, cada interacción de identidad de un ciudadano se registrara. IOTA Identity es un ejemplo: proporciona un método DID did:iota donde los documentos de identidad se referencian en el Tangle. Se puede usar para identidad autosoberana: los usuarios controlan sus documentos y los verificadores pueden obtener pruebas del DAG. Hedera también está activa en el ámbito DID: tiene una especificación DID y se ha usado en proyectos como registros inmutables de títulos universitarios, certificados de vacunación COVID o documentos de cumplimiento en la cadena de suministro (a través del Hedera Consensus Service como servicio de anclaje). Las ventajas de los DAG aquí son que es barato y rápido escribir datos, de modo que actualizar un estado de identidad (rotar claves, añadir credenciales) no enfrenta el coste o retraso de una blockchain congestionada. Además, las garantías de finalidad y orden pueden ser importantes para auditorías (Hashgraph, por ejemplo, proporciona un orden temporal confiable útil para registros de cumplimiento).
• Cadena de suministro e integridad de datos: Más allá de la identidad, cualquier caso de uso que involucre registrar un alto volumen de datos puede aprovechar DLT basadas en DAG. La trazabilidad en cadenas de suministro es uno: los productos generan muchos eventos (fabricado, enviado, inspeccionado, etc.). Proyectos han usado Hedera e IOTA para registrar estos eventos en un ledger DAG, aportando inmutabilidad y transparencia. El alto rendimiento garantiza que el ledger no sea un cuello de botella, incluso si se escanea y registra cada artículo de una red de suministro grande. Además, las comisiones nulas o bajas permiten registrar eventos de bajo valor sin costes elevados. Otro ejemplo es la integridad de datos IoT: redes eléctricas o telecomunicaciones pueden registrar lecturas de dispositivos en un ledger DAG para demostrar posteriormente que los datos no fueron manipulados. El DAG de Constellation Network (otro proyecto DAG) se centra en la validación de grandes volúmenes de datos para empresas y gobiernos (como la integridad de datos de drones de la Fuerza Aérea de EE. UU.), destacando cómo un DAG escalable puede manejar flujos masivos de datos de forma confiable.
• Pagos y remesas: Transacciones rápidas y sin comisiones hacen que criptomonedas DAG como Nano e IOTA sean adecuadas para pagos. Nano ha sido adoptada en escenarios como propinas online (donde un usuario puede enviar unos céntimos instantáneamente a un creador de contenido) y remesas internacionales (donde la velocidad y coste cero marcan una gran diferencia frente a esperar horas y pagar porcentajes elevados). Las redes DAG pueden servir como carriles de pago de alta velocidad integrados en sistemas de punto de venta o aplicaciones móviles. Por ejemplo, una cafetería podría usar una criptomoneda DAG para los pagos sin preocuparse por la latencia o el coste (la experiencia puede rivalizar con una tarjeta de crédito contactless). HBAR de Hedera también se usa en algunas pruebas de pago (su finalidad rápida y baja tarifa atraen a aplicaciones fintech para liquidación). Además, como las redes DAG suelen tener mayor capacidad, pueden mantener el rendimiento incluso durante eventos globales de compras o picos de uso, algo valioso para la fiabilidad de pagos.
• Feeds de datos en tiempo real y oráculos: Los oráculos (servicios que introducen datos externos en contratos inteligentes) requieren escribir muchos datos en un ledger. Un ledger DAG podría actuar como una red de oráculos de alto rendimiento, registrando precios, datos climáticos, lecturas de sensores IoT, etc., con garantía de orden y marca temporal. El Hedera Consensus Service, por ejemplo, es utilizado por algunos proveedores de oráculos para sellar datos antes de alimentarlos a otras cadenas. La velocidad asegura datos frescos y el rendimiento permite manejar flujos rápidos. En analítica Web3 descentralizada o publicidad, donde cada clic o impresión podría registrarse para transparencia, un backend DAG puede soportar el volumen de eventos.

En todos estos casos, el hilo común es que las redes DAG buscan proporcionar la escalabilidad, velocidad y eficiencia de costes que amplían el alcance de lo que se puede descentralizar. Son particularmente útiles donde ocurren transacciones de alta frecuencia o alto volumen (IoT, microtransacciones, datos de máquinas) o donde la experiencia del usuario exige interacciones rápidas y fluidas (gaming, pagos). No obstante, no todos los casos de uso migrarán a ledgers DAG: a veces la madurez y seguridad de las blockchains tradicionales, o simplemente los efectos de red (por ejemplo, la enorme base de desarrolladores de Ethereum), pesan más que la necesidad de rendimiento bruto. Aun así, los DAG están labrándose un nicho en la pila Web3 para escenarios que tensionan a las cadenas convencionales.

Limitaciones y desafíos de las redes basadas en DAG​

Aunque los ledgers distribuidos basados en DAG ofrecen ventajas atractivas, también implican compromisos y desafíos. Es importante examinar críticamente estas limitaciones:

• Madurez y seguridad: La mayoría de los algoritmos de consenso DAG son relativamente nuevos y están menos probados en batalla que los protocolos blockchain bien estudiados de Bitcoin o Ethereum. Esto puede significar vulnerabilidades de seguridad o vectores de ataque aún desconocidos. La complejidad de los sistemas DAG puede abrir nuevas vías de ataque: por ejemplo, un atacante podría intentar inundar o inflar el DAG con subtangles conflictivos, o aprovechar la estructura paralela para gastar doble antes de que la red alcance consenso. Análisis académicos señalan que la complejidad incrementada introduce una gama más amplia de vulnerabilidades frente a cadenas lineales más simples. Algunas redes DAG han sufrido incidencias: por ejemplo, en sus inicios la red de IOTA tuvo que pausarse en un par de ocasiones por irregularidades/ataques (en 2020 se robó un fondo y el Coordinador se detuvo temporalmente para resolverlo). Estos incidentes subrayan que los modelos de seguridad siguen perfeccionándose. Además, en algunos DAG la finalidad es probabilística (p. ej., antes de Coordicide IOTA no tenía finalidad absoluta, solo confianza creciente), lo que puede ser problemático para ciertas aplicaciones (aunque DAG más recientes como Hashgraph y Fantom ofrecen finalidad instantánea con garantías aBFT).
• Complejidad del consenso: Lograr consenso en un DAG suele implicar algoritmos complejos (protocolos gossip, votación virtual, muestreo aleatorio, etc.). Esta complejidad se traduce en bases de código más extensas e implementaciones complicadas, aumentando el riesgo de bugs de software. También hace el sistema más difícil de entender para los desarrolladores. La regla de la cadena más larga en una blockchain es conceptualmente simple, mientras que la votación virtual de Hashgraph o el muestreo repetido de Avalanche no son tan intuitivos. La complejidad puede frenar la adopción: desarrolladores y empresas pueden dudar en confiar en un sistema que les cuesta comprender o auditar. Como señaló un estudio, los sistemas basados en órdenes parciales (DAG) requieren más esfuerzo para integrarse con la infraestructura existente y la mentalidad de los desarrolladores. Las herramientas y librerías para redes DAG también son menos maduras en muchos casos, lo que puede empeorar la experiencia de desarrollo frente a Ethereum o Bitcoin.
• Compromisos de descentralización: Algunas implementaciones DAG actuales sacrifican cierto grado de descentralización para lograr su rendimiento. Por ejemplo, la dependencia de Hedera en un consejo fijo de 39 nodos implica que la red no está abierta a cualquiera para participar en el consenso, lo cual ha recibido críticas pese a sus fortalezas técnicas. IOTA, durante mucho tiempo, dependió de un Coordinador central para evitar ataques, un punto único de fallo/control. El consenso de Nano se basa en un pequeño número de representantes principales que concentran la mayor parte del peso de voto (en 2023, los pocos representantes principales controlaban gran parte del peso en línea), lo que puede considerarse una concentración de poder, aunque es algo análogo a los pools de minería en PoW. En general, se percibe que las blockchains son más fáciles de descentralizar ampliamente (miles de nodos) que algunas redes DAG. Las razones varían: ciertos algoritmos DAG pueden exigir mayores requisitos de ancho de banda (dificultando la participación plena de muchos nodos), o el diseño del proyecto puede mantener intencionalmente una estructura permisionada al inicio. No es una limitación inherente de los DAG, pero en la práctica muchos aún no alcanzan el número de nodos de las grandes blockchains.
• Necesidad de volumen (seguridad vs rendimiento): Algunas redes DAG requieren paradójicamente un alto volumen de transacciones para funcionar de forma óptima. Por ejemplo, el modelo de seguridad de IOTA se fortalece cuando muchas transacciones honestas se confirman constantemente entre sí (aumentando el peso acumulado de los subtangles honestos). Si la actividad es muy baja, el DAG puede volverse perezoso: puntas sin aprobar rápidamente o atacantes que lo tienen más fácil para intentar sobrescribir partes del grafo. En contraste, una blockchain tradicional como Bitcoin no necesita un número mínimo de transacciones para seguir segura (incluso con pocas transacciones, los mineros siguen compitiendo por extender la cadena). Así, los DAG suelen rendir mejor bajo carga, pero pueden estancarse con uso escaso, salvo que se apliquen medidas especiales (como el coordinador de IOTA o transacciones de “mantenimiento” en segundo plano). Esto significa que el rendimiento puede ser inconsistente: excelente cuando el uso es alto, pero con confirmaciones más lentas en periodos valle o redes con poca actividad.
• Ordenamiento y compatibilidad: Como los DAG producen un orden parcial de eventos que luego debe hacerse consistente, los algoritmos de consenso pueden ser bastante intrincados. En contextos de contratos inteligentes, se requiere un orden total de las transacciones para evitar doble gastos y mantener la ejecución determinista. Sistemas DAG como Fantom resuelven esto construyendo una capa de ordenamiento (la Opera Chain final), pero no todos los DAG soportan fácilmente smart contracts complejos. El manejo del estado y el modelo de programación puede ser desafiante en un DAG puro. Por ejemplo, si dos transacciones no conflictivas, se pueden confirmar en paralelo en un DAG —eso está bien—. Pero si sí confligen (p. ej., dos tx gastan el mismo output o dos operaciones sobre el mismo pedido), la red debe decidir una y descartar la otra. Garantizar que todos los nodos tomen la misma decisión de forma descentralizada es más difícil sin una cadena única que lo ordene todo. Por eso muchos proyectos DAG inicialmente evitaron los contratos inteligentes o el estado global y se enfocaron en pagos (donde los conflictos son más sencillos de detectar via UTXO o balances). Interconectar ledgers DAG con ecosistemas blockchain existentes tampoco es trivial; por ejemplo, conectar una EVM a un DAG requirió que Fantom creara un mecanismo para linearizar el DAG para la ejecución EVM. Estas complejidades implican que no todos los casos de uso pueden implementarse inmediatamente sobre un DAG sin un diseño cuidadoso.
• Almacenamiento y sincronización: Un potencial problema es que, si un ledger DAG permite un volumen alto de transacciones paralelas, el ledger puede crecer rápidamente. Son importantes algoritmos eficientes para podar el DAG (eliminar transacciones antiguas que ya no son necesarias para la seguridad) y para permitir nodos ligeros (los light clients necesitan confirmar transacciones sin almacenar todo el DAG). La investigación ha identificado el desafío de alcanzabilidad: asegurar que las nuevas transacciones puedan alcanzar y referenciar a las anteriores con eficiencia y determinar cómo truncar la historia de forma segura en un DAG. Aunque las blockchains también enfrentan problemas de crecimiento, la estructura del DAG puede complicar tareas como calcular saldos o pruebas para estados parciales, ya que el ledger no es una simple lista de bloques. Es un desafío técnico que puede resolverse, pero añade más carga al diseño de un sistema DAG robusto.
• Percepción y efectos de red: Más allá de los aspectos técnicos, los proyectos DAG enfrentan el reto de demostrarse en un espacio dominado por blockchains. Muchos desarrolladores y usuarios se sienten más cómodos con las L1 blockchain, y los efectos de red (más usuarios, más dApps, más herramientas en las cadenas existentes) pueden ser difíciles de superar. A veces los DAG se promocionan con afirmaciones audaces (“blockchain killer”), lo que puede invitar al escepticismo. Por ejemplo, un proyecto puede alegar escalabilidad ilimitada, pero los usuarios esperarán ver pruebas en condiciones reales. Hasta que las redes DAG alojan “killer apps” o bases de usuarios grandes, pueden percibirse como experimentales. Además, lograr listados en exchanges, soluciones de custodia, wallets —toda la infraestructura que ya soporta las grandes blockchains— es un esfuerzo continuo para cada nueva plataforma DAG. Hay, por tanto, un desafío de arranque: a pesar de los méritos técnicos, la adopción puede rezagarse por la inercia del ecosistema.

En resumen, los ledgers basados en DAG intercambian simplicidad por rendimiento, y eso conlleva dolores de crecimiento. La complejidad del consenso, la posible centralización en algunas implementaciones y la necesidad de ganarse una confianza comparable a los sistemas blockchain veteranos son obstáculos a superar. La comunidad de investigación estudia activamente estos problemas; por ejemplo, un paper de 2024 de sistematización del conocimiento sobre protocolos DAG destaca la creciente variedad de diseños y la necesidad de comprender integralmente sus compromisos. A medida que los proyectos DAG maduren, probablemente se aborden muchos de estos desafíos (eliminación de coordinadores, participación abierta, mejores herramientas), pero es importante considerarlos al evaluar DAG vs blockchain para una aplicación específica.

Tendencias de adopción y perspectivas futuras​

La adopción de la tecnología blockchain basada en DAG todavía está en fases tempranas frente al uso generalizado de las blockchains tradicionales. A 2025, solo un puñado de ledgers públicos usan DAG a escala: entre ellos Hedera Hashgraph, IOTA, Fantom, Nano, Avalanche (en parte de su sistema) y algunos otros. Las blockchains (cadenas lineales) siguen siendo la arquitectura dominante en los sistemas desplegados. Sin embargo, el interés en los DAG ha ido aumentando tanto en la industria como en la academia. Podemos identificar varias tendencias y una perspectiva para los DAG en blockchain:

• Creciente número de proyectos y estudios DAG: Se aprecia un aumento en la cantidad de proyectos nuevos que exploran arquitecturas DAG o híbridas. Por ejemplo, plataformas recientes como Aleph Zero (una red enfocada en privacidad) usan un consenso DAG para un orden rápido, y Sui y Aptos (cadenas con lenguaje Move) incorporan mempools basados en DAG o motores de ejecución paralela para escalar el rendimiento. La investigación académica en consenso DAG está floreciendo: protocolos como SPECTRE, PHANTOM, GhostDAG y otros más recientes están ampliando los límites, y se publican análisis exhaustivos (papers SoK) para clasificar y evaluar los enfoques DAG. Esto indica una exploración saludable y la aparición de buenas prácticas. A medida que la investigación identifica soluciones a debilidades previas (por ejemplo, cómo lograr equidad, cómo podar DAG, cómo asegurar DAG bajo condiciones dinámicas), es probable que estas innovaciones lleguen a las implementaciones.
• Modelos híbridos en uso general: Una tendencia interesante es que incluso las blockchains tradicionales están adoptando conceptos DAG para mejorar el rendimiento. Avalanche es un ejemplo principal de híbrido: se presenta como una plataforma blockchain, pero en su núcleo usa un consenso DAG. Ha ganado adopción significativa en DeFi y NFT, demostrando que los usuarios a veces adoptan un sistema DAG sin siquiera notarlo, siempre que satisfaga sus necesidades (rapidez y bajo coste). Esta tendencia puede continuar: DAG como motor interno exponiendo una interfaz blockchain familiar podría ser una estrategia ganadora, facilitando a los desarrolladores la transición. Fantom hizo esto con su Opera Chain, y otros proyectos podrían seguir el mismo camino, convirtiendo la tecnología DAG en el motor invisible de las cadenas de próxima generación.
• Adopción empresarial y de nicho: Las empresas que requieren alto rendimiento, costes predecibles y que se sienten cómodas con redes más permisionadas se han inclinado a explorar ledgers DAG. El modelo de Consejo de Hedera atrajo a grandes compañías; estas impulsan casos de uso como tokenización de activos para servicios financieros o seguimiento de licencias de software en Hedera. También vemos consorcios considerar DLT basadas en DAG para liquidaciones en telecomunicaciones, seguimiento de impresiones publicitarias o transferencias interbancarias, donde el volumen es alto y necesitan finalidad. IOTA ha participado en proyectos financiados por la Unión Europea para infraestructura, pilotos de identidad digital e IoT industrial: son caminos de adopción a largo plazo, pero demuestran que los DAG están en el radar más allá de la comunidad cripto. Si algunas de estas pruebas tienen éxito y escalan, podríamos ver adopciones sectoriales de redes DAG (p. ej., un consorcio IoT usando un ledger DAG para compartir y monetizar datos).
• Progreso comunitario y descentralización: Las críticas tempranas a las redes DAG (coordinadores centrales, validadores permisionados) se están abordando gradualmente. Coordicide de IOTA, si tiene éxito, eliminará el coordinador central y transformará IOTA en una red completamente descentralizada con una forma de staking y validadores comunitarios. Hedera ha abierto su código y ha insinuado planes para descentralizar aún más la gobernanza a largo plazo (más allá del consejo inicial). La comunidad de Nano trabaja continuamente para distribuir el peso de los representantes (alentando a más usuarios a operar nodos o repartir sus delegaciones). Estos pasos son importantes para la credibilidad y confianza en las redes DAG, alineándolas más con la ética blockchain. Conforme aumente la descentralización, es probable que más usuarios y desarrolladores cripto-nativos estén dispuestos a construir sobre o contribuir a proyectos DAG, acelerando su crecimiento.
• Interoperabilidad y uso como capa 2: También podríamos ver a los DAG usarse como capas de escalado o redes interoperables en lugar de ecosistemas independientes. Por ejemplo, un ledger DAG podría servir como capa 2 de alta velocidad para Ethereum, anclando periódicamente resultados agregados en Ethereum para seguridad. Alternativamente, redes DAG podrían conectarse mediante puentes a blockchains existentes, permitiendo mover activos hacia donde sea más barato transaccionar. Si la experiencia de usuario es fluida, los usuarios podrían operar en una red DAG (disfrutando de alta velocidad) mientras confían en una blockchain base para la liquidación o seguridad, obteniendo lo mejor de ambos mundos. Algunos proyectos contemplan este enfoque por capas.
• Perspectiva futura – complemento, no reemplazo (por ahora): Es revelador que incluso los defensores suelen decir que los DAG son una “alternativa” o complemento a las blockchains, más que un reemplazo total. En el futuro cercano podemos esperar redes heterogéneas: algunas basadas en blockchain, otras en DAG, cada una optimizada para distintos escenarios. Los DAG podrían alimentar la columna vertebral de alta frecuencia de Web3 (gestionando el trabajo pesado de microtransacciones y registro de datos), mientras que las blockchains podrían seguir siendo preferidas para la liquidación, transacciones de muy alto valor o donde la simplicidad y robustez sean críticas. A más largo plazo, si los sistemas DAG siguen demostrando su valía y logran igualar o superar la seguridad y descentralización, es concebible que se conviertan en el paradigma dominante de los ledgers distribuidos. El enfoque en eficiencia energética también alinea a los DAG con las presiones globales de sostenibilidad, lo que podría hacerlos más aceptables política y socialmente a largo plazo. Los beneficios de huella de carbono reducida, junto con las ventajas de rendimiento, podrían ser un impulsor clave si los entornos regulatorios enfatizan la tecnología verde.
• Sentimiento comunitario: Existe un segmento de la comunidad cripto muy entusiasmado con los DAG, viéndolos como el siguiente paso evolutivo de la DLT. Es común oír frases como “los DAG son el futuro; las blockchains se verán como el internet por dial-up frente a la banda ancha de los DAG”. Este entusiasmo debe equilibrarse con resultados prácticos, pero sugiere que talento e inversiones están fluyendo hacia este ámbito. Por otro lado, persisten los escépticos, señalando que no debe sacrificarse la descentralización y seguridad por velocidad, por lo que los proyectos DAG deberán demostrar que pueden lograr lo mejor de ambos mundos.

En conclusión, el futuro de los DAG en blockchain es cautelosamente optimista. Actualmente las blockchains siguen dominando, pero las plataformas basadas en DAG se están abriendo espacio y demostrando su capacidad en dominios específicos. A medida que la investigación resuelva los desafíos actuales, probablemente veremos más convergencia de ideas: blockchains adoptando mejoras inspiradas en DAG y redes DAG asimilando las lecciones de las blockchains en gobernanza y seguridad. Los investigadores y desarrolladores Web3 harían bien en seguir de cerca los avances DAG, ya que representan una rama significativa de la evolución de los ledgers distribuidos. En los próximos años podríamos ver un ecosistema diverso de ledgers interoperables donde los DAG desempeñen un papel vital en la escalabilidad y aplicaciones especializadas, acercándonos a la visión de una web escalable y descentralizada.

En palabras de una publicación de Hedera: los ledgers basados en DAG son “un paso prometedor” en la evolución de las monedas digitales y la tecnología descentralizada: no una bala de plata para reemplazar completamente a las blockchains, sino una innovación importante que trabajará junto a ellas e inspirará mejoras en todo el panorama de los ledgers distribuidos.

Fuentes: La información de este informe proviene de diversas fuentes confiables, como investigaciones académicas sobre consenso DAG, documentación oficial y whitepapers de proyectos como IOTA, Hedera Hashgraph, Fantom y Nano, además de blogs técnicos y artículos que aportan perspectivas sobre las diferencias DAG vs blockchain. Estas referencias respaldan el análisis comparativo, los beneficios y los estudios de caso discutidos. El diálogo constante en la comunidad de investigación Web3 sugiere que los DAG seguirán siendo un tema candente mientras buscamos resolver la trinidad de escalabilidad, seguridad y descentralización en la próxima generación de tecnología blockchain.

Somnia es una blockchain de Capa 1 compatible con EVM construida para un rendimiento extremo, capaz de procesar más de 1.000.000 de transacciones por segundo (TPS) con una finalidad en menos de un segundo. Para lograr esto, Somnia reimagina el diseño central de la blockchain con cuatro innovaciones técnicas clave:

• Consenso MultiStream: El consenso de Somnia es un novedoso protocolo BFT de prueba de participación donde cada validador mantiene su propia "cadena de datos" de transacciones, produciendo bloques de forma independiente. Una cadena de consenso separada confirma periódicamente el último bloque de la cadena de datos de cada validador y los ordena en una única blockchain global. Esto permite la ingesta de transacciones en paralelo: múltiples validadores pueden propagar transacciones simultáneamente en sus flujos de datos, que luego se fusionan en un único registro ordenado. La cadena de consenso (inspirada en la investigación de Autobahn BFT) garantiza la seguridad al evitar que cualquier validador bifurque o altere su propio flujo una vez que el bloque global está finalizado. La Figura 1 ilustra esta arquitectura, donde las cadenas específicas de los validadores alimentan un bloque de consenso global.

• Ejecución Secuencial Acelerada: En lugar de depender de la ejecución multi-hilo, Somnia opta por hacer que un solo núcleo sea extremadamente rápido. El cliente de Somnia compila los contratos inteligentes de EVM a código máquina x86 nativo (justo a tiempo o antes de tiempo). Los contratos de uso frecuente se traducen en instrucciones de máquina optimizadas, eliminando la sobrecarga de interpretación típica y logrando una velocidad casi nativa de C++ para la ejecución. En las pruebas de rendimiento, esto produce cientos de nanosegundos por transferencia ERC-20, soportando millones de TX/seg en un solo núcleo. Los contratos menos llamados aún pueden ejecutarse en el intérprete estándar de EVM, equilibrando el costo de compilación. Además, Somnia aprovecha la ejecución fuera de orden y el pipelining de las CPU modernas ("paralelismo a nivel de hardware") para acelerar las transacciones individuales. Al compilar a código nativo, la CPU puede ejecutar instrucciones en paralelo a nivel de chip (por ejemplo, superponiendo búsquedas de memoria y cálculos), acelerando aún más la lógica secuencial como las transferencias de tokens. Esta elección de diseño reconoce que el paralelismo de software a menudo falla bajo picos de carga altamente correlacionados (por ejemplo, una acuñación de NFT muy popular donde todas las transacciones afectan al mismo contrato). Las optimizaciones de un solo hilo de Somnia aseguran que incluso los escenarios de contratos "calientes" alcancen un alto rendimiento donde la ejecución paralela ingenua se detendría.
• IceDB (Motor de Almacenamiento Determinista): Somnia incluye una base de datos de blockchain personalizada llamada IceDB para maximizar el rendimiento y la previsibilidad del acceso al estado. A diferencia de los backends típicos de LevelDB/RocksDB, IceDB proporciona costos de lectura/escritura deterministas: cada operación devuelve un "informe de rendimiento" de exactamente cuántas líneas de caché de RAM y páginas de disco se accedieron. Esto permite a Somnia cobrar tarifas de gas basadas en el uso real de recursos de una manera consistente y determinista para el consenso. Por ejemplo, las lecturas servidas desde la memoria pueden costar menos gas que las lecturas frías que acceden al disco, sin no determinismo. IceDB también utiliza una capa de caché mejorada optimizada tanto para lectura como para escritura, lo que produce una latencia extremadamente baja (15–100 nanosegundos por operación en promedio). Además, IceDB cuenta con snapshotting de estado incorporado: explota la estructura interna del almacenamiento estructurado en log para mantener y actualizar los hashes de estado global de manera eficiente, en lugar de construir un árbol de Merkle separado a nivel de aplicación. Esto reduce la sobrecarga para calcular las raíces de estado y las pruebas. En general, el diseño de IceDB garantiza un acceso al estado predecible y de alta velocidad y una medición justa del gas, que son críticos a la escala de Somnia.
• Compresión y Red Avanzadas: Impulsar millones de TPS significa que los nodos deben intercambiar enormes volúmenes de datos de transacciones (por ejemplo, 1M de transferencias ERC-20/seg ~ 1.5 Gbps de datos brutos). Somnia aborda esto mediante optimizaciones de compresión y red:
  • Compresión por Flujo: Debido a que cada validador publica un flujo de datos continuo, Somnia puede usar compresión de flujo con estado a través de los bloques. Los patrones comunes (como direcciones repetitivas, llamadas a contratos, parámetros) se comprimen haciendo referencia a ocurrencias previas en el flujo, logrando tasas mucho mejores que la compresión de bloques independientes. Esto aprovecha la distribución de ley de potencias de la actividad de la blockchain: un pequeño subconjunto de direcciones o llamadas representa una gran fracción de las transacciones, por lo que codificarlas con símbolos cortos produce una compresión masiva (por ejemplo, una dirección utilizada en el 10 % de las TX puede codificarse en ~3 bits en lugar de 20 bytes). Las cadenas tradicionales no pueden usar fácilmente la compresión de flujo porque los productores de bloques rotan; los flujos fijos por validador de Somnia desbloquean esta capacidad.
  • Agregación de Firmas BLS: Para eliminar las partes incompresibles más grandes de las transacciones (firmas y hashes), Somnia utiliza firmas BLS para las transacciones y admite la agregación de muchas firmas en una sola. Esto significa que un bloque de cientos de transacciones puede llevar una única firma combinada, reduciendo drásticamente el tamaño de los datos (y el costo de verificación) en comparación con tener 64 bytes de firma ECDSA por transacción. Los hashes de las transacciones tampoco se transmiten (los pares los recalculan según sea necesario). Juntas, la compresión y la agregación BLS reducen los requisitos de ancho de banda lo suficiente como para sostener el alto rendimiento de Somnia sin "ahogar" la red.
  • Simetría de Ancho de Banda: En el diseño de múltiples líderes de Somnia, cada validador comparte continuamente su fracción de nuevos datos en cada bloque, en lugar de que un solo líder envíe el bloque completo a los demás. En consecuencia, la carga de la red se distribuye simétricamente: cada uno de los N validadores sube aproximadamente 1/N del total de datos a N-1 pares (y descarga las otras porciones) en cada bloque, en lugar de que un solo líder suba N-1 copias. Ningún nodo necesita un ancho de banda de salida mayor que el rendimiento general de la cadena, evitando el cuello de botella donde un solo líder debe tener una enorme capacidad de subida. Esta utilización uniforme permite a Somnia acercarse a los límites físicos de ancho de banda de los nodos sin centralizarse en unos pocos supernodos. En resumen, la pila de red de Somnia está diseñada para que todos los validadores compartan el trabajo de propagar transacciones, permitiendo un rendimiento cercano al nivel de gigabit en toda la red descentralizada.

Consenso y Seguridad: La cadena de consenso utiliza un protocolo de prueba de participación PBFT modificado (Tolerancia a Fallas Bizantinas Práctica) con una suposición parcialmente síncrona. Somnia se lanzó con 60–100 validadores distribuidos globalmente (la red principal comenzó con ~60 y apunta a 100). Se requiere que los validadores ejecuten hardware potente (especificaciones aproximadamente entre un nodo de Solana y Aptos en rendimiento) para manejar la carga. Este número de validadores equilibra el rendimiento con una descentralización suficiente: la filosofía del equipo es la "descentralización suficiente" (suficiente para garantizar la seguridad y la resistencia a la censura, pero no tan extrema como para paralizar el rendimiento). Notablemente, Google Cloud participó como validador en el lanzamiento, junto con otros operadores de nodos profesionales.

Somnia implementa medidas de seguridad estándar de PoS como depósitos de staking y slashing por comportamiento malicioso. Para reforzar la seguridad en su novedoso motor de ejecución, Somnia utiliza un sistema único llamado "Cuthbert": una implementación de referencia alternativa (no optimizada) que se ejecuta en paralelo con el cliente principal en cada nodo. Cada transacción se ejecuta en ambos motores; si se detecta una divergencia o un error en los resultados del cliente optimizado, el validador se detendrá y se negará a finalizar, evitando errores de consenso. Esta ejecución dual actúa como una auditoría en tiempo real, asegurando que las optimizaciones de rendimiento agresivas nunca produzcan transiciones de estado incorrectas. Con el tiempo, a medida que crece la confianza en el cliente principal, Cuthbert puede ser eliminado, pero durante las primeras etapas añade una capa extra de seguridad.

En resumen, la arquitectura de Somnia está diseñada para aplicaciones en tiempo real con usuarios masivos. Al desacoplar la propagación de transacciones de la finalización (MultiStream), sobrealimentar la ejecución de un solo núcleo (compilación de EVM y paralelismo a nivel de CPU), optimizar la capa de datos (IceDB) y minimizar el ancho de banda por transacción (compresión + agregación), Somnia logra un rendimiento órdenes de magnitud más allá de las L1 tradicionales. El CEO de Improbable, Herman Narula, afirma que es "la capa uno más avanzada... capaz de manejar miles de veces el rendimiento de Ethereum o Solana", construida específicamente para la velocidad, escala y capacidad de respuesta necesarias para los juegos de próxima generación, redes sociales y experiencias inmersivas del metaverso.

Tokenomics – Suministro, Utilidad y Diseño Económico​

Suministro y Distribución: El token nativo de Somnia, SOMI, tiene un suministro máximo fijo de 1.000.000.000 de tokens (1 mil millones). No hay inflación continua: el suministro está limitado y los tokens se asignaron por adelantado a varias partes interesadas con calendarios de adjudicación (vesting). El desglose de la asignación es el siguiente:

En el lanzamiento de la red principal (TGE en el tercer trimestre de 2025), alrededor del 16 % del suministro entró en circulación (principalmente de los desbloqueos iniciales de las asignaciones de Comunidad y Ecosistema). La mayoría de los tokens (equipo, socios, inversores) están bloqueados durante el primer año y luego se liberan gradualmente, alineando los incentivos para el desarrollo a largo plazo. Este vesting estructurado ayuda a prevenir grandes ventas inmediatas y asegura que la fundación y los contribuyentes principales tengan recursos a lo largo del tiempo para hacer crecer la red.

Utilidad del Token: SOMI es central para el ecosistema de Somnia y sigue un modelo de Prueba de Participación Delegada (DPoS). Sus usos principales incluyen:

• Staking y Seguridad: Los validadores deben hacer staking de 5.000.000 de SOMI cada uno para operar un nodo y participar en el consenso. Esta participación significativa (~0.5 % del suministro total por validador) proporciona seguridad económica; los actores maliciosos corren el riesgo de perder su fianza. Somnia apunta inicialmente a 100 validadores, lo que significa que hasta 500 millones de SOMI podrían estar en staking para la operación de nodos (parte de lo cual puede provenir de la delegación, ver más abajo). Además, los delegadores (cualquier poseedor de tokens) pueden hacer staking de SOMI delegando a los validadores para ayudarles a cumplir el requisito de 5M. Los delegadores ganan una parte de las recompensas a cambio. Esto abre los rendimientos del staking a los no validadores y ayuda a descentralizar la participación entre muchos poseedores de tokens. Solo los tokens en staking (ya sea por validadores o mediante delegación) son elegibles para recompensas de la red: simplemente mantener tokens sin hacer staking no genera recompensas.
• Tarifas de Gas: Todas las transacciones en la cadena y las ejecuciones de contratos inteligentes requieren SOMI para las tarifas de gas. Esto significa que cada interacción (transferencias, acuñaciones, uso de DApps) crea demanda para el token. El modelo de gas de Somnia se basa en el de Ethereum (mismas definiciones de unidades) pero con ajustes y costos base mucho más bajos. Como se detalla más adelante, Somnia tiene tarifas de sub-céntimo e incluso descuentos dinámicos para DApps de alto volumen, pero las tarifas todavía se pagan en SOMI. Por lo tanto, si la red ve un uso intensivo (por ejemplo, un juego popular o una aplicación social), los usuarios y desarrolladores necesitarán SOMI para alimentar sus transacciones, impulsando la utilidad.
• Recompensas para Validadores/Delegadores: Las recompensas de bloque en Somnia provienen de las tarifas de transacción y de una tesorería comunitaria, no de la inflación. Específicamente, el 50 % de todas las tarifas de gas se distribuye a los validadores (y sus delegadores) como recompensas. El otro 50 % de las tarifas se quema (se elimina de la circulación) como un mecanismo deflacionario. Esta división de tarifas (mitad para los validadores, mitad quemada) se asemeja al modelo EIP-1559 de Ethereum, excepto que es una división fija de 50/50 en el diseño actual de Somnia. En la práctica, las ganancias de los validadores se derivarán del volumen de tarifas de la red: a medida que el uso crece, las recompensas por tarifas crecen. Para impulsar la seguridad antes de que las tarifas sean significativas, Somnia también tiene incentivos de tesorería para los validadores. La asignación de la Comunidad incluye tokens destinados a recompensas de staking y liquidez; la fundación puede distribuirlos según sea necesario (probablemente como suplementos de rendimiento de staking en los primeros años). Es importante destacar que solo los tokens en staking ganan recompensas, lo que fomenta la participación activa y bloquea el suministro. Los delegadores comparten las recompensas de las tarifas de su validador elegido proporcionalmente a su participación, menos la comisión del validador (cada validador establece una "tasa de delegación", por ejemplo, si se establece en 80 %, entonces el 80 % de las recompensas de ese validador se comparte con los delegados). Somnia ofrece dos opciones de delegación: delegar a un pool de un validador específico (sujeto a un período de desvinculación de 28 días, o un desestakeo de emergencia inmediato con una penalización severa del 50 %), o delegar a un pool general que se distribuye automáticamente entre todos los validadores con poca participación (sin período de bloqueo, pero probablemente un rendimiento combinado más bajo). Este diseño flexible de DPoS incentiva a los poseedores de tokens a asegurar la red a cambio de recompensas, al tiempo que proporciona una salida fácil (pool general) para aquellos que desean liquidez.
• Gobernanza: A medida que Somnia madure, SOMI gobernará las decisiones de la red. Los poseedores de tokens eventualmente votarán sobre propuestas que afecten las actualizaciones del protocolo, el uso de los fondos de la tesorería, los parámetros económicos, etc. El proyecto prevé una gobernanza multifacética (ver "Gobernanza de Tokens" más abajo) donde los poseedores de SOMI (la "Casa del Token") controlan principalmente las asignaciones de los fondos de la fundación y la comunidad, mientras que los validadores, desarrolladores y usuarios tienen consejos para decisiones técnicas y de políticas. En la red principal temprana, la gobernanza es manejada principalmente por la Fundación Somnia (para agilidad y seguridad), pero durante 1–2 años se descentralizará progresivamente hacia la comunidad de tokens y los consejos. Por lo tanto, poseer SOMI conferirá influencia sobre la dirección del ecosistema, convirtiéndolo en un token de gobernanza además de un token de utilidad.

Mecánicas Deflacionarias: Debido a que el suministro es fijo, Somnia depende de la quema de tarifas para introducir presión deflacionaria. Como se señaló, el 50 % de cada tarifa de gas se quema permanentemente. Esto significa que si el uso de la red es alto, el suministro circulante de SOMI disminuirá con el tiempo, aumentando potencialmente la escasez del token. Por ejemplo, si se generan 1 millón de SOMI en tarifas en un mes, 500k SOMI serían destruidos. Este mecanismo de quema puede compensar los desbloqueos de tokens o las ventas, y alinea el valor del token a largo plazo con el uso de la red (más actividad -> más quema). Además, Somnia actualmente no admite propinas especificadas por el usuario (tarifas de prioridad) en el lanzamiento; el modelo de tarifa base es lo suficientemente eficiente dado el alto rendimiento, aunque pueden introducir propinas más tarde si surge congestión. Con tarifas ultra bajas, la quema por transacción es pequeña, pero a escala (miles de millones de transacciones), se acumula. El modelo económico de Somnia, por lo tanto, combina cero inflación, desbloqueos programados y quema de tarifas, apuntando a la sostenibilidad a largo plazo. Si la red alcanza un volumen masivo, SOMI podría volverse deflacionario, beneficiando a los stakers y poseedores a medida que el suministro disminuye.

Aspectos Destacados del Modelo de Gas: El precio del gas de Somnia es generalmente mucho más barato que el de Ethereum, pero con algunos giros novedosos para la equidad y la escalabilidad. La mayoría de los costos de los opcodes se ajustan a la baja (ya que el rendimiento y la eficiencia de Somnia son mayores), pero los costos de almacenamiento se recalibraron al alza por unidad (para evitar abusos dado el bajo costo por gas). Dos características especialmente notables planeadas para 2025 son:

• Descuentos por Volumen Dinámicos: Somnia introduce un descuento escalonado en el precio del gas para cuentas o aplicaciones que mantienen un alto uso de TPS. En efecto, cuantas más transacciones ejecute una aplicación o usuario por hora, menor será el precio efectivo del gas que pagan (hasta un 90 % de descuento a ~400 TPS). Este precio basado en el volumen tiene como objetivo incentivar a las DApps a gran escala a ejecutarse en Somnia reduciendo drásticamente sus costos a escala. Se implementa como un precio de gas que disminuye por pasos una vez que se superan ciertos umbrales de TPS por cuenta (0.1, 1, 10, 100, 400 TPS, etc.). Este modelo (que se espera que se implemente después del lanzamiento de la red principal) recompensa a los proyectos que traen una carga pesada, asegurando que Somnia siga siendo asequible incluso cuando alimenta juegos en tiempo real o feeds sociales con cientos de transacciones por segundo. Es un mecanismo inusual (la mayoría de las cadenas tienen un mercado de tarifas planas), lo que indica la priorización de Somnia de los casos de uso de rendimiento masivo.
• Almacenamiento Transitorio: Somnia planea ofrecer opciones de almacenamiento con límite de tiempo donde un desarrollador puede optar por almacenar datos en la cadena solo temporalmente (por horas o días) a un costo de gas mucho menor que el almacenamiento permanente. Por ejemplo, una variable en la cadena que solo necesita persistir durante una hora (como el estado de un lobby de juego o la posición efímera de un jugador) puede almacenarse con ~90 % menos de gas que una escritura permanente normal. El programa de gas para un SSTORE de 32 bytes podría ser de 20k de gas para una retención de 1 hora frente a 200k para una retención indefinida. Este concepto de "estado transitorio" está explícitamente dirigido a aplicaciones de juegos y entretenimiento que generan una gran cantidad de datos temporales (tablas de clasificación, estado del juego) que no necesitan vivir para siempre en la cadena. Al proporcionar un almacenamiento basado en la expiración con descuentos, Somnia puede soportar tales aplicaciones en tiempo real de manera más eficiente. La implementación probablemente implica descartar automáticamente el estado después de la duración elegida (o moverlo a un almacén separado), aunque los detalles están por implementarse. Esta característica, combinada con la compresión de Somnia, está orientada a juegos en la cadena que gestionan grandes volúmenes de actualizaciones de estado sin inflar la cadena o incurrir en costos enormes.

En general, la tokenomics de Somnia se alinea con su objetivo de potenciar la Web3 a escala Web2. Un gran fondo inicial de tokens financió el desarrollo y el crecimiento del ecosistema (con patrocinadores de renombre y largos bloqueos que señalan compromiso), mientras que el diseño económico continuo utiliza recompensas impulsadas por el mercado (a través de tarifas) y la deflación para mantener el valor. Se incentiva a los poseedores de SOMI a hacer staking y participar, ya que todos los beneficios de la red (ingresos por tarifas, poder de gobernanza) se acumulan para los stakers activos. Con un suministro limitado y una quema proporcional al uso, el valor de SOMI está estrechamente ligado al éxito de la red: a medida que más usuarios y aplicaciones se unen, la demanda de tokens (para gas y staking) aumenta y el suministro disminuye por las quemas, creando un bucle de retroalimentación que apoya la sostenibilidad a largo plazo del token.

Ecosistema y Asociaciones​

A pesar de lanzar su red principal a finales de 2025, Somnia entró en escena con un ecosistema robusto de proyectos y socios estratégicos gracias a una extensa fase de red de prueba y el apoyo de pesos pesados de la industria.

dApps y Protocolos del Ecosistema: Para el lanzamiento de la red principal, más de 70 proyectos y dApps ya estaban construyendo o integrándose con Somnia. El ecosistema inicial se inclina fuertemente hacia aplicaciones de juegos y sociales, reflejando el mercado objetivo de Somnia de aplicaciones inmersivas y en tiempo real. Proyectos notables incluyen:

• Sparkball: Un juego Web3 insignia en Somnia, Sparkball es un MOBA/brawler deportivo 4v4 de ritmo rápido desarrollado por Opti Games. Se unió a Somnia como título de lanzamiento, introduciendo jugabilidad en la cadena y activos de equipo basados en NFT. Sparkball demuestra la capacidad de Somnia para manejar emparejamientos rápidos y transacciones dentro del juego (por ejemplo, acuñar/intercambiar jugadores o artículos) con una latencia insignificante.
• Variance: Un RPG roguelite con temática de anime, una historia rica y sin mecánicas de pago para ganar. Los desarrolladores de Variance (veteranos de Pokémon GO y Axie Infinity) eligieron Somnia por su capacidad para manejar economías de juego a gran escala y transacciones de forma económica. Después de conversaciones con el fundador de Somnia, el equipo se convenció de que Somnia entendía las necesidades de los desarrolladores de juegos y la visión para los juegos Web3. Variance trasladó su token en el juego ($VOID) y la lógica de NFT a Somnia, permitiendo características como botines en la cadena y activos propiedad del jugador a escala. La comunidad del juego creció significativamente después de anunciar el cambio a Somnia. Variance realizó pruebas de juego y misiones comunitarias en la red de prueba de Somnia, demostrando combate multijugador en la cadena y recompensando a los jugadores con NFTs y tokens.
• Maelstrom Rise: Un juego de batalla naval (piensa en Fortnite en el mar) de Uprising Labs. Maelstrom presenta combate de barcos en tiempo real y una economía integrada en la cadena para mejoras y coleccionables. Ya disponible fuera de la cadena (en Steam), Maelstrom está transicionando a Somnia para dar a los jugadores la verdadera propiedad de los buques de guerra y los artículos. Es uno de los juegos Web3 más accesibles, con el objetivo de incorporar a los jugadores tradicionales mezclando una jugabilidad familiar con las ventajas de la blockchain.
• Dark Table CCG: Un juego de cartas coleccionables en la cadena que admite hasta 4 jugadores por partida. Ofrece construcción de mazos gratuita, con todas las cartas como NFTs que los jugadores poseen e intercambian libremente. Dark Table aprovecha Somnia para ejecutar una economía de cartas multiplataforma sin servidores centrales, permitiendo a los jugadores ser verdaderamente dueños de sus mazos. Está diseñado para ser de fácil entrada (no se necesita comprar cripto para empezar) para atraer tanto a jugadores de cartas casuales como competitivos a la Web3.
• Netherak Demons: Un RPG de acción de fantasía oscura respaldado por el acelerador Dream Catalyst de Somnia. Los jugadores personalizan personajes demoníacos y participan en batallas PvE y PvP en tiempo real, con una colección de NFT que se vincula con el progreso del juego. Netherak utiliza la tecnología de Somnia para permitir la progresión persistente de los personajes en la cadena: los logros y el botín de los jugadores se registran como activos que controlan, añadiendo un valor significativo a la jugabilidad.
• Masks of the Void: Un juego de acción y aventura roguelite con niveles generados proceduralmente, también apoyado por Uprising Labs. Planeó una prueba de juego cerrada donde acuñar un NFT gratuito otorga acceso temprano, mostrando cómo Somnia puede integrar el acceso restringido por NFT para el contenido del juego. Masks of the Void enfatiza la rejugabilidad y la progresión mejorada por blockchain (por ejemplo, recompensas de metajuego que persisten de una partida a otra como NFTs).

Estos son solo algunos ejemplos. El ecosistema de juegos de Somnia abarca muchos géneros, desde shooters navales hasta batallas de cartas y RPGs, lo que indica el amplio atractivo de la plataforma para los desarrolladores. Todos estos juegos aprovechan las características en la cadena (propiedad de artículos, tokens para recompensas, personajes NFT, etc.) que requieren una cadena de alto rendimiento para ser disfrutables por los jugadores. Los primeros resultados son prometedores: por ejemplo, la red de prueba de Somnia ejecutó una demostración de MMO sandbox completamente en la cadena llamada "Chunked" (construida por Improbable) donde miles de jugadores interactuaron en tiempo real, generando 250 millones de transacciones en 5 días, una carga récord que validó las capacidades de Somnia.

Más allá de los juegos, el ecosistema inicial de Somnia incluye otros dominios de Web3:

• Social y Metaverso: Somnia está destinada a potenciar redes sociales descentralizadas y mundos virtuales, aunque las aplicaciones específicas son tempranas. Sin embargo, hay indicios de plataformas sociales. Por ejemplo, Somnia se asoció con Yuga Labs para integrar NFTs de Otherside (del metaverso de Bored Ape Yacht Club) en el mundo de Somnia, permitiendo que esos activos se usen en experiencias inmersivas. Eventos impulsados por la comunidad como los "gamevents" Edison de BoredElon Musk se realizaron con tecnología de Improbable en 2023, y Somnia está preparada para llevar tales eventos metaversales completamente a la cadena en el futuro. También hay una aplicación Somnia Metaverse Browser, esencialmente un navegador/billetera Web3 personalizado orientado a la interacción en mundos virtuales, facilitando a los usuarios el acceso a DApps y experiencias de metaverso en una sola interfaz. A medida que la red madure, se espera que se lancen dApps sociales (análogos descentralizados de Twitter/Reddit, centros comunitarios) y plataformas de metaverso en Somnia, aprovechando sus características de portabilidad de identidad (Somnia admite nativamente los estándares abiertos de MSquared para la interoperabilidad de avatares y activos entre mundos).
• DeFi y Otros: En su lanzamiento, Somnia no estaba principalmente enfocada en DeFi, pero hay alguna infraestructura en su lugar. Hay integraciones con oráculos de precios como DIA (para feeds de precios en la cadena) y Chainlink VRF a través de adaptadores de Protofire (para aleatoriedad en los juegos). Se discutieron algunos casos de uso de estilo DeFi, como intercambios de libros de órdenes completamente en la cadena (la baja latencia de Somnia podría permitir la coincidencia de órdenes en la cadena de manera similar a un intercambio centralizado). Podemos esperar que aparezca un AMM o DEX (la documentación incluso incluye una guía para construir un DEX en Somnia), y quizás protocolos novedosos que mezclen juegos y finanzas (por ejemplo, préstamos de NFT o mercados de activos de juegos tokenizados). La presencia de proveedores de custodia BitGo y Fireblocks como socios también indica una mirada hacia el soporte de casos de uso institucionales y financieros (hacen que la tenencia de tokens sea segura para intercambios y fondos). Además, la tecnología de Somnia puede soportar IA y aplicaciones con gran cantidad de datos (el programa Dreamthon llama explícitamente a proyectos de IA e InfoFi), por lo que podríamos ver innovaciones como agentes de IA descentralizados o mercados de datos en la cadena.

Asociaciones Estratégicas: Somnia está respaldada por una impresionante lista de socios y patrocinadores:

• Improbable y MSquared: Improbable, una empresa líder en tecnología de metaverso, es el principal socio de desarrollo de Somnia. De hecho, Improbable construyó la blockchain de Somnia bajo contrato para la Fundación Somnia, aportando su década de experiencia en sistemas distribuidos. MSquared (M²), una iniciativa de red de metaverso respaldada por Improbable, también está estrechamente involucrada. Juntos, Improbable y MSquared comprometieron hasta 270 millones de dólares para apoyar el desarrollo y el ecosistema de Somnia. Este enorme fondo de inversión (anunciado a principios de 2025) provino en parte de la recaudación de 150 millones de dólares de M² en 2022 (que incluyó a Andreessen Horowitz, SoftBank Vision Fund 2, Mirana y otros como inversores) y 120 millones de dólares de la asignación de riesgo de Improbable. La financiación apoya subvenciones, marketing e incorporación de proyectos. La participación de Improbable también trae integraciones técnicas: Somnia está diseñada para funcionar con la tecnología Morpheus de Improbable para eventos virtuales masivos. En 2023, Improbable impulsó experiencias virtuales como el Virtual Ballpark de la MLB y conciertos de K-pop con decenas de miles de usuarios concurrentes; esos usuarios pronto podrían ser incorporados a Somnia para que las interacciones en los eventos generen activos o tokens en la cadena. Improbable y MSquared esencialmente aseguran que Somnia tenga tanto la pista financiera como los casos de uso reales (eventos de metaverso, juegos) para impulsar la adopción.
• Infraestructura y Servicios Web3: Somnia se integró con muchos de los principales proveedores de servicios de blockchain desde el primer día:
  • OpenSea: El mercado de NFT más grande del mundo está integrado con Somnia, lo que significa que los NFTs basados en Somnia pueden ser intercambiados en OpenSea. Esta es una gran victoria para los desarrolladores de juegos en Somnia: sus NFTs en el juego (personajes, skins, etc.) tienen liquidez y visibilidad inmediatas en un mercado popular.
  • LayerZero: Somnia está conectada a otras cadenas a través del protocolo Stargate de LayerZero, permitiendo transferencias de activos omnichain y puentes. Por ejemplo, los usuarios pueden puentear USDC u otras stablecoins desde Ethereum a Somnia fácilmente a través de Stargate. Esta interoperabilidad es crucial para incorporar liquidez al ecosistema de Somnia.
  • Ankr: Ankr proporciona nodos RPC e infraestructura de nodos global. Es probable que se utilice para ofrecer endpoints RPC públicos, alojamiento de nodos y servicios de API para Somnia, facilitando a los desarrolladores el acceso a la red sin ejecutar sus propios nodos completos.
  • Sequence (Horizon): Sequence es una billetera de contrato inteligente y una plataforma de desarrollo adaptada para juegos (por Horizon). La integración con Sequence sugiere que Somnia puede aprovechar las características de billetera inteligente (por ejemplo, abstracciones de gas, inicio de sesión con correo electrónico/redes sociales) para incorporar a usuarios convencionales. La billetera multi-cadena de Sequence probablemente añadió soporte para Somnia, para que los jugadores puedan firmar transacciones con una interfaz fácil de usar.
  • Thirdweb: Los SDKs y herramientas Web3 de Thirdweb son totalmente compatibles con Somnia. Thirdweb proporciona módulos plug-and-play para lanzamientos de NFT, mercados, tokens y especialmente Abstracción de Cuentas. De hecho, la documentación de Somnia tiene guías sobre transacciones sin gas y abstracción de cuentas a través de Thirdweb. Esta asociación significa que los desarrolladores en Somnia pueden construir DApps rápidamente usando las bibliotecas de Thirdweb y los usuarios pueden beneficiarse de características como la incorporación sin billetera con un solo clic (tarifas de gas patrocinadas por la DApp, etc.).
  • DIA y Oráculos: DIA es un proveedor de oráculos descentralizado; Somnia utiliza los feeds de precios de DIA para datos de DeFi o de la economía del juego. Además, Somnia trabajó con Protofire para adaptar Chainlink VRF (función de aleatoriedad verificable) para la generación de números aleatorios en los contratos inteligentes de Somnia. Esto asegura que los juegos puedan obtener aleatoriedad segura (para botines, etc.). Podemos esperar más integraciones de oráculos (quizás feeds de precios completos de Chainlink en el futuro) según lo necesiten los proyectos de DeFi.
• Socios de Nube y Empresariales: Google Cloud no solo invirtió, sino que también opera un validador, proporcionando credibilidad y experiencia en infraestructura en la nube. Tener a la división de nube de un gigante tecnológico validando activamente la red ayuda con la fiabilidad y abre puertas a colaboraciones empresariales (por ejemplo, Google Cloud podría ofrecer servicios de nodos de blockchain para Somnia o incluir a Somnia en su mercado). También hubo asociaciones con Fireblocks y BitGo: estos son los principales proveedores de custodia de activos digitales y billeteras. Su participación significa que los intercambios e instituciones pueden custodiar de forma segura SOMI y activos basados en Somnia desde el primer día, allanando el camino para las listas de SOMI y la adopción institucional. De hecho, poco después de la red principal, Binance listó SOMI y lo presentó en una campaña promocional de airdrop, probablemente facilitado por dicha preparación de custodia.
• Programas de Crecimiento del Ecosistema: La Fundación Somnia estableció un Programa de Subvenciones de 10 millones de dólares para financiar a los desarrolladores que construyen en Somnia. Este programa de subvenciones se lanzó junto con la red principal para incentivar el desarrollo de herramientas, DApps, investigación e iniciativas comunitarias. Complementándolo está Dream Catalyst, el acelerador de Somnia específicamente para startups de juegos Web3. Dream Catalyst (dirigido con Uprising Labs) proporciona financiación, créditos de infraestructura, mentoría y apoyo para la salida al mercado a los estudios de juegos que construyen en Somnia. Al menos media docena de juegos (como Netherak Demons y otros) formaron parte de la primera cohorte de Dream Catalyst, recibiendo porciones de ese fondo de 10 millones de dólares. También está Dreamthon, un próximo programa acelerador para otras verticales, centrado en proyectos de DeFi, IA, "InfoFi" (mercados de información) y SocialFi en el ecosistema de Somnia. Además, Somnia organizó hackathons y misiones en línea durante la red de prueba: por ejemplo, un evento Somnia Odyssey de 60 días recompensó a los usuarios por completar tareas y probablemente culminó en un airdrop. Los primeros usuarios podían ganar "puntos" y NFTs por probar dApps (un Programa de Puntos), y se planean mini-hackathons para involucrar continuamente a los desarrolladores. Este enfoque multifacético —subvenciones, aceleradores, hackathons, misiones comunitarias— muestra el fuerte compromiso de Somnia para construir un ecosistema vibrante rápidamente, reduciendo las barreras y financiando a los experimentadores.

En resumen, Somnia no se lanzó de forma aislada, sino respaldada por una poderosa alianza de empresas tecnológicas, inversores y proveedores de servicios. El apoyo de Improbable le proporciona tecnología de vanguardia y una cartera de eventos virtuales masivos. Las asociaciones con empresas como Google Cloud, Binance, LayerZero, OpenSea y otras aseguran que Somnia esté conectada a la infraestructura cripto más amplia desde el principio, mejorando su atractivo para los desarrolladores (que quieren herramientas fiables y liquidez) y para los usuarios (que demandan puentes fáciles y comercio de activos). Mientras tanto, una serie de juegos Web3 —Sparkball, Variance, Maelstrom y más— están construyendo activamente en Somnia, con el objetivo de ser la primera ola de entretenimiento completamente en la cadena que muestre las capacidades de la red. Con docenas de proyectos en vivo o en desarrollo, el ecosistema de Somnia en la red principal ya era más rico que algunas cadenas con años de lanzamiento. Es probable que este fuerte impulso crezca a medida que las subvenciones y las asociaciones continúen dando sus frutos, posicionando potencialmente a Somnia como un centro neurálgico para los juegos en la cadena y las aplicaciones de metaverso en los próximos años.

Infraestructura para Desarrolladores y Usuarios​

Somnia fue construida para ser amigable para los desarrolladores y para incorporar a millones de usuarios que pueden no ser expertos en cripto. Como una cadena compatible con EVM, soporta el familiar conjunto de herramientas de Ethereum desde el principio, al tiempo que ofrece SDKs y servicios personalizados para mejorar la experiencia del desarrollador y la incorporación de usuarios.

Herramientas para Desarrolladores y Compatibilidad: Somnia mantiene compatibilidad total con la Ethereum Virtual Machine, lo que significa que los desarrolladores pueden escribir contratos inteligentes en Solidity o Vyper y desplegarlos con cambios mínimos. La red soporta interfaces RPC estándar de Ethereum y ID de cadena, por lo que herramientas como Hardhat, Truffle, Foundry, y bibliotecas como Web3.js o ethers.js funcionan sin problemas (la documentación de Somnia incluso proporciona guías específicas sobre cómo desplegar con Hardhat y Foundry). Esto reduce significativamente la curva de aprendizaje: cualquier desarrollador de Solidity puede convertirse en un desarrollador de Somnia sin aprender un nuevo lenguaje o VM.

Para acelerar el desarrollo y las pruebas, Somnia lanzó un entorno interactivo de Playground. El Playground permite a los equipos (especialmente a los de juegos/metaverso) prototipar lógica en la cadena de una manera de baja fricción, utilizando plantillas para NFTs, minijuegos, tokens sociales, etc. Es probable que proporcione una red de sandbox o un portal para desarrolladores para iteraciones rápidas. Además, la documentación de Somnia en GitBook es completa, cubriendo todo, desde el despliegue de contratos hasta el uso de características avanzadas (como las APIs de Ormi, ver más abajo).

SDKs y APIs de Somnia: Reconociendo que consultar datos en la cadena de manera eficiente es tan importante como escribir contratos, Somnia se asoció con Ormi Labs para proporcionar robustos servicios de indexación de datos y API. Ormi es esencialmente la respuesta de Somnia a The Graph: ofrece subgrafos y APIs GraphQL para indexar eventos y estado de contratos. Los desarrolladores pueden crear subgrafos personalizados para sus DApps (por ejemplo, para indexar todos los NFTs de artículos de juego o publicaciones sociales) a través de Ormi, y luego consultar esos datos fácilmente. Las APIs de Datos de Ormi entregan datos estructurados en la cadena con alta disponibilidad, por lo que las aplicaciones de front-end no necesitan ejecutar sus propios nodos de indexación. Esto simplifica significativamente la construcción de interfaces de usuario ricas en Somnia. Somnia ha realizado Codelabs y tutoriales que muestran cómo construir interfaces de usuario de dApps con los endpoints GraphQL de Ormi, lo que indica un fuerte apoyo a esta herramienta. En resumen, Somnia proporciona soporte de indexación de primera clase, lo cual es crucial para cosas como tablas de clasificación en juegos o feeds en aplicaciones sociales, datos que necesitan ser filtrados y recuperados rápidamente.

Además de Ormi, la página de infraestructura de Somnia enumera múltiples endpoints RPC públicos y servicios de explorador:

• Endpoints RPC de proveedores como Ankr (para acceso público a la red).
• Exploradores de Bloques: Parece que Somnia tenía un explorador de testnet ("Shannon") y presumiblemente un explorador de mainnet para rastrear transacciones y cuentas. Los exploradores son vitales para que los desarrolladores y usuarios depuren transacciones y verifiquen la actividad en la cadena.
• Safes (Multifirma): La documentación menciona "Safes", probablemente una integración con Safe (anteriormente Gnosis Safe) para billeteras de firma múltiple. Esto significa que las DAOs o los estudios de juegos en Somnia pueden usar billeteras multifirma seguras para gestionar su tesorería o activos en el juego. La integración de Safe es otra pieza de infraestructura que hace que Somnia esté lista para empresas y DAOs.
• Adaptadores de Billetera: Se admiten muchas billeteras Web3 populares. MetaMask puede conectarse a Somnia configurando el RPC de la red (la documentación guía a los usuarios para agregar la red de Somnia a MetaMask). Para una experiencia de usuario más fluida, Somnia trabajó con RainbowKit y ConnectKit (bibliotecas de React para conexiones de billetera), asegurando que los desarrolladores de DApps puedan permitir fácilmente a los usuarios conectarse con una variedad de billeteras. También hay una guía para usar Privy (una solución de billetera centrada en un inicio de sesión fácil de usar).
• Abstracción de Cuentas: A través del SDK de Thirdweb, Somnia soporta características de abstracción de cuentas. Por ejemplo, la Smart Wallet o el SDK de Abstracción de Cuentas de Thirdweb se pueden usar en Somnia, permitiendo meta-transacciones (UX sin gas) o billeteras con inicio de sesión social. La documentación describe explícitamente las transacciones sin gas con Thirdweb, lo que significa que las DApps pueden pagar el gas en nombre de los usuarios, una capacidad crítica para la adopción masiva, ya que los usuarios finales podrían ni siquiera necesitar tener SOMI para jugar un juego inicialmente.

Incorporación de Usuarios y Participación Comunitaria: El equipo de Somnia ha sido proactivo en el crecimiento de una comunidad tanto de desarrolladores como de usuarios finales:

• El Discord de Somnia es el centro neurálgico para los desarrolladores (con un chat de desarrollo dedicado y soporte del equipo central). Durante la testnet, los desarrolladores podían solicitar tokens de prueba (STT) a través de Discord para desplegar y probar sus contratos. Este canal de soporte directo ayudó a incorporar muchos proyectos.
• Para los usuarios finales, Somnia organizó eventos como la Somnia Quest y la Somnia Odyssey. La Quest fue una campaña en junio de 2025 donde los usuarios completaban tareas sociales y de testnet (como seguir en X, unirse a Discord, probar DApps) para ganar recompensas y subir en una tabla de clasificación. La Odyssey (mencionada en un blog el 9 de septiembre de 2025) fue una aventura de 60 días que probablemente condujo a la mainnet, donde los usuarios que interactuaban consistentemente con las aplicaciones de testnet o aprendían sobre Somnia podían desbloquear un airdrop. De hecho, el HODLer Airdrop de Binance el 1 de septiembre de 2025, distribuyó 30 millones de SOMI (3 % del suministro) a los usuarios de Binance que cumplían ciertos criterios. Este fue un evento importante de adquisición de usuarios, dando efectivamente a miles de usuarios de cripto una participación en Somnia y un incentivo para probar la red. El airdrop y varias misiones han ayudado a Somnia a construir una base de usuarios inicial y presencia en redes sociales (el Twitter de Somnia – ahora X – y otros canales han crecido rápidamente).
• Metaverse Browser: Como se mencionó, Somnia introdujo una aplicación especializada de Metaverse Browser. Es probable que sirva como una puerta de entrada fácil de usar donde alguien puede crear una billetera, navegar por las DApps de Somnia y entrar en eventos virtuales sin problemas. Tiene una billetera Web3 integrada y una interfaz simple para acceder a las DApps. Este tipo de experiencia curada podría facilitar la entrada de usuarios no cripto a la blockchain (por ejemplo, un jugador podría descargar el navegador de Somnia y unirse a un concierto virtual donde el navegador maneja la creación de la billetera y las transacciones de tokens de fondo).
• Programas de Aceleración para Desarrolladores: Cubrimos Dream Catalyst y Dreamthon en la sección de ecosistema, pero desde una perspectiva de infraestructura para desarrolladores, estos programas también aseguran que los nuevos desarrolladores tengan orientación y recursos. Dream Catalyst proporcionó no solo financiación, sino también herramientas de infraestructura y apoyo para la construcción de comunidades. Eso significa que los equipos participantes probablemente recibieron ayuda para integrar los SDKs de Somnia, optimizar sus contratos para la arquitectura de Somnia, etc.

En términos de documentación y recursos:

• Somnia ofrece un Lightpaper y un OnePager para resúmenes rápidos (enlazados en su sitio), y un Litepaper/whitepaper más detallado en la documentación (la sección de Conceptos que referenciamos cumple ese propósito).
• Tienen repositorios de ejemplo y plantillas de código (por ejemplo, cómo construir un DEX, cómo usar Subgraphs, cómo integrar billeteras, todo proporcionado en su GitBook oficial). Al proporcionar esto, Somnia reduce la barrera de entrada para los desarrolladores de otras cadenas que quieren poner algo en funcionamiento rápidamente.
• Auditorías: La documentación menciona una sección de Auditorías, lo que implica que el código de Somnia ha sido sometido a auditorías de seguridad de terceros. Aunque no se proporcionan detalles en nuestras fuentes, esta es una infraestructura importante: asegurar que el software del nodo y los contratos clave (como los de staking o tokens) estén auditados para proteger a desarrolladores y usuarios.

En general, la infraestructura para desarrolladores de Somnia parece bien pensada: compatibilidad con EVM para familiaridad, mejorada con APIs de datos personalizadas, abstracción de cuentas incorporada y un fuerte soporte para desarrolladores. Para los usuarios, la combinación de tarifas ultra bajas, posibles transacciones sin gas y aplicaciones especializadas (Metaverse Browser, misiones, etc.) tiene como objetivo proporcionar una experiencia de usuario de nivel Web2 en una plataforma Web3. El enfoque temprano de Somnia en la participación comunitaria (airdrops, misiones) muestra una mentalidad de growth-hacking: sembrar la red con contenido y usuarios para que los desarrolladores tengan una razón para construir, y viceversa. A medida que Somnia crezca, podemos esperar SDKs aún más refinados (quizás plugins para Unity/Unreal para desarrolladores de juegos) y mejoras continuas en las billeteras de usuario (quizás billeteras móviles nativas o inicios de sesión sociales). La financiación sustancial de la fundación asegura que tanto los desarrolladores como los usuarios serán apoyados con las herramientas que necesitan para prosperar en Somnia.

Casos de Uso y Aplicaciones​

Somnia está diseñada específicamente para permitir una nueva clase de aplicaciones descentralizadas que antes eran inviables debido a las limitaciones de la blockchain. Su alto rendimiento y baja latencia abren la puerta a experiencias en tiempo real y completamente en la cadena en diversos dominios:

• Juegos (GameFi): Este es el enfoque principal de Somnia. Con Somnia, los desarrolladores pueden construir juegos donde cada acción del juego (movimiento, combate, obtención de objetos, intercambios) puede ser registrada o ejecutada en la cadena en tiempo real. Esto significa verdadera propiedad de los activos del juego: los jugadores poseen sus personajes, skins, cartas o botín como NFTs/tokens en sus propias billeteras, no en la base de datos de una compañía de juegos. Economías de juego enteras pueden funcionar en la cadena, permitiendo características como recompensas de jugar para ganar, comercio de jugador a jugador sin intermediarios y modificaciones del juego impulsadas por la comunidad. Crucialmente, la capacidad de Somnia (más de 1M de TPS) y su rápida finalidad hacen que los juegos en la cadena sean responsivos. Por ejemplo, un RPG de acción en Somnia puede ejecutar miles de acciones de jugadores por segundo sin lag, o un juego de cartas coleccionables puede tener movimientos y barajados instantáneos en la cadena. La abstracción de cuentas y las bajas tarifas de Somnia también permiten que los juegos cubran potencialmente el gas para los jugadores, haciendo la experiencia fluida (los jugadores pueden ni siquiera darse cuenta de que hay una blockchain debajo). La plataforma prevé específicamente "juegos completamente en la cadena a escala de internet": mundos virtuales persistentes o MMOs donde el estado del juego vive en Somnia y continúa mientras la comunidad lo mantenga vivo. Debido a que los activos están en la cadena, un juego en Somnia podría incluso seguir evolucionando bajo el control de la comunidad si el desarrollador original se va, un concepto imposible en la Web2. Ejemplos actuales: Sparkball demuestra un brawler deportivo multijugador en la cadena; Chunked (la demostración tecnológica de Improbable) mostró un sandbox tipo Minecraft completamente en la cadena con interacciones de usuarios reales; Variance y Maelstrom mostrarán cómo experiencias más ricas de RPG y battle royale se traducen a la blockchain. La promesa final son juegos donde cientos de miles de jugadores juegan simultáneamente en un mundo compartido en la cadena, algo que Somnia está en una posición única para manejar.
• Redes Sociales y Medios Sociales Web3: Con Somnia, se podría construir una plataforma social descentralizada donde los perfiles de usuario, publicaciones, seguidores y "me gusta" son todos datos en la cadena bajo el control del usuario. Por ejemplo, una DApp tipo Twitter en Somnia podría almacenar cada tuit como un NFT de mensaje en la cadena y cada seguimiento como una relación en la cadena. En tal red, los usuarios son verdaderamente dueños de su contenido y su grafo social, que podría ser portado a otras aplicaciones fácilmente. La escala de Somnia significa que un feed social podría manejar la actividad viral (millones de publicaciones y comentarios) sin colapsar. Y la finalidad en menos de un segundo significa que las interacciones (publicar, comentar) aparecen casi instantáneamente, como los usuarios esperan en la Web2. Un beneficio de las redes sociales en la cadena es la resistencia a la censura (ninguna compañía puede eliminar tu contenido o prohibir tu cuenta) y la portabilidad de datos (podrías moverte a un frontend o cliente diferente y mantener tus seguidores/contenido porque está en un registro público). El equipo de Somnia menciona explícitamente redes sociales descentralizadas construidas sobre identidad soberana y grafos sociales portátiles como un caso de uso principal. También prevén una gobernanza de asamblea de usuarios donde los usuarios clave tienen voz (esto podría vincularse a cómo las redes sociales moderan el contenido de manera descentralizada). Un ejemplo temprano concreto son probablemente los foros comunitarios dentro de los juegos: por ejemplo, un juego en Somnia podría tener un chat de gremio en la cadena o un tablero de eventos descentralizado. Pero a largo plazo, Somnia podría albergar alternativas completas a Facebook o Twitter, especialmente para comunidades que valoran la libertad y la propiedad. Otro ángulo interesante son las plataformas propiedad de los creadores: imagina un servicio tipo YouTube en Somnia donde los NFTs de video representan el contenido y los creadores ganan directamente a través de microtransacciones o participación tokenizada. El rendimiento de Somnia podría manejar los metadatos y las interacciones (aunque el almacenamiento de video sería fuera de la cadena), y sus transacciones baratas permiten micro-propinas y recompensas en tokens por la creación de contenido.
• Metaverso y Mundos Virtuales: Somnia proporciona la infraestructura de identidad y económica para los metaversos. En la práctica, esto significa que las plataformas de mundos virtuales pueden usar Somnia para identidades de avatares, activos entre mundos y transacciones dentro de experiencias virtuales. Los estándares abiertos de MSquared para avatares/activos son compatibles con Somnia, por lo que el avatar 3D de un usuario o sus artículos de moda digital pueden representarse como tokens en Somnia y portarse a través de diferentes mundos. Por ejemplo, podrías tener un único NFT de avatar que usas en un concierto virtual, una reunión deportiva y un juego, todo en plataformas basadas en Somnia. A medida que Improbable orquesta eventos masivos (como fiestas para ver deportes virtuales, festivales de música, etc.), Somnia puede manejar la capa económica: acuñar POAPs (tokens de prueba de asistencia), vender mercancía virtual como NFTs, recompensar a los participantes con tokens y permitir el comercio entre pares en tiempo real durante los eventos. La capacidad de Somnia para soportar decenas de miles de usuarios concurrentes en un estado compartido (a través del consenso multi-stream) es crucial para escenarios de metaverso donde una gran multitud podría realizar transacciones o interactuar simultáneamente. El Virtual Ballpark de la MLB y los eventos de K-pop en 2023 (pre-Somnia) alcanzaron a miles de usuarios; con Somnia, esos usuarios podrían tener cada uno billeteras y activos, permitiendo cosas como un lanzamiento de NFT en vivo para todos en el "estadio" o un marcador de tokens en tiempo real para la participación en el evento. Esencialmente, Somnia puede sustentar una economía de metaverso persistente e interoperable: piénsalo como el libro mayor que registra quién posee qué a través de muchos mundos virtuales interconectados. Esto soporta casos de uso como bienes raíces virtuales (NFTs de tierra) que pueden ser comerciados o usados como garantía, recompensas de misiones entre mundos (completa un objetivo en el juego A, obtén un artículo utilizable en el mundo B), o incluso reputación de identidad (registros en la cadena de los logros o credenciales de un usuario a través de plataformas).
• Finanzas Descentralizadas (DeFi): Aunque Somnia se posiciona principalmente como una cadena para aplicaciones de consumo, su alto rendimiento abre algunas posibilidades de DeFi intrigantes. Por un lado, Somnia puede albergar comercio de alta frecuencia e instrumentos financieros complejos en la cadena. El equipo menciona específicamente libros de órdenes de límite completamente en la cadena. En Ethereum, los intercambios de libros de órdenes son imprácticos (demasiado lentos/caros), por lo que DeFi utiliza AMMs. Pero en Somnia, un DEX podría mantener un contrato inteligente de libro de órdenes y emparejar órdenes en tiempo real, al igual que un intercambio centralizado, porque la cadena puede manejar miles de operaciones por segundo. Esto podría traer funcionalidad y liquidez similares a las de un CEX a la cadena con transparencia y auto-custodia. Otra área es la gestión de riesgos en tiempo real: la velocidad de Somnia podría permitir derivados en la cadena que actualicen los requisitos de margen cada segundo, o libros de órdenes de opciones en vivo. Además, con su característica de almacenamiento transitorio, Somnia podría soportar cosas como contratos de seguro efímeros o pagos por streaming que existen solo por un corto período. Los protocolos DeFi en Somnia también podrían aprovechar su gas determinista para costos más predecibles. Por ejemplo, una plataforma de micro-préstamos en Somnia podría procesar factiblemente transacciones diminutas (como pagos de intereses de 0,01 $ cada minuto) porque las tarifas son fracciones de un céntimo. Así que Somnia podría potenciar microtransacciones y flujos de pago Web3 en DeFi y más allá (algo que Ethereum no puede hacer económicamente a escala). Además, la capacidad de Somnia para comprimir datos y agregar firmas podría permitir el procesamiento por lotes de miles de transferencias o intercambios en un solo bloque, impulsando aún más el rendimiento para casos de uso de DeFi como airdrops o pagos masivos. Aunque DeFi no es el enfoque de marketing, es probable que surja un ecosistema financiero eficiente en Somnia para apoyar los juegos y metaversos (por ejemplo, DEXes para tokens de juegos, mercados de préstamos para NFTs, etc.). Podríamos ver protocolos especializados, por ejemplo, un intercambio de fraccionamiento de NFT donde los artículos de juego pueden ser comerciados fraccionalmente; Somnia puede manejar la demanda explosiva si un artículo popular se dispara de repente.
• Identidad y Credenciales: La combinación de identidad soberana y alta capacidad de Somnia permite sistemas de identidad en la cadena que podrían usarse para autenticación, reputación y credenciales en Web3. Por ejemplo, un usuario podría tener un NFT de identidad o un token soulbound en Somnia que atestigüe sus logros (como "completó X misiones de juego" o "asistió a Y eventos" o incluso credenciales fuera de la cadena como títulos o membresías). Estos podrían usarse en múltiples aplicaciones. El grafo social portable de un usuario (quiénes son sus amigos, a qué comunidades pertenecen) puede almacenarse en Somnia y llevarse de un juego o plataforma social a otra. Esto es poderoso para romper los silos de la Web2: imagina cambiar de aplicación social pero mantener a tus seguidores, o un perfil de jugador que lleva tu historial a nuevos juegos (quizás ganándote ventajas de veterano). Con el modelo de gobernanza de Somnia incorporando una Asamblea de Usuarios (usuarios clave que proporcionan supervisión), también podríamos ver una gobernanza basada en la identidad donde los usuarios con participación probada tienen más voz en ciertas decisiones (todo aplicable en la cadena a través de esas credenciales). Otro caso de uso son las economías de creadores de contenido: un creador podría emitir su propio token o serie de NFT en Somnia para su base de fans, y estos podrían desbloquear el acceso a varias plataformas (videos, chats, eventos virtuales). Dado que Somnia puede manejar grandes volúmenes, un creador popular con millones de fans podría hacer un airdrop de insignias a todos ellos o manejar micro-propinas en tiempo real durante una transmisión en vivo.
• Servicios Web en Tiempo Real: En términos generales, Somnia puede actuar como un backend descentralizado para servicios que requieren respuestas instantáneas. Considera una aplicación de mensajería descentralizada donde los mensajes son eventos en la cadena: con finalidad en menos de un segundo, dos usuarios podrían chatear a través de Somnia y ver los mensajes aparecer casi instantáneamente e inmutablemente (quizás con encriptación en el contenido, pero marcas de tiempo y pruebas en la cadena). O un mercado en línea donde los pedidos y listados son contratos inteligentes: Somnia podría actualizar el inventario y las ventas en tiempo real, evitando el doble gasto de artículos y permitiendo intercambios atómicos de bienes por pago. Incluso las plataformas de streaming podrían integrar la blockchain para la gestión de derechos: por ejemplo, un servicio de streaming de música en Somnia podría gestionar los recuentos de reproducción de canciones y los micropagos de licencias a los artistas cada pocos segundos de reproducción (porque puede manejar transacciones pequeñas de alta frecuencia). En esencia, Somnia permite una interactividad de nivel Web2 con la confianza y propiedad de la Web3. Cualquier aplicación donde muchos usuarios interactúan simultáneamente (subastas, herramientas de colaboración multijugador, feeds de datos en vivo) podría descentralizarse en Somnia sin sacrificar el rendimiento.

Estado Actual de los Casos de Uso: A finales de 2025, los casos de uso más tangibles en vivo en Somnia giran en torno a juegos y coleccionables: varios juegos están en fase de prueba o acceso temprano en la red principal, y se están acuñando colecciones de NFT (avatares, activos de juego) en Somnia. La red ha facilitado con éxito enormes eventos de prueba (miles de millones de transacciones en la testnet, demostraciones a gran escala) demostrando que estos casos de uso no son solo teóricos. El siguiente paso es convertir esas pruebas en aplicaciones en vivo continuas con usuarios reales. Los primeros adoptantes como Sparkball y Variance serán pruebas de fuego importantes: si pueden atraer a miles de jugadores diarios en Somnia, veremos a la cadena mostrar realmente su poder y quizás atraer a aún más desarrolladores de juegos.

Las posibles aplicaciones futuras son emocionantes de considerar. Por ejemplo, proyectos a escala nacional o empresarial: un gobierno podría usar Somnia para emitir una identificación digital o manejar una elección en la cadena (millones de votos en segundos, con transparencia), o una bolsa de valores podría usarla para negociar valores tokenizados a alta frecuencia. La parte de InfoFi mencionada para Dreamthon insinúa cosas como un Reddit descentralizado o mercados de predicción (un número masivo de pequeñas apuestas y votos) que Somnia podría potenciar.

En resumen, los casos de uso de Somnia abarcan juegos, redes sociales, metaverso, DeFi, identidad y más, todos unidos por un hilo común: transacciones a escala masiva y en tiempo real con total confianza en la cadena. Su objetivo es llevar experiencias generalmente reservadas para servidores centralizados al ámbito descentralizado. Si Ethereum fue pionero en las finanzas descentralizadas, la ambición de Somnia es ser pionera en la vida descentralizada, desde el entretenimiento hasta las conexiones sociales, al ofrecer finalmente el rendimiento necesario para las aplicaciones de estilo masivo. A medida que la red madure, es probable que veamos nuevas innovaciones que aprovechen sus características únicas (por ejemplo, juegos que usan estado transitorio para simulaciones de física, o aplicaciones sociales que usan compresión de flujo para manejar millones de pequeñas acciones). El próximo año o dos revelarán cuáles de estas aplicaciones potenciales ganan tracción y demuestran la promesa de Somnia en el mundo real.

Panorama Competitivo​

Somnia entra en un abarrotado campo de Capa 1, pero se diferencia por su rendimiento extremo y su enfoque en aplicaciones de consumo completamente en la cadena. Así es como Somnia se compara con otras blockchains L1 prominentes:

En esencia, los análogos más cercanos de Somnia son Solana, Sui/Aptos, y quizás app-chains especializadas como ciertas subnets de Avalanche o las próximas cadenas de alto rendimiento de Polygon. Al igual que Solana, Somnia renuncia a la descentralización extrema en favor del rendimiento, pero Somnia se diferencia al mantenerse en la EVM (ayudándole a aprovechar la base de desarrolladores de Ethereum) y al introducir un consenso único de múltiples cadenas en lugar de un líder a la vez. El enfoque de Solana hacia el paralelismo (múltiples hilos de GPU procesando diferentes transacciones) contrasta con el enfoque de Somnia (múltiples validadores procesando cada uno diferentes flujos). Durante cargas correlacionadas (un contrato popular), la optimización de un solo núcleo de Somnia brilla, mientras que el paralelismo de Solana se vería limitado ya que todos los hilos compiten por el mismo estado.

En comparación con la mainnet de Ethereum, Somnia es órdenes de magnitud más rápida pero sacrifica la descentralización (100 validadores frente a los cientos de miles de Ethereum). Ethereum también tiene un ecosistema mucho más grande y probado en batalla. Sin embargo, Ethereum no puede manejar directamente juegos o aplicaciones sociales a escala; esos terminan en L2s o sidechains. Somnia se posiciona esencialmente como una alternativa a un rollup de Ethereum, una que es su propia L1 con un rendimiento superior a cualquier rollup actual y sin necesidad de pruebas de fraude o suposiciones de seguridad separadas (aparte de su conjunto de validadores más pequeño). A largo plazo, la hoja de ruta de Ethereum (sharding, danksharding, etc.) aumentará el rendimiento pero probablemente no a millones de TPS en la L1. En cambio, Ethereum apuesta por los rollups; Somnia apuesta por escalar la L1 misma con ingeniería avanzada. Puede que no compitan por los mismos casos de uso inicialmente (DeFi podría quedarse en Ethereum/L2, mientras que los juegos van a Somnia o cadenas similares). La interoperabilidad (a través de LayerZero u otros) podría permitirles complementarse, con activos moviéndose entre Ethereum y Somnia según sea necesario.

Avalanche ofrece subnets que, como Somnia, pueden dedicarse a juegos con alto rendimiento. La diferencia es que cada subnet de Avalanche es una instancia separada (tendrías que poner en marcha tus propios validadores o reclutar algunos para que se unan). Somnia, en cambio, proporciona una cadena de alta capacidad compartida, lo que facilita la interoperabilidad entre aplicaciones (todas las aplicaciones de Somnia viven en una cadena, componibles, como en Ethereum o Solana). La subnet principal de Avalanche (C-Chain) es EVM pero mucho más lenta que Somnia. Así que Somnia supera con creces a la cadena común de Avalanche, aunque Avalanche puede escalar si un proyecto crea una subnet personalizada (pero entonces esa subnet podría no tener la componibilidad general completa o la base de usuarios). Para un desarrollador, desplegar en Somnia podría ser más simple que gestionar una subnet de Avalanche, y aprovechas inmediatamente el grupo de usuarios y la liquidez compartidos de Somnia.

Sui (y Aptos) a menudo se citan como cadenas de alto TPS de próxima generación, utilizando Move y consenso paralelo. La ventaja de Somnia sobre Sui es el rendimiento (Sui no ha demostrado millones de TPS; su diseño está quizás en los cientos de miles bajos en el mejor de los casos) y la compatibilidad con EVM. La ventaja de Sui podría ser la seguridad de Move para la lógica de activos complejos y posiblemente una hoja de ruta más descentralizada (aunque en el lanzamiento Sui también tenía alrededor de 100 validadores). Si Somnia captura a los estudios de juegos que prefieren usar Solidity (quizás portando contratos de Solidity de prototipos de juegos de Ethereum), podría superar a Sui en ecosistema rápidamente, dado lo grande que es la comunidad de desarrolladores de Solidity.

Somnia también se compara con Solana en su objetivo de Web3 de consumo (ambos han enfatizado las integraciones sociales y telefónicas: Solana tuvo un teléfono Saga, Somnia un navegador, etc.). La audaz afirmación de Herman Narula de que Somnia puede hacer "miles de veces el rendimiento de Solana" establece el tono de que Somnia se ve a sí misma no solo como otra cadena rápida, sino como la cadena EVM más rápida donde Solana es la cadena no EVM más rápida. Si Somnia ofrece incluso un orden de magnitud mejor de TPS sostenido que Solana en la práctica (digamos que Solana hace 5k TPS de promedio y Somnia podría hacer 50k o más de promedio con picos en los millones), realmente se abrirá un nicho para aplicaciones que incluso Solana no puede manejar (por ejemplo, un juego de blockchain a escala de Fortnite o una red social a escala global).

Un competidor más a tener en cuenta es Polygon 2.0 o los zkEVMs: aunque no son L1s, ofrecen escalado para EVM. Polygon está trabajando en una serie de ZK-rollups y cadenas de alto rendimiento. Esos podrían potencialmente igualar parte del rendimiento de Somnia mientras se benefician de la seguridad de Ethereum. Sin embargo, los ZK-rollups con 1M de TPS aún no existen, e incluso entonces, podrían enfrentar límites de disponibilidad de datos. El enfoque de Somnia es una solución todo en uno con su propia seguridad. Tendrá que demostrar que su seguridad (100 validadores PoS) es lo suficientemente robusta para aplicaciones de mucho dinero, algo que los rollups de Ethereum heredan inherentemente de ETH. Pero para juegos y redes sociales, donde los requisitos de seguridad son ligeramente diferentes (robar una espada de juego NFT no es tan catastrófico como robar miles de millones en TVL de DeFi), el compromiso de Somnia podría ser perfectamente aceptable e incluso preferible debido a la experiencia del usuario.

En conclusión, Somnia se destaca por llevar el rendimiento más allá que cualquier L1 de propósito general actual, manteniendo la familiaridad de la EVM. Su objetivo es ocupar un espacio en el mercado para "Web3 a escala Web2" que otros solo han abordado parcialmente:

• Ethereum dominará la confianza y DeFi, pero delegará las tareas de alta frecuencia a las L2 (que añaden complejidad y fragmentación).
• Solana mostró un alto TPS para DeFi y NFTs, pero no es EVM y tuvo problemas de estabilidad; Somnia podría atraer proyectos que quieren una velocidad similar a la de Solana con las herramientas de Ethereum.
• Avalanche ofrece personalización y comodidad EVM, pero no ha demostrado un rendimiento de cadena única cercano al de Somnia.
• Sui/Aptos están en la misma generación que Somnia, compitiendo por los desarrolladores de juegos, pero las asociaciones tempranas de Somnia (Improbable, grandes marcas) y la compatibilidad con EVM le dan una fuerte ventaja si se ejecuta bien.

Como dijo Narula, Somnia es posiblemente la primera cadena construida específicamente para experiencias virtuales en tiempo real a escala masiva. Si esas experiencias (juegos, eventos, mundos sociales) se convierten en la próxima gran ola de adopción de blockchain, la competencia de Somnia podría ser en realidad la infraestructura de nube tradicional (AWS, etc.) tanto como otras blockchains, porque está tratando de reemplazar los servidores de juegos centralizados y las bases de datos sociales, no solo competir por las aplicaciones de blockchain existentes. En ese sentido, el éxito de Somnia se medirá por si puede albergar aplicaciones que atraigan a millones de usuarios que quizás ni siquiera sepan (o les importe) que una blockchain está funcionando por debajo. Ninguna L1 actual ha alcanzado aún ese nivel de aplicación de usuario masivo (incluso las aplicaciones más grandes de Solana tienen cientos de miles, no millones de usuarios activos). Esa es la vara que Somnia se ha puesto, y contra la cual su innovadora arquitectura será probada en los próximos años.

Hoja de Ruta y Estado Actual​

El viaje de Somnia ha progresado rápidamente del concepto a la realidad en poco tiempo, y continúa evolucionando después de la mainnet con objetivos claros:

Desarrollos Recientes (2024–2025):

• Financiación y Testnet (2024): El proyecto surgió del sigilo respaldado por una financiación significativa. A principios de 2024, Improbable anunció el compromiso de 270 millones de dólares para el ecosistema de Somnia y MSquared. Esto proporcionó una enorme pista de despegue. Somnia ejecutó una Devnet a finales de 2024 (noviembre) donde batió récords: alcanzó 1.05 millones de TPS y otros benchmarks en una configuración global de 100 nodos. Esos resultados (incluyendo 50k intercambios de Uniswap/seg, 300k acuñaciones de NFT/seg) se publicitaron para construir credibilidad. Después de la Devnet, se lanzó una Testnet totalmente pública el 20 de febrero de 2025. La testnet (nombre en clave Shannon) funcionó durante unos 6 meses. Durante ese tiempo, Somnia afirma haber procesado más de 10 mil millones de transacciones e incorporado 118 millones de direcciones de billetera de prueba, cifras asombrosas. Estos números probablemente incluyen pruebas de carga programadas y participación de la comunidad. La testnet también vio un rendimiento diario máximo de 1.9 mil millones de transacciones en un día (un récord para cualquier contexto EVM). CoinDesk señaló estas cifras pero también que el explorador público estaba fuera de línea en ese momento para verificar, lo que implica que algunas de estas eran métricas internas. No obstante, la testnet demostró estabilidad bajo una carga sin precedentes.

  A lo largo de la testnet, Somnia ejecutó programas de participación: un programa de incentivos de Puntos donde los primeros usuarios que completaban tareas podían ganar puntos (probablemente convertibles en futuros tokens o recompensas), y colaboró con socios (los desarrolladores de juegos hicieron pruebas de juego, se celebraron hackathons). La fase de testnet también fue cuando se incorporaron más de 70 socios/proyectos del ecosistema. Esto indica que para la mainnet, muchas integraciones y aplicaciones estaban listas o casi listas.

• Lanzamiento de la Mainnet (Q3 2025): Somnia lanzó la mainnet el 2 de septiembre de 2025. El lanzamiento incluyó la liberación del token SOMI y la habilitación del staking. Notablemente, en la mainnet:

  • 60 validadores se pusieron en línea (con grandes nombres como Google Cloud entre ellos).
  • La Fundación Somnia está operativa, supervisando la cadena como un administrador neutral. Improbable entregó la tecnología y ahora la Fundación (también conocida como la Fundación de la Sociedad Virtual) está a cargo de la gobernanza y el desarrollo futuro.
  • Listado y distribución de SOMI: A un día del lanzamiento, Binance reveló a SOMI como parte de sus listados "Seed Tag" y realizó el airdrop HODLer. Esto fue un gran impulso, efectivamente un respaldo de un exchange de primer nivel. Muchas nuevas L1s luchan por conseguir tracción en los exchanges, pero Somnia inmediatamente puso SOMI en manos de los usuarios a través de Binance.
  • En las redes sociales, el equipo de Somnia y sus socios promocionaron las capacidades de la mainnet. Un comunicado de prensa de Improbable y la cobertura en medios como CoinDesk, Yahoo Finance, etc., difundieron la noticia de que "la cadena EVM más rápida" está en vivo.
  • Las dApps iniciales del ecosistema comenzaron su despliegue. Por ejemplo, el puente de NFT a través de LayerZero estaba activo (se podían puentear stablecoins según la documentación), y algunos de los juegos de la testnet comenzaron a moverse a la mainnet (el lanzamiento de Sparkball, etc., alrededor de septiembre según lo indicado por blogs y actualizaciones).
  • Los eventos de airdrop comunitarios (la Somnia Odyssey) probablemente culminaron alrededor del lanzamiento, distribuyendo parte de esa asignación de tokens de la Comunidad a los primeros partidarios.

En resumen, el lanzamiento de la mainnet fue exitoso y posicionó a Somnia con validadores en vivo, un token en vivo y más de 70 proyectos en vivo o a punto de lanzarse. Es importante destacar que llegaron al mercado justo cuando el interés en los juegos Web3 y el metaverso estaba repuntando a finales de 2025, aprovechando esa tendencia.

Estado Actual (Finales de 2025): La mainnet de Somnia está operativa con bloques en menos de un segundo. La red todavía está en una fase de arranque donde la Fundación Somnia y el equipo central mantienen un control significativo para garantizar la estabilidad. Por ejemplo, es probable que las propuestas de gobernanza aún no estén completamente abiertas; la fundación probablemente está gestionando las actualizaciones y los ajustes de parámetros mientras se educa a la comunidad sobre los procesos de gobernanza. La distribución de tokens todavía está muy concentrada (ya que solo circula ~16 % y los tokens de inversores/equipo no comenzarán a desbloquearse hasta finales de 2026). Esto significa que la Fundación tiene amplias reservas de tokens para apoyar el ecosistema (a través de subvenciones, provisión de liquidez, etc.).

En el frente técnico, Somnia probablemente está monitoreando y ajustando el rendimiento en condiciones reales. ¿Las dApps reales la están llevando a sus límites? Posiblemente aún no; los recuentos iniciales de usuarios probablemente están en los miles, no en los millones. Así que puede que no haya 1M de TPS ocurriendo regularmente en la mainnet, pero la capacidad está ahí. El equipo podría usar este período para optimizar el software del cliente, incorporar cualquier retroalimentación de Cuthbert (si se encontraron divergencias, se corregirían rápidamente) y reforzar la seguridad. Los resultados de las auditorías de seguridad (si no se han publicado ya) podrían publicarse en este momento o a principios de 2026 para asegurar a los desarrolladores la seguridad.

Hoja de Ruta a Corto Plazo (2026): La documentación y las comunicaciones de Somnia insinúan varios objetivos a corto plazo:

• Lanzamiento de Características: Se planeó activar algunas características después del lanzamiento:
  • La Fijación de Precios de Gas Dinámica y los Descuentos por Volumen están programados para implementarse a finales de 2025. Esto requiere algunas pruebas y quizás la aprobación de la gobernanza para activarse. Una vez habilitado, las dApps de alto rendimiento comenzarán a disfrutar de un gas más barato, lo que podría ser un punto de venta para atraer a socios empresariales o grandes de la Web2.
  • La característica de Almacenamiento Transitorio también está programada para finales de 2025. La implementación probablemente necesita ser probada cuidadosamente (asegurando que la eliminación de datos funcione correctamente y no introduzca problemas de consenso). Cuando esto se active, Somnia será una de las primeras cadenas en ofrecer datos en la cadena con caducidad, lo que será enorme para los desarrolladores de juegos (imagina sesiones de juego temporales en la cadena).
  • Propinas (tarifas de prioridad): Señalaron que las propinas podrían introducirse más tarde si fuera necesario. Si el uso de la red aumenta hasta el punto en que los bloques están consistentemente llenos, para 2026 podrían habilitar propinas opcionales para priorizar transacciones (al igual que el modelo de tarifa base y propina de Ethereum). Esto sería una señal de congestión saludable si sucede.
  • Expansión del Conjunto de Validadores: Inicialmente ~60, el objetivo es aumentar el número de validadores con el tiempo para mejorar la descentralización sin perjudicar el rendimiento. Mencionaron que esperan un crecimiento más allá de 100 a medida que la red madure. El cronograma podría depender de qué tan bien escale el consenso con más validadores (PBFT tiende a volverse más lento a medida que aumentan los validadores, pero quizás su variante inspirada en Autobahn pueda manejar unos pocos cientos). En 2026, podrían incorporar validadores adicionales, posiblemente de su comunidad o nuevos socios. Esto podría hacerse a través de votos de gobernanza (poseedores de tokens aprobando nuevos validadores) o automáticamente si hay suficiente stake respaldando a los nuevos participantes.
  • Descentralización de la Gobernanza: Somnia estableció una hoja de ruta de Descentralización Progresiva en la gobernanza. En los primeros 6 meses (fase de arranque), la junta de la Fundación tiene el control total. Así que aproximadamente hasta el Q1/Q2 de 2026, estaremos en arranque, durante el cual probablemente refinen los procesos e incorporen miembros a los consejos. Luego, de 6 a 24 meses (mediados de 2026 a finales de 2027), entran en la fase de Transición donde la Casa del Token (poseedores de tokens) puede comenzar a votar sobre propuestas, aunque la Fundación puede vetar si es necesario. Podríamos ver los primeros votos en la cadena en 2026 para cosas como asignaciones de subvenciones o cambios menores de parámetros. Para el año 2 (2027), el objetivo es la fase Madura donde las decisiones de los poseedores de tokens se mantienen en su mayoría y la Fundación solo realiza intervenciones de emergencia. Así que para 2026, un objetivo clave es establecer esos órganos de gobernanza: posiblemente elegir miembros para el Consejo de Validadores, el Consejo de Desarrolladores, la Asamblea de Usuarios que se describieron. Esto implicará organización comunitaria, probablemente algo que la Fundación facilitará seleccionando miembros de buena reputación inicialmente (por ejemplo, invitando a los mejores desarrolladores de juegos a un consejo de desarrolladores, o a grandes líderes de gremios comunitarios a una asamblea de usuarios).
• Crecimiento del Ecosistema: En el frente de la adopción, 2026 se tratará de convertir proyectos piloto en éxitos masivos:
  • Esperamos lanzamientos completos de juegos: Sparkball y Variance podrían pasar de beta a lanzamiento oficial en la mainnet de Somnia en 2026, con el objetivo de atraer a decenas de miles de jugadores. Otros juegos de la cohorte de Dream Catalyst (Maelstrom, Netherak, Dark Table, etc.) probablemente se lanzarán al público. El equipo de Somnia apoyará estos lanzamientos, posiblemente a través de campañas de marketing, torneos y programas de incentivos (como jugar para ganar o airdrops) para atraer a los jugadores.
  • Nuevas asociaciones: Improbable/MSquared planeaba escalar de 30 eventos en 2023 a más de 300 eventos de metaverso en 2024. En 2024 hicieron muchos eventos fuera de la cadena; en 2025/2026, esperamos que esos eventos integren Somnia. Por ejemplo, quizás un evento deportivo importante o un festival de música en 2026 use Somnia para la venta de entradas o recompensas para los fans. La participación de Google Cloud sugiere posibles eventos empresariales o exhibiciones a través de los clientes de la nube de Google. Además, dado que Mirana (asociada con Bybit/BitDAO) y otros invirtieron, Somnia podría ver colaboraciones con exchanges o grandes marcas de Web3 para utilizar la red.
  • Integración de MSquared: El comunicado de prensa de Chainwire señaló que M² planea integrar Somnia en su red de metaversos. Eso significa que cualquier mundo virtual que use la tecnología de MSquared podría adoptar Somnia como su capa de transacciones. Para 2026, podríamos ver a MSquared lanzar formalmente su red de metaverso con Somnia sustentando la identidad de los avatares, el comercio de artículos, etc. Si Otherside de Yuga Labs sigue en marcha, quizás ocurra una demostración de interoperabilidad con Somnia (por ejemplo, usar tu NFT de Otherside en un mundo impulsado por Somnia).
  • Expansión de la Comunidad de Desarrolladores: Los 10 millones de dólares en subvenciones se distribuirán con el tiempo; para 2026, es probable que docenas de proyectos hayan recibido financiación. El resultado de eso podría ser más herramientas (digamos, un SDK de Unity para Somnia, o más mejoras en Ormi), más aplicaciones (quizás alguien construya un Twitter descentralizado basado en Somnia o una nueva plataforma DeFi). Somnia probablemente celebrará más hackathons (potencialmente algunos en persona en conferencias, etc.) y continuará con un devrel agresivo para atraer talento. Podrían dirigirse especialmente a los desarrolladores de Ethereum que están alcanzando los límites de escalado con sus dApps, ofreciéndoles un puerto fácil a Somnia.
  • Interoperabilidad y Puentes: Ya integrada con LayerZero, Somnia probablemente expandirá los puentes a otros ecosistemas para un soporte de activos más amplio. Por ejemplo, la integración con Polygon o Cosmos IBC podría estar sobre la mesa. Además, se podrían buscar estándares entre cadenas para NFTs (quizás permitiendo que los NFTs de Ethereum se reflejen en Somnia para su uso en juegos). Dado que Somnia es EVM, desplegar contratos de puente para tokens populares (USDC, USDT, WETH) es sencillo; 2026 podría ver una liquidez más profunda a medida que más de estos activos entre cadenas fluyan.
  • Monitoreo del Rendimiento: A medida que llegue más uso real, el equipo monitoreará cualquier problema de estabilidad. ¿Hay algún vector de ataque (spam en muchas cadenas de datos, etc.)? Podrían implementar refinamientos como límites de tasa por cadena de datos u optimizaciones adicionales si es necesario. La ejecución dual de Cuthbert probablemente se ejecutará al menos hasta 2026 para detectar cualquier divergencia; si el sistema demuestra ser muy estable, podrían considerar apagarlo para reducir la sobrecarga después de un año o dos, pero eso depende de la confianza total.
• Marketing y Divulgación: Con la mainnet y las aplicaciones iniciales en vivo, el desafío de Somnia para 2026 es construir una base de usuarios. Se espera un marketing intenso dirigido tanto a jugadores como a usuarios de cripto:
  • Podríamos ver asociaciones con gremios de juegos o equipos de esports, para atraer jugadores a los juegos de Somnia.
  • Quizás colaboraciones con celebridades para eventos virtuales (dado que hicieron K-Pop y leyendas del deporte en eventos de prueba, podrían escalar eso; imagina a un músico famoso lanzando un álbum a través de un espectáculo en el metaverso de Somnia con merchandising NFT).
  • Además, asistir y patrocinar conferencias importantes (GDC para desarrolladores de juegos, Consensus para cripto, etc.) para promover la plataforma.
  • A finales de 2025, ya tenían una prensa significativa (artículo de Binance Academy, cobertura de CoinDesk, etc.). En 2026, saldrán más análisis independientes (perfiles de Messari, etc.), y Somnia querrá mostrar métricas de uso para demostrar tracción (como "X usuarios activos diarios, Y transacciones procesadas").

Visión a Largo Plazo: Aunque no se preguntó explícitamente, vale la pena señalar la trayectoria de Somnia:

• En unos pocos años, imaginan a Somnia como una capa base ampliamente utilizada para el entretenimiento Web3, con miles de millones de transacciones como rutina, y una gobernanza descentralizada dirigida por su comunidad y consejos. También es probable que prevean una mejora técnica continua: por ejemplo, explorar el sharding si es necesario, o adoptar nueva criptografía (quizás pruebas zk para comprimir datos aún más, o criptografía post-cuántica eventualmente).
• Otro objetivo a largo plazo podría ser la neutralidad de carbono o la eficiencia: las cadenas de alto TPS a menudo se preocupan por el uso de energía. Si Somnia alcanza millones de TPS, será importante asegurar que los nodos puedan manejarlo de manera eficiente (quizás a través de aceleración de hardware o escalado en la nube). Con Google Cloud en la mezcla, quizás se podrían considerar iniciativas de centros de datos verdes o hardware especial (como GPUs o FPGAs para la compresión).
• Para entonces, la competencia también habrá aumentado (Ethereum 2.0 con sharding, zkEVMs, mejoras de Solana, etc.). Somnia tendrá que mantener su ventaja a través de la innovación y los efectos de red (si captura una gran base de jugadores temprano, ese impulso puede llevarla adelante).

En resumen, la hoja de ruta para los próximos 1-2 años se centra en:

1. Activar características clave del protocolo (descuentos de gas, almacenamiento transitorio) para ofrecer completamente la funcionalidad prometida.
2. Descentralizar la gobernanza gradualmente, pasando de ser dirigida por la fundación a ser dirigida por la comunidad sin poner en peligro el progreso.
3. Impulsar el crecimiento del ecosistema: asegurar que los proyectos financiados se lancen y atraigan usuarios, forjar nuevas asociaciones (con creadores de contenido, estudios de juegos, quizás incluso empresas Web2 interesadas en Web3), y posiblemente expandirse a más regiones y comunidades.
4. Mantener el rendimiento y la seguridad a medida que el uso escala: vigilar cualquier problema cuando, por ejemplo, un juego impulse un pico de 10k TPS de tráfico real, y responder en consecuencia (esto podría incluir la ejecución de más eventos de prueba públicos, quizás un evento de "prueba de estrés de la Mainnet" donde se alienten toneladas de transacciones para probar los límites).

Somnia ha hecho un debut espectacular, pero 2026 será el campo de pruebas: necesita convertir su impresionante tecnología y su ecosistema bien financiado en una adopción real y una red sostenible y descentralizada. La gran tesorería de tokens de la fundación (Ecosistema y Comunidad ~55 % del suministro) le da los medios para impulsar la actividad durante años, por lo que a corto plazo veremos esos tokens en uso, a través de airdrops, recompensas (posiblemente minería de liquidez si se lanza un DEX), recompensas para desarrolladores y campañas de adquisición de usuarios. El eslogan del lanzamiento de la mainnet de Improbable fue que Somnia "marca la fundación de una economía de activos digitales abierta, donde miles de millones de personas pueden interactuar a través de experiencias inmersivas". Los siguientes pasos en la hoja de ruta consisten en sentar las bases de esa fundación: conseguir que los primeros millones de personas y las primeras aplicaciones estrella interactúen con la "computadora de los sueños" de Somnia (como la apodan), y así validar que la Web3 puede, de hecho, operar a escala de internet.

Si Somnia continúa en su trayectoria actual, para finales de 2026 podríamos ver docenas de juegos y plataformas sociales completamente en la cadena en funcionamiento, una red floreciente dirigida por la comunidad con cientos de validadores, y a SOMI siendo utilizado diariamente por usuarios convencionales (a menudo sin saberlo, bajo el capó de los juegos). Lograr eso marcaría un hito significativo no solo para Somnia, sino para el impulso de la industria de la blockchain hacia aplicaciones masivas y en tiempo real. Las piezas están en su lugar; ahora se trata de la ejecución y la adopción en esta fase crítica de la hoja de ruta del proyecto, impulsada por una profunda investigación.

Fuentes:

• Somnia Official Documentation (Litepaper & Technical Concepts)
• Somnia Tokenomics and Governance Docs
• Improbable Press Release (Mainnet Launch)
• CoinDesk Coverage of Somnia Launch
• Binance Academy – What is Somnia (SOMI)
• Gam3s.gg – Coverage of Somnia Games (Variance, Sparkball, etc.)
• Stakin Research – Introduction to Somnia
• Chainwire Press Release – $270M Investment & Devnet results
• Somnia Blog – Improbable & MSquared Events, Mainnet News
• Official Somnia Docs – Developer Guides (bridging, wallets, etc.)

La privacidad se está convirtiendo en infraestructura pública. En 2025, los desarrolladores necesitan herramientas que hagan la encriptación tan fácil como almacenar datos. Seal de Mysten Labs proporciona exactamente eso: gestión de secretos descentralizada con control de acceso onchain. Este tutorial te enseñará cómo construir aplicaciones Web3 seguras usando encriptación basada en identidad, seguridad threshold y políticas de acceso programables.

Introducción: Por Qué Seal Importa para Web3​

Las aplicaciones cloud tradicionales dependen de sistemas centralizados de gestión de claves donde un solo proveedor controla el acceso a datos encriptados. Aunque esto es conveniente, crea peligrosos puntos únicos de falla. Si el proveedor se ve comprometido, se desconecta o decide restringir el acceso, tus datos se vuelven inaccesibles o vulnerables.

Seal cambia completamente este paradigma. Construido por Mysten Labs para la blockchain Sui, Seal es un servicio de gestión de secretos descentralizada (DSM) que permite:

• Encriptación basada en identidad donde el contenido se protege antes de salir de tu entorno
• Encriptación threshold que distribuye el acceso a claves entre múltiples nodos independientes
• Control de acceso onchain con bloqueos temporales, token-gating y lógica de autorización personalizada
• Diseño agnóstico de almacenamiento que funciona con Walrus, IPFS o cualquier solución de almacenamiento

Ya sea que estés construyendo aplicaciones de mensajería segura, plataformas de contenido con acceso restringido o transferencias de activos con bloqueo temporal, Seal proporciona las primitivas criptográficas y la infraestructura de control de acceso que necesitas.

Primeros Pasos​

Prerrequisitos​

Antes de comenzar, asegúrate de tener:

• Node.js 18+ instalado
• Familiaridad básica con TypeScript/JavaScript
• Una wallet de Sui para pruebas (como Sui Wallet)
• Comprensión de conceptos blockchain

Instalación​

Instala el SDK de Seal vía npm:

npm install @mysten/seal

También querrás el SDK de Sui para interacciones blockchain:

npm install @mysten/sui

Configuración del Proyecto​

Crea un nuevo proyecto e inicialízalo:

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

Crea una configuración simple de TypeScript:

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

Conceptos Fundamentales: Cómo Funciona Seal​

Antes de escribir código, entendamos la arquitectura de Seal:

1. Encriptación Basada en Identidad (IBE)​

A diferencia de la encriptación tradicional donde encriptas a una clave pública, IBE te permite encriptar a una identidad (como una dirección de email o dirección Sui). El destinatario solo puede desencriptar si puede probar que controla esa identidad.

2. Encriptación Threshold​

En lugar de confiar en un solo servidor de claves, Seal usa esquemas threshold t-de-n. Podrías configurar 3-de-5 servidores de claves, significando que cualquier 3 servidores pueden cooperar para proporcionar claves de desencriptación, pero 2 o menos no pueden.

3. Control de Acceso Onchain​

Las políticas de acceso son aplicadas por smart contracts de Sui. Antes de que un servidor de claves proporcione claves de desencriptación, verifica que el solicitante cumpla con los requisitos de política onchain (propiedad de tokens, restricciones temporales, etc.).

4. Red de Servidores de Claves​

Los servidores de claves distribuidos validan políticas de acceso y generan claves de desencriptación. Estos servidores son operados por diferentes partes para asegurar que no haya un punto único de control.

Implementación Básica: Tu Primera Aplicación Seal​

Construyamos una aplicación simple que encripte datos sensibles y controle el acceso a través de políticas blockchain de Sui.

Paso 1: Inicializar el Cliente Seal​

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
  // Inicializar cliente Sui para testnet
  const suiClient = new SuiClient({
    url: 'https://fullnode.testnet.sui.io'
  });

  // Configurar cliente Seal con servidores de claves de testnet
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      'https://keyserver1.seal-testnet.com',
      'https://keyserver2.seal-testnet.com',
      'https://keyserver3.seal-testnet.com'
    ],
    threshold: 2, // threshold 2-de-3
    network: 'testnet'
  });

  return { sealClient, suiClient };
}

Paso 2: Encriptación/Desencriptación Simple​

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
  const { sealClient } = await createSealClient();

  // Datos a encriptar
  const sensitiveData = "¡Este es mi mensaje secreto!";
  const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // Encriptar datos para una dirección Sui específica
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, 'utf-8'),
      recipientId: recipientAddress,
      // Opcional: agregar metadata
      metadata: {
        contentType: 'text/plain',
        timestamp: Date.now()
      }
    });

    console.log('Datos encriptados:', {
      ciphertext: encryptedData.ciphertext.toString('base64'),
      encryptionId: encryptedData.encryptionId
    });

    // Más tarde, desencriptar los datos (requiere autorización apropiada)
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress
    });

    console.log('Datos desencriptados:', decryptedData.toString('utf-8'));

  } catch (error) {
    console.error('Encriptación/desencriptación falló:', error);
  }
}

basicExample();

Control de Acceso con Smart Contracts de Sui​

El verdadero poder de Seal viene del control de acceso programable. Creemos un ejemplo de encriptación con bloqueo temporal donde los datos solo pueden ser desencriptados después de un tiempo específico.

Paso 1: Desplegar Contrato de Control de Acceso​

Primero, necesitamos un smart contract Move que defina nuestra política de acceso:

// contracts/time_lock.move
module time_lock::policy {
    use sui::clock::{Self, Clock};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    public struct TimeLockPolicy has key, store {
        id: UID,
        unlock_time: u64,
        authorized_user: address,
    }

    public fun create_time_lock(
        unlock_time: u64,
        authorized_user: address,
        ctx: &mut TxContext
    ): TimeLockPolicy {
        TimeLockPolicy {
            id: object::new(ctx),
            unlock_time,
            authorized_user,
        }
    }

    public fun can_decrypt(
        policy: &TimeLockPolicy,
        user: address,
        clock: &Clock
    ): bool {
        let current_time = clock::timestamp_ms(clock);
        policy.authorized_user == user && current_time >= policy.unlock_time
    }
}

Paso 2: Integrar con Seal​

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
  const { sealClient, suiClient } = await createSealClient();

  // Crear política de acceso en Sui
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // Desbloquear en 1 minuto
  const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  txb.moveCall({
    target: 'time_lock::policy::create_time_lock',
    arguments: [
      txb.pure(unlockTime),
      txb.pure(authorizedUser)
    ]
  });

  // Ejecutar transacción para crear política
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // Tu keypair de Sui
  });

  const policyId = result.objectChanges?.find(
    change => change.type === 'created'
  )?.objectId;

  // Ahora encriptar con esta política
  const sensitiveData = "¡Esto se desbloqueará en 1 minuto!";

  const encryptedData = await sealClient.encrypt({
    data: Buffer.from(sensitiveData, 'utf-8'),
    recipientId: authorizedUser,
    accessPolicy: {
      policyId,
      policyType: 'time_lock'
    }
  });

  console.log('Datos con bloqueo temporal creados. Intenta desencriptar después de 1 minuto.');

  return {
    encryptedData,
    policyId,
    unlockTime
  };
}

Ejemplos Prácticos​

Ejemplo 1: Aplicación de Mensajería Segura​

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
  private sealClient: any;

  constructor(sealClient: any) {
    this.sealClient = sealClient;
  }

  async sendMessage(
    message: string,
    recipientAddress: string,
    senderKeypair: any
  ) {
    const messageData = {
      content: message,
      timestamp: Date.now(),
      sender: senderKeypair.toSuiAddress(),
      messageId: crypto.randomUUID()
    };

    const encryptedMessage = await this.sealClient.encrypt({
      data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
      recipientId: recipientAddress,
      metadata: {
        type: 'secure_message',
        sender: senderKeypair.toSuiAddress()
      }
    });

    // Almacenar mensaje encriptado en almacenamiento descentralizado (Walrus)
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // Recuperar del almacenamiento
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // Desencriptar con Seal
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    return JSON.parse(decryptedData.toString('utf-8'));
  }

  private async storeOnWalrus(data: any) {
    // Integración con almacenamiento Walrus
    // Esto subiría los datos encriptados a Walrus
    // y devolvería el blob ID para recuperación
  }

  private async retrieveFromWalrus(blobId: string) {
    // Recuperar datos encriptados de Walrus usando blob ID
  }
}

Ejemplo 2: Plataforma de Contenido con Token-Gating​

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
  private sealClient: any;
  private suiClient: any;

  constructor(sealClient: any, suiClient: any) {
    this.sealClient = sealClient;
    this.suiClient = suiClient;
  }

  async createGatedContent(
    content: string,
    requiredNftCollection: string,
    creatorKeypair: any
  ) {
    // Crear política de propiedad NFT
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair
    );

    // Encriptar contenido con requisito de acceso NFT
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, 'utf-8'),
      recipientId: 'nft_holders', // Destinatario especial para holders de NFT
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: 'nft_ownership'
      }
    });

    return {
      contentId: encryptedContent.encryptionId,
      accessPolicy: accessPolicy.policyId
    };
  }

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any
  ) {
    // Verificar propiedad NFT primero
    const hasAccess = await this.verifyNftOwnership(
      userAddress,
      contentId
    );

    if (!hasAccess) {
      throw new Error('Acceso denegado: NFT requerido no encontrado');
    }

    // Desencriptar contenido
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress
    });

    return decryptedContent.toString('utf-8');
  }

  private async createNftPolicy(collection: string, creator: any) {
    // Crear contrato Move que verifique propiedad NFT
    // Devuelve ID del objeto política
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // Verificar si el usuario posee NFT requerido
    // Consultar Sui por propiedad NFT
  }
}

Ejemplo 3: Transferencia de Activos con Bloqueo Temporal​

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
  assetData: any,
  recipientAddress: string,
  unlockTimestamp: number,
  senderKeypair: any
) {
  const { sealClient, suiClient } = await createSealClient();

  // Crear política de bloqueo temporal en Sui
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient
  );

  // Encriptar datos de transferencia de activos
  const transferData = {
    asset: assetData,
    recipient: recipientAddress,
    unlockTime: unlockTimestamp,
    transferId: crypto.randomUUID()
  };

  const encryptedTransfer = await sealClient.encrypt({
    data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
    recipientId: recipientAddress,
    accessPolicy: {
      policyId: timeLockPolicy.policyId,
      policyType: 'time_lock'
    }
  });

  console.log(`Activo bloqueado hasta ${new Date(unlockTimestamp)}`);

  return {
    transferId: encryptedTransfer.encryptionId,
    unlockTime: unlockTimestamp,
    policyId: timeLockPolicy.policyId
  };
}

async function claimTimeLockTransfer(
  transferId: string,
  recipientKeypair: any
) {
  const { sealClient } = await createSealClient();

  try {
    const decryptedData = await sealClient.decrypt({
      encryptionId: transferId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    const transferData = JSON.parse(decryptedData.toString('utf-8'));

    // Procesar la transferencia de activos
    console.log('Transferencia de activos desbloqueada:', transferData);

    return transferData;
  } catch (error) {
    console.error('Transferencia aún no desbloqueada o acceso denegado:', error);
    throw error;
  }
}

Integración con Almacenamiento Descentralizado Walrus​

Seal funciona perfectamente con Walrus, la solución de almacenamiento descentralizado de Sui. Aquí te mostramos cómo integrar ambos:

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
  private sealClient: any;
  private walrusClient: any;

  constructor(sealClient: any, walrusClient: any) {
    this.sealClient = sealClient;
    this.walrusClient = walrusClient;
  }

  async storeEncryptedData(
    data: Buffer,
    recipientAddress: string,
    accessPolicy?: any
  ) {
    // Encriptar con Seal
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy
    });

    // Almacenar datos encriptados en Walrus
    const blobId = await this.walrusClient.store(
      encryptedData.ciphertext
    );

    // Devolver referencia que incluye info tanto de Seal como Walrus
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any
  ) {
    // Recuperar de Walrus
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // Desencriptar con Seal
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });

    return decryptedData;
  }
}

// Ejemplo de uso
async function walrusExample() {
  const { sealClient } = await createSealClient();
  const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

  const integration = new SealWalrusIntegration(sealClient, walrusClient);

  const fileData = Buffer.from('Contenido de documento importante');
  const recipientAddress = '0x...';

  // Almacenar encriptado
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress
  );

  console.log('Almacenado con Blob ID:', result.blobId);

  // Más tarde, recuperar y desencriptar
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair
  );

  console.log('Datos recuperados:', decrypted.toString());
}

Configuración Avanzada de Encriptación Threshold​

Para aplicaciones de producción, querrás configurar encriptación threshold personalizada con múltiples servidores de claves:

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
  // Configurar con múltiples servidores de claves independientes
  const keyServers = [
    'https://keyserver-1.your-org.com',
    'https://keyserver-2.partner-org.com',
    'https://keyserver-3.third-party.com',
    'https://keyserver-4.backup-provider.com',
    'https://keyserver-5.fallback.com'
  ];

  const sealClient = new SealClient({
    keyServers,
    threshold: 3, // threshold 3-de-5
    network: 'mainnet',
    // Opciones avanzadas
    retryAttempts: 3,
    timeoutMs: 10000,
    backupKeyServers: [
      'https://backup-1.emergency.com',
      'https://backup-2.emergency.com'
    ]
  });

  return sealClient;
}

async function robustEncryption() {
  const sealClient = await setupProductionSeal();

  const criticalData = "Datos encriptados de misión crítica";

  // Encriptar con garantías de alta seguridad
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, 'utf-8'),
    recipientId: '0x...',
    // Requerir todos los 5 servidores para máxima seguridad
    customThreshold: 5,
    // Agregar redundancia
    redundancy: 2,
    accessPolicy: {
      // Requisitos multi-factor
      requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
    }
  });

  return encrypted;
}

Mejores Prácticas de Seguridad​

1. Gestión de Claves​

// src/security-practices.ts

// BUENO: Usar derivación segura de claves
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// BUENO: Almacenar claves de forma segura (ejemplo con variables de entorno)
const keypair = Ed25519Keypair.fromSecretKey(
  process.env.PRIVATE_KEY
);

// MALO: Nunca hardcodear claves
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345" // ¡No hagas esto!
);

2. Validación de Políticas de Acceso​

// Siempre validar políticas de acceso antes de encriptar
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // Validar dirección del destinatario
  if (!isValidSuiAddress(recipient)) {
    throw new Error('Dirección de destinatario inválida');
  }

  // Verificar que la política existe y es válida
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error('Política de acceso inválida');
  }

  return sealClient.encrypt({
    data,
    recipientId: recipient,
    accessPolicy: policy
  });
}

3. Manejo de Errores y Respaldos​

// Manejo robusto de errores
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
  const { sealClient } = await createSealClient();

  try {
    return await sealClient.decrypt({
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });
  } catch (error) {
    if (error.code === 'ACCESS_DENIED') {
      throw new Error('Acceso denegado: Verifica tus permisos');
    } else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
      // Intentar con configuración de respaldo
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === 'THRESHOLD_NOT_MET') {
      throw new Error('Servidores de claves insuficientes disponibles');
    } else {
      throw new Error(`Desencriptación falló: ${error.message}`);
    }
  }
}

4. Validación de Datos​

// Validar datos antes de encriptar
function validateDataForEncryption(data: Buffer): boolean {
  // Verificar límites de tamaño
  if (data.length > 1024 * 1024) { // límite de 1MB
    throw new Error('Datos demasiado grandes para encriptar');
  }

  // Verificar patrones sensibles (opcional)
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn('Advertencia: Los datos contienen patrones potencialmente sensibles');
  }

  return true;
}

Optimización de Rendimiento​

1. Operaciones en Lotes​

// Procesar múltiples encriptaciones por lotes para eficiencia
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
  const { sealClient } = await createSealClient();

  const promises = dataItems.map((data, index) =>
    sealClient.encrypt({
      data,
      recipientId: recipients[index]
    })
  );

  return Promise.all(promises);
}

2. Caché de Respuestas de Servidores de Claves​

// Cachear sesiones de servidores de claves para reducir latencia
class OptimizedSealClient {
  private sessionCache = new Map();

  async encryptWithCaching(data: Buffer, recipient: string) {
    let session = this.sessionCache.get(recipient);

    if (!session || this.isSessionExpired(session)) {
      session = await this.createNewSession(recipient);
      this.sessionCache.set(recipient, session);
    }

    return this.encryptWithSession(data, session);
  }
}

Probando tu Integración Seal​

Pruebas Unitarias​

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Integración Seal', () => {
  it('debería encriptar y desencriptar datos exitosamente', async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from('mensaje de prueba');
    const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

    const encrypted = await sealClient.encrypt({
      data: testData,
      recipientId: recipient
    });

    expect(encrypted.encryptionId).toBeDefined();
    expect(encrypted.ciphertext).toBeDefined();

    const decrypted = await sealClient.decrypt({
      ciphertext: encrypted.ciphertext,
      encryptionId: encrypted.encryptionId,
      recipientId: recipient
    });

    expect(decrypted.toString()).toBe('mensaje de prueba');
  });

  it('debería aplicar políticas de control de acceso', async () => {
    // Probar que usuarios no autorizados no pueden desencriptar
    const { sealClient } = await createSealClient();

    const encrypted = await sealClient.encrypt({
      data: Buffer.from('secreto'),
      recipientId: 'authorized-user'
    });

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: 'unauthorized-user'
      })
    ).rejects.toThrow('Acceso denegado');
  });
});

Despliegue a Producción​

Configuración de Entorno​

// config/production.ts
export const productionConfig = {
  keyServers: [
    process.env.KEY_SERVER_1,
    process.env.KEY_SERVER_2,
    process.env.KEY_SERVER_3,
    process.env.KEY_SERVER_4,
    process.env.KEY_SERVER_5
  ],
  threshold: 3,
  network: 'mainnet',
  suiRpc: process.env.SUI_RPC_URL,
  walrusGateway: process.env.WALRUS_GATEWAY,
  // Configuraciones de seguridad
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1 hora
  retryAttempts: 3
};

Monitoreo y Logging​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] Datos encriptados ${encryptionId} para ${recipient}`);
    // Enviar a tu servicio de monitoreo
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(`[SEAL] Desencriptación ${encryptionId}: ${success ? 'ÉXITO' : 'FALLÓ'}`);
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] Servidor de claves ${serverUrl}: ${status}`);
  }
}

Recursos y Próximos Pasos​

Documentación Oficial​

• Documentación Seal: https://seal-docs.wal.app/
• Repositorio GitHub: https://github.com/MystenLabs/seal
• Documentación Sui: https://docs.sui.io/
• Documentación Walrus: https://docs.wal.app/

Comunidad y Soporte​

• Discord de Sui: Únete al canal #seal para soporte comunitario
• GitHub Issues: Reporta bugs y solicita funcionalidades
• Foros de Desarrolladores: Foros comunitarios de Sui para discusiones

Temas Avanzados para Explorar​

1. Políticas de Acceso Personalizadas: Construir lógica de autorización compleja con contratos Move
2. Integración Cross-Chain: Usar Seal con otras redes blockchain
3. Gestión de Claves Empresarial: Configurar tu propia infraestructura de servidores de claves
4. Auditoría y Cumplimiento: Implementar logging y monitoreo para entornos regulados

Aplicaciones de Ejemplo​

• App de Chat Seguro: Mensajería con encriptación extremo a extremo con Seal
• Gestión de Documentos: Compartir documentos empresariales con controles de acceso
• Gestión de Derechos Digitales: Distribución de contenido con políticas de uso
• Análisis Preservando Privacidad: Flujos de trabajo de procesamiento de datos encriptados

Conclusión​

Seal representa un cambio fundamental hacia hacer de la privacidad y la infraestructura de encriptación preocupaciones a nivel de infraestructura en Web3. Al combinar encriptación basada en identidad, seguridad threshold y control de acceso programable, proporciona a los desarrolladores herramientas poderosas para construir aplicaciones verdaderamente seguras y descentralizadas.

Las ventajas clave de construir con Seal incluyen:

• Sin Punto Único de Falla: Los servidores de claves distribuidos eliminan autoridades centrales
• Seguridad Programable: Las políticas de acceso basadas en smart contracts proporcionan autorización flexible
• Amigable para Desarrolladores: El SDK TypeScript se integra perfectamente con herramientas Web3 existentes
• Agnóstico de Almacenamiento: Funciona con Walrus, IPFS o cualquier solución de almacenamiento
• Listo para Producción: Construido por Mysten Labs con estándares de seguridad empresarial

Ya sea que estés asegurando datos de usuarios, implementando modelos de suscripción o construyendo aplicaciones complejas multi-party, Seal proporciona las primitivas criptográficas y la infraestructura de control de acceso que necesitas para construir con confianza.

Comienza a construir hoy y únete al creciente ecosistema de desarrolladores haciendo de la privacidad una parte fundamental de la infraestructura pública.

¿Listo para empezar a construir? Instala @mysten/seal y comienza a experimentar con los ejemplos de este tutorial. La web descentralizada está esperando aplicaciones que pongan la privacidad y seguridad primero.

La Cumbre de Aplicaciones Blockchain de Stanford (BASS) dio inicio a la semana de la Conferencia Ciencia de Blockchain (SBC), reuniendo a innovadores, investigadores y constructores para explorar la vanguardia del ecosistema. Los organizadores Gil, Kung y Stephen dieron la bienvenida a los asistentes, resaltando el enfoque del evento en el emprendimiento y las aplicaciones del mundo real, un espíritu nacido de su estrecha colaboración con SBC. Con el apoyo de organizaciones como Blockchain Builders y el Alumni de Criptografía y Blockchain de Stanford, el día estuvo repleto de inmersiones profundas en blockchains celestiales, el futuro de Ethereum, DeFi institucional y la creciente intersección de IA y cripto.

Dalia Maliki: Construyendo una Raíz Orbital de Confianza con Computadora Espacial​

Dalia Maliki, profesora en UC Santa Barbara y asesora de Space Computer, abrió con una mirada a una aplicación verdaderamente fuera de este mundo: construir una plataforma de cómputo segura en órbita.

¿Qué es Space Computer?
En pocas palabras, Space Computer es una “raíz orbital de confianza”, que brinda una plataforma para ejecutar cálculos seguros y confidenciales en satélites. La propuesta de valor central radica en las garantías de seguridad únicas del espacio. “Una vez que una caja se lanza de forma segura y se despliega en el espacio, nadie puede venir después y hackearla”, explicó Maliki. “Es puramente, perfectamente a prueba de manipulaciones en este punto”. Este entorno la hace a prueba de fugas, asegura que las comunicaciones no puedan ser interferidas fácilmente y proporciona geolocalización verificable, ofreciendo potentes propiedades de descentralización.

Arquitectura y Casos de Uso
El sistema está diseñado con una arquitectura de dos capas:

• Capa 1 (Celestial): La raíz de confianza autoritativa funciona en una red de satélites en órbita, optimizada para comunicaciones limitadas e intermitentes.
• Capa 2 (Terrestre): Soluciones de escalado estándar como rollups y canales de estado se ejecutan en la Tierra, anclándose a la Capa 1 celestial para obtener finalización y seguridad.

Los primeros casos de uso incluyen ejecutar validadores de blockchain altamente seguros y un generador de números aleatorios verdadero que captura radiación cósmica. Sin embargo, Maliki enfatizó el potencial de la plataforma para innovaciones imprevistas. “Lo más genial de construir una plataforma es que siempre construyes una plataforma y otras personas vienen y crean casos de uso que ni siquiera soñaste”.

Trazando un paralelismo con el ambicioso Proyecto Corona de los años 50, que dejaba caer cubos de película desde satélites espía para ser atrapados en el aire por aviones, Maliki instó a la audiencia a pensar en grande. “En comparación, lo que trabajamos hoy con la computadora espacial es un lujo, y estamos muy entusiasmados con el futuro”.

Tomasz Stanczak: La Hoja de Ruta de Ethereum – Escalado, Privacidad e IA​

Tomasz Stanczak, Director Ejecutivo de la Ethereum Foundation, ofreció una visión integral de la hoja de ruta evolutiva de Ethereum, centrada fuertemente en el escalado, la mejora de la privacidad y la integración con el mundo de la IA.

Enfoque a Corto Plazo: Soporte a L2s
La prioridad inmediata para Ethereum es consolidar su papel como la mejor plataforma para que las Layer 2 construyan sobre ella. Los próximos forks, Fusaka y Glumpsterdom, están centrados en este objetivo. “Queremos hacer declaraciones mucho más fuertes de que sí, las L2 innovan, extienden Ethereum y contarán con el compromiso de los constructores de protocolo de que la Layer 1 apoyará a las L2 de la mejor manera posible”, afirmó Stanczak.

Visión a Largo Plazo: Lean Ethereum y Pruebas en Tiempo Real
Mirando más adelante, la visión de “Lean Ethereum” apunta a una escalabilidad masiva y al endurecimiento de la seguridad. Un componente clave es la hoja de ruta ZK‑EVM, que persigue pruebas en tiempo real con latencias menores a 10 segundos para el 99 % de los bloques, alcanzables por stakers solos. Esto, combinado con mejoras en la disponibilidad de datos, podría impulsar a las L2 a un teórico “10 millones de TPS”. El plan a largo plazo también incluye un enfoque en criptografía post‑cuántica mediante firmas basadas en hash y ZK‑EVMs.

Privacidad e Intersección con IA
La privacidad es otro pilar crítico. La Ethereum Foundation ha creado el equipo Privacy and Scaling Explorations (PSC) para coordinar esfuerzos, apoyar herramientas y explorar integraciones de privacidad a nivel de protocolo. Stanczak ve esto como esencial para la interacción de Ethereum con la IA, habilitando casos de uso como mercados financieros resistentes a la censura, IA que preserva la privacidad y sistemas agentes de código abierto. Subrayó que la cultura de Ethereum de conectar múltiples disciplinas —desde finanzas y arte hasta robótica e IA— es fundamental para navegar los retos y oportunidades de la próxima década.

Sreeram Kannan: El Marco de Confianza para Apps Crypto Ambiciosas con EigenCloud​

Sreeram Kannan, fundador de Eigen Labs, desafió a la audiencia a pensar más allá del alcance actual de las aplicaciones crypto, presentando un marco para entender el valor central de crypto e introduciendo EigenCloud como la plataforma para materializar esta visión.

Tesis Central de Crypto: Una Capa de Verificabilidad
“Subyacente a todo esto hay una tesis central de que crypto es la capa de confianza o verificabilidad sobre la cual puedes construir aplicaciones muy poderosas”, explicó Kannan. Presentó un marco “TAM vs. Trust”, ilustrando que el mercado total direccionable (TAM) para una aplicación crypto crece exponencialmente a medida que la confianza que subyace aumenta. El mercado de Bitcoin crece al volverse más confiable que las monedas fiat; el mercado de una plataforma de préstamos crece al volverse más creíble su garantía de solvencia del prestatario.

EigenCloud: Liberando la Programabilidad
Kannan argumentó que el principal cuello de botella para construir apps más ambiciosas —como un Uber descentralizado o plataformas de IA confiables— no es el rendimiento sino la programabilidad. Para resolverlo, EigenCloud introduce una nueva arquitectura que separa la lógica de la aplicación de la lógica del token.

“Mantengamos la lógica del token on‑chain en Ethereum”, propuso, “pero la lógica de la aplicación se traslada fuera. Ahora puedes escribir tu lógica central en contenedores arbitrarios… ejecutarlos en cualquier dispositivo que elijas, sea CPU o GPU… y luego traer esos resultados de forma verificable de vuelta on‑chain”.

Este enfoque, según él, extiende crypto de una “escala de laptop o servidor a escala de nube”, permitiendo a los desarrolladores crear las aplicaciones verdaderamente disruptivas que se imaginaron en los primeros días de crypto.

Panel: Un Análisis Profundo de la Arquitectura Blockchain​

Un panel con Leiyang de MegaETH, Adi de Realo y Solomon de la Solana Foundation exploró los trade‑offs entre arquitecturas monolíticas, modulares y “super modulares”.

• MegaETH (L2 Modular): Leiyang describió el enfoque de MegaETH de usar un secuenciador centralizado para velocidad extrema mientras delega la seguridad a Ethereum. Este diseño busca ofrecer una experiencia en tiempo real al nivel de Web2 para aplicaciones, reviviendo las ambiciosas ideas de la era ICO que antes estaban limitadas por el rendimiento.
• Solana (L1 Monolítica): Solomon explicó que la arquitectura de Solana, con sus altos requisitos de nodos, está diseñada deliberadamente para el máximo rendimiento y apoyar su visión de poner toda la actividad financiera global on‑chain. El foco actual está en emisión de activos y pagos. Sobre interoperabilidad, Solomon fue franco: “En general, no nos importa mucho la interoperabilidad… Se trata de conseguir la mayor liquidez y uso de activos on‑chain posible”.
• Realo (L1 “Super Modular”): Adi presentó el concepto “super modular” de Realo, que consolida servicios esenciales como oráculos directamente en la capa base para reducir la fricción del desarrollador. Este diseño busca conectar nativamente la blockchain al mundo real, con un enfoque go‑to‑market en RWAs y haciendo que la blockchain sea invisible para los usuarios finales.

Panel: La Intersección Real de IA y Blockchain​

Moderado por Ed Roman de HackVC, este panel mostró tres enfoques distintos para fusionar IA y crypto.

• Ping AI (Bill): Ping AI está construyendo una “IA personal” donde los usuarios mantienen la auto‑custodia de sus datos. La visión es reemplazar el modelo tradicional de intercambio de anuncios. En lugar de que las empresas moneticen los datos de los usuarios, el sistema de Ping AI recompensará directamente a los usuarios cuando sus datos generen una conversión, permitiéndoles capturar el valor económico de su huella digital.
• Public AI (Jordan): Descrita como la “capa humana de la IA”, Public AI es un marketplace para obtener datos de alta calidad bajo demanda que no pueden ser raspados ni generados sintéticamente. Utiliza un sistema de reputación on‑chain y mecanismos de staking para asegurar que los contribuyentes aporten señal, no ruido, recompensándolos por su trabajo en la construcción de mejores modelos de IA.
• Gradient (Eric): Gradient está creando un runtime descentralizado para IA, habilitando inferencia y entrenamiento distribuidos en una red de hardware de consumo subutilizado. El objetivo es proporcionar un contrapeso al poder centralizador de las grandes compañías de IA al permitir que una comunidad global entrene y sirva modelos de forma colaborativa, manteniendo la “soberanía inteligente”.

Más Destacados de la Cumbre​

• Orin Katz (Starkware) presentó bloques de construcción para “privacidad on‑chain compliant”, detallando cómo los ZK‑proofs pueden usarse para crear pools de privacidad y tokens privados (ZRC20) que incluyen mecanismos como “claves de visualización” para supervisión regulatoria.
• Sam Green (Cambrian) ofreció una visión general del panorama “Agentic Finance”, categorizando agentes crypto en trading, provisión de liquidez, préstamos, predicción e información, y resaltó la necesidad de datos rápidos, integrales y verificables para alimentarlos.
• Max Siegel (Privy) compartió lecciones de la incorporación de más de 75 millones de usuarios, enfatizando la necesidad de encontrarse donde están los usuarios, simplificar experiencias de producto y dejar que las necesidades del producto guíen las decisiones de infraestructura, no al revés.
• Nil Dalal (Coinbase) introdujo el “Onchain Agentic Commerce Stack” y el estándar abierto X42, un protocolo nativo de crypto diseñado para crear una “web pagable por máquinas” donde agentes de IA puedan transaccionar sin problemas usando stablecoins para datos, APIs y servicios.
• Gordon Liao & Austin Adams (Circle) revelaron Circle Gateway, una nueva primitiva para crear un balance USDC unificado que está abstractado por cadena. Esto permite despliegues de liquidez casi instantáneos (< 500 ms) en múltiples cadenas, mejorando drásticamente la eficiencia de capital para empresas y solucionadores.

El día concluyó con un mensaje claro: las capas fundacionales de crypto están madurando, y el foco se está desplazando decisivamente hacia la construcción de aplicaciones robustas, amigables para el usuario y económicamente sostenibles que puedan cerrar la brecha entre el mundo on‑chain y la economía global.

Introducción​

Tempo de Stripe es una red blockchain Layer-1 (L1) recién lanzada con un enfoque central en procesar pagos de stablecoins de alta velocidad y bajo costo. El proyecto fue co-incubado por el gigante de pagos Stripe y la destacada firma de capital de riesgo cripto Paradigm. Desde su concepción, se ha posicionado como una blockchain "orientada a pagos", diseñada para cumplir con los exigentes requisitos de escala y rendimiento de escenarios financieros del mundo real. En 2025, Tempo entró en una fase de testnet privada, co-diseñando y validando sus características con varios socios importantes, incluyendo Visa, Deutsche Bank, Shopify y OpenAI. Para la comunidad de desarrolladores, la emergencia de Tempo presenta una nueva oportunidad—construir la próxima generación de aplicaciones de pago sobre una infraestructura subyacente optimizada para stablecoins y casos de uso comerciales. Esta guía detallará cómo los desarrolladores pueden integrarse técnicamente con Tempo, qué recursos y comunidades están disponibles, y cómo participar en este ecosistema en crecimiento.

1. Integración Técnica: Construyendo en L1 Tempo​

Una filosofía de diseño central de Tempo es reducir la barrera de entrada para desarrolladores eligiendo un camino de compatibilidad total con Ethereum. Esto significa que los desarrolladores pueden construir sobre él usando herramientas maduras existentes y bases de conocimiento. La arquitectura de Tempo está basada en Reth (una implementación en Rust de un cliente Ethereum liderada por Paradigm), haciéndolo naturalmente compatible con contratos inteligentes de Ethereum y su cadena de herramientas para desarrolladores.

Aquí están sus características técnicas clave y puntos de integración:

• EVM y Contratos Inteligentes: Tempo soporta completamente contratos inteligentes en Solidity y la Máquina Virtual de Ethereum (EVM). Los desarrolladores pueden usar marcos estándar como Hardhat, Truffle y Foundry, así como bibliotecas como ethers.js y web3.js, para escribir, probar y desplegar contratos inteligentes. Para desarrolladores Web3, esta compatibilidad sin fricciones significa que prácticamente no hay curva de aprendizaje. DApps existentes, billeteras (como MetaMask) y herramientas de desarrollo funcionan "listas para usar" en Tempo, allanando el camino para la migración fácil de aplicaciones maduras desde Ethereum.

• Alto Rendimiento y Finalidad: Tempo ha sido profundamente optimizado para los requisitos de velocidad de escenarios de pago. Su objetivo de diseño es lograr una capacidad de procesamiento de más de 100,000 transacciones por segundo (TPS) y alcanzar finalidad determinística sub-segundo. Esto significa que una vez que una transacción es confirmada, es irreversible, eliminando el riesgo de reordenamiento de transacciones (reorgs) que puede ocurrir con confirmaciones probabilísticas tradicionales (como Proof-of-Work). Este alto rendimiento y certeza son cruciales para aplicaciones con requisitos estrictos de liquidación instantánea, como sistemas de punto de venta (POS), intercambios y micropagos.

• Diseño Nativo para Stablecoins: A diferencia de la mayoría de cadenas públicas de propósito general, la red Tempo no depende de un token nativo volátil para pagar las tarifas de transacción (Gas). Las tarifas de transacción en su red se pueden pagar directamente usando stablecoins principales (como USDC, USDT, etc.). Para lograr esto, el protocolo integra un creador de mercado automatizado (AMM) que puede manejar automáticamente intercambios entre diferentes stablecoins en segundo plano, asegurando "neutralidad del emisor" para pagos de tarifas. Para desarrolladores y usuarios, esto mejora enormemente la experiencia, ya que los costos de transacción pueden estar establemente vinculados al valor fiat (ej. siempre alrededor de $0.001), evitando la incertidumbre causada por la volatilidad del precio del token nativo.

• Características Orientadas a Pagos: Tempo añade varias características a nivel de protocolo adaptadas para aplicaciones financieras y de pago. Estas incluyen:

  • "Carriles de Pago": Al aislar transacciones tipo pago de otros tipos de actividad en cadena (como operaciones DeFi complejas), estos carriles aseguran baja latencia y alta prioridad para pagos.
  • Transferencias en Lote Nativas: Aprovechando tecnologías como Account Abstraction, soporta el envío eficiente de pagos a múltiples direcciones en una sola transacción, lo cual es altamente práctico para escenarios como nómina y pagos a proveedores.
  • Campos de Memo de Transacciones: Este campo es compatible con el estándar de mensajería financiera ISO 20022, permitiendo que metadatos como números de referencia de facturas o datos de cumplimiento se adjunten a transacciones en cadena, simplificando enormemente los procesos de reconciliación financiera corporativa.
  • Privacidad Opcional: El protocolo soporta características opcionales de privacidad de transacciones para cumplir con necesidades de cumplimiento empresarial para proteger información comercialmente sensible.

• Integración vía API de Stripe: Stripe planea integrar profundamente Tempo en su suite de productos existente, ofreciendo a los desarrolladores dos rutas de integración. La primera es desarrollo directo en cadena, donde desarrolladores Web3 usan cadenas de herramientas familiares para desplegar contratos inteligentes directamente en Tempo. La segunda es integración vía APIs de alto nivel de Stripe, que abstrae completamente la complejidad de la blockchain. Por ejemplo, la plataforma Bridge de Stripe (una herramienta para flujos de stablecoin cross-chain) usará Tempo como uno de sus rieles de liquidación centrales en el futuro. Los desarrolladores solo necesitarán llamar a la familiar API REST de Stripe para iniciar un pago o transferencia, y el sistema Stripe automáticamente lo ejecutará en la red Tempo en segundo plano. Esto les permite disfrutar de las ventajas de velocidad y costo de la blockchain sin necesidad de preocuparse por detalles subyacentes como gestión de nodos o firma de claves privadas.

2. Documentación para Desarrolladores, Tutoriales y Recursos de Incorporación​

A finales de 2025, Tempo aún está en una fase de testnet privada, y su documentación oficial para desarrolladores se está escribiendo activamente. Sin embargo, el sitio web oficial de Tempo ha confirmado que "documentación técnica comprensiva para desarrolladores estará disponible pronto."

Mientras tanto, los desarrolladores interesados pueden obtener información preliminar a través de los siguientes canales:

• Sitio Web Oficial y FAQ: Visitar el sitio web oficial de Tempo y su página de Preguntas Frecuentes (FAQ) proporciona una visión general de alto nivel de su filosofía de diseño, características centrales y cómo difiere de blockchains de propósito general.
• Solicitar Acceso a Testnet: Los desarrolladores o empresas interesados pueden enviar una solicitud a través del canal proporcionado en el sitio web de Tempo (partners@tempo.xyz) para obtener acceso a su testnet privada para exploración temprana y prototipado.

Basado en el enfoque consistente de Stripe en la experiencia del desarrollador, podemos esperar que la documentación oficial, una vez lanzada, incluya los siguientes recursos:

• Guías de Inicio: Tutoriales detallados guiando a los desarrolladores sobre cómo configurar su entorno de desarrollo, conectarse al testnet de Tempo y desplegar su primer contrato inteligente.
• Referencias de API y Documentación de SDK: Referencias técnicas completas para la ruta de integración de API de Stripe, así como documentación para los endpoints JSON-RPC para interactuar con el protocolo Tempo.
• Tutoriales y Aplicaciones de Muestra: Código de muestra open-source y proyectos demostrando cómo construir aplicaciones de pago comunes en Tempo.
• Mejores Prácticas: Consejo profesional sobre seguridad, cumplimiento, optimización de rendimiento y otras áreas.

Stripe es reconocido por su documentación de API clara y de alta calidad, y hay buenas razones para creer que la documentación de Tempo mantendrá el mismo estándar.

3. Canales de Participación de Desarrolladores y Comunidad de Stripe​

Stripe tiene un ecosistema maduro y activo de comunidad de desarrolladores. Para desarrolladores que quieren mantenerse actualizados sobre Tempo y recibir soporte técnico, los siguientes canales oficiales están disponibles:

• Discord de Desarrolladores de Stripe: Esta es una gran comunidad con más de 120,000 miembros, donde ingenieros de Stripe participan directamente respondiendo preguntas. Los últimos anuncios, discusiones técnicas y soporte comunitario para Tempo se pueden encontrar aquí.
• Foros en Línea y Plataformas de Q&A: El equipo de Stripe monitorea activamente y responde a preguntas publicadas en Stack Overflow (usando la etiqueta stripe) y Twitter/X (@StripeDev).
• Blog y Boletines de Stripe: Este es el canal principal para información oficial, artículos técnicos profundos y actualizaciones de productos. Hitos importantes y estudios de casos para Tempo serán publicados aquí.
• Eventos y Webinars para Desarrolladores: Stripe regularmente aloja eventos en línea y offline. En particular, su conferencia anual de desarrolladores, Stripe Sessions, es a menudo la plataforma para anuncios importantes de productos y probablemente contará con sesiones técnicas dedicadas y talleres para Tempo en el futuro.

Al aprovechar estos canales establecidos, los desarrolladores pueden fácilmente obtener información, resolver problemas y conectarse con otros desarrolladores interesados en Tempo.

4. Oportunidades para Contribuir al Ecosistema Tempo​

Mientras Tempo transiciona de un proyecto de incubación interno a una red pública abierta, los desarrolladores tienen varias maneras de participar y contribuir a su ecosistema más allá de solo construir aplicaciones:

• Contribuciones Open Source: Tempo está basado en el cliente open-source Reth, y se espera que sus propios componentes centrales sean gradualmente open-sourced. Los desarrolladores podrán revisar el código, enviar issues, proponer mejoras e incluso contribuir código directamente para mejorar conjuntamente el rendimiento y seguridad del protocolo.
• Participación de Validadores y Gobernanza de Red: Los nodos validadores de Tempo están actualmente operados por socios fundadores en un modelo con permisos, pero el plan a largo plazo es transicionar a un modelo sin permisos. En ese punto, cualquier desarrollador u organización técnicamente capaz puede ejecutar un nodo validador, participar en el consenso de red y ganar tarifas de transacción en forma de stablecoins mientras aseguran la red. Mientras la red se descentraliza, también se puede establecer un mecanismo de gobernanza comunitaria, permitiendo a los desarrolladores participar en decisiones de actualización del protocolo.
• Propuestas de Mejora del Protocolo (TIPs): Los desarrolladores pueden inspirarse en el modelo de EIPs de Ethereum escribiendo y discutiendo Propuestas de Mejora de Tempo (TIPs) para sugerir nuevas características u optimizaciones a mecanismos existentes, influenciando así directamente la evolución del protocolo.
• Participar en Hackathons y Desafíos para Desarrolladores: Tanto Stripe como Paradigm tienen una tradición de apoyar eventos para desarrolladores. Es previsible que una vez que la cadena de herramientas de desarrollador de Tempo madure, habrá tracks de hackathon dedicados o desafíos de premios para alentar a los desarrolladores a innovar sobre él.
• Educación Comunitaria y Compartir Conocimiento: Como participantes tempranos, los desarrolladores pueden compartir sus experiencias e insights escribiendo blogs técnicos, creando tutoriales en video, respondiendo preguntas en la comunidad o hablando en conferencias técnicas, ayudando a hacer crecer toda la comunidad de desarrolladores.

El ecosistema Tempo está en sus primeras etapas de construcción, proporcionando una oportunidad valiosa para que los desarrolladores se involucren profundamente de varias maneras y den forma a su futuro.

5. Incentivos y Programas de Subvenciones para Desarrolladores​

Actualmente, Stripe no ha anunciado formalmente ningún programa de subvenciones o incentivos para desarrolladores de Tempo. Al mismo tiempo, el diseño de Tempo excluye explícitamente emitir un nuevo token nativo especulativo. Sin embargo, esto no significa que el ecosistema carezca de soporte para desarrolladores. Es previsible que los incentivos futuros se enfoquen más en utilidad y construcción de ecosistema, y pueden incluir:

• Fondo del Ecosistema: Establecido por Stripe, Paradigm o una fundación independiente para proporcionar subvenciones directas a equipos construyendo infraestructura crítica (como billeteras, exploradores, herramientas de analítica) o aplicaciones prometedoras para el ecosistema Tempo.
• Premios de Hackathon y Recompensas: Incentivando desarrolladores a través de competiciones y publicando recompensas para tareas específicas de desarrollo, como desarrollar una biblioteca open-source para una característica particular.
• Incentivos para Socios: Para socios empresariales que eligen integrar Tempo en su negocio, Stripe puede ofrecer incentivos comerciales como reducciones de tarifas, soporte técnico prioritario o promociones de marketing conjunto.
• Recompensas de Validadores: Una vez que la red transicione a un modelo sin permisos, ejecutar un nodo validador y procesar transacciones proporcionará un flujo continuo de ingresos de tarifas de transacción denominadas en stablecoins.
• Inversión Estratégica: Para startups que construyen productos o servicios destacados en Tempo, inversión estratégica o adquisición potencial de Stripe o Paradigm también es un incentivo importante.

En resumen, el modelo de incentivos de Tempo girará en torno a construir valor del mundo real en lugar de especulación de tokens.

6. Eventos, Talleres y Meetups sobre Tempo​

Los desarrolladores que quieren aprender más sobre Tempo y conectarse con la comunidad pueden prestar atención a los siguientes tipos de eventos:

• Stripe Sessions: La conferencia anual de desarrolladores de Stripe es el lugar más importante para obtener la hoja de ruta oficial y actualizaciones importantes para Tempo.
• Paradigm Frontiers: Alojado por Paradigm para desarrolladores de tecnología cripto de vanguardia, eventos futuros probablemente incluirán sesiones técnicas profundas y desafíos de hackathon para Tempo.
• Conferencias de la Industria Fintech y Cripto: En conferencias importantes como Money20/20 y Consensus, discusiones sobre innovación en pagos inevitablemente involucrarán Tempo, haciéndolas buenas oportunidades para entender su posicionamiento en el mercado y perspectivas de aplicación comercial.
• Meetups Locales y Webinars en Línea: Eventos más pequeños organizados por Stripe o comunidades locales de desarrolladores a menudo proporcionan más interacción directa y experiencias de aprendizaje práctico.
• Hackathons Globales: Grandes eventos de hackathon como ETHGlobal pueden presentar Tempo como plataforma patrocinadora en el futuro, proporcionando una oportunidad para que los desarrolladores innoven en un escenario internacional.

Conclusión​

La blockchain Tempo de Stripe ofrece a los desarrolladores una intersección única, mezclando el rigor del fintech tradicional con la apertura del mundo cripto. Los desarrolladores pueden aprovechar su compatibilidad con Ethereum para comenzar rápidamente con herramientas familiares, o integrar sin problemas las poderosas características de Tempo en negocios existentes a través de las APIs de Stripe. Aunque el proyecto aún está en sus primeras etapas con mucha de la documentación y programas de soporte aún en desarrollo, el fuerte respaldo de Stripe y Paradigm señala un alto compromiso con la experiencia del desarrollador y el avance tecnológico. Al usar activamente recursos existentes, unirse a la comunidad y participar en eventos relevantes, los desarrolladores pueden aprovechar una valiosa oportunidad temprana en una red blockchain enfocada en resolver problemas de pago del mundo real.

TL;DR​

La abstracción intercadena convierte un laberinto de cadenas, puentes y billeteras en una experiencia de plataforma única y coherente tanto para desarrolladores como para usuarios finales. El ecosistema ha madurado silenciosamente: estándares de intención, abstracción de cuentas, movilidad nativa de stablecoins y iniciativas a nivel de red como OP Superchain y AggLayer de Polygon hacen realista un futuro de “muchas cadenas, una experiencia” en 2025. Para las empresas, la ventaja es pragmática: integraciones más simples, controles de riesgo ejecutables, operaciones determinísticas y auditoría lista para cumplimiento, sin apostar todo a una sola cadena.

El problema real que tienen las empresas (y por qué los puentes solos no lo solucionaron)​

La mayoría de los equipos empresariales no quieren “elegir una cadena”. Quieren resultados: liquidar un pago, emitir un activo, cerrar una operación o actualizar un registro, de forma fiable, auditable y con un costo predecible. El problema es que la producción de Web3 hoy es irrevocablemente multichain. Cientos de rollups, appchains y L2 se han lanzado en los últimos 18 meses, cada uno con sus propias tarifas, tiempos de finalización, herramientas y supuestos de confianza.

Los enfoques tradicionales de cross‑chain resolvieron el transporte — mover tokens o mensajes de A a B — pero no la experiencia. Los equipos siguen obligados a gestionar billeteras por red, provisionar gas por cadena, elegir un puente por ruta y asumir diferencias de seguridad que no pueden cuantificar fácilmente. Esa fricción es el verdadero impuesto a la adopción.

La abstracción intercadena elimina ese impuesto al ocultar la selección de cadena y el transporte detrás de APIs declarativas, experiencias impulsadas por intención y una identidad y gas unificados. En otras palabras, usuarios y aplicaciones expresan qué quieren; la plataforma determina cómo y dónde ocurre, de forma segura. La abstracción de cadenas hace que la tecnología blockchain sea invisible para los usuarios finales mientras preserva sus beneficios esenciales.

Por qué 2025 es diferente: los bloques de construcción finalmente encajan​

La visión de un mundo multichain sin fricciones no es nueva, pero la tecnología subyacente está lista para producción. Varios componentes clave han madurado y convergido, haciendo posible una abstracción de cadenas robusta.

• Unificación a nivel de red: Los proyectos están construyendo marcos que hacen que cadenas separadas se sientan como una única red unificada. OP Superchain busca estandarizar L2 basados en OP‑Stack con herramientas y capas de comunicación compartidas. AggLayer de Polygon agrega muchas cadenas aseguradas con ZK mediante “pruebas pesimistas” para la contabilidad a nivel de cadena, evitando que los problemas de una cadena contaminen a las demás. Mientras tanto, IBC v2 está expandiendo la interoperabilidad estandarizada más allá del ecosistema Cosmos, impulsando “IBC en todas partes”.

• Rieles de interoperabilidad maduros: El middleware para la comunicación intercadena está ahora probado en batalla y ampliamente disponible. Chainlink CCIP ofrece transferencia de tokens y datos de nivel empresarial a través de un número creciente de cadenas. LayerZero v2 proporciona mensajería omnichain y tokens OFT estandarizados con suministro unificado. Axelar entrega General Message Passing (GMP) para llamadas de contrato complejas entre ecosistemas, conectando cadenas EVM y Cosmos. Plataformas como Hyperlane permiten despliegues sin permisos, facilitando que nuevas cadenas se unan a la red sin gatekeepers, mientras que Wormhole ofrece una capa de mensajería general usada en más de 40 cadenas.

• Intención y abstracción de cuentas: La experiencia de usuario ha sido transformada por dos estándares críticos. ERC‑7683 estandariza intenciones intercadena, permitiendo que las apps declaren metas y que una red de solucionadores compartida las ejecute eficientemente en distintas cadenas. Simultáneamente, las cuentas inteligentes EIP‑4337, combinadas con Paymasters, habilitan abstracción de gas. Esto permite que una aplicación patrocine las tarifas de transacción o que los usuarios paguen con stablecoins, esencial para flujos que atraviesen múltiples redes.

• Movilidad nativa de stablecoins: El Cross‑Chain Transfer Protocol (CCTP) de Circle mueve USDC nativo entre cadenas mediante un proceso seguro de quemado‑y‑mint, reduciendo el riesgo de activos envueltos y unificando liquidez. La última versión, CCTP v2, reduce aún más la latencia y simplifica los flujos de trabajo de los desarrolladores, haciendo que la liquidación con stablecoins sea una parte fluida de la experiencia abstracta.

Cómo se ve la “abstracción intercadena” en una arquitectura empresarial​

Piénsalo como una capacidad en capas que puedes añadir a sistemas existentes. El objetivo es disponer de un único endpoint para expresar una intención y de un plano de políticas único que gobierne su ejecución a través de cualquier número de cadenas.

1. Identidad y política unificadas: En la capa superior están las cuentas inteligentes (EIP‑4337) con controles de acceso basados en roles, recuperación social y opciones modernas de custodia como passkeys o MPC. Todo ello es gobernado por un motor de políticas central que define quién puede hacer qué, dónde, usando listas de permitidos y denegados para cadenas, activos y puentes específicos.

2. Abstracción de gas y tarifas: Los Paymasters eliminan el dolor de “necesito gas nativo en la cadena X”. Los usuarios o servicios pueden pagar tarifas en stablecoins, o la aplicación puede patrocinarlas completamente, bajo políticas y presupuestos predefinidos.

3. Ejecución impulsada por intención: Los usuarios expresan resultados, no transacciones. Por ejemplo, “intercambiar USDC por wETH y entregarlo a la billetera de nuestro proveedor en la cadena Y antes de las 17:00”. El estándar ERC‑7683 define el formato de estas órdenes, permitiendo que redes de solucionadores compitan para ejecutarlas de forma segura y económica.

4. Liquidación y mensajería programables: Bajo el capó, el sistema usa una API consistente para seleccionar el riel adecuado para cada ruta. Puede usar CCIP para una transferencia de token donde el soporte empresarial es clave, Axelar GMP para una llamada de contrato inter‑ecosistema, o IBC donde la seguridad de light‑client nativo se alinea con el modelo de riesgo.

5. Observabilidad y cumplimiento por defecto: Todo el flujo es trazable, desde la intención inicial hasta la liquidación final. Esto genera auditorías claras y permite exportar datos a SIEMs existentes. Los marcos de riesgo pueden programarse para aplicar listas de permitidos o activar frenos de emergencia, por ejemplo pausando rutas si la postura de seguridad de un puente se degrada.

Arquitectura de referencia​

De arriba a abajo, un sistema con abstracción de cadenas se compone de capas bien definidas:

• Capa de experiencia: Interfaces de aplicación que recogen intenciones de usuario y ocultan completamente los detalles de cadena, combinadas con flujos de billetera de cuenta inteligente al estilo SSO.
• Plano de control: Motor de políticas para gestionar permisos, cuotas y presupuestos. Este plano se integra con KMS/HSM y mantiene listas de permitidos para cadenas, activos y puentes. También ingiere feeds de riesgo para cortar automáticamente rutas vulnerables.
• Capa de ejecución: Enrutador de intenciones que selecciona el mejor riel de interoperabilidad (CCIP, LayerZero, Axelar, etc.) según política, precio y requisitos de latencia. Un Paymaster gestiona tarifas, extrayendo de un tesoro de gas agrupado y presupuestos en stablecoins.
• Liquidación y estado: Contratos canónicos on‑chain para funciones centrales como custodia y emisión. Un indexador unificado rastrea eventos y pruebas intercadena, exportando datos a un data‑warehouse o SIEM para análisis y cumplimiento.

Construir vs. comprar: cómo evaluar proveedores de abstracción de cadenas​

Al seleccionar un socio que ofrezca capacidades de abstracción de cadenas, las empresas deben formular varias preguntas clave:

• Seguridad y modelo de confianza: ¿Cuáles son los supuestos de verificación subyacentes? ¿El sistema depende de oráculos, conjuntos de guardianes, light‑clients o redes de validadores? ¿Qué puede ser sancionado o vetado?
• Cobertura y neutralidad: ¿Qué cadenas y activos están soportados hoy? ¿Con qué rapidez pueden añadirse nuevos? ¿El proceso es sin permisos o está controlado por el proveedor?
• Alineación con estándares: ¿La plataforma soporta estándares clave como ERC‑7683, EIP‑4337, OFT, IBC y CCIP?
• Operaciones: ¿Cuáles son los SLA del proveedor? ¿Qué tan transparentes son respecto a incidentes? ¿Ofrecen pruebas reproducibles, reintentos determinísticos y registros de auditoría estructurados?
• Gobernanza y portabilidad: ¿Puedes cambiar de riel de interoperabilidad por ruta sin reescribir tu aplicación? Las abstracciones neutrales al proveedor son críticas para la flexibilidad a largo plazo.
• Cumplimiento: ¿Qué controles existen para retención y residencia de datos? ¿Cuál es su postura SOC2/ISO? ¿Puedes llevar tu propio KMS/HSM?

Despliegue empresarial pragmático de 90 días​

• Días 0‑15: Línea base y política: Inventariar todas las cadenas, activos, puentes y billeteras en uso. Definir una lista de permitidos inicial y establecer reglas de corte basadas en un marco de riesgo claro.
• Días 16‑45: Prototipo: Convertir un flujo de usuario único, como un pago intercadena, a un flujo basado en intención con abstracción de cuenta y un Paymaster. Medir el impacto en abandono de usuarios, latencia y carga de soporte.
• Días 46‑75: Expandir rieles: Añadir un segundo riel de interoperabilidad al sistema y enrutar transacciones dinámicamente según política. Integrar CCTP para movilidad nativa de USDC si los stablecoins forman parte del flujo.
• Días 76‑90: Endurecer: Conectar los datos de observabilidad de la plataforma a tu SIEM, ejecutar pruebas de caos en fallos de ruta y documentar todos los procedimientos operativos, incluidos los protocolos de pausa de emergencia.

Errores comunes (y cómo evitarlos)​

• Rutar solo por “precio del gas”: La latencia, la finalización y los supuestos de seguridad importan tanto como las tarifas. El precio solo no constituye un modelo de riesgo completo.
• Ignorar el gas: Si tu experiencia toca múltiples cadenas, la abstracción de gas no es opcional; es un requisito básico para un producto usable.
• Tratar los puentes como intercambiables: No lo son. Sus supuestos de seguridad difieren significativamente. Codifica listas de permitidos e implementa cortacircuitos para gestionar este riesgo.
• Proliferación de activos envueltos: Siempre que sea posible, prefiere la movilidad nativa de activos (como USDC vía CCTP) para minimizar la fragmentación de liquidez y reducir el riesgo de contrapartida.

Beneficios empresariales​

Cuando la abstracción de cadenas se implementa correctamente, blockchain deja de ser una colección de redes idiosincráticas y se convierte en una tela de ejecución que tus equipos pueden programar. Ofrece políticas, SLA y trazas de auditoría que coinciden con los estándares bajo los que ya operas. Gracias a los estándares de intención maduros, la abstracción de cuentas, rieles de interoperabilidad robustos y el transporte nativo de stablecoins, finalmente puedes entregar resultados de Web3 sin obligar a usuarios —ni a tus propios desarrolladores— a preocuparse por qué cadena realizó el trabajo.

Los exchanges descentralizados (DEX) han madurado hasta convertirse en pilares fundamentales del trading de criptomonedas, capturando ahora aproximadamente el 20 % del volumen total del mercado. Dentro de este espacio, Hyperliquid ha surgido como el líder indiscutible en derivados on-chain. Lanzado en 2022 con el ambicioso objetivo de igualar el rendimiento de los exchanges centralizados (CEX) en la cadena, Hyperliquid procesa hoy miles de millones en trading diario y controla alrededor del 70–75 % del mercado de futuros perpetuos de los DEX. Lo logra combinando una velocidad de nivel CEX y una profunda liquidez con la transparencia y la autocustodia de DeFi. El resultado es una blockchain y un exchange de Capa 1 verticalmente integrados que muchos ahora llaman “la blockchain para albergar todas las finanzas”. Este informe profundiza en la arquitectura técnica de Hyperliquid, su tokenomics, las métricas de crecimiento para 2025, comparaciones con otros líderes de DEX, desarrollos del ecosistema y su visión para el futuro de las finanzas on-chain.

Arquitectura Técnica: Una Cadena de Alto Rendimiento Verticalmente Integrada

Hyperliquid no es solo una aplicación DEX, es una blockchain de Capa 1 completa construida para el rendimiento en el trading. Su arquitectura consta de tres componentes estrechamente acoplados que operan en un estado unificado:

• HyperBFT (Consenso): Un mecanismo de consenso personalizado de Tolerancia a Fallos Bizantinos optimizado para velocidad y rendimiento. Inspirado en protocolos modernos como HotStuff, HyperBFT proporciona finalidad de menos de un segundo y alta consistencia para asegurar que todos los nodos estén de acuerdo en el orden de las transacciones. Este consenso de Prueba de Participación (Proof-of-Stake) está diseñado para manejar la intensa carga de una plataforma de trading, soportando del orden de 100,000–200,000 operaciones por segundo en la práctica. A principios de 2025, Hyperliquid contaba con alrededor de 27 validadores independientes asegurando la red, un número que crece constantemente para descentralizar el consenso.
• HyperCore (Motor de Ejecución): Un motor on-chain especializado para aplicaciones financieras. En lugar de usar contratos inteligentes genéricos para la lógica crítica del exchange, HyperCore implementa libros de órdenes de límite central (CLOBs) integrados para mercados de futuros perpetuos y spot, así como otros módulos para préstamos, subastas, oráculos y más. Cada colocación de orden, cancelación, coincidencia de operación y liquidación se procesa on-chain con finalidad en un solo bloque, produciendo velocidades de ejecución comparables a las de los exchanges tradicionales. Al evitar los AMM y manejar la coincidencia de órdenes dentro del protocolo, Hyperliquid logra una profunda liquidez y baja latencia; ha demostrado una finalidad de operación de <1s y un rendimiento que rivaliza con los centros de operaciones centralizados. Esta capa de ejecución personalizada (escrita en Rust) puede manejar, según se informa, hasta 200k órdenes por segundo después de optimizaciones recientes, eliminando los cuellos de botella que anteriormente hacían inviables los libros de órdenes on-chain.
• HyperEVM (Contratos Inteligentes): Una capa de ejecución de propósito general compatible con Ethereum introducida en febrero de 2025. HyperEVM permite a los desarrolladores desplegar contratos inteligentes en Solidity y dApps en Hyperliquid con total compatibilidad con EVM, similar a construir en Ethereum. Crucialmente, HyperEVM no es un shard o rollup separado, comparte el mismo estado unificado con HyperCore. Esto significa que las dApps en HyperEVM pueden interoperar nativamente con los libros de órdenes y la liquidez del exchange. Por ejemplo, un protocolo de préstamos en HyperEVM puede leer precios en vivo del libro de órdenes de HyperCore o incluso publicar órdenes de liquidación directamente en el libro de órdenes a través de llamadas al sistema. Esta componibilidad entre los contratos inteligentes y la capa de exchange de alta velocidad es un diseño único: no se necesitan puentes ni oráculos off-chain para que las dApps aprovechen la infraestructura de trading de Hyperliquid.

Figura: Arquitectura verticalmente integrada de Hyperliquid que muestra el estado unificado entre el consenso (HyperBFT), el motor de exchange (HyperCore), los contratos inteligentes (HyperEVM) y el puente de activos (HyperUnit).

Integración con la Infraestructura On-Chain: Al construir su propia cadena, Hyperliquid integra estrechamente funciones normalmente aisladas en una sola plataforma. HyperUnit, por ejemplo, es el módulo descentralizado de puente y tokenización de activos de Hyperliquid que permite depósitos directos de activos externos como BTC, ETH y SOL sin envoltorios custodiados. Los usuarios pueden bloquear BTC o ETH nativos y recibir tokens equivalentes (p. ej., uBTC, uETH) en Hyperliquid para usarlos como colateral de trading, sin depender de custodios centralizados. Este diseño proporciona una “verdadera movilidad de colateral” y un marco más consciente de la regulación para traer activos del mundo real a la cadena. Gracias a HyperUnit (y a la integración de USDC de Circle que se discutirá más adelante), los traders en Hyperliquid pueden mover liquidez sin problemas desde otras redes al rápido entorno de exchange de Hyperliquid.

Rendimiento y Latencia: Todas las partes de la pila están optimizadas para una latencia mínima y un rendimiento máximo. HyperBFT finaliza los bloques en menos de un segundo, y HyperCore procesa las operaciones en tiempo real, por lo que los usuarios experimentan una ejecución de órdenes casi instantánea. Efectivamente, no hay tarifas de gas para las acciones de trading: las transacciones de HyperCore no tienen comisiones, lo que permite la colocación y cancelación de órdenes de alta frecuencia sin costo para los usuarios. (Las llamadas a contratos EVM normales en HyperEVM sí incurren en una baja tarifa de gas, pero las operaciones del exchange se ejecutan sin gas en el motor nativo). Este diseño de cero gas y baja latencia hace viables las características de trading avanzadas on-chain. De hecho, Hyperliquid soporta los mismos tipos de órdenes avanzadas y controles de riesgo que los principales CEX, como órdenes límite y stop, margen cruzado y hasta 50× de apalancamiento en los principales mercados. En resumen, la cadena L1 personalizada de Hyperliquid elimina el tradicional compromiso entre velocidad y descentralización. Cada operación es on-chain y transparente, pero la experiencia del usuario, en términos de velocidad de ejecución e interfaz, es paralela a la de un exchange centralizado profesional.

Evolución y Escalabilidad: La arquitectura de Hyperliquid nació de la ingeniería desde los primeros principios. El proyecto se lanzó discretamente en 2022 como un DEX de perpetuos en alfa cerrada en una cadena personalizada basada en Tendermint, probando el concepto de CLOB con ~20 activos y 50× de apalancamiento. Para 2023, se transformó en una L1 totalmente soberana con el nuevo consenso HyperBFT, alcanzando más de 100K órdenes por segundo e introduciendo el trading sin gas y los pools de liquidez comunitarios. La adición de HyperEVM a principios de 2025 abrió las compuertas para los desarrolladores, marcando la evolución de Hyperliquid de un exchange de un solo propósito a una plataforma DeFi completa. Notablemente, todas estas mejoras han mantenido el sistema estable: Hyperliquid reporta un **99.99 % de tiempo de actividad históricamente[25]_. Este historial y la integración vertical_ le dan a Hyperliquid una ventaja técnica significativa: controla toda la pila (consenso, ejecución, aplicación), permitiendo una optimización continua. A medida que la demanda crece, el equipo continúa refinando el software del nodo para un rendimiento aún mayor, asegurando la escalabilidad para la próxima ola de usuarios y mercados on-chain más complejos.

Tokenomics de $HYPE: Gobernanza, Staking y Acumulación de Valor

El diseño económico de Hyperliquid se centra en su token nativo $HYPE**, introducido a finales de 2024 para descentralizar la propiedad y la gobernanza de la plataforma. El lanzamiento y la distribución del token fueron notablemente _centrados en la comunidad_: en noviembre de 2024, Hyperliquid realizó un Evento de Generación de Tokens (TGE) mediante un airdrop, asignando el **31$HYPE no tuvo asignaciones para VCs o inversores privados, reflejando una filosofía de priorizar la propiedad comunitaria. Esta distribución transparente tenía como objetivo evitar la fuerte propiedad de insiders vista en muchos proyectos y, en cambio, empoderar a los traders y constructores reales en Hyperliquid.

El token $HYPE cumple múltiples roles en el ecosistema de Hyperliquid:

• Gobernanza: $HYPE es un token de gobernanza que permite a los tenedores votar en las Propuestas de Mejora de Hyperliquid (HIPs) y dar forma a la evolución del protocolo. Ya se han aprobado actualizaciones críticas como HIP-1, HIP-2 y HIP-3, que establecieron estándares de listado sin permisos para tokens spot y mercados perpetuos. Por ejemplo, HIP-3 abrió la capacidad para que los miembros de la comunidad desplieguen nuevos mercados de perpetuos sin permisos, de manera muy similar a como lo hizo Uniswap para el trading spot, desbloqueando activos de cola larga (long-tail) (incluidos perpetuos del mercado tradicional) en Hyperliquid. La gobernanza decidirá cada vez más sobre listados, ajustes de parámetros y el uso de los fondos de incentivos comunitarios.
• Staking y Seguridad de la Red: Hyperliquid es una cadena de Prueba de Participación (Proof-of-Stake), por lo que **hacer staking de $HYPE en los validadores asegura la red HyperBFT**. Los stakers delegan a los validadores y ganan una porción de las recompensas de bloque y las tarifas. Poco después del lanzamiento, Hyperliquid habilitó el staking con un **rendimiento anual de ~2–2.5$HYPE en staking (o formas derivadas como el próximo staking líquido beHYPE) también puede usarse en la votación de gobernanza, alineando a los participantes de la seguridad con la toma de decisiones.
• Utilidad en el Exchange (Descuentos en Tarifas): Tener o hacer staking de $HYPE confiere **descuentos en las tarifas de trading** en el exchange de Hyperliquid. Similar a cómo el token BNB de Binance o el token DYDX de dYdX ofrecen tarifas reducidas, se incentiva a los traders activos a mantener$HYPE para minimizar sus costos. Esto crea una demanda natural del token entre la base de usuarios del exchange, especialmente los traders de alto volumen.
• Acumulación de Valor a través de Recompras: El aspecto más llamativo de la tokenomics de Hyperliquid es su agresivo mecanismo de tarifa a valor. Hyperliquid utiliza la gran mayoría de sus ingresos por tarifas de trading para recomprar y quemar $HYPE en el mercado abierto, devolviendo valor directamente a los tenedores de tokens. De hecho, el **97$HYPE** (y el resto a un fondo de seguro y a los proveedores de liquidez). Esta es una de las tasas de retorno de tarifas más altas de la industria. A mediados de 2025, Hyperliquid generaba más de 65 millones de dólares en ingresos del protocolo por mes a partir de las tarifas de trading, y prácticamente todo eso se destinaba a recompras de $HYPE, creando una presión de compra constante. Este modelo de token deflacionario, combinado con un suministro fijo de 1B, significa que la tokenomics de$HYPE está orientada a la acumulación de valor a largo plazo para los stakeholders leales. También indica que el equipo de Hyperliquid renuncia a las ganancias a corto plazo (ningún ingreso por tarifas se toma como ganancia o se distribuye a insiders; incluso el equipo central presumiblemente solo se beneficia como tenedores de tokens), en su lugar, canaliza los ingresos al tesoro comunitario y al valor del token.