Saltar al contenido principal

JAM de Polkadot: Redefiniendo la arquitectura blockchain con RISC-V

· 12 min de lectura
Dora Noda
Software Engineer

En abril de 2025, Vitalik Buterin propuso algo que habría parecido una herejía un año antes: reemplazar la EVM de Ethereum con RISC-V. La sugerencia generó un debate inmediato. Pero lo que la mayoría de los comentaristas pasaron por alto fue que Polkadot ya había estado construyendo exactamente esta arquitectura durante más de un año — y estaba a meses de desplegarla en producción.

JAM (Join-Accumulate Machine) de Polkadot no es solo otra actualización de blockchain. Representa un replanteamiento fundamental de lo que significa incluso una "blockchain". Mientras que la visión del mundo de Ethereum se centra en una máquina virtual global que procesa transacciones, JAM elimina el concepto de transacción por completo en su capa central, reemplazándolo con un modelo de computación que promete una disponibilidad de datos de 850 MB / s — 42 veces la capacidad anterior de Polkadot y 650 veces los 1.3 MB / s de Ethereum.

Las implicaciones se extienden mucho más allá de los puntos de referencia de rendimiento. JAM puede ser la articulación más clara hasta ahora de un paradigma post-Ethereum para la arquitectura blockchain.

El Gray Paper: El tercer acto de Gavin Wood

El Dr. Gavin Wood escribió el Yellow Paper de Ethereum en 2014, proporcionando la especificación formal que hizo posible Ethereum. Continuó con el White Paper de Polkadot en 2016, introduciendo el sharding heterogéneo y la seguridad compartida. En abril de 2024, lanzó el Gray Paper de JAM en Token2049 en Dubái — completando una trilogía que abarca toda la historia de las blockchains programables.

El Gray Paper describe a JAM como "un entorno de objetos sin permisos y singleton global — similar al entorno de contratos inteligentes de Ethereum — emparejado con una computación de banda lateral segura paralelizada sobre una red de nodos escalable". Pero esto subestima el cambio conceptual.

JAM no solo mejora los diseños de blockchain existentes. Se pregunta: ¿qué pasaría si dejáramos de pensar en las blockchains como máquinas virtuales por completo?

El problema de las transacciones

Las blockchains tradicionales — incluida Ethereum — son fundamentalmente sistemas de procesamiento de transacciones. Los usuarios envían transacciones, los validadores las ordenan y ejecutan, y la blockchain registra los cambios de estado. Este modelo ha servido bien pero conlleva limitaciones inherentes:

  • Cuellos de botella secuenciales: Las transacciones deben ordenarse, lo que crea restricciones de rendimiento.
  • Contienda del estado global: Cada transacción toca potencialmente el estado compartido.
  • Acoplamiento de ejecución: El consenso y la computación están estrechamente vinculados.

JAM desacopla estas preocupaciones a través de lo que Wood llama el paradigma "Refine-Accumulate" (Refinar-Acumular). El sistema opera en dos fases:

Refine (Refinar): La computación ocurre en paralelo en toda la red. El trabajo se divide en unidades independientes que pueden ejecutarse simultáneamente sin coordinación.

Accumulate (Acumular): Los resultados se recopilan y se fusionan en el estado global. Solo esta fase requiere consenso sobre el ordenamiento.

El resultado es un protocolo central "sin transacciones". JAM en sí mismo no procesa transacciones — las aplicaciones construidas sobre JAM sí lo hacen. Esta separación permite que la capa base se centre puramente en la computación paralela y segura.

PolkaVM: Por qué es importante RISC-V

En el corazón de JAM se encuentra PolkaVM, una máquina virtual diseñada específicamente basada en el conjunto de instrucciones RISC-V. Esta elección tiene profundas implicaciones para la computación en blockchain.

La deuda arquitectónica de la EVM

La EVM de Ethereum fue diseñada en 2013-2014, antes de que se comprendieran muchos de los supuestos modernos sobre la ejecución de blockchain. Su arquitectura refleja esa época:

  • Ejecución basada en pila: Las operaciones introducen y extraen valores de una pila ilimitada, lo que requiere un seguimiento complejo.
  • Tamaño de palabra de 256 bits: Elegido por conveniencia criptográfica pero ineficiente para la mayoría de las operaciones.
  • Gas unidimensional: Una sola métrica intenta valorar recursos computacionales enormemente diferentes.
  • Solo interpretación: El bytecode de la EVM no se puede compilar a código nativo de manera eficiente.

Estas decisiones de diseño tenían sentido como opciones iniciales, pero crean penalizaciones de rendimiento continuas.

Las ventajas de RISC-V

PolkaVM adopta un enfoque fundamentalmente diferente:

Arquitectura basada en registros: Al igual que las CPU modernas, PolkaVM utiliza un conjunto finito de registros para el paso de argumentos. Esto se alinea con el hardware real, lo que permite una traducción eficiente a conjuntos de instrucciones nativos.

Tamaño de palabra de 64 bits: Los procesadores modernos son de 64 bits. El uso de un tamaño de palabra coincidente elimina la sobrecarga de emular operaciones de 256 bits para la gran mayoría de los cálculos.

