1. Wprowadzenie i motywacja

Tło

Platforma EQTY opiera się na architekturze o podwójnej warstwie:

  • Prywatna warstwa do zarządzania weryfikowalnymi łańcuchami zdarzeń (np. Ownables, wiadomości)

  • Publiczna warstwa kotwiczenia, aby opatrzyć znacznikami czasowymi i weryfikować te łańcuchy zdarzeń na niezmiennym blockchainie

Historycznie, ta publiczna warstwa była dostarczana przez LTO Network Layer 1, dedykowany blockchain Proof-of-Stake zoptymalizowany do kotwiczenia.

Jednak kontekst operacyjny znacznie się zmienił.

Dlaczego warstwa LTO 1 musi zostać zdegradowana

1. Bezpieczeństwo ekonomiczne załamało się

  • LTO obecnie ma kapitalizację rynkową poniżej 5 milionów dolarów, zaledwie ~20% tokenów stakowanych.

  • Oznacza to, że efektywny budżet bezpieczeństwa (tj. całkowita wartość zabezpieczająca konsensus) wynosi < 1 milion dolarów.

  • Na tych poziomach, finansowo opłacalne jest, aby złośliwy aktor mógł skompromitować konsensus, cenzurować transakcje kotwiczenia lub przepisać historię.

  • Dla platformy takiej jak EQTY — która kotwiczy prawnie egzekwowalne rekordy aktywów — jest to nie do przyjęcia.

2. Centralizacja walidatorów i niskie zachęty

  • Węzły społecznościowe nie są już ekonomicznie opłacalne.

  • Węzły kończące usługi mogą prowadzić do małej grupy węzłów posiadających nieproporcjonalną kontrolę nad konsensusem.

  • To podważa gwarancje decentralizacji, które kotwiczenie ma zapewnić.

3. Tarcia związane z przyjęciem

  • Coraz trudniej uzasadnić LTO jako zabezpieczoną warstwę kotwiczenia w rozmowach sprzedażowych lub audytowych.

  • Klienci i partnerzy oczekują, że EQTY będzie kotwiczyć na powszechnie przyjętych i wiarygodnych publicznych sieciach (np. Ethereum, Base).

  • Postrzeganie „kotwiczenia do warstwy 1 o wartości 5 milionów dolarów” osłabia zaufanie do rdzeniowej infrastruktury EQTY.

4. Kruchość infrastruktury

  • Jeśli nawet kilka kluczowych walidatorów zgaśnie, LTO stanie się niestabilne lub całkowicie zatrzyma się.

  • Kontynuowana konserwacja (eksploratory, indeksatory, infrastruktura węzłów) zwiększa koszty przy malejącej wartości.

Dlaczego Base jest odpowiednią warstwą kotwiczącą

Base oferuje:

  • Pełna zgodność z EVM

  • Ekonomiczne i techniczne bezpieczeństwo dziedziczone z Ethereum

  • Szerokie wsparcie narzędzi (MetaMask, WalletConnect, The Graph itp.)

  • Prawie zerowe opłaty z szybkim zakończeniem

  • Bliskie powiązanie z warstwą aktywów i płynności EQTY, która również istnieje na Base

Kotwiczenie do Base usuwa ciężar utrzymania niestandardowej warstwy 1, jednocześnie zwiększając audytowalność, kompozycyjność i zaufanie.

Motywacja strategiczna

  • Wartość EQTY nie leży w konsensusie — leży w jego prywatnej warstwie, modelu aktywów i architekturze zgodności.

  • Utrzymywanie warstwy 1 niewiele oferuje strategicznych korzyści przy wysokich kosztach.

  • Przejście do Base pozwala EQTY skupić się całkowicie na przyjęciu produktu, integracji prawnej i tokenizacji aktywów, bez bycia obciążanym przez infrastrukturę Layer 1.

2. Nowy token $EQTY ERC-20

