For Developers #5

Olá, desenvolvedor! Seja bem-vindo à sua fonte de insights e ensinamentos técnicos sobre blockchain. Hoje vamos aprender sobre o conceito de stealth address e como implementá-lo.

ago 30, 2024

Nesta edição, nosso DevRel e PM de Inovações, Afonso Dalvi, mergulha no conceito técnico e teórico dos stealth addresses, uma abordagem que visa aprimorar a privacidade das informações dos destinatários de tokens.

Tempo de leitura: 6 minutos.

Stealth Address: um tutorial completo

Atualmente, a privacidade on-chain é um tema de grande relevância. Em blockchains públicas, todas as transações são transparentes e rastreáveis, o que levanta preocupações sobre a privacidade dos usuários.

Para enfrentar esses desafios, surgiram várias soluções, como as provas de conhecimento zero (ZKPs - Zero Knowledge Proofs), sobre as quais discutimos em detalhes em um dos nossos artigos anteriores. Outra solução bem conhecida é o Tornado Cash, um mixer que ganhou notoriedade por oferecer privacidade em transferências de tokens ERC20 e moedas nativas da blockchain. No entanto, ele não é eficaz para transferências de tokens ERC721.

Hoje, quero focar em uma abordagem inovadora discutida por Vitalik Buterin, o criador do Ethereum, em um de seus recentes posts de blog. Ele apresenta um guia sobre stealth addresses (endereços furtivos), que são uma solução para aprimorar a privacidade on-chain. Você pode conferir o post completo clicando aqui.

Os stealth addresses criam um novo endereço único para cada transação, garantindo a privacidade do destinatário. Essa técnica utiliza criptografia de curva elíptica e métodos de compartilhamento de segredos, permitindo o envio seguro e privado de valores.

Vamos explorar mais sobre essa dinâmica com um trecho do artigo de Vitalik:

“Suponha que Alice queira enviar um ativo para Bob. Pode ser alguma quantidade de criptomoeda (por exemplo, 1 ETH, 500 RAI) ou pode ser um NFT. Quando Bob recebe o ativo, ele não quer que o mundo inteiro saiba que foi ele quem o recebeu. Esconder o fato de que uma transferência aconteceu é impossível, especialmente se for um NFT do qual há apenas uma cópia na cadeia, mas esconder quem é o destinatário pode ser muito mais viável. Alice e Bob também são preguiçosos: eles querem um sistema em que o fluxo de trabalho de pagamento seja exatamente o mesmo de hoje. Bob envia a Alice (ou registra no ENS) algum tipo de 'endereço' codificando como alguém pode pagar a ele, e essa informação por si só é suficiente para Alice (ou qualquer outra pessoa) enviar o ativo a ele.”

No exemplo fornecido, são mencionados NFTs, destacando uma vantagem significativa dos stealth addresses em comparação com o Tornado Cash, que não oferece privacidade para esse tipo de transação. Vamos explorar como esse processo funciona em mais detalhes:

A primeira etapa envolve a geração de chaves essenciais para criar as chaves de "scan" (visualização) e "spend" (gasto). Essas chaves são derivadas da assinatura do destinatário, garantindo que somente ele possa acessar e utilizar os fundos.

Abaixo, temos capturas de tela de uma solução beta rodando localmente, mostrando o processo de geração dessas chaves:

Chaves geradas:

O conjunto de chaves é registrado no contrato ERC6538Registry, que é derivado do padrão ERC-6538. Abaixo, apresentamos dois exemplos de contratos implementados:

ERC6538Registry da documentação do stealthaddress.dev.
Stealth Key Registry do protocolo Umba Cash.

Basicamente, esses contratos exigem dois dados como argumentos: o schemeId e o stealthMetaAddress (meta-endereço stealth, que é o conjunto de chaves públicas mencionado anteriormente). Além disso, o endereço do registrante/destinatário é armazenado durante a interação com o contrato. Vamos analisar um exemplo:

Registrante/Destinatário (address - msg.sender): A conta à qual o meta-endereço furtivo registrado pertence.
schemeId (uint256): Identificador que corresponde ao esquema de endereço furtivo aplicado (por exemplo, 1 conforme especificado no secp256k1 do ERC-5564).
stealthMetaAddress (bytes): O meta-endereço stealth.

Com o meta-endereço stealth sendo totalmente público e compartilhável, ele pode ser utilizado para gerar o stealth address, permitindo o envio de valores que poderão ser retirados pelo registrante/destinatário. Esse processo envolve o uso de uma chave pública efêmera (uma chave temporária gerada pelo usuário que enviará o valor) e das chaves públicas do destinatário, geradas anteriormente de sua assinatura, tudo dentro da formatação correta do stealth meta-address, utilizando o prefixo st:eth, conforme o padrão definido no EIP-3770.

Essas são as chaves privadas e públicas de gasto e visualização, que correspondem às chaves públicas codificadas no meta-endereço furtivo:

No exemplo acima, utilizamos o formato st:eth:0x<Publickey1><Publickey2>, além da chave efêmera (Ephemeral Key), retornando os endereços públicos e privados de gasto e visualização, juntamente com o stealthAddress, a ephemeralPublicKey, e a viewTag. Se você quiser testar como gerar suas próprias chaves de gasto e entender na prática como isso funciona, clique aqui.

Agora que temos os elementos essenciais, podemos prosseguir para o próximo passo: a interação com o contrato Announcer, responsável por enviar os valores e anunciar a transação na blockchain. Abaixo, apresento três exemplos de contratos implementados para estudo:

Na função "announce", passamos os principais argumentos: schemeId, stealthAddress, ephemeralPubKey, e o metadata.

Observe que, ao chamar essa função, um evento é emitido pelo contrato contendo todos os argumentos fornecidos. Isso é crucial para que o endereço registrador do seu meta-endereço possa localizar a transação relacionada ao seu stealth address.

O registrador/destinatário usa sua chave de varredura privada para detectar transações endereçadas aos seus stealth addresses. Uma vez detectada, ele pode usar sua chave de gasto privada para reivindicar os fundos enviados ao endereço furtivo. Um detalhe importante é que, se o registrador/destinatário reivindicar os fundos para o mesmo endereço, a privacidade pode ser comprometida, pois o endereço original que derivou o stealth address poderá ser identificado.

Vamos a mais um trecho do artigo de Vitalik para esclarecer:

“Endereços furtivos fornecem tal esquema. Um endereço furtivo é um endereço que pode ser gerado por Alice ou Bob, mas que só pode ser controlado por Bob. Bob gera e mantém em segredo uma chave de gastos e usa essa chave para gerar um meta-endereço furtivo . Ele passa esse meta-endereço para Alice (ou o registra no ENS). Alice pode executar uma computação nesse meta-endereço para gerar um endereço furtivo pertencente a Bob. Ela pode então enviar quaisquer ativos que queira enviar para esse endereço, e Bob terá controle total sobre eles. Junto com a transferência, ela publica alguns dados criptográficos extras (uma pubkey efêmera ) na cadeia que ajuda Bob a descobrir que esse endereço pertence a ele.

Outra maneira de ver isso é: endereços furtivos fornecem as mesmas propriedades de privacidade que Bob, gerando um novo endereço para cada transação, mas sem exigir nenhuma interação de Bob.”

Agora, um exemplo simplificado da stealthaddress.dev:

Considere o caso de Alice enviando fundos para Bob usando um mecanismo de endereço furtivo:

Bob registra um meta-endereço stealth no contrato de registro canônico ERC6538Registry.
Alice cria um stealth address exclusivo para Bob usando o meta-endereço stealth de Bob e uma chave pública efêmera que ela gera.
Alice envia os fundos para o stealth address gerado.
Alice anuncia a transação no contrato do anunciador canônico ERC5564Announcer.
Bob monitora a blockchain em busca de transações que correspondam à sua chave de varredura. Ao detectar a transação de Alice, ele usa sua chave de gasto para reivindicar os fundos do stealth address.

Um fluxo animado sobre as etapas: