1. Introducere și Motivație
Context de fundal
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 de ancorare public pentru a marca temporal și verifica acele lanțuri de evenimente pe o blockchain imuabilă
Istoric, acest strat public a fost furnizat de LTO Network Layer 1, o blockchain dedicată bazată pe dovada mizei, optimizată pentru ancorare.
Cu toate acestea, contextul operațional s-a schimbat semnificativ.
De ce stratul LTO Layer 1 trebuie să fie depreciat
1. Securitatea economică s-a prăbușit
LTO are în prezent o capitalizare de piață sub 5 milioane de dolari, cu doar ~20% din tokenuri staked.
Aceasta înseamnă că bugetul de securitate efectiv (adică valoarea totală care asigură consensul) este de < 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 legal executabile — acest lucru este inacceptabil.
2. Centralizarea validatorilor și stimulentele scăzute
Nodurile comunității nu mai sunt viabile din punct de vedere economic.
Nodurile care își încheie serviciul ar putea duce la un set mic de noduri care dețin control disproporționat asupra consensului.
Acest lucru subminează garanțiile de descentralizare pe care ancorarea trebuie să le ofere.
3. Fricțiune în adoptare
Este din ce în ce mai dificil să justifici LTO ca un strat de ancorare sigur în conversațiile de vânzări sau 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ă nod) adaugă overhead cu valoare în scădere.
De ce Base este stratul de ancorare potrivit
Base oferă:
Compatibilitate completă cu EVM
Securitate economică și tehnică moștenită de la Ethereum
Suport larg pentru instrumente (MetaMask, WalletConnect, The Graph etc.)
Taxe aproape zero cu finalitate rapidă
Aliniere strânsă cu stratul de active și lichiditate EQTY, care trăiește de asemenea pe Base
Ancorarea pe Base elimină povara menținerii unui strat personalizat Layer 1, î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.
Trecerea la 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 token începe cu o ofertă de zero. $EQTY este emis la cerere când utilizatorii își schimbă tokenurile LTO în timpul unei perioade de migrare limitate. Această fereastră este aplicată pe lanț: după o înălțime de bloc prestabilită, funcția de mint devine permanent dezactivată. Orice tokenuri LTO care nu au fost convertite înainte de această limită sunt excluse din ecosistemul EQTY, iar oferta finală $EQTY va fi mai mică decât oferta originală LTO.
Contractul token este deliberat minimal. Acesta urmează interfața standard ERC-20, fără logică specială de transfer, caracteristici de airdrop sau planuri de vesting.
Tokenul $EQTY va fi folosit pentru a plăti taxele de ancorare, a participa la guvernarea protocolului și, potențial, a susține roluri suplimentare de utilitate pe măsură ce platforma evoluează. Utilitatea necesită arderea tokenurilor, reducând oferta totală.
3. Contract 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 nicio stare pe lanț.
Fiecare ancoră mapează o cheie la o valoare, unde:
Pentru lanțurile de evenimente: cheie = stateHash, valoare = eventHash
Pentru mesaje: cheie = messageHash, valoare = 0x0
Interfață
struct Anchor {
bytes32 cheie;
valoare bytes32;
}
funcție anchor(Anchor[] calldata ancore) extern;
eveniment Ancorat(
bytes32 indexed cheie,
valoare bytes32,
adresă expeditor indexată,
uint64 timestamp
);
Comportament
Contractul emite un eveniment Ancorat pentru fiecare pereche (cheie, valoare).
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 jurnale.
Contractul este permis fără restricții — oricine poate ancore.
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 taxare
Clienții trebuie să apeleze approve() pe contractul ERC20 pentru a activa ancorarea
Fiecare ancoră implică o ardere de $EQTY, aplicată î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 durabilă din punct de vedere economic și echitabilă de-a lungul timpului, 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 — în special, 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 este apelată 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 taxei.
Modelul de guvernare permite comunității să ajusteze taxele în timp în 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 externe de date sau control centralizat.
5. Noua bibliotecă a stratului privat
Pentru a susține ancorarea pe Base și semnarea nativă a portofelului, va fi creată o nouă bibliotecă TypeScript autonomă pentru a gestiona logica stratului privat — inclusiv lanțurile de evenimente, semnarea evenimentelor, ancorarea și structurile de mesaje de relay. Această bibliotecă înlocuiește @ltonetwork/lto-api.js specific LTO 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 de server-side.
Domeniu și conținut
Numai componentele relevante ale stratului privat LTO vor fi incluse:
evenimente/ Include Eveniment, LanțEveniment, ConflicteDeFuzionare și logica de serializare aferentă.
mesaj/ Include Mesaj și Relay, utilizate pentru comunicarea criptată off-chain.
Cod de suport Include clase utile, cum ar fi Binary.
Biblioteca nu va avea nicio dependență de LTO Network:
Fără API de noduri LTO
Fără logică de tranzacție
Fără instrumente de generare a cheilor
Fără codificare specifică LTO pentru adrese
Va susține ancorarea prin contracte inteligente pe Base și se va integra curat cu ethers.js pentru semnarea și trimiterea ancorelor.
Model de semnare a evenimentelor
Metoda Event.signWith() va fi făcută asincronă pentru a susține semnarea bazată pe browser prin MetaMask, WalletConnect sau orice semnatar extern, pe lângă semnarea directă cu ethers. Utilizează o interfață abstractă ISigner:
interfață ISigner {
semnează(data: Uint8Array): Promisiune<Uint8Array>;
}
Evenimentul semnat nu mai necesită o cheie publică; acesta include doar semnătura și adresa derivată. Acest lucru î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 medii de portofel.
Integrarea ancorării
Biblioteca include o metodă pentru a genera hărți de ancore:
const ancore = chain.from(lastKnownEvent.hash).getAnchorMap();
Fiecare ancoră mapează un stateHash (cheie) la un lastEventHash (valoare), gata să fie trimis către contractul inteligent Base. Pentru mesajele de relay, hash-ul mesajului în sine este folosit ca cheia ancorei, iar valoarea este setată la zero (0x0).
Ancorarea poate fi efectuată apelând direct contractul inteligent prin ethers.Contract.anchor(Anchor[]). Aceasta evită dependența de orice serviciu backend sau infrastructură proprietară.
Semnarea mesajelor
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 folosită pentru verificare.
După semnare, hash-ul mesajului este ancorat pe lanț prin același contract Anchor. Formatul este:
cheie = messageHash
valoare = 0x0
Acest lucru 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 utilizat de:
Portofelul EQTY (pentru semnarea evenimentelor și mesajelor)
Serviciul de relay (pentru calculul hash-ului și parsarea mesajelor)
SDK-ul Ownables (pentru construcția și trimiterea evenimentelor)
Orice frontend sau verificator terță parte
6. Indexarea oBridge
Serviciul oBridge va înlocui logica actuală de indexare bazată pe LTO cu un nou indexer care procesează evenimentele Ancorate emise de contractul de ancorare Base.
Acest indexer ascultă jurnalele de ancorare pe Base și menține o bază de date locală a celei mai recente ancore pe cheie, care poate reprezenta fie un stat al 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-o API HTTP publică. Structura și comportamentul acestei API vor rămâne compatibile cu indexerul de ancorare LTO existent, inclusiv endpoint-ul GET /hash/verify, permițând componentelor existente EQTY să treacă 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 starea ancorării fără a interoga direct Base.
Toate datele rămân verificabile pe lanț, iar clienții pot ocoli oBridge dacă doresc, folosind eth_getLogs sau propriul lor indexer.
7. Serviciul de Relay
Serviciul de relay gestionează livrarea sigură a mesajelor criptate între părți. Pentru a se asigura că mesajele sunt autentice, marcate temporal și controlate de acces, serviciul va fi actualizat pentru a susține atât validarea ancorării pe lanț, cât și autentificarea modernă, nativă portofelului, utilizând Sign-In with Ethereum (SIWE).
Autentificarea mesajelor cu SIWE
În loc să se bazeze pe semnăturile mesajelor HTTP sau provocări personalizate, relay-ul va implementa standardul SIWE (EIP-4361). Această abordare permite utilizatorilor să se autentifice prin semnarea unui mesaj text standard cu portofelul lor Ethereum, producând o semnătură recuperabilă care îi leagă de o sesiune.
Flux de autentificare:
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
Timp de expirare
Câmpul de resurse opțional este 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 resemna.
Acest model este complet compatibil cu MetaMask, WalletConnect și alte portofele EIP-1193, și urmează modele de securitate adoptate pe scară largă. 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 livrare. Ancorarea oferă imutabilitate, marcaj temporal și previne atacurile de spam sau de reexecutare.
Serviciul de relay își menține propriul indexer ușor pentru contractul de ancorare pe Base. Acesta ascultă evenimentele Ancorate și înregistrează:
cheie = messageHash
valoare = 0x0
expeditor
blockNumber, txHash, timestamp
Pentru a verifica un mesaj înainte de livrare, relay-ul verifică că:
Există un eveniment Ancorat cu cheie = messageHash
Valoarea este exact 0x0 (adică nu este un ancoraj de lanț de evenimente)
Expeditorul corespunde semnatarului mesajului (adică adresa de la care provine)
Numai după ancorarea cu succes mesajul este eliberat către destinatar. Acest lucru asigură că toate mesajele sunt verificabile public, marcate temporal pe Base și ancorate de identitatea corectă.
Serviciul de relay 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 să fie actualizate pentru a susține autorizarea bazată pe adrese folosind adrese Ethereum standard.
Autorizare bazată pe adrese
Anterior, verificarea proprietății se baza pe recuperarea și compararea cheilor publice extrase din evenimentele semnate. Deoarece portofelele Ethereum nu expun chei publice, iar semnăturile folosesc acum personal_sign (recuperabile la o adresă), modelul de verificare trebuie să se schimbe pentru a compara direct adresele.
Logica contractului actualizat utilizează info.sender — adresa care a semnat și trimis evenimentul — ca identitate autoritară.
Aceasta afectează toate punctele de intrare unde este necesară autorizarea:
try_transfer: expeditorul trebuie să corespundă adresei actuale a proprietarului
try_release: expeditorul trebuie să corespundă adresei anterioare a proprietarului blocat
try_register_lock: verifică că câmpul proprietar al evenimentului corespunde semnatarului
Î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 inter-chain folosind identificatorul de rețea CAIP-2. Pentru mesajele bazate pe Ethereum, spațiul de nume este eip155:<chainId>. Contractul verifică că:
Evenimentul.network corespunde rețelei așteptate
Câmpul proprietar în eveniment corespunde semnatarului (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 nevoie de nicio traducere de la sau către adrese LTO.
Impact
Această schimbare face ca contractul Ownable să fie:
Complet compatibil cu semnarea și identitatea nativă Ethereum
Independent de infrastructura cheilor LTO
Compatibil cu orice lanț care suportă recuperarea bazată pe adrese (de exemplu, EVM)
Ownables existente, care se bazează pe semnarea și ancorarea specifică LTO, vor deveni unverificabile sub noul model și trebuie să fie reemise (vezi Secțiunea 11).
9. Actualizarea SDK-ului Ownables
SDK-ul Ownables trebuie actualizat pentru a reflecta trecerea de la semnarea cheilor publice bazate pe LTO la autorizarea bazată pe adrese de tip Ethereum și ancorarea pe Base.
Actualizări cheie
Semnarea evenimentelor
Actualizați crearea evenimentelor pentru a utiliza noua bibliotecă a stratului privat (@eqty-core/events)
Utilizați implementările ISigner compatibile cu MetaMask, WalletConnect sau semnatarii bazati pe ethers
Asigurați-vă că signWith() nu se mai bazează pe o cheie publică; este utilizată doar adresa recuperabilă
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 mesajelor utilizează (cheie = messageHash, valoare = 0x0)
Verificare
Actualizați logica de verificare pentru a utiliza API-ul /hash/verify compatibil cu oBridge sau o interogare directă de jurnal
Confirmați că valoarea ancorei corespunde hash-ului de eveniment așteptat și că expeditorul corespunde adresei Ethereum a semnatarului
Utilizarea adreselor
Înlocuiți orice logică care compară sau generează adrese LTO
Utilizați adrese Ethereum simple (0x...) în fluxurile 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 serviciile nodurilor LTO. Este compatibil cu noua bibliotecă a stratului privat și ancorarea pe Base și va interopera cu contractele Ownable actualizate și serviciul de relay.
10. Actualizarea Portofelului Universal
Portofelul universal trebuie actualizat pentru a reflecta migrarea la Base și noua arhitectură EQTY. Acesta 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 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, istoricul și urmărirea soldului prin intermediul punctelor finale RPC publice
Semnarea evenimentelor și mesajelor
Integrați noua bibliotecă a stratului 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 ancore direct către contractul de ancorare Base utilizând ethers.js
Gestionați trimiterea pe lanț, confirmarea și feedback-ul opțional al UI pentru costul ancorării în $EQTY
Integrarea relay
Autentificare prin SIWE (Sign-In with Ethereum)
Stocați și reîmprospătați tokenurile de acces după cum este necesar
Utilizați cereri autentificate pentru a obține mesaje criptate de la serviciul de relay
Funcții eliminate
UI de leasing LTO
Selectarea nodurilor ș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 legate de infrastructura LTO — inclusiv ancorele, lanțurile de evenimente și mesajele — nu vor mai fi valide.
Ce devine invalid
Lanțurile de evenimente semnate folosind 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 de acum înainte.
Proprietățile legate de identități bazate pe LTO sau lanțuri ancorate trebuie înlocuite.
Mesajele neancorate pe Base vor fi respinse de serviciul de relay.
Acțiuni necesare
Migrarea tokenuluiUtilizatorii trebuie să își schimbe manual tokenurile LTO pentru $EQTY folosind podul. Mintingul este posibil doar până la o înălțime specifică de bloc pe Base. După acest bloc, podul va fi oprit și funcția de mint dezactivată permanent. Tokenurile LTO neschimbate devin fără valoare.
Reemiteți Activele Ownables.Emitentii Ownable trebuie să emită noi ownables legate de rețeaua BASE. Instrucțiuni vor urma despre cum să schimbați ownables vechi cu ownables noi
Trecerea portofelului Utilizatorii vor trebui să actualizeze Portofelul Universal.
Nicio instantanee
Nu va exista o instantanee, migrare automată sau un strat de compatibilitate inversă. Fiecare componentă (evenimente, mesaje, solduri de token) trebuie să fie reinstaurată pe Base prin interfețele corespunzătoare. Noua protocol este curat din design și nu păstrează legături cu LTO L1.
