David „JoelKatz" Schwartz zaproponował plan rezerwacji transakcji dla XRP Ledger po pojawieniu się nowych twierdzeń, że użytkownicy mogą nadal być narażeni na ataki front-running i sandwich na płatności, crossing ofert, transakcje DEX i swapy AMM.
Debata rozpoczęła się po tym, jak XRPresso stwierdziło, że niektórzy aktorzy mogą być w stanie przeglądać oczekujące transakcje przed zamknięciem księgi i wykorzystywać te informacje do celowania w transakcje.
„Na XRPL utrzymuje się poważny problem front-runningu, który działa na niekorzyść zwykłych użytkowników." XRPresso stwierdziło, że walidatorzy i dobrze połączone węzły mogą przeglądać transakcje w kolejce przed walidacją, a następnie składać własne transakcje, aby uzyskać lepszą pozycję w końcowej kolejności księgi.
XRPresso stwierdziło, że problem ten jest najbardziej istotny dla użytkowników handlujących za pośrednictwem portfeli i dApps. Według wpisu, końcowa kolejność w każdej księdze podąża za znanym procesem deterministycznym, a wielokrotne zgłoszenia mogą zwiększyć szansę na znalezienie się blisko docelowej transakcji. Może to pogorszyć poślizg dla pierwotnego tradera, gdy strategia sandwich odniesie sukces.
„Z powodów, które wyjaśniłem, nie jestem szczególnie zaniepokojony tym problemem." Schwartz napisał, że kwestia ta nadal zasługuje na praktyczną odpowiedź. Następnie zaproponował schemat rezerwacji transakcji, który mógłby sprawić, że ujawniona transakcja zostanie wykonana przed jakąkolwiek transakcją utworzoną po jej ujawnieniu.
Plan zakładałby dodanie nowego obiektu księgi o nazwie ReservedTxns. Obiekt ten przechowywałby numer sekwencji księgi i tablicę identyfikatorów transakcji. Nowa transakcja TxnReserve pozwoliłaby użytkownikowi zarezerwować slot dla transakcji w przyszłej księdze, o ile żądanie spełnia zasady dotyczące opłat, czasu i wykonania.
Schwartz powiedział, że rezerwacja powinna kosztować co najmniej dwa razy więcej niż normalna opłata transakcyjna. Docelowa księga musiałaby być większa niż bieżąca księga i nie więcej niż 16 ksiąg do przodu. Każdy zarezerwowany obiekt przechowywałby mniej niż 32 identyfikatory transakcji, chyba że projekt później rozszerzy limit.
Zgodnie z propozycją, zarezerwowana transakcja byłaby rozgłaszana w pobliżu momentu, gdy propozycje poprzedniej księgi są znane. Schwartz powiedział, że oprogramowanie XRPL mogłoby dodać funkcję wstrzymywania takich transakcji i zwalniania ich dopiero po spełnieniu tego warunku. Transakcja powinna również ustawić swoją ostatnią ważną księgę na księgę, w której ma być wykonana.
Gdy ta księga zostanie wykonana, sieć najpierw sprawdzi, czy dla numeru sekwencji księgi istnieje obiekt ReservedTxns. Jeśli istnieje, sieć wykona wymienione transakcje, które są w zestawie konsensusu, przed innymi transakcjami. Następnie usunie je z zestawu, aby zapobiec powtórnemu wykonaniu, i usunie obiekt rezerwacji.
Dokumentacja XRPL mówi, że kanoniczne porządkowanie jest zbudowane tak, aby było deterministyczne, wydajne i trudne do manipulowania. Dokumentacja DEX stwierdza również, że kolejność transakcji jest zaprojektowana w celu zniechęcenia do front-runningu, ponieważ transakcje są wykonywane po zamknięciu nowej księgi. Jednak dokumentacja dotycząca algorytmicznego tradingu XRPL mówi, że front-running jest trudny, ale nie niemożliwy.
Czas ten zbiega się z tym, jak deweloperzy XRPL kontynuują rozbudowę stosu DeFi sieci. Fundacja XRPL niedawno zaproponowała AMM Swappable Curves – projekt ulepszenia, który dodałby opcje StableSwap i skoncentrowanej płynności do natywnego automatycznego animatora rynku. XRPL przygotowuje również natywne narzędzia do pożyczek i programowalnego depozytu escrow.
Te ulepszenia mogą przynieść więcej aktywności handlowej on-chain, kredytowej i rozliczeniowej do XRPL. Ostatnie doniesienia pokazały również przypadki zastosowań instytucjonalnych, w tym rozliczenie tokenizowanego Treasury z udziałem Ripple i JPMorgan. Wraz ze wzrostem aktywności, kolejność transakcji i widoczność oczekujących transakcji mogą przyciągać więcej uwagi ze strony twórców, traderów i walidatorów.
Schwartz odniósł się również do możliwych zagrożeń atakami typu denial-of-service. Powiedział, że atakujący mógłby próbować wypełnić sloty rezerwacji w wielu księgach, ale rosnące opłaty mogłyby to uczynić kosztownym. W jednym z przykładów opłaty wzrosłyby po wypełnieniu 16 slotów i mogłyby osiągnąć kilkukrotność bazowej rezerwy przy około 30 slotach. Propozycja nie jest jeszcze formalną poprawką, ale daje społeczności XRPL jasną ścieżkę techniczną do przeglądu.


