Sobre o anonimato em blockchains com base em contas

Há muito tempo nos interessamos no anonimato das criptomoedas e tentamos acompanhar o desenvolvimento de tecnologias nessa área. Em nossos artigos, já examinamos em detalhes os princípios de operação de transações confidenciais em Monero e também realizamos uma análise comparativa das tecnologias existentes neste campo. No entanto, todas as criptomoedas anônimas hoje são construídas com base no modelo de dados proposto pelo Bitcoin - Unspent Transaction Output (doravante UTXO). Para blockchains baseados em contas como o Ethereum, as soluções existentes para a implementação do anonimato e da privacidade (por exemplo, Mobius ou Aztec ) tentaram repetir o modelo UTXO em contratos inteligentes.

Em fevereiro de 2019, um grupo de pesquisadores da Universidade de Stanford e da Visa Research divulgou a pré - impressão "Zether: Rumo à privacidade no mundo dos contratos inteligentes". Os autores propuseram uma abordagem para garantir o anonimato em blockchains com base em contas e apresentaram duas opções para um contrato inteligente: para transações confidenciais (ocultação de saldos e valores de transferência) e transações anônimas (ocultando destinatário e remetente). Achamos a tecnologia proposta interessante e gostaríamos de compartilhar seu dispositivo, além de discutir por que o problema do anonimato nas cadeias de blocos baseadas em contas é considerado muito complexo e se os autores conseguiram resolvê-lo por completo.

Sobre o dispositivo desses modelos de dados

No modelo UTXO, uma transação consiste em "entradas" e "saídas". Um análogo direto das “saídas” é a nota na sua carteira: cada “saída” tem uma determinada denominação. Quando você paga com alguém (forma uma transação), gasta uma ou mais "saídas", enquanto elas se tornam as "entradas" da transação, e o blockchain as marca como gastas. Ao mesmo tempo, o destinatário do seu pagamento (ou você mesmo, se precisar de uma alteração) recebe as "saídas" recém-geradas. Esquematicamente, isso pode ser representado da seguinte maneira:



As blockchains baseadas em contas são estruturadas como sua conta bancária. Eles operam apenas no valor da sua conta e no valor da transferência. Quando você transfere uma certa quantia da sua conta, não queima nenhuma "saída", a rede não precisa se lembrar de quais moedas são gastas e quais não são. No caso mais simples, a verificação de uma transação é reduzida à verificação da assinatura do remetente e do valor em seu saldo:

Análise de tecnologia

A seguir, falaremos sobre como o Zether oculta a quantidade de transações, o destinatário e o remetente. No decorrer da descrição dos princípios de seu trabalho, observaremos as diferenças nas versões confidencial e anônima. Como é muito mais fácil garantir a confidencialidade em blockchains com base em contas, algumas das restrições impostas pelo anonimato não serão relevantes para uma versão confidencial da tecnologia.

Ocultação de saldos e valores de transferência

O Zether usa o esquema de criptografia El Gamal para criptografar saldos e transferir valores. Funciona da seguinte maneira. Quando Alice deseja enviar as moedas de Bob b para o endereço (sua chave pública) Y , ela escolhe um número aleatório r e criptografa o valor:


onde C é a soma criptografada, D é o valor auxiliar necessário para descriptografar essa soma, G é o ponto fixo na curva elíptica, quando a chave secreta é multiplicada pela qual a chave pública é obtida.

Quando Bob recebe esses valores, ele simplesmente os adiciona ao seu saldo, criptografado da mesma maneira, o que é conveniente para esse esquema.

Da mesma forma, Alice subtrai os mesmos valores de seu balanço, usa apenas Y como sua chave pública.

Ocultação do destinatário e do remetente

A mistura de "saídas" no UTXO apareceu no início das criptomoedas e ajuda a esconder o remetente. Para fazer isso, o remetente, ao fazer uma transferência, coleta “saídas” aleatórias na blockchain e amassa-as com as suas. Em seguida, ele assina as “saídas” com uma assinatura de anel - um mecanismo criptográfico que permite convencer o verificador de que entre as “saídas” envolvidas existem moedas emissoras. As próprias moedas implicadas, é claro, não são desperdiçadas.

No entanto, para ocultar o destinatário, não seremos capazes de gerar "resultados" falsos. Portanto, no UTXO, cada “saída” possui seu próprio endereço exclusivo e é criptograficamente associada ao endereço do destinatário dessas moedas. No momento, não há como identificar a relação entre o endereço de “saída” exclusivo e o endereço do destinatário sem conhecer suas chaves secretas.

Em um modelo baseado em conta, não podemos usar endereços únicos (caso contrário, já será um modelo de "saídas"). Portanto, o destinatário e o remetente devem ser amassados ​​entre outras contas na blockchain. Ao mesmo tempo, 0 moedas criptografadas são debitadas das contas amassadas (ou 0 é adicionado - no caso de um destinatário amassar), sem alterar seu saldo real.

Como o remetente e o destinatário sempre têm um endereço permanente, aqui é necessário usar os mesmos grupos para misturar nos mesmos endereços. É mais fácil considerar isso com um exemplo.

Suponha que Alice decidiu contribuir para a caridade de Bob, mas prefere que a transferência permaneça anônima para um observador externo. Em seguida, para se disfarçar no campo do remetente, ela também entra nas contas de Adam e Adele. E para esconder Bob - no campo do destinatário, além das contas de Ben e Bill. No próximo capítulo, Alice decidiu entrar com Alex e Amanda ao lado dela, e Bruce e Bengen ao lado de Bob. Nesse caso, ao analisar o blockchain nessas duas transações, há apenas um par de participantes que se interceptam - Alice e Bob, que desinteronizam essas transações.

