Moxzi منشأ ساخت را به یک قابلیت کنیستر تبدیل می‌کند

یک پروژه جدید در جامعه Internet Computer در حال آزمودن ایده‌ای نامتعارف است: خود کامپایلر می‌تواند به‌عنوان یک کنیستر اجرا شود.

نسخه آلفای عمومی Moxzi یک زنجیره‌ابزار self-hosted برای Motoko است. کامپایلر آن با Motoko نوشته شده، به WebAssembly کامپایل می‌شود و برای اجرا در چند میزبان طراحی شده است؛ از جمله رابط خط فرمان محلی، مرورگر، سرور و کنیستر Internet Computer. طبق مستندات پروژه، در همه این محیط‌ها از همان WebAssembly کامپایلر استفاده می‌شود.

زاویه مهم برای توسعه‌دهندگان، منشأ آرتیفکت است. با دستور moxzi build --remote، فایل‌های منبع به یک سازنده روی‌زنجیره ارسال می‌شوند، کامپایل از طریق دنباله‌ای از پیام‌های کنیستر انجام می‌گیرد و در پایان آرتیفکت WebAssembly برگردانده می‌شود. سپس می‌توان ساخت محلی را با نتیجه روی‌زنجیره مقایسه کرد. مستندات Moxzi خروجی بایت‌به‌بایت یکسان را هدف می‌دانند: توسعه‌دهنده می‌تواند آرتیفکت را از روی منبع دوباره تولید و ماژول کامپایلر استفاده‌شده را بررسی کند.

این رویکرد معنای «ساخت قابل‌تکرار» را برای برنامه‌های کنیستری تغییر می‌دهد. در ساخت‌های قابل‌تکرار معمول، چند ماشین مستقل باید زنجیره‌ابزارهای معادل را اجرا کنند. سازنده روی‌زنجیره، یک محل اجرای عمومی و یک رابط کنیستر قابل‌ممیزی نیز به این فرایند اضافه می‌کند. این قابلیت می‌تواند برای DAOها، سرویس‌های ساخت و سامانه‌های استقرار مفید باشد؛ به‌خصوص جایی که انتقال قابل‌اثبات از کد منبع به Wasm قابل نصب اهمیت دارد.

طراحی Moxzi محدودیت‌های Internet Computer را نیز در نظر می‌گیرد. یک کامپایل بزرگ را نمی‌توان به‌صورت یک فراخوانی طولانی اجرا کرد؛ بنابراین سازنده کار را از طریق تعداد زیادی پیام به‌روزرسانی معمولی پیش می‌برد. این روش کندتر است، اما فرایند را در محدودیت‌های اجرای کنیستر نگه می‌دارد. مرجع CLI همچنین فرمانی برای راستی‌آزمایی فقط‌خواندنی ساخت راه‌دور و بررسی سازگاری ارتقا دارد؛ نشانه‌ای از گردش‌کاری که در آن کامپایل و بازبینی ارتقا به مراحل قابل‌بررسی تبدیل می‌شوند.

توسعه‌دهندگان باید مرز این ادعا را روشن نگه دارند. Moxzi یک پروژه آلفای جامعه است و جایگزین زنجیره‌ابزار رسمی Internet Computer نیست؛ ادعاهای مربوط به سازگاری و بازتولیدپذیری آن از مستندات پروژه و گفت‌وگوی معرفی آن می‌آیند، نه از یک ممیزی مستقل. تیم‌ها باید هش کامپایلر، مجموعه دقیق منابع، خروجی‌های بازتولیدشده محلی و آزمون‌های ارتقا را پیش از استفاده از سازنده راه‌دور برای استقرار تولیدی ثبت و تثبیت کنند.

حتی پیش از تبدیل‌شدن به زیرساخت تولیدی، این آزمایش ارزشمند است: در ICP، کامپایلر می‌تواند به‌عنوان منطق برنامه مستقر شود. در نتیجه، منشأ ساخت از یک دغدغه صرفاً محلی به بخشی از معماری کنیستر تبدیل می‌شود.