Topic: Stato DISASTROSO rete ethereum - page 19. (Read 6962 times)

Effettivamente non mi sono spiegato bene.

Attraverso i passaggi del mio studio sono reso conto che nonostante la cerenze del protocollo ethereum
siano ben note,  a nessuno interessa veramente affossarlo.

I pochi tentivi che ho fatto per discuterne seriamente mi hanno insegnato che non
c'e' il minimo interesse... o addirittura una vera e propria avversione a prendere in considerazione
il fatto che ethereum sia pieno di limiti (anche se la documentazione non manca di certo)

Allora ho pensato di trasformare deathstar, in uno strumento molto piu' sofisticato.

Visto che il mondo ethereum campa di hype piu' che di contenuti reali, facciamo la stessa cosa.

punti a favore:

1) esiste una vera base tecnica
2) esiste la possibilita' di fare il famoso short
3) lo stesso mondo di ethereum ha insegnato che e' possibile raccogliere capitali strabilianti anche per delle cazzate.

l'idea sarebbe di organizzare un crowdfounding, quindi raccogliere capitali,
per realizzare questo grande short...
e ignegnerizzare davvero sia la parte tecnica (e si puo' fare)
che quella finanziaria: ossia come raccogliere i capitali,
come organizzare lo short, i ritorni pensati ecc...

Poi curare bene la parte marketing con un ANNUNCIO urbi et orbi di questa cosa.
Se ben fatta,  penso che potrebbe avere molta risonanza,
molta di piu' di mille discussioni tecniche delle quali non frega un cazzo a nessuno,e che inoltre il 99% degli
utenti ethereum non e' in grado di capire.

mi viene in mente anche tutto uno sguazzare degli articolisti: "Bitcoin Contro Ethereum, chi vincera'?"
e cazzate del genere... proprio il tio di  fuffa di cui campano i fruitori della gran parte degli smart contract ethereum
(che tra l'altro non sono contratti e tantomeno smart... sono semplici programmi che girano, spesso molto malamente).

non ho capito, intendi idee non sugli aspetti tecnici ma sul reperimento di fondi per "caricare" l'arma?
o su come dare visibilità al progetto, che nella apposita sezione di questo forum è stato bellamente ignorato? Non pensi che si giunto il momento di pubblicarlo su qualche canale dedicato specificamente a Ethereum, per esempio su Reddit?

Adesso che sono certo che ci sono le basi tecniche, ossia la cosa non puo' essere catalogata come "cazzata"
ci vorrebbe un po' di "ingegneria" finanziaria e parallelamente di marketing.


Ossia, bisognerebbe progettare una sorta di crowdfunding finalizzato dichiaratamente a questo tipo di operazione,
con tanto di specifiche tecniche  ben pubblicate.

E mi piacerebbe che fosse un crowdfunding fatto usando tecnologie Bitcoin, non shitcoin.

Probabilmente farebbe piu' "rumore" dell'attacco stesso

E come ho ben dimostrato, nel mondo delle shitcoin conta solo il rumore,
il contenuto e' assolutamente ininfluente.

Ragazzi... potrebbe essere un progetto davvero importante... se avete idee e' il momento buono per tirarle fuori.

risposta breve... SI.

Risposta un po' piu' lunga: il voler implementare un linguaggio completo rende cosi' complessa
la gestione di tutte le possibili biforcazioni in un sistema distributo, da renderlo inattuabile.

Mi sono studiato i sorgeni di geth, e dentro e' un intreccio infernale di codice...
perche' dentro c'e' tutta la storia dei fork codificata... geth deve sapere come era la situazione
in ogni epoca

per un client di ethereum validare un blocco di una certa epoca, prima di un certo fork, era diverso
che validare un blocco ora, ma lui deve avere dentro tutte le logiche passate...

Ossia anche il codice stesso dei client diverra' immanutenibile per la complessita' che man mano accumula
ed e' cstretto a portarsi dietro.

Esatto.

Abbiamo l'esempio di ETC che ha subito attacchi di brute force del 51% a ripetizione, con tempi di conferma diventati biblici,  e vale ancora 7 miliardi di dollari.
Vale più di quanto valeva prima di subire gli attacchi 

Alla gente non frega niente se ETH sta ferma per un pò, loro hanno da comprare le scimmie mutanti.... e per farlo servono ETH (viste le fees).
Qualsiasi token muovi su Ethereum (dalle ICO, ai governance token, a Defi, agli NFT...) ti servono ether.
Ethereum è un immenso parco giochi dove per salire su ogni giostra ti serve sempre lo stesso gettone.
Fin quando il mercato andrà dietro a queste mode, il valore di Ethereum continuerà a crescere, nonostante i difetti.

Se a questo sommiamo 1) London che riduce l'offerta circolante e 2) l'accumulo dei 32 eth per il miraggio del passaggio alla POS.....
tutti artifici studiati a tavolino per accrescerne il prezzo.  

che torni lentamente alla normalità lo do per scontato anch'io, ma con le condizioni che ho specificato sopra si potrebbe sfruttare comunque per shortare su exchange, abbastanza in tempo per poi chiudere le posizioni su defi prima che vangano liquidate. Ovviamene la mia è una pura ipotesi, che si basa su qualche supposta vulnerabilità da sfruttare su defi.

Il mio timore è che una volta buttati i 250 ETH per bloccare la rete per un'ora, la situazione terminato l'attacco torni lentamente alla normalità.. con il prezzo he magari renche ne ha risentito.
Insomma.. abbiamo avuto un unintentional chain split ed il prezzo è al massimo storico! (contro USD, non contro BTC...): cosa ci fa pensare che un block stuffing attack avrebbe un risultato diverso?

Quindi riassumendo ETH si dimostra per quello che è: a livello teorico è una cagata pazzesca da far impallidire la gloriosa corazzata Potëmkin.
Un altro parallelo potremmo farlo con il titanic... ETH galleggia tranquilla finché qualcuno, durante una notte di nebbia, non vede l'Iceberg e...

Stavo riflettendo su una cosa. Questo lavoro rappresenta un mattone fondamentale per costruire un attacco potenzialmente devastante, ma che rimane per ora teorico per il vincolo imposto dal punto 2) elencato sopra.
Se però si trovasse un altro mattone, ovvero una vulnerabilità in qualche protocollo DeFi che permetta che quei 250 ETH/h vengano presi a prestito, anziché doverceli mettere in partenza, aggirando i vari meccanismi sui collaterali e i margini... BOOOOM!!

