Un operatore di nodi pubblica una lettera aperta di preoccupazione mentre l’API centralizzata di Hyperliquid scatena polemiche

Titolo dell’articolo originale: Una lettera al team principale di Hyperliquid
Autore dell’articolo originale: Kam Benbrik, ricercatore presso Chorus One
Traduzione dell’articolo: Ashley, BlockBeats

Nota della redazione: l’operatore di nodi Chorus One ha illustrato in una lettera aperta pubblicata sulla piattaforma X diversi problemi della testnet di Hyperliquid, tra cui frequenti arresti dei nodi, difficoltà operative dovute al codice closed source e rischi di centralizzazione causati da un singolo punto di errore nell’API. Ha proposto vari suggerimenti per migliorare la trasparenza e la decentralizzazione della blockchain. In risposta a queste preoccupazioni, il fondatore di Hyperliquid, Jeff, ha replicato sottolineando che i criteri di selezione dei validatori sono stati delineati in un annuncio; anche l’account ufficiale di Hyperliquid ha pubblicato un articolo separato sulla piattaforma X, rispondendo alle questioni sollevate nella lettera e affermando che il codice dei nodi sarà reso open source in condizioni di sicurezza.

Di seguito il contenuto originale (con lievi modifiche per migliorarne la leggibilità):

La seguente lettera è indirizzata da Chorus One al team di ingegneria di @HyperliquidX, nella speranza che il team trovi il tempo di esaminare questo feedback sulla gestione della blockchain Hyperliquid.

In breve

· A causa del codice closed source, della mancanza di documentazione e della dipendenza da un’API centralizzata, i validatori devono affrontare sfide significative, che comportano frequenti sospensioni dei nodi e prestazioni instabili.

· Il meccanismo di incentivi della testnet ha favorito la compravendita di token HYPE sul mercato nero, avvantaggiando le transazioni con i grandi detentori invece di una selezione equa dei validatori.

· I bassi rendimenti per i validatori sulla mainnet non bastano a coprire gli elevati requisiti di staking autonomo, limitando la decentralizzazione, poiché 81% dello stake è controllato dai nodi della fondazione.

· Per competere con le principali blockchain layer 1, Hyperliquid deve migliorare la trasparenza, decentralizzare la delega dello stake, introdurre un meccanismo equo di selezione dei validatori e interagire maggiormente con i validatori esterni.

Seguo Hyperliquid sin da 12/2023 e considero la sua applicazione eccezionale. È facile da usare, offre un’esperienza utente eccellente e presenta alcune funzionalità uniche, come Vaults e il celebre HLP, che non si trovano altrove. Attualmente, HLP gestisce più di 3,5 mld $ in fondi e consente a chiunque di partecipare passivamente a Hyperliquid.

Dopo aver visto le eccellenti prestazioni della piattaforma e aver appreso che Hyperliquid opera in modo indipendente come blockchain layer 1, vorrei che Chorus One partecipasse come operatore sulla blockchain Hyperliquid. Lavoro per Chorus One, uno dei maggiori operatori di nodi del settore. Dal 2018, Chorus One è attiva nel settore Proof of Stake. Abbiamo collaborato con molti team di eccellenza, contribuito allo sviluppo di diversi design di blockchain e algoritmi di consenso e svolto ruoli chiave in alcune delle prime blockchain Proof of Stake, come Tezos e Cosmos Hub. Attualmente, Chorus One gestisce più di 50 blockchain, con un valore totale degli asset in staking superiore a 3 mld $, e collabora con tutte le principali blockchain Proof of Stake fin dalle prime fasi.

Dopo essere stata inserita nella whitelist il 17/10, Chorus One è entrata nella testnet di Hyperliquid. Vorrei condividere con il team di ingegneria di Hyperliquid la nostra esperienza complessiva sulla testnet: anche dopo quasi 3 mesi di attività, non abbiamo avuto l’opportunità di interagire con il team. In questo periodo abbiamo assistito a uno dei lanci di token di maggior successo del 2024, quello del token HYPE. Allo stesso tempo, abbiamo sperimentato un ambiente di testnet divertente ma impegnativo. Vorrei riportare alcune osservazioni chiave, nella speranza che vengano prese in considerazione nei prossimi giorni, settimane o mesi.

Esperienza sulla testnet

Finora l’esperienza sulla testnet è stata piuttosto impegnativa. Gli operatori di nodi hanno pochissime informazioni su come gestire un nodo e le risorse di riferimento disponibili sono molto limitate.

Frequente arresto dei nodi per cause poco chiare

