1. Wprowadzenie i motywacja

Tło

Platforma EQTY opiera się na architekturze podwójnej warstwy:

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

  • Publiczna warstwa kotwiczenia do znacznikowania i weryfikacji tych łańcuchów zdarzeń na niezmiennej blockchainie

Historycznie, ta publiczna warstwa była zapewniana przez LTO Network Layer 1, dedykowaną blockchainem Proof-of-Stake zoptymalizowanym do kotwiczenia.

Jednak kontekst operacyjny zmienił się znacznie.

Dlaczego warstwa LTO 1 musi zostać zdewaluowana

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

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

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

  • Na tych poziomach, jest to finansowo opłacalne dla złośliwego aktora, aby skompromitować konsensus, cenzurować transakcje kotwiczenia lub przepisywać historię.

  • Dla platformy takiej jak EQTY — która kotwiczy prawnie egzekwowalne zapisy aktywów — jest to nieakceptowalne.

2. Centralizacja weryfikatorów i niskie zachęty

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

  • Zakończenie usługi węzłów może prowadzić do małego zestawu węzłów posiadających nieproporcjonalną kontrolę nad konsensusem.

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

3. Tarcia adopcyjne

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

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

  • Percepcja „kotwiczenia do Layer 1 o wartości 5 milionów dolarów” osłabia zaufanie do rdzennej infrastruktury EQTY.

4. Kruchość infrastruktury

  • Jeśli nawet kilku kluczowych weryfikatorów wyjdzie offline, LTO staje się niestabilne lub całkowicie zatrzymuje się.

  • Dalsze utrzymanie (eksploratory, indeksatory, infrastruktura węzłów) zwiększa obciążenie przy malejącej wartości.

Dlaczego Base jest odpowiednią warstwą kotwiczenia

Base oferuje:

  • Pełna zgodność z EVM

  • Bezpieczeństwo ekonomiczne i techniczne dziedziczone z Ethereum

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

  • Prawie zerowe opłaty z szybkim rozrachunkiem

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

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

Motywacja strategiczna

  • Wartość EQTY nie znajduje się w konsensusie — jest w jego prywatnej warstwie, modelu aktywów i architekturze zgodności.

  • Utrzymanie warstwy 1 oferuje niewielką przewagę strategiczną przy wysokich kosztach.

  • Przeniesienie na Base pozwala EQTY skupić się całkowicie na adopcji produktu, integracji prawnej i tokenizacji aktywów, bez bycia przytłoczonym przez infrastrukturę Layer 1.

2. Nowy token $EQTY ERC-20

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

Kontrakt tokena zaczyna się od zerowej podaży. $EQTY jest mintowany na żądanie, gdy użytkownicy wymieniają swoje tokeny LTO w ograniczonym okresie migracji. Ten okres jest egzekwowany na łańcuchu: po zdefiniowanej wysokości bloku, funkcja mint zostaje trwale wyłączona. Jakiekolwiek tokeny LTO, które nie zostaną wymienione przed tym terminem, zostaną wyłączone z ekosystemu EQTY, a ostateczna podaż $EQTY będzie niższa niż oryginalna podaż LTO.

Kontrakt tokena jest celowo minimalny. Podąża za standardowym interfejsem ERC-20, bez specjalnej logiki transferu, funkcji airdrop lub 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 całkowitą podaż.

3. Kontrakt kotwiczenia na Base

Kotwiczenie będzie przeprowadzane za pomocą lekkiego kontraktu inteligentnego wdrożonego w sieci Base. Ten kontrakt emituje zdarzenia, które publicznie rejestrują hasz łańcuchów zdarzeń lub wiadomości, nie przechowując żadnego 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 Kotwica {

bytes32 klucz;

bytes32 wartość;

}

function anchor(Anchor[] calldata anchors) external;

zdarzenie Zakotwiczone(

bytes32 indeksowany klucz,

bytes32 wartość,

adres indeksowany nadawca,

uint64 znacznik czasu

);

