Revelando o JAM da Polkadot do ponto de vista técnico

Kian Paimani, desenvolvedor principal da Parity, interpreta o protocolo JAM proposto pela Polkadot do ponto de vista técnico, para ajudar as pessoas a entenderem melhor como o JAM traz uma nova escalabilidade ao ecossistema da Polkadot.

Escrito por: Kian Paimani, Desenvolvedor Principal da Parity

Compilação: Polkadot Labs

*** "Graph de conhecimento do Polkadot" *** é um artigo de introdução que criamos do zero para o Polkadot. Tentamos começar pelo básico do Polkadot e fornecer uma compreensão abrangente do conteúdo para todos. Claro, este é um projeto enorme e cheio de desafios, mas esperamos que, através desse esforço, as pessoas possam entender o Polkadot corretamente e permitir que aqueles que não estão familiarizados com o Polkadot possam aprender rapidamente sobre o conhecimento relacionado ao Polkadot. *** Hoje é a 148ª edição desta seção e este artigo é uma interpretação técnica do protocolo JAM, a mais recente proposta do Polkadot, feita pelo desenvolvedor principal da Parity, Kian Paimani. Isso ajudará as pessoas a entenderem melhor como o JAM traz nova escalabilidade para o ecossistema do Polkadot. Este artigo é escrito na perspectiva do autor em primeira pessoa. ***

*Aqui está uma explicação detalhada do Polkadot1, Polkadot2 e como eles evoluem para JAM. (Veja mais detalhes em: ****) Este artigo é destinado a leitores técnicos, especialmente aqueles que não estão muito familiarizados com Polkadot, mas têm algum conhecimento sobre sistemas de blockchain e podem estar familiarizados com tecnologias relacionadas a outros ecossistemas.

*Eu acredito que ler este artigo é um bom prelúdio antes de ler o whitepaper da JAM. (Ver detalhes em: ***)

Conhecimento de fundo

Este artigo pressupõe que o leitor esteja familiarizado com os seguintes conceitos:

Descrever a Blockchain como uma função de transição de estado.
Compreender o que é um "estado". (Consulte: _sdk_docs/reference_docs/blockchain_state_machines/index.html para mais detalhes)
Segurança econômica e Prova de Participação. (Para mais detalhes, consulte: ,)

Introdução: Polkadot1

Primeiro, vamos rever o que eu considero como a característica mais inovadora do Polkadot1.

Nível social:

Polkadot é uma grande Organização Autónoma Descentralizada (DAO). A rede realiza governança totalmente baseada na cadeia, autoexecutável, incluindo atualizações de tempo de execução sem necessidade de forquilha.
A Comissão de Valores Mobiliários dos Estados Unidos (SEC) considera DOT como software, não como um valor mobiliário. (Veja mais em: )
A maior parte do trabalho de desenvolvimento de rede é realizado pela Polkadot Fellowship (consulte: 01928374656574839201) e não por empresas financiadas (como a Parity:).

Nível técnico:

Polkadot implementa segurança compartilhada e execução de Fragmentação.
Usando o protocolo baseado em WASM (consulte: _sdk_docs/reference_docs/wasm_meta_protocol/index.html), armazena o código da blockchain como bytecode no estado. Isso permite que a maioria das atualizações seja feita sem a necessidade de forquilha e também permite a Fragmentação heterogênea.

Para obter mais informações sobre "Fragmentação" heterogênea, consulte os capítulos relevantes.

Execução da Fragmentação: Pontos-chave

Atualmente, estamos discutindo uma rede Layer1 que hospeda outras redes Layer2 "blockchain", semelhante ao Polkadot e Ethereum. Portanto, os termos Layer2 e Parachain podem ser usados indistintamente.

O problema central com a escalabilidade da cadeia Bloco pode ser formulado da seguinte forma: existe um conjunto de validadores que podem garantir que a execução de determinado código é confiável através da criptoeconomia da Prova de Stake. Por padrão, esses validadores precisam executar novamente todo o trabalho uns dos outros. Assim, enquanto forçarmos todos os validadores a sempre reexecutar tudo, todo o sistema não é escalável.

Por favor, note que aumentar a quantidade de validadores neste modelo não aumentará verdadeiramente a capacidade de throughput do sistema, desde que os princípios de reexecução absolutos acima permaneçam inalterados.

