Nos limites dos pools de membros criptografados

O valor que pode ser extraído ao incluir, excluir ou reorganizar transações em um bloco é conhecido como "valor máximo extraível, ou MEV. MEV é comum na maioria das blockchains e tem sido um tópico de grande interesse e discussão na comunidade.

Nota: Este post do blog pressupõe familiaridade básica com MEV. Alguns leitores podem desejar começar lendo nosso Explicador de MEV.

Muitos pesquisadores, observando a situação do MEV, fizeram uma pergunta óbvia: A criptografia pode resolver o problema? Uma abordagem é um pool de membros criptografado, onde os usuários transmitem transações criptografadas que só são reveladas após serem sequenciadas. Assim, um protocolo de consenso teria que se comprometer com uma ordenação de transações de forma cega, aparentemente impedindo a capacidade de aproveitar as oportunidades de MEV durante o processo de ordenação.

Infelizmente, por razões práticas e teóricas, não vemos pools de membros criptografados fornecendo uma solução universal para MEV. Destacamos as dificuldades e exploramos como os pools de membros criptografados podem ser projetados.

Como funcionam os pools de membros criptografados

Houve muitas propostas para pools de membros criptografados, mas a estrutura geral para pools de membros criptografados é a seguinte:

1. Os usuários transmitem suas transações criptografadas.
2. As transações criptografadas são comprometidas na cadeia (em algumas propostas após serem provavelmente embaralhado aleatoriamente)
3. Após o bloco de compromisso ser finalizado, as transações são descriptografadas.
4. Finalmente, as transações são executadas.

Note que a etapa 3 (descriptografia da transação) representa um desafio importante: Quem descriptografa e e se a descriptografia não ocorrer? Uma solução ingênua seria dizer que os próprios usuários descriptografam suas transações (nesse caso, não seria nem necessário criptografar, mas poderia simplesmente ocultar os compromissos). No entanto, essa abordagem é vulnerável: Um atacante pode realizar MEV especulativo.

Com MEV especulativo, um atacante tenta adivinhar que uma determinada transação criptografada gera algum MEV. Eles criptografam suas próprias transações que, esperançosamente, aparecerão em um lugar oportuno (por exemplo, logo antes ou depois de uma transação alvo). Se a transação for sequenciada na ordem esperada, o atacante descriptografa e sua transação extrai o MEV. Caso contrário, eles optam por não descriptografar e sua transação não é incluída na cadeia final.

Talvez os usuários possam enfrentar alguma penalidade por não conseguirem descriptografar, mas isso é complicado de implementar. A penalidade precisaria ser a mesma para todas as transações criptografadas (já que estão criptografadas e, portanto, indistinguíveis), mas também grande o suficiente para desencorajar o MEV especulativo mesmo contra alvos de alto valor. Isso exigiria amarrar muito capital, que deve ser anônimo (para evitar vazamento de informações sobre quais transações são postadas por quais usuários). E isso acabaria custando aos usuários honestos no caso de um bug ou falha de rede que impeça sua tentativa legítima de descriptografar.

Portanto, a maioria das propostas sugere que as transações sejam criptografadas de tal maneira que a descriptografia seja garantida em algum momento no futuro — mesmo que o usuário que postou fique offline ou não coopere. Isso pode ser alcançado de várias maneiras:

TEEs: Os usuários podem criptografar suas transações para uma chave mantida por um Ambiente de Execução Confiável (TEE) enclave. Em algumas versões simples, o TEE é usado apenas para descriptografar transações após um certo prazo (o que requer alguma noção de tempo dentro do TEE). Abordagens mais avançadas usam o TEE para descriptografar transações e construir o bloco, ordenando-as com base em alguns critérios, como horários de chegada ou taxas. Uma vantagem dos TEEs em comparação com outras abordagens de pool de membros criptografadas é sua capacidade de operar em transações em texto simples, reduzindo assim o spam on-chain ao filtrar transações que seriam revertidas. No entanto, esse método requer confiança no hardware.

Compartilhamento secreto e criptografia de limiar: Com essa abordagem, os usuários criptografam transações para uma chave que é compartilhada por um comitê, tipicamente um subconjunto de validadores. Um limiar (por exemplo, dois terços do comitê) é necessário para a descriptografia.