Zachowanie

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

  • Aktualny block.timestamp jest dołączany do zdarzenia jako oddzielne pole dla wygody i audytowalności.

  • W kontrakcie nie jest przechowywany żaden stan. Wszystkie dane kotwiczenia są rejestrowane tylko poprzez logi.

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

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

  • Komponenty wewnętrzne, takie jak indeksator oBridge i platforma EQTY

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

Utrzymując kotwiczenie w stanie bezstanowym i emitując kompletną zdarzenia, ten projekt zapewnia, że kotwiczenie jest weryfikowalne, efektywne i niezależne od infrastruktury.

Mechanizm opłat

  • Klient musi wywołać approve() na kontrakcie ERC20, aby włączyć kotwiczenie

  • Każda kotwica wiąże się z wypaleniem $EQTY, egzekwowanym w funkcji anchor()

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

  • Kotwiczenie nie użyje approve(), lecz zamiast tego spali poprzez eqtyToken.burnFrom(msg.sender, fee * n)

4. Zarządzanie opłatami

Aby utrzymać kotwiczenie ekonomicznie zrównoważone i sprawiedliwe w czasie, opłata płacona w $EQTY za kotwicę musi być regulowana. Zamiast twardo kodować statyczną opłatę lub polegać na oracle'ach cenowych, EQTY wykorzysta model zarządzania on-chain do kontrolowania tego parametru w przejrzysty i zdecentralizowany sposób.

Dedykowany kontrakt konfiguracyjny przechowa aktualną 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łosowanie będzie odbywać się na podstawie sald $EQTY, używając standardowej logiki ERC20Votes.

Kontrakt kotwiczenia odczytuje aktualną 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 centralnej kontroli.

5. Nowa biblioteka warstwy prywatnej

Aby wspierać kotwiczenie na Base i natywne podpisywanie portfela, zostanie stworzona nowa samodzielna biblioteka TypeScript, która zajmie się logiką warstwy prywatnej — w tym łańcuchami zdarzeń, podpisywaniem zdarzeń, kotwiczeniem i strukturami wiadomości przekaźnika. Ta biblioteka zastępuje LTO-specyficzną @ltonetwork/lto-api.js dla wszystkich przypadków użycia EQTY.

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

Zakres i treść

Tylko odpowiednie komponenty prywatnej warstwy LTO będą zawarte:

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

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

  • Wsparcie kodu Zawiera klasy pomocnicze, takie jak Binary.

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

  • Brak API węzła LTO

  • Brak logiki transakcji

  • Brak narzędzi do generowania par kluczy

  • Brak specyficznego kodowania adresów LTO

Będzie wspierać kotwiczenie poprzez inteligentne kontrakty na Base i w pełni integrować się z ethers.js do podpisywania i przesyłania kotwic.

Model podpisywania zdarzeń

Metoda Event.signWith() zostanie zrobiona asynchronicznie, aby wspierać podpisywanie w przeglądarkach za pomocą 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. To sprawia, że jest zgodne z przepływami podpisywania Ethereum (personal_sign) i eliminuje potrzebę wydobywania kluczy publicznych, co nie jest możliwe w większości środowisk portfela.

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, sam hasz wiadomości jest używany jako klucz kotwicy, a wartość jest ustawiona na zero (0x0).

Kotwiczenie można przeprowadzić, wywołując kontrakt inteligentny bezpośrednio za pomocą ethers.Contract.anchor(Anchor[]). Unika to zależności od jakiejkolwiek usługi backendowej 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ą podpisywane asynchronicznie, używając interfejsu ISigner. Podpisy są nad haszem wiadomości, a żaden klucz publiczny nie jest dołączany — używany jest tylko wyprowadzony adres do weryfikacji.

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

  • klucz = messageHash

  • wartość = 0x0

To zapewnia, że wiadomości poza łańcuchem mogą być publicznie opatrzone znakiem czasu i weryfikowane bez ujawniania ich treści. Kotwiczenie może być wykonane przez nadawcę lub usługę przekaźnika.

