Introdução

Um grande problema para usuários de criptomoedas web3 é a falta de privacidade. O fato de que todas as transações são visíveis em um livro-razão público e, cada vez mais, associadas a um único e legível nome ENS, é um desincentivo para os usuários realizarem certas atividades, ou faz com que as realizem de maneiras que resultam em maior atrito UX. Um exemplo é simplesmente transferir fundos de uma carteira quente para uma carteira fria ou vice-versa. Os usuários podem não querer ter uma carteira vinculada a outra, pois podem não querer que seu saldo de carteira fria seja visto. Atualmente, os endereços Ethereum não funcionam como contas bancárias privadas, porque todos podem ver sua carteira e, cada vez mais, sua atividade social (SBTs, atestações, atividades em vários dapps, etc.). É por esses motivos que Vitalik destacou a privacidade como um dos...três grandes transições técnicasque o Ethereum precisa passar para ser útil para usuários comuns.

Usar soluções de privacidade existentes, como Tornado Cash, é uma experiência um tanto subótima por várias razões. Primeiro: os usuários certamente ficarão preocupados em ter seu endereço na lista negra de exchanges centralizadas ou outras plataformas. Em segundo lugar, a experiência do usuário ao interagir com serviços como o Tornado Cash não é muito amigável e realmente só adequada para usuários altamente proficientes.

Os endereços furtivos fornecem uma maneira de proporcionar ao usuário a privacidade que eles consideram garantida com contas bancárias privadas, e de uma maneira que é fácil de entender. Além disso, inovações em torno dos endereços furtivos significam que potencialmente podemos fazer isso de uma forma que permaneça em conformidade com as regulamentações de AML em numerosas jurisdições.

Demanda do usuário por privacidade

Embora a pesquisa sobre as atitudes em relação à privacidade entre usuários da web e da web3 não seja amplamente disponível, a pesquisa abaixo foi descoberta por meio de pesquisas na web e os resultados estão amplamente alinhados, demonstrando que há um claro apetite pela privacidade de transações.

1. Uma pesquisa realizada em 2022 e publicada por Simin Ghesmati et al. em um artigo intitulado: Privacidade percebida pelo usuário na blockchain, afirmou que 'metade dos entrevistados afirmaram que a privacidade das transações é muito importante para eles'. Embora essa pesquisa estivesse mais relacionada ao Bitcoin do que ao Ethereum, é provável que existam atitudes semelhantes dos usuários do Ethereum também. No entanto, o tamanho da amostra para esta pesquisa foi bastante pequeno (14 participantes).
2. Mais uma pesquisa interessante de 2022, publicada em Fronteiras, intitulado Atitudes políticas, econômicas e de governança dos usuários de blockchain, é mais abrangente, com 3.710 usuários de criptografia pesquisados. Os resultados mostraram que cerca de um quarto dos entrevistados indicaram que a privacidade é 'a característica mais importante da blockchain e da criptografia'.

1. Em termos de atitudes em relação à privacidade em geral, Consensyspublicou pesquisa intituladaPesquisa global sobre Web3 e criptomoedas 2023, na qual eles entrevistaram 15.158 pessoas online em 15 países sobre vários tópicos relacionados à web, e não apenas criptografia. A pesquisa descobriu que 83% dos entrevistados acham a privacidade dos dados importante, enquanto apenas 45% dos entrevistados afirmaram confiar em como os serviços atuais da Internet usam seus dados e informações pessoais.
2. Um pesquisa realizada pelo Financial Services Compensation Scheme do Reino Unido, publicado em abril de 2023, destacou que 9% dos entrevistados citaram o “desejo de anonimato/privacidade” como motivo para investir em criptomoedas.

Adoção de Protocolos de Transação Stealth

Railguntem números impressionantes, com o uso do protocolo parecendo crescer constantemente ao longo do tempo, atingindo um pico de mais de $70M TVL e $2 bilhões em volume até novembro de 2024.

TVL (USD) Railgun no Ethereum main — fonte: ​​Railgun — DefiLlama

Umbra também viu um aumento constante de pessoas usando seu protocolo (pessoas registrando um endereço furtivo em seu ENS), com quase 77K em novembro de 2024:

Registros Cumulativos Umbra (Cross Chain)— fonte: dune.com

Se olharmos para o protocolo de privacidade mais conhecido (e agora infelizmente famoso) no Ethereum, que é o Tornado cash, podemos ver que ele ainda está sendo amplamente utilizado, apesar do fato de que os endereços dos contratos estão tecnicamente na lista SDN da OFAC.

O gráfico abaixo mostra o TVL da Tornado Cash ao longo do tempo. Podemos observar que a primeira grande queda no TVL a partir do pico em torno de outubro de 2021 coincidiu com uma venda mais ampla nos mercados de criptomoedas, com a segunda grande queda em agosto de 2022 correspondendo à inclusão da Tornado Cash na lista SDN pelo OFAC, e a terceira grande queda correspondendo à redesignação do OFAC em novembro de 2022. Desde então, no entanto, a Tornado Cash vem apresentando um crescimento constante, apesar das sanções, atingindo quase $600M em TVL. Isso é uma evidência bastante sólida de que há uma demanda por privacidade básica de transações no Ethereum.

TVL (USD) Tornado Cash no Ethereum principal - fonte:Tornado Cash — DefiLlama

A Paisagem do Endereço Oculto

Esta pesquisa identificou 4 soluções principais para cadeias EVM em produção até hoje, são elas:

• Fluidkey
• Umbra
• Labirinto
• Railgun

Tanto o Fluidkey quanto o Umbra são baseados em padrões Ethereum, que são:

• ERC-5564: Protocolo de Endereço Oculto
• ERC-6538: Registro de Endereços Meta Furtivos

