Розробники XRP Ledger випустили xrpld версії 3.3.0 6 серпня, наблизивши кілька змін протоколу до можливої активації в основній мережі.
- XRPL 3.3.0 вводить код протоколу, але схвалення валідаторів залишається необхідним перед будь-якою активацією в основній мережі.
- ConfidentialTransfer захищатиме баланси MPT та суми переказів, зберігаючи доступ для комплаєнсу уповноважених сторін.
- BatchV1_1 відновлює функціональність атомарних транзакцій після того, як попередня версія була зупинена через вразливість безпеки.
- Sponsor дозволить третім сторонам покривати комісії та резерви, зберігаючи повний контроль користувача над акаунтом.
- DynamicMPT дозволить емітентам пізніше змінювати окремі властивості токенів, підтримуючи бізнес- та комплаєнс-потреби, що розвиваються.
Офіційний реліз на GitHub підтверджує роботу над ConfidentialTransfer, BatchV1_1, Sponsor та DynamicMPT, разом з виправленнями та іншими змінами протоколу. Сам випуск програмного забезпечення не активує ці функції в мережі.
Ця відмінність важлива, оскільки деякі звіти описують шість оновлень як уже запущені. Згідно з процесом внесення поправок XRP Ledger, нові функції протоколу вимагають підтримки валідаторів перед активацією. Поправка повинна зберігати понад 80% підтримки довірених валідаторів протягом двох безперервних тижнів, перш ніж набуде чинності.
XRP Ledger 3.3.0 додає інструменти конфіденційності та атомарних транзакцій
ConfidentialTransfer призначений для додавання конфіденційності для багатоцільових токенів (MPT). Документація XRPL каже, що поправка використовує криптографію для захисту окремих балансів і сум переказів, зберігаючи механізми, які дозволяють уповноваженим сторонам, включаючи емітентів або аудиторів, перевіряти інформацію, необхідну для комплаєнсу.
Функція залишається предметом активації поправки, тому приватні перекази MPT ще не слід описувати як активні в основній мережі XRPL.
BatchV1_1 є ще одним важливим компонентом. Стандарт XLS-56 дозволяє об'єднувати та обробляти кілька транзакцій разом, включаючи транзакції, що стосуються різних акаунтів. Атомарне виконання може допомогти робочим процесам розрахунків, де кілька дій повинні виконатися разом, а не залишати одну частину завершеною, а іншу невдалою.
Переглянуті функції після попередніх знахідок безпеки
Batch має важливу історію. Попередня версія була вимкнена перед активацією в основній мережі після виявлення проблеми безпеки в логіці підписання транзакцій. Фонд XRPL пізніше перейшов до BatchV1_1 як виправленої заміни. Як раніше повідомлялося в покритті безпеки XRPL, розробники посилили формальний огляд останніх оновлень.
Делегування дозволів пішло подібним шляхом. XRPL розкрив у вересні 2025 року, що помилка в попередній поправці могла дозволити несанкціонованій транзакції стягувати комісії з іншого акаунта за певних умов. Валідаторам порадили голосувати проти, і вразлива функція ніколи не активувалася. PermissionDelegationV1_1 був розроблений як її заміна.
Переглянута концепція дозволяє акаунту надавати визначені дозволи на транзакції без передачі свого основного приватного ключа, підтримуючи операційні гаманці з обмеженими повноваженнями.
Sponsor та DynamicMPT орієнтовані на інституційне впровадження
Sponsor, заснований на XLS-68, призначений для того, щоб інший акаунт покривав комісії за транзакції або резервні вимоги, поки користувач зберігає контроль над акаунтом і ключами. Ця функція може дозволити додаткам залучати користувачів без необхідності придбання XRP лише для покриття мережевих витрат. Пропозиція XLS-68 явно підтримує спонсорування комісій і резервів, зберігаючи контроль користувача над ключами.
DynamicMPT орієнтований на емітентів токенів. Пропозиція XLS-94 дозволяє емітентам позначати окремі властивості MPT як змінні при створенні токена, а потім оновлювати ці дозволені поля пізніше. Стандарт призначений для врахування змінних бізнес- або комплаєнс-вимог без того, щоб робити кожну властивість токена вільно редагованою.
Разом ці функції відповідають зростаючому фокусу XRPL на токенізованих фінансах. У пов'язаному покритті токенізації, crypto.news повідомив, що JPMorgan, Mastercard, Ondo Finance та Ripple протестували токенізоване погашення казначейських зобов'язань з використанням XRPL.
Не кожне згадане оновлення належить до версії 3.3.0
Необхідно внести одне виправлення щодо широко поширеного формулювання "шість оновлень". fixCleanup3_2_0 належить до попереднього циклу xrpld 3.2.0, а не до нововипущеного пакета функцій 3.3.0. Журнал змін GitHub для 3.3.0 натомість показує роботу над LendingProtocolV1_1 та окремим треком fixCleanup3_3_0 разом із головними функціями.
Тому реліз не слід сприймати як шість готових можливостей, що стають доступними одночасно. Це віха серверного програмного забезпечення, яка дає валідаторам та операторам код, необхідний для рішень щодо поправок. Окремі поправки можуть мати різні графіки голосування і можуть не активуватися, якщо підтримка впаде нижче необхідного порогу.
Цей процес управління мав значення раніше. Оригінальні поправки Batch та Permission Delegation були зупинені після виявлення помилок перед активацією в основній мережі, що показує, що включення в програмне забезпечення або голосування валідаторів не є тим самим, що розгортання у виробництві.
Що далі для валідаторів XRPL
Операторам вузлів тепер потрібно оцінити версію 3.3.0 та вирішити, чи оновлюватися та підтримувати окремі поправки. Точні дати активації залежать від голосування валідаторів, а не від випуску програмного забезпечення 6 серпня. Правила внесення поправок XRPL вимагають, щоб супербільшість зберігалася безперервно протягом двох тижнів.
Для власників XRP негайна зміна є технічною, а не грошовою. Версія 3.3.0 розширює потенційний інструментарій мережі для конфіденційності, багатокрокових розрахунків, делегованих повноважень, спонсорованого залучення та настроюваної емісії токенів, але жодна з них не гарантує вищого попиту на XRP або зростання ціни.
Наступними перевірними віхами будуть прийняття валідаторами 3.3.0, рівні підтримки поправок та заплановані дати активації. Поки ці пороги не досягнуті, нові можливості слід описувати як випущені в програмному забезпеченні вузлів і такі, що проходять через управління, а не як повністю активні функції основної мережі XRP Ledger.
Рішення валідаторів, а не маркетинг релізу, визначать, коли кожна функція стане придатною для використання в основній мережі.