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

Finalmente ho una versione compilabile del codice.


     
Dai compilatori moderni (dalla 0.5 in poi, adesso siamo al 0.8.8 ) hanno tolto la possibilita' di fare molte di queste cose,
ad esempio una tag per il jump (guarda caso....) comunque ho trovato un vecchio compilatore solc
che mi ha macinato il codice!

Questo e' il codice binario di uno smart contract eseguibile in rete!

Alcune considerazioni:

Inizilamente mi ero focalizzato sullo scrivere un codice che si auto-replicava...
ma poi mi sono reso conto che qualsiasi programma scritto per ethereum e' un Virus by-design!

Pensateci: qualsiasi programma (o smart contract come lo chiamano loro), proprio per architettura, viene eseguito su tutti i nodi!
unico anticorpo: il costo dell'esecuzione.

quindi non mi serviva nessuna logica di auto replicazione, ma solo una logica per essere il piu' "competitivo"
tra i possibili programmi (virus) in esecuzione, ossia quello piu' resistente all'unico anticorpo.

E nessuno puo' essere piu' competitivo di questo, che ha un costo medio di un solo gas per istruzione!

Altra nota tecnica: in realta' il codice di "wrap" fisso attorno ad una funzione, in questo caso la funzione DeathLoop,
(quello segnato in grassetto qui sotto) tende ad appesantire  il rapporto gas per istruzione,
ma lo fa solo per il primo ciclo, poi il rapporto comincia a calare e ad arrivare prossimo a 1 gas per istruzione

Ci sono degli strumenti di sviluppo.

Il piu' consono in questo caso credo sia Ganache, che ti crea una blockchain ethereum locale
sulla quale spataccare... ed ha il vantaggio di fare le prove che vuoi senza far suonare tanti campanelli,
lo svantaggio di essere moooolto lontano da una situazione reale. Diciamo che per un primo test puo' andare.

(Purtroppo come vedete sto approfondendo un po' ethereum.
E piu' ci entro dentro e piu' mi rendo conto che e' una cosa totalmente insostenibile, sotto
ogni punto di vista, uno di questi e' proprio lo sviluppo.... sviluppare e PROVARE e' letteralmente un incubo,
visto che una volta messo online il codice NON puoi piu' tornare indietro)

Si ma il migliormento e' sempre piu' marginale, perche' l'efficenza si avvicina asintoticamente
al costo medio di 1 gas per istruzione.

Comunque uno smart contract puo' essere al massimo  24500 byte circa, quindi
al massimo si possono mettere 24500 jumpdest.

Rifacendo il calcolo con 24.500 jumpdest abbiamo 24502 opcode ad un costo di 24511 gas
il costo medio di ogni opcode diventa quindi 1,00036 gas ossia 36.0129 gwei per opcode
In pratica col famoso ethereum faccio 27.767.827 (un incemento percentuale quasi insignificante).

Aggiungo giusto un dettaglio che potrebbe rivelarsi utile anche su ETH.

ETC è stato in passato attaccato con pesanti double spend e continue chain reorg (avendo un hashrate molto più basso di ETH).

Il mercato non è scomparso, tutt'altro, ad oggi ETC viene quotata sui 60 e passa dollari e continua a vivere serena, unico cambiamento sono le conferme chieste dagli exchange per accettare ETC (se non sbaglio coinbase ne voleva tipo 35k, sulla quindicina di giorni d'attesa)

Un fatto del genere, su BTC, lo considererei come la morte della moneta stessa, ma evidentemente ci sono investitori che non si fanno spaventare da nulla.

Quindi gbianchi, cerca di trovare una falla molto ma molto grande, perché la community e il mercato anche di fronte a double spend potrebbero non arrendersi  

Beh ETC non ha valore. Una blockchain inutile tipo bitcoincash che non ha ragione di esistere. Come sparare sulla beneamata Croce Rossa.
L'obiettivo è ETH ma come dicevate giustamente, un attacco simile su ETC farebbe drizzare le antenne agli ETHers.
O forse no?
Quando si è troppo sicuri di ciò che si fa, in genere questi segnali non vengono visti.

Però un attacco di questo tipo su ETC potrebbe fare suonare degli allarmi in casa ETH e permettere loro di effettuare delle contromosse.
Magari qualcuno si ispira e sfrutta lui l'attacco "DeathStar", facendo risparmiare a gbianchi un ETH...
La gloria sarebbe comunque assicurata!

DOMANDA:
Parli di 1,000 jumpdest... ma si piò aumentare ulteriormente il numero per ridurre ancora il costo?

effettivamente è un'idea interessante, per due motivi: 1) con gli stessi fondi da spendere si otterrebbero circa 50 volte più cicli a vuoto, e soprattutto 2) non potrebbero risolvere con hard fork, proprio per la filosofia alla base di ETC

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...