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

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

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?

TI ho messo qualche nota, guarda se le vedi

Grande fillippone, poi la riguardo anche io con calma.   
Non capisco perché si parli di spocchia: qui qualcuno sta cercando semplicemente di testare (e con questo verificare e validare) una rete che dovrebbe essere permissionless e open source. Se dobbiamo prenderla per buona... Stiamo freschi.

cosi' magari gli passa anche la spocchia a gbianchi 

Prima versione.
Tieni conto che stocrollando dal sonno.
Potete comunque commentare eventuali suggerimenti.

https://docs.google.com/document/d/1lVAFE-2RjhTqPS8P58ZaW8uBE2bhWz-3n0ksZRJ39Wk/edit?usp=sharing

Potete partire da questo ed usarlo e modifcarlo.

Ps. è una prima bozza... sto letteralmente crollando dal sonno, alla mia età certi sbattimenti potrebbero essermi fatali.

Girovagando in cerca di info:

https://ethereum.org/en/developers/docs/gas/


In queste righe della documentazione ufficiale, dicono candidamente che uno degli scopi per cui si pagano gas e' anche evitare loop infiniti.
Anzi, era proprio previsto ESATTAMENTE QUESTO CASO: hostile infinite loops

questo vuol implicitamente dire che e' possibile fare loop infiniti, e come ho scritto terminano quando si e' finito il gas.
e vuole anche dire che il loop si puo' lanciare e che l'unico meccanismo di salvataggio  e' quanto ci si e' disposti ad investire rispetto ai danni che si possono fare.

Ora la partita e' fondamentalmente nel vedere se avevano previsto una rete gia' di per se congestionata
e un loop altamente ottimizzato (o pessimizzato a seconda dei punti di vista) al costo medio per opcode di un gas.
e un mercato da centinaia di miliardi di dollari, dove gruppi potrebbero investire cifre stratosferiche in una operazione destabilizzazione.

Vedremo.

PS: C'e' anche un errore logico: se ethereum e' permissionless, e la gente puo' immettere qualsiasi smart contract basta che paghi,
perche dovrebbero essere dei "Bad actors"? questo vuol dire non avere le idee chiare... bad actors e' un giudizio morale...
ma se pago e seguo le regole del network io non sono un bad actor, oppure mi crei delle regole per NON POTER FARE certe cose.
Quali sono le azioni Bad e quelle Good? Non mi pare che rientri nelle regole di consenso dei nodi. Lo decide Buterin?


PPSS: piu' leggo queste cose e piu' mi puzza puzza puzza che abbiano eradicato certe istruzioni dai nuovi compilatori solidity

Hai provato a guardare qua se certe parti sono spiegate un po' meglio?

https://github.com/ethereumbook/ethereumbook

Ce l'ho nella mia lista da anni, ma finora tempo zero per cominciarlo...

Effettivamente altrimenti che consenso raggiungono? Questa potrebbe essere un interessante sfida futura
(Certo che spacciare questo coso per un linguaggio completo... non puoi fare quasi un tubo)

e boh onestamente sono parti oscure anche a me, e per ora la lettura del yellow paper
(che e' l'unica fonte ufficialissima) non mi ha illuminato.

tra l'altro anche lo yellow paper mi sembra un po' come la famosa scritta sul muro della fattoria degli animali...
nel senso che e' su git  e quello attuale recita

"ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER ISTANBUL VERSION 80085f7 – 2021-07-11"

Giustamente si potrebbe dire, visto che sara' aggiornato all'ultimo hard fork.

Ma sarei curioso di vedere quante versioni ne esistono, e quanto cambiano una dall'altra

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.

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 e la jumpdest in assembler mi puzza proprio molto.

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

uhhh grazie!!!

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

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?]

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

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

Qui ho scritto (e modificato) un documento che adesso e' in versione quasi definitiva,
a parte qualche possibile modifica di stile o sintassi.

https://bitcointalksearch.org/topic/m.57748079

Se avete voglia di sbattervi, descrivo tutto con un notevole dettaglio.

Ora voglio tradurlo in inglese e postarlo nella sezione internazionale dedicata alle altcoin.

Ok bianchi hai ragione tu allora. 

I miner ethereum non eseguono nessun codice, i miner fanno solo il proof of work (come in bitcoin)
Il codice lo eseguono TUTTI  i nodi per arrivare al consenso (come in bitcoin TUTTI i nodi controllano che le transazioni siano giuste)
Makkara dice che il codice non ha senso, e infatti da un punto di vista computazionale non ha senso... ma l'ho scritto io almeno 10 volte.
lo scopo e' bruciare ethereum ad un costo per opcode il piu' basso possibile per competere con l'esecuzione degli altri smart contract


chi e' il soggetto che si accorge? Vitalik Buterin che tutte le sere controlla tutti gli smart contract prima di andare a dormire?
ho spiegato bene qual'e' il criterio di ethereum per terminare i loop infiniti.

Mi piacerebbe che visto che ho scritto una descrizione bella dettagliata, e ci ho speso anche del tempo
mi si facessero dei rilievi sensati, non robe dette a caso.