چنگال سخت Toccata Kaspa: Covenants، Opcodes ZK، و هدف جدید ژوئن

کاسپاهارد فورک آتی توکاتا، دو مسیر برنامه‌نویسی جدید را به شبکه اضافه خواهد کرد: برنامه‌نویسی بومی L1 و زیرساخت اپلیکیشن مبتنی بر دانش صفر (zk)، که فعال‌سازی شبکه اصلی آن اکنون برای ۵ تا ۲۰ ژوئن ۲۰۲۶ برنامه‌ریزی شده است و از هدف اولیه ۵ مه به تعویق افتاده است.

مایکل ساتون از کاسپا کور مطلبی منتشر کرد به‌روزرسانی دقیق در مورد اینکه هارد فورک شامل چه مواردی می‌شود، چرا تاریخ آن تغییر کرده و انتظار می‌رود چند ماه آینده چگونه پیش برود. این فورک در ابتدا توسط اوری نیومن به عنوان تلاشی برای وارد کردن پیمان‌ها به موتور اسکریپت کسپا، تا حدودی در پاسخ به بحث OP_CAT در محافل بیت کوین، آغاز شد. از آن زمان به چیزی به مراتب بزرگتر تبدیل شده است.

هارد فورک توکاتا چیست؟

توکاتا یک هارد فورک برنامه‌ریزی‌شده برای شبکه کسپا است که قابلیت‌های جدیدی را مستقیماً به لایه پایه معرفی می‌کند. هارد فورک، برای کسانی که کمتر با آن آشنا هستند، یک ارتقاء پروتکل است که با نسخه‌های قبلی سازگار نیست. همه گره‌ها برای ادامه مشارکت در شبکه باید ارتقا یابند.

این نام از سنت کاسپا در استفاده از ارجاعات موسیقی برای ارتقاءهای اساسی پیروی می‌کند. این قطعه نام خود را از یک فرم موسیقی کلاسیک، توکاتا، قطعه‌ای که برای نمایش مهارت فنی در یک ساز کیبوردی طراحی شده است، گرفته است.

در سطح بالا، توکاتا دو چیز به کاسپا اضافه می‌کند:

• برنامه‌نویسی پیمانی بومی L1 از طریق یک کامپایلر جدید به نام Silverscript
• زیرساخت کاربردی مبتنی بر zk، ساخته شده بر روی همان پایه‌های عهد و پیمان

اینها سیستم‌های قابل تعویضی نیستند. آنها موارد استفاده متفاوتی را ارائه می‌دهند و مخاطبان توسعه‌دهنده متفاوتی را هدف قرار می‌دهند.

میثاق‌ها چیستند و چرا برای کسپا اهمیت دارند؟

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

کاسپا از یک مدل UTXO، مشابه بیت‌کوین، استفاده می‌کند که در آن هر تراکنش خروجی‌های موجود را مصرف کرده و خروجی‌های جدیدی ایجاد می‌کند. پیمان‌ها در یک سیستم UTXO به توسعه‌دهندگان اجازه می‌دهند جریان‌های چندقراردادیِ حالت‌مندِ شگفت‌انگیز و پیچیده‌ای بسازند، حتی اگر محاسبات اساسی برای هر UTXO محلی باقی بماند.

برای اینکه توسعه‌ی پیمان‌نامه‌ها قابل دسترس‌تر شود، Kaspa Core در حال نهایی کردن Silverscript است، کامپایلری که توسط Ori Newman، Michael Sutton، IzioDev و Manyfest آغاز شده است. Silverscript به گونه‌ای طراحی شده است که نوشتن و پیاده‌سازی پیمان‌نامه‌های پیچیده را مستقیماً در Kaspa L1 آسان‌تر و ایمن‌تر کند، بدون اینکه توسعه‌دهندگان نیاز به کار در سطح موتور اسکریپت خام داشته باشند.

اپلیکیشن‌های مبتنی بر دانش صفر چیستند؟

دومین رکن قابلیت برنامه‌ریزی که در توکاتا معرفی شده است، برنامه‌های مبتنی بر zk است. این مورد از نظر فنی پیچیده‌تر است و ارزش بررسی دقیق را دارد.

