Uma auditoria de uma carteira de criptomoeda é uma oportunidade para terceiros (o "auditor") verem as transações dessa carteira e calcular seu saldo atual correto sem o direito de gastar dinheiro.

O artigo discute várias maneiras de fornecer essa oportunidade no protocolo de criptografia CryptoNote 2.0 [ 1 ], onde a auditoria é implementada apenas parcialmente: usando uma chave de rastreamento, você pode reconhecer transações de entrada, mas para reconhecer as transações de saída, é necessário um conjunto completo de chaves.

O material é destinado a leitores familiarizados com o tópico blockchain e criptomoedas "clássicas", bem como com os conceitos básicos de criptografia em curvas elípticas.

Conteúdo

1.
2.
3. CryptoNote
4. 1/3. Bytecoin Auditable Coins
4.1. tx.version < amethyst, legacy address
4.2. tx.version ≥ amethyst
4.3. tx.version ≥ amethyst, legacy address
4.4. tx.version ≥ amethyst, amethyst address
4.5. CryptoNote Bytecoin Amethyst
5. 2/3. CryptoNote Anton Sokolov
6. 3/3.
7.

1.

CryptoNote?

Curiosamente, a maioria dos interessados na tecnologia blockchain não ouviu nada sobre o CryptoNote, e isso apesar do fato de que essa tecnologia se tornou a base de mais de 300 garfos, o mais famoso deles é o Monero.

Em 2014, apareceram menções no ambiente de criptomoeda [ 2] sobre um projeto chamado Bytecoin. O projeto não era um fork do Bitcoin ou outro projeto de código aberto e tinha uma base de código completamente nova, o que era extremamente incomum para a época. Seu principal conceito era implementar uma tecnologia de privacidade chamada CryptoNote. A privacidade foi fornecida por dois mecanismos: endereços secretos e mixagem de entradas usando uma assinatura de anel (também era chamado naquela época de "misturador na blockchain"). Como naquela época o Zcash existia apenas em teoria, a tecnologia se mostrou muito competitiva e causou uma grande ressonância na comunidade de criptomoedas.

Logo, um grupo de entusiastas que demonstrou interesse em um dos primeiros garfos dessa tecnologia e depois tomou a iniciativa nesse garfo, com suas ações energéticas, conseguiu atrair a maior atenção à tecnologia, tanto na comunidade quanto nos investidores. Este fork foi chamado BitMonero [ 3 , 4 ], mas logo foi renomeado para Monero.

No futuro, os dois projetos - Bytecoin e Monero - se desenvolveram de maneiras tecnologicamente diferentes: se o Bytecoin permaneceu um projeto anônimo fechado, então o Monero se transformou em um grande projeto orientado pela comunidade, com um número muito grande de participantes e desenvolvedores. No entanto, ambos são um desenvolvimento da tecnologia CryptoNote.

O conceito de auditoria e sua aplicação

Ao contrário do blockchain clássico "pseudônimo", como o Bitcoin, no qual qualquer pessoa, ao digitalizar o blockchain, pode calcular trivialmente os saldos de qualquer endereço, em um blockchain privado, em particular no CryptoNote, essa tarefa dificilmente é possível sem conhecimento adicional. Em primeiro lugar, graças à tecnologia de endereços furtivos, não há referências a nenhum endereço no blockchain (essa propriedade é geralmente chamada de anonimato ). Em segundo lugar, devido ao fato de que, devido à assinatura do anel, a entrada da transação não indica uma saída específica da transação pai, mas, em geral, indica muitas saídas possíveis, também não é possível rastrear a movimentação de fundos (essa propriedade é chamada não rastreabilidade ).

No entendimento tradicional da criptomoeda privada, essas propriedades são necessárias, mas há casos especiais em que o proprietário da carteira pode divulgar o histórico de suas transações e o saldo atual da carteira a terceiros, garantindo que é impossível que um terceiro gaste dinheiro. Isso pode ser necessário, por exemplo, para trocas, para interação com reguladores ou autoridades de verificação. Além disso, isso pode ser importante para vários fundos que gostariam de ser transparentes a um grupo específico de indivíduos ou de serem totalmente públicos.

Falando formalmente, uma auditoria de carteiras significa uma oportunidade para terceiros (o "auditor") verem as transações dessa carteira e calcularem seu saldo atual correto sem transferir o direito de gastar dinheiro. Na versão original do CryptoNote, a auditoria foi implementada apenas parcialmente: usando uma chave de rastreamento, é possível reconhecer transações de entrada, mas para reconhecer transações de saída, é necessário um conjunto completo de chaves.

Sobre o autor e o objetivo da publicação

O autor deste material é um dos principais desenvolvedores do projeto Zano - um projeto baseado no CryptoNote, que vem sendo desenvolvido há vários anos com as mesmas mãos que escreveram o código original da tecnologia.

Agora, nossa equipe está considerando adicionar uma auditoria de carteira ao projeto e realizar pesquisas sobre esse tópico para escolher a melhor opção. O autor deseja apresentar os resultados de alguns desses estudos aos leitores neste artigo.

2. Informações básicas sobre criptografia em curvas elípticas

O protocolo CryptoNote usa uma curva elíptica do esquema de assinatura digital de chave pública ed25519 [ 5 ].

Lembre-se dos principais parâmetros desta curva e dê definições adicionais.

Corrigido um grande prime $q = 2^{255}-19$ .
$F_q$ $q$ .
$F_q$ , $E/F_q$ :
$−x^2+y^2= 1 +dx^2y^2$
$d = −121665/121666$ ( $F_q$ ).
$x$ $y$ .
, : $F(A, B) = C$ , «», , , ( [6]). , , , , $E(F_q)$ .
( ): $\# E(F_q)=2^cl$ , $= 3$ () $l=2^{252}+27742317777372353535851937790883648493$ .
$(x, y)$ . , , $y$ , 256- .
$x$ -, (. ), , , $y$ -.
$G = (x, −4/5)$ . $y$ -, x .
(. . 3) $G$ $n$ ( $*$ , ) , $\mathbf{G}$ , , $E(F_q)$ :
$\#\mathbf{G} < \#E(F_q)$ ,

$\#\mathbf{G}=l=2^{252}+27742317777372353535851937790883648493$ .
$X$ — , $\mathbf{G}$ :
$X \in \mathbf{G}$
$x$ , , $X$ — , :
$X = x*G, x \in [1; l-1]$
, (. ), 256- .
- $H$ ( cn_fast_hash). 32- : $H:\{0, 1\}^* \to [0,2^{256}-1]$
- $H_s$ ( $s$ scalar) , , .. :
$H_s:\{0,1\}^* \to [1; l-1]$
$H_s$ $H$ :
$H_s(x)= H(x) \mod (l-1) + 1$
- $H_p$ ( $p$ point — ) $\mathbf{G}$ , , :
$H_p:\{0,1\}^* \to \mathbf{G}$
- , -, 256 (. . 4), -, $\mathbf{G}$ (. . 6).
$H_p$ $H(H(...H(x)...))$ , $X \in \mathbf{G}$ .
CryptoNote , ge_fromfe_frombytes_vartime, [7].
, 256 $\mathbf{G}$ :
$to\_point : [0,2^{256}-1] \to \mathbf{G}$
CryptoNote - $H_p$ :
$H_p(x) = to\_point( H(x) )$

3. CryptoNote

Lembre-se de como os fundos são enviados e o saldo é calculado na versão original do protocolo.

Alice, enviando dinheiro para Bob, forma os resultados de sua transação da seguinte maneira (Fig. 3.1).

