ElectroYou

Parlando di futuro, mi sono sentito "in dovere" di lanciare la provocazione.

Ho solo sorvolato il thread. Di cryptovalute non ne capisco molto, ma ho lavorato in passato proprio su progetti di hashing su ASIC (era il tempo del "concorso" del NIST per la definizione di SHA-3, ho implementato tutti i candidati del secondo round in VHDL). Non siamo stati i soli e le sorgenti si trovano facilmente (anche per altri algoritmi). L'ASIC e l'algoritmo sono l'ultimo dei problemi.
La domanda è che interfaccia ci metti con il mondo esterno. Ripeto che sono a digiuno di blockchains & co. Benché lo trovi un tema interessante non ho il tempo di occuparmene. I chip che ho prodotto erano classici: entra un data-stream ed esce un hash. L'ottimizzazione era fatta per il throughput, quindi l'interfaccia diventava facilmente il collo di bottiglia (Keccak fagocitava oltre 40 GBit/s in ingresso). Anche se questo non dovesse essere un problema, se vuoi vendere all'industria, l'interfaccia deve essere standardizzata e flessibile.

A proposito di recupero del calore: ho lavorato sopra ad un data-center e tutto il riscaldamento (necessario, visto che eravamo in mezzo alle montagne della Svizzera centrale) dell'edificio, così come acqua calda, docce, eccetera era generato dai server.

Dove lavoro adesso abbiamo l'aria compressa centralizzata per la produzione e anche qui riscaldamento e acqua calda sono generati dai compressori (OK, non c'entra un fico secco )

Un altro concetto interessante è quello del raffreddamento ad acqua calda. Componenti di grado industriale lavorano bene fino a 125°C (piú o meno) ed è quindi insensato raffreddarli a 30-40°C. Qui il raffreddamento viene fatto con acqua a 80°C proprio per utilizzarla per il riscaldamento: https://www.zurich.ibm.com/microserver/

Saluti, Boiler

Nel caso di Bitcoin l'interfaccia non è un gran problema perché essenzialmente è necessario caricare 1 MB ogni 10 minuti.

Questo perché la PoW di queste piattaforme consiste nel trovare un hash che sia minore di un certo valore.

In pillole, supponiamo di avere un blocco di dati contenente un certo numero di informazioni, l'operazione di convalida del blocco, consiste nel trovare un numero intero, diciamo a 32 bit, che se accodato alla sequenza di bit del blocco da convalidare, restituisca un hash che sia minore o uguale di un certo valore. Giacché non c'è modo di determinare l'input di una hash function che restituisca un output desiderato, l'unico modo di trovare questo input è provarli tutti quanti.

Nel caso di Ethereum le cose si complicano, un buon punto di partenza potrebbe essere lo studio dello soluzioni adottate dai produttori di gpu, e valutare possibili ottimizzazioni del caso particolare.

Comunque il problema esiste ed è sicuramente cruciale, ti ringrazio per averlo sollevato.

OK, ho capito, grazie.

Dimenticavo una cosa: andrei sul VHDL, non su Verilog.
Verilog viene ancora usato spesso negli Stati Uniti per motivi storici, ma il grosso dell'industria preferisce VHDL.

Boiler

DanteCpp ha scritto:Nel caso di Bitcoin l'interfaccia non è un gran problema perché essenzialmente è necessario caricare 1 MB ogni 10 minuti.
....

In realtà non è proprio così.
Oggi le cose sono divise tra la Pool e gli apparati di Mining.
La pool ha un "server" che prepara il nuovo blocco, controlla la congurenza delle operazioni e quindi calcola
il Merkle Root, con Sha-256.
Poi tutte le info vengono messe sull'header del Blocco (se non erro, sono 80 Bytes), ed è questo che viene
inviato ai minatori che fanno parte della Pool (indipendentemente che siano interni alla farm od esterni).
In pratica la generalità dei minatori bitcoin calcolano lo SHA-256 solo sull'header, quindi non vedono com'è fatto l'intero blocco .

PS : i capannoni di mining NON sono climatizzati, sono solamente ventilati.

Scusate, prima ho provato a rispondere dal telefono con scarso successo.

