Tenho trabalhado aos poucos em whitepapers mais antigos de blockchain ultimamente, principalmente por curiosidade sobre como diferentes projetos realmente tratam a regulação em vez de apenas evitá-la. A Dusk Network foi a que me fez pausar.
O que se destacou não foi a criptografia — que já é bem padrão nesse espaço —, mas um modelo de transações chamado Zedger, construído especificamente em torno do direito societário. Ele exige participantes previamente autorizados (whitelist), obriga os destinatários a aprovarem explicitamente as transferências recebidas e permite que um operador nomeado reconstrua um registro completo de propriedade em qualquer momento. Essa última parte é basicamente um requisito de auditoria, escrito diretamente no protocolo. É uma das poucas vezes que já vi um whitepaper propor um design voltado para conformidade, em vez de tratá-la como algo para contornar depois.
Ainda assim, não acho que uma especificação bem escrita resolva muita coisa sozinha. Uma whitelist só é tão confiável quanto quem a opera, e um contrato inteligente pode impor uma regra, mas não consegue decidir quem realmente está em conformidade com a lei. Essa decisão ainda pertence a uma pessoa ou instituição. Além disso, whitepapers são escritos anos antes de qualquer coisa real ser usada, e o intervalo entre um bom design e um sistema regulamentado em funcionamento geralmente é maior do que parece no papel.
Nada disso torna a ideia menos interessante — apenas menos finalizada do que ela parece ao ser lida. É um bom lembrete para ler devagar, perguntar o que de fato é exigido versus o que apenas foi projetado, e não aceitar a palavra de nenhum sistema. Pequenos hábitos como esse se somam — um pouco mais de entendimento a cada coisa que eu me sento para ler de verdade.
@Dusk_Foundation #dusk $DUSK
O que se destacou não foi a criptografia — que já é bem padrão nesse espaço —, mas um modelo de transações chamado Zedger, construído especificamente em torno do direito societário. Ele exige participantes previamente autorizados (whitelist), obriga os destinatários a aprovarem explicitamente as transferências recebidas e permite que um operador nomeado reconstrua um registro completo de propriedade em qualquer momento. Essa última parte é basicamente um requisito de auditoria, escrito diretamente no protocolo. É uma das poucas vezes que já vi um whitepaper propor um design voltado para conformidade, em vez de tratá-la como algo para contornar depois.
Ainda assim, não acho que uma especificação bem escrita resolva muita coisa sozinha. Uma whitelist só é tão confiável quanto quem a opera, e um contrato inteligente pode impor uma regra, mas não consegue decidir quem realmente está em conformidade com a lei. Essa decisão ainda pertence a uma pessoa ou instituição. Além disso, whitepapers são escritos anos antes de qualquer coisa real ser usada, e o intervalo entre um bom design e um sistema regulamentado em funcionamento geralmente é maior do que parece no papel.
Nada disso torna a ideia menos interessante — apenas menos finalizada do que ela parece ao ser lida. É um bom lembrete para ler devagar, perguntar o que de fato é exigido versus o que apenas foi projetado, e não aceitar a palavra de nenhum sistema. Pequenos hábitos como esse se somam — um pouco mais de entendimento a cada coisa que eu me sento para ler de verdade.
@Dusk_Foundation #dusk $DUSK