Parte 1 da nossa série sobre privacidade abordou o que a "privacidade" implica, como a privacidade em redes blockchain difere da privacidade web2 e por que é difícil alcançá-la em blockchains.

O principal argumento deste post é que se o estado final desejável é ter uma infraestrutura de privacidade programável que possa lidar com estados privados compartilhados sem nenhum ponto único de falha, então todos os caminhos levam ao MPC. Também exploramos a maturidade do MPC e suas suposições de confiança, destacamos abordagens alternativas, comparamos compensações e fornecemos uma visão geral da indústria.

Estamos todos construindo a mesma coisa? Continue lendo para descobrir.

Graças a Avishay (SodaLabs), Lukas (Taceo), Michael (Equilíbrio), e,Nico (Arcium) para as discussões que ajudaram a moldar esta postagem.

O que pode ser, livre do que foi

A infraestrutura de privacidade existente em blockchains é projetada para lidar com casos de uso muito específicos, como pagamentos privados ou votação. Esta é uma visão bastante limitada e reflete principalmente para o que os blockchains são atualmente utilizados (negociação, transferências e especulação).Tom Walpo colocou isso- A criptografia sofre de um Paradoxo de Fermi:

Além de aumentar a liberdade individual, acreditamos que a privacidade é um requisito para expandir o espaço de design das blockchains além do atual meta especulativo. Muitas aplicações exigem algum estado privado e/ou lógica oculta para funcionar corretamente:

• Estado oculto: A grande maioria dos casos de uso financeiro requer (no mínimo) privacidade de outros usuários e muitos jogos multiplayer são significativamente menos divertidos de jogar sem algum estado oculto (por exemplo, se todos na mesa de pôquer pudessem ver as cartas uns dos outros).
• Lógica oculta: Alguns casos de uso exigem ocultar alguma lógica, permitindo que outros usem o aplicativo, como um mecanismo de correspondência, estratégia de negociação on-chain, etc.

A análise empírica (tanto para web2 quanto para web3) mostra que a maioria dos usuários não está disposta a pagar mais ou passar por etapas adicionais para obter privacidade adicional, e concordamos que a privacidade não é um ponto de venda em si. No entanto, isso permite que novos casos de uso mais significativos existam em cima das blockchains - permitindo-nos sair do Paradoxo de Fermi.

