XRP Ledger 3.3.0 приносить оновлення конфіденційності та пакетної обробки

Розробники 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 або зростання ціни.

Наступні перевіряємi віхи будуть прийняття валідаторами 3.3.0, рівні підтримки поправок та заплановані дати активації. Поки ці пороги не будуть досягнуті, нові можливості слід описувати як випущені в програмному забезпеченні вузлів і що проходять через управління, а не як повністю активні функції основної мережі XRP Ledger.

Рішення валідаторів, а не маркетинг релізу, визначать, коли кожна функція стане доступною в основній мережі.