Implementando a Privacidade

Escrito em 28.08.2019 por Jake Yocom-Piatt, Decred Project Lead

Os recursos e planos de privacidade do Decred estão prontos para serem revelados. O objetivo dos nossos recursos de privacidade é ser simples, adaptável e criativo.

Em vez de seguir as rotas estabelecidas por projetos focados em privacidade, por exemplo ring signatures, zk-SNARKs ou Mimblewimble, decidimos adotar uma abordagem de mixnet, onde integramos o mixnet com nosso sistema de governança Proof-of-Stake (“PoS”). Atualmente, pouco mais de 50% de todos os decred em circulação participam do PoS, o que exige um fluxo constante de compras de tickets. Esse fluxo de transação existente, exclusivo do Decred, funciona como a base natural de um mixnet. Pela abordagem com o sistema de governança do PoS do Decred, isso gera um cenário de “muitos pássaros, uma pedra”: as partes interessadas ganham anonimato e criam simultaneamente um volume de fundo substancial contra o qual eles e partes não-interessadas ​​podem mixar transações regulares. Aqui está um resumo de alto nível do mixnet do Decred:

• É baseado no protocolo CoinShuffle++ de “P2P Mixing e Unlinkable Bitcoin Transactions” de Ruffing, Moreno-Sanchez e Kate.
• O processo de mixagem é integrado ao processo de compra de tickets, para que as partes interessadas que executam carteiras de compra de tickets possam comprar tickets anonimamente.
• Além de ter uma denominação baseada no preço atual do ticket, denominações fixas menores são usadas para mixar troco e transações regulares.
• O troco do processo de mixagem requer tratamento especial para evitar a vinculação de saídas de transação não gastas (“UTXOs”).
• Há um aumento de aproximadamente 12x no armazenamento de transações on-chain ao usar a privacidade.
• A versão inicial é apenas interface de linha de comando (“CLI”) e suportará apenas carteiras de staking ou transações sem staking.

No restante deste artigo, abordarei a motivação por trás das decisões tomadas para chegar a esse sistema, como o sistema funciona com mais detalhes e quais são os próximos passos após esse lançamento inicial.

Motivação

O trabalho de privacidade vem sendo mantido em sigilo desde meados de 2017, e isso merece alguma explicação. Naquela época, eu observei que tanto o Monero quanto o Zcash, apesar de oferecerem privacidade substancial, tinham o que eu considerava um problema sério: eles não podem retirar transações históricas de seus nós completos, ou seja, pruning, porque não é possível saber se uma transação de saída (“TXO”) foi gasta ou não. Embora esteja claro que ambos os projetos consideraram que este não era um problema sério, pensei que esse seria um grande problema de sustentabilidade a longo prazo. Uma blockchain terá dificuldades em funcionar como uma reserva de valor a longo prazo se estiver muito cheia para ser baixada e facilmente replicada, reduzindo sua segurança. Parece que a maioria das outras pessoas no espaço de criptomoedas não compartilhava dessa opinião, então eu senti que era melhor guardar minhas críticas, em vez de torná-las públicas e dar a dica para outra pessoa implementar uma solução.

Além dessa preocupação de que impedir o pruning era uma péssima decisão de engenharia a longo prazo que poderia afetar negativamente a sustentabilidade, apesar de ser boa para a privacidade a curto prazo, eu estava preocupado com a complexidade de ambas as abordagens. As ring signatures têm uma complexidade moderada e os zk-SNARKs têm uma alta complexidade, de modo que me levou a encontrar uma abordagem mais simples que não impedisse o pruning. Inicialmente, planejei implementar o TumbleBit a partir do artigo “TumbleBit: um hub de pagamento anônimo não confiável e compatível com Bitcoin” de Heilman, AlShenibr, Baldimtsi, Scafuro e Goldberg. Entre o inverno de 2017 e a primavera de 2018, Mikhail Belopuhov, desenvolvedor com experiência considerável em projetos de engenharia criptográfica, implementou o TumbleBit em Go (golang). Quando sua implementação inicial foi concluída e chegou a hora de integrar o código, fiquei mais ciente das deficiências do TumbleBit, especificamente que o servidor de mixagem é vulnerável a ataques de negação de serviço (“DoS”) e que a contramedida contra isso (comprovantes de taxas anônimas) significava que mais código e mais complexidade tinha que ser adicionada. Apesar de não integrar o código do TumbleBit ao Decred, estamos liberando este código para benefício público.

