Introdução

Um dos principais pontos problemáticos para os usuários de criptomoedas da 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 nome ENS legível, é um desincentivo para os usuários realizarem certas atividades, ou faz com que eles realizem essas atividades de maneiras que resultam em maior fricção de 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 o saldo de sua 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 essas razões 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 o Tornado Cash, é uma experiência um tanto subótima por várias razões. Em primeiro lugar: os usuários terão razão em se preocupar com a possibilidade de terem seu endereço colocado em lista negra em bolsas 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 ocultos fornecem uma maneira de oferecer ao usuário a privacidade que eles têm com as contas bancárias privadas e de uma maneira fácil de entender. Além disso, as inovações em torno dos endereços ocultos significam que podemos potencialmente fazer isso de uma maneira que esteja em conformidade com as regulamentações de AML em várias jurisdições.

Demanda do utilizador por privacidade

Embora a pesquisa sobre as atitudes em relação à privacidade entre os usuários da web e da web3 não esteja amplamente disponível, a pesquisa abaixo foi descoberta por meio de pesquisas na web e os resultados se alinham amplamente e demonstram que há um claro interesse pela privacidade das 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 especificou que a privacidade das transações é muito importante para eles". Embora esta pesquisa estivesse mais relacionada ao Bitcoin do que ao Ethereum, é provável que haja atitudes semelhantes aos usuários do Ethereum também. O tamanho da amostra para esta pesquisa foi, no entanto, bastante pequeno (14 participantes).
2. Outra peça interessante de pesquisa 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 criptomoedas pesquisados. Os resultados mostraram que cerca de um quarto dos entrevistados indicou que a privacidade é "a característica mais importante da blockchain e das criptomoedas".

1. Em termos de atitudes em relação à privacidade em geral, Consensyspublicou uma pesquisa intituladaPesquisa global sobre Web3 e criptomoedas 2023, em que entrevistaram 15.158 pessoas online em 15 países sobre vários temas relacionados à web, e não apenas criptomoedas. A pesquisa descobriu que 83% dos entrevistados consideram a privacidade de dados importante, enquanto apenas 45% dos entrevistados afirmaram confiar em como os serviços de Internet atuais usam seus dados e informações pessoais.
2. Um inquérito realizado 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 sua razão para investir em criptomoeda.

Adoção de Protocolos de Transação Furtiva

Railguntem números impressionantes, com o uso do protocolo parecendo estar crescendo 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 na mainnet do Ethereum - fonte:Railgun — DefiLlama

Umbratambém tem visto um aumento constante de pessoas usando seu protocolo (pessoas registrando um endereço furtivo em seu ENS), com quase 77.000 até novembro de 2024:

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

Se olharmos para o protocolo de privacidade mais conhecido (e agora infelizmente infame) no Ethereum, que é o Tornado cash, podemos ver que ainda está sendo usado significativamente, apesar do fato de que os endereços do contrato 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 seu 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 à colocaçã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 tem visto um crescimento constante, apesar das sanções, atingindo quase $600M em TVL. Esta é uma evidência bastante forte 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 as cadeias EVM em produção até hoje, são elas:

• Fluidkey
• Umbra
• Labirinto
• Arma ferroviária

Tanto o Fluidkey como o Umbra são baseados nos padrões do Ethereum, que são:

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

Labirinto e Railgun são baseados no protocolo zerocash (which zcashé também baseado no), que usa um pool protegido no qual os usuários depositam fundos. 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, chave do proprietário e um número único (um nulificador), com zk-SNARKs usados para verificar a propriedade sem revelar detalhes e, portanto, transferir o valor nas notas. Quando uma nota é gasta, seu nulificador é revelado para evitar gastos duplos, enquanto novas notas são criadas para o (s) destinatário (s), formando um sistema UTXO dentro do pool protegido.

