تصور کنید میخواهید با دوستانتان چت گروهی داشته باشید، اما هیچ سروری در دنیا وجود ندارد که لیست اعضا یا ترتیب پیامها را ذخیره کند. در چنین دنیایی، هر پیام یک معمای لجستیکی است که Kiyeovo با پذیرش یک تناقض فنی، راه حلی برای آن یافته است. در حالی که رویای تقارن کامل، یک شبکه کاملاً غیرمتمرکز را پیشنهاد میدهد، Kiyeovo با رها کردن این ایدهآل، تضاد فنی یک چت گروهی کاملاً بدون سرور (Serverless) را حل میکند. توسعهدهنده این پیامرسان P2P در توضیح مبناهای معماری مورد نیاز برای عملکرد گروههای پویا بدون یک مرجع مرکزی، تأکید کرد که چتهای گروهی دقیقاً همان جایی هستند که جنبهی «بدون سرور بودن» بیشترین آسیب و دشواری را ایجاد میکند.
در اپلیکیشنهای سنتی، سرور مانند یک «منبع حقیقت» (Source of Truth) عمل میکند و تعیین میکند چه کسی در گروه است و پیامها با چه ترتیبی ارسال شدهاند. با وجود یک سرور مرکزی، یک مقام مورد اعتماد به سوالات حیاتی پاسخ میدهد: در حال حاضر چه کسانی عضو این گروه هستند؟ چه کلیدی پیامها را رمزگذاری میکند و چه کسی باید آن کلید را داشته باشد؟ پیامها با چه ترتیبی رخ دادهاند؟ و کاربری که آفلاین بوده، چه پیامهایی را از دست داده است؟
حتی برنامههایی با رمزنگاری سرتاسری (E2E) که قادر به خواندن محتوای پیامها نیستند، همچنان برای هماهنگی (Coordination) به سرورها متکی هستند. برای مثال، سرور Signal لیست اعضای گروه را ذخیره کرده و پیامها را فوروارد میکند. Matrix از یک homeserver برای ذخیره وضعیت گروه و ترتیببندی رویدادها استفاده میکند. این سرورها وضعیت گروه را به کاربران جدید تحویل میدهند و بهسادگی مانع از دریافت بهروزرسانیها توسط کاربران حذفشده میشوند. بدون سرور، هیچ «مکانی» وجود ندارد که لیست اعضا را با اطمینان بداند، هیچ ماشین ترتیبدهندهای (Sequencer) برای نظم بخشیدن به پیامها نیست و هیچ صندوق پستی ۲۴ ساعتهای برای همتایان (Peers) آفلاین وجود ندارد.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، حذف واسطههای مرکزی همیشه هزینهی فنی بالایی دارد. در یک محیط کاملاً بدون سرور، مدیریت وضعیت گروه بدون یک مرجع متمرکز منجر به هرجومرج میشود.
معماری قدرت و مدیریت اعضا
طبق گزارش فنی این پروژه، Kiyeovo برای جلوگیری از هرجومرج در عضویتهای بدون رهبر، قانون «یک خالق» (One Creator) را وضع کرده است. توسعهدهنده ابتدا مدلی را بررسی کرد که در آن هر عضو بتواند دیگران را اضافه یا حذف کند و وضعیت از طریق منطق ادغام (Merge Logic) همگرا شود، اما این ایده را رد کرد. در چنین سیستمی، اگر دو نفر بهطور همزمان عضویتها را تغییر دهند، همتایان در نهایت تصاویری متفاوت از گروه خواهند داشت. بدون یک ساعت مرجع مورد اعتماد (Trusted Clock)، پاسخ به این سوال که آیا کاربر قبل یا بعد از ارسال یک پیام خاص اخراج شده است، غیرممکن است. توسعهدهنده برای حل این مشکل استفاده از یک لایه اثبات کار (Proof-of-Work) را بررسی کرد، اما آن را بیش از حد سنگین دانست.
برای حل این معضل، هر گروه به یک کلید Ed25519 متصل است که متعلق به خالق گروه است. تنها این هویت میتواند بهطور رسمی اعضای جدید را دعوت کند یا اعضای موجود را اخراج نماید.
ویژگیهای این معماری عبارت است از:
- نویسنده واحد (Single Writer): دقیقاً یک نویسنده مجاز برای وضعیت عضویت وجود دارد که باعث میشود همگرایی دادهها تrivial یا بسیار ساده شود.
- خروج اعضا: کاربرانی که میخواهند گروه را ترک کنند، یک درخواست ترکِ امضاشده میفرستند و سپس خالق آن را به عنوان یک حذف اعمال میکند.
- نقطه شکست واحد (Single Point of Failure): این مدل یک نقطه ضعف ایجاد میکند. اگر خالق دستگاه (هویت) خود را گم کند یا برای همیشه آفلاین شود، اعضای فعلی میتوانند با کلید فعلی به گفتگو ادامه دهند، اما هیچکس نمیتواند به گروه اضافه یا از آن حذف شود.
رمزنگاری و چرخش کلیدها
در بخش امنیت، این اپلیکیشن برای حفظ ایمنی از سیستمی از کلیدهای فرستنده چرخان استفاده میکند که به دورههای زمانی یا Epoch تقسیم شدهاند. هر Epoch نمایندهی یک «نسخه خاص از گروه» است. توسعهدهنده چارچوبهای پیشرفته و استانداردی مانند MLS (RFC 9420) و TreeKEM را رد کرد. اگرچه MLS برای هزاران کاربر مقیاسپذیری بالایی دارد، اما نیازمند یک «سرویس تحویل» (Delivery Service) برای توزیع پیامهای تغییر کلید است؛ این امر در یک جدول هش توزیعشده (DHT) که در آن همتایان اغلب آفلاین هستند، غیرعملی است.
مکانیسم رمزنگاری Kiyeovo به شرح زیر است:
- رمزنگاری متقارن: هر Epoch یک کلید متقارن تصادفی ۳۲ بایتی دارد که بین کل گروه مشترک است. پیامها با استفاده از الگوریتم XChaCha20-Poly1305 رمزگذاری میشوند.
- توزیع کلید: خالق، کلید گروه را برای هر عضو بهطور جداگانه با استفاده از رمزنگاری کلید عمومی (با استفاده مجدد از جفتکلید هویت پیامهای ۱:۱) درون یک پیام کنترلی امضاشده که به صندوق ورودی خصوصی آنها ارسال میشود، مهر و موم (Seal) میکند.
- چرخش خودکار: هرگونه تغییر در عضویت — چه پیوستن، چه ترک کردن یا اخراج شدن — باعث تحریک ایجاد یک Epoch جدید و یک کلید تازه میشود.
- پنهانسازی آینده (Forward Secrecy): یک عضو جدید تنها کلید مربوط به Epoch ای را دریافت میکند که به آن پیوسته است، به این معنی که او نمیتواند تاریخچه قدیمی گروه را بخواند.
این مکانیسم تضمین میکند که یک عضو حذفشده نمیتواند کلید جدید را محاسبه کند یا مشترک موضوع (Topic) جدید شود. از آنجایی که محدودیت گروه تا ۱۰ عضو است، هزینه مهر و موم کردن کلیدها (به ترتیب O(n)) سبک باقی میماند. با این حال، این بدان معناست که هیچ چرخش کلیدی در داخل یک Epoch و هیچ پنهانسازی آیندهی مستمری در یک گروه پایدار وجود ندارد.
توزیع وضعیت از طریق DHT
Kiyeovo متادادههای گروه — شامل لیست اعضا و مرزهای توالی (Sequence Boundaries) هر فرستنده — را در یک جدول هش توزیعشده (DHT) با استفاده از دو نوع رکورد خاص ذخیره میکند:
۱. اشارهگرهای نسخه (Version Pointers): یک اشارهگر تغییرپذیر به «آخرین نسخه».
۲. رکوردهای نسخهدار (Versioned Records): زنجیرهای از رکوردهای تغییرناپذیر و هششده که یک لگ (Log) فقط-افزایشی (Append-only) را تشکیل میدهند.
هر ورودی در این لگ توسط خالق امضا شده و از طریق هش به ورودی قبلی لینک میشود. محتوای بهروزرسانی عضویت با کلید مربوط به آن Epoch رمزگذاری شده است. این ساختار به اعضای آفلاین اجازه میدهد تاریخچهای قابل تأیید از نحوه تکامل گروه را دانلود کنند. برای تضمین یکپارچگی، اعتبارسنج DHT بهگونهای برنامهریزی شده است که هر رکوردی را که نسخه گروه را جلو نمیبرد یا فاقد امضای خالق است، رد کند. این سیستم از منطق «آخرین نویسنده برنده است» (Last-writer-wins) استفاده میکند که تنها به دلیل وجود تنها یک نویسنده designated (تعیین شده)، ایمن است.
حل شکاف پیامهای آفلاین
ترتیببندی پیامها در محیط P2P بدون یک ساعت مرجع، بسیار دشوار است. Kiyeovo این مشکل را با استفاده از اعداد توالی-محور برای هر فرستنده (Per-sender sequence numbers) حل میکند. هر فرستنده یک شماره توالی برای هر گروه و Epoch نگه میدارد (مثلاً: «این پیام N-اُم من است»). گیرندهها از این شمارهها برای شناسایی شکافهای موجود در گفتگو استفاده میکنند.
برای تحویل پیامهای آفلاین، اپلیکیشن به جای باکتهای «مخصوص گیرنده»، از باکتهای «مخصوص فرستنده» استفاده میکند. توسعهدهنده سه گزینه را برای این کار بررسی کرد:
۱. باکتهای مخصوص گیرنده: این روش نیازمند آن بود که فرستنده برای هر پیام، در باکت تکتک اعضا (تعداد گروهها × اعضا × Epochهای باز) بنویسد که باعث ناکارآمدی شدید میشد.
۲. باکتهای مشترک: گنجاندن تمام امضاهای عمومی در یک نام باکت مشترک منجر به این میشد که کاربران بهطور همزمان در یک باکت بنویسند یا آن را بازنویسی کنند، که طبق گفته توسعهدهنده «سریعاً وضعیت زشتی پیدا میکرد».
۳. باکتهای مخصوص فرستنده (گزینه انتخابی): هر ارسال در باکت مخصوص به خودِ فرستنده برای Epoch فعلی نوشته میشود. نام باکتها شامل امضای عمومی مالک است و اعتبارسنجهای DHT این مورد را برای جلوگیری از دستکاری (Tampering) اجباری میکنند.
زمانی که یک کاربر دوباره متصل میشود، باید ماتریسی از گروهها، اعضا و Epochهایی که بسته نشدهاند را اسکن کند تا تمام محتواهای از دست رفته را از باکتهای مختلف فرستندگانه بازیابی کند.
انتقال و موضوعات (Transport and Topics)
برای مدیریت پیامرسانی لحظهای (Real-time)، اپلیکیشن از Topicهای کتابخانه libp2p استفاده میکند که مانند «کانالها» عمل میکنند. کاربران برای دریافت پیامها مشترک یک Topic میشوند. برای جلوگیری از دسترسی غیرمجاز، نام خود Topic از کلید گروه مشتق میشود.
از آنجایی که چرخش کلید گروه باعث چرخش نام Topic نیز میشود، برای یک فرد خارجی تقریباً غیرممکن است که نام Topic را حدس بزند. یک عضو حذفشده بهطور کامل مسدود میشود زیرا نمیتواند نام Topic جدید را محاسبه کند، چه برسد به اینکه مشترک آن شود.
این رویکرد فنی یک حقیقت سخت را درباره غیرمتمرکزسازی آشکار میکند: تقارن مطلق اغلب به قیمت کاهش کاربردپذیری (Usability) تمام میشود. توسعهدهنده در ابتدا در نظر داشت عضویتها را در لحظه ایجاد گروه ثابت کند (مشابه گروههای خصوصی در Briar)، به گونهای که هیچکس نتواند اضافه یا حذف شود. اگرچه این کار معماری را سادهتر میکرد، اما نبود توابع دعوت یا اخراج، نقطه ضعف بزرگی بود. با معرفی یک «مرکزیت سبک» از طریق خالق گروه، اپلیکیشن توانایی داشتن عضویتهای پویا و ترتیببندی پایدار را به دست آورد.
بهطور خلاصه، مدل Kiyeovo ثابت میکند که اعمال یک سقف سخت بر اندازه گروه (۱۰ عضو)، اجازه میدهد تا طرحهای رمزنگاری سادهتر و سربارهای DHT قابل مدیریت باشند و جایگزینی کاربردی برای الزامات پیچیده وب غیرمتمرکز مدرن ارائه دهد.
گام بعدی شما
- اگر به دنبال پیادهسازی سیستمهای P2P هستید، مدل «نویسنده واحد» را برای مدیریت وضعیت (State) در محیطهای بدون سرور بررسی کنید.
- محدود کردن مقیاس (مثلاً تا ۱۰ کاربر) را به عنوان استراتژی کاهش پیچیدگی رمزنگاری در پروژههای خود به کار ببرید.
- برای درک عمیقتر توزیع دادهها، مستندات libp2p و مکانیزمهای DHT را مطالعه کنید.
اما این تنها بخشی از معماری است؛ تأثیر محدودیت تعداد اعضا بر سرعت استنتاج در شبکههای توزیعشده را در گزارش بعدی بررسی خواهیم کرد.
گفتگو