Segurança da carteira: a falácia 'não-custodial'

A expressão comumente citada “não suas chaves, não sua criptografia” transmite a filosofia purista de gerenciamento de chaves criptográficas. Neste modelo de segurança de carteira, apenas um indivíduo (ou um grupo via “multisig”) tem controle direto e exclusivo sobre suas próprias chaves privadas – e, portanto, tem a verdadeira propriedade de seus criptoativos. As carteiras criptográficas que aderem a esta abordagem linha-dura são chamadas de “sem custódia”, o que significa que nenhuma parte externa tem acesso às chaves.

Exceto, não tão rápido. A situação não é tão simples. Uma série de hacks de carteira “sem custódia” de alto perfil – incluindo o Hack de carteira inclinada que comprometeu mais de 8,000 contas em agosto, o Hack de carteira Trinity que perdeu mais de US$ 2 milhões em tokens IOTA em 2020, o Hack de carteira de paridade que permitiu que um invasor roubasse 150,000 ETH em 2017, além de descobertas de vários vulnerabilidades de carteira de hardwaree outros incidentes – mina a distinção convencional entre carteiras com e sem custódia. Em muitos desses casos, as vítimas que acreditavam estar usando uma carteira sem custódia descobriram que os invasores conseguiram sequestrar suas cobiçadas chaves. Uma contradição, não?

Na verdade, a história é mais complexa do que uma frase de efeito pode capturar. As carteiras sem custódia não dão realmente aos usuários o controle total de suas chaves. Isso porque as carteiras são normalmente criado e operado por meio de, software ou hardware de outra pessoa. Os usuários confiam constantemente em outras pessoas, produtos e programas de computador. Eles aceitam o uso de interfaces de linha de comando blockchain, software e dispositivos de carteira, plataformas centralizadas, código de contrato inteligente, aplicativos descentralizados e todas as diversas carteiras integrações de conexão intermediárias. Cada ponto de contato adiciona risco; a soma de todas estas partes interligadas destrói a ilusão da carteira sem custódia.

A tutela é, na verdade, não-binário. O que à primeira vista pode parecer não-custodial pode, na verdade, envolver muitos elementos de custódia cuja fiabilidade as pessoas muitas vezes tomam como certa. A dicotomia tradicional – prisão versus não prisão – é falsa. 

Em vez disso, é melhor considerar as carteiras com mais nuances. As principais perguntas a serem feitas são: Qual o tamanho da superfície de ataque que me sinto confortável em aceitar e quantas responsabilidades estou disposto a assumir na minha busca para eliminar a confiança em terceiros? Em geral, a gestão de chaves – a base da segurança da carteira – pode ser dividida em três áreas, cada uma das quais com oportunidades únicas de exposição. As subcategorias são as seguintes:

1. Geração de chave (criando chaves criptográficas)

2. Armazenamento de chaves (protegendo as chaves em repouso)

3. Uso da chave (colocando as chaves para funcionar)

Esta visão geral tem como objetivo ajudar os usuários do web3 a compreender melhor as complexidades envolvidas na proteção de seus ativos por meio da rubrica acima. Além disso, pretendemos ajudar os engenheiros a identificar e reforçar pontos frequentes de falha no desenvolvimento de carteiras. Esperamos que a aplicação deste guia - proveniente de nossos muitos anos de experiência combinada na construção de sistemas de criptografia e segurança em Docker, Anchorage, Facebook e criptografia a16z - ajude as pessoas a evitar contratempos de segurança, estejam elas interagindo, participando ou construindo tecnologia web3.

Abaixo, abordamos recursos comuns e armadilhas das plataformas de segurança e custódia de carteiras criptografadas conforme existem hoje. Também cobrimos áreas que acreditamos exigirem mais atenção e desenvolvimento nos próximos meses e anos para melhorar a segurança das experiências web3 dos usuários.

Segurança de carteira de geração de chaves

Qualquer discussão sobre segurança de carteira deve começar com a geração de chaves, o processo de criação de chaves criptográficas. Quer a carteira seja considerada com ou sem custódia, as propriedades de segurança da etapa de geração da chave são fundamentais para a segurança das chaves a partir de então. Durante a geração de chaves, há três preocupações gerais a serem lembradas: usar código confiável, implementar o código adequadamente e manipular a saída com segurança.