Tecnologias de aprimoramento de privacidade (PETs) e soluções modernas de criptografia (“criptografia programável" ) são os blocos de construção fundamentais para realizar essa visão (consulte apêndicepara obter mais informações sobre as diferentes soluções disponíveis e suas compensações).

Três hipóteses que moldam nossas visões

Três hipóteses-chave moldam nossa visão de como acreditamos que a infraestrutura de privacidade em blockchains pode evoluir:

1. A criptografia será abstraída dos desenvolvedores de aplicativos: A maioria dos desenvolvedores de aplicativos não quer (ou sabe como) lidar com a criptografia necessária para a privacidade. É irracional esperar que eles implementem sua própria criptografia e construam cadeias de aplicativos privadas (por exemplo. Zcash ou Namada) ou aplicações privadas em cima de uma cadeia pública (por exemplo, Tornado Cash). Isso é simplesmente muita complexidade e sobrecarga, o que atualmente restringe o espaço de design para a maioria dos desenvolvedores (não pode criar aplicativos que exigem algumas garantias de privacidade). Devido a isso, acreditamos que a complexidade do gerenciamento da parte de criptografia deve ser abstraída dos desenvolvedores de aplicativos. Duas abordagens aqui são a infraestrutura de privacidade programável (um L1/L2 privado compartilhado) ou a "confidencialidade como serviço", que permite a terceirização de computação confidencial.
2. Muitos casos de uso (provavelmente mais do que pensamos) exigem um estado privado compartilhado: Como mencionado anteriormente, muitos aplicativos exigem algum estado e/ou lógica ocultos para funcionar corretamente. O estado privado compartilhado é um subconjunto disso, no qual várias partes computam sobre o mesmo pedaço de estado privado. Embora pudéssemos confiar em uma parte centralizada para fazê-lo por nós e chamar isso de um dia, idealmente queremos fazê-lo de maneira minimizada em confiança para evitar pontos únicos de falha. Provas de conhecimento zero (ZKPs) por si só não podem alcançar isso - precisamos alavancar ferramentas adicionais como ambientes de execução confiáveis (TEE), criptografia homomórfica totalmente (FHE) e/ou computação de várias partes (MPC).
3. Conjuntos de escudos maiores maximizam a privacidade: A maior parte das informações é revelada quando entrando ou saindoo conjunto blindado, então devemos tentar minimizar isso. Ter várias aplicações privadas construídas em cima do mesmo blockchain pode ajudar a fortalecer as garantias de privacidade ao aumentar o número de usuários e transações dentro do mesmo conjunto blindado.

Fim do Jogo da Infraestrutura de Privacidade

Com as suposições acima em mente - qual é o resultado final para a infraestrutura de privacidade em blockchains? Existe uma abordagem que seja adequada para cada aplicação? Uma tecnologia de aprimoramento de privacidade para governar todas elas?

Não exatamente. Todos eles têm compromissos diferentes e já estamos vendo eles serem combinados de várias maneiras. No total, identificamos 11 abordagens diferentes (ver apêndice).

Hoje, as duas abordagens mais populares para construir infraestrutura de privacidade em blockchains alavancam ZKPs ou FHE. No entanto, ambos têm falhas fundamentais:

• Protocolos de privacidade baseados em ZK com prova do lado do cliente podem oferecer garantias de privacidade robustas, mas não permitem que várias partes calculem sobre o mesmo estado privado. Isso limita a expressividade, ou seja, quais tipos de aplicativos os desenvolvedores podem criar.
• FHE permite a computação sobre dados criptografados e estado privado compartilhado, mas levanta a questão de quem possui esse estado, ou seja, quem detém a chave de descriptografia. Isso limita a força das garantias de privacidade e o quanto podemos confiar que o que é privado hoje permaneça assim amanhã.

Se o estado final desejável é ter uma infraestrutura de privacidade programável que possa lidar com o estado privado compartilhado sem qualquer ponto único de falha, então ambos os caminhos levam ao MPC:

Note que, embora essas duas abordagens estejam eventualmente convergindo, o MPC é utilizado para coisas diferentes:

• Redes ZKP: MPC é usado para adicionar expressividade, permitindo a computação sobre um estado privado compartilhado.
• Redes FHE: MPC é usado para aumentar a segurança e reforçar as garantias de privacidade distribuindo a chave de descriptografia para um comitê MPC (em vez de um único terceiro).

Embora a discussão esteja começando a mudar para uma visão mais matizada, as garantias por trás dessas diferentes abordagens permanecem pouco exploradas. Dado que nossos pressupostos de confiança se resumem aos do MPC, as três principais perguntas a serem feitas são:

1. Quão forte são as garantias de privacidade que os protocolos MPC podem fornecer em blockchains?
2. A tecnologia está madura o suficiente? Se não, quais são os gargalos?
3. Dada a força das garantias e o overhead que introduz, faz sentido em comparação com abordagens alternativas?

Vamos abordar essas perguntas com mais detalhes.

Analisando Riscos e Fraquezas com MPC

Sempre que uma solução usa FHE, sempre é preciso perguntar: "Quem detém a chave de descriptografia?". Se a resposta for "a rede", a pergunta seguinte é: "Quais entidades reais compõem essa rede?". Esta última questão é relevante para todos os casos de uso que dependem do MPC de alguma forma.

Origem: Palestra da Zama na ETH CC

O principal risco com o MPC é a colusão, ou seja, bastantes partes agindo maliciosamente e colaborando para descriptografar dados ou apropriar-se indevidamente de computação. A colusão pode ser acordada off-chain e só é revelada se as partes maliciosas fizerem algo óbvio (chantagem, cunhar tokens do nada, etc). Desnecessário dizer que isso tem implicações significativas para as garantias de privacidade que o sistema pode oferecer. O risco de colusão depende de:

• Qual é o limiar de partes maliciosas que o protocolo pode suportar?
• Quais partes compõem a rede e quão confiáveis elas são?
• Número de partes diferentes que participam da rede e sua distribuição - Existem vetores de ataque comuns?
• A rede é sem permissão ou com permissão (baseada em participação econômica vs reputação/legais)?
• Qual é a punição para comportamento malicioso? Coludir o jogo é teoricamente o resultado ótimo?

1. Quão fortes são as garantias de privacidade que os protocolos MPC podem oferecer em blockchains?

TLDR: Não tão forte quanto gostaríamos, mas mais forte do que depender apenas de um terceiro centralizado.

O limiar necessário para descriptografar depende do esquema MPC escolhido - em grande parte, um compromisso entre a vivacidade ("entrega garantida de saída") e a segurança. Você pode ter um esquema N/N que é muito seguro, mas que falha se apenas um nó fica offline. Por outro lado, os esquemas N/2 ou N/3 são mais robustos, mas têm um risco maior de colusão.

As duas condições a equilibrar são:

1. A informação secreta nunca é vazada (por exemplo, a chave de descriptografia)
2. A informação secreta nunca desaparece (mesmo se 1/3 das partes sair subitamente).

O esquema escolhido varia de acordo com as implementações. Por exemplo, Zama está mirando N/3, enquanto a Arcium está atualmente implementando um Regime N/Nmas depois visando também suportar esquemas com garantias de maior vivacidade (e maiores pressuposições de confiança).

Uma solução de compromisso ao longo desta fronteira de tradeoff seria ter uma solução mista:

• Comitê de alta confiança que lida com o manuseio da chave com, por exemplo, o limiar N/3.
• Comitês de computação que são rotativos e têm, por exemplo, um limite de N-1 (ou vários comitês de computação diferentes com características distintas para os usuários escolherem).

Embora isso seja atraente na teoria, também introduz complexidade adicional, como a interação do comitê de computação com o comitê de alta confiança.

Outra maneira de fortalecer as garantias de segurança é executar o MPC em hardware confiável para que as partes-chave sejam mantidas dentro de um enclave seguro. Isso torna mais difícil extrair ou usar as partes-chave para qualquer outra coisa que não seja definida pelo protocolo. Pelo menos ZamaeArciumestão explorando o ângulo TEE.

Riscos mais sutis incluem casos extremos em coisas como engenharia social, onde, por exemplo, um engenheiro sênior é contratado por todas as empresas incluídas no cluster MPC por mais de 10 a 15 anos.

2. A tecnologia está madura o suficiente? Caso não esteja, quais são os gargalos?

Do ponto de vista de desempenho, o desafio chave com MPC é o overhead de comunicação. Ele cresce com a complexidade da computação e o número de nós que fazem parte da rede (mais comunicação de ida e volta é necessária). Para casos de uso de blockchain, isso leva a duas implicações práticas:

1. Conjunto de operadores pequeno: Para manter o overhead de comunicação gerenciável, a maioria dos protocolos existentes está atualmente restrita a conjuntos de operadores pequenos. Por exemplo, a rede de descriptografia da Zama atualmente permite um máximo de 4 nós (embora eles planejem expandir para 16). Com base em benchmarks iniciais publicados pela Zama para sua rede de descriptografia (TKMS), leva de 0,5 a 1s para descriptografar mesmo com um cluster de 4 nós (o fluxo completo de ponta a ponta leva muito mais tempo). Outro exemplo é o Taceo's.Implementação MPC para o banco de dados iris da Worldcoin, que tem 3 partes (com a suposição de 2/3 de partes honestas).

1. Origem: Palestra Zama na ETH CC
2. Conjunto de operadores autorizados: Na maioria dos casos, o conjunto de operadores é autorizado. Isso significa que confiamos na reputação e em contratos legais em vez de segurança econômica ou criptográfica. O principal desafio com um conjunto de operadores sem permissão é que não há como saber se as pessoas estão conspirando off-chain. Além disso, seria necessário um bootstrap ou redistribuição regular da chave compartilhada para que os nós possam entrar/sair dinamicamente da rede. Embora os conjuntos de operadores sem permissão sejam o objetivo final e haja pesquisas em andamento sobre como estender um mecanismo de PoS para um MPC de limite (por exemplo, por Zama), a rota com permissão parece ser a melhor opção para agora.

Abordagens Alternativas

O coquetel de privacidade completo consiste em:

• FHE para computação privada delegada
• ZKP para verificação de que o cálculo FHE foi executado corretamente
• MPC para decifração de limiar
• Cada nó MPC é executado dentro de um TEE para segurança adicional

Isso é complexo, introduz muitos casos de borda inexplorados, tem alta sobrecarga e pode não ser praticamente viável por muitos anos. Outro risco é a falsa sensação de segurança que se pode obter ao adicionar vários conceitos complexos uns sobre os outros. Quanto mais complexidade e pressupostos de confiança adicionamos, mais difícil se torna raciocinar sobre a segurança da solução geral.

Vale a pena? Talvez, mas também vale a pena explorar abordagens alternativas que podem trazer eficiência computacional significativamente melhor às custas de garantias de privacidade apenas um pouco mais fracas. Como Lyron da Seismicobservado - devemos focar na solução mais simples que atenda aos nossos critérios de nível de privacidade exigido e compensações aceitáveis, em vez de superengenharia apenas por causa disso.

1. Usando MPC diretamente para computação geral

Se tanto ZK quanto FHE acabarem por recuar para as suposições de confiança do MPC, por que não usar o MPC para computação diretamente? Esta é uma pergunta válida e algo que equipes como Arcium, SodaLabs (usado por Cotiv2),Taceo, e Nillionestão tentando fazer. Observe que o MPC assume muitas formas, mas, das três abordagens principais, estamos nos referindo aqui a protocolos baseados em compartilhamento de segredos e circuitos ofuscados (GC), não a protocolos baseados em FHE que usam o MPC para descriptografia.

Embora o MPC já seja usado para cálculos simples, como assinaturas distribuídas e carteiras mais seguras, o principal desafio de usar o MPC para cálculos mais gerais é a sobrecarga de comunicação (aumenta tanto com a complexidade do cálculo quanto com o número de nós envolvidos).

Existem algumas maneiras de reduzir a sobrecarga, como fazer o pré-processamento (ou seja, as partes mais caras do protocolo) com antecedência e off-line - algo tanto ArciumeSodaLabsestão explorando. O cálculo é então executado na fase online, que consome parte dos dados produzidos na fase offline. Isso reduz significativamente o overhead de comunicação geral.

A tabela abaixo da SodaLabs mostra benchmarks iniciais sobre quanto tempo leva para executar diferentes opcodes 1.000 vezes em seu gcEVM (notado em microssegundos). Embora isso seja um passo na direção certa, ainda há muito trabalho a ser feito para melhorar a eficiência e expandir o conjunto de operadores além de alguns nós.

Origem: SodaLabs

O benefício da abordagem baseada em ZK é que você só usa MPC para casos de uso que requerem computação sobre um estado privado compartilhado. FHE compete mais diretamente com MPC e depende muito da aceleração de hardware.

2. Ambientes de Execução Confiáveis

Recentemente, houve um interesse renovado em TEEs, que podem ser aproveitados tanto de forma isolada (blockchains privadas baseadas em TEE ou coprocessadores) quanto em combinação com outras PETs, como soluções baseadas em ZK (usar apenas TEE para computação em estado privado compartilhado).

Embora as TEEs sejam, de certa forma, mais maduras e introduzam menos sobrecarga de desempenho, elas não estão isentas de desvantagens. Em primeiro lugar, as TEEs possuem diferentes pressupostos de confiança (1/N) e oferecem uma solução baseada em hardware em vez de software. Uma crítica frequentemente ouvida está relacionada ao passado vulnerabilidades do SGX, mas vale ressaltar que TEE ≠ Intel SGX. Os TEEs também exigem confiar no fornecedor de hardware e o hardware é caro (não acessível para a maioria). Uma solução para o risco de ataques físicos poderia ser a de executar TEEs no espaçopara coisas críticas da missão.

No geral, os TEEs parecem mais adequados para atestação ou casos de uso que precisam apenas de privacidade de curto prazo (decodificação de limiar, livros de pedidos escuros, etc). Para privacidade permanente ou de longo prazo, as garantias de segurança parecem menos atraentes.

3. DAC privado e outras abordagens que dependem de terceiros confiáveis para privacidade

A privacidade intermediada pode oferecer privacidade a outros usuários, mas as garantias de privacidade vêm exclusivamente da confiança em uma terceira parte (ponto único de falha). Embora se assemelhe à 'privacidade web2' (privacidade de outros usuários), ela pode ser fortalecida com garantias adicionais (criptográficas ou econômicas) e permitir a verificação da execução correta.

Comitês de disponibilidade de dados privados (DAC) são um exemplo disso; Os membros do DAC armazenam dados off-chain e os usuários confiam neles para armazenar corretamente os dados e fazer cumprir as atualizações de transição de estado. Outro exemplo disso é o Sequenciador Franqueadoproposto por Tom Walpo.

Embora essa abordagem faça grandes concessões nas garantias de privacidade, pode ser a única alternativa viável para aplicações de baixo valor e alto desempenho em termos de custo e desempenho (pelo menos por enquanto). Um exemplo é Protocolo de Lente, que planeja usar um DAC privado para obter feeds privados. Para casos de uso como o social on-chain, a compensação entre privacidade e custo/desempenho é provavelmente razoável por enquanto (dado o custo e a sobrecarga de alternativas).

4. Endereços Furtivos

Os endereços ocultos podem fornecer garantias de privacidade semelhantes à criação de um novo endereço para cada transação, mas o processo é automatizado nos bastidores e abstraído dos usuários. Para mais informações, consulte estevisão geral por Vitalik ou este imersão profunda em abordagens diferentes. Os principais players neste campo incluem UmbraeFluidkey.

Embora os endereços furtivos ofereçam uma solução relativamente simples, a principal desvantagem é que eles só podem adicionar garantias de privacidade para transações (pagamentos e transferências), não para computação de propósito geral. Isso os diferencia das outras três soluções mencionadas acima.

Além disso, as garantias de privacidade fornecidas pelos endereços furtivos não são tão fortes quanto as alternativas. O anonimato pode ser quebrado comanálise de agrupamento simples, especialmente se as transferências de entrada e saída não estiverem em uma faixa semelhante (por exemplo, receber $10.000, mas gastar em média $10-100 em transações cotidianas). Outro desafio com endereços furtivos é a atualização das chaves, que atualmente precisa ser realizada individualmente para cada carteira (os rollups de armazenamento de chaves podem ajudar a resolver esse problema). Do lado da experiência do usuário, protocolos de endereço furtivo também exigem abstração de conta ou um pagador para cobrir taxas se a conta não tiver o token de taxa (por exemplo, ETH).

Riscos para a nossa tese

Dado o ritmo acelerado de desenvolvimento e a incerteza geral em torno de diferentes soluções técnicas, existem vários riscos para a nossa tese de que o MPC seja o resultado final. As principais razões pelas quais talvez não precisemos do MPC de uma forma ou de outra incluem:

1. O estado privado compartilhado não é tão importante quanto o tornamos: nesse caso, a infraestrutura baseada em ZK está mais bem posicionada para vencer, pois possui garantias de privacidade mais fortes e menor sobrecarga do que o FHE. Já existem casos de uso em que os sistemas baseados em ZK funcionam bem para casos de uso isolados, como o protocolo de pagamentos privados.Payy.
2. A compensação no desempenho não vale o benefício em garantias de privacidade: pode-se argumentar que as suposições de confiança de uma rede MPC com 2-3 partes autorizadas não são significativamente diferentes de um único player centralizado e que o aumento significativo no custo/sobrecarga não vale a pena. Isso pode ser verdade para muitos aplicativos, particularmente aqueles de baixo valor e sensíveis ao custo (por exemplo, sociais ou jogos). No entanto, também há muitos casos de uso de alto valor em que a colaboração é atualmente muito cara (ou impossível) devido a questões legais ou grande atrito de coordenação. Este último é onde as soluções baseadas em MPC e FHE podem brilhar.
3. A especialização supera o design de propósito geral: construir uma nova cadeia e criar uma comunidade de usuários e desenvolvedores é difícil. Devido a isso, a infraestrutura de privacidade de propósito geral (L1/L2s) pode ter dificuldades em obter tração. Outra questão diz respeito à especialização; é muito difícil para um único projeto de protocolo abranger todo o espaço de compensação. Neste mundo, prevaleceriam soluções que oferecem privacidade para ecossistemas existentes (confidencialidade como serviço) ou casos de uso especializados (por exemplo, para pagamentos). Porém, somos céticos em relação a este último devido à complexidade que ele introduz aos desenvolvedores de aplicativos, que precisariam implementar alguma criptografia por conta própria (em vez de ser abstraído).
4. A regulamentação continua a impedir a experimentação em torno de soluções de privacidade: Este é um risco para qualquer pessoa que esteja construindo infraestrutura de privacidade e aplicativos com algumas garantias de privacidade. Os casos de uso não financeiros enfrentam menos riscos regulatórios, mas é difícil (ou impossível) controlar o que é construído em cima da infraestrutura de privacidade sem permissão. Pode ser que resolvamos os problemas técnicos antes dos regulatórios.
5. A sobrecarga dos esquemas baseados em MPC (Multi-party Computation) e FHE (Fully Homomorphic Encryption) ainda é muito alta para a maioria dos casos de uso: enquanto o MPC sofre principalmente com sobrecarga de comunicação, as equipes de FHE dependem muito da aceleração de hardware para melhorar seu desempenho. No entanto, se pudermos extrapolar a evolução do hardware especializado no lado ZK (Zero-Knowledge), levará muito mais tempo do que a maioria gostaria antes de termos hardware FHE pronto para produção. Exemplos de equipes trabalhando na aceleração de hardware FHE incluem Optalysys, fhela, e Nióbio.

Resumo

Em última análise, uma cadeia é tão forte quanto seu elo mais fraco. No caso da infraestrutura de privacidade programável, as garantias de confiança se resumem às do MPC se quisermos que ela possa lidar com estado privado compartilhado sem um único ponto de falha.

Embora esta peça possa soar crítica em relação ao MPC, não é. O MPC oferece uma grande melhoria ao status quo atual de depender de terceiros centralizados. O principal problema, em nossa opinião, é a falsa sensação de confiança em toda a indústria e as questões que estão sendo varridas para debaixo do tapete. Em vez disso, devemos lidar com as questões de frente e concentrar-nos na avaliação dos riscos potenciais.

Nem todos os problemas, no entanto, precisam ser resolvidos usando as mesmas ferramentas. Embora acreditemos que o MPC é o jogo final, abordagens alternativas são opções viáveis, desde que a sobrecarga para soluções alimentadas por MPC permaneça alta. Vale sempre a pena considerar qual abordagem melhor se adapta às necessidades/características específicas dos problemas que estamos tentando resolver e quais compensações estamos dispostos a fazer.

Mesmo que você tenha o melhor martelo do mundo, nem tudo é um prego.

Apêndice 1: Abordagens Diferentes Para a Privacidade em Blockchains

Tecnologias que melhoram a privacidade, ou PETs, têm como objetivo melhorar um ou mais aspectos mencionados acima. Mais concretamente, eles são soluções técnicas para proteger dados durante o armazenamento, processamento e comunicação.

Existem muitos PETs diferentes para escolher, mas os mais relevantes para a indústria blockchain incluem a sopa de três letras - ZKP, MPC, FHE e TEE - juntamente com métodos adicionais, como endereços ocultos:

Esses PETs podem ser combinados de várias maneiras para alcançar diferentes compensações e pressupostos de confiança. Também temos soluções que dependem de um terceiro confiável (privacidade intermediada), como comitês de disponibilidade de dados privados (DAC). Isso pode permitir privacidade de outros usuários, mas as garantias de privacidade vêm exclusivamente da confiança em um terceiro. Nesse sentido, se assemelha à "privacidade web2" (privacidade de outros usuários), mas pode ser fortalecido com garantias adicionais (criptográficas ou econômicas).

No total, identificamos 11 abordagens diferentes para garantir alguma privacidade em redes blockchain. Algumas das compensações observadas incluem:

• Privacidade confiável vs. privacidade minimizada de confiança (existe um único ponto de falha?)
• Abordagem de Hardware vs Software
• Instâncias isoladas versus combinação de vários PETs
• L1 vs L2
• Nova cadeia vs Privacidade adicional às cadeias existentes ("confidencialidade como serviço")
• Tamanho do conjunto blindado (Multi-chain > Single-chain > Aplicativo > Ativo único)

Apêndice 2: Visão geral do setor

Dentro dessas 11 categorias, muitas empresas diferentes estão trabalhando em uma ou mais soluções. Abaixo está uma visão geral (não exaustiva) do estado atual da indústria:

Aviso legal:

1. Este artigo é reproduzido a partir de [equilíbrio], Todos os direitos autorais pertencem ao autor original [Hannes Huitula]. Se houver objeções a essa reimpressão, entre em contato com o Gate Learnequipe e eles resolverão isso prontamente.
2. Isenção de responsabilidade: as 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 outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.