Una publicación etiquetados con "Polkadot"

La JAM (Join-Accumulate Machine) Chain de Polkadot representa la innovación arquitectónica de blockchain más significativa desde el lanzamiento de Ethereum, reimaginando fundamentalmente cómo opera la computación descentralizada. Introducida por el Dr. Gavin Wood a través del JAM Gray Paper en abril de 2024, JAM transforma Polkadot de una cadena de retransmisión específica para parachains en una "supercomputadora sin confianza mayormente coherente" de propósito general y sin permisos, capaz de una disponibilidad de datos 42 veces mayor (850 MB/s) y una capacidad teórica de más de 3.4 millones de TPS. El protocolo resuelve el persistente problema de particionamiento que afecta a los sistemas blockchain actuales al permitir la componibilidad síncrona dentro de límites de fragmentos dinámicos mientras mantiene la ejecución paralela en más de 350 núcleos. A diferencia de la estrategia de rollups centrada en L2 de Ethereum o el modelo de zona soberana de Cosmos, JAM construye la ejecución fragmentada con un estado coherente directamente en la capa de consenso, utilizando una novedosa Máquina Virtual de Polkadot (PVM) basada en RISC-V y una arquitectura sin transacciones donde toda la computación fluye a través de una tubería Refine→Accumulate. Con 43 equipos de implementación compitiendo por 10 millones de DOT en premios, múltiples clientes logrando el 100% de conformidad para agosto de 2025, y el despliegue en la red principal (mainnet) previsto para principios de 2026, JAM está posicionada para cumplir lo que la visión original de Ethereum 2.0 prometió: ejecución escalable nativa sin sacrificar la componibilidad ni la seguridad.

El modelo computacional: cómo los procesos JAM funcionan a escala​

JAM introduce un paradigma computacional fundamentalmente nuevo llamado CoreJAM (Collect, Refine, Join, Accumulate), que divide la ejecución de blockchain en fases distintas optimizadas para la paralelización y la eficiencia. El nombre JAM deriva de las porciones en cadena —Join y Accumulate—, mientras que Collect y Refine ocurren fuera de la cadena. Esta arquitectura establece dos entornos de ejecución principales que trabajan en concierto: la ejecución en el núcleo para la computación paralela pesada y la ejecución en cadena para la integración de estados.

En la etapa Refine (ejecución en el núcleo), los elementos de trabajo se someten a un procesamiento paralelo sin estado a través de múltiples núcleos de validador, con cada núcleo manejando hasta 15 MB de datos de entrada por intervalo de 6 segundos y produciendo salidas comprimidas de un máximo de 90 KB, una notable relación de compresión de 166x. Esta etapa proporciona 6 segundos de tiempo de ejecución de PVM por núcleo, triplicando el límite de 2 segundos de las actuales Funciones de Validación de Parachain de Polkadot (PVF). La función Refine realiza el trabajo computacional pesado completamente fuera de la cadena, con solo búsquedas de preimagen como su operación con estado, lo que permite una paralelización masiva sin contención de estado.

Después del refinamiento, la etapa Accumulate (ejecución en cadena) integra los resultados del trabajo en el estado de la cadena a través de operaciones con estado limitadas a aproximadamente 10 milisegundos por salida. Esta función se ejecuta en todos los validadores y puede leer el almacenamiento de cualquier servicio, escribir en su propio almacén de clave-valor, transferir fondos entre servicios, crear nuevos servicios, actualizar código y solicitar la disponibilidad de preimagen. El marcado contraste en los presupuestos de ejecución —6 segundos fuera de la cadena frente a 10 milisegegundos en cadena— refleja la visión fundamental de JAM: al trasladar la computación costosa fuera de la cadena y paralelizarla, el sistema reserva un valioso tiempo en cadena solo para las transiciones de estado esenciales.

Los servicios en JAM definen un tercer punto de entrada llamado onTransfer, que maneja la comunicación asíncrona entre servicios. Este sistema de mensajería permite que los servicios interactúen sin bloquearse, con mensajes enviados sin valores de retorno inmediatos. El diseño anticipa futuras mejoras como la asignación de gas adicional a través de núcleos secundarios para interacciones complejas entre servicios.

Este modelo de ejecución dual logra lo que Wood describe como semicoherencia: los servicios programados para el mismo núcleo en el mismo bloque interactúan de forma síncrona (subconjunto coherente), mientras que los servicios en diferentes núcleos se comunican de forma asíncrona (incoherente en general). Los límites entre la ejecución coherente e incoherente permanecen fluidos y económicamente impulsados en lugar de ser impuestos por el protocolo, lo que permite que los servicios que se comunican con frecuencia se ubiquen en los mismos núcleos para un comportamiento síncrono mientras se mantiene la escalabilidad en todo el sistema. Esto representa un avance en la resolución del antagonismo tamaño-sincronía que ha limitado las arquitecturas blockchain anteriores.

Transformación arquitectónica de cadena de retransmisión a computación basada en servicios​

JAM reimagina fundamentalmente la arquitectura de Polkadot, pasando de un diseño muy específico y centrado en parachains a un sustrato computacional minimalista y de propósito general. La actual Cadena de Retransmisión de Polkadot consagra las parachains directamente en el protocolo con un límite estricto de aproximadamente 50 ranuras, requiere acceso basado en subastas que cuesta millones en DOT, y ejecuta toda la lógica de las parachains a través de rutas de validación fijas. JAM reemplaza esto con servicios, entornos de ejecución encapsulados y sin permisos que cualquiera puede desplegar sin aprobación de gobernanza ni subastas, limitados solo por factores criptoeconómicos (depósitos de DOT).

El cambio de filosofía arquitectónica es profundo: de una cadena de retransmisión actualizable a un protocolo fijo con servicios actualizables. Mientras que Polkadot 1.0 mantenía una cadena de retransmisión altamente actualizable que acumulaba complejidad con el tiempo, JAM fija los parámetros del protocolo central (codificación de encabezados de bloque, esquemas de hash, protocolo de red QUIC, parámetros de tiempo) para permitir una optimización agresiva y simplificar múltiples implementaciones. La funcionalidad a nivel de aplicación, incluyendo el staking, la gobernanza y la asignación de tiempo de núcleo, reside en servicios que pueden actualizarse de forma independiente sin tocar el protocolo central. Esta arquitectura de cadena no actualizable reduce drásticamente la complejidad al tiempo que preserva la flexibilidad donde más importa: en la capa de aplicación.

Las parachains se convierten en un tipo de servicio entre muchos en el modelo de JAM. Toda la funcionalidad de las parachains de Polkadot 1.1 se consolidará en un único servicio "Parachains" o "CoreChains", garantizando una compatibilidad total con versiones anteriores con garantías codificadas. Las parachains existentes transicionan automáticamente para ejecutarse sobre JAM cuando la cadena de retransmisión se actualiza, sin requerir cambios de código. El modelo de servicio generaliza lo que las parachains podían hacer en patrones de ejecución arbitrarios: contratos inteligentes desplegados directamente en núcleos, marcos basados en actores como CorePlay, ZK-rollups, servicios de disponibilidad de datos y modelos de ejecución completamente novedosos aún no concebidos.

El modelo de gestión de estados también se transforma significativamente. El Polkadot actual utiliza raíces de estado posteriores en los encabezados de bloque; los bloques esperan a que la computación completa termine antes de la distribución. JAM emplea raíces de estado previas que se retrasan un bloque, lo que permite el procesamiento en tubería (pipelining): las computaciones ligeras (aproximadamente el 5% de la carga de trabajo) se ejecutan inmediatamente, el bloque se distribuye antes de que las tareas de acumulación pesadas se completen, y el siguiente bloque comienza a procesarse antes de que el bloque actual termine su ejecución. Esta elección arquitectónica significa que JAM utiliza el tiempo completo de 6 segundos del bloque para la computación, logrando de 3 a 3.5 segundos de tiempo de computación efectivo por bloque, frente a menos de 2 segundos en el Polkadot actual.

La transición de JAM de WebAssembly a la Máquina Virtual de Polkadot (PVM) basada en RISC-V representa otro cambio fundamental. RISC-V, con solo 47 instrucciones base, ofrece una determinismo superior, velocidades de ejecución excepcionales en hardware convencional, fácil transpilación a x86/x64/ARM, soporte oficial de la cadena de herramientas LLVM y manejo natural de continuaciones con pila en memoria. Críticamente, PVM proporciona "medición gratuita" en comparación con la sobrecarga de medición de WebAssembly, mientras que la arquitectura basada en registros (frente al diseño basado en pila de WASM) evita el problema NP-completo de asignación de registros. Esto permite continuaciones habilitadas para RISC-V que establecen nuevos estándares para la codificación escalable de múltiples núcleos, permitiendo que los programas se pausen y reanuden a través de los límites de los bloques, algo esencial para la arquitectura asíncrona y paralela de JAM.

