Пакетна обробка V1.1 (Batch V1.1) XRP Ledger залишається вище необхідного порогу валідаторів, оскільки Ripple заявляє, що керуючі активами та комерційні проєкти готуються використовувати функцію транзакцій, якщо вона активується пізніше цього місяця.
CoinDesk повідомив 19 вересня, що керівник інженерного відділу RippleX Айо Акінєле (Ayo Akinyele) заявив, що готується робота за участю керуючих активами навколо пакетної обробки V1.1, яка може об'єднувати до восьми транзакцій в одну пакетну операцію. Ripple не оприлюднила назви керуючих активами та не розкрила точні дати запуску.
Дані про поточні поправки, переглянуті 20 вересня, показали, що 30 з 35 відстежуваних довірених валідаторів підтримують пакетну обробку V1.1. XRP Ledger вимагає підтримки щонайменше 80% протягом 14 послідовних днів, перш ніж поправка активується, встановлюючи поточний поріг у 28 голосів. Зворотний відлік розпочався 15 вересня о 14:06:41 UTC і вказує на можливу активацію незабаром після цього ж часу 29 вересня, якщо підтримка збережеться.
Специфікація XLS-56 визначає пакетну обробку як транзакцію, яка об'єднує від двох до восьми внутрішніх транзакцій. Вона підтримує чотири режими обробки: «Все або Нічого», «Лише Один», «До Збою» та «Незалежний». Налаштування «Все або Нічого» вимагає успішного виконання повної групи або запобігає застосуванню пакету.
Ripple зосереджує частину комерційного обговорення на постачанні проти оплати, або DvP. У такій транзакції передача активу та його оплата можуть бути розміщені в рамках однієї атомарної операції. Невдалий платіж запобіг би завершенню пов'язаної передачі активу в налаштуванні «все або нічого».
Акінєле повідомив CoinDesk, що «Ми поділимося додатковою інформацією, коли функція буде запущена, включаючи роботу з ключовими керуючими активами». Ripple не назвала ці фірми, тому заява залишається описом компанією роботи, яка ще не була публічно задокументована через оголошення про іменованих партнерів.
Специфікація XLS-56 перелічує бездовірні обміни між кількома рахунками, комісії платформи та структури флеш-кредитів серед потенційних застосувань. Маркетплейс або гаманець могли б, наприклад, об'єднати платіж клієнта з платою за послуги замість того, щоб вимагати окремих транзакцій, тоді як різні рахунки можуть авторизувати окремі етапи однієї і тієї ж пакетної обробки.
Акінєле сказав, що «деякі проєкти вже розробляються з урахуванням пакетної обробки», але особи партнерів та графіки виробництва залишаються нерозголошеними. Ripple заявила, що деталі будуть повідомлені після завершення планування.
Станом на останні дані від 20 вересня, пакетна обробка V1.1 мала 30 голосів підтримки серед 35 валідаторів, відстежуваних XRPLDashboard, що дорівнює приблизно 85%. Таким чином, підтримка залишалася вище порогу в 28 голосів, необхідного для продовження вікна активації.
Прогнозована дата 29 вересня є умовною. Поправки XRPL не активуються просто тому, що вони одного разу перевищили 80%. Валідатори повинні підтримувати супербільшість протягом повних 14 днів, і валідатори можуть змінювати свої голоси під час зворотного відліку. Якщо підтримка падає нижче необхідного рівня, поточне вікно зупиняється, і після відновлення порогу буде потрібен інший безперервний період.
Останній підрахунок продовжує швидке зростання підтримки цього місяця. Тоді пакетна обробка V1.1 мала 24 з 35 голосів валідаторів, або 68,57%, що залишало її нижче порогу активації. До 15 вересня підтримка зросла до 27 голосів, перш ніж достатня кількість валідаторів підтримала поправку, щоб розпочати зворотний відлік.
Сама поправка була випущена з xrpld версії 3.3.0 6 серпня. Офіційні примітки до випуску XRP Ledger описують пакетну обробку V1.1 як заміну оригінальної поправки Batch і заявляють, що вона підтримує до восьми внутрішніх транзакцій, включаючи структури атомарних обмінів.
З того часу Фонд XRP Ledger випустив xrpld 3.4.0. Випуск програмного забезпечення 16 вересня представляє окремі поправки щодо кредитування та очищення і не замінює пакетну обробку V1.1, яка залишається у власному процесі голосування в основній мережі. Операторам серверів було рекомендовано оновити до версії 3.4.0 для безперервності послуги.
Поточна поправка з'явилася після того, як розробники зупинили оригінальну пропозицію Batch у лютому. Офіційне розкриття вразливості XRPL зазначає, що дослідник безпеки Пранамая Кешкамат (Pranamya Keshkamat) та інструмент Apex компанії Cantina AI виявили критичну помилку перевірки підпису 19 лютого.
За певних умов, вразливий код міг припинити перевірку підписувачів Batch після виявлення новоствореного облікового запису. XRPL Labs заявила, що зловмисник міг би включити несанкціоновану транзакцію з іншого облікового запису, не володіючи приватними ключами власника цього облікового запису. Потенційні транзакції могли включати платежі та певні зміни стану реєстру.
Помилка ніколи не стала активною в основній мережі XRP Ledger. Оригінальна поправка все ще перебувала на етапі голосування, і XRPL Labs заявила, що кошти не були під загрозою. Валідаторам було рекомендовано проголосувати проти, тоді як rippled версії 3.1.1, випущений 23 лютого, зробила Batch та fixBatchInnerSigs непідтримуваними, щоб вони не могли активуватися.
Потім розробники змінили логіку підписання та авторизації для заміни. Звіт про вразливість заявив, що усунення вилучило умову передчасного успіху, додало засоби захисту авторизації та посилило правила перевірки підпису. Пакетна обробка V1.1 була пізніше включена до xrpld 3.3.0 після розробки та перегляду.
Робота з безпеки тривала до поточного голосування валідаторів. Ascrypto.news у своєму огляді безпеки пакетної обробки V1.1 повідомив, що розробники виправили ще 11 проблем, пов'язаних з підписами, перевірками авторизації та можливими збоями сервера, перш ніж поправка досягла поточної стадії голосування.
Акінєле повідомив CoinDesk, що перегляд включав внутрішнє змагальне тестування, аналіз за допомогою ШІ, конкурс безпеки Sherlock та оцінки за участю Halborn та Common Prefix. CoinDesk приписав ці деталі RippleX; публічні звіти партнерів, що охоплюють кожну частину цього перегляду, не були включені до матеріалу, переглянутого для цього звіту.
Екосистема розробників XRPL внесла підтримуючі зміни в міру розвитку дизайну підписання. Червнева проблема в офіційному репозиторії xrpl.js задокументувала, що стара логіка підписання Batch не відповідала переглянутому формату Batch V1.1, оскільки додаткова інформація про рахунок та послідовність була прив'язана до підписів. Історія випусків JavaScript binary-codec заявляє, що підтримка підписання Batch V1.1 була додана у версії 2.9.0 у серпні.
Коментарі Ripple щодо пакетної обробки з'являються в той час, коли фінансові фірми та розробники використовують інфраструктуру XRP Ledger для токенізованих активів та інституційних розрахункових проєктів. У червні JPMorgan, Mastercard, Ondo Finance та Ripple взяли участь у тесті на погашення токенізованих казначейських облігацій США за допомогою XRP Ledger.
Президент Ripple Моніка Лонг (Monica Long) заявила в серпні, що фінансові установи переводили деякі роботи з токенізованими активами з пілотних програм до виробництва. Crypto.news повідомив про інституційні проєкти токенізації Ripple, що Aviva Investors запустила клас токенізованих паїв фонду на XRPL у липні, і що Ripple розглядала RLUSD як можливу грошову складову для атомарного розрахунку «постачання проти оплати».
Зросла ончейн активність активів разом із цим розвитком. Інший огляд даних XRP Ledger RWA від crypto.news повідомив у липні, що мережа додала приблизно 2,6 мільярда доларів США токенізованих активів реального світу за шість місяців, за винятком стейблкойнів, на основі даних RWA.xyz. Той же звіт застерігав, що представлена вартість активів та активно розподілені активи є суттєво різними показниками.
Сама пакетна обробка V1.1 не вимагає від керуючих активами використання XRP як активу, що передається. Ця функція працює на рівні транзакцій і може упаковувати підтримувані транзакції XRPL з різних рахунків. XRP залишається актуальним для комісій за транзакції в реєстрі, тоді як базові транзакції можуть включати інші підтримувані активи та токенові структури.
Наступною процедурною подією є кінець поточного вікна поправки. XRPLDashboard прогнозує активацію пакетної обробки V1.1 на 29 вересня приблизно о 14:06:41 UTC, якщо щонайменше 80% підтримки валідаторів залишається безперервною протягом повного зворотного відліку. Останні опубліковані дані від 20 вересня залишалися на рівні 30 голосів «за» з 35 відстежуваних валідаторів.
XRP