_{FIG. 3.1 Alice gera saídas de transação enviando dinheiro para Bob}

Bob tem um par de chaves privadas $(v, s)$ . Ele calcula seu endereço como um par de chaves públicas correspondentes $(V, S)$ e publica ou envia para Alice.
Alice escolhe uma chave de transação secreta aleatória $r$ e calcula a chave pública $R = r G$ que grava no campo especial transações extras.
Para cada saída, Alice calcula o endereço secreto (chave de destino única):
$P_i = H_s(rV, i)G + S$ Onde $i$ - número de série da saída.
Alice assina e envia a transação.

Observador de terceiros analisando endereços secretos

$P_i$ , não pode dizer se uma saída específica é destinada a Bob e nem mesmo pode determinar se saídas diferentes com chaves são destinadas

$P_i$ e

$P_j$ para um destinatário.

Para aceitar o dinheiro, Bob analisa todas as transações na blockchain da seguinte forma (Fig. 3.2).

_{FIG. 3.2 Bob verifica as saídas da transação para determinar as transferências recebidas}

5. Usando sua chave privada

$v$ Bob calcula para cada saída

$P’_i = H_s(vR, i)G + S$ (Onde

$i$ - número de série da saída,

$S$ - Chave de gastos públicos de Bob).
E se

$P’_i = P_i$ , isso significa que ele é o destinatário dessa saída e pode gastá-la calculando a chave secreta correspondente, portanto, Bob aumenta o saldo de sua carteira pelo valor dessa saída.

Para gastar a saída, Bob recebe e envia moedas para Carol, ele age da seguinte maneira.

_{FIG. 3.3 Bob forma uma entrada para uma nova transação usando sua própria saída}

6. Bob usando suas chaves secretas

$(v, s)$ calcula a chave privada

$x_i = H_s(vR, i) + s$ para discrição

$P_i$ , ou seja, de modo que

$P_i = x_i G$ .

7. Bob calcula a imagem principal:

$I = x_i H_p(P_i)$ e escreve, o valor de face e um link para a saída correspondente na entrada de sua transação para Carol.
Note-se que, primeiro, apenas o proprietário da chave secreta de gastos pode calcular a imagem da chave

$s$ (a exatidão disso será certificada por uma assinatura de anel) e, em segundo lugar, um terceiro não poderá vincular a imagem da chave

$I$ e o endereço furtivo correspondente

$P_i$ .

8. Bob reduz o saldo de sua carteira pelo valor nominal da saída usada no parágrafo 6.

9. Bob forma as saídas na transação para Carol de acordo com os parágrafos. 2-3. Em seguida, assina a transação e envia.

Assumindo que Bob perdeu toda a história de suas operações, mas ainda possui suas chaves secretas

$(v, s)$ , ele poderá restaurar o histórico de transações e calcular seu saldo atual da seguinte maneira (Fig. 3.4).

_{FIG. 3.4 Bob determina seus pagamentos recebidos e efetuados e calcula o saldo}

10. Bob varre toda a cadeia de blocos e analisa todas as transações quanto à presença de saídas endereçadas a ele (consulte o parágrafo 5).

11. Ao encontrar essa saída

$P_i$ , Bob aumenta o saldo da carteira pelo valor do valor nominal.
Em seguida, usando sua chave secreta de gastos

$s$ calcula a chave de saída secreta correspondente

$x_i$ (p. 6) e imagem principal

$I$ (ponto 7) Em seguida, escreve a imagem principal,

$P_i$ e outros dados de pagamento em uma tabela.

12. Se durante uma varredura adicional do blockchain, Bob encontrar na entrada de alguma transação a imagem principal da tabela, isso significa que essa transação já foi formada por Bob. Portanto, ele reduzirá o saldo de sua carteira pelo valor do valor de entrada.

Ao fazer isso, Bob restaurará o saldo atual de sua carteira.

Observe que, se o auditor externo Dan receber uma chave secreta de Bob

$v$ , ele poderá reconhecer as transações recebidas de Bob na blockchain, no entanto, sem uma chave secreta

$s$ , ele não poderá reconhecer as transações de saída de Bob, o que significa que ele também calculará o saldo correto. Como será mostrado mais adiante, no caso de gastos diretos da saída de Bob sem misturar, Den poderá identificar uma transação como a transferência de saída de Bob, mas, no caso geral, isso não pode ser feito.

Portanto, para calcular o saldo da carteira de Bob, você precisa conhecer as duas chaves secretas $(v, s)$ .

Se Bob der as duas chaves privadas ao auditor Dan

$(v, s)$ , isso equivale a transferir os fundos eles mesmos, já que Den, possuindo

$s$ será capaz de gastá-los. Portanto, uma auditoria completa de carteiras sob o protocolo CryptoNote original não é possível.

Nas seções a seguir, consideraremos opções para modificar o protocolo que possui esse recurso.

Observe que a chave secreta da transação

$r$ Faz sentido que Alice salve (o que acontece em algumas implementações de protocolo). Quem sabe

$r$ para alguma transação, pode verificar se a saída é relevante

$i$ esta transação para o endereço fornecido

$(V, S)$ simplesmente repetindo os cálculos da cláusula 3:

$P’_i = H_s(rV, i)G + S$

e comparando o resultado com

$P_i$ .

Alice pode, por exemplo, usar esse fato para provar que ela transferiu o dinheiro para Bob.

Calcular endereço de destino

$(V, S)$ na saída, mesmo sabendo

$r$ , você não pode.

4. Opção 1/3. Moedas auditáveis do Bytecoin

No momento de sua aparência, o Bytecoin foi a primeira e única implementação do protocolo CryptoNote, por isso foi caracterizado por todos os recursos e limitações discutidos na seção anterior.

Em 7 de fevereiro de 2019, os desenvolvedores lançaram ([ 20 ]) versão 3.4.0 do Amethyst, que contém várias melhorias e alterações no CryptoNote, que consideraremos agora. A maioria das informações nesta seção foi obtida através da análise do código fonte do Bytecoin, uma vez que nenhuma documentação oficial foi fornecida.

No escopo deste artigo, a mudança mais interessante foi a capacidade das carteiras comuns de criar cópias especiais - carteira auditável (AW), que possui duas propriedades:

O AW não pode gastar fundos da carteira principal;
O saldo do AW sempre coincide com o saldo da carteira principal. Não é possível alterar o saldo da carteira principal para que não afete o saldo do AW.

No entanto, apenas os endereços de carteira de novas versões, os chamados endereços de ametista, têm essa funcionalidade. A compatibilidade com versões anteriores é fornecida com endereços e contas existentes; eles agora são chamados de endereços herdados. A implementação da nova funcionalidade se tornou possível apenas nas transações da nova versão, uma vez que os desenvolvedores alteraram o formato das saídas, portanto, as redes de bytecoin circulam atualmente as transações de formato antigo e as novas. As transações do novo formato também suportam dois tipos de endereços: ametista e legado; portanto, no final, temos três opções para esquemas criptográficos:

tx.version <ametista, endereço herdado;
tx.version ≥ ametista, endereço herdado;
tx.version ≥ ametista, endereço de ametista.

Vamos considerá-los com mais detalhes.

4.1 tx.version <ametista, endereço herdado

Este é o esquema original do CryptoNote, mas com geração determinística.

$r$ .

Conta da carteira representada por chave secreta.

$s$ e hash

$v_s$ . Chave de visualização secreta

$v$ deterministicamente gerado em função de

$v_s$ .

A chave secreta

$r$ As transações agora são selecionadas não por acaso, mas calculadas usando

