Topic: Stato DISASTROSO rete ethereum - page 25. (Read 6967 times)

Se è lo stesso codice che gira in ETC si potrebbe provarlo gratis sulla blockchain di Ethereum Classic e vedere l'effetto che fa.
Farlo live sulla mainnet di ETH comporta un discreto impiego di risorse considerati i tuoi calcoli.
Ora ragionando al contrario, assumendo che questo tipo di attacco funzioni, quali sarebbero le contromisure? Immagino, per l'ennesima volta, che ciò richieda in HF per attuare eventuali correttivi.

Una nuova versione dello smart contract, altamente ottimizzata.

pragma solidity ^0.4.0;

contract DeathStar
   {
   function DeathLoop() public
      {
      assembly
       {
       // push address stack+1 costo Wverylow=3gas
       loop:

         // jumpdest stack immutato, costo Gjumpdest=1gas
         jumpdest
         jumpdest
         jumpdest
         ..... ripetere n volte.
         jumpdest
         jumpdest

         // jmp address  stack -1  costo Wmid=8gas
         jump(loop)
       }
     }
   }


Dal punto di vista logico, il codice sembra non avere senso, ma ricordiamo che l'obiettivo del codice e' di eseguire
il massimo numero di operazioni al minor costo possibile.

Ecco quindi il senso: ogni operazione JUMPDEST ha un costo di un solo gas!
in questo modo eseguaimo n jumpdest  per un solo gas, e poi una push da 3 gas + una jump da 8 gas

in pratica se n vale 100, looppiamo eseguendo ad ogni ciclo di loop  102 opcode ad un costo di 111 gas (ossia cost medio 1.088 gas)

In questo momento il costo del gas e' 36 gwei (piu' basso dell'altro giorno)
un conto caricato con un ethereum equivale a 1.000.000.000 di Gwei
siccome ogni opcode del ciclo mi costa in media 1.088 gas ogni opcode mi costa 39.168 Gwei.

ossia in questo momento con un ethereum potrei eseguire 25.500.000 di opcode circa, un notevolissimo miglioramento
rispetto alle prime versioni

Si puo' ottenere un ulteriore piccolo miglioramento percentuale aumentando il numero dei jumpdest...
ad esempio con 1000 jumpdest ad ogni ciclo eseguiamo 1002 opcode al prezzo di 1011 gas, ad un prezzo medio di 1,0089 gas per opcode.
Con questa ulteriore ottimizzazione posso arrivare ad un costo medio di 36.32 Gwei per opcode,
ossia con un ethereum posso arrivare ad eseguire 27.500.000 opcode.

Questo e' il massimo livello possibile di ottimizzazione raggiungibile, cioe' il tipo di loop che genera il maggior
lavoro possibile della EVM al minor costo possibile, in quanto non esistono istruzioni utilizzabili per questo scopo dal costo di 0 gas
(le uniche al costo di 0 gas STOP, RETURN, REVERT stoppano l'esecuzione dello smart contract).

Con questo livello di ottimizzazione, (o pessimizzazione dal punto di vista della EVM)
penso davvero che si possano cominciare a fare dei danni.... e ironia della sorte  
l'operatore jumpdest (che fondamentalmente non serve a nulla, se non a stabilire che una certa locazione e' jumpabile)
e' stato introdotto come ulteriore livello di sicurezza!

Unico problema l'assembler di solidity NON permette di imettere l'opcode jumpdest, ma si puo' facilmente bypassare
inserendo direttamente il codice macchina a manazza, vista la banalita' del programma. Si tratta
fondamentalmente di immettere una serie di 0x5b che e' il codice macchina di JUMPDEST

Ho come l'impressione che se qualcosa del genere fosse lanciato e fosse scoperto e fosse ritenuto pericoloso, il gotha di Ethereum prenderebbe subito le dovute contromisure: HF su tutti.
Ricordo che i flash loans soprattutto sono stati sfruttati di recente per drenare un po' di fondi da vari contratti non troppo smart.

Nello specifico rispetto alle idee di gbianchi, queste non sono solo suee idee...
https://www.cryptoglobe.com/latest/2018/12/crypto-analyst-tuur-demeester-launches-devastating-attack-on-ethereum-eth/
Ethereum isn't safe or scalable. It is immature experimental tech. Don't rely on it for mission critical apps unless absolutely necessary!

— Vlad Zamfir (@VladZamfir) March 4, 2017

https://www.bloomberg.com/news/articles/2021-07-15/vlad-zamfir-on-the-dangers-of-unstoppable-software-and-what-people-get-wrong-about-blockchains

