SPV potrebbe supportare un miliardo di utenti Bitcoin ? Valutare una richiesta di ridimensionamento

Jameson Lopp è un ingegnere informatico presso BitGo, creatore di statoshi.info e fondatore di bitcoinsig.com.

In questo articolo Opinioni , Lopp analizza in modo approfondito le affermazioni secondo cui sarebbe sicuro rimuovere il limite alla dimensione dei blocchi di Bitcoin e affidarsi invece ai metodi di "verifica dei pagamenti semplificata" (SPV) esistenti.

Una nuova affermazione si sta perpetuando nel dibattito sulla scalabilità Bitcoin .

Abbiamo sentito dire che è sicuro rimuovere il limite di dimensione del blocco perché Bitcoin può facilmente scalare a enormi dimensioni di blocco che supporterebbero miliardi di utenti tramite i metodi di "verifica semplificata dei pagamenti" (SPV) esistenti. Presumibilmente, SPV è molto scalabile a causa della piccola quantità di dati che richiede a un client SPV di archiviare, inviare e ricevere.

Analizziamo questa affermazione da più prospettive.

Come funziona SPV

Satoshi

ha descritto la progettazione di alto livello per SPV nelLibro bianco Bitcoin, anche se T fu implementato fino a due anni dopo, quando Mike Hearn creò BitcoinJ.

Eliminando le transazioni che T erano rilevanti per il portafoglio del cliente SPV, è stato possibile ottenere notevoli risparmi nell'utilizzo del disco. Ci sono voluti altri 18 mesi per PIP 37da pubblicare, fornendo una specifica per il filtraggio Bloom delle transazioni, basandosi quindi sulla radice Merkle dell'intestazione del blocco per dimostrare l'inclusione di una transazione in un blocco come descritto da Satoshi. Ciò ha fornito un utilizzo di larghezza di banda notevolmente ridotto.

Quando un client SPV si sincronizza con la rete Bitcoin , si connette a ONE o più nodi Bitcoin completamente convalidati, determina l'ultimo blocco all'estremità della catena, quindi richiede tutte le intestazioni dei blocchi con un comando "getheaders" per i blocchi dall'ultimo blocco sincronizzato fino all'estremità della catena.

Se il client SPV è interessato solo a transazioni specifiche corrispondenti a un portafoglio, costruirà un filtro Bloom basato su tutti gli indirizzi per i quali il suo portafoglio possiede chiavi private e invierà un comando "filterload" a tutti i nodi, in modo che sappiano di dover restituire solo le transazioni che corrispondono al filtro.

Dopo aver sincronizzato le intestazioni dei blocchi ed eventualmente caricato un filtro Bloom, il client SPV invia un comando "getdata" per Request ogni singolo blocco (eventualmente filtrato) che non è riuscito a vedere dall'ultima volta che è stato online, in sequenza.

Una volta sincronizzato, se il client rimane connesso ai peer del nodo completo, riceverà solo messaggi di inventario "inv" per le transazioni che corrispondono al filtro Bloom caricato.

Scalabilità del cliente SPV

Dal punto di vista del cliente, il filtraggio Bloom è un mezzo molto efficiente per trovare transazioni rilevanti nella blockchain, utilizzando al contempo risorse di CPU, larghezza di banda e spazio su disco minimi.

Ogni intestazione di blocco Bitcoin è di soli 80 byte, quindi al momento in cui scrivo sono solo 38 megabyte di dati per l'intera cronologia di oltre otto anni della blockchain. Ogni anno (circa 52.560 blocchi), aggiunge solo 4,2 megabyte, indipendentemente dalla dimensione dei blocchi nella blockchain.

Anche l'albero di Merkle utilizzato per dimostrare l'inclusione di una transazione in un blocco è estremamente scalabile. Poiché ogni nuovo "livello" aggiunto all'albero raddoppia il numero totale di "foglie" che può rappresentare, T è necessario un albero molto profondo per dimostrare in modo compatto l'inclusione di una transazione, anche in un blocco con milioni di transazioni.