Comunque si, nel caso di pool mining funziona cosi, comunque volendo ideare un dispositivo che possa lavorare anche indipendentemente, l'input è 10 MB al minuto in media. Se nel lavorare collettivamente qualcuno si prende carico di prepararmi l'header di 80 B, ben venga!

Che poi il caso di lavoro solitario è anche facile da "pipelinezare" perché mentre si convalida su un blocco si può preparare il Merkle Tree del blocco successivo, operazione comunque di peso ridicolo rispetto alla ricerca dell'hash.

Comunque quella di 1MB ogni 10 minuti è un caso peggiore che ho voluto dare per non entrare in picchiata sui dettagli!

DanteCpp ha scritto:....Comunque si, nel caso di pool mining funziona cosi, comunque volendo ideare un dispositivo che possa lavorare anche indipendentemente, l'input è 10 MB al minuto in media. Se nel lavorare collettivamente qualcuno si prende carico di prepararmi l'header di 80 B, ben venga!
Che poi il caso di lavoro solitario è anche facile da "pipelinezare" perché mentre si convalida su un blocco si può preparare il Merkle Tree del blocco successivo, operazione comunque di peso ridicolo rispetto alla ricerca dell'hash.
Comunque quella di 1MB ogni 10 minuti è un caso peggiore che ho voluto dare per non entrare in picchiata sui dettagli!

Il minatore solitario non ha sufficienti macchine per competere con tutti gli altri minatori (che poi a loro volta sono riuniti nelle pool). La sua potenza di calcolo sarà sempre una quantità trascurabile.
Pertanto gli sarà praticamente impossibile azzeccare l'hash di un qualunque blocco prima degli altri miners.
Le probabilità sono a suo netto sfavore, quindi non incasserà mai nulla se non in caso di un estemporaneo colpo di fortuna.

Pertanto, prima di iniziare la progettazione di qualunque cosa, devi fare un bilancio costi-benefici.
Il tuo FPGA potrebbe funzionare, ma se poi non rende economicamente, a che serve ?

Come ho detto, nel contesto dell'interfaccia chip mondo esterno, volevo dare un indicazione di caso peggiore. Non ho detto che quella sia la strada da seguire.

L'FPGA va intesa solo come piattaforma di prototipazione, non è il risultato finale. Per intenderci, il risultato finale non vuole essere neanche il dispositivo in se, bensì il progetto open-source.

Il guadagno non vuole essere economico (almeno in prima battuta), bensì culturale. Tecnici esperti in tecnologia blockchain sono sempre più richiesti, un background in un progetto open-source che potrebbe raggiungere una certa notorietà, è una buona freccia nella propria faretra.

Uno Speciale Tg1, leggero e interessante.

DanteCpp ha scritto:Come ho detto, nel contesto dell'interfaccia chip mondo esterno, volevo dare un indicazione di caso peggiore. Non ho detto che quella sia la strada da seguire.
L'FPGA va intesa solo come piattaforma di prototipazione, non è il risultato finale. Per intenderci, il risultato finale non vuole essere neanche il dispositivo in se, bensì il progetto open-source.
Il guadagno non vuole essere economico (almeno in prima battuta), bensì culturale. Tecnici esperti in tecnologia blockchain sono sempre più richiesti, un background in un progetto open-source che potrebbe raggiungere una certa notorietà, è una buona freccia nella propria faretra.

Intendevo dire che il progetto dovrebbe partire con il piede giusto, altrimenti rischi di fare un progetto stile scolastico, cioè puro esercizio ma inutile nel mondo reale.

Qualunque progetto che tu decida di fare, anche la costruzione di un palazzo, deve analizzare 1000 cose,
Se vuoi avere "successo", Inutile perder tempo a progettare i cementi armati se poi nell'area non sono ammessi i palazzi alti oltre 2 piani !
E soprattutto, un progetto deve partire dalle esigenze che cerca il mercato.
Tu vuoi fare un FPGA Open Source, OK, ma in quale nicchia di mercato andrebbe a collocarsi ? Chi sarebbero i possibili utenti che lo vedrebbero come un vantaggio ?
ecc..ecc...
Se parti con il piede giusto, questo poi si traduce anche in un ritorno economico, oltre che un ottimo biglietto da visita. Altrimenti se progetti un dispositivo antieconomico e che nessuno è interessato ad avere, non ti porta nessun vantaggio,
Anzi diventa per te una pessima pubblicità