EN
→ بازگشت به خبرخوان
شمارهٔ ۰۴۲۱Internet Computer۲ دقیقه۳ منبع

آزمون Canic در برابر OpenChat، در اصل آزمون ایمنی ارتقاست

یک بررسی مهندسی می‌گوید Canic می‌تواند بخشی از بار مدیریت ناوگان OpenChat را کاهش دهد، اما مسئله اصلی ساخت و تخصیص کانستر نیست. ابتدا باید ارتقاهای حافظه‌حافظ، حاکمیت، مالکیت حافظه و سربار واقعی ناوگان ارزیابی شوند.

اشتراک‌گذاری
رایانه اینترنتی (ICP)
آزمون Canic در برابر OpenChat، در اصل آزمون ایمنی ارتقاست
تصویر: تولید هوش مصنوعی

یک بررسی تازه در انجمن توسعه‌دهندگان Internet Computer، OpenChat را هدفی سخت‌گیرانه برای ارزیابی Canic می‌داند، نه گزینه‌ای برای مهاجرت فوری در محیط تولید.

مسئله اصلی، مرز انتشار و ارتقاست. OpenChat در ارتقاهای مرحله‌ای وضعیت برنامه را حفظ می‌کند، اما سیاست فعلی Canic در مرحله پیش از ۱.۰، گذارهای انتشار را بر نصب مجدد بنا می‌کند. بنابراین حتی اگر Canic بتواند بخشی از فرایند تأمین زیرساخت OpenChat را بازسازی کند، جایگزینی مستقیم ناوگان فعلی OpenChat مسئولانه نیست.

این تفاوت مهم است، چون OpenChat همین حالا زیرساخت قابل‌توجهی دارد. ایندکس‌های آن ایجاد کانستر، ظرفیت آماده، تأمین چرخه، بررسی کنترلرها، صف‌های ارتقا، تلاش مجدد و عملیات محلی هر ساب‌نت را مدیریت می‌کنند. مدل جدیدتر کاربران اشتراکی نیز کاربر منطقی را از کانستر فیزیکی جدا می‌کند. یک حلقه نصب عمومی به‌طور خودکار این سیستم‌ها را بهتر نمی‌کند.

بررسی مذکور فرصت محدودتری را پیشنهاد می‌کند: Canic در آینده می‌تواند زیرساخت قابل‌استفاده مجددی برای تخصیص، حسابداری چرخه، تطبیق وضعیت، شواهد بازیابی و منشأ انتشار فراهم کند. فرایند فعلی OpenChat برای حاکمیت مبتنی بر هش Wasm می‌تواند مرجع اختیار برنامه باقی بماند و Canic شواهد مربوط به آرتیفکت و استقرار را ارائه دهد. خود پست انجمن تأکید می‌کند که این کار باید تضمین‌های فعلی OpenChat را حفظ کند، نه اینکه آن‌ها را با انتزاع‌های آزمایش‌نشده جایگزین کند.

سطح یکپارچه‌سازی نیز از تأمین کانستر گسترده‌تر است. OpenChat از مدیران حافظه اختصاصی برنامه، چند قالب ارتباطی، payloadهای بزرگ، بازسازی تایمرها و منطق آمادگی مخصوص برنامه استفاده می‌کند. بنابراین قابلیت‌های زمان اجرا و مشاهده‌پذیری Canic باید با آزمون‌های اجرایی برای مالکیت حافظه، ترتیب چرخه عمر، codecها، سقف آرگومان، تایمرها، پاسخ‌های نامعلوم، تأمین زیرساخت قطع‌شده و بازیابی ارزیابی شوند.

این بررسی پیشنهاد می‌کند کار با یک بارکاری دورریختنی و شبیه OpenChat آغاز شود، نه با مهاجرت تولیدی. چنین نمونه‌ای باید ایندکس‌های سراسری و محلی ساب‌نت، نقش‌های کاربر اختصاصی و اشتراکی، نقش‌های گروه و ذخیره‌سازی، موج ثبت‌نام، تمام‌شدن pool، فشار تأمین مالی و گم‌شدن پاسخ‌ها را مدل کند. تنها پس از این آزمون‌ها می‌توان درباره مقیاس، سربار، حاکمیت و پشتیبانی از انتشارهای وضعیت‌حافظ تصمیم گرفت.

دو caveat مهم وجود دارد: این متن یک بررسی سطح کد است، نه سرشماری ناوگان زنده، ممیزی امنیتی یا مقایسه عملکرد اندازه‌گیری‌شده. همچنین Canic هنوز پیش از نسخه ۱.۰ است و معماری OpenChat در حال تغییر است؛ بنابراین نتیجه‌گیری‌ها موقتی‌اند و اعلام پذیرش یا مهاجرت محسوب نمی‌شوند.

نتیجه مفید برای توسعه‌دهندگان ICP، تفکیک دقیق‌تر مالکیت است: OpenChat باید عضویت، مسیریابی، منطق محصول و اختیار انتشار تحت SNS را حفظ کند؛ Canic شاید در آینده تخصیص فیزیکی، نصب، ذخایر چرخه و شواهد زیرساخت را بر عهده بگیرد. بخش دشوار، ترسیم این مرز نیست؛ اثبات آن هنگام خرابی و ارتقاست.

برچسب‌هاInternet ComputerICPCanicOpenChat
منابع مستند۳ مرجع
  1. [۰۱]Canic + OpenChat - my Astra experimentforum.dfinity.org ↗
  2. [۰۲]Canic repositorygithub.com ↗
  3. [۰۳]OpenChat architecture documentationgithub.com ↗
خواندنی بعدی

خبرخوان را در ایمیل بگیرید

هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.

خوراک RSS در دسترس · بدون هرزنامه