Deweloperzy XRP Ledger wydali xrpld w wersji 3.3.0 6 sierpnia, przybliżając kilka zmian protokołu do możliwej aktywacji w sieci głównej.
- XRPL 3.3.0 wprowadza kod protokołu, ale zatwierdzenie przez walidatorów pozostaje konieczne przed jakąkolwiek aktywacją w sieci głównej.
- ConfidentialTransfer miałby ukrywać salda MPT i kwoty transferów, zachowując dostęp zgodnościowy dla upoważnionych stron.
- BatchV1_1 przywraca funkcjonalność transakcji atomowych po tym, jak wcześniejsza wersja została zatrzymana z powodu luki w zabezpieczeniach.
- Sponsor pozwoliłby stronom trzecim pokrywać opłaty i rezerwy, podczas gdy użytkownicy zachowują pełną kontrolę nad kontem.
- DynamicMPT pozwoliłby emitentom modyfikować wybrane właściwości tokenów później, wspierając ewoluujące potrzeby biznesowe i zgodnościowe.
Oficjalne wydanie na GitHubie potwierdza prace nad ConfidentialTransfer, BatchV1_1, Sponsor i DynamicMPT, wraz z poprawkami i innymi zmianami protokołu. Samo wydanie oprogramowania nie aktywuje tych funkcji w sieci.
To rozróżnienie ma znaczenie, ponieważ niektóre raporty opisują sześć aktualizacji jako już działające. Zgodnie z procesem poprawek XRP Ledger, nowe funkcje protokołu wymagają wsparcia walidatorów przed aktywacją. Poprawka musi utrzymywać ponad 80% wsparcia zaufanych walidatorów przez dwa ciągłe tygodnie, zanim wejdzie w życie.
XRP Ledger 3.3.0 dodaje narzędzia prywatności i transakcji atomowych
ConfidentialTransfer ma na celu dodanie prywatności dla tokenów wielofunkcyjnych (MPT). Dokumentacja XRPL mówi, że poprawka wykorzystuje kryptografię do ukrywania poszczególnych sald i kwot transferów, zachowując mechanizmy umożliwiające upoważnionym stronom, w tym emitentom lub audytorom, weryfikację informacji potrzebnych do zgodności.
Funkcja pozostaje przedmiotem aktywacji poprawki, więc prywatnych transferów MPT nie należy jeszcze opisywać jako aktywnych w sieci głównej XRPL.
BatchV1_1 to kolejny ważny element. Standard XLS-56 pozwala na pakowanie i przetwarzanie wielu transakcji razem, w tym transakcji dotyczących różnych kont. Wykonanie atomowe może pomóc w przepływach rozliczeniowych, gdzie kilka działań musi się powieść razem, zamiast pozostawiać jedną część ukończoną, a inną nieudaną.
Zmienione funkcje po wcześniejszych ustaleniach dotyczących bezpieczeństwa
Batch ma ważną historię. Wcześniejsza wersja została wyłączona przed aktywacją w sieci głównej po odkryciu problemu bezpieczeństwa w logice podpisywania transakcji. Fundacja XRPL później przeszła na BatchV1_1 jako poprawioną wersję. Jak wcześniej informowano w raportach o bezpieczeństwie XRPL, deweloperzy zwiększyli formalny przegląd wokół ostatnich aktualizacji.
Delegowanie uprawnień poszło podobną ścieżką. XRPL ujawnił we wrześniu 2025 r., że błąd we wcześniejszej poprawce mógł pozwolić nieautoryzowanej transakcji na obciążenie opłatami innego konta w określonych warunkach. Walidatorom zalecono głosowanie przeciw, a podatna na ataki funkcja nigdy nie została aktywowana. PermissionDelegationV1_1 został opracowany jako jej zamiennik.
Zmieniona koncepcja pozwala kontu przyznawać określone uprawnienia transakcyjne bez przekazywania głównego klucza prywatnego, wspierając portfele operacyjne z ograniczonymi uprawnieniami.
Sponsor i DynamicMPT ukierunkowane na instytucjonalne wdrażanie
Sponsor, oparty na XLS-68, ma na celu umożliwienie innemu kontu pokrycia opłat transakcyjnych lub wymogów rezerwowych, podczas gdy użytkownik zachowuje kontrolę nad kontem i kluczami. Funkcja mogłaby pozwolić aplikacjom na wdrażanie użytkowników bez wymagania od nich posiadania XRP wyłącznie w celu pokrycia kosztów sieci. Propozycja XLS-68 wyraźnie wspiera sponsorowanie opłat i rezerw przy zachowaniu kontroli kluczy przez użytkownika.
DynamicMPT jest skierowany do emitentów tokenów. Propozycja XLS-94 pozwala emitentom wyznaczyć wybrane właściwości MPT jako zmienne podczas tworzenia tokena, a następnie aktualizować te dozwolone pola później. Standard ma na celu dostosowanie się do zmieniających się wymagań biznesowych lub zgodnościowych bez czynienia każdej właściwości tokena swobodnie edytowalną.
Razem te funkcje wpisują się w rosnące skupienie XRPL na finansach tokenizowanych. W związanych raportach o tokenizacji, crypto.news poinformował, że JPMorgan, Mastercard, Ondo Finance i Ripple przetestowali tokenizowany wykup skarbowy przy użyciu XRPL.
Nie każda cytowana aktualizacja należy do wersji 3.3.0
Jedna korekta jest konieczna wokół powszechnie cytowanego sformułowania "sześć aktualizacji". fixCleanup3_2_0 należy do wcześniejszego cyklu xrpld 3.2.0, a nie do nowo wydanego pakietu funkcji 3.3.0. Dziennik zmian 3.3.0 na GitHubie pokazuje natomiast prace wokół LendingProtocolV1_1 i oddzielnej ścieżki fixCleanup3_3_0 obok głównych funkcji.
Wydanie nie powinno być zatem odczytywane jako sześć gotowych funkcji dostępnych jednocześnie. To kamień milowy w oprogramowaniu serwera, który daje walidatorom i operatorom kod potrzebny do decyzji o poprawkach. Poszczególne poprawki mogą mieć różne harmonogramy głosowania i mogą nie zostać aktywowane, jeśli wsparcie spadnie poniżej wymaganego progu.
Ten proces zarządzania miał znaczenie wcześniej. Oryginalne poprawki Batch i Permission Delegation zostały zatrzymane po wykryciu błędów przed aktywacją w sieci głównej, co pokazuje, że włączenie do oprogramowania lub głosowanie walidatorów nie jest tym samym co wdrożenie produkcyjne.
Co dalej dla walidatorów XRPL
Operatorzy węzłów muszą teraz ocenić wersję 3.3.0 i zdecydować, czy dokonać aktualizacji i wesprzeć poszczególne poprawki. Dokładne daty aktywacji zależą od głosowania walidatorów, a nie od wydania oprogramowania z 6 sierpnia. Zasady poprawek XRPL wymagają, aby superwiększość utrzymywała się nieprzerwanie przez dwa tygodnie.
Dla posiadaczy XRP bezpośrednia zmiana ma charakter techniczny, a nie pieniężny. Wersja 3.3.0 rozszerza potencjalny zestaw narzędzi sieci o prywatność, rozliczenia wieloetapowe, delegowane uprawnienia, sponsorowane wdrażanie i konfigurowalną emisję tokenów, ale żadna z tych funkcji nie gwarantuje wyższego popytu na XRP ani wzrostu ceny.
Kolejne weryfikowalne kamienie milowe to przyjęcie 3.3.0 przez walidatorów, poziomy wsparcia poprawek i zaplanowane daty aktywacji. Dopóki te progi nie zostaną osiągnięte, nowe funkcje należy opisywać jako wydane w oprogramowaniu węzłów i przechodzące przez proces zarządzania, a nie jako w pełni aktywne funkcje sieci głównej XRP Ledger.
Decyzje walidatorów, a nie marketing wydania, określą, kiedy każda funkcja stanie się użyteczna w sieci głównej.