W03.05 – IL NETWORK BITCOIN


WEEK 3
Mechanics of Bitcoin

Learn how the individual components of the Bitcoin protocol make the whole system tick: transactions, script, blocks, and the peer-to-peer network. Scopri in che modo i singoli componenti del protocollo Bitcoin fanno funzionare l’intero sistema: transazioni, script, blocchi e la rete peer-to-peer.

Joseph Bonneau
Postdoctoral Research Associate – Princeton University

03.05.03
Sezione 03.05 – Il Network Bitcoin
03.05.01
So we’ve been talking about the ability for participants to publish their transactions and get it into the blockchain, as if this happens by magic. Of course it doesn’t happen by magic in the real world, it happens through the Bitcoin network.

So what is a Bitcoin network? It’s a peer-to-peer network, so it inherits a lot of ideas from peer-to=peer networks that have been proposed for all sorts of other purposes. It’s a peer-to-peer network where all nodes are equal. There’s no hierarchy, there’s no centralized, special nodes, no master nodes. Every node on Bitcoin is an equal peer.

It runs over TCP, it has a random topology, so there’s random nodes are peered with random other nodes.

And new nodes can come at any time. So you can download the Bitcoin client today, you can spin your computer up as an node, and you will be a participating Bitcoin node with equal rights and capabilities as every other node on the Bitcoin network.

Now the network is very dynamic. It changes over time. Nodes are coming and going all the time. Although there’s actually no explicit way to leave the network, instead if you don’t hear from a node in awhile, three hours is the amount that’s hardcoded into the common clients, people eventually start to forget you. So it gracefully handles nodes going offline.
Quindi abbiamo parlato della possibilità per i partecipanti di pubblicare le loro transazioni e metterle nella blockchain, come se ciò accadesse per magia. Certo che non accade per magia nel mondo reale, succede attraverso la rete Bitcoin.

Allora, cos’è una rete Bitcoin? È una rete peer-to-peer, quindi eredita molte idee dalle reti peer-to-peer che sono state proposte per tutti i tipi di altri scopi. È una rete peer-to-peer in cui tutti i nodi sono uguali. Non c’è gerarchia, non ci sono nodi speciali, centralizzati, né nodi principali. Ogni nodo su Bitcoin è uguale.

Funziona su TCP, ha una topologia casuale, quindi i nodi casuali sono controllati con altri nodi casuali.

E i nuovi nodi possono arrivare in qualsiasi momento. Quindi puoi scaricare il client Bitcoin oggi, puoi far funzionare il tuo computer come nodo e sarai un nodo Bitcoin partecipante con diritti e funzionalità uguali a tutti gli altri nodi della rete Bitcoin.

Ora la rete è molto dinamica. Cambia nel tempo. I nodi vanno e vengono continuamente. Sebbene in realtà non ci sia un modo esplicito per lasciare la rete, se invece non si sente da un nodo in un intervallo di tempo, tre ore è la quantità codificata nei client comuni, le persone alla fine iniziano a dimenticarsi di te. Quindi gestisce con garbo i nodi andando offline.
03.05.02
So what does that mean, that you can simply join the Bitcoin peer-to-peer network at any time?

Well, if this a picture of the network at one moment in time, obviously scaled down quite a bit with just seven nodes, but this is a picture of what it might look like, seven nodes, with all random connections to each other. And notice that the numbers are scattered around here cuz there’s no geographic topology here. Networks connect other nodes in a random fashion by design.

Now if you launch a new node and say you wanna join the network, you start with a simple message to one node that you know about. So all you need to know is how to get to one node that’s already on the network, this is usually called your seed node, and there’s a few different ways you can look up lists of seed nodes to try connecting to. But you find your seed node, and you send a special message, saying, tell me all the peers that you have. Tell me the addresses of all the other nodes in the network that you know about.

And that node will respond and say, well, I’m peered with nodes one and seven, you can try them.

And then you might go and talk to one and seven and say, hey, tell me everybody on the network that you know about. And they’ll send you the nodes that they know about, and you can iterate as many times as you want until you have a list of peers to make connections with.
Quindi, cosa significa, che puoi semplicemente unirti alla rete peer-to-peer di Bitcoin in qualsiasi momento?

Bene, se questa è un’immagine della rete in un determinato momento, ovviamente ridotta di un numero solo con sette nodi, ma questa è un’immagine di come potrebbe apparire, sette nodi, con tutte le connessioni casuali tra loro. E noti che i numeri sono sparsi qui perché non c’è topologia geografica. Le reti collegano altri nodi in modo casuale in base alla progettazione.