Labyrinth e Railgun são baseados no protocolo zerocash (que zcashbaseia-se em), que usa uma pool protegida na qual os usuários depositam fundos. O Zerocash usa o conceito de "notas", que são basicamente representações criptográficas de valor que permitem transações privadas. Cada nota inclui um valor oculto, uma chave do proprietário e um número único (um anulador), com zk-SNARKs usados para verificar a propriedade sem revelar detalhes e, portanto, transferir o valor nas notas. Quando uma nota é gasta, seu anulador é revelado para evitar gastos duplos, enquanto novas notas são criadas para o(s) destinatário(s), formando um sistema UTXO dentro da pool protegida.

Em alto nível, os endereços furtivos funcionam com base no princípio básico de que uma terceira parte pode enviar fundos para um endereço que nunca existiu antes, mas que o destinatário pretendido pode descobrir e controlar (ou seja, pode posteriormente gastar esses fundos).

O padrão erc-5564 especifica um mecanismo pelo qual um destinatário pode publicar um stealth-meta-endereço, a partir do qual novos endereços Ethereum podem ser derivados. Qualquer pessoa que deseje enviar fundos ao destinatário pode gerar novos endereços a partir do stealth-meta-endereço e permitir que o destinatário saiba sobre esses fundos sem nenhuma comunicação direta ocorrendo. Todas as implementações de endereço stealth funcionam com base nessa premissa básica.

Como funcionam os Endereços Furtivos

Um meta-endereço furtivo é essencialmente a concatenação de 2 chaves públicas compactadas, referidas como a "chave de gasto" e a "chave de visualização". O metaendereço furtivo usa o formato de endereço específico da cadeia EIP-3770, com a adição do prefixo "st:". A seguir está um exemplo de um endereço furtivo:

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

Para simplificar, este endereço oculto pode estar associado a um endereço Ethereum normal (e, portanto, ENS), tornando mais fácil enviar fundos para o proprietário do endereço oculto. Para enviar fundos, um remetente resolveria o endereço acima e, usando o padrão EIP-5564, criaria uma chave pública efêmera, da qual então derivariam o endereço oculto. O remetente envia fundos para o novo endereço oculto, normalmente através de um contrato singleton para o qual todos os destinatários de endereços ocultos ouvem os eventos. Este contrato emite um evento de “Anúncio” ao qual os destinatários se inscrevem. Sempre que um evento de anúncio é emitido, os destinatários verificarão a chave pública efêmera no anúncio, combiná-la-ão com a sua chave privada de visualização e determinarão se têm a capacidade de gastar os fundos enviados para o endereço oculto. Se o fizerem, a carteira / cliente que estão a utilizar lembrar-se-á do endereço oculto e dos fundos respetivos, adicionando-o ao saldo exibido do utilizador. Para realmente gastar os fundos, podem assinar uma transação usando a chave de gasto privada.

O diagrama a seguir esboça o processo de ponta a ponta, esperançosamente um pouco mais claramente:

Lembre-se de que este processo acontece inteiramente de forma não interativa, o que significa que o remetente e o destinatário nunca têm qualquer comunicação direta, ou seja, não há efetivamente nenhuma ligação entre o remetente e o destinatário que qualquer terceiro possa observar.

No entanto, para que isso funcione em primeiro lugar, o destinatário deve informar seu endereço oculto ao(s) remetente(s). Uma maneira de fazer isso é usar o Registro de Meta-Endereço Stealth eip-6538. Este é um contrato singleton que permite aos usuários registrar um meta-endereço furtivo para um endereço normal do Ethereum, o qual os remetentes podem então consultar. Isso permite que os remetentes resolvam o endereço normal do ENS e, em seguida, consultem o meta-endereço furtivo associado do registro.

Esquema dos quebra a ligação entre o remetente e o destinatário, proporcionando a ambos privacidade para que o mundo inteiro não saiba dos seus negócios. Há algumas ressalvas:

• Quando o destinatário for gastar os fundos, quem quer que eles transfiram esses fundos verão que eles têm origem do remetente original (ou seja, eles podem ver o endereço para onde os fundos foram transferidos e quem enviou fundos anteriormente para esse endereço). O que isso significa é que a cadeia de transferências permanece intacta e rastreável, mas simplesmente não estão associadas ao destinatário em questão (a menos que o destinatário faça algo como enviar os fundos para um de seus endereços não ocultos conhecidos). Note que isso se aplica apenas às implementações do erc-5564, não ao Railgun ou Labyrinth.
• Outro efeito colateral do problema acima é que, para manter a privacidade ideal, o usuário provavelmente precisará deixar os fundos nos endereços ocultos para os quais foram originalmente enviados até que realmente precise deles, em vez de consolidá-los em um único endereço. Isso representa um custo adicional para lembrar os endereços e subsequentemente gastar os fundos nesses endereços, pois a quantia que você deseja transferir precisará ser obtida a partir da combinação de fundos em vários outros endereços.
• Para transferir fundos deste endereço, o destinatário precisará financiar o endereço com algum ETH para pagar pelo gás, e isso poderia potencialmente desanonimizar o destinatário. Esse é um problema conhecido com endereços ocultos e uma das razões pelas quais várias implementações implementaram suporte para eip-4337 e um pagador.
• Uma desvantagem do esquema de endereço oculto é que os destinatários precisam monitorar a blockchain em busca de eventos de anúncio e verificar cada anúncio para determinar se receberam fundos. Isso é obviamente uma sobrecarga impraticável para a maioria dos usuários, especialmente quando se trata de receber fundos em várias redes. Para tornar esse processo mais eficiente, o padrão especifica uma “tag de visualização”, que é um hash truncado derivado do segredo compartilhado e pode ser usado para descartar rapidamente transações que definitivamente não são destinadas a eles. Ao usar tags de visualização, o desempenho não é tão ruim em desktops, no entanto, pode ser um pouco mais perceptível em dispositivos móveis. O único momento em que o impacto no desempenho é realmente perceptível é quando uma carteira está sendo restaurada, caso em que a carteira precisará percorrer todos os endereços desde que o contrato on-chain foi implantado, o que consome tempo.
• Para contornar isso, os usuários podem opcionalmente compartilhar a chave de visualização privada com uma terceira parte confiável. Este serviço de terceira parte pode monitorar várias redes e notificar os usuários quando eles recebem fundos. Isso, é claro, implica em um compromisso: embora a terceira parte não possa gastar efetivamente os fundos dos usuários (eles não têm a chave de gastos privada para fazer isso), eles podem ver todos os fundos enviados a um determinado destinatário, o que significa que o usuário precisa confiar neles com sua privacidade. A Fluidkey faz isso por padrão.
• O protocolo padrão de endereço furtivo, ou seja, ERC-5564, é projetado para facilitar transferências que preservam a privacidade. No entanto, casos de uso não financeiros, como chamar funções arbitrárias de contratos inteligentes, exigem um pouco mais de engenharia e geralmente são específicos da implementação.

