Nos limites dos pools de mem

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. O 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 assume uma familiaridade básica com MEV. Alguns leitores podem querer começar por ler o nosso Explicação 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 mem, 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 a 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 mem a fornecer uma solução universal para o MEV. Destacamos as dificuldades e exploramos como os pools de mem podem ser projetados.

Como funcionam os pools de mem de criptografia

Existem muitas propostas para pools de mem, mas a estrutura geral para pools de mem é a seguinte:

1. Os utilizadores transmitem as suas transações encriptadas.
2. As transações criptografadas são confirmadas 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 o passo 3 (desencriptação de transações) representa um desafio importante: Quem desencripta, e e se a desencriptação não acontecer? Uma solução ingênua seria dizer que os próprios usuários desencriptam suas transações (neste caso, nem seria necessário encriptação, mas poderia simplesmente esconder compromissos). No entanto, esta abordagem é vulnerável: Um atacante pode realizar MEV especulativo.

Com o 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 desejada, 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 utilizadores possam enfrentar alguma penalização por não conseguirem descriptografar, mas isso é complicado de implementar. A penalização teria de ser a mesma para todas as transações encriptadas (uma vez que estão encriptadas e, portanto, indistinguíveis), mas também suficientemente elevada para desencorajar o MEV especulativo, mesmo contra alvos de alto valor. Isso exigiria amarrar muito capital, que deveria ser anónimo (para evitar vazar informações sobre quais transações são publicadas por quais utilizadores). E isso acabaria por custar aos utilizadores honestos em caso de um erro ou falha na rede que impeça a sua tentativa legítima de descriptografar.

Assim, a maioria das propostas sugere que as transações sejam encriptadas de tal forma que a decriptação seja garantidamente possível em algum momento no futuro — mesmo que o utilizador que publicou a transação fique offline ou não coopere. Isso pode ser alcançado de várias maneiras:

TEEs: Os utilizadores podem encriptar as suas transações para uma chave detida 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 determinado 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 mem criptografado é a sua capacidade de operar em transações em texto claro, reduzindo assim o spam onchain ao filtrar transações que seriam revertidas. No entanto, este método requer confiança no hardware.

Partilha de segredos e encriptação por limiar: Com esta abordagem, os utilizadores encriptam transações para uma chave que é partilhada por um comité, tipicamente um subconjunto de validadores. É necessário um limiar (por exemplo, dois terços do comité) para a decriptação.

A abordagem mais simples utiliza uma nova chave de decriptação partilhada em cada ronda (por exemplo, cada bloco ou época na Ethereum), que o comité reconstrói e publica após as transações serem ordenadas num bloco finalizado. Esta abordagem pode usar partilha secreta simples. A desvantagem é que isto revela todas as transações do pool de mem, mesmo aquelas que não foram incluídas num bloco. Esta abordagem também requer uma nova geração de chave distribuída (DKG) em cada ronda.

Uma abordagem melhor para a privacidade é descriptografar apenas as transações que foram realmente incluídas. Isso pode ser realizado usando a descriptografia por limiares. 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. Na prática, o trabalho do comitê é linear no número de transações a serem descriptografadas, embora recentetrabalhosugere a decriptação de limiar em lote, o que pode melhorar significativamente isso.

Com a decriptação por limiar, a confiança passa de um pedaço de hardware para um comitê. A alegaçã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 precocemente. Uma nota de cautela é necessária, no entanto: 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 (chamada de suposição de confiança fraca), enquanto um comitê malicioso decriptando transações precocemente 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, enquanto, de fora, as suposições de segurança para o consenso e um comitê de encriptação podem parecer as mesmas, considerações práticas tornam a suposição de que um comitê não irá coludir mais tenuosa.

Criptografia com atraso e bloqueio temporal: Uma alternativa à criptografia de limiar vem na forma de criptografia com atraso. Os usuários criptografam suas transações para uma chave pública cuja chave secreta está oculta dentro de um quebra-cabeça bloqueado pelo tempo. Um quebra-cabeça bloqueado pelo 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 descriptografado realizando repetidamente algum cálculo não paralelizável. Neste caso, esse quebra-cabeça pode ser aberto por qualquer pessoa para recuperar a chave e descriptografar 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 descriptografadas antes de serem finalizadas. A versão mais forte deste primitivo usa encriptação 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 em relação à criptografia de limiar sejam questionáveis.

Seja por criptografia de atraso ou computação por um comitê confiável, existem vários desafios práticos. Primeiro, é mais difícil garantir a temporização precisa da descriptografia, uma vez que o atraso é de natureza computacional. Em segundo lugar, esses esquemas dependem de alguma entidade que opere hardware sofisticado para resolver os quebra-cabeças de forma eficiente. Embora qualquer pessoa possa desempenhar 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 testemunhas) poderiam potencialmente apenas descriptografar transações que foram incluídas com sucesso.

Criptografia testemunhal. Por fim, a abordagem criptográfica mais avançada utiliza uma ferramenta chamada encriptação de testemunhas. Teoricamente, a encriptação por testemunha permite encriptar informações para qualquer pessoa que conhece o testemunho de uma relação NP específica. Por exemplo, poderia-se encriptar de forma que qualquer pessoa com a solução para um certo quebra-cabeça Sudoku, ou qualquer pessoa com uma pré-imagem de hash de um certo valor, possa descriptografar.

Os 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 mem, 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 atrasos são casos específicos. Infelizmente, não temos construções práticas de criptografia baseada em testemunhas. Além disso, mesmo que tivéssemos, não está claro como isso representa uma melhoria em relação a uma abordagem baseada em comitês para cadeias de proof-of-stake. Mesmo que a criptografia de testemunhas seja configurada de forma que as transações só possam ser descriptografadas 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 então usar essa cadeia privada como testemunha para descriptografar transações. Nesse ponto, usar a descriptografia por limiar pelo mesmo comitê fornece segurança equivalente e é muito mais simples.

A encriptação testemunhal oferece uma vantagem mais decisiva nos protocolos de consenso proof-of-work, uma vez que mesmo um comitê totalmente malicioso não consegue minerar vários novos blocos em cima do atual cabeçalho para simular a finalização.

Desafios técnicos para pools de mem

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

Primeiro, pode haver partes com acesso direto ao texto simples 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 o provedor de carteira. Consequentemente, o provedor de carteira tem acesso à transação em texto simples 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 metadados, ou seja, os dados que cercam a carga criptografada (transação), que não estão criptografados. Os pesquisadores podem usar esses metadados para adivinhar a intenção de uma transação e, em seguida, tentar MEV especulativo. Lembre-se, os pesquisadores 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 uma DEX específica.

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

• 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 feita nas definições formais de segurança semântica para excluir a ocultação do tamanho do texto simples que está sendo criptografado.) Este é um vetor de ataque clássico em comunicação criptografada. (Em um exemplo famoso, mesmo com criptografia, um bisbilhoteiro...pode determinar que vídeo está a ser transmitido em tempo real pela Netflix a partir do tamanho de cada pacote no fluxo de vídeo.) No contexto do pool de mem, certos tipos de transações podem ter um tamanho específico que vaza informações.

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

• Endereço IP de origem: Os pesquisadores podem inferir a identidade de um remetente de transação ao monitorar a rede peer-to-peer e observar o endereço IP de origem. Este problema foi na verdade identificado há mais de dez anos nos 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ção do remetente da transação e taxas/gas: Finalmente, as taxas de transação representam um tipo de metadado específico para pools de mem. No Ethereum, as transações incluem classicamente um endereço de remetente (onchain), que é utilizado para pagar as taxas, bem como um orçamento máximo de gas e uma taxa por unidade de gas que o remetente está disposto a pagar. O endereço do remetente, assim como o endereço da rede de origem, pode ser utilizado para vincular transações entre si e a entidades do mundo real. O orçamento de gas pode ser utilizado para estimar o que a transação pretende fazer. Por exemplo, interagir com um DEX específico pode exigir uma quantidade específica de gas que é identificável.

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

