Czy Ethereum sprawi, że rollupy będą działać jak jedna sieć?

Trader w demonstracji na Devcon podpisał jedno zlecenie na rollupie Ethereum, kupił tokeny wykorzystując płynność w sieci głównej i otrzymał je z powrotem na rollupie. Transakcja pokazuje, jak użytkownicy mogliby dotrzeć do głębszego rynku bez samodzielnego przenoszenia środków — podejście, które Gnosis obiera za cel dla swojej domyślnej konfiguracji wiosną 2027 roku.

Zespół Ethereum Economic Zone zademonstrował transakcję, w której użytkownik podpisał jedno zlecenie w eksperymentalnej sieci Rollup X, solver CoW Swap zrealizował je wykorzystując płynność sieci głównej Ethereum, a zakupione tokeny wróciły na rollup. Demonstracja pokazuje, jak trader mógłby dotrzeć do głębszego rynku w sieci głównej bez uprzedniego wysyłania tam środków i czekania na ich dotarcie przed złożeniem zlecenia.

Zespół zaprezentował tę transakcję na Devcon 4 listopada, jak informował crypto.news. To rozróżnienie ma znaczenie, gdy ceny zmieniają się szybko, ponieważ kwotowanie dostępne w momencie, gdy trader zaczyna przenosić środki, może się zmienić, zanim środki będą gotowe do handlu.

Gnosis planuje wiosnę 2027 roku na uczynienie tego projektu domyślnym. Dla traderów praktycznym testem będzie to, czy ich portfele i aplikacje handlowe będą mogły zaoferować tę trasę oraz czy cena dostępna w sieci głównej wciąż będzie opłacalna po uwzględnieniu kosztów wykonania.

Jak transakcja działałaby w dwóch środowiskach wykonawczych

Zespół Ethereum Economic Zone rozpoczął od transakcji z października obejmującej 0,001 ETH i aktualizacji stanu rollupu. Swap na Devcon przeniósł ten sam problem koordynacji do środowiska rozpoznawalnego przez traderów. Musiał zrealizować zlecenie wobec płynności na innym łańcuchu i dostarczyć wynikowy aktyw tam, gdzie użytkownik rozpoczął.

Dla tradera zlecenie opisuje wynik. Sprzedawca chce wymienić jeden aktyw na inny, zgodnie z warunkami zlecenia, i otrzymać wynik na rollupie. Solver bierze na siebie odpowiedzialność za znalezienie ścieżki wykonania. To rozróżnienie ma znaczenie, ponieważ użytkownik może autoryzować wynik bez decydowania, z której puli skorzysta solver, ani bez przygotowywania osobnej transakcji dla każdej operacji.

W przykładzie z Devcon ta ścieżka obejmowała sieć główną Ethereum. Płynność handlowa pozostała tam, podczas gdy zlecenie użytkownika pochodziło z Rollup X, a zakupione aktywa do niego wróciły. Demonstracja rozwiązywała zatem problem, który może się pojawić nawet wtedy, gdy aplikacje każdej sieci działają poprawnie samodzielnie. Trader może mieć środki na łańcuchu z płytkim rynkiem dla pożądanej pary, podczas gdy najlepsze wykonanie jest dostępne gdzie indziej.

Trasa z osobnymi krokami naraża użytkownika na decyzje po drodze. Pierwszy transfer może się zakończyć, podczas gdy kwotowanie, które użytkownik widział, już się zmieniło. W tym momencie użytkownik musi albo zaakceptować bieżącą cenę, albo poczekać, albo ponownie przenieść środki. Skoordynowana trasa może uzależnić ruchy aktywów od zakończenia całego zlecenia, pod warunkiem że uczestnicząca infrastruktura może przeprowadzić operację w uzgodnionym oknie wykonania.

Praktyczne rozróżnienie polega na tym, czy trasa obiecuje dostawę, czy wiąże ze sobą poszczególne operacje składowe. Usługa może sprawić, że transakcja międzyłańcuchowa wyda się prosta, biorąc na siebie odpowiedzialność za samą dostawę. Projekt z demonstracji daje aplikacji sposób na powiązanie wyniku na jednym łańcuchu z wykonaniem na innym. To, które podejście oferuje lepsze doświadczenie, zależy od ceny, dostępnych aktywów i warunków, na jakich każda usługa realizuje zlecenie.

