Stato DISASTROSO rete ethereum

[gbianchi]

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.

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

[1714021592]

1714021592

[jack0m]

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

[gbianchi]

Girovagando in cerca di info:

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

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

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

[fillippone]

Se qualcuno vuole iniziare...

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

uhhh grazie!!!

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.

[Makkara]

Ok bianchi hai ragione tu allora. 

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

cosi' magari gli passa anche la spocchia a gbianchi 

[acquafredda]

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.

[gbianchi]

Potete partire da questo ed usarlo e modifcarlo.

TI ho messo qualche nota, guarda se le vedi

[fillippone]

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?

[gbianchi]

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

[fillippone]

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.

[gbianchi]

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.

Ok perfetto, poi quando me la manderai prima la posto qui per vedere che faccia fa, poi se va bene creo un thread nella sezione alt-coin internazionale.

qui per capirci : https://bitcointalk.org/index.php?board=67.0

(o sai se c'e' una sezione piu' adatta?)

[acquafredda]

Va bene sezione alt-coin, dato che shitcoin ancora non c'è 
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.

[gbianchi]

Va bene sezione alt-coin, dato che shitcoin ancora non c'è  
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.

Grazie, appena lo hai controllato dillo a filippone che mi prepara il formato "postabile"

Nel frattempo mi appunto qui qualche link che sono certo mi verra' utile,
si parla delle funzioni "pure" (e' proprio una sintassi di solidity)
ossia le funzioni che non leggono ne' scrivono sulla blockchain,
ma sono esclusivamente computazionali.


https://ethereum.github.io/yellowpaper/paper.pdf (sezione 6 dello yellow paper modalita' di esecuzione degli smart contract)
https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/mining/
https://medium.com/mycrypto/the-ethereum-virtual-machine-how-does-it-work-9abac2b7c9e
https://ethereum.stackexchange.com/questions/357/does-every-node-execute-the-contract-code-for-each-transaction
https://ethereum.stackexchange.com/questions/52885/view-pure-gas-usage-cost-gas-if-called-internally-by-another-function
https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call/770
https://blog.b9lab.com/calls-vs-transactions-in-ethereum-smart-contracts-62d6b17d0bc2
https://infernaltoast.medium.com/how-bitcoin-and-ethereum-solved-the-halting-problem-differently-cffbb4e3045c
https://www.quora.com/Why-is-Bitcoin-not-Turing-complete

Da non includere
https://raw.githubusercontent.com/chronaeon/beigepaper/master/beigepaper.pdf
https://hugonguyen.medium.com/why-ethereum-architecture-is-flawed-d4eefd15db3e
https://ethereum.stackexchange.com/questions/78310/smart-contract-execution-without-making-transaction-on-ethereum-blockchain
...

[fillippone]

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

Aggiunti, insieme al yellow-paper, in una sezione REFERENCES alla fine del documento.
Così sembra molto più professionale.


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:

Differences Between a White Paper, Yellow Paper, and Beige Paper

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.

[gbianchi]

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:

Si, anche se (come ho gia' scritto) assomiglia un po' alla scritta sul muro della fattoria degli animali...
per essere buoni diciamo che e' abbastanza fluido. Infatti lo tengono in github.

Io nel frattempo ho fatto qualche piccola modifica al codice per renderlo piu' facilmente utilizzabile,
e anche meno palesemente "inutile" (per rendere un po' piu' difficile un'eventuale individuazione automatica)


EDIT

ecco una lista delle versioni
https://github.com/ethereum/yellowpaper/blob/master/BRANCHES.md


che mostra che e' stato gia' fatto questo hard fork  (tangerine-wistle)  
con aumento di costi per istruzioni


    Increase the gas cost of EXTCODESIZE to 700 (from 20).
    Increase the base gas cost of EXTCODECOPY to 700 (from 20).
    Increase the gas cost of BALANCE to 400 (from 20).
    Increase the gas cost of SLOAD to 200 (from 50).
    Increase the gas cost of CALL, DELEGATECALL, CALLCODE to 700 (from 40).
    Increase the gas cost of SELFDESTRUCT to 5000 (from 0).
    If SELFDESTRUCT hits a newly created account, it triggers an additional gas cost of 25000 (similar to CALLs).
    Increase the recommended gas limit target to 5.5 million.
    Define “all but one 64th” of N as N - floor(N / 64).
    If a call asks for more gas than the maximum allowed amount (i.e. the total amount of gas remaining in the parent after subtracting the gas cost of the call and memory expansion), do not return an OOG error; instead, if a call asks for more gas than all but one 64th of the maximum allowed amount, call with all but one 64th of the maximum allowed amount of gas (this is equivalent to a version of EIP-901 plus EIP-1142). CREATE only provides all but one 64th of the parent gas to the child call.


e questo hard fork spurious-dragon ha aumentato il costo di EXP

[Plutosky]

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

[gbianchi]

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

infatti la modulazione di costi degli opcode e' un tema fisso (anche se per nulla publicizzato)
degli hard fork. QUi ad esempio definisce
https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/berlin.md
una nuova rimodulazione del costo degli opcode.

Effettivamente l'assegnare un costo "adeguato" agli opcode dovrebbe essere una funzione dinamica,
in base all'utilizzo medio. Il solo fatto di avere degli opcode a costo prefissato e' un errore progettuale non da poco.

Supponiamo che la mia strategia di attacco funzioni, e che la soluzione sia di aumentare il costo dell'opcode "jumpdest" con un hard fork.
Ma immediatamente si puo' riproporre un attacco del genere su un altro tipo di opcode appena piu' costoso.

E cosi' via all'infinito.


 

[acquafredda]

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

[fillippone]

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.

[Plutosky]

 

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