Gas multidimensional: Los diferentes recursos (computación, almacenamiento, ancho de banda) se valoran de forma independiente, lo que refleja mejor los costes reales y evita los ataques de precios erróneos.

Modos de ejecución dual: El código puede interpretarse para una ejecución inmediata o compilarse mediante JIT para un rendimiento optimizado. El sistema elige el modo adecuado en función de las características de la carga de trabajo.

Impacto en el rendimiento

Las diferencias arquitectónicas se traducen en ganancias de rendimiento reales. Los puntos de referencia muestran que PolkaVM logra mejoras de más de 10 veces sobre WebAssembly para contratos con uso intensivo de aritmética — y la EVM es aún más lenta. Para interacciones complejas de múltiples contratos, la brecha se amplía aún más a medida que la compilación JIT amortiza los costes de configuración.

Quizás lo más importante es que PolkaVM admite cualquier lenguaje que se compile a RISC-V. Mientras que los desarrolladores de EVM están limitados a Solidity, Vyper y un puñado de lenguajes especializados, PolkaVM abre la puerta a Rust, C++ y, eventualmente, cualquier lenguaje compatible con LLVM. Esto amplía drásticamente el grupo de desarrolladores potenciales.

Manteniendo la experiencia del desarrollador

A pesar de la revisión arquitectónica, PolkaVM mantiene la compatibilidad con los flujos de trabajo existentes. El compilador Revive proporciona soporte completo para Solidity, incluyendo el ensamblador en línea (inline assembler). Los desarrolladores pueden seguir utilizando Hardhat, Remix y MetaMask sin cambiar sus procesos.

El equipo de Papermoon demostró esta compatibilidad al migrar con éxito el código del contrato de Uniswap V2 a la testnet de PolkaVM—demostrando que incluso el código DeFi complejo y probado en batalla puede transicionar sin necesidad de reescrituras.

Objetivos de rendimiento de JAM

Las cifras que Wood proyecta para JAM son asombrosas según los estándares actuales de blockchain.

Disponibilidad de datos

JAM apunta a 850 MB / s de disponibilidad de datos—aproximadamente 42 veces la capacidad estándar de Polkadot antes de las optimizaciones recientes y 650 veces los 1.3 MB / s de Ethereum. Para contextualizar, esto se acerca al rendimiento de los sistemas de bases de datos empresariales.

Rendimiento computacional

El Gray Paper estima que JAM puede alcanzar aproximadamente 150 mil millones de gas por segundo a plena capacidad. Traducir el gas a transacciones es impreciso, pero el rendimiento máximo teórico alcanza más de 3.4 millones de TPS basado en el objetivo de disponibilidad de datos.

Validación en el mundo real

Estas no son cifras puramente teóricas. Las pruebas de estrés han validado la arquitectura:

  • Kusama (agosto de 2025): Alcanzó 143,000 TPS con solo el 23 % de la capacidad de carga
  • Polkadot "Spammening" (2024): Alcanzó 623,000 TPS en pruebas controladas

Estas cifras representan un rendimiento de transacciones real, no proyecciones optimistas o condiciones de testnet que no reflejan los entornos de producción.

Estado del desarrollo y cronograma

El desarrollo de JAM sigue un sistema de hitos estructurado, con 43 equipos de implementación compitiendo por un fondo de premios que supera los $ 60 millones (10 millones de DOT + 100,000 KSM).

Progreso actual (finales de 2025)

El ecosistema ha alcanzado varios hitos críticos:

  • Múltiples equipos han logrado el 100 % de conformidad con los vectores de prueba de la Web3 Foundation
  • El desarrollo ha progresado a través de las versiones del Gray Paper 0.6.2 a la 0.8.0, acercándose a la v1.0
  • La conferencia JAM Experience en Lisboa (mayo de 2025) reunió a los equipos de implementación para una colaboración técnica profunda
  • Las giras universitarias llegaron a más de 1,300 asistentes en nueve ubicaciones globales, incluyendo Cambridge, la Universidad de Pekín y la Universidad de Fudan

Estructura de hitos

Los equipos progresan a través de una serie de hitos:

  1. IMPORTER (M1): Superar las pruebas de conformidad de transición de estado e importar bloques
  2. AUTHORER (M2): Conformidad total, incluyendo producción de bloques, networking y componentes off-chain
  3. HALF-SPEED (M3): Alcanzar el rendimiento de nivel Kusama, con acceso al JAM Toaster para pruebas a gran escala
  4. FULL-SPEED (M4): Rendimiento a nivel de la mainnet de Polkadot con auditorías de seguridad profesionales

Múltiples equipos han completado el M1, y varios están progresando hacia el M2.

Cronograma hacia la mainnet

  • Finales de 2025: Revisiones finales del Gray Paper, presentaciones continuas de hitos, participación ampliada en la testnet
  • Q1 2026: Actualización de la mainnet JAM en Polkadot tras la aprobación de la gobernanza mediante referéndum en OpenGov
  • 2026: Despliegue de la Fase 1 de CoreChain, testnet pública oficial de JAM, transición completa de la red

