حل مسائل کلیدی مدیریت Nostr – مجله بیت کوین
این یک سرمقاله نظری توسط شینوبی، یک مربی خودآموخته در فضای بیت کوین و میزبان پادکست بیت کوین مبتنی بر فناوری است.
پیشنهاد می‌کنم قبل از خواندن این مطلب، مقاله قبلی را که در آن توضیح داده‌ام Nostr چیست و چگونه در سطح بالایی کار می‌کند، نوشته‌ام، بخوانید. پس از آن باید ایده خوبی از طراحی هسته سیستم در آن نقطه داشته باشید، بنابراین اکنون بیایید نگاهی به مشکلات احتمالی ای بیندازیم که قرار است در هنگام پذیرش آن رخ دهد. با محبوب شدن این پلت فرم برای جامعه بیت کوین، باید از این مشکلات آگاه بود.
همانطور که در مقاله قبلی بحث کردم، جفت کلید عمومی/خصوصی کاربر برای نحوه عملکرد Nostr به عنوان یک پروتکل ضروری است. هیچ نام کاربری یا هر نوع شناسه‌ای وجود ندارد که سرور رله کنترل آن را در دست داشته باشد تا به کاربران فردی مرتبط شود. این به سادگی کلیدهای آن دسته از کاربران هستند که کاملاً تحت کنترل آنها هستند.
این به عنوان یک اتصال محکم بین کاربر واقعی و نحوه شناسایی آنها توسط دیگران عمل می کند که مانع از جداسازی هر سرور رله ای از این دو چیز می شود، یعنی دادن شناسه شخصی به کاربر دیگر. این یکی از بزرگترین مشکلات اساسی پلتفرم های مورد استفاده برای ارتباط بین افراد را حل می کند: عدم کنترل بر هویت خود کاربران. اما همچنین تمام مشکلات مدیریت کلید را که شخصی که دارای کلید خصوصی است با آن مواجه می شود، معرفی می کند. ممکن است کلیدها گم شوند و کلیدها به خطر بیفتند و اگر چنین رویدادی اتفاق بیفتد، کاربران مانند بیت کوین کسی را ندارند که برای کمک به او مراجعه کنند. هیچ پشتیبانی مشتری برای بازیابی چیزی وجود ندارد. شما آن را از دست می دهید، همین.
این امر ناگزیر به طرحی برای چرخش کاربران از یک جفت کلید به جفت کلید دیگر می‌شود، به گونه‌ای که برای سایر کاربرانی که از طریق پروتکل با آنها در تعامل هستند قابل تأیید و کشف باشد. کل پروتکل مبتنی بر اثبات این است که یک رویداد از یک کاربر خاص (کلید هویت) آمده است، بنابراین همه این ضمانت‌ها پس از به خطر افتادن کلیدهای شخصی از پنجره خارج می‌شوند.
چطور از پس این بر می آیی؟ فقط برو حساب توییترشون رو چک کن؟ خوب، پس این یک سیستم خیلی غیرمتمرکز نیست، در نهایت، اگر برای تأیید هویت Nostr خود نیاز به استفاده از یک پلت فرم متمرکز دارید که در آن کنترل هویت خود را ندارند.
آیا سایر کاربران مشروعیت یک کلید جدید را تأیید کرده اند؟ این به موقعیت‌هایی مانند سازش‌های کلیدی انبوه، یا ناشناختن افراد نزدیک به آنها به اندازه کافی برای اعتماد به گواهینامه آنها نمی‌پردازد.
Nostr به یک طرح رمزنگاری واقعی نیاز دارد که چرخش یک کلید را به کلید دیگر گره بزند. پیشنهادی از طرف توسعه دهنده fiatjaf برای یک طرح اساسی وجود دارد که به طور بالقوه می تواند این مشکل را حل کند. ایده اصلی این است که مجموعه‌ای طولانی از آدرس‌های مشتق شده از یک دانه اصلی را انتخاب کنیم و مجموعه‌ای از کلیدهای «بهینه‌سازی‌شده» ایجاد کنیم که شبیه نحوه تعهد درختان Taproot به یک کلید بیت‌کوین است. Taproot ریشه درخت Merkle درخت Taproot را می گیرد و آن را به کلید عمومی اضافه می کند تا یک کلید عمومی جدید ایجاد کند. این را می توان با افزودن ریشه درخت مرکل به کلید خصوصی به منظور دستیابی به کلید خصوصی منطبق برای کلید عمومی جدید تکرار کرد. ایده فیات جاف این است که تعهدات زنجیره ای را از انتها به ابتدا به عقب برگرداند تا هر کلید بهینه سازی شده در واقع حاوی مدرکی باشد مبنی بر اینکه کلید بهینه سازی شده بعدی برای ایجاد آن استفاده شده است.
بنابراین، تصور کنید که با کلید Z شروع کنید، آخرین کلید در زنجیره. شما می توانید این را با چیزی تغییر دهید و سپس به عقب برگردید و با استفاده از کلید Z بهینه سازی شده (Z’ + Y = Y’) یک نسخه بهینه سازی شده از کلید Y ایجاد کنید. از اینجا می توانید Y’ را بگیرید و سپس از آن برای تنظیم X (Y’ + X = X’) استفاده کنید. شما این کار را تا آخر به کلید A انجام می دهید تا A’ را بدست آورید و از آنجا شروع به استفاده از آن کلید کنید. هنگامی که در معرض خطر قرار می گیرد، کاربر می تواند رویدادی حاوی کلید اصلاح نشده A و کلید B’ را پخش کند. این شامل تمام داده‌های مورد نیاز برای نشان دادن استفاده از B برای تولید A’ است و کاربران می‌توانند فوراً A’ را دنبال نکنند و به جای B’ را دنبال کنند. آنها به طور قطع می دانند که B’ کلید بعدی آن کاربر است و در عوض آن را دنبال می کنند.
هرچند این پیشنهاد هنوز هم مشکلاتی دارد. اول، شما باید تمام کلیدهایی را که تا به حال استفاده می کنید را زودتر از موعد تولید کنید و هیچ راهی برای چرخش به یک مجموعه کاملاً جدید از کلیدها وجود ندارد. این را می‌توان با تعهد به یک کلید اصلی در این طرح که می‌تواند چنین چرخش‌هایی را محضری کند، یا به سادگی مجموعه‌ای از کلیدها را از ابتدا تولید می‌کند. هر یک از مسیرها یک دوره معتبر برای گذراندن خواهد بود، اما در نهایت مستلزم ایمن نگه داشتن یک کلید اصلی یا مواد کلیدی است و فقط کلیدهای میانبر جداگانه در معرض مشتریان Nostr است.
با این حال، این طرح برای محافظت از کاربران یا ارائه مکانیزمی برای بازیابی هویت در صورتی که ماده اصلی کلید از بین برود یا خود به خطر بیفتد، کاری انجام نمی دهد. اکنون، این بدان معنا نیست که هیچ فایده ای برای طرح فیات جاف وجود ندارد، قطعاً وجود دارد، اما مهم این است که به این نکته اشاره کنیم که هیچ راه حلی همه مشکلات را حل نمی کند.
برای اینکه کمی در مورد راه‌حل‌های بالقوه در اینجا صحبت کنیم، به جای زنجیره‌ای از کلیدهای بهینه‌سازی شده که او پیشنهاد می‌کند، تصور کنید که یک کلید با یک کلید سرد اصلی بهینه‌سازی شده است که باید برای امضای رویداد در حال چرخش از یک کلید به کلید دیگر استفاده شود. شما کلید A’ دارید که با افزودن A و M (کلید اصلی) به دست می آید، و رویداد چرخش A، M و B’ خواهد بود (با اضافه کردن B و M ایجاد می شود) با امضای M. M می تواند یک باشد. کلید آستانه چند علامتی – دو از سه، سه از پنج، و غیره. این به طور بالقوه می تواند افزونگی را در برابر از دست دادن اضافه کند و همچنین مکانیزم ایمن برای چرخش کلید ایجاد کند. این همچنین راه را برای استفاده از خدمات برای کمک به بهبودی یا پخش برخی از این کلیدها به دوستان مورد اعتماد باز می کند. این همان انعطاف‌پذیری را ارائه می‌دهد که Multisig با خود بیت‌کوین انجام می‌دهد.
NIP26 نیز پیشنهادی است که می تواند در رسیدگی به این مشکل بسیار مفید باشد. این یک پسوند پروتکل را برای رویدادها مشخص می کند که به امضای یک کلید اجازه می دهد تا کلید دیگری را برای ارسال رویدادها از طرف خود مجاز کند. سپس «توکن» یا گواهی امضای تفویض اختیار، در تمام رویدادهایی که توسط کلید عمومی دوم از طرف اولی ارسال می‌شود، گنجانده می‌شود. حتی ممکن است محدود به زمان باشد تا توکن‌های نمایندگی به‌طور خودکار منقضی شوند و باید تمدید شوند.
در نهایت، هر طور که حل شود، این مشکل دارد برای Nostr در دراز مدت حل شود. پروتکلی که کاملاً مبتنی بر جفت کلید عمومی/خصوصی است که به عنوان هویت مورد استفاده قرار می گیرد، در صورتی که یکپارچگی آن هویت ها نتواند برای کاربران محافظت و حفظ شود، نمی تواند مورد توجه و پذیرش قرار گیرد. این در نهایت به این ختم می شود که باید دائماً از پلتفرم های خارج از باند و متمرکز برای تأیید کلیدهای جدید و هماهنگ کردن افرادی که هویت جدید شما را دنبال می کنند هنگامی که چیزی گم می شود یا در خطر است استفاده کنید، و در آن مرحله، آن پلت فرم های دیگر به وسیله ای برای ایجاد سردرگمی تبدیل می شوند. و وارد سانسور شوند.
مسائل مربوط به مدیریت کلید و امنیت، مشکلات بزرگی با فضای طراحی بسیار بزرگ پر از معاوضه و نکات دردناک هستند، اما مشکلاتی هستند که باید در چارچوب Nostr حل شوند تا کار کند. در مقاله بعدی، برخی از مسائلی را که می بینم در رابطه با معماری سرور رله و مسائل مقیاس بندی که توسعه دهندگان Nostr باید با توجه به ساختارهای داده اولیه ای که Nostr بر روی آنها ساخته شده است، با آن مواجه شوند، خلاصه می کنم.
برای هر کسی که می‌خواند و نمی‌داند چرا من به شناسه‌های غیرمتمرکز (DID) اشاره نکرده‌ام: بله، این یک راه‌حل بالقوه برای این مشکلات است که به نظر من کاملاً جامع است. با این حال، به نظر می رسد توسعه دهندگان Nostr در ادغام DID ها در پروتکل یا کلاینت ها بسیار مردد هستند، زیرا این امر باعث ایجاد وابستگی های خارجی خارج از پروتکل Nostr می شود. اگر با نحوه کار DID در سطح فنی آشنا نیستید و علاقه مند هستید، این مقاله سطح 39 خلاصه ای بسیار خوب از نحوه کار آنها است.
این پست مهمان شینوبی است. نظرات بیان شده کاملاً متعلق به خود آنها است و لزوماً نظرات BTC Inc یا مجله Bitcoin را منعکس نمی کند.