Encaminhar o título original’Como podemos tornar o uso de dados web2 na web3 realmente privado e verificável?’

Muitas pessoas que afirmam que o web3 é o novo internet definem com a frase “ler, escrever, possuir”. As partes “ler” e “escrever” são claras, mas quando se trata de “possuir” em termos de dados, dificilmente possuímos algo hoje em dia.

Os dados do usuário são frequentemente roubados por corporações e usados de maneiras que as beneficiam; nós não possuímos realmente nada na internet.

No entanto, não podemos simplesmente mudar para um mundo onde apenas a web3 existe sem compartilhar nada. Não, ainda precisamos compartilhar, mas apenas o necessário.

Como alguém com um passaporte mais fraco, estou preso a pedir vistos eletrônicos e a enviar inúmeros detalhes sobre mim mesmo para provar que sou elegível para vistos específicos. E sempre acabo me perguntando:

• Por que devo compartilhar todo o meu extrato bancário quando eles só precisam confirmar um nível de renda específico?

• Por que devo fornecer a reserva exata do hotel em vez de apenas provar que reservei um hotel neste país?

• Por que eu tenho que enviar todos os detalhes do meu passaporte quando tudo que eles precisam é verificar minha residência permanente no meu país atual?

Há duas preocupações principais aqui: os serviços sabem muito mais do que precisam e os dados que você está fornecendo não são privados. Mas como isso se relaciona com a segurança e privacidade em criptografia?

1. Web3 não vai conseguir sem dados da web2.

Como a maioria de vocês sabe, os contratos inteligentes essencialmente não têm ideia de quanto custa BTC, ETH, SOL ou qualquer outro ativo. Essa tarefa é delegada aos oráculos, que constantemente publicam dados públicos do mundo exterior para o contrato inteligente.

No mundo do Ethereum, esse papel é quase monopolizado por @chainlinkcom suas redes oráculo para garantir que não dependemos de um único nó. Portanto, realmente precisamos de dados web2 para mais casos de uso além de apenas saber o preço de certos ativos.

No entanto, isso se aplica apenas a dados públicos. E se eu quiser conectar com segurança minha conta bancária ou conta do Telegram e compartilhar informações sensíveis que não estão disponíveis publicamente, mas são privadas para mim?

O primeiro pensamento é: como podemos trazer esses dados para uma blockchain com a prova de que os dados privados estão seguros?

Infelizmente, não funciona assim porque os servidores não assinam as respostas que enviam, então não é possível verificar algo assim de forma confiável em contratos inteligentes.

O protocolo que garante a comunicação em uma rede de computadores é chamado de TLS: Segurança da Camada de Transporte. Mesmo que você não tenha ouvido falar dele, você o utiliza diariamente. Por exemplo, enquanto lê este artigo, você verá o “https://“ na barra de endereço do seu navegador.

Se tentou acessar o site com uma conexão “http://” (sem o “s”), o seu navegador o alertaria de que a conexão não é segura. O “s” no link representa o TLS, que garante a segurança da sua conexão, garantindo privacidade e evitando que alguém roube os dados que está transmitindo.

2. A conexão já é segura, não podemos simplesmente transportá-la e usá-la no web3?

Como mencionei antes, enfrentamos um problema de verificabilidade: os servidores não assinam as respostas que enviam, então não podemos realmente verificar os dados.

Mesmo que uma fonte de dados concorde em compartilhar seus dados, o protocolo TLS padrão não pode provar sua autenticidade para outros. Simplesmente passar uma resposta não é suficiente: os clientes podem facilmente alterar os dados localmente, compartilhando essas respostas totalmente os expõe, arriscando a privacidade do usuário.

Uma abordagem para o problema da verificabilidade é uma versão aprimorada do TLS chamada zkTLS.

O mecanismo de trabalho do zkTLS é semelhante ao TLS, mas ligeiramente diferente, veja como funciona:

• Você visita um site através de uma conexão segura TLS e envia a solicitação necessária.

• zkTLS gera uma prova zk que verifica os dados enquanto revela apenas os detalhes específicos que o usuário deseja provar, mantendo tudo o mais privado.

• A prova zk gerada é então usada por outros aplicativos para confirmar e verificar que as informações fornecidas estão corretas.

Quando digo zkTLS, estou me referindo a projetos que utilizam zkTLS, mas existem abordagens diferentes para verificabilidade de dados usando várias soluções:

1. TEE (Ambiente de Execução Confiável)
2. MPC (Multi-Party Computation)
3. Proxy

Curiosamente, cada abordagem introduz seu próprio conjunto de casos de uso exclusivos. Então, como elas diferem?

3. Por que não existe um único padrão para zkTLS? Quais são as diferenças?

zkTLS não é uma única tecnologia, pois verificar dados da web privada sem expô-los pode ser abordado por múltiplos ângulos, cada um com seus próprios compromissos. A ideia central é estender o TLS com provas, mas como você gera e valida essas provas depende do mecanismo subjacente.

Como mencionei antes, três abordagens principais estão usando TEE-TLS, MPC-TLS ou Proxy-TLS.

A TEE conta com hardware especializado, como Intel SGX ou AWS Nitro Enclaves, para criar uma “caixa preta” segura onde os dados podem ser processados e as provas geradas. O hardware garante que os dados permaneçam privados e que os cálculos sejam invioláveis.

Em uma configuração zkTLS baseada em TEE, o TEE executa o protocolo, comprovando a execução e o conteúdo da sessão TLS. O verificador é o próprio TEE, portanto, a confiança depende do fabricante do TEE e de sua resistência a ataques. Essa abordagem é eficiente, com baixa sobrecarga computacional e de rede.

No entanto, ele tem uma grande falha: você tem que confiar no fabricante de hardware, e vulnerabilidades em TEEs (como ataques de canal lateral) podem quebrar todo o sistema.

Proxy-TLS e MPC-TLS são as abordagens mais amplamente adotadas devido à sua ampla gama de casos de uso. Projetos como@OpacityNetworke@reclaimprotocol, que são construídos em @eigenlayer, aproveite esses modelos para garantir a segurança e a privacidade dos dados, juntamente com uma camada adicional de segurança econômica.

Vamos ver o quão seguras são essas soluções, quais casos de uso os protocolos zkTLS permitem e o que já está ativo hoje.

4. O que há de tão especial em MPC-TLS e na Rede Opacity?

Durante o handshake do TLS (onde um cliente e um servidor concordam sobre como se comunicar de forma segura compartilhando chaves de criptografia), o papel do site permanece inalterado, mas o processo do navegador faz algo diferente.

Em vez de gerar sua própria chave secreta, ele usa uma rede de nós para criar uma chave secreta multipartidária via MPC. Essa chave realiza o handshake para o navegador, garantindo que nenhuma entidade única conheça a chave compartilhada.

A criptografia e a descriptografia exigem cooperação entre todos os nós e o navegador, com cada um adicionando ou removendo sua parte da criptografia sequencialmente antes que os dados cheguem ou saiam do site. O MPC-TLS fornece segurança forte e pode ser distribuído para que nenhum grupo tenha todo o poder.

A Rede de Opacidade aprimora o clássico@tlsnotaryframework adicionando salvaguardas para minimizar problemas de confiança. Ele emprega várias medidas de segurança como:

1. Verificação on-chain de IDs de contas web2
2. Esquema de compromisso
3. Esquema de revelação
4. Amostragem aleatória de rede MPC
5. Registro verificável de tentativas

IDs de conta, sendo estáticos nos sistemas web2, permitem a comprovação por comitê, onde dez nós diferentes devem confirmar a propriedade. Isso vincula a conta a uma carteira única, impedindo tentativas repetidas com carteiras diferentes para encontrar um nó que esteja colaborando.