Em termos gerais, os endereços ocultos 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, posteriormente pode 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 para o 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 que haja qualquer comunicação direta. Todas as implementações de endereços stealth funcionam com base neste princípio básico.

Como funcionam os Endereços Furtivos

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

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

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

O diagrama seguinte esboça o processo de ponta a ponta, esperamos que de forma um pouco mais clara:

Lembre-se de que esse processo acontece totalmente de forma não interativa, o que significa que o remetente e o destinatário nunca têm qualquer comunicação direta, o que significa que efetivamente não há qualquer vínculo entre o remetente e o destinatário que qualquer terceiro possa observar.

No entanto, para que isto funcione em primeiro lugar, o destinatário deve tornar o seu endereço oculto conhecido pelos remetentes. Uma forma de o fazer é usar o Registo de Endereço Meta-Stealth EIP-6538. Este é um contrato singleton que permite aos utilizadores registarem um meta-endereço stealth para um endereço Ethereum normal, que os remetentes podem então consultar. Isso permite que os remetentes resolvam o endereço normal a partir do ENS e em seguida consultem o meta-endereço stealth associado ao registo.

Este esquema quebra a ligação entre o remetente e o destinatário, proporcionando a ambos privacidade em relação ao mundo inteiro saber dos seus negócios. Há algumas ressalvas:

• Quando o destinatário for gastar os fundos, quem quer que transfira esses fundos verá que eles têm origem no remetente original (ou seja, eles podem ver o endereço de onde os fundos foram transferidos e quem enviou anteriormente fundos para esse endereço). O que isto 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 dos seus endereços não-stealth conhecidos). Note que isto só se aplica às implementações erc-5564, não a Railgun ou Labyrinth.
• Outro efeito colateral do problema acima é que, para manter a privacidade ideal, um 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 uma sobrecarga para lembrar os endereços e, posteriormente, gastar os fundos nesses endereços, pois a quantia que você deseja transferir precisará ser obtida a partir da combinação de fundos de 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. Este é um problema conhecido com endereços furtivos, e uma das razões pelas quais um número de implementações implementou suporte para eip-4337 e um pagador.
• Uma desvantagem do esquema de endereço oculto é que os destinatários precisam monitorar a blockchain para 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 “etiqueta 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 as etiquetas 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 a queda de desempenho é realmente perceptível é quando uma carteira está sendo restaurada, nesse caso, a carteira precisará verificar cada endereço desde que o contrato on-chain foi implantado, o que consome tempo.
• Para contornar isso, os usuários podem optar por compartilhar a chave de visualização privada com uma terceira parte confiável. Este serviço de terceiros pode monitorar várias redes e notificar os usuários quando eles receberem fundos. Isso, é claro, tem uma compensação: embora a terceira parte não possa realmente gastar os fundos dos usuários (eles não têm a chave de gasto privada para fazê-lo), 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 oculto, 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 de contrato inteligente arbitrário, exigem um pouco mais de engenharia e geralmente são específicos da implementação.

Matriz de Comparação

Existem várias maneiras pelas quais podemos 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 obfuscação do valor.

Embora tanto o Fluidkey quanto o Umbra permitam a transferência de fundos para um endereço Ethereum padrão sem quebrar 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. O Railgun e o Labyrinth ocultam o remetente, bem como o valor sendo enviado, mas com o compromisso 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ços ocultos em seis dimensões principais:

1. Privacidade completa de ponta a ponta (apenas o remetente e o destinatário veem o pagamento)
2. Forward-secrecy. Enviar fundos que foram recebidos por meio de transações ocultas não permite que o segundo destinatário veja de onde os fundos se 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 oferece algum nível de conformidade por meio de algum tipo de suporte de desanonimização?
7. O design suporta a obfuscação do valor/quantidade que está a ser transferido?

| Protocolo | Privacidade E2E | Segurança Avançada | Padrão Aberto | Arquitetura Modular | SDK | Suporte de Desanonimização | Valores Ocultos |

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

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

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

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

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

