Fonte dell'articolo: GodRealmX
Autore: Shew, GodRealmX
Recentemente, Hyperliquid ha attirato molta attenzione sul mercato ed è uno dei più influenti exchange on-chain con libro ordini, con un TVL che ha superato i 2 miliardi di dollari. È stato definito "Binance on-chain" da Messari e ha persino riportato all'attenzione il discorso sul Layer3 e le catene di applicazione, che erano già svaniti dalla vista pubblica. Con il brillante risultato di un FDV salito a 30 miliardi di dollari entro un mese dal lancio del token, Hyperliquid ha attirato l'attenzione di utenti comuni e professionisti; nel frattempo, sono emersi anche molti rapporti su Hyperliquid, ma questi articoli si sono concentrati principalmente sulle caratteristiche della funzionalità del prodotto libro ordini e del meccanismo di trading, senza approfondire la sua struttura tecnica e i rischi di sicurezza.
L'autore di questo articolo mira a colmare questa lacuna, esaminando Hyperliquid puramente dal punto di vista della costruzione tecnica e della sicurezza, per aiutare più persone a comprendere la struttura e i principi di questo progetto stellare. Discuteremo la costruzione e i rischi del contratto del ponte cross-chain di Hyperliquid e la costruzione della doppia catena HyperEVM e HyperL1, per aiutare tutti a comprendere meglio l'architettura tecnica e le modalità di implementazione dietro di essa.
(Attualmente Hyperliquid occupa il 67% dell'offerta totale di USDC su Arbitrum)
Analisi del ponte cross-chain HyperLiquid
Poiché HyperLiquid non ha open source i componenti principali, ma ha reso open source i contratti del ponte correlati, abbiamo una migliore comprensione dei rischi associati al contratto del ponte. Hyperliquid ha distribuito un contratto del ponte su Arbitrum per memorizzare gli asset USDC depositati dagli utenti, possiamo osservare alcune delle azioni dei nodi Hyperliquid nel componente Bridge.
Collezione di Validatori
Dal punto di vista della classificazione dell'identità dei nodi, Hyperliquid ha 4 gruppi di validatori, rispettivamente hotValidatorSet, coldValidatorSet, finalizers e lockers, corrispondenti a diverse funzioni. Tra questi, il hotValidatorSet è utilizzato per rispondere alle operazioni di prelievo degli utenti e ad altre azioni ad alta frequenza, generalmente utilizzando portafogli caldi per rispondere rapidamente alle richieste di prelievo degli utenti di Hyperliquid.
Il coldValidatorSet è principalmente utilizzato per modificare la configurazione del sistema, come riscrivere l'elenco dei validatori del hotValidatorSet o dei locker, o gestire lo stato di blocco del contratto del ponte, e il coldValidatorSet ha il potere di invalidare direttamente alcune richieste di prelievo.
I locker sono un gruppo di validatori con autorizzazioni speciali, simili a un "comitato di sicurezza" comunemente usato nei layer 2, che decidono tramite voto se sospendere il funzionamento del ponte cross-chain in determinate situazioni. Attualmente, il gruppo di locker del ponte Hyperliquid include 5 indirizzi, è sufficiente che 2 locker votino per sospendere l'esecuzione del contratto del ponte.
Per quanto riguarda i finalizers, essi sono in realtà anche un gruppo di validatori speciali, principalmente utilizzati per confermare le variazioni di stato del ponte cross-chain; a livello di contratto, ciò che devono confermare sono principalmente i depositi e i prelievi degli utenti. Il ponte cross-chain di Hyperliquid utilizza un meccanismo di "sottomissione-conferma"; ad esempio, dopo che l'utente ha avviato un prelievo, questo non verrà eseguito immediatamente, ma dovrà attendere un certo periodo di tempo (questo periodo è chiamato periodo di controversia). Dopo che il periodo di controversia è scaduto, i membri all'interno dei finalizers eseguiranno le transazioni di prelievo, e il prelievo può essere eseguito normalmente.
Se si verifica un problema con il ponte cross-chain, ad esempio, se una richiesta di prelievo richiede di prelevare più asset di quanto l'utente possieda effettivamente, i nodi Hyperliquid possono votare durante il periodo di controversia per sospendere l'esecuzione del contratto del ponte utilizzando i locker, oppure il coldValidatorSet può invalidare direttamente la richiesta di prelievo problematica.
Attualmente, ci sono solo 4 nodi validatori in Hyperliquid, quindi hotValidatorSet e coldValidatorSet corrispondono a soli 4 indirizzi sulla catena. Durante l'inizializzazione, Hyperliquid registra automaticamente gli indirizzi all'interno di hotValidatorSet come membri di lockers e finalizers, mentre coldValidatorSet è controllato ufficialmente da Hyperliquid, utilizzando portafogli freddi per memorizzare le chiavi.
Deposito
Il contratto del ponte di Hyperliquid utilizza il metodo Permit di EIP-2612 per gestire le operazioni di deposito degli utenti, e all'interno del contratto del ponte è consentito depositare solo USDC come asset. Permit è più semplice rispetto al tradizionale modello Approve-Transfer e facilita il supporto per operazioni in blocco.
Il contratto del ponte di Hyperliquid utilizza la funzione batchedDepositWithPermit per elaborare in blocco più depositi, qui l'azione di deposito è piuttosto semplice, non ci sono rischi di sicurezza dei fondi, il processo di gestione è molto semplice, utilizzando solo il metodo Permit per ottimizzare l'UX.
Prelievo
Rispetto ai depositi, i prelievi sono un'operazione ad alto rischio, quindi la logica di prelievo è molto più complessa rispetto ai depositi. Quando un utente avvia una richiesta di prelievo, i nodi Hyperliquid chiameranno la funzione batchedRequestWithdrawals del contratto del ponte. In questo momento, il contratto del ponte richiederà che ogni richiesta di prelievo soddisfi il peso delle firme di 2/3 del hotValidatorSet, si noti che molti documenti descrivono questo come "raccogliere 2/3 delle firme", ma in realtà il contratto del ponte verifica il "peso delle firme di 2/3". Attualmente, HyperLiquid ha solo 4 nodi con lo stesso peso, quindi il controllo del peso delle firme coincide temporaneamente con il controllo del numero di firme, ma in futuro, HyperLiquid potrebbe introdurre nodi con un peso maggiore.
Dopo aver avviato una richiesta di prelievo, il ponte cross-chain non trasferirà immediatamente gli USDC controllati dal contratto, ma ci sarà un periodo di "controversia", simile al "periodo di sfida" nei protocolli di prova di frode. Attualmente, il periodo di controversia del contratto del ponte Hyperliquid è di 200 secondi, durante il quale possono verificarsi due situazioni:
1. I locker ritengono che l'attuale richiesta di prelievo presenti gravi problemi, in questo caso possono votare per sospendere/congelare il contratto;
2. I nodi ritengono che alcune azioni di prelievo presentino problemi; in questo caso, i membri del coldValidatorSet possono chiamare la funzione invalidateWithdrawals per rendere quel prelievo non valido.
Se durante il periodo di controversia non ci sono problemi, al termine del periodo di controversia, i membri all'interno dei finalizers possono chiamare la funzione batchedFinalizeWithdrawals del contratto del ponte per finalizzare lo stato finale; solo dopo l'attivazione di questa funzione gli USDC verranno inviati all'indirizzo del wallet dell'utente su Arbitrum.
Quindi, dal punto di vista del modello di sicurezza, se un attaccante malintenzionato desidera manipolare il processo di prelievo di Hyperliquid, deve superare tre linee di difesa:
1. Possedere oltre 2/3 del peso delle firme nel hotValidatorSet, in altre parole, ottenere un certo numero di chiavi private o cospirare; attualmente, HyperLiquid ha solo 4 validatori, quindi la possibilità di essere controllati o cospirati dall'attaccante non è bassa;
2. Durante il periodo di controversia, gli attaccanti dovrebbero evitare che le loro transazioni malevole vengano scoperte, poiché, una volta scoperte, è probabile che i locker intervengano per bloccare il contratto. Discuteremo questa parte più avanti.
3. Ottenere la chiave privata di almeno un membro dei finalizers, per far sì che le proprie azioni di prelievo vengano confermate definitivamente. Attualmente, i membri dei finalizers sono praticamente gli stessi dei membri del hotValidatorSet, quindi se l'attaccante soddisfa la condizione 1 sopra, soddisferà automaticamente anche la condizione 3.
Blocco del contratto del ponte
Abbiamo menzionato più volte in precedenza che Hyperliquid ha impostato una funzione di blocco per il contratto del ponte cross-chain. In particolare, il blocco del ponte cross-chain richiede che i membri dei locker chiamino la funzione voteEmergencyLock all'interno del contratto del ponte cross-chain per votare; attualmente, quando 2 membri dei locker chiamano questa funzione e votano, il contratto del ponte cross-chain verrà bloccato e sospeso.
Tuttavia, è importante notare che il ponte cross-chain di HyperLiquid offre anche la funzione unvoteEmergencyLock, che consente ai membri dei locker di revocare il voto. Una volta che il contratto del ponte cross-chain è stato bloccato con successo, può essere sbloccato solo attraverso una funzione chiamata emergencyUnlock, richiedendo di raccogliere oltre 2/3 del peso delle firme dei membri del coldValidatorSet.
La funzione emergencyUnlock, oltre a sbloccare, inserirà anche nuovi indirizzi di validatori hotValidatorSet e coldValidatorSet, aggiornandoli immediatamente.
Aggiornamento della collezione di validatori
Rispetto a tentare di superare le difese esistenti nel processo di prelievo, una strategia di attacco migliore è quella di utilizzare direttamente la funzione updateValidatorSet per aggiornare la collezione di validatori hotValidatorSet e coldValidatorSet. Questo richiede che il chiamante fornisca le firme di tutti i membri del hotValidatorSet e che l'operazione abbia un periodo di controversia di 200 secondi.
Al termine del periodo di controversia, i membri dei finalizers devono chiamare la funzione finalizeValidatorSetUpdate per completare l'aggiornamento finale dello stato.
Fino ad ora, abbiamo presentato gran parte dei dettagli del ponte cross-chain Hyperliquid. Questo articolo non ha trattato la logica di aggiornamento dei locker e dei finalizers, il cui aggiornamento richiede la firma del hotValidatorSet, mentre la rimozione di un membro richiede la firma del coldValidatorSet.
In sintesi, il contratto del ponte di Hyperliquid presenta i seguenti rischi:
1. I hacker che controllano il coldValidatorSet possono ignorare qualsiasi ostacolo per rubare gli asset degli utenti. Poiché il coldValidatorSet ha l'autorizzazione per operare la funzione emergencyUnlock, può invalidare le azioni di blocco del contratto dei locker e può aggiornare immediatamente l'elenco dei nodi. Attualmente, Hyperliquid ha solo 4 nodi validatori, quindi la possibilità di furto delle chiavi private non è bassa;
2. I finalizers rifiutano di confermare definitivamente le transazioni di prelievo degli utenti, avviando attacchi di revisione; in questo caso, gli asset degli utenti non verranno rubati, ma potrebbero non essere prelevati dal contratto del ponte;
3. I locker maliziosamente bloccano il ponte cross-chain, in questo caso tutte le transazioni di prelievo non possono essere eseguite e si deve attendere lo sblocco da parte del coldValidatorSet;
Architettura di interazione tra HyperEVM e doppia catena
Per rendere le transazioni dell'ordine programmabili, ad esempio introducendo transazioni riservate che richiedono contratti intelligenti per essere implementate, Hyperliquid ha lanciato una soluzione chiamata HyperEVM. Rispetto all'EVM tradizionale, HyperEVM ha due vantaggi speciali: primo, HyperEVM può leggere lo stato del libro ordini di HyperLiquid; secondo, i contratti intelligenti all'interno di HyperEVM possono interagire con il sistema di ordini di Hyperliquid, ampliando notevolmente gli scenari di applicazione di Hyperliquid.
Facendo un semplice esempio, se un utente desidera garantire la riservatezza delle operazioni di ordine, può applicare un livello di riservatezza tramite contratti intelligenti simili a Tornado Cash su HyperEVM e poi attivare azioni di ordine nel sistema di ordini di HyperLiquid tramite interfacce specifiche.
Prima di presentare HyperEVM, è necessario introdurre l'architettura speciale preparata da Hyperliquid per HyperEVM. Poiché Hyperliquid ha un sistema di ordine personalizzato ad alte prestazioni, la velocità di elaborazione delle transazioni nell'ambiente EVM è molto più lenta. Per evitare che la velocità di lavoro del sistema di ordine rallenti, Hyperliquid ha utilizzato una "soluzione a doppia catena", che consiste nel far funzionare simultaneamente due blockchain a livello software sui dispositivi dei nodi Hyperliquid, con ogni nodo che memorizza localmente i dati di entrambe le catene e gestisce separatamente le transazioni di entrambe le catene.
Hyperliquid ha impostato una catena dedicata per il suo sistema di ordine personalizzato, e ha anche aggiunto una catena compatibile con EVM (HyperEVM). I dati di queste due catene vengono diffusi tra il gruppo di nodi tramite lo stesso protocollo di consenso, esistendo come uno stato unificato, ma funzionando in ambienti di esecuzione diversi. Chiamiamo la catena dedicata agli ordini Hyperliquid L1 (L1), questa catena è di tipo autorizzato; mentre la catena utilizzata per HyperEVM è HyperEVM (EVM), questa catena è senza autorizzazione, chiunque può distribuire contratti, e questi contratti possono accedere alle informazioni all'interno di L1 tramite codice precompilato.
È importante notare che la velocità di generazione dei blocchi di Hyperliquid L1 è superiore a quella della catena HyperEVM, ma questi blocchi verranno comunque eseguiti in ordine. I contratti sulla catena EVM possono leggere i dati dai blocchi L1 precedenti e scrivere dati nei futuri blocchi L1. Come mostrato nell'immagine:
Per consentire l'interazione tra HyperL1 e HyperEVM, Hyperliquid ha utilizzato due tecnologie: Precompilati e Eventi.
Precompilati
Il cosiddetto precompilato (Precompiles) significa semplicemente implementare alcune operazioni complesse e difficili da realizzare nei contratti intelligenti direttamente a livello di base, spostando i flussi di calcolo problematici e non amichevoli per Solidity all'esterno dei contratti intelligenti convenzionali. Questo tipo di codice precompilato può essere realizzato in linguaggi più vicini all'hardware come C, C++.
L'approccio precompilato consente a EVM di supportare funzionalità più avanzate e complesse, facilitando le esigenze degli sviluppatori di contratti intelligenti. Nella sua forma, il precompilato è essenzialmente un insieme di contratti intelligenti speciali, altri contratti intelligenti possono chiamare direttamente questi contratti speciali, passando parametri e ottenendo i risultati di esecuzione precompilati. Attualmente, il comando ecRecover è implementato all'interno di EVM tramite precompilati per verificare se la firma secp256k1 è corretta, e tale comando si trova all'indirizzo 0x01.
L'uso di precompilati per aggiungere alcune funzionalità speciali è la prassi attuale, ad esempio, Base ha aggiunto il codice precompilato P256 per facilitare le operazioni di autenticazione WebAuth degli utenti.
(Questa immagine proviene dal sito Rollup Codes)
In linea con le attuali soluzioni prevalenti, anche HyperEVM ha aggiunto una serie di codice precompilato per implementare la lettura dello stato del sistema di ordini di Hyperliquid. Attualmente, un indirizzo di codice precompilato noto di Hyperliquid è 0x0000000000000000000000000000000000000800, che può leggere la situazione delle posizioni dei contratti perpetui degli utenti nell'ultimo blocco L1.
Eventi
Come accennato in precedenza, HyperEVM può scrivere dati nel blocco HyperL1, e il comportamento di scrittura si basa sugli eventi. Gli eventi sono un concetto nativo all'interno di EVM, consentendo ai contratti intelligenti di inviare informazioni di log all'esterno (come applicazioni frontend o ascoltatori) durante l'esecuzione, facilitando il monitoraggio della situazione operativa del contratto intelligente.
Ad esempio, quando un utente utilizza la funzione di trasferimento di token dei contratti ERC-20, il contratto emetterà l'evento Transfer corrispondente, per consentire a browser di blocco e altre applicazioni frontend di conoscere lo stato del trasferimento di token. Queste informazioni sugli eventi saranno incluse nel blocco, e ci sono molte soluzioni mature per ascoltare e recuperare i log degli eventi.
Attualmente, molti scenari relativi al cross-chain utilizzano eventi per trasmettere parametri cross-chain, ad esempio, nel contratto del ponte distribuito su Ethereum Mainnet di Arbitrum, gli utenti possono chiamare funzioni correlate per emettere eventi che attivano transazioni su Arbitrum.
Le informazioni note indicano che i nodi HyperLiquid ascolteranno
0x3333333333333333333333333333333333333333 (indirizzo evento) emette eventi, e tramite le informazioni contenute negli eventi si può comprendere l'intenzione dell'utente e tradurla in azioni di transazione, scrivendola nei futuri blocchi Hyperliquid L1.
Ad esempio, l'indirizzo dell'evento sopra menzionato fornirà una funzione che, quando l'utente chiama questa funzione, l'indirizzo dell'evento emetterà un evento chiamato IocOrder. Quando viene generato un blocco Hyper L1, i nodi HyperLiquid interrogheranno prima gli eventi emessi dall'indirizzo dell'evento più recente all'interno di HyperEVM: quando viene recuperato un nuovo evento IocOrder, verrà convertito in un'operazione di ordine in sospeso all'interno di Hyper L1.
HyperBFT
A livello di protocollo di consenso, Hyperliquid utilizza un protocollo chiamato HyperBFT, che è un metodo derivato basato su HotStuff. Attualmente, HotStuff-2 è uno dei protocolli di consenso più recenti e con la complessità più bassa.
Secondo le informazioni, inizialmente HyperLiquid utilizzava l'algoritmo di consenso Tendermint, che è l'algoritmo di consenso predefinito all'interno del sistema Cosmos, ma questo algoritmo ha un'efficienza relativamente bassa e richiede lo scambio di messaggi All-to-All in ogni fase, dove ogni nodo deve inviare messaggi a tutti gli altri nodi, con una complessità di comunicazione di O(n²), dove n è il numero di nodi.
Se viene utilizzato Tendermint, Hyperliquid può elaborare al massimo 20.000 ordini al secondo. Per raggiungere la velocità degli exchange centralizzati, il team di HyperLiquid ha sviluppato l'algoritmo HyperBFT basato su HotStuff, implementato in Rust, teoricamente capace di elaborare fino a 2 milioni di ordini al secondo.
L'immagine sottostante mostra il modo in cui avviene la comunicazione nel consenso HyperBFT in assenza di parallelismo; si può notare che tutti i messaggi vengono riassunti dal Leader e inviati in modo uniforme, eliminando il passaggio di scambio di messaggi tra i nodi, riducendo significativamente la complessità.
In breve, HyperBFT è un protocollo di consenso in cui l'attuale leader genera un blocco, tutti i nodi partecipano al voto e inviano i risultati del voto al Leader, prima di far ruotare il leader successivo. In realtà, i dettagli specifici coinvolti in HotStuff e Tendermint sono molto più complessi, e questo articolo, per motivi di spazio e focalizzazione, non si sofferma su di essi.
Punti chiave da tenere a mente per gli sviluppatori
Il meccanismo di lettura dei dati basato su precompilati sopra è piuttosto perfetto; gli sviluppatori Solidity non devono scrivere codice specifico per leggere lo stato di Hyper L1, ma devono prestare attenzione alla questione di msg.sender. Come la maggior parte dei layer 2 di Ethereum, HyperLiquid consente anche agli utenti di interagire direttamente con i contratti di sistema all'interno di Hyper L1, innescando indirettamente azioni di transazione sulla catena HyperEVM; in questo caso, se il contratto intelligente legge il campo msg.sender all'interno di questa transazione, scoprirà che msg.sender corrisponde all'indirizzo del contratto di sistema di HyperL1, e non all'indirizzo dell'utente che ha inizialmente avviato la transazione su HyperL1.
Per quanto riguarda l'interazione tra EVM e L1, gli sviluppatori devono prestare attenzione a una serie di problemi. Il primo problema è la non atomicità dell'interazione: se un utente effettua un ordine indiretto su L1 tramite l'indirizzo dell'evento sopra menzionato, ma non ci sono asset sufficienti su L1, la transazione fallirà sicuramente, ma non ci sarà alcun messaggio di errore al momento della chiamata della funzione dell'indirizzo dell'evento. La non atomicità dell'interazione potrebbe portare a danni agli asset dell'utente. In questo caso, gli sviluppatori devono gestire manualmente il fallimento dell'ordine sul lato del contratto intelligente EVM. Inoltre, i contratti intelligenti all'interno di EVM dovrebbero avere una funzione per il recupero finale dei fondi, per evitare che gli asset degli utenti non possano mai essere ritirati da L1.
In secondo luogo, l'indirizzo del contratto corrispondente all'EVM deve avere un account mappato su L1. Quando un utente completa la distribuzione del contratto intelligente all'interno dell'EVM, deve trasferire una piccola quantità di USDC all'indirizzo mappato su L1, costringendo L1 a creare un account per l'indirizzo del contratto. Questa operazione potrebbe essere correlata al consenso di base di HyperLiquid, come specificato nella documentazione di Hyperliquid.
Infine, gli sviluppatori devono prestare attenzione ad alcune situazioni speciali, in particolare alla situazione del saldo dei token. Hyper L1 ha un indirizzo speciale per il trasferimento di asset, ma quando gli utenti inviano asset a tale indirizzo speciale, questi passano da L1 alla catena HyperEVM. Poiché i nodi HyperLiquid eseguono effettivamente simultaneamente la catena EVM e la catena L1, potrebbe verificarsi che, dopo che l'utente ha trasferito asset, l'HyperEVM non generi blocchi per un lungo periodo; in questo caso, l'utente non sarà in grado di visualizzare il proprio saldo sulla catena EVM.
In parole povere, gli asset degli utenti sono bloccati nel ponte cross-chain, e non possono essere verificati né su L1 né sulla catena EVM. I protocolli costruiti dagli sviluppatori dovrebbero gestire queste situazioni speciali per evitare che gli utenti provino panico.
In sintesi, HyperEVM è simile a un layer 2 basato su Hyperliquid L1; HyperEVM si basa sul codice precompilato per leggere lo stato di L1 e anche sugli eventi per interagire con Hyper L1. L1 ha anche alcuni contratti di sistema che aiutano gli utenti a innescare transazioni all'interno di HyperEVM o a gestire il cross-chain degli asset. Tuttavia, a differenza della normale architettura Layer1-Layer2, Hyperliquid fornisce una maggiore interoperabilità per HyperEVM.
Fonti di riferimento
Hyperliquid: Il L1 dell'Ordine Superottimizzato
hyperliquid-dex/contracts
La guida non definitiva ai precompilati di Hyperliquid.
Qual è la differenza tra PBFT, Tendermint, HotStuff e HotStuff-2?