La ricerca afferma che la rete EOS può bloccarsi, Block.one nega qualsiasi errore

Nelle ultime settimane, gli utenti del protocollo blockchain EOS hanno riscontrato problemi periodici con l’accesso alla rete. Un recente articolo scritto da Dexaran, sviluppatore di contratti intelligenti pseudonimo e ingegnere della sicurezza, ha descritto l’apparente radice del problema: una tecnica poco costosa che consente agli hacker di “congestionare” la rete – o di metterla in una modalità a bassa efficienza – con solo pochi dollari di EOS.

Apparentemente, quell’exploit ha permesso a un hacker di rubare più di $ 110.000 in criptovaluta da un’applicazione di gioco d’azzardo EOS, EOSPlay, all’inizio di settembre. Tuttavia, i dirigenti della società madre di EOS, Block.one, non sono turbato, sostenendo che la rete funziona “correttamente”.

Nozioni di base su EOS: governance, picchettamento e modalità di congestione

EOS.io è un protocollo smart contract basato su blockchain per lo sviluppo e l’hosting di applicazioni decentralizzate (DApps). Utilizza un modello di consenso chiamato DPoS (delegated proof-of-stake) ed è regolato in conformità con l’Accordo con l’utente EOS (EUA).

Secondo l’accordo, le modifiche alla rete possono essere apportate quando c’è un consenso tra almeno 15 su 21 Block Producer, ovvero entità indipendenti che sono responsabili dell’elaborazione dei blocchi sulla blockchain EOS.

Il protocollo è supportato dalla sua omonima criptovaluta nativa, attualmente la settima risorsa più grande per capitalizzazione di mercato totale. Questi token sono al centro del meccanismo di picchettamento delle risorse integrato, una delle caratteristiche distintive di EOS. Ogni volta che una transazione viene inviata alla rete EOS, i produttori di blocchi devono elaborarla.

Il periodo di tempo (misurato in microsecondi) che un Block Producer richiede per convalidare la transazione è chiamato CPU. In parole povere, gli utenti e gli sviluppatori EOS possono accedere a risorse di CPU e larghezza di banda a livello di catena effettuando lo staking dei loro token. I blocchi vengono prodotti ogni 500 millisecondi. Ogni Block Producer ha 200 millisecondi per convalidare il blocco. I restanti 300 millisecondi vengono lasciati per la distribuzione sulla rete.

In particolare, entro il limite di 200 millisecondi, esiste anche una soglia percentuale alla quale inizia la limitazione della velocità in tutta la rete. In altre parole, quando un blocco raggiunge il limite del 10% dei 200 millisecondi totali consentiti dalla CPU per blocco, esso trigger l’algoritmo di allocazione della CPU per entrare in modalità “congestione”.

“Prima di raggiungere questo limite, tutti gli utenti possono effettuare liberamente transazioni sulla rete poiché non è in” modalità di congestione “”, l’autore dell’articolo spiegato. “Una volta superato questo limite, gli utenti vengono limitati di nuovo alla loro quota proporzionale dell’allocazione totale di CPU per staked EOS”.

Come da un altro articolo scritto da EOS Canada, uno dei principali Block Producer nella rete blockchain EOS, se ci fossero 1.000 token puntati per la CPU in un dato momento e un singolo account avesse 20 token puntati, allora quell’account sarebbe garantito il 2% della CPU totale capacità della rete.

Tuttavia, se la rete non ha raggiunto la soglia alla quale è attivata la limitazione della velocità (non in modalità “congestione”), consente a quell’account di spingere le transazioni al di sopra dell’importo garantito del 2%. Una volta superata tale soglia, l’account non può superare l’assegnazione. Inoltre, durante il "congestione" fase, la quantità di CPU di ogni utente inizia a diminuire fino a quando ogni parte in congestione esaurisce la CPU e smette di intraprendere azioni che consumano CPU.

Daniel Larimer, co-fondatore di EOS e chief technology officer di Block.one, si riferisce a questo meccanismo come un “vantaggio gratuito” della rete:

“La proprietà e lo staking di #eos offre agli utenti una quota proporzionale della larghezza di banda disponibile. Quando le persone non utilizzano la loro condivisione, questa viene reindirizzata ad altri su base proporzionale. Durante un uso intenso, gli utenti non ricevono più questo vantaggio gratuito “.

