آخرین وضعیت ارتقای XRP: فعال‌سازی Batch در XRPL به ۹ اکتبر موکول شد؛ چه چیزی تغییر می‌کند؟

ارتقای XRP که قرار بود در ⁦29/09⁩ فعال شود، انجام نشد. اصلاحیه Batch در XRP Ledger که با نسخه اصلاح‌شده BatchV1_1 منتشر شده بود، در بازه کوتاهی حوالی ⁦25/09⁩ حمایت اعتبارسنج‌ها را از دست داد؛ اتفاقی که شمارش معکوس دو هفته‌ای آن را از ابتدا آغاز کرد و زودترین زمان فعال‌سازی را به ⁦09/10/2026⁩، حدود ⁦14:46 UTC⁩، موکول کرد. این مقاله توضیح می‌دهد Batch دقیقاً چه قابلیتی به دفترکل اضافه می‌کند، چرا افت کوتاه‌مدت آرا می‌تواند زمان‌سنج را صفر کند، اپراتورهای نود و توسعه‌دهندگان اپلیکیشن پیش از ⁦09/10⁩ چه کارهایی باید انجام دهند و این تأخیر چه نسبتی با بازار XRP دارد؛ بازاری که نزدیک ⁦$1.50⁩ معامله می‌شود و همچنان ⁦%59⁩ پایین‌تر از اوج خود در ⁦07/2025⁩ است.

آیا ارتقای XRP در ⁦29/09⁩ فعال شد؟

خیر. قرار بود BatchV1_1 در ⁦29/09⁩ و در ⁦14:06 UTC⁩ فعال شود، مشروط بر اینکه حمایت فهرست اعتبارسنج‌های مورد اعتماد برای دو هفته پیاپی بالاتر از ⁦%80⁩ باقی بماند. در ⁦25/09⁩، میزان حمایت برای مدت کوتاهی از این حد پایین‌تر رفت. فرایند اصلاحیه‌های XRPL افت آرا را نمی‌پذیرد: شمارش معکوس طی‌شده کنار گذاشته می‌شود و پس از بازگشت حمایت، یک بازه تازه دو هفته‌ای آغاز می‌شود. همان روز، حمایت دوباره به 30 اعتبارسنج از 35 اعتبارسنج مورد اعتماد رسید؛ به همین دلیل زودترین زمان فعال‌سازی جدید ⁦09/10⁩ است، نه تاریخی دیرتر.

دو مورد مرتبط دیگر هم جابه‌جا شدند. PermissionDelegationV1_1 که به یک حساب اجازه می‌دهد بدون واگذاری کلیدهای امضا، برخی مجوزهای مشخص را واگذار کند، در ⁦23/09⁩–⁦24/09⁩ حمایت خود را از دست داد و دوباره به دست آورد؛ اکنون زودترین زمان فعال‌سازی آن ⁦08/10⁩، حدود ⁦21:25 UTC⁩، است. همچنین در ⁦25/09⁩، تیم عملیات XRP Ledger نسخه xrpld 3.4.1 را منتشر کرد که اصلاحیه تکمیلی کوچکی با نام fixBatchV1_2 را در خود دارد. یادداشت‌های انتشار می‌گویند این اصلاحیه یک مشکل جزئی Batch را برطرف می‌کند که دارایی کاربران را در معرض خطر قرار نمی‌دهد؛ هر دو اصلاحیه با وضعیت default-yes مشخص شده‌اند و انتظار می‌رود در یک بازه اکتبر فعال شوند.

برداشت عملی این است: ⁦09/10⁩ زودترین زمان ممکن است، نه تاریخی قطعی. هر افت دیگری در میزان حمایت پیش از آن، شمارش را دوباره از ابتدا آغاز می‌کند.

Batch (BatchV1_1) در XRPL دقیقاً چه کاری انجام می‌دهد؟

