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

A parte il fatto che quella funzione, non scrivendo nella blockchain, non viene eseguita da nessun miner, ma solo da chi la esegue senza nessun costo.
Pure se ci metti un istruzione write non ha senso, nella migliore delle ipotesi esegue fino a che ci stanno fondi, nella peggiore non viene eseguita nemmeno perchè si accorge prima che non termina. 8

Vero ci avevo pensato. Ma in questo caso basterebbe lanciare n ricorrenze dello smart contract, magari
leggermente diverse una dall'altra per confondere un po' le idee alla rete.

........

ho trovato ben due punti g!
Ecco i miei punti che me lo rendono impossiible!

Un caso di studio nato proprio da una tua osservazione:

Una possibile strategia di attacco alla rete ethereum.

Di gbianchi bitcointalk.org

questo studio nasce da alcune osservazioni:

1) nella rete ethereum non esiste nessun concetto di "smart contract vietato", la rete e' permissionless
   ossia qualsiasi utente puo' immettere in rete qualsiasi tipo di codice, basta che il codice sia formalmente corretto
   e che paghi il caricamento e l'esecuzione del codice.

2) ogni "smart contract" si comporta by design come un virus, ossia se eseguito, viene eseguito automaticamente
   su tutti i nodi, proprio in virtu' del principio di decentralizzazione, ogni nodo deve ri-eseguire il codice  
   per verificare il lavoro fatto dagli altri e giungere al consenso con gli altri nodi.

3) L'unico meccanismo per "governare" l'esecuzione del codice  e' il fatto che l'esecuzione di qualsiasi
   smart contract costa gas, proporzionale al numero di istruzioni eseguite ed al tipo di istruzioni.

4) gli smart contract vengono normalmente scritti in solidity, ma vengono poi compilati e tradotti in linguaggio
   macchina EVM, e solidity da' la possibilita' di scrivere direttamente in linguaggio assembler della EVM.

5) Una volta immesso, il codice e' immutabile, quindi non vi e' modo di "togliere di mezzo" lo smart contract dalla rete,
   a meno di un hard fork tipo DAO. Ma mentre Dao sfruttava un bug, qui viene utilizzata l'architettura di base di ethereum,
   rendendo veramente difficile la progettazione di un hard fork abbastanza efficace.

In base a queste osservazioni, si puo' progettare uno smart contract "DeathStar" la cui esecuzione costi il meno possibile,
e che "bruci" ethereum solo per competere con gli altri smart contract sui vari nodi, e ottenere piu' risorse elaborative possibili,
rallentando e facendo stagnare l'esecuzione di tutti gli altri smart contract.

Un gruppo di attaccanti potrebbe essere incentivato per svariati motivi a bruciare ethereum per mettere in difficolta' la rete, ad esempio:

- ad esempio essere i sostenitori di un'altra moneta competitor,
- oppure organizzare  uno short su ethereum prima dell'attacco, congestionare la rete ethereum e ricoprirsi a prezzi piu' bassi,
  recuperndo i soldi dell'attacco e guadagnandoci
- mettere in difficolta' uno o piu' degli svariati smart contract che girano su ethereum

In generale qualsiasi persona o gruppo con sufficenti mezzi e con un qualsiasi tipo di interesse alla decadenza della rete ethereum
e/o degli smart contract che vi girano, potrebbe usare questa linea di attacco.


Descrizione tecnica di DeathStar

lo yellow paper di ethereum  https://ethereum.github.io/yellowpaper/paper.pdf e' la fonte di informazioni ufficiale.
 
All'interno si trovano (tra tante al tre cose) la descrizione degli opcode EVM (Ethereum Virtual Machine)
e  le tabelle del costo in gas di ogni opcode.

Emerge che ogni smart contract viene compilato e convertito in opcode EVM, e dalla tabella
"Appendix G FEE SCHEDULE" emerge che questi opcode hanno  costi che vanno da 0 gas (opcode STOP, RETURN, REVERT)
fino a 20.000 gas o piu' per opcode di store di dati, 32.000 gas per la CREATE ecc.

Introduciamo ora il concetto di costo medio per opcode. Uno smart contract e' composto da un insieme di opcode che
formano la logica dello smart contract stesso, quindi chiamate funzionali, operazioni logiche, calcoli, storage dei risultati ecc.

L'esecuzione di uno smart contract sara' quindi l'esecuzione di tante di questi opcode, dai vari costi, che portano alla fine
al costo totale dell'esecuzione.

supponiamo che uno smart contract esegua questi opcode:
10 da 3 gas, 5 da 8 gas uno da 700 gas e uno da 20.000 gas (le operazioni sullo storage sono molto costose).
avremo quindi un costo totale di 30+40+700+20.000=20770 gas per 17 opcode. Il costo medio per opcode sara'
quindi di 1221.76 gas.