Foi nesse ponto que achei melhor dar uma olhada de perto no protocolo CoinShuffle++ de “P2P Mixing e Unlinkable Bitcoin Transactions” de Ruffing, Moreno-Sanchez e Kate, que eu achei bem menos complexo que o TumbleBit. O CoinShuffle++ é baseado em primitivos criptográficos comuns, por exemplo trocas de chaves, chaves de sessão, funções de hash, assinaturas e aritmética de campos finitos. Depois de analisar de perto o CoinShuffle++, ficou claro que era mais simples e mais resistente a DoS do que o TumbleBit, por isso demos uma guinada e fomos atrás do CoinShuffle++. Código simples e primitivos simples significam menos coisas para quebrar ou dar errado. Devido a restrições nos recursos de engenharia, este trabalho não foi iniciado até dezembro de 2018 e agora está pronto para ser publicado após vários meses de trabalho.

O CoinShuffle++ trata apenas do componente de rastreabilidade da privacidade, sem abordar a questão das quantias das transações. Como o CoinShuffle++ não exigia mudanças de consenso, este trabalho pôde ser concluído em sigilo. O mesmo não pode ser dito para técnicas que ofusquem quantias da transação. Para ofuscar as quantias das transações, é necessário que ocorram alterações de consenso, parte de um processo público com o Decred, conforme a vontade das partes interessadas (stakeholders).

O Decred baseia-se nos princípios de segurança da blockchain, governança integrada e uma recompensa de autofinanciamento que o torna uma reserva de valor superior. Com essas fundações em vigor, queremos criar recursos de privacidade que melhorem a segurança de nossos usuários. Apesar de um processo público ser necessário para ofuscar as quantias das transações, eu sou da opinião de que a questão da rastreabilidade é muito mais importante quando se trata da segurança de nossas partes interessadas, que terão um ganho substancial de privacidade como resultado.

Como funciona

O Decred implementou uma variante do CoinShuffle++ em sua carteira. Embora seja possível executar esse processo de maneira totalmente peer-to-peer (“P2P”), ignorando as restrições que vêm do roteamento pela Internet pública, criamos um servidor, csppserver, e integramos o cliente na dcrwallet. Para dar uma compreensão mais profunda de como o CoinShuffle++ funciona, trabalharemos em um exemplo simples que ilustra o conceito por trás do processo. Além do que está descrito no documento, há um robusto suporte a denominações e troco embutidos na carteira, e é configurada para lidar com transações regulares e compra de tickets. Existem algumas limitações notáveis ​​para esta versão inicial, já que é apenas CLI, requer uma configuração de staking ou não-staking, e mixagens podem ser desfeitas por um adversário que pode quebrar o problema de logaritmo discreto (“DLP”). Espera-se que cerca de 12,5% de todos os gastos em circulação façam uso da privacidade dentro de alguns meses. Configurar o dcrwallet para usar a privacidade requer a edição do arquivo de configuração.

CoinShuffle++

O CoinShuffle++ é um processo sem custódia para a criação de transações CoinJoin, em que os endereços de saída são anonimizados por meio de uma rede de mixagem. O processo pelo qual os endereços de saída são anonimizados é chamado DiceMix Light, que é uma iteração por Ruffing do processo DiceMix originalmente proposto no documento CoinShuffle++. Note-se que o CoinJoin que ocorre vaza quais endereços de entradas e de troco pertencem ao peer para o servidor, mas não para os outros peers que participam do mix. Os endereços de saída são totalmente anonimizados, de forma que nenhum dos peers ou o servidor possam dizer qual saída pertence a qual peer. Mixagens ocorrem episodicamente em intervalos, com o intervalo inicial da rede definido para 20 minutos (1200 segundos).

Arquitetura

A arquitetura cliente-servidor que escolhemos é uma abordagem comum para a infraestrutura de rede, principalmente porque a tradução de endereços de rede significa que você pode não conseguir alcançar diretamente outros peers com os quais está mixando transações. Esse problema é muito comum e se resume a uma questão de port forwarding (encaminhamento de porta) ou se o UDP hole punching é uma abordagem aceitável, o que acreditamos que acrescenta muita complexidade. Além disso, o uso de P2P direto significa que todos os peers veem o IP público de todos os outros peers, o que não é bom para a privacidade. O servidor, csppserver, requer acesso JSON-RPC ao dcrd, o daemon de consenso do Decred, para verificar se os TXOs realmente não foram gastos.

