Introdução

O futuro é multichain. A busca pela escalabilidade levou o Ethereum a roll-ups. A mudança para blockchains modulares reacendeu a atenção nas cadeias de aplicativos. E no horizonte, ouvimos rumores de roll-ups, L3s e cadeias soberanas específicas de aplicações.

Mas isto ocorreu à custa da fragmentação. Conseqüentemente, a primeira onda de pontes básicas foi lançada para atender à necessidade de ponte, mas elas geralmente são limitadas em funcionalidade e dependem de assinantes confiáveis para segurança.

Como será o jogo final de uma web3 interconectada? Acreditamos que todas as pontes evoluirão para mensagens entre cadeias ou protocolos de “Passagem de Mensagens Arbitrárias” (AMP) para desbloquear novos casos de uso, permitindo que os aplicativos passem mensagens arbitrárias da cadeia de origem para a cadeia de destino. Também veremos surgir um “cenário de mecanismo de confiança”, onde os construtores fazem várias compensações em termos de usabilidade, complexidade e segurança.

Cada solução AMP precisa de dois recursos críticos:

• Verificação: A capacidade de verificar a validade da mensagem da cadeia de origem na cadeia de destino
• Vivacidade: A capacidade de transmitir informações da origem ao destino

A verificação 100% confiável não é alcançável e os usuários são obrigados a confiar no código, na teoria dos jogos, em humanos (ou entidades) ou em uma combinação destes, dependendo se a verificação está sendo feita dentro ou fora da cadeia.

Dividimos o cenário geral de interoperabilidade com base no mecanismo de confiança e na arquitetura de integração.

Mecanismo de confiança:

1. Confie no código/matemática: para essas soluções, existe prova on-chain e pode ser verificada por qualquer pessoa. Essas soluções geralmente dependem de um cliente leve para validar o consenso de uma cadeia de origem em uma cadeia de destino ou verificar a validade de uma transição de estado para uma cadeia de origem em uma cadeia de destino. A verificação por meio de clientes leves pode se tornar muito mais eficiente por meio de provas de Conhecimento Zero para compactar off-line cálculos arbitrariamente longos e fornecer uma verificação simples na cadeia para comprovar os cálculos.
2. Teoria do jogo de confiança: Há uma suposição de confiança adicional quando o usuário/aplicação precisa confiar em um terceiro ou em uma rede de terceiros para a autenticidade das transações. Estes mecanismos podem tornar-se mais seguros através de redes sem permissão, juntamente com a teoria dos jogos, como incentivos económicos e segurança optimista.
3. Confie nos humanos: Estas soluções dependem da honestidade da maioria dos validadores ou da independência das entidades que transmitem informações diferentes. Eles exigem confiança em terceiros, além de confiar no consenso das duas cadeias em interação. A única coisa que está em jogo aqui é a reputação das entidades participantes. Se um número suficiente de entidades participantes concordarem que uma transação é válida, ela será considerada válida.

É importante observar que todas as soluções, até certo ponto, exigem confiança no código e também nos humanos. Qualquer solução com código defeituoso pode ser explorada por hackers e cada solução possui algum elemento humano na configuração, atualizações ou manutenção da base de código.

Arquitetura de integração:

1. Modelo ponto a ponto: Um canal de comunicação dedicado precisa ser estabelecido entre cada origem e cada destino.
2. Modelo Hub and Spoke: Um canal de comunicação precisa ser estabelecido com um hub central que permita a conectividade com todos os outros blockchains conectados a esse hub.

O modelo ponto a ponto é relativamente difícil de escalar, pois é necessário um canal de comunicação em pares para cada blockchain conectado. O desenvolvimento desses canais pode ser um desafio para blockchains com diferentes consensos e estruturas. No entanto, as pontes emparelhadas oferecem mais flexibilidade para personalizar configurações, se necessário. Uma abordagem híbrida também é possível, por exemplo, usando um protocolo de comunicação Inter-Blockchain (IBC) com roteamento multi-hop através de um hub, o que elimina a necessidade de comunicação direta entre pares, mas reintroduz mais complexidade em segurança, latência e custo considerações.

Confie no código/matemática

Como os clientes leves validam o consenso de uma cadeia de origem em uma cadeia de destino?