پروژه‌های امیدبخش را کشف کنید...

پروژه‌های نویدبخش ...

(تبلیغات)

ادامه مقاله...

ZK مخفف zero-knowledge است، یک روش رمزنگاری که به یک طرف اجازه می‌دهد بدون افشای داده‌های زیربنایی، صحت چیزی را اثبات کند. اثبات‌های ZK به طور فزاینده‌ای در مقیاس‌پذیری بلاکچین مورد استفاده قرار می‌گیرند زیرا امکان تأیید محاسبات خارج از زنجیره را به صورت ارزان و ایمن در داخل زنجیره فراهم می‌کنند.

«مبتنی» در این زمینه به این معنی است که سیستم zk به طور کامل از توالی L1 پیروی می‌کند. یک برنامه zk مبتنی بر نمی‌تواند تراکنش‌ها را به طور مستقل اضافه یا حذف کند. این برنامه به ترتیب تراکنش‌های خود Kaspa متصل است، که همین امر باعث می‌شود بدون نیاز به یک توالی‌یاب جداگانه، قابل اعتماد باشد.

توکاتا چندین مؤلفه را برای پشتیبانی از این امر معرفی می‌کند:

• کدهای عملیاتی تأیید ZKشامل یک تأییدکننده انعطاف‌پذیر Groth16 و یک تأییدکننده RISC Zero STARK
• یک کد عملیاتی دسترسی به تعهد توالیو برنامه‌های کاربردی مبتنی بر آن را قادر می‌سازد تا خود را به ترتیب L1 متصل کنند.
• KIP-21یک معماری تعهد توالی پارتیشن‌بندی شده که تضمین می‌کند هزینه‌های اثبات یک برنامه zk با فعالیت خودش مقیاس‌پذیر باشد، نه با فعالیت کلی DAG

تأییدکننده RISC Zero STARK در حال حاضر پیاده‌سازی و روی شبکه آزمایشی ۱۲ فعال شده است. اینکه آیا روی شبکه اصلی فعال می‌شود یا خیر، هنوز در دست تصمیم‌گیری است.

چرا اثبات هزینه‌ها اهمیت دارد

برای اینکه هر برنامه zk کاربردی باشد، هزینه تولید اثبات‌ها باید متناسب با کاری باشد که خود برنامه انجام می‌دهد. اگر یک برنامه zk مجبور باشد نسبت به تمام فعالیت‌های روی DAG گسترده‌تر، کار را اثبات کند، هزینه‌ها غیرقابل پیش‌بینی و غیرقابل مدیریت می‌شوند. KIP-21 این مشکل را با تقسیم‌بندی تعهدات توالی حل می‌کند و حجم کاری هر برنامه را مستقل نگه می‌دارد.

چه چیزی از قبل وجود دارد؟

بخش قابل توجهی از هارد فورک در حال حاضر پیاده‌سازی شده است. ویژگی‌های زیر از قبل ساخته شده‌اند:

• پشتیبانی گسترده از کد عملیاتی موتور اسکریپت، ستون فقرات پیمان‌های اصلی، تحت KIP-17
• شناسه‌های پیمان برای مدیریت دودمان به عنوان یک ویژگی اجماع و موتور، تحت KIP-20
• کدهای عملیاتی ZK با یک زیرسیستم پیش‌کامپایل تأییدکننده zk، تحت KIP-16، نوشته شده توسط الکساندر سافستروم
• کد عملیاتی دسترسی تعهد توالی
• KIP-21، نوشته شده توسط ساتون و پیاده‌سازی شده توسط ماکسیم بیریوکوف، به‌طور کامل پیاده‌سازی شده و در انتظار بررسی است

نقاط عطف اثبات مفهوم، از جمله پیمان‌های درون‌خطی zk و پیمان‌های مبتنی بر zk با یک پل متعارف KAS، نیز توسط Maxim تکمیل شده‌اند و در شکل‌دهی به طراحی نهایی این چنگال نقش مهمی داشته‌اند.

چرا تاریخ هارد فورک به ژوئن منتقل شد؟

