XRP Ledger testuje płatności uwalniane na warunkach, gdy Smart Escrow Devnet osiąga dziewiąte wydanie
Najważniejsze informacje
- •5 października Mayukha Vadari, inżynierka oprogramowania w RippleX, ogłosiła dziewiąte wydanie Smart Escrow Devnet, które przenosi testy na nową infrastrukturę wasm-devnet.dev.ripplex.io po wycofaniu punktów końcowych wasm.devnet.rippletest.net.
- •Smart Escrow ma na celu dołączanie małego programu WebAssembly do escrow w momencie jego tworzenia, co pozwala na uwolnienie zablokowanych środków tylko wtedy, gdy spełnione są niestandardowe, z góry określone reguły.
- •Dziewiąte wydanie przenosi integrację WebAssembly z C++ na Rust, ujednolicając rozliczanie gazu, obsługę błędów i walidację przez jeden punkt wejścia, ze szacowaną poprawą wywołań funkcji hosta o 30% do 50%.
- •Kod Smart Escrow musi działać w ograniczonej piaskownicy z limitami wywołań zewnętrznych, plików, pamięci i mocy obliczeniowej, a każde escrow zawierające kod bajtowy musi uwzględniać czas CancelAfter, aby użytkownicy mogli odzyskać zablokowane środki.
- •Funkcja pozostaje projektem roboczym XLS-0100, a nie aktywną możliwością księgi, a dotarcie do sieci głównej wymagałoby formalnej poprawki walidatorów wraz z dalszą implementacją i przeglądem bezpieczeństwa.