Ora se lanci un nuovo nodo e dici che vuoi unirti alla rete, inizi con un semplice messaggio a un nodo che conosci. Quindi tutto quello che devi sapere è come arrivare a un nodo che è già presente in rete, questo di solito è chiamato il tuo nodo seme, e ci sono diversi modi in cui puoi cercare elenchi di nodi seme per provare a connetterti. Ma trovi il tuo nodo seme e invii un messaggio speciale, dicendo, dimmi tutti i tuoi pari. Dimmi gli indirizzi di tutti gli altri nodi della rete che conosci.

E quel nodo risponderà e dirà, beh, sto “alla pari” con i nodi uno e sette, puoi provarli.

E poi potresti andare a parlare con uno e sette e dire, ehi, dimmi tutti quelli che conosci sulla rete. E ti invieranno i nodi che conoscono, e potrai ripetere tutte le volte che vuoi finché non avrai una lista di colleghi con cui fare i collegamenti.
And then, you can choose which ones to peer with and you’ll be a fully functioning member out of the Bitcoin network.

And again, there’s a few steps of randomness here, so, depending on which seed nodes you used or which of the peers of the seed node you decided to go and talk to, you’ll end up with a random set of nodes that you’re connected to. But that’s perfectly fine.

So now that you’re a member of the network, what is the network good for?

Well the network maintains the blockchain, so if you want to publish a transaction, you want to get the entire network to hear about it. And there’s a simple flooding algorithm to make this happen.
E poi, puoi scegliere con chi confrontarti e sarai un membro completamente funzionante fuori dalla rete Bitcoin.

E ancora, ci sono alcuni passaggi di casualità qui, quindi, a seconda dei nodi seme che hai usato o di quello dei peer del nodo seme con cui hai deciso di parlare, ti ritroverai con un insieme casuale di nodi che sei connesso a. Ma va benissimo.

Quindi, ora che sei un membro della rete, a cosa serve la rete?