$v_s$ :

$r = H_s(h_t, v_s)$ Onde

$h_t = H(tx.inputs, tx.version)$

Isso elimina a necessidade de chaves privadas.

$r$ no armazenamento local para necessidades futuras, já que para qualquer transação já enviada para o blockchain, essa chave pode ser calculada usando

$v_s$ .

O saldo da carteira é calculado de forma semelhante ao CryptoNote original (consulte a seção 3), ou seja, é necessária uma chave secreta de gasto para contabilizar as contas a pagar

$s$ .

Se todos os endereços que já foram transferidos para a carteira forem salvos no armazenamento local da carteira , é possível calcular o saldo correto sem envolver uma chave secreta de gastos

$s$ Da seguinte maneira:

Alice verifica as transações no blockchain e controla os pagamentos recebidos usando uma chave de visualização secreta $v$ , conforme descrito na seção 3, e aumenta o equilíbrio.
Além disso, para cada saída de cada transação, Alice passa por todos os endereços $(V, S)$ para as quais já foram feitas transferências e calcula:
$P’_i = H_s(rV, i)G + S$
E se $P’_i = P_i$ , essa saída é o pagamento efetuado por Alice no endereço $(V, S)$ e reduz o equilíbrio.

Então Alice calculará o saldo usando apenas

$v_s$ e

$v$ .

Obviamente, esse método não é confiável e impraticável, pois a ausência no armazenamento local indicado do endereço para o qual a transferência foi efetivamente realizada levará a uma superestimação da balança. Portanto, é, antes, de interesse teórico.

4.2 tx.version ≥ ametista

Como observado acima, desde a versão 3.4.0 da Amethyst, o Bytecoin mudou o formato das transações. Se tx.version ≥ ametista, as saídas da transação terão um formato diferente.

Agora, cada uma das saídas, para além da quantidade e da P chave pública _i , também contém um adicional Q chave pública _i (indicado no código da encrypted_secret) e um byte adicional contendo o encriptado tipo endereço, ametista ou legado (referidos no código encrypted_address_type). Estas estruturas são mostrados esquematicamente na Fig. 4.2

_{FIG. 4.2 Comparando a estrutura de dados das saídas da transação CryptoNote e Bytecoin Amethyst}

Assim, o tamanho de cada saída aumentou em 33 bytes.

Para cada saída i, o tipo de endereço é codificado e decodificado da seguinte maneira :

encrypted_address_type(i) = (H(o_i) & 255) xor address_tag

$o_i = H(h_t, v_s, i)$ (indicado no código como output_seed),

address_tag é 0 para endereços herdados e 1 para endereços amétimo.

4.3 tx.version ≥ ametista, endereço herdado

A conta da carteira também é representada por uma chave secreta.

$s$ e hash

$v_s$ com base na qual uma chave de visão secreta é gerada deterministicamente

$v$ .

Alice enviando dinheiro para Bob em seu endereço

$(V, S)$ forma os resultados de sua transação da seguinte maneira:

1. Calcula

$h_t = H(tx.inputs, tx.version)$ , então para cada saída

$i$ :
2

$D_i = H_s(h_t, v_s, i)G$ (indicado no código como output_shared_secret)
3.

$P_i = S + H_s(D_i, h_t, i)G$
4)

$Q_i = H_s(h_t, v_s, i)V$ (em que

$Q_i = v D_i$ no entanto, visualizar chave

$v$ destinatário desconhecido)
5. Par

$(P_i, Q_i)$ - chaves de saída públicas

$i$ .

Para aceitar o dinheiro, Bob analisa todas as transações da seguinte maneira.

6. Para cada transação, calcula

$h_t = H(tx.inputs, tx.version)$ , então para cada saída

$i$ :
7

$D_i = v^{-1} Q_i$
8)

$S’ = P_i — H_s(D_i, h_t, i) G$
9. Se

$S’$ corresponde à chave pública

$S$ Bob, essa saída é para ele e ele aumenta o saldo de sua carteira pelo valor nominal correspondente.

Para gastar a saída, Bob recebe e envia moedas para Carol, ele age da seguinte maneira.

10. Usando suas chaves secretas

$v$ e

$s$ calcula a parte secreta

$P_i$ :

$D_i = v^{-1} Q_i$

$x_i = s + H_s(D_i, h_t, i)$ , é fácil ver que

$P_i = x_i G$ (ver parágrafo 3)
11. Bob calcula a imagem principal:

$I = x_i H_p(P_i)$ e escreve, o valor de face e um link para a saída correspondente na entrada de sua transação para Carol.
12. Bob reduz o saldo de sua carteira pelo valor da saída usada.
13. Bob forma os resultados da transação para Carol de acordo com 1-5. Em seguida, assina a transação e envia.

Um recurso desse esquema, diferentemente do CryptoNote, é que qualquer pessoa para quem Alice transfira seu hash secreto

$v_s$ , será capaz de calcular o endereço do destinatário

$(V, S)$ para qualquer transação com Alice:

14.

$D_i = H_s(h_t, v_s, i) G$
quinze.

$S = P_i — H_s(D_i, h_t, i) G$
dezesseis.

$V = H_s(h_t, v_s, i)^{-1} Q_i$

No entanto, o problema nesse caso é a tarefa de determinar quais transações Alice gerou e enviou. Sem essa informação na p.p. 14-16 para transações arbitrárias serão obtidos dados inúteis arbitrários indistinguíveis de endereços reais

$(V, S)$ . O algoritmo de codificação pode fornecer alguma ajuda encrypted_address_type, pois nas transações de Alice esse campo após a decodificação terá apenas valores válidos

$\{0, 1\}$ . Infelizmente, porém, valores aceitáveis também podem ser obtidos arbitrariamente, e esse caso não pode ser distinguido.

Como nesse esquema, o cálculo da imagem-chave também requer conhecimento da chave secreta de gastos

$s$ , o problema de auditoria, ou seja, calcular o saldo exato da carteira sem transferir os direitos de gastar dinheiro, permanece sem solução.

4.4 tx.version ≥ ametista, endereço de ametista

H constante

A operação desse esquema criptográfico requer a introdução de uma nova constante - o ponto

$H$ elemento do grupo

$\mathbf{G}$ e a ordem do ponto

$H$ desconhecido. Em outras palavras, essa é uma chave pública fixa, cuja parte secreta é garantida desconhecida e a probabilidade de sua descoberta é insignificante:

$H = yG$ Onde

$y$ É um número desconhecido.

Por exemplo, você pode definir

$H$ como proposto em [ 8 ]:

$H = H_p(G) = to\_point( cn\_fast\_hash(G) )$

Os desenvolvedores de Bytecoin não calculam a constante, mas a definem numericamente, sem nenhuma indicação da natureza de sua origem:

bytecoin / src / crypto / crypto_helpers.hpp, linha 67

constexpr P3 H{ge_p3{{7329926, -15101362, 31411471, 7614783, 27996851, -3197071, -11157635, -6878293, 466949, -7986503},    {5858699, 5096796, 21321203, -7536921, -5553480, -11439507, -5627669, 15045946, 19977121, 5275251},    {1, 0, 0, 0, 0, 0, 0, 0, 0, 0},    {23443568, -5110398, -8776029, -4345135, 6889568, -14710814, 7474843, 3279062, 14550766, -7453428}}};

No entanto, uma busca por essa sequência numérica mostrou ([ 9 ]) que eles usam a mesma constante que em Monero para RingCT, cujo método de cálculo e sua justificativa foram considerados em [ 8 ].

Porque o

