Tendências de privacidade para 2026

Durante toda esta semana, estamos publicando nossas observações sobre as perspectivas para este ano... Fique de olho por aqui e não deixe de assinar nossa newsletter semanal para receber atualizações de tendências, relatórios do setor, guias para builders, análises de notícias e outros conteúdos exclusivos.

1. Privacidade será o principal diferencial competitivo em cripto neste ano

Privacidade é o fator determinante para que o sistema financeiro mundial migre para o onchain. No entanto, quase todas as blockchains atuais ainda carecem desse recurso essencial. Em muitos projetos, privacidade foi tratada como algo secundário. Agora, porém, ela se tornou um diferencial suficiente para destacar uma rede das demais.

Além disso, a privacidade gera um efeito ainda mais relevante: cria o lock-in da rede, um efeito de rede de privacidade. Principalmente em um cenário em que competir apenas por performance não é mais suficiente.

Com protocolos de bridge, migrar entre blockchains públicas é trivial. Quando as informações se tornam privadas, essa facilidade desaparece: transferir tokens é simples, mas transferir segredos é complexo. Sempre existe o risco de quem monitora a rede, o mempool ou o tráfego identificar o usuário ao movimentar-se entre zonas privadas e públicas. Ao cruzar a fronteira entre blockchains privadas e públicas — ou mesmo entre duas privadas — ocorre vazamento de metadados, como horários e valores das transações, facilitando o rastreamento.

Enquanto novas blockchains sem diferenciação tendem a ter taxas reduzidas a zero pela concorrência (o blockspace se tornou praticamente igual em todos os lugares), blockchains com privacidade podem criar efeitos de rede muito mais sólidos. Na prática, se uma blockchain “generalista” não possui um ecossistema vibrante, um killer app ou uma vantagem de distribuição, dificilmente atrairá usuários, builders ou fidelidade.

Em blockchains públicas, usuários transacionam facilmente entre redes — a escolha da rede é indiferente. Já em blockchains privadas, a escolha é decisiva: após ingressar, o usuário evita migrar para não se expor. Isso cria uma dinâmica de “o vencedor leva quase tudo”. Como a privacidade é fundamental para a maioria dos casos de uso reais, poucas blockchains privadas podem dominar o mercado cripto.

~Ali Yahya (@ alive_eth), sócio geral da a16z crypto

2. A questão para aplicativos de mensagens este ano não é apenas como serem resistentes a quântica, mas como serem descentralizados

Com o avanço da computação quântica, diversos mensageiros baseados em criptografia (Apple, Signal, WhatsApp) lideraram o caminho, com avanços relevantes. O problema é que todos dependem da confiança em um servidor privado controlado por uma única organização. Esses servidores são alvos fáceis para governos, que podem desligá-los, instalar backdoors ou forçar a entrega de dados privados.

De que adianta criptografia quântica se um país pode desligar seu servidor, se uma empresa tem a chave do servidor privado ou mesmo se ela controla o servidor?

Servidores privados exigem “confie em mim” — mas sem servidor privado, “você não precisa confiar em mim”. Comunicação não precisa de uma empresa intermediária. Mensagens exigem protocolos abertos, sem necessidade de confiança em terceiros.

A solução é descentralizar a rede: sem servidores privados, sem um único app, código totalmente open source e criptografia de ponta — inclusive contra ameaças quânticas. Em uma rede aberta, ninguém — pessoa, empresa, ONG ou país — pode retirar nosso direito de comunicar. Mesmo que um app seja derrubado, centenas de versões surgem no dia seguinte. Se um nó cair, há incentivo econômico (graças às blockchains e outros mecanismos) para outro assumir imediatamente.

Quando usuários passam a ser donos das próprias mensagens, assim como de seu dinheiro — por meio de uma chave — tudo muda. Apps podem ir e vir, mas o usuário mantém o controle de suas mensagens e identidade; o usuário final é dono das mensagens, mesmo que não do aplicativo.

Isso vai além da resistência quântica e da criptografia; trata-se de propriedade e descentralização. Sem ambos, só criamos criptografia inquebrável que ainda pode ser desligada.