"quindi se ci fosse un modo per volare lo avrebbero già fatto" ... dicevano così anche a Icaro?

Vado a memoria ma uno shock simile si è visto con la stable coin MakerDAO che era era legata al valore di ETH.
In pratica scendendo il valore di ETH ha creato un meccanismo di liquidazione di ulteriori ETH etc etc ...
Anche in quel caso era visto come impossibile o "lo si avrebbe fatto" .

ps la sezione giusta del topic è https://bitcointalk.org/index.php?board=132.0 ALTCOIN

xo' ci deve essere sempre un "gbianchi " che lo fà x primo!

quindi facciamo una colletta di ETH x il super LOOP?
 

Una prima versione, non so se si compila sopratutto non so che codice macchina genera davvero,
bisogna verificare con un ambiente di sviluppo (che io non ho e vorrei continuare a non avere ...)

pragma solidity ^0.4.0;

contract esempio
   {
   function loop() public
      {
      assembly
       {
       // push address stack+1 costo Wverylow=3gas
       loop:


          // push a stack+1 costo Wverylow=3gas
          // push b stack +1 costo Wverylow=3gas
          // mul a b stack -2 (pop operandi) +1 (push risultato) costo Wlow=5gas
          // il compilatore ottimizza questa mul ? si possono disabilitare le ottimizzazioni? 
          // se si ottimizza si puo' bypassare con mul(add(div(.....)))?? da verificare in codice macchina
          mul(12312, 8374832) 

          //Il valore letto dallo stack viene "buttato via" con la pop, tanto non ci interessa, 
          // se la mul senza assegnazione non fa la pop, la faccio io a mano, da verificare in codice macchina.
          // qui sono a stack+1 serve una pop per tornare a zero
          pop stack -1 costo wbase=2gas
          
        
         // jmp address  stack -1  costo Wmid=8gas 
         jump(loop)
       }
     }
   }

Lo stack rimane sempre bilanciato, quindi non cresce indefinitamente.

come si vede sono 3 istruzioni assembler ad ogni ciclo, che in realta'
generano 6 istruzioni EVM il totale dei gas e' 24 24/6 = 4 gas valore medio per ogni istruzione del loop.
quindi arriviamo a circa 3.000.000 di sitruzioni al costo di circa un ethereum.

https://blockgeeks.com/guides/ethereum-gas/

ecco uno dei pochi articoli che ho trovato con un buon contenuto tecnico.

Dice chiaramente che il meccanismo che ha ethereum per stoppare un loop infinito e'...
terminare il gas (ossia gli ethereum) a disposizione, come avevo immaginato.

Ora non mi e' chiaro come e quando avviene l'addebbito delle fee (che come dice chiaramente l'articolo
vengono addebitate ANCHE se lo smart contract non va a buon fine).

Faccio un esempio: io ho un indirizzo bello carico di ethereum, supponiamo 1000. E mando in rete
una transazione che fa questo loop in assembler EVM. QUndi tutti i nodi si devono mettere a fare
il loop di un miliardo e rotti di cicli per scoprire che finiscono il gas e sollevare un'eccezione.

Ma a questo gia' mi solleva molti dubbi: i nodi non saranno tutti ugualmente veloci, supponiamo che un nodo ci metta 50 secondi,
uno 100, uno addirittura 150 perche' sta facendo anche altre cose.

Nel frattempo vengono minati dei blocchi (in ethereum ne minano uno ogni pochi secondi)
che non comprendono lo stato finale della mia transazione.
Che cosa comprendono questi blocchi? le fee mi sono gia' state scalate subito? ma come fanno a saperle
che il loop non e' ancora finito su nessun nodo?
  
E quando il loop comincia a finire sui vari nodi, come fanno a mettersi d'accordo?
(anche perche' si potrebbe anche introdurre una variabile random dove su ogni nodo il loop  non e' infinito
ma dura un numero di cicli  diverso...)

Boh tutta questa parte non mi e' chiara.


Comunque l'equazione: pago per fare lavorare a vuoto i nodi e' fattibile. Ora bisogna riuscire a capire
come e quanto pago, per vedere se e' sostenibile il concetto mando la rete in tilt per fare uno short,
anche perche' per mandarla "sufficentemente" in tilt da scatenare un drop dei prezzi,
suppongo che debba essere praticamente inusabile per ore.

si per fortuna gbianchi ha fatto solide ricerche e speso tanto tempo, e' gia la seconda volta che se ne esce con questa storia dei loop infiniti per mandare in palla tutto  


la penso cosi' anche io, ma vi prego continuate pure 