Za podpisem użytkownika wciąż kryje się praca. Aplikacja musi przedstawić warunki, solver musi znaleźć trasę i wycenić ją, a uczestniczące sieci muszą uzgodnić odpowiedni stan. System produkcyjny musi obsługiwać awarie w każdym z tych miejsc. Aplikacja może uprościć interfejs, nie sprawiając, że te zadania znikną.

Dla portfela równie praktycznym testem jest zapis transakcji, który może pokazać po wygaśnięciu zlecenia. Jeśli użytkownik podpisze raz, a transakcja zakończy się sukcesem, użytkownik powinien móc zobaczyć otrzymane aktywo i to, które konto je otrzymało. Jeśli ścieżka zawiedzie, portfel nadal potrzebuje sposobu na odróżnienie wygasłego zlecenia od transakcji oczekującej na rozliczenie. Ma to znaczenie podczas ruchu na rynku, gdy trader może złożyć drugie zlecenie i musi wiedzieć, czy pierwsze może jeszcze zostać wykonane.

Na co sieci muszą się zgodzić, zanim będą mogły wykonywać operacje wspólnie

Blockchain rejestruje więcej niż salda. Jego stan obejmuje informacje wykorzystywane przez aplikacje, takie jak uprawnienia kont, salda kontraktów i status transakcji. Kontrakt, który chce polegać na wyniku z innego łańcucha, potrzebuje dowodu dotyczącego tego stanu. Dowód musi być dostępny, gdy kontrakt potrzebuje użyć wyniku.

Gnosis opisuje dwa warunki dla sieci dołączających do projektu EEZ. Muszą one wytworzyć dowód w ramach slotu Ethereum i podążać za Ethereum w przypadku reorganizacji. Gnosis przedstawia je jako warunki dla podłączonej sieci, pozostawiając niektóre wybory implementacyjne poszczególnym uczestnikom.

Slot daje inżynierom termin. Jeśli wytworzenie wymaganego dowodu zajmie sieci więcej czasu niż jest dostępny, druga strona nie może na niej polegać w tym samym oknie. System dowodzenia, który dobrze sprawdza się przy typowych blokach, nadal musi zmierzyć się z nietypowo wymagającym obciążeniem, przerwami i konkurencją o zasoby obliczeniowe.

Drugi warunek dotyczy tego, co się dzieje, gdy najnowsza historia Ethereum się zmienia. Transakcja w innej sieci mogła polegać na zdarzeniu w niedawnym bloku mainnetu. Jeśli zastąpi go konkurencyjny blok, podłączony system potrzebuje reguł postępowania z transakcją zależną. Zgodność ogranicza możliwość utrzymania przez jedną stronę wyniku opartego na zdarzeniu z mainnetu, które nie należy już do akceptowanego łańcucha.

Ta zależność jest ważna dla użytkowników, ponieważ jedna skoordynowana transakcja i ostateczne rozliczenie opisują różne właściwości. Skoordynowane wykonanie dotyczy tego, czy kroki mogą zostać ukończone razem. Ostateczne rozliczenie dotyczy tego, kiedy uczestnicy mogą uznać wynik za rozliczony zgodnie z regułami zaangażowanych sieci. Portfel może oferować jeden widok operacji, jednocześnie odróżniając transakcję włączoną od tej, która osiągnęła status rozliczenia wymagany przez biznes.

Wcześniejsze prace inżynieryjne Gnosis dotyczyły zobowiązań do korzenia bloku, limitów gazu i sposobu przeprowadzania aktualizacji. Te wybory wpływają na to, jak sieci mogą rozpoznawać swoje wyniki i jak dużo pracy aplikacje mogą im zlecić. Październikowy kamień milowy umieścił prostą operację w mainnecie, a listopadowe demonstracje dały deweloperom bardziej zróżnicowane obciążenia do wypróbowania.

Gdzie projekt może wyjść poza handel

Demonstracja Safe zastosowała to samo podejście do własności portfela. Skarbiec, który używa oddzielnych kont w różnych łańcuchach, może napotkać lukę między usunięciem sygnatariusza w jednej sieci a aktualizacją uprawnień gdzie indziej. Przykład pokazał, jak rollup mógł zweryfikować zmianę własności dokonaną w mainnecie w ramach tej samej transakcji.

Trzecia demonstracja zweryfikowała podpis postkwantowy Falcon na rollupie i użyła wyniku do autoryzacji przelewu w mainnecie. Zespół odnotował o 91% niższe zużycie gazu w porównaniu z przeprowadzeniem weryfikacji bezpośrednio w mainnecie. Zmierzona oszczędność dotyczyła tego ćwiczenia weryfikacyjnego, a aplikacja produkcyjna musiałaby uwzględnić pełne koszty wykonania i rozliczenia.

