Розробники 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 Foundation перейшов до BatchV1_1 як виправленої заміни. Як раніше повідомлялося в матеріалах про безпеку XRPL, розробники посилили формальний огляд останніх оновлень.
Permission Delegation пройшов подібний шлях. 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.
Рішення валідаторів, а не маркетинг релізу, визначать, коли кожна функція стане придатною для використання в мейннеті.
