ارتقاهای بلاکچین همیشه قابلیتهای یک شبکه را تغییر نمیدهند. گاهی، آنها نحوه وقوع قابلاعتماد چندین فرایند بهصورت همزمان را تغییر میدهند.
ایده پشتِ XRP Ledger Batch V1.1، اصلاحیهای است که برای آن طراحی شده تا مشارکتکنندگان بتوانند حداکثر هشت تراکنش را در یک بسته واحد گروهبندی کنند. بهجای اینکه اجازه دهد بخشی از این توالی اجرا شود و بقیه شکست بخورد، بسته میتواند بر اساس یک نتیجه واحد ساختاربندی شود: یا همهچیز انجام میشود، یا هیچچیز.
گزارش شده بود که این اصلاحیه قرار است پس از ۲۹ سپتامبر ساعت ۱۴:۰۶:۴۱ UTCفعال شود، مشروط بر اینکه حمایت اعتبارسنجها به مدت ۱۴ روز در سطح آستانه موردنیاز ۸۰٪ یا بالاتر باقی بماند. گزارش RSS حمایت ۳۰ مورد از ۳۵ اعتبارسنج تحت رصد را نشان میداد.
برای معاملهگران، بخش مهم این نیست که آیا این ارتقا روایت جدیدی پیرامون XRP ایجاد میکند یا نه. مهم این است که اجرای اتمیک در لایه زیرین بازار چه تغییری ایجاد میکند، بهویژه برای برنامههایی که تلاش میکنند چندین اقدام درونزنجیرهای را هماهنگ کنند، بدون اینکه کاربران را در میانه یک توالی سرگردان بگذارند.
وقتی مشکل، نیمهکاره ماندن یک توالی تراکنش است
بیشتر تراکنشها بهتنهایی بهاندازه کافی سادهاند. یک انتقال یا کامل میشود یا نمیشود. وقتی چندین تراکنش به یکدیگر وابسته باشند، پیچیدگی شروع میشود.
تصور کنید یک برنامه باید مجموعهای از اقدامات مرتبط را اجرا کند که شامل انتقالها، پیشنهادها یا دیگر عملیات حساب است. اگر این اقدامات جداگانه ارسال شوند، ممکن است یکی موفق شود و دیگری شکست بخورد؛ چون موجودی تغییر کرده، شرط کارمزد برآورده نشده یا شرایط بین ارسالها تغییر کرده است. نتیجه میتواند از نظر فنی معتبر، اما از نظر عملیاتی ناقص باشد.
Batch V1.1 روش متفاوتی برای رسیدگی به این مشکل معرفی میکند.
میتوان حداکثر هشت تراکنش را طوری گروهبندی کرد که توالی موردنظر یا بهطور کامل موفق شود یا بهطور کامل شکست بخورد. منظور از اتمیکبودن در اینجا همین است. ارزش این قابلیت در آن نیست که هر تراکنش منفرد امنتر یا سودآورتر میشود؛ بلکه در این است که برنامهها کنترل بیشتری بر آنچه هنگام قرار است چند اقدام مانند یک اقدام واحد عمل کنند، به دست میآورند.
برای معاملهگران، این تمایز اهمیت دارد. اجرای اتمیک میتواند برخی شکلهای ریسک اجرای ناقص را کاهش دهد، اما نمیتواند ریسک بازار پیرامون خود تراکنش را از بین ببرد. حتی یک توالی که کاملاً اجرا شده باشد نیز ممکن است در زمانی نامطلوب رخ دهد.
این اصلاحیه تنها یکی از لایههای این تغییر است
تمایز دیگری هم وجود دارد که باید در نظر داشت: پشتیبانی پروتکل با در دسترسبودن عملی یکسان نیست.
Batch V1.1 ممکن است قابلیت جدیدی به XRP Ledger اضافه کند، اما کیفپولها، برنامههای کاربردی غیرمتمرکز و دیگر ابزارهای شبکه همچنان باید تصمیم بگیرند که آیا و چگونه از آن استفاده کنند. تا زمانی که این رابطها قابلیت دستهبندی تراکنشها را به شکلی در دسترس واقعی کاربران ارائه نکنند، این اصلاحیه همچنان زیرساخت محسوب میشود، نه قابلیتی که هر معاملهگر فوراً با آن مواجه شود.
این فاصله میان قابلیت پروتکل و پذیرش محصول در حوزه رمزارز رایج است. یک شبکه میتواند قوانین جدیدی وضع کند، مدتها پیش از آنکه این قوانین تجربه کاربری معمول را بهطور معناداری تغییر دهند.
بنابراین، درباره Batch V1.1 پرسشهای مفیدتر پس از فعالسازی مطرح میشوند. کدام برنامهها آن را میپذیرند؟ چه نوع جریانهای تراکنشی را دستهبندی میکنند؟ و آیا اجرای اتمی، فرایندهایی را که پیشتر به چندین تراکنش مستقل نیاز داشتند، بهطور محسوسی ساده میکند؟
پاسخ این پرسشها بیش از خود رویداد فعالسازی، درباره اهمیت عملی آن اطلاعات خواهد داد.
فعالسازی یک فرایند است، نه صرفاً یک تاریخ
زمانبندی اعلامشده برای ۲۹ سپتامبر نیز به توضیح بیشتری نیاز دارد.
انتظار میرفت این اصلاحیه تنها در صورتی فعال شود که حمایت اعتبارسنجها بالاتر از آستانه ۸۰٪ برای دوره الزامی ۱۴روزهباقی بماند. بنابراین، این زمان یک زمان مشروط است و معادل راهاندازی قطعی نیست.
یک اصلاحیه پیشنهادی، حمایت کافی اعتبارسنجها، زمان مورد انتظار برای فعالسازی و اصلاحیهای که واقعاً فعال شده است، مراحل جداگانهای از این فرایند هستند.
این تمایز زمانی اهمیت بیشتری پیدا میکند که رویدادهای فنی بهعنوان تیترهای بازار منتشر شوند. انتظارات میتوانند سریعتر از پروتکلها حرکت کنند، بهویژه در XRP Ledger، جایی که اجماع اعتبارسنجها نقشی اساسی در نحوه پذیرش تغییرات شبکه دارد.
بنابراین، برای هر کسی که Batch V1.1 را دنبال میکند، نقطه بررسی مهم صرفاً این نیست که آیا زمانی برای فعالسازی اعلام شده است یا نه. مسئله این است که آیا شرایط لازم مربوط به اعتبارسنجها برآورده شده و اصلاحیه واقعاً فعال شده است یا خیر.
اجرای اتمی، بازارها را اتمی نمیکند
گسترش بیش از حد مفهوم اجرای همه یا هیچ، آسان است.
دستهبندی تراکنشها میتواند تعیین کند که آیا یک گروه از تراکنشها با هم تکمیل میشوند یا نه. اما نمیتواند نقدینگی ایجاد کند، مانع تغییر قیمتها شود یا تضمین کند که نتیجه اقتصادی این تراکنشها مطلوب خواهد بود.
این ریسکها خارج از سازوکار اتمیبودن وجود دارند.
اگر شرایط بازار پیش از رسیدن یک سفارش به مقصد تغییر کند، دستهبندی سفارشها بازار را در اطراف آن منجمد نمیکند. اگر نقدینگی کم باشد، این ارتقا عمق دفتر سفارشها را افزایش نمیدهد. و اگر خودِ یک راهبرد بهخوبی طراحی نشده باشد، اجرای موفقیتآمیز همه اجزای آن، راهبرد را به یک راهبرد سودآور تبدیل نمیکند.
Batch V1.1 همچنین به این معنا نیست که تراکنشهای XRP Ledger ناگهان بهصورت پیشفرض در بستههایی واحد قرار میگیرند. این قابلیت زمانی اهمیت پیدا میکند که برنامهها عمداً بر مبنای آن ساخته شوند و کاربران با محصولاتی تعامل کنند که از چنین جریانهایی پشتیبانی میکنند.
این موضوع باعث میشود کنترلهای آشنای اجرای معاملات همچنان به همان اندازه مهم باشند. معاملهگران هنوز باید نقدینگی، شرایط محل معامله، و اینکه انواع مختلف سفارش چگونه بر اجرای معامله تأثیر میگذارندرا درک کنند، زیرا اتمیکبودن جایگزین این سازوکارها نمیشود.
داستان بزرگتر، چیزی است که بر بستر آن ساخته میشود
Batch V1.1 در نهایت یک ارتقای زیرساختی است، و زیرساخت معمولاً از طریق کارهایی که توسعهدهندگان در ادامه با آن انجام میدهند اهمیت پیدا میکند.
فراهم کردن راهی برای برنامهها تا چندین تراکنش را تحت یک شرط اجرایی واحد هماهنگ کنند، میتواند برخی جریانهای کاری چندمرحلهای را سادهتر و قابلپیشبینیتر کند. این قابلیت ممکن است در هر جایی که تکمیل ناقص باعث ایجاد مشکلات عملیاتی میشود مفید باشد، بهویژه با پیچیدهتر شدن برنامهها.
اما خودِ این اصلاحیه فقط یک بنیان است. پذیرش آن توسط کیفپولها و برنامهها تعیین میکند که دستههای اتمیک در عمل کجا مفید واقع شوند، در حالی که نقدینگی، زمانبندی و شرایط بازار همچنان ریسکهای پیرامون معاملات حاصل را تعیین خواهند کرد.
به همین دلیل، Batch V1.1 بهعنوان یک ارتقای اجرایی جالبتر از یک سیگنال بازار است. این قابلیت یکی از روشهای هماهنگسازی تراکنشها در XRP Ledger را تغییر میدهد. اما تعیین نمیکند که ارزش XRP پس از آن چه باشد.
برای معاملهگران، درک همین مرز بخش مفید ماجراست. ارتقاهای پروتکل میتوانند سازوکار زیربنایی یک بازار را بهبود دهند، بیآنکه تصمیم بگیرند آن بازار در ادامه به کدام سو حرکت کند.