Problema: la modalità Congestion è troppo facile da attivare

Il problema, ha affermato Dexaran, è che la modalità di congestione è troppo facile da attivare. Dopo l’analisi, lo sviluppatore di smart contract ha notato importanti picchi di utilizzo della CPU all’inizio di ogni ora, presumibilmente causati da una DApp di scommesse chiamata EOSBetDice. Dexaran ha quindi deciso di valutare quanta CPU è necessaria per spingere la rete nella congestione.

Per l’esperimento, lo sviluppatore ha puntato 7.156 EOS per CPU. Quella quantità di EOS può essere presa in prestito dagli scambi di risorse al basso costo di due EOS al mese (meno di $ 6), ha sottolineato Dexaran. Per vedere come il test avrebbe influenzato gli utenti medi della rete EOS, l’ingegnere della sicurezza ha preselezionato tre account utente casuali che erano online a giocare alla DApp EOSKnights subito prima dell’inizio della sessione.

Lo sviluppatore ha quindi eseguito un contratto che generava molte transazioni differite con un ritardo di un secondo, con ogni transazione che consumava “da 25 a 27 ms di CPU”. Dopo aver monopolizzato l’utilizzo della CPU per un minuto intero, il contratto ha spinto la rete EOS in modalità di congestione. Di conseguenza, tutti e tre gli account di esempio erano fuori dalla CPU e quindi “congelati completamente”, in pratica significa che tutti gli utenti occasionali di EOS non erano in grado di interagire con alcuna DApp sulla rete in quel momento.

Due minuti dopo, il già citato DApp EOSBetDice – che ha causato picchi regolari della CPU ogni ora, indipendentemente dall’esperimento – ha iniziato a funzionare secondo il programma. Consumando ancora più CPU dalla rete nel momento in cui era già sovraccarica, ha involontariamente contribuito alla congestione avviata da Dexaran. “Più CPU consumi consecutivamente, più” profonda “sarà la modalità di congestione e più tempo impiegherà la rete a ripristinare la modalità normale”, ha osservato lo sviluppatore.

Di conseguenza, la rete EOS è entrata in una congestione ancora più “profonda” e, secondo quanto riferito, la disponibilità della CPU si è ridotta di 35 volte per tutti gli utenti EOS. “Non importa quanto EOS hai puntato per la CPU, se ne hai usato più del 3% verresti congelato”, ha osservato Dexaran.

Dopo che il contratto di Dexaran e EOSBetDice hanno stressato la rete per un totale di cinque minuti, la rete è rimasta apparentemente paralizzata per i successivi 10 minuti. Dopo altri sei minuti, si era ampiamente ripreso, ma il prezzo di prestito di EOS negli scambi di risorse era ancora circa tre volte superiore al normale, indicando che la rete richiedeva quantità elevate di token allocati nella CPU in quel momento a causa dello stress test.

La rete è stata completamente ripristinata solo 30 minuti dopo l’ultima "dannoso" azione. Ciò offre agli utenti “una finestra di 25 minuti fino alla prossima sessione di congestione”, ha osservato Dexaran, poiché l’attacco può essere eseguito ogni ora, secondo le stime dello sviluppatore. “7000 EOS sono sufficienti per spingere la rete EOS in una modalità di congestione per una discreta quantità di tempo”, ha concluso il ricercatore, aggiungendo:

“La sessione di congestione descritta causerà problemi solo a (1) utenti che hanno speso una certa quota della larghezza di banda della loro CPU, (2) utenti con una larghezza di banda della CPU molto ridotta. La sessione di congestione descritta non ha alcun impatto su (1) DApp che hanno molta CPU disponibile, (2) utenti che non si impegnano in alcuna attività e hanno la loro CPU completamente disponibile (supponendo che questi utenti abbiano abbastanza CPU per fare una singola trasmissione ). “

Inoltre, Dexaran ha sottolineato che mentre alcuni utenti di EOS potrebbero chiamarlo a "pirata" a causa del sovraccarico intenzionale della rete, “Sto facendo esattamente l’opposto: proteggo i miei e i tuoi investimenti”.