Matriz de Comparação

Existem várias maneiras de comparar as quatro implementações de endereços ocultos que este post explora. Todas as implementações têm diferenças sutis e compensações, mas provavelmente os pontos mais importantes a destacar são a rastreabilidade e a ofuscação do valor.

Embora tanto o Fluidkey quanto o Umbra permitam que os fundos sejam transferidos para um endereço Ethereum padrão, quebrando qualquer vínculo com a identidade do destinatário, eles ainda preservam a rastreabilidade da transação, o que significa que o remetente é visível para qualquer pessoa que examine o histórico de transações do endereço oculto. Isso significa que, se você receber fundos em um endereço oculto, a pessoa para quem você decidir enviar esses fundos verá de onde eles vieram. Além disso, o valor real sendo transferido também é visível. Railgun e Labyrinth ocultam o remetente, assim como o valor sendo enviado, mas com a compensação de que tudo isso acontece dentro de um único contrato e não como uma transação normal para um endereço Ethereum normal.

A figura abaixo mostra como os protocolos que analisamos neste post se comparam entre si em relação a essas duas importantes dimensões de comparação.

Para explorar as diferenças um pouco mais detalhadamente, abaixo está uma matriz de comparação dos quatro principais protocolos de endereçamento furtivo em seis dimensões principais:

1. Privacidade completa de ponta a ponta (apenas remetente e destinatário veem o pagamento)
2. Sigilo avançado. O envio de fundos recebidos por meio de transações furtivas não permite que o segundo destinatário veja de onde os fundos originaram
3. Segue os padrões erc-5564 e erc-6538
4. Implementa uma arquitetura modular extensível que permite a integração com dapps de terceiros
5. A implementação oferece um SDK que os desenvolvedores podem usar para integrar?
6. A solução fornece um nível de conformidade por meio de algum tipo de suporte para desanonimização?
7. O design suporta a obfuscação do valor/quantidade sendo transferido?

| Protocolo | Privacidade do E2E | Encaminhar Sigilo | Padrão Aberto | Arquitetura Modular | SDK | Suporte à desanonimização | Valores ocultos |

|—————-|——————-|————————-|————————|———————————|———|—————————————|————————|

| Umbra | ✅ | ⛔️ | ✅ | ⛔️ | ⛔️ | ⛔️ | ⛔️ |

| Fluidkey | ⛔️ | ⛔️ | ✅ | ✅ | em breve | ✅ | ⛔️ |

| Labirinto | ✅ | ✅ | ⛔️ | ✅ | ✅ | ✅ | ✅ |

| Railgun | ✅ | ✅ | ⛔️ | ✅ | ✅ | voluntário | ✅ |

Algumas das outras nuances e diferenças são capturadas com mais detalhes na seção a seguir. Cada implementação possui diferenças sutis interessantes que podem ou não fazer diferença, dependendo do seu caso de uso.

Por exemplo: no Fluidkey: todas as transferências vão diretamente para endereços ocultos na cadeia, com a Umbra: apenas ETH vai para endereços ocultos na cadeia, enquanto os tokens vão para o contrato central, e com o Railgun e o Labyrinth, todas as transações vão para contratos principais, não diretamente para endereços ocultos na cadeia.

Mergulho profundo nas implementações do endereço furtivo

Fluidkey

Fluidkeyé uma implementação do erc-5564 que permite aos usuários enviar, receber, trocar e conectar ETH e tokens erc-20. No momento da escrita, o Fluidkey está implantado na Base, Optimism, Arbitrum, Polygon, Gnosis e na mainnet do Ethereum.

Os usuários interagem com a Fluidkey por meio de sua interface da web. Quando eles fazem login pela primeira vez usando sua carteira, eles assinam uma mensagem de geração de chave da qual são derivadas suas chaves de visualização e gastos. Essas mesmas chaves são recriadas da mesma maneira toda vez que o usuário entra no aplicativo.

Há algumas maneiras pelas quais o Fluidkey difere de outras implementações. Uma maneira pela qual o Fluidkey difere de outras implementações de endereços furtivos é que os usuários compartilham sua chave de visualização privada com o Fluidkey (na verdade, umBIP-32nó derivado da chave para ser pedante). Isso permite que o Fluidkey gere endereços furtivos para o usuário e também notifique o usuário quando eles receberam pagamentos para esses endereços. No entanto, isso significa que o Fluidkey está em posição de visualizar as transações e saldos recebidos de um usuário, o que é o equilíbrio. No entanto, ainda permanece totalmente auto-custodial.