Jeden podpis nadal pozostawia rynek dla wykonania

Ścieżka swapu przenosi część pracy z osoby składającej zlecenie. Solver musi zdecydować, gdzie je zrealizować, uwzględnić opłaty i przesłać operacje wymagane do jego ukończenia. Użytkownik może otrzymać jedną wycenę, mimo że solver wycenił kilka kroków w oferowanej kwocie.

Taki układ jest najbardziej użyteczny, gdy płynność dostępna w innej sieci poprawia transakcję na tyle, by pokryć koszt dotarcia do niej. Małe zlecenie na głębokim lokalnym rynku może być tańsze do zrealizowania lokalnie. Większe zlecenie w płytkiej puli może otrzymać lepszą cenę z płynności mainnetu nawet po uwzględnieniu dodatkowych kosztów wykonania.

Ważne jest również to, co dzieje się z nieudanymi próbami. Wycofanie ruchów aktywów zapobiega pozostawieniu tradera z tylko jedną nogą zamierzonej transakcji. Aplikacja lub solver nadal mogą ponieść koszty związane z aranżacją lub próbą wykonania, w zależności od sposobu implementacji ścieżki. Na rynku produkcyjnym te koszty mogą wpływać na to, które zlecenia solverzy będą skłonni realizować i jak wyceniają swoje oferty.

Dobre porównanie dla traderów wymagałoby użycia tego samego rozmiaru zlecenia, tej samej pary tokenów i tego samego przedziału czasowego. Otrzymaną po opłatach cenę można następnie porównać z lokalnym swapem lub trasą, która przenosi środki w osobnych krokach. Liczba kliknięć odzwierciedla wygodę. Kwota netto otrzymana odzwierciedla samą transakcję.

Jak projekt przeszedł od propozycji do devnetu

Projekt został publicznie zaprezentowany na EthCC wiosną przez Gnosis i ZisK, przy wsparciu Ethereum Foundation. Pierwotna propozycja dotyczyła płynności i aplikacji, które rozproszyły się pomiędzy różnymi sieciami warstwy 2. Rollup X daje deweloperom środowisko do testowania, w jaki sposób współdzielona transakcja może korzystać z tych aplikacji.

Wybór demonstracji ma znaczenie nie bez powodu. Przeniesienie niewielkiej ilości ETH między środowiskami testuje stosunkowo prostą operację. Swap wprowadza potrzebę zrealizowania zlecenia wobec płynności rynkowej i zwrócenia aktywa. Zmiana własności Safe'a wiąże się z uprawnieniami. Weryfikacja podpisu wymaga, aby jedno środowisko przeprowadziło sprawdzenie, a inne podjęło działanie na podstawie jego wyniku. Każda z nich sprawdza inną zależność.

Trasa, która działa dla jednej z tych operacji, może być niepraktyczna dla innej. Swap musi zmierzyć się z cenami i płynnością, które zmieniają się nieustannie. Zmiana własności jest mniej wrażliwa na cenę rynkową, ale może mieć poważniejsze tryby awarii. Aplikacja weryfikacyjna może odnieść korzyść z wykonywania pracy obliczeniowej gdzie indziej, nawet gdy nie ma ekonomicznego powodu do przenoszenia środków między sieciami.

Wspólnym wymogiem jest to, aby kontrakt odbierający mógł polegać na informacjach w momencie, gdy ich potrzebuje. To wywiera presję na oprogramowanie utrzymujące połączenia. Aplikacja może oferować prosty interfejs tylko wtedy, gdy ścieżka wykonania obsługuje wymagany stan i zwraca oczekiwany wynik. W działającym produkcie deweloperzy musieliby zdecydować, które operacje warto umieścić na tej ścieżce, a które mogą działać niezależnie.

Argument Gnosis za uczynieniem tej technologii domyślną opiera się częściowo na tym, czego aplikacje mogłyby uniknąć duplikowania. Zespół budujący w nowej sieci mógłby w przeciwnym razie potrzebować finansowania lokalnej płynności dla długiej listy rynków. Możliwość sięgnięcia do pul mainnetu mogłaby pozwolić mu na oferowanie handlu parą, zanim dedykowana lokalna pula stanie się opłacalna. Dla lokalnego dostawcy płynności ten sam wybór tworzy konkurencję z innego źródła wykonania.

