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

کوین‌دسک در ۱۹ سپتامبر گزارش داد که آیو آکینیل، رئیس مهندسی RippleX، گفت کارهایی شامل مدیران دارایی در حال آماده‌سازی حول محور بچ V1.1 است که می‌تواند تا هشت تراکنش را در یک عملیات بچ واحد بسته‌بندی کند. ریپل هنوز نام مدیران دارایی را علناً فاش نکرده و تاریخ‌های قطعی راه‌اندازی را نیز اعلام نکرده است.

داده‌های اصلاحیه زنده که در ۲۰ سپتامبر بررسی شد، نشان داد که ۳۰ از ۳۵ اعتبارسنج معتبر ردیابی شده از بچ V1.1 حمایت می‌کنند. لجر XRP برای فعال شدن یک اصلاحیه، حداقل ۸۰ درصد حمایت را به مدت ۱۴ روز متوالی لازم دارد که آستانه فعلی را ۲۸ رأی تعیین می‌کند. شمارش معکوس در ۱۵ سپتامبر ساعت ۱۴:۰۶:۴۱ به وقت جهانی (UTC) آغاز شد و در صورت حفظ حمایت، به فعال‌سازی احتمالی بلافاصله پس از همین زمان در ۲۹ سپتامبر اشاره دارد.

بچ V1.1 لجر XRP می‌تواند مراحل تسویه را به هم پیوند دهد

مشخصات XLS-56، بچ را به عنوان تراکنشی تعریف می‌کند که بین دو تا هشت تراکنش داخلی را بسته‌بندی می‌کند. این قابلیت از چهار حالت پردازش پشتیبانی می‌کند: همه یا هیچ (All or Nothing)، فقط یک (Only One)، تا زمان شکست (Until Failure) و مستقل (Independent). تنظیم "همه یا هیچ" مستلزم آن است که کل گروه با موفقیت اجرا شود یا از تأثیرگذاری بچ جلوگیری می‌کند.

ریپل بخشی از بحث تجاری را بر روی پرداخت در برابر تحویل (delivery-versus-payment) یا DvP متمرکز کرده است. در چنین تراکنشی، یک انتقال دارایی و پرداخت آن می‌تواند در همان عملیات اتمی قرار گیرد. یک پرداخت ناموفق، از تکمیل انتقال دارایی مرتبط تحت تنظیم "همه یا هیچ" جلوگیری می‌کند.

آکینیل به کوین‌دسک گفت: "ما جزئیات بیشتری را پس از فعال شدن این ویژگی، از جمله همکاری با مدیران دارایی کلیدی، به اشتراک خواهیم گذاشت." ریپل هنوز این شرکت‌ها را شناسایی نکرده است، بنابراین این بیانیه همچنان توصیفی شرکتی از کاری است که هنوز به طور عمومی از طریق اعلامیه‌های شرکای نام‌برده، مستند نشده است.

مشخصات XLS-56، مواردی مانند مبادلات چندحسابی بدون نیاز به اعتماد (trustless multi-account swaps)، کارمزدهای پلتفرم و ساختارهای وام‌های فلش (flash-loan) را از جمله کاربردهای بالقوه برشمرده است. برای مثال، یک بازار یا کیف پول می‌تواند پرداخت مشتری را همراه با هزینه خدمات بسته‌بندی کند، به جای اینکه نیاز به تراکنش‌های جداگانه باشد، در حالی که حساب‌های مختلف می‌توانند مراحل جداگانه همان بچ را تأیید کنند.

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

حمایت اعتبارسنج‌ها پنجره ۲۹ سپتامبر را باز نگه می‌دارد

بر اساس آخرین قرائت در ۲۰ سپتامبر، بچ V1.1 دارای ۳۰ رأی حمایتی از بین ۳۵ اعتبارسنج ردیابی شده توسط XRPLDashboard بود که تقریباً معادل ۸۵ درصد است. بنابراین، حمایت بالای آستانه ۲۸ رأی مورد نیاز برای ادامه پنجره فعال‌سازی باقی ماند.