Bene, la rete gestisce la blockchain, quindi se vuoi pubblicare una transazione, vuoi che l’intera rete ne venga a conoscenza. E c’è un semplice algoritmo di flooding per far sì che ciò accada.
03.05.04
So let’s say that node four here hears about new transaction, so Alice wants to pay Bob some money, Alice creates a Bitcoin transaction and submits it to node four. Or maybe her wallet software or her exchange does that on her behalf, but somehow this transaction gets to node four. Now node four says, great, I’ve got a new transaction, Alice wants to pay Bob. Let’s tell everybody about it, sometimes this is called a gossip protocol because it’s very simple. If you have news you try to tell as many people as you can, and they try to tell as many people as they can. Much like people gossiping in the real world. Quindi diciamo che il nodo quattro qui parla della nuova transazione, quindi Alice vuole pagare un po’ di soldi a Bob, Alice crea una transazione Bitcoin e la sottopone al nodo quattro. O forse il suo software di portafoglio o il suo scambio lo fa per suo conto, ma in qualche modo questa transazione arriva al nodo quattro. Ora il nodo quattro dice, fantastico, ho una nuova transazione, Alice vuole pagare Bob. Diciamolo a tutti, a volte questo è chiamato un protocollo di gossip perché è molto semplice. Se conosci delle notizie, cerchi di dirle a quante più persone puoi che a loro volta e cercano di dirle a quante più persone possono. Assomiglia a come le persone spettegolano nel mondo reale.
03.05.05
Great, so node four is gonna talk to its neighbors, node three and node two. And say “hey, check out this new transaction. Alice wants to pay Bob”. Ottimo, quindi il nodo quattro parlerà con i suoi vicini, il nodo tre e il nodo due. E dirà “hey, dai un’occhiata a questa nuova transazione. Alice vuole pagare Bob”.
03.05.06
And those nodes will add it to their own pool of pending transactions, so each node maintains a list of all the transactions they’ve heard about that haven’t been put into the blockchain yet. And then they can decide to forward that on to other nodes. E quei nodi lo aggiungeranno al loro pool di transazioni in sospeso, quindi ogni nodo mantiene un elenco di tutte le transazioni di cui hanno sentito parlare che non sono ancora state inserite nella blockchain. E poi possono decidere di inoltrarlo ad altri nodi.
03.05.07
So three is gonna talk to its neighbors, and say new transaction for you. Alice wants to pay Bob. Quindi i tre parleranno con i loro vicini e diranno di questa nuova tua transazione. Alice vuole pagare Bob.
03.05.08
That’ll end up in their transaction pools, and so on. And we wanna make sure that this process doesn’t go on forever. So let’s say that node two comes along later and tries to tell node seven, hey, new transaction, Alice wants to pay Bob. Questo finirà nei loro pool di transazioni, e così via. E vogliamo essere sicuri che questo processo non vada avanti per sempre. Quindi diciamo che il nodo due arriva più tardi e prova a dire al nodo sette, ehi, nuova transazione, Alice vuole pagare Bob.
03.05.09
Node seven is gonna say, that’s all right, node two, I’ve already heard about that, already got in my memory. I don’t need to forward it further. So eventually, this thing has to stop because every node will have heard about the new transaction and they won’t forward it anymore. And remember every transaction is identified uniquely by its hash, so each node can tell they’ve seen that hash before and that they don’t need to keep forwarding that transaction so it won’t loop around the network forever. Il Nodo sette dirà, va tutto bene, il secondo nodo, ne ho già sentito parlare, è già nella mia memoria. Non ho bisogno di inoltrarlo ulteriormente. Quindi alla fine, questa cosa deve finire perché ogni nodo avrà sentito parlare della nuova transazione e non la inoltrerà più. E ricorda ogni transazione viene identificato in modo univoco tramite il suo hash, quindi ogni nodo può dire di aver già visto quell’hash prima e di non dover continuare a inoltrare quella transazione in modo che non circoli all’infinito nella rete.
03.05.10
So how do nodes decide when they hear about a new transaction whether or not they should propagate it? The most important thing they do is they check to see, given their view of the blockchain, whether or not this transaction is valid. So they do all the transaction validation we talked about earlier. They run script, they see that the script checks out. They see that the coins that are being redeemed here haven’t already been spent. And if all of that checks out, then this looks like a valid transaction that they should try to relay, with a couple of other caveats. By default, nodes won’t relay the transaction if it’s a nonstandard script. If the script has any weird features, if it doesn’t match a fairly simple whitelist of scripts that nodes know about, even though it’s a valid transaction, the nodes won’t relay it. They’ll also make sure that they haven’t seen the transaction before. That’s that condition to avoid infinite loops. And there’s another property which is that they won’t relay the transaction if it looks like a double spend.

So if they’ve seen a transaction where Alice tries to send some specific coins to Bob, And then later they see a second transaction where Alice tries to send those same coins to Charlie, the nodes shouldn’t relay the second transaction. Even though either transaction could be valid, because those coins still haven’t been spent, they’ll only relay the first one they hear.

And that’s an extra guard against double spending.
Così come i nodi decidono quando senti parlare di una nuova transazione, indipendentemente dal fatto che debbano o meno propagarla? La cosa più importante che fanno è controllare, vista la loro visione della blockchain, se questa transazione sia o meno valida. Quindi fanno tutte le convalide delle transazioni di cui abbiamo parlato prima. Eseguono lo script, vedono che lo script esegue il check out. Vedono che le monete che vengono riscattate qui non sono state già spese. E se tutto ciò si verifica, allora sembra una transazione valida che dovrebbero provare a trasmettere, con un paio di altri avvertimenti. Per impostazione predefinita, i nodi non trasmetteranno la transazione se si tratta di uno script non standard. Se lo script ha delle caratteristiche strane, se non corrisponde ad una lista bianca di script abbastanza semplice di cui i nodi sono a conoscenza, anche se è una transazione valida, i nodi non la inoltreranno. Si assicureranno inoltre che non abbiano mai visto la transazione prima. Questa è la condizione per evitare loop infiniti. E c’è un’altra proprietà che è quella che non trasmetteranno la transazione se sembra una doppia spesa.

Quindi se hanno visto una transazione in cui Alice cerca di inviare alcune monete specifiche a Bob, E poi vedono una seconda transazione dove Alice cerca di inviare quelle stesse monete a Charlie, i nodi non dovrebbero inoltrare la seconda transazione. Anche se entrambe le transazioni possono essere valide, poiché tali monete non sono state ancora spese, trasmetteranno solo la prima che sentono.

E questa è una guardia in più contro la doppia spesa.
03.05.11
But it’s important to keep in mind that all of these checks are just sanity checks.

