Poprawka Batch V1.1 XRP Ledger przesunęła się o jeden głos walidatora od rozpoczęcia dwutygodniowego procesu aktywacji, po tym jak programiści naprawili kolejnych 11 problemów z oprogramowaniem wykrytych podczas przeglądów bezpieczeństwa.
Podsumowanie
- Batch V1.1 XRP Ledger zdobył 27 z 35 głosów walidatorów, pozostawiając mu jeden głos do progu aktywacji wynoszącego 80%.
- Programiści naprawili kolejnych 11 problemów dotyczących podpisów, kontroli autoryzacji i potencjalnych awarii serwera przed najnowszym głosowaniem.
- Batch pozwoliłby użytkownikom połączyć do ośmiu transakcji w jedną operację i wymagałby, aby powiązane płatności zostały zrealizowane razem.
- Obecna wersja zastąpiła wcześniejszą propozycję Batch po tym, jak badacze odkryli poważną wadę autoryzacji, zanim trafiła do mainnetu.
RippleX powiedział w poniedziałek, że najnowszy przegląd Batch V1.1 zidentyfikował problemy dotyczące podpisów transakcji, kontroli autoryzacji i awarii serwera, a poprawki zostały włączone do wersji obecnie rozważanej przez walidatorów XRP Ledger.
Wsparcie wyniosło 27 z 35 zaufanych walidatorów we wtorek, co stanowi około 77%, pozostawiając propozycję tuż poniżej poziomu 80% wymaganego do wejścia w okres aktywacji sieci.
Aktualizacja XRP Ledger Batch zbliża się do 80% wsparcia
Batch V1.1 pozwoliłby na grupowanie nawet ośmiu transakcji w jedną operację, z regułami wykonania, które mogą wymagać, aby powiązane transakcje zakończyły się sukcesem razem.
W przypadku wymiany tokenów między dwoma użytkownikami, funkcja ta mogłaby uzależnić oba transfery od siebie. Jeśli jedna strona wymiany zawiedzie, druga transakcja nie zostałaby zrealizowana niezależnie.
Portfele i platformy handlowe mogłyby użyć tej samej struktury do przetworzenia płatności klienta i opłaty platformy razem. RippleX powiedział, że projekty komercyjne wykorzystujące Batch są już objęte umowami lub w fazie rozwoju, choć zespół programistów nie ujawnił publicznie zaangażowanych firm.
Wsparcie walidatorów szybko wzrosło w ciągu ostatniego tygodnia. 8 września Batch V1.1 miał 24 głosy od 35 walidatorów na domyślnej Unikalnej Liście Węzłów, co stanowi 68,57%, jak wcześniej informował crypto.news. Od tego czasu trzech kolejnych walidatorów poparło poprawkę.
Zgodnie z zasadami zarządzania XRP Ledger, poprawka musi utrzymać co najmniej 80% wsparcia walidatorów przez 14 kolejnych dni, zanim będzie mogła zostać aktywowana. Przy obecnie liczonych 35 zaufanych walidatorach, kolejny głos poparcia przeniósłby Batch V1.1 powyżej progu i rozpocząłby ten okres.
Wynik nie zostałby ustalony po rozpoczęciu odliczania. Walidatorzy mogą zmieniać swoje stanowiska, a spadek wsparcia poniżej 80% w ciągu 14-dniowego okna przerwałby proces aktywacji.
Podobny proces miał miejsce w lipcu, kiedy poprawka fixCleanup3_2_0 zdobyła 85,71% wsparcia i weszła w swoje okno aktywacji. Pakiet następnie został aktywowany 29 lipca po utrzymaniu wystarczającego poparcia walidatorów przez wymagany okres.
Batch V1.1 zastępuje wcześniejszą wersję z poważną wadą
Obecne głosowanie następuje po wycofaniu oryginalnego projektu Batch po tym, jak badacze odkryli lukę, zanim funkcja trafiła do mainnetu XRP Ledger.
W pewnych warunkach wada mogła pozwolić atakującemu na umieszczenie transakcji z konta innego użytkownika w partii bez uzyskania wymaganej autoryzacji. Żadne środki użytkowników nie były zagrożone, ponieważ dotknięta poprawka nigdy nie została aktywowana.
Programiści odbudowali funkcję po odkryciu, a Batch V1.1 został później włączony do xrpld 3.3.0, wydanego 6 sierpnia.
Wydanie xrpld 3.3.0 wprowadziło poprawioną implementację Batch wraz z kilkoma innymi proponowanymi funkcjami protokołu. Każda poprawka nadal wymaga oddzielnej zgody walidatorów przed aktywacją w mainnecie.
Inżynier oprogramowania RippleX, Mayukha Vadari, powiedział, że pierwotny problem z podpisem został znaleziony w lutym przed wdrożeniem mainnetu. Kolejne prace obejmowały poprawkę przyczyny źródłowej, przeglądy przez czterech starszych inżynierów, konkurs bezpieczeństwa Sherlock oraz audyty od Halborn i Common Prefix.
„Po tym, jak w lutym wykryto błąd sygnatury w wersji v1.0 (przed Mainnet, żadne środki nie były zagrożone), przebudowaliśmy go” – napisała Vadari na X 14 września.
Proces przeglądu nie zakończył się na początkowej podatności. RippleX poinformował, że znaleziono kolejnych 11 problemów podczas badania implementacji zastępczej.
Przeglądy bezpieczeństwa wykryły 11 kolejnych problemów w Batch
Dodatkowe ustalenia obejmowały obsługę sygnatur, kontrole autoryzacji oraz warunki oprogramowania mogące powodować awarie serwerów.
Common Prefix zaklasyfikował jedną z podatności jako krytyczną. Według przeglądu RippleX problem mógł pozwolić atakującemu na ponowne wykorzystanie uprawnienia podpisanego przez użytkownika i przeprowadzenie większej liczby transakcji, niż użytkownik pierwotnie zamierzał autoryzować.
Inne ustalenia dotyczyły sposobu, w jaki transakcje Batch weryfikowały uprawnienia i przetwarzały sygnatury. Deweloperzy rozwiązali zgłoszone problemy, zanim poprawka osiągnęła obecny etap głosowania walidatorów.
RippleX poinformował, że czterech starszych inżynierów dokonało przeglądu implementacji, podczas gdy Halborn i Common Prefix przeprowadzili zewnętrzne audyty. Kod przeszedł zautomatyzowane testy oraz publiczny konkurs bezpieczeństwa zaprojektowany w celu ujawnienia słabości przed aktywacją.
Testy bezpieczeństwa były stosowane w innych niedawnych propozycjach XRP Ledger. Czerwcowy przegląd bezpieczeństwa Common Prefix zidentyfikował problemy numeryczne i behawioralne w komponentach XRPL, a poprawki wdrożono w wersji 3.2.0. Firma zajmująca się bezpieczeństwem została następnie wyznaczona do formalnej weryfikacji i analizy innych części sieci.
Osobny konkurs Sherlock obejmujący proponowane funkcje XRP Ledger wykrył dziesiątki ważnych podatności, zanim objęte nimi poprawki trafiły do mainnetu, w tym ustalenia o krytycznym i wysokim stopniu ważności.
Batch jest częścią zestawu funkcji xrpld 3.3.0
Batch to jedna z kilku zmian protokołu wprowadzonych w cyklu oprogramowania 3.3.0, podczas gdy deweloperzy XRP Ledger pracują nad rozliczaniem transakcji, prywatnością, uprawnieniami i funkcjami instytucjonalnymi.
Przed wydaniem oprogramowania deweloperzy przedstawili pięć proponowanych poprawek XRPL, które obejmowały transakcje Batch, Confidential MPT, Sponsor, Dynamic MPT i Permission Delegation.
Batch został zaprojektowany wokół rozliczenia atomowego, w którym wiele powiązanych operacji można obsłużyć jako skoordynowaną transakcję zamiast przesyłać je osobno.
Permission Delegation pozwoliłoby kontu przyznać ograniczone uprawnienia innemu kontu bez przekazywania pełnej kontroli. Confidential MPT ma na celu ukrycie sald i kwot transferów dla Multi-Purpose Tokens, przy jednoczesnym zachowaniu widoczności tożsamości kont w publicznym rejestrze.
Żadna z funkcji nie staje się aktywna wyłącznie dlatego, że jej kod został zawarty w xrpld. Walidatorzy osobno decydują, czy poprzeć poprawki, pozostawiając każdą propozycję w jej własnym harmonogramie głosowania.
Sieć odnotowała już różne wskaźniki adopcji wśród propozycji z 3.3.0. Ripple zagłosował w sierpniu za poprawką PermissionDelegationV1_1, gdy miała ona poparcie siedmiu z 35 zaufanych walidatorów.
Od tego czasu Batch znacznie zbliżył się do progu aktywacji. Jego obecne 27 głosów pozostawia poprawkę o jednego wspierającego walidatora od rozpoczęcia 14-dniowego okresu, pod warunkiem że istniejące głosy pozostaną w mocy.
RippleX nie wymienił projektów komercyjnych, o których mówił, że są objęte umową lub w fazie rozwoju, aby korzystać z Batch. CoinDesk podał, że zapytał zespół deweloperów, które firmy przygotowują się do korzystania z tej funkcji oraz czy 11 najnowszych poprawek zostało poddanych niezależnemu przeglądowi względem wersji obecnie rozważanej przez walidatorów.
