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 aplicações. E no horizonte, ouvimos sussurros de roll-ups específicos de aplicações, L3s e cadeias soberanas.

Mas isto veio à custa da fragmentação. Assim, a primeira vaga de pontes básicas foi lançada para responder à necessidade de ponte, mas muitas vezes são limitadas em funcionalidade e dependem de signatários confiáveis para a segurança.

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

Todas as soluções AMP precisam de duas capacidades críticas:

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

100% de verificação sem confiança não é possível e os utilizadores são obrigados a confiar no código, na teoria dos jogos, nos seres humanos (ou entidades) ou numa combinação destes, dependendo se a verificação está a ser feita na cadeia ou fora da cadeia.

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

Mecanismo de Confiança:

1. Código de confiança/matemática: Para estas soluções, existe prova na cadeia e pode ser verificada por qualquer pessoa. Estas soluções geralmente dependem de um cliente leve para validar o consenso de uma cadeia de origem numa cadeia de destino ou verificar a validade de uma transição de estado para uma cadeia de origem numa cadeia de destino. A verificação através de clientes leves pode ser muito mais eficiente através de provas Zero Knowledge para comprimir cálculos arbitrariamente longos offline e fornecer uma verificação simples na cadeia para provar cálculos.
2. Teoria dos jogos de confiança: Há uma suposição de confiança adicional quando o utilizador/aplicação tem de confiar num terceiro ou rede de terceiros para a autenticidade das transações. Estes mecanismos podem ser tornados mais seguros através de redes sem permissão, juntamente com teóricas de jogo, tais como incentivos económicos e segurança otimista.
3. Confie nos humanos: Estas soluções dependem da honestidade da maioria dos validadores ou da independência das entidades que retransitam informações diferentes. Exigem confiança em terceiros para além de confiarem no consenso das duas cadeias que interagem. A única coisa em jogo aqui é a reputação das entidades participantes. Se um número suficiente de entidades participantes concordar que uma transação é válida, então ela é considerada válida.

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

Arquitetura de integração:

1. Modelo ponto a ponto: É necessário estabelecer um canal de comunicação dedicado entre cada fonte e cada destino.
2. Modelo Hub and Spoke: É necessário estabelecer um canal de comunicação com um hub central que permita a conectividade com todos os outros blockchains ligados a esse hub.

O modelo ponto a ponto é relativamente difícil de escalar, uma vez que é necessário um canal de comunicação em pares para cada cadeia de blocos ligada. Desenvolver estes canais pode ser um desafio para blockchains com diferentes consensos e frameworks. No entanto, as pontes em pares fornecem 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 interblockchain (IBC) com roteamento multi-hop através de um hub, o que elimina a necessidade de comunicação direta em pares, mas reintroduz mais complexidade nas considerações de segurança, latência e custo.

Código de confiança/matemática

Como é que os clientes leves validam o consenso de uma cadeia de origem numa cadeia de destino?

Um cliente/nó leve é um software que se conecta a nós completos para interagir com a cadeia de blocos. Os clientes leves na cadeia de destino normalmente armazenam o histórico de cabeçalhos de bloco (sequencialmente) da cadeia de origem, o que é suficiente para verificar as transações. Agentes fora da cadeia, como relayers, monitorizam os eventos na cadeia de origem, geram provas de inclusão criptográfica e encaminham junto com os cabeçalhos de bloco, para o cliente leve na cadeia de destino. Os clientes leves podem verificar a transação à medida que armazenam os cabeçalhos dos blocos sequencialmente e cada cabeçalho de 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 de luz pode ser enganado mais tarde com outros cabeçalhos falsos. Nenhuma suposição de confiança é introduzida uma vez que o cliente leve tenha sido inicializado. No entanto, esta é uma suposição de confiança fraca, pois qualquer pessoa pode verificar a inicialização.
• Há uma suposição de vitalidade no relayer, uma vez que é necessário transmitir a informação.

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

• Se o mesmo tipo de cadeia estiver a ser ligado (mesma estrutura de aplicação e algoritmo de consenso), 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: O Composable Finance está a funcionar para permitir que as cadeias Cosmos SDK sejam conectadas via IBC ao Substrato (estrutura de aplicação do ecossistema Polkadot). Isto requer um cliente de luz Tendermint na cadeia de substrato e um chamado cliente de luz rochoso adicionado à cadeia Cosmos SDK

1. Desafios:

• Intensividade 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: É necessária uma implementação leve do cliente para cada combinação de cadeias. Dado que a implementação varia de acordo com a arquitetura da cadeia, é difícil escalar e ligar 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 descobriu uma vulnerabilidade de segurança crítica que afetava todas as cadeias habilitadas para IBC.

