Stato DISASTROSO rete ethereum

[gbianchi]

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

[acquafredda]

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.

[jack0m]

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 sarebbere le contromisure? Immagino, per l'ennesima volta, che ciò richieda in HF per attuare eventuali correttivi.

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

[fillippone]

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 sarebbere le contromisure? Immagino, per l'ennesima volta, che ciò richieda in HF per attuare eventuali correttivi.

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

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?

[acquafredda]

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.

[alexrossi]

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  

[gbianchi]

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

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

[gbianchi]

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.

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)

[gbianchi]

Finalmente ho una versione compilabile del codice.

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(loop001)
       }
     }
   }

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 61004f565b5600a165627a7a72305820ee78c2a05eeec0067f21c039d9876e47f4397627e2469cd f45407ae4e91422090029

     
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

sub_0: assembly {
        /* "death":26:16255  contract DeathStar... */
     mstore(0x40, 0x60)
      calldataload(0x0)
      0x100000000000000000000000000000000000000000000000000000000
      swap1
      div
      0xffffffff
      and
      dup1
      0x4b489b32
      eq
      tag_2
      jumpi
    tag_1:
      invalid
        /* "death":53:16250  function DeathLoop() public... */
    tag_2:
      jumpi(tag_3, iszero(callvalue))
      invalid
    tag_3:
      tag_4
      jump(tag_5)
    tag_4:
      stop
    tag_5:
        /* "death":172:179  loop000 */
    tag_7:
        /* "death":188:195  loop001 */
  

[fillippone]

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

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

[gbianchi]

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

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

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.

[fillippone]

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

Non rimane che mandarlo in esecuzione allora?
Io non trado shitcoin....ma magari qualcuno che vuole darti fiducia potrebe essere interessato a sapere quando farai questo test....

[jack0m]

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

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

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.

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.

[fillippone]

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.

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

[jack0m]

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.

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

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

[fillippone]

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.

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

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

Ma quale è l'obiettivo? Bloccare la rete Ethereum? e come si ottiene? Con un hard crash? o soffocandola piano piano?
Comunque è interessante vedere cosa succede e come in effetti viene parallelizzato il computo tra i diversi punti di accesso al sistema (si possono chiamare nodi? E quali sono? Solo i nodi validatori? Quei famosi 12 nodi nel mondo??).

[gbianchi]

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.

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

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

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 con
certe istruzioni, guarda caso legate all'uso di jumpdest (che apparentemente e' l'istruzione piu' innocente del mondo), 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?

 

[jack0m]

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.

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

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

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?

 

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.

[gbianchi]

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.

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 )

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)

[jack0m]

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.

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 )

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)

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