A cima é mostrada uma cadeia de Bloco única (em oposição à cadeia de Bloco de Fragmentação). Todos os validadores de rede processarão as entradas (ou seja, Bloco) uma por uma.

Neste sistema, se a Layer1 quiser hospedar mais camadas Layer2, todos os validadores terão de reexecutar todo o trabalho da Layer2. Claramente, este método não é escalável. Os rollups otimistas são uma forma de contornar esse problema, pois só é necessário reexecutar (prova de fraude) quando alguém alega fraude. Os rollups baseados em SNARK contornam este problema ao aproveitar o facto de que o custo de verificação de uma prova SNARK é muito inferior ao custo de gerá-la, permitindo assim que todos os validadores verifiquem as provas SNARK. Para mais informações sobre este assunto, consulte o 'Apêndice: Espaço Escalável'.

Uma solução simples para a Fragmentação é simplesmente dividir o conjunto de validadores em subconjuntos menores e fazer com que esses subconjuntos menores reexecutem o Bloco Layer2. Qual é o problema com este método? Estamos fragmentando a execução e a segurança econômica da rede. A segurança do Layer2 é menor do que a do Layer1 e, à medida que dividimos o conjunto de validadores em mais Fragmentação, sua segurança diminuirá ainda mais.

Ao contrário dos rollups otimistas que não podem ser reexecutados de forma consistente, o Polkadot considerou a fragmentação na conceção, permitindo que alguns validadores reexecutem o Bloco da Camada 2, fornecendo evidências econômicas de criptografia suficientes para provar a autenticidade do Bloco da Camada 2, tão seguras quanto quando reexecutadas pelo conjunto completo de validadores. Isso é alcançado através de um mecanismo inovador (recentemente lançado) ELVES. (Veja mais em: )

Em resumo, ELVES pode ser visto como um mecanismo de 'rollups' de suspeita. Ao perguntar ativamente a outros validadores em várias rodadas se um determinado Bloco Layer2 é válido, podemos confirmar com grande probabilidade a validade desse Bloco Layer2. De fato, em caso de qualquer disputa, será rapidamente exigido que todo o conjunto de validadores participe. Rob Habermeier, co-fundador da Polkadot, explicou detalhadamente este ponto num artigo. (Ver detalhes em: )

ELVES permite que Polkadot tenha duas propriedades que antes eram consideradas mutuamente exclusivas: 'Execução de Fragmentação' e 'Segurança Compartilhada'. Este é o principal resultado técnico do Polkadot1 em termos de escalabilidade.

Agora, continuemos a discussão sobre a analogia do "CORE".

Uma cadeia de blocos que executa Fragmentação é muito semelhante a uma CPU: assim como a CPU pode ter vários núcleos executando instruções em paralelo, o Polkadot pode processar em paralelo os Blocos da Camada 2. É por isso que a Camada 2 no Polkadot é chamada de parachain, e o ambiente no qual um subconjunto menor de validadores reexecuta um único Bloco da Camada 2 é chamado de "core". Cada core pode ser abstraído como "um conjunto de validadores cooperantes".

Você pode imaginar a cadeia de bloco individual como capturando apenas um bloco em qualquer período de tempo, enquanto o Polkadot captura um bloco de cadeia de retransmissão e um bloco de cadeia paralela para cada núcleo em cada período de tempo.

Heterogeneidade

Até agora, só discutimos a escalabilidade e a execução de Fragmentação fornecidas pelo Polkadot. É digno de nota que cada Fragmentação do Polkadot é na verdade um aplicativo totalmente diferente. Isso é alcançado usando o protocolo armazenado em bytecode: um protocolo que define a cadeia de blocos armazenada como bytecode no próprio estado da cadeia de blocos. No Polkadot 1.0, o WASM é usado como bytecode preferido, enquanto no JAM, o PVM/RISC-V é adotado.

Em resumo, é por isso que o Polkadot é chamado de blockchain de fragmentação heterogênea. (Veja detalhes em: ) Cada Layer2 é um aplicativo completamente diferente.

Polkadot2

Uma parte importante do Polkadot2 é tornar o uso do núcleo mais flexível. No modelo original do Polkadot, o período de locação do núcleo pode variar de 6 meses a 2 anos, o que é adequado para empresas ricas em recursos, mas não é tão adequado para pequenas equipes. As características do núcleo do Polkadot que podem ser usadas de forma mais flexível são chamadas de "tempo de núcleo ágil". Nesse modo, o período de locação do núcleo do Polkadot pode ser tão curto quanto um Bloco, ou até mesmo um mês, e oferece um limite de preço para os usuários que desejam alugar a longo prazo. (Veja mais em: )