Voglio bypassare solidity e codificare direttamente in assembly EVM (cosa che e' fattibile)
effettivamente EVM e' una macchina a stack, ma la jump fatta cosi' dovrebbe solo prelevare dallo stack
il parametro di dove saltare.

Premesso che non conosco solidity, da quel che ho letto in giro dovrebbero esistere dei meccanismi di sicurezza nella EVM che impediscano loop infiniti, per esempio con dei limiti a quanto può crescere lo stack:

https://ethereum.stackexchange.com/questions/26938/why-is-the-evm-stack-limited-to-1024

poi onestamente non so se con quello che intendi tu andresti a bypassare questi controlli, non conosco abbastanza i dettagli per approfondire.

Una prima bozza e qualche stima:


secondo lo yellow-paper,
https://ethereum.github.io/yellowpaper/paper.pdf vi e' una tabella di gas pagati per le varie operazioni.

la piu' economica con la quale si puo' creare un loop e' l'istruzione EVM jump, che fa parte del gruppo Wmid
che costa 8 gas.

con un'istruzione assembler jump si puo' creare quindi un loop infinito (jump alla location di se stesso)
che costa "relativamente poco".

quindi si puo' creare una serie di micro contratti poco costosi (estremamente piccoli)
che una volta lanciati looppano a non far niente a relativamente poco costo.

al prezzo attuale del gas, attorno agli 80 Gwei, serveno quindi 640 Gwei (8 gas dell'istruzione jump * 80 Gwei gas)
per fare un ciclo di loop. (ricordiamo che un Gwei = un miliardesimo di ethereum)

Quindi con un ethereum (ossia 3000$ circa) si fanno un 1.500.000 cicli circa.

Il bello e' che una volta lanciata la call, TUTTI i nodi che partecipano alla rete (quindi almeno tutti i full)
devono rifare questo calcolo (perche devono verificare la transazione con lo smart contract*
ho scoperto  poi tutti i calcoli della logica di tutti gli smart contract se li fanno TUTTI i nodi... ditemi voi come faranno a scalare!
ed ecco un altro motivi di perche'  i nodi  si stanno centralizzando su server potenti in cloud)
 
(Il brutto e' che un milione di cicli non credo sia tanto impattante. Non so quanto sia ottimizzata (o pessimizzata)
la EVM ma e' un numero comunque molto basso... ci vorrano molti di questi micro smart contract da eseguire in parallelo)

Ora ci sono dei dettagli che qualche esperto di Ethereum dovrebbe spiegarmi: Siccome
non e' che ci interessa che l'esecuzione dello smart contract finisca davvero nella blockchain,
(lo scopo e' solo rompere le scatole ai nodi validatori che devono eseguirlo per validarlo... nel mondo bitcoin
e' come quando sparo una transazione nella mempool... ma se non finisce in blockchain e' un nulla di fatto come saldo reale,
qui come fanno mi scalano i soldi ugualmente, anche se non finisco in blockachain come transazione eseguita?)
 
Ma di tutto questo pezzo non ho idea chiara di come funzioni.

Vale la pena aprire una piccola parentesi su questo incidente.
Secondo il sito https://www.buybitcoinworldwide.com/bitcoin-uptime/ bitcoin è stato up per il 99.98% del temopo.
Sono solo stati due gli incidenti che lo hanno messo down, per un totale di.

Uno di questi è proprio quello indicato da acquafredda: il CVE -2010-5139.


Ovviamente il trhead di riferimento è proprio qui su bitcointalk.org:
Strange block 74638

Chissà se esiste analogo counter per ETH..

Molti di noi dovrebbero ricordare o quantomeno sapere cosa successe a Bitcoin quando fu trovato il suo peggiore e credo unico bug grave.
Nell'agosto 2010, qualcuno ha sfruttato una falla nel codice di Bitcoin per creare 184 miliardi di Bitcoin, il bug è stato rapidamente corretto da Satoshi e la persona dietro l'exploit del "value overflow incident" rimane sconosciuta.
Ora tutto questo è successo quando bitcoin valeva niente. Un problema simile su ETH determinerebbe non la morte ma quantomeno il coma della rete.
Se gbianchi riesci...

se riesci a farlo @gbianchi, scriverai il tuo nome nella storia... altro che blockchain

pensa all'orda di neo-trader che imprechera maledicendo il tuo nome e la tua progenie fino alla settima generazione

ao so soddisfazioni

Ti vedo ottimista.
Se la distanza tra oggi e la gloria sempriterna (vi ricordate quello che ha fatto implodere RTH, 20 anni fa? come si chiamava? gbianchi!) sono solo due giorni di lavoro di "un vecchio informatico" sono davvero spaventato di cosa si stia usando come livello base della nuova infrastruttura DeFi.
Sono scettico, ma non ho basi scientifiche per motivare questa mia convinzione

bè se decidi di farla tu ti pregherei solo di avvisare prima di lanciarla, così faccio in tempo a dumpare quei pochi Eth che mi sono rimasti

io so solo che EIP-1559 non ha funzionato,cioe non ha raggiunto il suo scopo primario ridurre le fee delle transazioni che sono rimaste molto variabili e con un valore medio alto

Ecco... questa e' un'osservazione corretta che ha un notevole peso come prova che
un eventuale "hack" non sia cosi' semplice come sostiene Zucco.

ma non e' una prova che sia impossibile.

Nel frattempo mi sono messo un po'  a studiare come funziona ethereum.

Da vecchio programmatore direi che le basi per uno possibile hack ci sono tutte:

- Il codice e' immutabile (una volta iniettato nella blockchain non si cammbia piu' (a meno di un hard fork tipo DAO))
- il compilatore da la possibilita' di fare un online assembler del "codie macchina della EVM" e l'assembler era il modo principe per andare a scovare bug
  tipo buffer overflow, integer overflow, stack corruption e robe del genere.
- sono possibili le funzioni ricorsive (che sono un altra fonte inesauribile di potenziali vulnerabilita')

Cosi' ad un prima occhiata, mi pare che l'unico meccanismo di vera protezione non sia tanto il poter scrivere del codice buggato/malevolo...
ma che eseguire questo codice costa dei soldi (e tanti)

Ora, proviamo a vedere la cosa da un punto di vista totalmente diverso.

Non esistono (almeno in apparenza*) regole censorie per immettere del codice in blockchain... basta pagare.
Ossia uno puo' immettere un codice anche proprio PROGETTATO per fare danni, non che sfrutti bug per farli,
basta che paghi. questa potrebbe essere la madre di tutte le debolezze:

una linea di attacco potrebbe essere: siamo un gruppo che
a) vuole dimostrare che ethereum non sta in piedi alla radice, proprio perche' si puo' immettere del codice a piacimento, basta pagare.
b) lo spirito morale non ci motiva a sufficenza, quindi nell'operazione ci vogliamo anche guadagnare e molto.
c) siamo gente che vive nel mondo delle crypto da anni... e fortunatamente i mezzi non ci mancano  
d) Progettiamo e realizziamo uno smart contrat chiamato "La morte nera"
e) shortiamo ethereum di brutto,
f)  immettiamo lo smart contract "La morte nera" nella blockchain di ethereum
g) lo pompiano a suon di milioni in ethereum per farlo girare, ma con la certezza di quadagnarne molto di piu' dallo short.
e) lo smart contract "La morte nera" progettato a mo' di virus, spamma la chain di ethereum fino alla devastazione.
f) ethereum crolla in un tempo brevissimo, il prezzo crolla in picchiata di e di conseguenza  copriamo gli short nababbi.
g) guadagnamo una barca di soldi ed abbiamo devastato ethereum (senza infrangere nessua legge)