$H$ pertence ao grupo

$\mathbf{G}$ , então podemos dizer que

$H$ também gera um grupo

$\mathbf{G}$ como ponto base

$G$ .

Significa que

$\forall x \in [1,p-1], xH \in \mathbf{G}$

Vários endereços não vinculáveis

No CryptoNote original, cada carteira (ou seja, um conjunto de chaves secretas) era associada a um endereço público, usado para transferir fundos para ela.

O esquema considerado permite gerar um número ilimitado de endereços públicos no mesmo conjunto de chaves secretas. Em que:

endereços são gerados deterministicamente a partir do conjunto inicial de segredos;
esses endereços não podem ser interconectados, ou seja, um observador externo não será capaz de calcular que pertence à mesma conta;
verificação de transações recebidas e contabilização de $N$ vários endereços serão computacionalmente mais fáceis do que verificar $N$ contas no esquema usual.

Conta da carteira representada por chave secreta.

$s$ e hash

$v_s$ , bem como no esquema anterior. No entanto, com base no hash

$v_s$ agora, não apenas uma chave de exibição secreta é gerada deterministicamente

$v$ , mas também uma chave de auditoria secreta adicional

$a$ .

O processo de geração do i-ésimo endereço é o seguinte (Fig. 4.4.2).

_{FIG. 4.4.2 Geração de endereços de ametista para a conta Bytecoin (a cor amarela indica os valores calculados, cuja divulgação não ameaça a divulgação de chaves secretas $v$ , $s$ e $v_s$ )}

1. Calculado

$\delta = H_s(A + sH, i)$ e

$\Delta = \delta G$
2)

$S = A + sH + Δ$
3)

$V = vS = v(A + sH + Δ) = v(A + sH) + δV$
4. par

$(V, S) = (v S, S)$ é um

$i$ O endereço público desta conta.

Note-se que o cálculo é o suficiente para saber os seguintes valores:
•

$A$
•

$V$
•

$s H$
•

$v (A + s H)$

Quantidades

$s H$ e

$v (A + s H)$ são calculadas ao criar uma conta e são consideradas seguras no sentido de que conhecê-las, você não pode calcular

$s$ ou

$v$ .

Os endereços gerados são armazenados localmente em um contêiner otimizado para pesquisa de campo.

$S$ .

Formação de saídas ao enviar fundos

Alice enviando dinheiro para Bob em seu endereço

$(V, S)$ forma os resultados de sua transação da seguinte forma (Fig. 4.4.3).

_{FIG. 4.4.3 Formação de resultados de transações ao enviar fundos para um endereço de Ametista}

1. Calcula

$h_t = H(tx.inputs, tx.version)$ , então para cada saída

$i$ :
2

$P_i = H_s( H_p(h_t, v_s, i), h_t, i )^{-1} S$
3)

$Q_i = H_s( H_p(h_t, v_s, i), h_t, i )^{-1} V + H_p(h_t, v_s, i)$
4. Casal

$(P_i, Q_i)$ - chaves de saída públicas

$i$ .

Contabilização de pagamentos recebidos

Para aceitar o dinheiro, Bob analisa todas as transações da seguinte maneira (Fig. 4.4.4.).

_{FIG. 4.4.4 Análise dos resultados da transação para transferências recebidas}

Para cada saída $i$ usando uma chave de visualização secreta $v$ Bob calcula: $K = H_p(h_t, v_s, i) = Q_i — v P_i$ ( output_shared_secretno código)
$S’ = H_s(K, h_t, i) P_i$
Após o que ele tenta encontrar $S’$ na sua lista de endereços. Se encontrar, significa que essa saída transfere dinheiro para Bob. Aumenta o saldo do endereço correspondente.

Isso significa que, para considerar corretamente os pagamentos recebidos, nesse esquema, além da lista de endereços ou chaves para gerá-los, é necessário conhecer a chave de exibição secreta

$v$ .

Formação de contas a pagar

Para passar uma saída

$i$ qual Bob é o destinatário, e envia as moedas para Carol, ele age da seguinte maneira.

$K = H_p(h_t, v_s, i) = Q_i — v P_i$ ( output_shared_secretno código)
$x_i = H_s(K, h_t, i)^{-1} (a + \delta)$
$X_i = x_i G + H_s(K, h_t, i)^{-1} s H$
Calcula a imagem principal $I = x_i * H_p(X_i)$
Bob reduz o saldo relacionado ao seu endereço $S = H_s(K, h_t, i) P_i$ pelo valor nominal da saída correspondente.
Bob gera saídas de transação, assina e envia.

Observa-se que para calcular a imagem-chave requer conhecimento não apenas da chave de exibição secreta

$v$ , mas também

$a$ .

Uma característica importante desse esquema é a capacidade de calcular uma imagem-chave (e, portanto, levar em consideração seus pagamentos efetuados, portanto, calcular o saldo) sem usar uma chave secreta de gasto. $s$ .

Divulgação do Endereço do Destinatário de Auditoria

Assim como o anterior, esse esquema criptográfico permite extrair endereços de destinatários das saídas da transação se o hash secreto do remetente for conhecido

$v_s$ .

Isso acontece da seguinte maneira (Fig. 4.4.5).

_{FIG. 4.4.5 Auditor que possui $v_s$ , restaura informações sobre entrada / saída de pagamentos, saldo e endereços de destinatários}

Suponha que Alice tenha passado

$v_s$ e

$s H$ Carol. Então Carol:

Recuperar chaves secretas $v$ e $a$ , restaurará a lista de endereços de Alice.
Irá verificar o blockchain para cada saída. $i$ cada transação determinará se é um pagamento recebido, tentando encontrar
$S’ = H_s(Q_i — v P_i, h_t, i) P_i$
entre os endereços de Alice.
Se encontrar, Carol aumentará o saldo do endereço correspondente e, com $a$ e $v$ , calculará a imagem principal (veja acima) e a salvará localmente.
Se a imagem principal de Alice for encontrada entre as entradas da transação, isso significará que essa transação é a conta de saída de Alice. Carol recuperará endereços de destinatários para todas as saídas desta transação:
$S = P_i H_s(H_p(h_t, v_s, i), h_t, i)$
$V = (Q_i — H_p(h_t, v_s, i)) H_s(H_p(h_t, v_s, i), h_t, i)$
e reduza o saldo do endereço Alice correspondente pelo valor do valor de entrada.

Assim, revelando parte dos dados da conta, você pode fornecer a terceiros diferentes níveis de acesso às informações.

Para gerar uma lista de seus endereços:
•

$A$
•

$V$
•

$s H$
•

$v (A + s H)$

Para reconhecer os pagamentos só entrada:
•

$A$
•

$v$
•

$s H$

Para auditar, ou seja, calcular o saldo em seus endereços, sem revelar os endereços dos destinatários:
•

$a$
•

$v$
•

$s H$

Para auditar, ou seja, calcular o saldo em seus endereços, e divulgar os endereços dos destinatários:
•

$v_s$
•

$s H$

4.5 Comparando assinaturas de transação CryptoNote e Bytecoin Amethyst

Estruturas de dados e tamanhos de assinatura

Como observado acima, a implementação da capacidade de auditar carteiras sem revelar uma chave secreta de gasto exigiu que os desenvolvedores do Bytecoin Amethyst aumentassem o tamanho dos dados transmitidos em cada saída da transação: em comparação com o protocolo original, uma chave pública e 1 byte são transferidos para identificar o tipo de endereço. Total de 33 bytes por saída.

No CryptoNote, cada transação é assinada separadamente para uma transação. Para cada chave pública

