La siguiente es una explicación detallada de Polkadot1, Polkadot2, y cómo evolucionaron hacia JAM. (Para más detalles, ver:https://www.navalmanack.com/almanack-of-naval-ravikant/how-to-think-clearly). Este artículo está dirigido a lectores técnicos, especialmente aquellos que quizás no estén profundamente familiarizados con Polkadot pero tengan cierto conocimiento de sistemas blockchain y probablemente estén familiarizados con tecnologías de otros ecosistemas.
Creo que este artículo sirve como un buen precursor para leer el JAM Gray Paper. (Para más detalles, ver:https://graypaper.com/)

Antecedentes

Este artículo asume que el lector está familiarizado con los siguientes conceptos:

• Describir blockchain como una función de transición de estado.
• Comprender lo que significa "estado". (Para más detalles, ver: https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/blockchain_state_machines/index.html)
• Seguridad económica y prueba de participación. (Para más detalles, ver:https://polkadot-blockchain-academy.github.io/pba-book/economics/economics-of-polkadot/page.html#staking-concept,https://www.youtube.com/watch?v=suyram9vaFc)

Introducción: Polkadot1

Primero revisemos las características más innovadoras de Polkadot1.

Aspectos Sociales:

• Polkadot es una organización autónoma descentralizada masiva (DAO). La red implementa gobernanza completamente en cadena, autoejecutante, incluyendo actualizaciones de tiempo de ejecución sin bifurcación.
• La SEC ha reconocido DOT como software, no como un valor. (Para más detalles, ver:https://polkadot.com/newsroom/press-releases/web3-foundation-announces-polkadot-blockchains-native-token-dot-has-morphed-and-is-software-not-a-security)
• La mayor parte del trabajo de desarrollo en la red es gestionado por la Polkadot Fellowship (Para más detalles, ver:https://polkadot-fellows.github.io/dashboard/) en lugar de por Parity Technologies, una empresa que respalda financieramente el proyecto (https://www.parity.io/).

Aspectos técnicos:

• Polkadot implementó seguridad compartida y ejecución fragmentada.
• Usando un metaprotocolo basado en WASM (Para más detalles, ver:https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/wasm_meta_protocol/index.html) , el código del blockchain se almacena en el estado como bytecode. Esto permite que la mayoría de las actualizaciones ocurran sin bifurcaciones y habilita el particionado heterogéneo. (Consulte las secciones relevantes para obtener más información sobre el "particionado heterogéneo".)

Ejecución fragmentada: Puntos clave

Actualmente, estamos hablando de una red de capa 1 que alberga otras redes de "blockchain" de capa 2, similares a Polkadot y Ethereum. Por lo tanto, los términos Capa 2 y Parachain se pueden usar indistintamente.

El problema central de la escalabilidad de la cadena de bloques se puede enmarcar como: Hay un conjunto de validadores que, utilizando la criptoeconomía de la prueba de participación, asegura que la ejecución de cierto código sea confiable. Por defecto, estos validadores necesitan reejecutar todo el trabajo de los demás. Mientras impongamos que todos los validadores siempre reejecuten todo, el sistema completo seguirá siendo no escalable.

Tenga en cuenta que, siempre y cuando el principio de reejecución absoluta permanezca inalterado, aumentar el número de validadores en este modelo no mejora realmente la capacidad del sistema.

Esto demuestra una cadena de bloques monolítica (en lugar de una fragmentada). Todos los validadores de la red procesan las entradas (es decir, bloques) una por una. En tal sistema, si la Capa 1 desea alojar más Capas 2, entonces todos los validadores deben volver a ejecutar todo el trabajo de las Capas 2. Claramente, este método no es escalable.

Los rollups optimistas abordan este problema al volver a ejecutar (pruebas de fraude) solo cuando se reclama fraude. Los Rollups basados en SNARK abordan este problema aprovechando el hecho de que el costo de validar pruebas de SNARK es significativamente menor que el costo de generarlas, lo que permite a todos los validadores verificar eficientemente las pruebas de SNARK. Para obtener más detalles, consulte el “Apéndice: Diagrama del Espacio de Escalabilidad.”

Una solución directa para el particionamiento es dividir el conjunto de validadores en subconjuntos más pequeños y hacer que estos subconjuntos más pequeños vuelvan a ejecutar bloques de Capa2. ¿Cuáles son los problemas con este enfoque? Básicamente, estamos particionando tanto la ejecución como la seguridad económica de la red. Una solución de Capa2 como esta tiene una seguridad inferior en comparación con la Capa1, y su seguridad disminuye aún más a medida que dividimos el conjunto de validadores en más fragmentos.

A diferencia de los rollups optimistas, donde los costos de reejecución no siempre pueden evitarse, Polkadot fue diseñado teniendo en cuenta la ejecución fragmentada. Permite a una parte de los validadores reejecutar bloques de Capa 2 mientras proporciona suficiente evidencia cripto-económica a toda la red para demostrar que el bloque de Capa 2 es tan seguro como si el conjunto completo de validadores lo hubiera reejecutado. Esto se logra a través de un mecanismo novedoso (y recientemente formalizado) conocido como ELVES. (Para más detalles, ver:https://eprint.iacr.org/2024/961)

En resumen, ELVES se puede ver como un mecanismo de "rollups sospechosos". A través de varias rondas de validadores que consultan activamente a otros validadores sobre si un bloque de Capa 2 dado es válido, podemos confirmar con alta probabilidad la validez del bloque. En caso de cualquier disputa, todo el conjunto de validadores se involucra rápidamente. El cofundador de Polkadot, Rob Habermeier, explicó esto en detalle en un artículo. (Para más detalles, ver:https://polkadot.com/blog/polkadot-v1-0-sharding-and-economic-security#approval-checking-and-finality)

ELVES permite a Polkadot poseer tanto ejecución fragmentada como seguridad compartida, dos propiedades que anteriormente se consideraban mutuamente excluyentes. Este es el logro técnico principal de Polkadot1 en escalabilidad.

Ahora, avancemos con la analogía del “Core”. Una cadena de bloques de ejecución fragmentada es muy parecida a una CPU: al igual que una CPU puede tener múltiples núcleos ejecutando instrucciones en paralelo, Polkadot puede procesar bloques de Capa 2 en paralelo. Por eso, en Polkadot se llama a la Capa 2 una paracadena, y el entorno donde subconjuntos más pequeños de validadores vuelven a ejecutar un único bloque de Capa 2 se llama un “core”. Cada núcleo puede ser abstracto como “un grupo de validadores cooperantes.”

Puedes pensar en una blockchain monolítica como procesando un solo bloque a la vez, mientras que Polkadot procesa tanto un bloque de la cadena de relés como un bloque de la paracadena para cada núcleo en el mismo período de tiempo.

Heterogeneidad

Hasta ahora, solo hemos discutido la escalabilidad y la ejecución fragmentada ofrecida por Polkadot. Es importante tener en cuenta que cada uno de los fragmentos de Polkadot es, de hecho, una aplicación completamente diferente. Esto se logra a través del metaprotocolo almacenado como bytecode: un protocolo que almacena la definición de la cadena de bloques como bytecode en su estado. En Polkadot 1.0, se utiliza WASM como bytecode preferido, mientras que en JAM, se adopta PVM/RISC-V.

Por eso Polkadot se conoce como una cadena de bloques fragmentada heterogénea. (Para más detalles, ver:https://x.com/kianenigma/status/1790763921600606259) Cada Capa 2 es una aplicación completamente diferente.

Polkadot2

Un aspecto importante de Polkadot2 es hacer el uso de los núcleos más flexible. En el modelo original de Polkadot, los períodos de arrendamiento de núcleos iban de 6 meses a 2 años, lo que era adecuado para empresas con recursos pero menos factible para equipos más pequeños. La característica que permite que los núcleos de Polkadot se utilicen de manera más flexible se llama "Agile Coretime." (Para más detalles, ver:https://polkadot.com/agile-coretime) En este modo, los términos de arrendamiento principales pueden ser tan cortos como un solo bloque o tan largos como un mes, con un límite de precio para aquellos que deseen arrendar por períodos más largos.

Las otras características de Polkadot 2 se están revelando gradualmente a medida que avanza nuestra discusión, por lo que no es necesario profundizar más en ellas aquí.

Operaciones en el núcleo vs Operaciones en la cadena

Para entender JAM, es importante primero comprender qué sucede cuando un bloque de Capa 2 entra en el núcleo de Polkadot. La siguiente es una explicación simplificada.

Recuerde que un núcleo consiste principalmente en un conjunto de validadores. Entonces, cuando decimos "los datos se envían al núcleo", significa que los datos se pasan a este conjunto de validadores.

1. Un bloque de Capa 2, junto con parte del estado de esa Capa 2, se envía al núcleo. Estos datos contienen toda la información necesaria para ejecutar el bloque de Capa 2.

2. Una parte de los validadores principales volverá a ejecutar el bloque de la Capa 2 y continuará con las tareas relacionadas con el consenso.

3. Estos validadores principales proporcionan los datos reejecutados a otros validadores fuera del núcleo. Según las reglas de ELVES, estos validadores pueden decidir si volver a ejecutar o no el bloque de la Capa 2, necesitando estos datos para hacerlo.

Es importante tener en cuenta que, hasta ahora, todas estas operaciones están ocurriendo fuera del bloque principal de Polkadot y de la función de transición de estado. Todo ocurre dentro del núcleo y la capa de disponibilidad de datos.

1. Finalmente, una pequeña parte del estado más reciente de la Capa 2 se hace visible en la cadena principal de retransmisión de Polkadot. A diferencia de las operaciones anteriores, este paso es mucho más barato que volver a ejecutar el bloque de la Capa 2, y afecta al estado principal de Polkadot. Es visible en un bloque de Polkadot y es ejecutado por todos los validadores de Polkadot.

A partir de esto, podemos explorar algunas operaciones clave que Polkadot está realizando:

• Desde el Paso 1, podemos concluir que Polkadot ha introducido un nuevo tipo de ejecución, diferente de las funciones tradicionales de transición de estado de la cadena de bloques. Normalmente, cuando todos los validadores de la red realizan una tarea, el estado principal de la cadena de bloques se actualiza. Esto es lo que llamamos ejecución en cadena, y es lo que sucede en el Paso 3. Sin embargo, lo que sucede dentro del núcleo (Paso 1) es diferente. Esta nueva forma de computación de blockchain se conoce como ejecución en el núcleo.
• Desde el Paso 2, inferimos que Polkadot tiene un nativo Disponibilidad de Datos (DA)la capa, y los Layer 2s lo utilizan automáticamente para garantizar que la evidencia de su ejecución permanezca disponible durante un cierto período. Sin embargo, los bloques de datos que se pueden publicar en la capa DA son fijos, conteniendo solo la evidencia requerida para la reejecución de la Capa 2. Además, el código de la paracadena no lee los datos de la capa DA.

Comprender esto forma la base para entender JAM. Aquí tienes un resumen:

• Ejecución en núcleo: Se refiere a operaciones que tienen lugar dentro del núcleo. Estas operaciones son ricas, escalables y seguras a través de la criptoeconomía y ELVES, ofreciendo la misma seguridad que la ejecución on-chain.
• Ejecución en cadena: Se refiere a las operaciones ejecutadas por todos los validadores. Estas están garantizadas económicamente para ser seguras por defecto, pero son más costosas y restrictivas ya que todos realizan todas las tareas.
• Disponibilidad de datos: Se refiere a la capacidad de los validadores de Polkadot para garantizar la disponibilidad de ciertos datos durante cierto período de tiempo y proporcionarlos a otros validadores.

JAM

Con esta comprensión, ahora podemos introducir JAM.

JAM es un nuevo protocolo inspirado en el diseño de Polkadot y totalmente compatible con él, con el objetivo de reemplazar la cadena de relé de Polkadot y hacer que el uso principal sea completamente descentralizado e irrestricto.

Construido en Polkadot 2, JAM se esfuerza por hacer que la implementación de las Capas 2 en el núcleo sea más accesible, ofreciendo aún más flexibilidad que el modelo ágil-coretime.

• Polkadot 2 permite que la implementación de la Capa 2 en el núcleo sea más dinámica.
• JAM tiene como objetivo permitir que cualquier aplicación se implemente en el núcleo de Polkadot, incluso si esas aplicaciones no están estructuradas como blockchains o capas 2.

Esto se logra principalmente exponiendo los tres conceptos básicos discutidos anteriormente a los desarrolladores: ejecución en cadena, ejecución en núcleo y la capa DA.

En otras palabras, en JAM, los desarrolladores pueden:

• Programar completamente tareas tanto en el núcleo como en la cadena.
• Leer desde y escribir en la capa DA de Polkadot con datos arbitrarios.

Esto forma la visión general básica de los objetivos de JAM. No hace falta decir que gran parte de esto ha sido simplificado y es probable que el protocolo evolucione aún más.

Con esta comprensión fundamental, ahora podemos adentrarnos en algunos de los detalles de JAM en los siguientes capítulos.

Servicios y elementos de trabajo

En JAM, lo que antes se conocía como Capa 2 o paracadenas ahora se llama Servicios, y lo que antes se conocía como bloques o transacciones ahora se llama Elementos de trabajo o Paquetes de trabajoEspecíficamente, un elemento de trabajo pertenece a un servicio, y un paquete de trabajo es una colección de elementos de trabajo. Estos términos son intencionalmente amplios para abarcar casos de uso más allá de escenarios de blockchain/Layer 2.

Un servicio está descrito por tres puntos de entrada, dos de los cuales son fn refine() y fn accumulate(). El primero describe lo que el servicio hace durante la ejecución en núcleo, y el segundo describe lo que hace durante la ejecución en cadena.

Finalmente, los nombres de estos puntos de entrada son la razón por la que el protocolo se llama JAM (Join Accumulate Machine).Únetese refiere arefinar fn(), que es la fase en la que todos los núcleos de Polkadot procesan un gran volumen de trabajo en paralelo a través de diferentes servicios. Después de que los datos se procesan, pasan a la siguiente etapa.Acumularrefiere al proceso de acumular todos estos resultados en el estado principal JAM, que ocurre durante la fase de ejecución en cadena.

Los elementos de trabajo pueden especificar con precisión el código que ejecutan en el núcleo y en la cadena, así como cómo, cuándo y desde dónde leen o escriben contenido en el Lago de Datos Distribuido.

Semi-Consistencia

Revisando la documentación existente sobre XCM (el lenguaje seleccionado por Polkadot para la comunicación entre paracadenas), toda la comunicación es asincrónica (para más detalles, veraquíEsto significa que una vez que se envía un mensaje, no se puede esperar su respuesta. La comunicación asincrónica es un síntoma de inconsistencia en el sistema, y una de las principales desventajas de los sistemas permanentemente fragmentados como Polkadot 1, Polkadot 2 y los ecosistemas existentes de capa 2 de Ethereum.

Sin embargo, como se describe en la Sección 2.4 delLibro gris, un sistema completamente coherente que permanece sincrónico para todos sus inquilinos solo puede escalar hasta cierto grado sin sacrificar universalidad, accesibilidad o resistencia.

• Síncrono ≈ Consistencia || Asíncrono ≈ Inconsistencia

Aquí es donde JAM se destaca: al introducir varias características, JAM logra un estado intermedio novedoso conocido como un sistema semi-consistente. En este sistema, los subsistemas que se comunican con frecuencia pueden crear un entorno consistente entre sí, sin obligar a que todo el sistema permanezca consistente. Esto fue mejor descrito por el Dr. Gavin Wood, autor del Graypaper, en una entrevista: https://www.youtube.com/watch?t=1378&v=O3kRAVBTkfs&embeds_referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ

Otra forma de entender esto es viendo a Polkadot/JAM como un sistema fragmentado, donde los límites entre estos fragmentos son fluidos y determinados dinámicamente.

Polkadot siempre ha sido fragmentado y totalmente heterogéneo.

Ahora, no solo está fragmentado y heterogéneo, sino que estos límites de fragmentación pueden definirse de manera flexible, lo que Gavin Wood se refiere como un sistema “semi-consistente” en sus tweets y el Graypaper. (por favor ver: https://x.com/gavofyork?ref_src=twsrc%5Etfw、https://graypaper.com/)

Varias características hacen posible este estado semi-consistente:

1. Acceso a la ejecución paralela sin estado en el núcleo, donde diferentes servicios solo pueden interactuar de forma sincrónica con otros servicios dentro del mismo núcleo y bloque específico, así como a la ejecución en cadena, donde los servicios pueden acceder a los resultados de todos los servicios en todos los núcleos.
2. JAM no impone ninguna programación específica de servicios. Los servicios con comunicación frecuente pueden proporcionar incentivos económicos a sus programadores para crear paquetes de trabajo que contengan estos servicios que se comunican con frecuencia. Esto permite que estos servicios se ejecuten en el mismo núcleo, haciendo que sus interacciones parezcan síncronas, aunque estén distribuidas.
3. Además, los servicios JAM pueden acceder a la capa DA y utilizarla como una capa de datos temporal y extremadamente rentable. Una vez que los datos se colocan en la DA, eventualmente se propagan a todos los núcleos, pero están disponibles de inmediato dentro del mismo núcleo. Por lo tanto, los servicios JAM pueden lograr un mayor grado de acceso a los datos programándose dentro del mismo núcleo en bloques consecutivos.

Es importante tener en cuenta que si bien estas capacidades son posibles dentro de JAM, no están obligadas a nivel de protocolo. En consecuencia, algunas interfaces son teóricamente asíncronas pero pueden funcionar de forma síncrona en la práctica debido a abstracciones sofisticadas e incentivos. CorePlay, que se discutirá en la siguiente sección, es un ejemplo de este fenómeno.

CorePlay

Esta sección presenta CorePlay, un concepto experimental en el entorno JAM que puede describirse como un nuevo modelo de programación de contratos inteligentes. En el momento de la escritura, CorePlay no ha sido completamente definido y sigue siendo una idea especulativa.

Para entender CorePlay, primero necesitamos presentar la máquina virtual (VM) elegida por JAM: la PVM.

PVM

PVM es un detalle clave tanto en JAM como en CorePlay. Los detalles de nivel inferior de PVM están más allá del alcance de este documento y son mejor explicados por expertos en el dominio en el Graypaper. Sin embargo, para esta explicación, destacaremos algunas atributos clave de PVM:

• Medición eficiente
• La capacidad de pausar y reanudar la ejecución

Este último es especialmente crucial para CorePlay.

CorePlay es un ejemplo de cómo los primitivos flexibles de JAM pueden ser utilizados para crear un entorno de contrato inteligente síncrono y escalable con una interfaz de programación altamente flexible. CorePlay propone que los contratos inteligentes basados en actores se desplieguen directamente en núcleos JAM, lo que les permite beneficiarse de interfaces de programación síncronas. Los desarrolladores pueden escribir contratos inteligentes como si fueran funciones simples fn main(), utilizando expresiones como let resultado = other_coreplay_actor(data).await? para comunicarse. Siotro actor de CorePlayestá en el mismo núcleo JAM en el mismo bloque, esta llamada es síncrona. Si está en otro núcleo, el actor será pausado y reanudado en un bloque JAM posterior. Esto es posible gracias a los servicios JAM, su programación flexible y las capacidades de PVM.

Servicio CoreChains

Finalmente, resumamos la razón principal por la que JAM es totalmente compatible con Polkadot. El producto estrella de Polkadot son sus parachains ágiles de núcleo-tiempo, que continúan en JAM. Es probable que los servicios desplegados más temprano en JAM sean conocidos como CoreChains o Parachains, lo que permite que las parachains existentes de estilo Polkadot-2 se ejecuten en JAM.

Se pueden implementar más servicios en JAM, y el servicio CoreChains existente puede comunicarse con ellos. Sin embargo, los productos actuales de Polkadot seguirán siendo robustos, simplemente abriendo nuevas puertas para los equipos de parachain existentes.

Apéndice: Fragmentación de datos

La mayor parte de este documento discute la escalabilidad desde la perspectiva del fragmentado de ejecución. Sin embargo, también podemos examinar este problema desde el punto de vista del fragmentado de datos. Curiosamente, encontramos que esto es similar al modelo semi-consistente mencionado anteriormente. En principio, un sistema totalmente consistente es superior pero no escalable, mientras que un sistema totalmente inconsistente escala bien pero es subóptimo. JAM, con su modelo semi-consistente, introduce una nueva posibilidad.

• Sistemas Totalmente Coherentes: Estas son plataformas donde todo está sincronizado, como Solana o aquellas desplegadas exclusivamente en la capa 1 de Ethereum. Todos los datos de la aplicación se almacenan en la cadena y son fácilmente accesibles por todas las demás aplicaciones. Esto es ideal desde un punto de vista de programabilidad pero no escalable.
• Sistemas inconsistentes: Los datos de la aplicación se almacenan fuera de la Capa 1 o en fragmentos diferentes y aislados. Esto es altamente escalable pero tiene un mal rendimiento en cuanto a composabilidad. Los modelos de rollup de Polkadot y Ethereum entran en esta categoría.

JAM ofrece algo más allá de estas dos opciones: permite a los desarrolladores publicar datos arbitrarios en la capa DA de JAM, que sirve como un punto intermedio entre los datos en cadena y fuera de cadena. Se pueden construir nuevas aplicaciones que aprovechen la capa DA para la mayor parte de sus datos, mientras que solo persisten los datos absolutamente críticos en el estado de JAM.

Apéndice: Paisaje de Escalabilidad

Esta sección vuelve a examinar nuestra perspectiva sobre la escalabilidad de blockchain, que también se discute en el Graypaper, aunque se presenta aquí de forma más concisa.

La escalabilidad de la cadena de bloques sigue en gran medida los métodos tradicionales de los sistemas distribuidos: escalado vertical y escalado horizontal.

La escalabilidad vertical es en lo que se centran plataformas como Solana, maximizando el rendimiento optimizando tanto el código como el hardware hasta sus límites.

La escalabilidad horizontal es la estrategia adoptada por Ethereum y Polkadot: reducir la carga de trabajo que cada participante necesita manejar. En sistemas distribuidos tradicionales, esto se logra agregando más máquinas réplica. En blockchain, la “computadora” es toda la red de validadores. Al distribuir tareas entre ellos (como lo hace ELVES) o reduciendo optimistamente sus responsabilidades (como en Optimistic Rollups), disminuimos la carga de trabajo para todo el conjunto de validadores, logrando así la escalabilidad horizontal.

En blockchain, el escalado horizontal se puede asemejar a "reducir el número de máquinas que necesitan realizar todas las operaciones".

En resumen:

1. Escalado vertical: Hardware de alto rendimiento + optimización de blockchains monolíticas.
2. Escalado horizontal:
   • Rollups optimistas
   • Rollups basados en SNARK
   • ELVES: Rollups cínicos de Polkadot

Apéndice: Mismo Hardware, Actualización del Kernel

Esta sección se basa en la analogía de Rob Habermeier de Sub0 2023: Polkadot: Kernel/Userland | Sub0 2023 - YouTube (ver:https://www.youtube.com/watch?v=15aXYvVMxlw) que muestra JAM como una actualización para Polkadot: una actualización del núcleo en el mismo hardware.

En un ordenador típico, podemos dividir toda la pila en tres partes:

1. Hardware
2. Núcleo
3. Espacio de usuario

En Polkadot, el hardware, la infraestructura principal que proporciona computación y disponibilidad de datos, siempre ha sido los núcleos, como se mencionó anteriormente.

En Polkadot, el núcleo hasta ahora ha consistido en dos partes principales:

1. El Protocolo de Parachains: una forma fija y dogmática de utilizar los núcleos.
2. Un conjunto de funcionalidades de bajo nivel, como el token DOT y su transferibilidad, staking, gobernanza, etc.

Ambos existen en la Cadena de Relevo de Polkadot.

Las aplicaciones del espacio de usuario, por otro lado, son las parachains mismas, sus tokens nativos y todo lo que se construye sobre ellas.

Podemos visualizar este proceso de la siguiente manera:

Polkadot ha imaginado durante mucho tiempo trasladar más funcionalidades básicas a sus usuarios principales, las parachains. Este es precisamente el objetivo del RFC de Reenvío Mínimo. (Para más detalles, ver:Minimal Relay RFC)

Esto significa que la Cadena de Relé de Polkadot solo se encargaría de proporcionar el protocolo de parachain, reduciendo así el espacio del núcleo en cierta medida.

Una vez que esta arquitectura esté implementada, será más fácil visualizar cómo será la migración de JAM. JAM reducirá significativamente el espacio del núcleo de Polkadot, haciéndolo más versátil. Además, el protocolo de Parachains se trasladará al espacio de usuario, ya que es una de las pocas formas de construir aplicaciones en el mismo núcleo (hardware) y kernel (JAM).

Esto también refuerza por qué JAM es un reemplazo para la Cadena de Relé de Polkadot, no para las parachains.

En otras palabras, podemos ver la migración de JAM como una actualización del kernel. El hardware subyacente permanece sin cambios y gran parte del contenido del antiguo kernel se traslada al espacio de usuario para simplificar el sistema.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [ Instituto de Investigación Ecológica de Polkadot], Todos los derechos de autor pertenecen al autor original [Instituto de Investigación Ecológica de Polkadot]. Si hay objeciones a esta reimpresión, póngase en contacto con el Aprendizaje de la puertaequipo y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.