O csppserver inicial será hospedado em cspp.decred.org, mas é possível executar seu próprio servidor. A execução do seu próprio servidor terá utilidade limitada, pois o objetivo é obter o maior número possível de peers em cada mix, por isso recomendamos não fazê-lo. Existem planos para dar alta disponibilidade ao servidor no futuro.

Exemplo DiceMix Simplificado

Para entender como funciona o protocolo DiceMix, é mais didático trabalhar com um algoritmo simplificado, chamado “Secure Sum”. Este exemplo usa 3 peers, mas é simples estender esse processo para um número arbitrário de peers.

Suponha que Alice, Bob e Carol tenham um número cada e queiram calcular a soma de todos esses números, mas cada um deles quer evitar que qualquer peer saiba quais são os números dos outros peers. Alice divide seu número como A1 + A2 + A3, Bob divide seu número como B1 + B2 + B3 e Carol divide seu número como C1 + C2 + C3. Alice então envia A2 para Bob e A3 para Carol, Bob envia B1 para Alice e B3 para Carol, e Carol envia C1 para Alice e C2 para Bob. Alice calcula A1 + B1 + C1, Bob calcula A2 + B2 + C2, Carol calcula A3 + B3 + C3, então todos eles transmitem suas respectivas somas parciais para os outros peers. Agora, cada um deles pode calcular a soma de todos os números adicionando as somas parciais e nenhum peer sabe qual era o número dos outros peers, supondo que não haja conluio.

O truque usado no exemplo acima é que a soma das somas horizontais é igual à soma das somas verticais, que é aparente se você escrever as partições:

Com o DiceMix, uma complexidade adicional é adicionada, mas o conceito principal permanece o mesmo. O DiceMix envolve cada peer criando um vetor dos expoentes de seu endereço de pagamento, adicionando termos de padding a cada componente vetorial que são baseados nas chaves de sessão em pares do processo de troca de chaves, somando esses vetores de cada peer para criar um sistema de equações e em seguida, resolver o sistema de equações para os endereços de pagamento. O truque aqui é que os termos de padding são escolhidos de forma que eles cancelem à medida que são somados em todos os vetores dos peers. Uma vez que tenhamos uma lista anônima de endereços de pagamento, um processo CoinJoin padrão ocorre com os peers.

Denominações e Troco

O DiceMix anonimiza os endereços de saída para uma transação CoinJoin, mas não torna as saídas indistinguíveis. Para tornar as saídas indistinguíveis, elas devem ter uma denominação fixa para cada mix. A necessidade de denominações de saída fixa foi anotada no artigo do CryptoNote em 2012, portanto a necessidade de quantidades de saída idênticas para preservar a privacidade é bem conhecida. As denominações usadas para o Decred são o preço atual do ticket (mais uma taxa) e várias denominações fixas abaixo do preço do ticket. O preço do ticket muda a cada 144 blocos, aproximadamente a cada 12 horas, portanto, essa denominação muda com o tempo. Se o preço do ticket mudar durante um intervalo, o mix será cancelado e os peers se inscreverão no próximo mix.

Como é típico no mundo da criptografia e da privacidade, “o diabo está nos detalhes”, e o troco nas mixagens CoinShuffle++ não é uma exceção a essa regra. O CoinShuffle++ faz um ótimo trabalho de anonimizar os endereços de saída, mas se o troco não for tratado com cuidado, ele pode vincular UTXOs mixados e não mixados. Em muitos casos, as saídas de troco podem ser vinculadas a suas entradas fazendo uma análise de soma parcial, por exemplo um subconjunto de entradas soma 12.34, uma saída anônima de 10, taxa de 0.001 e troco de 2.339. Isso significa que, se o troco de 2.339 for incluído como uma entrada com saídas anônimas, ele cria um link entre as entradas que somam 12.34 e aquelas saídas anônimas, reduzindo ou removendo totalmente a privacidade que trabalhamos para criar. Para lidar com essa ameaça, o troco da mixagem vai para uma carteira separada, onde ele é então mixado em denominações menores até que a alteração seja menor que a menor denominação do mixer.

