martedì, marzo 08, 2016

Blockchain e Quantum Computing

Facendomi una cultura su Bitcoin e Blockchain, sono incappato in questa interessante domanda: Bitcoin è vulnerabile ai computer quantistici?

Questa è la risposta sul sito di Bitcoin.

Si, la maggior parte dei sistemi si affidano alla crittografia, inclusi i sistemi bancari. Tuttavia, i computer quantici non esistono ancora e non esisteranno per un po'. Nell'evenienza che le computazioni quantiche costituiscano una minaccia immediata per Bitcoin, il protocollo sarà aggiornato per l'uso di algoritmi post-quantici. [...]

La risposta apre a mio avviso ulteriori interessanti domande, alcune delle quali mi giravano nella testa da anni, ma che non avevo mai avuto voglia e tempo di approfondire, tra cui:
  1. Quando veramente ci sarà un computer quantistico, qualunque sistema di crittografia come lo conosciamo oggi diventerà obsoleto?
  2. Ci sono algoritmi crittografici sicuri anche se la NSA o la CIA o il MOSSAD ha già sviluppato un computer quantistico e non ce lo dice?
  3. D-WAVE è un computer quantistico?
  4. Il primo che svilupperà un computer quantistico, potrà fare il "reverse" della blockchain, e quindi annullare tutte le transazioni? Oppure creare transazioni fasulle?
Per darmi una risposta, ho trovato molto utili questi articoli:
  1. The limits of Quantum Computers (Scott Aaronson)
  2. When can Quantum Annealing Win (Hartmut Neven)