Alguns dos outros pormenores e diferenças são capturados com mais detalhes na secção seguinte. Cada implementação tem diferenças subtis 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 furtivos na cadeia, com o Umbra: apenas ETH vai para endereços furtivos na cadeia, enquanto tokens vão para contrato central, e com Railgun e Labyrinth, todas as transações vão para contratos principais, não diretamente para endereços furtivos na cadeia.

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

Fluidkey

Chave fluidaé uma implementação do erc-5564 que permite aos utilizadores enviar, receber, trocar e fazer a ponte entre tokens ETH e erc-20. No momento da escrita, Fluidkey está implementado em Base, Optimism, Arbitrum, Polygon, Gnosis e na mainnet da Ethereum.

Os utilizadores interagem com o Fluidkey através da sua interface web. Quando fazem login pela primeira vez usando a sua carteira, assinam uma mensagem de geração de chaves a partir da qual são derivadas as suas chaves de visualização e gastos. Estas mesmas chaves são regeneradas da mesma forma sempre que o utilizador entra na aplicação.

Existem 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 receber pagamentos para esses endereços. No entanto, isso significa que o Fluidkey está em uma posição para visualizar as transações de entrada e os saldos do usuário, o que é uma compensação. No entanto, ainda permanece totalmente auto custodial.

Outro aspecto interessante do design da Fluidkey é que ele implementa uma conta de contrato inteligente para cada novo endereço furtivo. Isso acontece de forma contrafactual apenas quando os fundos de um endereço furtivo são gastos. A conta inteligente é uma conta 1/1 Safe e permite coisas como patrocínio de gás, facilitando a gestão dos vários endereços furtivos juntos. Há detalhes abrangentes sobre isso no Visão Geral Técnica.

Embora a Fluidkey tenha a desvantagem de reter a visibilidade nas contas do usuário, isso pode potencialmente 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 disponível publicamente. Eles estão sediados na Suíça, no entanto, e embora tenham que cumprir as leis locais, as leis de proteção de dados são muito claras e muito fortes - teria que haver um caso muito claro para compartilhar os dados e também teria que ser analisado por um tribunal.ver esta publicaçãopara uma excelente visão geral das leis de privacidade na Suíça).

Os utilizadores também são totalmente livres para exportar as suas transações, ou partilhar as suas chaves de visualização com terceiros (por exemplo, os seus contabilistas), o que pode ser extremamente útil, especialmente para empresas. No entanto, é importante ter em mente que, com a especificação erc-5564, a partilha da chave pública é “tudo ou nada”, o que significa que não pode revelar transações individuais isoladas por si só. Além disso, tal como acontece com todas as implementações do erc-5564, a rastreabilidade não é quebrada - apenas a ligação ao utilizador - o que significa que o histórico de transações de cada endereço furtivo é exposto a quem tem a chave de visualização. Uma funcionalidade não muito conhecida do Fluidkey que ajuda a mitigar estes compromissos é a capacidade de rodar as chaves de visualização, o que permitiria a um utilizador utilizar uma nova chave de visualização a cada mês e apenas partilhar o acesso visual a 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 de forma pseudoaleatória toda vez que o ENS é consultado. Isso é muito mais rápido porque os usuários não precisam escanear eventos de anúncio para identificar transações em que são os destinatários. 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 - eles apenas enviam fundos para um endereço como fariam para qualquer outro endereço e pronto. Isso também significa que não há contrato de 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 disponibilizaram em código aberto sua biblioteca Stealth Account Kit. Existem também várias interfaces de recuperação desenvolvidas independentemente disponíveis no improvável evento de que a Fluidkey desapareça da noite para o dia, o que significa que os fundos nunca ficarão bloqueados ou presos.

Abstração de Endereço