Outro aspecto interessante do design da Fluidkey é que ela implanta uma conta de contrato inteligente para cada novo endereço oculto. Isso acontece de forma contrafactual apenas quando os fundos de um endereço oculto são gastos. A conta inteligente é uma conta 1/1 Safe e permite coisas como patrocínio de gás, tornando mais fácil gerenciar os vários endereços ocultos juntos. Existem detalhes abrangentes sobre isso em seu Visão Técnica.

Embora a Fluidkey tenha a desvantagem de manter a visibilidade nas contas de um usuário, isso pode realmente ser uma vantagem quando se trata de conformidade, embora o quadro exato de como a Fluidkey lidará com coisas como possíveis solicitações de aplicação da lei no futuro ainda não esteja publicamente disponível. No entanto, eles estão sediados na Suíça e, embora tenham que cumprir as leis locais, as leis de proteção de dados são muito claras e muito fortes — tem que haver um caso muito claro para compartilhar os dados e também teria que ser analisado por um tribunal (ver este postpara uma excelente visão geral das leis de privacidade na Suíça).

Os usuários também são totalmente livres para exportar suas transações ou compartilhar suas chaves de visualização com terceiros (por exemplo, seu contador), o que pode ser extremamente útil, especialmente para empresas. Vale a pena lembrar, no entanto, que com a especificação erc-5564, compartilhar a chave pública é 'tudo ou nada', o que significa que não pode revelar transações individuais isoladas por si só. Além disso, como em todas as implementações de erc-5564, a rastreabilidade não é quebrada - apenas a vinculação ao usuário - o que significa que o histórico de transações de cada endereço oculto é exposto a quem possui a chave de visualização. Um recurso não muito conhecido do Fluidkey que ajuda a mitigar essas compensações é a capacidade de girar as chaves de visualização, o que permitiria que um usuário usasse uma nova chave de visualização a cada mês e compartilhasse apenas o acesso à visualização de meses específicos com um terceiro.

Um bom benefício da abordagem da Fluidkey é que o endereço furtivo em si não é gerado pelo remetente, é gerado pela própria Fluidkey pseudoaleatoriamente cada vez que o ENS é consultado. Isso é muito mais rápido porque os usuários não precisam procurar eventos de anúncio para identificar transações em que são o destinatário. Isso também significa que o remetente não precisa de uma carteira de endereço furtivo para gerar um endereço furtivo para o destinatário - basta enviar fundos para um endereço como fariam para qualquer outro endereço e pronto. Isso também significa que não há contrato do registro envolvido, o que é único no design da Fluidkey e uma grande vantagem.

Vale a pena dizer que a Fluidkey está comprometida em ser totalmente auto-custodial, e eles tornaram open source sua biblioteca Stealth Account Kit, e também existem várias interfaces de recuperação desenvolvidas de forma independente disponíveis no caso improvável de a Fluidkey desaparecer da noite para o dia, significando que os fundos nunca serão bloqueados ou presos.

Abstração de Endereço

Ao usar contas de contrato inteligente de forma contrária, o Fluidkey pode automaticamente abstrair o gerenciamento dos endereços ocultos individuais. Isso significa que, se você quiser transferir uma quantia específica para um determinado destinatário de seus saldos em vários endereços ocultos, o Fluidkey pode automaticamente descobrir qual combinação de endereços usar para obter os fundos para a transferência, lidando com todos os custos de gás e implantações de contratos, tudo nos bastidores. O Fluidkey também permite que os usuários exerçam algum controle sobre quais endereços são combinados usando um recurso legal chamado rótulos, que permitem que o usuário marque endereços em diferentes categorias.

Resolução ENS

Fluidkey requer que os usuários criem nomes ENS que sejam específicos para o Fluidkey. Esses nomes estáticos assumem duas formas: username.fkey.id e username.fkey.eth, uma que é um URL para a interface da web para enviar fundos a alguém, e a outra um nome ENS padrão que pode ser usado com carteiras.

A configuração do ENS usa um Resolvedor offchain ENS (aka erc-3668: CCIP Read) para retornar endereços furtivos. Sempre que o resolvedor off-chain é consultado, ele gera e retorna um novo endereço furtivo para o respectivo nome ENS. Isso é uma ótima funcionalidade, pois permite que o usuário tenha um único nome ENS legível por humanos e ainda mantenha a privacidade dos endereços furtivos, já que os endereços furtivos gerados não podem ser vinculados ao nome ENS retrospectivamente.

Custo

Fluidkey é gratuito e não cobra uma taxa. Existe o custo de implantar um contrato Safe para cada endereço que possui fundos quando você deseja gastar esses fundos. No entanto, embora seja relativamente caro na mainnet, nos L2s é realmente bastante negligível, geralmente menos de 1 centavo, mesmo ao combinar vários endereços furtivos em uma única transferência.

Eles também podem patrocinar o gás através das implantações seguras - eles calculam quanto o gás vai custar e retiram isso do saldo dos usuários, mesmo que seja um token - nesse caso, um relayer implanta o cofre e transfere o token em nome do usuário.

Umbra Cash

Umbraé uma implementação de eip-5564 + eip6538 porScopelift. Quando um usuário faz login no aplicativo Umbra, ele passa por uma fase de configuração, na qual ele assina uma mensagem, a partir da qual são derivadas as chaves de gastos e visualização e o respectivo meta-endereço oculto. Em seguida, ele registra este meta-endereço oculto em seu endereço de carteira principal em um registro on-chain. É aqui que a implementação difere do Fluidkey.

A implementação da Umbra do erc-5564 é a mais próxima da especificação, pois eles não têm acesso às chaves do usuário. Embora isso signifique que a Umbra (ou qualquer outra pessoa) não possa ver os fundos dos usuários, isso significa que, para receber fundos, o remetente precisa ter uma carteira compatível com erc-5564 (ou o aplicativo da Umbra) para gerar seu meta-endereço furtivo.