A abordagem mais simples usa uma nova chave de decriptação compartilhada em cada rodada (por exemplo, cada bloco ou época no Ethereum), que o comitê reconstrói e publica após as transações serem ordenadas em um bloco finalizado. Essa abordagem pode usar compartilhamento secreto simples. A desvantagem é que isso revela todas as transações do pool de membros, mesmo aquelas que não foram incluídas em um bloco. Essa abordagem também requer uma nova geração de chave distribuída (DKG) em cada rodada.

Uma abordagem melhor para privacidade é descriptografar apenas as transações que foram realmente incluídas. Isso pode ser realizado usando descriptografia por limiar. Essa abordagem também permite amortizar o custo dos protocolos DKG, utilizando a mesma chave para múltiplos blocos, com o comitê descriptografando transações após serem ordenadas em um bloco finalizado. Um desafio é que o comitê tem que fazer muito mais trabalho. De forma ingênua, o trabalho do comitê é linear em relação ao número de transações a serem descriptografadas, embora recentetrabalhosugere a decriptação de limiar em lotes, que pode melhorar isso significativamente.

Com a decriptação por limiar, a confiança se desloca de um dispositivo de hardware para um comitê. A afirmação é que, uma vez que a maioria dos protocolos já faz uma suposição de maioria honesta sobre os validadores para o protocolo de consenso, podemos fazer uma suposição semelhante de que a maioria dos validadores é honesta e não irá decriptar transações antecipadamente. No entanto, uma nota de cautela é necessária: estas não são a mesma suposição de confiança. Falhas de consenso como a bifurcação da cadeia são visíveis publicamente (chamadas de suposição de confiança fraca), enquanto um comitê malicioso decriptando transações antecipadamente gerará nenhuma evidência pública e, portanto, tal ataque não pode ser detectado ou penalizado (uma suposição de confiança forte). Assim, embora, do exterior, as suposições de segurança para consenso e um comitê de criptografia possam parecer as mesmas, considerações práticas tornam a suposição de que um comitê não irá coludir mais tenuosa.

Criptografia com bloqueio de tempo e atraso: Uma alternativa à criptografia de limiar vem na forma de criptografia de atraso. Os usuários criptografam suas transações para uma chave pública cuja chave secreta está oculta dentro de um quebra-cabeça com bloqueio de tempo. Um quebra-cabeça com bloqueio de tempo é um quebra-cabeça criptográfico que encapsula um segredo, que só pode ser revelado após um determinado período de tempo ter decorrido – mais especificamente, o quebra-cabeça pode ser decifrado realizando repetidamente algum cálculo não paralelizável. Nesse caso, esse quebra-cabeça pode ser aberto por qualquer pessoa para recuperar a chave e decifrar transações, mas apenas após um cálculo lento (inherentemente sequencial) que é projetado para levar tempo suficiente para que as transações não possam ser decifradas antes de serem finalizadas. A versão mais forte deste primitivo usacriptografia de atraso gerar publicamente tal quebra-cabeça. Também pode ser aproximado usando um comitê de confiança para calcular o quebra-cabeça via criptografia de bloqueio temporal, embora nesse ponto as vantagens sobre a criptografia de limiar sejam questionáveis.

Seja por criptografia de atraso ou computação por um comitê de confiança, existem vários desafios práticos. Primeiro, é mais difícil garantir um tempo preciso de descriptografia, uma vez que o atraso é de natureza computacional. Em segundo lugar, esses esquemas dependem de alguma entidade que execute hardware sofisticado para resolver os quebra-cabeças de maneira eficiente. Embora qualquer um possa cumprir esse papel, não está claro como incentivar essa parte. Finalmente, nesses designs, todas as transações transmitidas serão descriptografadas, incluindo aquelas que nunca foram finalizadas em um bloco. Soluções baseadas em limiares (ou criptografia de testemunha) poderiam potencialmente descriptografar apenas transações que foram incluídas com sucesso.

Criptografia de testemunhas. Finalmente, a abordagem criptográfica mais avançada usa uma ferramenta chamada criptografia de testemunhas. Teoricamente, a criptografia por testemunha permite criptografar informações para qualquer um que conheça o testemunho de uma relação NP específica. Por exemplo, pode-se criptografar de forma que qualquer pessoa com a solução de um determinado quebra-cabeça Sudoku, ou qualquer pessoa com uma pré-imagem de hash de um determinado valor, possa descriptografar.

SNARKs também são possíveis para qualquer relação NP. Pode-se pensar na criptografia de testemunhas como a criptografia de dados para qualquer pessoa que possa calcular um SNARK provando uma condição desejada. Para pools de membros criptografados, um exemplo de tal condição seria que as transações só podem ser descriptografadas quando um bloco foi finalizado.