So well behaving nodes all implement these to try to keep the network healthy and running properly, but there’s no rule that says that nodes have to follow these specific steps. So since it’s a peer-to-peer network, and anybody can join, there is always the possibility of a node not following this exact protocol. Forwarding double spends, forwarding transactions that aren’t standard, forwarding transactions that aren’t valid. And that’s why it’s important that every node do the checking for itself.
Ma è importante tenere presente che tutti questi controlli sono solo dei controlli di sanità.

Così i nodi che si comportano bene li implementano per cercare di mantenere la rete in buone condizioni e funzionare correttamente, ma non c’è una regola che dice che i nodi devono seguire questi passaggi specifici. Quindi, dato che è una rete peer-to-peer e chiunque può unirsi, c’è sempre la possibilità che un nodo non segua questo protocollo esatto. Inoltro di doppia spesa, inoltro di transazioni che non sono standard, inoltro di transazioni che non sono valide.
03.05.12
So it’s possible that nodes will end up with a different view of the pending transaction pool based on what they’ve seen. So let’s go back to this example where node four originally relayed a transaction where Alice was trying to pay Bob, and let’s say that this transaction hasn’t yet flooded to the entire network. And before it gets to everybody, node one is going to announce a new transaction and say hey, I just heard Alice is trying to pay Charlie. Now from node one’s perspective this is a valid transaction, and they haven’t seen the other transaction where Alice is trying to pay Bob. Ed è per questo che è importante che ogni nodo esegua il controllo autonomamente. Quindi è possibile che i nodi finiscano con una diversa visualizzazione del pool di transazioni in sospeso in base a ciò che hanno visto. Quindi torniamo a questo esempio in cui il nodo quattro originariamente trasmetteva una transazione in cui Alice stava cercando di pagare Bob, e diciamo che questa transazione non è ancora stata invasa dall’intera rete. E prima che arrivi a tutti, il nodo uno sta per annunciare una nuova transazione e dire hey, ho appena sentito che Alice sta cercando di pagare Charlie. Ora dal punto di vista del nodo uno questa è una transazione valida, e non hanno visto l’altra transazione in cui Alice sta cercando di pagare Bob.
03.05.13
So, node one is gonna implement the protocol normally and is gonna tell all of her neighbors about it.

Now the neighbors that haven’t heard the conflicting transactions yet will added to their transaction pool.

Whereas other neighbors, like node six in this example, they’ve already received the transaction where Alice is trying to pay Bob. So, node six is gonna say, I don’t wanna hold two conflicting transactions in my pool I’ll just keep the one I already have.
Quindi, il nodo uno implementerà normalmente il protocollo e lo dirà a tutti i suoi vicini a riguardo.

Ora i vicini che non hanno ancora ascoltato le transazioni in conflitto verranno aggiunti al loro pool di transazioni.

Mentre altri vicini, come il nodo sei in questo esempio, hanno già ricevuto la transazione in cui Alice sta cercando di pagare Bob. Quindi, il nodo sei dirà, non voglio tenere due transazioni in conflitto nel mio pool, terrò solo quello che ho già.
03.05.14
The network may end up in a divided state here, where different nodes have a different view of what the pending transaction pool is, but that’s fine. These transactions haven’t been published in the blockchain yet, so this is just a temporary state where nodes disagree on which transaction should be put into the next block.

In practice, this is a race condition.
La rete potrebbe finire in uno stato di divisione, dove diversi nodi hanno una visione diversa di qual è il pool di transazioni in sospeso, ma va bene. Queste transazioni non sono ancora state pubblicate nella blockchain, quindi questo è solo uno stato temporaneo in cui i nodi non sono d’accordo su quale transazione deve essere inserita nel blocco successivo.

In pratica, questa è una condizione di competizione
.
03.05.15
If nodes have a different perspective on which transactions are pending, or which blocks have been accepted, that’s okay in a temporary state. And eventually, they’ll sort it out.
So in the case of transactions, if different nodes have a different view of the pending transaction pool, depending on who mines the next block, they’ll essentially break the tie with a race condition and decide which of those two pending transactions should end up being put permanently into a block. And once one of those two transactions has been put into a block, other nodes will see that the transaction that they’re holding onto in their pool is now never going to make it into a block, because it would be a double spend, and they’ll just drop it.

