Há pouco tempo, voltei à minha cidade natal e vi minha mãe arrumando coisas: guardou o caderno de poupança numa gaveta trancada, as contas ficaram no fundo da caixa, mas fotos antigas estavam espalhadas, sem cerimônia, sobre a mesa. Ela não entende nada de criptografia, mas sobre a questão de “quem deve ver o quê”, ela sabe controlar melhor do que qualquer um. Foi só naquele momento que percebi: a privacidade que a maioria das pessoas realmente quer talvez não seja se esconder, e sim separar níveis.
Depois, ao encontrar <c>@Dusk </c>, percebi que ela condensou esse sentido em uma palavra: privacidade programável. Pela explicação do white paper, privacidade não é uma escolha entre “tudo público” e “tudo anônimo”; é um botão que dá para ajustar conforme o cenário.
<i>$DUSK </i> o que ela pretende fazer pode, em linhas gerais, ser dividido em algumas partes. Algumas transações não precisam ser divulgadas; então ficam escondidas. Mas há lugares em que ser mais transparente aumenta a confiança e facilita a colaboração; então tornam-se públicas. O mais importante é deixar uma chave para quem audita e para o regulador — porém só para ver o que deve ser verificado, sem precisar entregar o livro inteiro. E tem mais um ponto que costuma ser ignorado: transações financeiras não podem depender apenas de privacidade; a liquidação precisa ser decidida em questão de segundos, não pode ficar pendente para sempre.
Em resumo, <i>#dusk </i> é como dar uma fechadura diferente para cada ativo, cada papel e cada jurisdição, em vez de uma única fechadura trancar “toda a casa”, ou simplesmente não trancar a porta. E esse sistema de níveis não depende da consciência das pessoas: ele está escrito no protocolo e executa automaticamente por meio de código. Para quem mostrar e até quanto permitir ver — isso já fica definido de antemão.
Eu gosto bastante desse rumo. Ele puxa a privacidade das confusões de algo “indigno de luz” e a transforma numa capacidade básica controlável. Mas quanto mais flexível a privacidade, mais complexa fica a engenharia das regras. Se o regulador vai ou não aceitar essa lógica é, na verdade, o verdadeiro obstáculo. Sobre essa moeda, DUSK — não acredite apenas no que eu estou dizendo; faça seus próprios estudos.</i>
Depois, ao encontrar <c>@Dusk </c>, percebi que ela condensou esse sentido em uma palavra: privacidade programável. Pela explicação do white paper, privacidade não é uma escolha entre “tudo público” e “tudo anônimo”; é um botão que dá para ajustar conforme o cenário.
<i>$DUSK </i> o que ela pretende fazer pode, em linhas gerais, ser dividido em algumas partes. Algumas transações não precisam ser divulgadas; então ficam escondidas. Mas há lugares em que ser mais transparente aumenta a confiança e facilita a colaboração; então tornam-se públicas. O mais importante é deixar uma chave para quem audita e para o regulador — porém só para ver o que deve ser verificado, sem precisar entregar o livro inteiro. E tem mais um ponto que costuma ser ignorado: transações financeiras não podem depender apenas de privacidade; a liquidação precisa ser decidida em questão de segundos, não pode ficar pendente para sempre.
Em resumo, <i>#dusk </i> é como dar uma fechadura diferente para cada ativo, cada papel e cada jurisdição, em vez de uma única fechadura trancar “toda a casa”, ou simplesmente não trancar a porta. E esse sistema de níveis não depende da consciência das pessoas: ele está escrito no protocolo e executa automaticamente por meio de código. Para quem mostrar e até quanto permitir ver — isso já fica definido de antemão.
Eu gosto bastante desse rumo. Ele puxa a privacidade das confusões de algo “indigno de luz” e a transforma numa capacidade básica controlável. Mas quanto mais flexível a privacidade, mais complexa fica a engenharia das regras. Se o regulador vai ou não aceitar essa lógica é, na verdade, o verdadeiro obstáculo. Sobre essa moeda, DUSK — não acredite apenas no que eu estou dizendo; faça seus próprios estudos.</i>