Quando alguém querenviarAo enviar fundos para um usuário, eles normalmente usariam o aplicativo Umbra para fazê-lo. Essencialmente, o aplicativo Umbra procurará o meta-endereço furtivo registrado em um nome ENS / endereço de carteira e gerará um endereço furtivo. Os destinatários podem fazer login no aplicativo Umbra e procurar por quaisquer fundos enviados para endereços furtivos pertencentes a eles desde a última vez que fizeram login. Graças a um cache inteligente, isso parece levar apenas 10-15 segundos para uma verificação semanal, embora os usuários também possam especificar opcionalmente um intervalo de blocos para estreitar a varredura. O Umbra v2 incluirá o uso de viewtags, o que acelerará ainda mais o processo.

Relayer

Um problema com endereços furtivos que mencionamos anteriormente é que, para que o destinatário gaste os fundos enviados para um endereço furtivo, esse endereço precisará ter ETH ou outro token de gás requisito para pagar as taxas de transação. Na maioria das redes, se o endereço furtivo recebeu ETH em primeiro lugar, isso geralmente não é um problema. No entanto, se o endereço furtivo recebeu um token erc-20 ou NFT, então o ato de financiar o endereço com ETH para pagar o gás pode vincular o endereço aos outros endereços de um usuário, removendo sua privacidade.

Para contornar isso, a Umbra usa uma construção envolvendo um relayer. Quando qualquer ativo que não seja ETH é enviado para um usuário da Umbra, ele é na verdade enviado para um contrato especial em vez de ser diretamente para o endereço oculto. Os usuários podem gastar fundos enviados para seus endereços ocultos enviando uma meta-transação (do aplicativo Umbra) para o relayer da Umbra, que transferirá os fundos do contrato inteligente em nome do usuário. O relayer deduzirá alguns tokens para cobrir os custos das taxas de gás, e apenas um certo número de tokens é suportado inicialmente.

Custo

O contrato Umbra também aplica uma pequena taxa ao transferir fundos em redes com baixas taxas de transação, a fim de desestimular o spam. A justificativa é que o spam aumentaria o custo de vasculhar transações para identificar as relevantes, e isso é considerado uma compensação aceitável.

Redes suportadas

Umbra está atualmente implantado na mainnet do Ethereum, bem como no Optimism, Polygon, Gnosis Chain e Arbitrum.

O contrato de registro da Umbra tem um design interessante. O método de implantação usa create2 e o implantador padrão create2, e o endereço do contrato inteligente é o mesmo em qualquer rede. Isso significa que se o contrato existe em uma determinada rede, então o cliente pode ter certeza de que é o contrato certo. O cliente pode ser configurado para adicionar redes, e qualquer pessoa pode implantar em qualquer rede. Eles canonizaram o bytecode e o contrato não tem proprietário, o que permite a implantação sem permissão de contratos de registro e anúncio em qualquer cadeia por qualquer pessoa.

Umbra v2

Scopelift está atualmente em desenvolvimentoversão 2 do Umbra, que introduz uma nova arquitetura modular que permite que os contratos principais sejam estendidos para suportar novos padrões de tokens ou casos de uso de não pagamento. Usando essa nova arquitetura, desenvolvedores de terceiros podem construir módulos para qualquer tipo de padrão de token, por exemplo, erc-1155, erc-7621, suporte para paymasters erc-4337 ou qualquer outra coisa que você possa imaginar. Atualmente, o contrato principal da Umbra suporta dois cenários, um para ETH e outro para erc-20. V2 suportará muitos cenários diferentes.

Labirinto

Labirintoé um protocolo que não se baseia em eip-5564 + eip6538, mas em vez disso usa provas de conhecimento zero para adicionar anonimato e privacidade às transações. O whitepaper do Labyrinth descreve-o como um middleware “zkFi”: “zkFi oferece uma solução embalada que atua como um middleware de privacidade com conformidade integrada”. A conformidade integrada refere-se ao “Desanonimização Seletiva” do Labyrinth, que é uma solução sofisticada que permite que certas transações sejam desanonimizadas para atores autorizados específicos, ou seja, autoridades legais como interpol, etc., mantendo a transparência e a abertura.

Os contratos inteligentes principais que o Labyrinth usa incluem um pool de várias transações e ativos múltiplos que permitem ao usuário transacionar vários ativos em uma única transação. Para gastar ativos, um usuário verifica a rede e busca dados de notas criptografadas, descriptografa as notas e filtra os ativos que deseja gastar. Posteriormente, o usuário cria uma ZKP que inclui as transações e uma assinatura da chave de assinatura associada às transações de notas que deseja gastar.

Parte dos contratos principais do Labrynth inclui um contrato de conversão, que se comunica com contratos proxy modulares, que são basicamente proxies para contratos externos. Então, por exemplo: se um usuário quer usar o Labyrinth para interagir com o Uniswap, o usuário criaria uma transação que usaria o contrato de conversão para chamar uma operação de troca em um pool do Uniswap via contrato proxy do Uniswap.

O protocolo zkFi da Labyrinth usa "notas" para rastrear saldos e transferências. Uma nota é essencialmente uma estrutura de dados que descreve alguma quantidade de algum ativo e a qual endereço pertence. Um cliente armazena as informações necessárias para recriar uma nota e usa isso para gastar ativos. Um comprometimento com a nota (um hash do id do ativo, proprietário e valor) é armazenado em uma árvore de merkle on-chain. Na verdade, Labyrinth usa duas árvores de merkle, uma para notas e outra para endereços raiz.

A estrutura de dados da nota contém o seguinte:

• assetId: Identificador do ativo (ETH, WBTC, MATIC, etc.) que esta nota representa o valor de.
• Valor: Valor ou quantidade que a nota representa.
• leafIndex: O índice da folha da árvore de merkle de compromisso onde esta nota será inserida.
• ocultação: Um fator de ocultação aleatório.
• rootAddress: O endereço raiz de um usuário com autoridade para gastá-lo.
• revogador: O ponto de chave pública do revogador escolhido.