So if the transaction where Alice tried to pay Bob successfully makes it into a block first, the nodes who heard the transaction where Alice tried to pay Charlie will just say that’s not a valid transaction anymore so I can forget it. So the default behavior is for nodes to just hang onto whatever they hear first, which means that network position matters. If two conflicting transactions, or two conflicting blocks get announced at two different positions in the network, they’ll both flood in opposite directions. And the nodes which end up with one transaction or the other will depend on which side of the network they started out closer to.

Of course this assumes that every miner implements this logic where they keep whatever they hear first, but there’s no central authority enforcing this. So every node is free to do whatever logic they want. So if for some reason if any node wants to, they can choose to implement any other logic they for choosing which blocks or which transactions to forward. We’ll talk about that more in our lecture on mining, why miners might want to implement some different logic other than the default.
Se i nodi hanno una prospettiva diversa su cui le transazioni sono in sospeso, o quali blocchi sono stati accettati, va bene in uno stato temporaneo. E alla fine, lo risolvono.
Quindi, nel caso delle transazioni, se i diversi nodi hanno una visione diversa del pool di transazioni in sospeso, a seconda di chi estrae il blocco successivo, sostanzialmente interromperanno il legame con una condizione di competizione e decidono quale di queste due transazioni in sospeso dovrebbe finire per essere messa definitivamente in un blocco. E una volta che una di queste due transazioni è stata messa in un blocco, altri nodi vedranno che la transazione che stanno trattenendo nel loro pool non lo renderà mai un blocco, perché sarebbe una doppia spesa, e lo faranno.

Quindi se la transazione in cui Alice ha cercato di pagare Bob riesce a farlo diventare un blocco, i nodi che hanno ascoltato la transazione in cui Alice ha cercato di pagare Charlie diranno che non è più una transazione valida, quindi posso dimenticarla. Quindi il comportamento predefinito è che i nodi si blocchino su ciò che sentono prima, il che significa che la posizione della rete è importante. Se due transazioni in conflitto o due blocchi in conflitto vengono annunciati in due diverse posizioni nella rete, entrambi si riverseranno in direzioni opposte. E i nodi che finiscono con una transazione o l’altro dipenderà da quale lato della rete hanno iniziato più vicino.

Naturalmente questo presuppone che ogni minatore implementa questa logica in cui mantengono tutto ciò che sentono prima, ma non c’è un’autorità centrale che lo imponga. Quindi ogni nodo è libero di fare qualsiasi logica voglia. Quindi, se per qualche ragione se un nodo lo desidera, possono scegliere di implementare qualsiasi altra logica per scegliere quali blocchi o quali transazioni inoltrare. Ne parleremo di più nella nostra sezione sul mining, perché i minatori potrebbero voler implementare una logica diversa dall’impostazione predefinita.
03.05.16
Now I’ve been talking mostly about transactions here. The logic for announcing new blocks, whenever miners find a new block, is almost exactly the same as propagating a new transaction. So the same algorithm is used to announce new blocks around the network. It’s the same flooding algorithm and the same gossip process. And in this case instead of verifying that the transaction is valid by running a script, the nodes are going to verify that the new block is valid by computing the hash. And making sure that it starts with a sufficient number of zeroes, to meet the difficulty target.

Now validating a block is also much more in-depth because in addition to validating the header. And seeing that the hash value is correct, nodes are asked to validate every transaction included in the block to make sure that the block contains only valid new transactions.

And the other check, which is this really important critical part, if it makes BitCcoin consensus what it is, is that nodes shouldn’t forward a block, unless it builds on their perspective of the current longest chain. So they have a view of the blockchain, and they should only forward new blocks if they come at the very end of the chain, not at some earlier point.

And this avoids forks building up. So just like with transactions, nodes can implement different logic if they want. They’re free to relay blocks that aren’t valid, or to relay blocks that build off of an earlier point in the blockchain. So some nodes may be trying to relay a block that doesn’t extend the current longest chain, that actually builds a fork. And that’s okay, the protocol is designed to withstand that.
Ora ho parlato principalmente di transazioni. La logica per annunciare nuovi blocchi, ogni volta che i minatori trovano un nuovo blocco, è quasi esattamente la stessa cosa che propagare una nuova transazione. Quindi lo stesso algoritmo viene utilizzato per annunciare nuovi blocchi attorno alla rete. È lo stesso algoritmo di flooding e lo stesso processo di gossip. E in questo caso invece di verificare che la transazione sia valida eseguendo uno script, i nodi verificheranno che il nuovo blocco è valido calcolando l’hash. E assicurandoci che inizi con un numero sufficiente di zeri, per raggiungere l’obiettivo di difficoltà.

