文是 Parity 核心开发者 Kian Paimani 从技术角度解读波卡最新提出的 JAM protocolo，以帮助人们更好地了解 JAM 如何为波卡生态系统带来全新的可扩展性。
Escrito por: Kian Paimani, Desarrollador principal de Parity
Compilación: Polkadot Labs
"El 'Polkadot Knowledge Graph' es nuestro artículo introductorio desde cero para Polkadot. Intentamos comenzar desde lo más básico de Polkadot, proporcionando a todos una comprensión integral del contenido de Polkadot. Por supuesto, esto es un gran desafío, pero esperamos que a través de este esfuerzo, todos puedan comprender correctamente Polkadot y que las personas que no lo conocen puedan familiarizarse rápidamente con el conocimiento relacionado con Polkadot.Hoy es el número 148 de esta sección, y este artículo es una interpretación técnica del protocolo JAM recientemente propuesto por Kian Paimani, un desarrollador principal de Parity, para ayudar a las personas a comprender mejor cómo JAM puede aportar nueva escalabilidad al ecosistema de Polkadot. Este artículo está escrito desde el punto de vista del autor en primera persona.
*A continuación se detalla la explicación de Polkadot1, Polkadot2 y cómo evolucionan hacia JAM. (Para más detalles, consulte: ****) Este artículo está dirigido a lectores técnicos, especialmente aquellos que no están muy familiarizados con Polkadot pero tienen cierto conocimiento de los sistemas de blockchain, y posiblemente a lectores que estén familiarizados con tecnologías relacionadas con otros ecosistemas.
*Creo que es una buena introducción leer este artículo antes de leer el libro gris de JAM. (Ver detalles: ***)
Conocimiento de fondo
Este artículo asume que el lector está familiarizado con los siguientes conceptos:
Describir la cadena de bloques como una función de transición de estado.
Comprender qué es un "estado". (Consulte: _sdk_docs/reference_docs/blockchain_state_machines/index.html para más detalles)
Seguridad económica y Prueba de participación。（详情请参见：、）
Introducción: Polkadot1
Primero, repasemos lo que considero la característica más innovadora de Polkadot1.
A nivel social:
Polkadot es una gran Organización Autónoma Descentralizada (DAO). La red logra una gobernanza totalmente basada en la cadena, con ejecución automática, incluyendo actualizaciones en tiempo de ejecución sin necesidad de fork.
La Comisión Nacional del Mercado de Valores (SEC) de los Estados Unidos considera DOT como software en lugar de valores (ver detalles en: )
La mayor parte del trabajo de desarrollo de redes es llevado a cabo por Polkadot Fellowship (consulte los detalles en: ), en lugar de las empresas apoyadas por la financiación (como Parity: ).
En el nivel técnico:
Polkadot ha logrado la seguridad compartida y la ejecución de Fragmentación.
Almacenar el código de la cadena de bloques en forma de bytecode utilizando el protocolo de metadatos WASM (consulte: _sdk_docs/reference_docs/wasm_meta_protocol/index.html) para permitir la mayoría de las actualizaciones sin necesidad de fork y lograr una fragmentación heterogénea.
Para obtener más información sobre 'Fragmentación heterogénea', consulte los capítulos correspondientes.
Ejecución de Fragmentación: Puntos clave del núcleo
Actualmente estamos discutiendo una red de Layer1 que actúa como un custodio para otras redes de Layer2 'blockchain', similar a Polkadot y Ethereum. Por lo tanto, los términos Layer2 y Parachain pueden intercambiarse.
El problema central de la escalabilidad de la cadena Bloquear se puede expresar como la existencia de un grupo de validadores que pueden garantizar la ejecución confiable de cierto código a través de la economía criptográfica de la Prueba de Participación (Proof-of-Stake). Por defecto, estos validadores necesitan volver a ejecutar todo el trabajo entre ellos. Por lo tanto, si obligamos a todos los validadores a volver a ejecutar todo en todo momento, el sistema completo no será escalable.
Tenga en cuenta que el aumento de la cantidad de validadores en este modelo no aumentará realmente el rendimiento del sistema siempre y cuando se mantenga inalterable el principio absoluto de reejecución mencionado anteriormente.
Lo que se muestra arriba es una cadena de bloques monolítica (en contraposición a una cadena de bloques fragmentada). Todos los validadores de la red procesarán las entradas (es decir, bloques) uno por uno.
En un sistema de este tipo, si Layer1 desea alojar más Layer2, entonces todos los validadores deben volver a ejecutar todo el trabajo de Layer2. Obviamente, este enfoque no es escalable. Los rollups optimistas son una forma de evitar este problema, ya que solo se vuelve a ejecutar cuando alguien reclama que ha ocurrido una prueba de fraude. Los rollups basados en SNARK evitan este problema al aprovechar el hecho de que el costo de verificar una prueba de SNARK es mucho menor que generarla, lo que permite que todos los validadores verifiquen que la prueba de SNARK es válida. Para obtener más información al respecto, consulte 'Anexo: Gráfico del espacio de escalabilidad'.
Una solución simple para la fragmentación es simplemente dividir el conjunto de validadores en subconjuntos más pequeños y hacer que estos subconjuntos más pequeños vuelvan a ejecutar el Bloquear de la capa 2. ¿Cuál es el problema con este enfoque? Estamos fragmentando la seguridad de la ejecución y la economía de la red de esta manera. La seguridad de la capa 2 es inferior a la de la capa 1, y a medida que dividimos el conjunto de validadores en más fragmentos, su seguridad disminuirá aún más.
A diferencia de los rollups optimistas que no pueden volver a ejecutar los costos de manera consistente, Polkadot considera la fragmentación en su diseño, lo que permite a algunos validadores volver a ejecutar Bloquear de Layer2, al mismo tiempo que proporciona suficiente evidencia económica de cripto a todos los participantes de la red para demostrar la autenticidad de este Bloquear de Layer2, tan seguro como cuando todo el conjunto de validadores lo vuelve a ejecutar. Esto se logra a través de un mecanismo novedoso (recientemente lanzado oficialmente) ELVES. (Ver detalles: )
En pocas palabras, ELVES puede considerarse como un mecanismo de "rollups escépticos". Preguntando a otros validadores si un Bloqueo de Layer2 es válido o no, podemos confirmar la validez del Bloqueo de Layer2 con una alta probabilidad. De hecho, en caso de cualquier disputa, pronto se pedirá la participación de toda la colección de validadores. Rob Habermeier, cofundador de Polkadot, lo explica en detalle en un artículo. (Ver para más detalles:)
ELVES permite que Polkadot tenga dos propiedades que antes se consideraban mutuamente excluyentes: 'Fragmentación ejecutiva' y 'seguridad compartida'. Este es uno de los principales logros técnicos de Polkadot en cuanto a escalabilidad.
Ahora, continuemos discutiendo la analogía de "CORE".
Una cadena de Bloquear que ejecuta Fragmentación es muy similar a una CPU: al igual que la CPU puede tener núcleos que ejecutan instrucciones en paralelo, Polkadot puede procesar en paralelo las Layer2 Bloquear. Por eso las Layer2 en Polkadot se llaman parachain, y el entorno en el que un subconjunto más pequeño de validadores vuelve a ejecutar un solo Layer2 Bloquear se llama "CORE". Cada CORE se puede abstraer como "un grupo de validadores que trabajan en conjunto".
Puedes pensar en una cadena de bloques de un solo bloque como tomar solo un bloque en cualquier período de tiempo, mientras que Polkadot toma un bloque de la cadena de repetidores y un bloque de la cadena paralela de cada núcleo en cada período de tiempo.
Heterogeneidad
Hasta ahora, solo hemos discutido la escalabilidad y la ejecución de Fragmentación que Polkadot proporciona. Es importante tener en cuenta que cada Fragmentación de Polkadot es en realidad una aplicación completamente diferente. Esto se logra mediante el uso de un protocolo de elemento almacenado en bytecode: un protocolo que define la cadena de bloques se almacena como bytecode en el estado mismo de la cadena de bloques. En Polkadot 1.0, se utilizó WASM como bytecode preferido, mientras que en JAM se adoptó PVM/RISC-V.
En resumen, esto es por qué Polkadot se llama una cadena de bloques de fragmentación heterogénea. (Ver más detalles: ) Cada Capa 2 es una aplicación completamente diferente.
Polkadot2
Una parte importante de Polkadot2 es hacer que el uso del núcleo sea más flexible. En el modelo original de Polkadot, el plazo del núcleo puede variar de 6 meses a 2 años, lo cual es adecuado para empresas con recursos abundantes, pero no es adecuado para equipos pequeños. Las características del núcleo ágil, que permiten un uso más flexible de Polkadot, se conocen como 'agile coretime'. En este modo, el plazo del núcleo de Polkadot puede ser tan corto como un Bloquear o tan largo como un mes, y ofrece una garantía de precio máximo para aquellos usuarios que deseen alquilar a largo plazo.
Otras características de Polkadot 2 están empezando a mostrarse gradualmente en el proceso que estamos discutiendo, por lo que no es necesario extenderse demasiado aquí.
Operaciones internas y on-chain del núcleo
Para entender JAM, primero necesitamos entender qué sucede cuando un Bloquear de Layer2 ingresa al núcleo de Polkadot.
El siguiente contenido ha sido simplificado en gran medida.
En resumen, el núcleo está compuesto principalmente por un grupo de validadores. Por lo tanto, cuando decimos 'los datos se envían al núcleo', en realidad nos referimos a que estos datos se transmiten a este grupo de validadores.
Un bloque Layer2 junto con una parte de su estado se envía al núcleo. Estos datos contienen toda la información necesaria para ejecutar el bloque Layer2.
Parte de los validadores en el núcleo volverán a ejecutar Layer2 Bloquear y continuarán procesando tareas relacionadas con Consenso.
Los validadores principales volverán a proporcionar los datos necesarios a otros validadores (fuera del núcleo principal). Los otros validadores pueden decidir según las reglas de ELVES si volver a ejecutar el bloqueador de Layer2 y necesitan estos datos para hacerlo.
Ten en cuenta que hasta el momento, todas las operaciones se han llevado a cabo fuera del bloque principal y las funciones de cambio de estado de Polkadot. Todo ocurre en el núcleo interno y en la capa de disponibilidad de datos.
Finalmente, una pequeña parte del estado más reciente de Layer2 será visible en el relay chain principal de Polkadot. A diferencia de todas las operaciones anteriores, esta operación es mucho más barata que volver a ejecutar Layer2 en el bloque de Polkadot. Afectará al estado principal de Polkadot, será visible en el bloque de Polkadot y será ejecutado por todos los validadores de Polkadot.
A partir del contenido anterior, podemos explorar algunas de las operaciones que está realizando Polkadot:
En primer lugar, desde el paso 1 podemos concluir que Polkadot tiene una forma de ejecución novedosa diferente a la función de transición de estado de la cadena de bloques tradicional. Normalmente, cuando todos los validadores en la red realizan un trabajo, el estado principal de la cadena se actualiza. Llamamos a esta situación operación on-chain (operación on-chain), que es lo que sucede en el paso 3. Sin embargo, lo que ocurre internamente en el núcleo (paso 1) es diferente. Llamamos a este nuevo cálculo de la cadena interna in-core ution.
A continuación, a partir del punto 2, podemos inferir que Polkadot ha proporcionado una capa de disponibilidad de datos nativa (Data-Availability, en adelante DA) y que Layer2 la utiliza automáticamente para asegurar que su prueba de ejecución esté disponible durante un cierto período de tiempo. Sin embargo, los bloques de datos que se pueden publicar en esta capa de DA son fijos y siempre son pruebas necesarias para volver a ejecutar Layer2. Además, el código de la parachain nunca lee datos de la capa de DA.
Entender el contenido anterior es la base para entender JAM. Resumiendo:
En el núcleo: se refiere a las operaciones que se producen dentro del núcleo. Se caracteriza por ser rico, escalable y logra la misma seguridad que la ejecución on-chain a través de Crypto economics y ELVES.
Ejecución en cadena (on-chain ution): se refiere a las operaciones realizadas por todos los validadores. Los validadores obtienen seguridad por defecto a través de garantías económicas, pero con mayores costos y restricciones, ya que todos realizan todas las operaciones.
数据可用性（Disponibilidad de datos）：Los validadores de Polkadot se comprometen a la disponibilidad de ciertos datos durante un período de tiempo y tienen la capacidad de proporcionar estos datos a otros validadores.
MERMELADA
Con base en la comprensión de la primera parte, podemos pasar sin problemas a la introducción de JAM.
JAM es un nuevo protocolo diseñado inspirado en Polkadot y completamente compatible con él, con el objetivo de reemplazar la cadena de relé de Polkadot y hacer que el uso centralizado y sin restricciones sea completamente descentralizado.
JAM se construye sobre Polkadot2 con el objetivo de hacer que el núcleo de Polkadot sea más accesible, pero de una manera más flexible y sin restricciones fijas en comparación con agile-coretime.
Polkadot2 permite una implementación más flexible de Layer2 en su núcleo.
JAM tiene como objetivo permitir que cualquier aplicación se despliegue en el núcleo de Polkadot, incluso si estas aplicaciones no son como blockchains o capas 2.
Esto se logra principalmente mediante la exposición a los desarrolladores de los tres conceptos principales discutidos anteriormente: ejecución en la cadena, ejecución interna del núcleo y capa DA.
En otras palabras, en JAM, los desarrolladores pueden acceder a:
Completamente Programabilidadización del núcleo y el trabajo on-chain.
Se permite que cualquier dato se lea y escriba en la capa DA de Polkadot.
Esta es una descripción básica del objetivo JAM. No es necesario decir más, se han realizado muchas simplificaciones aquí, y el protocolo podría seguir evolucionando.
Con esta comprensión básica, ahora podemos explorar más a fondo algunos detalles de JAM en los próximos capítulos.
1 Servicio y Elemento de Trabajo
En el contexto de JAM, lo que solía llamarse Layer2/parachain ahora se llama "Servicio", y lo que solía llamarse Bloquear/ transacción ahora se llama "Ítem de trabajo" o "Paquete de trabajo". Específicamente, un ítem de trabajo pertenece a un servicio, mientras que un paquete de trabajo es una colección de ítems de trabajo. Estos términos están diseñados intencionalmente para ser lo suficientemente generales como para abarcar una variedad de casos de uso que van más allá de la cadena Bloquear/Layer2.
Un servicio está descrito por tres puntos de entrada, dos de los cuales son fn refine() y fn accumulate(). El primero describe el contenido ejecutado en el núcleo del servicio, y el segundo describe el contenido ejecutado on-chain.
Finalmente, el nombre de los dos puntos de entrada también es la razón por la que se llama JAM (Join Accumulate Machine) al protocolo. Join se refiere a fn refine(), cuando todos los núcleos de Polkadot procesan en paralelo una gran cantidad de trabajo de diferentes servicios, esta etapa se llama Join. Una vez que los datos han sido filtrados, pasan a la siguiente etapa. Accumulate se refiere al proceso en el que todos los resultados anteriores se acumulan en el estado principal de JAM, es decir, la parte de ejecución on-chain.
Los elementos de trabajo pueden especificar con precisión qué código ejecutar en el núcleo, on-chain, y cómo / si / desde dónde leer / escribir contenido en el Lago de Datos Distribuido (Distributed Data Lake).
2 Semi-consistencia
Al revisar la información existente sobre XCM (el lenguaje de comunicación de parachain elegido por Polkadot), se observa que todas las comunicaciones son asíncronas. Esto significa que una vez que se envía un mensaje, no se puede esperar una respuesta. (Consulte los detalles en:)
La asincronía es la manifestación de la inconsistencia del sistema, y es la principal desventaja de los sistemas de Fragmentación permanentes (como Polkadot 1 y Polkadot 2 y el ecosistema Layer2 existente de Ethereum).
Sin embargo, como se describe en la sección 2.4 del libro blanco, un sistema completamente coherente que siempre mantiene sincronizados a todos sus inquilinos solo puede subir hasta cierto punto sin sacrificar universalidad, accesibilidad o flexibilidad. (Ver detalles en: )
Este es otro campo en el que JAM se destaca: al introducir múltiples características, JAM logra un nuevo estado intermedio, es decir, un sistema de semi-consistencia. En este sistema, los subsistemas que se comunican con frecuencia tienen la oportunidad de crear un entorno coherente entre sí sin obligar al sistema completo a mantener la coherencia. Esto se describe mejor en la entrevista del Dr. Gavin Wood, autor del libro gris (ver detalles en: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ).
Otra forma de entender a Polkadot / JAM es como un sistema de Fragmentación, donde los límites de estas Fragmentaciones son fluidos y se determinan de manera dinámica.
Polkadot siempre ha sido Fragmentación, y completamente heterogéneo.
Ahora, será fragmentado, heterogéneo, y los límites de estos fragmentos pueden ser flexiblemente determinados, tal como Gavin Wood lo llamó en Twitter, un sistema de "semi-consistencia". (Ver detalles en: _src=twsrc%5Etfw)
Las características que hacen posible todo esto incluyen:
Acceder a la ejecución central sin estado y paralela, donde los diferentes servicios solo pueden interactuar de forma sincrónica con otros servicios en el mismo bloquear específico y en el mismo núcleo, así como la ejecución on-chain, donde los servicios pueden acceder a los resultados de todos los servicios en todos los núcleos.
JAM no impone ninguna programación de servicio específica. Los servicios de comunicación frecuente pueden proporcionar incentivos económicos a sus ordenadores de servicio y crear paquetes de trabajo que contengan estos servicios de comunicación frecuente. Esto permite que estos servicios se ejecuten en el mismo núcleo y que la comunicación entre ellos sea similar a la que se produce en un entorno sincrónico.
Además, el servicio JAM puede acceder a la capa de datos DA y usarla como una forma temporal pero extremadamente económica de Capa de datos. Una vez que los datos se colocan en DA, eventualmente se propagarán a todos los núcleos, pero estarán disponibles de inmediato en el mismo núcleo. Por lo tanto, el servicio JAM puede programarse en el mismo núcleo en bloques consecutivos para disfrutar de un mayor acceso a los datos.
Es importante tener en cuenta que aunque lo anterior es posible en JAM, no se aplica obligatoriamente en la capa de protocolo. Por lo tanto, se espera que algunas interfaces sean teóricamente asíncronas, pero mediante una abstracción ingeniosa y medidas de incentivo, pueden parecer sincrónicas en la práctica. La siguiente sección discutirá CorePlay como ejemplo de esto.
3 CorePlay
En esta sección se presenta CorePlay, una idea experimental en el entorno JAM que se puede describir como un nuevo modelo de programación de Contratos inteligentes. Hasta la fecha de redacción de este artículo, CorePlay aún no se ha detallado y sigue siendo una idea.
Para entender CorePlay, primero necesitamos presentar la Máquina virtual elegida por JAM: PVM.
4 PVM
PVM es un detalle importante en JAM y CorePlay. Los detalles a nivel inferior de PVM están más allá del alcance de este documento, es mejor consultar la descripción en el libro blanco de expertos en el campo. Sin embargo, para las necesidades de este documento, solo necesitamos explicar algunas propiedades de PVM:
Medición eficiente
La capacidad de suspender y reanudar la ejecución
Esto es especialmente importante para CorePlay.
CorePlay es un ejemplo de cómo usar el lenguaje JAM para crear un entorno de contratos inteligentes sincronizado y escalable, con una interfaz de programación muy flexible. CorePlay sugiere desplegar directamente los contratos inteligentes basados en actores en el núcleo de JAM, lo que les permite disfrutar de una interfaz de programación síncrona, donde se pueden escribir como el fn main() normal, y comunicarse a través de let_result=other_coreplay_actor(data).await?. Si other_coreplay_actor está en el mismo núcleo de Bloquear de JAM, esta llamada es sincrónica; si está en otro núcleo, el actor se pausará y se reanudará en Bloquear subsiguiente de JAM. Esto es posible gracias a los servicios de JAM y su programación flexible, así como a las propiedades de PVM.
Servicios de 5 CoreChains
Por último, resumamos las principales razones por las que se menciona que JAM es completamente compatible con Polkadot. El producto principal de Polkadot es Parachains, que se ejecuta en modo de tiempo central ágil, y este producto se extiende en JAM.
Los servicios desplegados por primera vez en JAM podrían denominarse CoreChains o Parachains. Este servicio permitirá que las parachains existentes de estilo Polkadot -2 se ejecuten en JAM.
Los servicios adicionales se pueden implementar en JAM y los servicios existentes de CoreChains pueden comunicarse con ellos, pero los productos existentes de Polkadot seguirán siendo fuertes y solo abrirán nuevas puertas para los equipos existentes de Parachain.
Apéndice: Fragmentación de datos
La mayor parte de este artículo explora la escalabilidad desde el punto de vista de la Fragmentación. También podemos examinar el mismo problema desde una perspectiva de datos. Es interesante descubrir que esto es similar a la situación de semi coherencia mencionada anteriormente: en principio, un sistema completamente coherente es mejor, pero no es escalable; un sistema completamente incoherente es escalable, pero no ideal, mientras que JAM propone una nueva posibilidad con su modelo de semi coherencia.
Sistema totalmente coherente: esto es lo que vemos en plataformas de contratos inteligentes totalmente sincronizadas, como Solana o aquellas valientes que se despliegan únicamente en la capa 1 de Ethereum. Todos los datos de la aplicación se almacenan en la cadena y se puede acceder fácilmente a todas las demás aplicaciones. Esta es una propiedad perfecta programática, pero no escalable.
Sistemas no concordantes: Los datos de la aplicación se almacenan fuera de Layer1 y en Fragmentación separadas e aisladas. Es altamente escalable, pero tiene un rendimiento deficiente en términos de composabilidad. El modelo Rollup de Polkadot y Ethereum pertenece a esta categoría.
Además de proporcionar las dos funciones mencionadas anteriormente, JAM permite a los desarrolladores publicar cualquier dato en la capa JAM DA, lo que es en cierto sentido una zona intermedia entre los datos on-chain y los datos off-chain. Se pueden desarrollar nuevas aplicaciones que utilicen la mayoría de los datos de aplicaciones de la capa DA, al tiempo que solo se persisten en el estado JAM los datos absolutamente críticos.
Apéndice: Gráfico de Espacio de Escalabilidad
Esta sección reinterpreta nuestra visión del campo de la escalabilidad de blockchain. Esto también se explica en el libro gris, aquí se proporciona una versión más concisa.
La escalabilidad de blockchain sigue en gran medida los métodos utilizados en los sistemas distribuidos tradicionales: escalabilidad vertical y escalabilidad horizontal.
La escalabilidad es el trabajo realizado por plataformas como Solana. Logran la máxima capacidad a través de la optimización extrema del código y el hardware.
La expansión hacia afuera es la estrategia adoptada por Ethereum y Polkadot: reducir la carga de trabajo para cada persona. En los sistemas distribuidos tradicionales, esto se logra mediante la adición de más máquinas replicadas. En la Cadena de bloques, los "validadores" son un conjunto de validadores de la red entera. Al asignarles trabajo entre ellos (como lo hace ELVES) o al reducir optimistamente sus responsabilidades (como lo hacen los Rollups optimistas), reducimos la carga de trabajo del conjunto completo de validadores, logrando así la expansión del sistema.
En la cadena de Bloquear, la expansión hacia afuera es similar a 'reducir la cantidad de máquinas necesarias para ejecutar todas las operaciones'.
Resumiendo:
Expansión hacia arriba: hardware de alto rendimiento + optimización de blockchain monolítica.
Ampliación externa:
Rollups optimistas
Rollups basados en SNARK
ELVES: Rollups irónicos de Polkadot (Cynical Rollups)
Apéndice: Actualización del núcleo con el mismo hardware
Esta sección se basa en la analogía proporcionada por Rob Habermeier en Sub02023: Polkadot:Kernel/Userland|Sub02023-YouTube (ver detalles:), que muestra JAM como una actualización para Polkadot: una actualización del núcleo en el mismo hardware.
En una computadora típica, podemos dividir toda la pila en tres partes:
Hardware
Núcleo
Espacio del usuario
En Polkadot, el hardware, es decir, la esencia que proporciona la computación y la disponibilidad de datos, ha sido fundamental (cores), como se ha mencionado anteriormente.
En Polkadot, el núcleo en realidad es[9]Hasta ahora, consta de dos partes:
1.parachain（Parachains）protocolo: una forma de uso específica y fija del núcleo de opinión.
Un conjunto de funciones básicas, como DOT Token y su transferibilidad, stake, gobernanza, etc.
Ambos existen en la cadena de retransmisión (Relay Chain) de Polkadot.
Las aplicaciones de espacio de usuario son instancias de parachains, sus tokens nativos y otros contenidos construidos sobre ellas.
Podemos visualizar este proceso de la siguiente manera:
Polkadot siempre ha imaginado trasladar más funciones principales a sus usuarios de parachain. Este es precisamente el objetivo que persigue el RFC de Relay Mínimo. (Ver detalles en: )
Esto significa que la cadena de retransmisión de Polkadot solo maneja la provisión de parachainprotocolo, lo que en cierta medida reduce el espacio del núcleo.
Una vez que se logra esta arquitectura, es más fácil visualizar cómo sería 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 Parachains se moverá al espacio del usuario, ya que es una de las pocas formas en las que se pueden escribir aplicaciones en el mismo núcleo (hardware) y kernel (JAM).
Esto también vuelve a demostrar por qué JAM es solo un sustituto de la cadena de retransmisión de Polkadot en lugar de un sustituto de la parachain.
En otras palabras, podemos considerar la migración de JAM como una actualización del núcleo. El hardware subyacente permanece sin cambios, y la mayor parte del contenido del antiguo núcleo se traslada al espacio de usuario para simplificar el sistema.
Si desea participar en la discusión de este artículo, no dude en expresar su opinión en el foro:
Para obtener información sobre cómo participar en las discusiones del foro, consulte nuestra Guía de uso del foro de Polkadot lanzada por nosotros: 01928374656574839201
Cómo participar en las discusiones de Polkadot: una guía para usar el foro oficial de Polkadot
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Revelando la JAM de Polkadot desde una perspectiva técnica
Escrito por: Kian Paimani, Desarrollador principal de Parity
Compilación: Polkadot Labs
"El 'Polkadot Knowledge Graph' es nuestro artículo introductorio desde cero para Polkadot. Intentamos comenzar desde lo más básico de Polkadot, proporcionando a todos una comprensión integral del contenido de Polkadot. Por supuesto, esto es un gran desafío, pero esperamos que a través de este esfuerzo, todos puedan comprender correctamente Polkadot y que las personas que no lo conocen puedan familiarizarse rápidamente con el conocimiento relacionado con Polkadot. Hoy es el número 148 de esta sección, y este artículo es una interpretación técnica del protocolo JAM recientemente propuesto por Kian Paimani, un desarrollador principal de Parity, para ayudar a las personas a comprender mejor cómo JAM puede aportar nueva escalabilidad al ecosistema de Polkadot. Este artículo está escrito desde el punto de vista del autor en primera persona.
*A continuación se detalla la explicación de Polkadot1, Polkadot2 y cómo evolucionan hacia JAM. (Para más detalles, consulte: ****) Este artículo está dirigido a lectores técnicos, especialmente aquellos que no están muy familiarizados con Polkadot pero tienen cierto conocimiento de los sistemas de blockchain, y posiblemente a lectores que estén familiarizados con tecnologías relacionadas con otros ecosistemas.
*Creo que es una buena introducción leer este artículo antes de leer el libro gris de JAM. (Ver detalles: ***)
Conocimiento de fondo
Este artículo asume que el lector está familiarizado con los siguientes conceptos:
Introducción: Polkadot1
Primero, repasemos lo que considero la característica más innovadora de Polkadot1.
A nivel social:
En el nivel técnico:
Para obtener más información sobre 'Fragmentación heterogénea', consulte los capítulos correspondientes.
Ejecución de Fragmentación: Puntos clave del núcleo
Actualmente estamos discutiendo una red de Layer1 que actúa como un custodio para otras redes de Layer2 'blockchain', similar a Polkadot y Ethereum. Por lo tanto, los términos Layer2 y Parachain pueden intercambiarse.
El problema central de la escalabilidad de la cadena Bloquear se puede expresar como la existencia de un grupo de validadores que pueden garantizar la ejecución confiable de cierto código a través de la economía criptográfica de la Prueba de Participación (Proof-of-Stake). Por defecto, estos validadores necesitan volver a ejecutar todo el trabajo entre ellos. Por lo tanto, si obligamos a todos los validadores a volver a ejecutar todo en todo momento, el sistema completo no será escalable.
Tenga en cuenta que el aumento de la cantidad de validadores en este modelo no aumentará realmente el rendimiento del sistema siempre y cuando se mantenga inalterable el principio absoluto de reejecución mencionado anteriormente.
Lo que se muestra arriba es una cadena de bloques monolítica (en contraposición a una cadena de bloques fragmentada). Todos los validadores de la red procesarán las entradas (es decir, bloques) uno por uno.
En un sistema de este tipo, si Layer1 desea alojar más Layer2, entonces todos los validadores deben volver a ejecutar todo el trabajo de Layer2. Obviamente, este enfoque no es escalable. Los rollups optimistas son una forma de evitar este problema, ya que solo se vuelve a ejecutar cuando alguien reclama que ha ocurrido una prueba de fraude. Los rollups basados en SNARK evitan este problema al aprovechar el hecho de que el costo de verificar una prueba de SNARK es mucho menor que generarla, lo que permite que todos los validadores verifiquen que la prueba de SNARK es válida. Para obtener más información al respecto, consulte 'Anexo: Gráfico del espacio de escalabilidad'.
Una solución simple para la fragmentación es simplemente dividir el conjunto de validadores en subconjuntos más pequeños y hacer que estos subconjuntos más pequeños vuelvan a ejecutar el Bloquear de la capa 2. ¿Cuál es el problema con este enfoque? Estamos fragmentando la seguridad de la ejecución y la economía de la red de esta manera. La seguridad de la capa 2 es inferior a la de la capa 1, y a medida que dividimos el conjunto de validadores en más fragmentos, su seguridad disminuirá aún más.
A diferencia de los rollups optimistas que no pueden volver a ejecutar los costos de manera consistente, Polkadot considera la fragmentación en su diseño, lo que permite a algunos validadores volver a ejecutar Bloquear de Layer2, al mismo tiempo que proporciona suficiente evidencia económica de cripto a todos los participantes de la red para demostrar la autenticidad de este Bloquear de Layer2, tan seguro como cuando todo el conjunto de validadores lo vuelve a ejecutar. Esto se logra a través de un mecanismo novedoso (recientemente lanzado oficialmente) ELVES. (Ver detalles: )
En pocas palabras, ELVES puede considerarse como un mecanismo de "rollups escépticos". Preguntando a otros validadores si un Bloqueo de Layer2 es válido o no, podemos confirmar la validez del Bloqueo de Layer2 con una alta probabilidad. De hecho, en caso de cualquier disputa, pronto se pedirá la participación de toda la colección de validadores. Rob Habermeier, cofundador de Polkadot, lo explica en detalle en un artículo. (Ver para más detalles:)
ELVES permite que Polkadot tenga dos propiedades que antes se consideraban mutuamente excluyentes: 'Fragmentación ejecutiva' y 'seguridad compartida'. Este es uno de los principales logros técnicos de Polkadot en cuanto a escalabilidad.
Ahora, continuemos discutiendo la analogía de "CORE".
Una cadena de Bloquear que ejecuta Fragmentación es muy similar a una CPU: al igual que la CPU puede tener núcleos que ejecutan instrucciones en paralelo, Polkadot puede procesar en paralelo las Layer2 Bloquear. Por eso las Layer2 en Polkadot se llaman parachain, y el entorno en el que un subconjunto más pequeño de validadores vuelve a ejecutar un solo Layer2 Bloquear se llama "CORE". Cada CORE se puede abstraer como "un grupo de validadores que trabajan en conjunto".
Puedes pensar en una cadena de bloques de un solo bloque como tomar solo un bloque en cualquier período de tiempo, mientras que Polkadot toma un bloque de la cadena de repetidores y un bloque de la cadena paralela de cada núcleo en cada período de tiempo.
Heterogeneidad
Hasta ahora, solo hemos discutido la escalabilidad y la ejecución de Fragmentación que Polkadot proporciona. Es importante tener en cuenta que cada Fragmentación de Polkadot es en realidad una aplicación completamente diferente. Esto se logra mediante el uso de un protocolo de elemento almacenado en bytecode: un protocolo que define la cadena de bloques se almacena como bytecode en el estado mismo de la cadena de bloques. En Polkadot 1.0, se utilizó WASM como bytecode preferido, mientras que en JAM se adoptó PVM/RISC-V.
En resumen, esto es por qué Polkadot se llama una cadena de bloques de fragmentación heterogénea. (Ver más detalles: ) Cada Capa 2 es una aplicación completamente diferente.
Polkadot2
Una parte importante de Polkadot2 es hacer que el uso del núcleo sea más flexible. En el modelo original de Polkadot, el plazo del núcleo puede variar de 6 meses a 2 años, lo cual es adecuado para empresas con recursos abundantes, pero no es adecuado para equipos pequeños. Las características del núcleo ágil, que permiten un uso más flexible de Polkadot, se conocen como 'agile coretime'. En este modo, el plazo del núcleo de Polkadot puede ser tan corto como un Bloquear o tan largo como un mes, y ofrece una garantía de precio máximo para aquellos usuarios que deseen alquilar a largo plazo.
Otras características de Polkadot 2 están empezando a mostrarse gradualmente en el proceso que estamos discutiendo, por lo que no es necesario extenderse demasiado aquí.
Operaciones internas y on-chain del núcleo
Para entender JAM, primero necesitamos entender qué sucede cuando un Bloquear de Layer2 ingresa al núcleo de Polkadot.
El siguiente contenido ha sido simplificado en gran medida.
En resumen, el núcleo está compuesto principalmente por un grupo de validadores. Por lo tanto, cuando decimos 'los datos se envían al núcleo', en realidad nos referimos a que estos datos se transmiten a este grupo de validadores.
Un bloque Layer2 junto con una parte de su estado se envía al núcleo. Estos datos contienen toda la información necesaria para ejecutar el bloque Layer2.
Parte de los validadores en el núcleo volverán a ejecutar Layer2 Bloquear y continuarán procesando tareas relacionadas con Consenso.
Los validadores principales volverán a proporcionar los datos necesarios a otros validadores (fuera del núcleo principal). Los otros validadores pueden decidir según las reglas de ELVES si volver a ejecutar el bloqueador de Layer2 y necesitan estos datos para hacerlo.
Ten en cuenta que hasta el momento, todas las operaciones se han llevado a cabo fuera del bloque principal y las funciones de cambio de estado de Polkadot. Todo ocurre en el núcleo interno y en la capa de disponibilidad de datos.
A partir del contenido anterior, podemos explorar algunas de las operaciones que está realizando Polkadot:
En primer lugar, desde el paso 1 podemos concluir que Polkadot tiene una forma de ejecución novedosa diferente a la función de transición de estado de la cadena de bloques tradicional. Normalmente, cuando todos los validadores en la red realizan un trabajo, el estado principal de la cadena se actualiza. Llamamos a esta situación operación on-chain (operación on-chain), que es lo que sucede en el paso 3. Sin embargo, lo que ocurre internamente en el núcleo (paso 1) es diferente. Llamamos a este nuevo cálculo de la cadena interna in-core ution.
A continuación, a partir del punto 2, podemos inferir que Polkadot ha proporcionado una capa de disponibilidad de datos nativa (Data-Availability, en adelante DA) y que Layer2 la utiliza automáticamente para asegurar que su prueba de ejecución esté disponible durante un cierto período de tiempo. Sin embargo, los bloques de datos que se pueden publicar en esta capa de DA son fijos y siempre son pruebas necesarias para volver a ejecutar Layer2. Además, el código de la parachain nunca lee datos de la capa de DA.
Entender el contenido anterior es la base para entender JAM. Resumiendo:
En el núcleo: se refiere a las operaciones que se producen dentro del núcleo. Se caracteriza por ser rico, escalable y logra la misma seguridad que la ejecución on-chain a través de Crypto economics y ELVES.
MERMELADA
Con base en la comprensión de la primera parte, podemos pasar sin problemas a la introducción de JAM.
JAM es un nuevo protocolo diseñado inspirado en Polkadot y completamente compatible con él, con el objetivo de reemplazar la cadena de relé de Polkadot y hacer que el uso centralizado y sin restricciones sea completamente descentralizado.
JAM se construye sobre Polkadot2 con el objetivo de hacer que el núcleo de Polkadot sea más accesible, pero de una manera más flexible y sin restricciones fijas en comparación con agile-coretime.
Esto se logra principalmente mediante la exposición a los desarrolladores de los tres conceptos principales discutidos anteriormente: ejecución en la cadena, ejecución interna del núcleo y capa DA.
En otras palabras, en JAM, los desarrolladores pueden acceder a:
Esta es una descripción básica del objetivo JAM. No es necesario decir más, se han realizado muchas simplificaciones aquí, y el protocolo podría seguir evolucionando.
Con esta comprensión básica, ahora podemos explorar más a fondo algunos detalles de JAM en los próximos capítulos.
1 Servicio y Elemento de Trabajo
En el contexto de JAM, lo que solía llamarse Layer2/parachain ahora se llama "Servicio", y lo que solía llamarse Bloquear/ transacción ahora se llama "Ítem de trabajo" o "Paquete de trabajo". Específicamente, un ítem de trabajo pertenece a un servicio, mientras que un paquete de trabajo es una colección de ítems de trabajo. Estos términos están diseñados intencionalmente para ser lo suficientemente generales como para abarcar una variedad de casos de uso que van más allá de la cadena Bloquear/Layer2.
Un servicio está descrito por tres puntos de entrada, dos de los cuales son fn refine() y fn accumulate(). El primero describe el contenido ejecutado en el núcleo del servicio, y el segundo describe el contenido ejecutado on-chain.
Finalmente, el nombre de los dos puntos de entrada también es la razón por la que se llama JAM (Join Accumulate Machine) al protocolo. Join se refiere a fn refine(), cuando todos los núcleos de Polkadot procesan en paralelo una gran cantidad de trabajo de diferentes servicios, esta etapa se llama Join. Una vez que los datos han sido filtrados, pasan a la siguiente etapa. Accumulate se refiere al proceso en el que todos los resultados anteriores se acumulan en el estado principal de JAM, es decir, la parte de ejecución on-chain.
Los elementos de trabajo pueden especificar con precisión qué código ejecutar en el núcleo, on-chain, y cómo / si / desde dónde leer / escribir contenido en el Lago de Datos Distribuido (Distributed Data Lake).
2 Semi-consistencia
Al revisar la información existente sobre XCM (el lenguaje de comunicación de parachain elegido por Polkadot), se observa que todas las comunicaciones son asíncronas. Esto significa que una vez que se envía un mensaje, no se puede esperar una respuesta. (Consulte los detalles en:)
La asincronía es la manifestación de la inconsistencia del sistema, y es la principal desventaja de los sistemas de Fragmentación permanentes (como Polkadot 1 y Polkadot 2 y el ecosistema Layer2 existente de Ethereum).
Sin embargo, como se describe en la sección 2.4 del libro blanco, un sistema completamente coherente que siempre mantiene sincronizados a todos sus inquilinos solo puede subir hasta cierto punto sin sacrificar universalidad, accesibilidad o flexibilidad. (Ver detalles en: )
Sincronización ≈ consistencia||Incoherencias ≈ asincrónicas
Este es otro campo en el que JAM se destaca: al introducir múltiples características, JAM logra un nuevo estado intermedio, es decir, un sistema de semi-consistencia. En este sistema, los subsistemas que se comunican con frecuencia tienen la oportunidad de crear un entorno coherente entre sí sin obligar al sistema completo a mantener la coherencia. Esto se describe mejor en la entrevista del Dr. Gavin Wood, autor del libro gris (ver detalles en: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ).
Otra forma de entender a Polkadot / JAM es como un sistema de Fragmentación, donde los límites de estas Fragmentaciones son fluidos y se determinan de manera dinámica.
Polkadot siempre ha sido Fragmentación, y completamente heterogéneo.
Ahora, será fragmentado, heterogéneo, y los límites de estos fragmentos pueden ser flexiblemente determinados, tal como Gavin Wood lo llamó en Twitter, un sistema de "semi-consistencia". (Ver detalles en: _src=twsrc%5Etfw)
Las características que hacen posible todo esto incluyen:
Acceder a la ejecución central sin estado y paralela, donde los diferentes servicios solo pueden interactuar de forma sincrónica con otros servicios en el mismo bloquear específico y en el mismo núcleo, así como la ejecución on-chain, donde los servicios pueden acceder a los resultados de todos los servicios en todos los núcleos.
JAM no impone ninguna programación de servicio específica. Los servicios de comunicación frecuente pueden proporcionar incentivos económicos a sus ordenadores de servicio y crear paquetes de trabajo que contengan estos servicios de comunicación frecuente. Esto permite que estos servicios se ejecuten en el mismo núcleo y que la comunicación entre ellos sea similar a la que se produce en un entorno sincrónico.
Además, el servicio JAM puede acceder a la capa de datos DA y usarla como una forma temporal pero extremadamente económica de Capa de datos. Una vez que los datos se colocan en DA, eventualmente se propagarán a todos los núcleos, pero estarán disponibles de inmediato en el mismo núcleo. Por lo tanto, el servicio JAM puede programarse en el mismo núcleo en bloques consecutivos para disfrutar de un mayor acceso a los datos.
Es importante tener en cuenta que aunque lo anterior es posible en JAM, no se aplica obligatoriamente en la capa de protocolo. Por lo tanto, se espera que algunas interfaces sean teóricamente asíncronas, pero mediante una abstracción ingeniosa y medidas de incentivo, pueden parecer sincrónicas en la práctica. La siguiente sección discutirá CorePlay como ejemplo de esto.
3 CorePlay
En esta sección se presenta CorePlay, una idea experimental en el entorno JAM que se puede describir como un nuevo modelo de programación de Contratos inteligentes. Hasta la fecha de redacción de este artículo, CorePlay aún no se ha detallado y sigue siendo una idea.
Para entender CorePlay, primero necesitamos presentar la Máquina virtual elegida por JAM: PVM.
4 PVM
PVM es un detalle importante en JAM y CorePlay. Los detalles a nivel inferior de PVM están más allá del alcance de este documento, es mejor consultar la descripción en el libro blanco de expertos en el campo. Sin embargo, para las necesidades de este documento, solo necesitamos explicar algunas propiedades de PVM:
Esto es especialmente importante para CorePlay.
CorePlay es un ejemplo de cómo usar el lenguaje JAM para crear un entorno de contratos inteligentes sincronizado y escalable, con una interfaz de programación muy flexible. CorePlay sugiere desplegar directamente los contratos inteligentes basados en actores en el núcleo de JAM, lo que les permite disfrutar de una interfaz de programación síncrona, donde se pueden escribir como el fn main() normal, y comunicarse a través de let_result=other_coreplay_actor(data).await?. Si other_coreplay_actor está en el mismo núcleo de Bloquear de JAM, esta llamada es sincrónica; si está en otro núcleo, el actor se pausará y se reanudará en Bloquear subsiguiente de JAM. Esto es posible gracias a los servicios de JAM y su programación flexible, así como a las propiedades de PVM.
Servicios de 5 CoreChains
Por último, resumamos las principales razones por las que se menciona que JAM es completamente compatible con Polkadot. El producto principal de Polkadot es Parachains, que se ejecuta en modo de tiempo central ágil, y este producto se extiende en JAM.
Los servicios desplegados por primera vez en JAM podrían denominarse CoreChains o Parachains. Este servicio permitirá que las parachains existentes de estilo Polkadot -2 se ejecuten en JAM.
Los servicios adicionales se pueden implementar en JAM y los servicios existentes de CoreChains pueden comunicarse con ellos, pero los productos existentes de Polkadot seguirán siendo fuertes y solo abrirán nuevas puertas para los equipos existentes de Parachain.
Apéndice: Fragmentación de datos
La mayor parte de este artículo explora la escalabilidad desde el punto de vista de la Fragmentación. También podemos examinar el mismo problema desde una perspectiva de datos. Es interesante descubrir que esto es similar a la situación de semi coherencia mencionada anteriormente: en principio, un sistema completamente coherente es mejor, pero no es escalable; un sistema completamente incoherente es escalable, pero no ideal, mientras que JAM propone una nueva posibilidad con su modelo de semi coherencia.
Sistema totalmente coherente: esto es lo que vemos en plataformas de contratos inteligentes totalmente sincronizadas, como Solana o aquellas valientes que se despliegan únicamente en la capa 1 de Ethereum. Todos los datos de la aplicación se almacenan en la cadena y se puede acceder fácilmente a todas las demás aplicaciones. Esta es una propiedad perfecta programática, pero no escalable.
Sistemas no concordantes: Los datos de la aplicación se almacenan fuera de Layer1 y en Fragmentación separadas e aisladas. Es altamente escalable, pero tiene un rendimiento deficiente en términos de composabilidad. El modelo Rollup de Polkadot y Ethereum pertenece a esta categoría.
Además de proporcionar las dos funciones mencionadas anteriormente, JAM permite a los desarrolladores publicar cualquier dato en la capa JAM DA, lo que es en cierto sentido una zona intermedia entre los datos on-chain y los datos off-chain. Se pueden desarrollar nuevas aplicaciones que utilicen la mayoría de los datos de aplicaciones de la capa DA, al tiempo que solo se persisten en el estado JAM los datos absolutamente críticos.
Apéndice: Gráfico de Espacio de Escalabilidad
Esta sección reinterpreta nuestra visión del campo de la escalabilidad de blockchain. Esto también se explica en el libro gris, aquí se proporciona una versión más concisa.
La escalabilidad de blockchain sigue en gran medida los métodos utilizados en los sistemas distribuidos tradicionales: escalabilidad vertical y escalabilidad horizontal.
La escalabilidad es el trabajo realizado por plataformas como Solana. Logran la máxima capacidad a través de la optimización extrema del código y el hardware.
La expansión hacia afuera es la estrategia adoptada por Ethereum y Polkadot: reducir la carga de trabajo para cada persona. En los sistemas distribuidos tradicionales, esto se logra mediante la adición de más máquinas replicadas. En la Cadena de bloques, los "validadores" son un conjunto de validadores de la red entera. Al asignarles trabajo entre ellos (como lo hace ELVES) o al reducir optimistamente sus responsabilidades (como lo hacen los Rollups optimistas), reducimos la carga de trabajo del conjunto completo de validadores, logrando así la expansión del sistema.
En la cadena de Bloquear, la expansión hacia afuera es similar a 'reducir la cantidad de máquinas necesarias para ejecutar todas las operaciones'.
Resumiendo:
Apéndice: Actualización del núcleo con el mismo hardware
Esta sección se basa en la analogía proporcionada por Rob Habermeier en Sub02023: Polkadot:Kernel/Userland|Sub02023-YouTube (ver detalles:), que muestra JAM como una actualización para Polkadot: una actualización del núcleo en el mismo hardware.
En una computadora típica, podemos dividir toda la pila en tres partes:
Hardware
Núcleo
Espacio del usuario
En Polkadot, el hardware, es decir, la esencia que proporciona la computación y la disponibilidad de datos, ha sido fundamental (cores), como se ha mencionado anteriormente.
En Polkadot, el núcleo en realidad es[9]Hasta ahora, consta de dos partes:
1.parachain（Parachains）protocolo: una forma de uso específica y fija del núcleo de opinión.
Ambos existen en la cadena de retransmisión (Relay Chain) de Polkadot.
Las aplicaciones de espacio de usuario son instancias de parachains, sus tokens nativos y otros contenidos construidos sobre ellas.
Podemos visualizar este proceso de la siguiente manera:
Polkadot siempre ha imaginado trasladar más funciones principales a sus usuarios de parachain. Este es precisamente el objetivo que persigue el RFC de Relay Mínimo. (Ver detalles en: )
Esto significa que la cadena de retransmisión de Polkadot solo maneja la provisión de parachainprotocolo, lo que en cierta medida reduce el espacio del núcleo.
Una vez que se logra esta arquitectura, es más fácil visualizar cómo sería 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 Parachains se moverá al espacio del usuario, ya que es una de las pocas formas en las que se pueden escribir aplicaciones en el mismo núcleo (hardware) y kernel (JAM).
Esto también vuelve a demostrar por qué JAM es solo un sustituto de la cadena de retransmisión de Polkadot en lugar de un sustituto de la parachain.
En otras palabras, podemos considerar la migración de JAM como una actualización del núcleo. El hardware subyacente permanece sin cambios, y la mayor parte del contenido del antiguo núcleo se traslada al espacio de usuario para simplificar el sistema.
Si desea participar en la discusión de este artículo, no dude en expresar su opinión en el foro:
Para obtener información sobre cómo participar en las discusiones del foro, consulte nuestra Guía de uso del foro de Polkadot lanzada por nosotros: 01928374656574839201
Cómo participar en las discusiones de Polkadot: una guía para usar el foro oficial de Polkadot