Esta semana eu basicamente repliquei toda a parte de XSC do "Dusk Yellow Book" até não sobrar nada. No começo eu também achei, como a maioria, que XSC (Confidential Security Contract) era só "colocar uma proteção de privacidade ZK em cima do ERC-20" — esconde o saldo, esconde as transferências e pronto. Mas quando eu sigo o ciclo de vida do contrato de verdade, vejo que não é nada disso. XSC embute no storage do token coisas que normalmente ficariam sob controle de cartório/advogado e de planilhas — credenciais de KYC, execução forçada de whitelist, período de lock, direitos de distribuição — e na hora do transferir a validação acontece dentro do circuito: se o endereço não passar pela camada de identidade da Citadel, dá revert. E mesmo que o backend do projeto quebre, isso não afeta a decisão de conformidade.
Eu só entendi a diferença depois de testar um trechinho de pseudocódigo na testnet: em ERC-20, o transfer só verifica balance; em ERC-1400, a whitelist é checada num modifier, mas a whitelist geralmente fica num banco de dados do próprio projeto; em XSC, o modelo de conta da Zedger transforma "quem detém moedas passou no KYC" em uma declaração verificável por ZK, e isso fica gravado no estado do contrato. Conformidade não é um rótulo colado do lado de fora do token; é um gene que vem junto quando o token nasce.
O mais contraintuitivo é que privacidade e auditoria, aparentemente, não brigam — valores e posições ficam escondidos com provas de zero conhecimento, mas a fiscalização consegue usar a view key para divulgar de forma seletiva quanto um endereço específico tem, se está dentro da whitelist autorizada e se já passou do período de lock. Isso é mais sofisticado do que misturadores e também mais sólido do que simplesmente gritar "compliance de securities" usando ERC-1400.
Agora há pouco eu fui à Binance e comprei um pouco de DUSK à vista usando 15U para completar uma tarefa (depois de descontar taxas, não pode sobrar 10U certinho, senão falha), e aproveitei para embutir o cartão de trading; perder 0,3U também foi PNL real, diferente de ficar falando "vai decolar" e depois levar corte de original por um CreatorPad. Vocês acham que essa ideia de "colocar KYC dentro do token" do XSC é uma verdadeira quebra em conformidade, ou é algo que instituições evitam por causa de um backdoor regulatório?
@Dusk_Foundation $DUSK #dusk
Eu só entendi a diferença depois de testar um trechinho de pseudocódigo na testnet: em ERC-20, o transfer só verifica balance; em ERC-1400, a whitelist é checada num modifier, mas a whitelist geralmente fica num banco de dados do próprio projeto; em XSC, o modelo de conta da Zedger transforma "quem detém moedas passou no KYC" em uma declaração verificável por ZK, e isso fica gravado no estado do contrato. Conformidade não é um rótulo colado do lado de fora do token; é um gene que vem junto quando o token nasce.
O mais contraintuitivo é que privacidade e auditoria, aparentemente, não brigam — valores e posições ficam escondidos com provas de zero conhecimento, mas a fiscalização consegue usar a view key para divulgar de forma seletiva quanto um endereço específico tem, se está dentro da whitelist autorizada e se já passou do período de lock. Isso é mais sofisticado do que misturadores e também mais sólido do que simplesmente gritar "compliance de securities" usando ERC-1400.
Agora há pouco eu fui à Binance e comprei um pouco de DUSK à vista usando 15U para completar uma tarefa (depois de descontar taxas, não pode sobrar 10U certinho, senão falha), e aproveitei para embutir o cartão de trading; perder 0,3U também foi PNL real, diferente de ficar falando "vai decolar" e depois levar corte de original por um CreatorPad. Vocês acham que essa ideia de "colocar KYC dentro do token" do XSC é uma verdadeira quebra em conformidade, ou é algo que instituições evitam por causa de um backdoor regulatório?
@Dusk_Foundation $DUSK #dusk