tramitePadroneggiare Bitcoin

La struttura dati dell'albero di Merkle è così efficiente che può rappresentare 16 milioni di transazioni con una profondità di soli 24, il che è sufficiente per rappresentare un blocco da 8 GB. Tuttavia, la prova dell'albero di Merkle per una tale transazione rimane di dimensioni inferiori a 1 KB!

📷tramitePadroneggiare Bitcoin

È abbastanza chiaro che, dal punto di vista di un cliente SPV, la rete Bitcoin potrebbe essere scalata a blocchi multi-gigabyte e i clienti SPV avrebbero pochi problemi a elaborare le piccole quantità di dati richieste, anche su un telefono cellulare con una connessione 3G.

Ma ahimè, scalare la rete Bitcoin non è poi così semplice.

Scalabilità del server SPV

Mentre SPV è incredibilmente efficiente per i client, lo stesso non vale per il server, ovvero per i nodi completi a cui i client SPV inviano richieste. Questo metodo mostra una scarsa scalabilità per una serie di motivi.

I nodi nella rete devono elaborare una quantità di dati estremamente grande per restituire i risultati per un singolo peer, e devono ripetere questo lavoro su ogni blocco per ogni peer che lo richiede. L'I/O su disco diventa rapidamente un collo di bottiglia.

Ogni client SPV deve sincronizzare l'intera blockchain dall'ultima volta che ha avuto un contatto con la rete, oppure, se ritiene di aver perso delle transazioni, dovrà rianalizzare l'intera blockchain dalla data di creazione del wallet. Nel caso peggiore, al momento della scrittura, si tratta di circa 150 GB. Il nodo completo deve caricare ogni singolo blocco dal disco, filtrarlo in base alle specifiche del client e restituire il risultato.

Poiché le blockchain sono una forma di registro append-only, questa quantità non smetterà mai di crescere. Senza ampie modifiche al protocollo, la potatura della blockchain è incompatibile con BIP 37, che si aspetta che tutti i blocchi siano disponibili in tutti i nodi completi che pubblicizzano NODE_BLOOM.

I client SPV BIP 37 possono essere ingannati per omissione. Per combattere questo, i client SPV si collegano a più nodi (di solito quattro) anche se non è ancora una garanzia: i client SPV possono essere partizionati dalla rete principale tramite un attacco Sybil. Ciò aumenta il carico sulla rete di nodi completi di un fattore quattro.

Per ogni client SPV connesso che è stato sincronizzato con la punta della blockchain, ogni blocco e transazione in arrivo deve essere filtrato individualmente. Ciò comporta una quantità non trascurabile di tempo CPU e deve essere fatto separatamente per ogni client SPV connesso.

Elaborare i numeri

Al momento in cui scrivo ci sono circa 8.300 nodi completi in esecuzione che accettano connessioni in entrata; circa 8.000 di essi pubblicizzano NODE_BLOOM e dovrebbero quindi essere in grado di servire le richieste dei client SPV. Ma quanti client SPV può ragionevolmente supportare l'attuale numero di nodi completi in ascolto?

Cosa sarebbe necessario affinché la rete fosse composta da nodi completi in grado di supportare sia un miliardo di utenti giornalieri sia blocchi sufficientemente grandi da ospitare le loro transazioni?

Bitcoin CORE ha come impostazione predefinita un massimo di 117 connessioni in entrata, il che creerebbe un limite superiore di 936.000 socket disponibili sulla rete. Tuttavia, la maggior parte di questi socket è già consumata oggi.

Ogni nodo completo si collega di default ad altri otto nodi completi. Sviluppatore Bitcoin CORE Luke-Jr (molto approssimativo) conteggio dei nodi stima 100.000 nodi totali al momento della scrittura; 92.000 dei quali T rendono disponibili socket per i client SPV. Ciò consuma 800.000 socket disponibili solo per i nodi completi, lasciandone disponibili solo 136.000 per i client SPV.