Ora la convalida di un blocco è anche molto più approfondita perché oltre a convalidare l’intestazione. E visto che il valore hash è corretto, ai nodi viene chiesto di convalidare ogni transazione inclusa nel blocco per assicurarsi che il blocco contenga solo nuove transazioni valide.

E l’altro controllo, che è questa parte critica molto importante, se rende il consenso di BitCcoin quello che è, è che i nodi non dovrebbero inoltrare un blocco, a meno che non si costruisca sulla loro prospettiva dell’attuale catena più lunga. Quindi hanno una visione della blockchain, e dovrebbero solo inoltrare nuovi blocchi se arrivano alla fine della catena, non in qualche punto precedente.

E questo evita l’accumulo di forche. Quindi, proprio come con le transazioni, i nodi possono implementare una logica diversa se vogliono. Sono liberi di inoltrare blocchi non validi o di ritrasmettere blocchi che si basano su un punto precedente della blockchain. Quindi alcuni nodi potrebbero provare a trasmettere un blocco che non estende l’attuale catena più lunga, che in realtà genera una forcella. E va bene, il protocollo è progettato per resistere a questo.
03.05.17
So how long does this floating algorithm actually take? How much latency is imposed here?

This is a graph showing the average time for new blocks to propagate to every node in the network, and the three lines show the 25th, the 50th, and the 75th percentile of how long it takes for a new block to reach every node in the network. And if you look at the 75th percentile there for some of the larger blocks, and this is heavily dependent on size because of bandwidth constraints that some nodes have, you’ll see that the average propagation time is over 30 seconds. So this shows that this isn’t a particularly efficient protocol. On the Internet, 30 seconds is a pretty long time for people to hear about something.

The reason it takes so long is because the protocol is not very efficient. It wasn’t designed to be efficient. It was designed to be simple and to have no structure so that every node is equal and they can come and go at every time.

And as a result the topology may not be optimized for fast communication.

A block may need to go through many nodes before it reaches the most distant nodes in the network. Whereas if you design a network top down for efficiency you would design it to make sure that the path between any two nodes was very short. For Bitcoin, it’s more important to have a decentralized structure where all nodes are equal, even if that means that the propagation time can be over 30 seconds in some cases.
Quindi quanto dura questo algoritmo floating? Quanta latenza viene imposta qui?

Questo è un grafico che mostra il tempo medio per i nuovi blocchi da propagare a ogni nodo della rete, e le tre linee mostrano il 25°, il 50° e il 75° percentile di quanto tempo ci vuole per un nuovo blocco per raggiungere ogni nodo della rete. E se guardi al 75° percentile per alcuni dei blocchi più grandi, e questo dipende fortemente dalle dimensioni a causa dei vincoli di larghezza di banda che hanno alcuni nodi, vedrai che il tempo medio di propagazione è di oltre 30 secondi. Questo dimostra che questo non è un protocollo particolarmente efficiente. Su Internet, 30 secondi sono un tempo piuttosto lungo per le persone che sentono parlare di qualcosa.

Il motivo per cui ci vuole così tanto tempo è perché il protocollo non è molto efficiente. Non è stato progettato per essere efficiente. È stato progettato per essere semplice e per non avere una struttura in modo tale che ogni nodo sia uguale e possa andare e venire in ogni momento.

E come risultato la topologia potrebbe non essere ottimizzata per una comunicazione veloce.

Un blocco potrebbe dover passare attraverso molti nodi prima che raggiunga i nodi più lontani nella rete. Considerando che se si progetta una rete verso il basso per efficienza, si progetta per assicurarsi che il percorso tra due nodi sia molto breve. Per Bitcoin, è più importante avere una struttura decentralizzata in cui tutti i nodi sono uguali, anche se ciò significa che in alcuni casi il tempo di propagazione può essere superiore a 30 secondi.
03.05.18
So how big is a Bitcoin network? Well, there is no official statistics anywhere, because again there is no central authority overseeing it. It’s simply whatever the nodes participating. They are the Bitcoin network. So it’s impossible to measure exactly and it’s changing all the time. But a number of researchers have looked into this and tried to come up with estimates.

On the high end, some researchers have said that over a million IP addresses in a given month will at some point be running the Bitcoin protocol and acting at least temporarily as a Bitcoin node.

