Parte 1 da nossa série de privacidade abordou o que "privacidade" implica, como a privacidade em redes blockchain difere da privacidade web2 e por que é difícil de alcançar 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 o estado privado compartilhado sem qualquer 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 a construir a mesma coisa? Continue a ler para descobrir.

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

O que pode ser, desembaraçado pelo 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 restrita e reflete principalmente para o que as blockchains são atualmente utilizadas (negociações, transferências e especulações). Como Tom Walpo colocou isso- A criptomoeda sofre de uma Paradoxo de Fermi:

Além de aumentar a liberdade individual, acreditamos que a privacidade é um pré-requisito para expandir o espaço de design das blockchains além da atual meta especulativa. Muitas aplicações requerem 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 um do outro).
• Lógica oculta: Alguns casos de uso requerem ocultar alguma lógica enquanto ainda permitem que outros usem a aplicação, como um mecanismo de correspondência, estratégia de negociação on-chain, etc.

A análise empírica (tanto da web2 como da web3) mostra que a maioria dos utilizadores não está disposta a pagar mais ou a passar por mais procedimentos para ter mais privacidade, e concordamos que a privacidade em si não é um ponto de venda. No entanto, ela permite que novos e (esperançosamente) mais significativos casos de uso existam em cima das blockchains - permitindo-nos sair do Paradoxo de Fermi.

