A seguir, uma explicação detalhada de Polkadot1, Polkadot2 e como evoluíram para JAM. (Para mais detalhes, consulte: https://www.navalmanack.com/almanack-of-naval-ravikant/how-to-think-clearlyEste artigo é destinado a leitores técnicos, especialmente aqueles que podem não estar profundamente familiarizados com Polkadot, mas têm algum conhecimento de sistemas blockchain e provavelmente estão familiarizados com tecnologias de outros ecossistemas.
Acredito que este artigo sirva como um bom precursor para ler o JAM Gray Paper. (Para mais detalhes, consulte:https://graypaper.com/)

Conhecimento de fundo

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

• Descrevendo blockchain como uma função de transição de estado.
• Compreender o que significa "estado". (Para mais detalhes, veja: https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/blockchain_state_machines/index.html)
• Segurança econômica e prova de participação. (Para mais detalhes, consulte: https://polkadot-blockchain-academy.github.io/pba-book/economics/economics-of-polkadot/page.html#staking-concept,https://www.youtube.com/watch?v=suyram9vaFc)

Introdução: Polkadot1

Vamos primeiro revisitar os recursos mais inovadores do Polkadot1.

Aspectos Sociais:

• Polkadot é uma organização autônoma descentralizada (DAO) massiva. A rede implementa governança totalmente on-chain e autoexecutável, incluindo atualizações de tempo de execução sem fork.
• A SEC reconheceu DOT como software, não como um valor mobiliário. (Para mais detalhes, veja: https://polkadot.com/newsroom/press-releases/web3-foundation-anuncia-que-o-token-nativo-da-blockchain-da-polkadot-dot-mudou-e-e-um-software-nao-um-titulo-de-seguranca)
• A maior parte do trabalho de desenvolvimento na rede é tratada pela Bolsa Polkadot (Para mais detalhes, consulte:https://polkadot-fellows.github.io/dashboard/) em vez da Parity Technologies, uma empresa que apoia financeiramente o projeto (https://www.parity.io/).

Aspectos Técnicos:

• Polkadot implementou segurança compartilhada e execução em fragmentos.
• Usando um metaprotocolo baseado em WASM (Para mais detalhes, consulte:https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/wasm_meta_protocol/index.html) o código da blockchain é armazenado no estado como bytecode. Isso permite que a maioria das atualizações ocorra sem bifurcações e possibilita o particionamento heterogêneo. (Consulte as seções relevantes para obter mais informações sobre o 'particionamento heterogêneo'.)

Execução Fragmentada: Pontos Chave

Atualmente, estamos discutindo uma rede de Camada 1 que hospeda outras redes de "blockchain" de Camada 2, semelhantes a Polkadot e Ethereum. Portanto, os termos Layer 2 e Parachain podem ser usados de forma intercambiável.

O problema central da escalabilidade da blockchain pode ser formulado como: Há um conjunto de validadores que, usando a criptoeconomia de prova de participação, garante que a execução de determinados códigos é confiável. Por padrão, esses validadores precisam reexecutar todo o trabalho uns dos outros. Desde que imponhamos que todos os validadores sempre reexecutem tudo, o sistema inteiro permanece não escalável.

Por favor, note que, desde que o princípio da reexecução absoluta permaneça inalterado, aumentar o número de validadores neste modelo na verdade não melhora a capacidade do sistema.

Isso demonstra uma blockchain monolítica (em oposição a uma em fragmentos). Todos os validadores de rede processam as entradas (ou seja, blocos) um por um. Em tal sistema, se a Camada 1 deseja hospedar mais Camadas 2, então todos os validadores devem reexecutar todo o trabalho das Camadas 2. Claramente, esse método não é escalável.

Rollups otimistas abordam esse problema re-executando (provas de fraude) apenas quando a fraude é afirmada. Rollups baseados em SNARK abordam esse problema aproveitando o fato de que o custo de validar provas de SNARK é significativamente menor do que o custo de gerá-las, permitindo assim que todos os validadores verifiquem eficientemente as provas de SNARK. Para mais detalhes, consulte o “Apêndice: Diagrama do Espaço de Escalabilidade.”

Uma solução direta para a fragmentação é dividir o conjunto de validadores em subconjuntos menores e fazer com que esses subconjuntos menores reexecutem os blocos da Camada2. Quais são os problemas dessa abordagem? Estamos essencialmente fragmentando tanto a execução quanto a segurança econômica da rede. Uma solução de Camada2 tem menor segurança em comparação com a Camada1, e sua segurança diminui ainda mais à medida que dividimos o conjunto de validadores em mais fragmentos.

Ao contrário dos rollups otimistas, onde os custos de reexecução nem sempre podem ser evitados, o Polkadot foi projetado tendo em mente a execução fragmentada. Ele permite que uma parte dos validadores reexecute blocos da Camada 2, fornecendo evidências criptoeconômicas suficientes à rede inteira para provar que o bloco da Camada 2 é tão seguro quanto se o conjunto completo de validadores o tivesse reexecutado. Isso é alcançado por meio de um mecanismo inovador (e recentemente formalizado) conhecido como ELVES. (Para mais detalhes, consulte: https://eprint.iacr.org/2024/961)

Em resumo, ELVES pode ser visto como um mecanismo de “rollups suspeitos”. Através de várias rodadas de validadores consultando ativamente outros validadores sobre se um determinado bloco da Camada 2 é válido, podemos confirmar com alta probabilidade a validade do bloco. Em caso de qualquer disputa, o conjunto completo de validadores é rapidamente envolvido. O co-fundador da Polkadot, Rob Habermeier, explicou isso detalhadamente em um artigo. (Para mais detalhes, consulte: https://polkadot.com/blog/polkadot-v1-0-sharding-and-economic-security#approval-checking-and-finality)

ELVES permitem que o Polkadot possua tanto execução fragmentada quanto segurança compartilhada, duas propriedades que anteriormente se pensava serem mutuamente exclusivas. Esta é a principal conquista técnica do Polkadot1 em termos de escalabilidade.

Agora, avancemos com a analogia do 'Core'. Um blockchain de execução fragmentada é muito parecido com uma CPU: assim como uma CPU pode ter múltiplos núcleos executando instruções em paralelo, o Polkadot pode processar blocos da Camada 2 em paralelo. É por isso que a Camada 2 no Polkadot é chamada de parachain, e o ambiente onde subconjuntos menores de validadores reexecutam um único bloco da Camada 2 é chamado de 'core'. Cada core pode ser abstraído como 'um grupo de validadores cooperantes'.

Você pode pensar em um blockchain monolítico como processando um único bloco por vez, enquanto o Polkadot processa tanto um bloco de corrente de retransmissão quanto um bloco de paracorrente para cada núcleo no mesmo período de tempo.

Heterogeneidade

Até agora, só discutimos escalabilidade e execução segmentada oferecida pelo Polkadot. É importante notar que cada um dos fragmentos do Polkadot é, na verdade, uma aplicação completamente diferente. Isso é alcançado através do metaprotocolo armazenado como bytecode: um protocolo que armazena a definição da própria blockchain como bytecode em seu estado. No Polkadot 1.0, o WASM é usado como bytecode preferido, enquanto no JAM, o PVM/RISC-V é adotado.

É por isso que Polkadot é referido como um blockchain heterogêneo com shard. (Para mais detalhes, veja:https://x.com/kianenigma/status/1790763921600606259) Cada Camada 2 é uma aplicação completamente diferente.

Polkadot2

Um aspecto importante do Polkadot2 é tornar o uso de núcleos mais flexível. No modelo Polkadot original, os períodos de leasing principal variavam de 6 meses a 2 anos, o que se adequava a empresas ricas em recursos, mas era menos viável para equipes menores. O recurso que permite que os núcleos Polkadot sejam usados de forma mais flexível é chamado de "Agile Coretime". (Para obter mais detalhes, consulte:https://polkadot.com/agile-coretime) Neste modo, os termos básicos do contrato podem ser tão curtos quanto um único bloco ou tão longos quanto um mês, com um limite de preço para aqueles que desejam alugar por períodos mais longos.

Os outros recursos do Polkadot 2 estão sendo gradualmente revelados à medida que nossa discussão avança, então não há necessidade de elaborar mais sobre eles aqui.

Operações In-Core vs On-Chain

Para entender JAM, é importante primeiro compreender o que acontece quando um bloco da Camada 2 entra no núcleo do Polkadot. A seguir, uma explicação simplificada.

Lembre-se de que um núcleo consiste principalmente em um conjunto de validadores. Portanto, quando dizemos que "os dados são enviados para o núcleo," significa que os dados são passados para este conjunto de validadores.

1. Um bloco da Camada 2, juntamente com parte do estado dessa Camada 2, é enviado para o núcleo. Esses dados contêm todas as informações necessárias para executar o bloco da Camada 2.

2. Uma parte dos validadores principais irá reexecutar o bloco da Camada 2 e continuar com as tarefas relacionadas ao consenso.

3. Esses validadores principais fornecem os dados reexecutados para outros validadores fora do núcleo. De acordo com as regras dos ELVES, esses validadores podem decidir se devem ou não reexecutar o bloco da Camada 2, precisando desses dados para fazê-lo.

É importante notar que, até agora, todas essas operações estão acontecendo fora do bloco principal do Polkadot e da função de transição de estado. Tudo ocorre dentro do núcleo e da camada de disponibilidade de dados.

1. Finalmente, uma pequena parte do estado mais recente da Camada 2 torna-se visível na cadeia principal de relé da Polkadot. Ao contrário das operações anteriores, este passo é muito mais barato do que reexecutar o bloco da Camada 2 e afeta o estado principal da Polkadot. É visível em um bloco da Polkadot e é executado por todos os validadores da Polkadot.

A partir disso, podemos explorar algumas operações-chave que o Polkadot está realizando:

• A partir do Passo 1, podemos concluir que a Polkadot introduziu um novo tipo de execução, diferente das funções de transição de estado tradicionais do blockchain. Normalmente, quando todos os validadores da rede executam uma tarefa, o estado principal do blockchain é atualizado. Isso é o que chamamos execução on-chain, e é o que acontece no Passo 3. No entanto, o que acontece dentro do núcleo (Passo 1) é diferente. Essa nova forma de computação em blockchain é referida como execução interna.
• Do Passo 2, inferimos que Polkadot tem uma nativa Disponibilidade de Dados (DA)camada, e as camadas 2 utilizam-na automaticamente para garantir que a evidência da sua execução permaneça disponível por um certo período. No entanto, os blocos de dados que podem ser enviados para a camada DA são fixos, contendo apenas a evidência necessária para a reexecução da Camada 2. Além disso, o código da paracadeia não lê os dados da camada DA.

Compreender isso forma a base para entender JAM. Aqui está um resumo:

• Execução In-Core: Refere-se a operações que ocorrem dentro do núcleo. Essas operações são ricas, escaláveis e seguras por meio de criptoeconomia e ELVES, oferecendo a mesma segurança que a execução on-chain.
• Execução On-Chain: Refere-se às operações executadas por todos os validadores. Estas são garantidas economicamente para serem seguras por padrão, mas são mais caras e restritas, uma vez que todos realizam todas as tarefas.
• Disponibilidade de Dados: Refere-se à capacidade dos validadores do Polkadot de garantir a disponibilidade de certos dados por um período de tempo e fornecê-los a outros validadores.

JAM

Com esta compreensão, agora podemos introduzir JAM.

JAM é um novo protocolo inspirado no design da Polkadot e totalmente compatível com ele, com o objetivo de substituir a cadeia de retransmissão da Polkadot e tornar o uso central totalmente descentralizado e irrestrito.

Construído sobre o Polkadot 2, JAM se esforça para tornar o deployment de Camadas 2 no núcleo mais acessível, oferecendo ainda mais flexibilidade do que o modelo agile-coretime.

• Polkadot 2 permite que a implantação da Camada 2 no núcleo seja mais dinâmica.
• JAM tem como objetivo permitir que qualquer aplicativo seja implantado no núcleo do Polkadot, mesmo que esses aplicativos não sejam estruturados como blockchains ou Camadas 2.

Isso é alcançado principalmente expondo os três conceitos principais discutidos anteriormente aos desenvolvedores: execução on-chain, execução in-core e a camada DA.

Em outras palavras, em JAM, os desenvolvedores podem:

• Programar totalmente tarefas tanto no núcleo quanto na cadeia.
• Leia e escreva na camada DA da Polkadot com dados arbitrários.

Esta é uma visão geral básica dos objetivos da JAM. Desnecessário dizer que grande parte disso foi simplificada, e o protocolo provavelmente continuará a evoluir.

Com essa compreensão fundamental, agora podemos nos aprofundar em alguns dos detalhes do JAM nos próximos capítulos.

Serviços e Itens de Trabalho

Em JAM, o que antes era chamado de camada 2 ou parachains agora é chamado deServiços, e o que antes eram chamados de blocos ou transações agora são chamados deItens de TrabalhoouPacotes de trabalhoEspecificamente, um item de trabalho pertence a um serviço, e um pacote de trabalho é uma coleção de itens de trabalho. Esses termos são intencionalmente amplos para cobrir casos de uso além de cenários de blockchain/Layer 2.

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 durante a execução em núcleo, e o último descreve o que ele faz durante a execução em cadeia.

Finalmente, os nomes desses pontos de entrada são a razão pela qual o protocolo é chamado JAM (Join Accumulate Machine).Participarrefere-se arefinar(), que é a fase em que todos os núcleos Polkadot processam um grande volume de trabalho em paralelo em diferentes serviços. Depois que os dados são processados, eles avançam para a próxima etapa.Acumularrefere-se ao processo de acumular todos esses resultados no estado principal JAM, que ocorre durante a fase de execução on-chain.

Os itens de trabalho podem especificar precisamente o código que executam in-core e on-chain, bem como como, se e de onde leem ou escrevem conteúdo no Distributed Data Lake.

Semi-Consistência

Revisando a documentação existente sobre XCM (linguagem selecionada da Polkadot para comunicação entre parachains), toda a comunicação é assíncrona (para mais detalhes, consulteaqui). Isso significa que uma vez que uma mensagem é enviada, você não pode esperar por sua resposta. A comunicação assíncrona é um sintoma de inconsistência no sistema e uma das principais desvantagens de sistemas permanentemente fragmentados como Polkadot 1, Polkadot 2 e os ecossistemas existentes da Camada 2 do Ethereum.

No entanto, como descrito na Seção 2.4 doGraypaper, um sistema totalmente consistente que permanece síncrono para todos os seus inquilinos só pode escalar até certo ponto sem sacrificar universalidade, acessibilidade ou resiliência.

• Síncrono ≈ Consistência || Assíncrono ≈ Inconsistência

Aqui é onde JAM se destaca: ao introduzir várias características, JAM alcança um estado intermediário inovador conhecido como um sistema semi-consistente. Neste sistema, subsistemas que se comunicam com frequência podem criar um ambiente consistente entre si, sem forçar o sistema inteiro a permanecer consistente. Isso foi melhor descrito pelo Dr. Gavin Wood, autor do Graypaper, em uma entrevista: https://www.youtube.com/watch?t=1378&v=O3kRAVBTkfs&embeds_referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ

Outra maneira de entender isso é visualizando Polkadot/JAM como um sistema shardado, onde as fronteiras entre esses shards são fluidas e dinamicamente determinadas.

Polkadot sempre foi shardado e totalmente heterogêneo.

Agora, não é apenas fragmentado e heterogêneo, mas esses limites de fragmentação podem ser definidos de forma flexível - o que Gavin Wood se refere como um sistema "semi-consistente" em seus tweets e no Graypaper. (ver: https://x.com/gavofyork?ref_src=twsrc%5Etfw、https://graypaper.com/)

Várias características tornam possível esse estado semi-consistente:

1. Acesso à execução em paralelo sem estado, onde diferentes serviços só podem interagir de forma síncrona com outros serviços dentro do mesmo núcleo e bloco específico, bem como à execução on-chain, onde os serviços podem acessar resultados de todos os serviços em todos os núcleos.
2. O JAM não impõe nenhum agendamento de serviço específico. Serviços com comunicação frequente podem fornecer incentivos econômicos aos seus agendadores para criar pacotes de trabalho contendo esses serviços que se comunicam com frequência. Isso permite que esses serviços sejam executados no mesmo núcleo, fazendo com que suas interações pareçam síncronas, mesmo que estejam distribuídas.
3. Além disso, os serviços JAM podem acessar a camada DA e usá-la como uma camada de dados temporária, porém extremamente econômica. Uma vez que os dados são colocados na DA, eles eventualmente se propagam para todos os núcleos, mas estão imediatamente disponíveis dentro do mesmo núcleo. Portanto, os serviços JAM podem alcançar um grau maior de acesso aos dados agendando-se dentro do mesmo núcleo em blocos consecutivos.

É importante notar que, embora essas capacidades sejam possíveis dentro do JAM, elas não são aplicadas no nível do protocolo. Como resultado, algumas interfaces são teoricamente assíncronas, mas podem funcionar de forma síncrona na prática devido a abstrações sofisticadas e incentivos. CorePlay, que será discutido na próxima seção, é um exemplo desse fenômeno.

CorePlay

Esta seção apresenta o CorePlay, um conceito experimental no ambiente JAM que pode ser descrito como um novo modelo de programação de contratos inteligentes. No momento da escrita, o CorePlay ainda não foi totalmente definido e permanece uma ideia especulativa.

Para entender o CorePlay, primeiro precisamos apresentar a máquina virtual (VM) escolhida pela JAM: o PVM.

PVM

PVM é um detalhe chave tanto em JAM quanto em CorePlay. Os detalhes de nível inferior do PVM estão além do escopo deste documento e são melhor explicados por especialistas de domínio no Graypaper. No entanto, para esta explicação, destacaremos algumas atributos-chave do PVM:

• Medição eficiente
• A capacidade de pausar e retomar a execução

Este último é especialmente crucial para CorePlay.

CorePlay é um exemplo de como os primitivos flexíveis da JAM podem ser usados para criar um ambiente de contrato inteligente síncrono e escalável com uma interface de programação altamente flexível. CorePlay propõe que os contratos inteligentes baseados em atores sejam implantados diretamente nos núcleos JAM, permitindo que se beneficiem de interfaces de programação síncronas. Os desenvolvedores podem escrever contratos inteligentes como se fossem funções simples fn main(), usando expressões como let resultado = other_coreplay_actor(data).await?comunicar. Seoutro ator principal da Coreplayestá no mesmo núcleo JAM no mesmo bloco, essa chamada é síncrona. Se estiver em outro núcleo, o ator será pausado e retomado em um bloco JAM subsequente. Isso é possível graças aos serviços JAM, sua programação flexível e às capacidades do PVM.

Serviço CoreChains

Finalmente, vamos resumir a razão principal pela qual JAM é totalmente compatível com Polkadot. O produto principal da Polkadot são suas paracorrentes ágeis de coretime, que continuam no JAM. Os serviços implantados mais cedo no JAM provavelmente serão chamados de CoreChains ou Parachains, permitindo que as paracorrentes no estilo Polkadot-2 existentes sejam executadas no JAM.

Mais serviços podem ser implantados no JAM, e o serviço CoreChains existente pode se comunicar com eles. No entanto, os produtos atuais da Polkadot permanecerão robustos, simplesmente abrindo novas portas para as equipes de parachain existentes.

Apêndice: Fragmentação de Dados

A maior parte deste documento discute escalabilidade do ponto de vista do shard de execução. No entanto, também podemos examinar essa questão do ponto de vista do shard de dados. Curiosamente, descobrimos que isso é semelhante ao modelo semi-consistente mencionado anteriormente. Em princípio, um sistema totalmente consistente é superior, mas não escalável, enquanto um sistema totalmente inconsistente escala bem, mas é subótimo. JAM, com seu modelo semi-consistente, apresenta uma nova possibilidade.

• Sistemas Totalmente Coerentes: Estas são plataformas onde tudo está sincronizado, como Solana ou aquelas exclusivamente implantadas na Camada 1 do Ethereum. Todos os dados do aplicativo são armazenados on-chain e facilmente acessíveis por todos os outros aplicativos. Isso é ideal do ponto de vista da programabilidade, mas não é escalável.
• Sistemas Inconsistentes: Os dados do aplicativo são armazenados fora da Camada 1 ou em fragmentos diferentes e isolados. Isso é altamente escalável, mas tem um desempenho ruim em termos de composabilidade. Os modelos de rollup da Polkadot e Ethereum se enquadram nessa categoria.

O JAM oferece algo além dessas duas opções: permite que os desenvolvedores publiquem dados arbitrários na camada DA do JAM, que serve como um meio-termo entre dados on-chain e off-chain. Novas aplicações podem ser construídas que aproveitam a camada DA para a maioria de seus dados, enquanto persistem apenas dados absolutamente críticos no estado do JAM.

Apêndice: Paisagem de escalabilidade

Esta seção revisita nossa perspectiva sobre a escalabilidade do blockchain, que também é discutida no Graypaper, embora apresentada aqui de forma mais concisa.

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

A escalabilidade vertical é o que plataformas como Solana se concentram, maximizando o throughput otimizando tanto o código quanto o hardware até seus limites.

A escalabilidade horizontal é a estratégia adotada pelo Ethereum e Polkadot: reduzindo a carga de trabalho que cada participante precisa lidar. Em sistemas distribuídos tradicionais, isso é alcançado adicionando mais máquinas replicadas. Na blockchain, o “computador” é toda a rede de validadores. Ao distribuir tarefas entre eles (como ELVES faz) ou reduzir otimisticamente suas responsabilidades (como em Optimistic Rollups), diminuímos a carga de trabalho para todo o conjunto de validadores, alcançando assim a escalabilidade horizontal.

No blockchain, a escalabilidade horizontal pode ser comparada a "reduzir o número de máquinas que precisam executar todas as operações".

Em resumo:

1. Escalonamento vertical: Hardware de alto desempenho + otimização de blockchains monolíticos.
2. Dimensionamento horizontal:
   • Rollups Otimistas
   • Rollups baseados em SNARK
   • ELVES: Rollups Cínicos de Polkadot

Apêndice: Mesmo Hardware, Atualização do Kernel

Esta seção é baseada na analogia de Rob Habermeier da Sub0 2023: Polkadot: Kernel/Userland | Sub0 2023 - YouTube (see: https://www.youtube.com/watch?v=15aXYvVMxlw) mostrando JAM como uma atualização para Polkadot: uma atualização de kernel no mesmo hardware.

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

1. Hardware
2. Núcleo
3. Espaço do Usuário

No Polkadot, o hardware — a infraestrutura principal que fornece computação e disponibilidade de dados — sempre foi o núcleo, como mencionado anteriormente.

Em Polkadot, o núcleo até agora consistiu de duas partes principais:

1. O Protocolo de Parachains: uma maneira fixa e opinativa de utilizar os núcleos.
2. Um conjunto de funcionalidades de baixo nível, como o token DOT e sua transferibilidade, staking, governança, etc.

Ambos existem na Cadeia de Revezamento do Polkadot.

Aplicações de espaço do usuário, por outro lado, são as parachains em si, seus tokens nativos e qualquer coisa construída em cima delas.

Podemos visualizar este processo da seguinte forma:

Polkadot há muito tempo vislumbrou mover mais funcionalidades principais para seus usuários primários — parachains. Este é precisamente o objetivo do RFC de Revezamento Mínimo. (Para mais detalhes, consulte:Relé Mínimo RFC)

Isso significa que a Cadeia de Relevo do Polkadot só lidaria com o fornecimento do protocolo de parachain, reduzindo assim o espaço do kernel em certa medida.

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

Isso também reforça por que JAM é um substituto para a Cadeia de Revezamento Polkadot, não para parachains.

Em outras palavras, podemos ver a migração do JAM como um upgrade de kernel. O hardware subjacente permanece inalterado e grande parte do conteúdo do kernel antigo é movido para o espaço do usuário para simplificar o sistema.

Disclaimer：

1. Este artigo é reimpresso de [GateInstituto de Pesquisa Ecológica Polkadot], Todos os direitos autorais pertencem ao autor original [Instituto de Pesquisa Ecológica Polkadot]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprendaequipe e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.