In particolare, un paio di giorni prima della pubblicazione della voce di Dexaran sulla congestione EOS, lo sviluppatore Christoph Michel ha scritto un post sul blog collegare il recente hack del casinò EOSPlay alla congestione della rete, mostrando quindi come il problema della rete potrebbe essere sfruttato a scopo di lucro.

Secondo Michel, l’attaccante ha noleggiato i token EOS da REX, un mercato di noleggio di risorse CPU e NET, e poi li ha impilati per aumentare sia la CPU sua che quella di EOSPlay per garantire che il casinò rimanesse funzionale, quindi rimanere in grado di pagare le sue scommesse. L’hacker ha quindi inviato spam alla rete con transazioni simili a Dexaran e ha giocato diversi giochi di dadi su EOSPlay, scommettendo su un risultato 50/50. Dato che EOSPlay guarda l’hash del blocco del blocco dei risultati e prende i primi due caratteri – a partire da destra e tra zero e nove – come il lancio di dadi, si deve prevedere l’hash del blocco del blocco dei risultati per vincere la partita.

“Le uniche incognite nella previsione sono le transazioni incluse nei blocchi”, ha spiegato Michel. “Ma cosa succederebbe se si potesse semplicemente inviare spam e congestionare la rete in modo che nessun altro possa inviare transazioni?”

Secondo lo sviluppatore, questo è esattamente il motivo per cui l’attaccante ha preso in prestito EOS per inviare spam alla rete: per avere il controllo sulla rete e quindi essere in grado di prevedere gli hash di blocco e vincere la maggior parte delle sue scommesse. In caso di previsione errata, l’attaccante potrebbe inviare un’altra transazione casuale al blocco e quindi avere un “lancio della moneta” extra, migliorando notevolmente le probabilità.

Alla fine, l’hacker ha utilizzato solo 300 EOS, del valore di poco più di $ 1.000, che avrebbe potuto noleggiare per un paio di dollari. In cambio, la quantità di vincite fisse ha portato oltre 30.000 EOS, ovvero circa $ 110.000.

Gli sviluppatori EOS assicurano che la rete “funzioni correttamente”, ma non tutti sono d’accordo

Gli esperimenti di congestione di Dexaran non sono passati inosservati, poiché numerosi utenti hanno segnalato di avere “problemi di CPU” su Twitter e Reddit. Denis Bredikhin, CEO di Graphene Lab, un team di sviluppatori di contratti intelligenti, ha confermato a Cointelegraph che anche gli utenti della sua DApp di scommesse EOS basata sul poker hanno riscontrato problemi nelle ultime settimane, sebbene l’applicazione stessa non sia stata compromessa. Bredikhin ha detto:

“Al culmine dello spam, i giocatori anche con 8-10 mila EOS allocati alla CPU, non potevano eseguire alcuna operazione.”

Secondo lui, a partire dal 1 ° ottobre, i giocatori devono allocare “fino a 10.000 EOS” nella CPU in modo che il gioco non si fermi per loro durante le sessioni di spam. Nel frattempo, Larimer di Block.one è andato su Twitter per rassicurare la comunità che EOS “funziona correttamente”. Lui ha scritto:

“Questo non è diverso da quando gli aggressori inondano eth o bitcoin con spam di transazioni a pagamento elevato. La rete non si bloccava per i possessori di token, semplicemente non c’era larghezza di banda aggiuntiva disponibile per l’uso gratuito “.

Alcuni membri della comunità chiedono tuttavia di differire. “La differenza tra questo attacco a EOS e uno spam con commissioni elevate su BTC o ETH è che puoi ancora pagare di più per inviare una transazione su BTC o ETH”, sostenuto Rob Finch, CEO di CypherGlass, produttore di blocchi EOS con sede negli Stati Uniti. Ha aggiunto:

“Molti utenti EOS non avevano CPU sufficiente per noleggiare più CPU, quindi si è bloccato per loro. Operare correttamente “non è la risposta migliore IMO.”

Un altro utente EOS, l’imprenditore blockchain Jared Moore, confermato che la rete era inutilizzabile per DApps o il suo portafoglio. Si è anche chiesto se Block.one avrebbe “aiutato la comunità EOS a pubblicare linee guida su come prevenire gli attacchi REX”.

Cointelegraph ha contattato Block.one per ulteriori commenti e aggiornerà l’articolo una volta ottenute ulteriori informazioni.