Una combinazione letale inarrestabile, anche perché finché la rete è bloccata, smetterebbero di funzionare gli stessi smart contract su DeFi che dovrebbero comportare la liquidazione forzata, ripristinando l'equilibrio: in pratica si verrebbe a creare un disallineamento fra ciò che succede sugli exchange, dove ETH potrebbe effettivamente crollare di valore, e sui Dex paralizzati dall'attacco. Una cosa simile è successa non molto tempo fa su BSC, dove un improvviso pump di un token su Binance ha destabilizzato il protocollo Venus causando liquidazioni forzate per 200M di USD. E lì non c'è neanche stato bisogno di bloccare la rete: figuriamoci se ci fosse stato un attacco concomitante di questo genere!

https://www.theblockcrypto.com/post/105301/bsc-venus-protocol-liquidations-xvs-token-possible-price-manipulation

Attacco block stuffing con DeathStar:

0) lanciare un proprio nodo geth: geth   --syncmode "light"  --mainnet
    si sincronizza in un attimo perche' non tira giu' nulla della blockchain precedente.
    servira' per essere autonomi e non passare da api proprietarie che potrebbero bannarci durante l'attacco.

1)  pre-caricare in rete un certo numero di smart-contract deathStar
ognuno ad un address diverso e con codice leggermente diverso,
per rendere impossibile sia il riconoscimento da parte delle mining pool che un possibile hard fork,
ossia  se ne viene riconosciuto e neutralizzato uno, si parte con un'altro.
(DeathStar_version_xxx, DeathStar_version_yyy ecc..)

2) Rimediare un numero consono di ETH; Ce ne vogliono CIRCA 250 all'ora (al costo gas attuale)
    e suddividerli su alcuni indirizzi che useremo come indirizzi origine delle transazioni.

3) Rimediare del pop-corn

4) crere uno script (python, perl, c, go.... un linguaggio a piacere) che usa chiamate RPC su geth
e fa piu' o meno le cose qui descritte sommariamente:

#
# se DeathStar_version_xxx smette di funzionare,
# passare a DeathStar_version_yyy e cosi' via.
#
CalledDeathStar=DeathStar_version_xxx
while( nuovo blocco minato)
   {
   legge la baseFeePerGas e il BlockGasLimit attuali.  
   calcola BlockGasBurned=BlockGasLimit-X (X serve per lasciare un piccolo spazio anche alle altre transazioni, da decidere se X > 0)
   crea una transazione con fee = BlockGasBurned * (BaseFeePerGas + Tip) ed esegue lo smart contract(CalledDeathStar, BlockGasBurned) da un indirizzo random di quelli origine.
       (dove tip e' la percentuale che va ai miner, diciamo il 20% per essere sicuri di essere inclusi velocemente
       e passa come parametro a CalledDeathStar BlockGasBurned per fargli bruciare esattamente i gas previsti,
       l'indirizzo origine varia  per evitare di essere riconosciti e bloccati facilmente, ricordare che in ethereum fanno HF praticamente ogni giorno)

   while (la nostra transazione non e' inclusa in un blocco minato)
     {
     opzionale
     usare tecniche MAV per controllare nella mempool che siamo davvero  i piu' competitivi,
     altrimenti alzare le fee alla transazione reimmettendo una transazione con la stessa nonce e Fee aumentate.
     }
   }

5) lanciare lo script

6) mangiare il pop-corn.