Como é que 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 blockchains. Os clientes leves em implementações como o 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 o 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 em cadeia, apenas a verificação da prova de computação é feita em 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: os zk-SNARKs dependem de curvas elípticas para a sua segurança e os zk-STARKs dependem de funções de hash. O zk-SNARKS pode ou não exigir uma configuração fidedigna. A configuração fidedigna só é necessária inicialmente, o que se refere ao evento de criação inicial das chaves que são utilizadas para criar as provas necessárias para a verificação dessas provas. Se os segredos no evento de configuração não forem destruídos, podem ser utilizados para falsificar transações por falsas verificações. Nenhuma suposição de confiança é introduzida uma vez concluída a configuração fidedigna.
2. Implementação: Diferentes esquemas de prova ZK como SNARK, STARK, VPD, SNARG existem hoje e atualmente o SNARK é o mais amplamente adotado. As provas recursivas do ZK 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 utilizado pelos validadores
• inclusão de prova de chaves públicas do validador no compromisso definido pelo validador (que é armazenado na cadeia)
• rastrear o conjunto de validadores que podem continuar a mudar com frequência

1. Desafios:

• Implementar vários esquemas de assinatura dentro de um ZKsnark requer a implementação de operações aritméticas fora de campo e de curva elíptica 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, apenas equipas especializadas com hardware especializado poderão fazer o que levará à centralização. Maior tempo de geração de prova 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á a trabalhar em IBC habilitado para multi-hop para aumentar a conectividade enquanto reduz o número de ligações em pares necessárias.

Confie na teoria dos jogos

Os protocolos de interoperabilidade que dependem de teóricas 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. Isto é semelhante a uma configuração multi-sig mas para se tornarem um validador, os participantes são obrigados a aposta de uma certa quantidade de tokens, que podem ser cortados caso alguma atividade maliciosa seja detectada. Em configurações sem permissão, qualquer pessoa pode acumular apostas e tornar-se um validador. Também existem recompensas em bloco, para atuar como incentivos económicos, quando os validadores participantes seguem o protocolo. Os participantes são assim economicamente incentivados a ser honestos. No entanto, se o valor que pode ser roubado for muito superior ao valor apostado, os participantes podem tentar conluir para roubar fundos. Exemplos: Axelar, Celer IM
2. Segurança otimista: As soluções de segurança otimistas baseiam-se no pressuposto de confiança minoritária que pressupõe que apenas uma minoria dos participantes da blockchain estão vivos, honestos e seguem as regras do protocolo. A solução pode exigir apenas um único participante honesto para ter uma garantia. O exemplo mais comum é uma solução ideal onde qualquer pessoa pode apresentar provas de fraude. Há também um incentivo económico aqui mas é praticamente possível mesmo para um observador honesto perder uma transação fraudulenta. Roll-ups otimistas também alavancam esta abordagem. Exemplos: Nomad, ChainLink CCIP

• No caso do Nomad, os observadores podem provar fraude. No entanto, os observadores nómadas estão na lista branca no momento em que este artigo foi escrito.
• ChainLink CCIP irá alavancar uma Rede Antifraude que consistirá em redes oracle descentralizadas com o único propósito de monitorizar a atividade maliciosa. A implementação da Rede Antifraude da CCIP ainda não foi vista.

As principais características destes mecanismos são:

1. Segurança: Para ambos os mecanismos, é essencial ter a participação sem permissão de validadores e observadores para que os mecanismos da teoria dos jogos sejam eficazes. Ao abrigo do mecanismo de segurança económica, os fundos podem estar em maior risco se o valor em causa for inferior ao montante que pode ser roubado. Sob o mecanismo de segurança otimista, os pressupostos de confiança minoritária para soluções otimistas 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 vida para a segurança.
2. Implementação:

• Cadeia intermediária com os seus próprios validadores: Um grupo de validadores externos monitoriza a cadeia de origem, chega a um consenso sobre a validade da transação sempre que uma chamada é detectada e fornece um atestado na cadeia de destino se o consenso for alcançado. Os validadores são normalmente obrigados a apostar uma certa quantidade de tokens que podem ser cortados se for detectada atividade maliciosa. Exemplos: Rede Axelar, Celer IM
• Via agentes off-chain: Os agentes off-chain podem ser usados para implementar uma solução otimista tipo roll-up em que, durante uma janela de tempo predefinida, os agentes fora da cadeia poderão apresentar provas de fraude e reverter a transação. Exemplo: O Nomad conta com agentes independentes fora da cadeia para transmitir o cabeçalho e a prova criptográfica. O ChainLink CCIP irá alavancar a sua rede oracle existente para monitorizar 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: Soluções AMP otimistas baseadas em segurança introduzem complexidade na finalidade e na vida porque os utilizadores e as aplicações precisam de esperar pela janela de fraude.