But if you look at full nodes that are actually permanently connected and are fully validating every transaction they hear, and running the full protocol, it’s only about 5 or 10,000, which may be a surprisingly low number.

And in fact, that number may be dropping. There’s no evidence that the number of fully validating nodes is going up. And there’s some concern that the number of fully-validating nodes is actually going down.
Quindi, quanto è grande una rete Bitcoin? Beh, non ci sono statistiche ufficiali da nessuna parte, perché di nuovo non esiste un’autorità centrale che la controlla. È semplicemente qualunque cosa partecipino i nodi. Sono la rete Bitcoin. Quindi è impossibile misurare esattamente e sta cambiando tutto il tempo. Ma un certo numero di ricercatori ha esaminato questo aspetto e cercato di fornire stime.

Nella fascia alta, alcuni ricercatori hanno affermato che oltre un milione di indirizzi IP in un dato mese ad un certo punto eseguiranno il protocollo Bitcoin e agiranno almeno temporaneamente come un nodo Bitcoin.

Ma se si guardano i nodi completi che sono effettivamente connessi in modo permanente e stanno convalidando completamente ogni transazione che ascoltano, ed eseguendo il protocollo completo, sono solo circa 5 o 10.000, che può essere un numero sorprendentemente basso.

E infatti , quel numero potrebbe essere in calo. Non ci sono prove che il numero di nodi completamente convalidanti sta aumentando. E c’è qualche preoccupazione sul fatto che il numero di nodi completamente validi sia effettivamente in calo.
03.05.19
So to be a fully-validating node, you wanna stay permanently connected so that you hear about all data. The longer you’re offline, the more catch up you’re gonna have to do to hear about all the transactions you missed. And you’re gonna have to stored the entire block chain.

You’ll also need a pretty active network connection so that you can hear every new transaction and forward it to your peers.
Quindi, per essere un nodo pienamente convalidante, si deve rimanere connessi in modo permanente in modo che si senta parlare di tutti i dati. Più a lungo sei offline, più rimedi dovrai fare per sapere tutte le transazioni che hai perso. E dovrai memorizzare l’intera catena di blocchi.

Avrai anche bisogno di una connessione di rete abbastanza attiva in modo che tu possa sentire ogni nuovo transazione e inoltralo ai tuoi colleghi.
03.05.20
So you can see the growth over time here, and currently it takes about 20 GB to store the entire blockchain.

Which isn’t too bad, if you have a few years old PC with an active network connection you have what it takes to be a fully validating node. Although you basically need to dedicate that machine to doing that, and not much else.
Puoi vedere la crescita nel tempo qui, e attualmente occorrono circa 20 GB per archiviare l’intera blockchain.

Che non è un problema, se hai un PC vecchio di alcuni anni con una rete attiva connessione, hai quello che serve per essere un nodo pienamente validante. Sebbene tu abbia fondamentalmente bisogno di dedicare quella macchina a questo, e non molto altro.
03.05.21
Fully validating nodes, maintain the entire set of unspent transaction outputs.

So every coin that’s available to be spent, and remember that those are just unspent output transactions.
Ideally, you’d like to store this in RAM, so that when you hear a new proposed transaction on the network, you can quickly check the transaction that it’s attempting to claim. Run the script and see if it the signature is valid.
So currently there are about 12 million unspent transactions. And that’s out of 44 million transactions that have ever been proposed.

So fortunately, that’s still small enough to fit in less than a gigabyte of RAM in an efficient data structure. So that if you’re running a fully validating node, every time you hear about a new transaction, you can quickly check, run the redemption script, and see that this is a valid transaction that you should put in your pending transaction pool.

So in contrast to being a fully validating node, there are lightweight nodes, also called thin clients or simple payment verification clients.

This is actually the vast majority of nodes on the Bitcoin network, and the difference here is that these nodes aren’t attempting to store the entire blockchain.

They only store the pieces that they need to verify some specific transactions that they care about.
So for example if you run a wallet, your wallet might want to be a simple payment verification node, and if somebody sends money to you, you’ll act as a node. You’ll download the bits of the blockchain that you need to verify that the person sending you the money actually owned it and that the transaction sending it to you actually gets included in the blockchain, but you won’t care about the thousands of other transactions going on that don’t affect you.
Completamente validando i nodi, mantieni l’intero set di output di transazione non spesi.