Ao usar contas de contratos inteligentes de forma contrafactual, o Fluidkey pode automaticamente abstrair a gestão dos endereços furtivos individuais. Isso significa que, se você quiser transferir uma quantia específica para um determinado destinatário a partir dos seus saldos em vários endereços furtivos, o Fluidkey pode automaticamente descobrir quais combinações de endereços usar para obter os fundos para a transferência, tratando de todos os custos de gás e implantações de contratos, tudo nos bastidores. O Fluidkey também permite aos usuários exercer algum controle sobre quais endereços são combinados usando um recurso legal chamado rótulos, que permitem ao usuário marcar os endereços em diferentes categorias.

Resolução ENS

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

A configuração do ENS usa um Resolvente fora da cadeia ENS (aka erc-3668: CCIP Read) para devolver endereços furtivos. Cada vez que o resolvedor off-chain é consultado, ele gera e devolve um novo endereço furtivo para o respetivo nome ENS. Esta é uma ótima funcionalidade, pois permite a um utilizador ter um único nome ENS legível por humanos, mantendo ainda a privacidade dos endereços furtivos, uma vez que os endereços furtivos gerados não podem ser associados ao nome ENS retrospetivamente.

Custo

Fluidkey é gratuito e não cobra uma taxa. Há o custo de implantar um contrato de Seguro 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 negligenciável, geralmente inferior a 1 centavo, mesmo ao combinar vários endereços furtivos em uma transferência única.

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 se for um token - nesse caso, um relayer implanta o contrato seguro 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, eles passam por uma fase de configuração, na qual eles assinam uma mensagem, a partir da qual são derivadas as chaves de gastos e visualização e o respectivo metadado de endereço furtivo. Em seguida, eles registram este metadado de endereço furtivo 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 Umbra) para gerar seu meta-endereço oculto.

Quando alguém querenviarAo transferir fundos para um usuário, normalmente eles 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 verificar se há fundos enviados para endereços furtivos pertencentes a eles desde a última vez que fizeram login. Graças a um armazenamento em cache inteligente, isso parece levar apenas 10 a 15 segundos para uma verificação semanal, embora os usuários também possam especificar opcionalmente um intervalo de blocos para estreitar a verificação. O Umbra v2 incluirá o uso de visualização de tags, o que acelerará ainda mais o processo.

Relayer

Um problema com os endereços furtivos que mencionamos anteriormente é que, para que o destinatário gaste os fundos que foram enviados para um endereço furtivo, esse endereço precisará ter ETH ou outro token de gás necessário 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 do usuário, removendo sua privacidade.

Para contornar isso, a Umbra utiliza uma construção que envolve um intermediário. 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 enviado diretamente para o endereço oculto. Os usuários podem gastar os fundos enviados para seus endereços ocultos enviando uma meta-transação (do aplicativo da Umbra) para o intermediário da Umbra, que transferirá os fundos do contrato inteligente em nome do usuário. O intermediário 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 desincentivar o spam. A justificativa é que o spam aumentaria o custo de escanear transações para identificar as relevantes, e assim isso é visto como um compromisso 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 create2 padrão, e o endereço do contrato inteligente é o mesmo em qualquer rede. Isso significa que, se o contrato existir em uma determinada rede, 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 canonicalizaram o bytecode e o contrato não tem dono, 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 desenvolvimento versã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 não relacionados a pagamentos. Usando essa nova arquitetura, desenvolvedores de terceiros podem construir módulos para qualquer tipo de padrão de token, como erc-1155, erc-7621, suporte para pagamentos erc-4337 ou qualquer outra coisa que você possa imaginar. Atualmente, o contrato principal do Umbra suporta dois cenários, um para ETH e outro para erc-20. A versão 2 suportará muitos cenários diferentes.

Labirinto

