A seguir, é apresentada uma explicação detalhada sobre 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 destina-se a leitores técnicos, especialmente aqueles que podem não estar profundamente familiarizados com o 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 Documento Técnico da JAM. (Para mais detalhes, consulte:https://graypaper.com/)

Conhecimentos prévios

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

• Descrever 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 rever as características mais inovadoras do Polkadot1.

Aspectos Sociais:

• Polkadot é uma organização autônoma descentralizada (DAO) massiva. A rede implementa governação totalmente on-chain, auto-executável, incluindo atualizações de tempo de execução sem fork.
• A SEC reconheceu o DOT como software, não como um título. (Para mais detalhes, consulte:https://polkadot.com/newsroom/press-releases/web3-foundation-announces-polkadot-blockchains-native-token-dot-has-morphed-and-is-software-not-a-security)
• A maioria do trabalho de desenvolvimento na rede é tratada pela Bolsa Polkadot (Para mais detalhes, consulte: https://polkadot-fellows.github.io/dashboard/) em vez de pela Parity Technologies, uma empresa que apoia financeiramente o projeto (https://www.parity.io/).

Aspetos Técnicos:

• Polkadot implementou segurança compartilhada e execução shardada.
• 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 forks e permite o shardamento heterogêneo. (Consulte as seções relevantes para obter mais informações sobre o “shardamento 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 Camada 2 e Parachain podem ser usados indistintamente.

A questão central da escalabilidade da blockchain pode ser enquadrada da seguinte forma: Existe um conjunto de validadores que, utilizando a cripto-economia do mecanismo de prova de participação, garante que a execução de determinado código é 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.

Isto demonstra uma blockchain monolítica (em oposição a uma fragmentada). Todos os validadores de rede processam as entradas (ou seja, blocos) um por um. Num sistema assim, se a Camada 1 deseja hospedar mais Camadas 2, então todos os validadores devem reexecutar todo o trabalho das Camadas 2. Claramente, este método não escala.

As rollups otimistas abordam esse problema apenas reexecutando (provas de fraude) quando é reivindicada fraude. Os 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 obter mais detalhes, consulte o “Apêndice: Diagrama do Espaço de Escalabilidade.”

Uma solução direta para o sharding é dividir o conjunto de validadores em subconjuntos menores e fazer com que esses subconjuntos menores reexecutem blocos de Camada2. Quais são os problemas desta abordagem? Estamos essencialmente dividindo 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 shards.

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. Isso 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 suma, 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 de 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 em detalhes 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 execução fragmentada e segurança compartilhada, duas propriedades que anteriormente se pensava serem mutuamente exclusivas. Este é o principal feito técnico do Polkadot1 em escalabilidade.

Agora, avancemos com a analogia do "Core". Um blockchain de execução fragmentada é muito semelhante a uma CPU: assim como uma CPU pode ter vários 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".

Pode-se pensar em uma blockchain monolítica como processando um único bloco de cada vez, enquanto o Polkadot processa tanto um bloco da cadeia de retransmissão quanto um bloco de cadeia paralela para cada núcleo no mesmo período de tempo.

Heterogeneidade

Até agora, apenas discutimos a escalabilidade e a execução em fragmentos 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, é adotado o PVM/RISC-V.

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

Polkadot2

Um dos aspectos importantes do Polkadot2 é tornar o uso dos núcleos mais flexível. No modelo original do Polkadot, os períodos de arrendamento de núcleos variavam de 6 meses a 2 anos, o que se adequava a empresas com recursos, mas era menos viável para equipes menores. A funcionalidade que permite que os núcleos do Polkadot sejam usados de forma mais flexível é chamada de "Agile Coretime." (Para mais detalhes, consulte: https://polkadot.com/agile-coretimeNeste modo, os termos do contrato principal 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 arrendar por períodos mais longos.

As outras características do Polkadot 2 vão sendo reveladas gradualmente à medida que a nossa discussão avança, por isso não é necessário elaborar mais sobre elas aqui.

Operações In-Core vs On-Chain

Para entender JAM, é importante primeiro perceber 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 num conjunto de validadores. Por isso, quando dizemos que os dados são enviados para o núcleo, significa que os dados são passados a este conjunto de validadores.

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

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

3. Estes validadores principais fornecem os dados reexecutados a outros validadores fora do núcleo. De acordo com as regras dos ELVES, estes validadores podem decidir se devem ou não reexecutar o bloco da Camada 2, precisando destes dados para o fazer.

É importante notar que, até agora, todas essas operações estão a acontecer 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 retransmissão 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 num bloco da Polkadot e é executado por todos os validadores da Polkadot.

A partir disto, podemos explorar algumas operações-chave que o Polkadot está a realizar:

• A partir do Passo 1, podemos concluir que a Polkadot introduziu um novo tipo de execução, diferente das funções tradicionais de transição de estado da blockchain. Normalmente, quando todos os validadores da rede realizam uma tarefa, o estado principal da blockchain é atualizado. Isto é 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. Esta nova forma de computação em blockchain é referida como execução em núcleo.
• A partir do Passo 2, inferimos que o Polkadot tem uma Disponibilidade de Dados (DA)camada e as camadas 2s a utilizam 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 parachain não lê os dados da camada DA.

Compreender isso constitui a base para compreender JAM. Aqui está um resumo:

• Execução In-Core: Refere-se a operações que ocorrem dentro do núcleo. Estas operações são ricas, escaláveis e seguras através de criptoeconomia e ELVES, oferecendo a mesma segurança que a execução on-chain.
• Execução na Cadeia: Refere-se a operações executadas por todos os validadores. Estas são garantidas economicamente para serem seguras por padrão, mas são mais dispendiosas e restritas, uma vez que todos executam 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 Polkadot 2, JAM se esforça para tornar o deploy 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 aplicação seja implantada no núcleo do Polkadot, mesmo que essas aplicações não estejam estruturadas como blockchains ou Camadas 2.

Isto é conseguido principalmente expondo os três conceitos principais discutidos anteriormente aos desenvolvedores: execução na cadeia, execução no núcleo e a camada DA.

Em outras palavras, no 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 simplificado e o protocolo provavelmente irá evoluir ainda mais.

Com esta compreensão fundamental, podemos agora aprofundar algumas das especificidades do JAM nos capítulos seguintes.

Serviços e Itens de Trabalho

Em JAM, o que antes era chamado de Camada 2 ou parachains agora é chamadoServiços, e o que antes eram chamados de blocos ou transações agora são chamados deItens de trabalhoouPacotes de Trabalho. Especificamente, um item de trabalho pertence a um serviço e um pacote de trabalho é uma coleção de itens de trabalho. Estes termos são intencionalmente amplos para cobrir casos de uso para além de cenários 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 no núcleo, e o segundo descreve o que faz durante a execução na cadeia.

Finalmente, os nomes destes pontos de entrada são a razão pela qual o protocolo é chamado JAM (Join Accumulate Machine).Junte-serefere-se arefinar(), que é a fase em que todos os núcleos do Polkadot processam um grande volume de trabalho em paralelo em diferentes serviços. Após os dados serem 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 gravam conteúdo no Distributed Data Lake.

Semi-Consistência

Ao rever a documentação existente sobre XCM (linguagem selecionada para a comunicação de parachain da Polkadot), 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 de Camada 2 do Ethereum.

No entanto, como descrito na Seção 2.4 doPapel Cinzento, 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 o JAM se destaca: ao introduzir várias funcionalidades, o JAM alcança um novo estado intermediário conhecido como um sistema semi-consistente. Neste sistema, subsistemas que comunicam frequentemente podem criar um ambiente consistente entre si, sem forçar que todo o sistema permaneça consistente. Isso foi melhor descrito pelo Dr. Gavin Wood, autor do Graypaper, numa 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 forma de entender isto é visualizando Polkadot/JAM como um sistema shardado, onde as fronteiras entre esses shards são fluidas e determinadas dinamicamente.

Polkadot tem sido sempre fragmentado e totalmente heterogéneo.

Agora, não só é 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. (por favor veja:https://x.com/gavofyork?ref_src=twsrc%5Etfw、https://graypaper.com/)

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

1. Acesso à execução in-core paralela e sem monitoração de estado, onde diferentes serviços só podem interagir de forma síncrona com outros serviços dentro do mesmo bloco principal e 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. JAM não impõe nenhum agendamento de serviço específico. Os serviços com comunicação frequente podem fornecer incentivos econômicos aos seus agendadores para criar pacotes de trabalho contendo esses serviços de comunicação frequente. 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ídos.
3. Além disso, os serviços JAM podem aceder à camada DA e utilizá-la como uma camada de dados temporária, mas extremamente eficaz em termos de custos. Uma vez que os dados são colocados na DA, acabam por propagar-se 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 mais elevado de acesso a dados ao programarem-se dentro do mesmo núcleo ao longo de blocos consecutivos.

É importante notar que, embora essas capacidades sejam possíveis dentro de JAM, elas não são aplicadas ao nível do protocolo. Consequentemente, 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 secção, é um exemplo deste 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, CorePlay ainda não foi totalmente definido e continua a ser uma ideia especulativa.

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

PVM

PVM é um detalhe chave tanto em JAM como em CorePlay. Os detalhes de nível inferior de PVM estão fora do âmbito deste documento e são melhor explicados por especialistas de domínio no Graypaper. No entanto, para esta explicação, iremos destacar algumas atributos chave de PVM:

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

O último é especialmente crucial para CorePlay.

CorePlay é um exemplo de como os primitivos flexíveis do 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 do JAM, permitindo-lhes beneficiar de interfaces de programação síncronas. Os desenvolvedores podem escrever contratos inteligentes como se fossem simples funções fn main(), usando expressões como letresultado = outro_ator_de_reproducao_nucleo(dados).await?comunicar. Se other_coreplay_actorestá no mesmo núcleo JAM no mesmo bloco, esta chamada é síncrona. Se estiver noutro núcleo, o ator será pausado e retomado num bloco JAM subsequente. Isto é 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 principal razão pela qual JAM é totalmente compatível com Polkadot. O produto principal da Polkadot são as suas parachains agile-coretime, que continuam em JAM. Os serviços implantados mais cedo em JAM provavelmente serão chamados de CoreChains ou Parachains, permitindo que as parachains no estilo Polkadot-2 existentes operem em JAM.

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

Apêndice: Fragmentação de Dados

A maior parte deste documento discute escalabilidade do ponto de vista do particionamento de execução. No entanto, também podemos examinar esta questão a partir de um ponto de vista de particionamento de dados. Interessantemente, 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, introduz uma nova possibilidade.

• Sistemas Totalmente Coerentes: Estas são plataformas onde tudo está sincronizado, como Solana ou aquelas exclusivamente implementadas na Camada 1 do Ethereum. Todos os dados da aplicação são armazenados on-chain e facilmente acessíveis por todas as outras aplicações. Isto é ideal do ponto de vista da programabilidade, mas não é escalável.
• Sistemas Inconsistentes: Os dados da aplicação são armazenados fora da Camada 1 ou em fragmentos diferentes e isolados. Isso é altamente escalável, mas tem um desempenho fraco em termos de composabilidade. Os modelos de rollup do Polkadot e do Ethereum se enquadram nesta categoria.

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

Apêndice: Paisagem de escalabilidade

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

A escalabilidade da blockchain segue largamente métodos tradicionais dos sistemas distribuídos: escalamento vertical e escalamento horizontal.

O escalonamento vertical é o que plataformas como Solana se concentram, maximizando a taxa de transferência otimizando tanto o código quanto o hardware até aos seus limites.

A escalabilidade horizontal é a estratégia adotada pela 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 de réplica. No blockchain, o “computador” é toda a rede de validadores. Ao distribuir tarefas entre eles (como o ELVES faz) ou reduzir otimisticamente suas responsabilidades (como nos Optimistic Rollups), diminuímos a carga de trabalho para todo o conjunto de validadores, alcançando assim a escalabilidade horizontal.

Na 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. Escala vertical: Hardware de alto desempenho + otimização de blockchains monolíticas.
2. Escalonamento horizontal:
   • Rollups Otimistas
   • Rollups baseados em SNARK
   • ELVES: Rollups Cínicos da Polkadot

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

Esta secçã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 do núcleo no mesmo hardware.

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

1. Hardware
2. Núcleo
3. Espaço do Utilizador

No Polkadot, o hardware - a infraestrutura central que fornece computação e disponibilidade de dados - sempre foi os cores, como mencionado anteriormente.

Em Polkadot, o kernel até agora consistiu em duas partes principais:

1. O Protocolo das 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 Relay Chain da Polkadot.

As aplicações de espaço do utilizador, por outro lado, são as próprias paracadeias, os seus tokens nativos e tudo o que é construído em cima delas.

Podemos visualizar este processo da seguinte forma:

Polkadot há muito tempo tem vislumbrado mover mais funcionalidades centrais para seus usuários primários — parachains. Este é precisamente o objetivo do Minimal Relay RFC. (Para mais detalhes, consulte:RFC de Reenvio Mínimo)

Isto significa que a Polkadot Relay Chain apenas lidaria com a disponibilização do protocolo de parachain, reduzindo assim o espaço do kernel em certa medida.

Uma vez implementada esta arquitetura, será mais fácil visualizar como será a migração para JAM. JAM reduzirá significativamente o espaço do kernel do Polkadot, tornando-o mais versátil. Além disso, o protocolo Parachains passará para o espaço do usuário, sendo uma das poucas maneiras de construir aplicações 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 uma atualização 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.

Aviso legal：

1. Este artigo é reproduzido a partir de [Instituto 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 Learnequipa, e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.