Inizialmente, i nostri nodi sono stati fermati più volte senza che ne capissimo il motivo. Poiché il codice è closed source, non siamo riusciti a valutare correttamente le cause degli arresti. L’unica possibilità era comunicare con gli altri validatori su Discord e ipotizzare insieme le possibili ragioni. Dopo aver parlato con diversi validatori, abbiamo scoperto che anche i loro nodi venivano fermati ripetutamente e che nemmeno loro avevano le idee del tutto chiare sulle cause.

Problemi legati alla posizione del nodo

In seguito, abbiamo scoperto che il problema degli arresti poteva dipendere dal fatto che il nostro nodo non fosse stato implementato a Tokyo. Spostarlo a Tokyo avrebbe potuto essere utile. Purtroppo, il team non ce lo ha mai comunicato esplicitamente e lo abbiamo scoperto solo dopo aver riscontrato più volte dei problemi.

Dopo aver spostato il nodo a Tokyo, la situazione è migliorata. Potrebbe essere perché molti nodi della testnet con uno stake elevato si trovano anch’essi a Tokyo, consentendo al nostro nodo di recuperare parzialmente il ritardo e riducendo i blocchi persi. Tuttavia, anche dopo la migrazione continuiamo ad avere problemi di arresto e le cause specifiche restano poco chiare. Questa mancanza di comprensione dipende soprattutto dal fatto che il codice è closed source.

Dipendenza dagli script automatici di riattivazione

Riconosciamo che mantenere un buon uptime sulla testnet di Hyperliquid dipende dalla rapidità degli script che riattivano automaticamente i nodi. L’unico modo per migliorare l’uptime è affidarsi a script rapidi di riattivazione automatica. I validatori non possono comprendere appieno o risolvere i potenziali problemi e, in situazioni che non capiscono, possono solo riattivare i propri nodi alla cieca.

L’API centralizzata di Hyperliquid come singolo punto di errore

In alcune occasioni i nostri tentativi di riattivazione sono falliti perché l’API di Hyperliquid era fuori servizio. Poiché i validatori devono inviare richieste al server di Hyperliquid per riattivare i nodi, quando l’API non funziona non possono farlo autonomamente.

Il team potrebbe già esserne al corrente, ma questo design va rivisto perché rende l’API centralizzata un punto critico di errore nella rete. Se l’obiettivo è creare un sistema Byzantine Fault Tolerant, nessun nodo dovrebbe avere privilegi speciali, come la dipendenza da un’API centralizzata.

Selezione dei validatori sulla mainnet

Di recente Hyperliquid ha avviato un processo di decentralizzazione del proprio insieme di validatori, selezionandone circa 16. In precedenza, i validatori erano 4, gestiti dal team principale e oggetto di forti critiche. Di recente Hyperliquid ha compiuto un passo importante, ampliando l’insieme dei validatori da 4 a 16.

La selezione dei 4 validatori è stata annunciata nel seguente post su Discord:

I validatori sono Validao, Bharvest, Hypurrstake e Prrposefulnode. Sono stati selezionati in base al mantenimento di più di 90% uptime negli ultimi 7 o 30 giorni.

Si tratta di un risultato significativo sotto molti aspetti, soprattutto perché le prestazioni dei validatori sono ancora influenzate da fattori esterni, come i tempi di inattività dell’API di Hyperliquid, i problemi di riattivazione e i continui arresti dei file binari, tutti elementi che hanno un impatto non trascurabile sulle prestazioni.

Oltre ai 4 validatori selezionati in base alle prestazioni sulla testnet, sulla mainnet operano anche 5 validatori della Hyperliquid Foundation. Inoltre, sono stati scelti altri 7 validatori per partecipare alla mainnet, ma i motivi della loro selezione non sono stati resi pubblici.

Successivamente è nato un mercato nero per i token HYPE della testnet.

Inizialmente, la testnet di Hyperliquid aveva un insieme di 50 validatori. All’inizio, alcune entità specifiche venivano inserite nella whitelist per partecipare alla testnet, ma dal 12/12 l’insieme dei validatori è diventato completamente aperto.

Le condizioni erano semplici: per registrarsi come validatore servivano 10,000 token HYPE della testnet. Tuttavia, per diventare un validatore attivo era anche necessario rientrare tra i primi 50; altrimenti i validatori sarebbero rimasti inattivi.

Questa decisione ha provocato un’impennata del prezzo dei token HYPE della testnet. Inizialmente, il prezzo è salito a più di 3.000 USDC simulati e, pochi giorni dopo, ha persino superato i 28,000 USDC simulati. Al momento della stesura, il prezzo è di circa 700 USDC simulati per token.

Purtroppo, il faucet distribuisce solo 100 USDC simulati ogni 4 ore. Attualmente, per rientrare tra i primi 50 validatori della testnet servono più di 528.747 token HYPE della testnet. Ipotizzando un prezzo di 700 USDC simulati per token e affidandosi esclusivamente al faucet, il calcolo è il seguente:

Giorni = (528,747 × 700) ÷ (100 × 6) = 616,871.5 giorni

Ciò significa che affidarsi esclusivamente al faucet richiederebbe circa 616,871.5 giorni, ovvero 1,690 anni, per accumulare abbastanza token HYPE della testnet da diventare un validatore attivo su Hyperliquid.

Tuttavia, anche coloro che avevano ricevuto un airdrop di HYPE sulla mainnet hanno ricevuto la stessa quantità di token sulla testnet. Questo ha permesso ai validatori di collaborare con questi membri della community tramite lo staking dei token HYPE della testnet, garantendosi così l’accesso all’insieme dei validatori attivi.

Allo stesso tempo, questa situazione ha offerto un’altra prospettiva a chi deteneva token HYPE della testnet. Data la competizione per entrare nell’insieme dei validatori della testnet, molti validatori erano ansiosi di procurarsi quanti più token HYPE della testnet possibile. Di conseguenza, è nato un mercato nero in cui le balene in possesso di grandi quantità di token HYPE della testnet hanno iniziato a venderli ai validatori in cambio di USDC della mainnet.

Non avevo mai visto una situazione così caotica. Anche se il team di Hyperliquid non approva chiaramente queste pratiche, ha tutti gli strumenti per affrontare il problema. Una possibile soluzione è introdurre un adeguato processo di selezione dei validatori della testnet.

Nella maggior parte delle altre reti PoS, il team principale pubblica di solito un modulo che qualsiasi validatore può compilare per dichiarare la propria disponibilità a gestire la blockchain. Il team esamina quindi le candidature in base a diversi criteri, come l’esperienza dell’operatore nella gestione dei nodi, i contributi passati, il coinvolgimento nella community o altri fattori.

Questo gruppo di validatori preselezionati può quindi partecipare alla testnet, collaborare a stretto contatto con il team di ingegneria, fornire feedback e assicurarsi che tutto funzioni correttamente. Abbiamo provato più volte a fornire feedback, ma finora senza successo.

Mainnet e decentralizzazione

Come accennato in precedenza, l’attuale insieme di validatori della mainnet di Hyperliquid è composto da 16 validatori, consultabili al seguente URL: https://app.hyperliquid.xyz/staking

· 5 validatori appartengono alla Hyperliquid Foundation.

· 4 validatori sono stati selezionati in base alle prestazioni sulla testnet, mantenendo più di 90% uptime negli ultimi 7 giorni.

· 7 validatori sono stati scelti direttamente dal team di Hyperliquid.

Dei 404,495,250 token HYPE in staking, circa 329,578,724 sono messi in staking sui nodi della Foundation, pari a circa 81,4% dello stake totale. Sappiamo molto poco di HyperBFT, ma se ipotizziamo che funzioni come un sistema Byzantine Fault Tolerant, il presupposto fondamentale della maggior parte dei sistemi BFT è che non più di 33% del potere di voto si comporti in modo malevolo. Se una singola entità controlla 1/3 dello stake, può fermare la blockchain. Se ne controlla 2/3, ha il pieno controllo della rete.

Inizialmente, la Hyperliquid Foundation ha messo in staking 60mln token HYPE su ciascun nodo della Foundation. Tuttavia, anche molti detentori di HYPE hanno scelto di fare staking sui nodi della Foundation, cosa non ideale per la decentralizzazione. Il team dovrebbe interagire maggiormente con la community per incoraggiare una distribuzione dello staking più decentralizzata.

Esistono tre possibili soluzioni:

· Informare la community sull’importanza di fare staking con validatori esterni per rafforzare la sicurezza e la decentralizzazione della blockchain.

· Applicare una commissione dello 100% ai nodi della Foundation, così da incentivare gli utenti a fare staking con validatori esterni e promuovere la decentralizzazione.

· Riassegnare lo staking della Foundation a validatori esterni, una pratica comune in molte blockchain.

Decentralizzare lo staking a favore dei validatori esterni li aiuterà anche a raggiungere la sostenibilità economica. Hyperliquid è una blockchain focalizzata su un throughput elevato, in cui i costi dell’infrastruttura possono essere alti, soprattutto quando i nodi sono implementati a Tokyo. Attualmente, i validatori in fondo all’insieme guadagnano tra 3.000 $ e 5.000 $ all’anno, una cifra insufficiente a coprire i costi. La situazione è particolarmente impegnativa perché, per convalidare le transazioni sulla mainnet, devono mettere in staking autonomamente i 10,000 token HYPE iniziali (che al prezzo attuale valgono circa 250.000 $).

