Há uma nova ferramenta de privacidade chegando à cidade: moedaswaps em cadeias de estado. O projeto da cadeia de estado original foi proposto por Ruben Somsen no Scaling Bitcoin 2018 em Tóquio. Vou resumir rapidamente, mas Aaron van Wirdum tem um explicador muito completo do conceito original aqui. A ideia geral é ter uma entidade facilitadora (o operador de cadeia de estados) para criar um endereço multisig 2 de 2 com um usuário para facilitar a transferência fora da cadeia de um UTXO. O usuário então transfere sua chave privada do 2 de 2 para um novo usuário. A entidade statechain seria informada de quando isso acontecesse e, nesse ponto, só permitirá que o novo proprietário transfira os fundos para fora. Portanto, a ideia toda é fazer uma transação literalmente transferindo a própria chave privada e fazer com que o operador da rede estadual imponha a propriedade atual.
E, assim como os canais da Lightning Network, cada usuário tem uma transação pré-assinada, permitindo que eles assumam o controle unilateral do UTXO após a expiração de um bloqueio de tempo. Dessa forma, se o operador de cadeia de estado desaparecesse, os fundos não ficariam presos naquele 2 de 2 para sempre. Mas essa opção de backup deve ser balanceada contra o risco de uma das partes tentar usar indevidamente sua transação pré-assinada para roubar os fundos. A proposta de Somsen depende da eltoo para facilitar ao novo proprietário a substituição da transação de fechamento pré-assinada do proprietário anterior, no caso de o proprietário anterior tentar roubar de volta os fundos. A última parte importante do projeto da cadeia de estados é uma cadeia de assinaturas de um proprietário para outro, que começa com o proprietário original e vai até o atual. Este é passado de um proprietário para outro e anexado em paralelo com cada transação para que todos possam manter uma cópia local comprovando a transferência legítima e, no caso do atual proprietário, que eles são de fato o proprietário legítimo.
Por causa da dependência do eltoo e do fato de que os soft forks tendem a não acontecer durante a noite, CommerceBlock começou a trabalhar na implementação de uma variante de statechains em 2020 que não depende do eltoo. No lugar de eltoo, permitindo que a transação mais recente substitua as anteriores, eles têm implementado um esquema nLocktime decrescente chamado Mercury. A ideia é que a transação de fechamento do proprietário original seja bloqueada em um período de x blocos no futuro; eles não podem executar sua transação para retomar os fundos até que o blockchain tenha atingido esse limite. E então, na próxima transferência de propriedade, a transação do novo proprietário é bloqueada em x-1. Isso permite que o proprietário atual envie sua transação de fechamento para a rede antes que a do proprietário original se torne válida para enviar. À medida que outras transferências de propriedade acontecem, os bloqueios de tempo continuam diminuindo (x-2, x-3, etc), garantindo que o proprietário atual sempre pode agir antes que qualquer uma das transações dos proprietários anteriores seja desbloqueada. Isso remove a necessidade de eltoo, mas introduz uma limitação na transferência de cadeias de estados entre proprietários: você só pode diminuir os bloqueios de tempo tantas vezes antes que não possa mais ser diminuído; em algum ponto, o futuro, menos alguma quantidade de tempo (blocos), torna-se igual ao presente (o nLocktime é a altura do bloco atual). Nesse ponto, os usuários devem fechar a cadeia de estado ou os proprietários mais antigos poderão roubar as moedas à medida que as transações nLocktime anteriores atingirem o vencimento do tempo de bloqueio e se tornarem válidas.
Outra diferença fundamental entre o design original de Somsen e Mercury é como a geração de chave é tratada. Em vez de usar um script multisig óbvio de 2 de 2, a Mercury implementa ECDSA-MPC (algoritmo de assinatura digital de curva elíptica computação multipartidária). Você pode pensar nisso como funcionalmente semelhante a um endereço MuSig usando Schnorr, exceto no caso de Schnorr, os usuários simplesmente adicionam duas chaves públicas juntas para criar um endereço que ambos devem assinar. Com ECDSA-MPC, a geração de chaves é um processo mais interativo com várias etapas. No final, eles produzem funcionalmente o mesmo resultado: uma única chave pública que não é obviamente um multisig e onde ambas as partes envolvidas têm uma parte da chave privada correspondente necessária para assinar uma transação.
O processo de transferência utilizando ECDSA-MPC é um processo interativo onde, em vez de o proprietário original transferir explicitamente uma chave privada existente, conforme descrito na proposta de Somsen, o operador de cadeia de estado e o remetente colaboram através do ECDSA-MPC para gerar um chave privada por meio de keyshares. Crucialmente, há mais de um conjunto de compartilhamentos de chaves possíveis que podem gerar a mesma chave privada. Assim, o operador de cadeia de estado recria a chave privada com o destinatário, mas criando compartilhamentos de chaves diferentes. O operador de cadeia de estado então exclui o keyshare que eles possuíam que corresponde ao proprietário anterior. CommerceBlock reforça isso com um HSM (módulo de segurança de hardware), embora isso não remova toda a confiança. Desta forma, se o statechain estiver operando honestamente, ele é literalmente incapaz de assinar uma transação de fechamento com um proprietário anterior porque o keyshare que ele mantém atualmente não funciona com o keyshare do proprietário anterior para criar uma assinatura válida. Também no caso de tal conluio, a prova pública seria publicável mostrando que a entidade estatal agiu desonestamente. Este é um desincentivo à reputação de fazê-lo.
Como funciona a prova pública? CommerceBlock projetou anteriormente uma variação de Opentimestamps chamada Mainstay. Opentimestamps é apenas um protocolo para obter quaisquer dados arbitrários e incluí-los em uma árvore merkle muito grande com a raiz comprometida com uma transação Bitcoin. O problema com Opentimestamps é que a árvore está completamente desordenada; as coisas são adicionadas ao final da árvore à medida que chegam. Isso significa que não oferece garantias de que as informações conflitantes não sejam confirmadas pela mesma transação de ancoragem no blockchain. O que o Mainstay faz é efetivamente atribuir “slots” canônicos na árvore merkle para dados específicos, por exemplo, um oráculo atestando o resultado de um jogo esportivo. Todos podem saber qual “slot” verificar para aquele oráculo específico e podem então ignorar qualquer carimbo de data/hora conflitante que não esteja nesse slot. Isso permite que as pessoas atestem algo com um carimbo de data/hora sem deixar aberta a possibilidade de itens conflitantes de carimbo de data/hora para revelar seletivamente (se você pode escrever em qualquer lugar na árvore merkle, você pode ter o carimbo de data/hora real em um lugar enquanto aponta para um falso em outro lugar). Cada transferência de uma cadeia de estado Mercury é atestada em um slot de esteio específico, a fim de fornecer uma prova com carimbo de data/hora da propriedade atual que pode ser publicada se a entidade de cadeia de estado agir desonestamente.
Agora que os detalhes da implementação da cadeia de estados estão fora do caminho, vamos para a parte interessante: co-trocas. A distinção geral historicamente feita entre coinjoins e coinswaps é que um coinjoin é um uso explícito e publicamente visível de técnicas de aumento de privacidade ocorrendo em uma única transação, enquanto um coinjoins é geralmente considerado como secreto e, no caso cooperativo de sucesso, não um uso publicamente visível de uma técnica de privacidade ocorrendo em várias transações separadas. O mundo inteiro pode ver quando um UTXO entra em um coinjoin, mas se implementado como geralmente discutido anteriormente, ninguém, exceto os participantes saberia quando um UTXO está envolvido em um co-troca.
A implementação do coinswap construída sobre as cadeias de estados do Mercury quebra essa distinção clara entre coinjoins e coinswaps em termos dessa propriedade de privacidade aberta versus encoberta. As transferências de cadeias de estados são registradas nos compromissos da Mainstay, então adversamente você tem que assumir que é de conhecimento público cada vez que uma cadeia de estados muda de proprietário. Mas cada transferência também pode ser uma troca de moeda com qualquer outra cadeia de estados transferida no mesmo intervalo de bloco. Então, em termos de ferramentas de anonimato, isso se torna uma espécie de monstro de Frankenstein combinando as propriedades de anonimato de coinjoins enquanto usa o mecanismo de uma coinwap para conduzir a troca de UTXOs fora da cadeia. Ele usa um”co-troca”fora da cadeia no topo de uma cadeia de estado para emular propriedades de anonimato semelhantes de um coinjoin sem incorrer em uma taxa na cadeia para cada troca.
Coinswaps em statechains Mercury são essencialmente apenas transferências regulares de statechain com um pouco de magia criptográfica divertida para torná-los anônimos. Quando você registra um UTXO para um coinjoin típico (como Whirlpool ou Wasabi), você registra um UTXO como uma entrada e, em seguida, recebe uma credencial criptográfica cega que pode usar para criar uma saída no coinjoin para obter suas moedas de volta em uma nova conexão de rede para proteger sua privacidade contra o coordenador. Esta mesma coordenação é aproximada no esquema de Mercúrio ao registrar cadeias de estados, receber tokens cegos e, em seguida, consultar o coordenador para ser atribuído aleatoriamente a um novo endereço para o qual transferir sua cadeia de estados. Existe até uma chance de receber sua própria cadeia de estado de volta para você. É aleatório. Depois disso, são basicamente todos assinando suas transferências atomicamente.
No final, o que temos aqui é algo muito contra-intuitivo e em um ponto estranho no”espectro de confiança”das ferramentas Bitcoin que as pessoas provavelmente não estão acostumadas a considerar profundamente. A rigor, no plano técnico, o que está acontecendo é uma troca de moedas; as moedas estão sendo trocadas secretamente sem deixar uma impressão digital direta na cadeia de que uma troca de UTXOs está acontecendo. Mas, devido ao compromisso do Mainstay com todas as transferências e ao potencial de análise heurística da qual as cadeias de estados transferiram os proprietários em diferentes períodos de tempo, você pode inferir que a troca de moedas ocorreu, reduzindo assim os ganhos do conjunto de anonimato para serem equivalentes a uma co-junção padrão. Mas você não tem que pagar taxas de corrente para cada”coinjoin”.
Para realmente esclarecer o ponto do “ponto estranho”, sem dúvida com uma única entidade funcionando como o operador de cadeia de estado, você poderia ver isso como uma aproximação de um acordo de custódia. Mas por causa da exclusão de keyshare imposta por HSM, atestados de Mainstay e transações de fechamento pré-assinadas, os usuários sempre têm um caminho de saída unilateral do sistema, desde que o operador não colabore com um proprietário anterior da cadeia de estado para fraudar o proprietário legítimo.
A melhor maneira que posso pensar para descrever o modelo de confiança é parafrasear Tom Trevethan de CommerceBlock: “O objetivo é ocupar o meio-termo entre um misturador totalmente custodial e um coinjoin totalmente sem confiança em termos de ferramentas de privacidade.” Há inegavelmente algum grau de confiança no operador de cadeia de estado, neste caso CommerceBlock, para agir honestamente. Mas também existem mecanismos para alertar publicamente os usuários sobre comportamentos desonestos por parte deles e claros benefícios de privacidade a serem obtidos com uma possível economia de taxas em comparação com associações simples de moeda em rede.
Não é totalmente confiável, mas também não é totalmente baseado em confiança. É um novo ponto no espectro em termos de ferramentas de privacidade. Pessoalmente, dado o fato subestimado de quão amplamente usados os misturadores centralizados ainda são, estou interessado em ver onde isso se encaixa nesse ecossistema. Há um novo garoto na cidade.
Este é um post convidado de Shinobi. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC, Inc. ou da Bitcoin Magazine.