Ciò mi porta a concludere che circa l'85 percento dei socket disponibili viene consumato dalla rete mesh dei nodi completi. (Vale la pena notare che il metodo di stima di Luke-Jr T riesce a determinare quanto tempo i nodi non in ascolto trascorrono online; sicuramente almeno alcuni di essi si disconnettono e si riconnettono periodicamente.)

Il mio nodo che alimentastatoshi.infoin media 100 peer full node (otto in uscita, 92 in entrata) e 25 client SPV. Ciò significa che l'80 percento dei socket disponibili viene consumato dai full node.

Se vogliamo che anche 1 miliardo di client SPV siano in grado di utilizzare un sistema del genere, ci dovranno essere sufficienti risorse full node disponibili per servirli: socket di rete, cicli di CPU, I/O su disco e così via. Possiamo far funzionare la matematica?

Per dare il beneficio del dubbio alle affermazioni sulla scalabilità degli SPV, utilizzerò alcune ipotesi prudenti secondo cui ciascuno dei miliardi di utenti degli SPV:

– Invia e ricevi ONE transazione al giorno.

– Sincronizzare il proprio portafoglio con la punta della blockchain una volta al giorno.

– Interrogare quattro nodi diversi durante la sincronizzazione per ridurre le possibilità di essere ingannati per omissione.

Un miliardo di transazioni al giorno, se distribuite equamente (cosa che sicuramente non sarebbe) darebbe come risultato circa 7 milioni di transazioni per blocco. Grazie alla grande scalabilità degli alberi Merkle, sarebbero necessari solo 23 hash per dimostrare l'inclusione di una transazione in tale blocco: 736 byte di dati più una media di 500 byte per la transazione.

Aggiungendo altri 12 KB di intestazioni di blocco al giorno, un client SPV utilizzerebbe comunque solo circa 20 KB di dati al giorno.

Tuttavia, 1 miliardo di transazioni al giorno genera 500 GB di dati blockchain che i nodi completi possono archiviare ed elaborare. E ogni volta che un client SPV si connette e chiede di trovare delle transazioni per il suo portafoglio nel giorno precedente, quattro nodi completi devono leggere e filtrare 500 GB di dati ciascuno.

Ricorda che attualmente ci sono circa 136.000 socket disponibili per i client SPV sulla rete di 8.000 nodi completi che servono SPV. Se ogni client SPV utilizza quattro socket, allora solo 34.000 client possono sincronizzarsi con la rete in un dato momento. Se ci fossero più persone online contemporaneamente, altri utenti che provassero ad aprire il loro portafoglio otterrebbero errori di connessione quando provassero a sincronizzarsi con la punta della blockchain.

Pertanto, affinché la rete attuale supporti 1 miliardo di utenti SPV che si sincronizzano una volta al giorno, mentre solo 34.000 possono sincronizzarsi in un dato momento, si tratterebbe di 29.400 "gruppi" di utenti che devono connettersi, sincronizzarsi e disconnettersi: ogni utente dovrebbe essere in grado di sincronizzare i dati del giorno precedente in meno di tre secondi.

Ciò pone un BIT' di enigma perché richiederebbe che ogni nodo completo sia in grado di leggere e filtrare 167 GB di dati al secondo per client SPV in modo continuo. Con 20 client SPV per nodo completo, ciò significa 3.333 GB al secondo. Non sono a conoscenza di alcun dispositivo di archiviazione in grado di tale throughput. Dovrebbe essere possibile creare un enorme array RAID 0 di dischi allo stato solido di fascia altache possono raggiungere circa 600 MB/s ciascuno.

Avresti bisogno di 5.555 unità per raggiungere il throughput target. Il disco di esempio collegato costa $ 400 al momento della scrittura e ha circa 1 TB di capacità, abbastanza per archiviare due giorni di blocchi in questa rete teorica. Quindi, avresti bisogno di un nuovo array di dischi ogni due giorni, il che ti costerebbe oltre $ 2,2 milioni, ovvero oltre $ 400 milioni per archiviare un anno di blocchi e soddisfare comunque il throughput di lettura richiesto.