Se você não for um especialista em criptografia, pode ser difícil verificar se todos os fatores a seguir estão sendo seguidos de acordo com as regras. Verifique se você consegue acessar um relatório de auditoria confiável, que alguns provedores de carteira publicam em seus sites oficiais ou repositórios do Github. Em vez disso, faça sua própria pesquisa para tentar determinar se existe uma empresa respeitável por trás da carteira. Se as informações forem escassas, a atividade significativa de usuários e desenvolvedores pode ser o próximo indicador de reputação.

Siga estas diretrizes para reduzir sua exposição ao risco. Se uma carteira falhar nas verificações abaixo, fuja!

• Use carteiras que não geram suas próprias criptomoedas

Os criptógrafos têm um ditado: “não crie sua própria criptografia”. A essência é semelhante ao ditado “não reinvente a roda”. A roda está boa como está e qualquer tentativa de reconstruí-la do zero provavelmente resultará em um produto pior. O mesmo vale para a criptografia, uma ciência que é difícil de acertar. O código que compõe uma carteira deve ter a reputação de funcionar bem. Escolher software mal escrito – ou tentar desenvolver sua própria alternativa de novo – pode levar a acidentes, como vazamento de chaves ou revelação de informações secretas a partes não autorizadas. Isto é o que estava por trás de uma vulnerabilidade recentemente explorada em Ferramenta de endereço personalizado do Profanity. Antes de mais nada, deve ficar claro que a carteira em questão usa uma biblioteca e um processo de geração de chaves auditado e confiável.

• Use carteiras que medem duas vezes e cortam repetidas vezes

Mesmo que o código utilize bibliotecas de criptografia confiáveis, ele ainda deve ser integrado adequadamente. O software avaliado normalmente configurará os parâmetros corretos por padrão, mas pode haver lacunas na execução. Por exemplo, é necessária uma forte fonte de entropia, ou uma dose de aleatoriedade matemática, para tornar as chaves a serem geradas imprevisíveis e, portanto, mais seguras. Para certos processos de geração de chaves, como para muitos algoritmos de Computação Multipartidária (MPC), nos quais muitas chaves separadas – ou fragmentos, fragmentos de chaves – devem ser geradas e coordenadas, a carteira deve seguir o protocolo preciso conforme especificado pelo algoritmo. O algoritmo também pode exigir várias rodadas de computação, bem como chaves de atualização, que a carteira deve integrar adequadamente para manter a segurança dos fundos.

• Use uma carteira que possa guardar segredos

A fase final do processo de geração de chaves envolve a operação real e a saída do software. Esteja ciente de onde as chaves estão sendo geradas e de que forma.

O ideal é que as chaves sejam geradas em hardware isolado e as informações criptografadas com um algoritmo confiável. Um exemplo de padrão fraco a ser evitado é o Data Encryption Standard, ou DES, que hoje é considerado quebrado. As chaves deixadas em texto simples – especialmente na memória, no disco ou na zona intermediária entre esses dois locais conhecidos como “swap” – são um grande risco de segurança. Em geral, o material chave não deve sair do hardware em que é gerado e não deve escapar para redes acessíveis a terceiros. (Isto é, a menos que o material da chave seja criptografado, caso em que a chave de criptografia também deverá ser protegida.)

As chaves do Slope, a carteira que foi hackeada neste verão, foram registrados em texto simples em servidores externos após serem gerados. Esse é o tipo de lapso de segurança que poderia ter surgido em uma auditoria ou implementação de código aberto do código. As carteiras que carecem de transparência – apresentando código-fonte fechado, sem auditorias de segurança de terceiros disponíveis ao público – devem levantar sinais de alerta. 

Segurança da carteira de armazenamento de chaves

Depois que as chaves são geradas, eles precisarão ser guardados em algum lugar – nunca em texto simples, sempre criptografados. Mas apenas possuir o dispositivo no qual as chaves estão armazenadas não significa necessariamente propriedade e controle das chaves. Muitos fatores, como a segurança da cadeia de suprimentos do dispositivo, o grau de conexão do dispositivo e com quais outros componentes o dispositivo interage devem ser considerados. Além disso, cada método de armazenamento tem seu próprio conjunto de compromissos entre segurança, acessibilidade, facilidade de manutenção e usabilidade.