Attualmente, gli utenti interagiscono con Hyperliquid trasferendo USDC da Arbitrum alla blockchain Hyperliquid tramite bridge. Dall’esame del contratto del bridge, sembra che questo sia ancora gestito da 4 validatori. Tali validatori non sembrano essere collegati al consenso della blockchain né ai 16 validatori della mainnet.

Hyperliquid ha un ottimo prodotto, ma il team deve ancora apportare diversi miglioramenti all’infrastruttura per competere davvero con le principali blockchain layer 1. Alcuni interventi sono semplici, per esempio:

Chiedere il parere di validatori esperti che operano su più reti. L’attuale approccio del team, che lavora in autonomia, è stato molto efficace nel creare un prodotto sostenibile, ma i validatori sono un pilastro fondamentale di una blockchain layer 1. È altrettanto importante ascoltare il loro parere per assicurarsi che tutto funzioni correttamente.

Rendere il codice open source. Questo aiuterà i validatori a comprendere meglio i problemi che incontrano nella gestione di un nodo sulla L1 di Hyperliquid e aiuterà anche gli utenti a fidarsi del prodotto. Rendere il codice open source consentirà inoltre ai validatori di conoscere meglio l’architettura e l’algoritmo di consenso. Al momento le informazioni su HyperBFT sono molto limitate; l’apertura del codice può offrire la trasparenza e la comprensione di cui c’è tanto bisogno. Chorus One ha una guida di rete sull’importanza dell’open source. Gli operatori dovrebbero poter compilare dal codice sorgente tutti i software che gestiscono: https://handbook.chorus.one/node-software/open-source.html

Creare un processo adeguato di selezione dei validatori per impedire la compravendita sul mercato nero dei token HYPE della testnet. Selezionare i validatori in base all’uptime è un approccio equo, ma anche garantire un buon uptime dovrebbe essere un processo equo. Non dovrebbe dipendere dalla possibilità di avere contatti per ottenere token della testnet, dall’acquisto di tali token o da fattori esterni, come la dipendenza dall’API di Hyperliquid per mantenere un buon uptime.

Nel complesso, Hyperliquid non deve apportare molti cambiamenti per competere con le principali blockchain layer 1. Dovrebbe soprattutto interagire di più con le parti esterne e tenere conto dei loro feedback. Non vedo l’ora di assistere ai cambiamenti nelle prossime settimane e nei prossimi mesi; il nostro team sarà pronto a offrire supporto e feedback in qualsiasi momento.

Il fondatore di Hyperliquid Jeff e l’account ufficiale rispondono

In risposta a questa lettera, Jeff, fondatore di Hyperliquid, ha replicato sulla piattaforma X.

Ha sottolineato che gestire correttamente un validatore non è difficile: la chiave sta nella configurazione e nella specializzazione del validatore stesso. Ha inoltre precisato che i criteri di selezione dei validatori sono stati spiegati nell’annuncio e si basano sulle elevate prestazioni in termini di uptime registrate nelle prime fasi della testnet. Ciò indica che Jeff tende a ritenere che i problemi attuali derivino più dalla configurazione dei validatori stessi che da difetti nella progettazione del sistema.

Inoltre, il team ufficiale di Hyperliquid ha fornito ulteriori chiarimenti, affermando che il codice dei nodi sarà reso open source in modo sicuro.

· Tutti i validatori vengono selezionati in base alle prestazioni sulla testnet e non possono ottenere un posto acquistandolo; commenti infondati sminuiscono gli sforzi dei validatori che hanno dedicato tempo e impegno a comprendere il sistema; con la maturazione della blockchain, l’insieme dei validatori si amplierà gradualmente.

· Come annunciato in precedenza, sarà lanciato un programma di delega della Foundation per sostenere i validatori con le migliori prestazioni e decentralizzare ulteriormente la rete.

· Chiunque può gestire un server API che punti a qualsiasi nodo; il codice di esempio del client invia richieste a server API specifici, ma questo non è un requisito fondamentale della rete.

· È inaccettabile che gli utenti creino un mercato nero per i token HYPE della testnet; lo abbiamo già dichiarato più volte e continueremo a lavorare per migliorare il processo di accesso alla testnet.

· Il codice dei nodi è attualmente closed source; renderlo open source è molto importante e il progetto sarà pubblicato come open source una volta che lo sviluppo avrà raggiunto uno stato stabile; la velocità di sviluppo di Hyperliquid è di diversi ordini di grandezza superiore a quella della maggior parte dei progetti, e anche la sua portata è di diversi ordini di grandezza maggiore; il codice sarà reso open source in condizioni di sicurezza.

· Attualmente esiste un solo file binario. Anche in una rete matura come Solana, la stragrande maggioranza dei validatori utilizza un singolo client.

「Link all’articolo originale」