ASIC open-source per la "hash-industry" del futuro/presente

[DanteCpp]

Il fenomeno della "hash-industry" si può facilmente mettere in analogia con quello che fu il fenomeno di elettrificazione. In principio c'era chi si organizzava in cantina il proprio generatore a carbone, immaginate: il rumore, il calore e il fumo, frutto dell'avere un dinamo o un alternatore, mosso da vapore prodotto bruciando carbone!

Bene, sappiate che oggi c'è chi si mette in cantina questi aggeggi, per "produrre" in casa un po di proof-of-work.
Che si debba andare verso la centralizzazione della "produzione" si è già capito, tant'è vero che i cinesi stanno tirando su questo genere di "industrie" già da tempo, come documentato ormai più di un anno fa in un articolo del nostro m_dalpra.

È abbastanza evidente l'inefficienza di questi stabilimenti, che consistono sostanzialmente di una messa in parallelo di moduli in principio ideati per lavorare indipendentemente.
Grande vantaggio si avrebbe in degli impianti ingegnerizzati da cima a fondo con lo scopo di massimizzare l'efficienza. Ad esempio dei sistemi di raffreddamento idraulici, che se pensati su piccoli calcolatori non hanno molto senso di esistere, ma applicati a livello industriale potrebbero rivelarsi vantaggiosi.

Mi sento abbastanza confidente nell'affermare che nel futuro nasceranno nuove aziende di progettazione, specializzate nella creazione di impianti di "hashing".

Tanto è il lavoro per ingegneri elettronici, elettrici, informatici, ma anche meccanici e chimici per la necessità di accurati studi termofluidodinamici.

Ora che ho blaterato un po di futurologie, la mia proposta è di progettare e magari prototipare dell' hardware specializzato per il calcolo delle funzioni di hashing. Da parte mia potrei dedicarmi al progetto del core-chip in verilog, che magari potrà essere prototipato su fpga.

Uno primo schizzo può essere

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

dove HM sta per hash module. Core-chip a parte, serve molto altro, come un sistema di controllo a cpu classica o micro per il controllo dei vari core-chip e per la comunicazione con il PC. Software per il controllo ad alto livello, elettronica di potenza per l'alimentazione, elettronica analogica di bassa potenza per la generazione dei segali di clock e tutta l'insalata di contorno.

Cosa ne pensate? C'è qualcuno interessato alla collaborazione in un progetto di questo tipo?

[m_dalpra]

Grazie Dante per la tua proposta.
Purtroppo le crypto sono moltissime e non riesco a stare dietro a tutto, visto che l'evoluzione è praticamente quotidiana, quindi ti porto qualche idea e riflessione.

Premessa
La sicurezza delle cryptovalute è demandata alle funzioni di hash (che poi sono operazioni di logica booleana che ri-mescolano i bit più volte).
Solitamente si ripete lo stesso calcolo più volte (per tentativi) fino a che si azzecca un Hash che inizia con una sequenza di zeri.
Il primo (al mondo) che riesce nel calcolo, guadagna la taglia (reward). Ad esempio 12,5 Bitcoin.
Il numero di zeri richiesto per ciascuna operazione, aumenta con l'aumentare dei minatori che tentano di indovinare il calcolo. Si chiama quindi "difficoltà".

Ordunque

1. E' vero che le macchine di Hashing di oggi non sono fatte per l'efficienza. Ad esempio generalmente non si può recuperare il calore da una scheda grafica. Ho anche testato macchine Bitmain
come questa
https://shop.bitmain.com/antminer_s9_asic_bitcoin_miner.htm?flag=specifications
ma recuperare la parte termica per fare riscaldamento o altro è davvero complesso.
Sono incompatibili con qualunque sistema di riscaldamento, anche per i rumore che fanno
Ci vogliono macchine progettate in modo diverso, dal punto di vista meccanico.