Platforma EQTY wprowadzi nowy token ERC-20, $EQTY, wdrożony w sieci Base. Ten token zastępuje token LTO i służy jako natywna waluta do operacji protokołu, w tym kotwiczenia i zarządzania.

Kontrakt tokena zaczyna się od zerowej podaży. $EQTY jest mintowane na żądanie, gdy użytkownicy wymieniają swoje tokeny LTO w czasie ograniczonej migracji. Ten czas jest wymuszany na łańcuchu: po zdefiniowanej wysokości bloku funkcja mint staje się na stałe wyłączona. Wszelkie tokeny LTO, które nie zostały wymienione przed tym terminem, są wykluczone z ekosystemu EQTY, a ostateczna podaż $EQTY będzie niższa niż pierwotna podaż LTO.

Kontrakt tokena jest celowo minimalny. Podąża za standardowym interfejsem ERC-20, bez specjalnej logiki transferu, funkcji airdrop czy harmonogramów vestingowych.

Token $EQTY będzie używany do opłacania opłat za kotwiczenie, uczestniczenia w zarządzaniu protokołem i potencjalnie wspierania dodatkowych ról użyteczności, gdy platforma się rozwija. Użyteczność wymaga spalania tokenów, co zmniejsza ogólną podaż.

3. Kontrakt kotwiczenia na Base

Kotwiczenie będzie realizowane za pomocą lekkiego inteligentnego kontraktu wdrożonego w sieci Base. Ten kontrakt emituje zdarzenia, które publicznie rejestrują hasz łańcuchów zdarzeń lub wiadomości, bez przechowywania jakiegokolwiek stanu na łańcuchu.

Każda kotwica mapuje klucz na wartość, gdzie:

  • Dla łańcuchów zdarzeń: klucz = stateHash, wartość = eventHash

  • Dla wiadomości: klucz = messageHash, wartość = 0x0

Interfejs

struktura Anchor {

bytes32 klucz;

wartość bytes32;

}

funkcja anchor(Anchor[] calldata anchors) external;

zdarzenie Anchored(

bytes32 indeksowany klucz,

wartość bytes32,

adres indeksowany nadawca,

uint64 znacznik czasu

);

Zachowanie

  • Kontrakt emituje jedno zdarzenie Anchored na parę (klucz, wartość).

  • Bieżący block.timestamp jest dołączany do zdarzenia jako osobne pole dla wygody i audytowalności.

  • Żaden stan nie jest przechowywany w kontrakcie. Wszystkie dane kotwiczenia są rejestrowane tylko przez logi.

  • Kontrakt jest bezzezwoleniowy — każdy może kotwiczyć.

Te zdarzenia są zaprojektowane do indeksowania i są dostępne przez:

  • Wewnętrzne komponenty, takie jak indeksator oBridge i platforma EQTY

  • Usługi zewnętrzne, w tym The Graph, Infura lub niestandardowe weryfikatory

Utrzymując kotwiczenie bezstanowe i emitując pełne zdarzenia, ten projekt zapewnia, że kotwiczenie jest weryfikowalne, wydajne i niezależne od infrastruktury.

Mechanizm opłat

  • Klient musi wywołać approve() na kontrakcie ERC20, aby umożliwić kotwiczenie

  • Każda kotwica powoduje spalenie $EQTY, wymuszane w funkcji anchor()

  • Kwota opłaty jest odczytywana z osobnego kontraktu konfiguracyjnego kontrolowanego przez zarząd

  • Kotwiczenie nie będzie używać approve(), lecz zamiast tego spali przez eqtyToken.burnFrom(msg.sender, fee * n)

4. Zarządzanie opłatami

Aby utrzymać kotwiczenie w ekonomicznie zrównoważony i sprawiedliwy sposób w czasie, opłata płacona w $EQTY za każdą kotwicę musi być regulowana. Zamiast twardego kodowania stałej opłaty lub polegania na oracle cenowych, EQTY będzie korzystać z modelu zarządzania na łańcuchu, aby kontrolować ten parametr w przejrzysty i zdecentralizowany sposób.