Este é um primitivo teórico muito poderoso. De fato, é uma generalização para a qual abordagens baseadas em comitês e abordagens baseadas em atraso são casos específicos. Infelizmente, não temos nenhuma construção prática de criptografia baseada em testemunhas. Além disso, mesmo que tivéssemos, não está claro como isso é uma melhoria em relação a uma abordagem baseada em comitês para cadeias de proof-of-stake. Mesmo se a criptografia de testemunhas for configurada de modo que as transações possam ser descriptografadas apenas uma vez que estejam ordenadas em um bloco finalizado, um comitê malicioso ainda pode simular privadamente o protocolo de consenso de forma que a transação seja finalizada e, em seguida, usar essa cadeia privada como uma testemunha para descriptografar transações. Nesse ponto, usar a descriptografia por limiares pelo mesmo comitê oferece segurança equivalente e é muito mais simples.

A criptografia de testemunha oferece uma vantagem mais decisiva em protocolos de consenso de prova de trabalho, uma vez que até mesmo um comitê totalmente malicioso não consegue minerar vários novos blocos em cima do cabeçalho atual para simular a finalização.

Desafios técnicos para pools de membros criptografados

Vários desafios práticos importantes limitam a capacidade dos pools de membros criptografados de prevenir MEV. Em geral, manter informações confidenciais é difícil. Curiosamente, a criptografia é uma ferramenta raramente usada no espaço web3. Mas temos décadas de experiência prática que mostram os desafios de implantar criptografia na web (TLS/HTTPS) e para comunicação privada (de PGP a plataformas modernas de mensagens criptografadas como Signal ou Whatsapp). Embora a criptografia seja uma ferramenta para preservar a confidencialidade, ela não a garante.

Primeiro, podem haver partes com acesso direto ao texto claro da transação de um usuário. Em casos típicos, os usuários podem não criptografar sua própria transação, mas terceirizar isso para seu provedor de carteira. Consequentemente, o provedor de carteira tem acesso à transação em texto claro e poderia usar ou vender essa informação para extrair MEV. A criptografia nunca é mais forte do que o conjunto de partes com acesso à chave.

Além disso, o maior problema é a metadata, ou seja, os dados que cercam a carga útil criptografada (transação), que não estão criptografados. Os buscadores podem usar essa metadata para adivinhar a intenção de uma transação e, em seguida, tentar MEV especulativo. Lembre-se de que os buscadores não precisam entender completamente uma transação ou estar certos todas as vezes. É suficiente se eles souberem, por exemplo, que com alguma probabilidade razoável uma transação representa uma ordem de compra de um DEX específico.

Podemos considerar vários tipos de metadados, alguns dos quais são desafios clássicos com criptografia e alguns dos quais são únicos para pools de membros criptografados.

• Tamanho da transação: A criptografia por si só não oculta o tamanho do texto simples criptografado. (Há, notoriamente, uma exceção específica nas definições formais de segurança semântica para excluir a ocultação do tamanho do texto simples que está sendo criptografado.) Esta é uma vetor de ataque clássico em comunicação criptografada. (Em um exemplo famoso, mesmo com criptografia, um invasorpode determinar qual vídeoestá sendo transmitido ao vivo pela Netflix em tempo real a partir do tamanho de cada pacote no fluxo de vídeo.) No contexto do pool de membros criptografado, certos tipos de transações podem ter um tamanho específico que vaza informações.

• Tempo de transmissão: A criptografia também não oculta informações de tempo (outro vetor de ataque clássico). No contexto web3, certos remetentes — por exemplo, na venda estruturada — podem realizar transações em intervalos regulares. A temporização das transações também pode estar correlacionada com outras informações, como atividade em exchanges externas ou eventos noticiosos. Uma maneira mais sutil de explorar informações de temporização é a arbitragem CEX/DEX. Um sequenciador pode se beneficiar ao inserir uma transação criada o mais tarde possível, aproveitando informações mais recentes sobre os preços CEX. O mesmo sequenciador poderia excluir qualquer outra transação (mesmo que criptografada) transmitida após um determinado ponto no tempo, garantindo que sua transação tenha a vantagem das informações de preço mais atualizadas.