1. Vantagens:

• Optimização de Recursos: Esta abordagem normalmente não é intensiva em recursos, uma vez que a verificação normalmente não acontece na cadeia
• Extensibilidade: Esta abordagem é mais extensível, uma vez que o mecanismo de consenso permanece o mesmo para todos os tipos de cadeias e pode ser facilmente alargado a blockchains heterogéneos.

Confiar nos humanos

1. Pressuposição de honestidade maioritária: Estas soluções dependem de uma implementação multi-sig onde várias 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 são honestas e se a maioria dessas entidades está a assinar uma determinada transação, é válida. A única coisa em jogo aqui é a reputação das entidades participantes. Exemplos: Multichain (Anycall V6), Wormhole. Explorações devido a bugs de contratos inteligentes ainda são possíveis, como evidenciado pelo hack do Wormhole no início de 2022.
2. Independência: Estas soluções dividem todo o processo de transmissão de mensagens em duas partes e dependem de 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 a conluir. Exemplo: LayerZero. Os cabeçalhos de bloco são transmitidos a pedido por oráculos descentralizados e as provas de transação são enviadas através de relayers. Se a prova corresponder aos cabeçalhos, a transação é considerada válida. Embora a correspondência de provas dependa do código/matemática, os participantes são obrigados a confiar nas entidades para permanecerem independentes. As aplicações baseadas no LayerZero têm a opção de escolher o seu Oracle e Relayer (ou alojar o seu próprio Oracle/Relayer), limitando assim o risco ao conluio individual de oracle/relayer. Os utilizadores finais precisam de confiar que ou o LayerZero, um terceiro ou a própria aplicação está a executar o oracle e o relayer de forma independente e sem intenções maliciosas.

Em ambas as abordagens, a reputação das entidades de terceiros participantes desincentiva o comportamento malicioso. Estas são normalmente entidades respeitadas dentro da comunidade validadora e oracle e arriscam consequências reputacionais e um impacto negativo nas suas outras atividades comerciais se agirem de forma maliciosa.

Para além dos pressupostos de confiança e do futuro da interoperabilidade

Considerando a segurança e a usabilidade de uma solução AMP, precisamos também de ter em conta os detalhes para além dos mecanismos básicos. Como se tratam de partes móveis que podem mudar ao longo do 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, bounties de bugs bem planejadas e várias implementações de clientes. Se todos os validadores (em segurança económica/otimista/reputacional) executarem o mesmo cliente (software para verificação), aumenta a dependência de uma única base de código e reduz a diversidade do cliente. O Ethereum, por exemplo, depende de vários clientes de execução como geth, nethermind, erigon, besu, akula. É provável que várias implementações numa variedade de linguagens aumentem a diversidade sem que qualquer cliente domine a rede, eliminando assim um potencial ponto único de falha. Ter vários clientes também pode ajudar com a vitalidade se uma minoria de validadores/signatários/clientes leves cair devido a exploits/bugs numa implementação específica.
• Configuração e capacidade de actualização: Os utilizadores e os programadores têm de estar cientes se os validadores/observadores podem aderir à rede sem permissão, caso contrário, a confiança é ocultada pela seleção de entidades autorizadas. As actualizações para contratos inteligentes também podem introduzir bugs que podem levar a explorações ou mesmo potencialmente alterar 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 são atualizáveis sujeitos à aprovação de um comité offline (limiar 4/8), no entanto, num futuro próximo, a Axelar planeia exigir que todos os validadores aprovem coletivamente quaisquer upgrades para os gateways. Os principais contratos do Wormhole são atualizáveis e são geridos através do sistema de governança on-chain da Wormhole. O LayerZero depende de contratos inteligentes imutáveis e bibliotecas imutáveis para evitar quaisquer actualizações, no entanto, pode enviar uma nova biblioteca, e dapps com configurações predefinidas receberão a versão atualizada, e os dapps com a sua versão definida manualmente precisariam configurá-la para a nova.
• MEV: Blockchains diferentes não são sincronizados através de um relógio comum e têm tempos diferentes para finalizar. Como resultado, a ordem e o tempo de execução na cadeia de destino podem variar entre as cadeias. MEV num mundo de cadeias cruzadas é um desafio de definir claramente. Introduz um trade-off entre a vida e a ordem de execução. Um canal encomendado garantirá a entrega encomendada de mensagens mas o canal fechará se uma mensagem se esgotar. Outra aplicação pode preferir um cenário em que a encomenda não é necessária mas a entrega de outras mensagens não é afectada.