Especificaciones técnicas: objetivos de rendimiento y requisitos de validador​

JAM apunta a métricas de rendimiento extraordinarias que lo posicionan como un salto generacional en la capacidad computacional de blockchain. El sistema busca una disponibilidad de datos de 850 MB/s, una mejora de 42x sobre Polkadot vanilla antes de las mejoras de Asynchronous Backing y órdenes de magnitud más allá de los 1.3 MB/s de Ethereum. Esto se traduce en un rendimiento agregado de aproximadamente 2.3 Gbps en todos los núcleos, con cada núcleo procesando 5 MB de entrada por ranura de 6 segundos.

La capacidad de rendimiento de transacciones escala drásticamente: más de 3.4 millones de TPS como máximo teórico basado en el objetivo de disponibilidad de datos de 850 MB/s. Las pruebas de estrés en el mundo real validan estas proyecciones: Kusama logró 143,000 TPS con solo el 23% de capacidad de carga en agosto de 2025, mientras que la prueba de estrés "Spammening" de Polkadot alcanzó 623,000 TPS en 2024. Con las optimizaciones adicionales de JAM y el recuento de núcleos expandido (apuntando a 350 núcleos con escalado elástico), el umbral de más de 1 millón de TPS se vuelve alcanzable en producción.

La capacidad computacional se mide en 150 mil millones de gas por segundo cuando está completamente operativa, según las estimaciones del Gray Paper, lo que refleja la ejecución total de PVM en todos los núcleos. El mecanismo de consenso mantiene tiempos de bloque de 6 segundos con finalidad determinista a través de GRANDPA en aproximadamente 18 segundos (aproximadamente 3 bloques). SAFROLE, el algoritmo de producción de bloques basado en SNARK de JAM, proporciona una operación casi sin bifurcaciones a través de la selección anónima de validadores utilizando zkSNARKs y RingVRF, con tickets que sirven como entradas anónimas para la producción de bloques con dos épocas de antelación.

Los requisitos de hardware para los validadores siguen siendo accesibles para operadores profesionales, aunque demandan recursos significativos:

• CPU: 8 núcleos físicos a 3.4 GHz mínimo (se prioriza el rendimiento de un solo hilo)
• RAM: 128 GB mínimo
• Almacenamiento: 2 TB NVMe SSD mínimo (priorizando la latencia sobre el rendimiento), con un crecimiento continuo estimado en 50 GB/mes
• Red: Conexión simétrica de 500 Mbit/s mínimo (se prefiere 1 Gbit/s) para manejar un gran número de servicios y asegurar el control de congestión
• Sistema Operativo: Basado en Linux (Kernel 5.16 o posterior)
• Tiempo de actividad: 99%+ requerido para evitar penalizaciones por recorte (slashing)

El conjunto de validadores consta de 1,023 validadores, el mismo número que el Polkadot actual, todos recibiendo recompensas de bloque iguales independientemente del stake que los respalde. Esta distribución equitativa de recompensas crea incentivos económicos para que el stake se distribuya entre los validadores en lugar de concentrarse en unos pocos operadores grandes, promoviendo la descentralización. Los requisitos mínimos de stake son dinámicos; históricamente, entrar en el conjunto de validadores activos requería aproximadamente 1.75 millones de DOT de stake total (stake propio más nominaciones), aunque la intención de nominación mínima se sitúa en 250 DOT. El período de desvinculación de 28 días permanece sin cambios con respecto al Polkadot actual.

La capa de red de JAM transiciona al protocolo QUIC para conexiones directas punto a punto entre los más de 1,000 validadores, evitando los problemas de agotamiento de sockets de las pilas de red tradicionales. Dado que JAM es fundamentalmente sin transacciones (sin mempool ni gossip), el sistema emplea la difusión en cuadrícula (grid-diffusal) para la transmisión: los validadores se organizan en una cuadrícula lógica y los mensajes se propagan por fila y luego por columna, reduciendo drásticamente los requisitos de ancho de banda en comparación con los protocolos de gossip completos.

El entorno de pruebas JAM Toaster demuestra la escala de la infraestructura que soporta el desarrollo: 1,023 nodos con 12,276 núcleos y 16 TB de RAM ubicados en las instalaciones del Polkadot Palace de Lisboa, clasificándose entre las 500-1000 supercomputadoras globales más importantes. Esta infraestructura de pruebas a gran escala aborda las limitaciones históricas donde las pequeñas redes de prueba no podían simular dinámicas de red a gran escala y las redes de producción carecían de capacidades de monitoreo exhaustivas.

Modelo económico: tokenomics de DOT y precios basados en tiempo de núcleo​

JAM mantiene a DOT como el único token nativo sin creación de nuevos tokens, preservando la continuidad con el modelo económico de Polkadot al tiempo que introduce cambios estructurales significativos. La arquitectura económica se centra en el despliegue de servicios sin permisos, donde cualquiera puede cargar y ejecutar código a cambio de tarifas proporcionales a los recursos utilizados. Los servicios no tienen límites predefinidos de código, datos o estado; la capacidad está determinada por factores criptoeconómicos, específicamente la cantidad de DOT depositada como garantía económica.

La tokenomía experimentó una gran transformación en 2025 con el Referéndum 1710, que implementó un límite de suministro de 2.1 mil millones de DOT y un calendario de inflación escalonada. Las emisiones anuales de tokens se reducirán a la mitad cada dos años a partir de marzo de 2026, creando un modelo de escasez similar al de Bitcoin. La inflación anual actual es del 7.56% (frente al 10% inicial), proyectándose un suministro total de aproximadamente 1.91 mil millones de DOT para 2040 frente a 3.4 mil millones bajo el modelo anterior. Esta presión deflacionaria tiene como objetivo apoyar la acumulación de valor a largo plazo mientras se mantienen recompensas suficientes para la seguridad de la red.

La estructura de tarifas transiciona de las subastas de parachains a la tarificación basada en el tiempo de núcleo (coretime), reemplazando el complejo mecanismo de subasta de ranuras de Polkadot 1.0 con opciones flexibles:

El tiempo de núcleo a granel (Bulk Coretime) proporciona suscripciones mensuales para un acceso consistente a los núcleos computacionales, lo que permite una presupuestación predecible para proyectos que requieren un rendimiento garantizado. El tiempo de núcleo bajo demanda (On-Demand Coretime) ofrece acceso de pago por uso para un uso esporádico, reduciendo drásticamente las barreras de entrada en comparación con las subastas de ranuras de parachain de millones de dólares. Este modelo de tiempo de núcleo ágil permite adquirir recursos computacionales por duraciones que van desde segundos hasta años, optimizando la eficiencia del capital.

JAM introduce un novedoso modelo de consumo de recursos mixto donde los paquetes de trabajo pueden combinar tareas computacionalmente intensivas con operaciones intensivas en datos. Al emparejar servicios con diversos requisitos de recursos —por ejemplo, verificación de pruebas de conocimiento cero (intensiva en computación) con disponibilidad de datos (intensiva en almacenamiento)— el sistema optimiza la utilización del hardware del validador y reduce los costos generales. Los incentivos económicos alinean naturalmente a los secuenciadores para agrupar elementos de trabajo relacionados y ubicar servicios que se comunican con frecuencia en los mismos núcleos.

La arquitectura sin transacciones elimina por completo las estructuras tradicionales de tarifas de transacción. En lugar de que los usuarios envíen transacciones a un mempool con tarifas de gas, todas las acciones pasan por la etapa Refine fuera de la cadena antes de que los resultados se integren en la cadena. Este modelo económico fundamentalmente diferente cobra por la adquisición de tiempo de núcleo y el procesamiento de paquetes de trabajo en lugar de gas por transacción, con tarifas determinadas por los recursos computacionales y de datos consumidos durante las etapas Refine y Accumulate.

La economía de los validadores continúa con el Nominated Proof-of-Stake (NPoS) de Polkadot, con recompensas de bloque iguales distribuidas entre todos los validadores activos por era, independientemente del tamaño del stake. Los validadores establecen sus propias tasas de comisión deducidas de las recompensas totales antes de la distribución a los nominadores. Las fuentes de ingresos incluyen recompensas de bloque (primarias), bonificaciones por puntos de era por participación activa, propinas de los usuarios (100% para el validador) y tarifas de comisión de los nominadores. Las estadísticas actuales de staking muestran una tasa de participación del 58% con 825.045 millones de DOT en stake distribuidos entre 600 validadores activos.