Proponowana funkcja Smart Escrow w XRP Ledger poczyniła postępy w fazie testów. 5 października Mayukha Vadari, inżynierka oprogramowania w RippleX, której praca koncentruje się na programowalności XRPL, ogłosiła dziewiąte wydanie Smart Escrow Devnet. Zgodnie z jej notatką wydawniczą sieć testowa przeniosła się na nową infrastrukturę, zastępując wycofane punkty końcowe wasm.devnet.rippletest.net adresem wasm-devnet.dev.ripplex.io. Proponowana funkcja pozwoliłaby, by płatności escrow w księdze podlegały ograniczonym, niestandardowym regułom.
Nowy Devnet daje Smart Escrow szerszy test
Zmiana adresu to tylko część aktualizacji. Deweloperzy potrzebują wspólnego środowiska, w którym ich kontrakty, portfele, biblioteki i konfiguracje węzłów mogą być uruchamiane według tych samych reguł — praca ta staje się szczególnie ważna, gdy kod bierze udział w decydowaniu o tym, czy zablokowane środki mogą zostać uwolnione.
Vadari powiedziała, że projekt pozostaje w fazie przeglądu i testów, podczas gdy zespół wzmacnia framework i kod. Devnet zapewnia miejsce do wykrywania problemów ze zgodnością i bezpieczeństwem, zanim Smart Escrow będzie można rozważyć dla sieci produkcyjnej.
Smart Escrow dodaje programowalny warunek do zablokowanych środków
XRPL już obsługuje płatności escrow z prostymi warunkami uwolnienia — możliwość tę sieć główna oferuje od końca 2017 roku. Środki mogą stać się dostępne po określonym czasie lub gdy ktoś dostarczy wymagane kryptograficzne potwierdzenie realizacji. Takie reguły odpowiadają prostym ustaleniom, choć aplikacja może potrzebować wskazanego zatwierdzającego, zweryfikowanego zdarzenia lub kilku sprawdzanych razem warunków.
Rozważmy kupującego, który blokuje XRP dla sprzedającego: escrow zostaje uwolnione dopiero po tym, jak wskazany notariusz potwierdzi dostawę, termin pozwala kupującemu odzyskać środki, jeśli takiego potwierdzenia nigdy nie będzie. Smart Escrow jest zaprojektowany właśnie dla takich przypadków. Mały program WebAssembly byłby dołączany przy tworzeniu escrow, a następnie uruchamiany, gdy ktoś próbuje je zakończyć. Program ocenia uzgodnioną regułę i decyduje, czy uwolnienie może nastąpić.
Proponowane zmiany w XRP Ledger są dokumentowane w publicznych propozycjach XLS (XRP Ledger Standard). Specyfikacja XLS-0100 Smart Escrows wymienia możliwe zastosowania, od blokad zgodności i płatności etapowych po vesting tokenów, mechanizmy aukcyjne i warunki oparte na wyroczniach. Każdy przypadek użycia opiera się na tej samej idei: reguły uwolnienia środków są zapisywane w escrow przed zablokowaniem pieniędzy.
Ograniczenia mają chronić sieć i środki
Każdy system uruchamiający kod wokół płatności potrzebuje jasnych limitów. Każdy walidator XRPL musi osiągnąć ten sam wynik przy zakończeniu escrow; w przeciwnym razie sieć nie mogłaby uzgodnić stanu księgi.
Kod Smart Escrow działa zatem w ograniczonym środowisku. Nie może swobodnie wywoływać usług zewnętrznych ani uzyskiwać dostępu do plików, a podlega limitom pamięci i mocy obliczeniowej. Te granice pomagają zapobiegać nadmiernemu zużyciu zasobów przez źle napisany kontrakt lub powstawaniu sprzecznych wyników u różnych walidatorów i mają zapobiegać uwięzieniu środków.
Propozycja wymaga również, aby każde Smart Escrow zawierające kod bajtowy uwzględniało czas CancelAfter. Użytkownicy mieliby sposób na odzyskanie zablokowanych środków, jeśli warunek nie może zostać spełniony, kontrahent nie działa lub kod zawiera błąd.
Biblioteka deweloperska Smart Escrow firmy Ripple zawiera już przykłady obejmujące zatwierdzenie notariusza, weryfikację poświadczeń, dane wyroczni i własność NFT. Przykłady te pokazują rodzaje reguł, które deweloperzy mogą testować, a Devnet ujawnia, czy podstawowy system obsługuje je spójnie.
Dziewiąte wydanie aktualizuje mechanizm stojący za tymi regułami
Dziewiąte wydanie reorganizuje sposób uruchamiania kodu Smart Escrow przez sieć. Vadari powiedziała, że integracja WebAssembly została przeniesiona z C++ na Rust, łącząc rozliczanie gazu, obsługę błędów i kontrole walidacji przez jeden punkt wejścia. Jej notatka wydawnicza szacuje 30-50% poprawę wywołań funkcji hosta — technicznego wskaźnika istotnego dla deweloperów budujących i testujących logikę escrow. Sam WebAssembly to izolowany format kodu używany daleko poza XRP Ledger — Polkadot, NEAR i kilka łańcuchów opartych na Cosmos uruchamia na nim inteligentne kontrakty — a Rust należy do najczęściej używanych języków dla tego celu.
Zmieniły się również biblioteki oprogramowania. Deweloperzy są proszeni o odejście od przestarzałego pakietu typu all-in-one na rzecz osobnych bibliotek — wspólnej i skupionej na escrow — a następnie ponowne przetestowanie aplikacji na nowym Devnecie. Kontrakt kompilujący sięnie nadal musi współpracować z siecią, jej formatem transakcji i otaczającymi go narzędziami.
To praktyczna wartość tego wydania: daje zespołom bardziej stabilne środowisko do znajdowania problemów, które pojawiają się dopiero wtedy, gdy kilka elementów infrastruktury musi współpracować.
Warunkowe escrow mogłoby uzupełniać zautomatyzowane płatności
Reguły kontrolowanego uwalniania mogłyby również uzupełniać prace XRP Ledger nad płatnościami AI w XRP i RLUSD, stabilnej monecie powiązanej z dolarem przez Ripple. Agent może przygotować płatność, a Smart Escrow mógłby definiować okoliczności, w których środki już umieszczone w escrow mogą się przemieścić.
Ten podział daje aplikacjom przestrzeń do automatyzacji rutynowych kroków bez pozostawiania warunków uwolnienia pieniędzy w niejasności. Portfel, żądanie płatności i escrow pełnią różne role, co ułatwia ustalenie, gdzie podjęto decyzję, jeśli coś pójdzie nie tak.
Smart Escrow nadal potrzebuje drogi do sieci głównej
Smart Escrow pozostaje projektem roboczym, a nie funkcją XRP Ledger. Wersja produkcyjna wymagałaby formalnej poprawki — mechanizmu księgi do wdrażania zmian protokołu, w którym walidatory sygnalizują poparcie, a aktualizacje aktywują się dopiero po szerokim konsensusie — a także dalszej implementacji i przeglądu bezpieczeństwa, po czym nastąpiłby proces aktywacji w sieci głównej.
Dziewiąta wersja Devnet daje deweloperom lepsze miejsce do testowania proponowanych reguł. Jej postępy będą mierzone udanymi migracjami, ustaleniami dotyczącymi bezpieczeństwa i reakcją szerszej społeczności XRPL, gdy funkcja zmierza w kierunku ewentualnej drogi do sieci głównej.
Ten artykuł ma charakter wyłącznie informacyjny i nie stanowi porady inwestycyjnej. Smart Escrow jest w fazie rozwoju, a jego specyfikacje, harmonogram i droga do sieci głównej mogą ulec zmianie.