$P_i$ de alguma saída à qual essa entrada se refere, um par de escalares é gravado na assinatura

$(r,c)$ tamanho total de 64 bytes. (Uma entrada pode se referir a várias saídas, apenas uma real, e o restante serve para anonimizar a transferência.)

Portanto, se a transação

$N_{inputs}$ entradas, cada uma das quais se refere a

$N_{mixins}$ saídas, o tamanho total da assinatura em bytes pode ser expresso como:

$S = 32 * 2 * N_{mixins} * N_{inputs}$

O tamanho mínimo da assinatura para uma transação é de 64 bytes (uma entrada que gasta uma saída diretamente).

No Bytecoin Amethyst, toda a transação é assinada e a estrutura de dados correspondente é complicada (Fig. 4.5.1).

_{FIG. 4.5.1 Comparando a estrutura de assinatura de transação no CryptoNote e Bytecoin}

Para cada entrada de transação, um período, dois escalares e outro

$N_{mixins}$ escalares. Outra assinatura também é adicionada a toda a assinatura. Total, o tamanho total da assinatura em bytes pode ser expresso como:

$S = 32 * ((3 + N_{mixins}) * N_{inputs} + 1)$

O tamanho mínimo da assinatura para uma transação é de 160 bytes (uma entrada que gasta uma saída diretamente).

Pode-se observar que ambas as funções crescem proporcionalmente ao produto

$N_{mixins} * N_{inputs}$

Para comparar a diferença nos tamanhos de assinatura de transação com mais clareza, calculamos-os para os valores mais característicos

$N_{mixins}$ e

$N_{inputs}$ e faça uma mesa (Fig. 4.5.2).

_{FIG. 4.5.2 A diferença no tamanho da assinatura da transação Bytecoin em comparação com o CryptoNote (como uma porcentagem do tamanho da assinatura CryptoNote; o verde é o ganho no tamanho da assinatura do Bytecoin)}

Como você pode ver facilmente, em uma situação em que não há mix de produtos e há um desperdício direto de fundos (

$N_{mixins} = 1$ ) ou quando uma saída é mista (

$N_{mixins} = 2$ ), O tamanho da assinatura do Bytecoin é maior que o CryptoNote até 150%.

Ao misturar duas saídas (

$N_{mixins} = 3$ ) os tamanhos das assinaturas em um e no outro esquema praticamente coincidem.

Com um aumento adicional no número de saídas mistas, o tamanho da assinatura do Bytecoin é menor.

Vale ressaltar que os desenvolvedores do Bytecoin com o lançamento da versão 3.4.0 Amethyst, a fim de aumentar o anonimato, definem o número mínimo de saídas mistas para 3 [ 10 ]. Em tais circunstâncias, a assinatura do Bytecoin terá um tamanho menor.

A complexidade da verificação de assinatura

Além do tamanho da assinatura do anel, que afeta diretamente o tamanho da blockchain, outra característica importante é a complexidade computacional de sua verificação. Ele determina parâmetros tão importantes do sistema de criptomoedas como, por exemplo, a velocidade de sincronização com a rede de novos nós e a carga computacional na rede com um grande fluxo de transações.

A complexidade da verificação de assinaturas para CryptoNote e Bytecoin pode ser facilmente comparada na prática, basta escrever um teste que gera e, em seguida, verifica um grande número de assinaturas com os dados fornecidos.

$N_{mixins}$ e

$N_{inputs}$ no entanto, uma vez que mais adiante neste artigo consideraremos os esquemas que ainda não foram implementados na prática, mas são apenas propostos em teoria, será lógico trabalhar e avaliar esses esquemas empiricamente, de acordo com o número de operações criptográficas usadas.

O CryptoNote e o Bytecoin usam várias primitivas básicas (consulte a seção 2). Na tabela na fig. 4.5.3 o tempo de execução típico das primitivas mais comumente usadas é fornecido em um computador intermediário moderno com um processador Core i5-6500 (para comparação, o código-fonte original compilado no Microsoft Visual Studio 2017 com todas as otimizações de velocidade possíveis foi usado).

_{FIG. 4.5.3 O tempo característico das principais operações criptográficas}

Os resultados obtidos nos testes do Bytecoin e do CryptoNote estão de acordo. É fácil ver que a maior contribuição será feita pela operação de multiplicar o escalar por um ponto e, em menor grau, pelo procedimento para calcular a função hash

$H_p$ , enquanto as operações de adição de dois pontos e computação de uma função hash

$H_s$ não afetará significativamente a complexidade.

Considere o procedimento de verificação de assinatura de anel CryptoNote (Fig. 4.5.4, o procedimento de geração de assinatura foi discutido em detalhes em [ 1 ] e não será considerado aqui).

_{FIG. 4.5.4 Esquema de verificação de assinatura de anel CryptoNote}

Como já observado, no CryptoNote, cada entrada de transação é assinada separadamente, respectivamente, e cada entrada também é verificada separadamente. Portanto, o verificador para cada entrada de transação verifica a linha correspondente (na figura) da assinatura da seguinte maneira.

Para cada par de valores $r_j$ e $c_j$ usando entrada de imagem-chave $I$ e chave pública $P_j$ da próxima saída à qual essa entrada se refere, os valores são calculados: $L_j = r_j G + c_j P_j$
$R_j = r_j H_p(P_j) + c_j I$
(nesse caso, o índice j é executado de 0 a $N_{mixins}$ )
O valor é calculado $c$ de tudo $c_j$ .
O hash é calculado $c`=H_s(tx\_prefix\_hash, L_0 ... L_n, R_0 ... R_n$ )
onde tx_prefix_hashé o hash da parte do prefixo da transação (sem assinatura).
Igualdade verificada $c` = c$ . Se for, a assinatura do anel é considerada válida.

Vamos estimar o número de operações de multiplicação escalar por um ponto e cálculos de hash

$H_p$ .

Todo cálculo

$L_j$ e

$R_j$ requer duas multiplicações escalares. Número de pares

$L_j, R_j$ corresponde ao número de saídas a serem misturadas

$N_{mixins}$ para cada entrada. Portanto, temos:

$O(*) = N_{inputs} * 4 * N_{mixins}$

Nesse caso, a função hash

$H_p$ usado uma vez por cálculo

$R_j$ , conseqüentemente:

$O(H_p) = N_{inputs} * N_{mixins}$

Agora, considere o algoritmo de verificação de assinatura de anel no Bytecoin Amethyst (Fig. 4.5.5).

_{FIG. 4.5.5 Esquema de verificação de assinatura de anel Bytecoin Amethyst}

A assinatura inteira é verificada inteiramente, para todas as entradas de uma só vez. Isso acontece assim:

O prefixo hash da transação é gravado no buffer hash (sem assinatura).
Para cada entrada $i$ (linha de assinatura na figura):
Calculado $H_s$ de acordo com todos os dados do buffer de hash e o resultado é comparado com o valor $c_0$ Uma assinatura é considerada válida se a igualdade for respeitada.

Vamos estimar o número de operações de multiplicação escalar por um ponto e cálculos de hash

$H_p$ .

Todo cálculo

$Y_j$ e

$Z_j$ requer duas multiplicações escalares, além de cálculo

$X$ requer três multiplicações escalares. Número de pares

$Y_j, Z_j$ corresponde ao número de saídas a serem misturadas

$N_{mixins}$ para cada entrada. Portanto, temos:

$O(*) = N_{inputs} * (3 + 4 * N_{mixins})$

Nesse caso, a função hash

$H_p$ usado uma vez por cálculo

