Controllo degli Accessi su Secret Network: Viewing Keys vs Permits
Secret Network porta la privacy nativa negli smart contract. Con le Chiavi di Visualizzazione e Permessi (Viewing Keys e Permits), agli utenti vengono fornite capacità di controllo sull’accesso a dati, risorse ed NFT. Qual’è la differenza tra le due?
Consentendo agli sviluppatori di creare applicazioni per la tutela della privacy e agli utenti di assumere il controllo dei propri dati, Secret Network può offrire ciò che nessuna blockchain pubblica per impostazione predefinita può: il controllo dell’accesso nativo.
Attualmente, ci sono due implementazioni di progettazione tecnica per ottenere il controllo degli accessi: chiavi di visualizzazione e permessi di query. Analizzeremo queste specifiche più da vicino e come le due differiscono l’una dall’altra.
Chiavi di visualizzazione: i problemi che risolvono e creano
Secret Network crittografa i dati dell’utente per impostazione predefinita. Quando un utente converte risorse pubbliche come ETH, BNB e SCRT nel loro equivalente privato (sETH, sBNB, sSCRT), i metadati, come i saldi, vengono nascosti a tutti gli utenti della rete, incluso l’utente che possiede queste risorse. Pertanto, nonostante l’ulteriore vantaggio sulla sicurezza, la crittografia crea un problema con l’utente.
In che modo infatti, i nostri utenti dovrebbero interagire con le applicazioni sulla rete se non possono vedere la quantità dei token nei loro wallet?
I token segreti (noti anche come token conformi a SNIP) sono basati sugli standard esistenti dell’ecosistema Cosmos. Pertanto, l’identità di un richiedente (qualcuno che richiede dati) non può essere autenticata crittograficamente. In altre parole, senza un meccanismo per verificare l’identità di un utente, le informazioni di base sull’utente non possono essere decifrate. Per risolvere questo problema, le chiavi di visualizzazione sono state implementate come parte della specifica SNIP-20.
Osservando il diagramma qui sopra, possiamo vedere il tipico caso d’uso di una chiave di visualizzazione.
1. Alice non può vedere il suo saldo, quindi crea una chiave di visualizzazione (password) per un particolare token SNIP.
2. Lo smart contract responsabile della gestione del token SNIP salva Alice e la sua password nello stato del contratto.
3. In un altro momento, chiunque, come Bob, può richiedere di vedere il saldo di Alice. Se a Bob è stato concesso il permesso di utilizzare la chiave di visualizzazione di Alice, gli verrà fornito correttamente il saldo del suo account dallo smart contract.
Le chiavi di visualizzazione agiscono come password crittografate. Consentendo agli utenti di creare e condividere queste password con applicazioni di terze parti, la visualizzazione delle chiavi evidenzia la qualità del controllo sugli accessi fornito agli utenti su Secret Network. Alice è la proprietaria delle sue chiavi di visualizzazione e, senza di esse, gli altri non possono accedere ai suoi dati sensibili.
Sfortunatamente, le chiavi di visualizzazione contribuiscono a creare un attrito significativo per quanto riguarda l’esperienza utente complessiva sulla rete ed inoltre sono responsabili dell’emergere di problemi tecnici durante i periodi di traffico elevato. Quindi, i dati cruciali dell’account nascosti agli utenti senza chiavi di visualizzazione sono una funzionalità che nel migliore dei casi crea temporaneamente confusione per i nuovi utenti e, nel peggiore dei casi, funge da deterrente all’adozione della rete.
Poiché le chiavi di visualizzazione sono archiviate nello stato di uno smart contract, gli utenti devono inviare una transazione e pagare una piccola commissione per coprire il costo del gas al fine di creare queste password crittografate. Pertanto, quando si utilizzano le chiavi di visualizzazione, è previsto un piccolo costo iniziale per i nuovi utenti che potrebbero voler semplicemente visualizzare il saldo del proprio account. Nel caso di asset pubblici portati tramite bridge, come BNB (Binance Coin), questo problema di esperienza utente (UX) è amplificato dal fatto che è probabile che i nuovi utenti non abbiano SCRT per cui non possono coprire il costo del gas. Senza SCRT per pagare il gas, una transazione non può mai essere inviata, non è possibile creare una chiave di visualizzazione ed in definitiva, l’utente non può visualizzare il proprio saldo sBNB privato appena trasferito.
Inoltre, in tempi di traffico intenso, la creazione in rapida successione di molte chiavi di visualizzazione a volte non necessarie ha dimostrato di mettere a dura prova la rete. Ad esempio, la prima raccolta privata di NFT su Secret Network, Anons, ha generato un utilizzo importante della rete. Gli utenti, timorosi di perdere il conio pubblico, sono corsi sul sito web degli Anons per accaparrarsi i loro NFT. Il processo di conio degli Anons ha guidato gli utenti lungo un percorso che richiedeva la creazione di chiavi di visualizzazione prima del conio. A causa della natura del conio degli NFT in cui il tempo è breve mentre i token scarseggiano, un mucchio di utenti ha interagito con lo smart contract degli Anons per creare chiavi di visualizzazione, ed è così che è stata generata una marea di transazioni, che a sua volta ha portato all’arresto della rete e ad un lancio ritardato del conio (minting).
Quando la rete è intasata di richieste, i nodi iniziano a perdere la sincronizzazione e le transazioni iniziano a non riuscire. È probabile che gli utenti che ricevono richieste non riuscite rispondano inviando più richieste solo per esacerbare il problema. Pertanto, per risolvere queste sfide tecniche e di UX, è stato implementato un nuovo metodo per interrogare i dati degli utenti privati.
Per riassumere, le principali sfide associate alle Chiavi di Visualizzazione sono:
1. Le chiavi di visualizzazione richiedono ai nuovi utenti di pagare una tariffa anticipata una tantum per le informazioni di base sull’account come saldi, cronologia delle transazioni e così via.
2. In tempi di traffico elevato, l’interfaccia utente (UI)/esperienza utente (UX) costruita attorno alle chiavi di visualizzazione può portare alla creazione di molte transazioni non necessarie che possono ridurre le prestazioni dei nodi, causando problemi a cascata per la rete.
Query permits: il metodo di interrogazione alternativo
I permessi di query sono stati introdotti nella specifica di progettazione SNIP-24. La documentazione descrive i permessi come un metodo di interrogazione superiore rispetto alle chiavi di visualizzazione. Considerando l’esempio precedente di Alice e di un utente che vuole controllare il saldo del suo account privato, possiamo capire meglio come funzionano i permessi e perché rappresentano un drastico miglioramento per gli utenti su Secret Network.
I permessi di query utilizzano una tecnica crittografica nota come crittografia a chiave pubblica associata a firme digitali. Un permesso è un messaggio formattato. Delinea diversi argomenti come a quali token si applica il permesso e quali autorizzazioni dovrebbe consentire il permesso (ad esempio, se il permesso consente all’interrogante di visualizzare la cronologia delle transazioni, il saldo di un utente, ecc.). Questo messaggio è firmato da Alice utilizzando la chiave privata del suo account. Quando Alice invia una domanda, invia il suo permesso firmato come argomento per uno smart contract. Una volta ricevuto, lo smart contract, utilizzando la chiave pubblica di Alice, può convalidare la sua identità in base alla firma che ha fornito. Se l’identità di Alice viene confermata, lo smart contract restituisce i suoi dati come richiesto.
Nota che, a differenza delle chiavi di visualizzazione, lo smart contract non cambia mai il suo stato per salvare l’identità di Alice. Pertanto, non vi è alcuna transazione associata all’utilizzo dei permessi di query e non vi è alcun costo per la richiesta di informazioni utente di base. Questo è un importante miglioramento della UX per gli utenti finali. Inoltre, poiché non esiste alcuna transazione associata ai permessi di query, non vi è alcun rischio che i permessi ostacolino le prestazioni della rete durante i periodi di traffico elevato.
Sebbene però i permessi migliorino significativamente l’esperienza dell’utente, hanno un compromesso. I permessi di query sono più affamati di risorse sui nodi che eseguono la rete. Poiché l’identità di un utente non viene mai salvata, un permesso deve sempre essere convalidato con ogni richiesta di query. Questo processo è più costoso in termini di potenza di calcolo rispetto alle chiavi di visualizzazione, che richiedono solo un controllo di base rispetto ai dati archiviati nello stato di uno smart contract. Tuttavia, il miglioramento generale dell’esperienza utente e della stabilità della rete vale la pressione aggiuntiva esercitata sui nodi per convalidare questi permessi.
Progettare per l’esperienza dell’utente (UX)
A causa della novità dei permessi di query, le applicazioni decentralizzate basate su Secret Network li hanno utilizzati con vari gradi di successo. Se utilizzati in modo improprio, i permessi possono creare UX più critiche rispetto alle chiavi di visualizzazione, quindi è fondamentale che gli sviluppatori considerino l’impatto che i permessi di query hanno sulla progettazione dell’interfaccia e dell’esperienza utente. Questa sezione mira a fornire una breve serie di consigli che gli sviluppatori devono seguire quando utilizzano i permessi di query.
I permessi di query dovrebbero essere archiviati
I permessi sono messaggi effimeri che devono essere passati a uno smart contract ogni volta che viene effettuata una query. Imporre ad un utente a rigenerare un permesso ad ogni query è probabilmente un’esperienza utente peggiore rispetto al pagamento di una tariffa una tantum per creare una chiave di visualizzazione. Pertanto, dopo la creazione di un permesso, dovrebbe essere salvato nel browser (ad es. in localStorage), in modo che possa essere riutilizzato in seguito. Se i permessi vengono salvati, gli sviluppatori possono fornire un’esperienza senza interruzioni agli utenti inviando query future senza che l’utente finale si accorga che è stata effettuata una richiesta.
I permessi archiviati devono essere utilizzati per sempre o fino a quando non vengono revocati.
Per ribadire, non è necessario ricreare un permesso una volta che è stato generato. Fornire agli utenti un modo semplice per revocare i permessi dovrebbe essere integrato nell’interfaccia utente di un’applicazione. I permessi possono essere revocati inviando un messaggio di revoca il cui unico parametro è il nome del permesso da revocare.
I permessi di query possono essere applicati a più token segreti
Anziché costringere un utente a creare un nuovo permesso per ogni token segreto che l’applicazione può utilizzare, è meglio consentire l’utilizzo di più token con lo stesso permesso. È possibile specificare più token nell’allowed_tokens arrey del messaggio di autorizzazione. Gli sviluppatori dovrebbero considerare il dominio della loro applicazione e consentire di conseguenza più token.
Seguendo queste semplici linee guida per i permessi di query, gli sviluppatori possono fornire un’esperienza utente decisamente migliore per le loro applicazioni su Secret Network. Per maggiori dettagli sui permessi e sulla loro implementazione, dai un’occhiata alla documentazione SNIP-24 trovata sul GitHub della Secret Foundation.
Conclusione
Secret Network è una soluzione blockchain layer 1 che combina la resilienza della privacy e la rivoluzione degli smart contract scalabili. Le soluzioni di sicurezza spesso vanno a scapito dell’esperienza dell’utente. Gli sviluppatori di Secret Network prendono una posizione attiva nell’alleggerire i nuovi utenti in modo che tutti possano accedere facilmente alla finanza decentralizzata privata. Le chiavi di visualizzazione sono state la prima implementazione del controllo sugli accessi per gli utenti finali, ma hanno comportato un costo, sia per l’esperienza utente che per la stabilità della rete. I permessi di query sono un miglioramento dei token di Secret Network che preservano la privacy. Man mano che gli sviluppatori creano nuove applicazioni e ristrutturano gli strumenti esistenti in base a questo nuovo standard, gli utenti finali saranno in grado di esplorare l’ecosistema con la stessa facilità con cui farebbero su una chain pubblica per impostazione predefinita.