2. Non è detto che tutte le criptovalute avranno la necessità di queste funzioni. Iota ad esempio non ha la blockchain (non ho indagato se ha bisogno o meno dell'hash, anche se presumo di si).

3. La funzione di OR è in pratica il primo minatore (o device) che sul pianeta ha azzeccato il calcolo, e che alza la mano per segnalare la sua riuscita

4. Ma solitamente queste funzioni sono fatte tramite ASIC (bitcoin, Dash, Litecoin) o con le GPU (Ethereum e tutte le altre),
Non mi risulta che nessuno utilizzi FPGA.
Mi ricordo che sono più lenti delle GPU e meno efficenti delle ASIC.


PS Il mercato comunque è enorme, potrei anche essermi perso qualcosa.

Spero di riuscire a trovare il tempo di fare un articolo delle sperimentazioni che ho fatto.

[DanteCpp]

1. Certamente recuperare il calore è una follia, però lo si può dissipare in maniera efficiente.

2. Non tutti i protocolli blockchain utilizzano la stessa funzione di hashing, ad esempio bitcoin utilizza SHA256 mentre litecoin scrypt. Per quanto riguarda ethereum, io presumo che la resistenza all'hardware specializzato sia dovuta alla sua turing-completezza. Nel senso che la rete ethereum è in grado di eseguire codice come un qualsiasi calcolatore general purpose, per questo le gpu sono terreno fertile. Comunque non sono ancora riuscito ad inquadrare nei dettagli l'architettura di ethereum che è decisamente più complessa di quella bitcoin, che alla fine non è altro che una struttura dati un po particolare.
Sicuramente l'architettura del futuro è quella di ethereum.

3. Se ti riferisci alla bozza che ho postato, quello è il primo circuito digitale che mi è venuto in mente per parallelizzare la ricerca dell'hash.

4. Su FPGA il prototipo di ciò che dovrà essere un chip special purpose.

[Narcolex]

Premetto non sono un tecnico, ma un miner a tempo perso...

L'idea dell'asic è buona, ma ci mini solo btc credo....

perché invece non puntare su un dispositivo che mini gli altri algoritmi tipo equihash, neoscript etc?
Attualmente vengono utilizzate le GPU, il costo è spropositato perché i fornitori non riescono a stare dietro alla richiesta... Progettando un "Dispositivo" che possa sosttuire le GPU sarebbe come fare bingo...

Altra cosa... Esiste tutte una serie di altri dispositivi necessari al mining con gpu... schede madri, riser, alimentatori super affidabili.. Potremmo partire ad esempio progettando un alimentatore ATX capace di restare acceso h24 in qualsiasi condizione, oppure non una matherboard, ma un semplice PCB con attacchi PCIex dove poter inserire le gpu etc.... io credo che nei prossimi 4/5 anni chi proporrà soluzioni per il mining avrà tantissimo lavoro..

Riguardo la centralizzazione, sono d'accordo solo a metà.... sicuramente con l'aumentare della difficoltà, sarà sempre più difficile minare btc in casa.... Ma ci sono centinaia di monete e miliardi di persone che nei prossimi anni vorranno entrare in questo mondo... quindi non so fino a che punto si potrà centralizzare tutto il mining, anche perché per loro natura, le criptovalute sono nate decentralizzate.

[deltax]

ma è una cosa open source che vuoi tirare su tu? Ti serve aiuto da altri persone che sono interessate a investire tempo in questo progetto open source?
Se si, sono interessato. Ho necessità di ricollocarmi professionalmente e un progettino open source a cui partecipare non sarebbe male.
Fammi sapere.

[ucr]

Il motivo per cui ethereum si oppone all'uso di FPGA è ASIC risiede nella volontà di mantenere decentralizzato il controllo sulla cryptovaluta, perché consentendo l'uso di questi dispositivi dedicati si metterebbe in mano il controllo ai pochi utenti della valuta virtuale che hanno ASIC e FPGA. Questo è quanto sostengono loro.

[DanteCpp]

Per carità non iniziamo a parlare di filosofia!

Premesso che la maggior parte delle applicazioni distribuite(DAPP) sonobasate su Ethereum, vale la pena approfondire la sua architettura. Nel caso si decida di unire gli sforzi per progettare nuovo hardware, sarebbe bene mirare il lavoro su soluzioni per la convalida di blocchi su blockchain sottostanti ad infrastrutture turing-complete, come è il caso della blockchain Ethereum.

La resistenza all' ASIC di Ethereum è derivante da due caratteristiche di quest'ultimo. La prima è la turing-completezza, ossia, la capacità di eseguire qualsiasi tipo di computazione eseguibile da una comune unità di calcolo.

A commonly asked question is "where" contract code is executed, in terms of physical hardware. This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B.

La seconda caratteristica è che la proof-of-work (PoW) di Ethereum richiede una grande quantità di memoria.

The current intent at Ethereum is to use a mining algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the last N blocks in the blockchain, and return the hash of the result. This has two important benefits. First, Ethereum contracts can include any kind of computation, so an Ethereum ASIC would essentially be an ASIC for general computation - ie. a better CPU. Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction.

Quindi un ASIC per Ethereum dovrà avere sicuramente una parte dedicata all'esecuzione di algoritmi generali, ma può avere delle funzionalità speciali dedicate a questo tipo di attività. Per dirla terra terra, si deve pensare ad una cpu con una alu che riesca a gestire operazioni più complesse, come le funzioni di hash, piuttosto che le solite quattro operazioni aritmetiche.
un altro frangente interessante su cui si può ottimizzare è quello delle operazioni più frequenti, è ragionevole pensare che la maggior parte delle operazioni elaborate in una infrastruttura per DAPP sia di tipo finanziario(almeno sin'ora). Questo tipo di operazioni sono un sottoinsieme molto ristretto di tutte le operazioni possibili in un calcolatore. Implementandole direttamente via hardware si potrebbe raggiungere un'efficienza maggiore. Ma naturalmente studi statistici sono da condursi prima di inoltrarsi in questa via.

Esiste tutte una serie di altri dispositivi necessari al mining con gpu... schede madri, riser, alimentatori super affidabili.. Potremmo partire ad esempio progettando un alimentatore ATX capace di restare acceso h24 in qualsiasi condizione, oppure non una matherboard, ma un semplice PCB con attacchi PCIex dove poter inserire le gpu etc

Condivido, progettare un chip è un pochino fuori portata, anche se non impossibile. Naturalmente senza alcuna pretesa, si inizia da qualche parte e si vede dove si arriva. Comunque, ideare una scheda madre o un alimentatore sembra un punto di attacco più accessibile. Per quanto riguarda il frangente alimentatori, non saprei proprio, dal momento che le mie conoscenze di elettronica di potenza sono piuttosto base.
Sul lato schede madri c'è senz'altro da lavorare, le soluzioni che si adottano ora sono molto alla Dr. Frankenstein.

Interessante sarebbe anche un sistema di raffreddamento ad olio minerale, a convezione forzata per mezzo di pompe, che se di grandi dimensioni potrebbero rivelarsi più economicamente efficienti dei sistemi di raffreddamento ad aria. Anche in questo caso simulazioni termodinamiche sono da condursi.

Mi piacerebbe che questa conversazione mantenga un carattere tecnico e per quanto possibile oggettivo.

Questa discussione vuole essere centrata sul'hardware necessario ad implementare la soluzione PoW al problema dei generali bizantini. Argomento di questa discussione non sono le criptovalute. Vi lascio con una lettura interessante:

> It is not sufficient that everyone knows X. We also
> need everyone to know that everyone knows X, and that
> everyone knows that everyone knows that everyone knows X
> - which, as in the Byzantine Generals problem, is the
> classic hard problem of distributed data processing.

The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll
try to rephrase it in that context.

A number of Byzantine Generals each have a computer and want to attack the
King's wi-fi by brute forcing the password, which they've learned is a certain
number of characters in length. Once they stimulate the network to generate a
packet, they must crack the password within a limited time to break in and
erase the logs, otherwise they will be discovered and get in trouble. They
only have enough CPU power to crack it fast enough if a majority of them attack
at the same time.

They don't particularly care when the attack will be, just that they all agree.
It has been decided that anyone who feels like it will announce a time, and
whatever time is heard first will be the official attack time. The problem is
that the network is not instantaneous, and if two generals announce different
attack times at close to the same time, some may hear one first and others hear
the other first.

They use a proof-of-work chain to solve the problem. Once each general
receives whatever attack time he hears first, he sets his computer to solve an
extremely difficult proof-of-work problem that includes the attack time in its
hash. The proof-of-work is so difficult, it's expected to take 10 minutes of
them all working at once before one of them finds a solution. Once one of the
generals finds a proof-of-work, he broadcasts it to the network, and everyone
changes their current proof-of-work computation to include that proof-of-work
in the hash they're working on. If anyone was working on a different attack
time, they switch to this one, because its proof-of-work chain is now longer.

After two hours, one attack time should be hashed by a chain of 12
proofs-of-work. Every general, just by verifying the difficulty of the
proof-of-work chain, can estimate how much parallel CPU power per hour was
expended on it and see that it must have required the majority of the computers
to produce that much proof-of-work in the allotted time. They had to all have
seen it because the proof-of-work is proof that they worked on it. If the CPU
power exhibited by the proof-of-work chain is sufficient to crack the password,
they can safely attack at the agreed time.

The proof-of-work chain is how all the synchronisation, distributed database
and global view problems you've asked about are solved.


---------------------------------------------------------------------
The Cryptography Mailing List

[fpalone]

A me ha sempre incuriosito il fatto che questi miner ASIC abbiano il raffreddamento ad aria: questo ti costringerebbe ad utilizzare un sistema HVAC estremamente oneroso per dissipare il calore prodotto dai numerosi ASIC ed immesso nell'ambiente.

A meno che l'ASIC sia abbastanza robusto da stare in un ambiente solo ventilato e non condizionato; da molte foto trovate in rete queste miniere sembrerebbero capannoni piuttosto semplici se paragonati alle server farm convenzionali.

Il design termico è quindi fondamentale, così come la velocità di messa in servizio, che diventa un fattore essenziale per la competitività della miniera; a me da tutto in questi impianti di mining da l'impressione di provvisorietà, con fili volanti, rack non ancorati al suolo (nessun requisito antisismico) ecc...

Senza dubbio la necessità di grandi quantità di energia elettrica e di smaltire calore potrebbe rendere conveniente, con i prezzi europei dell'energia(1), la scelta di una generazione locale con macchine refrigeranti ad assorbimento.
Purtroppo la mia totale ignoranza in materia elettronica non mi permette di contribuire all'idea, se però serve una consulenza sulla gestione energetica di questi grandi mining centres (che superano la decina di MW di assorbimento), qualche contributo potrei darlo ...

(1) Certo che se ti trovi in Cina, dove l'energia elettrica costa alle industrie 50 €/MWh, le cose sono più facili.

[SandroCalligaro]

Purtroppo non ci capisco niente di hash e crypto ecc.
Ma visto che parlate di consumo di sistemi di calcolo...

E se un domani si lavorasse con logica adiabatica?

Ho sempre pensato che fosse piuttosto stupido (anche se per ora è l'unica opzione disponibile) sprecare energia per portare a zero un bit. In sé si tratta di un'operazione concettuale, è solo l'implementazione che per ora richiede di dissipare così tanto.
Siccome oggi in molti casi il consumo è il vero problema, secondo me prima o poi arriveremo ad una logica "adiabatica".

[DanteCpp]

eheheh l'argomento è interessante, anche se non direttamente correlato.

Alcune domande che mi sono posto sulla scia del lavoro di Landauer, e su cui non ho trovato nulla in merito sono:

qual è l' energia che è necessario spendere per raggiungere il consenso in una rete di n agenti? C'è un limite fisico a questa energia?

Forse non trovo nulla perché non so cosa cercare! Comunque per ora quello del calcolo reversibile è un argomento troppo di frontiera.