Labirinto é um protocolo que não se baseia em eip-5564 + eip6538, mas 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 age como um middleware de privacidade com conformidade integrada“. A conformidade integrada refere-se à “Desanonimização Seletiva” do Labyrinth, que é uma solução sofisticada que permite que determinadas 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 multi-transacional e multi-ativos que permitem ao usuário transacionar vários ativos em uma única transação. Para gastar ativos, um usuário escaneia a rede e busca os dados das 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 notas que deseja gastar nas transações.

Parte dos contratos principais da Labrynth inclui um contrato de conversão, que se comunica com contratos de 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 a 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 da Uniswap por meio do contrato de proxy da Uniswap.

O protocolo zkFi do 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 ele pertence. Um cliente armazena as informações necessárias para recriar uma nota e usa isso para gastar ativos. Um compromisso com a nota (um hash do id do ativo, proprietário e valor) é armazenado em uma árvore merkle on-chain. Na verdade, Labyrinth usa duas árvores merkle, uma para notas, e outra para endereços de 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.
• cegante: um fator de cegamento aleatório.
• rootAddress: O endereço raiz de um usuário que tem a autoridade para gastá-lo.
• revogador: O ponto da 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, já que o compromisso registrado na árvore merkle das 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 ofuscação aleatório, e, portanto, para observadores externos, o proprietário é na verdade um endereço recém-criado para cada nova transação.

Grupo Protegido

O que é realmente interessante sobre o Labyrinth, que também é ligeiramente diferente dos protocolos baseados em endereços furtivos comuns, é que o pool de ativos é, na verdade, um pool blindado, que usa o conceito de notas para criar um tipo de pool UTXO blindado que oferece segredo avançado para transações. Lembre-se de que com as implementações do eip-5564, a entidade para quem um usuário transfere fundos poderá ver de onde vieram esses fundos. Em outras palavras, Alice paga Bob usando um endereço furtivo, 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 blindado do Labyrinth.

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

Os saldos de um usuário no pool blindado 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 de Merkle de notas, e 𝑐 é o compromisso, e 𝛿 é um elemento aleatório também conhecido como fator de cegamento.

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

Há pesquisas em curso para tornar o processo de descoberta de fundos recebidos mais rápido, como este exemplo de proposta da Aztec: Pedido 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 um desempenho relativamente bom, levando cerca de 20 segundos ou algo assim em um dispositivo Android de médio alcance.

Bundler e Conversor

Existem algumas características interessantes que a Labyrinth oferece para resolver alguns pontos de dor das transações furtivas. As transações enviadas para os contratos principais da Labyrinth são enviadas como operações de usuário via 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. Esse uso do pagador er-4337 também tem a vantagem adicional de poder pagar o gás por meio dos ativos transferidos, mesmo que sejam tokens erc-20, e para isso a Labyrinth expõe uma API de oráculo de preço de gás.

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

Solução de conformidade

