1. Introduzione & Motivazione
Contesto
La piattaforma EQTY si basa su un'architettura a doppio strato:
Uno strato privato per la gestione di catene di eventi verificabili (ad es. Ownables, messaggi)
Uno strato di ancoraggio pubblico per timestampare e verificare quelle catene di eventi su una blockchain immutabile
Storicamente, questo strato pubblico è stato fornito dalla Rete LTO Layer 1, una blockchain dedicata Proof-of-Stake ottimizzata per l'ancoraggio.
Tuttavia, il contesto operativo è cambiato in modo significativo.
Perché il Layer 1 di LTO deve essere deprecato
1. La sicurezza economica è crollata
LTO attualmente ha una capitalizzazione di mercato inferiore a $5M, con solo ~20% dei token staked.
Questo significa che il budget di sicurezza effettivo (cioè il valore totale che garantisce il consenso) è di < $1M.
A questi livelli, è finanziariamente sostenibile per un attore malevolo compromettere il consenso, censurare le transazioni di ancoraggio o riscrivere la storia.
Per una piattaforma come EQTY — che ancorerà registri di asset legalmente vincolanti — questo è inaccettabile.
2. Centralizzazione dei validatori e bassi incentivi
I nodi della comunità non sono più economicamente sostenibili.
I nodi che terminano il servizio potrebbero portare a un piccolo gruppo di nodi che detiene un controllo sproporzionato sul consenso.
Questo mina le garanzie di decentralizzazione che l'ancoraggio è destinato a fornire.
3. Attrito nell'adozione
Diventa sempre più difficile giustificare LTO come layer di ancoraggio sicuro nelle vendite o nelle conversazioni di audit.
I client e i partner si aspettano che EQTY ancorerà su reti pubbliche ampiamente adottate e credibili (ad es. Ethereum, Base).
La percezione di “ancorare a un Layer 1 da $5M” indebolisce la fiducia nell'infrastruttura core di EQTY.
4. Fragilità dell'infrastruttura
Se anche solo pochi validatori chiave vanno offline, LTO diventa instabile o si ferma completamente.
Il mantenimento continuo (esploratori, indicizzatori, infrastruttura nodale) aggiunge oneri con valore decrescente.
Perché Base è il giusto strato di ancoraggio
Base offre:
Completamente compatibile con EVM
Sicurezza economica e tecnica ereditata da Ethereum
Ampio supporto degli strumenti (MetaMask, WalletConnect, The Graph, ecc.)
Commissioni quasi zero con finalità rapida
Allineamento stretto con il layer di asset e liquidità di EQTY, che vive anch'esso su Base
L'ancoraggio a Base rimuove l'onere di mantenere un Layer 1 personalizzato aumentando l'auditabilità, la composabilità e la fiducia.
Motivazione strategica
Il valore di EQTY non è nel consenso — è nel suo layer privato, modello di asset e architettura di conformità.
Mantenere un Layer 1 offre poco vantaggio strategico a un costo elevato.
Passare a Base consente a EQTY di concentrarsi interamente sull'adozione del prodotto, sull'integrazione legale e sulla tokenizzazione degli asset, senza essere appesantito dall'infrastruttura Layer 1.
2. Nuovo token $EQTY ERC-20
La piattaforma EQTY introdurrà un nuovo token ERC-20, $EQTY, distribuito sulla rete Base. Questo token sostituisce il token LTO e funge da valuta nativa per le operazioni del protocollo, inclusi l'ancoraggio e la governance.
Il contratto del token inizia con un'offerta pari a zero. $EQTY viene mintato su richiesta quando gli utenti scambiano i loro token LTO durante un periodo di migrazione limitato. Questa finestra è applicata on-chain: dopo un'altezza di blocco predeterminata, la funzione di mint diventa permanentemente disabilitata. Qualsiasi token LTO non convertito prima di questa scadenza è escluso dall'ecosistema EQTY, e l'offerta finale di $EQTY sarà inferiore all'offerta originale di LTO.
Il contratto del token è deliberatamente minimale. Segue l'interfaccia standard ERC-20, senza logica di trasferimento speciale, funzionalità di airdrop o programmi di vesting.
Il token $EQTY sarà utilizzato per pagare le tariffe di ancoraggio, partecipare alla governance del protocollo e potenzialmente supportare ulteriori ruoli di utilità man mano che la piattaforma evolve. L'utilità richiede che i token vengano bruciati, riducendo l'offerta totale.
3. Contratto Anchor su Base
L'ancoraggio sarà eseguito tramite un contratto intelligente leggero distribuito sulla rete Base. Questo contratto emette eventi che registrano pubblicamente l'hash delle catene di eventi o dei messaggi, senza memorizzare alcuno stato on-chain.
Ogni ancoraggio mappa una chiave a un valore, dove:
Per catene di eventi: chiave = stateHash, valore = eventHash
Per messaggi: chiave = messageHash, valore = 0x0
Interfaccia
struttura Anchor {
chiave bytes32;
valore bytes32;
}
funzione anchor(Anchor[] calldata anchors) esterna;
evento Ancorato(
chiave indexed bytes32,
valore bytes32,
indirizzo mittente indicizzato,
uint64 timestamp
);
Comportamento
Il contratto emette un evento Ancorato per ogni coppia (chiave, valore).
Il timestamp attuale del blocco è incluso nell'evento come campo separato per comodità e auditabilità.
Nessuno stato è memorizzato nel contratto. Tutti i dati di ancoraggio sono registrati solo tramite log.
Il contratto è permissionless — chiunque può ancorare.
Questi eventi sono progettati per essere indicizzabili e accessibili da:
Componenti interni, come l'indicizzatore oBridge e la piattaforma EQTY
Servizi esterni, tra cui The Graph, Infura o verificatori personalizzati
Mantenendo l'ancoraggio senza stato ed emettendo eventi completi, questo design garantisce che l'ancoraggio sia verificabile, efficiente e indipendente dall'infrastruttura.
Meccanismo delle tariffe
I client devono chiamare approve() sul contratto ERC20 per abilitare l'ancoraggio
Ogni ancoraggio comporta una combustione di $EQTY, applicata nella funzione anchor()
L'importo della tariffa viene letto da un contratto di configurazione controllato dalla governance separata
L'ancoraggio non utilizzerà approve() ma invece brucerà tramite eqtyToken.burnFrom(msg.sender, fee * n)
4. Governance delle tariffe
Per mantenere l'ancoraggio economicamente sostenibile e giusto nel tempo, la tariffa pagata in $EQTY per ancoraggio deve essere regolabile. Anziché codificare a mano una tariffa statica o fare affidamento su oracoli di prezzo, EQTY utilizzerà un modello di governance on-chain per controllare questo parametro in modo trasparente e decentralizzato.
Un contratto di configurazione dedicato memorizzerà la tariffa di ancoraggio corrente. Questo valore può essere aggiornato solo da un contratto di governance — specificamente, un'istanza del Governatore di OpenZeppelin legato al token $EQTY. I voti saranno espressi in base ai saldi di $EQTY utilizzando la logica standard di ERC20Votes.
Il contratto di ancoraggio legge la tariffa corrente dal contratto di configurazione ogni volta che viene chiamato anchor(). Brucia quindi l'importo appropriato di $EQTY direttamente dal saldo del mittente. Questo approccio evita la necessità di transazioni di approve() e garantisce che il contratto di ancoraggio rimanga leggero e senza stato oltre all'applicazione della tariffa.
Il modello di governance consente alla comunità di adattare le tariffe nel tempo in risposta alle condizioni di mercato, alle fluttuazioni del prezzo del token o ai cambiamenti nella domanda di ancoraggio — senza fare affidamento su fonti di dati esterne o su un controllo centralizzato.
5. Nuova libreria Layer Privata
Per supportare l'ancoraggio su Base e la firma nativa del wallet, sarà creata una nuova libreria TypeScript autonoma per gestire la logica del layer privato — comprese le catene di eventi, la firma degli eventi, l'ancoraggio e le strutture dei messaggi relay. Questa libreria sostituisce l'@ltonetwork/lto-api.js specifico per LTO per tutti i casi d'uso di EQTY.
La nuova libreria è progettata per essere utilizzata sia in ambienti browser (ad es. MetaMask, WalletConnect) che in strumenti server-side.
Ambito e contenuti
Solo i componenti rilevanti del layer privato LTO saranno inclusi:
eventi/ Include Event, EventChain, MergeConflict e logica di serializzazione correlata.
messaggio/ Include Message e Relay, utilizzati per la comunicazione crittografata off-chain.
Codice di supporto Include classi utilitarie come Binary.
La libreria non avrà dipendenze dalla Rete LTO:
Nessuna API del nodo LTO
Nessuna logica di transazione
Nessun strumento di generazione di coppie di chiavi
Nessuna codifica di indirizzi specifica per LTO
Supporterà l'ancoraggio tramite contratti intelligenti su Base e si integrerà facilmente con ethers.js per la firma e l'invio di ancore.
Modello di firma dell'evento
Il metodo Event.signWith() sarà reso asincrono per supportare la firma basata su browser tramite MetaMask, WalletConnect o qualsiasi firmatario esterno, oltre alla firma direttamente con ethers. Utilizza un'interfaccia ISigner astratta:
interfaccia ISigner {
sign(data: Uint8Array): Promise<Uint8Array>;
}
L'evento firmato non richiede più una chiave pubblica; include solo la firma e l'indirizzo derivato. Questo lo rende compatibile con i flussi di firma Ethereum (personal_sign) ed elimina la necessità di estrarre chiavi pubbliche, il che non è possibile nella maggior parte degli ambienti wallet.
Integrazione dell'ancoraggio
La libreria include un metodo per generare mappe di ancoraggio:
const anchors = chain.from(lastKnownEvent.hash).getAnchorMap();
Ogni ancoraggio mappa uno stateHash (chiave) a un lastEventHash (valore), pronto per essere inviato al contratto intelligente di Base. Per i messaggi relay, l'hash del messaggio stesso è utilizzato come chiave dell'ancora e il valore è impostato a zero (0x0).
L'ancoraggio può essere eseguito chiamando direttamente il contratto intelligente tramite ethers.Contract.anchor(Anchor[]). Questo evita la dipendenza da qualsiasi servizio backend o infrastruttura proprietaria.
Firma del messaggio
La libreria include anche classi per Messaggi e Relay per la comunicazione off-chain. Come gli eventi, i messaggi sono firmati in modo asincrono utilizzando l'interfaccia ISigner. Le firme sono sull'hash del messaggio, e non è inclusa alcuna chiave pubblica — viene utilizzato solo l'indirizzo derivato per la verifica.
Dopo la firma, l'hash del messaggio è ancorato on-chain tramite lo stesso contratto Anchor. Il formato è:
chiave = messageHash
valore = 0x0
Questo garantisce che i messaggi off-chain possano essere timestampati e verificati pubblicamente senza rivelare i loro contenuti. L'ancoraggio può essere effettuato dal mittente o dal servizio relay.
Distribuzione e utilizzo
La libreria sarà pubblicata come un pacchetto NPM separato. È destinata a essere il core condiviso utilizzato da:
Il wallet EQTY (per la firma di eventi e messaggi)
Il servizio relay (per il calcolo dell'hash e il parsing dei messaggi)
L'SDK degli Ownables (per la costruzione e la presentazione degli eventi)
Qualsiasi frontend o verificatore di terze parti
6. Indicizzazione oBridge
Il servizio oBridge sostituirà la sua attuale logica di indicizzazione basata su LTO con un nuovo indicizzatore che elabora eventi Ancorati emessi dal contratto di ancoraggio di Base.
Questo indicizzatore ascolta i log di ancoraggio su Base e mantiene un database locale dell'ancora più recente per chiave, che può rappresentare sia uno stato di catena di eventi che un hash di messaggio relay. Ogni voce include:
chiave: lo stato ancorato o l'hash del messaggio
valore: l'hash dell'evento corrispondente o 0x0
txHash, blockNumber, logIndex e mittente
Questi record sono esposti attraverso un'API HTTP pubblica. La struttura e il comportamento di questa API rimarranno compatibili con l'indicizzatore di ancoraggio LTO esistente, inclusa l'API GET /hash/verify, consentendo ai componenti EQTY esistenti di transitare con modifiche minime.
L'indicizzatore oBridge svolge due ruoli:
Come dipendenza interna per il servizio relay, che deve verificare che i messaggi siano stati ancorati prima di rilasciarli.
Come servizio di verifica pubblico per clienti esterni e wallet che desiderano controllare lo stato di ancoraggio senza interrogare direttamente Base.
Tutti i dati rimangono verificabili on-chain e i client possono bypassare oBridge se lo desiderano utilizzando eth_getLogs o il proprio indicizzatore.
7. Servizio Relay
Il servizio relay gestisce la consegna sicura di messaggi crittografati tra le parti. Per garantire che i messaggi siano autentici, timestampati e controllati in accesso, il servizio sarà aggiornato per supportare sia la convalida di ancoraggio on-chain che l'autenticazione moderna, nativa del wallet, utilizzando il Sign-In with Ethereum (SIWE).
Autenticazione del messaggio con SIWE
Invece di fare affidamento su firme di messaggi HTTP o sfide personalizzate, il relay implementerà lo standard SIWE (EIP-4361). Questo approccio consente agli utenti di autenticarsi firmando un messaggio di testo standard con il proprio wallet Ethereum, producendo una firma recuperabile che li vincola a una sessione.
Flusso di accesso:
Il client richiede un messaggio SIWE dal backend relay: GET /auth/siwe-message?address=0x...
Il server restituisce un messaggio SIWE standard che include:
Dominio (ad es. relay.eqty.network)
Nonce
Timestamp di scadenza
Campo risorse opzionale limitato a /messages?to=...
Dichiarazione: ad es. “Accedi per accedere ai tuoi messaggi EQTY.”
Il client firma il messaggio utilizzando personal_sign
Il client invia il messaggio firmato e la firma a POST /auth/verify
Il server verifica la firma e rilascia:
Un token di accesso JWT (a breve termine, ad es. 15 minuti)
Un token di aggiornamento (a lungo termine, ad es. 24 ore)
Tutte le richieste successive di recupero messaggi (GET /messages?to=...) devono includere il token di accesso nell'intestazione Authorization.
Quando il token scade, il client può utilizzare il token di aggiornamento per ottenere un nuovo token di accesso senza dover firmare di nuovo.
Questo modello è completamente compatibile con MetaMask, WalletConnect e altri wallet EIP-1193, e segue modelli di sicurezza ampiamente adottati. Non è necessaria alcuna logica personalizzata o infrastruttura oltre alle librerie SIWE esistenti.
Ancoraggio e verifica dei messaggi
In aggiunta all'autenticazione, il servizio relay convaliderà che ogni messaggio è stato ancorato on-chain prima di consegnarlo. L'ancoraggio fornisce immutabilità, timestamping e previene attacchi di spam o replay.
Il relay mantiene il proprio indicizzatore leggero per il contratto di ancoraggio su Base. Ascolta gli eventi Ancorati e registra:
chiave = messageHash
valore = 0x0
mittente
blockNumber, txHash, timestamp
Per verificare un messaggio prima della consegna, il relay controlla che:
Un evento Ancorato esiste con chiave = messageHash
Il valore è esattamente 0x0 (cioè non è un'ancora di catena di eventi)
Il mittente corrisponde al firmatario del messaggio (cioè dall'indirizzo)
Solo dopo un ancoraggio riuscito il messaggio viene rilasciato al destinatario. Questo garantisce che tutti i messaggi siano pubblicamente verificabili, timestampati su Base e ancorati dalla giusta identità.
Il relay esegue questa verifica utilizzando il proprio indicizzatore interno e non si basa su oBridge.
8. Modifiche al Contratto Ownable (CosmWasm)
Con la migrazione lontana da LTO Layer 1 e la deprecazione della firma di eventi basata su chiave pubblica, i contratti Ownable devono essere aggiornati per supportare l'autorizzazione basata su indirizzo utilizzando indirizzi Ethereum standard.
Autorizzazione basata su indirizzo
In precedenza, la verifica della proprietà si basava sul recupero e sul confronto delle chiavi pubbliche estratte dagli eventi firmati. Poiché i wallet Ethereum non espongono chiavi pubbliche, e le firme ora utilizzano personal_sign (recuperabili a un indirizzo), il modello di verifica deve spostarsi al confronto diretto degli indirizzi.
La logica del contratto aggiornata utilizza info.sender — l'indirizzo che ha firmato e inviato l'evento — come identità autorevole.
Questo influisce su tutti i punti di ingresso in cui è richiesta l'autorizzazione:
try_transfer: il mittente deve corrispondere all'attuale indirizzo del proprietario
try_release: il mittente deve corrispondere all'indirizzo del proprietario precedentemente bloccato
try_register_lock: verifica che il campo proprietario dell'evento corrisponda al firmatario
Invece di convertire le chiavi pubbliche in indirizzi LTO, il contratto semplicemente memorizza e confronta i valori Addr (ad es. 0xabc123...).
CAIP-2 e corrispondenza della rete
Il contratto continua a convalidare l'origine degli eventi cross-chain utilizzando l'identificatore di rete CAIP-2. Per messaggi basati su Ethereum, il namespace è eip155:<chainId>. Il contratto verifica che:
L'evento.network corrisponde alla rete prevista
Il campo del proprietario nell'evento corrisponde al firmatario (info.sender) sotto il dato namespace CAIP
Le funzioni di conversione address_lto() e address_eip155() possono essere rimosse, poiché non è più necessaria alcuna traduzione da o verso gli indirizzi LTO.
Impatto
Questa modifica rende il contratto Ownable:
Completamente compatibile con la firma e l'identità native di Ethereum
Indipendente dall'infrastruttura delle chiavi LTO
Compatibile con qualsiasi catena che supporti il recupero basato su indirizzo (ad es., EVM)
Gli Ownables esistenti, che si basano sulla firma e sull'ancoraggio specifici per LTO, diventeranno non verificabili secondo il nuovo modello e devono essere riemettere (vedi Sezione 11).
9. Aggiornamento dell'SDK degli Ownables
L'SDK degli Ownables deve essere aggiornato per riflettere il passaggio dalla firma di chiavi pubbliche basata su LTO all'autorizzazione basata su indirizzo in stile Ethereum e all'ancoraggio su Base.
Aggiornamenti chiave
Firma dell'evento
Aggiornare la creazione di eventi per utilizzare la nuova libreria di layer privato (@eqty-core/events)
Utilizzare implementazioni ISigner compatibili con MetaMask, WalletConnect o firmatari basati su ethers
Assicurarsi che signWith() non si basi più su una chiave pubblica; viene utilizzato solo l'indirizzo recuperabile
Ancoraggio
Sostituire la logica di ancoraggio del nodo LTO con la presentazione di contratti intelligenti su Base
Utilizzare getAnchorMap() per raccogliere coppie (chiave, valore) e presentarle tramite ethers.Contract.anchor()
Assicurarsi che l'ancoraggio del messaggio utilizzi (chiave = messageHash, valore = 0x0)
Verifica
Aggiornare la logica di verifica per utilizzare l'API /hash/verify compatibile con oBridge o una query di log diretta
Confermare che il valore di ancoraggio corrisponde all'hash dell'evento previsto e che il mittente corrisponde all'indirizzo Ethereum del firmatario
Utilizzo degli indirizzi
Sostituire qualsiasi logica che confronta o genera indirizzi LTO
Utilizzare indirizzi Ethereum semplici (0x...) in tutto il flusso di eventi e messaggi
Compatibilità
L'SDK aggiornato rimane strutturalmente simile ma non è più legato alla libreria @ltonetwork/lto-api.js o ai servizi nodali LTO. È compatibile con la nuova libreria di layer privato e l'ancoraggio su Base, e interagirà con i contratti Ownable aggiornati e il servizio relay.
10. Aggiornamento del wallet universale
Il wallet universale deve essere aggiornato per riflettere la migrazione a Base e la nuova architettura EQTY. Non interagisce più con i nodi LTO.
Aggiornamenti core
Connessione del wallet
Sostituire la gestione delle coppie di chiavi LTO con una libreria compatibile con Ethereum (ethers.js)
Utilizzare interfacce provider EIP-1193 per abilitare la firma e il recupero degli indirizzi
Supporto per token
Aggiungere supporto per visualizzare e gestire i saldi del nuovo token $EQTY ERC-20 su Base
Includere metadati sui token, storia e tracciamento dei saldi tramite endpoint RPC pubblici
Firma di eventi e messaggi
Integrare la nuova libreria di layer privato per consentire agli utenti di creare e firmare catene di eventi e messaggi
Utilizzare personal_sign tramite il wallet connesso; le chiavi pubbliche non sono più necessarie
Ancoraggio
Inviare mappe di ancoraggio direttamente al contratto di ancoraggio di Base utilizzando ethers.js
Gestire la presentazione on-chain, la conferma e il feedback opzionale dell'interfaccia utente per il costo di ancoraggio in $EQTY
Integrazione del relay
Autenticarsi tramite SIWE (Sign-In with Ethereum)
Memorizzare e aggiornare i token di accesso secondo necessità
Utilizzare richieste autenticate per recuperare messaggi crittografati dal servizio relay
Funzionalità rimosse
Interfaccia utente di leasing LTO
Selezione dei nodi e vista della catena
Gestione dell'identità on-chain legata a LTO
11. Piano di migrazione
Con la deprecazione di LTO Layer 1 e l'introduzione di un nuovo sistema di ancoraggio su Base, tutti i componenti core del protocollo devono migrare. I dati legacy legati all'infrastruttura LTO — inclusi ancore, catene di eventi e messaggi — non saranno più validi.
Cosa diventa non valido
Le catene di eventi firmate utilizzando le coppie di chiavi LTO non possono essere verificate, poiché la chiave pubblica non può più essere estratta dalle firme basate su Ethereum.
Le ancore registrate su LTO L1 non possono essere fidate o interrogate in futuro.
Gli Ownables legati a identità basate su LTO o catene ancorate devono essere sostituiti.
Messaggi non ancorati su Base saranno rifiutati dal servizio relay.
Azioni richieste
Migrazione del tokenGli utenti devono scambiare manualmente i loro token LTO per $EQTY utilizzando il bridge. La minting è possibile solo fino a un'altezza di blocco specifica su Base. Dopo questo blocco, il bridge sarà chiuso e la funzione di minting disabilitata permanentemente. I token LTO non scambiati diventano privi di valore.
Riemettere Asset degli Ownables.I soggetti emittenti di Ownables devono emettere nuovi ownables legati alla rete BASE. Seguiranno istruzioni su come scambiare gli Ownables legacy con nuovi Ownables
Transizione del wallet Gli utenti dovranno aggiornare il Wallet Universale.
Nessuno snapshot
Non ci sarà alcuno snapshot, migrazione automatica o layer di compatibilità retroattiva. Ogni componente (eventi, messaggi, saldi dei token) deve essere ristabilito su Base attraverso le interfacce appropriate. Il nuovo protocollo è pulito per design e non preserva legami con LTO L1.