As senhas de retirada em pontos de encomendas nunca são as mesmas. Mesmo sendo ainda o mesmo destinatário, o sistema não te avisa: "estas duas retiradas foram feitas pela mesma pessoa".
Recentemente ajudei um vizinho a retirar uma encomenda e percebi que o sistema do quiosque tem algo interessante: uma mesma pessoa retirando duas vezes, com códigos de retirada totalmente diferentes. A atendente ao escanear só consegue ver "de quem é esta retirada"; não dá para saber se essa pessoa já veio antes.
Depois, ao consultar o modelo de transações Phoenix do Dusk, entendi: essa lógica de "a cada vez troca-se por um código novo, e os de fora não conseguem ligar as informações" também está sendo usada on-chain — e de forma ainda mais extrema.
No Phoenix, a cada transação, a parte que recebe o pagamento não recebe um endereço fixo, mas sim uma "note public key" única (vou chamar de npk). O remetente usa a chave pública de longo prazo do destinatário, somada a um número aleatório, para calcular essa npk única. O destinatário, usando a sua view key, faz a verificação uma a uma; se consegue calcular a npk, então fica claro que aquela transação foi enviada para ele.
O ponto-chave é: — essa npk nunca é a mesma. Mesmo que a mesma pessoa receba dez pagamentos, se um estranho varrer os dados na cadeia, não conseguirá ver se essas dez transações foram para o mesmo recebedor, porque não existe um endereço fixo que se repita e permita fazer a correspondência.
Essa arquitetura existe para resolver a "unlinkability" (inalocabilidade/ não relacionabilidade) — ela não protege apenas contra o fato de "ter sido visto que você recebeu dinheiro"; protege contra o fato de que essa relação de "essas dez transações de dinheiro são para a mesma pessoa" seja construída a partir dos dados. Além disso, ela também suporta delegação: o usuário pode entregar a view key separadamente a um terceiro, para que a outra parte ajude a identificar quais transações são suas, mas sem obter permissão para gastar. A divisão de responsabilidades é bem detalhada.
Endereços descartáveis parecem seguros, mas também significam que a quantidade de cálculo para detectar cada transação é maior do que no modelo de endereços fixos; depois que o volume cresce, se a eficiência de varredura aguenta, depende dos dados reais.
$DUSK
#dusk @Dusk
Recentemente ajudei um vizinho a retirar uma encomenda e percebi que o sistema do quiosque tem algo interessante: uma mesma pessoa retirando duas vezes, com códigos de retirada totalmente diferentes. A atendente ao escanear só consegue ver "de quem é esta retirada"; não dá para saber se essa pessoa já veio antes.
Depois, ao consultar o modelo de transações Phoenix do Dusk, entendi: essa lógica de "a cada vez troca-se por um código novo, e os de fora não conseguem ligar as informações" também está sendo usada on-chain — e de forma ainda mais extrema.
No Phoenix, a cada transação, a parte que recebe o pagamento não recebe um endereço fixo, mas sim uma "note public key" única (vou chamar de npk). O remetente usa a chave pública de longo prazo do destinatário, somada a um número aleatório, para calcular essa npk única. O destinatário, usando a sua view key, faz a verificação uma a uma; se consegue calcular a npk, então fica claro que aquela transação foi enviada para ele.
O ponto-chave é: — essa npk nunca é a mesma. Mesmo que a mesma pessoa receba dez pagamentos, se um estranho varrer os dados na cadeia, não conseguirá ver se essas dez transações foram para o mesmo recebedor, porque não existe um endereço fixo que se repita e permita fazer a correspondência.
Essa arquitetura existe para resolver a "unlinkability" (inalocabilidade/ não relacionabilidade) — ela não protege apenas contra o fato de "ter sido visto que você recebeu dinheiro"; protege contra o fato de que essa relação de "essas dez transações de dinheiro são para a mesma pessoa" seja construída a partir dos dados. Além disso, ela também suporta delegação: o usuário pode entregar a view key separadamente a um terceiro, para que a outra parte ajude a identificar quais transações são suas, mas sem obter permissão para gastar. A divisão de responsabilidades é bem detalhada.
Endereços descartáveis parecem seguros, mas também significam que a quantidade de cálculo para detectar cada transação é maior do que no modelo de endereços fixos; depois que o volume cresce, se a eficiência de varredura aguenta, depende dos dados reais.
$DUSK
#dusk @Dusk
