XRP Ledger zbliża się do aktywacji aktualizacji ograniczonego dostępu do konta (Permission Delegation)
Najważniejsze informacje
- •PermissionDelegationV1_1 wszedł 21 września w 14-dniowy okres aktywacji z poparciem 29 z 35 zaufanych walidatorów XRP Ledger; do utrzymania poparcia do przewidywanej aktywacji 5 października wymaganych jest co najmniej 28 walidatorów.
- •Zgodnie ze specyfikacją XLS-75 delegujący może przypisać kontu delegata do dziesięciu predefiniowanych uprawnień za pomocą transakcji DelegateSet, a XRPL odrzuca żądania wykraczające poza zapisane uprawnienia.
- •Skompromitowany delegat pozostałby ograniczony do swojej przypisanej roli, co zmniejsza szkody spowodowane ujawnionym kluczem operacyjnym, choć wrażliwe uprawnienia, takie jak zmiana kluczy podpisujących czy mianowanie nowych delegatów, nie mogą być delegowane.
- •Pierwotna implementacja zawierała błąd, który mógł obciążać prowizjami inne konto poprzez niewłaściwie podpisane transakcje, ale został wykryty podczas testów, nigdy nie uruchomiono go na mainnecie, a środki rzeczywistych użytkowników nie ucierpiały.
- •Sama aktywacja nie ustanowi adopcji instytucjonalnej, ponieważ portfele i dostawcy usług powierniczych muszą wciąż zbudować interfejsy, decyzje zgodności pozostają poza rejestrem, a nie ogłoszono żadnego wdrożenia przez konkretny bank.

