Provas de armazenamento: Alcançando a consciência do estado ao longo do tempo e das cadeias

Introdução

E se você perdesse a memória a cada hora? E você precisa pedir constantemente a alguém que lhe conte o que você fez? Esse é o estado atual dos contratos inteligentes. Em blockchains como o Ethereum, os contratos inteligentes não podem acessar diretamente estados além de 256 blocos. Este problema é ainda mais agravado no ecossistema multicadeia, onde a recuperação e verificação de dados em diferentes camadas de execução é ainda mais difícil.

Em 2020, Vitalik Buterin e Tomasz Stanczak propuseram uma forma de acessar dados ao longo do tempo. Embora o EIP tenha ficado estagnado, a sua necessidade ressurgiu no mundo multi-cadeia centrado no roll-up. Hoje, as provas de armazenamento surgiram como uma fronteira, para dar consciência e memória aos contratos inteligentes.

Acessando dados na cadeia

Existem várias maneiras pelas quais os dapps podem acessar dados e estado. Todas as abordagens exigem que o aplicativo confie em humanos/entidades ou na segurança ou código criptoeconômico e tenha algumas compensações:

Confiança em humanos/entidades:

• Nós de arquivo: os operadores podem executar eles próprios um nó de arquivo ou contar com provedores de serviços de nó de arquivo, como Alchemy ou Infura, para acessar todos os dados desde o bloco Genesis. Eles fornecem todos os mesmos dados que um Full Node, mas também todos os dados históricos do estado de todo o blockchain. Serviços fora da cadeia, como Etherscan e Dune Analytics, usam nós de arquivo para acessar dados na cadeia. Os atores fora da cadeia podem atestar a validade desses dados, e os contratos inteligentes na cadeia podem verificar se os dados foram assinados por um ator/comitê confiável. A integridade dos dados subjacentes não é verificada. Essa abordagem exige que o dapp confie que o provedor de serviços do nó de arquivo está executando a infraestrutura corretamente e sem qualquer intenção maliciosa.

Confie na segurança econômica da criptografia:

• Indexadores: O protocolo de indexação organiza todos os dados no Blockchain, permitindo aos desenvolvedores construir e publicar APIs abertas que os aplicativos podem consultar. Indexadores individuais são operadores de nós que apostam tokens para fornecer serviços de indexação e processamento de consultas. No entanto, podem ocorrer disputas quando os dados fornecidos estão incorretos e o processo de arbitragem pode demorar. Além disso, os dados de indexadores como o The Graph não podem ser utilizados diretamente pela lógica de negócios dos contratos inteligentes e são usados no contexto de análise de dados baseado na web2.
• Oráculos: os provedores de serviços Oracle usam os dados agregados de muitos operadores de nós independentes. O desafio aqui é que os dados disponíveis nos Oráculos podem não ser atualizados com frequência e têm escopo limitado. Oráculos como o Chainlink geralmente mantêm apenas estados específicos, como feeds de preços, e para estados e históricos específicos de aplicativos eles não são viáveis. Além disso, esta abordagem também introduz um certo nível de desvio nos dados e exige confiança nos operadores dos nós.

Código de confiança:

• Variáveis e funções especiais: Blockchains como Ethereum têm variáveis e funções especiais que são usadas principalmente para fornecer informações sobre o blockchain ou são funções utilitárias de uso geral. Só é possível que um contrato inteligente acesse o hash dos 256 blocos mais recentes. Os hashes de bloco não estão disponíveis para todos os blocos por motivos de escalabilidade. Ter acesso a hashes de blocos históricos seria útil, pois poderia permitir a verificação de provas contra eles. Não há código de operação na execução do EVM que permita acesso ao conteúdo de blocos antigos ou ao conteúdo de transações anteriores ou saídas de recebimento, portanto, um nó pode esquecer essas coisas com segurança e ainda ser capaz de processar novos blocos. Este método também está limitado a um único blockchain.

Dados os desafios e limitações destas soluções, há uma clara necessidade de armazenar e fornecer hashes de blocos na cadeia. É aqui que entram as provas de armazenamento. Para entender melhor as provas de armazenamento, vamos dar uma olhada rápida no armazenamento de dados em blockchains.

Armazenamento de dados em blockchain

