Ascolta “Blockchain: Permissionless vs. Permissioned” su Spreaker. Le Blockchain sono così definite all’art. 8-ter della Legge n. 12 del 11 febbraio 2019 recante le “Tecnologie […]]]>Ascolta “Blockchain: Permissionless vs. Permissioned” su Spreaker.
Le Blockchain sono così definite all’art. 8-ter della Legge n. 12 del 11 febbraio 2019 recante le “Tecnologie basate su registri distribuiti e smart contract”: “Si definiscono “tecnologie basate su registri distribuiti” le tecnologie e i protocolli informatici che usano un registro condiviso, distribuito, replicabile, accessibile simultaneamente, architetturalmente decentralizzato su basi crittografiche, tali da consentire la registrazione, la convalida, l’aggiornamento e l’archiviazione di dati sia in chiaro che ulteriormente protetti da crittografia verificabili da ciascun partecipante, non alterabili e non modificabili”.
La domanda è: le blockchain sono tutte uguali?
Sicuramente tutte le blockchain hanno come elemento comune la sicurezza. La condivisione dei dati che, replicati in tutti i nodi, sono così protetti dalle vulnerabilità tipiche delle architetture centralizzate. Non potendo i dati essere resi inaccessibili e non potendo essere modificati, un cyber attacco dovrebbe essere sferrato su tutti i nodi costituenti la blockchain.
Altro tema comune a tutte le tipologie di blockchain è l’integrità del dato, la sua immutabilità. I dati risiedono su tutti i nodi coinvolti e, poiché ciascun blocco è legato con soluzioni crittografate e con timestamp al blocco precedente, i dati non sono assolutamente manipolabili.
Le differenze tra le tipologie di blockchain risiedono allora nelle modalità di accesso ai dati, nella verifica e validazione dei blocchi, nel meccanismo del consenso e nelle regole di partecipazione alla blockchain. Vi sono quindi delle caratteristiche che fanno sì che possiamo suddividere le blockchain in due macro tipologie: quelle Permissionless e quelle Permissioned. Le prime sono pubbliche e non prevedono abilitazioni all’accesso. Le seconde sono private e possono prevedere abilitazioni all’accesso.
Permissionless Blockchain
Una blockchain permissionless (altrimenti detta pubblica) è una blockchain aperta alla quale chiunque installi un software opportuno può accedere prendendo visione di ogni blocco e di ogni singola transazione.
Chiunque può sottoporre transazioni alla blockchain e può rendersi parte attiva nel processo di validazione.
La più famosa blockchain permissionless è la celebre Bitcoin creata nel 2009 da un anonimo inventore, noto con lo pseudonimo di Satoshi Nakamoto. Si opta per una blockchain permissionless quando i soggetti che la compongono non hanno rapporti fiduciari tra loro o addirittura non si conoscono a priori. In tale contesto, nel quale nessun soggetto centralizzato controlla e verifica le transizioni, la moltitudine di soggetti che si occupa della validazione (i cosiddetti miners) devono essere motivati ed incentivati con un compenso per la loro attività.
Si sceglie dunque una blockchain permissionless qualora sia determinante la possibilità di sfruttare la trasparenza, la sicurezza e l’immutabilità nella gestione di tale fattispecie di blockchain. Il soggetto aderente ad una siffatta blockchain deve però accettare che la validazione delle transazioni e la creazione di blocchi sia in capo ad ogni partecipante e che verifica e validazione delle transazioni avvengano sulla base
della maggioranza dei nodi. Non è un limite, le blockchain permissionless sono nate proprio per questo!
Permissioned Blockchain
Le blockchain permissioned (altrimenti dette private) consentono di definire autorizzazioni sia in merito alla partecipazione alla blockchain, sia in merito ai permessi accordati ad ogni utente. La dotazione di tali privilegi consente un controllo sui partecipanti pur mantenendo i vantaggi in termini di trasparenza ed immutabilità tipici di una blockchain.
Si sceglie una blockchain permissioned quando esistono dei rapporti pregressi di conoscenza e fiducia tra i partecipanti. In tale contesto il meccanismo di consenso per la validazione opera sulla base dei criteri definiti dal consorzio di appartenenti alla blockchain. Mancando del meccanismo di consenso tipico delle blockchain permissionless, ci troviamo di fronte ad una procedura più snella e più efficiente.
Il caso tipico di implementazione è dunque quello di un consorzio di organizzazioni o imprese finalizzato alla gestione di una filiera, di transazioni e di informazioni. La blockchain permissioned permette la customizzazione delle regole di governance in termini di autorizzazioni e responsabilità.
Bibliografia
- Legge 11 febbraio 2019, n. 12
- La blockchain per le imprese, Mauro Bellini
- https://www.blockchain4innovation.it/esperti/blockchain-perche-e-cosi-importante/, Mauro Bellini
Ascolta “Analisi del software con la tecnica delle 3C: le User Story” su Spreaker. L’interazione continua con il cliente è una componente fondamentale nell’utilizzo delle […]]]>Ascolta “Analisi del software con la tecnica delle 3C: le User Story” su Spreaker.
L’interazione continua con il cliente è una componente fondamentale nell’utilizzo delle metodologie Agili per la produzione del software. Fin dall’inizio del progetto, nel metodo Agile, si opera una definizione dei requisiti attraverso frequenti riunioni cui partecipa sia il team di lavoro, sia il cliente. Tali riunioni hanno il duplice scopo di definire in modo incrementale le funzionalità del prodotto e di concordare le priorità di rilascio.
Negli ultimi vent’anni il processo di analisi del software è mutato da estese documentazioni al ricorso a espedienti narrativi che vedono il software con gli occhi dell’utente finale. La redazione del gantt di progetto, con il ricorso alle metodologie Agile, predilige come strumento di comunicazione tra il team ed il cliente le User Story.
La tecnica, piuttosto semplice da utilizzare, vede in prima battuta la redazione di stories con un livello di dettaglio molto basso e, solo successivamente, l’arricchimento delle User Story con dettagli sempre più simili ai requisiti.
Ron Jeffries, uno dei tre fondatori della metodologia di sviluppo del software Extreme Programming, descrive le fasi successive di questa tecnica con l’acronimo 3C: Card, Conversation e Confirmation.
Fase Card
La fase Card contiene la descrizione sommaria delle funzionalità da realizzare. Una moltitudine di brevi frasi sono assimilabili a tanti piccoli episodi che si aprono e si chiudono assai velocemente.
Tale approccio consente al cliente di comprendere facilmente la funzionalità come va delineandosi, ma consente anche un notevole feedback da parte sua lasciando il dovuto spazio alla conversazione.
Un requisito della funzionalità negoziato in tale maniera diventa una proposta dalla quale possono originarsi ulteriori idee. Si descrivono le necessità del cliente con un’ampia visione palesando così i vantaggi per l’utente, ma rimandando a un secondo momento il dettaglio implementativo, evitando al cliente di definire le specifiche nella loro interezza fin dall’inizio.
Interessanti sinergie possono svilupparsi mediante ricorso a tale tecnica proprio grazie alla condivisione delle funzionalità con tutto il team; in tal modo è possibile che altri componenti del team ravvisino funzionalità simili a quelle già oggetto di analisi. Un gruppo di più User Story simili tra loro, viene definita Epic.
Fase Conversation
Successivamente alla fase Card, si entra nel merito delle funzionalità con un maggiore livello di dettaglio in modo da dirimere ogni ambiguità per il tecnico. L’interazione con il cliente avviene allorquando ci si trova in possesso delle informazioni necessarie a identificare il livello di dettaglio derivante dai dati e non più dalle previsioni, che sovente si rivelano errate.
La User Story viene articolata in task assegnati a specifici membri del team. Per fare questo, i tecnici forniscono stime e comunicano le conseguenze delle scelte che vengono intraprese nel realizzare le funzionalità richieste, mentre il cliente definisce la priorità rispetto alle schede di lavorazione che il team di tecnici è in grado di prendere in carico per quella iterazione.
Fase Confirmation
Siamo infine alla fase di Confirmation quando, congiuntamente con il cliente, si definisce il termine del lavoro.
L’Extreme Programming prevede che sia il cliente a determinare il completamento di una funzionalità e a decretarne l’accettazione in fase di Confirmation. Una funzionalità si ritiene completata quando il test preventivamente concordato e predisposto con il cliente ha avuto esito positivo. È proprio per questo che, nell’Extreme Programming, la predisposizione dei test costituisce una parte fondamentale del processo.
La prima tecnica formulata in Extreme Programming è stata la Acceptance Test Driven Development (A-TDD) nella quale lo sviluppo è guidato dai test di accettazione scritti con il cliente. Tale tecnica si è nel tempo evoluta con la Specification By Example (SBE) con la quale si procede scrivendo piccoli esempi delle funzionalità da realizzare e con la Behavior Driven Design (BDD) cioè con lo sviluppo guidato dai comportamenti dell’utente.
Bibliografia
- DevOps Guida per integrare Development e Operations e produrre software di qualità, Fabio Mora
- User Stories Applied: For Agile Software Development, Mike Cohn