Dedykowany kontrakt konfiguracyjny będzie przechowywał bieżącą opłatę za kotwiczenie. Ta wartość może być aktualizowana tylko przez kontrakt zarządzający — konkretnie, instancję Gubernatora OpenZeppelin powiązaną z tokenem $EQTY. Głosy będą oddawane na podstawie sald $EQTY, korzystając z logiki standardowej ERC20Votes.

Kontrakt kotwiczenia odczytuje bieżącą opłatę z kontraktu konfiguracyjnego za każdym razem, gdy wywoływana jest funkcja anchor(). Następnie spala odpowiednią ilość $EQTY bezpośrednio z salda nadawcy. To podejście unika potrzeby transakcji approve() i zapewnia, że kontrakt kotwiczenia pozostaje lekki i bezstanowy poza egzekwowaniem opłat.

Model zarządzania umożliwia społeczności dostosowywanie opłat w czasie w odpowiedzi na warunki rynkowe, wahania cen tokenów lub zmiany w popycie na kotwiczenie — bez polegania na zewnętrznych źródłach danych lub scentralizowanej kontroli.

5. Nowa biblioteka prywatnej warstwy

Aby wspierać kotwiczenie na Base i podpisywanie natywne w portfelach, zostanie stworzona nowa samodzielna biblioteka TypeScript do obsługi logiki prywatnej warstwy — w tym łańcuchów zdarzeń, podpisywania zdarzeń, kotwiczenia i struktur wiadomości przekaźnika. Ta biblioteka zastępuje specyficzną dla LTO bibliotekę @ltonetwork/lto-api.js dla wszystkich przypadków użycia EQTY.

Nowa biblioteka jest zaprojektowana do użytku zarówno w środowiskach przeglądarkowych (np. MetaMask, WalletConnect), jak i narzędziach po stronie serwera.

Zakres i zawartość

Tylko istotne komponenty prywatnej warstwy LTO będą uwzględnione:

  • zdarzenia/ Zawiera zdarzenie, łańcuch zdarzeń, konflikt scalania i powiązaną logikę serializacji.

  • wiadomość/ Zawiera wiadomość i przekaźnik, używane do zaszyfrowanej komunikacji poza łańcuchem.

  • Kod wspierający Zawiera klasy pomocnicze, takie jak Binary.

Biblioteka nie będzie miała zależności od LTO Network:

  • Brak API węzła LTO

  • Brak logiki transakcji

  • Brak narzędzi do generowania par kluczy

  • Brak kodowania adresów specyficznych dla LTO

Będzie wspierać kotwiczenie za pomocą inteligentnych kontraktów na Base oraz integrować się z ethers.js do podpisywania i składania kotwic.

Model podpisywania zdarzeń

Metoda Event.signWith() zostanie uczyniona asynchroniczną, aby wspierać podpisywanie w przeglądarkach za pośrednictwem MetaMask, WalletConnect lub dowolnego zewnętrznego sygnatariusza, oprócz podpisywania bezpośrednio z ethers. Używa abstrakcyjnego interfejsu ISigner:

interfejs ISigner {

sign(data: Uint8Array): Promise<Uint8Array>;

}

Podpisane zdarzenie nie wymaga już klucza publicznego; zawiera jedynie podpis i wyprowadzony adres. Czyni to je zgodnym z przepływami podpisów Ethereum (personal_sign) i usuwa potrzebę wydobywania kluczy publicznych, co w większości środowisk portfelowych jest niemożliwe.

Integracja kotwiczenia

Biblioteka zawiera metodę do generowania map kotwic:

const anchors = chain.from(lastKnownEvent.hash).getAnchorMap();

Każda kotwica mapuje stateHash (klucz) na lastEventHash (wartość), gotowa do przesłania do inteligentnego kontraktu Base. Dla wiadomości przekaźnika hasz wiadomości jest używany jako klucz kotwicy, a wartość ustawiana jest na zero (0x0).

