Con le nuove uscite, i software Bitcoin concorrenti forgiano piani a lungo termine

Le divisioni nel dibattito in corso sulla dimensione dei blocchi si sono fatte più marcate questa settimana in seguito a una conferenza privata e a un picco nell'attività di rete che ha visto gli utenti attendere più a lungo e pagare di più per la conferma delle transazioni.

Il dibattito in corso su come la blockchain Bitcoin dovrebbe essere ridimensionata per accogliere nuovi utenti è stato segnalato come un punto focale come il recenteTavola rotonda di Satoshi, un ritiro su invito che ha unito sviluppatori e leader aziendali. Tuttavia, i segnali suggeriscono che i partecipanti sono usciti dall'evento con unpiù negativovisione dello stato del discorso.

Ma anche se le tensioni persistono, lo sviluppo di entrambe le versioni concorrenti del software Bitcoin – Bitcoin Classico E CORE Bitcoin– continua mentre i gruppi fanno pressioni per ottenere il sostegno della più ampia base di utenti della rete.

A fine febbraio, Bitcoin CORE, il gruppo di sviluppatori più grande e più longevo della rete, ha rilasciato una nuovatabella di marcia, e insieme ad essa, l'ultima versione – versione0,12,0– del software.

Subito dopo, il team dietrol'implementazione alternativa Bitcoin Bitcoin Classic ha annunciato la sua roadmap per il 2016 <a href="https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md">https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md</a> e questa settimana ha rilasciato l'ultima versione di Classic, basata sulla versione CORE 0.12.0.

Le release continuano a destare interesse per la comunità, perché quando si tratterà di un potenziale fork Bitcoin , il risultato potrebbe essere in cui il vincitore prende tutto.

I principali esperti di tecnologia ritengono che il gruppo che riuscirà a ottenere un consenso sulla propria visione vedrà rapidamente promulgate le proprie regole e che, nonostante le preoccupazioni, il rischio che la rete si divida in due versioni incompatibili della blockchain rimanga basso.

Jeff Garzik, CEO di Bloq, ha dichiarato a CoinDesk:

"La rete Seguici rapidamente la forchetta vincente, [ci sono] miliardi di incentivi."

Questo articolo LOOKS la composizione di queste due release e il modo in cui entrambi i gruppi stanno procedendo per implementare la loro visione per la rete Bitcoin .

Roadmap classica

Nella roadmap ufficiale del 2016, il team di sviluppo responsabile di Classic ha pubblicato il piano previsto per il lancio del software nei successivi 11 mesi.

Durante la prima fase, il team prevede di implementare BIP 109, originariamente proposto per CORE dallo sviluppatore Gavin Andresen, che aumenterebbe la dimensione dei blocchi di transazione sulla rete Bitcoin dall'attuale 1 megabyte (MB) per blocco a 2 MB per blocco.

La soglia per questa transizione sarebbe quando 751 dei precedenti 1.000 blocchi fossero stati estratti con il codice che supportava blocchi più grandi. Una volta raggiunta quella soglia del 75%, inizierebbe un periodo di attivazione di 28 giorni.

Andresen ha detto a CoinDesk:

"Il pericolo di una soglia elevata è che un minatore o un operatore di pool potrebbe essere costretto a esercitare quel veto, potrebbe essere minacciato o ricattato. Questo non è un rischio teorico. Vediamo attacchi di negazione del servizio contro pool o servizi che "votano nel modo sbagliato" e ci sono state persino segnalazioni di minacce di morte".

Il periodo di 28 giorni ha lasciato alcuni membri della comunità preoccupati, ma Andresen ha osservato in un recentepost del blog che "molti dei principali minatori Bitcoin , exchange [e] fornitori di portafogli web" hanno indicato che il periodo di attivazione dà loro "tutto il tempo" per cambiare il loro software.

Ha ulteriormente difeso il periodo di grazia di 28 giorni confrontandolo con l'ultimo aggiornamento della versione a blocchi.

Andresen ha spiegato che ci è voluto circa un mese per raggiungere il 75% dell'hashrate e, una volta raggiunto, ci sono voluti solo altri sette giorni per raggiungere il 95% dell'hashrate.