هدف اصلی شبکه اصلی ۵ مه ۲۰۲۶ بود. از آن زمان به بازه زمانی ۵ تا ۲۰ ژوئن ۲۰۲۶ تغییر یافته است.

دلیل آن معماری است. زمانی که مدارها و زمان‌های اجرا zk به یک ساختار هشینگ تعهد توالی متصل می‌شوند، هرگونه تغییر ساختاری پس از آن به تغییرات مخرب تبدیل می‌شود. اشتباه در طراحی و اصلاح آن در آینده بسیار مخرب‌تر از صرف زمان اضافی در حال حاضر خواهد بود.

KIP-21 از قبل طوری طراحی شده است که با طرح تعهدی که در نهایت توسط vprogs، نقشه راه بلندمدت Kaspa برای برنامه‌های قابل تأیید با قابلیت ترکیب همزمان، مورد نیاز خواهد بود، در آینده سازگار باشد. تثبیت ساختار مناسب قبل از فعال‌سازی شبکه اصلی، از مهاجرت‌های پرهزینه بعدی جلوگیری می‌کند.

انتظار می‌رود این ویژگی در ۱۵ آوریل ۲۰۲۶ غیرفعال شود.

بین توقف ویژگی‌ها و شبکه اصلی چه اتفاقی می‌افتد؟

پس از توقف ارائه ویژگی‌ها در ۱۵ آوریل، Kaspa Core قصد دارد شبکه آزمایشی اختصاصی، TN12، را مجدداً راه‌اندازی کند و مجموعه کامل ویژگی‌های نهایی را در آن بگنجاند. این یک شبیه‌سازی از گذار هارد فورک نیست. این یک شبکه تمیز برای آزمایش مجموعه کامل ویژگی‌ها در شکل نهایی آن است.

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

پس از اتمام این کار، یک هارد فورک آزمایشی روی TN10، شبکه آزمایشی بلندمدت، اجرا خواهد شد تا یک گذار کامل به سبک شبکه اصلی را شبیه‌سازی کند. تاریخ شبکه اصلی تنها پس از اجرای آزمایشی و تا رسیدن به رضایت تیم، به صورت کدنویسی شده ارائه خواهد شد.

آنچه اپراتورهای گره باید انتظار داشته باشند

برای ماینرها و اپراتورهای گره، این ارتقا به گونه‌ای طراحی شده است که ساده باشد. گره‌ها باید به‌روزرسانی شوند و عملکردهای موجود باید به کار خود ادامه دهند. انتظار می‌رود فضای دیسک مورد نیاز تقریباً 20 تا 50 درصد افزایش یابد. هیچ تغییر زیرساختی چشمگیری پیش‌بینی نمی‌شود.

آنچه توکاتا واقعاً برای کاسپا ارائه می‌دهد

توکاتا دو سیستم برنامه‌نویسی کاربردی را به لایه پایه کسپا اضافه می‌کند: اسکریپت‌نویسی بومی L1 از طریق Silverscript و زیرساخت برنامه کاربردی zk مبتنی بر KIP-16، KIP-20 و KIP-21. بخش بزرگی از کار فنی از قبل انجام شده است. آنچه باقی مانده است، نهایی کردن رابط‌ها، ادغام شاخه در حال انتظار در شاخه اصلی و اجرای یک تمرین کامل روی TN10 قبل از تأیید تاریخ شبکه اصلی است.

بازه زمانی ۵ تا ۲۰ ژوئن ۲۰۲۶ به این دلیل وجود دارد که تیم تصمیم گرفت معماری تعهد توالی‌یابی را از همان ابتدا به درستی پیاده‌سازی کند، نه اینکه بعداً آن را در شرایط عملیاتی اصلاح کند. برای اپراتورهای گره، ارتقاء به گونه‌ای طراحی شده است که ساده باشد و هیچ تغییر زیرساختی عمده‌ای فراتر از افزایش اندک فضای دیسک وجود نداشته باشد.

منابع

1. کسپا روی ایکس: پست (آوریل، ۲۰۲۶)

2. مقاله وبلاگ از مایکل ساتون: Kaspa Covenants++ "Toccata" Hard-Fork Outlook