1. Introducere și Motivație
Context
Platforma EQTY se bazează pe o arhitectură cu două straturi:
Un strat privat pentru gestionarea lanțurilor de evenimente verificabile (de exemplu, Ownables, mesaje)
Un strat public de ancorare pentru a marca și verifica aceste lanțuri de evenimente pe o blockchain imuabilă
Istoric, acest strat public a fost oferit de LTO Network Layer 1, o blockchain dedicată bazată pe dovada de miza optimizată pentru ancorare.
Cu toate acestea, contextul operațional s-a schimbat semnificativ.
De ce Layer 1 LTO trebuie să fie depreciat
1. Securitatea economică a colapsat
LTO are în prezent o capitalizare de piață sub 5 milioane de dolari, cu doar ~20% din tokenuri staked.
Aceasta înseamnă că bugetul efectiv de securitate (adică valoarea totală care asigură consensul) este < 1 milion de dolari.
La aceste niveluri, este viabil din punct de vedere financiar pentru un actor rău intenționat să compromită consensul, să cenzureze tranzacțiile de ancorare sau să rescrie istoria.
Pentru o platformă precum EQTY — care ancorează înregistrări de active ce pot fi aplicate legal — acest lucru este inacceptabil.
2. Centralizarea validatorilor și stimulentele scăzute
Nodurile comunității nu mai sunt viabile din punct de vedere economic.
Oprirea serviciilor nodurilor ar putea duce la un set mic de noduri care dețin un control disproporționat asupra consensului.
Aceasta subminează garanțiile de descentralizare pe care ancorarea ar trebui să le ofere.
3. Fricțiune în adoptare
Devine din ce în ce mai dificil să justifici LTO ca un strat de ancorare sigur în vânzări sau în conversații de audit.
Clienții și partenerii se așteaptă ca EQTY să ancoreze pe rețele publice larg adoptate și credibile (de exemplu, Ethereum, Base).
Percepția de „ancorare la un Layer 1 de 5 milioane de dolari” slăbește încrederea în infrastructura de bază a EQTY.
4. Fragilitatea infrastructurii
Dacă chiar și câțiva validatori cheie ies offline, LTO devine instabil sau se oprește complet.
Întreținerea continuă (exploratori, indexeri, infrastructură de noduri) adaugă overhead cu valoare în scădere.
De ce Base este stratul de ancorare potrivit
Base oferă:
Compatibilitate completă EVM
Securitate economică și tehnică moștenită de la Ethereum
Suport larg pentru unelte (MetaMask, WalletConnect, The Graph etc.)
Taxe aproape nule cu finalitate rapidă
Aliniere strânsă cu stratul de active și lichiditate al EQTY, care de asemenea trăiește pe Base
Ancorarea în Base elimină povara menținerii unui Layer 1 personalizat, în timp ce crește auditabilitatea, compozabilitatea și încrederea.
Motivație strategică
Valoarea EQTY nu este în consens — este în stratul său privat, modelul de active și arhitectura de conformitate.
Menținerea unui Layer 1 oferă puțin avantaj strategic la un cost ridicat.
Migrarea către Base permite EQTY să se concentreze complet pe adoptarea produsului, integrarea legală și tokenizarea activelor, fără a fi tras în jos de infrastructura Layer 1.
2. Nou token $EQTY ERC-20
Platforma EQTY va introduce un nou token ERC-20, $EQTY, desfășurat pe rețeaua Base. Acest token înlocuiește tokenul LTO și servește ca monedă nativă pentru operațiunile protocolului, inclusiv ancorarea și guvernarea.
Contractul tokenului începe cu o ofertă zero. $EQTY este mintat la cerere atunci când utilizatorii își schimbă tokenurile LTO într-o perioadă limitată de migrare. Această fereastră este impusă pe lanț: după o înălțime predefinită a blocului, funcția de mint devine dezactivată permanent. Orice tokenuri LTO neconvertite înainte de acest termen sunt excluse din ecosistemul EQTY, iar oferta finală de $EQTY va fi mai mică decât oferta originală LTO.
Contractul tokenului este deliberat minimal. Urmează interfața standard ERC-20, fără logică specială de transfer, caracteristici de airdrop sau programe de vesting.
Tokenul $EQTY va fi folosit pentru a plăti taxele de ancorare, a participa la guvernarea protocolului și, potențial, a sprijini roluri de utilitate suplimentare pe măsură ce platforma evoluează. Utilitatea necesită arderea tokenurilor, reducând oferta totală.
3. Contractul de Ancorare pe Base
Ancorarea va fi efectuată printr-un contract inteligent ușor desfășurat pe rețeaua Base. Acest contract emite evenimente care înregistrează public hash-ul lanțurilor de evenimente sau mesajelor, fără a stoca orice stare pe lanț.
Fiecare ancor mapează o cheie la o valoare, unde:
Pentru lanțuri de evenimente: cheie = stateHash, valoare = eventHash
Pentru mesaje: cheie = messageHash, valoare = 0x0
Interfață
struct Anchor {
cheie bytes32;
valoare bytes32;
}
funcția anchor(Anchor[] calldata ancore) extern;
eveniment Ancorat(
cheie indexată bytes32,
valoare bytes32,
adresă indexată expeditor,
uint64 timestamp
);
Comportament
Contractul emite un eveniment Ancorat per (cheie, valoare) pereche.
Timestamp-ul blocului curent este inclus în eveniment ca un câmp separat pentru comoditate și auditabilitate.
Niciun stat nu este stocat în contract. Toate datele de ancorare sunt înregistrate doar prin loguri.
Contractul este fără permisiune — oricine poate ancorează.
Aceste evenimente sunt concepute pentru a fi indexabile și accesibile prin:
Componente interne, cum ar fi indexerul oBridge și platforma EQTY
Servicii externe, inclusiv The Graph, Infura sau verificatori personalizați
Prin menținerea ancorării fără stare și emiterea de evenimente complete, acest design asigură că ancorarea este verificabilă, eficientă și independentă de infrastructură.
Mecanism de taxe
Clienții trebuie să apeleze approve() pe contractul ERC20 pentru a activa ancorarea
Fiecare ancor implică o ardere de $EQTY, impusă în funcția anchor()
Suma taxei este citită dintr-un contract de configurare controlat de guvernare separat
Ancorarea nu va folosi approve() ci va arde prin eqtyToken.burnFrom(msg.sender, fee * n)
4. Guvernarea taxelor
Pentru a menține ancorarea economică sustenabilă și corectă în timp, taxa plătită în $EQTY per ancoră trebuie să fie ajustabilă. În loc să codifice o taxă statică sau să se bazeze pe oracle-uri de preț, EQTY va folosi un model de guvernare pe lanț pentru a controla acest parametru într-un mod transparent și descentralizat.
Un contract de configurare dedicat va stoca taxa curentă de ancorare. Această valoare poate fi actualizată doar de un contract de guvernare — specific, o instanță a Guvernatorului OpenZeppelin legată de tokenul $EQTY. Voturile vor fi exprimate pe baza soldurilor $EQTY folosind logica standard ERC20Votes.
Contractul de ancorare citește taxa curentă din contractul de configurare de fiecare dată când se apelează anchor(). Apoi arde suma corespunzătoare de $EQTY direct din soldul expeditorului. Această abordare evită necesitatea tranzacțiilor approve() și asigură că contractul de ancorare rămâne ușor și fără stare dincolo de aplicarea taxelor.
Modelul de guvernare permite comunității să ajusteze taxele în timp ca răspuns la condițiile de piață, fluctuațiile prețului tokenului sau schimbările în cererea de ancorare — fără a se baza pe surse de date externe sau control centralizat.
5. Nouă Bibliotecă de Strat Privat
Pentru a sprijini ancorarea pe Base și semnarea nativă pentru portofel, va fi creată o nouă bibliotecă TypeScript independentă pentru a gestiona logica stratului privat — inclusiv lanțuri de evenimente, semnarea evenimentelor, ancorarea și structurile mesajului de relay. Această bibliotecă înlocuiește biblioteca specifică LTO @ltonetwork/lto-api.js pentru toate cazurile de utilizare EQTY.
Noua bibliotecă este concepută pentru a fi utilizată atât în medii de browser (de exemplu, MetaMask, WalletConnect) cât și în instrumente pe server.
Domeniu și conținut
Numai componentele relevante ale stratului privat LTO vor fi incluse:
evenimente/ Include Event, EventChain, MergeConflict și logica de serializare asociată.
mesaj/ Include Message și Relay, utilizate pentru comunicarea criptată off-chain.
Cod de suport Include clase utile precum Binary.
Biblioteca nu va avea nicio dependență de LTO Network:
Niciun API de noduri LTO
Nicio logică de tranzacție
Niciun instrument de generare a cheilor
Nicio codare specifică adresei LTO
Aceasta va sprijini ancorarea prin contracte inteligente pe Base și se va integra curat cu ethers.js pentru semnarea și trimiterea ancorelor.
Modelul de semnare a evenimentelor
Metoda Event.signWith() va fi făcută asincronă pentru a sprijini semnarea bazată pe browser prin MetaMask, WalletConnect sau orice semnatar extern, în plus față de semnarea directă cu ethers. Folosește o interfață ISigner abstractă:
interfață ISigner {
sign(data: Uint8Array): Promise<Uint8Array>;
}
Evenimentul semnat nu mai necesită o cheie publică; include doar semnătura și adresa derivată. Aceasta îl face compatibil cu fluxurile de semnare Ethereum (personal_sign) și elimină necesitatea de a extrage chei publice, ceea ce nu este posibil în majoritatea mediilor de portofel.
Integrarea ancorării
Biblioteca include o metodă pentru a genera hărți de ancorare:
const ancore = chain.from(lastKnownEvent.hash).getAnchorMap();
Fiecare ancor mapează un stateHash (cheie) la un lastEventHash (valoare), gata să fie trimis la contractul inteligent Base. Pentru mesajele de relay, hash-ul mesajului în sine este folosit ca cheia ancorei, iar valoarea este setată pe zero (0x0).
Ancorarea poate fi efectuată prin apelarea directă a contractului inteligent prin ethers.Contract.anchor(Anchor[]). Aceasta evită dependența de orice serviciu backend sau infrastructură proprietară.
Semnarea mesajului
Biblioteca include, de asemenea, clase Message și Relay pentru comunicarea off-chain. La fel ca evenimentele, mesajele sunt semnate asincron folosind interfața ISigner. Semnăturile sunt peste hash-ul mesajului, iar nicio cheie publică nu este inclusă — doar adresa derivată este utilizată pentru verificare.
După semnare, hash-ul mesajului este ancorat pe lanț prin același contract Anchor. Formatul este:
cheie = messageHash
valoare = 0x0
Aceasta asigură că mesajele off-chain pot fi marcate temporal și verificate public fără a dezvălui conținutul lor. Ancorarea poate fi efectuată de expeditor sau de serviciul de relay.
Implementare și utilizare
Biblioteca va fi publicată ca un pachet NPM separat. Este destinată a fi nucleul comun folosit de:
Portofelul EQTY (pentru semnarea evenimentelor și mesajelor)
Serviciul de relay (pentru calcularea hash-ului și parsarea mesajului)
SDK-ul Ownables (pentru construcția și trimiterea evenimentelor)
Orice frontend sau verificator terță parte
6. Indexarea oBridge
Serviciul oBridge va înlocui logica sa actuală de indexare bazată pe LTO cu un nou indexer care procesează evenimente Ancorate emise de contractul de ancorare pe Base.
Acest indexer ascultă logurile de ancorare pe Base și menține o bază de date locală a celei mai recente ancore pe cheie, care poate reprezenta fie o stare a lanțului de evenimente, fie un hash de mesaj de relay. Fiecare intrare include:
cheie: starea ancorată sau hash-ul mesajului
valoare: hash-ul evenimentului corespunzător sau 0x0
txHash, blockNumber, logIndex și expeditor
Aceste înregistrări sunt expuse printr-un API HTTP public. Structura și comportamentul acestui API vor rămâne compatibile cu indexerul existent de ancorare LTO, inclusiv endpoint-ul GET /hash/verify, permițând componentelor EQTY existente să tranziționeze cu modificări minime.
Indexerul oBridge îndeplinește două roluri:
Ca o dependență internă pentru serviciul de relay, care trebuie să verifice că mesajele au fost ancorate înainte de a le elibera.
Ca un serviciu de verificare public pentru clienți externi și portofele care doresc să verifice statusul ancorării fără a interoga direct Base.
Toate datele rămân verificabile pe lanț, iar clienții pot o ocolii pe oBridge dacă doresc, folosind eth_getLogs sau propriul lor indexer.
7. Serviciul de Relay
Serviciul de relay se ocupă de livrarea sigură a mesajelor criptate între părți. Pentru a asigura că mesajele sunt autentice, marcate cu timp și controlate pe bază de acces, serviciul va fi actualizat pentru a sprijini atât validarea ancorării pe lanț cât și autentificarea modernă, nativă pentru portofel, folosind Sign-In with Ethereum (SIWE).
Autentificarea mesajelor cu SIWE
În loc să se bazeze pe semnăturile mesajelor HTTP sau provocările personalizate, relay-ul va implementa standardul SIWE (EIP-4361). Această abordare le permite utilizatorilor să se autentifice semnând un mesaj text standard cu portofelul lor Ethereum, producând o semnătură recuperabilă care îi leagă de o sesiune.
Flux de conectare:
Clientul solicită un mesaj SIWE de la backend-ul relay: GET /auth/siwe-message?address=0x...
Serverul returnează un mesaj standard SIWE care include:
Domeniu (de exemplu, relay.eqty.network)
Nonce
Timestamp de expirare
Câmp de resurse opțional limitat la /messages?to=...
Declarație: de exemplu, „Conectați-vă pentru a accesa mesajele dvs. EQTY.”
Clientul semnează mesajul folosind personal_sign
Clientul trimite mesajul semnat și semnătura la POST /auth/verify
Serverul verifică semnătura și emite:
Un token de acces JWT (cu durată scurtă, de exemplu, 15 minute)
Un token de reîmprospătare (cu durată mai lungă, de exemplu, 24 de ore)
Toate cererile ulterioare de recuperare a mesajelor (GET /messages?to=...) trebuie să includă tokenul de acces în antetul Authorization.
Când tokenul expiră, clientul poate folosi tokenul de reîmprospătare pentru a obține un nou token de acces fără a fi necesară re-semnația.
Acest model este pe deplin compatibil cu MetaMask, WalletConnect și alte portofele EIP-1193, și urmează tipare de securitate larg adoptate. Nu este necesară nicio logică sau infrastructură personalizată dincolo de bibliotecile SIWE existente.
Ancorarea și verificarea mesajelor
În plus față de autentificare, serviciul de relay va valida că fiecare mesaj a fost ancorat pe lanț înainte de a-l livra. Ancorarea oferă imuabilitate, marcaj temporal și previne atacurile de spam sau replay.
Relay-ul își menține propriul indexer ușor pentru contractul de ancorare pe Base. Ascultă pentru evenimente Ancorate și înregistrează:
cheie = messageHash
valoare = 0x0
expeditor
blockNumber, txHash, timestamp
Pentru a verifica un mesaj înainte de livrare, relay-ul verifică că:
Un eveniment Ancorat există cu cheia = messageHash
Valoarea este exact 0x0 (adică nu este un ancor de lanț de evenimente)
Expeditorul se potrivește cu semnatarul mesajului (adică din adresă)
Numai după ancorarea cu succes mesajul este eliberat către destinatar. Aceasta asigură că toate mesajele sunt public verificabile, marcate cu timp pe Base și ancorate de identitatea corectă.
Relay-ul efectuează această verificare folosind propriul său indexer intern și nu se bazează pe oBridge.
8. Schimbări la Contractul Ownable (CosmWasm)
Odată cu migrarea de la LTO Layer 1 și deprecierea semnării evenimentelor bazate pe chei publice, contractele Ownable trebuie actualizate pentru a sprijini autorizarea bazată pe adrese folosind adrese standard Ethereum.
Autorizarea bazată pe adrese
Anterior, verificarea proprietății se baza pe recuperarea și compararea cheilor publice extrase din evenimente semnate. Deoarece portofelele Ethereum nu expun chei publice, iar semnăturile folosesc acum personal_sign (recuperabil la o adresă), modelul de verificare trebuie să se schimbe pentru a compara adresele direct.
Logica contractului actualizată folosește info.sender — adresa care a semnat și a trimis evenimentul — ca identitate autoritativă.
Aceasta afectează toate punctele de intrare unde este necesară autorizarea:
try_transfer: expeditorul trebuie să se potrivească cu adresa curentă a proprietarului
try_release: expeditorul trebuie să se potrivească cu adresa proprietarului blocat anterior
try_register_lock: verifică dacă câmpul owner al evenimentului se potrivește cu semnatarul
În loc să convertească cheile publice în adrese LTO, contractul pur și simplu stochează și compară valorile Addr (de exemplu, 0xabc123...).
CAIP-2 și potrivirea rețelei
Contractul continuă să valideze originea evenimentelor transfrontaliere folosind identificatorul de rețea CAIP-2. Pentru mesajele bazate pe Ethereum, spațiul de nume este eip155:<chainId>. Contractul verifică că:
Evenimentul.network se potrivește cu rețeaua așteptată
Câmpul owner din eveniment se potrivește cu semnatarul (info.sender) sub spațiul de nume CAIP dat
Funcțiile de conversie address_lto() și address_eip155() pot fi eliminate, deoarece nu mai este necesară nicio traducere de la sau către adresele LTO.
Impact
Această modificare face ca contractul Ownable să fie:
Complet compatibil cu semnarea și identitatea nativă Ethereum
Independent de infrastructura de chei LTO
Compatibil cu orice lanț care suportă recuperarea bazată pe adrese (de exemplu, EVM)
Ownables-urile existente, care se bazează pe semnarea și ancorarea specifice LTO, vor deveni unverificabile sub noul model și trebuie să fie reemise (vezi Secțiunea 11).
9. Actualizarea SDK-urilor Ownables
SDK-ul Ownables trebuie actualizat pentru a reflecta schimbarea de la semnarea cheii publice bazate pe LTO la autorizarea bazată pe adrese de stil Ethereum și ancorarea pe Base.
Actualizări cheie
Semnarea evenimentului
Actualizați crearea de evenimente pentru a utiliza noua bibliotecă de strat privat (@eqty-core/events)
Utilizați implementările ISigner compatibile cu MetaMask, WalletConnect sau semnatarii bazati pe ethers
Asigurați-vă că signWith() nu mai depinde de o cheie publică; doar adresa recuperabilă este utilizată
Ancorare
Înlocuiți logica de ancorare a nodului LTO cu trimiterea contractului inteligent pe Base
Utilizați getAnchorMap() pentru a colecta perechi (cheie, valoare) și trimiteți-le prin ethers.Contract.anchor()
Asigurați-vă că ancorarea mesajului folosește (cheie = messageHash, valoare = 0x0)
Verificare
Actualizați logica de verificare pentru a utiliza API-ul compatibil cu oBridge /hash/verify sau o interogare directă a logurilor
Confirmați că valoarea ancorei se potrivește cu hash-ul evenimentului așteptat și că expeditorul se potrivește cu adresa Ethereum a semnatarului
Utilizarea adresei
Înlocuiți orice logică care compară sau generează adrese LTO
Utilizați adrese Ethereum simple (0x...) în întreaga fluxuri de evenimente și mesaje
Compatibilitate
SDK-ul actualizat rămâne structurally similar, dar nu mai este legat de biblioteca @ltonetwork/lto-api.js sau de serviciile nodului LTO. Este compatibil cu noua bibliotecă de strat privat și ancorarea pe Base, și va interopera cu contractele Ownable actualizate și serviciul de relay.
10. Actualizare Portofel Universal
Portofelul universal trebuie actualizat pentru a reflecta migrarea către Base și noua arhitectură EQTY. Nu mai interacționează cu nodurile LTO.
Actualizări de bază
Conexiune portofel
Înlocuiți gestionarea cheilor LTO cu o bibliotecă compatibilă cu Ethereum (ethers.js)
Utilizați interfețele de provider EIP-1193 pentru a permite semnarea și recuperarea adreselor
Suport pentru tokenuri
Adăugați suport pentru afișarea și gestionarea soldurilor noului token $EQTY ERC-20 pe Base
Includeți metadatele tokenului, istoria și urmărirea soldului prin intermediul punctelor finale publice RPC
Semnarea evenimentelor și mesajelor
Integrați noua bibliotecă de strat privat pentru a permite utilizatorilor să creeze și să semneze lanțuri de evenimente și mesaje
Utilizați personal_sign prin portofelul conectat; cheile publice nu mai sunt necesare
Ancorare
Trimiteți hărțile ancorei direct către contractul de ancorare Base folosind ethers.js
Gestionează trimiterea pe lanț, confirmarea și feedback-ul opțional al interfeței pentru costul ancorării în $EQTY
Integrarea relay-ului
Autentificare prin SIWE (Sign-In with Ethereum)
Stocare și reîmprospătare a tokenurilor de acces după cum este necesar
Utilizați cereri autentificate pentru a obține mesaje criptate de la serviciul de relay
Funcționalități eliminate
UI de închiriere LTO
Selecția nodului și vizualizarea lanțului
Gestionarea identității pe lanț legată de LTO
11. Plan de Migrare
Odată cu deprecierea LTO Layer 1 și introducerea unui nou sistem de ancorare pe Base, toate componentele de bază ale protocolului trebuie să migreze. Datele moștenite legate de infrastructura LTO — inclusiv ancore, lanțuri de evenimente și mesaje — nu vor mai fi valide.
Ce devine invalid
Lanțurile de evenimente semnate folosind perechi de chei LTO nu pot fi verificate, deoarece cheia publică nu mai poate fi extrasă din semnăturile bazate pe Ethereum.
Ancorele înregistrate pe LTO L1 nu pot fi de încredere sau interogate mai departe.
Ownables legate de identitățile bazate pe LTO sau lanțurile ancorate trebuie să fie înlocuite.
Mesajele care nu sunt ancorate pe Base vor fi respinse de serviciul de relay.
Acțiuni necesare
Migrarea tokenurilorUtilizatorii trebuie să schimbe manual tokenurile lor LTO pentru $EQTY folosind podul. Minting-ul este posibil doar până la o înălțime specifică a blocului pe Base. După acest bloc, podul va fi închis și funcția de minting dezactivată permanent. Tokenurile LTO neschimbate devin lipsite de valoare.
Reemite Activele Ownables.Emitentii Ownable trebuie să emită noi ownable legate de rețeaua BASE. Instrucțiunile vor urma despre cum să schimbe Ownables-urile moștenite în noi Ownables
Tranziția portofelului Utilizatorii vor trebui să actualizeze Portofelul Universal.
Fără snapshot
Nu va exista niciun snapshot, migrare automată sau strat de compatibilitate retroactivă. Fiecare componentă (evenimente, mesaje, solduri de tokenuri) trebuie să fie re-estabilită pe Base prin intermediul interfețelor corespunzătoare. Noul protocol este curat prin design și nu păstrează legături cu LTO L1.
