Encaminhar o Título Original‘’

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

Os dados do utilizador são frequentemente roubados por empresas e usados de formas que as beneficiam; na verdade, não possuímos nada na internet.

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

Como alguém com um passaporte mais fraco, estou preso a pedir vistos eletrónicos e a submeter detalhes intermináveis sobre mim para provar que sou elegível para vistos específicos. E acabo sempre por me perguntar:

• Por que devo partilhar o meu extrato bancário completo quando eles apenas precisam de confirmar um nível de rendimento específico?

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

• Porque é que tenho de submeter os detalhes completos do meu passaporte quando tudo o que eles precisam é de verificar a minha residência permanente no meu país atual?

Existem duas preocupações principais aqui: os serviços sabem muito mais do que precisam e os dados que está a fornecer não são privados. Mas como é que isto se relaciona com a segurança e privacidade nas criptomoedas?

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

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

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

No entanto, isto aplica-se apenas a dados públicos. E se eu quiser ligar de forma segura a minha conta bancária ou conta do Telegram e partilhar informações sensíveis que não estão publicamente disponíveis, 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, por isso não é possível verificar algo assim de forma fiável em contratos inteligentes.

O protocolo que garante a comunicação numa rede de computadores chama-se TLS: Segurança da Camada de Transporte. Mesmo que nunca tenha ouvido falar dele, utiliza-o diariamente. Por exemplo, ao ler este artigo, verá o “https://“ na barra de endereço do seu navegador.

Se tentou aceder ao site com uma ligação “http://“ (sem o “s”), o seu navegador avisaria que a ligação não é segura. O “s” no link significa TLS, que garante a segurança da sua ligação, assegurando a privacidade e evitando que alguém roube os dados que está a transmitir.

2. A conexão já está 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 partilhar os seus dados, o protocolo TLS padrão não consegue provar a sua autenticidade a outros. Simplesmente passar uma resposta não é suficiente: os clientes podem facilmente alterar os dados localmente, partilhando essas respostas completamente os expõe, colocando em risco a privacidade do utilizador.

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

O mecanismo de funcionamento do zkTLS é semelhante ao TLS, mas ligeiramente diferente, aqui está como funciona:

• Você visita um site através de uma conexão segura TLS e envia o pedido necessário.

• O 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 outras aplicações para confirmar e verificar que a informação fornecida está correta.

Quando digo zkTLS, estou a referir-me a projetos que utilizam zkTLS, mas existem diferentes abordagens para a 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 o seu próprio conjunto de casos de uso únicos. Então, como é que elas diferem?

3. Por que não existe um único padrão para zkTLS? Como eles são diferentes?

zkTLS não é uma única tecnologia, porque verificar dados da web privada sem os expor pode ser abordado a partir de múltiplos ângulos, cada um com os seus próprios compromissos. A ideia principal é estender o TLS com provas, mas como gera e valida essas provas depende do mecanismo subjacente.

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

A TEE depende de 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.

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

No entanto, tem uma falha importante: é necessário confiar no fabricante do hardware, e as vulnerabilidades nos TEEs (como ataques de canal lateral) podem comprometer 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, alavancar esses modelos para garantir a segurança e 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 os casos de uso que os protocolos zkTLS permitem e o que já está em funcionamento hoje.

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

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

Em vez de gerar a sua própria chave secreta, utiliza uma rede de nós para criar uma chave secreta multiparte através de MPC. Esta chave realiza o handshake para o navegador, garantindo que nenhuma entidade única conhece a chave partilhada.

A criptografia e a descriptografia requerem 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 Opacity melhora o clássico @tlsnotaryestrutura adicionando salvaguardas para minimizar questões de confiança. Emprega várias medidas de segurança como:

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

Os IDs de conta, sendo estáticos nos sistemas web2, permitem a prova por comissão, 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 a colaborar.

Pode ver como a Opacidade funciona em detalhe em baixo:

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

Pode ver que a Opacity utiliza tanto o MPC como o TEE, mas como o MPC é utilizado para o zkTLS enquanto o TEE é utilizado basicamente para a segurança do nó, ainda é chamado de MPC-TLS.

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

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

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