Nella mia ignoranza ho sempre pensato che un Computer Quantistico fosse un computer in grado di effettuare una certa operazione (o sequenza di operazioni) su un insieme di bit (un'area di memoria) che avevano la strana caratteristica di assumere tutte le possibili combinazioni di valori possibili contemporaneamente. Quindi una certa operazione, fatta una volta sola, avrebbe calcolato tutti i risultati possibili considerando tutti gli input possibili.

Da quanto capisco non è che mi stessi sbagliando, ma sottovalutavo il problema di leggere poi il risultato. O meglio la risposta che mi davo era "vabbè qualcuno ci avrà pensato e tanto per il momento non ci sono i computer quantistici".

In realtà è decisamente complicato, e la verità è che gli algoritmi per i computer quantistici devono avere una caratteristica sorprendente: devono riuscire ad eliminare tutte le possibili soluzioni che non sono corrette.

A questo punto ho pensato: Ehi ma questo è piuttosto limitante! Che pacco i computer quantistici! Ne voglio uno più potente (*).

Tornando alle mie domande... beh, questa caratteristica porta una buona notizia. Alcuni degli attuali algoritmi di crittografia, come ad esempio AES-256, sono già "post-quantistici". Questo grazie proprio alle limitazioni dei computer quantistici, o quantomeno grazie al fatto che ad oggi nessuno ha trovato un algoritmo "quantistico" con una complessità polinomiale (so P is still different than NP) per craccare questi algoritmi.

La cattiva notizia è che in realtà per la maggior parte degli algoritmi a chiave pubblica attualmente in uso sono attaccabili dai computer quantistici grazie all'algoritmo di Shor. Esistono però nuovi algoritmi di crittazione a chiave pubblica che invece sono sufficientemente cazzuti.

L'altra cosa che mi era poco chiara è se esiste o meno un computer quantistico. D-WAVE è un'azienda canadese che produce un computer quantistico. O almeno, così è pubblicizzato sul loro sito. Ci sono però un sacco di controversie a riguardo: alcuni accademici dicono che non è un vero computer quantistico. Sono sempre stato un po' stato scettico a riguardo: se fosse stato vero, mi sarei aspettato stravolgenti innovazioni, e invece fino a poco tempo fa non c'erano reazioni veramente positive (indipendenti) per questo prodotto.

Ad inizio del 2016 sono però cominciati ad uscire anche sulla stampa generalista articoli del tipo "Google dice di avere un computer quantistico e funziona bene", ed ovviamente parlano di un computer D-WAVE. Ovviamente il titolo è un po' enfatico, però effettivamente Google ha pubblicato un articolo scientifico sui risultati ottoenuti con un computer D-WAVE, dicendo che sono promettenti.

Però continuo a non essere certo che quello di D-WAVE sia effettivamente un computer quantistico. L'articolo di Google lo chiama "quantum annealer". Il quantum annealing è un'euristica per risolvere il problema di ricerca del valore minimo di una funzione, usando alcune caratteristiche della meccanica quantistica. Quindi, da quello che capisco, D-WAVE produce un sistema che risolve una sola classe di problemi usando feature della meccanica quantistica. Insomma, per fare un paragone tra i calcolatori non-quantistici, il computer di D-WAVE mi sembra come una calcolatrice in grado di calcolare la radice quadrata (molto utile), ma non tutte le operazioni possibili. Su questo punto però non ho ancora le idee chiare.

Oltre a D-WAVE, ci sono altri computer quantistici maturi là fuori? Non lo so. Personalmente penso di no. Se la NSA avesse un computer quantistico maturo, si preoccuperebbe del fatto che la maggior parte delle trasmissioni dati su internet che usano algoritmi di cifratura a chiave pubblica, comprese quelle governative, non sono sicure (perché altre agenzie di intelligence potrebbero averne un altro). Quindi avrebbero iniziato a definire come standard di criptazione degli algoritmi post-quantistici. E non l'hanno ancora fatto.

Infine, con un computer quantistico, potrei "smontare" la blockchain, annullando la storia delle transazioni? O creare transazioni fasulle?

Da un punto di vista teorico è una domanda abbastanza importante. Nel senso che teoricamente bitcoin, e più in generale la blockchain, dovrebbe fornirmi garanzie tali per cui posso pensare che il mio wallet sia sicuro, ovvero che non sia possibile rubarlo o falsificare transazioni che partano dal mio wallet, o ancora annullare transazioni che ho fatto nel passato. Al punto tale che dovrei vivere sereno trasferendoci tutto il mio patrimonio, e anche al pensiero che a un certo punto della mia vita (il più in là possibile) farò una transazione verso il wallet di mia figlia di tutto il mio patrimonio. E non sarà ripudiabile. Ovvero non potrà succedere che nel 2200, la figlia di mia figlia si troverà il wallet vuoto perché qualcuno con un computer quantistico riuscirà a fare il revert della blockchain fino a quel punto.

Ecco, io sono ragionevolmente sicuro che bitcoin/blockchain è sicuro fino a questo livello. In particolare ci sono due fattori che mi mettono tranquillità... il fatto che il protocollo è destinato ad evolvere, e quindi è possibile che un giorno la comunità deciderà di passare ad algoritmi di cifratura post-quantistici. Questo dovrebbe limitare le possibilità di creare transazioni fasulle.

Il secondo punto, è che ogni volta che viene creato un blocco nella blockchain, "craccare" quello precedente diventa sempre più difficile. Questo dovrebbe limitare la possibilità di fare il "rollback" della blockchain.

In sostanza è molto più probabile che qualcuno ad un certo punto mi punti un coltello alla gola intimandogli di dargli il mio wallet.

Ed inoltre alcune preoccupazioni sarebbero valide anche con valute tradizionali. Per certi aspetti molto più valide. Non sarei più sereno al pensiero di avere tutto il mio patrimonio in dollari contanti e sicuramente credo che sarebbe assurdo pensare di tramandare questi dollari a mia figlia e alla figlia di mia figlia fino al 2200.

Se lo stesso ragionamento dovessi farlo per il wallet di un'azienda o addirittura di uno stato, beh... in quel caso penso che sarebbe bene fare ancora qualche ricerca e chiedere a qualche cervellone.

In sostanza quindi, il mio pensiero è:
- bitcoin/blockchain è abbastanza sicuro
- preferisco comunque comprarmi una birra che comprarmi bitcoin
- l'investimento in birra è un investimento sicuro, che non arriverà però a mia figlia

(*) Oltre i computer quantistici ci sono computer ipotetici in grado di usare i viaggi nel tempo. Ecco, questo dovrebbe essere abbastanza veloce, appena esce voglio farci il porting di linux. :-)