Toda esta informação poderia potencialmente estar oculta, mas a um custo de desempenho e complexidade. Por exemplo, o preenchimento de transações até um limite padrão oculta o tamanho da transação, mas desperdiça largura de banda e espaço na cadeia. Adicionar atrasos antes de enviar mensagens oculta o tempo da transação, mas prejudica a latência. Submeter transações através de uma rede de anonimato como o Tor poderia ocultar o endereço IP do remetente, mas isto tem os seus próprios desafios.

Os dados de taxa de transação são os metadados mais difíceis de ocultar. A encriptação 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 forem encriptados, então qualquer pessoa pode transmitir transações encriptadas malformadas que serão ordenadas, mas não terão capacidade de pagar taxas. Assim, após a decriptação, não poderão ser executadas, mas nenhuma parte poderá ser penalizada. Isso poderia ser possivelmente resolvido 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 os 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 encriptação desses dados interrompe este processo. Isso poderia ser resolvido estabelecendo uma taxa fixa em cada bloco, mas isso é economicamente ineficiente e pode incentivar mercados secundários para a inclusão de transações, o que minaria o objetivo de ter um pool de mem encriptado. A realização de um leilão de taxas usando computação multi-partidária segura ou hardware confiável é possível, mas ambos são passos caros.

Finalmente, pools de mem seguros e encriptados impõem sobrecarga no sistema de várias maneiras. A encriptação adiciona latência, sobrecarga computacional e de largura de banda à cadeia. Como combiná-la com suporte para 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 vitalidade (por exemplo, o comitê de decriptação para soluções de limiar ou solucionador de função de atraso). E certamente aumenta a complexidade de design e implementação.

Muitos dos problemas dos pools de mem associados à criptografia são partilhados por blockchains que visam garantir a privacidade das transações (por exemplo, Zcash, Monero). Se houver um lado positivo, é que resolver todos os desafios da criptografia para a mitigação do MEV teria como efeito colateral limpar o caminho para a privacidade das transações.

Desafios económicos para pools de mem

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

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

Não é difícil imaginar como seria isso, pois uma versão dela, chamada MEV Share, existe hoje. MEV Share é um leilão de fluxo de ordens que permite aos usuários submeter seletivamente informações sobre suas transações a um pool onde os pesquisadores competem pela chance de explorar a oportunidade de MEV apresentada pela transação. O pesquisador 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 mem, 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 que lhes são devolvidas e ficando felizes em abrir mão de suas informações. Existem também exemplos da finança tradicional (por exemplo, serviços de negociação sem taxas como a Robinhood) que lucram ao vender o fluxo de ordens de seus usuários para terceiros em um chamado " pagamento-por-fluxo-de-encomenda” modelo de negócios.

