توسعه‌دهندگان ریپل‌ایکس (RippleX) در حال اعمال راستی‌آزمایی رسمی (Formal Verification) بر روی سیستم وام‌دهی بومی برنامه‌ریزی شده دفتر کل XRP (XRPL) پیش از فعال‌سازی شبکه اصلی (Mainnet) هستند. این شامل پروتکل وام‌دهی XLS-66 و خزانه‌های تک دارایی XLS-65 می‌شود.

«وت» (Vet)، اعتبارسنج بنیاد XRPL، پس از اینکه ویتو توماس (Vito Tumas)، مهندس ریپل، بخش دوم سری راستی‌آزمایی RippleX را به اشتراک گذاشت، توجه را به این بررسی جلب کرد. هدف آن یافتن نقص‌هایی است که ممکن است آزمایش‌های معمولی از دست بدهند.

ریپل راستی‌آزمایی رسمی را برای وام‌دهی XRPL به کار می‌برد

توماس گفت: «هنگامی که دیفای (DeFi) را مستقیماً در لایه ۱ (Layer-1) می‌سازید، آزمایش سنتی کافی نیست.» تست‌های استاندارد سناریوهایی را بررسی می‌کنند که توسعه‌دهندگان انتظار دارند. راستی‌آزمایی رسمی از مدل‌های ریاضی برای بررسی اینکه آیا یک سیستم می‌تواند وارد حالت‌های نامعتبر شود یا خیر، استفاده می‌کند.

ریپل در حال همکاری با شرکت تحقیقات پروتکل کامن پریفیکس (Common Prefix) است. این تیم‌ها یک مدل انتزاعی از رفتار مورد نظر ایجاد می‌کنند و از روش‌های قابل بررسی توسط ماشین برای آزمایش قوانین ایمنی قبل از مقایسه نتایج با پیاده‌سازی xrpld استفاده می‌کنند.

وت این کار را بخشی از ساخت «قلعه XRP» توصیف کرد. او گفت که پروتکل وام‌دهی در حال دریافت یک بررسی بر اساس روش‌های مورد استفاده برای نرم‌افزارهای پرخطر است. این برچسب ارزیابی اوست، نه گواهینامه.

وام‌دهی لایه ۱ هزینه خطاهای کدنویسی را افزایش می‌دهد

XRPL قصد دارد توابع وام‌دهی را به جای وابستگی به قراردادهای هوشمند جداگانه، درون پروتکل پایه خود قرار دهد. این طراحی می‌تواند دسترسی را ساده‌تر کند، اما نقصی در کد اصلی می‌تواند بر هر برنامه‌ای که از این ویژگی استفاده می‌کند، تأثیر بگذارد.

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

RippleX قبلاً گفته بود که روش‌های رسمی می‌توانند عدم وجود دسته‌های تعریف‌شده‌ای از باگ‌ها را اثبات کنند، نه اینکه فقط نشان دهند موارد آزمایش‌شده کار کرده‌اند. این فرآیند نمی‌تواند اثبات کند که نرم‌افزار هیچ ضعفی ندارد زیرا هر اثبات به مدل و ویژگی‌های انتخاب شده بستگی دارد.

این بررسی به دنبال یک مورد امنیتی قبلی XRPL مربوط به تراکنش‌های دسته‌ای (Batch transactions) است. نسخه ۳.۱.۱ پشتیبانی از تراکنش‌های دسته‌ای را پس از اینکه پرانامیا کشکامات (Pranamya Keshkamat) و کانتینا هوش مصنوعی (Cantina AI) نقصی را در اصلاحیه پیشنهادی یافتند، غیرفعال کرد.

XLS-66 هنوز پیش از فعال‌سازی به پشتیبانی اعتبارسنج‌ها نیاز دارد

XLS-66 امکان وام‌های بدون وثیقه و با مدت ثابت را فراهم می‌کند که از طریق خزانه‌های تک دارایی (Single Asset Vaults) تأمین می‌شوند. کارگزاران وام شرایط را تعیین کرده و ریسک را مدیریت می‌کنند، در حالی که ارزیابی ریسک اعتباری خارج از زنجیره، وام‌گیرندگان را پیش از انتقال وجوه به روی زنجیره ارزیابی می‌کند.

این طراحی شامل سرمایه اختیاری «اولین زیان» (first-loss capital) برای جذب بخشی از نکول پیش از متحمل شدن ضرر توسط سپرده‌گذاران خزانه است. همچنین از XRP و دارایی‌های صادر شده پشتیبانی می‌کند، در حالی که کنترل‌های انطباق می‌توانند توکن‌های واجد شرایط را مسدود یا بازپس‌گیرند.

نسخه ۳.۱.۰ XRPL در ماه ژانویه پشتیبانی از اصلاحات وام‌دهی و خزانه را اضافه کرد. این ویژگی‌ها همچنان تابع فرآیند اصلاحیه هستند و نمی‌توانند فعال شوند مگر اینکه اعتبارسنج‌ها پشتیبانی لازم را حفظ کنند.

همانطور که قبلاً توسط crypto.news گزارش شده بود، دفتر کل XRP نسخه ۳.۲.۰ انتشار در ۱۵ ژوئن را هدف قرار داده و نرم‌افزار سرور اصلی شبکه را از rippled به xrpld تغییر نام خواهد داد. این ارتقاء به دنبال نسخه ۳.۱.۳ است که اصلاحات حسابداری و ثابت‌های (invariant fixes) لازم برای خزانه‌ها و ابزارهای وام‌دهی را اضافه کرد.

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