As denominações fixas foram escolhidas para equilibrar o tamanho médio de armazenamento das transações on-chain, a qualidade da mixagem e a facilidade de realizar multiplicações. Se assumirmos que as denominações usam a base N e existem denominações M, no pior dos casos, haverá saídas N-1 de uma determinada denominação, e M x (N - 1) saídas totais de uma única entrada de troco. Para a base 10, isso significa que um valor de troco de 99,999 exigiria até 5 x (10 - 1) = 45 saídas combinadas, portanto, é possível esperar um aumento de aproximadamente 22x no armazenamento de transações on-chain. Escolhemos trabalhar na base 4, com 8 denominações abaixo do tamanho do ticket, portanto, um troco no pior caso exigiria 8 x (4 - 1) = 24 saídas, criando um aumento de aproximadamente 12x no armazenamento on-chain. Duas denominações extras acima do preço do ticket foram incluídas, mas esperamos que elas tenham uso limitado. A menor denominação é 4^9 atoms = 0.00262144 e a abaixo do tamanho atual do ticket é 4^16 atoms = 42.94967296.

Limitações

Este código inicial suporta apenas a carteira CLI, dcrwallet e stakers solo, ou seja, não funciona com provedores de serviços de votação (“VSPs”) e transações regulares. Obviamente, queremos aumentar o suporte à privacidade das carteiras gráficas, por exemplo, Decrediton, e temos que trabalhar com VSPs. O desafio das carteiras gráficas é o da experiência do usuário (“UX”), pois o processo de mixagem de pagamentos ou trocos recém-recebidos exige que a carteira seja desbloqueada por períodos mais longos, por exemplo, dezenas de minutos. Os VSPs criam um desafio mais substancial porque os usuários têm uma noção de identidade quando registram uma conta em um VSP e cada conta possui um script fixo de várias assinaturas de 1-of-2. No caso de um adversário poder quebrar o DLP e ter registrado passivamente todas as comunicações entre os clientes mix e o servidor, eles podem revelar a ligação entre as entradas, saídas e trocos. Observe que não há risco de um adversário causar inflação silenciosa.

Expectativas

Um aspecto importante de qualquer recurso de privacidade é o que os usuários podem esperar obter com isso, particularmente no contexto da privacidade de adesão (opt-in). No preço do ticket atual de aproximadamente DCR 128, a compra em estado estacionário (steady state) de tickets exige que as partes interessadas gastem DCR 128 x 5 por bloco x 288 blocos por dia = DCR 184.320 por dia. Atualmente há aproximadamente 10.282.000 DCR em circulação, portanto, esta compra em estado estacionário representa aproximadamente 1,8% da emissão total sendo usada para comprar tickets todos os dias. Cerca de 50% de todos os tickets são comprados por carteiras que apenas compram tickets (solo staking), estimando que 50% da participação individual fará uso de privacidade, e aproximadamente 50% de todos os decred estão em tickets, o que significa uma estimativa de 12,5% de todos os decred usando privacidade após a liberação inicial do recurso. É provável que demore alguns meses para que a participação atinja esse nível, porque os tickets são chamados para votar lentamente ao longo do tempo e somente os tickets novos podem optar por usar a privacidade.

Tanto as partes interessadas quanto as partes não-interessadas podem usar o sistema de privacidade e estar confiantes em um fluxo constante de transações, porque integramos essas transações com o fluxo constante de compra de tickets do nosso sistema de governança. Com o sistema descrito acima, os usuários que optam pela privacidade poderão receber e gastar pagamentos com uma negação plausível e saudável, e a situação só melhorará à medida que melhorarmos a experiência do usuário e aumentarmos o nível de participação. Os observadores passivos externos poderão ver as coleções de UTXOs mixadas gastas, mas elas não poderão vincular essas transações a uma identidade.

Configuração

Com toda essa conversa sobre como a privacidade funciona, alguns leitores certamente vão desejar configurá-la e fazer funcionar. Várias novas opções devem ser definidas no dcrwallet.conf:

• csppserver=cspp.decred.org:15760 - Este é o FQDN e a porta onde o csppserver está escutando.
• csppserver.ca=cspp.decred.org.pem - Este é o certificado de CA para o csppserver.
• purchaseaccount=mixed - Define a conta na qual você comprará os tickets.
• mixaccount=mixed/1 - Conforme as mixagens ocorrem, os endereços de saída mixados virão da ramificação interna dessa conta.
• changeaccount=unmixed - Cada conjunto de entradas de mix usa um endereço de troco desta conta.
• mixchange=1 - Diz ao dcrwallet para mixar os pagamentos para changeaccount na mixedaccount.
• ticketbuyer.votingaccount=voting - Indica à carteira qual conta usar ao definir os endereços de votação dos tickets de votação.