$Z_j$ e uma vez para calcular

$B$ para cada uma das entradas, portanto:

$O(H_p) = N_{inputs} * (N_{mixins} + 1)$

Para comparar visualmente a complexidade computacional de ambos os algoritmos em dados padrão, introduzimos a seguinte métrica. Adicione o número de operações de multiplicação escalar e operações de cálculo

$H_p$ com pesos proporcionais ao tempo característico necessário para concluir essas operações:

$O(total) = 130 * O(*) + 15 * O(H_p)$

Em seguida, compare os resultados relativos do CryptoNote e Bytecoin em porcentagem (Fig. 4.5.6).

_{FIG. 4.5.6 Complexidade computacional da verificação da assinatura do anel Bytecoin Amethyst em comparação com o CryptoNote (dependência de $N_{inputs}$ ausência de)}

Como você pode ver, a verificação de assinatura do Bytecoin é uma operação muito mais demorada.

No entanto, como observado acima, no Bytecoin da versão 3.4.0 Amethyst, para aumentar o anonimato, o número mínimo de saídas mistas é definido como 3 [ 10 ], portanto o pior valor prático não excederá 25% (em teoria).

Para resumir:

O tamanho de cada saída é aumentado pela chave pública $Q$ - 32 bytes.
O tamanho da assinatura do anel varia em comparação com o tamanho da assinatura CryptoNote, dependendo do número de saídas misturadas (com um número grande, acaba sendo menor):
$S = 32 * ((3 + N_{mixins}) * N_{inputs} + 1)$
A complexidade computacional é maior que no CryptoNote e depende significativamente do número de saídas a serem misturadas:
$O(*) = N_{inputs} * (3 + 4 * N_{mixins})$
$O(H_p) = N_{inputs} * (N_{mixins} + 1)$

5. Opção 2/3. Estudos de auditoria na CryptoNote por Anton Sokolov

No outono de 2019, uma série de ensaios [ 11 , 12 , 13 , 14 , 15 , 18 ] sobre o problema de auditoria no CryptoNote e possíveis soluções para ele de autoria de Anton Sokolov foram publicadas no Medium.com . Teoricamente, considera várias opções para modificar o protocolo original de maneira a resolver a tarefa de auditoria para terceiros.

Consideramos o último deles [ 15 ] como o mais otimizado. Vamos abreviá-lo como "AS".

Nota: por questões de consistência, as chaves de gastos continuarão sendo indicadas por letras

$s$ e

$S$ , veja chaves nas letras

$v$ e

$V$ , apesar de nos trabalhos originais serem utilizados

$b$ ,

$B$ e

$a$ ,

$A$ respectivamente.

Formação de Saída

A conta da carteira é representada por um conjunto de três chaves secretas, não duas, como no CryptoNote

$\{v, s, d\}$ : visualizar, gastar e auditar chaves, respectivamente.

Uma coleção de três chaves públicas

$\{V, S, D\}$ representa o endereço público desta conta.

Alice, enviando dinheiro para o feijão, age da seguinte maneira (Fig. 5.1).

_{FIG. 5.1 Formação dos resultados das transações no esquema AS}

Bob publica seu endereço, para que Alice saiba suas chaves públicas $V$ , $S$ e $D$ .
Como o CryptoNote, Alice escolhe uma chave de transação secreta aleatória $r$ e calcula a chave pública $R = r G$ que grava no campo especial transações extras.
Para cada saída, Alice calcula não um, mas dois endereços furtivos $P$ e $T$ . O primeiro é calculado de forma semelhante ao CryptoNote:
$P = H_s(r V) G + S$
O segundo é diferente:
$T = H_s(r D) D$
O número de série da saída não é usado no trabalho original, no entanto, é razoável supor que isso seja feito para simplificação e, na prática, será um dos argumentos da função $H_s$ semelhante ao CryptoNote (consulte a seção 3).
Alice assina e envia a transação.

Um observador externo não poderá vincular

$P$ e

$T$ com o endereço de Bob.

Reconhecimento de pagamentos recebidos e formação de insumos

Para aceitar e gastar dinheiro, Bob age da seguinte maneira (Fig. 5.2).

_{FIG. 5.2 Definição de transferências de entrada e formação de insumos para a transação que os gasta}

Usando sua chave de visualização privada $v$ Bob stealth address $P$ compara cada saída com um ponto:
$P’ = H_s(vR)G+S$
(esta etapa é semelhante ao CryptoNote)
Caso a igualdade seja cumprida, isso significa que essa saída é endereçada a Bob. Ele aumenta seu saldo pelo valor da produção nominal.
Se necessário, transfira os fundos recebidos por Carol, Bob, usando suas chaves secretas de gastos e auditoria $s$ e $d$ calcula duas imagens principais: $I$ e $\ddot I$ . O primeiro é semelhante ao CryptoNote:
$I = x * H_p(P)$
e opcional:
$t = H_s(dR)d$
$\ddot I = t H_p(P)$
Em seguida, ele os escreve, a denominação e um link para a saída correspondente na entrada de sua transação para Carol.
Em seguida, Bob forma os resultados da transação para Carol, reduz seu saldo na proporção dos resultados gastos, assina a transação e envia.

Como você pode ver, aqui, como no CryptoNote, o terceiro - o Auditor - possuindo apenas uma chave de exibição secreta

$v$ , só pode reconhecer transferências recebidas.

Auditar

Se o Auditor também tiver uma chave de auditoria secreta

$d$ , ele poderá reconhecer os pagamentos efetuados por Bob e calcular seu saldo da seguinte maneira:

Para cada pagamento recebido, o Auditor calcula e lembra uma imagem-chave adicional $\ddot I$ no armazenamento local:
$t = H_s(d R) d$
$\ddot I = t H_p(P)$
Se nas entradas de qualquer transação blockchain uma imagem-chave adicional $Ï$ Se coincidir com um dos salvos, isso significará que esta transação é o pagamento efetuado por Bob. O auditor reduzirá o saldo pelo valor nominal da entrada correspondente.

Assim, o Auditor, com um conjunto de chaves

$\{v, S, d\}$ poderá reconhecer as transferências de entrada e saída de Bob na blockchain e restaurar seu saldo correto. Ao mesmo tempo, o auditor não poderá gastar dinheiro, porque sem chave secreta de gastos

$s$ ele não será capaz de calcular a imagem principal

$I$ .

O problema está resolvido.

Assinatura de anel

Aplicando as idéias de [ 16 ], o autor conseguiu reduzir o tamanho da assinatura em comparação com o CryptoNote: agora, para cada entrada na assinatura é armazenada apenas

$N_{mixins} + 1$ escalar (Fig. 5.3).

_{FIG. 5.3 Comparando tamanhos de assinatura de anel no AS e no CryptoNote}

Assim, o tamanho da assinatura é quase pela metade.

Considere a complexidade computacional de sua verificação. O esquema de verificação de assinatura é mostrado na Fig. 5.4

_{FIG. 5.4 Esquema de verificação de assinatura de anel no AS}

Esse algoritmo é muito semelhante em estrutura ao usado no CryptoNote (veja a Figura 4.5.4). A verificação é realizada separadamente para cada entrada e consiste em calcular seqüencialmente os valores

$u_j$ ,

$L_j$ ,

$R_j$ ,

$c_j$ para todas as saídas usadas para misturar nesta entrada. Como resultado, o ciclo de

$c_j$ deve fechar e o valor

$c_{n+1}$ deve combinar

$c_0$ , nesse caso, a assinatura é considerada válida.