In altre parole, ritiene che T ci siano preoccupazioni significative riguardo alla finestra di transizione di 28 giorni.

Fasi future per Classic

Nel caso in cui l'hard fork dovesse effettivamente avere inizio, Classic entrerà nella sua seconda fase nel secondo o terzo trimestre del 2016, con l'obiettivo di risolvere i problemi relativi alle dimensioni dei blocchi.

"L'obiettivo della fase due è eliminare le barriere tecniche (dovute a un protocollo di rete inefficiente) che limitano la capacità della rete. Invece di trasmettere un'enorme raffica di dati quando viene trovato un nuovo blocco, verrà trasmessa una piccola quantità di dati, facendo riferimento ai dati delle transazioni che devono essere già stati trasmessi", ha spiegato Andresen.

Ha continuato affermando che queste efficienze non sono un problema per blocchi da 1 MB o 2 MB, ma che l'obiettivo finale della fase due era quello di "interrompere il processo decisionale centrale sulla dimensione massima 'giusta' e tornare alla visione originale di Satoshi di un sistema autoregolante".

Il passaggio finale per il team Classic sarà quello di introdurre un limite dinamico alla dimensione dei blocchi, ma solo dopo che "i miner e le aziende confermeranno che la fase due ha risolto con successo i loro problemi relativi alla dimensione dei blocchi".

ONE proposta presentata nella roadmap è quella di utilizzare una variante del dimensione del blocco adattivoin base alla dimensione media del blocco descritta in un recente post sul blog di Stephen Pair, CEO di BitPay.

"Per determinare il limite della dimensione del blocco, si calcola la dimensione media del blocco su un campione recente di blocchi e si applica un multiplo", ha scritto Pair.

Pair continua spiegando che, a differenza della dimensione media del blocco, la mediana è molto più difficile da manipolare. Con una dimensione media del blocco, i minatori potrebbero gonfiare la dimensione del blocco con le proprie transazioni o, d'altra parte, non inserire alcuna transazione nei blocchi. Con la mediana, "avresti bisogno di un'azione coordinata di oltre il 50% della capacità di mining".

Naturalmente, se qualcuno controllasse più del 50% della capacità di mining, il Bitcoin avrebbe problemi più grandi da affrontare rispetto al limite della dimensione del blocco.

Oltre all'aumento delle dimensioni dei blocchi, Classic sta pianificando di organizzare una conferenza "in cui queste e future soluzioni e problematiche di scalabilità potranno essere discusse dalla comunità".

La nuova versione, pubblicata il 7 marzo, incorpora elementi della versione 0.12.0 di Bitcoin Core, ma in particolare lascia disabilitata per impostazione predefinita la funzionalità RBF (opt-in replace-by-fee), con cui gli utenti possono ritrasmettere transazioni con commissioni più elevate a patto che T siano state incluse in un blocco.

CORE rilascia l'ultima versione del software

IL Team di sviluppo CORE ha annunciato il rilascio della versione v0.12.0 il 23 febbraio, che gli sviluppatori hanno descritto come potenzialmente "la più ONE di sempre, con più miglioramenti significativi di qualsiasi altra versione precedente".

Il team ha inquadrato la release come focalizzata sull'ottimizzazione delle prestazioni complessive del software. In molti casi, era intesa a ridurre le risorse computazionali necessarie o a migliorare la velocità con cui le azioni possono aver luogo.

Nel novembre 2015, lo sviluppatore CORE Pieter Wuille ha presentato un Request di pullper passare a una convalida ECDSA basata su libsecp256k1. In esso, ha spiegato che ci sarebbero stati tre vantaggi nel fare quella transizione.

"La convalida della firma è da 2,5 a 5,5 volte più veloce; il codice di consenso non dipende più da OpenSSL o dal suo parser di firma; rimuove il collegamento con OpenSSL da libconsensus", ha scritto.

Abbandonare OpenSSL ha comportato anche implicazioni in termini di sicurezza.