Per essere lo smart contract piu' "competitivo" in temine di costo per opcode, DeathStar dovra' essere progettato attorno
ad un opcode che costi il meno possibile, per avere il minor costo medio per opcode possibile.

Non si possono usare gli opcode da costo 0 (STOP, RETURN, REVERT)  in quanto tutti terminano l'esecuzione dello smart contract.

Quindi passiamo all'unico opcode  al costo di 1 gas: JUMDEST. Jumpdest e' un opcode  che non fa quasi nulla,
se non "Mark a valide destination for jump". non fa push e/o pop dallo stack, non fa nulla se non settare una posizione
dove poter saltare con una JUMP.

L'idea e' di wrappare una serie di opcode  JUMPDEST in un loop, in modo tale da abbassare il piu' possibile costo medio per opcode
di esecuzione di questo loop, in modo da renderlo vicino ad 1 gas per opcode, target al quale nessuno smart
contract che implementa qualche logica' potra' mai neanche lontanamente arrivare.

Ma ricordiamo il nostro scopo non e' avere una logica (infatti da un punto di vista elaborativo questo codice non produce nulla, non ha una logica)
e' semplicemente avere il costo medio per opcode piu' basso possibile,  per eseguire con una certa somma il maggior numero possibile di opcode che
"drenano" risorse elaborative dal network.

Ultima nota che ci serve sapere, e' che ethereum ha un criterio molto semplice per "interrompere" i loop infiniti: li termina quando
sono finiti i fondi. Quindi Caricando opportunamete di fondi lo smart contract, questo continuera' a girare, scalando un gas a opcode (in media)
in competizione con altri smart contract molto piu' costosi in termini di costo medio a opcode, che e' esattamente lo scopo
che ci eravamo prefissi: Avere uno smart contract che brucia ethereum al costo piu' basso possibile in competizione con gli altri smart
contract in esecuzione che avranno costi medi per opcode  di gran lunga piu' alti.

Un "trucco" che ci aiuta ad ottenere il codice binario e' che nelle vecchie versioni di solidity (fino alla versione 0.4)
era possibile immettere in assembler delle tag per le istruzioni jump, e che queste tag erano implementate proprio con degli opcode JUMPSET,
quindi usando un compilatore solc della versione 0.4.x il codice si compila in un attimo.
Coincidenza vuole che questa tecnica di codifica non sia  piu' possibile nei nuovi compilatori.


Codice di DeathStar:

pragma solidity ^0.4.0;

contract DeathStar
   {
   function DeathLoop() public
      {
      assembly
       {
       loop000:
       loop001:
       loop002:
       loop003:
       loop004:
       loop005:
       ....
       ....
       loop992:
       loop993:
       loop994:
       loop995:
       loop996:
       loop997:
       loop998:
       loop999:
      
       jump(loop000)
       }
     }
   }


viene compilato cosi':

...

JUMPDEST
JUMPDEST
JUMPDEST
...
JUMPDEST
JUMPDEST
PUSH2 0x4F
JUMP

Con 1000 jumpdest (ogni tag loopxxx: genera una jumpdest) + una push (costo 3 gas) + una jump (costo 8 gas)
abbiamo 1002 opcode al costo di 1011 gas  il costo medio per opcode del loop e' quindi attorno a 1,0089 gas.
Ipotizzando un costo gas di 36 Gwei, abbiamo un costo medio ad istruzione di 36,32 Gwei per opcode,
ossia con un ethereum possiamo eseguire ben 27.500.000 di opcode.
Notare che aggiungere piu' jumpdest allunga il codice ma migliora il costo medio per opcode in modo molto marginale,
non credo ne valga la pena.

Codice binario dello smart contract compilato:

Binary:
6060604052341561000c57fe5b5b6104688061001c6000396000f30060606040526000357c01000 00000000000000000000000000000000000000000000000000000900463ffffffff1680634b489b 321461003b575bfe5b341561004357fe5b61004b61004d565b005b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5 b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b 61004e565b5600a165627a7a7230582038b23d251247261d10e2d2488b65e84ad63f17d7c93525f da5e1c3551ac3ae460029


Un ringraziamento ai ragazzi della comunita' italiana di bitcointalk.org (filippone, acquafredda, HostFat, jack0m ed altri)
che mi hanno dato spunti interessanti per la realizzazione di questo studio.

Ecco i miei punti che me lo rendono impossiible!

ok, diciamo che rivedendolo ora, ci sono almeno 3 punti che lo rendono un caso di studio puramente accademico, almeno per quanto mi riguarda

