XRP Ledger przeniósł PermissionDelegationV1_1 do swojego 14-dniowego okresu aktywacji po tym, jak 29 z 35 zaufanych walidatorów sieci poparło aktualizację uprawnień konta.
Podsumowanie
- PermissionDelegationV1_1 może zostać aktywowany 5 października, jeśli wsparcie walidatorów pozostanie powyżej wymaganego progu 80%.
- Aktualizacja pozwala kontom XRPL delegować określone uprawnienia bez przyznawania innemu kontu pełnej kontroli nad ich kluczami.
- Delegowanie uprawnień nie zmienia bezpośrednio podaży XRP ani tokenomiki, co sprawia, że ewentualny wpływ na cenę zależy w dużej mierze od adopcji i aktywności sieci.
Zgodnie z aktywnym panelem poprawek XRP Ledger, odliczanie rozpoczęło się 21 września i mogłoby wprowadzić PermissionDelegationV1_1 w życie 5 października o 11:18 UTC, jeśli wsparcie walidatorów pozostanie powyżej wymaganego progu przez cały okres.
Co najmniej 28 z 35 zaufanych walidatorów musi nadal wspierać poprawkę. Jeśli poparcie spadnie poniżej tego poziomu przed zakończeniem odliczania, licznik aktywacji zostanie zresetowany.
PermissionDelegationV1_1 dzieli uprawnienia konta XRP Ledger
PermissionDelegationV1_1 zmienia sposób, w jaki konto XRP Ledger może przyznać innemu kontu uprawnienia do wykonywania określonych zadań.
W obecnej strukturze konta firmy, które potrzebują różnych systemów lub pracowników do przeprowadzania operacji, mogą napotkać problem polegający na przyznaniu kontu operacyjnemu większych uprawnień, niż faktycznie potrzebuje. Delegowanie uprawnień ma na celu rozdzielenie tych obowiązków.
Konto może na przykład upoważnić inne konto do dokonywania płatności bez przyznawania mu uprawnień do zmiany kluczy głównego konta. Emitent stablecoina mógłby trzymać swoje główne klucze offline, jednocześnie przyznając podłączonemu do internetu systemowi zgodności uprawnienia do zatwierdzania klientów do posiadania swojego tokena.
Każde delegowane konto może otrzymać do 10 uprawnień, podczas gdy konto przyznające uprawnienia zachowuje możliwość ich zmiany lub odwołania.
Rozwiązanie to przypomina podział obowiązków powszechnie stosowany przez instytucje finansowe, gdzie funkcje płatnicze, zgodnościowe i administracyjne niekoniecznie mają ten sam poziom dostępu.
PermissionDelegationV1_1 stanowi część większej grupy poprawek wprowadzonych przez xrpld 3.3.0. Wydanie obejmowało BatchV1_1, ConfidentialTransfer, DynamicMPT i Sponsor obok Delegowania uprawnień, przy czym kilka z tych funkcji jest ukierunkowanych na transakcje instytucjonalne i emisję tokenów.
Sponsor pozwoliłby innemu podmiotowi pokrywać opłaty transakcyjne i wymagania dotyczące rezerw dla użytkowników bez kontrolowania ich kont. DynamicMPT daje emitentom większą elastyczność w zakresie wybranych właściwości Multi Purpose Token, podczas gdy ConfidentialTransfer ma na celu ukrycie sald MPT i kwot płatności przed publicznym wglądem, zachowując mechanizmy dostępu dla upoważnionych stron.
Crypto.news wcześniej informowało, że ConfidentialTransfer jest ukierunkowany na instytucjonalne przypadki użycia, w których firmy mogą potrzebować prywatności transakcji, jednocześnie dostarczając informacje audytorom i innym upoważnionym stronom.
Delegowanie uprawnień powraca po wcześniejszej luce bezpieczeństwa
PermissionDelegationV1_1 to druga próba wprowadzenia delegowanych uprawnień konta do XRP Ledger.
Oryginalna poprawka została zatrzymana przed dotarciem do głównej sieci po tym, jak tester społeczności zgłosił podatność 15 września 2025 r.
W przypadku dotkniętej implementacji oprogramowanie sprawdzało, czy konto ma uprawnienia do wykonania transakcji, przed prawidłowym zweryfikowaniem jej podpisu. Niektóre odrzucone transakcje mogły nadal wiązać się z opłatą.
Atakujący mógł zatem przesłać nieautoryzowane transakcje z celowo wysokimi opłatami i spowodować, że inne konto je zapłaci, mimo że transakcje nie były prawidłowo podpisane. Powtarzanie tego procesu mogło wyczerpać dostępne saldo XRP ofiary.
Po odkryciu podatności walidatorom zalecano nieobsługiwanie poprawki, co uniemożliwiło aktywację dotkniętej wersji w mainnecie.
Zamiennik został uwzględniony w xrpld 3.3.0 ze zmianami w sposobie obsługi nieautoryzowanych transakcji. Weryfikacja podpisu odbywa się teraz przed rodzajem błędu, który mógłby obciążyć docelowe konto.
Delegowanie uprawnień to nie jedyna funkcja z tego wydania, która powraca po pracach nad bezpieczeństwem. BatchV1_1 zastąpił wcześniejszą implementację Batch po tym, jak deweloperzy odkryli odrębną krytyczną lukę w podpisywaniu. Poprawiona aktualizacja Batch przeszła przez głosowanie walidatorów po poprawkach i dalszym przeglądzie.
Czy PermissionDelegationV1_1 może wpłynąć na cenę XRP?
PermissionDelegationV1_1 nie zmienia bezpośrednio podaży XRP, harmonogramu emisji ani ekonomii tokena, co nie daje mechanicznego powodu, by samo jej aktywowanie tworzyło znaczny nowy popyt na XRP.
Poprawka dotyczy uprawnień kont, a nie samego tokena XRP. Instytucje korzystające z delegowanych kont nadal używałyby XRP do normalnych opłat i wymogów rezerwy w księdze, ale funkcja nie wymaga od nich kupowania lub posiadania dużych ilości XRP tylko po to, by korzystać z delegowanych uprawnień.
Ostatnie wydarzenia w sieci pokazują, dlaczego rozróżnienie między adopcją XRPL a popytem na XRP ma znaczenie.
Wcześniejsza analiza ekspozycji Ripple Prime na XRP wykazała, że nawet znaczna aktywność instytucjonalna w ekosystemie Ripple nie przekłada się automatycznie na równoważny popyt na XRP. Stablecoiny i inne emitowane aktywa mogą obsłużyć znaczną część transferu wartości bazowej, podczas gdy XRP zachowuje role obejmujące opłaty transakcyjne, rezerwy i niektóre funkcje routingu.
Podobna struktura dotyczy Delegowania uprawnień. Emitenci stablecoinów, dostawcy tokenizowanych aktywów i inne firmy mogliby korzystać z tej funkcji bez uczynienia XRP aktywem będącym przedmiotem transferu.
Możliwy związek z ceną zależy natomiast od tego, czy aktualizacja pomoże z czasem przyciągnąć więcej aktywności do XRP Ledger.
Emitenci instytucjonalni, którzy chcą trzymać klucze o wysokich uprawnieniach offline, mogliby używać delegowanych kont do płatności cyklicznych lub zadań zgodności. Jeśli te możliwości przyczynią się do tego, że więcej firm będzie emitować aktywa i przetwarzać transakcje w XRPL, wynikająca z tego aktywność stworzyłaby większe wykorzystanie sieci, w której XRP pozostaje natywnym aktywem używanym do opłat i rezerw.
Dotychczasowe dowody sugerują, że wzrost sieci i cena XRP nie zawsze poruszają się razem. RLUSD i tokenizowane aktywa rozszerzyły się w XRPL, podczas gdy XRP doświadczał okresów słabości cenowej, co pokazuje, że rosnąca aktywność w księdze niekoniecznie wywołuje natychmiastową presję zakupową na token.
Test instytucjonalny z czerwca z udziałem JPMorgan, Mastercard, Ondo Finance i Ripple dostarczył kolejnego przykładu. Tokenizowany wykup Treasury wykorzystywał XRP Ledger, ale XRP nie był aktywem będącym przedmiotem wykupu. Jego bezpośrednia rola pozostała związana z bazową infrastrukturą sieci.
PermissionDelegationV1_1 mogłaby zatem zapewnić kolejny element infrastruktury dla użytkowników instytucjonalnych, nie stając się głównym samodzielnym katalizatorem ceny XRP.
Reakcja rynku wokół aktywacji pozostaje możliwa, ponieważ traderzy mogą reagować na aktualizacje sieci i oczekiwania dotyczące adopcji. Jakikolwiek trwały wpływ na cenę zależałby jednak od późniejszego wykorzystania tej funkcji i innych czynników rynkowych, a nie od samego włączenia poprawki.
XRP Ledger buduje więcej narzędzi do transakcji instytucjonalnych
Delegowanie uprawnień zmierza do aktywacji, podczas gdy kilka innych funkcji XRP Ledger pozostaje na różnych etapach procesu poprawek.
BatchV1_1 został zaprojektowany do łączenia wielu operacji w skoordynowaną transakcję, pozwalając, by każda uwzględniona akcja zakończyła się sukcesem lub porażką razem. Taka struktura może wspierać procesy rozliczeniowe, w których aktywo i jego płatność muszą zmienić właściciela w tym samym czasie.
ConfidentialTransfer dałby emitentom Multi Purpose Token możliwość ukrycia sald i kwot transferów, pozostawiając konta widoczne. Upoważnione strony nadal mogłyby otrzymywać informacje potrzebne do zgodności w ramach proponowanego projektu.
Deweloperzy XRPL kontynuowali prace po wydaniu 3.3.0. Wersja 3.4.0, wydana 16 września, wprowadziła zmiany w proponowanych funkcjach pożyczkowych wraz z kolejnym pakietem poprawek protokołu.
Ramy pożyczkowe pozostają przedmiotem procesu poprawek sieci, z wymaganą zgodą walidatorów, zanim proponowane funkcje będą mogły stać się aktywne w mainnecie.
