Skip to content

Commit

Permalink
Updated [Italian] Libro Bianco (markdown)
Browse files Browse the repository at this point in the history
  • Loading branch information
pedrosoftz committed Jun 16, 2015
1 parent 1eca9ab commit cdb7a22
Showing 1 changed file with 8 additions and 8 deletions.
16 changes: 8 additions & 8 deletions [Italian]-Libro-Bianco.md
Original file line number Diff line number Diff line change
Expand Up @@ -104,25 +104,25 @@ Una volta avvenuto lo step (1), dopo qualche minuto qualche miner includerà la

![SPV in bitcoin](https://raw.githubusercontent.com/ethereum/www/master-postsale/src/extras/gh_wiki/spv_bitcoin.png)

_Sinistra: è sufficiente mostrare solo un esiguo numero di nodi in un Merkle tree per dimostrare la prova della validità di un ramo._
_Sinistra: è sufficiente mostrare solo un esiguo numero di nodi in un Merkle tree per avere la prova della validità di un ramo._

_Destra: qualunque tentativo di modificare qualsiasi parte del Merkle tree porterà ad un'incongruenza da qualche parte a monte della chain._

Un'importante funzione della scalabilità del Bitcoin è che nel blocco è memorizzata una struttura di dati multi-livello. L' "hash" di un blocco è in realtà solo l'hash dell'intestazione del blocco, approssimativamente 200-byte di dati che contengono la marca temporale, un numero, hash del precedente blocco e l'hash principale della struttura dei dati chiamata Merkle tree che contiene tutte le transazioni del blocco. Un Merkle tree è un tipo di struttura binaria, composto da un set di nodi con un grande numero di nodi dipendenti alla base della struttura che contengono dati sottostanti, un insieme di nodi intermedi dove ogni nodo è l'hash dei suoi due figli, e alla fine un nodo singolo principale, anch'esso composto dall'hash dei suoi due figli, che rappresenta il "top" della struttura. La finalità del Merkle tree è quello di consentire che i dati in un blocco siano consegnati in maniera frammentaria: un nodo può scaricare solo l'intestazione di un blocco da una sorgente, la piccola parte della struttura di loro interesse da un'altra sorgente, per assicurarsi che tutti i dati siano correnti. Il motivo per cui questo funziona è che gli hash si propagano verso l'alto: se un cattivo utente tenta di cambiare una transazione falsa verso il punto più basso del Merkle tree, questo cambiamento causerà un cambio sul nodo di sopra, e poi un cambio sul nodo sopra quest'ultimo, per cambiare in fine la struttura principal end pertanto l' hash del blocco, causando che il protocollo registri questo come un blocco completamente differente (quasi certamente con un proof of work invalido).
Un'importante funzione della scalabilità del Bitcoin è che nel blocco è memorizzata una struttura di dati multi-livello. L' "hash" di un blocco è in realtà solo l'hash dell'intestazione del blocco, approssimativamente 200-byte di dati che contengono la marca temporale, un numero, hash del precedente blocco e l'hash principale della struttura dei dati chiamata Merkle tree che contiene tutte le transazioni del blocco. Un Merkle tree è un tipo di struttura binaria, composto da un set di nodi, con un grande numero di nodi dipendenti alla base della struttura, che contengono dati sottostanti, un insieme di nodi intermedi dove ogni nodo è l'hash dei suoi due figli, e alla fine un nodo singolo principale, anch'esso composto dall'hash dei suoi due "figli", che rappresenta l'apice della struttura. La finalità del Merkle tree è quello di consentire che i dati in un blocco siano consegnati in maniera frammentaria: un nodo può scaricare solo l'intestazione di un blocco da una sorgente, la piccola parte della struttura di loro interesse da un'altra sorgente, per assicurarsi che tutti i dati siano correnti. Il motivo per cui questo funziona è che gli hash si propagano verso l'alto: se un utente malevolo tenta di cambiare una transazione falsa verso il punto più basso del Merkle tree, ciò causerà un cambio sul nodo di sopra, e poi un cambio sul nodo sopra quest'ultimo, per cambiare, infine, la struttura principale e pertanto l' hash del blocco, causando che il protocollo registri questo come un blocco completamente differente (quasi certamente con un proof of work invalido).

Il protocollo Merkle tree è senza dubbio essenziale per la sostenibilità a lungo termine. Un "nodo completo" nel Bitcoin network, uno che memorizza ed elabora l'interezza di ogni blocco, richiede all'incirca 15 GB di spazio sul disco nel Bitcoin network alla data di Aprile 2014, e sta crescendo di oltre un gigabyte al mese. Allo stato attuale, questo è sostenibile per un computer desktop e non per i telefoni, e più in là con il tempo potranno partecipare solo le aziende e gli appassionati. Un protocollo conosciuto come "controllo semplificato del pagamento" (CSP) permette ad un'altra classe di nodi di esistere, chiamati "nodi leggeri", che scaricano le intestazioni del blocco, verificando la proof of work sulle intestazioni del blocco, e successivamente scaricano solo i "rami" associati con le transazioni che sono per loro rilevanti. Questo permette ai nodi leggeri di determinare con una forte garanzia di sicurezza quale sia lo status di una qualsiasi transazione Bicoin, ed il loro corrente bilancio, con soltanto il download di una piccolissima parte dell'intera.
Il protocollo Merkle tree è, senza dubbio, essenziale per la sostenibilità a lungo termine. Un "nodo completo" nel Bitcoin network, uno che memorizza ed elabora l'interezza di ogni blocco, richiede all'incirca 15 GB di spazio sul disco nel Bitcoin network alla data di Aprile 2014, e sta crescendo di oltre un gigabyte al mese. Allo stato attuale, ciò è sostenibile per un computer desktop e non per i telefoni, e più in là con il tempo potranno partecipare solo le aziende e gli appassionati. Un protocollo conosciuto come "controllo semplificato del pagamento" (CSP) permette ad un'altra classe di nodi di esistere, chiamati "nodi leggeri", che scaricano le intestazioni del blocco, verificando la proof of work sulle intestazioni del blocco, e successivamente scaricano solo i "rami" associati con le transazioni che sono per loro rilevanti. Questo permette ai nodi leggeri di determinare con una forte garanzia di sicurezza quale sia lo status di una qualsiasi transazione Bicoin, ed il loro corrente bilancio, con soltanto il download di una piccolissima parte dell'intera.

### Applicazioni Alternative della Blockchain

L'idea di prendere spunto dalla tecnologia sottostate alla blockchain e di applicarla anche ad altri concetti ha una storia. Nel 2005, Nick Szabo proposte il concetto di "[titoli di proprietà sicuri con l'autorizzazione del proprietario](http://szabo.best.vwh.net/securetitle.html)", un documento che descriveva come "nuovi progressi nella tecnologia di un database replicato" consentiranno ad un sistema basato sulla blockchain di conservare un registro di chi possiede quella terra, creando un quadro elaborato che include concetti come quello di autosufficienza economica, usucapione e la tasse sulla terra Georgiana Tuttavia, sfortunatamente non era disponibile a quel tempo un efficace sistema di database replicato, ed il protocollo non fu mai implementato nella pratica. Ciononostante dopo il 2009 una volta che il consenso decentralizzato del Bitcoin fu sviluppato un numero di applicazioni alternative cominciò rapidamente ad emergere.
L'idea di prendere spunto dalla tecnologia sottostate alla blockchain e di applicarla anche ad altri concetti ha una storia. Nel 2005, Nick Szabo proposte il concetto di "[titoli di proprietà sicuri con l'autorizzazione del proprietario](http://szabo.best.vwh.net/securetitle.html)", un documento che descriveva come "nuovi progressi nella tecnologia di un database replicato" consentiranno ad un sistema basato sulla blockchain di conservare un registro di chi possiede quella terra, creando un quadro elaborato che include concetti come quello di autosufficienza economica, usucapione e la tasse sulla terra Georgiana. Tuttavia, sfortunatamente, non era disponibile a quel tempo un efficace sistema di database replicato, ed il protocollo non fu mai implementato nella pratica. Ciononostante dopo il 2009 una volta che il consenso decentralizzato del Bitcoin fu sviluppato un numero di applicazioni alternative cominciò rapidamente ad emergere.

* **Namecoin** - creato nel 2010, [Namecoin](https://namecoin.org/) conosciuto come un sistema decentralizzato di database per la registrazione di nomi di dominio. Nei protocolli decentralizzati come Tor, Bitcoin e BitMessage, c'è bisogno di un modo di identificare gli account in modo che le altre persone possono interagire con loro, ma in tutte le soluzioni esistenti l'unico tipo di identificatore disponibile è un hash pseudo casuale come `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`. Idealmente, qualcuno potrebbe avere un account con un nome come "george". Tuttavia, il problema è che se una persona può creare un account chiamato "george" poi qualcun altro può utilizzare lo stesso processo per registrare "george" per se stesso così come per impersonificare quell'altra persona. L'unica soluzione è il paradigma first-to-file, dove il primo registrante ha successo ed il secondo fallisce - un problema che si adatta perfettamente al protocollo di consenso del Bitcoin. Namecoin è la più vecchia, e di più successo, implementazione di un sistema di registrazione di dominio che utilizza una tale idea.
* **Monete colorate** - lo scopo delle [monete colorate](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) è quello di servire come un protocollo per consentire alle persone di creare le proprie valute digitali - o, nell'importante caso banale di una moneta con una sola unità, tokens digitali, sulla Blockchain del Bitcoin. Nel protocollo delle monete colorate, una persona "emette" una nuova moneta assegnando pubblicamente un colore ad una UTXO specifica del Bitcoin, e il protocollo definisce ricorsivamente il colore dell'altra UTXO al fine che sia dello stesso colore degli inputs di quella transazione da cui deriva (qualche regola speciale si applica nel caso di inputs di colori di monete misti. Questo permette agli utenti di conservare portafogli di monete che contengono solo una UTXO di uno specifico colore e di inviare questa in modo del tutto simile ai Bitcoins, attraverso lo studio della blockchain per determinare il colore di un qualsiasi UTXO che essi hanno ricevuto.
* **Metacoins** - l'idea dietro un metacoin è quello di avere un protocollo che vive in cima Bitcoin, usando le transazioni Bitcoin per conservare le transazioni metacoin ma avendo una differente funzione di transazione, `APPLY'`. Poichè il protoccolo Metacoin non può prevenire che una transazione metacoin invalida cannot prevent invalid metacoin transactions sia visualizzata sulla blockchain del Bitcoin, si aggiunge una regola che se `APPLY'(S,TX)`ritorna come un errore, le impostazioni predefinite del protocollo sono`APPLY'(S,TX) = S`. Questo fornisce un semplice meccanismo per la creazione di un protocollo arbitrario di criptomoneta, potenzialmente con funzioni avanzate che non possono essere implementate all'interno del Bitcoin stesso, ma con un costo di sviluppo molto basso visto che la complessità del mining e del networking sono già gestiti dal protocollo Bitcoin.
* **Namecoin** - creato nel 2010, [Namecoin](https://namecoin.org/) conosciuto come un sistema decentralizzato di database per la registrazione di nomi di dominio. Nei protocolli decentralizzati come Tor, Bitcoin e BitMessage, c'è bisogno di un modo di identificare gli account in modo che le altre persone possano interagire con loro, ma in tutte le soluzioni esistenti l'unico tipo di identificatore disponibile è un hash pseudo casuale come `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`. Idealmente, qualcuno potrebbe avere un account con un nome come "george". Tuttavia, il problema è che se una persona può creare un account chiamato "george" poi qualcun altro può utilizzare lo stesso processo per registrare "george" per se stesso così come per impersonificare quell'altra persona. L'unica soluzione è il paradigma first-to-file, dove il primo registrante ha successo ed il secondo fallisce - un problema che si adatta perfettamente al protocollo di consenso del Bitcoin. Namecoin è la più vecchia, e di più successo, implementazione di un sistema di registrazione di dominio che utilizza una tale idea.
* **Monete colorate** - lo scopo delle [monete colorate](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) è quello di servire come un protocollo per consentire alle persone di creare le proprie valute digitali - o, nell'importante caso comune di una moneta con una sola unità, tokens digitali, sulla Blockchain del Bitcoin. Nel protocollo delle monete colorate, una persona "emette" una nuova moneta assegnando pubblicamente un colore ad una UTXO specifica del Bitcoin, e il protocollo definisce ricorsivamente il colore dell'altra UTXO al fine che sia dello stesso colore degli inputs di quella transazione da cui deriva (qualche regola speciale si applica nel caso di inputs di colori di monete misti. Questo permette agli utenti di conservare portafogli di monete che contengono solo una UTXO di uno specifico colore e di inviare questa in modo del tutto simile ai Bitcoins, attraverso lo studio della blockchain per determinare il colore di un qualsiasi UTXO che essi hanno ricevuto.
* **Metacoins** - l'idea dietro un metacoin è quello di avere un protocollo che vive al vertice del Bitcoin, usando le transazioni Bitcoin per conservare le transazioni metacoin ma avendo una differente funzione di transazione, `APPLY'`. Poichè il protoccolo Metacoin non può prevenire che una transazione metacoin invalida cannot prevent invalid metacoin transactions sia visualizzata sulla blockchain del Bitcoin, si aggiunge una regola che se `APPLY'(S,TX)`ritorna come un errore, le impostazioni predefinite del protocollo sono`APPLY'(S,TX) = S`. Questo fornisce un semplice meccanismo per la creazione di un protocollo arbitrario di criptomoneta, potenzialmente con funzioni avanzate che non possono essere implementate all'interno del Bitcoin stesso, ma con un costo di sviluppo molto basso visto che la complessità del mining e del networking sono già gestiti dal protocollo Bitcoin.

Così, in generale, esistono due approcci per la costruzione di un protocollo di consenso: costruire un network indipendente, e costruire un protocollo sul modello di quello del Bitcoin. Il primo approccio è difficile da implementare, anche se ha avuto un buon successo in applicazioni come Namecoin; ogni implementazione individuale necessità una nuova ed indipendente blockchain, così come la costruzione ed il testing di tutta la transizione di stato ed il codice del network. Per di più, si ipotizza che il set di applicazioni per una tecnologia di consenso decentralizzato seguirà la "power law distribution" dove la maggior parte delle applicazioni sarebbe troppo piccola da garantire la loro propria blockchain, e si noti che esistono grandi classi di applicazioni decentralizzate, in particolare le organizzazioni autonome decentralizzate, che necessitano di interagire tra loro.

D'altro canto, l'approccio basato sul Bitcoin, ha il difetto di non avere la funzione di verificazione semplificata del Bitcoin. SPV funziona per il Bitcoin perchè può usare la grandezza della Blockchain come un proxy per la validità; ad un certo punto, una volta che le transazioni precedenti ad un'altra vanno abbastanza indietro , si può affermare che erano legittimamente parte dello stato. I meta-protocolli basati sulla Blockchain, d'altro canto, non possono forzare questa a non includere le transazioni che non sono valide all'interno del contesto del loro stesso protocollo. Da ciò, un'implementazione di un meta-protocollo SPV altamente sicuro necessiterebbe di analizzare tutte le transazioni fino all'inizio della Blockchain del Bitcoin per determinare quali siano le transazioni valide e quali invalide. Allo stato attuale, tutta la "luce" di implementazioni di meta-protocolli basati sul Bitcoin si basano su un server di fiducia per fornire i dati, probabilmente questo è uno dei migliori risultati possibili soprattutto quando uno degli scopi principali di una Criptovaluta è quello di eliminare la necessità di fiducia.
D'altro canto, l'approccio basato sul Bitcoin, ha il difetto di non avere la funzione di verificazione semplificata del Bitcoin. SPV funziona per il Bitcoin perchè può usare la grandezza della Blockchain come un proxy per la validità; ad un certo punto, una volta che le transazioni precedenti ad un'altra vanno abbastanza indietro , si può affermare che erano legittimamente parte dello stato. I meta-protocolli basati sulla Blockchain, d'altro canto, non possono forzare questa a non includere le transazioni che non sono valide all'interno del contesto del loro stesso protocollo. Da ciò, un'implementazione di un meta-protocollo SPV altamente sicuro necessiterebbe di analizzare tutte le transazioni fino all'inizio della Blockchain del Bitcoin per determinare quali siano le transazioni valide e quali quelle invalide. Allo stato attuale, tutta la "luce" di implementazioni di meta-protocolli basati sul Bitcoin si basano su un server di fiducia per fornire i dati; probabilmente questo è uno dei migliori risultati possibili soprattutto quando uno degli scopi principali di una Criptovaluta è quello di eliminare la necessità di fiducia.

### Scripting

Expand Down

0 comments on commit cdb7a22

Please sign in to comment.