Batch که در XLS-56 تعریف شده، به کاربر امکان می‌دهد 2 تا 8 تراکنش را در یک واحد امضاشده تجمیع کند تا دفترکل آن‌ها را با هم پردازش کند. در حال حاضر، یک سواپ که به یک آفر، یک پرداخت و تغییری در خط اعتماد نیاز دارد باید در قالب 3 تراکنش جداگانه ارسال شود؛ هرکدام از آن‌ها می‌توانند مستقل از بقیه موفق یا ناموفق شوند. Batch این خلأ را برطرف می‌کند.

این اصلاحیه 4 شیوه اجرا ارائه می‌دهد و انتخاب شیوه است که تضمین تسویه را تعیین می‌کند:

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

Batch از دسته‌های چندحسابی هم پشتیبانی می‌کند؛ در این حالت چند حساب یک بسته واحد را مشترکاً امضا می‌کنند. همین قابلیت باعث شد نسخه نخست کنار گذاشته شود و بازنویسی آن بیشترین اهمیت را دارد.

چرا Batch یک بار پس گرفته و بازنویسی شد؟

اصلاحیه اصلی Batch پس از آنکه پژوهشگران امنیتی در مرحله رأی‌گیری نقصی در مجوزدهی امضاکننده پیدا کردند، در ⁦02/2026⁩ رد شد. در منطق حلقه نسخه اولیه، اگر کد به امضاکننده معتبری می‌رسید که با یک حساب تازه‌ساخته‌شده مطابقت داشت، بدون بررسی امضاکنندگان باقی‌مانده موفقیت را برمی‌گرداند. مهاجم می‌توانست یک ورودی جعلی را در ابتدا قرار دهد و تراکنش قربانی را بدون کلیدهای او تأیید کند. از آنجا که اصلاحیه هرگز فعال نشد، هیچ دارایی‌ای در معرض خطر قرار نگرفت.

BatchV1_1 که در ⁦06/08/2026⁩ در نسخه xrpld 3.3.0 منتشر شد، مسیر مجوزدهی را بازنویسی می‌کند. اکنون یک دسته چندحسابی باید مجموعه دقیق و کاملی از BatchSigners را داشته باشد؛ هیچ ورودی مفقود، اضافه، تکراری یا جابه‌جاشده‌ای پذیرفته نیست. هر امضا به حساب بیرونی، شماره توالی یا تیکت آن، شیوه Batch، هش هر تراکنش داخلی و حساب‌های شرکت‌کننده متصل است؛ در نتیجه، استفاده مجدد از امضا در دسته‌های دیگر مسدود می‌شود. این بازنویسی همچنین محدودیت‌هایی برای تعداد تراکنش‌ها و محافظت‌هایی در برابر بازپخش دفترکل اضافه کرد.

هنگام خواندن تیترهای مربوط به «ارتقای XRP»، بهتر است این پیشینه را در نظر داشته باشیم. رسیدن این قابلیت به شبکه اصلی در تلاش دوم، پس از آنکه یک ممیزی بیرونی باگی واقعی را شناسایی کرد، درباره فرایند بازبینی دفترکل نشانه‌ای قوی‌تر از فعال‌سازی در تلاش نخست است. این موضوع همچنین توضیح می‌دهد چرا اعتبارسنج‌ها درباره زمان‌بندی محتاط‌اند: وقتی اختلاف فقط 5 اعتبارسنج از میان 35 اعتبارسنج است، یک اعتبارسنج با کنار گذاشتن رأی خود برای چند ساعت جهت به‌روزرسانی نرم‌افزار یا ارزیابی دوباره یک نسخه، می‌تواند به‌تنهایی زمان‌سنج دو هفته‌ای را از ابتدا آغاز کند.

اپراتورهای نود و توسعه‌دهندگان پیش از ⁦09/10⁩ چه باید بکنند؟

فعال‌شدن اصلاحیه در XRP Ledger برای زیرساخت‌ها اختیاری نیست. هر سرور xrpld که نسخه‌اش BatchV1_1 را درک نکند، به‌محض فعال‌شدن آن با اصلاحیه مسدود می‌شود و دیگر شبکه را دنبال نمی‌کند. حداقل نسخه موردنیاز 3.3.0 است؛ تیم عملیات استفاده از 3.4.1 را توصیه می‌کند، چون این نسخه مواردی را هم وصله می‌کند که یادداشت‌های انتشار آن‌ها را مسائل حساس امنیتی می‌خوانند؛ کد منبع قرار است بعداً منتشر شود.

