Ripple wydało XRP Ledger w wersji 3.0.0 i wezwało walidatorów oraz operatorów węzłów do szybkiej aktualizacji, aby uniknąć zakłóceń. To nie jest zwykła aktualizacja. Dzieje się tak, ponieważ naprawia ona fundamentalny problem technologiczny związany z escrow tokenów.
Jest to jedna z kluczowych funkcji wykorzystywanych do rozliczeń, a także zaplanowanych transakcji na XRPL. Osoby zaangażowane w tworzenie aplikacji korporacyjnych uważają escrow za jeden z istotnych filarów zaufania.
Przeczytaj również: XRPL Q2 odnotowuje rekordowe 154% wzrostu adopcji RLUSD przy rosnącej kapitalizacji rynkowej XRP
Escrow zawsze było integralną częścią usług rozliczeniowych XRPL. Przez długi czas obsługiwało wyłącznie XRP. Ale oznaczało to, że gdyby firma miała emitować swoje tokeny na XRPL, miałaby trudności z wykorzystaniem zaawansowanych funkcji.
Propozycja nazwana XLS-85 Token Escrow wprowadziła usługę escrow dla emitowanych aktywów, takich jak IOU oraz tokeny wielofunkcyjne.
Tokeny wielofunkcyjne są szczególnie istotne w tokenizacji. Stanowią połączenie tokenów wymiennych i niewymiennych, a także zawierają dużą ilość metadanych.
Deweloperzy XRPL przytaczają tokeny wielofunkcyjne jako rozwiązanie dla środowiska o wysokiej zgodności z przepisami, ponieważ mogą one zawierać reguły i cykle życia bez korzystania z zewnętrznych inteligentnych kontraktów.
Wewnętrzni testerzy oryginalnego projektu Token Escrow zauważyli problem dotyczący MPT, które zawierają opłaty transferowe. Problem ten pojawił się po zakończeniu procesu escrow i odblokowania tokenów.
Gdy 100 tokenów zostało odblokowanych, z opłatą transferową wynoszącą 1 token, odbiorca faktycznie otrzymał 99 tokenów.
Problem tkwił w księgowości emitentów. Księga zmniejszyła LockedAmount emitenta tylko o 99 zamiast całych 100 pierwotnie zdeponowanych w escrow. W ten sposób jeden token pozostał w stanie zablokowanym. Ostatecznie ten drobny problem może się kumulować i prowadzić do rozbieżności w ilościach podaży w sieci.
Eksperci śledzący infrastrukturę XRPL nieustannie podkreślali zagrożenia wynikające z najmniejszych rozbieżności księgowych w kontekście sieci tokenów i jak mogą one podważać zaufanie do takich sieci.
Problem ten został rozwiązany w poprawce TokenEscrowV1, w której logika brutto escrow została oddzielona od dostawy netto. Po zakończeniu escrow, LockedAmount zmniejszy się o całą wcześniej zablokowaną wartość.
Opłaty transferowe będą przetwarzane niezależnie, tak aby tylko wartość netto wpływała na podaż. Żadne tokeny nie pozostaną zablokowane, a całkowite wartości podaży będą utrzymywane dokładnie.
Przeczytaj również: Portfel XRPL nowej generacji od Anodos upraszcza onboarding i nagradza użytkowników