Além de definir essas novas opções no dcrwallet.conf, duas novas contas devem ser criadas: mixed e unmixed. A conta de votação pode ser criada localmente, se sua carteira de compra de tickets também votar, ou você pode importar uma extended pubkey para uma conta de votação de uma carteira de votação externa.

As partes interessadas que executam um comprador de tickets irão desejar configurar um segundo comprador de tickets que será executado em paralelo, onde as configurações são tais que os tickets recém-comprados na 1ª carteira têm a ramificação de conta mixed 0 da 2ª carteira definida como sua conta mixed. Para partes interessadas com muitos tickets pode levar até a expiração total do ticket de aproximadamente 4,7 meses para migrar completamente para a nova carteira mixed. Os não-interessados ​​podem definir essas opções, deixando de fora uma conta de compra e participar da mixagem sem comprar tickets. Para receber pagamentos, gere novos endereços a partir da conta não mixada e, em seguida, esses pagamentos serão mixados na conta mixed.

Observe que o processo de mixagem exige que a carteira seja desbloqueada por períodos mais longos, para que ela possa participar de uma mixagem que ocorre a cada 20 minutos. As carteiras de compra de tickets já estão desbloqueadas, mas as carteiras que não são de staking precisam ser desbloqueadas por tempo suficiente para concluir suas mixagens.

Trabalho futuro

Há muito trabalho a ser feito para melhorar a privacidade, tanto em termos de aprimoramento quanto de inclusão na versão de privacidade inicial. O UX para carteiras gráficas, por exemplo Decrediton, requer trabalho de integração nos componentes gráficos e no dcrwallet. Reformar as VSPs para serem compatíveis com a privacidade requer ir de um sistema baseado em conta para um sistema baseado em ticket direto, e isso requer modificação nas dcrstakepool e dcrwallet. Esta versão inicial depende de um único processo de servidor, mas podemos substituir este servidor único por um cluster ou por um mempool de mixagem no dcrd. Depois de ver a complexidade que surge do suporte ao troco, a adição de suporte a confidential transactions (“CT”) seria um próximo passo natural, o que exigiria uma mudança de consenso. Como o processo de mixagem não ocorre on-chain, é possível modificar o DiceMix para suportar criptografia pós-quântica (“PQ”), o que tornaria a mixagem segura contra um adversário que pode quebrar o DLP.

Integração com a carteira gráfica

Como mencionado acima, há algumas mudanças que devem ser feitas no dcrwallet para que a UX de mixagem com o Decrediton seja aceitável. O problema aqui é que um intervalo na ordem de 20 minutos exige que uma carteira de mixagem esteja pronta para assinar a transação CoinJoin por pelo menos esse período de tempo. A opção simples aqui é deixar a carteira inteira desbloqueada por um longo período, mas essa é uma prática ruim de segurança. Com algum trabalho, é possível fazer o dcrwallet desbloquear apenas uma conta por vez, por exemplo a conta não mixada, e fazer todos os RPCs que envolvem a assinatura para a carteira exigir explicitamente a frase secreta. Depois que essas alterações forem feitas, a integração do suporte à privacidade no Decrediton deve ser mais fácil.

VSP Changes

Os VSPs operam atualmente por conta, por exemplo você tem um login, um endereço fixo de multiassinatura 1-of-2 para essa conta e um único conjunto de preferências de votação, mas para oferecer suporte adequado à privacidade, os VSPs devem operar com base em tickets. Isso exige que os usuários enviem uma chave privada individual por ticket ao VSP, as taxas do VSP sejam pagas via pagamento direto e as preferências do ticket definidas por ticket. Além disso, seria ideal se os tickets fossem delegados para VSPs via Tor ou similar. Isso requer alterações no dcrwallet e no dcrstakepool. Como aproximadamente 50% dos tickets são mantidos por VSPs, isso deve se traduzir em uma duplicação aproximada do uso de privacidade, de 12,5% a 25% do decred em circulação.

Mixer Server Clustering

É simples operar um único servidor de mixagem, mas não é uma configuração particularmente resiliente, mesmo que seja suficiente para lidar com um volume substancial de transações. Uma configuração de longo prazo mais resiliente seria um cluster de alta disponibilidade, ou até mesmo integração do servidor no dcrd, criando um mempool de mixagem. Pode haver razões para não integrá-lo ao dcrd, portanto é necessária uma investigação mais aprofundada aqui.