A complexidade computacional do algoritmo é determinada por seis operações de multiplicação escalar e um cálculo da função hash

$H_p$ à iteração, o número que é o produto

$N_{inputs} * N_{mixins}$ .

Comparação com o CryptoNote por dados e carga computacional

O tamanho do endereço aumenta em 50%, porque o endereço agora representa uma coleção de três chaves públicas:{V,S,D}não dois {V,S}.
A representação codificada do endereço aumentará aproximadamente o mesmo: por exemplo, um endereço Zano padrão contendo duas chaves públicas ocupa 97 caracteres:
```
ZxD5UBX5PM3RTsEtTRd9ATUFxXyocoQzDRk3baVBahuWQJRK8QHTUT9GQM7jk7GoedK5B2nP4HxSPDpuLHvizpwj2q99bmz7t
```
Um endereço Zano semelhante contendo três chaves públicas terá um comprimento de cerca de 141 caracteres:
```
ZxD5UBX5PM3RTsEtTRd9ATUFxXyocoQzDRk3baVBahuWQJRK8QHTUT9GQM7jk7GoedK5B2nP4HxSPDpuLHvizpwjcenhnGbhpJFLk8vkhJywHCcht4d9EKA7CHHav1H6QPpB1cLsTvPfj
```
O tamanho de cada saída é aumentado por um endereço secreto adicional $T$ - 32 bytes.
O tamanho de cada entrada é aumentado por uma imagem-chave adicional $\ddot I$ - 32 bytes.
O tamanho da assinatura do anel é menor que no CryptoNote:
$S = 32 * (N_{mixins} + 1) N_{inputs}$
A complexidade computacional é maior que no CryptoNote:
$O(*) = N_{inputs} * 6 * N_{mixins}$
$O(H_p) = N_{inputs} * N_{mixins}$

6. Opção 3/3. Auditoria através do limite de mixagem de saída

Considere outra maneira de implementar a auditoria no CryptoNote.

Atributo de saída Mix_attr

No projeto Zano, que é o sucessor do CryptoNote, a saída da transação possui um atributo mix_attr adicional de 8 bits e uma regra do kernel que restringe o uso de saídas na mistura, dependendo do seu valor.

A estrutura das saídas do CryptoNote e Bytecoin (Fig. 4.2) agora podemos complementar dessa maneira (Fig. 6.1.).

_{FIG. 6.1 Comparando a estrutura de dados para saídas de transação CryptoNote, Zano e Bytecoin Amethyst}

A regra do kernel que restringe a mistura de acordo com mix_attr é a seguinte:

mix_attr = 0, . . — -.
mix_attr = 1, , , .
mix_attr ≥ 2, , mix_attr.

A principal característica dessa inovação é o parágrafo 3, que permite aumentar a rastreabilidade (rastreabilidade de títulos), eliminando situações em que a produção já usada na mistura é gasta diretamente pelo proprietário (isso foi descrito em detalhes em [ 19 ]).

No entanto, no contexto deste artigo, estaremos interessados no item 2, ou seja, uma situação em que mix_attr = 1 e a saída marcada dessa maneira só podem ser gastos diretamente. Esta limitação é ilustrada na fig. 6.2

_{FIG. 6.2 Limite de ilustração. Acima : a entrada nº 0 refere-se apenas à saída nº 0 com mix_attr = 1 (desperdício direto) - uma situação válida. Abaixo : a entrada 1 refere-se a três saídas: saída 2 com mix_attr = 1 e também à saída 1 e saída 3 - uma situação inválida}

Como a saída 2 possui mix_attr = 1, não pode ser combinada com outras saídas, independentemente de seus valores de atributo mix_attr. Só pode ser gasto diretamente, como saída # 0.

Esse recurso pode ser usado para organizar uma auditoria.

Auditoria com mix_attr = 1

Conforme observado na Seção 3, se, sob o protocolo CryptoNote original, o Auditor Dan receber uma chave secreta de Bob

$v$ , ele poderá reconhecer transações de entrada, mas não poderá reconhecer transações de saída, portanto, o cálculo preciso do saldo é impossível.

No entanto, como Den terá informações completas sobre as saídas não gastas de Bob (UTXO), ele poderá rastrear o fato de que alguma transação em suas entradas se refere ao UTXO de Bob. Ao usar a mistura de outras saídas, Den não poderá determinar se esta transação está gastando a saída de Bob, o que é alcançado através do uso de uma assinatura de anel. No entanto, se não houver mixagem e o UTXO de Bob for gasto diretamente, o Auditor Dan pode ter certeza de que essa transação é o pagamento efetuado por Bob. Essa é a ideia desse esquema.

Suponha que Alice envie uma transação para Bob, e Bob deseja que o Auditor Dan veja o fato de que Alice recebeu o dinheiro e que eles gastaram quando Bob decidiu gastá-lo.

O esquema do trabalho será o seguinte (Fig. 6.3).

_{FIG. 6.3 Auditor usando uma chave de exibição secreta $v$ Bob define transações de entrada e saída}

Bob diz a Alice seu endereço público $(V, S)$ , e também pede que ela defina o atributo mix_attr como 1 em todas as saídas endereçadas a ele (abaixo, consideraremos como isso pode ser tecnicamente implementado).
Bob dá ao auditor Dan sua chave de visão secreta $v$ .
Alice envia a Bob uma transação usando o esquema CryptoNote usual. Nas saídas endereçadas a Bob, ela define mix_attr = 1.
Dan verifica todas as transações no blockchain e, usando a chave secreta de exibição de Bob, verifica cada saída $P_i \stackrel{?}{=} P’_i = H_s(v R, i) G + S$ (Onde $i$ - número de série da saída, $S$ - Chave de gastos públicos de Bob). Se a igualdade se mantiver, essa saída será endereçada a Bob.
Den garante que mix_attr == 1 adicione esta saída à lista e aumente o saldo pelo valor da saída.
Dan também verifica todas as entradas de todas as transações e, se uma delas se referir ao UTXO de Bob da lista, isso significa que essa transação é o pagamento efetuado por Bob. Devido à restrição mix_attr = 1, a entrada não pode misturar outras saídas, o que significa que gasta a saída de Bob diretamente, e Den pode ter certeza de que este é o pagamento efetuado por Bob. Den reduz o saldo pelo valor do valor de entrada.

Assim, Den poderá calcular o saldo correto da carteira de Bob sem obter acesso à sua chave secreta de gastos

$s$ .

Recursos do circuito

Recurso 1. É importante que a parte remetente (Alice) defina mix_attr como 1 ao enviar uma transação. Se Alice não fizer isso, os fundos serão destinados a Bob, mas no futuro, Den não poderá dizer claramente se Bob os gastou ou não, pois qualquer outro usuário poderá usar essa saída para mixagem.

Uma solução é a introdução de um tipo especial de endereço que contém as mesmas duas chaves públicas

$(V, S)$ mas embalados de uma maneira diferente do padrão. Alice, enviando fundos para um endereço desse tipo, saberá sobre a necessidade de definir mix_attr = 1 para as saídas correspondentes.

Recurso 2. O uso de um tipo especial de endereço não obriga Alice a definir o valor do atributo desejado para as saídas. Ela pode enviar fundos sem fazer isso, no entanto, isso será revelado imediatamente por Bob e pelo auditor Dan.