Um blockchain é um banco de dados público atualizado e compartilhado entre vários computadores em uma rede. Os dados e o estado são armazenados em grupos consecutivos chamados blocos e cada bloco faz referência criptográfica ao seu pai, armazenando o hash do cabeçalho do bloco anterior.

Tomemos o bloco Ethereum como exemplo. Ethereum aproveita um tipo específico de árvore Merkle conhecida como “árvore Merkle Patricia” (MPT). Os cabeçalhos dos blocos Ethereum contêm raízes de quatro tentativas diferentes de Merkle-Patricia, ou seja Teste de estado, teste de armazenamento, teste de recibos e teste de transação. Essas 4 tentativas codificam mapeamentos que compreendem todos os dados Ethereum. Merkle Trees são utilizadas devido à sua eficiência no armazenamento de dados. Usando hashes recursivos, apenas o hash raiz precisa ser armazenado, economizando muito espaço. Eles permitem que qualquer pessoa prove a existência de um elemento na árvore, provando que o hash recursivo dos nós leva ao mesmo hash raiz. As provas Merkle permitem que clientes leves no Ethereum obtenham respostas para perguntas como:

• Esta transação existe em um bloco específico?
• Qual é o saldo atual da minha conta?
• Essa conta existe?

Em vez de baixar cada transação e cada bloco, um “cliente leve” só pode baixar a cadeia de cabeçalhos de bloco e verificar as informações usando Merkle Proofs. Isso torna o processo geral altamente eficiente. Consulte este artigo de pesquisa do blog de Vitalik e Maven11 para entender melhor a implementação, vantagens e desafios associados às árvores Merkle.

Provas de armazenamento

As provas de armazenamento nos permitem provar que algo está confirmado no banco de dados e também é válido usando compromissos criptográficos. Se pudermos fornecer tal prova, será uma afirmação verificável de que algo aconteceu na blockchain.

O que as provas de armazenamento podem permitir?

As provas de armazenamento permitem duas funcionalidades principais:

1. Acesse dados históricos na cadeia além dos últimos 256 blocos, desde o bloco gênese
2. Acesse dados on-chain (históricos e atuais) de uma blockchain em outra blockchain com a ajuda de verificação de consenso ou ponte L1-L2 no caso de L2s

Como funcionam as provas de armazenamento?

As provas de armazenamento em um nível muito alto verificam se o bloco específico faz parte do histórico canônico do blockchain e, em seguida, verificam se os dados específicos solicitados fazem parte do bloco. Isto pode ser alcançado através de:

• Processamento em cadeia: os dapps podem pegar o bloco confiável inicial, passar o bloco como calldata para acessar o bloco anterior e percorrer todo o caminho de volta ao bloco genesis. Isso requer muita computação on-chain e uma enorme quantidade de dados de chamadas. Esta abordagem não é praticamente viável devido à enorme quantidade de computação necessária na cadeia. Aragon tentou usar a abordagem on-chain em 2018, mas não foi viável devido ao alto custo on-chain.
• Usando provas ZK: A abordagem é semelhante ao processamento on-chain, exceto pelo fato de que o provador ZK é usado para mover a computação complexa para fora da cadeia.

1. Acessando dados na mesma cadeia: a prova ZK pode ser usada para afirmar que um cabeçalho de bloco histórico arbitrário é um ancestral de um dos 256 cabeçalhos de bloco mais recentes acessíveis no ambiente de execução. A outra abordagem é indexar todo o histórico da cadeia de origem e gerar uma prova ZK da mesma para provar que a indexação ocorreu corretamente. Esta prova é atualizada regularmente à medida que novos blocos são adicionados à cadeia de origem. Acessando dados entre cadeias: O provedor coleta os cabeçalhos de bloco da cadeia de origem na cadeia de destino e atesta a validade desses cabeçalhos de bloco usando a prova de consenso ZK. Também é possível usar uma solução AMP existente como Axelar, Celer ou LayerZero para consultar os cabeçalhos dos blocos.
2. Um cache de hashes de cabeçalhos de bloco da cadeia de origem, ou o hash raiz de um acumulador de hash de bloco fora da cadeia, é mantido na cadeia de destino. Este cache é atualizado regularmente e é usado para provar de forma eficiente na cadeia que um determinado bloco existe e tem ligação criptográfica a um hash de bloco recente acessível a partir do estado. Este processo é conhecido como prova da continuidade da cadeia. Também é possível usar um blockchain dedicado para armazenar os cabeçalhos de bloco de todas as cadeias de origem.
3. Os dados/blocos históricos são acessados a partir de dados indexados fora da cadeia ou cache on-chain (dependendo da complexidade da solicitação), conforme solicitado pelo dapp na cadeia de destino. Embora o cache de um hash de cabeçalhos de bloco seja mantido na cadeia, os dados reais podem ser armazenados fora da cadeia.
4. A existência de dados no bloco especificado é verificada através de provas de inclusão merkle e uma prova zk para os mesmos é gerada. Esta prova é combinada com a prova zk de indexação correta ou prova de consenso ZK e a prova é disponibilizada na cadeia para verificação sem confiança.
5. Os dapps podem então verificar esta prova na cadeia e usar os dados para executar a ação desejada. Junto com a verificação da prova ZK, parâmetros públicos como o número do bloco e o hash do bloco são verificados em relação ao cache dos cabeçalhos dos blocos mantidos na cadeia.