تاریخ پیش‌بینی شده ۲۹ سپتامبر مشروط است. اصلاحات XRPL صرفاً با یک بار عبور از ۸۰ درصد فعال نمی‌شوند. اعتبارسنج‌ها باید اکثریت قاطع را برای کل دوره ۱۴ روزه حفظ کنند، و اعتبارسنج‌ها می‌توانند آرای خود را در حین اجرای شمارش معکوس تغییر دهند. اگر حمایت به زیر سطح مورد نیاز کاهش یابد، پنجره فعلی متوقف می‌شود و پس از بازیابی آستانه، یک دوره بدون وقفه دیگر لازم خواهد بود.

آخرین شمارش، افزایش سریع حمایت در این ماه را نشان می‌دهد. بچ V1.1 در آن زمان ۲۴ رأی از ۳۵ رأی اعتبارسنجی را داشت، یا ۶۸.۵۷ درصد، که آن را پایین‌تر از آستانه فعال‌سازی قرار می‌داد. حمایت تا ۱۵ سپتامبر به ۲۷ رأی افزایش یافته بود، قبل از اینکه به اندازه کافی اعتبارسنج از این اصلاحیه برای شروع شمارش معکوس حمایت کنند.

خود این اصلاحیه در ۶ آگوست همراه با نسخه 3.3.0 xrpld عرضه شد. یادداشت‌های رسمی انتشار XRP Ledger، بچ V1.1 را به عنوان جایگزین اصلاحیه اصلی Batch توصیف می‌کنند و بیان می‌کنند که این قابلیت تا هشت تراکنش داخلی، از جمله ساختارهای مبادله اتمی (atomic-swap)، را پشتیبانی می‌کند.

از آن زمان، بنیاد XRP Ledger نسخه 3.4.0 xrpld را منتشر کرده است. انتشار نرم‌افزاری ۱۶ سپتامبر اصلاحیه‌های جداگانه وام‌دهی و پاک‌سازی را معرفی می‌کند و جایگزین بچ V1.1 نمی‌شود، که همچنان در فرآیند رأی‌گیری شبکه اصلی (mainnet) خود باقی مانده است. به اپراتورهای سرور توصیه شد برای تداوم خدمات، به نسخه 3.4.0 ارتقا دهند.

بچ V1.1 در پی یک نقص بحرانی در نسخه اول آمد

اصلاحیه فعلی پس از آن ارائه شد که توسعه‌دهندگان پیشنهاد اصلی Batch را در ماه فوریه متوقف کردند. افشای رسمی آسیب‌پذیری XRPL می‌گوید پرانامیا کشکامات، محقق امنیتی، و ابزار Apex از Cantina AI، یک نقص بحرانی در اعتبارسنجی امضا را در ۱۹ فوریه شناسایی کردند.

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

این نقص هرگز در شبکه اصلی XRP Ledger فعال نشد. اصلاحیه اصلی هنوز در مرحله رأی‌گیری بود، و XRPL Labs گفت که هیچ سرمایه‌ای در خطر نبود. به اعتبارسنج‌ها توصیه شد که علیه آن رأی دهند، در حالی که نسخه 3.1.1 ریپلد (rippled)، که در ۲۳ فوریه منتشر شد، Batch و fixBatchInnerSigs را غیرقابل پشتیبانی کرد تا نتوانند فعال شوند.

سپس توسعه‌دهندگان منطق امضا و مجوز را برای جایگزینی تغییر دادند. گزارش آسیب‌پذیری بیان کرد که اصلاحات، شرط موفقیت زودهنگام را حذف کرده، محافظ‌های مجوز را اضافه کرده و قوانین بررسی امضا را سخت‌تر کرده است. بچ V1.1 بعدها پس از توسعه و بررسی، در xrpld 3.3.0 گنجانده شد.

کار امنیتی قبل از رأی‌گیری فعلی اعتبارسنج‌ها ادامه یافت. وب‌سایت Ascrypto.news در پوشش بررسی امنیتی بچ V1.1 خود گزارش داد که توسعه‌دهندگان ۱۱ مشکل دیگر مربوط به امضاها، بررسی‌های مجوز و سقوط احتمالی سرور را قبل از رسیدن اصلاحیه به مرحله رأی‌گیری فعلی خود، برطرف کردند.