آمادگی در سمت کلاینت ضعیف‌تر است. گزارشی از CryptoSlate در ⁦23/09⁩ نقاط شکست را توضیح داد:

• نسخه xrpl.js 5.0.0 امضاهای Batch را بر پایه داده‌پی‌لود قدیمی می‌سازد و با خطای temBAD_SIGNATURE رد می‌شود؛ نسخه 5.1.0 قالب امضای بازنگری‌شده را دارد.
• کیف‌پول‌هایی که تراکنش‌های داخلی یک دسته را به‌روشنی نمایش نمی‌دهند، باعث می‌شوند کاربران بسته‌هایی را امضا کنند که امکان بررسی آن‌ها را ندارند.
• کاوشگرهایی که نتیجه دسته‌ها را نادرست گزارش می‌کنند، باعث می‌شوند نمایش یک تراکنش در ابزارهای مختلف با هم تفاوت داشته باشد.
• تراکنش بیرونی Batch می‌تواند حتی زمانی که تراکنش‌های داخلی در حالت‌های غیراتمیک ناموفق شده‌اند، نتیجه موفقیت برگرداند؛ بنابراین اپلیکیشن‌ها باید نتیجه‌های داخلی را بخوانند، نه فقط کد بیرونی را.

آیو آکینیله، مدیر مهندسی RippleX، گفته است برخی پروژه‌ها از همین حالا با در نظر گرفتن Batch ساخته می‌شوند و فعال‌سازی آن می‌تواند این کارها را به مرحله تولید نزدیک‌تر کند. برداشت واقع‌بینانه از تقاضا همین است: Batch زیرساختی برای ناشران، متولیان دارایی و مدیران دارایی است که روی XRPL می‌سازند، نه قابلیتی خرده‌فروشی که کاربران از همان روز اول در کیف‌پول ببینند.

تأخیر چه معنایی برای قیمت XRP دارد؟

در ⁦30/09/2026⁩، XRP طبق داده‌های CoinGecko حدود ⁦$1.49⁩ معامله می‌شود؛ طی بیشتر از ⁦24⁩ ساعت ⁦%1.6⁩ رشد کرده، اما در هفت روز گذشته ⁦%5.1⁩ افت داشته است. حجم معاملات 24 ساعته حدود ⁦$4B⁩ و ارزش بازار نزدیک ⁦$94.3B⁩ است که رتبه پنجم را از نظر ارزش بازار دارد. در WEEX، جفت‌ارز اسپات XRP/USDT در همان تاریخ ⁦$1.4996⁩ ثبت کرد. این توکن همچنان حدود ⁦%59⁩ پایین‌تر از اوج تاریخی ⁦$3.65⁩ است که در ⁦07/2025⁩ ثبت شد.

نکته مهم‌تر این است که بازار در واکنش به تاریخ Batch در هیچ‌یک از دو جهت معامله نکرد. در روزی که CoinDesk خبر جابه‌جایی زمان به ⁦09/10⁩ را گزارش کرد، XRP کمتر از نیم درصد حرکت کرد. این با رفتار تاریخی اصلاحیه‌های XRPL سازگار است: دفترکل ده‌ها اصلاحیه را فعال کرده، اما هیچ‌کدام به‌تنهایی محرک قابل‌اتکایی برای قیمت نبوده‌اند. Batch ارتقایی زیرساختی برای نهادهاست و ارزش آن در گذر چند فصل و از طریق پروژه‌هایی که بر بسترش ساخته می‌شوند نمایان خواهد شد، نه در بسته‌شدن دفترکلی که امکان استفاده از آن را فراهم می‌کند.