lunedì, settembre 07, 2015

Mainframe Modernization

Qualche mese fa ho avuto l'opportunità di lavorare ad un interessante studio di fattibilità in ambito bancario, con l'obiettivo di "modernizzare" una applicazione che in larga parte è scritta in Cobol e viene eseguita su Mainframe IBM.

Con questo post voglio suggerire un libro interessante: Oracle Modernization Solutions [Laszewski, Williamson].

Il titolo non tragga in inganno: anche chi non è interessato ad Oracle può trovare degli spunti interessanti, soprattutto nei primi capitoli, che sono una guida generale alle metodologie di modernizzazione di applicazioni "Mainframe".

Prima di questa attività vedevo i Mainframe come uno scatolone nero misterioso, una reliquia in cui credere senza farsi troppe domande sul contenuto.

Ora non sono un esperto, ma ho scoperto cose interessanti, tra cui:

  • I Mainframe moderni sono delle gigantesche infrastrutture di virtualizzazione, con performance notevoli e feature peculiari (quali ad esempio quelle per la gestione del disaster recovery)
  • Questi scatoloni possono eseguire diversi tipi di Virtual Machine, alcuni di questi legati alle tecnologie ritenute ormai obsolete (z/OS), altri assolutamente moderne (z/Linux), e questi contenitori possono anche "mischiare" feature del vecchio con il nuovo (es. Java che dialoga con Cobol, etc.)
  • Un aspetto interessante è dato dalla combinazione delle feature di gestione delle transazioni con le performance che si possono ottenere con un'architettura "locale", mi spiego meglio: le applicazioni in ambito bancario sono strettamente intrecciate tra di loro, ed una operazione deve essere sempre consistente tra tutte le applicazioni, ad esempio il pagamento della rata di un mutuo deve essere un'unica transazione che verifica il saldo del conto corrente, registra il pagamento della rata, e scala l'ammontare dal conto corrente. Su un'architettura distribuita (es. SOA) questo potrebbe richiedere una gestione delle transazioni complesse (es. gestione della compensazione), ma soprattutto porta ad un overhead molto alto (es. nel networking). Questo potrebbe non essere un problema per il calcolo di una singola rata, mentre potrebbe essere un problema molto grave se la più grande banca italiana deve registrare le rate dei mutui di 2 milioni di clienti l'ultimo giorno del mese in un timeframe di 1 ora. Quindi: i Mainframe potrebbero fare cose che su architetture "moderne" potrebbero richiedere complessità significative.
  • La possibilità di iniettare tecnologie "moderne" (es. Java OSGi bundle) potrebbe essere una strada verso la modernizzazione, che non significa necessariamente "uscire" dal Mainframe, proprio perché il Mainframe ha delle feature interessanti che può continuare a valere la pena sfruttare. 
  • Se con "modernizzazione" si intende solo la strada di uscita dai Mainframe, bisogna considerare ostacoli notevoli, come ad esempio l'intricata relazione di un qualunque componente software con tutte le altre applicazioni in esecuzione sullo stesso Mainframe.
  • Qualunque attività in questo ambito avrà un punto di frizione con le strategie e le politiche commerciali di IBM: IBM è riuscita a creare un monopolio ed una dipendenza difficile da sradicare. Con il Mainframe non puoi dire "smetto quando voglio" :-)

martedì, agosto 25, 2015

Il ritorno!

Dopo appena tre anni dall'ultimo post (abbastanza inutile), torno a scrivere sul blog.

Perché? Nella speranza che quello che vado a condividere sia di aiuto a qualcuno, perché rappresenta un riassunto di alcune cose che reputo significative e utili che ho visto, letto, imparato, annusato, etc.

Negli ultimi anni ho fatto esperienze un po' meno tecniche (ahimè), ed in parte con i prossimi post vorrei condividere cosa prova uno smanettone, come in fondo all'anima ancora sono, quando si trova a dover abbandonare il compilatore e la shell unix, per dover fare cose come il project management.

In parte ricominciando a scrivere su questo blog vorrei riprendere gli aspetti tecnici, prenderlo come spunto per studiare cose nuove.