Vediamo se questa bella pensata (che e' la prima che mi viene in mente eh, so fare di peggio) me la smontate facilmente.

*l'unica via di fuga che vedo e' di bloccare immediatamente lo smart contract "la morte nera" con un hard fork
e annullamento dello smart contract... ma in questo caso anche gli ethereum che ci abbiamo pompato dentro
per far girare il codice-virus non sono piu' stati pompati.

EDIT: "La morte nera" e' anche facilissimo da realizzare, credo che in due giorni di lavoro lo potrei fare io,
che ho iniziato oggi pomeriggio a studiare solidity... non e' che ci voglia un genio della programmazione.

Potrebbe esistere un grosso bug di Eth? certo, e se qualcuno lo avesse trovato di sicuro ne avrebbe già approfittato facendo grossi short. Non avrebbe senso infatti attendere prima di shortare visto che facendolo si correrebbe il rischio che altri scoprano il bug e facciano lo short prima di te.

Quindi il fatto che ad oggi non sia stato fatto nessun grosso sohrt di questo tipo significa che ad oggi nessun bug di elevato impatto è ancora stato trovato.

Questo però non significa che non esistano grossi bug, potrebbe essere che esistano ma nessuno abbia ancora dedicato sufficiente tempo/energie per trovarli.....

Si può shortare ETH sugli exchange? Si.
Quindi se ci fosse un modo per causare il panico e guadagnarci, già lo si avrebbe fatto.
ETH avrà i suoi problemi, ma evidentemente non sono così gravi come ovviamente un massimalista cercherà di raccontare