Fiquei a noite inteira discutindo com alguém: “cadeia de privacidade pode passar na regulação?”; esta manhã, ao revisar o código, descobri que o Dusk já tinha colocado a resposta.
Bom papo, hein — o BTC está subindo muito!
Ontem à noite, conversei até a 2h com um amigo que trabalha com conformidade. Ele bateu o pé numa coisa: “combinar ZK com UTXO deixa as auditorias praticamente impossíveis de fazer o trabalho; a regulamentação não vai aceitar.” Na hora, usei a divulgação seletiva do Phoenix para rebater. Ele simplesmente mandou: “dá para exportar o código para o Excel com um clique?” e desligou.
Fiquei engasgado com essa frase por um tempo.
Mas de manhã, ao consultar a documentação, vi um detalhe que antes eu não tinha dado tanta atenção: o mecanismo de View Key do Phoenix — a chave é separada em duas: uma para visualização e outra para gastar. A primeira pode ser entregue a um terceiro para ele escanear e identificar transações que pertencem a você; a segunda fica para sempre com você. O que isso significa? A parte de auditoria pode obter a View Key para verificar se você fez alguma operação em desacordo, se houve transferência acima do limite, etc., mas não consegue tirar um centavo do seu dinheiro. A “verificabilidade” que a conformidade exige e a “inalcançabilidade” que a segurança dos ativos requeridas são resolvidas com a separação de uma única chave.
O “exportar para o Excel com um clique” que meu amigo mencionou é, sim, uma necessidade real — a regulação não discute seus ideais criptográficos; o que eles querem é algo que possa ser impresso e arquivado. O interessante nessa arquitetura do Phoenix é que ela não trata “privacidade” e “auditabilidade” como opostos. Ela usa a View Key como uma ponte no meio: o que precisa ser visto, você deixa; o que não deve ser tomado, ninguém leva. Vale também mencionar o mecanismo de Nullifier — em vez de expor diretamente qual note foi gasta, cada transação privada publica um identificador único de destruição. A auditoria pode validar que “esta transação de fato aconteceu e não houve gasto duplo”, mas não consegue saber quem transferiu quanto para quem.
Claro, essa conta não pode ser levada longe demais: depois de delegar a View Key, o terceiro consegue ver seus registros de recebimento — isso, por si só, é um custo de confiança. Para quem mostrar, como guardar depois e se haverá vazamento, o protocolo não controla.
Mas pelo menos a direção está certa: privacidade não precisa necessariamente ficar de cara com a regulação. A questão nunca foi “dá ou não para estar em conformidade”, e sim “qual é o custo de estar em conformidade”. A resposta que o Phoenix dá é: o custo pode ser uma chave somente leitura — e não o “fazer sua conta ficar nua”.
@Dusk $DUSK #dusk
Bom papo, hein — o BTC está subindo muito!
Ontem à noite, conversei até a 2h com um amigo que trabalha com conformidade. Ele bateu o pé numa coisa: “combinar ZK com UTXO deixa as auditorias praticamente impossíveis de fazer o trabalho; a regulamentação não vai aceitar.” Na hora, usei a divulgação seletiva do Phoenix para rebater. Ele simplesmente mandou: “dá para exportar o código para o Excel com um clique?” e desligou.
Fiquei engasgado com essa frase por um tempo.
Mas de manhã, ao consultar a documentação, vi um detalhe que antes eu não tinha dado tanta atenção: o mecanismo de View Key do Phoenix — a chave é separada em duas: uma para visualização e outra para gastar. A primeira pode ser entregue a um terceiro para ele escanear e identificar transações que pertencem a você; a segunda fica para sempre com você. O que isso significa? A parte de auditoria pode obter a View Key para verificar se você fez alguma operação em desacordo, se houve transferência acima do limite, etc., mas não consegue tirar um centavo do seu dinheiro. A “verificabilidade” que a conformidade exige e a “inalcançabilidade” que a segurança dos ativos requeridas são resolvidas com a separação de uma única chave.
O “exportar para o Excel com um clique” que meu amigo mencionou é, sim, uma necessidade real — a regulação não discute seus ideais criptográficos; o que eles querem é algo que possa ser impresso e arquivado. O interessante nessa arquitetura do Phoenix é que ela não trata “privacidade” e “auditabilidade” como opostos. Ela usa a View Key como uma ponte no meio: o que precisa ser visto, você deixa; o que não deve ser tomado, ninguém leva. Vale também mencionar o mecanismo de Nullifier — em vez de expor diretamente qual note foi gasta, cada transação privada publica um identificador único de destruição. A auditoria pode validar que “esta transação de fato aconteceu e não houve gasto duplo”, mas não consegue saber quem transferiu quanto para quem.
Claro, essa conta não pode ser levada longe demais: depois de delegar a View Key, o terceiro consegue ver seus registros de recebimento — isso, por si só, é um custo de confiança. Para quem mostrar, como guardar depois e se haverá vazamento, o protocolo não controla.
Mas pelo menos a direção está certa: privacidade não precisa necessariamente ficar de cara com a regulação. A questão nunca foi “dá ou não para estar em conformidade”, e sim “qual é o custo de estar em conformidade”. A resposta que o Phoenix dá é: o custo pode ser uma chave somente leitura — e não o “fazer sua conta ficar nua”.
@Dusk $DUSK #dusk