Abaixo, detalhamos as categorias mais comuns com base no nível de risco percebido associado. 

Maior risco: carteiras “quentes”

Na verdade, o conceito não tem muito a ver com temperatura. Quando se trata de opções de armazenamento de chaves, uma carteira é considerada “quente” se estiver conectada à Internet. Por outro lado, uma carteira é considerada “fria” se estiver offline e isolada. Se todo o resto for igual, as carteiras frias são mais seguras do que as carteiras quentes – mas também são mais difíceis de acessar e usar. Uma carteira conectada a qualquer rede é mais suscetível a hacks, pois permite aos invasores mais chances de acesso para descobrir e explorar vulnerabilidades.

As carteiras quentes podem assumir algumas formas.

• Software conectado: bancos de dados on-line, memória de aplicativos de telefone ou servidor web, extensões de navegador

Estas são as opções mais arriscadas. Aqui, o software da carteira, com custódia ou não, tem acesso direto às chaves – tudo isso enquanto está conectado à Internet externa. Idealmente, as chaves devem ser criptografadas, e o outro conjunto de chaves usado para criptografá-las deve ser armazenado em um sistema de gerenciamento de chaves (KMS) dedicado com controles de acesso altamente restritos, como um chaveiro do sistema operacional ou um sistema de gerenciamento de chaves na nuvem.

Para hot wallets baseadas em software, é fundamental isolar o gerenciamento de chaves e a autorização do restante dos componentes de software. Podem surgir problemas no registro, no gerenciamento de erros e no gerenciamento de memória (especialmente com base em heap, onde as chaves podem não ser “zeradas” ou apagadas adequadamente), e todos eles podem vazar por engano senhas, chaves de criptografia, chaves de assinatura ou outras informações confidenciais. material criptográfico. Quando isso acontece, os intrusos podem obter acesso não autorizado por meio de aplicativos conectados ou servidores web, ataques de canal lateral ou ameaças internas.

Não importa como um serviço se autodenomina, se as chaves de assinatura não forem criptografadas a qualquer momento na memória do sistema online, então o modelo deve ser considerado uma carteira de software quente. (Mesmo que as chaves sejam posteriormente armazenadas em repouso em um enclave seguro.)

• Hardware conectado: dispositivos para fins especiais, enclaves seguros móveis, módulos de segurança de hardware online (HSM)

O hardware conectado é geralmente considerado menos arriscado do que o software conectado, mas ainda não é tão seguro quanto o armazenamento frio. No hardware conectado, as chaves são geradas e ficam apenas dentro de dispositivos de hardware para fins especiais. Estes podem então ser conectados a redes internas ou públicas. Esses dispositivos geralmente assumem diversas responsabilidades relacionadas ao gerenciamento de chaves, incluindo segurança para geração, assinatura e armazenamento de chaves.

O hardware conectado vem em diversas variedades. Existem carteiras de hardware, como dispositivos Trezor e Ledger, que usuários de criptografia um pouco mais sofisticados costumam usar. (Muito mais pessoas deveriam usar esses dispositivos, pois eles são muito mais seguros do que usar apenas software conectado.) Existem também módulos de segurança de hardware, ou HSMs, que são comumente usados ​​em ambientes de negócios mais tradicionais, como aqueles que lidam com processamento de dados confidenciais. , como pagamentos com cartão de crédito.

Os dispositivos são tão seguros quanto a cadeia de fornecimento que os produziu e configurou. Ao considerar o hardware conectado, pergunte-se: Qual é a probabilidade de os dispositivos – ou firmware – terem sido adulterados antes de chegarem à sua posse? Para reduzir esse risco, é melhor comprar dispositivos diretamente de fornecedores confiáveis. Faça com que sejam enviados diretamente da fonte. Certifique-se de que as embalagens não pareçam comprometidas – sem rasgos, rasgos, lacres quebrados, etc. – o que pode indicar adulteração durante o transporte. Também é aconselhável verificar a versão e configuração do firmware antes de usar. As etapas para fazer isso variam dependendo do hardware, mas todas devem fornecer instruções.