Naturalmente, possiamo giocare con queste ipotesi e modificare vari numeri. Possiamo produrre uno scenario in cui il costo del nodo sia più ragionevole?

Proviamo:

Cosa succederebbe se avessimo 100.000 nodi completi che eseguono tutti dischi rotanti più economici e ad alta capacità e in qualche modo li convincessimo tutti ad accettare connessioni client SPV? Cosa succederebbe se riuscissimo anche a modificare il software del nodo completo per supportare 1.000 client SPV connessi?

Ciò ci darebbe 100 milioni di socket disponibili per i client SPV che potrebbero supportare 25 milioni di client SPV simultanei sulla rete. Quindi ogni client SPV avrebbe 2.160 secondi al giorno per sincronizzarsi con la rete. Affinché un nodo completo possa KEEP il passo con la domanda, dovrebbe mantenere una velocità di lettura costante di 231 MB/s per client SPV, il che si tradurrebbe in 231 GB/s ipotizzando 1.000 client SPV connessi.

Un disco rigido da 7.200 RPM può leggere circa 220 MB/s, quindi è possibile raggiungere questa velocità di lettura con un array RAID 0 di BIT più di 1.000 unità.

Al momento della scrittura è possibile acquistare unUnità da 10 TB a $ 400, quindi un array RAID da 400.000 $ di queste unità consentirebbe di archiviare blocchi pari a 20 giorni, il che equivale a una cifra molto più gestibile di 7,2 milioni di $ per archiviare blocchi pari a un anno, continuando a soddisfare i requisiti di velocità di lettura del disco.

Vale la pena notare che ONE sano di mente farebbe funzionare un array RAID 0 con così tante unità perché un singolo guasto di unità corromperebbe l'intero array di dischi. Quindi un array RAID con tolleranza agli errori sarebbe ancora più costoso e meno performante. Sembra anche incredibilmente ottimistico che 100.000 organizzazioni sarebbero disposte a sborsare milioni di dollari all'anno per far funzionare un nodo completo.

Un altro punto da notare è che queste stime prudenti presumono anche che i client SPV si coordinerebbero in qualche modo per distribuire i loro tempi di sincronizzazione in modo uniforme durante ogni giorno. In realtà, ci sarebbero picchi e cali ciclici giornalieri e settimanali di attività: la rete dovrebbe avere una capacità decisamente superiore a quella stimata sopra per soddisfare la domanda di picco.

Altrimenti molti client SPV non riuscirebbero a sincronizzarsi durante le ore di picco.

È interessante notare che la modifica del numero di socket per nodo T influisce sul carico complessivo su un dato nodo completo: finisce comunque per dover elaborare la stessa quantità di dati. Ciò che conta davvero in questa equazione è il rapporto tra nodi completi e client SPV. E, naturalmente, la dimensione dei blocchi nella catena che i nodi completi devono elaborare.

Il risultato finale sembra inevitabile: il costo di gestione di un nodo completo in grado di soddisfare la domanda SPV di un miliardo di transattori giornalieri on-chain sarebbe astronomico.

Alla ricerca di una via di mezzo

A questo punto, è abbastanza chiaro che un miliardo di transazioni al giorno pone i costi di gestione di un nodo completamente convalidato fuori dalla portata di tutti, fatta eccezione per le entità più ricche.

Ma cosa succederebbe se capovolgessimo questo calcolo e provassimo invece a trovare una formula per determinare il costo dell'aggiunta di carico alla rete aumentando la produttività delle transazioni on-chain?

Affinché la rete Bitcoin possa supportare un numero target di transazioni al secondo (aggiungendo capacità per 86.400 nuovi utenti netti giornalieri), possiamo calcolare i requisiti di throughput del disco per nodo come:

Questo ci fornisce la velocità minima di lettura del disco al secondo per un nodo completo per soddisfare la domanda dei client SPV. Con le caratteristiche esistenti della rete e la Tecnologie disponibile, possiamo estrapolare un costo stimato del funzionamento del nodo utilizzando la velocità del disco come collo di bottiglia presunto. Si noti che ci sono sicuramente altri vincoli di risorse che entrerebbero in gioco, aumentando così il costo del funzionamento del nodo completo.