sabato, novembre 10, 2012

Java Code Metrics: eclipse metrics is the way

Sto lavorando ad un'analisi per il porting di un insieme di applicazioni J2EE da Oracle OC4J verso un differente container (WebLogic, Tomcat, WhoKnows?).

Per avere un dato macro della complessità delle applicazioni ho cercato un tool che mi permettesse di raccogliere un po' di statistiche, anche abbastanza banali, come il numero di linee di codice, etc.

Ho provato innanzitutto Sonar. Bellissimo, potentissimo. Fornisce un sacco di dati, ma... forse è un po' troppo complesso. Innanzitutto ho trovato qualche bug, per esempio non gli piacciono le classi che non rispettano il CamelCase java, ovvero le classi che iniziano con una lettera minuscola. Altri "difetti", per quello di cui ho bisogno, sono che ha bisogno di un server (un database, un container java), e che per analizzare il codice impiega un sacco di tempo. 

Poi ho pensato anche ad una cosa più semplice, per certi versi un dato nudo e crudo come quello che tira fuori il comando unix wc poteva anche essere un'idea. Però effettivamente dopo aver visto Sonar, sembra la preistoria.

Poi sono impazzito a cercare un'estensione di eclipse che potesse fare quello che chiedevo. Nel marketplace di eclipse juno, ad oggi, però non c'è niente che faccia al caso mio. Alla fine ho trovato eclipse metrics, che al momento mi sembra il giusto compromesso per quello di cui avevo bisogno.

Occhio che ci sono altre estensioni di eclipse che si chiamano metrics, ma decisamente più povere.

martedì, febbraio 09, 2010

HIVE: Extreme Datawarehousing

HIVE è un progetto di Apache Software Foundation, inizialmente sviluppato da Facebook per permettere ai propri analisti di fare elaborazioni su enormi volumi di dati in totale autonomia.

HIVE è un’infrastruttura di Data Ware Housing che permette di memorizzare dati ed effettuare query in un linguaggio simile ad SQL. Hive utilizza un’infrastruttura per la distribuzione dello storage e delle elaborazioni chiamata Hadoop (che è un’implementazione di MapReduce), che permette di distribuire la memorizzazione dei dati e delle elaborazioni su un cluster di macchine eterogenee a basso costo.

Per fare un esempio pratico, Facebook raccoglie oltre 2TB di dati (compressi) al giorno utili all’analisi. La memorizzazione avviene su un cluster enorme (migliaia di nodi) di macchine relativamente semplici (es. 2 CPU, 4 GB Di RAM, 2TB di disco, ovvero macchine che costano circa 1000$).

HIVE permette di fare query su tale volume di dati, distribuendo automaticamente il carico sul cluster, e senza dover scrivere del codice, ma solamente utilizzando un linguaggio molto simile a SQL (cosa abbastanza diffusa tra gli analisti). Sempre per tornare a Facebook, gli analisti di Facebook possono fare query ad hoc su Petabyte di dati, senza dover avere uno skill da programmatore.

Un altro elemento interessante è che HIVE è offerto anche on-the-cloud (da Amazon, per esempio, con il servizio Elastic MapReduce), permettendo quindi la possibilità di usare un cluster Hadoop con un costo a consumo (magari solo un giorno al mese ho bisogno di un cluster di 100 nodi per fare una query su 1 Petabyte di dati).

Per dimostrare le potenzialità di questo strumento, ho convertito in HIVE una query che viene oggi eseguita su un database Oracle per la costruzione di un Data Mart. Sul database Oracle la query impiega circa 10 ore ad essere risolta: è una query piuttosto complessa che coinvolge centinaia di milioni di record. Il database Oracle è installato su una macchina configurata con 4CPU, 24GB RAM e uno Storage SCSI.

Ho quindi lanciato la stessa query convertita nel linguaggio di HIVE, su un cluster Hadoop di Amazon aumentando progressivamente i nodi a disposizione. E’ stato interessante notare che la velocità di esecuzione della query è inversamente proporzionale al numero di nodi. Ovvero: con 1 nodo la query veniva risolta in 20 ore, con 2 nodi in 10 ore, e così via.

