Stato DISASTROSO rete ethereum

[acquafredda]

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.

[jack0m]

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 $!!!

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?

[fillippone]

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.

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?

[gbianchi]

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

[gbianchi]

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 $!!!

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?

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.

[jack0m]

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 $!!!

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?

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.

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!

[gbianchi]

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 $!!!

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?

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.

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!

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)


 

[gbianchi]

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:

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.

[acquafredda]

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.

[gbianchi]

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

3.3.3 DoS with Block Stuffing (V31
). This vulnerability was first observed from the Fomo3D contract [23].
The vulnerability entails only the attacker's transactions being included in the newly mined blocks
while others are abandoned by miners for a period of time. This can happen when the attacker offers a higher
gasPrice to incentivize the miners to select the attacker's transactions. This vulnerability is caused by the greedy
mining incentive mechanism. At the moment of writing, there is no solution to prevent this vulnerability.

[fillippone]

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.

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:

Miners’ strategy for selecting transactions
Miners want to maximize their profit by including transactions with highest fees. In the current PoW implementation of Ethereum, mining the block takes significantly more time than executing the transactions. So let’s assume all transactions in the pool are trivially executed as soon as they arrive and miners know the amount of gas each one uses.

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:

(In a PoS system, our assumptions would be wrong since executing transactions is not trivial compared to validating blocks. Validators would need to develop more complex strategies depending on the PoS implementation.)

Di male in peggio.

[gbianchi]

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:

Miners’ strategy for selecting transactions
Miners want to maximize their profit by including transactions with highest fees. In the current PoW implementation of Ethereum, mining the block takes significantly more time than executing the transactions. So let’s assume all transactions in the pool are trivially executed as soon as they arrive and miners know the amount of gas each one uses.

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

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.

[gbianchi]

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

[jack0m]

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

[acquafredda]

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

[fillippone]

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?

[jack0m]

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?

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.

[Plutosky]

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?

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.  

[gbianchi]

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

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.

[gbianchi]

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

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.