Questo è un editoriale di opinione di Shinobi, un educatore autodidatta nello spazio Bitcoin e host di podcast Bitcoin orientato alla tecnologia.
Vi suggerisco, prima di leggere questo, di leggere il articolo precedente ho scritto spiegando cos'è Nostr e come funziona ad alto livello. Dovresti quindi avere una buona idea del design di base del sistema a quel punto, quindi ora diamo un'occhiata ai probabili problemi che si verificheranno man mano che aumenta l'adozione. Con la piattaforma diventando popolare per la comunità Bitcoin, questi problemi sono quelli di cui essere consapevoli.
Come ho discusso nell'articolo precedente, le coppie di chiavi pubblica/privata dell'utente sono parte integrante del modo in cui Nostr funziona come protocollo. Non ci sono nomi utente o alcun tipo di identificatore di cui un server di inoltro ha il controllo da associare a singoli utenti. Sono semplicemente le chiavi di quegli utenti che sono completamente sotto il loro controllo.
Funziona come un legame stretto tra l'utente effettivo e il modo in cui viene identificato da altri che impedisce a qualsiasi server di inoltro di separare queste due cose, ad esempio, fornendo l'identificatore di qualcuno a un altro utente. Questo risolve uno dei maggiori problemi fondamentali delle piattaforme utilizzate per la comunicazione tra le persone: la mancanza di controllo sull'identità degli utenti. Ma introduce anche tutti i problemi di gestione delle chiavi in cui si imbatte chi possiede una chiave privata. Le chiavi possono essere perse e le chiavi possono essere compromesse e se dovesse verificarsi un evento del genere, gli utenti non hanno nessuno a cui rivolgersi per assistenza, proprio come con Bitcoin. Non c'è assistenza clienti per recuperare nulla. Lo perdi, ecco.
Ciò richiederà inevitabilmente uno schema per consentire agli utenti di ruotare da una coppia di chiavi a un'altra in modo verificabile e rilevabile per altri utenti con cui interagiscono attraverso il protocollo. L'intero protocollo si basa sulla dimostrazione che un evento proviene da un utente specifico (chiave di identità), quindi tutte queste garanzie vanno fuori dalla finestra una volta che le chiavi di qualcuno vengono compromesse.
Come lo gestisci? Vai a controllare il loro account Twitter? Bene, allora non è un sistema molto decentralizzato, in definitiva, se è necessario utilizzare una piattaforma centralizzata in cui non hanno il controllo della propria identità per verificare la propria identità Nostr.
Altri utenti hanno attestato la legittimità di una nuova chiave? Ciò non affronta situazioni come i compromessi delle chiavi di massa o il non conoscere abbastanza bene qualcuno vicino da fidarsi della loro attestazione.
Nostr ha bisogno di un vero e proprio schema crittografico che leghi la rotazione di una chiave a un'altra. C'è un proposta dallo sviluppatore fiatjaf per uno schema di base che potrebbe potenzialmente risolvere questo problema. L'idea di base sarebbe quella di prendere un lungo set di indirizzi derivati da un singolo seme principale e creare un insieme di chiavi "ottimizzate" simili a come gli alberi Taproot sono impegnati in una chiave Bitcoin. Taproot prende la radice dell'albero Merkle dell'albero Taproot e la "aggiunge" alla chiave pubblica per creare una nuova chiave pubblica. Questo può essere replicato aggiungendo la radice dell'albero Merkle alla chiave privata per ottenere la chiave privata corrispondente per la nuova chiave pubblica. L'idea di Fiatjaf è di concatenare impegni che vanno all'indietro dalla fine all'inizio in modo che ogni chiave ottimizzata contenga effettivamente una prova che la successiva chiave ottimizzata è stata utilizzata per crearla.
Quindi, immagina di iniziare con la chiave Z, l'ultima della catena. Dovresti modificarlo con qualcosa, quindi tornare indietro e creare una versione ottimizzata del tasto Y usando il tasto Z ottimizzato (Z' + Y = Y'). Da qui prenderesti Y' e poi lo useresti per modificare X (Y' + X = X'). Dovresti farlo fino alla chiave A, per ottenere A', e da lì, iniziare a usare quella chiave. Quando viene compromesso, l'utente può trasmettere un evento contenente la chiave A non ottimizzata e la chiave B' ottimizzata. Questo conterrebbe tutti i dati necessari per dimostrare che B' è stato utilizzato per generare A' e gli utenti potrebbero immediatamente smettere di seguire A' e seguire invece B'. Saprebbero definitivamente che B' è la prossima chiave di quell'utente e seguirla invece.
Tuttavia, questa proposta presenta ancora alcuni problemi. Innanzitutto, devi generare tutte le chiavi che utilizzeresti in anticipo e non ha modo di ruotare su un set di chiavi completamente nuovo. Ciò potrebbe essere affrontato impegnandosi in una chiave principale in questo schema che potrebbe autenticare tali rotazioni o semplicemente generando un set di chiavi molto ampio dall'inizio. Entrambi i percorsi sarebbero un corso valido da seguire, ma alla fine richiederebbero di mantenere al sicuro una chiave root o il materiale della chiave ed esporre solo i singoli tasti di scelta rapida ai client Nostr.
Questo schema, tuttavia, non fa nulla per proteggere gli utenti o offrire un meccanismo per il recupero dell'identità nel caso in cui il materiale della chiave root venga perso o sia esso stesso compromesso. Ora, questo non vuol dire che non ci sia alcun vantaggio nello schema di fiatjaf, c'è assolutamente, ma è importante sottolineare che nessuna soluzione risolve tutti i problemi.
Per pontificare un po' sulle potenziali soluzioni qui, immagina invece di una catena di chiavi ottimizzate come lui propone, che una chiave sia ottimizzata con una chiave fredda master che deve essere utilizzata anche per firmare l'evento ruotando da una chiave all'altra. Hai la chiave A', che deriva dall'aggiunta di A e M (la chiave principale), e l'evento di rotazione sarebbe A, M e B' (generato aggiungendo B e M) con una firma da M. M potrebbe essere un chiave di soglia multisig: due su tre, tre su cinque, ecc. Ciò potrebbe potenzialmente aggiungere ridondanza contro la perdita e fornire un meccanismo sicuro per la rotazione delle chiavi. Questo apre anche la porta all'utilizzo di servizi per aiutare nel recupero o alla diffusione di alcune di quelle chiavi ad amici fidati. Offre tutta la stessa flessibilità di multisig con Bitcoin stesso.
PIN26 è anche una proposta che potrebbe essere molto utile per affrontare questo problema. Questo specifica un'estensione del protocollo agli eventi che consente a una firma di una chiave di autorizzare un'altra chiave a pubblicare eventi per suo conto. Il "token", o prova di firma della delega, verrebbe quindi incluso in tutti gli eventi inviati dalla seconda chiave pubblica per conto della prima. Può anche essere limitato nel tempo in modo che i token di delega scadano automaticamente e debbano essere rinnovati.
In definitiva, comunque sia risolto, questo problema ha da risolvere per Nostr a lungo termine. Un protocollo basato interamente su coppie di chiavi pubbliche/private utilizzate come identità non può ottenere trazione e adozione se l'integrità di tali identità non può essere protetta e mantenuta per gli utenti. Ciò alla fine si ridurrà a dover utilizzare costantemente piattaforme fuori banda e centralizzate per verificare nuove chiavi e coordinare le persone che seguono la tua nuova identità quando qualcosa viene perso o compromesso, e a quel punto, quelle altre piattaforme diventano un mezzo per seminare confusione e impegnarsi nella censura.
I problemi di gestione delle chiavi e sicurezza sono grossi problemi con uno spazio di progettazione molto ampio pieno di compromessi e punti deboli, ma sono problemi che dovranno essere risolti nel contesto di Nostr affinché funzioni. Nel mio prossimo articolo, riassumerò alcuni problemi che vedo spuntare in merito all'architettura del server di inoltro e ai problemi di ridimensionamento che gli sviluppatori di Nostr dovranno affrontare date le strutture di dati di base su cui è costruito Nostr.
Per chiunque legga e si chieda perché non ho menzionato gli identificatori decentralizzati (DID): Sì, questa è una potenziale soluzione a questi problemi che, a mio parere, è abbastanza completa. Tuttavia, gli sviluppatori Nostr sembrano molto riluttanti a integrare i DID nel protocollo o nei client a causa del fatto che creerebbero dipendenze esterne al di fuori del protocollo Nostr. Se non hai familiarità con il funzionamento dei DID a livello tecnico e sei interessato, questo articolo di Level 39 è un riassunto molto ben scritto di come funzionano.
Questo è un guest post di Shinobi. Le opinioni espresse sono interamente proprie e non riflettono necessariamente quelle di BTC Inc o Bitcoin Magazine.
- Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
- Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. Accedi qui.
- Fonte: https://bitcoinmagazine.com/technical/solving-nostr-key-management-issues
- 7
- a
- assolutamente
- Il mio account
- effettivamente
- indirizzo
- indirizzi
- Aggiunge
- Adozione
- contro
- avanti
- aiuto
- Tutti
- Consentire
- ed
- Un altro
- chiunque
- architettura
- in giro
- articolo
- Assistenza
- Associate
- autorizzare
- automaticamente
- precedente
- basato
- basic
- diventare
- diventa
- prima
- Inizio
- essendo
- beneficio
- fra
- Big
- Maggiore
- rilegatura
- Po
- Bitcoin
- Bitcoin Magazine
- BROADCAST
- BTC
- BTC Inc
- costruito
- non può
- Censura
- centralizzata
- catena
- dai un'occhiata
- clienti
- Chiudi
- impegnata
- commettere
- Comunicazione
- completamente
- globale
- Compromissione
- confusione
- costantemente
- contesto
- di controllo
- coordinare
- Nucleo
- potuto
- Portata
- creare
- crittografico
- cliente
- Assistenza clienti
- dati
- decentrata
- derivato
- Design
- Costruttori
- sviluppatori
- discusso
- Porta
- giù
- ogni
- Editoriale
- o
- impegnarsi
- abbastanza
- Intero
- interamente
- eccetera
- Anche
- Evento
- eventi
- alla fine
- EVER
- spiegando
- espresso
- estensione
- esterno
- familiare
- Fiatjaf
- Nome
- Flessibilità
- seguire
- i seguenti
- amici
- da
- pieno
- funzioni
- fondamentale
- Guadagno
- generare
- generato
- la generazione di
- ottenere
- dato
- Dare
- Go
- andando
- buono
- cresce
- garanzie
- GUEST
- Ospite Messaggio
- maniglia
- Manovrabilità
- avendo
- qui
- Esitante
- Alta
- host
- Come
- Tuttavia
- HTTPS
- idea
- identificato
- identificatore
- identità
- Identità
- subito
- importante
- in
- incluso
- individuale
- inevitabilmente
- invece
- integrale
- integrare
- interezza
- interagire
- interessato
- Introduce
- problema
- sicurezza
- IT
- stessa
- conservazione
- Le
- Tasti
- Sapere
- Conoscere
- Dipingere
- grandi
- Cognome
- legittimità
- Livello
- probabile
- Limitato
- Lunghi
- Guarda
- perdere
- spento
- rivista
- make
- gestione
- Massa
- Mastercard
- corrispondenza
- materiale
- si intende
- meccanismo
- menzionato
- Multisig
- necessariamente
- esigenze
- New
- GENERAZIONE
- Nostr
- offrire
- Offerte
- ONE
- apre
- Opinione
- Opinioni
- minimo
- Altro
- Altri
- al di fuori
- proprio
- Dolore
- coppie
- sentiero
- Persone
- piattaforma
- Piattaforme
- Platone
- Platone Data Intelligence
- PlatoneDati
- Podcast
- punto
- punti
- Popolare
- Post
- postato
- potenziale
- potenzialmente
- Precedente
- un bagno
- chiave privata
- Problema
- problemi
- prova
- proposta
- propone
- protegge
- protetta
- protocollo
- fornire
- la percezione
- chiave pubblica
- Leggi
- Lettura
- Recuperare
- recupero
- riflettere
- Saluti
- rinnovato
- replicato
- richiedere
- ritorno
- radice
- sicura
- stesso
- scala
- schema
- Secondo
- sicuro
- problemi di
- seme
- Servizi
- set
- dovrebbero
- mostrare attraverso le sue creazioni
- segno
- simile
- semplicemente
- singolo
- situazioni
- So
- soluzione
- Soluzioni
- RISOLVERE
- risolve
- alcuni
- Qualcuno
- qualcosa
- lo spazio
- specifico
- Diffondere
- Di partenza
- Ancora
- Fermare
- tale
- riassumere
- supporto
- sistema
- Fai
- prende
- fittone
- Consulenza
- I
- loro
- cose
- tre
- soglia
- Attraverso
- tempo
- a
- token
- Tokens
- trazione
- commercio
- Alberi
- Affidati ad
- di fiducia
- in definitiva
- per
- uso
- Utente
- utenti
- verificare
- versione
- Che
- quale
- volere
- entro
- chiedendosi
- Lavora
- lavori
- sarebbe
- scritto
- X
- Tu
- Trasferimento da aeroporto a Sharm
- youtube
- zefiro