Confidential Transactions

O aumento da complexidade e do armazenamento de transações on-chain, necessário para lidar adequadamente com o troco no CoinShuffle++, é uma boa motivação para considerar a inclusão de ofuscação das quantias das transações. Ofuscar quantias faz com que toda a análise de soma parcial e a mixagem correspondente baseada em denominação se tornem obsoletas. Isto leva a uma única transação de mixagem por intervalo, em vez de várias transações de mixagem separadas com várias denominações. Convenientemente, há um artigo “Mixing Confidential Transactions: Comprehensive Transaction Privacy for Bitcoin” de Ruffing e Moreno-Sanchez, que cobre exatamente essa melhoria. Se Bulletproofs (“BPs”) forem usados, o tamanho das transações usando o CT é tal que é provável que isso reduza os requisitos de armazenamento de transações on-chain.

Uma preocupação válida sobre a CT é que um adversário que pode quebrar o DLP pode criar inflação silenciosa, o que seria desastroso para o sistema de governança de PoS do Decred e sua capacidade de servir como uma reserva de valor. Embora existam argumentos válidos com base em informações públicas de que um computador quântico em larga escala em funcionamento ainda está a muitos anos de distância, existe um grande incentivo para que governos desenvolvam essa tecnologia em segredo e a usem para descriptografar uma grande variedade de dados criptografados. Os autores das BPs sugerem na seção 4.9 que é possível implementar BPs que são computacionalmente ocultas e perfeitamente vinculativas, em vez de BPs mais simples, perfeitamente ocultas e computacionalmente vinculativas. Vamos investigar essa opção porque o modo de falha da inflação silenciosa seria seriamente prejudicial para o Decred.

Criptografia pós-computação quântica

Um dos principais benefícios do CoinShuffle++ e do protocolo associado DiceMix é que ele pode ser modificado para suportar criptografia PQ, tornando o processo de mixing seguro contra adversários que podem quebrar o DLP. O DiceMix exige que os peers participantes realizem uma troca de chaves em pares, o que eles sugerem que seja feito como troca de chaves não interativa por motivos de simplicidade, porque uma troca de chaves interativa criaria rodadas adicionais de comunicação. Ao adicionar uma rodada adicional de comunicação, é possível usar a criptografia PQ para proteger o processo de troca de chaves. A Company 0 possui uma implementação existente de um dos melhores sistemas de criptografia PQ, Streamlined NTRU Prime 4591^761, baseado no trabalho de Bernstein, Chuengsatiansup, Lange e van Vredendaal, portanto, essa seria uma escolha natural para essa aplicação. Como o processo de mixing ocorre off-chain, as considerações típicas de tamanho de transação para o uso da criptografia PQ não são relevantes, por exemplo, as chaves públicas PQ geralmente têm 1 KB ou mais. Observe que isso não impediria um adversário que pode quebrar o DLP de roubar fundos onde a chave pública correspondente foi revelada, mas impediria que eles desfizessem passivamente mixings para remover a privacidade.

Conclusão

É reconfortante tornar esse trabalho público e fornecer um release inicial de privacidade aos nossos stakeholders de uma maneira que possa beneficiar todos os usuários do Decred. Esses recursos estão disponíveis como uma solicitação pull do dcrwallet no GitHub e incentivamos os usuários mais técnicos a testarem esse código conosco. Este código recebeu testes substanciais na testnet durante todo o seu desenvolvimento, por isso já deve estar bastante estável. Após alguns testes adicionais, este código se tornará parte do branch master e será incluído no próximo release, 1.5.0. Estamos sempre à procura de desenvolvedores talentosos, portanto, se este trabalho de privacidade lhe interessar, entre em nosso chat e fale conosco.

Enquanto o trabalho já concluído é substancial, ainda há muito a fazer. Nosso objetivo é manter o código de privacidade simples, tanto em termos de primitivos criptográficos quanto às suas restrições implícitas na blockchain do Decred. O Decred continuará a interagir e adaptar-se ao cenário de privacidade em constante mudança, integrando novos recursos conforme necessário, de acordo com a vontade das partes interessadas, para lidar com as ameaças à medida que elas surgirem. Como sempre, nós nos esforçamos para maximizar a segurança da nossa blockchain e de seus usuários, e faremos isso de forma sustentável, para fazer do Decred uma reserva de valor superior a longo prazo.

De acordo com o artigo de privacidade anterior, adicionamos o Decred ao quadro abaixo.