Ma la cosa però secondo me più interessante è che il costo per risolvere la query è indipendente dalla velocità con cui la si vuole risolta. Mi spiego meglio: su Amazon si pagano le ore di utilizzo delle macchine virtuali. Affittare quindi una macchina per 20 ore equivale ad affittare due macchine per 10 ore. Ma avendo a disposizione un cluster di due macchine, con HIVE posso risolvere la query al doppio della velocità, mantenendo il costo costante!


martedì, ottobre 13, 2009

Orthogonal Toolbox: esportare un diagramma Entity Relationship da Visio

Io adoro Visio. Permette di fare grafici di tipologie molto diverse... flowchart, DFD, mappe di interni di edifici, diagrammi di rete, diagrammi di schedulazione, diagrammi entity relationship, etc.

Per ognuno di questi grafici sono sicuro che esista un tool migliore di Visio. Ma il fatto di poter fare tutti questi tipi di grafici da un solo programma è un gran vantaggio.

Una delle grosse limitazioni che ho incontrato più volte riguarda proprio i diagrammi Entity Relationship. Non è possibile da un ER esportare i dati in codice SQL, o in un qualunque formato che non sia grafico. Non è nemmeno possibile esportare l'elenco delle colonne di una tabella in un file excel.

Dovrebbe essere possibile farlo da Visio for Enterprise Architect. Ma non ho mai avuto la possibilità di vedere questa versione del prodotto. Credo non sia molto diffusa.

Ho trovato un tool fenomenale che si aggancia a Visio e fa abbastanza quello che voglio. Si chiama Orthogonal Toolbox. Questo strumento permette di esportare in XML i dati di un diagramma ER, e poi di applicare un XSD al file XML generato. Quindi è possibile esportare tutti i dettagli, e trasformarli in qualunque altro formato.

A me... me piace.

Salvare la disposizione delle icone sul desktop

Per l'angolo delle utility.

Spesso capita di attaccare il portatile ad un proiettore. Talvolta questa operazione provoca il cambio di risoluzione. E le icone sul desktop perdono la disposizione che con la vostra maestria avevate ritenuto essere la più produttiva, intuitiva e soprattutto concettualmente artistica.

Ho scoperto da poco un semplice tool che permette di salvare la disposizione delle icone e ripristinarla in qualunque momento.

Si tratta di una dll (layout.dll). Potete trovarla su un sacco di siti (basta cercare su google layout.dll). Io l'ho scaricato da qui.

Funziona anche con Vista!

mercoledì, maggio 13, 2009

Scalabilità Infinita: elastic map reduce

Amazon ha inserito nella sua offerta di servizi Elastic MapReduce.

Per chi non conoscesse MapReduce, si tratta di un paradigma di programmazione, sviluppato da Google, per applicazioni di calcolo distribuito. Esempio semplice: dobbiamo applicare un algoritmo di clusterizzazione a 30 Miliardi di dati, che sul tuo pc impiega solamente 100 giorni a essere calcolato. Come fare? Semplice, dividiamo il problema in 100 sottoproblemi, lo diamo in pasto a 100 nodi del nostra server farm general-purpose, e alla fine ricomponiamo i risultati ottenuti in un unico output, in 1 giorno.

Piccolo problema, nessuno di quelli che conosco ha una server farm general-purpose con 100 nodi.

A questo punto arriva Amazon, che offre Elastic MapReduce, ovvero ti affitta 100 nodi per 1 giorno, e implementa già il framework hadoop, ovvero il framework che implementa MapReduce.

A questo punto non avrà più senso dire che i tempi di elaborazione sono troppo lunghi. Semmai l'algoritmo è inefficiente. Oppure non si è stati sufficientemente smart da trovare un algoritmo che permette di suddividere il problema in sottoproblemi. In questo caso, i tempi di elaborazione dipendono solo dalla fretta del cliente: lo vuoi in un 1 giorno, affitta 100 nodi. Lo vuoi in un'ora? Affita 2400 nodi.

Il pensiero lineare è finito. Se pensate ancora con i cicli for e while, siete alle schede perforate.