Há muito tempo que nos interessamos pelo tema do anonimato em criptomoedas e procuramos acompanhar o desenvolvimento de tecnologias nesta área. Em nossos artigos já discutimos detalhadamente os princípios de operação em Monero, e também realizou tecnologias existentes neste domínio. No entanto, todas as criptomoedas anônimas hoje são construídas 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 implementar o anonimato e a confidencialidade (por exemplo, ou ) tentaram replicar o modelo UTXO em contratos inteligentes.
Em fevereiro de 2019, um grupo de pesquisadores da Universidade de Stanford e da Visa Research liberado "Zether: Rumo à privacidade no mundo dos contratos inteligentes." Os autores foram os primeiros a propor uma abordagem para garantir o anonimato em blockchains baseados em contas e apresentaram duas versões de um contrato inteligente: para transações confidenciais (ocultando saldos e valores de transferência) e anônimas (ocultando o destinatário e o remetente). Achamos a tecnologia proposta interessante e gostaríamos de compartilhar seu design, bem como falar sobre por que o problema do anonimato em blockchains baseados em contas é considerado muito difícil e se os autores conseguiram resolvê-lo totalmente.
Sobre a estrutura desses modelos de dados
No modelo UTXO, uma transação consiste em “entradas” e “saídas”. Um análogo direto das “saídas” são as notas na sua carteira: cada “saída” tem algum valor. Quando você paga alguém (forma uma transação), você gasta uma ou mais “saídas”, caso em que elas se tornam “entradas” da transação, e o blockchain as marca como gastas. Nesse caso, o destinatário do seu pagamento (ou você mesmo, se precisar de troco) recebe as “saídas” recém-geradas. Isso pode ser representado esquematicamente assim:
Os blockchains baseados em contas são estruturados de forma semelhante à sua conta bancária. Eles tratam apenas do valor da sua conta e do valor da transferência. Ao transferir algum valor da sua conta, você não queima nenhuma “saída”, a rede não precisa lembrar quais moedas foram gastas e quais não foram. No caso mais simples, a verificação da transação se resume a verificar a assinatura do remetente e o valor em seu saldo:
Análise de tecnologia
A seguir, falaremos sobre como Zether oculta o valor da transação, o destinatário e o remetente. Ao descrevermos os princípios de seu funcionamento, notaremos as diferenças nas versões confidencial e anônima. Como é muito mais fácil garantir a confidencialidade em blockchains baseados em contas, algumas das restrições impostas pelo anonimato não serão relevantes para a versão confidencial da tecnologia.
Ocultando saldos e valores de transferência
Um esquema de criptografia é usado para criptografar saldos e transferir valores em Zether . Funciona da seguinte maneira. Quando Alice quer mandar Bob b moedas por endereço (sua chave pública) Y, ela escolhe um número aleatório r e criptografa o valor:
onde C - valor criptografado, D - valor auxiliar necessário para decifrar esse valor, G - um ponto fixo na curva elíptica, quando multiplicado pela chave secreta obtém-se a chave pública.
Quando Bob recebe esses valores, ele simplesmente os adiciona ao seu saldo criptografado da mesma maneira, e é por isso que esse esquema é conveniente.
Da mesma forma, Alice subtrai os mesmos valores de seu saldo, apenas como Y usa sua chave pública.
Ocultando o destinatário e o remetente
O embaralhamento de “saídas” no UTXO remonta aos primórdios das criptomoedas e ajuda a ocultar o remetente. Para isso, o próprio remetente, ao fazer uma transferência, coleta “saídas” aleatórias no blockchain e as mistura com as suas. Em seguida, ele assina as “saídas” com uma assinatura em anel – um mecanismo criptográfico que lhe permite convencer o verificador de que as moedas do remetente estão presentes entre as “saídas” envolvidas. As próprias moedas mistas, é claro, não são gastas.
No entanto, não poderemos gerar saídas falsas para ocultar o destinatário. Portanto, no UTXO, cada “saída” possui seu endereço único e está criptograficamente vinculada 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.
No modelo baseado em contas, 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 estar misturados com outras contas no blockchain. Neste caso, 0 moedas criptografadas são debitadas das contas mistas (ou 0 são adicionadas se o destinatário for misto), sem realmente alterar seu saldo real.
Como tanto o remetente quanto o destinatário sempre possuem um endereço permanente, torna-se necessário utilizar os mesmos grupos para mistura na transferência para os mesmos endereços. É mais fácil ver isso com um exemplo.
Digamos que Alice decida fazer uma contribuição para a instituição de caridade de Bob, mas prefere que a transferência permaneça anônima para um observador externo. Depois, para se disfarçar no campo do remetente, ela também insere as contas de Adam e Adele. E para ocultar Bob, adicione as contas de Ben e Bill no campo do destinatário. Fazendo a próxima contribuição, Alice decidiu escrever Alex e Amanda ao lado dela, e Bruce e Benjen ao lado de Bob. Neste caso, ao analisar a blockchain, nestas duas transações existe apenas um par de participantes que se cruza - Alice e Bob, o que desanonimiza estas transações.
Corridas de transação
Como já mencionamos, para ocultar o seu saldo em sistemas baseados em contas, o usuário criptografa o seu saldo e o valor da transferência. Ao mesmo tempo, ele deve provar que o saldo da sua conta permanece não negativo. O problema é que ao criar uma transação, o usuário constrói uma comprovação do status de sua conta corrente. O que acontece se Bob enviar uma transação para Alice e ela for aceita antes daquela enviada por Alice? Então a transação de Alice será considerada inválida, pois o comprovante de saldo foi construído antes da transação de Bob ser aceita.
A primeira decisão que surge em tal situação é congelar a conta até que a transação seja realizada. Mas esta abordagem não é adequada, porque além da complexidade de resolver tal problema em um sistema distribuído, em um esquema anônimo não ficará claro qual conta bloquear.
Para resolver esse problema, a tecnologia separa as transações de entrada e de saída: os gastos têm efeito imediato no balanço, enquanto os recebimentos têm efeito retardado. Para isso, é introduzido o conceito de “época” - um grupo de blocos de tamanho fixo. A "época" atual é determinada dividindo a altura do bloco pelo tamanho do grupo. Ao processar uma transação, a rede atualiza imediatamente o saldo do remetente e armazena os fundos do destinatário em um tanque de armazenamento. Os fundos acumulados são disponibilizados ao beneficiário apenas quando uma nova “era” começa.
Como resultado, o usuário pode enviar transações independentemente da frequência de recebimento dos fundos (até onde seu saldo permitir, é claro). O tamanho da época é determinado com base na rapidez com que os blocos se propagam pela rede e na rapidez com que uma transação entra em um bloco.
Esta solução funciona bem para transferências confidenciais, mas com transações anônimas, como veremos mais adiante, cria sérios problemas.
Proteção contra ataques de repetição
Em blockchains baseados em contas, cada transação é assinada pela chave privada do remetente, o que convence o verificador de que a transação não foi modificada e foi criada pelo proprietário desta chave. Mas e se um invasor que estava ouvindo o canal de transmissão interceptar essa mensagem e enviar exatamente a mesma segunda? O verificador verificará a assinatura da transação e ficará convencido de sua autoria, e a rede debitará novamente o mesmo valor do saldo do remetente.
Este ataque é chamado de ataque de repetição. No modelo UTXO, tais ataques não são relevantes, pois o invasor tentará utilizar saídas gastas, o que por si só não é válido e é rejeitado pela rede.
Para evitar que isso aconteça, um campo com dados aleatórios é embutido na transação, que é chamado de nonce ou simplesmente “salt”. Ao reenviar uma transação com salt, o verificador verifica se o nonce já foi usado antes e, caso não, considera a transação válida. Para não armazenar todo o histórico de nonces do usuário no blockchain, geralmente na primeira transação ele é igual a zero e depois aumentado em um. A rede só pode verificar se o nonce da nova transação difere em um do anterior.
No esquema de transferência anônima, surge o problema de validação de nonces de transação. Não podemos vincular explicitamente o nonce ao endereço do remetente, pois, obviamente, isso desanonimiza a transferência. Também não podemos adicionar um valor aos nonces de todas as contas participantes, pois isso pode entrar em conflito com outras transferências que estão sendo processadas.
Os autores do Zether propõem gerar o nonce criptograficamente, dependendo da “época”. Por exemplo:
é x é a chave secreta do remetente e Gepoch — um gerador adicional para a época, obtido através do hash de uma string no formato ‘Zether +’. Agora o problema parece estar resolvido – não revelamos o nonce do remetente e não interferimos nos nonces de participantes não envolvidos. Mas esta abordagem impõe uma limitação séria: uma conta não pode enviar mais do que uma transação por “época”. Este problema, infelizmente, permanece sem solução e atualmente torna a versão anônima do Zether, em nossa opinião, dificilmente adequada para uso.
A complexidade das provas de conhecimento zero
No UTXO, o remetente deve provar à rede que não está gastando um valor negativo, caso contrário será possível gerar novas moedas do nada (por que isso é possível, escrevemos em um dos anteriores ). E também assinar as “entradas” com uma assinatura para comprovar que entre as moedas que estão sendo misturadas há fundos que pertencem a ele.
Na versão anônima do blockchain baseado em contas, as expressões para prova são muito mais complexas. O remetente prova que:
- O valor enviado é positivo;
- O saldo permanece não negativo;
- O remetente criptografou corretamente os valores da transferência (incluindo zero);
- O saldo do saldo muda apenas para o remetente e o destinatário;
- O remetente possui a chave privada de sua conta e está na lista de remetentes (entre os envolvidos);
- O Nonce utilizado na transação está composto corretamente.
Para uma prova tão complexa, os autores usam uma mistura (um dos autores, aliás, participou de sua criação) e , que são chamados de marcadores Sigma. A prova formal de tal afirmação é uma tarefa bastante difícil e limita enormemente o número de pessoas dispostas a implementar a tecnologia.
O resultado?
Em nossa opinião, a parte do Zether que traz privacidade aos blockchains baseados em contas pode ser usada agora. Mas, no momento, a versão anônima da tecnologia impõe sérias restrições ao seu uso e complexidade à sua implementação. No entanto, não se deve desconsiderar que os autores o lançaram há apenas alguns meses, e talvez outra pessoa encontre uma solução para os problemas que existem hoje. Afinal, é assim que se faz ciência.
Fonte: habr.com