Per ilseguenti calcoliHo utilizzato queste ipotesi:

– Dimensione media della transazione in byte = 500 byte in base astatoshi.info.

– Numero totale di utenti SPV = ONE per transazione al giorno.

– Socket consumati da un client SPV = standard di quattro.

– Numero di socket disponibili per i client SPV su ciascun nodo completo = numero calcolato in precedenza pari a 20.

– Numero totale di socket di rete disponibili per i client SPV = numero calcolato in precedenza pari a 136.000.

– Costo della capacità di elaborazione e dello spazio del disco rigido = $ 400 Unità da 10 TB a 7.200 RPM in configurazione RAID 0.

Sfortunatamente, i requisiti di throughput del disco e quindi il costo per gestire un nodo completo aumentano in modo quadratico in relazione al numero di transazioni al secondo. I costi diventano rapidamente insostenibili per la maggior parte delle entità.

Per riferimento, ricorda che Visa elabora circa 2.000 transazioni al secondo. Su Bitcoin ciò richiederebbe quasi $ 200.000 di dischi solo per KEEP il passo con la domanda SPV. ONE punto degno di nota è che questi grafici KEEP il numero di nodi completi costante a 8.000: in realtà, probabilmente diminuirebbero all'aumentare del costo, aumentando così i requisiti di throughput e il costo di gestione dei nodi rimanenti per aumentare ancora più rapidamente.

Sembra che questa sia una forza combinata della centralizzazione dei nodi.

I sondaggi (non scientifici) che ho condotto un anno prima hanno mostrato che il 98% degli operatori di nodi non pagherebbe più di $ 100 al mese per gestire un nodo, anche se avessero investito molto in Bitcoin. Scommetterei che aumentare le transazioni on-chain di bitcoin di un ordine di grandezza comporterebbe la perdita della maggior parte dei nodi completi, mentre un aumento di due ordini di grandezza comporterebbe una perdita del 90% o più di nodi.

Credo che sia lecito supporre che pochissime entità sarebbero disposte a prendersi la briga di costruire array RAID per eseguire un nodo completo. Se così fosse, non sarebbe sostenibile affermare che tali incrementi andrebbero bene per l'utente medio, perché T ci sarebbe abbastanza throughput del disco del nodo completo o socket disponibili per soddisfare la domanda SPV.

Altre debolezze degli SPV

SPV è ottimo per gli utenti finali che T richiedono la sicurezza o la Privacy di un nodo completamente convalidante. Tuttavia, ci sono molte ragioni che potrebbero essere considerate degli ostacoli per una rete Bitcoin prevalentemente SPV, indipendentemente dalla sua scalabilità.

SPV fa delle ipotesi importanti che si traducono in una sicurezza e Privacy più deboli rispetto a un nodo completamente convalidato:

• I client SPV si fidano dei miner per convalidare e far rispettare correttamente le regole di Bitcoin; presumono che la blockchain con la più grande proof-of-work cumulativa sia anche una catena valida. Puoi Imparare la differenza tra i modelli di sicurezza SPV e full node in questo articolo.
• I client SPV presumono che i nodi completi non mentiranno loro per omissione. Un nodo completo T può mentire e dire che una transazione è esistita in un blocco quando in realtà T esisteva, ma può mentire dicendo che una transazione che esiste in un blocco non è avvenuta.
• Poiché i client SPV puntano all'efficienza, Request dati solo per le transazioni che appartengono a loro. Ciò comporta una massiccia perdita di Privacy.

È interessante notare che il coautore del BIP 37, Matt Corallo,si pente di averlo creato:

"Un grosso problema oggi per la Privacy degli utenti nel sistema sono i filtri bloom BIP37 SPV. Mi dispiace, l'ho scritto io."