Você notará que a estrutura de dados acima não contém nenhuma referência ao proprietário dos ativos, o que é estranho, pois o compromisso registrado na árvore merkle de notas é um hash do id do ativo, valor e proprietário. Na verdade, o proprietário é calculado a partir do endereço raiz, do revogador e de um fator de cegamento aleatório, e assim, para observadores externos, o proprietário é, na verdade, um endereço recém-criado para cada nova transação.

Pool Protegido

O que é realmente interessante sobre o Labirinto, que também é ligeiramente diferente dos protocolos baseados em endereço de sigilo, é que o pool de ativos é na verdade um pool protegido, que usa o conceito de notas para criar uma espécie de pool protegido de UTXO que oferece segurança avançada para as transações. Lembre-se de que, com as implementações eip-5564, a entidade para quem um usuário transfere fundos poderá ver de onde esses fundos vieram. Em outras palavras, Alice paga Bob usando um endereço de sigilo, Bob paga Charlie, então agora Charlie pode ver que Bob inicialmente recebeu os fundos de Alice, e assim por diante. Isso não acontece com o pool protegido do Labirinto.

Para entender como este pool protegido funciona, precisamos analisar como os fundos são transferidos dentro do protocolo:

Os saldos de um usuário no pool protegido são a soma das notas dos respectivos ativos. Para gastar essas notas, o usuário precisa revelar os “anuladores” dessas notas. Um anulador é único para uma nota e, uma vez que essa nota é gasta, o anulador é marcado para evitar gastos duplos e uma nova nota é criada a partir dessa nota gasta. Várias notas do mesmo ativo podem ser combinadas e várias novas notas podem ser criadas. O anulador é simplesmente o hash de (𝑙,𝑐,𝛿), onde 𝑙 é o índice do compromisso da nota na árvore merkle das notas, e 𝑐 é o compromisso, e 𝛿 é um elemento aleatório também conhecido como fator de ofuscação.

Um destinatário de uma transferência de transação oculta identifica a transferência da mesma forma que o eip-5564, na medida em que eles ouvem os eventos emitidos pelos contratos principais e determinam quais endereços ocultos eles serão capazes de enviar fundos, registrando-os localmente. A identificação de fundos recebidos também é acelerada utilizando tags de visualização e sincronização e armazenamento em cache local de notas de forma assíncrona durante a vida útil do aplicativo.

Há pesquisas em andamento para tornar o processo de descoberta de fundos recebidos mais rápido, como por exemplo esta proposta da Aztec:Solicitação de Propostas: Protocolo de Descoberta de Notas — Aztec.

Para gastar os fundos, o usuário também precisa gerar uma prova zk, ao contrário das implementações erc-6654, que são basicamente endereços Ethereum normais. Gerar uma prova requer uma carteira compatível, com o desempenho sendo relativamente bom, levando cerca de 20 segundos ou algo parecido em um dispositivo Android de médio porte.

Bundler e Conversor

Existem algumas características interessantes que o Labyrinth oferece, que resolvem alguns pontos problemáticos das transações furtivas. As transações enviadas para os contratos principais do Labyrinth são enviadas como operações de usuário através dos agrupadores erc-4337. Essa configuração permite gastar notas sem ETH ou exigir tokens de gás para as transações, pois o usuário pode aproveitar o pagador erc-4337 para pagar o gás em seu nome, o que adiciona uma camada adicional de privacidade. A única exceção é o depósito inicial, que não é enviado como uma operação de usuário. O uso do pagador er-4337 também tem a vantagem adicional de poder pagar pelo gás através dos ativos transferidos, mesmo que sejam tokens erc-20, e para isso o Labyrinth expõe uma API de oráculo de preço do gás.

Outra característica muito legal que o Labyrinth tem é uma arquitetura modular que permite que os contratos de conversor atuem como proxy para dapps de terceiros. Isso permite que os usuários não apenas transfiram fundos usando transações furtivas, mas também interajam com dapps de terceiros, como DEXs (por exemplo, Uniswap, Aave, Lido etc.). Esses contratos "conversores" de procuração implementam essencialmente uma função que leva em que alguma quantidade de um ativo, e alguma quantidade de ativo sai, com a lógica subjacente residindo em algum contrato de terceiros.

Solução de conformidade

Labirinto garante conformidade e aderência regulatória através de um quadro chamado Desanonimização Seletiva (SeDe).

Lembre-se de que a estrutura de dados de uma nota contém um campo chamado 'revoker'. O revoker é o endereço de uma entidade específica que pode iniciar o processo de desanonimização. Um usuário deve escolher pelo menos um revoker de uma lista predefinida. O revoker não é o único responsável por identificar atividades potencialmente ilícitas ou ilegais, mas pode responder a solicitações de agências de aplicação da lei.

Os revogadores não têm a capacidade unilateral de desanonimizar transações diretamente, mas são responsáveis por iniciar solicitações de desanonimização. Essas solicitações são publicadas publicamente aos guardiões, que são um comitê de entidades que supervisionam a privacidade e conformidade. Os guardiões devem responder à solicitação votando se concedem ou não permissão para desanonimizar a(s) transação(ões). Se os guardiões puderem atingir um quórum e votar a favor, então o revogador pode descriptografar os dados da transação, permitindo-lhes vincular a transação em questão às transações anteriores até que a cadeia de transações tenha sido totalmente desanonimizada.

Este sistema cria uma série de verificações e equilíbrios, na medida em que os guardiões não podem decidir unilateralmente revelar dados de transação, e mesmo que eles colidam, eles não podem fazer nada sem o revogador, e o revogador sozinho não pode fazer nada com a maioria dos votos dos guardiões.

Railgun

