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

Sì ma tanto di ETC non frega niente a nessuno, quindi anche se una cosa del genere dovesse funzionare nessuno si strapperebbe le vesti per l'indelicata dipartita di Ethereum Classic che poi è l'Ethereum originale.
La tua ipotesi, se funzionante, deve essere considerata solo ed esclusivamente su ETH.
A giudicare dalle non-risposte ottenute dal tuo post sulla board internazionale non c'è un minimo interesse.
Ma sappiamo bene che quella board è piena solo di utenti di bassa lega.

Ricordo quando lanciammo il thread sulla riserva frazionaria...quello sì che fece rumore sulla board internazionale. Be your own bank divenne forte anche dopo quel thread.
Ma erano ancora i tempi in cui si veniva sul forum per capire.

Sono arrivato ad una versione di DeathStar che con 10.000.000 di gas sta in pausa 0.2 secondi:

--input 6e62ff3500000000000000000000000000000000000000000000000000000005  run

EVM gas used:    10000000
execution time:  201.290923ms
allocations:     42
allocated bytes: 94476
0x
 error: out of gas

10.000.000 di gas e' vicino al limite che si puo' mettere in un unico blocco quindi abbastanza realistico (massimo 15.000.000 di gas per blocco)
ovviamente bisogna fare una raffica di transazioni dethstar.

Al costo che uso ultimamente di 50 gwei per gas, con 0.5 eth si congestiona un nodo per 0.2 secondi. (e quindi poi anche tutti gli altri quando la transazione viene inclusa in un blocco)
quindi con 1 eth sono 0.4 secondi. 10 eth 4 secondi 100 eth 40 secondi 1000 eth (3.300.000$ ad oggi) sono 400 secondi  , ossia poco meno di 7 minuti.

Secondo me sono costi altamente sotenibili per il tipo di danno che si puo' fare.

--------

Ma come aveva suggerito qualcuno (non ricordo chi) con la rete ethereum classic ... sono cazzi!

Il loro client ufficiale e' core geth, l'ho guardato e nella struttura la EVM e' praticamente identica a quella di geth,
quindi DeathStar dovrebbe girare con le stesse performance

il loro costo gas e' molto basso... diciamo 5 gwei ma anche meno. e il costo di un etc e' 63$
quindi 10.000.000 di gas * 5 gwei = 0.05 etc per 0.2 sec.
quindi con un etc sono 4 secondi.  con 1000 etc si tengono congestionati i nodi per  circa 4.000 secondi ossia 66 minuti.
(che sono 63.0000$ una cifra direi risibile per quello di cui stiamo parlando, ricordiamoci che pur sempre una rete da alcuni miliardi di dollari)


EDIT trovato:

infatti uno delle decine di problemi che ha ethereum e' che al miner non converrebbe aspettare l'esecuzione degli smart contract del blocco minato...
perche' rischia che nel frattempo altri miner trovino un hash giusto e gli "soffino" la possibilita' di generare il blocco
(se leggi a fondo il documento che ho postato precedentemente e' uno dei tanti punti deboli del protocollo)


 

mmm... io pensavo che se un nodo si fosse accorto che quello smart contract va in errore perché out of gas, lo avrebbe flaggato come invalido senza neanche propagarlo in rete, quindi che il miner non lo avrebbe ricevuto... per quello mi chiedevo che fine facesse il gas sprecato. Quindi non si rallenta solo la validazione e la propagazione in rete delle transizioni e dei cambi di stato, ma anche la generazione dei nuovi blocchi: un bel casino totale!

Lo stesso smart contract viene eseguito in modalita' "mono-thread"
quando il miner trova un hash risolutivo (mina un blocco) deve parlare con un nodo, assemblare un blocco (mettendo assieme tutte le transazioni che ritiene convenienti)
ed eseguirlo sul nodo per determinare i costi  reali finali. E finche questo smart contract non finisce, il blocco non puo' uscire, anche se in un ambinete multithread magari
gli altri smart contract sono finiti da un pezzo.

Poi appena il blocco viene finalizzato, viene propagato in rete, dove ogni altro nodo deve rifare la stessa cosa.

nel frattempo ho delle interessanti novita'.

Avendo ora la possibilita' di fare dei benchmark, ho potuto fare dei test ed esperimenti.

Mentre l'idea di base di deathstar e' valida e funziona, ossia un loop che dura finche' non finisce il gas,
si puo' perfezionare un altro concetto:

io ho lavorato sul concetto di "ripetere l'operazione che costa di meno"

invece devo lavorare sul concetto "ripetere l'operazione che ha il maggior rapporto durata/costo"
Purtroppo questo dato si ottiene solo sperimentando e guardando l'implementazione dell'EVM,
non e' un dato pubblicato su nessun paper.

ho gia' una versione di deathstar che a parita' di costo dura ben 18 secondi (il doppio della prima versione)
e credo che si possa ancora fare parecchio.



EVM gas used:    1000000000
execution time:  18.474124538s
allocations:     48
allocated bytes: 14912
0x
 error: out of gas

Magari bloccandola nel momento giusto... magari quando c'è un pò di casino già su DeFi si potrebbero fare più danni. Ovvio che il costo del gas in quel momento sarebbe più alto, e quindi l'efficacia ulteriormente ridotta...

Chi conosce qualche massimalista massimalista ricco?

scusa, non so se ho capito bene. Stai dicendo che il validatore prende tutti gli smart contract in successione, e continua ad eseguirne uno finché non finisce il gas? Non c'è nessuno scheduler o meccanismo di parallelizzazione dei task che assegni le risorse di calcolo in maniera equa e distribuita fra i diversi contratti?

Quindi con meno del 10% del valore in dollari scambiato giornalmente dalle pair ETH potremme sfasciare definitivamente i sogni degli altocoiners. Io penso che un gruppo di massimalisti spinti che vogliono testare la macchina infernale lo si possa trovare.
Ho una domanda: ma deathstar ha mitigazioni possibili o l'unica è un HF che modifichi tutto ciò che lo permette under the hood?

edit: rileggendo quindi ho capito che non sfasciamo niente in realtà ma saremmo in grado di bloccare l'operatività della macchina per un tempo n.

ragazzi, ho finalmente dei dati.

una piccola soddisfazione personale: deathstar FUNZIONA PERFETTAMENTE sulla EVM di geth 1.10.8 (l'ultima versione fresca  fresca)
il loop continua finche' non arriva ad out of gas!!!

ho lanciato dei benchmark ...

con 1.000.000.000 di gas  ecco i risultati:

evm version 1.10.8-stable
root@ubuperfcheck:/home/sistemi/eth# ./run
EVM gas used:    1000000000
execution time:  9.017201832s
allocations:     41
allocated bytes: 10248
0x
 error: out of gas

quindi se supponiamo gas=50 gwei  con 50 eth si tiene ferma la rete per circa 9 secondi
(ricordiamo che il controllo lo devono fare TUTTI i nodi)

con circa 500 eth (aka 1.500.000$ cira) sono 90 secondi....

Secondo me e' un attacco che puo' funzionare, non ha un costo totalmente proibitivo.
C'e' cente che trada con decine di milioni di $!!!

guarda che se ti vuoi immolare per la causa non saremo certo noi a fermarti, ne guadagneresti un monumento al merit a imperitura memoria

Per non parlare poi di una cosa assolutamente odiosa di ETH che non so se ancora è così. Facendo transazioni con gas basso in tempi di congestione, le transazioni venivano sistematicamente rigettate e si perdeva il gas connesso. Non ho nemmeno idee se quel gas comunque finisse ai miner o diosolosa cosa succedeva alle tx failed.
Più lo si guarda con occhio attento e più ETH impallidisce alla simil-perfezione di btc.

Aspettate, si parla coi dati in mano.

Il client piu' eseguito nella rete ethereum e' geth.

Ho tirato giu' i sorgenti di geth per vedere se riesco a fare un benchmark di DeathStar che gira su geth
per poi fare dei calcoli di quanto costerebbe davvero far girare DeathStar e fare danni
(almeno ai nodi geth... ma credo sia piu' che sufficente sono il 74% dei nodi:  https://ethernodes.org/ )


Intanto ad una prima sommaria "guardata" vi posso dire che l'implementazione della
EVM in geth fa cagarissimo. Praticamente il ciclo di fetch delle istruzioni e' un orrendo loop
che estrae ad una ad una le istruzione della EVM e le esegue, e ricalcola il gas rimasto.

Una roba da far rabbrividire che secondo me ha delle prformance orribili con un overhead mostruoso
per ogni opcode EVM eseguito.

Mi state dicendo quindi che ce la stiamo conigliando e nessuno costruirà mai la nostra DarkStar?
Ci avevo sperato per un attimo di essere coinvolto nel "Big Short" su ETH.
Va bene, vorrà dire che aspetteremo che la storia faccia il suo corso.

a me e' piaciuta di eth l'idea degli smart contract, devo essere onesto..
ma eth in se, mi fa veramente cagare, non mi piace tecnicamente e non mi piace la direzione presa
pero - ripeto - gli smart contract sono una idea molto figa

99% di chi scrive in quella sezione lo fa esclusivamente per le signature.
98% dei progetti sono shitcoin ne piu ne meno.
 il livello generale .... è infimo.
non sorprende che sia quasi impossibile intavolare una discussione di senso compiuto.

credo che hai centrato il punto. un attacco del genere è costosissimo, richiede tanti ETH disponibili ed una posizione short ENORME.
senza short è un semplice sabotaggio, estremamente costoso. per quanto affascinante in linea teorica, totalmente impraticabile/inutile ai fini pratici..
con il rischio concreto di generare solo fee di spesa e non influenzare nulla a conti fatti.

Sì, concordo pienamente e penso tu abbia centrato esattamente il punto. Ho ritrovato un articolo che avevo letto tempo fa sul tema delle vulnerabilità maggiori di ETH. Lo riporto qui di seguito in ita.
Il gruppo NCC ha lanciato un'iniziativa chiamata DASP per Decentralized Application Security Project nel 2018. Copre le 10 principali vulnerabilità trovate negli smart contract in esecuzione sulla blockchain di Ethereum:

1. Reentrancy: Si verifica quando le chiamate di contratti esterni possono effettuare nuove chiamate al contratto chiamante prima che l'esecuzione iniziale sia completa. Per esempio, chiamiamo un'altra funzione prima di aggiornare il valore del contratto (successo con TheDAO);
2. Controllo dell'accesso: Quando lo smart contract viene creato, il proprietario deve essere impostato correttamente e in seguito devono essere messi in atto controlli sufficienti per permettere che certe funzioni siano eseguite solo dal proprietario;
3. Problemi aritmetici: Gli integer underflows o overflows potrebbero essere un problema quando si tratta del valore del contratto.
4. Valori di ritorno non controllati per le chiamate di basso livello: Le funzioni di basso livello call(), callcode(), delegatecall() e send() possono restituire dei false. Dobbiamo verificare il valore di ritorno prima di assumere che sia stato eseguito con successo;
5. DoS: Quando si tratta di smart contract, i prezzi del gas sono importanti. In un attacco DoS per smart contract, il prezzo del gas è superiore al prezzo massimo consentito. Pertanto, il contratto non può essere eseguito;
6. Bad Randomness: Gli smart contract come ricordavamo sono aperti pubblicamente sulla blockchain. Non vanno codificate logiche pseudo-casuale su di essi oppure utilizzare un oracolo esterno come fonte di entropia;
7. Front-Running:  Gli utenti possono specificare tariffe più alte per avere le loro transazioni minate più velocemente degli altri. Un utente malintenzionato può superare un'altra transazione inviando la sua transazione con tariffe più alte per prevenire la transazione originale;
8. Manipolazione del tempo: Se c'è una dipendenza temporale incorporata nello smart contract, un minatore malintenzionato potrebbe tenere il suo stake per adattarsi al timestamp specificato;
9. Attacco all'indirizzo corto: Gli indirizzi dei contratti smart sono uint256, se uno sviluppatore usa solo uint l'EVM riempirà di zeri i byte rimanenti manipolando l'indirizzo del destinatario;
10. Qualsiasi altra cosa dato che Solidity è un nuovo linguaggio informatico e tutto può succedere.

https://www.dasp.co/

siccome di gente con capacità tecniche sufficienti non credo che manchi, e lo dimostrano i vari hack avvenuti in passato a partire da TheDao fino ai più recenti su Defi, mi sono dato 2 possibili spiegazioni: o un attacco del genere è stato già tentato, mentre noi diamo per scontato di no, ma non ha avuto gli effetti sperati (dall'attaccante) e sostanzialmente si è perso nel rumore di fondo delle varie dApp e crittogattini che intasano già di loro la rete ethereum, oppure qualcuno ha valutato che è più profittevole avvantaggiarsi di altre vulnerabilità citate anche in questa discussione (dark-forest, MEV, ...), evitando di affossare la rete e di conseguenza il valore di ETH. In fondo perché buttare giù il valore di qualcosa che può essere spremuto ai danni della massa inconsapevole degli utilizzatori?

Ma queste considerazioni riguardano forse lo 0,01% di chi si interessa ad ethereum, gli altri non si pongono neanche il problema e sembrano accecati dal miraggio delle promesse rivoluzionarie confidando in un pump senza fine. Basta leggere le discussioni in tema nella sezione alt, dove ho cercato inutilmente di linkare quel thread senza che nessuno lo degnasse di uno sguardo, pare che abbiano un filtro incorporato per i commenti non allineati. Boh...

Con i se non si va da nessuna parte ma se tutto questo fosse vero davvero non si spiega come nessuno abbia interesse ad affossare definitivamente ETH. O tutti quelli che potrebbero farlo hanno interesse a mangiarci sopra fin quando possibile, oppure davvero non si trova un nesso logico in tutta questa faccenda. Sinceramente, per quanto mi riguarda mi dispiace solo di non averci fatto soldi sopra quando era possibile. Occasione mancata per aver più btc, tanti più btc.

allora, dunque, fammi cercare... ooops, ho lasciato il wallet nell'altro hard disk