Outras características do Polkadot 2 estão gradualmente se revelando à medida que são discutidas, portanto não há necessidade de entrar em muitos detalhes aqui.

Operações internas do núcleo e na cadeia

Para entender o JAM, primeiro é necessário compreender o que acontece quando um Bloco Layer2 entra no núcleo do Polkadot.

O seguinte conteúdo foi amplamente simplificado.

Para recapitular, o núcleo é composto principalmente por um grupo de validadores. Portanto, quando dizemos que 'os dados são enviados para o núcleo', na verdade estamos nos referindo a esses dados que são transmitidos a esse grupo de validadores.

Um bloco Layer2 adicionado a uma parte do estado desse Layer2 é enviado para o núcleo. Esses dados contêm todas as informações necessárias para executar o bloco Layer2.
Alguns validadores do núcleo irão reexecutar o Bloco Layer2 e continuar a processar tarefas relacionadas ao Consenso.
Os validadores principais irão reexecutar os dados necessários para os outros validadores (os validadores fora do núcleo). Os outros validadores podem decidir, de acordo com as regras do ELVES, se devem reexecutar o Bloco Layer2 e precisam destes dados para completar esta operação.

Tenha em mente que até agora todas as operações foram realizadas fora do bloco principal e das funções de transição de estado do Polkadot. Tudo acontece internamente no núcleo e na camada de disponibilidade de dados.

Finalmente, uma pequena parte do estado mais recente do Layer2 será visível na cadeia de retransmissão principal da Polkadot. Ao contrário de todas as operações anteriores, esta operação é muito mais barata do que executar novamente o Bloco Layer2 real, ela afetará o estado principal da Polkadot, será visível no Bloco da Polkadot e será executada por todos os validadores da Polkadot.

A partir do conteúdo acima, podemos explorar algumas das operações que Polkadot está realizando:

Em primeiro lugar, a partir do passo 1, podemos concluir que Polkadot tem um novo estilo de execução diferente da função tradicional de transição de estado da blockchain. Normalmente, quando todos os validadores na rede realizam um trabalho, o estado principal da blockchain é atualizado. Chamamos a isso uma operação na cadeia (on-chain operation), que é o que acontece no passo 3. No entanto, o que acontece internamente no CORE (passo 1) é diferente. Chamamos a este novo tipo de computação blockchain de execução interna (in-core ution).

A seguir, a partir do ponto 2, podemos deduzir que a Polkadot já forneceu uma camada nativa de disponibilidade de dados (Data-Availability, doravante designada por DA) e que a Layer2 a utiliza automaticamente para garantir que as suas provas de execução estejam disponíveis por um período de tempo. No entanto, os blocos de dados que podem ser publicados para esta camada DA são fixos e sempre consistem em provas necessárias para a reexecução do Bloco Layer2. Além disso, o código da parachain nunca lê os dados da camada DA.

Compreender o conteúdo acima é a base para entender JAM. Resumo abaixo:

CORE内执行（in-core execution）：Refere-se às operações que ocorrem internamente no CORE. Suas características são ricas, extensíveis e implementadas com a mesma segurança na cadeia através da economia cripto e do ELVES.
na cadeia执行（on-chain ution）：指所有validadores执行的操作。通过经济保障的validadores默认获得安全性，但成本更高且限制更多，因为所有人都在执行所有操作。
数据可用性（Data Availability）：波卡validadores在一定时间内承诺一些数据的可用性，并向其他validadores提供这些数据的能力。

JAM

Com a compreensão da primeira parte, podemos fazer uma transição suave para a introdução de JAM.

JAM é um novo protocolo inspirado pelo Polkadot e totalmente compatível com ele, destinado a substituir as correntes de retransmissão do Polkadot e tornar o uso principal completamente descentralizado e ilimitado.

JAM is built on top of Polkadot2, aiming to make the core of Polkadot more accessible, but in a more flexible and unrestricted way than agile-coretime.