Wdrożenie i użycie

Biblioteka zostanie opublikowana jako osobny pakiet NPM. Jest przeznaczona do użycia jako wspólny rdzeń przez:

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

  • Usługa przekaźnika (do obliczania haszów i parsowania wiadomości)

  • SDK Ownables (do konstruowania i przesyłania zdarzeń)

  • Dowolny frontend lub weryfikator zewnętrzny

6. Indeksowanie oBridge

Usługa oBridge zastąpi swoją obecną logikę indeksowania opartą na LTO nowym indeksatorem, który przetwarza zdarzenia zakotwiczonych emitowane przez kontrakt kotwiczenia 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, blockNumber, logIndex i nadawca

Te zapisy 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, co pozwala istniejącym komponentom EQTY na 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 zakotwiczone przed ich wydaniem.

  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ą ominąć 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 znakiem czasu i kontrolowane dostępem, usługa zostanie zaktualizowana, aby wspierać zarówno weryfikację kotwiczenia na łańcuchu, jak i nowoczesne, natywne uwierzytelnianie portfela przy użyciu Sign-In with Ethereum (SIWE).

Uwierzytelnianie wiadomości za pomocą 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 na uwierzytelnienie poprzez podpisanie standardowej wiadomości tekstowej swoim portfelem Ethereum, produkując odzyskiwalny podpis, który wiąże ich z sesją.

Przepływ logowania:

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

  2. Serwer zwraca standardową wiadomość SIWE, w tym:

  • 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ść używając 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 subsequent requests do pobrania wiadomości (GET /messages?to=...) muszą zawierać token dostępu w nagłówku autoryzacji.

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

Ten model jest w pełni zgodny z MetaMask, WalletConnect i innymi portfelami EIP-1193, i podąża za szeroko przyjętymi wzorcami bezpieczeństwa. Nie jest wymagana żadna niestandardowa logika ani infrastruktura poza istniejącymi bibliotekami SIWE.

Kotwiczenie i weryfikacja wiadomości

Oprócz uwierzytelnienia, usługa przekaźnika będzie weryfikować, że każda wiadomość została zakotwiczona na łańcuchu przed dostarczeniem. Kotwiczenie zapewnia niezmienność, znacznik czasu i zapobiega atakom spamowym lub powtórkowym.

Przekaźnik utrzymuje własny lekki indeksator dla kontraktu kotwiczenia na Base. Nasłuchuje zdarzeń zakotwiczonych i rejestruje:

  • klucz = messageHash

  • wartość = 0x0

  • nadawca

  • blockNumber, txHash, znacznik czasu

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

  • Istnieje zdarzenie zakotwiczone z kluczem = messageHash

  • Wartość to dokładnie 0x0 (tj. nie jest kotwiczeniem łańcucha zdarzeń)

  • Nadawca pasuje do sygnatariusza wiadomości (tj. z adresu)

Dopiero po pomyślnym kotwiczeniu wiadomość zostaje przekazana odbiorcy. Zapewnia to, że wszystkie wiadomości są publicznie weryfikowalne, opatrzone znakiem czasu na Base i zakotwiczone przez odpowiednią tożsamość.

Przekaźnik wykonuje tę weryfikację, używając swojego 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 adresie używając standardowych adresów Ethereum.

Autoryzacja oparta na adresie

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

Zaktualizowana logika kontraktu wykorzystuje info.sender — adres, który podpisał i przesłał zdarzenie — jako autorytatywną tożsamość.

To wpływa na wszystkie punkty wejścia, w których wymagana jest autoryzacja:

  • try_transfer: nadawca musi odpowiadać aktualnemu 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...).

Dopasowanie CAIP-2 i sieci

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

  • event.network pasuje do oczekiwanej sieci

  • Pole właściciela w zdarzeniu pasuje do sygnatariusza (info.sender) w danej przestrzeni nazw CAIP

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

Wpływ