XRP Ledger (XRPL) zbliża się do aktywacji aktualizacji, która pozwoliłaby organizacjom podzielić kontrolę nad pojedynczym kontem pomiędzy wiele kont delegowanych, ograniczając władzę każdego pojedynczego klucza operacyjnego.
PermissionDelegationV1_1 jest zaprojektowany dla organizacji, które przetwarzają transakcje często, ale nie chcą, aby klucze zdolne do kontrolowania całego konta znajdowały się w codziennych systemach operacyjnych. Emitent stablecoina może na przykład potrzebować jednego systemu do zatwierdzania linii zaufania klientów (mechanizmu rejestru do przechowywania emitowanych aktywów), drugiego do przetwarzania płatności oraz bardziej chronionej konfiguracji do zarządzania bezpieczeństwem konta. Poprawka pozwoliłaby podzielić te obowiązki pomiędzy oddzielne konta XRPL.
Jej „bankowy” element to rozdzielenie odpowiedzialności. Nie oznacza to zatwierdzenia regulacyjnego ani potwierdzonej adopcji przez bank. Skompromitowany delegat mógłby nadal być wykorzystany w ramach swojej przypisanej roli, ale atakujący nie otrzymałby automatycznie wszystkich uprawnień posiadanego przez konto główne, co zmniejsza potencjalne szkody wyrządzone przez pojedynczy ujawniony klucz operacyjny.
XRPL wymuszałby każde uprawnienie na łańcuchu
Zgodnie ze specyfikacją XLS-75 kontem przekazującym uprawnienia jest delegujący. Przesyła on transakcję DelegateSet, wskazującą drugie konto oraz działania, które to konto może wykonywać. Relacja jest zapisywana we wpisie Delegate w rejestrze.
Delegat podpisuje własnymi kluczami, identyfikuje konto, dla którego działa, i opłaca prowizję transakcyjną. XRPL odrzuca żądania wykraczające poza zapisane uprawnienia, a delegujący może później zaktualizować lub cofnąć te uprawnienia.
Oficjalna dokumentacja wymienia uprawnienia typu transakcyjnego oraz węższe uprawnienia szczegółowe, a każdy delegat może otrzymać najwyżej dziesięć. Dostępne szczegółowe kontrole są predefiniowane, więc organizacje nie mogą tworzyć dowolnych restrykcji. Delegaci muszą również utrzymywać konta z zasobami, a każda delegacja tworzy obiekt na łańcuchu, który zwiększa wymóg rezerwy właściciela delegującego, czyli minimalną ilość XRP, jaką konto musi posiadać dla każdego posiadanego obiektu rejestru.
Wrażliwe uprawnienia, w tym zmiana kluczy podpisujących czy mianowanie nowych delegatów, nie mogą być delegowane. Transakcje, które nie mogą trafić do otwartego rejestru natychmiast, kończą się niepowodzeniem zamiast trafiać do kolejki.
Dwadzieścia dziewięć głosów rozpoczęło warunkowe odliczanie
PermissionDelegationV1_1 wszedł 21 września w 14-dniowy okres aktywacji z poparciem 29 z 35 zaufanych walidatorów XRP Ledger, według bieżącej listy poprawek. Poprawki to wbudowany w rejestr mechanizm zmiany jego zasad, a utrzymane poparcie walidatorów sprawia, że nowy kod protokołu trafia na mainnet. Co najmniej 28 walidatorów musi dalej go wspierać, a spadnięcie poniżej tego poziomu zresetowałoby odliczanie. CoinDesk poinformował, że przewidywany czas aktywacji to 5 października o 11:18 UTC, o ile poparcie pozostanie nieprzerwane.
Kod istnie już w oprogramowaniu serwerowym XRPL, ale nie może być używany na mainnecie przed aktywacją. Oddzielna poprawka Batch V1.1 przechodzi ten sam dwutygodniowy proces, choć dotyczy powiązanych transakcji, a nie uprawnień do kont.
Delegacja nie zastępuje wielopodpisu
Wielopodpis określa, ile zatwierdzonych stron musi autoryzować działanie, podczas gdy delegowanie uprawnień ogranicza, które działania konto operacyjne może żądać. Organizacja mogłaby je połączyć, ograniczając delegata do płatności, przy jednoczesnym wymaganiu zatwierdzenia każdej płatności przez kilka osób.
Po kompromitacji klucza wielopodpis może uniemożliwić jednemu skradzionemu podpisującemu osiągnięcie progu zatwierdzenia, podczas gdy delegacja może ograniczyć dostępne atakującemu typy transakcji nawet po skompromitowaniu konta delegowanego. Żadna z tych kontrol nie weryfikuje, czy instrukcja biznesowa jest uprawniona.
Pierwotna wersja zawiodła przed dotarciem na mainnet
Społecznościowy tester odkrył, że pierwsza implementacja PermissionDelegation mogła w określonych warunkach obciążać prowizją transakcyjną inne konto, nawet gdy transakcja delegowana była niewłaściwie podpisana. Powtarzające się przesyłki z wysokimi prowizjami mogły obniżyć saldo XRP ofiary bez ujawnienia jej klucza prywatnego.
Błąd został wykryty podczas testów, a poprawka nigdy nie została aktywowana na mainnecie. Oficjalne zgłoszenie podatności nie odnotowało utraty środków rzeczywistych użytkowników.
Coindoo wcześniej analizował, dlaczego Permission Delegation powrócił w zmienionej formie wśród poprawek xrpld 3.3.0. Nowe głosowanie pokazuje, że walidatorzy są teraz skłonni rozważyć aktywację zamiennika.
Aktywacja nie ustanowi adopcji instytucjonalnej
Portfele i dostawcy usług powierniczych muszą wciąż zbudować interfejsy do tworzenia, przeglądania i odwoływania delegowanych uprawnień. Nie ogłoszono żadnego wdrożenia przez konkretny bank, a instytucje pozostają odpowiedzialne za decydowanie, które konta otrzymają dane uprawnienia.
Decyzje dotyczące zgodności również pozostałyby poza rejestrem. Firma nadal przeprowadzałaby weryfikację tożsamości, screening sankcyjny i oceny ryzyka we własnych systemach. XRPL wymuszałby, który delegat może przesć wynikową autoryzację; nie określałby, czy klient powinien został zatwierdzony.
Korzystanie z funkcji byłoby widoczne poprzez publiczne wpisy Delegate, choć powiązanie adresu z firmą mogłoby wymagać dobrowolnego ujawnienia. Konta delegatów również potrzebują XRP na rezerwy i prowizje, ale aktywacja nie ustanawia żadnego wolumenu użytkowania ani automatycznego popytu na token.
Użytkowanie produkcyjne stanie się kolejnym testem
Jeśli poparcie walidatorów się utrzyma, dowody przyniosą integracje portfeli, nowe wpisy Delegate i nazwane wdrożenia. Te sygnały pokażą, czy organizacje potrzebują rozdzielenia własności konta i codziennych operacji na poziomie protokołu.
Głosowanie czyni ograniczony dostęp do konta możliwym. Jego wartość będzie zależała od tego, jak wąsko organizacje skonfigurują te uprawnienia i czy będą korzystać z funkcji poza demonstracjami.
Ten artykuł ma wyłącznie charakter informacyjny i nie stanowi porady finansowej, prawnej ani bezpieczeństwa. Poparcie walidatorów i czasy aktywacji mogą ulec zmianie.