Claro, sempre existe a possibilidade de uma carteira de hardware ser posteriormente roubada ou acessada por uma pessoa não autorizada. Dadas essas ameaças, é importante garantir que as carteiras de hardware também tenham camadas seguras de controle de acesso – salvaguardas que garantam que elas não assinem cegamente toda e qualquer transação. Os controles podem incluir requisitos de senha, solicitações de permissão explícita para cada etapa de uma transação e resumos simples em inglês que descrevem o que as transações estão realmente fazendo. Além disso, a maioria das carteiras de hardware oferece suporte à criptografia de chave privada, também conhecida como “envoltório de chave”. Melhor ainda, as carteiras seguras não permitirão que as chaves sejam exportadas em formato de texto simples, mesmo que se deseje que o sejam.

Este é o nível de segurança necessário para proteger verdadeiramente os ativos criptográficos.

Menos arriscado: carteiras “frias”

Menos calor, menor risco. As carteiras frias são, em igualdade de circunstâncias, geralmente consideradas mais seguras do que as quentes, embora também sejam geralmente menos utilizáveis. As carteiras frias são comumente chamadas de carteiras “airgapped”, o que significa que não têm conexão com nenhuma rede interna ou pública.

A solidão é uma virtude neste caso. Airgapping envolve a implementação de medidas rigorosas de isolamento físico e autorização. Essas medidas podem incluir o uso de gaiolas de Faraday (escudos que bloqueiam sinais sem fio), acesso biométrico (como leitores de impressão digital ou de íris), sensores de movimento (para disparar alarmes em caso de uso não autorizado) e SCIFs, ou Instalações de Informações Compartimentadas Sensíveis (especiais). áreas de processamento de informações classificadas).

Vamos revisar algumas opções de carteira fria com mais detalhes.

• Software Airgrapped: aplicativo de servidor offline

Como um invasor pode roubar ou colocar uma máquina online a qualquer momento, as carteiras frias devem ser projetadas com sistemas de segurança que resistam mesmo que sejam colocadas online. As chaves devem ser divididas em fragmentos de chave – exigindo que as peças sejam reunidas para se tornarem utilizáveis ​​– através de um método padrão, como o Compartilhamento Secreto de Shamir ou a Computação Multipartidária. Hardwares para fins especiais, como HSMs, são altamente recomendados em vez de softwares conectados, pois geralmente oferecem mais controles.

• Hardware Airgrapped: carteira de hardware offline, módulo de segurança de hardware offline (HSM)

Esta solução é considerada a mais segura de todas. Semelhante à categoria anterior, deve-se assumir que o hardware pode ser roubado e levado online. Por esse motivo, é novamente importante que estes sistemas incluam camadas de controle de acesso devidamente implementadas, conforme discutido anteriormente. Muitos fornecedores de HSM exigem que um quorum de smartcards físicos seja reunido antes que o acesso às chaves possa ser desbloqueado. Mesmo que o dispositivo não tenha tela, ele deve oferecer alguma forma para os usuários verificarem os detalhes das transações.

Como as carteiras frias ou sem ar são a categoria mais segura, a maioria dos fundos administrados por grandes jogadores são armazenados dessa maneira. Os principais serviços de varejo, como Coinbase, Gemini, Kraken e outros, bem como serviços para usuários institucionais, como Anchorage, estão entre aqueles que o fazem. Muitos desses jogadores optam por ter outra linha de defesa na forma de backups e recuperação, apenas no caso – Deus me livre – de perderem o acesso ou de as máquinas serem corrompidas, roubadas ou destruídas.

Backups e recuperação

As chaves de assinatura devem sempre ter backup após serem criptografadas. É fundamental ter redundância tanto das chaves de assinatura criptografadas quanto das chaves de encapsulamento de chaves. Os métodos para fazer backup de uma chave de assinatura são diferentes, mas deve-se sempre preferir soluções nativas de hardware.