• Endereço IP de origem: Os buscadores podem inferir a identidade do remetente de uma transação monitorando a rede peer-to-peer e observando o endereço IP de origem. Este problema foi, na verdade,identificado há mais de dez anosnos primeiros dias do Bitcoin. Isso pode ser útil para os pesquisadores se remetentes específicos tiverem padrões específicos — por exemplo, saber quem é o remetente pode permitir vincular uma transação criptografada a transações anteriores que já foram descriptografadas.

• Informações sobre o remetente da transação e taxa/gás: Por fim, as taxas de transação representam um tipo de metadados específico para pools de membros criptografados. No Ethereum, as transações incluem classicamente um endereço de remetente (onchain), que é usado para pagar taxas, bem como um orçamento máximo de gás e uma taxa por unidade de gás que o remetente está disposto a pagar. O endereço do remetente, assim como o endereço da rede de origem, pode ser usado para vincular transações entre si e a entidades do mundo real. O orçamento de gás pode ser usado para estimar o que a transação pretende fazer. Por exemplo, interagir com um DEX específico pode exigir uma quantidade específica de gás que é identificável.

Pesquisadores sofisticados podem usar qualquer combinação dos tipos de metadados acima para prever o conteúdo de uma transação.

Todas essas informações poderiam potencialmente ser ocultadas, mas a um custo de desempenho e complexidade. Por exemplo, transações com preenchimento até um limite padrão ocultam o tamanho da transação, mas desperdiçam largura de banda e espaço na blockchain. Adicionar atrasos antes de enviar mensagens oculta o tempo da transação, mas prejudica a latência. Enviar transações através de uma rede de anonimato como o Tor poderia ocultar o endereço IP do remetente, mas isso tem seus próprios desafios.

Os dados de taxa de transação são os metadados mais difíceis de ocultar. A criptografia desses dados cria uma série de desafios para o construtor. O primeiro problema é o spam. Se os dados de pagamento da taxa de transação estiverem criptografados, então qualquer um pode transmitir transações criptografadas malformadas que serão ordenadas, mas não terão capacidade de pagar as taxas. Assim, após a descriptografia, eles não poderão ser executados, mas nenhuma parte poderá ser penalizada. Isso poderia ser possivelmente abordado com SNARKs que provam que uma transação está bem formada e financiada, mas isso aumentaria muito a sobrecarga.

O segundo problema é a construção eficiente de blocos e leilões de taxas. Os construtores usam taxas para construir o bloco mais lucrativo e estabelecer o preço de mercado atual para recursos onchain. A criptografia desses dados interrompe esse processo. Isso poderia ser resolvido estabelecendo uma taxa fixa em cada bloco, mas isso é economicamente ineficiente e pode incentivar mercados secundários para inclusão de transações que prejudicariam o objetivo de ter um pool de membros criptografado. Realizar um leilão de taxas usando computação segura multiparte ou hardware confiável é possível, mas essas são ambas etapas caras.

Finalmente, pools de membros seguros e criptografados impõem sobrecarga ao sistema de várias maneiras. A criptografia adiciona latência, sobrecarga computacional e de largura de banda à cadeia. Como combiná-la com suporte a sharding ou execução paralela — que são metas futuras importantes — está longe de ser óbvio. Isso pode adicionar pontos adicionais de falha para a vivacidade (por exemplo, o comitê de descriptografia para soluções de limiar ou solucionador de função de atraso). E isso certamente aumenta a complexidade de design e implementação.

Muitos dos problemas das mempools criptografadas são compartilhados por blockchains que visam garantir a privacidade das transações (por exemplo, Zcash, Monero). Se há um lado positivo, é que resolver todos os desafios da criptografia para a redução de MEV teria, como efeito colateral, o caminho livre para a privacidade das transações.

Desafios econômicos para pools de membros criptografados

Finalmente, os pools de membros criptografados enfrentam desafios econômicos. Ao contrário dos desafios técnicos, que podem ser potencialmente mitigados com esforço de engenharia suficiente, essas são limitações fundamentais que parecem difíceis de resolver.

O problema básico do MEV resulta da assimetria de informações entre os usuários que criam transações e os buscadores e construtores que encontram oportunidades de MEV. Os usuários geralmente não sabem quanto MEV pode ser extraído de suas transações. Como resultado, mesmo com um pool de membros criptografado perfeito, os usuários podem ser induzidos a abrir mão de suas chaves de decriptação em troca de um pagamento dos construtores que é menor do que o valor extraído. Podemos chamar isso de decriptação incentivada.

