&emoji=&slug=kriptovijesti&button_colour=b532ed&font_colour=ffffff&font_family=Poppins&outline_colour=ffffff&coffee_colour=FFDD00)
Ovo je uvodnik mišljenja Shinobija, samoukog edukatora u prostoru Bitcoina i voditelja Bitcoin podcasta orijentiranog na tehnologiju.
Predlažem da prije čitanja ovoga pročitate prethodni članak koji sam napisao objašnjavajući što je Nostr i kako radi na visokoj razini. Tada biste trebali imati dobru predodžbu o temeljnom dizajnu sustava u tom trenutku, pa sada pogledajmo moguće probleme koji će se pojaviti kako bude rastao u usvajanju. Budući da platforma postaje popularna za Bitcoin zajednicu, treba biti svjestan ovih problema.
Kao što sam govorio u prethodnom članku, parovi korisničkih javnih/privatnih ključeva sastavni su dio načina na koji Nostr funkcionira kao protokol. Ne postoje korisnička imena ili bilo koja vrsta identifikatora koje kontrolira relejni poslužitelj, a koja bi se mogla pridružiti pojedinačnim korisnicima. Jednostavno, tipke korisnika su potpuno pod njihovom kontrolom.
Ovo funkcionira kao čvrsto povezivanje između stvarnog korisnika i načina na koji ga drugi identificiraju, što sprječava bilo koji relejni poslužitelj da poništi te dvije stvari, tj. davanje nečijeg identifikatora drugom korisniku. Time se rješava jedan od najvećih temeljnih problema platformi koje se koriste za komunikaciju među ljudima: nedostatak kontrole nad vlastitim identitetom korisnika. Ali također predstavlja sve probleme upravljanja ključevima na koje nailazi netko tko posjeduje privatni ključ. Ključevi se mogu izgubiti i ključevi mogu biti kompromitirani, a ako se takav događaj dogodi, korisnici nemaju od koga potražiti pomoć, baš kao i kod Bitcoina. Ne postoji korisnička podrška za oporavak bilo čega. Izgubiš ga, to je to.
Ovo će neizbježno zahtijevati shemu za korisnike da se mijenjaju s jednog para ključeva na drugi na način koji je provjerljiv i vidljiv drugim korisnicima s kojima komuniciraju putem protokola. Cijeli se protokol temelji na dokazivanju da je događaj došao od određenog korisnika (ključ identiteta), tako da sva ta jamstva nestaju nakon što su nečiji ključevi ugroženi.
Kako to podnosiš? Samo otići provjeriti njihov Twitter račun? Pa, onda to nije baš decentraliziran sustav, u konačnici, ako vam je potrebna centralizirana platforma na kojoj oni nemaju kontrolu nad svojim identitetom za provjeru svog Nostr identiteta.
Hoće li drugi korisnici potvrditi legitimnost novog ključa? To se ne odnosi na situacije kao što su masovne kompromitacije ključeva ili nepoznavanje nikoga tko im je blizak dovoljno dobro da vjeruje njihovoj potvrdi.
Nostr treba stvarnu kriptografsku shemu koja povezuje rotaciju jednog ključa s drugim. Postoji prijedlog programera fiatjaf za osnovnu shemu koja bi potencijalno mogla riješiti ovaj problem. Osnovna ideja bila bi uzeti dugačak skup adresa izvedenih iz jednog glavnog sjemena i stvoriti skup “podešenih” ključeva slično kao što su Taproot stabla posvećena Bitcoin ključu. Taproot uzima korijen stabla Merkle stabla Taproot i “dodaje” ga javnom ključu kako bi stvorio novi javni ključ. To se može replicirati dodavanjem korijena stabla Merkle privatnom ključu kako bi se dobio odgovarajući privatni ključ za novi javni ključ. Fiatjafova ideja je lančati obveze idući unatrag od kraja prema početku tako da bi svaki podešeni ključ zapravo sadržavao dokaz da je sljedeći podešeni ključ korišten za njegovo stvaranje.
Dakle, zamislite da počnete ključem Z, zadnjim u lancu. Ovo biste nečim dotjerali, a zatim se vratili unatrag i stvorili dotjeranu verziju tipke Y pomoću dotjerane tipke Z (Z’ + Y = Y’). Odavde biste uzeli Y’ i zatim ga upotrijebili za podešavanje X-a (Y’ + X = X’). Ovo biste učinili sve do tipke A, da biste dobili A’, i od tamo počeli koristiti tu tipku. Kada je ugrožen, korisnik može emitirati događaj koji sadrži nepodešeni ključ A i podešeni ključ B’. To bi sadržavalo sve podatke potrebne da se pokaže da je B’ korišten za generiranje A’, a korisnici bi mogli odmah prestati pratiti A’ i umjesto toga pratiti B’. Definitivno bi znali da je B’ sljedeća tipka tog korisnika i da bi umjesto toga slijedili to.
Ipak, ovaj prijedlog još uvijek ima problema. Prvo, morate unaprijed generirati sve ključeve koje biste ikada upotrijebili i nema načina da se rotiraju na potpuno novi skup ključeva. To bi se moglo riješiti obvezivanjem na glavni ključ u ovoj shemi koji bi mogao ovjeriti takve rotacije ili jednostavno generiranje vrlo velikog skupa ključeva od početka. Bilo koji put bio bi valjan smjer, ali bi u konačnici zahtijevao čuvanje korijenskog ključa ili ključnog materijala na sigurnom i samo izlaganje pojedinačnih prečaca Nostr klijentima.
Ova shema, međutim, ne štiti korisnike niti nudi mehanizam za oporavak identiteta u slučaju da je materijal korijenskog ključa izgubljen ili da je i sam ugrožen. Sada, ovo ne znači da nema koristi od fiatjafove sheme, apsolutno ima, ali važno je naglasiti da nijedno rješenje ne rješava svaki problem.
Da se malo osvrnemo na potencijalna rješenja ovdje, zamislite umjesto lanca podešenih ključeva kao što on predlaže, da je ključ podešen glavnim hladnim ključem koji se također mora koristiti za potpisivanje događaja koji se mijenja s jednog ključa na drugi. Imate ključ A’, koji je izveden dodavanjem A i M (glavni ključ), a događaj rotacije bi bio A, M i B’ (generiran dodavanjem B i M) s potpisom od M. M bi mogao biti multisig threshold key — dva od tri, tri od pet, itd. Ovo bi potencijalno moglo dodati redundantnost protiv gubitka, kao i pružiti siguran mehanizam za rotaciju ključa. Ovo također otvara vrata korištenju usluga za pomoć u oporavku ili širenju nekih od tih ključeva prijateljima od povjerenja. Nudi istu fleksibilnost kao multisig sa samim Bitcoinom.
NIP26 također je prijedlog koji bi mogao biti vrlo koristan u rješavanju ovog problema. Ovo specificira proširenje protokola za događaje koji dopuštaju potpisu jednog ključa da ovlasti drugi ključ da objavi događaje u njegovo ime. “Token” ili dokaz o delegiranju potpisa bi tada bio uključen u sve događaje koje je objavio drugi javni ključ u ime prvog. Može se čak i vremenski ograničiti tako da delegirani tokeni automatski isteknu i moraju se obnoviti.
U konačnici, kako god se riješio, ovaj problem ima dugoročno riješiti za Nostr. Protokol koji se u potpunosti temelji na parovima javnih/privatnih ključeva koji se koriste kao identiteti ne može biti prihvaćen i usvojen ako se integritet tih identiteta ne može zaštititi i održati za korisnike. To će se na kraju svesti na to da morate stalno koristiti izvanpojasne i centralizirane platforme za provjeru novih ključeva i koordinaciju ljudi koji prate vaš novi identitet kada se nešto izgubi ili kompromitira, a u tom trenutku te druge platforme postaju sredstvo za sijanje zbrke i baviti se cenzurom.
Pitanja upravljanja ključevima i sigurnosti veliki su problemi s vrlo velikim prostorom dizajna punim kompromisa i bolnih točaka, ali to su problemi koji će se morati riješiti unutar konteksta Nostra da bi funkcionirao. U sljedećem ću članku sažeti neke probleme za koje vidim da se pojavljuju u vezi s arhitekturom relejnog poslužitelja i problemima skaliranja s kojima će se Nostr programeri morati suočiti s obzirom na osnovne strukture podataka na kojima je Nostr izgrađen.
Za sve koji čitaju i pitaju se zašto nisam spomenuo decentralizirane identifikatore (DID): Da, to je potencijalno rješenje za ove probleme koje je, po mom mišljenju, prilično sveobuhvatno. Međutim, čini se da programeri Nostr-a jako oklijevaju integrirati DID-ove u protokol ili klijente zbog činjenice da bi to stvorilo vanjske ovisnosti izvan Nostr protokola. Ako niste upoznati s načinom na koji DID-ovi rade na tehničkoj razini, a zainteresirani ste, ovaj članak o Razini 39 vrlo je dobro napisan sažetak njihovog rada.
Ovo je gostujući post od Shinobija. Izražena mišljenja su u potpunosti njihova vlastita i ne odražavaju nužno ona BTC Inc ili Bitcoin Magazine.
 &emoji=&slug=kriptovijesti&button_colour=b532ed&font_colour=ffffff&font_family=Comic&outline_colour=ffffff&coffee_colour=FFDD00)
