Dusk questo tipo di catena che deve accettare beni regolamentati, l'account non è "può essere utilizzato solo se ha un indirizzo". Deve poter esprimere una serie di vincoli reali: chi può possedere, chi può scambiare, chi può solo guardare senza muoversi, chi può avviare il trasferimento di un certo tipo di bene. Molti progetti lasciano queste cose all'interfaccia frontend o a un backend centralizzato, limitandosi a gestire i trasferimenti sulla catena, il che può sembrare conveniente nel breve termine, ma una volta che si presenta un contenzioso o un audit, non puoi dimostrare "perché il sistema ha consentito quella transazione".
Comprendo che i permessi dell'account di Dusk dovrebbero essere uno stato verificabile sulla catena, non una promessa verbale. In altre parole, i permessi di un account non sono una descrizione testuale, ma un insieme di condizioni che possono essere lette direttamente da contratti e logiche di verifica: categoria dell'account, se ha superato una certa certificazione, se è soggetto a un periodo di restrizione, se ha attivato un congelamento temporaneo. Poi ogni volta che c'è un trasferimento di stato degli asset, si devono verificare queste condizioni, e solo se soddisfatte si procede, altrimenti si rifiuta. Il rifiuto deve anche poter essere spiegato chiaramente, almeno deve essere possibile risalire a quale condizione di permesso lo ha bloccato, altrimenti il team di conformità non può lavorare e gli utenti non faranno altro che lamentarsi del sistema in modo incomprensibile.
Qui i punti più facili per incorrere in problemi, a mio avviso, sono due. Il primo è l'aggiornamento dei permessi. Nella realtà, lo stato dell'identità cambia: certificazione scaduta, livello di identità regolato, aggiornamento della lista delle sanzioni, valutazione del rischio che attiva restrizioni temporanee. Se i permessi vengono aggiornati in modo troppo arbitrario, diventa "chi ha la chiave decide"; se l'aggiornamento è troppo rigido, porta a non poter gestire eventi di conformità. Se Dusk vuole diventare un sistema capace, deve rendere gli aggiornamenti dei permessi, dei processi e delle registrazioni eventi sulla catena tracciabili, almeno per far comprendere agli auditor perché a un certo punto un account ha ricevuto o perso una certa capacità.
Il secondo punto è il coupling tra permessi e regole degli asset. I permessi dell'account non esistono in modo isolato, devono essere utilizzati in combinazione con le condizioni limitative specifiche degli asset, ad esempio un certo asset richiede che solo un certo tipo di account possa possederlo, o un certo tipo di account possa scambiare solo in finestre specifiche. Se progettato in modo inadeguato, gli sviluppatori si troveranno a ripetere la scrittura delle verifiche dei permessi per ogni asset, finendo per trasformare tutto in implementazioni frammentate, con un costo di audit che esplode direttamente.
