نیلیون چه مسئله‌ای را حل می‌کند؟
بسیاری از برنامه‌ها برای ذخیره یا پردازش اطلاعات حساس، داده را در اختیار یک سرور می‌گذارند. در چنین وضعی، امنیت داده تا حد زیادی به مدیر سرور، تنظیمات دسترسی و شیوه نگهداری کلیدها وابسته است. نیلیون زیرساختی برای کاهش این وابستگی می‌سازد. توسعه‌دهنده می‌تواند بخشی از داده را به صورت رمزگذاری‌شده در چند گره نگه دارد یا یک کار پردازشی را در محیطی ایزوله اجرا کند. این طراحی برای اطلاعاتی مانند پرونده‌های پزشکی یا داده‌های داخلی سازمان‌ها کاربرد بالقوه دارد؛ البته مناسب بودن آن برای هر پروژه به نیازهای همان پروژه بستگی دارد.
نام «رایانه کور» در اسناد نیلیون به مجموعه خدمات ذخیره‌سازی و پردازش خصوصی آن اشاره دارد. این نام به معنی نامرئی شدن همه فعالیت‌ها یا تضمین محرمانگی در هر شرایطی نیست. هر برنامه باید مشخص کند چه داده‌ای را رمزگذاری می‌کند، چه کسی مجوز بازیابی دارد و نتیجه پردازش در اختیار چه کسانی قرار می‌گیرد.
اجزای شبکه نیلیون چگونه کنار هم قرار می‌گیرند؟
در معماری توصیف‌شده در سند رسمی ۲۰۲۶، شبکه نیلیون یک بخش خدمات حریم خصوصی به نام Petnet و یک لایه درون‌زنجیره‌ای دارد. Petnet محل فعالیت گره‌های ذخیره‌سازی و محاسبات محرمانه است. توکن NIL روی شبکه اصلی اتریوم قرار دارد و شبکه لایه دوم نیلیون برای هماهنگی بخشی از فعالیت‌ها، از جمله لایه راستی‌آزمایی Blacklight، به کار می‌رود. بنابراین محل نگهداری توکن با محل اجرای همه خدمات پردازشی یکی نیست.
گره‌های nilDB داده را ذخیره می‌کنند و گره‌های nilCC بارهای کاری را در محیط اجرای مورد اعتماد انجام می‌دهند. Blacklight برای بررسی عملکرد گره‌های پردازشی طراحی شده است. سند رسمی دامنه فعلی این راستی‌آزمایی را به بخش محاسبات Petnet نسبت می‌دهد؛ از این توضیح نباید نتیجه گرفت که Blacklight صحت هر داده، هر خروجی هوش مصنوعی یا همه رفتارهای یک برنامه را تأیید می‌کند.
ذخیره‌سازی خصوصی با nilDB
در راهکار ذخیره‌سازی خصوصی نیلیون، فیلدهای حساس رمزگذاری و سپس به سهم‌هایی تقسیم می‌شوند که میان گره‌های nilDB توزیع می‌شوند. هر گره یک سهم را نگه می‌دارد. برای بازسازی داده، باید سهم‌های لازم دوباره کنار هم قرار گیرند و فرایند رمزگشایی انجام شود. این روش خطر آشکار شدن اطلاعات بر اثر دسترسی به تنها یک گره را کاهش می‌دهد. تعداد گره‌ها و تنظیمات خوشه می‌تواند بسته به پیاده‌سازی فرق کند.
توسعه‌دهندگان از کتابخانه‌هایی مانند secretvaults برای ارتباط با خوشه nilDB استفاده می‌کنند. مستندات امکان تعریف مجموعه داده، ذخیره و پرس‌وجو و مدیریت مجوزهای دسترسی را شرح می‌دهند. صاحب داده باید بداند که اجازه خواندن یا پردازش را به چه برنامه یا کاربری داده است. همچنین مستندات می‌گویند اسناد nilDB می‌توانند ترکیبی از مقدارهای رمزگذاری‌شده و متن آشکار داشته باشند؛ پس صرف استفاده از nilDB به معنی خصوصی بودن تک‌تک فیلدها نیست.
پردازش محرمانه و خدمات هوش مصنوعی
nilCC برای اجرای برنامه‌های کانتینری در محیط اجرای مورد اعتماد، یا TEE، ساخته شده است. این محیط می‌کوشد داده و برنامه در حال اجرا را از میزبان جدا نگه دارد. گزارش تأیید سخت‌افزاری نیز به بررسی پیکربندی محیط اجرا کمک می‌کند. برای نمونه، یک تیم می‌تواند برنامه تحلیل خود را به صورت بار کاری سازگار با Docker Compose آماده کند و آن را روی گره nilCC اجرا کند. محرمانگی این روش به سخت‌افزار، پیکربندی و بررسی درست گزارش تأیید وابسته است.
nilAI از همین خانواده ابزارها برای ارائه استنتاج مدل‌های زبانی در محیط محرمانه استفاده می‌کند. کاربرد آن می‌تواند پردازش یک پرسش حاوی اطلاعات حساس باشد، اما خروجی مدل همچنان ممکن است اشتباه باشد یا اطلاعاتی را بازگو کند که خود برنامه در ورودی گذاشته است. توسعه‌دهنده باید پیش از استفاده عملی، مسیر ورود داده، سیاست نگهداری آن و محتوای خروجی را بررسی کند. محرمانه بودن محیط اجرا جای کنترل کیفیت پاسخ مدل را نمی‌گیرد.
توکن NIL چه کاربردی دارد؟
NIL توکن کاربردی شبکه نیلیون است. سند رسمی آن را راهی برای دسترسی به خدمات محاسبه و ذخیره‌سازی و مشارکت در سازوکارهای عملیاتی شبکه معرفی می‌کند. در مستندات توسعه‌دهندگان، nilDB و nilCC از سامانه اعتبار مبتنی بر NIL استفاده می‌کنند؛ اعتبار مصرفی از درگاه‌های مربوط شارژ می‌شود. در مقابل، nilAI به عنوان محصولی ساخته‌شده روی nilCC امکان پرداخت از طریق Stripe را هم دارد. پس شیوه پرداخت کاربر نهایی در همه خدمات یکسان نیست.
NIL در سازوکار سهام‌گذاری و فعالیت گره‌های Blacklight نیز نقش دارد و گره‌های واجد شرایط برای کار راستی‌آزمایی پاداش می‌گیرند. مشارکت در تصمیم‌های فنی و عملیاتی شبکه با حق مالکیت بر شرکت یا انجمن نیلیون فرق دارد. طبق سند رسمی، نگهداری NIL سهمی از نیلیون، حق دریافت درآمد تجاری یا حق رأی در اداره شرکتی آن ایجاد نمی‌کند.
چرا تاریخچه شبکه برای شناسایی NIL مهم است؟
NIL ابتدا توکن بومی nilChain، زنجیره مبتنی بر کازموس نیلیون، بود. نیلیون در سال ۲۰۲۶ انتقال آن به توکن ERC-20 روی اتریوم را اعلام کرد. سند رسمی بعدی می‌گوید nilChain در مارس ۲۰۲۶ متوقف شد و از موجودی‌ها تصویر نهایی گرفته شد. دارندگانی که پیش از توقف انتقال نداده بودند، برای دریافت معادل توکن خود از سازوکار مطالبه مبتنی بر درخت مرکل استفاده می‌کنند. این سابقه توضیح می‌دهد چرا برخی راهنماهای قدیمی هنوز از nilChain به عنوان محل فعلی توکن نام می‌برند.
برای تشخیص دارایی باید نام کامل Nillion و نماد NIL را با هم بررسی کرد. راهنمای رسمی مهاجرت، قرارداد توکن روی اتریوم را نیز منتشر کرده است. تطبیق شبکه و قرارداد با منبع رسمی هنگام کار با کیف پول یا یک برنامه ضروری است، چون شباهت نام یا نماد به‌تنهایی هویت توکن را ثابت نمی‌کند. این موضوع به‌ویژه برای آدرس‌های دریافتی و درخواست‌های اتصال کیف پول اهمیت دارد.
یک نمونه کاربردی از ابزارهای نیلیون
فرض کنید یک برنامه پژوهشی می‌خواهد پاسخ‌های حساس داوطلبان را نگه دارد و گزارشی آماری تهیه کند. سازندگان برنامه می‌توانند فیلدهای حساس را پیش از ذخیره‌سازی رمزگذاری کنند و سهم‌های آن را میان گره‌های nilDB بفرستند. سپس مجوز دسترسی به داده را برای نقش‌های مشخص تعریف کنند. اگر بخشی از پردازش به اجرای یک برنامه معمولی نیاز داشته باشد، nilCC محیطی ایزوله برای آن فراهم می‌کند. این یک الگوی ممکن بر پایه قابلیت‌های مستندشده است، نه ادعای پیاده‌سازی یک سامانه پژوهشی مشخص.
پیش از استفاده واقعی، تیم باید بررسی کند کدام داده در دستگاه کاربر آشکار است، چه کسی کلیدها را نگه می‌دارد و گزارش نهایی چه اطلاعاتی را فاش می‌کند. اگر خروجی شامل رکوردهای قابل شناسایی باشد، خصوصی بودن محل ذخیره‌سازی مشکل انتشار خروجی را حل نمی‌کند. همچنین مجوزی که به یک برنامه داده می‌شود باید به اندازه همان کار محدود باشد و امکان لغو آن در طراحی برنامه دیده شود.
محدودیت‌های فنی و تغییرات برنامه‌ریزی‌شده
قابلیت‌های نیلیون برای همه نرم‌افزارها بدون تغییر قابل استفاده نیست. مستندات nilCC محدودیت‌هایی برای اتصال پوشه‌ها، دسترسی به دستگاه میزبان و اجرای کانتینر دارای دسترسی ویژه مشخص کرده‌اند. برنامه‌ای که به این امکانات وابسته است باید پیش از انتقال، سازگاری خود را بررسی کند. nilDB نیز انتخاب نحوه رمزگذاری فیلدها، مدیریت کلید و تعیین مجوزها را از دوش طراح برنامه برنمی‌دارد.
معماری شبکه در حال تغییر است. نقشه راه نیلیون در اکتبر ۲۰۲۶ از برنامه انتقال فعالیت‌های مربوط به طرح Covenants به اتریوم و بازنشسته کردن لایه دوم در مرحله‌ای بعد سخن می‌گوید. این موارد برنامه‌های اعلام‌شده‌اند و زمان یا اجرای نهایی آن‌ها را نمی‌توان قطعی دانست. برای ارزیابی یک کاربرد، بهتر است قابلیت موجود در مستندات فنی را از مرحله‌ای که هنوز در نقشه راه است جدا بررسی کرد.
امنیت و ریسک‌های معنادار برای کاربر
تقسیم داده میان گره‌ها و اجرای برنامه در TEE سطحی از حفاظت فنی فراهم می‌کنند، اما خطای برنامه، افشای کلید یا اعطای مجوز بیش از حد همچنان می‌تواند به داده آسیب بزند. گزارش تأیید سخت‌افزاری باید به‌درستی بررسی شود و استفاده از آن تضمین نمی‌کند که منطق خود برنامه بی‌اشکال است. اسناد رسمی نیلیون همچنین احتمال اختلال خدمات، آسیب‌پذیری قرارداد هوشمند و وابستگی به زیرساخت‌های دیگر را در زمره ریسک‌ها آورده‌اند.
برای دارنده NIL، نگهداری امن کلید خصوصی و بررسی آدرس مقصد اهمیت مستقیم دارد؛ انتقال اشتباه ممکن است برگشت‌ناپذیر باشد. اتصال کیف پول به برنامه جعلی نیز می‌تواند به از دست رفتن دارایی منجر شود. لایه دوم با خطرهایی مانند توقف ترتیب‌دهنده و تأخیر در تسویه روی اتریوم روبه‌رو است. ممیزی امنیتی می‌تواند یک پیاده‌سازی را در زمان بررسی ارزیابی کند، اما نبود آسیب‌پذیری کشف‌شده در ممیزی به معنی نبود خطر در آینده نیست.
