XRP Ledger 3.3.0 wprowadza ulepszenia prywatności i transakcji zbiorczych

Deweloperzy XRP Ledger wydali wersję 3.3.0 xrpld 6 sierpnia, przybliżając kilka zmian protokołu do możliwej aktywacji w sieci głównej.

Oficjalne wydanie na GitHub 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ść ulepszeń 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 indywidualnych sald i kwot transferów, zachowując jednocześnie 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 prywatne transfery MPT nie powinny być jeszcze opisywane jako aktywne w sieci głównej XRPL.

BatchV1_1 to kolejny ważny element. Standard XLS-56 umożliwia pakowanie i przetwarzanie wielu transakcji razem, w tym transakcji dotyczących różnych kont. Wykonanie atomowe może pomóc w przepływach pracy rozliczeniowych, gdzie kilka działań musi zakończyć się sukcesem 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 poprawiony zamiennik. Jak wcześniej informowano w raportach o bezpieczeństwie XRPL, deweloperzy zwiększyli formalny przegląd wokół ostatnich ulepszeń.

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 operacyjne portfele z ograniczonymi uprawnieniami.

Sponsor i DynamicMPT celują w instytucjonalne wdrażanie

Sponsor, oparty na XLS-68, jest zaprojektowany tak, aby umożliwić innemu kontu pokrycie opłat transakcyjnych lub wymogów rezerwowych, podczas gdy użytkownik zachowuje kontrolę nad kontem i kluczami. Funkcja ta mogłaby pozwolić aplikacjom na wdrażanie użytkowników bez konieczności nabywania przez nich XRP wyłącznie w celu pokrycia kosztów sieciowych. Propozycja XLS-68 wyraźnie wspiera sponsorowanie opłat i rezerw przy zachowaniu kontroli użytkownika nad kluczami.

DynamicMPT celuje w emitentów tokenów. Propozycja XLS-94 pozwala emitentom na oznaczenie wybranych właściwości MPT jako zmiennych podczas tworzenia tokena, a następnie aktualizację tych dozwolonych pól w późniejszym czasie. Standard ten ma na celu dostosowanie się do zmieniających się wymogów biznesowych lub zgodności bez czynienia każdej właściwości tokena swobodnie edytowalną.

Razem te funkcje wpisują się w rosnący nacisk XRPL na tokenizowane finanse. W związanym artykule o tokenizacji, crypto.news poinformował, że JPMorgan, Mastercard, Ondo Finance i Ripple przetestowali tokenizowany wykup bonów skarbowych przy użyciu XRPL.

Nie każda cytowana aktualizacja należy do wersji 3.3.0

Jedna korekta jest konieczna w odniesieniu do szeroko rozpowszechnionego 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 nad LendingProtocolV1_1 oraz oddzielny tor fixCleanup3_3_0 obok głównych funkcji.

Wydanie to nie powinno być zatem odczytywane jako sześć gotowych funkcji stających się dostępnych jednocześnie. Jest to kamień milowy w oprogramowaniu serwerowym, który daje walidatorom i operatorom kod potrzebny do decyzji dotyczących poprawek. 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 zidentyfikowaniu 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 wspierać 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 natychmiastowa zmiana ma charakter techniczny, a nie monetarny. Wersja 3.3.0 rozszerza potencjalny zestaw narzędzi sieci o prywatność, wieloetapowe rozliczenia, 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 wersji 3.3.0 przez walidatorów, poziomy wsparcia poprawek i zaplanowane daty aktywacji. Dopóki te progi nie zostaną osiągnięte, nowe funkcje powinny być opisywane 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.