Você pode ver como a Opacidade funciona em detalhes abaixo:

Os nós de opacidade operam dentro de um TEE, tornando a colusão quase impossível se o TEE for seguro. Além dos TEEs, a Opacidade também usa o Eigenlayer para alavancar um AVS, exigindo que os nós reestabeleçam 32 stETH, com corte imediato por má conduta, evitando atrasos associados a períodos de espera.

Você pode ver que a Opacity usa tanto o MPC quanto o TEE, mas porque o MPC é usado para zkTLS, enquanto o TEE é usado basicamente para a segurança do nó, ainda é chamado de MPC-TLS.

No entanto, se os TEEs falhassem, isso poderia permitir que um nó se envolvesse em conluio dentro do MPC. Essa é uma das razões pelas quais uma camada adicional de segurança econômica é necessária para evitar esse comportamento.

É também por isso que a Opacity está desenvolvendo um mecanismo de denúncia onde os usuários que puderem provar que um notário agiu de forma imprópria serão recompensados com uma parte da penalidade imposta à participação do notário.

Devido à sua simplicidade de integração, segurança e privacidade que oferece, Opacity atraiu vários protocolos para integrá-lo em seus produtos em diversos setores, incluindo consumidor, DeFi e agentes de IA.

A equipe da@earnos_ioestá desenvolvendo uma plataforma onde as marcas podem recompensar os usuários pelo engajamento ou conclusão de tarefas. O EarnOS usa a tecnologia da Opacity para comprovar características através de aplicativos populares sem revelar informações pessoais, permitindo que as marcas atinjam o público-alvo enquanto os usuários mantêm a privacidade e ganham recompensas.

A opacidade também está integrada no@daylightenergy_protocol, desenvolvendo uma rede de utilidade elétrica descentralizada onde os usuários podem ganhar recompensas por contribuir para soluções de energia limpa. Graças ao Opacity, os usuários podem provar a propriedade do dispositivo de energia on-chain sem hardware especializado.

A opacidade pode até ser integrada com agentes de IA, trazendo mais verificabilidade e transparência para um campo que atualmente enfrenta desafios significativos. zkTLS foi recentemente integrado em @elizaOS, permitindo interações de IA verificáveis sem perda de privacidade.

No entanto, TEE-TLS e MPC-TLS são apenas duas variações do zkTLS, também existe uma terceira chamada Proxy-TLS, sendo a Rede Reclaim a representação mais famosa desse modelo. Então, como ela é diferente em termos de tecnologia das outras duas variações e quais casos de uso podem ser habilitados pelo Proxy-TLS?

5. O que há de tão especial no Proxy-TLS e no Protocolo de Recuperação?

Proxies HTTPS, comuns na internet, encaminham tráfego criptografado sem acessar seu conteúdo. No modelo de proxy zkTLS, funciona quase da mesma forma, com pequenas adições:

• O navegador envia solicitações ao site por meio de um proxy, que também lida com as respostas do site.

• O proxy vê todas as trocas criptografadas e atesta sua autenticidade, observando se cada uma é uma solicitação ou resposta.

• O navegador então gera uma prova zk que afirma que pode criptografar esses dados com uma chave compartilhada sem revelar a chave e mostra o resultado.

• Isso funciona porque é praticamente impossível criar uma chave falsa que transforme os dados em algo sensato, então apenas mostrar que você pode descriptografá-los é suficiente.

Revelar a chave comprometeria todas as mensagens anteriores, incluindo dados sensíveis como nomes de usuário e senhas. O Proxy-TLS é bastante rápido, acessível e lida bem com grandes volumes de dados, tornando-o ideal para configurações de alta taxa de transferência.

A maioria dos servidores não restringe o acesso com base em endereços IP variados, tornando este método bastante amplamente aplicável.

O Reclaim Protocol usa o Proxy-TLS para verificação eficiente de dados e emprega proxies para contornar os firewalls da Web2, impedindo o bloqueio em larga escala de proxies.