معامله‌گران باتجربه XRP معمولاً به‌جای آن بررسی می‌کنند که آیا ارتقا با رویدادی همراه شده که جریان سرمایه را تغییر می‌دهد یا نه: ثبت ورود سرمایه به ETF، انتخاب XRPL از سوی یک ناشر جدید دارایی توکنیزه‌شده یا حرکت ریسک‌پذیری در کل بازار. افت هفتگی ⁦%5⁩ در آستانه این تأخیر، حرکتی فراگیر در بازار بود، نه واکنشی ویژه به XRP. اگر قرار باشد Batch باعث ارزیابی دوباره XRP شود، دلیلش عرضه محصولی قابل‌مشاهده روی این بستر خواهد بود؛ اتفاقی که در زودترین حالت، داستان بازه اکتبر تا دسامبر است.

چطور در بازه فعال‌سازی، XRP را در WEEX معامله کنیم؟

اگر قصد دارید تا ⁦09/10⁩ XRP را نگه دارید یا معامله کنید، بهتر است پیش از شروع این بازه موقعیت‌ها و هشدارهایتان را تنظیم کنید، نه اینکه پس از دیدن یک تیتر واکنش نشان دهید.

1. جفت‌ارز اسپات XRP/USDT در WEEX را باز کنید و پیش از تعیین حجم معامله، عمق لحظه‌ای دفتر سفارش را بررسی کنید؛ زیرا در روزهای انتشار خبر، فاصله قیمت خرید و فروش ممکن است برای مدتی بیشتر شود.
2. تازه‌وارد این دارایی هستید؟ راهنمای خرید XRP مراحل شارژ حساب و ثبت نخستین سفارش بازار یا سفارش محدود را توضیح می‌دهد.
3. معامله‌گرانی که بدون جابه‌جایی دارایی اسپات به‌دنبال موقعیت‌گیری در جهت بازار یا پوشش ریسک هستند، می‌توانند از قراردادهای آتی دائمی XRP/USDT در WEEX استفاده کنند که اهرم تا 300x ارائه می‌دهند. در آستانه یک رویداد شناخته‌شده، اهرم را پایین نگه دارید؛ حرکت هفتگی ⁦%5⁩ با اهرم 20x به لیکوییدشدن می‌انجامد، نه صرفاً افت ارزش موقعیت.
4. هشدارهای قیمت را نزدیک ⁦$1.40⁩ و ⁦$1.60⁩ تنظیم کنید که محدوده اخیر را مشخص می‌کنند و برای ⁦08/10⁩–⁦09/10⁩ به وقت UTC یادآوری بگذارید تا بررسی کنید آیا حمایت اعتبارسنج‌ها در کاوشگر XRPL همچنان بالاتر از ⁦%80⁩ است یا نه.
5. برای بررسی سریع روزانه قیمت، حجم و ارزش بازار، بدون بازکردن محیط معاملاتی، از صفحه قیمت XRP در WEEX استفاده کنید.

نمای بازار: Batch محرک سازندگان است، نه معامله‌گران

اهمیت Batch از این جهت است که XRPL را برای جریان‌های تحویل در برابر پرداخت و عملیات چندمرحله‌ای مورد انتظار نهادها از زیرساخت‌های تسویه، کاربردی می‌کند. برای XRP به‌عنوان یک دارایی، زنجیره علت‌ومعلولی واقع‌بینانه طولانی است: فعال‌سازی در ⁦09/10⁩، سپس به‌روزرسانی اپلیکیشن‌ها به xrpl.js 5.1.0، بعد عرضه محصولاتی از سوی ناشران که از دسته‌های همه یا هیچ استفاده می‌کنند و در نهایت، شاید افزایش فعالیت روی دفترکل که برای کارمزدها و انتقال میان شبکه‌ها به XRP نیاز دارد. هرکدام از این مراحل ممکن است به تأخیر بیفتد. جابه‌جایی زمان از ⁦29/09⁩ به ⁦09/10⁩ یادآوری می‌کند که حتی نخستین مرحله هم قطعی نیست.

پرسش‌های متداول

1. آیا ارتقای XRP در ⁦29/09/2026⁩ انجام شد؟