Wpływ na użytkowników najłatwiej zmierzyć w produktach, które ujawniają obie trasy. Portfel mógłby porównać lokalne wypełnienie z wypełnieniem w mainnecie dla tego samego zlecenia i pokazać kwotę netto w tym samym łańcuchu docelowym. Narzędzie skarbowe mogłoby udokumentować, ile osobnych transakcji jest wymaganych do zastosowania zmiany uprawnień. Takie testy pokazałyby, gdzie to podejście zmienia rzeczywiste koszty wykonania lub pracę operacyjną.

Harmonogram ma znaczenie, ponieważ udana demonstracja może być znacznie łatwiejsza w obsłudze niż usługa z wieloma użytkownikami i aplikacjami. Działający system musi obsługiwać jednoczesne żądania, różniące się warunki rynkowe i zmiany oprogramowania. Przeprowadzenie istniejących aplikacji Gnosis Chain przez tę zmianę sprawdziłoby więcej z tych zależności niż same przykłady z Devcon.

Co musiałaby pokryć cena swapu międzyłańcuchowego

Trader porównuje ilość zakupionego aktywa, która dociera po uwzględnieniu kosztów. Lokalna pula ma własną opłatę transakcyjną i wpływ na cenę. Trasa przez mainnet może oferować głębszą płynność, ale może wymagać więcej pracy wykonawczej i generować koszty jej użycia. Solver decydujący między trasami musi zważyć lepszą cenę puli wobec tych kosztów.

Wyobraźmy sobie, że lokalna pula dostarczyłaby aktywo o wartości 9 900 dolarów po wszystkich opłatach dla zlecenia o wartości referencyjnej 10 000 dolarów. Trasa międzyłańcuchowa, która może zrealizować transakcję za 9 980 dolarów przed kosztami wykonania, ma do 80 dolarów marginesu, zanim lokalna wycena stanie się lepsza. Jeśli dotarcie do lepszej puli kosztuje 30 dolarów, trasa międzyłańcuchowa dostarcza 9 950 dolarów. Przy 100 dolarach dodatkowego kosztu lokalna trasa oferuje więcej. Liczby ilustrują porównanie i nie opisują żadnej rzeczywistej wyceny.

Wielkość zlecenia zmienia tę kalkulację. Większa transakcja może przesunąć cenę dalej w płytkiej puli, dając solverowi więcej powodów, by sięgnąć po głębszy rynek. Mała transakcja może wywrzeć niewielki lokalny wpływ na cenę i pozostawić zbyt mało oszczędności, by pokryć trasę międzyłańcuchową. Nawet dla tej samej pary tokenów użyteczna trasa może zmieniać się w ciągu dnia wraz ze zmianami płynności i kosztów sieciowych.

Solverzy muszą także wyceniać nieudane próby i czas, który spędzają na szukaniu tras. Nieudana operacja może pozostawić ruchy aktywów użytkownika wycofane, podczas gdy strony organizujące zlecenie nadal mogą ponosić wydatki związane z próbą wykonania. Wpływ tego rozwiązania na spread, który widzi trader, zależy od tego, jak działająca implementacja rozdziela te koszty i jak duża jest konkurencja między firmami oferującymi kwotowania.

Dla portfela integrującego to rozwiązanie ważną informacją jest to, co użytkownik może porównać. Kwotowanie, które podaje minimalną dostarczoną kwotę i sieć, do której ona dotrze, daje traderowi sposób oceny wyniku. Interfejs, który podkreśla jedno kliknięcie lub jeden podpis, pokazuje coś o wygodzie, podczas gdy cena i warunki dostawy pokazują, czy trasa obsługuje zlecenie.

Miejsce handlu rozważające to rozwiązanie musiałoby zdecydować, co pokazywać klientom na temat zależności kwotowania. Jedna trasa może zostać w całości zrealizowana tam, gdzie użytkownik trzyma środki. Inna może uruchomić płynność mainnetu i polegać na tym, że dowód będzie gotowy w ciągu jednego slotu. Nawet jeśli oba kwotowania pokazują ten sam token i tę samą kwotę, mogą mieć różne zasady wygaśnięcia i różne powody niepowodzenia. Interfejs musiałby komunikować minimalną kwotę, którą klient akceptuje, oraz to, co się dzieje, jeśli solver nie może jej dostarczyć.