Kotwiczenie można wykonać, wywołując inteligentny kontrakt bezpośrednio przez ethers.Contract.anchor(Anchor[]). Unika to zależności od jakiejkolwiek usługi zaplecza lub własnej infrastruktury.

Podpisywanie wiadomości

Biblioteka zawiera również klasy Message i Relay do komunikacji poza łańcuchem. Podobnie jak zdarzenia, wiadomości są asynchronicznie podpisywane za pomocą interfejsu ISigner. Podpisy są nad haszem wiadomości, a żaden klucz publiczny nie jest dołączany — tylko wyprowadzony adres jest używany do weryfikacji.

Po podpisaniu, hasz wiadomości jest kotwiczony na łańcuchu za pośrednictwem tego samego kontraktu Anchor. Format to:

  • klucz = messageHash

  • wartość = 0x0

Zapewnia to, że wiadomości poza łańcuchem mogą być publicznie opatrzone znacznikami czasowymi i weryfikowane bez ujawniania ich treści. Kotwiczenie może być przeprowadzane przez nadawcę lub usługę przekaźnika.

Wdrożenie i użycie

Biblioteka zostanie opublikowana jako osobny pakiet NPM. Jest przeznaczona do bycia wspólnym rdzeniem używanym przez:

  • Portfel EQTY (do podpisywania zdarzeń i wiadomości)

  • Usługa przekaźnika (do obliczania haszy i analizy wiadomości)

  • SDK Ownables (do budowy i składania zdarzeń)

  • Jakikolwiek zewnętrzny frontend lub weryfikator

6. Indeksowanie oBridge

Usługa oBridge zastąpi swoją obecną logikę indeksowania opartą na LTO nowym indeksatorem, który przetwarza zdarzenia Anchored emitowane przez kontrakt kotwiczenia na Base.

Ten indeksator nasłuchuje logów kotwiczenia na Base i utrzymuje lokalną bazę danych najnowszej kotwicy dla każdego klucza, która może reprezentować stan łańcucha zdarzeń lub hasz wiadomości przekaźnika. Każdy wpis zawiera:

  • klucz: zakotwiczony stan lub hasz wiadomości

  • wartość: odpowiadający hasz zdarzenia lub 0x0

  • txHash, numer bloku, logIndex i nadawca

Te rekordy są udostępniane za pośrednictwem publicznego API HTTP. Struktura i zachowanie tego API pozostaną zgodne z istniejącym indeksatorem kotwiczenia LTO, w tym punktem końcowym GET /hash/verify, umożliwiając istniejącym komponentom EQTY przejście z minimalnymi zmianami.

Indeksator oBridge pełni dwie role:

  1. Jako wewnętrzna zależność dla usługi przekaźnika, która musi weryfikować, że wiadomości zostały kotwiczone przed ich uwolnieniem.

  2. Jako publiczna usługa weryfikacji dla zewnętrznych klientów i portfeli, które chcą sprawdzić status kotwiczenia bez bezpośredniego zapytania do Base.

Wszystkie dane pozostają weryfikowalne na łańcuchu, a klienci mogą pominąć oBridge, jeśli chcą, używając eth_getLogs lub własnego indeksatora.

7. Usługa przekaźnika

Usługa przekaźnika obsługuje bezpieczne dostarczanie zaszyfrowanych wiadomości między stronami. Aby zapewnić, że wiadomości są autentyczne, opatrzone znacznikami czasowymi i kontrolowane dostępem, usługa zostanie zaktualizowana, aby wspierać zarówno walidację kotwic na łańcuchu, jak i nowoczesną autoryzację natywną w portfelach z użyciem Sign-In z Ethereum (SIWE).

Autoryzacja wiadomości z SIWE

Zamiast polegać na podpisach wiadomości HTTP lub niestandardowych wyzwaniach, przekaźnik wdroży standard SIWE (EIP-4361). To podejście pozwala użytkownikom uwierzytelnić się, podpisując standardową wiadomość tekstową za pomocą swojego portfela Ethereum, co generuje podpis możliwy do odzyskania, łączący ich z sesją.