Note:

Ci ho messo un po' tutto quel che ho imparato in queste 2 settimane,
comprese (opzionalmente) le tecniche piu' avanzate di MAV.

Ametto che il punto 2 non sia banale, ma volete mettere la soddisfazione?

I punti 3 e 6 per quanto importanti non sono indispensabili

Infatti deathstar deve avere un parametro di input che dice quanto "gas" vuoi bruciare, per tararlo perfettamente ed adattarlo alla perfezione ad ogni blocco da minare.
In questo modo, puoi leggere dall'ultimo blocco minato quale sara' il limite di gas (GasLimit) e il costo di gas del blocco successivo (BaseFee), in base
alle ultime modifiche di London.

Poi lanciare una transazione DeathStar che cosuma esattamente quel gas (GasLimit - magari meno un pochino, per lasciare uno spazio risibile alle altre transazioni, oppure tutto... da decidere),
ad una fee gwei per gas di una certa percentuale superiore al BaseGas (BaseGas + x%) per essere sicuri di essere i piu' competitivi.

E comunque i miner invece che incluedere N transazioni piccole sono incentivati ad includerne una sola che renda molto... fanno prima.
Infatti seguendo questa logica e' meglio che DethStar sia eseguito velocemente. Ma non e' certo un problema.

Resta il fatto che con cifre molto piu' competitive di quel che pensavo all'inizio si puo' veramente mettere in grande difficolta' la rete per ore o anche giorni.

Come dicevo, in base a questi ultimi risultati, con un ordine di grandezza attorno un ETH puoi letteralmente COMPRARE un blocco... e quindi 15 secondi di tempo rete.

Altro dato interessante, tutta la programmazione necessaria per questa operazione (Solidity per deathStar + lo script che lancia le transazioni) rasenta veramente il banale,
non serve ne assembler EVM ne' nessuna tecnica particolarmente sofisticata  di codifica.

Questo thread non smette mai di stupirmi.

Quindi non solo il protocollo ha dei limiti notevoli, ma qusti limiti sono ben conosciuti ed attivamente sfruttati per profitto personale ai danni della rete.
Tutto questo accade mentre ETH continua a tradare invariato, anzi, con una dinamica bella bullish.

Tornand strattamente in tema, non mi è esattamente chiaro questo passaggio:


Devi quindi ottimizzare "la grandezza" di DeathStar per ottimizzare l'inclusione nel blocco? Se fosse una singola transazione enorme, magari verrebbe scartata dai miner, seppur legittima.


Inoltre , fa ridere la conclusione:


Di male in peggio.

Per terminare l'analisi tecnica di questo thread, mi sono chiesto come riempire al meglio i blocchi
con un loop di questo genere e mi sono reso conto che  visto che il blocco ha un limite di 15.000.000 di gas
(variabile dopo London ma non e' un problema)
se facciamo 15.000.000 * costo gas supponiamo 50 gwei = 0.75 ethereum.

se aggiungo una percentuale diciamo del 10% viene 0.85 eth.

In pratica cosa sucede ? ad un costo di poco meno di un eth creo una transazione che

1) viene scelta dai miner perche' pago piu' di tutti in termine di gas.
2) riempie tutto il blocco perche'  cosuma tutti i 15.000.000 gas che un blocco puo' al massimo contenere,
quindi non c'e' spazio per altre transazioni.

Alla fine, basta uno qualsiasi dei miei loop deathstar (senza neppure impazzire tanto sulle performance del loop)
con questo limite di gas da spendere. ad un prezzo leggermente piu' alto del mercato della fee in gwei.

Detto ancora piu' semplicisticamente: A poco meno di un ETH mi compro un blocco. e quindi circa 15
secondi del tempo di ethereum.

Molto meglio di quanto avevo inizialmente pensato!!! con 1.000 ethereum mi compro 15.000 secondi, ossia 250 minuti, ossia piu' di 4 ore.

Ad oggi non esistono rimedi contro questo attacco.

E questa e' anche la dimostrazione con prove che NON c'e' nessuno che vuol fare questo tipo di attacco,
altrimenti l'avrebbero gia' fatto, visto che e' ben documentato.

Viene solo usato sporadicamente come trucco, ad esempio per vincere a qualche gioco, se la posta in gioco ne vale la pena,
o magari per imbrogliare o ritardare qualche speculazione... ma mai sistematicamente per affossare la rete.


https://medium.com/hackernoon/the-anatomy-of-a-block-stuffing-attack-a488698732ae


https://dl.acm.org/doi/fullHtml/10.1145/3391195

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?