RAILGUNé um sistema de privacidade de transação furtiva implantado na Ethereum, BSC, Polygon e Arbitrum. O protocolo é semelhante de certa forma ao Labyrinth, na medida em que é baseado em notas, que são armazenadas em uma árvore de merkle como compromissos e formam um conjunto UTXO, ou seja, as notas podem ser gastas criando novas notas para outros destinatários. Para gastar uma nota, um anulador é adicionado ao estado dessa nota, impedindo gastos duplicados. Somente o proprietário de uma nota pode calcular seu anulador, que é baseado no hash da chave de gasto e no índice das notas na árvore de merkle, ou seja, apenas o proprietário da nota pode gastá-la (e só pode gastá-la uma vez).

Os meta-endereços ocultos no Railgun usam o prefixo “0zk” e, assim como o eip-5564, é uma concatenação da chave pública de visualização e da chave pública de gastos. No entanto, o Railgun usa chaves Ed25519 na curva BabyJubJub em vez de ECDSA e secp256k1. Da mesma forma que o eip-5564, os usuários examinam todos os eventos emitidos pelos contratos Railgun e usam sua chave de visualização para determinar quais eventos representam transferências para sua carteira.

O Railgun usa uma rede de transmissores, que são essencialmente relayers que aceitam meta-transações dos usuários e transmitem a transação real para o respectivo blockchain, pagando as taxas de gás em nome do usuário. As interações diretas com os contratos do Railgun vêm dessa rede de transmissores, protegendo o anonimato dos usuários finais. As transações enviadas pelos usuários para os transmissores são criptografadas para a chave pública de um transmissor específico e comunicadas usando o Protocolo Waku.

Railgun possui uma arquitetura modular que permite interagir com contratos inteligentes externos, permitindo funcionalidades além de simples transferências. Ele faz isso por meio do contrato AdaptRelay, que protege e desprotege os tokens antes e depois da interação com um contrato externo, por exemplo, desproteger o token A, trocar pelo token B em alguma AMM, proteger o token B de volta para o proprietário original.

Com a versão 3, Railgun planeja aproveitar o EIP-4337, bem como suportar meta-transações legadas. Eles esperam que, ao manter uma mempool de usuárioop dedicada ao EIP-4337 para Railgun, solucionadores independentes possam participar como transmissores. Atualmente, estão colaborando com a Umbra nesta pesquisa, identificando casos específicos e como abordá-los, veja a seção Railgun v3 abaixo para mais detalhes.

Taxas

O protocolo Railgun cobra uma taxa de 0,25% para depósitos e saques. Essas taxas são enviadas ao tesouro DAO e são pagas ao longo do tempo aos detentores do token de governança RAIL. Além da taxa de depósito e saque de 0,25%, os transmissores geralmente aplicam sua própria taxa, que geralmente é de aproximadamente 10% do valor da taxa de gás para a transação real na cadeia.

Governança

Railgun possui um sistema de governança que permite que qualquer forma de proposta seja submetida, e nenhuma alteração em nenhum dos contratos principais (incluindo contratos de tesouraria e governança) pode acontecer sem proposta DAO. Incomumente, instâncias separadas do Railgun têm sua própria governança. Por exemplo, Railgun na Ethereum, Polygon e Binance Chain têm seus próprios sistemas e tokens de governança separados.

SDK e Livro de Receitas

O Railgun oferece um SDK abrangente e bem documentado que os desenvolvedores de carteira ou dapp podem usar para criar a funcionalidade de endereço furtivo por meio do suporte ao Railgun. Railgun também tem uma comunidade mantida livro de receitascom “receitas” que permitem aos desenvolvedores de dapp fornecer módulos para Railgun que permitam aos usuários interagir com seu dapp usando Railgun. Por exemplo, um desenvolvedor pode escrever uma receita para uma DEX que permita aos usuários com saldos de tokens em Railgun trocar tokens de forma privada.

RailGun v3

A próxima iteração do Railgun tornará as transações cerca de 50% - 60% mais baratas. As outras mudanças na versão 3 são a mudança para o suporte de userops eip-4337 via uma mempool dedicada. Além disso, a v3 fornecerá suporte para uma arquitetura baseada em intenções, que permitirá que os solvers compitam pela melhor execução, embora os detalhes sejam muito superficiais no momento da escrita. Eles estão trabalhando atualmente com CowSwapsobre isso e planejo usar ganchos pré e pós para permitir que os solvers acessem os fundos.

Conexão Railgun

Possivelmente a mudança mais interessante proposta é algo chamado Railgun Connect, que é descrito como uma ferramenta semelhante ao WalletConnect, pois permite que os endereços 0zk se conectem à maioria dos frontends para uso privado, sem exigir que esses dapps forneçam integração explícita com o Railgun por meio de módulos personalizados.

Railgun Connect é uma extensão do navegador, e o que ela faz na verdade é bifurcar o estado da cadeia localmente usando o HardHat sob o capô, e injeta seu próprio provedor web3 no dapp, com um ponto de extremidade RPC da versão local do HardHat da cadeia. Isso então permite que você realize as interações com os contratos do dapp como normalmente faria, registra as transações, em seguida, agrupa-as e cria uma prova de snark, e envia isso para os contratos reais do Railgun na cadeia real. Embora esta descrição seja um pouco simplista, ela transmite a ideia geral. O que isso faz é permitir que você basicamente interaja com virtualmente qualquer dapp (com alguns casos excepcionais para dapps que fazem processamento extra fora da cadeia). A ressalva é que salvar o estado da cadeia localmente é uma operação pesada, mas uma vez feito, significa que você pode interagir com dapps usando os endereços furtivos do Railgun sem ver nenhuma diferença do uso de uma carteira normal.

Conclusão