Não é difícil imaginar como isso seria, pois uma versão dele, chamada MEV Share, existe hoje. MEV Share é um leilão de fluxo de ordens que permite aos usuários enviar seletivamente informações sobre suas transações para um pool onde os buscadores competem pela chance de explorar a oportunidade de MEV apresentada pela transação. O buscador com a oferta vencedora extrai o MEV e reembolsa parte de seu lucro (ou seja, a oferta ou uma fração da oferta) ao usuário.

Este modelo poderia ser imediatamente adaptado dentro de um espaço de pool de membros criptografado, exigindo que os usuários revelassem suas chaves de decriptação (ou possivelmente apenas algumas informações parciais) para participar. Mas a maioria dos usuários não entenderá o custo de oportunidade de participar de tal esquema, vendo apenas as recompensas voltando para eles e felizes por abrir mão de suas informações. Também há exemplos da finança tradicional (por exemplo, serviços de negociação sem taxas como Robinhood) que lucram ao vender o fluxo de ordens de seus usuários para terceiros em um chamado " pagamento-para-fluxo-de-pedido” modelo de negócios.

Outras possíveis cenários incluem grandes construtores forçando os usuários a revelarem suas transações (ou algumas informações sobre elas) por razões de censura. A resiliência à censura é um tópico importante e controverso dentro do web3, mas se grandes proponentes e/ou construtores forem legalmente obrigados a aplicar uma lista de censura (por exemplo, por OFAC), eles podem se recusar a sequenciar quaisquer transações criptografadas. Pode ser possível resolver esse problema tecnicamente, se os usuários puderem produzir uma prova de conhecimento zero de que sua transação criptografada está em conformidade com a lista de censura, mas isso também adicionará custo e complexidade. Mesmo que a cadeia tenha uma forte resistência à censura, onde transações criptografadas têm a garantia de serem incluídas, os construtores de blocos ainda podem priorizar a colocação de transações que conhecem em texto claro no topo do bloco e rebaixar quaisquer transações criptografadas para o final do bloco. Assim, transações que desejam certas garantias de execução podem ser forçadas a revelar seu conteúdo para os construtores, de qualquer forma.

Outros desafios de eficiência

Os pools de membros criptografados adicionam sobrecarga ao sistema de algumas maneiras óbvias. Os usuários devem criptografar transações e o sistema deve de alguma forma descriptografá-las. Isso aumenta o custo computacional e possivelmente aumenta o tamanho da transação. Como discutido acima, lidar com metadados pode agravar essas sobrecargas. No entanto, alguns outros custos de eficiência são menos óbvios. Em finanças, um mercado é considerado eficiente se o preço reflete todas as informações disponíveis, e ineficiências surgem de atrasos e assimetrias de informação — consequências naturais dos pools de membros criptografados.

Uma das consequências dessas ineficiências é o aumento da incerteza de preços, resultado do atraso adicional que os pools de membros criptografados introduzem. Assim, o número de falhas de negociação devido à superação da tolerância ao deslizamento de preços provavelmente aumentará e desperdiçará espaço na cadeia.

Da mesma forma, essa incerteza de preços também pode levar a transações especulativas de MEV que tentam lucrar com a arbitragem onchain. É importante notar que essas oportunidades podem ser mais amplas com pools de membros criptografados, porque a incerteza aumentada em torno do estado atual das DEXs, à luz da execução atrasada, provavelmente produzirá mercados menos eficientes com discrepâncias de preços entre os locais. Esses tipos de transações especulativas de MEV também desperdiçariam espaço em bloco, pois muitas vezes serão abortadas se tais oportunidades não forem encontradas.

Embora nosso objetivo aqui tenha sido delinear os desafios em pools de membros criptografados, para que as pessoas possam se concentrar em construir e resolver coisas de outras maneiras, eles podem ainda ser parte da solução para o MEV.

Uma possível solução são os designs híbridos, onde algumas transações são ordenadas de forma cega através de um pool de membros criptografado e algumas são ordenadas por meio de outra solução. Para certos tipos de transações — por exemplo, ordens de compra/venda de grandes participantes do mercado que podem criptografá-las/padronizá-las cuidadosamente e estão dispostos a pagar mais para evitar MEV — os designs híbridos podem ser a solução certa. Esses designs também podem fazer sentido para transações altamente sensíveis, como correções de bugs em um contrato de segurança com uma vulnerabilidade.