Przepływ logowania:

  1. Klient żąda wiadomości SIWE z zaplecza przekaźnika: GET /auth/siwe-message?address=0x...

  2. Serwer zwraca standardową wiadomość SIWE zawierającą:

  • Domena (np. relay.eqty.network)

  • Nonce

  • Znacznik czasu wygaśnięcia

  • Opcjonalne pole zasobów ograniczone do /messages?to=...

  • Oświadczenie: np. „Zaloguj się, aby uzyskać dostęp do swoich wiadomości EQTY.”

  1. Klient podpisuje wiadomość za pomocą personal_sign

  2. Klient przesyła podpisaną wiadomość i podpis do POST /auth/verify

  3. Serwer weryfikuje podpis i wydaje:

  • Token dostępu JWT (krótkoterminowy, np. 15 minut)

  • Token odświeżający (długoterminowy, np. 24 godziny)

Wszystkie kolejne żądania pobrania wiadomości (GET /messages?to=...) muszą zawierać token dostępu w nagłówku Authorization.

Gdy token wygaśnie, klient może użyć tokena odświeżającego do uzyskania nowego tokena dostępu bez ponownego podpisywania.

Ten model jest w pełni zgodny z MetaMask, WalletConnect i innymi portfelami EIP-1193, i przestrzega powszechnie przyjętych wzorców bezpieczeństwa. Nie jest wymagana żadna niestandardowa logika ani infrastruktura poza istniejącymi bibliotekami SIWE.

Kotwiczenie i weryfikacja wiadomości

Oprócz autoryzacji, usługa przekaźnika zweryfikuje, że każda wiadomość została kotwiczona na łańcuchu przed jej dostarczeniem. Kotwiczenie zapewnia niezmienność, opatrzenie znacznikami czasowymi i zapobiega atakom spamowym lub powtórzeniowym.

Usługa przekaźnika utrzymuje własny lekki indeksator dla kontraktu kotwiczenia na Base. Nasłuchuje zdarzeń Anchored i rejestruje:

  • klucz = messageHash

  • wartość = 0x0

  • nadawca

  • numer bloku, txHash, znacznik czasu

Aby zweryfikować wiadomość przed dostarczeniem, przekaźnik sprawdza, że:

  • Zdarzenie Anchored istnieje z kluczem = messageHash

  • Wartość wynosi dokładnie 0x0 (tj. nie jest kotwicą łańcucha zdarzeń)

  • Nadawca odpowiada sygnatariuszowi wiadomości (tj. adresowi z)

Tylko po pomyślnym kotwiczeniu wiadomość zostaje uwolniona do odbiorcy. Zapewnia to, że wszystkie wiadomości są publicznie weryfikowalne, opatrzone znacznikami czasowymi na Base, i kotwiczone przez właściwą tożsamość.

Usługa przekaźnika dokonuje tej weryfikacji za pomocą własnego wewnętrznego indeksatora i nie polega na oBridge.

8. Zmiany w kontrakcie Ownable (CosmWasm)

Wraz z migracją z LTO Layer 1 i deprecjacją podpisywania zdarzeń opartego na kluczach publicznych, kontrakty Ownable muszą zostać zaktualizowane, aby wspierać autoryzację opartą na adresach z użyciem standardowych adresów Ethereum.

Autoryzacja oparta na adresie

Wcześniej weryfikacja własności opierała się na odzyskiwaniu i porównywaniu kluczy publicznych wydobytych z podpisanych zdarzeń. Ponieważ portfele Ethereum nie ujawniają kluczy publicznych, a podpisy wykorzystują teraz personal_sign (możliwe do odzyskania do adresu), model weryfikacji musi przejść do bezpośredniego porównywania adresów.

Zaktualizowana logika kontraktu używa info.sender — adresu, który podpisał i przesłał zdarzenie — jako autorytatywnej tożsamości.