O Labyrinth garante conformidade e adesão regulatória através de uma estrutura chamada Selective De-Anonymization (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 pré-definida. O revoker não é o único responsável por identificar atividades potencialmente ilícitas ou ilegais, mas pode responder a pedidos das 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 postadas publicamente para os guardiões, que são um comitê de entidades que supervisionam 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 votarem a favor, então o revogador pode descriptografar os dados da transação, permitindo que eles vinculem a transação em questão às transações anteriores até que a cadeia de transações tenha sido completamente 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 os dados da transação e, mesmo que coludam, eles não podem fazer nada sem o revogador, e o revogador sozinho não pode fazer nada com um voto majoritário dos guardiões.

Railgun

RAILGUNé um sistema de privacidade de transações furtivas implantado no 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 duplos. Apenas 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, o que significa que apenas o proprietário da nota pode gastá-la (e só pode gastá-la uma vez).

Os meta-endereços furtivos em Railgun usam o prefixo “0zk” e, como eip-5564, é uma concatenação da chave de visualização pública e da chave de gastos públicos. No entanto, o Railgun usa chaves Ed25519 na curva BabyJubJub em vez de ECDSA & secp256k1. Da mesma forma que o eip-5564, os usuários escaneiam 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 utiliza 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 desta rede de transmissores, protegendo o anonimato dos usuários finais. As transações que são enviadas de usuários para transmissores são criptografadas com a chave pública específica do transmissor e comunicadas usando a protocolo Waku.

O Railgun tem uma arquitetura modular que permite a interação com contratos inteligentes externos, permitindo funcionalidades além de simples transferências. Faz isso através do contrato AdaptRelay, que protege e desprotege os tokens antes e depois da interação com um contrato externo, por exemplo, desprotege o token A, troca pelo token B em algum AMM, protege o token B de volta para o proprietário original.

Com a versão 3, Railgun planeia alavancar o eip-4337, bem como apoiar transações meta-legadas. Eles esperam que, ao manter um mempool dedicado de userop eip-4337 para Railgun, solucionadores independentes possam participar como emissores. Atualmente, estão a colaborar com a Umbra na investigação deste assunto, identificando casos limite e como abordá-los. Consulte a secção Railgun v3 abaixo para mais detalhes.

Taxas

O protocolo Railgun cobra uma taxa de 0,25% para depósitos e levantamentos. Estas taxas são enviadas para o tesouro da DAO e são pagas ao longo do tempo aos detentores do token de governação RAIL. Além da taxa de 0,25% para depósitos e levantamentos, os emissores geralmente aplicam a sua própria taxa, que normalmente corresponde a cerca de 10% da taxa de gás para a transação real na cadeia.

Governança

Railgun tem 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 ocorrer sem proposta DAO. Incomum, instâncias separadas de Railgun têm sua própria governança. Por exemplo, Railgun na Ethereum, Polygon e Binance Chain têm seus próprios sistemas de governança e tokens separados.

SDK e Cookbook

O Railgun oferece um SDK abrangente e bem documentado que os desenvolvedores de carteiras ou dapps podem usar para incorporar a funcionalidade de endereço oculto através do suporte ao Railgun. O Railgun também possui uma comunidade mantidalivro de receitas com "receitas" que permitem aos desenvolvedores dapp fornecer módulos para Railgun que permitem aos usuários interagir com seu dapp usando Railgun. Por exemplo, um desenvolvedor pode escrever uma receita para uma DEX que permite que usuários com saldos de token no Railgun troquem 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 alterações na versão 3 são uma mudança para o suporte de eip-4337 userops via um mempool dedicado. Além disso, a v3 fornecerá suporte para uma arquitetura baseada em intenções, que permitirá que solucionadores compitam pela melhor execução, embora os detalhes sejam muito abstratos no momento da escrita. Eles estão atualmente trabalhando com CowSwape planejo usar ganchos pré e pós para permitir que os solucionadores acessem os fundos.

Railgun Connect

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 Railgun por meio de módulos personalizados.

Railgun Connect é uma extensão do navegador e o que faz na verdade é bifurcar o estado da cadeia localmente usando o HardHat por baixo dos panos e injeta o seu próprio fornecedor web3 no dapp, com um ponto de extremidade RPC da versão local do HardHat da cadeia. Isso permite então 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 snark, e envia isso para os contratos reais do Railgun na cadeia real. Embora esta descrição seja ligeiramente simplista, transmite a ideia geral. O que isso faz é permitir que você basicamente interaja com praticamente qualquer dapp (com alguns casos especiais 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 qualquer diferença do uso de uma carteira normal.

Conclusão

Existem algumas propostas interessantes para consagrar endereços furtivos no protocolo Ethereum. Por exemplo, Inco Usa 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 por meio de criptografia totalmente homomórfica. Inco depende de pré-compilações que atualmente só existem em sua própria rede, mas pode algum dia chegar ao Ethereum.

Existe também outra proposta chamada EIP-7503: Zero-Knowledge Wormholesque se baseia num design chamado “prova-de-queima”, embora isso pareça não estar a ganhar muita tração, provavelmente porque requer uma atualização do EVM, sem a qual só pode realmente ser implementado ao nível do token, utilizando um design erc-20 que suporta especificamente o eip-7503 (ou se um L2 decidir adicionar suporte aos seus opcodes EVM).

Aztecaé talvez a tecnologia de privacidade mais sofisticada disponível, mas requer que os usuários transfiram fundos para a Aztec para usá-la, o que pode ou não ser uma experiência do usuário 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 oferece privacidade por padrão.

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

Suporte de Carteira

Embora estejamos vendo uma adoção crescente de protocolos de endereço oculto, o que é promissor, ainda existem vários desafios. O desafio mais importante é que eles não são totalmente suportados em carteiras Ethereum mainstream (ainda não, de qualquer forma). As carteiras mainstream provavelmente têm várias escolhas a fazer se quiserem oferecer suporte para endereços ocultos. Algumas dessas escolhas incluem:

• Eles fornecerão suporte opinativo para uma única implementação, ou eles construirão e manterão uma espécie de agregador abrangente em vários protocolos? O último é provavelmente muito caro em termos de desenvolvimento e manutenção.
• Haverá considerações regulatórias e eles precisarão adotar uma posição sobre a extensão e o mecanismo de desanonimização seletiva (ou seja, como o Labyrinth's)?
• Os endereços ocultos exigem um componente on-chain vis-a-vis o contrato de registro (exceto Fluidkey), o que significa que cada rede EVM tem que ser suportada explicitamente 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 Explorer" não funcionará para um meta-endereço furtivo, onde a carteira mostra o saldo agregado. Este problema também pode existir para transferências. Os vários casos especiais, como este, precisarão ser considerados.
• Dependendo da implementação subjacente, um usuário só poderá usar o endereço furtivo efetivamente com um conjunto específico de dapps, nomeadamente aqueles que são suportados pelo protocolo subjacente. Isso será possível com arquiteturas modulares de endereços furtivos. No entanto, nem todas as dapps serão suportadas, e isto terá de ser comunicado de alguma forma ao usuário. É um pouco mais fácil com o eip-5506, mas ainda tem suas complicações e casos extremos, e isso pode muitas vezes vazar para a UX da carteira.

Também há espaço para melhorias na prevenção de uma má higiene de privacidade do usuário, ver este artigo: “Análise de Anonimato do Esquema de Endereço Furtivo Umbra na Ethereum” de como os autores desanonimizaram com sucesso 48,5% das transações furtivas na mainnet Ethereum. As heurísticas que usaram para fazer isto não tiveram nada a ver com os protocolos, e mais com a higiene de privacidade, por exemplo, um utilizador envia fundos para um endereço furtivo que controla e depois envia esses fundos de volta para o endereço de onde os enviou originalmente, pensando erroneamente que a rastreabilidade está quebrada. No geral, os autores identificaram 6 heurísticas diferentes que podem ser usadas para desanonimizar transações de endereços furtivos, principalmente baseadas em não seguir as melhores práticas. No entanto, estes são problemas críticos de UX que precisam de ser abordados.

Em geral, estou bastante otimista em relação aos endereços furtivos e à privacidade no Ethereum em geral. Acredito que fizemos progressos impressionantes e descobrimos alguns desafios que são facilmente solucionáveis. Tenho confiança de que as carteiras populares encontrarão uma maneira de oferecer suporte aos endereços furtivos, permitindo que os usuários os utilizem com o mínimo de atrito e reflexão, oferecendo o nível normal de privacidade que os usuários esperam e merecem.

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

Aviso legal:

1. Este artigo foi reproduzido a partir de [Médium]. Todos os direitos autorais pertencem ao autor original [Simon Brown]. Se houver objeções a esta reimpressão, por favor contate o Gate Learnequipa e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. A equipe de aprendizado da gate faz traduções do artigo para outros idiomas. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.