El proceso de gobernanza ya ha mostrado un fuerte apoyo de la comunidad. Un voto casi unánime de los holders de DOT aprobó la dirección de la actualización en mayo de 2024.

JAM vs. Ethereum: ¿Complementarios o competitivos?

La pregunta de si JAM representa un "asesino de Ethereum" (Ethereum killer) ignora los matices arquitectónicos.

Diferentes filosofías de diseño

Ethereum se construye hacia afuera desde una base monolítica. La EVM proporciona un entorno de ejecución global, y las soluciones de escalado—L2s, rollups, sharding—se añaden por capas encima. Este enfoque ha creado un ecosistema enorme pero también ha acumulado deuda técnica.

JAM comienza con la modularidad en su núcleo. La separación de las fases de Refine y Accumulate, la optimización específica del dominio para el manejo de rollups y la capa base sin transacciones (transactionless) reflejan un diseño desde cero para la escalabilidad.

Elecciones técnicas convergentes

A pesar de los diferentes puntos de partida, los proyectos están convergiendo en conclusiones similares. La propuesta RISC-V de Vitalik en abril de 2025 reconoció que la arquitectura de la EVM limita el rendimiento a largo plazo. Polkadot ya había desplegado el soporte para RISC-V en testnet meses antes.

Esta convergencia valida el juicio técnico de ambos proyectos al tiempo que resalta la brecha de ejecución: Polkadot está entregando lo que Ethereum está proponiendo.

Realidades del ecosistema

La superioridad técnica no se traduce automáticamente en dominio del ecosistema. La comunidad de desarrolladores de Ethereum, la diversidad de aplicaciones y la profundidad de la liquidez representan efectos de red sustanciales que no se pueden replicar de la noche a la mañana.

El resultado más probable no es el reemplazo, sino la especialización. La arquitectura de JAM está optimizada para ciertas cargas de trabajo—particularmente aplicaciones de alto rendimiento e infraestructura de rollups—mientras que Ethereum conserva ventajas en madurez del ecosistema y formación de capital.

En 2026, se ven menos como competidores y más como capas complementarias de un internet multi-cadena.

Lo que JAM significa para la arquitectura blockchain

La importancia de JAM se extiende más allá de Polkadot. Representa la articulación más clara de un paradigma post-EVM que otros proyectos estudiarán y adoptarán selectivamente.

Principios Clave

Separación de cómputo: Desacoplar la ejecución del consenso permite el procesamiento en paralelo en la capa base, no como una idea de último momento.

Optimización específica del dominio: En lugar de construir una VM de propósito general y esperar que escale, JAM está diseñado específicamente para las cargas de trabajo que las blockchains realmente ejecutan.

Alineación con el hardware: El uso de RISC - V y palabras de 64 bits alinea la arquitectura de la máquina virtual con el hardware físico, eliminando la sobrecarga de emulación.

Abstracción de transacciones: Mover el manejo de transacciones a la capa de aplicación permite que el protocolo se concentre en el cómputo y la gestión del estado.

Impacto en la Industria

Ya sea que JAM tenga éxito o fracase comercialmente, estas elecciones arquitectónicas influirán en el diseño de blockchain durante la próxima década. El Gray Paper proporciona una especificación formal que otros proyectos pueden estudiar, criticar e implementar de manera selectiva.

La propuesta RISC - V de Ethereum ya demuestra esta influencia. La pregunta no es si estas ideas se difundirán, sino qué tan rápido y en qué forma.

El camino por delante

JAM representa la visión técnica más ambiciosa de Gavin Wood desde el propio Polkadot. Lo que está en juego coincide con la ambición: el éxito validaría un enfoque completamente diferente de la arquitectura blockchain, mientras que el fracaso dejaría a Polkadot compitiendo con nuevas L1 sin una narrativa técnica diferenciada.

Los próximos 18 meses determinarán si las ventajas teóricas de JAM se traducen en una realidad de producción. Con 43 equipos de implementación, un fondo de premios de nueve cifras y una hoja de ruta clara hacia la mainnet, el proyecto cuenta con recursos e impulso. Lo que queda por ver es si la complejidad del paradigma Refine - Accumulate puede cumplir con la visión de Wood de una "computadora distribuida que puede ejecutar casi cualquier tipo de tarea".

Para los desarrolladores y proyectos que evalúan la infraestructura blockchain, JAM merece una atención seria — no como hype, sino como un intento técnicamente riguroso de resolver problemas que enfrentan todas las principales blockchains. El paradigma de blockchain como máquina virtual sirvió bien a la industria durante una década. JAM apuesta a que la próxima década requiere algo fundamentalmente diferente.


¿Construyendo sobre infraestructura blockchain de próxima generación? BlockEden.xyz proporciona endpoints RPC de alto rendimiento en todo el ecosistema de Polkadot y más de 30 redes adicionales. Explore nuestro mercado de APIs para acceder a infraestructura de nivel empresarial para sus aplicaciones.