To wpływa na wszystkie punkty wejścia, gdzie wymagana jest autoryzacja:

  • try_transfer: nadawca musi odpowiadać bieżącemu adresowi właściciela

  • try_release: nadawca musi odpowiadać wcześniejszemu zablokowanemu adresowi właściciela

  • try_register_lock: weryfikuje, że pole właściciela zdarzenia odpowiada sygnatariuszowi

Zamiast konwertować klucze publiczne na adresy LTO, kontrakt po prostu przechowuje i porównuje wartości Addr (np. 0xabc123...).

CAIP-2 i dopasowywanie sieci

Kontrakt nadal weryfikuje pochodzenie zdarzeń międzyłańcuchowych za pomocą identyfikatora sieci CAIP-2. Dla wiadomości opartych na Ethereum przestrzeń nazw to eip155:<chainId>. Kontrakt weryfikuje, że:

  • Zdarzenie.network odpowiada oczekiwanej sieci

  • Pole właściciela w zdarzeniu odpowiada sygnatariuszowi (info.sender) w danej przestrzeni nazw CAIP

Funkcje konwersji address_lto() i address_eip155() mogą być usunięte, ponieważ nie jest już potrzebne tłumaczenie na lub z adresów LTO.

Wpływ

Ta zmiana czyni kontrakt Ownable:

  • W pełni zgodny z podpisywaniem i tożsamością natywnymi dla Ethereum

  • Niezależny od infrastruktury kluczy LTO

  • Zgodny z każdą siecią, która wspiera odzyskiwanie oparte na adresach (np. EVM)

Istniejące Ownables, które opierają się na podpisywaniu i kotwiczeniu specyficznym dla LTO, staną się nieweryfikowalne pod nowym modelem i muszą zostać ponownie wydane (zobacz sekcję 11).

9. Aktualizacja SDK Ownables

SDK Ownables musi zostać zaktualizowane, aby odzwierciedlić przejście z podpisywania kluczy publicznych opartych na LTO na autoryzację opartą na adresach w stylu Ethereum i kotwiczenie na Base.

Kluczowe aktualizacje

  1. Podpisywanie zdarzeń

  • Zaktualizuj tworzenie zdarzeń, aby korzystać z nowej biblioteki prywatnej warstwy (@eqty-core/events)

  • Użyj implementacji ISigner zgodnych z MetaMask, WalletConnect lub signerami opartymi na ethers

  • Upewnij się, że signWith() nie polega już na kluczu publicznym; używany jest tylko adres możliwy do odzyskania

  1. Kotwiczenie

  • Zastąp logikę kotwiczenia węzłów LTO logiką przesyłania inteligentnych kontraktów na Base

  • Użyj getAnchorMap(), aby zebrać pary (klucz, wartość) i przesłać je za pomocą ethers.Contract.anchor()

  • Upewnij się, że kotwiczenie wiadomości używa (klucz = messageHash, wartość = 0x0)

  1. Weryfikacja

  • Zaktualizuj logikę weryfikacji, aby korzystać z zgodnego z oBridge API /hash/verify lub bezpośredniego zapytania log.

  • Potwierdź, że wartość kotwicy odpowiada oczekiwanemu haszowi zdarzenia i że nadawca odpowiada adresowi Ethereum sygnatariusza

  1. Użycie adresu

  • Wymień wszelką logikę, która porównuje lub generuje adresy LTO

  • Użyj zwykłych adresów Ethereum (0x...) w całym przepływie zdarzeń i wiadomości

Zgodność

Zaktualizowane SDK pozostaje strukturalnie podobne, ale nie jest już powiązane z biblioteką @ltonetwork/lto-api.js lub usługami węzłów LTO. Jest zgodne z nową biblioteką prywatnej warstwy i kotwiczeniem Base, i będzie współdziałać z zaktualizowanymi kontraktami Ownable oraz usługą przekaźnika.

10. Aktualizacja Uniwersalnego Portfela