آکینیل به کوین‌دسک گفت که این بررسی شامل تست‌های خصمانه داخلی، تحلیل با کمک هوش مصنوعی، یک مسابقه امنیتی شرلوک و ارزیابی‌هایی با مشارکت Halborn و Common Prefix بود. کوین‌دسک این جزئیات را به RippleX نسبت داد؛ گزارش‌های عمومی شرکا که هر بخش از آن بررسی را پوشش می‌دادند، در مطالب بررسی شده برای این گزارش گنجانده نشده بود.

اکوسیستم توسعه‌دهنده XRPL با تکامل طراحی امضا، تغییرات پشتیبانی‌کننده را اعمال کرد. یک مشکل در ژوئن در مخزن رسمی xrpl.js مستند کرد که منطق قدیمی امضای Batch با فرمت بازبینی شده بچ V1.1 مطابقت نداشت زیرا اطلاعات اضافی حساب و توالی به امضاها مرتبط شده بود. تاریخچه انتشار باینری-کدک جاوا اسکریپت بیان می‌کند که پشتیبانی از امضای بچ V1.1 در نسخه 2.9.0 در ماه آگوست اضافه شد.

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

اظهارات ریپل در مورد Batch در حالی مطرح می‌شود که شرکت‌های مالی و توسعه‌دهندگان از زیرساخت لجر XRP برای دارایی‌های توکن‌سازی شده و پروژه‌های تسویه نهادی استفاده می‌کنند. در ماه ژوئن، جی‌پی‌مورگان، مسترکارت، اوندو فایننس و ریپل در آزمایشی برای بازخرید خزانه‌داری توکن‌سازی شده ایالات متحده با استفاده از XRP Ledger شرکت کردند.

مونیکا لانگ، رئیس ریپل، در ماه آگوست گفت که مؤسسات مالی در حال انتقال برخی کارهای مربوط به دارایی‌های توکن‌سازی شده از برنامه‌های آزمایشی به سمت تولید هستند. وب‌سایت Crypto.news در مورد پروژه‌های توکن‌سازی نهادی ریپل گزارش داد که Aviva Investors یک رده سهام صندوق توکن‌سازی شده را در ماه جولای در XRPL راه‌اندازی کرده بود و ریپل RLUSD را به عنوان یک پایه نقدی ممکن برای تسویه اتمی پرداخت در برابر تحویل (delivery-versus-payment) می‌دید.

فعالیت دارایی‌های درون زنجیره‌ای (Onchain) همراه با این توسعه رشد کرده است. یک بررسی دیگر از داده‌های RWA لجر XRP توسط crypto.news در ماه جولای گزارش داد که این شبکه تقریباً ۲.۶ میلیارد دلار به ارزش دارایی‌های واقعی توکن‌سازی شده (real-world asset) در طول شش ماه، به استثنای استیبل‌کوین‌ها، بر اساس ارقام RWA.xyz اضافه کرده است. همان گزارش هشدار داد که ارزش دارایی‌های نشان داده شده و دارایی‌های فعالانه توزیع شده، معیارهای به طور قابل توجهی متفاوتی هستند.

خود بچ V1.1 مدیران دارایی را ملزم نمی‌کند که از XRP به عنوان دارایی در حال انتقال استفاده کنند. این ویژگی در لایه تراکنش عمل می‌کند و می‌تواند تراکنش‌های پشتیبانی شده XRPL را از حساب‌های مختلف بسته‌بندی کند. XRP برای کارمزدهای تراکنش لجر همچنان مرتبط است، در حالی که تراکنش‌های اساسی می‌توانند شامل سایر دارایی‌ها و ساختارهای توکن پشتیبانی شده باشند.

رویداد رویه‌ای بعدی، پایان پنجره اصلاحیه فعلی است. XRPLDashboard فعال‌سازی بچ V1.1 را برای ۲۹ سپتامبر در حدود ساعت ۱۴:۰۶:۴۱ به وقت جهانی (UTC) پیش‌بینی می‌کند، اگر حداقل ۸۰٪ حمایت اعتبارسنج‌ها در تمام طول شمارش معکوس بدون وقفه باقی بماند. آخرین آمار منتشر شده در ۲۰ سپتامبر، ۳۰ رأی موافق از ۳۵ اعتبارسنج ردیابی شده بود.