Ta zmiana sprawia, że kontrakt Ownable:

  • W pełni zgodny z natywnym podpisywaniem i tożsamością 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 polegają na podpisywaniu i kotwiczeniu specyficznym dla LTO, staną się nieweryfikowalne w nowym modelu i muszą zostać ponownie wydane (patrz sekcja 11).

9. Aktualizacja SDK Ownables

SDK Ownables musi zostać zaktualizowane, aby odzwierciedlić przejście od podpisywania klucza publicznego opartego na LTO do autoryzacji opartej na adresie w stylu Ethereum i kotwiczenia na Base.

Kluczowe aktualizacje

  1. Podpisywanie zdarzeń

  • Zaktualizuj tworzenie zdarzeń, aby używało nowej biblioteki warstwy prywatnej (@eqty-core/events)

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

  • Zapewnij, aby signWith() już nie polegało na kluczu publicznym; używany jest tylko odzyskiwalny adres

  1. Kotwiczenie

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

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

  • Zapewnij, aby kotwiczenie wiadomości używało (klucz = messageHash, wartość = 0x0)

  1. Weryfikacja

  • Zaktualizuj logikę weryfikacji, aby używała API zgodnego z oBridge /hash/verify lub bezpośredniego zapytania do logów

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

  1. Użycie adresu

  • Zastąp wszelką logikę, która porównuje lub generuje adresy LTO

  • Używaj 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 ani usługami węzłów LTO. Jest zgodne z nową biblioteką warstwy prywatnej i kotwiczeniem na Base oraz będzie współpracować z zaktualizowanymi kontraktami Ownable i usługą przekaźnika.

10. Aktualizacja portfela uniwersalnego

Uniwersalny portfel musi zostać zaktualizowany, aby odzwierciedlić migrację do Base i nową architekturę EQTY. Nie będzie już współdziałać z węzłami LTO.

Aktualizacje rdzeniowe

  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. Wsparcie tokenów

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

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

  1. Podpisywanie zdarzeń i wiadomości

  • Zintegruj nową bibliotekę warstwy prywatnej, 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 nie są już wymagane

  1. Kotwiczenie

  • Przesyłaj mapy kotwic bezpośrednio do kontraktu kotwiczenia Base przy użyciu ethers.js

  • Obsłuż przesyłanie na łańcuchu, potwierdzenie i opcjonalną informację zwrotną na UI dla kosztów kotwic w $EQTY

  1. Integracja przekaźnika

  • Uwierzytelnij za pomocą SIWE (Logowanie przy użyciu Ethereum)

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

  • Użyj uwierzytelnionych żądań, aby pobrać zaszyfrowane wiadomości z usługi przekaźnika

Usunięte funkcje

  • Interfejs użytkownika leasingu LTO

  • Wybór węzła 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 rdzenne komponenty protokołu muszą migrować. Dane dziedziczone z infrastruktury 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 wyodrębnienia z podpisów opartych na Ethereum.

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

  • Ownables powiązane z tożsamościami opartymi na LTO lub zakotwiczonymi łańcuchami muszą zostać zastąpione.

  • Wiadomości, które nie są zakotwiczone na Base, zostaną odrzucone 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. Minting jest możliwy tylko do określonej wysokości bloku na Base. Po tym bloku most zostanie zamknięty, a funkcja mint trwale wyłączona. Nie wymienione tokeny LTO stają się bezwartościowe.

  2. Ponowne wydanie aktywów Ownables.Emitenci Ownable muszą wydać nowe ownables powiązane z siecią BASE. Instrukcje będą następować, jak wymienić dziedziczne Ownables na nowe Ownables

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

Brak migawki

Nie będzie migawki, automatycznej migracji ani warstwy wstecznej kompatybilności. Każdy komponent (zdarzenia, wiadomości, salda tokenów) musi zostać przywrócony na Base przez odpowiednie interfejsy. Nowy protokół jest czysty w designie i nie zachowuje więzi z LTO L1.

#ETH