Outras possíveis situações incluem grandes construtores forçando os usuários a revelarem suas transações (ou alguma informação 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 recusar-se a sequenciar quaisquer transações encriptadas. Pode ser possível resolver este problema tecnicamente, se os utilizadores conseguirem produzir uma prova de conhecimento zero que a sua transação encriptada cumpre com a lista de censura, mas isso também acrescentará custo e complexidade. Mesmo que a cadeia tenha uma forte resistência à censura, onde as transações encriptadas são garantidas a ser incluídas, os construtores de blocos ainda podem priorizar colocar transações que conhecem em texto claro no topo do bloco e rebaixar quaisquer transações encriptadas para o fundo do bloco. Assim, transações que desejam certas garantias de execução podem ser forçadas a revelar os seus conteúdos aos construtores de qualquer maneira.

Outros desafios de eficiência

Os pools de mem 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 adiciona 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 toda a informação disponível, e as ineficiências surgem de atrasos e assimetrias de informação — consequências naturais dos pools de mem criptografados.

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

Da mesma forma, esta incerteza de preços pode também levar a transações MEV especulativas que tentam lucrar com a arbitragem onchain. É importante notar que estas oportunidades podem ser mais comuns com pools de mem porque a incerteza aumentada em torno do estado atual dos DEXs, à luz da execução atrasada, é suscetível de produzir mercados menos eficientes com discrepâncias de preços entre locais. Esses tipos de transações MEV especulativas também desperdiçariam espaço em bloco porque muitas vezes abortarão se não forem encontradas tais oportunidades.

Embora o nosso objetivo aqui tenha sido delinear os desafios nas pool de mem, para que as pessoas possam concentrar-se em construir e resolver coisas de outras maneiras, elas 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 mem e outras são ordenadas através 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 de engenharia significativa e aos custos de desempenho, os pools de mem criptografados são improváveis de serem a solução milagrosa para o MEV que às vezes se faz parecer. A comunidade precisará desenvolver outras soluções, incluindo leilões de MEV, defesas a nível 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 gerir os seus contras.

Pranav Garimidi é um Associado de Pesquisa na a16z Crypto. Ele faz pesquisas sobre problemas em design de mecanismos e teoria dos jogos algorítmicos na sua relação com sistemas de blockchain. Ele está especialmente focado em como os incentivos interagem através da pilha de blockchain. Antes da a16z, Pranav foi estudante na 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, da Universidade de Nova Iorque, e conselheiro técnico da a16z crypto. Sua pesquisa foca em criptografia aplicada e segurança de blockchain. Ele lecionou cursos de criptomoeda na Universidade de Melbourne, NYU, Stanford e Princeton, e obteve um doutoramento em ciência da computação pela Universidade de Cambridge e graus de BS/MS pela Stanford.

Lioba Heimbach é um estudante de doutoramento no quarto ano, aconselhado pelo Prof. Dr. Roger Wattenhofer em Computação Distribuída (Disco)grupo na ETH Zurich. Sua pesquisa centra-se em protocolos de blockchain com foco em finanças descentralizadas (DeFi). Em particular, concentra-se 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 pessoal individual da AH Capital Management, L.L.C. (“a16z”) citado e não são as opiniões de a16z ou suas afiliadas. Certas informações contidas aqui foram obtidas de fontes de terceiros, incluindo empresas de portfólio de fundos geridos por a16z. Embora tenham sido obtidas de fontes consideradas confiáveis, 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 determinada situação. Além disso, este conteúdo pode incluir anúncios de terceiros; a16z não revisou tais anúncios e não endossa qualquer conteúdo publicitário contido neles.

Este conteúdo é fornecido apenas para fins informativos e não deve ser considerado como aconselhamento legal, empresarial, de investimento ou fiscal. Você deve consultar seus próprios consultores 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 por quaisquer investidores ou investidores em potencial, e não pode, sob nenhuma circunstância, 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, acordo de subscrição e outros documentos relevantes de qualquer fundo e deve ser lida na íntegra.) Quaisquer investimentos ou empresas de portfólio mencionados, referidos ou descritos não são representativos de 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 forneceu permissão para a a16z divulgar 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, perspetivas e/ou opiniões expressas nestes materiais estão sujeitas a alterações sem aviso prévio e podem diferir ou ser contrárias a opiniões expressas por outros. Por favor, veja https://a16z.com/disclosures para informações adicionais importantes.

Isenção de responsabilidade:

1. Este artigo é reproduzido de [a16zcrypto]. Todos os direitos autorais pertencem ao autor original [Pranav GarimidiJoseph Bonneauandy Lioba Heimbach]. Se houver objeções a esta reimpressão, por favor entre em contacto com o Gate Learn equipe, e eles tratarão disso prontamente.
2. Declaração de Isenção de Responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer aconselhamento de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.