Los servicios asocian saldos de tokens directamente con el código y el estado, lo que permite ajustes del modelo económico que no son fácilmente alcanzables en cadenas puramente actualizables. Esta innovación permite a los servicios mantener y gestionar DOT, creando actores económicos que pueden pagar sus propias operaciones, implementar mecanismos tokenómicos novedosos o servir como custodios de fondos de usuarios, todo ello sin intermediarios de confianza.

El modelo de seguridad económica se basa en Validadores Económicos (ELV), un mecanismo de rollup cínico donde validadores seleccionados aleatoriamente reejecutan el trabajo para verificar la corrección. Este enfoque resulta aproximadamente 4,000 veces más rentable que las pruebas ZK para garantizar la corrección computacional, aprovechando el modelo de seguridad criptoeconómica probado de Polkadot. Cuando se disputan los resultados del trabajo, el mecanismo de juicio puede pausar la finalidad hasta por 1 hora mientras los validadores llegan a un consenso, manteniendo las garantías de seguridad incluso bajo condiciones adversas.

Estado de desarrollo: implementaciones, redes de prueba y hoja de ruta a la red principal​

A octubre de 2025, el desarrollo de JAM ha alcanzado una masa crítica con 43 equipos de implementación activos en cinco categorías de idiomas compitiendo por el fondo de premios de 10 millones de DOT + 100,000 KSM (valorado entre $60 y $100 millones de USD). Esta diversidad de implementadores sin precedentes tiene como objetivo difundir la experiencia más allá de un solo equipo, garantizar la resiliencia del protocolo a través de la diversidad de clientes e identificar ambigüedades en las especificaciones a través de implementaciones independientes.

Múltiples implementaciones lograron el 100% de conformidad con JAM para agosto de 2025, incluyendo JAM DUNA (Go), JamZig (Zig), Jamzilla (Go), JavaJAM (Java), SpaceJam (Rust), Vinwolf (Rust), Jamixir (Elixir) y Boka (Swift). El Panel de Conformidad de JAM proporciona puntos de referencia de rendimiento en tiempo real, resultados de pruebas de fuzzing y comparaciones de implementaciones, lo que permite una evaluación transparente de la madurez de cada cliente. La implementación PolkaJAM de Parity en Rust actualmente lidera en métricas de rendimiento.

El JAM Gray Paper ha progresado a través de múltiples revisiones: la v0.7.0 se lanzó el 25 de junio de 2025 con pseudocódigo detallado para la ejecución de PVM y el Agregador de Planificación (Aggregating Scheduler), seguida de la v0.7.1 el 26 de julio de 2025 incorporando los comentarios de la comunidad. El Gray Paper emula el enfoque del Yellow Paper de Ethereum, proporcionando especificaciones matemáticas formales que permiten múltiples implementaciones independientes en lugar de depender de un único cliente de referencia.

La actividad de la red de prueba (testnet) se aceleró a lo largo de 2025 con el Evento JAM Experience en Lisboa (9-11 de mayo), que marcó una importante fiesta de lanzamiento público de la testnet a la que asistieron desarrolladores internacionales. La testnet de Rollup Mínimo Viable se lanzó en junio de 2025, permitiendo a los desarrolladores probar la funcionalidad básica de JAM en un entorno de red en vivo. Múltiples equipos de implementación ejecutan testnets privadas continuamente, y Parity lanzó el binario experimental PolkaJAM, lo que permite a los desarrolladores crear sus propias testnets de JAM para experimentar.

El Premio para Implementadores de JAM estructura las recompensas a través de cinco hitos por cada ruta de implementación (Nodo Validador, Nodo Validador No-PVM o Nodo Ligero):

Hito 1 (IMPORTER): 100,000 DOT + 1,000 KSM por pasar las pruebas de conformidad de transición de estado e importar bloques. Las presentaciones se abrieron en junio de 2025 con la Polkadot Fellowship revisando las propuestas. Hito 2 (AUTHORER): 100,000 DOT + 1,000 KSM adicionales por la conformidad completa, incluyendo la producción de bloques, la red y los componentes fuera de la cadena. Hito 3 (HALF-SPEED): 100,000 DOT + 1,000 KSM por lograr un rendimiento a nivel de Kusama, otorgando acceso a JAM Toaster para pruebas a gran escala. Hito 4 (FULL-SPEED): 100,000 DOT + 1,000 KSM por un rendimiento a nivel de la red principal de Polkadot con una auditoría de seguridad externa profesional gratuita. Hito 5 (SECURE): 100,000 DOT + 1,000 KSM finales por pasar auditorías de seguridad completas sin vulnerabilidades significativas.