Tecnologias de aprimoramento de privacidade (PETs) e soluções de criptografia moderna (“criptografia programável"}) são os blocos de construção fundamentais para realizar esta visão (verapê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 nossas visões de como acreditamos que a infraestrutura de privacidade em blockchains possa evoluir:

1. A criptografia será abstraída dos desenvolvedores de aplicativos: a maioria dos desenvolvedores de aplicativos não quer (ou não sabe como) lidar com a criptografia necessária para a privacidade. É irrazoável esperar que eles implementem sua própria criptografia e construam cadeias específicas de aplicativos privados (por exemplo, ZcashouNamada) ou aplicações privadas no topo 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 é possível 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 um serviço", que permite a terceirização de computação confidencial.
2. Muitos casos de uso (provavelmente mais do que pensamos) requerem um estado privado compartilhado: Como mencionado anteriormente, muitos aplicativos exigem algum estado oculto e/ou lógica para funcionar corretamente. Estado privado compartilhado é um subconjunto disso, onde várias partes computam sobre o mesmo pedaço de estado privado. Embora pudéssemos confiar em uma parte centralizada para fazer isso por nós e chamá-lo de um dia, idealmente queremos fazê-lo de uma maneira minimizada pela confiança para evitar pontos únicos de falha. Provas de conhecimento zero (ZKPs) sozinhas não podem alcançar isso - precisamos aproveitar ferramentas adicionais, como ambientes de execução confiáveis (TEE), criptografia totalmente homomórfica (FHE) e/ou computação multipartidária (MPC).
3. Conjuntos blindados maiores maximizam a privacidade: a maioria das informações é revelada quando entrando ou saindoo conjunto blindado, portanto, 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 protegido.

Fim do Jogo da Infraestrutura de Privacidade

Com as hipóteses acima em mente - qual é o objetivo final da infraestrutura de privacidade em blockchains? Existe uma abordagem adequada para cada aplicação? Uma tecnologia de aprimoramento de privacidade para governar todas elas?

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

Atualmente, as duas abordagens mais populares para a construção de infraestrutura de privacidade em blockchains utilizam ZKPs ou FHE. No entanto, ambas têm falhas fundamentais:

• Os protocolos de privacidade baseados em ZK com prova do lado do cliente podem oferecer fortes garantias de privacidade, mas não permitem que várias partes calculem sobre o mesmo estado privado. Isso limita a expressividade, ou seja, os tipos de aplicações que 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 permanece assim amanhã.

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

Note que, mesmo que essas duas abordagens acabem convergindo, a MPC é utilizada 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 a um comitê de MPC (em vez de a 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 nossas suposições de confiança se resumem às do MPC, as três perguntas-chave a fazer são:

1. Quão fortes 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. Dadas as garantias de força e o overhead que introduz, faz sentido comparado com abordagens alternativas?

Vamos abordar essas questões com mais detalhes.

Analisando Riscos e Fraquezas com o MPC

Sempre que uma solução utiliza FHE, é sempre necessário perguntar: "Quem detém a chave de desencriptação?". Se a resposta for "a rede", a pergunta de acompanhamento é: "Quais entidades reais compõem esta rede?". A última pergunta é relevante para todos os casos de uso que dependem de MPC de alguma forma.

Origem: Palestra Zama na ETH CC

O principal risco com o MPC é o conluio, ou seja, partes suficientes agindo maliciosamente e em conluio para desencriptar dados ou apropriar-se indevidamente do cálculo. O conluio pode ser acordado fora da cadeia e só é revelado se as partes maliciosas fizerem algo que seja óbvio (chantagem, cunhagem de tokens do nada, etc.). Escusado será dizer que isto tem implicações significativas para as garantias de privacidade que o sistema pode fornecer. O risco de colusão depende:

• Que limiar de partes maliciosas o protocolo pode suportar?
• Que partes compõem a rede e quão confiáveis são elas?
• Número de diferentes partes que participam na rede e a sua distribuição - Existem vetores de ataque comuns?
• A rede é sem permissão ou com permissão (baseada em participação econômica versus reputação/jurídica)?
• Qual é a punição para comportamento malicioso? É a conluência o resultado teoricamente ótimo do jogo?

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

TLDR: Não é tão forte como gostaríamos, mas mais forte do que depender apenas de uma terceira parte centralizada.

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

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

1. A informação secreta nunca é divulgada (por exemplo, a chave de desencriptação)
2. A informação secreta nunca desaparece (mesmo que 1/3 das partes saia repentinamente).

O esquema escolhido varia de acordo com as implementações. Por exemplo, Zama está visando N/3, enquanto a Arcium está atualmente implementando um Esquema N/Nmas posteriormente com a intenção de também suportar esquemas com maiores garantias de vivacidade (e maiores pressupostos de confiança).

Um compromisso ao longo desta fronteira de trade-off seria ter uma solução mista:

• Comité de alta confiança que faz o tratamento das chaves com, por exemplo, um limiar N/3.
• Comités de cálculo rotativos que têm, por exemplo, um limiar N-1 (ou vários comités de cálculo diferentes com características diferentes para os utilizadores 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 forma de reforçar as garantias de segurança é executar o MPC em hardware confiável, de modo que as partes das chaves sejam mantidas dentro de um enclave seguro. Isso torna mais difícil extrair ou usar as partes das chaves para qualquer outra coisa que não seja o que é definido pelo protocolo. Pelo menos Zama e Arciumestão explorando o ângulo da TEE.

Riscos mais sutis incluem casos limítrofes em torno de coisas como engenharia social, onde, por exemplo, um engenheiro sênior é empregado por todas as empresas incluídas no cluster MPC ao longo de 10-15 anos.

2. A tecnologia está suficientemente madura? Se não estiver, quais são os obstáculos?

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

1. Pequeno conjunto de operadores: Para manter o overhead de comunicação gerenciável, a maioria dos protocolos existentes atualmente está restrita a pequenos conjuntos de operadores. 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 nos benchmarks iniciais publicados pela Zama para sua rede de descriptografia (TKMS), leva 0,5-1s para descriptografar, mesmo com apenas um cluster de 4 nós (o fluxo completo e2e leva muito mais tempo). Outro exemplo é o Taceo’sImplementação do MPC para o banco de dados iris da Worldcoin, que tem 3 partidos (com uma assunção de partido honesto de 2/3).

1. Origem: Palestra Zama na ETH CC
2. Conjunto de operadores com permissão: Na maioria dos casos, o conjunto de operadores é permitido. Isso significa que confiamos na reputação e em contratos legais, em vez de segurança econômica ou criptográfica. O principal desafio de um conjunto de operadores sem permissão é que não há como saber se as pessoas entram em conluio fora da cadeia. Além disso, exigiria inicialização regular ou redistribuição do compartilhamento de chaves para que os nós pudessem 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 PoS para um MPC de limite (por exemplo, por Zama), a rota permitida parece ser o melhor caminho a seguir por enquanto.

Abordagens Alternativas

O cocktail completo de privacidade consiste em:

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

Isto é complexo, introduz muitos casos limite inexplorados, tem um alto custo adicional 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 múltiplos conceitos complexos uns sobre os outros. Quanto mais complexidade e pressuposições de confiança adicionamos, mais difícil se torna raciocinar sobre a segurança da solução global.

Vale a pena? Talvez, mas também vale a pena explorar abordagens alternativas que possam trazer uma eficiência computacional significativamente melhor em detrimento de garantias de privacidade ligeiramente mais fracas. As Lyron da Seismicanotado - devemos focar na solução mais simples que satisfaça nossos critérios para o nível de privacidade requerido e as compensações aceitáveis, em vez de superengenharia apenas por causa disso.

1. Usar MPC diretamente para computação geral

Se tanto ZK quanto FHE acabarem por recorrer às suposições de confiança do MPC, por que não usar o MPC diretamente para a computação? Esta é uma pergunta válida e algo que equipes como Gate têm considerado.Arcium, SodaLabs (usado porCOTIv2),TaceoeNillionestão tentando fazer. Note que MPC assume muitas formas, mas das três abordagens principais, estamos nos referindo aqui a protocolos baseados em compartilhamento de segredo e circuito embaralhado (GC), e não a protocolos baseados em FHE que usam MPC para descriptografia.

Embora o MPC já seja usado para cálculos simples, como assinaturas distribuídas e carteiras mais seguras, o principal desafio com o uso do MPC para computação mais geral é a sobrecarga de comunicação (cresce com a complexidade da computação e o número de nós envolvidos).

Existem algumas maneiras de reduzir o overhead, como fazer o pré-processamento (ou seja, as partes mais caras do protocolo) antecipadamente e offline - algo que ambosArcium e ainda SodaLabsestão explorando. A computação é então executada na fase online, que consome parte dos dados produzidos na fase offline. Isso reduz significativamente a sobrecarga de comunicação global.

A tabela abaixo da SodaLabs mostra benchmarks iniciais sobre o tempo necessário 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.

Fonte: SodaLabs

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

2. Ambientes de Execução Confiáveis

Recentemente, houve um renovado interesse em TEEs, que podem ser aproveitados quer de forma isolada (blockchains privados baseados em TEE ou co-processadores) ou em combinação com outros PETs, como soluções baseadas em ZK (usar apenas TEE para computação sobre estado privado compartilhado).

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

No geral, os TEEs parecem mais adequados para atestados ou casos de uso que só precisam de privacidade de curto prazo (descriptografia de limite, livros de pedidos escuros, etc.). Para a privacidade permanente ou a longo prazo, as garantias de segurança parecem menos atraentes.

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

A privacidade intermediada pode oferecer privacidade de 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), 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 dados corretamente e aplicar atualizações de transição de estado. Outra variante disso é o Sequenciador Franqueado proposto 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 planeia utilizar um CAD privado para obter feeds privados. Para casos de uso como o social on-chain, o compromisso entre privacidade e custo/desempenho é provavelmente razoável por enquanto (dado o custo e a sobrecarga das alternativas).

4. Endereços Ocultos

Os endereços furtivos podem fornecer garantias de privacidade semelhantes à criação de um novo endereço para cada transação, mas o processo é automatizado no backend e abstraído dos usuários. Para mais informações, consulte estevisão geral por Vitalikou istoimersão profunda em diferentes abordagens. Os principais jogadores 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 uso 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 com análise de clustering 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 diárias). Outro desafio com endereços ocultos é a atualização de chaves, que hoje precisa ser feita individualmente para cada carteira (os rollups de armazenamento de chaves podem ajudar com esse problema). Do lado da experiência do usuário, os protocolos de endereço oculto também requerem abstração de conta ou um pagador para cobrir taxas se a conta não tiver o token da 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 é o fim do jogo. As principais razões pelas quais podemos acabar não precisando de MPC de uma forma incluem:

1. O estado privado compartilhado não é tão importante quanto imaginamos: nesse caso, a infraestrutura baseada em ZK está mais bem preparada para vencer, pois tem garantias de privacidade mais fortes e menores despesas gerais do que a 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. O compromisso no desempenho não vale a pena em termos de 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 jogador centralizado e que o aumento significativo no custo/sobrecarga não vale a pena. Isso pode ser verdade para muitas aplicações, especialmente as de baixo valor e sensíveis a custos (por exemplo, sociais ou de jogos). No entanto, existem também muitos casos de uso de alto valor em que a colaboração é atualmente muito cara (ou impossível) devido a questões legais ou a uma grande fricção de coordenação. É aqui que as soluções baseadas em MPC e FHE podem se destacar.
3. A especialização supera o design de propósito geral: construir uma nova cadeia e iniciar 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 para obter tração. Outra questão diz respeito à especialização; é muito difícil para um único design de protocolo cobrir todo o espaço de compensação. Neste mundo, soluções que oferecem privacidade para ecossistemas existentes (confidencialidade como serviço) ou casos de uso especializados (por exemplo, para pagamentos) prevaleceriam. Somos céticos em relação a este último, devido à complexidade que introduz aos desenvolvedores de aplicativos que precisariam implementar alguma criptografia por si próprios (em vez de ser abstraído).
4. A regulamentação continua a dificultar a experimentação em torno de soluções de privacidade: isso é um risco para quem constrói tanto infraestrutura de privacidade quanto aplicações com algumas garantias de privacidade. Casos de uso não financeiros enfrentam menos risco regulatório, mas é difícil (impossível) controlar o que é construído em cima de infraestrutura de privacidade sem permissão. Podemos resolver os problemas técnicos antes dos regulatórios.
5. O overhead dos esquemas baseados em MPC e FHE ainda é muito alto para a maioria dos casos de uso: enquanto o MPC sofre principalmente do overhead 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 do ZK, 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 Niobium.

Resumo

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

Embora esta peça possa parecer crítica em relação à MPC, não é. A MPC oferece uma grande melhoria em relação ao atual status quo 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 os problemas que estão sendo escondidos. Em vez disso, devemos lidar com os problemas de frente e focar na avaliação dos riscos potenciais.

No entanto, nem todos os problemas precisam de ser resolvidos com as mesmas ferramentas. Embora acreditemos que o MPC é o objetivo final, abordagens alternativas são opções viáveis desde que o overhead para soluções baseadas em MPC permaneça elevado. Vale sempre a pena considerar qual a abordagem que melhor se adapta às necessidades/características específicas dos problemas que estamos a tentar resolver e que compromissos estamos dispostos a fazer.

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

Apêndice 1: Abordagens Diferentes para Privacidade em Blockchains

Tecnologias de melhoria da privacidade, ou PETs, visam melhorar um ou mais aspectos acima mencionados. Mais concretamente, são soluções técnicas para proteger dados durante o armazenamento, computação 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:

Estes 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 uma terceira parte de confiança (privacidade intermediada), como comités de disponibilidade de dados privados (DAC). Estes podem permitir privacidade face a outros utilizadores, mas as garantias de privacidade provêm unicamente da confiança numa terceira parte. Neste sentido, assemelha-se à “privacidade web2” (privacidade face a outros utilizadores), mas pode ser reforçada com garantias adicionais (criptográficas ou económicas).

No total, identificamos 11 abordagens diferentes para alcançar algumas garantias de privacidade em redes blockchain. Algumas das compensações observadas incluem:

• Privacidade confiável versus privacidade minimizada (Existe um único ponto de falha?)
• Abordagem Hardware vs Software
• Instâncias isoladas vs combinação de múltiplos PETs
• L1 vs L2
• Nova cadeia vs Privacidade adicional para cadeias existentes ("confidencialidade como serviço")
• Tamanho do conjunto blindado (Multi-chain > Single-chain > Aplicação > Ativo único)

Apêndice 2: Visão geral da indústria

Dentro destas 11 categorias, muitas empresas diferentes estão a trabalhar 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 é reimpresso de [equilíbrio], Todos os direitos autorais pertencem ao autor original [Hannes Huitula]. Se houver objeções a esta reimpressão, contacte o Gate Learn equipe, e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.