Para carteiras de hardware, os backups geralmente envolvem uma frase inicial de texto simples de 12 palavras da qual as chaves privadas são derivadas. Esta frase-semente deve ser armazenada de forma não digital (pense em papel, metal) e da forma mais segura disponível (um cofre físico em casa, dentro de um cofre de banco). A frase pode ser dividida em partes distribuídas geograficamente para evitar o fácil comprometimento de todo o segredo. (As pessoas às vezes explicam essa abordagem fazendo referência às horcruxes fictícias que os bruxos das trevas usam efetivamente para “fazer backup” de suas almas. Harry Potter.)

Muitos HSMs lidam nativamente com alguns dos desafios relacionados ao backup e à recuperação. Os padrão possuem mecanismos que podem exportar chaves que são, por padrão, criptografadas com controles de acesso. Se os controles de acesso forem atendidos, as chaves poderão ser importadas para outros HSMs. De forma útil, frotas de HSMs também podem ser provisionadas com uma chave de criptografia comum, derivada de um quorum de cartões inteligentes. Desacoplar o hardware dos materiais principais dessa maneira ajuda a evitar pontos únicos de falha.

Finalmente, os fatores humanos precisam ser abordados. Os mecanismos de recuperação deverão ser capazes de resistir à indisponibilidade temporária ou permanente de qualquer indivíduo envolvido em operações de gestão de contas. Os indivíduos devem certificar-se de fornecer meios para que familiares próximos ou outras pessoas de confiança recuperem as chaves em caso de morte ou outras emergências. As operações do grupo, por sua vez, devem definir um quórum – como 2 em 3 ou 3 em 5, digamos – que possa funcionar razoavelmente apesar de acontecimentos da vida, viagens, doenças ou acidentes.

Segurança da carteira de uso de chaves

Depois que as chaves são geradas e armazenadas, elas podem ser usadas para criar assinaturas digitais que autorizam transações. Quanto mais componentes de software e hardware estiverem presentes, maior será o risco. Para reduzir o risco, as carteiras devem respeitar as seguintes diretrizes para autorização e autenticação.

• Confie mas verifique

As carteiras devem exigir autenticação. Por outras palavras, devem verificar se os utilizadores são quem dizem ser e se apenas as partes autorizadas podem aceder ao conteúdo da carteira. As salvaguardas mais comuns aqui são códigos PIN ou senhas. Como sempre, estes devem ser suficientemente longos e complexos – usando muitos tipos diferentes de caracteres – para serem eficazes ao máximo. Formas mais avançadas de autenticação podem incluir biometria ou aprovações baseadas em criptografia de chave pública, como assinaturas criptográficas de vários outros dispositivos seguros.

• Não lance sua própria criptografia (de novo!)

As carteiras devem usar bibliotecas de criptografia bem estabelecidas. Faça pesquisas para garantir que sejam auditados e seguros, a fim de evitar vazamento de material de chave ou perda total de chaves privadas. Para complicar a questão, mesmo bibliotecas confiáveis ​​podem ter interfaces inseguras, como aconteceu recentemente com essas bibliotecas Ed25519. Tome cuidado! 

• Reutilização única

Uma armadilha bem estudada no uso de chaves é a reutilização inadvertida de certos parâmetros de assinatura criptográfica. Alguns esquemas de assinatura podem exigir um nonce significando “número usado uma vez”, um número arbitrário destinado a ser usado apenas uma vez em um sistema. O Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA) é um desses esquemas de assinatura que faz isso. Se um nonce for reutilizado com ECDSA, isso poderá levar a um comprometimento importante. Vários outros algoritmos não são afetados, portanto, como sempre, certifique-se de que bibliotecas criptográficas bem estabelecidas estejam sendo usadas. (Certas bibliotecas criptográficas garantem nonces exclusivos por meio de hashing de dados de transação, que incluem outros dados exclusivos, como nonces de contas.) Mas esse vetor de ataque já foi explorado antes em hacks de alto perfil fora da web3, como este de 2010. Hack do Sony PlayStation 3.

• Uma chave por finalidade