La diversidad de lenguajes abarca lenguajes empresariales tradicionales (Java, Kotlin, C#, Go en el Conjunto A), lenguajes de rendimiento nativo (C, C++, Rust, Swift, Zig en el Conjunto B), lenguajes de scripting concisos (Python, JavaScript, TypeScript en el Conjunto C) y lenguajes centrados en la corrección (OCaml, Elixir, Julia, Haskell en el Conjunto D). El Conjunto Z ofrece un máximo de 5,000 KSM para implementaciones en lenguajes esotéricos como Brainfuck o Whitespace, demostrando el espíritu lúdico de la comunidad al tiempo que prueba la claridad de las especificaciones.

La línea de tiempo para el despliegue en la red principal sigue un ambicioso calendario:

• Finales de 2025: Revisiones finales del Gray Paper (v0.8.0, v0.9.0, acercándose a v1.0), continuas presentaciones y revisiones de hitos, participación ampliada en la testnet.
• Primer trimestre de 2026: Actualización de la red principal de JAM prevista en la red de Polkadot tras la aprobación de la gobernanza a través de un referéndum de OpenGov.
• 2026: Despliegue de CoreChain Fase 1, testnet pública oficial de JAM, transición completa de la red de Polkadot a la arquitectura JAM.

La estrategia de despliegue implica una única actualización integral en lugar de cambios incrementales iterativos, lo que permite una restricción precisa de las acciones posteriores a la actualización y minimiza la sobrecarga para los desarrolladores debido a cambios constantes que rompen la compatibilidad. Este enfoque consolida todos los cambios disruptivos en una sola transición, evitando la acumulación de complejidad que afectó la evolución de Polkadot 1.0. Sin embargo, la aprobación de la gobernanza sigue siendo obligatoria: JAM requiere la aprobación de la gobernanza descentralizada en cadena de Polkadot con la votación de los poseedores de tokens DOT. El precedente de la aprobación casi unánime del Referéndum 682 en mayo de 2024 (con el respaldo de más de 31 millones de DOT) sugiere un fuerte apoyo de la comunidad, aunque el despliegue final en la red principal requiere una aprobación de gobernanza separada.

Ya están surgiendo implementaciones en el mundo real. Acala Network anunció JAMVerse en agosto de 2025, construyendo la primera cadena dApp nativa de JAM con un cliente JAM de clase B basado en Swift (Boka). Su hoja de ruta incluye la migración de los servicios DeFi centrales (Swap, Staking, LDOT) a JAM para operaciones con latencia sub-bloque, el desarrollo de un adaptador JAM-XCM para preservar la interoperabilidad con las parachains de Substrate y la demostración de préstamos flash entre cadenas habilitados por la componibilidad síncrona. Quartz de Unique Network está en transición a entornos de prueba internos para la arquitectura JAM, con la planificación completa para octubre de 2025.

Impacto en el ecosistema: compatibilidad con versiones anteriores y estrategias de migración​

El diseño de JAM prioriza la compatibilidad total con versiones anteriores con las parachains existentes de Polkadot, asegurando que la transición mejore en lugar de interrumpir el ecosistema. La documentación oficial confirma que "parte de la propuesta incluirá herramientas y garantías de compatibilidad codificadas", y la Web3 Foundation asegura que "las parachains seguirán siendo ciudadanos de primera clase incluso después de JAM". Cuando JAM se lance, la cadena de retransmisión se actualizará y las parachains se convertirán automáticamente en servicios que se ejecutarán sobre JAM sin requerir ningún cambio de código.

El Servicio de Parachains (alternativamente llamado CoreChains o ChainService) consolida toda la funcionalidad de las parachains de Polkadot 1.1 en un único servicio JAM. Las parachains existentes basadas en Substrate continúan operando a través de esta capa de compatibilidad con un comportamiento funcionalmente inalterado: "La funcionalidad de cualquiera de las parachains que actualmente se ejecutan en Polkadot no se verá afectada". Desde la perspectiva de los equipos de parachains, "la pila tecnológica no parece muy diferente. Seguirán siendo validadas por validadores" con flujos de trabajo de desarrollo similares.

Tres rutas de migración permiten a los equipos adoptar las capacidades de JAM a su propio ritmo:

La Opción A: Sin Migración permite a los equipos de parachains seguir operando exactamente como antes con cero esfuerzo. El servicio de parachains se encarga de todas las preocupaciones de compatibilidad, manteniendo las características de rendimiento actuales y los flujos de trabajo de desarrollo. Esta ruta predeterminada es adecuada para equipos satisfechos con las capacidades existentes o que prefieren posponer las características específicas de JAM hasta que la tecnología madure.

La Opción B: Migración Parcial permite enfoques híbridos donde los equipos continúan operando como una parachain tradicional mientras despliegan funcionalidades específicas como servicios nativos de JAM. Por ejemplo, una parachain DeFi podría continuar sus operaciones de cadena principal sin cambios mientras despliega un servicio ZK-rollup para características de privacidad o un servicio de oráculo para feeds de precios directamente en los núcleos de JAM. Esta transición gradual permite probar nuevas capacidades sin un compromiso total, manteniendo la compatibilidad con versiones anteriores mientras se accede a funciones avanzadas de forma selectiva.

La Opción C: Migración Completa implica la reconstrucción utilizando el modelo de servicio de JAM con puntos de entrada Refine, Accumulate y onTransfer distintos. Esta ruta proporciona la máxima flexibilidad: despliegue sin permisos, componibilidad síncrona a través de Accords, marcos basados en actores de CorePlay y acceso directo a los novedosos modelos de ejecución de JAM. JAMVerse de Acala ejemplifica este enfoque: construir una implementación completa nativa de JAM mientras se mantiene la operación de la parachain heredada durante la transición. La migración completa requiere un esfuerzo de desarrollo significativo, pero desbloquea todo el potencial de JAM.

La infraestructura de soporte a la migración incluye la herramienta de migración Omicode mencionada en la documentación de Acala como habilitadora de una "migración fluida a JAM sin necesidad de modificar la lógica de tiempo de ejecución", aparentemente una capa de compatibilidad para las parachains existentes de Substrate. El SDK de Polkadot sigue siendo compatible con JAM, aunque las Funciones de Validación de Parachain (PVF) se redirigen de WebAssembly a PVM. Dado que PVM representa una modificación menor de RISC-V (que ya es un objetivo oficial de LLVM), las bases de código existentes compiladas a WASM generalmente pueden recompilarse a PVM con cambios mínimos.

La transición de WASM a PVM ofrece varios beneficios: la medición gratuita elimina la sobrecarga de gas durante la ejecución, la arquitectura basada en registros evita el problema NP-completo de asignación de registros inherente al diseño basado en pila de WASM, el soporte natural de continuaciones permite que los programas se pausen y reanuden a través de los límites de los bloques, y las velocidades de ejecución excepcionales en hardware convencional proporcionan mejoras de rendimiento sin cambios de infraestructura. Los pallets FRAME de Substrate siguen funcionando dentro de los servicios de parachain, aunque el sistema medido de JAM a menudo obvia los requisitos frecuentes de benchmarking que cargaban el desarrollo de Substrate.

La evolución del formato de mensajes entre consensos (XCM) garantiza la interoperabilidad durante la transición. El XCMP completo (Cross-Chain Message Passing) se vuelve obligatorio en JAM; mientras que el HRMP actual (Horizontal Relay-routed Message Passing) almacena todos los datos de los mensajes en la cadena de retransmisión con límites de carga útil de 4 KB, el XCMP de JAM solo coloca los encabezados de los mensajes en la cadena con transmisión de datos fuera de la cadena ilimitada. Este requisito arquitectónico se deriva de los estrictos límites de transmisión de datos entre las etapas Refine y Accumulate, lo que permite cargas de datos realistas sin cuellos de botella en la cadena de retransmisión.

Los adaptadores JAM-XCM mantienen la interoperabilidad entre los servicios JAM y las parachains de Substrate durante el período de transición. Las mejoras de XCM v5 que se lanzarán en 2025 incluyen transacciones de múltiples saltos, pagos de tarifas multicadena, menos firmas requeridas y una mejor prevención de errores, todo diseñado para funcionar sin problemas durante la transición de Polkadot a JAM. Los Accords introducen capacidades XCM síncronas que permiten interacciones con mínima confianza, como la teletransportación directa de tokens entre cadenas sin intermediarios basados en reservas.

Los mecanismos de gobernanza para el staking, la tesorería y las actualizaciones de protocolo migran a los servicios en lugar de consagrarse en el protocolo central. Esta separación de preocupaciones simplifica la propia cadena JAM al tiempo que preserva toda la funcionalidad necesaria en el código de servicio actualizable. Las funciones a nivel de aplicación, incluida la distribución de recompensas de staking, los mercados de tiempo de núcleo y la votación de gobernanza, residen en servicios que pueden evolucionar de forma independiente a través de sus propios mecanismos de actualización sin requerir cambios a nivel de protocolo.

La transición de validador sigue siendo sencilla: los operadores deberán ejecutar clientes compatibles con JAM en lugar de los clientes actuales de Polkadot, pero las responsabilidades del validador de producir bloques, validar transacciones (ahora paquetes de trabajo) y mantener el consenso continúan sin cambios. El cambio de BABE+GRANDPA a SAFROLE+GRANDPA para el consenso afecta principalmente a los aspectos internos de la implementación del cliente en lugar de a los procedimientos operativos. Los validadores que mantengan un tiempo de actividad superior al 99%, respondan a las solicitudes de validación con prontitud y participen en el consenso seguirán recibiendo recompensas iguales por era, como en el Polkadot actual.

Experiencia del desarrollador: de contratos inteligentes a servicios y más allá​

JAM transforma fundamentalmente la experiencia del desarrollador al eliminar las barreras de entrada y expandir las opciones de capacidad. Donde Polkadot 1.0 obligaba a los equipos a elegir entre contratos inteligentes (capacidad limitada, fácil despliegue) o parachains (capacidad completa, acceso basado en subastas), JAM proporciona un entorno flexible y rico para ambos, además de modelos de ejecución novedosos.

El modelo de despliegue de servicios sin permisos se asemeja al despliegue de contratos inteligentes en Ethereum: los desarrolladores pueden desplegar código como un servicio sin aprobación de gobernanza ni subastas de ranuras, pagando solo por los recursos utilizados a través de la adquisición de tiempo de núcleo. Esto reduce drásticamente las barreras financieras: sin ofertas de subasta multimillonarias, sin compromisos de ranura de dos años, sin complejas mecánicas de crowdloan. Los servicios escalan económicamente a través de depósitos de DOT que limitan criptoeconómicamente el consumo de recursos, en lugar de a través de barreras políticas o financieras.

Los contratos inteligentes ink! continúan prosperando en el ecosistema de JAM con un potencial despliegue directo en los núcleos de JAM a través de servicios dedicados, eliminando la necesidad de un alojamiento intermedio de parachain. Las herramientas siguen siendo maduras: cargo-contract para la compilación, ink! playground para la experimentación, rustfmt y rust-analyzer para el desarrollo, el explorador Chainlens para la verificación de contratos y marcos de pruebas de integración. La ruta de graduación desde la prueba de concepto hasta la producción sigue siendo clara: comenzar con contratos ink! para una iteración rápida, validar la adecuación producto-mercado y luego migrar a servicios JAM o parachains cuando los requisitos de rendimiento lo exijan, reutilizando el código Rust, las pruebas y los componentes de frontend en todo el proceso.

Tres puntos de entrada de servicio definen el modelo de programación de JAM, lo que requiere que los desarrolladores piensen de manera diferente sobre la computación:

La función Refine maneja la computación sin estado que transforma las entradas de rollup en salidas. Acepta hasta 15 MB de elementos de trabajo por ranura de 6 segundos, se ejecuta durante hasta 6 segundos de gas PVM y produce resultados comprimidos de un máximo de 90 KB. Refine se ejecuta fuera de la cadena en paralelo a través de subconjuntos de validadores, con solo búsquedas de preimagen disponibles para el acceso a datos. Esta función realiza el trabajo computacional pesado (procesamiento de transacciones, verificación de pruebas, transformación de datos) completamente aislado del estado global.

La función Accumulate integra las salidas de Refine en el estado del servicio a través de operaciones con estado limitadas a aproximadamente 10 milisegundos por salida. Puede leer el almacenamiento de cualquier servicio (lo que permite consultas entre servicios), escribir en su propio almacén de clave-valor, transferir fondos entre servicios, crear nuevos servicios, actualizar su propio código y solicitar la disponibilidad de preimagen. Accumulate se ejecuta de forma síncrona en todos los validadores, lo que lo hace costoso pero seguro por defecto. La asimetría —6 segundos para Refine frente a 10 milisegundos para Accumulate— impone disciplina arquitectónica: empujar la computación fuera de la cadena, mantener las actualizaciones de estado mínimas.

La función onTransfer maneja la comunicación entre servicios a través de mensajería asíncrona. Los servicios pueden enviar mensajes sin esperar respuestas, lo que permite un acoplamiento flexible al tiempo que evita bloqueos. Las futuras mejoras pueden permitir la asignación de gas adicional para interacciones complejas entre servicios o el manejo de patrones síncronos a través de Accords.

CorePlay representa un marco experimental basado en actores que muestra las capacidades únicas de JAM. Los actores desplegados directamente en los núcleos pueden usar patrones de programación síncronos normales, código de estilo fn main() estándar con sintaxis async/await. Cuando los actores en el mismo núcleo se llaman entre sí, la ejecución procede de forma síncrona. Al llamar a actores en diferentes núcleos, las continuaciones de PVM pausan automáticamente la ejecución, serializan el estado y se reanudan en un bloque posterior cuando llegan los resultados. Esta abstracción hace que la ejecución asíncrona de múltiples bloques parezca síncrona para los desarrolladores, simplificando drásticamente la lógica de las aplicaciones distribuidas.

Las mejoras en las herramientas para desarrolladores incluyen un despliegue más sencillo a través de la creación de servicios sin permisos, requisitos de benchmarking reducidos mediante la ejecución PVM medida de JAM, precios de tiempo de núcleo transparentes y predecibles (evitando la volatilidad de tarifas al estilo Ethereum) y acceso a JAM Toaster para implementadores de Hito 3+ que proporciona una simulación de red completa de 1,023 nodos para pruebas de rendimiento realistas. El soporte para múltiples lenguajes —equipos que trabajan en Rust, Go, Swift, Zig, Elixir, OCaml y más— demuestra la claridad de las especificaciones y permite a los desarrolladores elegir cadenas de herramientas familiares.

La componibilidad síncrona transforma lo que es posible en aplicaciones multicadena. Las parachains actuales de Polkadot se comunican de forma asíncrona a través de XCM, lo que requiere que las aplicaciones manejen respuestas retrasadas, tiempos de espera y escenarios de reversión. Los Accords de JAM permiten contratos inteligentes de múltiples instancias que gobiernan los protocolos de interacción entre servicios con garantías de ejecución síncrona. Por ejemplo, la hoja de ruta de Acala demuestra "iniciar un préstamo flash en Ethereum y ejecutar arbitraje en múltiples cadenas a través de una única llamada sincronizada", atomicidad previamente imposible en ecosistemas blockchain fragmentados.

El cambio de los pallets de Substrate a los servicios JAM reduce la fricción de gobernanza: los pallets de Substrate requieren la aprobación de la gobernanza en cadena para su despliegue y actualizaciones, mientras que los servicios JAM se despliegan sin permisos como los contratos inteligentes. Los desarrolladores conservan la compatibilidad con el SDK de Substrate y pueden seguir utilizando FRAME para los servicios de parachain, pero los servicios nativos de JAM acceden a modelos de desarrollo simplificados sin la sobrecarga de coordinación de actualización de pallets.

La documentación y los recursos educativos se expandieron significativamente a lo largo de 2025 con el JAM 2025 World Tour, que llegó a 9 ciudades en 2 continentes y atrajo a más de 1,300 desarrolladores. La documentación técnica incluye el completo Gray Paper, las secciones de JAM en la Wiki de Polkadot, guías oficiales para desarrolladores y tutoriales creados por la comunidad. El programa Decentralized Futures de la Web3 Foundation financia iniciativas de educación sobre JAM, mientras que el Premio para Implementadores crea incentivos económicos para producir documentación y herramientas para desarrolladores de alta calidad.

Visión estratégica: resolución del trilema de blockchain mediante innovación arquitectónica​

La visión de Gavin Wood para JAM aborda lo que él identifica como la limitación fundamental de blockchain: el antagonismo tamaño-sincronía, donde los sistemas deben elegir entre escala y coherencia. Las cadenas monolíticas como Bitcoin y Ethereum L1 logran alta sincronía y componibilidad, pero no pueden escalar más allá de los límites computacionales de un solo nodo. Los sistemas fragmentados como los L2 de Ethereum, las parachains de Polkadot y las zonas de Cosmos logran escala a través del particionamiento, pero sacrifican la coherencia, forzando a las aplicaciones a silos aislados con solo comunicación asíncrona entre fragmentos.

JAM intenta trascender esta falsa dicotomía a través de la coherencia parcial, un sistema que "garantiza la coherencia durante períodos críticos" mientras mantiene la escalabilidad a través de la paralelización. Los servicios programados para el mismo núcleo en el mismo bloque interactúan de forma síncrona, creando subconjuntos coherentes. Los servicios en diferentes núcleos se comunican de forma asíncrona, lo que permite la ejecución paralela. Críticamente, los límites de los fragmentos permanecen fluidos y económicamente impulsados en lugar de ser impuestos por el protocolo. Los secuenciadores tienen incentivos para ubicar servicios que se comunican con frecuencia, y los desarrolladores pueden optimizar la interacción síncrona cuando sea necesario sin la sincronía global del sistema.

El objetivo estratégico se centra en crear una "supercomputadora sin confianza mayormente coherente" que combine tres propiedades históricamente incompatibles:

Un entorno de contratos inteligentes sin permisos similar a Ethereum permite a cualquiera desplegar código sin aprobación de autoridad ni barreras económicas. Los servicios se crean y actualizan sin votos de gobernanza, victorias en subastas o compromisos de ranura. Esta apertura impulsa la innovación al eliminar las barreras institucionales, permitiendo la experimentación rápida y fomentando un mercado competitivo de servicios en lugar de recursos asignados políticamente.

La computación segura de banda lateral paralela sobre una red de nodos escalable pionera de Polkadot proporciona seguridad compartida en todos los servicios a través del conjunto completo de 1,023 validadores. A diferencia de las zonas de Cosmos con seguridad independiente o los L2 de Ethereum con diversas suposiciones de confianza, cada servicio JAM hereda garantías de seguridad idénticas desde el primer día. La ejecución paralela en los núcleos permite el escalado computacional sin fragmentar la seguridad; añadir servicios no diluye la seguridad, sino que aumenta el rendimiento total del sistema.

La componibilidad síncrona dentro de límites de ejecución coherentes desbloquea los efectos de red. Los protocolos DeFi pueden componerse atómicamente entre servicios para préstamos flash, arbitraje y liquidaciones. Los mercados de NFT pueden agrupar atómicamente activos de múltiples cadenas. Las aplicaciones de juegos pueden interactuar sincrónicamente con primitivas DeFi para economías dentro del juego. Esta componibilidad, históricamente limitada a cadenas monolíticas, está disponible en un entorno escalado y paralelo.

El posicionamiento a largo plazo de Wood para JAM se extiende más allá de blockchain a la computación general. El lema "computadora global descentralizada" hace eco deliberadamente de las primeras descripciones de Ethereum, pero con fundamentos arquitectónicos que respaldan la metáfora a escala. Donde la "computadora mundial" de Ethereum alcanzó rápidamente los límites de escalabilidad, lo que requirió el pragmatismo de L2, JAM construye la escalabilidad computacional en su base a través del paradigma Refine-Accumulate y el soporte de continuaciones de PVM.

La evolución de Polkadot 1.0 a JAM refleja una filosofía de "menos opinión", pasando de lo específico del dominio a lo de propósito general, de parachains consagradas a servicios arbitrarios, de la complejidad de protocolo actualizable a la simplicidad fija con aplicaciones actualizables. Este minimalismo arquitectónico permite oportunidades de optimización imposibles en sistemas en constante evolución: los parámetros fijos permiten una optimización agresiva de la topología de red, la temporización conocida permite algoritmos de programación precisos, las especificaciones inmutables permiten la aceleración de hardware sin riesgo de obsolescencia.

Cinco factores impulsores motivan el diseño de JAM:

La resiliencia a través de la descentralización requiere más de 1,000 operadores de validadores independientes que mantengan la seguridad en todos los servicios. El diseño de JAM preserva el NPoS pionero de Polkadot con recompensas iguales para los validadores, evitando la concentración de stake mientras mantiene una robusta tolerancia a fallos bizantinos.

La generalidad que permite la computación arbitraria se expande más allá de los casos de uso específicos de blockchain. La PVM acepta cualquier código RISC-V, admitiendo lenguajes desde Rust y C++ hasta implementaciones más exóticas. Los servicios pueden implementar blockchains, plataformas de contratos inteligentes, ZK-rollups, capas de disponibilidad de datos, oráculos, redes de almacenamiento o patrones computacionales completamente novedosos.

El rendimiento que logra una "escalabilidad más o menos indefinida" proviene de la paralelización horizontal: agregar núcleos escala el rendimiento sin límites arquitectónicos. El objetivo de 850 MB/s representa la capacidad de lanzamiento; el escalado elástico y los mercados económicos de tiempo de núcleo permiten aumentar la capacidad a medida que aumenta la demanda sin cambios de protocolo.

La coherencia que proporciona interacción síncrona cuando es necesario resuelve el problema de componibilidad que afecta a los sistemas fragmentados. Los Accords permiten la aplicación de protocolos con mínima confianza entre servicios, transferencias de tokens entre cadenas síncronas y operaciones atómicas multiservicio previamente imposibles en ecosistemas fragmentados.

La accesibilidad que reduce las barreras democratiza la infraestructura. Reemplazar las subastas de parachains de millones de dólares con tiempo de núcleo de pago por uso, el despliegue de servicios sin permisos y la asignación flexible de recursos permite que proyectos de todas las escalas, desde desarrolladores individuales hasta equipos empresariales, accedan a una infraestructura de clase mundial.

Panorama competitivo: JAM frente a enfoques alternativos de Capa 0 y Capa 1​

El posicionamiento de JAM frente a la hoja de ruta de Ethereum revela filosofías de escalado fundamentalmente diferentes. Ethereum persigue una modularidad centrada en L2, donde la L1 proporciona disponibilidad de datos y liquidación, mientras que la ejecución migra a rollups optimistas y ZK como Arbitrum, Optimism, Base y zkSync. Proto-danksharding (EIP-4844) añadió transacciones de blob que proporcionan disponibilidad de datos temporal, con un danksharding completo planeado para aumentar la capacidad 100 veces. La Separación Proponente-Constructor (PBS) y el rediseño de la capa de consenso de Beam Chain anunciado continúan optimizando la L1 para su papel cada vez más reducido.

Esta estrategia crea un particionamiento persistente: los L2 siguen siendo ecosistemas aislados con liquidez fragmentada, suposiciones de confianza variadas, períodos de retiro de 7 días para los rollups optimistas, riesgos de centralización del secuenciador y volatilidad de tarifas durante la congestión de la L1 que se propaga a todos los L2. La componibilidad funciona sin problemas dentro de cada L2, pero las interacciones entre L2 vuelven a la mensajería asíncrona con riesgos de puente. La comunidad de Ethereum adoptó el pragmatismo de L2 después de que la visión original de fragmentación de Ethereum 2.0 resultara demasiado compleja, pero este pragmatismo acepta limitaciones fundamentales como compensaciones inherentes.

JAM persigue lo que Ethereum 2.0 prometió originalmente: ejecución fragmentada nativa con estado coherente integrado en la capa de consenso. Donde Ethereum movió la ejecución fuera de la cadena a los L2, JAM construye la ejecución paralela en el consenso de L1 a través del modelo Refine-Accumulate. Donde Ethereum aceptó ecosistemas L2 fragmentados, JAM proporciona seguridad unificada y componibilidad a nivel de protocolo a través de servicios y Accords. La apuesta arquitectónica difiere fundamentalmente: Ethereum apuesta por la innovación especializada de L2, JAM apuesta por la escalabilidad generalizada de L1.

Los objetivos de rendimiento ilustran la ambición: Ethereum procesa aproximadamente 15 transacciones por segundo en L1 con 1.3 MB por bloque de disponibilidad de datos, mientras que los L2 manejan colectivamente miles de TPS con suposiciones de seguridad variadas. JAM apunta a 850 MB/s de disponibilidad de datos (aproximadamente 650 veces Ethereum L1) y más de 3.4 millones de TPS de capacidad teórica con seguridad unificada. El modelo computacional también diverge: la ejecución secuencial EVM de Ethereum frente al procesamiento paralelo de 350 núcleos de JAM representa enfoques fundamentalmente diferentes para el problema de la escalabilidad.

Cosmos con el protocolo Inter-Blockchain Communication (IBC) representa una visión alternativa de Capa 0 que prioriza la soberanía sobre la seguridad compartida. Las zonas de Cosmos son blockchains soberanas independientes con sus propios conjuntos de validadores, gobernanza y modelos de seguridad. IBC permite la comunicación sin confianza a través de la verificación de clientes ligeros: las cadenas verifican de forma independiente el estado de la contraparte sin depender de validadores compartidos o pools de seguridad.

Esta filosofía de "la soberanía primero" otorga a cada zona autonomía completa: mecanismos de consenso personalizados, modelos económicos especializados y decisiones de gobernanza independientes sin sobrecarga de coordinación. Sin embargo, la soberanía conlleva costos: las nuevas zonas deben arrancar conjuntos de validadores y seguridad de forma independiente, enfrentan seguridad fragmentada (un ataque a una zona no compromete a otras, pero también significa niveles de seguridad variados entre zonas) y experimentan una comunicación verdaderamente asíncrona sin opciones de componibilidad síncrona.

JAM adopta el enfoque opuesto: la seguridad primero con validación compartida. Los 1,023 validadores aseguran cada servicio desde el lanzamiento, eliminando los desafíos de arranque y proporcionando garantías de seguridad uniformes. Los servicios sacrifican la soberanía (operan dentro del modelo de ejecución de JAM y dependen de un conjunto de validadores compartido), pero obtienen seguridad inmediata, componibilidad a nivel de protocolo y menor sobrecarga operativa. La diferencia filosófica es profunda: Cosmos optimiza la independencia soberana, JAM optimiza la integración coherente.

Las subredes de Avalanche proporcionan otra arquitectura comparativa donde las subredes son blockchains soberanas de Capa 1 que los validadores eligen validar. Los validadores de la red principal (que requieren 2,000 AVAX en stake) pueden validar adicionalmente cualquier subred que elijan, lo que permite conjuntos de validadores personalizados por subred. Este modelo de seguridad horizontal (más subredes = más conjuntos de validadores) contrasta con el modelo de seguridad vertical de JAM (todos los servicios comparten el conjunto completo de validadores).

La arquitectura de subredes permite la optimización específica de la aplicación: las subredes de juegos pueden tener un alto rendimiento y baja finalidad, las subredes de DeFi pueden priorizar la seguridad y la descentralización, las subredes empresariales pueden implementar validadores con permisos. El consenso Snowman de Avalanche proporciona una finalidad de menos de un segundo dentro de las subredes. Sin embargo, las subredes permanecen en gran medida aisladas: Avalanche Warp Messaging (AWM) proporciona comunicación básica entre subredes, pero sin la componibilidad a nivel de protocolo o la ejecución síncrona que permiten los Accords de JAM.

El posicionamiento de rendimiento muestra a Avalanche enfatizando la finalidad de menos de un segundo (aproximadamente 1 segundo frente a los 18 segundos de JAM), pero con una seguridad más fragmentada entre subredes en lugar de los 1,023 validadores unificados por servicio de JAM. La arquitectura de estado también difiere fundamentalmente: las subredes de Avalanche mantienen máquinas de estado completamente aisladas, mientras que los servicios JAM comparten una capa de acumulación que permite lecturas entre servicios e interacciones síncronas cuando se programan en el mismo núcleo.

Los protocolos de interoperabilidad externos como LayerZero, Wormhole, Chainlink CCIP y Axelar sirven para propósitos diferentes al XCMP nativo de JAM. Estos protocolos conectan ecosistemas blockchain completamente dispares (Ethereum a Solana a Bitcoin a Cosmos) confiando en validadores externos, oráculos o redes de retransmisión para la seguridad. LayerZero utiliza un modelo de Oráculo + Retransmisor que asegura más de $6 mil millones en valor total bloqueado en más de 50 cadenas. Wormhole emplea 19 Guardianes que validan más de mil millones de mensajes con una valoración totalmente diluida de $10.7 mil millones.

El XCMP de JAM opera en una capa diferente: comunicación intra-ecosistema con validadores de protocolo nativos en lugar de suposiciones de seguridad externas. Los servicios en JAM no necesitan puentes externos para interactuar; comparten el mismo conjunto de validadores, mecanismo de consenso y garantías de seguridad. Esto permite interacciones sin confianza imposibles con puentes externos: llamadas síncronas, operaciones atómicas multiservicio, entrega garantizada de mensajes y finalidad a nivel de protocolo.

El posicionamiento estratégico sugiere coexistencia en lugar de competencia: JAM utiliza XCMP para la comunicación interna mientras que potencialmente integra LayerZero, Wormhole o protocolos similares para la conectividad de cadenas externas. Los servicios JAM podrían envolver protocolos externos para conectar con Ethereum, Solana, Bitcoin o Cosmos, proporcionando lo mejor de ambos mundos en conectividad: operaciones internas sin confianza con puentes externos pragmáticos.

Fundamentos de investigación: rigor académico y contribuciones novedosas a la informática​

El JAM Gray Paper establece la base académica del protocolo, emulando el Yellow Paper de Ethereum al proporcionar especificaciones matemáticas formales que permiten múltiples implementaciones independientes. Lanzado en abril de 2024 con la versión 0.1, el documento ha progresado a través de un refinamiento continuo (la v0.7.0 en junio de 2025 añadió pseudocódigo PVM detallado, la v0.7.1 en julio incorporó los comentarios de la comunidad), acercándose a la v1.0 esperada para principios de 2026. Este desarrollo iterativo de especificaciones con el escrutinio de la comunidad es paralelo a la revisión académica por pares, mejorando la claridad y detectando ambigüedades.

El resumen del Gray Paper cristaliza la contribución teórica de JAM: "Presentamos una definición completa y formal de Jam, un protocolo que combina elementos tanto de Polkadot como de Ethereum. En un único modelo coherente, Jam proporciona un entorno de objetos singleton global sin permisos —muy parecido al entorno de contratos inteligentes pionero de Ethereum—, emparejado con una computación segura de banda lateral paralela sobre una red de nodos escalable, una propuesta pionera de Polkadot." Esta síntesis de propiedades aparentemente incompatibles —la componibilidad sin permisos de Ethereum con la seguridad compartida paralela de Polkadot— representa el desafío teórico central que aborda JAM.

La selección de RISC-V para los fundamentos de PVM refleja un riguroso análisis de la arquitectura de computadoras. RISC-V surgió de la investigación de la UC Berkeley como una arquitectura de conjunto de instrucciones de código abierto que prioriza la simplicidad y la extensibilidad. Con solo 47 instrucciones base en comparación con cientos en x86 o ARM, RISC-V minimiza la complejidad de la implementación mientras mantiene la completitud computacional. La arquitectura basada en registros evita el problema NP-completo de asignación de registros inherente a las máquinas virtuales basadas en pila como WebAssembly, lo que permite una compilación más rápida y un rendimiento más predecible.

La PVM de JAM realiza modificaciones mínimas al RISC-V estándar, principalmente añadiendo gestión de memoria determinista y medición de gas, al tiempo que preserva la compatibilidad con las cadenas de herramientas RISC-V existentes. Este conservadurismo de diseño permite aprovechar décadas de investigación en arquitectura de computadoras y compiladores de grado de producción (LLVM) en lugar de construir una infraestructura de compiladores personalizada. Los lenguajes que compilan a RISC-V —Rust, C, C++, Go y muchos otros— se vuelven automáticamente compatibles con JAM sin modificaciones de compilador específicas de blockchain.

El soporte de continuaciones en PVM representa una contribución teórica significativa. Las continuaciones —la capacidad de pausar la ejecución, serializar el estado y reanudar más tarde— permiten la computación asíncrona de múltiples bloques sin una compleja gestión manual del estado. Las VM de blockchain tradicionales carecen de soporte de continuaciones, lo que obliga a los desarrolladores a dividir manualmente las computaciones, persistir el estado intermedio y reconstruir el contexto a través de las transacciones. El diseño de pila en memoria de PVM y la ejecución determinista permiten un soporte de continuaciones de primera clase, simplificando drásticamente las computaciones de larga duración o entre bloques.

El dualismo Refine-Accumulate se mapea conceptualmente al modelo de programación MapReduce, pionero de Google para la computación distribuida. Refine opera como la fase Map: una transformación vergonzosamente paralela y sin estado de entradas a salidas a través de trabajadores distribuidos (núcleos de validadores). Accumulate opera como la fase Reduce: integración secuencial de resultados transformados en un estado unificado. Este patrón de la informática, probado eficaz a escala masiva en sistemas distribuidos tradicionales, se adapta elegantemente al entorno de mínima confianza de blockchain con verificación criptográfica que reemplaza la coordinación centralizada.

El mecanismo de consenso SAFROLE se basa en décadas de investigación en sistemas distribuidos. El algoritmo evoluciona de SASSAFRAS (Semi-Anonymous Sortition of Staked Assignees for Fixed-time Rhythmic Assignment of Slots), simplificándolo para los requisitos específicos de JAM mientras preserva propiedades clave: producción de bloques sin bifurcaciones a través de la selección anónima de validadores, resistencia a ataques DoS dirigidos mediante anonimato basado en zkSNARKs hasta la producción de bloques, y temporización determinista que permite una programación precisa de recursos.

Los fundamentos criptográficos combinan las Funciones Aleatorias Verificables en Anillo (RingVRF) para probar la membresía del conjunto de validadores de forma anónima con zkSNARKs para una verificación eficiente. El sistema de tickets con dos épocas de antelación —los validadores envían tickets dos épocas antes de la producción de bloques— previene varios ataques mientras mantiene las garantías de anonimato. Esto representa una aplicación elegante de primitivas criptográficas modernas para resolver desafíos prácticos de consenso.

Los Validadores Económicos (ELV) como alternativa a la verificación de pruebas ZK proporcionan un novedoso análisis de equilibrio entre seguridad y costo. La documentación de JAM afirma que los ELV son aproximadamente 4,000 veces más rentables que las pruebas de conocimiento cero para garantizar la corrección computacional. El modelo se basa en la seguridad criptoeconómica: validadores seleccionados aleatoriamente reejecutan el trabajo para verificar la corrección, y los resultados incorrectos desencadenan disputas y posibles recortes (slashing). Este enfoque "optimista", donde se asume la corrección a menos que se impugne, refleja los rollups optimistas, pero opera a nivel de protocolo con finalidad inmediata después de las auditorías de los validadores.

El futuro potencialmente combina ELV y pruebas ZK en un modelo de seguridad híbrido: ELV para seguridad limitada donde las garantías criptoeconómicas son suficientes, pruebas ZK para seguridad ilimitada donde se requiere certeza matemática. Esta flexibilidad permite a las aplicaciones elegir modelos de seguridad que coincidan con sus requisitos y restricciones económicas en lugar de forzar un enfoque único para todos.

Las contribuciones teóricas novedosas de JAM incluyen:

El paradigma de blockchain sin transacciones desafía una suposición fundamental de la arquitectura blockchain. Bitcoin, Ethereum y casi todos los sucesores se organizan en torno a transacciones —acciones de usuario firmadas en un mempool que compiten por la inclusión en el bloque. JAM elimina por completo las transacciones: todos los cambios de estado fluyen a través de paquetes de trabajo que contienen elementos de trabajo que pasan por las etapas Refine y Accumulate. Este modelo fundamentalmente diferente plantea interesantes preguntas de investigación sobre MEV (Valor Máximo Extraíble), resistencia a la censura y experiencia del usuario que la investigación académica aún no ha explorado completamente.

El consenso parcialmente coherente representa una posición novedosa entre los sistemas totalmente coherentes (cadenas monolíticas) y totalmente incoherentes (fragmentos aislados). JAM garantiza la coherencia durante ventanas críticas de 6 segundos cuando los servicios se ubican en los mismos núcleos, mientras acepta la asincronía entre núcleos. Los mecanismos económicos que impulsan los patrones de coherencia —los secuenciadores que optimizan la composición de los paquetes de trabajo para maximizar el rendimiento y minimizar la latencia— crean un interesante problema de teoría de juegos. ¿Cómo organizan los actores económicos racionales los servicios entre los núcleos? ¿Qué equilibrios emergen? Estas preguntas esperan validación empírica.

Los Accords como contratos inteligentes de múltiples instancias que gobiernan los protocolos de interacción entre servicios, por lo demás independientes, introducen una primitiva novedosa de minimización de confianza. En lugar de confiar en puentes o retransmisores para la comunicación entre servicios, los Accords imponen protocolos a nivel de consenso de JAM mientras distribuyen la ejecución a través de los límites del servicio. Esta abstracción permite patrones de minimización de confianza como la teletransportación directa de tokens, operaciones atómicas multiservicio y llamadas síncronas entre servicios, capacidades teóricas que requieren validación empírica para sus propiedades de seguridad y viabilidad económica.

La optimización del consumo de recursos mixto crea un interesante problema de programación y economía. Los servicios tienen diversos perfiles de recursos: algunos están limitados por la computación (verificación de pruebas ZK), otros por los datos (servicios de disponibilidad), y otros están equilibrados. La utilización óptima de los recursos del validador requiere emparejar servicios complementarios en paquetes de trabajo. ¿Qué mecanismos surgen para coordinar este emparejamiento? ¿Cómo se desarrollan los mercados para la agrupación de servicios complementarios? Esto representa un territorio inexplorado en la investigación de la economía de blockchain.

El procesamiento en tubería (pipelining) a través de raíces de estado previas en lugar de raíces de estado posteriores permite el procesamiento de bloques superpuestos, pero introduce complejidad en el manejo de disputas. Si la carga de trabajo pesada de Accumulate para el bloque N ocurre después de que el bloque N+1 comienza a procesarse, ¿cómo manejan los validadores las discrepancias? El mecanismo de juicio que permite pausas de finalidad de hasta 1 hora para la resolución de disputas proporciona respuestas, pero las implicaciones de seguridad de esta elección de diseño justifican un análisis formal.

Se están llevando a cabo esfuerzos de verificación formal con Runtime Verification desarrollando la semántica del K Framework para PVM. El K Framework proporciona rigor matemático para definir la semántica de los lenguajes de programación y las máquinas virtuales, lo que permite pruebas formales de las propiedades de corrección. Los entregables incluyen especificaciones de referencia, depuradores y herramientas de prueba de propiedades. Este nivel de rigor matemático, aunque común en el software aeroespacial y militar, sigue siendo relativamente raro en el desarrollo de blockchain, lo que representa una maduración del campo hacia los métodos formales.

Síntesis: el lugar de JAM en la evolución de blockchain e implicaciones para web3​

JAM representa la culminación de más de una década de investigación sobre la escalabilidad de blockchain, intentando construir lo que las generaciones anteriores prometieron pero no pudieron cumplir. Bitcoin introdujo el consenso descentralizado pero no pudo escalar más allá de 7 TPS. Ethereum añadió programabilidad pero alcanzó límites de rendimiento similares. La visión original de Ethereum 2.0 propuso una fragmentación nativa con 64 cadenas de fragmentos, pero resultó demasiado compleja, virando hacia el pragmatismo centrado en L2. Polkadot fue pionero en la seguridad compartida para parachains, pero con límites fijos de 50 cadenas y acceso basado en subastas.

JAM sintetiza las lecciones de estos intentos: mantener la descentralización y la seguridad (lección de Bitcoin), permitir la computación arbitraria (lección de Ethereum), escalar a través de la paralelización (intento de Ethereum 2.0), proporcionar seguridad compartida (innovación de Polkadot), añadir componibilidad síncrona (la pieza que faltaba) y reducir las barreras de entrada (accesibilidad).

La compensación entre la elegancia teórica y la complejidad práctica sigue siendo el riesgo central de JAM. El diseño del protocolo es intelectualmente coherente: el dualismo Refine-Accumulate, las continuaciones de PVM, el consenso SAFROLE, la ejecución parcialmente coherente, todo encaja lógicamente. Pero la solidez teórica no garantiza el éxito práctico. El giro de Ethereum de la fragmentación nativa a los L2 no se debió a una imposibilidad teórica, sino a la complejidad práctica en la implementación, las pruebas y la coordinación.

La estrategia de actualización única y completa de JAM amplifica tanto las ventajas como las desventajas. El éxito ofrece todas las mejoras simultáneamente —42 veces la disponibilidad de datos, servicios sin permisos, componibilidad síncrona, rendimiento RISC-V— en un único despliegue coordinado. El fracaso o los retrasos afectan a toda la actualización en lugar de enviar mejoras incrementales. Los 43 equipos de implementación independientes, las extensas fases de testnet y las pruebas a gran escala de JAM Toaster tienen como objetivo mitigar los riesgos, pero coordinar a 1,023 validadores a través de una transición arquitectónica importante sigue siendo algo sin precedentes en la historia de blockchain.

La transición del modelo económico de las subastas de parachains a los mercados de tiempo de núcleo representa un mecanismo en gran medida no probado a escala. Si bien el Agile Coretime de Polkadot entró en funcionamiento en 2024, el modelo basado en servicios de JAM con despliegue sin permisos crea dinámicas económicas completamente nuevas. ¿Cómo fijarán los mercados de tiempo de núcleo el precio de los diferentes tipos de servicios? ¿Se concentrará la liquidez en núcleos específicos? ¿Cómo optimizarán los secuenciadores la composición de los paquetes de trabajo? Estas preguntas carecen de respuestas empíricas hasta el despliegue en la red principal.

La adopción por parte de los desarrolladores depende de si el novedoso modelo de programación de JAM —puntos de entrada Refine/Accumulate/onTransfer, ejecución sin estado y luego con estado, asincronía basada en continuaciones— proporciona suficiente valor para justificar la curva de aprendizaje. El éxito de Ethereum se debió en parte a la familiaridad de la EVM para los desarrolladores a pesar de sus ineficiencias. La PVM de JAM ofrece un rendimiento superior pero requiere repensar la arquitectura de las aplicaciones en torno a los paquetes de trabajo y los servicios. El despliegue sin permisos y la eliminación de las subastas reducen drásticamente las barreras financieras, pero los cambios de modelo mental pueden resultar más desafiantes que los financieros.

La dinámica competitiva evoluciona a medida que JAM se despliega. Los L2 de Ethereum tienen importantes efectos de red, liquidez y cuota de mercado de desarrolladores. Solana ofrece un rendimiento excepcional con modelos de programación más simples. Cosmos proporciona una soberanía que algunos proyectos valoran mucho. JAM no solo debe ofrecer capacidades técnicas, sino también atraer a los participantes del ecosistema —desarrolladores, usuarios, capital— que hacen que las redes blockchain sean valiosas. El ecosistema existente de Polkadot proporciona una base, pero expandirse más allá de los participantes actuales requiere propuestas de valor convincentes para la migración.

Las contribuciones de investigación que introduce JAM aportan valor independientemente del éxito comercial. La arquitectura blockchain sin transacciones, el consenso parcialmente coherente, los Accords para protocolos entre servicios con mínima confianza, la optimización del consumo de recursos mixto y el modelo de ejecución basado en continuaciones de PVM representan enfoques novedosos que avanzan la informática de blockchain. Incluso si JAM no logra una posición dominante en el mercado, estas innovaciones informarán futuros diseños de protocolos y expandirán el espacio de soluciones para la escalabilidad de blockchain.

Las implicaciones a largo plazo para web3 si JAM tiene éxito incluyen cambios fundamentales en la forma en que se arquitecturan las aplicaciones descentralizadas. El paradigma actual de "desplegar en una blockchain" (Ethereum L1, Solana, Avalanche) o "construir tu propia blockchain" (Cosmos, parachains de Polkadot) añade una opción intermedia: "desplegar como un servicio" con seguridad compartida instantánea, asignación flexible de recursos y componibilidad con el ecosistema más amplio. Esto podría acelerar la innovación al eliminar las preocupaciones de infraestructura: los equipos se centran en la lógica de la aplicación mientras JAM se encarga del consenso, la seguridad y la escalabilidad.

La visión de una computadora global descentralizada se vuelve arquitectónicamente factible si JAM cumple con los objetivos de rendimiento. Con 850 MB/s de disponibilidad de datos, 150 mil millones de gas por segundo y una capacidad de más de 3.4 millones de TPS, el rendimiento computacional se acerca a niveles en los que aplicaciones tradicionales significativas podrían migrar a la infraestructura descentralizada. No para todos los casos de uso —las aplicaciones sensibles a la latencia aún enfrentan limitaciones fundamentales de la velocidad de la luz, los requisitos de privacidad pueden entrar en conflicto con la ejecución transparente—, pero para problemas de coordinación, infraestructura financiera, seguimiento de la cadena de suministro, identidad digital y muchas otras aplicaciones, la computación descentralizada se vuelve técnicamente viable a escala.

Las métricas de éxito de JAM durante los próximos 2 a 5 años incluirán: el número de servicios desplegados más allá de las parachains heredadas (midiendo la expansión del ecosistema), el rendimiento real y la disponibilidad de datos logrados en producción (validando las afirmaciones de rendimiento), la sostenibilidad económica de los mercados de tiempo de núcleo (demostrando que el modelo económico funciona), las métricas de adopción por parte de los desarrolladores (actividad en GitHub, tráfico de documentación, participación en programas educativos) y el historial de seguridad (ausencia de exploits importantes o fallos de consenso).

La pregunta final sigue siendo si JAM representa una mejora incremental en el espacio de diseño de blockchain —mejor que las alternativas pero no fundamentalmente diferente en capacidad— o un salto generacional que permite categorías de aplicaciones completamente nuevas imposibles en la infraestructura actual. Los fundamentos arquitectónicos —ejecución parcialmente coherente, continuaciones de PVM, dualismo Refine-Accumulate, Accords— sugieren que esto último es posible. Si el potencial se traduce en realidad depende de la calidad de la ejecución, la construcción del ecosistema y los factores de tiempo de mercado que trascienden el mérito puramente técnico.

Para los investigadores de web3, JAM proporciona una rica plataforma experimental para estudiar nuevos mecanismos de consenso, arquitecturas de ejecución, mecanismos de coordinación económica y modelos de seguridad. Los próximos años generarán datos empíricos que probarán las predicciones teóricas sobre el consenso parcialmente coherente, la arquitectura sin transacciones y la organización de blockchain basada en servicios. Independientemente de los resultados comerciales, el conocimiento adquirido informará el diseño de protocolos blockchain durante las próximas décadas.