Transaction Racing

Como já mencionamos, para ocultar seu saldo em sistemas baseados em contas, o usuário criptografa seu saldo e o valor da transferência. Além disso, ele deve provar que o saldo em sua conta permanece não negativo. O problema é que, ao formar uma transação, o usuário cria evidências sobre seu estado atual da conta. E o que acontece se Bob enviar uma transação para Alice, e ela será aceita antes do envio por Alice? A transação de Alice será considerada inválida porque a prova de saldo foi criada antes da adoção da transação Bob.



A primeira solução que vem em tal situação é congelar sua conta antes da transação. Mas essa abordagem não é adequada, pois, além da complexidade de resolver esse problema em um sistema distribuído, em um esquema anônimo, não ficará claro quem deve bloquear a conta.

Para resolver esse problema, a tecnologia separa as transações de entrada e saída: gastar dinheiro tem um efeito imediato no balanço patrimonial e a receita é diferida. Para isso, é introduzido o conceito de “era” - um grupo de blocos de tamanho fixo. A "era" atual é determinada dividindo a altura do bloco pelo tamanho do grupo. Ao processar a transação, a rede atualiza o saldo do remetente imediatamente e adiciona os fundos do destinatário à unidade. Os fundos acumulados estão disponíveis para o beneficiário somente quando uma nova "era" se instala.

Como resultado, o usuário pode enviar transações, independentemente da frequência com que recebe fundos (na medida em que o saldo permitir, é claro). O tamanho de uma época é determinado com base na rapidez com que os blocos se espalham pela rede e na rapidez com que a transação cai no bloco.

Essa solução funciona bem no caso de transferências confidenciais, mas com transações anônimas, como veremos mais adiante, cria sérios problemas.

Reproduzir proteção contra ataques

Nas blockchains baseadas em contas, cada transação é assinada pela chave privada do remetente, o que convence o verificador de que a transação não foi alterada e foi criada pelo proprietário dessa chave. Mas e se o atacante que estava ouvindo o canal de transmissão interceptar essa mensagem e enviar exatamente o mesmo segundo? O verificador verificará a assinatura da transação e ficará convencido de sua autoria, e a rede debitará o mesmo valor do saldo do remetente novamente.

Esse ataque é chamado de ataque de repetição. No modelo UTXO, esses ataques não são relevantes, porque o invasor tentará usar as saídas gastas, que por si só não são válidas e são rejeitadas pela rede.

Para impedir que isso aconteça, um campo de dados aleatório é inserido na transação, chamado de nonce ou simplesmente "salt". Ao reenviar uma transação com um salt, o revisor verifica se esse nonce foi usado antes e, se não, considera essa transação válida. Para não armazenar todo o histórico de usuários nonce no blockchain, geralmente é considerado zero na primeira transação e depois aumentado em um. A rede só pode verificar se a diferença da nova transação difere do passado em uma.

Em um esquema de tradução anônima, surge o problema de validar transações nonce. Não podemos vincular nonce explicitamente ao endereço do remetente, porque, obviamente, isso desaroniza a tradução. Também não podemos adicionar um ao nonce de todas as contas participantes, pois isso pode entrar em conflito com outras traduções que estão sendo processadas.

Os autores de Zether propõem gerar nonce criptograficamente - dependendo da "era". Por exemplo:


Aqui x é a chave secreta do remetente e a _época G é um gerador adicional para a época, obtido por hash de uma string da forma 'Zether +'. Agora, o problema, ao que parece, está sendo resolvido - não divulgamos o não envio do remetente e não interferimos com o não envio dos participantes não envolvidos. Mas essa abordagem impõe uma limitação séria: uma conta não pode enviar mais de uma transação na "era". Infelizmente, esse problema permanece sem solução e atualmente torna uma versão anônima do Zether, em nossa opinião, pouco adequada para uso.

Evidência de Confiança Zero

No UTXO, o remetente deve provar à rede que ele não está gastando uma quantia negativa; caso contrário, torna-se possível gerar novas moedas a partir do ar (por que isso foi possível, escrevemos em um dos artigos anteriores). E também assine as “entradas” com uma assinatura de anel para provar que entre as moedas amassadas existem fundos pertencentes a ele.

Na versão anônima do blockchain baseado em conta, as expressões para prova são muito mais complicadas. O remetente prova que:

1. O valor enviado é positivo;
2. O saldo permanece não negativo;
3. O remetente criptografou corretamente a quantidade de transferências (incluindo zero);
4. O saldo da balança é alterado apenas pelo remetente e pelo destinatário;
5. O remetente possui a chave secreta de sua conta e ele realmente está na lista de remetentes (entre os envolvidos);
6. O nonce usado na transação é composto corretamente.

Para uma prova tão complexa, os autores usam uma mistura de Bulletproof (a propósito, um dos autores participou de sua criação) e o protocolo Sigma , chamado Sigma-bullets. A prova formal de tal afirmação é uma tarefa bastante difícil e limita severamente o número de pessoas que desejam adotar a implementação da tecnologia.

Qual é o resultado?

Em nossa opinião, a parte do Zether, que adiciona privacidade às blockchains baseadas em contas, pode muito bem ser usada agora. No momento, porém, uma versão anônima da tecnologia impõe sérias restrições ao seu uso e sua complexidade na implementação. No entanto, não esqueça que os autores o lançaram apenas alguns meses atrás e talvez alguém encontre uma solução para os problemas hoje. De fato, é assim que a ciência é feita.