A equipe da@earnos_ioestá a desenvolver uma plataforma onde as marcas podem recompensar os utilizadores pela interação ou conclusão de tarefas. O EarnOS utiliza a tecnologia da Opacity para comprovar características através de aplicações populares sem revelar informações pessoais, permitindo que as marcas atinjam o público-alvo, ao mesmo tempo que os utilizadores mantêm a privacidade e ganham recompensas.

A Opacidade também está integrada no @daylightenergy_protocol, desenvolvendo uma rede elétrica descentralizada onde os utilizadores podem ganhar recompensas por contribuir para soluções de energia limpa. Graças à Opacidade, os utilizadores podem comprovar 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 a 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, existe também uma terceira chamada Proxy-TLS, sendo a Reclaim Network a representação mais famosa deste modelo. Então, como é diferente em termos tecnológicos das outras duas variações e quais casos de uso podem ser habilitados pelo Proxy-TLS?

5. O que há de especial no Protocolo Proxy-TLS e no Protocolo Reclaim?

Proxys HTTPS, comuns na internet, encaminham tráfego encriptado sem aceder ao seu conteúdo. No modelo de proxy zkTLS, funciona quase da mesma forma com ligeiras adições:

• O navegador envia pedidos ao site através de um proxy, que também trata as respostas do site.

• O proxy vê todas as trocas criptografadas e atesta a sua autenticidade, observando se cada uma é um pedido ou uma resposta.

• O navegador gera então uma prova zk que afirma que pode encriptar estes dados com uma chave partilhada sem revelar a chave e mostra o resultado.

• Isto funciona porque é quase impossível criar uma chave falsa que transforme os dados em algo sensato, por isso apenas mostrar que pode descriptografá-los é suficiente.

Revelar a chave comprometeria todas as mensagens anteriores, incluindo dados sensíveis como nomes de utilizador e palavras-passe. O Proxy-TLS é bastante rápido, acessível e lida bem com grandes volumes de dados, tornando-o ideal para configurações de alto débito.

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

O Protocolo Reclaim usa o Proxy-TLS para verificação eficiente de dados e emprega proxies para contornar firewalls Web2, evitando o bloqueio em grande escala de proxies.

Aqui está como funciona:

O principal problema aqui é a colusão: se o usuário e o atestante entrarem em conluio, podem assinar basicamente qualquer coisa e agir maliciosamente. Para mitigar isso, o 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 seu serviço.

Reclaim é uma plataforma que permite casos de uso únicos, como importar dados de partilha de viagens para aplicações de transporte, ligar dados off-chain para economia blockchain, verificar identidades com dados de identificação nacional, criar soluções de dados personalizadas através de ferramentas para programadores e muito mais.

O ecossistema Reclaim é o lar de 20+ projetos, mas gostaria de destacar 4 deles nos mercados monetários, identidade digital, consumidor e setores de contratação.

@3janexyzé o primeiro mercado monetário baseado em crédito na Base, oferecendo linhas de crédito garantidas aos utilizadores de criptomoeda ao avaliar a sua solvabilidade e fluxos de caixa futuros, utilizando dados financeiros tanto on-chain como 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.

Outra utilização para pontuações de crédito com zkTLS é através@zkme_‘s recurso, zkCreditScore. Ele usa o Protocolo Reclaim para obter sua pontuação de crédito dos EUA de forma segura com zkTLS. Isso permite que zkMe verifique a pontuação de crédito de um usuário e crie tokens soulbound únicos (SBTs) para armazenar esses dados.

Podem existir 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 dos usuários do Ticketmaster, bem como verificar os pagamentos dos usuários.

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

Ao analisar 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 utilizadores controlar os seus próprios dados sem necessitar de permissão de grandes corporações.

Mais importante, o zkTLS é feito para garantir que os seus dados pessoais não sejam usados contra si. Então, para onde é que isto se dirige?

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 de blockchain, graças a centenas de desenvolvedores trabalhando para reduzir o tamanho e os custos das provas.

E agora, as contribuições da indústria blockchain estão a ser utilizadas noutras áreas para além do próprio cripto.

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

Aviso legal:

1. Este artigo é reimpresso de [gatePavel Paramonov]. Todos os direitos de autor pertencem ao autor original [Pavel Paramonov]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipa, e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipe do Learn gate faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, salvo indicação em contrário.