O Polkadot2 permite uma implantação mais flexível da Layer2 no núcleo.
O objetivo do JAM é permitir que qualquer aplicação seja implantada no núcleo do Polkadot, mesmo que essas aplicações não sejam como blockchains ou Layer2.

Isso é principalmente realizado expondo aos desenvolvedores as três principais concepções primárias discutidas anteriormente: execução on-chain, execução interna central e camada de DA.

Em outras palavras, no JAM, os desenvolvedores podem ter acesso a:

Trabalho completamente programável no núcleo e na cadeia.
Permite que quaisquer dados sejam lidos e escritos na camada DA do Polkadot.

Esta é uma descrição básica do objetivo JAM. Sem necessidade de muitas palavras, muitas simplificações foram feitas aqui, e o protocolo pode ainda sofrer evoluções.

Com esta compreensão básica, podemos agora explorar mais alguns detalhes sobre JAM nos próximos capítulos.

1 Serviço e Itens de Trabalho

Com o JAM, o que costumava ser chamado de Layer2/parachain agora é chamado de 'Serviço', enquanto o que costumava ser chamado de Bloco/Transação agora é chamado de 'ITEM de trabalho' ou 'Pacote de trabalho'. Em termos concretos, um ITEM de trabalho pertence a um serviço, enquanto um Pacote de trabalho é uma coleção de ITENS de trabalho. Esses termos foram intencionalmente projetados para serem suficientemente genéricos para cobrir casos de uso que vão além da Blockchain/Layer2.

Um serviço é descrito por três pontos de entrada, dois dos quais são fn refine() e fn accumulate(). O primeiro descreve o que o serviço faz no núcleo, o segundo descreve o que o serviço faz na cadeia.

Por fim, o nome dos dois pontos de entrada também é chamado de protocolo JAM (Join Accumulate Machine). Join, também conhecido como fn refine(), é a fase em que todo o trabalho pesado de diferentes serviços do Polkadot Core é processado em paralelo. Os dados são filtrados e passam para a próxima fase. Accumulate refere-se ao processo de acumulação de todos os resultados mencionados acima no estado principal do JAM, ou seja, na parte executada na cadeia.

Os trabalhos podem especificar com precisão o que eles executam no núcleo, na cadeia, e indicam como / se / de onde ler ou escrever o conteúdo no Lago de Dados Distribuído (Distributed Data Lake).

2 Consistência Parcial

Ao rever a documentação existente sobre XCM (a linguagem de comunicação parachain escolhida pelo Polkadot), fica claro que todas as comunicações são assíncronas. Isso significa que, depois de enviar uma mensagem, não é possível esperar por uma resposta. (consulte: )

A assincronia é uma manifestação da inconsistência do sistema e é a principal desvantagem dos sistemas permanentes de fragmentação (como Polkadot 1 e Polkadot 2 e o ecossistema Layer2 existente do Ethereum).

No entanto, como descrito na secção 2.4 do Livro Branco, um sistema completamente consistente, que mantém sempre todos os seus inquilinos sincronizados, só pode subir até certo ponto sem sacrificar universalidade, acessibilidade ou elasticidade. (Consulte: )

Sincronização ≈ Consistência || Assincronização ≈ Inconsistência

Esta é outra área em que o JAM se destaca: ao introduzir diversas funcionalidades, o JAM alcança um novo estado intermediário, ou seja, um sistema de semi-consistência. Neste sistema, os subsistemas de comunicação frequente têm a oportunidade de criar um ambiente consistente entre si, sem forçar a consistência do sistema inteiro. Esta foi a melhor descrição feita pelo Dr. Gavin Wood, autor do white paper, durante uma entrevista (ver detalhes em: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ)

Outra forma de entender é ver o Polkadot / JAM como um sistema de Fragmentação, onde as fronteiras dessas Fragmentações são fluidas e dinamicamente determinadas.

Polkadot tem sido Fragmentação desde o início e é completamente heterogêneo.

Agora, será fragmentado e heterogêneo, e as fronteiras desses fragmentos podem ser flexivelmente determinadas, como Gavin Wood chama de sistema "semi-consistente" no Twitter. (Veja mais em: _src=twsrc%5Etfw、)

As características que tornam tudo isto possível incluem:

Acesso a execução central sem estado e paralela, onde diferentes serviços só podem interagir sincronizadamente com outros serviços no mesmo núcleo e bloco específico, e execução na cadeia, onde os serviços podem aceder aos resultados de todos os serviços em todos os núcleos.
O JAM não impõe nenhuma programação de serviço específica. Os serviços de comunicação frequente podem fornecer incentivos econômicos para seus classificadores, criando pacotes de trabalho que incluem esses serviços de comunicação frequente. Isso permite que esses serviços sejam executados no mesmo núcleo, com a comunicação entre eles ocorrendo como se estivessem em um ambiente síncrono.
Além disso, o serviço JAM pode acessar a camada de dados e usá-la como uma camada de dados temporária, mas extremamente barata. Uma vez que os dados são colocados na camada de dados, eles acabam sendo propagados para todos os blocos, mas estão imediatamente disponíveis no mesmo bloco. Portanto, o serviço JAM pode agendar a si mesmo em blocos consecutivos no mesmo bloco para desfrutar de um maior acesso aos dados.

É importante notar que, embora o conteúdo acima seja possível em JAM, não é obrigatório na camada de protocolo. Portanto, espera-se que algumas interfaces sejam teoricamente assíncronas, mas, por meio de abstrações engenhosas e incentivos, podem se manifestar como síncronas na prática. A próxima seção discutirá o CorePlay, que é um exemplo disso.

3 CorePlay

Esta seção descreve o CorePlay, uma ideia experimental no ambiente JAM, que pode ser descrita como um novo modelo de programação de contratos inteligentes. No momento da redação deste documento, o CorePlay ainda não foi detalhadamente explicado e permanece apenas uma concepção.

Para entender o CorePlay, primeiro precisamos apresentar a Máquina virtual escolhida pela JAM: PVM.

4 PVM

PVM é um detalhe importante no JAM e CorePlay. Os detalhes de baixo nível do PVM estão além do escopo deste artigo, é melhor verificar a descrição no white paper feita por especialistas do campo. No entanto, para as necessidades deste artigo, só precisamos explicar algumas propriedades do PVM:

Medição eficiente
Capacidade de suspensão e retoma da execução

Isso é especialmente importante para a CorePlay.

CorePlay é um exemplo de ambiente de Contrato Inteligente sincronizado e escalável, criado usando a linguagem JAM e suas primitivas flexíveis, com uma interface de programação altamente flexível. CorePlay sugere implantar Contratos Inteligentes baseados em atores diretamente no núcleo JAM, permitindo que eles aproveitem as interfaces de programação sincronizadas, onde podem ser programados como um fn main() normal e se comunicar usando let_result=other_coreplay_actor(data).await?. Se other_coreplay_actor estiver no mesmo bloco do núcleo JAM, essa chamada será síncrona; se estiver em outro núcleo, o ator será suspenso e retomado em blocos JAM subsequentes. Isso é possível graças aos serviços JAM e ao seu agendamento flexível, bem como às propriedades do PVM.

5 Serviços CoreChains

Por fim, vamos resumir as principais razões pelas quais JAM é totalmente compatível com Polkadot. O principal produto da Polkadot é a parachain, que é executada de forma ágil no núcleo do tempo, e este produto é continuado no JAM.

Os primeiros serviços implantados no JAM provavelmente serão chamados de CoreChains ou Parachains. Este serviço permitirá que os parachains existentes no estilo Polkadot -2 sejam executados no JAM.

Serviços adicionais podem ser implantados no JAM e os serviços CoreChains existentes podem se comunicar com eles, mas os produtos existentes da Polkadot permanecerão fortes, apenas abrindo novas portas para as equipes de Parachain existentes.

Apêndice: Fragmentação de dados

A maior parte deste artigo explora a escalabilidade a partir da perspectiva da Fragmentação. Também podemos examinar o mesmo problema a partir da perspectiva dos dados. É interessante notar que isso é semelhante às situações de consistência parcial mencionadas anteriormente: idealmente, um sistema totalmente consistente é melhor, mas não é escalável; um sistema totalmente inconsistente é escalável, mas não ideal, e JAM propõe uma nova possibilidade com seu modelo de consistência parcial.

Sistema de Consistência Total: É o que vemos em plataformas como Solana, que estão totalmente sincronizadas com contratos inteligentes ou aquelas que corajosamente implantam apenas na camada 1 do Ethereum. Todos os dados do aplicativo são armazenados na cadeia e podem ser facilmente acessados por todos os outros aplicativos. Isso é uma propriedade perfeita programática, mas não é escalável.