Ogni moneta è disponibile per essere spesa, e ricorda che si tratta solo di transazioni in uscita non spesa.

Preferibilmente, ti piacerebbe archiviarlo nella RAM, così che quando ascolti nuova transazione proposta sulla rete, è possibile controllare rapidamente la transazione che sta tentando di richiedere. Esegui lo script e verifica se la firma è valida.

Attualmente ci sono circa 12 milioni di transazioni non spese. E questo su 44 milioni di transazioni che sono mai state proposte.

Fortunatamente, è ancora abbastanza piccolo da adattarsi a meno di un gigabyte di RAM in una struttura dati efficiente. In questo modo, se si sta eseguendo un nodo di convalida completo, ogni volta che si sente una nuova transazione, è possibile controllare rapidamente, eseguire lo script di utilizzo e verificare che si tratti di una transazione valida da inserire nel proprio pool di transazioni in sospeso.

A differenza di essere un nodo completamente validante, ci sono nodi leggeri, chiamati anche thin client o semplici client di verifica dei pagamenti.

Questa è in realtà la stragrande maggioranza dei nodi sulla rete Bitcoin, e la differenza è che questi nodi non stanno tentando di memorizza l’intera blockchain.

Conservano solo i pezzi di cui hanno bisogno per verificare alcune transazioni specifiche a cui tengono.
Così, ad esempio, se gestisci un portafoglio, il tuo portafoglio potrebbe voler essere un semplice nodo di verifica dei pagamenti e se qualcuno invia denaro a te, agirai come un nodo. Scaricherai i pezzi della blockchain di cui hai bisogno per verificare che la persona che ti ha inviato i soldi effettivamente li abbia posseduti e che la transazione che ti ha inviato venga effettivamente inclusa nella blockchain, ma non ti interessano le migliaia di altre le transazioni in corso che non influiscono su di te.
03.05.22
Now an SPV client like this won’t have the full security level of being a fully validating node.

And reason is that when they hear a new block, the only thing they can check is the block header. They can check to see that the block was difficult to mine, but they can’t check to see that every transaction included in that block is actually valid, because they don’t the entire previous blockchain. They don’t know the entire unspanned transaction output set. They can only validate the transactions that actually affect them, so they’re essentially trusting the fully validating nodes to have validated all the other transactions that are out there. So this isn’t a bad security tradeoff. You’re assuming there are fully validating nodes out there that are doing the hard work, and that if Myers went through the trouble to mine this block, which is a really expensive process, they probably also did some validation to make sure that this block wouldn’t be rejected.

And the cost savings of being an SPV node are huge.

It’s about 1000 times smaller to just store block headers than to store all of the previous transactions, so instead of storing about 20 GB of data, you’re down to about 20 MB. Which is something that almost anybody on a PC or even on a phone can store and act as a limited node in the Bitcoin network.
Ora un client SPV come questo non avrà il pieno livello di sicurezza di essere un nodo completamente validante.

E la ragione è che quando sentono un nuovo blocco, l’unica cosa che possono controllare è l’intestazione del blocco. Possono verificare che il blocco fosse difficile da estrarre, ma non possono controllare che ogni transazione inclusa in quel blocco sia effettivamente valida, perché non è l’intera blockchain precedente. Non conoscono l’intero set di output delle transazioni non visualizzate. Possono solo validare le transazioni che effettivamente li riguardano, quindi si fidano essenzialmente dei nodi pienamente convalidanti per avere convalidato tutte le altre transazioni che sono là fuori. Quindi questo non è un cattivo compromesso di sicurezza. Supponete che là fuori ci siano nodi di validazione completi che stanno facendo il duro lavoro e che se Myers ha affrontato il problema di estrarre questo blocco, che è un processo molto costoso, probabilmente hanno anche fatto delle convalide per assicurarsi che questo blocco non sarebbe rifiutato.

E i risparmi sui costi di essere un nodo SPV sono enormi.

È circa 1000 volte più piccolo per archiviare le intestazioni dei blocchi piuttosto che per archiviare tutte le transazioni precedenti, quindi invece di memorizzare circa 20 GB di dati, sei fino a circa 20 MB. Che è qualcosa che quasi chiunque su un PC o anche su un telefono può memorizzare e agire come un nodo limitato nella rete Bitcoin.

[top]
© Joseph Bonneau – Postdoctoral Research Associate – Princeton University

W03.04
Blocchi Bitcoin
W03.06
Limitazioni & miglioramenti