خیر. BatchV1_1 در ⁦25/09⁩ برای مدتی کوتاه حمایت اعتبارسنج‌ها را از دست داد و شمارش معکوس دو هفته‌ای فعال‌سازی آن از ابتدا آغاز شد. زودترین زمان فعال‌سازی اکنون ⁦09/10/2026⁩، حدود ⁦14:46 UTC⁩، است و اگر حمایت به کمتر از ⁦%80⁩ برسد، ممکن است دوباره به تعویق بیفتد.

2. XRPL BatchV1_1 چیست؟

BatchV1_1 نسخه اصلاح‌شده اصلاحیه Batch (XLS-56) است. این قابلیت به کاربر اجازه می‌دهد 2 تا 8 تراکنش را در یک واحد امضاشده تجمیع کند و 4 شیوه اجرا، از جمله تسویه اتمیک همه یا هیچ، ارائه می‌دهد. نسخه اصلی Batch در ⁦02/2026⁩ به دلیل نقصی در مجوزدهی امضاکننده رد شد؛ نسخه بازنویسی‌شده در ⁦08/2026⁩ در xrpld 3.3.0 منتشر شد.

3. آیا ارتقای Batch قیمت XRP را بالا می‌برد؟

هیچ شواهدی وجود ندارد که این ارتقا به‌تنهایی چنین اثری داشته باشد. XRP در روزی که خبر تأخیر منتشر شد کمتر از ⁦%0.5⁩ حرکت کرد و اصلاحیه‌های قبلی XRPL نیز محرک‌های قابل‌اتکایی برای قیمت نبوده‌اند. هرگونه اثر قیمتی بعدتر و در نتیجه محصولاتی ظاهر می‌شود که بر بستر Batch ساخته می‌شوند.

4. برای نودهایی که پیش از ⁦09/10⁩ ارتقا نمی‌یابند چه اتفاقی می‌افتد؟

این نودها با اصلاحیه مسدود می‌شوند و همگام‌سازی با شبکه را متوقف می‌کنند. اپراتورها دست‌کم به xrpld 3.3.0 نیاز دارند و نسخه پیشنهادی 3.4.1 است، چون fixBatchV1_2 و وصله‌های امنیتی را هم شامل می‌شود.

5. آیا fixBatchV1_2 همان BatchV1_1 است؟

خیر. fixBatchV1_2 اصلاحیه تکمیلی کوچکی است که در ⁦25/09/2026⁩ با xrpld 3.4.1 معرفی شد تا مشکل جزئی Batch را که خطری برای دارایی‌ها ندارد برطرف کند. انتظار می‌رود این اصلاحیه در همان بازه اکتبر و در کنار BatchV1_1 فعال شود.

هشدار ریسک

XRP دارایی پرنوسانی است و ممکن است در چند روز بخش بزرگی از ارزش خود را از دست بدهد؛ نگهداری آن می‌تواند به زیان جزئی یا کلی منجر شود. تاریخ فعال‌سازی اصلاحیه Batch به رأی اعتبارسنج‌ها بستگی دارد و ممکن است دوباره تغییر کند؛ بنابراین، راهبردهای معاملاتی مبتنی بر تاریخ قطعی ⁦09/10⁩ با ریسک زمان‌بندی رویداد همراه‌اند. قراردادهای آتی اهرمی XRP هم سود و هم زیان را چندبرابر می‌کنند و یک حرکت هفتگی معمولی به‌اندازه ⁦%5⁩ برای لیکوییدشدن موقعیتی با اهرم بالا کافی است. خود Batch نیز هنگام عرضه ریسک عملیاتی تازه‌ای ایجاد می‌کند: نودهای قدیمی با اصلاحیه مسدود می‌شوند، کتابخانه‌های کلاینت قدیمی امضاهای ردشده تولید می‌کنند و در حالت‌های غیراتمیک ممکن است تراکنش بیرونی موفق گزارش شود، درحالی‌که تراکنش‌های داخلی ناموفق بوده‌اند. XRP همچنین همچنان در معرض تحولات نظارتی مؤثر بر Ripple و تمرکز عرضه در سپرده‌گذاری تحت کنترل Ripple قرار دارد. هیچ‌یک از مطالب اینجا توصیه سرمایه‌گذاری نیست.