Aqui está como funciona:

O principal problema aqui é a colusão: se o usuário e o atestador se colidirem, eles podem assinar basicamente qualquer coisa e agir maliciosamente. Para mitigar isso, Reclaim incorpora um subconjunto de validadores escolhidos para introduzir aleatoriedade e bloquear tais explorações.

Reclaim usa o AVS da Eigen para descentralizar a validação dos dados. Os operadores da EigenLayer podem atuar como atestadores, mas precisarão implantar seu próprio AVS para especificar a lógica de atestação para o seu serviço.

Reclaim é uma plataforma que possibilita casos de uso exclusivos, como importar dados de compartilhamento de viagens para aplicativos de transporte, conectar dados off-chain para economia blockchain, verificar identidades com dados de identidade nacional, criar soluções de dados personalizadas por meio de ferramentas para desenvolvedores e muito mais.

O ecossistema Reclaim abriga 20+ projetos, mas gostaria de destacar 4 deles nos setores de mercado financeiro, identidade digital, consumo e contratação.

@3janexyzé o primeiro mercado monetário baseado em crédito na Base, oferecendo linhas de crédito garantidas aos usuários de criptomoedas avaliando sua solvência e fluxos de caixa futuros, usando dados financeiros tanto on-chain quanto off-chain.

3Jane usa o modelo de proxy da Reclaim para verificar os dados de crédito da VantageScore, Cred, Coinbase e Plaid, garantindo a privacidade desses dados.

Outro uso para pontuações de crédito com zkTLS é através de@zkme_, zkCreditScore. Ele usa o Reclaim Protocol para obter sua pontuação de crédito nos EUA com segurança com zkTLS. Isso permite que o zkMe verifique a pontuação de crédito de um usuário e crie tokens exclusivos soulbound (SBTs) para armazenar esses dados.

Existem outros casos de uso além das pontuações de crédito? Claro que sim.

Podemos levar @zkp2pcomo exemplo, que é um mercado de bens de consumo que alavanca Reclaim para verificar os dados do Ticketmaster dos usuários, bem como verificar os pagamentos dos usuários.

Ao mesmo tempo,@bondexapp, que é um dos quadros de empregos mais populares em criptografia, usa Reclaim para obter prova de trabalho de perfis, verificando que os dados são reais, privados e verificáveis.

Analisando os casos de uso possíveis via zkTLS, a capacidade de verificar transcrições TLS on-chain já está desbloqueando inúmeras novas funcionalidades, permitindo aos usuários controlar seus próprios dados sem precisar de permissão de grandes corporações.

Mais importante, zkTLS é feito para garantir que seus dados pessoais não sejam usados contra você. Então, para onde isso está indo?

6. O zkTLS veio para ficar?

Ainda há trabalho a ser feito, mas diferentes protocolos zkTLS já estão introduzindo novos casos de uso que redistribuem o poder de volta para os usuários.

@Tim_Roughgardenno podcast a16z crypto destacou que as provas zk, propostas em 1985, só ganharam popularidade com aplicações blockchain, graças a centenas de desenvolvedores trabalhando para reduzir o tamanho e os custos da prova.

E agora, as contribuições da indústria de blockchain estão encontrando usos em outras áreas além da criptomoeda em si.

Espero que uma história semelhante se desenrole com zkTLS, começando com a implementação no Web3 e depois se estendendo além disso, porque, como eu disse antes, atualmente, nós “lemos” e “escrevemos”, mas mal estamos protegidos e mal “possuímos” até mesmo nossos próprios dados.

Aviso legal:

1. Este artigo é reproduzido a partir de [gatePavel Paramonov]. Todos os direitos autorais pertencem ao autor original [Pavel Paramonov]. Se houver objeções a esta reimpressão, por favor, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não representam nenhum conselho de investimento.
3. A equipe Learn da gate faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.