نسخهای در دل هر اثبات: تغییرات snarkVM 4.0.0 آلئو برای توسعهدهندگان ZK
snarkVM 4.0.0 آلئو، نسخهبندی رکوردها و فراداده رمزنگاریشده فرستنده را به مرزهای واقعی پروتکل تبدیل میکند؛ تغییری که تکامل اپلیکیشنهای خصوصی را آسانتر، اما ارتقای آنها را حساستر میسازد.

snarkVM 4.0.0 آلئو یادآوری میکند که زیرساخت دانش صفر فقط به اثبات محاسبه محدود نمیشود. نحوه سریالسازی، ارتقا، ایندکسگذاری و بازیابی وضعیت خصوصی نیز بخشی از مسئله تولیدی آن است.
این نسخه فیلد _version را به رکوردها اضافه میکند. رکوردهایی که پس از ConsensusVersion::V8 ساخته شوند نسخه ۱ دارند، در حالی که رکوردهای قدیمی نسخه ۰ باقی میمانند. به این ترتیب، آلئو راهی رسمی برای تمایز میان وضعیت خصوصی قدیمی و رکوردهای ساختهشده با قواعد جدید ایجاد میکند.
این تفاوت مهم است، چون مدل رکورد آلئو وضعیت و مالکیت رمزنگاریشده اپلیکیشن را روی زنجیره نگه میدارد. رکورد بیشتر شبیه یک UTXO خصوصی و قابلبرنامهریزی است تا یک موجودی ساده حساب. وقتی قالب آن تغییر میکند، کیفپولها، SDKها، ایندکسرها، سازندگان تراکنش و ابزارهای بازیابی همگی در دامنه مهاجرت قرار میگیرند.
آشکارترین تغییر حریم خصوصی، فیلد رمزنگاریشده فرستنده است. رکوردهای خروجی جدید میتوانند sender_ciphertext داشته باشند و به گیرنده اجازه دهند با استفاده از کلید مشاهده حساب، آدرس فرستنده را استخراج کند. این قابلیت فرستنده را بهصورت عمومی آشکار نمیکند؛ بلکه امکان کشف انتخابی اطلاعات برای گیرنده را فراهم میسازد و مدل انتقال خصوصی را حفظ میکند.
برای توسعهدهندگان، این تغییر فقط یک بهینهسازی رمزنگاری نیست؛ بلکه تغییر در API و سریالسازی است. Request::InputID برای ورودیهای رکوردی دارای فیلد record_view_key میشود و Transition::Output برای خروجیهای رکوردی فیلد اختیاری sender_ciphertext را دریافت میکند. برنامههای مستقر روی زنجیره نیز به کلیدهای تأیید بهروزشده منتقل میشوند و به edition 1 نیاز دارند.
درس عملی این است که اپلیکیشنهای ZK به انضباط صریح در طرح داده نیاز دارند. کیفپولی که فقط رکوردهای نسخه ۰ را بشناسد ممکن است نتواند وضعیت جدید را درست نمایش دهد یا خرج کند. ایندکسری که فرض کند همه خروجیها شکل یکسانی دارند، ممکن است تراکنشها را نادرست پردازش کند. سرویس اثباتی که editionهای قدیمی برنامه را ثابت نگه دارد، ممکن است خروجیهایی تولید کند که دیگر با قواعد فعال شبکه سازگار نیستند.
این نسخه همچنین روش دریافت برنامههای مستقر را تغییر میدهد: block_store().get_latest_program برای دریافت جدیدترین edition برنامه طراحی شده است، در حالی که روش قدیمی همان رفتار آگاه از ارتقا را ارائه نمیکند. این تغییر در نگاه اول کوچک است، اما برای ابزارهایی که بر اساس برنامههای مستقر کامپایل، ممیزی یا اثبات تولید میکنند پیامد بزرگی دارد.
زاویه گستردهتر ZK همینجاست. سیستمهای خصوصی اغلب مانند ریاضیات تغییرناپذیر معرفی میشوند، اما حریم خصوصی در محیط تولید به مرزهای نرمافزاری پیرامون آن ریاضیات وابسته است. رکوردهای نسخهبندیشده، فراداده رمزنگاریشده، editionهای کلید تأیید و کوئریهای آگاه از ارتقا، سازوکارهایی هستند که به یک پروتکل خصوصی اجازه میدهند بدون وادار کردن هر اپلیکیشن به حدسزدن معنای بایتها تغییر کند.
مرز ایمنی مهم است: یادداشت انتشار گیتهاب تغییرات ناسازگار را توضیح میدهد، اما مهلت کامل مهاجرت در سراسر شبکه را مشخص نمیکند. توسعهدهندگان باید پیش از ارتقا، وضعیت استقرار را با آلئو یا Provable تأیید کنند. بنابراین تیمهایی که snarkVM را یکپارچه میکنند باید نسخهها را قفل کنند، هر دو نسل رکورد را آزمایش کنند، سریالایزرها را بهروزرسانی کنند و مطمئن شوند کیفپولها و ایندکسرهایشان با sender_ciphertext بهصورت آگاهانه برخورد میکنند، نه اینکه آن را صرفاً دادهای ناشناخته فرض کنند.
خبرخوان را در ایمیل بگیرید
هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.