Alguns dos projetos que adotam essa abordagem são Heródoto, Lagrange, Axiom, Hyper Oracle, Brevis Network e Nil Foundation. Embora esforços significativos estejam sendo feitos para tornar os aplicativos conscientes do estado em vários blockchains, o IBC (Inter Blockchain Communication) se destaca como um padrão de interoperabilidade que permite aplicativos como ICQ (consultas Interchain) e ICA (contas Interchain). O ICQ permite que aplicativos na Cadeia A consultem o estado da Cadeia B, incluindo a consulta em um pacote IBC simples e o ICA permite que um blockchain controle com segurança uma conta em outro blockchain. Combiná-los pode permitir casos de uso interessantes entre cadeias. Provedores de RaaS como a Saga oferecem essas funcionalidades a todas as suas cadeias de aplicativos por padrão usando IBC.

Há muitas maneiras pelas quais as provas de armazenamento podem ser otimizadas para encontrar o equilíbrio certo entre consumo de memória, tempo de prova, tempo de verificação, eficiência computacional e experiência do desenvolvedor. O processo geral pode ser amplamente dividido em 3 subprocessos principais.

• Acesso de dados
• Processamento de dados
• Geração de prova ZK para acesso e processamento de dados

Acesso aos dados: Neste subprocesso, o provedor de serviços acessa os cabeçalhos dos blocos da cadeia de origem nativamente na camada de execução ou por meio da manutenção de um cache on-chain. Para acesso a dados entre cadeias, é necessária a verificação do consenso da cadeia de origem na cadeia de destino. Algumas das abordagens e otimizações adotadas incluem:

• O Blockchain Ethereum Existente: A estrutura existente do blockchain Ethereum pode ser usada para provar o valor de qualquer slot de armazenamento histórico em relação ao blockheader atual usando ZKP. Isso pode ser considerado uma grande prova de inclusão. É a prova de que, dado um cabeçalho de bloco recente X na altura b, existe o cabeçalho de bloco Y que é um ancestral de X na altura bk. Baseia-se na segurança do consenso da Ethereum e requer um sistema de rápida comprovação de eficiência. Esta é a abordagem usada por Lagrange.
• Cache de Merkle Mountain Ranges (MMR) na cadeia: Uma Merkle Mountain Range pode ser vista como uma lista de árvores Merkle onde as árvores Merkle individuais são combinadas quando duas árvores atingem o mesmo tamanho. As árvores Merkle individuais no MMR são combinadas adicionando nós pais às raízes anteriores das árvores. MMR é uma estrutura de dados semelhante às árvores Merkle com alguns benefícios adicionais, como anexação eficiente de elementos e consultas de dados eficientes, especialmente ao ler dados sequenciais de grandes conjuntos de dados. Acrescentar novos cabeçalhos por meio da árvore Merkle exigiria a passagem de todos os nós irmãos em cada nível. Para anexar dados de forma eficiente, Axiom usa MMR para manter um cache do hash dos cabeçalhos de bloco na cadeia. Heródoto armazena o hash raiz do acumulador de hash do bloco MMR na cadeia. Isso permite que eles verifiquem os dados buscados em relação a esses hashes de cabeçalho de bloco por meio de provas de inclusão. Esta abordagem exige que o cache seja atualizado regularmente e traz problemas de atividade se não for descentralizada.
• Heródoto mantém dois MMR diferentes. Dependendo do blockchain ou camada específica, os acumuladores podem ser adaptados para utilizar diferentes funções de hash, otimizando a eficiência e os custos computacionais. Para provar no Starknet, o hash poseidon pode ser usado, mas o hash Keccack pode ser usado para cadeias EVM.
• Cache MMR fora da cadeia: Herodotus mantém um cache fora da cadeia de consultas e resultados obtidos anteriormente para permitir uma busca mais rápida caso os dados sejam solicitados novamente. Isto requer infraestrutura adicional do que simplesmente executar um nó de arquivo. As otimizações feitas na infraestrutura fora da cadeia podem potencialmente diminuir os custos para o usuário final.
• Blockchain dedicado para armazenamento: Brevis depende de um rollup ZK dedicado (camada de agregação) para armazenar todos os cabeçalhos de bloco de todas as cadeias que eles atestam. Sem esta camada de agregação, cada cadeia precisaria armazenar os cabeçalhos de bloco para todas as outras cadeias, resultando em O(N2) “conexões” para N blockchains. Ao introduzir uma camada de agregação, cada blockchain só precisa armazenar a raiz do estado para o rollup, reduzindo as conexões gerais para O(N). Esta camada também é usada para agregar múltiplas provas para cabeçalhos de bloco/resultados de consulta e uma única prova para verificação em cada blockchain conectada pode ser enviada.
• Passagem de mensagens L1-L2: A verificação do consenso da cadeia de origem pode ser evitada no caso de L2s porque os L2s suportam mensagens nativas para atualização de contratos L2 em L1. O cache pode ser atualizado no Ethereum e a passagem de mensagens L1-L2 pode ser usada para enviar o hash do bloco ou raiz da árvore compilada fora da cadeia para outros L2s. Heródoto está adotando essa abordagem, mas isso não é viável para L1s alternativos.

Processamento de dados:

Juntamente com o acesso aos dados, os contratos inteligentes também devem ser capazes de fazer cálculos arbitrários sobre os dados. Embora alguns casos de uso possam não exigir computação, é um importante serviço de valor agregado para muitos outros casos de uso. Muitos dos provedores de serviços permitem cálculos nos dados, pois uma prova zk do cálculo pode ser gerada e fornecida na cadeia para validade. Como as soluções AMP existentes, como Axelar, LayerZero e Polyhedra Network, poderiam ser potencialmente usadas para acesso a dados, o processamento de dados poderia se tornar um diferencial para provedores de serviços à prova de armazenamento.

O Hyper Oracle, por exemplo, permite que os desenvolvedores definam cálculos off-chain personalizados com JavaScript. Brevis projetou um mercado aberto de ZK Query Engines que aceita consultas de dados de dApps e as processa usando os cabeçalhos de bloco atestados. O contrato inteligente envia uma consulta de dados, que é coletada por um provador do mercado. O Prover gera uma prova com base na entrada da consulta, cabeçalhos de bloco relevantes (da camada de agregação Brevis) e resultados. Lagrange introduziu o ZK Big Data Stack para provar modelos de programação distribuída como SQL, MapReduce e Spark/RDD. As provas são modulares e podem ser geradas a partir de qualquer cabeçalho de bloco originado de pontes cross-chain e protocolos AMP existentes. ZK MapReduce, o primeiro produto da pilha Lagrange ZK BigData, é um mecanismo de computação distribuída (baseado no conhecido modelo de programação MapReduce) para provar resultados de computação envolvendo conjuntos consideráveis de dados de múltiplas cadeias. Por exemplo, uma única prova ZKMR pode ser usada para provar mudanças na liquidez de um DEX implantado em 4–5 cadeias durante um período de tempo especificado. Para consultas relativamente simples, o cálculo também pode ser feito diretamente na cadeia, como é feito por Heródoto no momento.

Geração de prova:

• Provas atualizáveis: provas atualizáveis podem ser usadas quando uma prova precisa ser computada e mantida de forma eficiente em um fluxo móvel de blocos. Quando um dapp deseja manter uma prova para uma média móvel para uma variável de contrato (como o preço do token), à medida que novos blocos são criados, sem recalcular a nova prova do zero, as provas existentes podem ser atualizadas de forma eficiente. Para provar a computação paralela de dados dinâmica em um estado on-chain, Lagrange constrói um compromisso de vetor em lote, chamado Recproof, em cima de uma parte do MPT, atualiza-o dinamicamente e calcula dinamicamente sobre ele. Ao criar recursivamente uma árvore Verkle sobre o MPT, Lagrange é capaz de calcular com eficiência grandes quantidades de dados de estado dinâmico na cadeia.
• Árvores Verkle: Ao contrário das árvores Merkle, onde precisamos fornecer todos os nós que compartilham um pai, as árvores Verkle exigem apenas o caminho para a raiz. Este caminho é muito menor comparado a todos os nós irmãos no caso da árvore Merkle. Ethereum também está explorando o uso de árvores Verkle em versões futuras para minimizar a quantidade de estado que os nós completos do Ethereum devem manter. Brevis aproveita o Verkle Tree para armazenar cabeçalhos de bloco atestados e resultados de consultas na camada de agregação. Reduz significativamente o tamanho da prova de inclusão de dados, especialmente quando a árvore contém um grande número de elementos, e também suporta prova de inclusão eficiente para um lote de dados.
• Monitoramento de Mempool para geração de provas mais rápida: Herodotus anunciou recentemente o turbo, que permite aos desenvolvedores adicionar algumas linhas de código ao seu código de contrato inteligente para especificar a consulta de dados. Heródoto monitora o mempool em busca de transações de contratos inteligentes que interagem com o contrato turbo. O processo de geração de prova começa quando a transação está no próprio mempool. Depois que a prova é gerada e verificada na rede, os resultados são registrados no contrato de troca turbo na rede. Os resultados só podem ser gravados no contrato de troca turbo depois de autenticados por provas de armazenamento. Quando isso acontece, uma parte das taxas de transação é compartilhada com o sequenciador ou construtor de blocos, incentivando-os a esperar um pouco mais para cobrar as taxas. Para consultas simples de dados, é possível que os dados solicitados sejam disponibilizados on-chain antes que a transação do usuário seja incluída no bloco.

Aplicação de provas de estado/armazenamento

As provas de estado e armazenamento podem desbloquear muitos novos casos de uso para contratos inteligentes nas camadas de aplicação, middleware e infraestrutura. Alguns deles são:

Camada de aplicação:

Governança:

• Votação entre cadeias: Um protocolo de votação em cadeia poderia permitir que os usuários da Cadeia B comprovassem a propriedade dos ativos da Cadeia A. Os usuários não terão que conectar seus ativos para obter poder de voto em uma nova cadeia. Exemplo: SnapshotX em Heródoto
• Distribuição de tokens de governança: os aplicativos poderiam distribuir mais tokens de governança para usuários ativos ou pioneiros. Exemplo: RetroPGF em Lagrange

Identidade e reputação:

• Prova de propriedade: um usuário pode fornecer prova de propriedade de um determinado NFT, SBT ou ativos na cadeia A, permitindo-lhes realizar certas ações na Cadeia B. Por exemplo, uma cadeia de aplicativos de jogos pode decidir lançar sua coleção NFT em outra rede com liquidez existente como Ethereum ou qualquer L2. Isso permitirá que o jogo aproveite a liquidez que existe em outros lugares e conecte o utilitário NFT sem realmente exigir que os NFTs sejam interligados.
• Prova de uso: os usuários podem receber descontos ou recursos premium com base no histórico de uso da plataforma (provar que o volume X negociado pelo usuário no Uniswap)
• Prova de OG: um usuário pode provar que possui uma conta ativa com mais de X dias
• Pontuação de crédito on-chain: uma plataforma de pontuação de crédito multichain pode agregar dados de várias contas de um único usuário para gerar uma pontuação de crédito

Todas as provas acima podem ser usadas para fornecer uma experiência personalizada aos usuários. Os Dapps podem oferecer descontos ou privilégios para reter traders ou usuários experientes e oferecer uma experiência de usuário simplificada para usuários novatos.

Definição:

• Empréstimo entre cadeias: os usuários poderiam bloquear ativos na Cadeia A e contrair um empréstimo na Cadeia B em vez de fazer a ponte entre os tokens
• Seguro on-chain: As falhas podem ser determinadas acessando dados históricos on-chain e o seguro pode ser liquidado totalmente on-chain.
• TWAP do preço do ativo em um pool: um aplicativo pode calcular e buscar o preço médio de um ativo em um pool AMM durante um período de tempo especificado. Exemplo: Uniswap TWAP Oracle com Axiom
• Precificação de opções: um protocolo de opções em cadeia pode precificar uma opção usando a volatilidade de um ativo nos últimos n blocos em uma bolsa descentralizada.

Os dois últimos casos de uso exigirão que a prova seja atualizada sempre que um novo bloco for adicionado à cadeia de origem.

Middleware:

• Intenções: as provas de armazenamento permitirão que os usuários sejam mais articulados e claros com suas intenções. Embora seja trabalho dos solucionadores executar as etapas necessárias para cumprir a intenção do usuário, um usuário poderia especificar mais claramente as condições com base nos dados e parâmetros da cadeia. Os solucionadores também podem provar a validade dos dados on-chain aproveitados para encontrar a solução ideal.
• Abstração de conta: os usuários podem contar com dados provenientes de outras cadeias usando provas de armazenamento para definir regras por meio de abstração de conta. Exemplo: Toda carteira possui um nonce. Podemos provar que há um ano o nonce era um número específico e atualmente o nonce é o mesmo. Isto pode ser usado para provar que esta carteira não foi utilizada e o acesso à carteira pode então ser delegado a outra carteira.
• Automação on-chain: Os contratos inteligentes podem automatizar certas ações com base em condições predefinidas que dependem de dados on-chain. Os programas automatizados são obrigados a acionar contratos inteligentes em determinados intervalos para manter o fluxo de preços ideal do AMM ou para manter os protocolos de empréstimo saudáveis, evitando dívidas inadimplentes. O Hyper Oracle permite automação junto com acesso a dados on-chain.

A infraestrutura

• Oracle on-chain confiável: redes oracle descentralizadas agregam respostas de vários nós oracle individuais dentro de uma rede oracle. A Oracle Networks pode eliminar essa redundância e aproveitar a segurança criptográfica para dados em cadeia. A rede Oracle poderia ingerir dados de múltiplas cadeias (L1s, L2s e alt L1s) em uma única cadeia e simplesmente provar a existência usando provas de armazenamento em outro lugar. Soluções DeFi com tração significativa também poderiam funcionar em uma solução personalizada. Por exemplo, a Lido Finance, o maior provedor de liquidez, uniu-se à Nil Foundation para financiar o desenvolvimento do zkOracle. As soluções permitirão acesso confiável a dados históricos in-EVM e garantirão US$ 15 bilhões em liquidez Ethereum apostada pela Lido Finance.
• Protocolos AMP: As soluções AMP existentes poderiam aumentar a expressividade de suas mensagens através de parcerias com provedores de serviços de prova de armazenamento. Esta é uma abordagem sugerida por Lagrange em seu artigo Modular Thesis .

Conclusão

A conscientização capacita as empresas de tecnologia a atender melhor seus clientes. Da identidade do usuário ao comportamento de compra e aos gráficos sociais, as empresas de tecnologia aproveitam a conscientização para desbloquear recursos como segmentação precisa, segmentação de clientes e marketing viral. As empresas de tecnologia tradicionais precisam de permissão explícita de seus usuários e devem ter cuidado ao gerenciar os dados dos usuários. No entanto, todos os dados do usuário em blockchains sem permissão estão disponíveis publicamente sem necessariamente revelar a identidade do usuário. Os contratos inteligentes devem ser capazes de aproveitar os dados publicamente disponíveis para melhor servir os utilizadores. O desenvolvimento e a adoção de ecossistemas mais especializados tornarão a consciência do Estado ao longo do tempo e as blockchains um problema cada vez mais importante a ser resolvido. As provas de armazenamento podem permitir que o Ethereum emerja como uma camada de identidade e propriedade de ativos, além de ser uma camada de liquidação. Os usuários poderiam manter sua identidade e ativos principais no Ethereum, que poderiam ser usados em vários blockchains sem conectar ativos o tempo todo. Continuamos entusiasmados com as novas possibilidades e casos de uso que serão desbloqueados no futuro.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [meio]. Todos os direitos autorais pertencem ao autor original [LongHash Ventures]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos 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 do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.