Um cliente/nó leve é um software que se conecta a nós completos para interagir com o blockchain. Os clientes leves na cadeia de destino normalmente armazenam o histórico dos cabeçalhos dos blocos (sequencialmente) da cadeia de origem, o que é suficiente para verificar as transações. Agentes fora da cadeia, como retransmissores, monitoram os eventos na cadeia de origem, geram provas de inclusão criptográfica e as encaminham junto com os cabeçalhos do bloco para o cliente leve na cadeia de destino. Os clientes leves são capazes de verificar a transação à medida que armazenam os cabeçalhos do bloco sequencialmente e cada cabeçalho do bloco contém o hash raiz Merkle que pode ser usado para provar o estado. As principais características deste mecanismo são:

1. Segurança:

• Além da confiança no código, outra suposição de confiança é introduzida durante a inicialização do cliente light. Quando alguém cria um novo cliente light, ele é inicializado com um cabeçalho de uma altura específica da cadeia da contraparte. O cabeçalho fornecido pode estar incorreto e o cliente light pode ser posteriormente enganado com outros cabeçalhos falsos. Nenhuma suposição de confiança é introduzida depois que o cliente light é inicializado. No entanto, esta é uma suposição de confiança fraca, pois qualquer pessoa pode verificar a inicialização.
• Há uma suposição de atividade no retransmissor, pois ele é necessário para transmitir as informações.

1. Implementação: Depende da disponibilidade de suporte para as primitivas criptográficas necessárias para verificação

• Se o mesmo tipo de cadeia estiver sendo conectado (mesma estrutura de aplicação e algoritmo de consenso), então a implementação do cliente leve em ambos os lados será a mesma. Exemplo: IBC para todas as cadeias baseadas no Cosmos SDK.
• Se dois tipos diferentes de cadeias (estruturas de aplicação diferentes ou tipos de consenso) estiverem conectados, a implementação do cliente leve será diferente. Exemplo: Composable Finance está trabalhando para permitir que as cadeias Cosmos SDK sejam conectadas via IBC ao Substrate (estrutura de aplicativo do ecossistema Polkadot). Isso requer um cliente leve Tendermint na cadeia de substrato e um chamado cliente leve robusto adicionado à cadeia Cosmos SDK

1. Desafios:

• Intensidade de recursos: É caro executar clientes leves em pares em todas as cadeias, pois as gravações em blockchains são caras e não são viáveis para serem executadas em cadeias com conjuntos de validadores dinâmicos como o Ethereum.
• Extensibilidade: A implementação do cliente leve é necessária para cada combinação de cadeias. Dado que a implementação varia de acordo com a arquitetura da cadeia, é difícil dimensionar e conectar diferentes ecossistemas.
• Exploração de código: erros no código podem levar a vulnerabilidades. A exploração da cadeia BNB em outubro de 2022 revelou uma vulnerabilidade crítica de segurança que afeta todas as cadeias habilitadas para IBC.

Como as provas ZK verificam a validade de uma transição de estado para a cadeia de origem na cadeia de destino?

Executar clientes leves em pares em todas as cadeias tem um custo proibitivo e não é prático para todas as cadeias de blocos. Clientes leves em implementações como IBC também são obrigados a acompanhar o conjunto de validadores da cadeia de origem, o que não é prático para cadeias com conjuntos de validadores dinâmicos, como Ethereum. As provas ZK fornecem uma solução para reduzir o gás e o tempo de verificação. Em vez de executar todo o cálculo na cadeia, apenas a verificação da prova do cálculo é feita na cadeia e o cálculo real é feito fora da cadeia. A verificação de uma prova de cálculo pode ser feita em menos tempo e com menos gás do que executar novamente o cálculo original. As principais características deste mecanismo são:

1. Segurança: zk-SNARKs dependem de curvas elípticas para sua segurança e zk-STARKs dependem de funções hash. zk-SNARKs podem ou não exigir uma configuração confiável. A configuração confiável só é necessária inicialmente, o que se refere ao evento de criação inicial das chaves que são usadas para criar as provas necessárias para a verificação dessas provas. Se os segredos do evento de configuração não forem destruídos, eles poderão ser utilizados para falsificar transações por meio de verificações falsas. Nenhuma suposição de confiança é introduzida depois que a configuração confiável é concluída.
2. Implementação: Diferentes esquemas de prova de ZK como SNARK, STARK, VPD, SNARG existem hoje e atualmente o SNARK é o mais amplamente adotado. As provas ZK recursivas são outro desenvolvimento mais recente que permite que o trabalho total de prova seja dividido entre vários computadores em vez de apenas um. Para gerar provas de validade, as seguintes primitivas principais precisam ser implementadas:

• verificação do esquema de assinatura usado pelos validadores
• inclusão de prova de chaves públicas do validador no compromisso do conjunto de validadores (que é armazenado na cadeia)
• rastreando o conjunto de validadores que podem mudar frequentemente

1. Desafios:

• Para implementar vários esquemas de assinatura dentro de um zkSNARK, é necessária a implementação de operações aritméticas fora de campo e de curvas elípticas complexas. Isto não é fácil de conseguir e pode exigir implementações diferentes para cada cadeia, dependendo da sua estrutura e consenso.
• Se o tempo e o esforço de prova forem extremamente elevados, então apenas equipas especializadas com hardware especializado serão capazes de fazer o que levará à centralização. Um tempo de geração de prova mais alto também pode levar à latência.
• Maior tempo e esforço de verificação levarão a custos mais elevados na cadeia.

1. Exemplos: Polímero ZK-IBC da Polymer Labs, Succinct Labs. A Polymer está trabalhando em IBC habilitado para multi-hop para aumentar a conectividade e, ao mesmo tempo, reduzir o número de conexões entre pares necessárias.

Confie na teoria dos jogos

Os protocolos de interoperabilidade que se baseiam na teoria dos jogos podem ser amplamente divididos em 2 categorias com base na forma como incentivam o comportamento honesto das entidades participantes:

1. Segurança económica: Vários participantes externos (como validadores) chegam a um consenso sobre o estado atualizado da cadeia de origem. Isso é semelhante a uma configuração multi-sig, mas para se tornar um validador, os participantes são obrigados a apostar uma certa quantidade de tokens, que pode ser reduzida caso alguma atividade maliciosa seja detectada. Em configurações sem permissão, qualquer pessoa pode acumular apostas e se tornar um validador. Existem também recompensas em bloco, que funcionam como incentivos econômicos, quando os validadores participantes seguem o protocolo. Os participantes são, portanto, economicamente incentivados a serem honestos. No entanto, se o montante que pode ser roubado for muito superior ao montante apostado, os participantes poderão tentar conspirar para roubar fundos. Exemplos: Axelar, Celer IM
2. Segurança otimista: As soluções de segurança otimistas baseiam-se na suposição de confiança da minoria, que pressupõe que apenas uma minoria dos participantes da blockchain são ativos, honestos e seguem as regras do protocolo. A solução poderia exigir que apenas um único participante honesto detivesse uma garantia. O exemplo mais comum é uma solução ideal onde qualquer pessoa pode enviar provas de fraude. Há também aqui um incentivo económico, mas é praticamente possível, mesmo para um observador honesto, perder uma transação fraudulenta. Roll-ups otimistas também aproveitam essa abordagem. Exemplos: Nomad, ChainLink CCIP

• No caso do Nomad, os observadores podem comprovar a fraude. No entanto, os observadores Nomad estão na lista de permissões no momento em que este artigo foi escrito.
• ChainLink CCIP alavancará uma rede antifraude que consistirá em redes oracle descentralizadas com o único propósito de monitorar atividades maliciosas. A implementação da Rede Antifraude da CCIP ainda não foi vista.

As principais características desses mecanismos são:

1. Segurança: Para ambos os mecanismos, é essencial a participação sem permissão de validadores e observadores para que os mecanismos da teoria dos jogos sejam eficazes. No âmbito do mecanismo de segurança económica, os fundos podem estar em maior risco se o montante apostado for inferior ao montante que pode ser roubado. No âmbito do mecanismo de segurança optimista, os pressupostos de confiança das minorias para soluções optimistas podem ser explorados se ninguém apresentar a prova de fraude, ou se os observadores autorizados forem comprometidos/removidos, enquanto os mecanismos de segurança económica não têm a mesma dependência da vitalidade para a segurança.
2. Implementação:

• Cadeia intermediária com validadores próprios: Um grupo de validadores externos monitora a cadeia de origem, chega a um consenso sobre a validade da transação sempre que uma chamada é detectada e fornece atestado na cadeia de destino se o consenso for alcançado. Os validadores geralmente são obrigados a apostar uma certa quantidade de tokens que podem ser reduzidos se atividade maliciosa for detectada. Exemplos: Rede Axelar, Celer IM
• Através de agentes fora da cadeia: Os agentes fora da cadeia podem ser usados para implementar uma solução otimista do tipo roll-up, onde durante uma janela de tempo predefinida, os agentes fora da cadeia terão permissão para enviar provas de fraude e reverter a transação. Exemplo: Nomad depende de agentes independentes fora da cadeia para retransmitir o cabeçalho e a prova criptográfica. ChainLink CCIP aproveitará sua rede oracle existente para monitorar e atestar transações entre cadeias.

1. Desafios:

• As suposições de confiança podem ser exploradas para roubar fundos se a maioria dos validadores conspirar, o que exige contramedidas como votação quadrática e provas de fraude.
• Finalidade: As soluções AMP otimistas baseadas em segurança introduzem complexidade na finalidade e na vitalidade porque os usuários e os aplicativos precisam aguardar a janela de fraude.

1. Vantagens:

• Otimização de Recursos: Esta abordagem geralmente não consome muitos recursos, pois a verificação geralmente não acontece na cadeia
• Extensibilidade: Esta abordagem é mais extensível, pois o mecanismo de consenso permanece o mesmo para todos os tipos de cadeias e pode ser facilmente estendido a cadeias de blocos heterogêneas.

Confie nos humanos

1. Suposição de honestidade da maioria: Estas soluções dependem de uma implementação multi-sig onde múltiplas entidades verificam e assinam as transações. Uma vez atingido o limite mínimo, a transação é considerada válida. A suposição aqui é que a maioria das entidades é honesta e se a maioria dessas entidades assina uma transação específica, ela é válida. A única coisa que está em jogo aqui é a reputação das entidades participantes. Exemplos: Multichain (Anycall V6), Buraco de minhoca. Explorações devido a bugs de contratos inteligentes ainda são possíveis, conforme evidenciado pelo hack do Wormhole no início de 2022.
2. Independência: Estas soluções dividem todo o processo de passagem de mensagens em duas partes e contam com diferentes entidades independentes para gerir os dois processos. A suposição aqui é que as duas entidades são independentes uma da outra e não estão em conluio. Exemplo: CamadaZero. Os cabeçalhos dos blocos são transmitidos sob demanda por oráculos descentralizados e as provas de transação são enviadas por meio de retransmissores. Se a prova corresponder aos cabeçalhos, a transação é considerada válida. Embora a correspondência de provas dependa de código/matemática, os participantes são obrigados a confiar que as entidades permanecerão independentes. Os aplicativos desenvolvidos no LayerZero têm a opção de escolher seu Oracle e Relayer (ou hospedar seu próprio Oracle/Relayer), limitando assim o risco de conluio individual entre oráculo/relayer. Os usuários finais precisam confiar que o LayerZero, um terceiro ou o próprio aplicativo estão executando o oráculo e o retransmissor de forma independente e sem intenções maliciosas.

Em ambas as abordagens, a reputação das entidades terceirizadas participantes desincentiva o comportamento malicioso. Estas são geralmente entidades respeitadas dentro da comunidade validadora e oráculo e correm o risco de consequências reputacionais e um impacto negativo nas suas outras atividades comerciais se agirem de forma maliciosa.

Além das suposições de confiança e do futuro da interoperabilidade

Ao considerar a segurança e a usabilidade de uma solução AMP, precisamos também levar em consideração os detalhes que vão além dos mecanismos básicos. Como se trata de peças móveis que podem mudar com o tempo, não as incluímos na comparação geral.