Aplikacje muszą także opracować sposób zbierania wystarczającej ilości porównywalnych danych, aby zidentyfikować, dlaczego jedna trasa kosztuje więcej. Przydatny szereg obejmowałby tę samą parę i te same wielkości transakcji w tych samych sieciach, z kwotowaniami przechwyconymi blisko siebie w czasie. Pojedyncza transakcja nietypowo niepłynnej pary mogłaby sprawić, że zdolność dotarcia do innego rynku wydawałaby się cenniejsza, niż jest w przypadku codziennych zleceń. Przeciwny problem może pojawić się w przypadku głównej pary, która już handluje tanio na rollupie użytkownika. Cena wykonania, uwzględnione opłaty i warunki wygaśnięcia muszą być porównywane razem.

Safe czyni autorytet międzyłańcuchowy częścią problemu

Skarbiec może używać jednego konta do regularnych płatności, a innego do przechowywania aktywów w innej sieci. Jeśli zmieni osoby upoważnione do zatwierdzania wydatków, ktoś musi zadbać o to, by zmiana została odzwierciedlona tam, gdzie przechowywane są aktywa. Osobne aktualizacje stwarzają możliwości pozostania nieaktualnej listy podpisujących w stanie aktywnym na rzadziej używanym koncie.

Demonstracja Safe pokazała, jak aplikacja mogła wykorzystać zmianę własności na mainnecie w ramach skoordynowanej transakcji obejmującej rollup. Jej korzyść zależy od tego, jak skarbiec zdecydował się przypisać autorytet. Organizacja może chcieć, aby mainnet określał wspólny zestaw podpisujących, zachowując jednocześnie osobną politykę dla lokalnego konta wydatków obsługującego konkretny zespół.

Wspólna struktura autorytetu może zmniejszyć duplikację pracy. Sprawia też, że obsługa błędów staje się ważniejsza, ponieważ jedna zmiana może mieć konsekwencje w kilku miejscach. Skarbiec musiałby zrozumieć, jak jego konta odzyskują sprawność, jeśli aktualizacja jest błędna, kto może zatwierdzić korektę i jak zachowuje się połączony łańcuch, jeśli nie może uzyskać aktualnego wyniku.

Organizacja oceniająca to rozwiązanie zapytałaby zatem, którą operację chce koordynować. Odczyt listy podpisujących, aktualizacja własności i przenoszenie aktywów skarbca mają różne konsekwencje. Wartość wykonania jednej z nich w ramach wspólnej transakcji nie dowodzi, że organizacja powinna delegować każdą decyzję do tego samego konta.

Zainteresowanie instytucji wykracza poza scenę Devcon. Consensys ogłosił system interoperacyjności dla banków i stwierdził, że planuje wspierać standard EEZ. Dla banku zgodność współistniałaby z pytaniami o to, kto może korzystać z systemu, jakie mechanizmy kontroli dotyczą każdej operacji i jak zapisuje on wynik w istniejących systemach.

Przypadek Safe sugeruje inny zestaw testów produktowych. Zespół może chcieć, aby podpisujący w jednej sieci zatwierdzali operację, która dotyczy wyłącznie aktywów w innej sieci. Rodzi to pytanie, czy podpisujący usunięty lokalnie może nadal zatwierdzić wcześniej zgłoszoną operację między sieciami. Odpowiedź zależy od tego, jak aplikacja odczytuje stan konta i co uznaje za moment zatwierdzenia. To kwestie, które aplikacja musi określić, nawet gdy bazowy protokół jest w stanie przenieść wiadomość.

Co demonstracja Falcon mówi o wykonywaniu obliczeń gdzie indziej

Prezentacja sygnatury wykorzystała rollup do weryfikacji podpisu Falcon i dostarczyła ten wynik do akcji w mainnecie. Zespół poinformował o 91% redukcji zużycia gazu w porównaniu z weryfikacją w mainnecie. Przykład ma węższy zakres niż twierdzenie o koszcie każdej transakcji, która mogłaby wykorzystać ten projekt. Porównuje określoną operację w dwóch ścieżkach wykonania.

Szaną jest uruchomienie kosztownej obliczeniowo weryfikacji w środowisku, które się do tego nadaje, pozwalając innemu kontraktowi polegać na wyniku. Aplikacja, która wykonuje weryfikację tylko rzadko, może wyceniać oszczędności inaczej niż taka, która powtarza ją przy każdym zleceniu. Decyzja zależy również od tego, jak aplikacja waliduje wynik i jakie inne kroki musi wykonać, aby go użyć.

Weryfikacja postkwantowa jest jednym z zastosowań tego wzorca. Kontrakt może potrzebować innych informacji z połączonego środowiska, zanim będzie mógł kontynuować, na przykład czy konto ma prawo do wykonania operacji. Wspólnym problemem jest udostępnienie wyniku w tym samym oknie wykonania. Różne weryfikacje mogą mieć bardzo różne wymagania obliczeniowe i dowodowe.