"OpenSSL è molto completo nelle sue capacità, ma questo enorme set di funzionalità implica che la sua superficie di attacco sia piuttosto ampia", ha scritto il team nel suo annuncio della versione 0.12.0.

Dopo aver trascorso quasi tre anni in fase di sviluppo, libsecp256k1 è stato unito al client Bitcoin CORE , con un conseguente miglioramento di sette volte della velocità di convalida delle firme, secondo il team. Inoltre, poiché libsecp256k1 è focalizzato principalmente sulla convalida delle firme, l'area per gli exploit di sicurezza è molto più piccola, secondo CORE.

Proseguendo con l'ottimizzazione, il team ha anche implementato un meccanismo per impedire arresti anomali dei nodi dovuti ai limiti del pool di memoria.

Un altro cambiamento importante riguarda il modo in cui i nodi archiviano le transazioni che T sono ancora state inserite in un nuovo blocco.

In un post del blog pubblicato prima di luiha lasciato il team Bitcoin CORE, lo sviluppatore Mike Hearn ha avvertitoil potenzialeper una significativa diminuzione dei nodi di rete.

Man mano che vengono effettuate delle transazioni, queste entrano nel pool di memoria, dove vengono conservate finché non vengono visualizzate sulla blockchain. Man mano che si verificano più transazioni, altre vengono forzate nel pool di memoria. Per i nodi che hanno molta memoria, questo T è un problema; tuttavia, quelli che operano con quantità minime di memoria affrontano una situazione potenzialmente negativa.

Hearn ha delineato tre possibili scenari che potrebbero verificarsi in questa circostanza:

"Il nodo potrebbe diventare incredibilmente lento quando entra nell'inferno dello swap; il nodo potrebbe bloccarsi quando tenta di allocare memoria e fallisce; il nodo potrebbe essere eliminato dal kernel del sistema operativo."

Per contrastare questo problema, CORE ha introdotto una funzionalità chiamata limitazione del pool di memoria, che imposta un limite rigido predefinito sulla dimensione del pool di memoria; in particolare, nella versione 0.12.0 è impostato su 300 MB.

Ciò che accade in pratica è che, quando un nodo inizia a raccogliere più transazioni, se il pool di memoria raggiunge il limite di 300 MB, il nodo eliminerà prima le transazioni che offrono la commissione per bye più bassa anziché accettare semplicemente più transazioni.

Riduzione dei costi delle risorse

0.12.0 introduce anche un fattore di limitazione del traffico di upload. Con i nodi che inoltrano costantemente transazioni in rete, può risultare in una maggiore quantità di risorse di upload, gravando sui singoli nodi.

Un fattore di limitazione del traffico di upload consente all'operatore di limitare la quantità di dati caricati e condivisi con il resto della rete Bitcoin . Nel caso in cui raggiunga questo limite, il nodo servirà i blocchi richiesti nella settimana precedente, riducendo così al minimo le esigenze di risorse.

Per evitare ulteriormente che i nodi venissero sovraccaricati, il team ha introdotto la tecnica del wallet pruning.

Attualmente, i nodi archiviano una copia completa della blockchain. Al momento in cui scrivo questo articolo, ciò significa che ogni nodo deve archiviare 57,8 GB di dati di transazione. Più grande diventa, più spazio di archiviazione è necessario.

La nuova "modalità pruned" consente a coloro che utilizzano il portafoglio Bitcoin CORE di ridurre lo spazio su disco richiesto da 60 GB a soli 2 GB.

"Ciò significa che il nodo si concentrerà solo sul monitoraggio degli output non spesi e dimenticherà i blocchi elaborati in precedenza, così come gli output che sono stati spesi", ha spiegato il team.

Mentre c'era controversia con ilinclusione della sostituzione a pagamentofondamentalmente, la nuova versione si è concentrata sul rendere meno dispendioso in termini di risorse il funzionamento dei nodi.

Come ilnumero di nodi è sceso negli ultimi anni, riducendo le risorse necessarie dovrebbe portare più utenti a scegliere di eseguire nodi che convalidano completamente la blockchain. Più nodi ci sono nella rete, più sicuro diventa il Bitcoin .

Immagine di escursionista smarritotramite Shutterstock