I clienti SPV filtrati da Bloom del BIP 37 hannopraticamente nessuna Privacy, anche quando si utilizzano tassi di falsi positivi irragionevolmente elevati. Jonas Nick [un ingegnere della sicurezza presso Blockstream] ha scoperto che, data una singola chiave pubblica, poteva quindi determinare il 70% degli altri indirizzi appartenenti a un determinato portafoglio.

[incorpora]https://www.youtube.com/watch?v=HScK4pkDNds[/incorpora]

È possibile aggirare la scarsa Privacy di SPV suddividendo i filtri Bloom tra più peer, anche se ciò peggiorerebbe ulteriormente la scalabilità di SPV, poiché assegnarebbe un carico maggiore a più nodi completi.

BIP 37 è anche vulnerabile ad attacchi denial-of-service banali. Il codice dimostrativo èdisponibile quiche è in grado di paralizzare nodi completi effettuando numerose richieste di inventario rapide tramite filtri appositamente costruiti che causano una continua ricerca sul disco e un elevato utilizzo della CPU.

L'autore della proof-of-concept dell'attacco, CORE Developer Peter Todd, spiega:

"Il problema fondamentale è che si può consumare una quantità sproporzionata di larghezza di banda I/O del disco con una larghezza di banda di rete molto ridotta."

Ancora oggi, gli avvisi di frode descritti da Satoshi nel white paper non sono stati implementati. Infatti, gli sforzi di ricerca in quest'area hanno dimostrato che potrebbe non essere possibile implementare nemmeno avvisi di frode leggeri.

Ad esempio, un avviso di frode funziona solo se si possono effettivamente ottenere i dati richiesti per dimostrare la frode: se un miner non fornisce tali dati, l'avviso di frode T può essere creato. Pertanto, i client SPV T hanno il livello di sicurezza che Satoshi aveva immaginato.

Da una prospettiva di altissimo livello, un mondo costituito principalmente da nodi SPV rende molto più semplici le modifiche al consenso, come il limite totale delle monete o persino la modifica del registro. Meno nodi completamente convalidati significano un'applicazione più centralizzata delle regole del consenso e quindi una minore resistenza alla modifica delle regole del consenso. Alcune persone potrebbero considerarlo una caratteristica; la maggior parte sicuramente lo considera un difetto.

Potenziali miglioramenti

La sicurezza e la scalabilità SPV potrebbero potenzialmente essere migliorate in vari modi tramite prove di frode, suggerimenti di frode, prove di input, prove di spentness e così via. Ma per quanto ne so nessuno di questi ha superato la fase concettuale, e tanto meno è pronto per l'implementazione in produzione.

Impegni del filtro Bloom

potrebbe migliorare la Privacy, ma c'è un compromesso tra l'utilità delle dimensioni del filtro e il suo tasso di falsi positivi: se è troppo grossolano, i peer scaricano troppi blocchi di falsi positivi, se è troppo fine, i filtri saranno assolutamente giganteschi e poco pratici da scaricare con un client SPV.

Ciò ridurrebbe il carico sulla velocità di trasmissione del disco del nodo completo, ma il compromesso sarebbe un aumento della larghezza di banda sia per i client SPV sia per i nodi completi, poiché interi blocchi dovrebbero essere trasferiti attraverso la rete.

Questo recentemente proposto un filtraggio compatto lato client elimina i problemi Privacy , ma richiede il download di blocchi completi se c'è una corrispondenza con il filtro (anche se non necessariamente tramite la rete p2p!).

Impegni UTXO

potrebbe consentire ai client SPV di sincronizzare il loro attuale set UTXO e quindi il saldo del portafoglio senza richiedere al nodo completo di scansionare l'intera blockchain. Piuttosto, fornirebbe una prova dell'esistenza degli UTXO.

Potrebbe essere possibile proteggersi dagli attacchi DoS del filtro Bloom richiedendo ai client SPV di inviare una prova di lavoro (non sostenibile su un dispositivo alimentato a batteria come un telefono) o micropagamenti basati su canale (impossibili da avviare se un client T ha ancora ricevuto denaro), ma nessuna delle due soluzioni offre una soluzione semplice.