Dla użytkownika obsługa jednego schematu podpisu w aplikacji nie determinuje bezpieczeństwa każdego portfela ani transakcji w łańcuchu. Demonstracja dotyczyła weryfikacji i autoryzacji konkretnego transferu. Zmiana zasad, według których portfele ogólnie podpisują transakcje, wiązałaby się z innymi decyzjami dotyczącymi oprogramowania, kompatybilności i tego, które konta przyjmą zmiany.

Podobne rozróżnienie dotyczy deweloperów oceniających demonstrację Falcon. Gaz zużyty przez kontrakt odczytujący wynik weryfikacji i koszt wytworzenia tego wyniku gdzie indziej należą do różnych środowisk wykonania. Pomiar pierwszego uchwytuje realne ograniczenie dla aplikacji, która w przeciwnym razie musiałaby wykonywać weryfikację w mainnecie. Usługa decydująca, czy może zaoferować tę funkcję, musi uwzględnić również to drugie. Musi też wiedzieć, czy weryfikacja może zakończyć się pod obciążeniem, gdy wiele żądań może konkurować o tę samą przepustowość.

Gnosis będzie musiała przeprowadzić istniejące aplikacje przez transformację

GnosisDAO zatwierdziło przejście z samodzielnej sieci do rollupu EEZ poprzez GIP 153 w sierpniu. Migracja ma znaczenie, ponieważ istniejący użytkownicy i aplikacje mają salda, adresy i zależności powiązane z działającym łańcuchem. Dla nich przyjęcie nowego układu wykonania i rozliczeń jest zmianą infrastruktury, której już używają.

Pytania, na które musi odpowiedzieć działająca aplikacja, różnią się od tych dotyczących sieci deweloperskiej. Jej użytkownicy muszą wiedzieć, jak przenoszone są salda, które portfele i dostawcy infrastruktury obsługują migrację oraz gdzie uzyskać wiarygodny zapis aktywności w trakcie transformacji. Platformy handlowe muszą uwzględnić możliwość, że integracje staną się dostępne w różnych momentach.

Rollup, który może uzyskać dostęp do rynków mainnetu, może być w stanie zaoferować ścieżki, zanim zbuduje własne głębokie pule dla każdej pary tokenów. Łańcuch z ugruntowaną płynnością podejmuje inną decyzję. Jego aplikacje mogą wybierać między lokalnym wykonaniem a wspólną ścieżką, a dostawcy płynności już obecni w łańcuchu mogą obserwować, jak te wybory wpływają na aktywność w ich pulach.

Migracja sprawdzi również różnicę między uruchomieniem sieci a uczynieniem funkcji domyślną dla użytkowników. Pierwszy blok może zademonstrować, że nowy łańcuch działa. Domyślna ścieżka użytkownika wymaga, aby portfele, aplikacje i inni dostawcy używali nowej ścieżki w zwykłej aktywności. Wcześniejsze doniesienia opisywały cel około przełomu roku dla wstępnego wdrożenia. Listopadowa aktualizacja Gnosis podaje wiosnę 2027 jako cel domyślnego działania.

Gnosis daje deweloperom miejsce do zadawania tych pytań wobec wdrożenia z istniejącymi aplikacjami. Migracja poddałaby wykonanie, obsługę portfeli i procedury operacyjne temu samemu harmonogramowi, umożliwiając śledzenie, jak zespół radzi sobie z opóźnieniami lub częściowymi integracjami. Jej listopadowa aktualizacja wskazuje wiosnę 2027 jako cel uczynienia tego projektu domyślnym. Operacje Devcon odbyły się na Rollup X.

Na co zwrócić uwagę

• Obsługiwane trasy. Portfele i aplikacje publikujące sieci, w których ta sama operacja jest dostępna.
• Wyceny wykonania. Porównywalna wartość netto na wyjściu i wskaźniki nieudanych zleceń dla transakcji lokalnych i międzysieciowych.
• Wydajność slotów. Powtarzane testy pokazujące dostępność dowodów i odzyskiwanie po reorganizacjach Ethereum.
• Uprawnienia skarbca. Publikowany zakres, wygaśnięcie i zasady odwoływania dla integracji Safe.
• Kamienie milowe Gnosis. Publiczne testy migracji i postęp w kierunku celu na wiosnę 2027 r.

FAQ