Ez egy véleményszerkesztő Shinobitól, aki egy autodidakta oktató a Bitcoin térben és a technológia-orientált Bitcoin podcast-gazda.
Mielőtt elolvasná ezt, azt javaslom, hogy olvassa el az általam korábban írt cikket, amely elmagyarázza, mi az a Nostr, és hogyan működik magas szinten. Akkor jó elképzeléssel kell rendelkeznie a rendszer alapvető kialakításáról, ezért most nézzük meg a használat növekedésével felmerülő lehetséges problémákat. Mivel a platform népszerűvé válik a Bitcoin közössége számára, tisztában kell lennie ezekkel a problémákkal.
Amint azt az előző cikkben tárgyaltam, a felhasználói nyilvános/privát kulcspárok a Nostr protokollként való működésének szerves részét képezik. Nincsenek olyan felhasználónevek vagy egyéb azonosítók, amelyek felett a továbbítószerver vezérelhetne, és amelyeket az egyes felhasználókhoz társíthatna. Ezek egyszerűen a felhasználók kulcsai, amelyek teljes mértékben az ő irányításuk alatt állnak.
Ez szoros kapcsolatként működik a tényleges felhasználó és mások általi azonosításuk között, megakadályozva, hogy a továbbítószerver leválasztsa ezt a két dolgot, azaz valaki azonosítását adja át egy másik felhasználónak. Ez megoldja az emberek közötti kommunikációra használt platformok egyik legnagyobb alapvető problémáját: a felhasználók saját identitása feletti kontroll hiányát. De bemutatja az összes kulcskezelési problémát is, amelyekbe valaki privát kulccsal belefut. A kulcsok elveszhetnek és a kulcsok veszélybe kerülhetnek, és ha ilyen esemény történik, a felhasználóknak nincs kihez fordulniuk segítségért, akárcsak a Bitcoin esetében. Nincs ügyfélszolgálat, aki bármit megjavítana. Elveszíted, ennyi.
Ez elkerülhetetlenül szükségessé tesz egy olyan sémát, amellyel a felhasználók az egyik kulcspárról a másikra válthatnak oly módon, hogy az ellenőrizhető és felfedezhető legyen a többi felhasználó számára, akikkel a protokollon keresztül kommunikálnak. Az egész protokoll azon alapul, hogy bebizonyítjuk, hogy egy esemény egy adott felhasználótól származik (identitáskulcs), így ezek a garanciák megszűnnek, ha valakinek a kulcsait feltörik.
Hogyan kezeled ezt? Csak megnézed a Twitter-fiókjukat? Nos, akkor ez végül is nem túl decentralizált rendszer, ha olyan központosított platformra van szüksége, ahol nincs ellenőrzésük a személyazonosságuk felett, hogy ellenőrizzék a Nostr identitásukat.
Más felhasználók megerősítették az új kulcs jogosságát? Ez nem foglalkozik az olyan helyzetekkel, mint például a kulcsfontosságú komoly kompromisszumok, vagy ha valaki nem ismer elég közel ahhoz, hogy megbízzon a tanúsítványában.
A Nostr-nek valódi kriptográfiai sémára van szüksége, amely összekapcsolja az egyik kulcs elforgatását a másikkal. A fiatjaf fejlesztő javaslatot tett egy alapvázlatra, amely potenciálisan megoldhatja ezt a problémát. Az alapötlet az lenne, hogy egyetlen mester magból származó címek hosszú készletét hozzuk létre, és hozzunk létre egy “beállított” kulcskészletet, hasonlóan ahhoz, ahogy a Taproot fák leképeznek egy Bitcoin kulcsot. A Taproot átveszi a Taproot fa Merkle-fa gyökerét, és “hozzáadja” a nyilvános kulcshoz, hogy új nyilvános kulcsot hozzon létre. Ez replikálható a Merkle-fa gyökerének hozzáadásával a privát kulcshoz, hogy megkapja az új nyilvános kulcshoz tartozó privát kulcsot. A Fiatjaf ötlete az, hogy a kötelezettségvállalásokat a végétől az elejéig visszafelé láncolja, hogy minden beszorított kulcs valóban bizonyítékot tartalmazzon arra vonatkozóan, hogy a következő becsípett kulcsot használták a létrehozásához.
Képzelje el, hogy a Z kulccsal kezdődik, amely az utolsó a láncban. Módosítanád ezt valamivel, majd visszamész, és létrehozod az Y kulcs módosított változatát a módosított Z billentyűvel (Z’ + Y = Y’). Innentől kezdve Y’-t kell venni, majd ezzel beállítani az X-et (Y’ + X = X’). Ezt egészen az A billentyűig kell megtennie, hogy megkapja az A’-t, és onnan kezdje el használni a kulcsot. Kompromittálódás esetén a felhasználó sugározhat egy eseményt, amely tartalmazza a gyengítetlen A billentyűt és a becsípett B’ billentyűt. Ez tartalmazza az összes szükséges adatot annak bizonyításához, hogy B’-t használták A’ generálására, és a felhasználók azonnal abbahagyhatják az A’ követését, és helyette a B’-t követhetik. Határozottan tudnák, hogy B’ a felhasználó következő kulcsa, és inkább ezt követik.
Ezzel a javaslattal azonban még vannak problémák. Először is, előzetesen létre kell hoznia az összes használt kulcsot, és nem lehet teljesen új kulcskészletre váltani. Ezt úgy lehet megoldani, hogy ebben a sémában rögzítünk egy mesterkulcsot, amely képes hitelesíteni az ilyen elforgatásokat, vagy egyszerűen csak nagyon nagy kulcskészletet generálunk a semmiből. Bármely elérési út követhető, de végső soron a gyökérkulcsot vagy a kulcsanyagot biztonságban kell tartani, és csak az egyes gyorsbillentyűket kell a Nostr-kliensek rendelkezésére bocsátani.
Ez a séma azonban nem védi a felhasználókat, és nem biztosít identitás-helyreállítási mechanizmust arra az esetre, ha a gyökérkulcs anyaga elveszne, vagy maga veszélybe kerülne. Ez nem azt jelenti, hogy a Fiatjaf tervének semmi haszna nem lenne, ez mindenképpen van, de fontos leszögezni, hogy egyetlen megoldás sem old meg minden problémát.
Hogy egy kicsit beszéljünk a lehetséges megoldásokról, képzeljük el, hogy ahelyett, hogy a billentyűk sorozatát úgy módosítanák, ahogy ő javasolja, egy kulcsot egy mesterkulccsal módosítanak, amelyet az egyik kulcsról a másikra váltó esemény aláírására is használni kell. . Van A’ kulcsa, amelyet A és M (a mesterkulcs) hozzáadásával kapunk, és a forgatási esemény A, M és B’ (a B és M hozzáadásával jön létre) M aláírással. multisig küszöbkulcs – kettő a háromból, három az ötből stb. Ez potenciálisan növelheti a redundanciát az elvesztéssel szemben, és biztonságos mechanizmust biztosít a kulcsok elforgatásához. Ez megnyitja az ajtót a felépülést segítő szolgáltatások igénybevételére, vagy a kulcsok némelyikének megbízható barátok számára történő kiosztására. Ugyanolyan rugalmasságot kínál, mint a multisig magával a Bitcoinnal.
A NIP26 is egy olyan javaslat, amely nagyon hasznos lehet a probléma megoldásában. Ez egy eseményprotokoll-bővítményt határoz meg, amelynél az egyik kulcsból származó aláírás felhatalmazza a másik kulcsot, hogy eseményeket tegyen közzé a nevében. A felhatalmazás „tokenje” vagy aláírási igazolása ezután minden olyan eseményben szerepelne, amelyet a második nyilvános kulcs az első nevében tesz közzé. Ez akár időkorlátos is lehet, így a delegálási tokenek automatikusan lejárnak, és meg kell újítani.
Végül azonban ez a probléma megoldódott van hosszú távú Nostr meg kell oldani. A teljes egészében identitásként használt nyilvános/privát kulcspárokon alapuló protokoll nem nyerheti el a hatalmat és nem veheti át az irányítást, ha ezen identitások integritása nem védhető és karbantartható a felhasználók számára. Ez végső soron abból adódik, hogy folyamatosan sávon kívüli és központosított platformokat kell használni az új kulcsok ellenőrzésére, és az emberek koordinálására, hogy nyomon kövessék az új személyazonosságot, ha valami elveszett vagy kompromittálódott, és ezen a ponton ezek a platformok a zavart keltő erőforrásokká válnak. és gyakorolják a cenzúrát.
A kulcsfontosságú kezelési és biztonsági problémák komoly problémákat jelentenek a kompromisszumokkal és fájdalmas pontokkal teli, nagyon nagy tervezési térrel, de ezeket a problémákat a Nostr kontextusában kell megoldani ahhoz, hogy működjön. Következő cikkemben összefoglalok néhány felmerülő problémát a továbbítókiszolgáló architektúrájával és a skálázási problémákkal kapcsolatban, amelyekkel a Nostr fejlesztői szembesülni fognak, tekintettel a Nostr alapadatszerkezetére.
Mindenkinek, aki olvas, és azon tűnődik, hogy miért nem említettem a decentralizált azonosítókat (DID): Igen, ez az egyik lehetséges megoldás ezekre a problémákra, ami szerintem elég átfogó. A Nostr fejlesztői azonban nagyon haboznak integrálni a DID-ket a protokollba vagy a kliensekbe, mivel ez a Nostr protokollon kívüli külső függőségeket hozna létre. Ha nem ismeri a DID-k működését technikai szinten, és érdekli, ez a 39. szintű cikk egy nagyon jól megírt összefoglaló a működésükről.
Ez egy vendégposzt Shinobitól. A kifejtett vélemények teljes mértékben a sajátjuk, és nem feltétlenül tükrözik a BTC Inc vagy a Bitcoin Magazine véleményét.
.