~Shane Mac (@ ShaneMac), cofundador e CEO, XMTP Labs

3. Teremos ‘segredos-como-serviço’ para tornar privacidade infraestrutura central

Por trás de todo modelo, agente ou automação, existe uma dependência fundamental: dados. Hoje, a maioria dos pipelines de dados — o que entra ou sai do modelo — é opaca, mutável e não auditável.

Isso pode servir para aplicações de consumo, mas setores como finanças e saúde exigem sigilo de dados sensíveis. É também um obstáculo para instituições que querem tokenizar ativos do mundo real.

Como garantir privacidade e, ao mesmo tempo, promover inovação segura, compliance, autonomia e interoperabilidade global?

Existem várias abordagens, mas destaco os controles de acesso a dados: Quem controla os dados sensíveis? Como eles circulam? Quem ou o quê pode acessá-los? Sem esses controles, quem deseja sigilo precisa recorrer a serviços centralizados ou criar soluções próprias — o que é caro, demorado e impede instituições financeiras tradicionais de explorar o potencial dos dados onchain. E, à medida que sistemas agentivos passam a navegar, transacionar e tomar decisões de forma autônoma, usuários e instituições precisam de garantias criptográficas, não apenas de “confiança por esforço”.

Por isso, precisamos de segredos-como-serviço: tecnologias que ofereçam regras de acesso programáveis e nativas, criptografia no lado do cliente e gestão descentralizada de chaves — determinando quem pode descriptografar, sob quais condições e por quanto tempo, tudo onchain.

Combinando sistemas de dados verificáveis, segredos podem se tornar parte da infraestrutura pública fundamental da internet — deixando de ser um remendo em nível de aplicação, tornando a privacidade parte essencial da infraestrutura.

~Adeniyi Abiodun (@ EmanAbio), chief product officer e cofundador, Mysten Labs

4. Vamos passar de ‘code is law’ para ‘spec is law’ nos testes de segurança

Os ataques a protocolos DeFi no último ano atingiram projetos maduros, com equipes experientes, auditorias rigorosas e anos de produção. Isso evidencia um cenário desconfortável: a segurança padrão ainda é, em grande parte, heurística e pontual.

Para amadurecer em 2024, a segurança DeFi precisa evoluir de padrões de bugs para propriedades de design — e de abordagens “por esforço” para métodos “baseados em princípios”:

• No lado estático/pré-implantação (testes, auditorias, verificação formal), é preciso provar invariantes globais de forma sistemática, não apenas validar casos locais. Ferramentas de prova assistidas por IA, já em desenvolvimento, ajudam a escrever specs, propor invariantes e automatizar etapas antes caras e complexas.
• No lado dinâmico/pós-implantação (monitoramento em tempo real, enforcement em runtime), esses invariantes podem se tornar barreiras de proteção em tempo real: a última linha de defesa. Essas barreiras são codificadas como assertivas executadas em runtime, que toda transação precisa satisfazer.

Assim, em vez de presumir que todos os bugs foram capturados, impomos propriedades de segurança no código, revertendo automaticamente transações que as violem.

Isso não é só teoria. Na prática, quase todo exploit até hoje teria sido barrado por esses checadores durante a execução, interrompendo o ataque. Assim, o conceito de “code is law” evolui para “spec is law”: Mesmo ataques inéditos precisam respeitar as propriedades de segurança que mantêm o sistema íntegro, restando apenas ataques mínimos ou extremamente difíceis de executar.

~Daejun Park (@ daejunpark), equipe de engenharia a16z crypto

Aviso legal:

1. Este artigo foi reproduzido de [a16zcrypto]. Todos os direitos autorais pertencem ao autor original [a16zcrypto]. Caso haja objeções à reprodução, entre em contato com a equipe do Gate Learn, que tomará as providências necessárias.
2. Aviso de responsabilidade: As opiniões e visões expressas neste artigo são exclusivas do autor e não constituem aconselhamento de investimento.
3. As traduções deste artigo para outros idiomas são realizadas pela equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.