Existem algumas propostas interessantes para consagrar endereços furtivos no protocolo Ethereum. Por exemplo, Incousa a ideia de um “wrapper” erc-20, que envolve um contrato erc-20 normal e criptografa todos os saldos. As transferências e aprovações são todas realizadas no estado criptografado via criptografia totalmente homomórfica. A Inco depende de pré-compilações que atualmente só existem em sua própria rede, mas podem um dia chegar ao Ethereum.

Também há outra proposta chamadaEIP-7503: Wormholes de Conhecimento Zeroque é baseado em um design chamado 'prova de queima', embora isso não pareça estar ganhando muita tração, provavelmente porque requer uma atualização para o EVM, sem a qual só pode ser implementado no nível do token, usando um design erc-20 que suporta especificamente o eip-7503 (ou se um L2 decidir adicionar suporte aos seus opcodes do EVM).

Aztecé talvez a tecnologia de privacidade mais sofisticada disponível, mas requer que os usuários enviem fundos para a Aztec para usá-la, o que pode ou não ser uma UX inaceitável para a maioria dos usuários. No entanto, se a demanda por privacidade básica em transações crescer entre os usuários do Ethereum, então a Aztec poderia ter uma proposta de valor única que a torna uma L2 muito valiosa, à medida que aplicativos descentralizados e usuários migram para uma plataforma que lhes proporciona privacidade por padrão.

Da mesma forma, Intmaxé uma Ethereum L2 (com base em um design de Plasma) que tem foco em privacidade e também tem um aspecto de conformidade regulamentar, verificando a legitimidade dos fundos individuais por meio de provas de AML baseadas em ZKP e impondo limites aos valores das transações. Intmax é limitado em termos de fornecer privacidade para transferências, enquanto as operações de contratos inteligentes da EVM não são privadas. No entanto, ao contrário da Aztec, os contratos inteligentes podem ser escritos em Solidity, o que alguns desenvolvedores podem preferir (dependendo do caso de uso).

Suporte de Carteira

Embora estejamos vendo aumento da adoção de protocolos de endereço furtivo, o que é promissor, ainda existem vários desafios. O desafio mais importante é que eles não são totalmente suportados em carteiras Ethereum convencionais (pelo menos por enquanto). As carteiras convencionais provavelmente terão várias opções a considerar se desejarem oferecer suporte para endereços furtivos. Algumas dessas opções incluem:

• Eles fornecerão suporte opinativo para uma única implementação, ou eles construirão e manterão algum tipo de agregador abrangente entre vários protocolos? Este último provavelmente será proibitivamente caro em termos de desenvolvimento e manutenção.
• Haverá considerações regulatórias e eles precisarão tomar uma posição sobre a extensão e o mecanismo de desanonimização seletiva (ou seja, como o Labirinto)?
• Os endereços furtivos requerem um componente on-chain vis-à-vis o contrato de registro (exceto Fluidkey), o que significa que cada rede EVM deve ser explicitamente suportada pela carteira (embora o design da Umbra facilite a implantação sem permissão do registro).
• Os endereços furtivos tornam as integrações existentes com exploradores de blocos (por exemplo, Etherscan) mais complicadas. Por exemplo, o botão 'Ver no Explorador' não funcionará para um meta-endereço furtivo, onde a carteira mostra o saldo agregado. Esse problema também pode existir para transferências. Os vários casos especiais, como esse, precisarão ser pensados.
• Dependendo da implementação subjacente, um usuário só poderá usar o endereço oculto de forma eficaz com um conjunto específico de dapps, ou seja, aqueles que são suportados pelo protocolo subjacente. Isso será possível com arquiteturas modulares de endereços ocultos. No entanto, nem todos os dapps serão suportados, e isso precisará ser comunicado de alguma forma ao usuário. É um pouco mais fácil com eip-5506, mas ainda possui suas complicações e casos específicos, e isso pode acabar vazando para a experiência do usuário da carteira.

Há também espaço para melhorias na prevenção da má higiene de privacidade do usuário, veja este artigo: “Análise de Anonimato do Esquema de Endereço Oculto Umbra na Ethereum” para como os autores conseguiram desanonimizar com sucesso 48,5% das transações furtivas na rede principal do Ethereum. As heurísticas que eles usaram para fazer isso não tinham nada a ver com os protocolos e mais em torno da higiene de privacidade, por exemplo, um usuário envia fundos para um endereço furtivo que eles controlam e, em seguida, envia esses fundos de volta para o endereço de onde originalmente os enviaram, pensando equivocadamente que a rastreabilidade está quebrada. No geral, os autores identificaram 6 heurísticas diferentes que podem ser usadas para desanonimizar transações de endereço furtivo, principalmente todas baseadas em não seguir as melhores práticas. No entanto, essas são questões críticas de UX que precisam ser abordadas.

No geral, estou bastante otimista em relação aos endereços furtivos e à privacidade no Ethereum em geral. Acredito que fizemos um progresso bastante impressionante e descobrimos alguns desafios que são muito solucionáveis. Estou confiante de que as carteiras convencionais descobrirão como fornecer o nível de suporte para endereços furtivos que permita aos usuários usá-los com o mínimo de atrito e pensamento, proporcionando o nível normal de privacidade que os usuários esperam e merecem.

Um grande agradecimento a todas as equipes que dedicaram tempo e trabalho árduo para pesquisar e construir infraestrutura de endereço furtivo, incluindo os quatro protocolos sobre os quais falei neste post. Seu trabalho árduo e tenacidade farão uma enorme diferença para o Ethereum!

Aviso legal:

1. Este artigo é reimpresso de [Médio]. Todos os direitos autorais pertencem ao autor original [Simon Brown]. Se houver objeções a esta reimpressão, por favor, entre em contato com o Gate Learnequipe e eles resolverão isso prontamente.
2. Isenção 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 Gate Learn faz traduções do artigo para outros idiomas. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.