I requisiti di lettura del disco per i nodi completi potrebbero probabilmente essere ridotti in diversi modi tramite una migliore indicizzazione dei dati e l'elaborazione in batch delle richieste dai client SPV.

Ryan X Charles ha sottolineato nei commenti qui sotto che usare il protocollo di pagamento BIP70 per comunicare direttamente a qualcuno l' ID UTXO del pagamento che gli stai inviando eliminerebbe del tutto la necessità di usare filtri bloom, poiché potrebbe Request i dati direttamente dai nodi completi. Ciò è incredibilmente efficiente se sei disposto ad accettare il compromesso Privacy .

Basti dire che c'è ampio margine di miglioramento: saranno molte le sfide da superare per migliorare la scalabilità on-chain.

Soluzioni di ridimensionamento adatte

Se ignoriamo la moltitudine di altri problemi vari legati al ridimensionamento a blocchi di dimensioni maggiori, come la latenza di propagazione dei blocchi, il ridimensionamento del set UTXO, i tempi di sincronizzazione iniziale della blockchain e i compromessi in termini di sicurezza e Privacy , potrebbe essere tecnicamente possibile ridimensionare Bitcoin a un miliardo di utenti giornalieri on-chain se ci sono entità disposte a investire risorse significative per sviluppare miglioramenti software e gestire l'infrastruttura richiesta.

Sembra altamente improbabile che il Bitcoin si evolverebbe organicamente in quel modo, tuttavia, perché ci sono modi molto più efficienti per scalare il sistema. Il più efficiente è una forma di scalabilità già in uso: il consolidamento attorno ai provider API centralizzati. Ci sono tendono a esserci enormi compromessi di fiducia e Privacy quando si impiegano questi metodi, ma molte di queste interazioni implicano accordi contrattuali che mitigano alcuni dei pericoli.

In termini di scalabilità in modo trustless, i protocolli Layer 2 come Lightning offrono una scalabilità molto più efficiente perché gli alti volumi di dati trasferiti vengono inviati solo tra il piccolo numero di parti direttamente coinvolte in una determinata transazione off-chain. Si può pensare a questo come alla differenza tra un livello di comunicazione ethernet broadcast-to-all rispetto a un livello IP instradato: Internet T potrebbe scalare senza routing e nemmeno Internet of Money.

Sebbene questo approccio al ridimensionamento sia molto più complesso dal punto di vista tecnico rispetto al tradizionale ridimensionamento centralizzato e richieda il superamento di alcune sfide particolari, l'investimento iniziale di risorse per la ricerca e lo sviluppo di questi protocolli di routing darà enormi frutti nel lungo termine, poiché ridurrà di ordini di grandezza il carico che deve essere sopportato dall'intera rete.

Esistono anche molte altre opzioni intermedie che possono essere esplorate:

– Schemi di custodia centralizzati con perfetta Privacy che utilizzano token Chaum come ContantiHash.

– Sistemi centralizzati non custoditi a prova di conoscenza zero comeTumbleBit.

– Sidechain federate (multifirma semi-affidabili) https://elementsproject.org/sidechains/.

– Garantito dal minatore (semi-affidabile)catene di trasmissione.

Io sono ancora convinto che a lungo termine il Bitcoin avrà bisogno di blocchi molto più grandi.

Ma dobbiamo essere pazienti e diplomatici e cercare di adattare il sistema nel modo più efficiente possibile, mantenendone al contempo le proprietà di sicurezza e Privacy .

Un PayPal verificabile e leggermente decentralizzato avrebbe sicuramente utilità se fosse funzionale dal punto di vista dell'utente medio, ma non offrirebbe il livello di sovranità finanziaria di cui godono oggi i possessori di bitcoin.

Grazie a Matt Corallo, Mark Erhardt e Peter Todd per aver esaminato e fornito feedback per questo articolo

Dichiarazione informativa: CoinDesk è una sussidiaria di Digital Currency Group, che detiene una quota di proprietà di Blockstream.