Recurso 3. Nesse esquema, a capacidade de auditoria é alcançada ao preço da maior redução na impossibilidade de rastreabilidade. Isso não apresenta um problema específico se a oportunidade de auditoria for fornecida a um número ilimitado de pessoas. Por exemplo, um fundo de caridade pode publicar um endereço de doação juntamente com uma chave de visualização secreta, para que qualquer pessoa possa atuar como auditor e calcular o saldo atual de sua carteira. É importante que, neste caso, o anonimato das transferências recebidas permaneça padrão no CryptoNote (um grande número de

$N_{mixins}$ ) No entanto, o anonimato das contas a pagar será limitado pela incapacidade de combinar resultados arbitrários.

Vale a pena notar que, no caso em que a oportunidade de auditoria é oferecida a um círculo estreito de pessoas, em contraste com o exemplo acima, uma diminuição na rastreabilidade pode ser um efeito indesejável.

As grandes vantagens dessa opção são a facilidade de implementação e a ausência de carga adicional nos cálculos e dados.

7. Conclusão

Examinamos três opções para adicionar a possibilidade de realizar uma auditoria ao protocolo CryptoNote: Bytecoin Amethyst, o esquema AS teórico de Anton Sokolov e o uso de mix_attr (indicado por MA).

O redimensionamento relativo da assinatura do anel para todas as opções, exceto Bytecoin (BCN), é independente de

$N_{inputs}$ portanto considere

$N_{inputs} = 1$ (mínimo) e

$N_{inputs} = 3$ (Fig. 7.1).

_{FIG. 7.1 Comparação dos tamanhos da assinatura do anel quando $N_{inputs} = 1$ e $N_{inputs} = 3$ para todas as opções consideradas}

Nota. $N_{inputs}$ - o número de entradas na transação, $N_{mixins}$ - o número de saídas associadas a cada entrada da transação. E se $N_{mixins} > 1$ isso significa que, para aumentar a impossibilidade de rastreabilidade, cada entrada refere-se a mais de uma saída de outra transação e é impossível estabelecer qual é real.

O melhor resultado é mostrado pelo circuito AS, proporcionando uma redução no tamanho da assinatura do anel em uma ampla faixa do número de saídas a serem misturadas (

$N_{mixins}$ ) O Bytecoin também oferece bons resultados quando

$N_{mixins} \ge 3$ (como já observado, um Bytecoin Amethyst introduziu um limite mínimo de número para aumentar a impossibilidade de rastreabilidade

$N_{mixins}$ igual a 3).

O esquema MA não oferece nenhuma melhoria no tamanho da assinatura do anel.

Vamos agora comparar a laboriosidade do procedimento de verificação de assinatura de anel. Para isso, usaremos a métrica mencionada acima, a saber, a soma das operações do produto escalar e o cálculo da função hash

$H_p$ com pesos proporcionais ao tempo de execução em um processador moderno típico:

$O(total) = 130 * O(*) + 15 * O(H_p)$

Temos a seguinte figura (Fig. 7.2).

_{FIG. 7.2 Comparação do aumento da complexidade computacional da verificação de assinatura de anel ( $N_{inputs} = 1$ )}

Com gastos diretos de fundos (

$N_{mixins} = 1$ ) Os esquemas de AS e Bytecoin exigem significativamente mais computação para verificar a assinatura.

Ao misturar saídas (

$N_{mixins} > 1$ ) O esquema de Bytecoin Amethyst parece preferível ao AS, no entanto, a última opção considerada MA permanece insuperável.

Vamos resumir o resultado final, levando em consideração fatores como um aumento no tamanho do endereço, entradas e saídas das transações (Fig. 7.3).

_{FIG. 7.3 Comparação de todos os esquemas considerados}

O Bytecoin mantém conveniente o tamanho do endereço para o usuário final, enquanto o esquema Anton Sokolov aumenta em 50%. Isso não afeta diretamente o tamanho do blockchain (embora o endereço do remetente na forma criptografada possa ser transmitido em transações extras, se o último desejar, por exemplo) e a complexidade computacional, no entanto, não afeta significativamente a usabilidade. No esquema MA, o tamanho do endereço permanece igual a 64 bytes; no entanto, é necessária uma maneira de distinguir os endereços de auditoria dos normais.

As opções de auditoria para o Bytecoin e o AS incluem adicionar um ponto (32 bytes) a cada saída da transação; no entanto, o tamanho da entrada permanece inalterado apenas para o Bytecoin.

Também é importante notar que o esquema de Bytecoin Amethyst foi implementado no código por um longo tempo e, a julgar pela falta de mensagens sobre problemas que passaram desde sua implementação, ele é bem testado na prática. No entanto, não foi possível encontrar sua descrição pública de forma estrita; portanto, não há provas formais de sua correção.

O esquema AS, pelo contrário, é estritamente descrito e proposto para discussão na comunidade criptográfica [ 17 ].

O esquema MA não possui uma prova formal estritamente descrita; no entanto, devido à sua extrema simplicidade, parece desnecessário.

Carteiras de auditoria no CryptoNote

Conteúdo

1.

CryptoNote?

O conceito de auditoria e sua aplicação

Sobre o autor e o objetivo da publicação

2. Informações básicas sobre criptografia em curvas elípticas

3. CryptoNote

4. Opção 1/3. Moedas auditáveis do Bytecoin

4.1 tx.version <ametista, endereço herdado

4.2 tx.version ≥ ametista

4.3 tx.version ≥ ametista, endereço herdado

4.4 tx.version ≥ ametista, endereço de ametista

H constante

Vários endereços não vinculáveis

Formação de saídas ao enviar fundos

Contabilização de pagamentos recebidos

Formação de contas a pagar

Divulgação do Endereço do Destinatário de Auditoria

4.5 Comparando assinaturas de transação CryptoNote e Bytecoin Amethyst

Estruturas de dados e tamanhos de assinatura

A complexidade da verificação de assinatura

5. Opção 2/3. Estudos de auditoria na CryptoNote por Anton Sokolov

Formação de Saída

Reconhecimento de pagamentos recebidos e formação de insumos

Auditar

Assinatura de anel

Comparação com o CryptoNote por dados e carga computacional

6. Opção 3/3. Auditoria através do limite de mixagem de saída

Atributo de saída Mix_attr

Auditoria com mix_attr = 1

Recursos do circuito

7. Conclusão

Literatura

More articles:

Carteiras de auditoria no CryptoNote

Conteúdo

1.

CryptoNote?

O conceito de auditoria e sua aplicação

Sobre o autor e o objetivo da publicação

2. Informações básicas sobre criptografia em curvas elípticas

3. CryptoNote

4. Opção 1/3. Moedas auditáveis ​​do Bytecoin

4.1 tx.version <ametista, endereço herdado

4.2 tx.version ≥ ametista

4.3 tx.version ≥ ametista, endereço herdado

4.4 tx.version ≥ ametista, endereço de ametista

H constante

Vários endereços não vinculáveis

Formação de saídas ao enviar fundos

Contabilização de pagamentos recebidos

Formação de contas a pagar

Divulgação do Endereço do Destinatário de Auditoria

4.5 Comparando assinaturas de transação CryptoNote e Bytecoin Amethyst

Estruturas de dados e tamanhos de assinatura

A complexidade da verificação de assinatura

5. Opção 2/3. Estudos de auditoria na CryptoNote por Anton Sokolov

Formação de Saída

Reconhecimento de pagamentos recebidos e formação de insumos

Auditar

Assinatura de anel

Comparação com o CryptoNote por dados e carga computacional

6. Opção 3/3. Auditoria através do limite de mixagem de saída

Atributo de saída Mix_attr

Auditoria com mix_attr = 1

Recursos do circuito

7. Conclusão

Literatura

More articles:

4. Opção 1/3. Moedas auditáveis do Bytecoin