No entanto, devido às suas limitações tecnológicas, bem como à complexidade significativa de engenharia e sobrecargas de desempenho, pools de membros criptografados são improváveis de ser a solução milagrosa para MEV que às vezes se faz parecer. A comunidade precisará desenvolver outras soluções, incluindo leilões de MEV, defesas em camada de aplicação e minimização do tempo de finalização. O MEV será um desafio por algum tempo, e uma investigação cuidadosa é necessária para encontrar o equilíbrio certo de soluções para gerenciar suas desvantagens.

Pranav Garimidi é um Associado de Pesquisa na a16z Crypto. Ele faz pesquisas sobre problemas em design de mecanismos e teoria dos jogos algorítmica em relação a sistemas de blockchain. Ele está especialmente focado em como os incentivos interagem em toda a pilha de blockchain. Antes de a16z, Pranav foi aluno da Universidade de Columbia, onde se formou em Ciência da Computação.

Joseph Bonneau é Professor Associado no Departamento de Ciência da Computação do Courant Institute, Universidade de Nova York, e um conselheiro técnico da a16z crypto. Sua pesquisa se concentra em criptografia aplicada e segurança de blockchain. Ele lecionou cursos sobre criptomoeda na Universidade de Melbourne, NYU, Stanford e Princeton, e recebeu um PhD em ciência da computação da Universidade de Cambridge e graus de BS/MS de Stanford.

Lioba Heimbach é um estudante de doutorado do quarto ano orientado pelo Prof. Dr. Roger Wattenhofer em Computação Distribuída (Disco) grupo na ETH Zurich. Sua pesquisa se concentra em protocolos de blockchain com foco em finanças descentralizadas (DeFi). Em particular, ela se concentra em permitir um ecossistema de blockchain e DeFi acessível, descentralizado, justo e eficiente. Ela foi estagiária de pesquisa na a16z crypto durante o verão de 2024.

As opiniões expressas aqui são de indivíduos da AH Capital Management, L.L.C. (“a16z”) citados e não representam as opiniões da a16z ou de suas afiliadas. Certas informações contidas aqui foram obtidas de fontes de terceiros, incluindo empresas de portfólio de fundos geridos pela a16z. Embora sejam provenientes de fontes consideradas confiáveis, a a16z não verificou independentemente tais informações e não faz representações sobre a precisão atual ou duradoura das informações ou sua adequação para uma situação específica. Além disso, este conteúdo pode incluir anúncios de terceiros; a a16z não revisou tais anúncios e não endossa nenhum conteúdo publicitário contido neles.

Este conteúdo é fornecido apenas para fins informativos e não deve ser considerado como aconselhamento legal, comercial, de investimento ou tributário. Você deve consultar seus próprios conselheiros sobre esses assuntos. Referências a quaisquer valores mobiliários ou ativos digitais são apenas para fins ilustrativos e não constituem uma recomendação de investimento ou oferta para fornecer serviços de consultoria de investimento. Além disso, este conteúdo não é direcionado nem destinado ao uso de quaisquer investidores ou potenciais investidores e não pode, sob quaisquer circunstâncias, ser considerado ao tomar uma decisão de investir em qualquer fundo gerido pela a16z. (Uma oferta para investir em um fundo da a16z será feita apenas pelo memorando de colocação privada, contrato de subscrição e outros documentos relevantes de qualquer fundo e deve ser lida em sua totalidade.) Quaisquer investimentos ou empresas de portfólio mencionados, referidos ou descritos não representam todos os investimentos em veículos geridos pela a16z, e não há garantia de que os investimentos serão lucrativos ou que outros investimentos feitos no futuro terão características ou resultados semelhantes. Uma lista de investimentos feitos por fundos geridos pela Andreessen Horowitz (excluindo investimentos para os quais o emissor não concedeu permissão para que a a16z divulgasse publicamente, bem como investimentos não anunciados em ativos digitais negociados publicamente) está disponível em https://a16z.com/investments/.

O conteúdo fala apenas na data indicada. Quaisquer projeções, estimativas, previsões, metas, perspectivas e/ou opiniões expressas nestes materiais estão sujeitas a alterações sem aviso prévio e podem diferir ou ser contrárias às opiniões expressas por outros. Por favor, veja https://a16z.com/disclosures para informações adicionais importantes.

Aviso Legal:

1. Este artigo é reproduzido de [a16zcrypto]. Todos os direitos autorais pertencem ao autor original [Pranav GarimidiJoseph Bonneau andy Lioba Heimbach]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe, e eles lidarão com isso prontamente.
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 outras línguas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.