Uniwersalny portfel musi zostać zaktualizowany, aby odzwierciedlić migrację do Base i nową architekturę EQTY. Nie ma już interakcji z węzłami LTO.

Aktualizacje rdzenia

  1. Połączenie portfela

  • Zastąp obsługę par kluczy LTO biblioteką zgodną z Ethereum (ethers.js)

  • Użyj interfejsów dostawcy EIP-1193, aby umożliwić podpisywanie i odzyskiwanie adresów

  1. Wspieranie tokenów

  • Dodaj wsparcie dla wyświetlania i zarządzania saldami nowego tokena $EQTY ERC-20 na Base

  • Uwzględnij metadane tokena, historię i śledzenie salda za pomocą publicznych punktów końcowych RPC

  1. Podpisywanie zdarzeń i wiadomości

  • Zintegruj nową bibliotekę prywatnej warstwy, aby umożliwić użytkownikom tworzenie i podpisywanie łańcuchów zdarzeń i wiadomości

  • Użyj personal_sign za pośrednictwem połączonego portfela; klucze publiczne są już niezbędne

  1. Kotwiczenie

  • Przesyłaj mapy kotwic bezpośrednio do kontraktu kotwiczenia Base za pomocą ethers.js

  • Obsługuj przesyłanie na łańcuchu, potwierdzenie i opcjonalną informację zwrotną interfejsu użytkownika na temat kosztu kotwiczenia w $EQTY

  1. Integracja przekaźnika

  • Autoryzuj za pomocą SIWE (Zaloguj się przy użyciu Ethereum)

  • Przechowuj i odświeżaj tokeny dostępu w razie potrzeby

  • Użyj uwierzytelnionych żądań do pobierania zaszyfrowanych wiadomości z usługi przekaźnika

Funkcje usunięte

  • Interfejs użytkownika leasingu LTO

  • Wybór węzłów i widok łańcucha

  • Zarządzanie tożsamością na łańcuchu powiązane z LTO

11. Plan migracji

Wraz z deprecjacją LTO Layer 1 i wprowadzeniem nowego systemu kotwiczenia na Base, wszystkie podstawowe komponenty protokołu muszą zostać przeniesione. Dane z przeszłości powiązane z infrastrukturą LTO — w tym kotwice, łańcuchy zdarzeń i wiadomości — nie będą już ważne.

Co staje się nieważne

  • Łańcuchy zdarzeń podpisane przy użyciu par kluczy LTO nie mogą być weryfikowane, ponieważ klucz publiczny nie jest już możliwy do wydobycia z podpisów opartych na Ethereum.

  • Kotwice zarejestrowane w LTO L1 nie mogą być zaufane ani zapytane w przyszłości.

  • Własności powiązane z tożsamościami opartymi na LTO lub kotwiczonymi łańcuchami muszą być wymienione.

  • Wiadomości, które nie są kotwiczone na Base, będą odrzucane przez usługę przekaźnika.

Wymagane działania

  1. Migracja tokenówUżytkownicy muszą ręcznie wymienić swoje tokeny LTO na $EQTY za pomocą mostu. Mintowanie jest możliwe tylko do określonej wysokości bloku na Base. Po tym bloku most zostanie zamknięty, a funkcja mint na stałe wyłączona. Niewymienione tokeny LTO stają się bezwartościowe.

  2. Reissue Ownables Asset.Emitenci Ownable muszą wyemitować nowe ownables powiązane z siecią BASE. Instrukcje dotyczące wymiany starych Ownables na nowe Ownables będą następujące

  3. Przejście portfela Użytkownicy będą musieli zaktualizować Uniwersalny Portfel.

Brak migawki

Nie będzie migawki, automatycznej migracji ani warstwy zgodności wstecznej. Każdy komponent (zdarzenia, wiadomości, salda tokenów) musi być na nowo ustanowiony na Base za pośrednictwem odpowiednich interfejsów. Nowy protokół jest czysty z założenia i nie zachowuje powiązań z LTO L1.

#ETH