c) siamo gente che vive nel mondo delle crypto da anni... e fortunatamente i mezzi non ci mancano  Grin
g) lo pompiano a suon di milioni in ethereum per farlo girare, ma con la certezza di quadagnarne molto di piu' dallo short.
g) guadagnamo una barca di soldi ed abbiamo devastato ethereum (senza infrangere nessua legge)

ok, diciamo che rivedendolo ora, ci sono almeno 3 punti che lo rendono un caso di studio puramente accademico, almeno per quanto mi riguarda

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

oh certo, io immagino mooolto di piu'.

ma ti riposto lo schema originario del potenziale attacco: (non avevo ancora sviluppato nessuna idea pratica su come realizzare lo smart contract,
(anzi onestamente manco sapevo cosa fosse in pratica... parlavo ancora di spammarlo a mo' di virus...  ma qualsiasi smart contract si auto-spamma a mo' di virus )

eh però così moltiplichi per n anche la spesa in gas... non so, ho la sensazione che per avere un qualche effetto riscontrabile la spesa sia veramente alta, centinaia di ETH o forse di più... ma non ho elementi concreti per accertarlo.

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  Grin
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)

Vero ci avevo pensato. Ma in questo caso basterebbe lanciare n ricorrenze dello smart contract, magari
leggermente diverse una dall'altra per confondere un po' le idee alla rete.

Il vero elemento cruciale e' se con una cifra "ragionevole" si riesce ad impattare sui nodi.

Se si riesce, per ethereum sono cazzi.

Non so se se la cavano neppure con un hard fork, perche' dovrebbe aumentare (e di parecchio) i gas di questa operazione!
ma ci sono altre operazioni che costano poco di piu' che si possono usare. E che fanno, un hard fork al giorno?


EDIT: comunque detto tra di noi, il fatto che nei compilatori moderni abbiano tolto la possibilita' di  smanettare
certe istruzioni, guarda caso legate all'uso di jumpdest, gia' mi puzza da morire.... forse non voglio che qualcuno, magari per sbaglio,
si imbatta in qualcosa del genere? mah... diciamo che e' una coincidenza, eh?

 

sì ma questo diluirebbe nel tempo i gas sprecati, rendendoli una % trascurabile di quelli complessivamente processati dal nodo

sì ma questo diluirebbe nel tempo i gas sprecati, rendendoli una % trascurabile di quelli complessivamente processati dal nodo

Beh, se anche così fosse significherebbe che tot cicli dell nodo sarebbero occupati per moolto tempo dallo DeathStar, quindi per moolto tempo il nodo in questione avrebbe tot cicli occupati in modo inutile, lasciando quindi meno risorse per gli smart contract "veri"... potrebbe essere addirittura meglio... una sorta di "gramigna" nei nodi, difficile da estirpare....

bisognerebbe capire come un nodo assegna le sue risorse hw ai vari smart contract. Non è che assegna un tot di cicli ad ognuno e poi passa a quello successivo? Perché se così fosse l'unico risultato sarebbe un rallentamento nella terminazione di quel contratto. O sbaglio? Non ho la minima idea del design di un nodo ether.

Ho due o tre idee... ma prima, essendo un tipo pratico, non mi accontento della teoria.

Vorrei quindi vedere in un ambiente di test che cavolo succede. La prima domanda e'...
che impatto ha DAVVERO su una EVM un ciclo del genere?

Sai, questi hanno voluto mettere su un "computer" di dimensioni mondiali... con un'unica
leva di comando, che sono le fee, i programmi che sono tutti virus e che non si possono manco modificare.

Ora qualsiasi sistemista che abbia lavora piu' di un giorno su un server, sa che in realta'
servono tanti accorgimenti per gestire tante risorse... comandi per assegnare i processori, la ram,
lo storage, le quote, le priorita' dei processi, comandi per sospendere, per killare, per riavviare,
programmi di monitoraggio e test.... e non sto qui a tediarvi con l'infinita lista di tarature
che bisogna fare.

Ora ditemi voi: su ethereum ci sono circa 1.500.000 (si un milione e mezzo) di smart contract,
senza nessuna altro meccanismo di controllo a parte sto' cazzo di gas da pagare.

Sono proprio curioso di vedere come cavolo impatta sto' loop micidiale su una EVM vera.

Sono proprio curioso di vedere come cavolo impatta sto' loop micidiale su una EVM vera.

Bene, a questo punto che si fa? Lo butti in esecuzione in rete?
Cerchi Ethereum? Scusami no guarda ho lasciato il portafoglio a casa, sono uscito solo un secondo a fare due passi...

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