• Integridade do código: Vários hacks no passado recente aproveitaram bugs no código que exigem auditorias confiáveis, recompensas de bugs bem planejadas e múltiplas implementações de clientes. Se todos os validadores (em segurança econômica/otimista/reputacional) executarem o mesmo cliente (software para verificação), isso aumenta a dependência de uma única base de código e reduz a diversidade de clientes. Ethereum, por exemplo, depende de vários clientes de execução como geth, nethermind, erigon, besu, akula. Múltiplas implementações em uma variedade de linguagens provavelmente aumentarão a diversidade sem que nenhum cliente domine a rede, eliminando assim um potencial ponto único de falha. Ter vários clientes também pode ajudar na vitalidade se uma minoria de validadores/signatários/clientes leves cair devido a explorações/bugs em uma implementação específica.
• Configuração e capacidade de atualização: usuários e desenvolvedores precisam estar cientes se validadores/observadores podem ingressar na rede sem permissão, caso contrário, a confiança será ocultada pela seleção de entidades autorizadas. As atualizações de contratos inteligentes também podem introduzir bugs que podem levar a explorações ou até mesmo alterar potencialmente as suposições de confiança. Diferentes soluções podem ser implementadas para mitigar esses riscos. Por exemplo, na instanciação atual, os gateways Axelar podem ser atualizados, sujeitos à aprovação de um comitê off-line (limite de 4/8). No entanto, num futuro próximo, a Axelar planeja exigir que todos os validadores aprovem coletivamente quaisquer atualizações nos gateways. Os contratos principais do Wormhole podem ser atualizados e gerenciados por meio do sistema de governança on-chain do Wormhole. LayerZero depende de contratos inteligentes imutáveis e bibliotecas imutáveis para evitar quaisquer atualizações, no entanto, ele pode enviar uma nova biblioteca, e dapps com configurações padrão obteriam a versão atualizada, e dapps com sua versão definida manualmente precisariam configurá-la para a nova. .
• MEV: Blockchains diferentes não são sincronizados por meio de um relógio comum e têm tempos de finalização diferentes. Como resultado, a ordem e o tempo de execução na cadeia de destino podem variar entre as cadeias. MEV em um mundo entre cadeias é difícil de definir claramente. Ele introduz uma compensação entre vivacidade e ordem de execução. Um canal ordenado garantirá a entrega ordenada de mensagens, mas o canal será fechado se uma mensagem expirar. Outro aplicativo pode preferir um cenário em que o pedido não seja necessário, mas a entrega de outras mensagens não seja afetada.

Tendências e perspectivas futuras:

• Segurança personalizável e adicional: para melhor atender a diversos casos de uso, as soluções AMP são incentivadas a oferecer mais flexibilidade aos desenvolvedores. A Axelar introduziu uma abordagem para a capacidade de atualização da passagem e verificação de mensagens, sem quaisquer alterações na lógica da camada de aplicação. O HyperLane V2 introduziu módulos que permitem aos desenvolvedores escolher entre diversas opções, como segurança econômica, segurança otimista, segurança dinâmica e segurança híbrida. CelerIM oferece segurança otimista adicional juntamente com segurança econômica. Muitas soluções aguardam um número mínimo predefinido de confirmações de bloco na cadeia de origem antes de transmitir a mensagem. LayerZero permite que os desenvolvedores atualizem esses parâmetros. Esperamos que algumas soluções AMP continuem a oferecer mais flexibilidade, mas essas opções de design merecem alguma discussão. Os aplicativos devem ser capazes de configurar sua segurança, até que ponto e o que acontece se os aplicativos adotarem uma arquitetura de design abaixo da média? A conscientização do usuário sobre os conceitos básicos por trás da segurança pode se tornar cada vez mais importante. Em última análise, prevemos agregação e abstração de soluções AMP, talvez em alguma forma de combinação ou segurança “aditiva”.
• Crescimento e maturação dos mecanismos de “código/matemática de confiança”: Em um final de jogo ideal, todas as mensagens entre cadeias terão a confiança minimizada usando provas de conhecimento zero (ZK) para verificar mensagens e estados. Já estamos testemunhando essa mudança com o surgimento de projetos como Polymer Labs e Succinct Labs. A Multichain também publicou recentemente um white paper zkRouter para permitir a interoperabilidade por meio de provas ZK. Com a recém- anunciada Máquina Virtual Axelar, os desenvolvedores podem aproveitar o Interchain Amplifier para configurar novas conexões sem permissão à rede Axelar. Por exemplo, uma vez desenvolvidos light-clients robustos e provas ZK para o estado do Ethereum, um desenvolvedor pode integrá-los facilmente à rede Axelar para substituir ou aprimorar uma conexão existente. LayerZero em sua documentação fala sobre a possibilidade de adicionar novas bibliotecas otimizadas de mensagens de prova no futuro. Projetos mais recentes como Lagrange estão explorando a agregação de múltiplas provas de múltiplas cadeias de origem e Heródoto está viabilizando provas de armazenamento por meio de provas ZK. No entanto, esta transição levará tempo, uma vez que esta abordagem é difícil de escalar entre blockchains que dependem de diferentes mecanismos e estruturas de consenso. ZK é uma tecnologia relativamente nova e complexa que é difícil de auditar e, atualmente, a verificação e a geração de provas não são otimizadas em termos de custo. Acreditamos que, no longo prazo, para oferecer suporte a aplicações cross-chain altamente escaláveis no blockchain, muitas soluções AMP provavelmente complementarão seres humanos e entidades confiáveis com software verificável porque:
• A possibilidade de exploração de código pode ser minimizada por meio de auditorias e recompensas por bugs. Com o passar do tempo, será mais fácil confiar nestes sistemas, pois o seu histórico servirá como prova da sua segurança.
• O custo de geração de provas ZK diminuirá. Com mais P&D em ZKPs, ZK recursivo, agregação de provas e hardware especializado, esperamos que o tempo e o custo da geração e verificação de provas sejam reduzidos significativamente, tornando-a uma abordagem mais econômica.
• Blockchains se tornarão mais amigáveis ao zk. No futuro, os zkEVMs serão capazes de fornecer uma prova de execução de validade sucinta, e soluções leves baseadas em clientes serão capazes de verificar facilmente a execução e o consenso de uma cadeia de origem na cadeia de destino. No jogo final do Ethereum, também há planos para “zk-SNARK tudo”, incluindo consenso.
• Prova de humanidade/reputação/identidade: A segurança de sistemas complexos como soluções AMP não pode ser encapsulada através de uma única estrutura e garante múltiplas camadas de soluções. Por exemplo, juntamente com incentivos económicos, a Axelar implementou a votação quadrática para evitar a concentração do poder de voto entre um subconjunto de nós e promover a descentralização. Outras provas de humanidade, reputação e identidade também podem complementar mecanismos de configuração e permissão.

No espírito de abertura da Web3, provavelmente veremos um futuro plural onde coexistirão múltiplas abordagens. Na verdade, os aplicativos podem optar por usar múltiplas soluções de interoperabilidade, seja de forma redundante, ou permitir que os usuários misturem e combinem com a divulgação de compensações. As soluções ponto a ponto podem ser priorizadas entre rotas de “alto tráfego”, enquanto os modelos hub and spoke podem dominar a longa cauda das cadeias. No final, cabe a nós, o coletivo dem e os usuários, construtores e contribuidores, moldar a topografia da web interconectada3.

Gostaríamos de agradecer a Bo Du e Peter Kim da Polymer Labs, Galen Moore da Axelar Network, Uma Roy da Succinct Labs, Max Glassman e Ryan Zarick da LayerZero por revisar e fornecer seus valiosos comentários.

Lista de referências:

• Axelar: https://docs.axelar.dev/
• CelerIM: https://im-docs.celer.network/developer/celer-im-overview
• ChainLink CCIP: https://blog.chain.link/introduzindo-the-cross-chain-interoperability-protocol-ccip/
• debridge: https://docs.debridge.finance/
• IBC: https://tutorials.cosmos.network/academy/3-ibc/
• CamadaZero: https://layerzero.gitbook.io/docs/
• Multichain: https://docs.multichain.org/getting-started/introduction
• Nômade: https://docs.nomad.xyz/nomad-101/introduction
• Laboratórios de polímeros: https://polymerlabs.medium.com/
• Laboratórios sucintos: https://blog.succinct.xyz/
• Buraco de minhoca: https://docs.wormhole.com/wormhole/

Lista de leitura adicional:

• Navegando em pontes de mensagens arbitrárias: uma estrutura de comparação: https://blog.li.fi/navigating-arbitrary-messaging-bridges-a-comparison-framework-8720f302e2aa
• Estrutura de risco L2Bridge: https://gov.l2beat.com/t/l2bridge-risk-framework/31
• Horácio na ponte: https://maven11.substack.com/p/horatius-at-the-bridge

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.