Tendências e perspectivas futuras:

• Segurança personalizável e aditiva: Para melhor servir diversos casos de uso, as soluções AMP são incentivadas a oferecer mais flexibilidade aos programadores. A Axelar introduziu uma abordagem para a capacidade de actualizaçã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 programadores escolher entre várias opções, como segurança económica, segurança otimista, segurança dinâmica e segurança híbrida. O 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. O LayerZero permite que os programadores atualizem estes parâmetros. Esperamos que algumas soluções AMP continuem a oferecer mais flexibilidade mas estas opções de design merecem alguma discussão. As aplicações devem ser capazes de configurar a sua segurança, até que ponto, e o que acontece se as aplicações adoptarem uma arquitectura de design abaixo da média? A consciência dos utilizadores sobre os conceitos básicos por trás da segurança pode tornar-se 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 “Código de confiança/matemática”: Num final de jogo ideal, todas as mensagens entre cadeias serão minimizadas pela utilização de provas de conhecimento zero (ZK) para verificar mensagens e estados. Já estamos a testemunhar esta mudança com o surgimento de projetos como Polymer Labs e Succinct Labs. A Multichain também publicou recentemente um whitepaper do ZKRouter para permitir a interoperabilidade através de provas ZK. Com a recentemente anunciada Axelar Virtual Machine, os programadores podem alavancar o Amplificador Interchain para configurar sem permissão novas ligações à rede Axelar. Por exemplo, uma vez desenvolvidas provas robustas de clientes leves & ZK para o estado do Ethereum, um programador pode facilmente integrá-los à rede Axelar para substituir ou melhorar uma ligação existente. O LayerZero na sua documentação fala sobre a possibilidade de adicionar novas bibliotecas de mensagens de prova otimizadas no futuro. Projetos mais recentes como o Lagrange estão a explorar a agregação de várias provas de várias cadeias de origem e o Herodotus está a tornar as provas de armazenamento viáveis através das provas ZK. No entanto, esta transição levará tempo, uma vez que esta abordagem é difícil de escalar entre blockchains que contam com diferentes mecanismos e estruturas de consenso. O ZK é uma tecnologia relativamente nova e complexa que é desafiadora de auditar e, atualmente, a verificação e geração de provas não é a melhor relação custo-benefício. Acreditamos que, a longo prazo, para suportar aplicações de cadeia cruzada altamente escaláveis na cadeia de blocos, é provável que muitas soluções AMP complementem seres humanos e entidades de confiança com software verificável porque:
• A possibilidade de exploração de código pode ser minimizada através de auditorias e bounties de bugs. Com o passar do tempo, será mais fácil confiar nestes sistemas, pois a sua história servirá como prova da sua segurança.
• O custo de geração de provas ZK diminuirá. Com mais R & 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 reduzam significativamente, tornando-se uma abordagem mais económica.
• Os blockchains tornar-se-ão mais amigáveis ao zk. No futuro, os zkeVMS poderão fornecer uma prova sucinta de validade de execução, e soluções leves baseadas no cliente poderão verificar facilmente a execução e o consenso de uma cadeia de origem na cadeia de destino. No final do jogo do Ethereum, também existem planos para “zk-SNark tudo”, incluindo o consenso.
• Prova de humanidade/reputação/identidade: A segurança de sistemas complexos como as soluções AMP não pode ser encapsulada através de uma única estrutura e garante várias 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 os mecanismos de configuração e permissão.

No espírito de abertura da Web3, provavelmente veremos um futuro plural onde várias abordagens coexistem. Na verdade, as aplicações podem optar por usar várias soluções de interoperabilidade, seja de forma redundante, ou permitir que os utilizadores misturem e combinem com a divulgação de compensações. As soluções ponto a ponto podem ser priorizadas entre rotas de “tráfego intenso”, enquanto os modelos hub e spoke podem dominar a longa cauda das cadeias. No final, cabe a nós, o dem coletivo e dos utilizadores, construtores e colaboradores, moldar a topografia da web interligado3.

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 pela revisão e fornecimento dos 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/introducing-the-cross-chain-interoperability-protocol-ccip/
• debridge: https://docs.debridge.finance/
• IBC: https://tutorials.cosmos.network/academy/3-ibc/
• Camada Zero: https://layerzero.gitbook.io/docs/
• Multicadeias: https://docs.multichain.org/getting-started/introduction
• Nomad: https://docs.nomad.xyz/nomad-101/introduction
• Polymer Labs: 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
• Quadro 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 [medium]. Todos os direitos de autor pertencem ao autor original [LongHash Ventures]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.