Inconsistência no sistema: Os dados do aplicativo são armazenados fora da Camada 1 e em Fragmentação separada e isolada. Isso é altamente escalável, mas tem um desempenho ruim em termos de composição. Modelos de Rollup como Polkadot e Ethereum se enquadram nessa categoria.

JAM Além de fornecer as duas funcionalidades acima, também permite que os desenvolvedores publiquem quaisquer dados na camada JAM DA, que em certa medida é uma zona intermediária entre os dados na cadeia e os dados fora da cadeia. Novos tipos de aplicativos podem ser desenvolvidos que utilizam a maioria dos dados de aplicativos na camada DA, ao mesmo tempo que apenas persistem os dados absolutamente críticos no estado JAM.

Apêndice: Gráfico de Espaço de Escalabilidade

Esta seção redefine nossa visão do campo da escalabilidade blockchain. Isso também é explicado no livro branco, aqui está uma versão mais concisa.

A escalabilidade da blockchain segue em grande parte os métodos utilizados nos sistemas distribuídos tradicionais: escalabilidade vertical e horizontal.

Expandir para cima é o que plataformas como Solana estão a fazer. Através da otimização extrema do código e do hardware para alcançar a máxima capacidade de processamento.

A expansão externa é a estratégia adotada pelo Ethereum e Polkadot: reduzir a carga de trabalho de cada pessoa. Em sistemas distribuídos tradicionais, isso é feito aumentando o número de máquinas replicadas. Na cadeia de Blocos, os 'computadores' são o conjunto de validadores de toda a rede. Ao distribuir o trabalho entre eles (como feito pelos ELVES), ou ao reduzir otimisticamente suas responsabilidades (como feito pelos Rollups otimistas), reduzimos a carga de trabalho de todo o conjunto de validadores, alcançando assim a expansão externa do sistema.

Na cadeia de blocos, a escalabilidade é semelhante a "reduzir a quantidade de máquinas necessárias para executar todas as operações".

Resumo:

Expansão para cima: otimização de hardware de alto desempenho + blockchain monolítica.
Expansão externa:
Rollups otimistas
Rollups baseados em SNARK
ELVES: A ironia do Polkadot Rollups (Rollups Cínicos)

Apêndice: Mesmo hardware, atualização do kernel

Esta secção, baseada na analogia fornecida por Rob Habermeier em Sub02023, mostra a atualização do JAM como um upgrade para o Polkadot: uma atualização do kernel no mesmo hardware.

Em um computador típico, podemos dividir a pilha inteira em três partes:

hardware
núcleo
Espaço do Usuário

Em Polkadot, o hardware, que é essencial para fornecer computação e disponibilidade de dados, tem sido fundamental (núcleos), como já mencionado anteriormente.

No Polkadot, o núcleo é na verdade[9]Até agora incluiu duas partes:

parachain (Parachains) protocolo: uma maneira de opinião e uso centralizados e fixos.
Um conjunto de funcionalidades básicas, como DOT Token e sua transferibilidade, stake, governança, etc.

Ambos estão presentes na relay chain (Relay Chain) do Polkadot.

As aplicações de espaço de usuário são exemplos de parachains, seus Token nativos e outros conteúdos construídos sobre eles.

Podemos visualizar esse processo da seguinte forma:

波卡一直设想将更多的核心功能移至其一类用户——parachain。这正是 Minimal Relay RFC 旨在实现的目标。（详情请参见：）

Isto significa que a relay chain do Polkadot apenas lida com a disponibilização de parachainprotocolo, reduzindo assim, em certa medida, o espaço do núcleo.

Uma vez que essa arquitetura seja implementada, será mais fácil visualizar como seria a migração do JAM. O JAM reduzirá significativamente o espaço do núcleo do Polkadot, tornando-o mais geral. Além disso, o protocolo Parachains será movido para o espaço do usuário, pois essa é uma das poucas maneiras de escrever aplicativos no mesmo hardware e kernel (JAM) central.

Isto também volta a mostrar por que a JAM é apenas uma alternativa à relay chain do Polkadot, e não uma alternativa à parachain.

Em outras palavras, podemos ver a migração do JAM como uma atualização do núcleo. O hardware subjacente permanece inalterado, e a maior parte do conteúdo do núcleo antigo é movido para o espaço do usuário para simplificar o sistema.