Outra prática recomendada é evitar a reutilização de uma chave para mais de uma finalidade. Chaves separadas devem ser mantidas para criptografia e assinatura, por exemplo. Isto segue o princípio de “Ultimo privilégio”em caso de comprometimento, o que significa que o acesso a qualquer ativo, informação ou operação deve ser restrito apenas às partes ou código que absolutamente o exijam para o funcionamento do sistema. O princípio do “privilégio mínimo” pode, quando implementado corretamente, limitar drasticamente o raio de ação de um ataque bem-sucedido. Chaves diferentes terão requisitos diferentes para backups e gerenciamento de acesso, dependendo de sua finalidade. No contexto do web3, é uma prática recomendada separar chaves e frases iniciais entre ativos e carteiras, para que o comprometimento de uma conta não afete nenhuma outra.

Conclusão

A natureza de custódia ou não de custódia da propriedade de chaves não é tão clara como o pensamento convencional faria crer. A situação é complicada pelas muitas partes móveis envolvidas no gerenciamento de chaves – desde a geração de chaves até o armazenamento e o uso. Cada peça de hardware ou software ao longo da cadeia apresenta riscos que expõem até mesmo opções de carteira supostamente sem custódia a riscos do tipo custódia. 

Para o futuro, esperamos que seja feito mais trabalho de desenvolvimento para proteger as carteiras contra ataques e para mitigar os riscos discutidos acima. As áreas de melhoria incluem:

• Bibliotecas compartilhadas seguras de gerenciamento de chaves e assinatura de transações de código aberto em sistemas operacionais móveis e de desktop
• Estruturas compartilhadas de aprovação de transações de código aberto

Especificamente, ficaríamos particularmente entusiasmados em ver o desenvolvimento de software compartilhado e de código aberto:

• Bibliotecas de geração de chaves para implementar a melhor segurança da categoria em diferentes back-ends de armazenamento (criptografados em disco, hardware seguro, etc.)
• Bibliotecas de gerenciamento de chaves e assinatura de transações para sistemas operacionais móveis e de desktop
• Estruturas para fluxos de aprovação de transações que implementam verificação de fatores fortes, como biometria, aprovações baseadas em PKI, recuperação de autorização, etc.

A lista acima não é exaustiva, mas é um bom ponto de partida. Tudo isso para dizer que a situação é mais complicada do que indica o slogan “nem suas chaves, nem sua criptografia”. A posse de chaves é uma questão complicada, dadas as muitas partes e fases que interagem, desde a geração e armazenamento até o uso. 

Se você já está trabalhando em um projeto que aborda alguma das opções acima, ou está interessado em fazê-lo, entre em contato! Esperamos mais progressos nestas frentes.

***

Editor: Robert Hackett, @rhhackett

***

As opiniões expressas aqui são as do pessoal individual da AH Capital Management, LLC (“a16z”) citadas e não são as opiniões da a16z ou de suas afiliadas. Certas informações aqui contidas foram obtidas de fontes de terceiros, inclusive de empresas do portfólio de fundos administrados pela a16z. Embora retiradas de fontes consideradas confiáveis, a16z não verificou essas informações de forma independente e não faz representações sobre a precisão atual ou duradoura das informações ou sua adequação a uma determinada situação. Além disso, esse conteúdo pode incluir anúncios de terceiros; a16z não revisou tais anúncios e não endossa nenhum conteúdo de publicidade neles contido. 

Este conteúdo é fornecido apenas para fins informativos e não deve ser considerado como aconselhamento jurídico, comercial, de investimento ou fiscal. Você deve consultar seus próprios conselheiros sobre esses assuntos. As 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 potenciais investidores, e não pode, em nenhuma circunstância, ser invocado ao tomar uma decisão de investir em qualquer fundo administrado pela a16z. (Uma oferta para investir em um fundo a16z será feita apenas pelo memorando de colocação privada, contrato de subscrição e outra documentação relevante de tal 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 administrados pela a16z, e não pode haver garantia de que os investimentos serão rentáveis ​​ou que outros investimentos realizados no futuro terão características ou resultados semelhantes. Uma lista de investimentos feitos por fundos administrados por Andreessen Horowitz (excluindo investimentos para os quais o emissor não deu 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 /.

Os gráficos e gráficos fornecidos são apenas para fins informativos e não devem ser considerados ao tomar qualquer decisão de investimento. O desempenho passado não é indicativo de resultados futuros. O conteúdo fala apenas a partir da 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. Consulte https://a16z.com/disclosures para obter informações adicionais importantes.