I programmatori Bitcoin affrontano un vecchio dilemma: come aggiornare un'intera rete

Un vecchio dibattito sta riaffiorando nella comunità degli sviluppatori Bitcoin , evidenziando ONE delle sfide critiche che devono affrontare i sistemi decentralizzati: come aggiornare il software quando apparentemente non c'è nessuno al comando.

Il catalizzatore questa volta si chiama Taproot/Schnorr, un aggiornamento Privacy e della scalabilità in lavorazione da anni che ha visto progresso entusiasmante di recente, soprattutto ora che il codice sotto forma di "pull Request" è in fase di revisione e test, rendendo più vicina alla realtà una modifica discussa per la prima volta anni fa.

La modifica del codice in sé T è finora controversa tra gli sviluppatori. Cosa Èin discussione è il modo migliore per attivare il cambiamento, rendendo finalmente possibile l'invioBitcoin (BTC) transazioni in questo nuovo modo.

Il nocciolo della questione è che Bitcoin non ha un leader ed è distribuito in tutto il mondo. Come fa l'intera rete ad aggiornarsi senza problemi in un modo che sia retrocompatibile, consentendo a coloro che hanno versioni precedenti del software di continuare a partecipare? Qual è il modo migliore per Bitcoin di apportare questo tipo di cambiamento senza interruzioni?

Per essere chiari: il codice di Bitcoin è stato aggiornatoquasi ogni giornodalla rete globale di sviluppatori del progetto open source. Ma le modifiche al codice "consensuale", che colpiscono una parte più profonda di Bitcoin, richiedono un "soft fork", che a sua volta richiede una certa quantità di coordinamento per procedere senza intoppi.

"Ci sono una serie di design soft-fork che di recente hanno fatto buoni progressi verso l'implementazione e l'adozione futura. Tuttavia, per vari motivi, i metodi di attivazione ... hanno ricevuto una discussione limitata,"CORE Bitcoinil collaboratore Matt Corallo ha scritto inuna e-mail alla lista degli sviluppatori Bitcoin il mese scorso, che ha riaperto il dibattito.

Ci sono due opzioni principali per attuare un soft fork. ONE , Bitcoin Improvement Proposal (BIP) 9, è stata utilizzata per alcuni soft fork in passato. Garantisce che minatorisono preparati in anticipo rispetto a un soft fork, per assicurarsi che un cambiamento si diffonda senza problemi in tutta la rete. Un'obiezione comune a questo approccio è che dà ai miner troppo potere.

In alternativa, c'è BIP 8, noto anche come user-activated soft fork (UASF), che si attiva indipendentemente dal fatto che i miner segnalino di essere pronti o meno. A seconda dell'esecuzione, questo approccio potrebbe causare altri problemi, ha avvertito Corallo.

Lezione di storia

La discussione è iniziata nel 2017, quando BIP 9 è stato utilizzato per attivare Segregated Witness, o SegWit, un cambiamento fondamentale per il grande dibattito sulla scalabilità di bitcoin. Per proteggere i minatori dal mining di blocchi non validi e dalla perdita di denaro, SegWit non si sarebbe attivato finché il 95 percento dei minatori non avesse sollevato una bandiera indicando di essere pronto.

La maggior parte dei pool di mining (gruppi di minatori che uniscono la loro potenza di calcolo sulla rete) ha dichiarato che non avrebbe sostenuto SegWit, ponendo sostanzialmente il veto, a meno che non fosse stato abbinato a un aumento del parametro della dimensione del blocco. (Il misterioso creatore di Bitcoin aveva fissato il limite massimo a 1 megabyte, limitando il numero di transazioni che potevano essere inserite nei blocchi, pubblicati ogni 10 minuti circa.)

Si trattava di una richiesta controversa che molti ritenevano avrebbe potuto portare alla centralizzazione della rete (e che comunque T avrebbe potuto essere eseguita con successo a meno che i Bitcoin non fossero stati centralizzati).

Per farla breve, l'incidente ha dimostrato che i pool di mining potrebbero utilizzare la soglia del 95 percento per estrarre altre modifiche invece che per lo scopo previsto: aiutarli ad adattarsi gradualmente al cambiamento in modo da T perdere denaro.

Molti bitcoiner non hanno gradito questa cosa, vedendola come un tentativo da parte dei minatori di usare il loro potere per imporre un cambiamento che non tutti gli utenti desideravano.

Mentre questo dibattito infuriava, uno sviluppatore misterioso che si faceva chiamare Shaolinfry ha sottolineato che i bitcoiner potevano ancora effettuare l'aggiornamento. La radice dell'idea è che gli utenti e gli exchange Bitcoin dovrebbero decidere se una modifica debba essere eseguita o meno, e i miner Seguici i loro desideri, non il contrario. Questo metodo era stato utilizzato per attivare altre modifiche Bitcoin . Shaolinfy ha formalizzato questa idea in BIP 8, altrimenti noto come UASF.

Una larga fetta di utenti ha dichiarato a gran voce il proprio supporto per SegWit UASF sui social media e ha iniziato a eseguire il software. Ciò sembrava avere l'effetto desiderato. Prima che UASF si attivasse, i miner hanno iniziato a segnalare il supporto per SegWit.

In particolare, c'erano un paio di varianti di UASF in circolazione durante questo periodo tumultuoso, ONE più cauta (e più prudente nei tempi) e meno controversa dell'altra. Ma senza entrare nei dettagli, la conclusione per alcuni sviluppatori Bitcoin è stata che UASF era un modo migliore per attuare cambiamenti.

All'epoca, Rusty Russell, uno sviluppatore della startup Bitcoin Blockstream, arrivò addirittura a scusarsi per aver avuto un ruolo nella realizzazione del BIP 9.

"T mi aspettavo che questo checkpoint sarebbe stato utilizzato come punto di strozzatura per riscattare la rete. Ciò modifica significativamente il modello di rischio;Bip-8è ora un metodo di gran lunga superiore per gli aggiornamenti di rete, dove i minatori possono solo accelerare il processo, non bloccarlo", ha scritto in un articolo su Mediuminviare.

Ricordi lunghi

Considerando tutto questo dramma, alcuni sviluppatori sono cauti nell'utilizzare nuovamente BIP 9 per Schnorr/Taproot o altre modifiche future.

"Penso che il BIP 9 sia un fallimento comprovato",disse CORE Bitcoin sviluppatore Luke Dashjr, rispondendo a Corallo, ha continuato a fornire ragioni tecniche per la sua obiezione. Durante il dibattito sulla scalabilità, Dashjr è stato ONE dei più vociferanti sostenitori di un UASF per far passare SegWit.

Alex Bosworth, uno sviluppatore della startup Lightning Labs, ha espresso Opinioni simile, basata in parte sul recente scompiglio che ha circondato Bitcoin Cash (BCH), una Criptovaluta più piccola che si è separata da Bitcoin nel 2017.

Un gruppo considerevole di pool di mining Bitcoin Cash di recentepropostoche una parte BCH di ogni nuovo blocco debba essere destinata a un fondo di sviluppo, il che secondo Bosworth è un altro esempio di come i mining pool mostrino i muscoli in un modo che va a discapito della decentralizzazione Criptovaluta .

"So che il pensiero comune per l'implementazione di soft fork è di tentare il tradizionale metodo friendly-miner. Ma un buon [ONE terzo] del nostro attuale hashrate si è appena organizzato in un cartello allo scopo di censurare per rubare i sussidi per le monete", twittatoBosworth, che lavora all'infrastruttura per la rete Lightning veloce e scalabile.

Ecco perché sostiene il metodo UASF, anche se ONE un orizzonte temporale più lungo.

"Mi sembra più appropriato un UASF a combustione lenta", ha aggiunto.

Sintesi

Ma alcuni, invitando alla cautela, temono che considerare gli UASF come unico metodo di attivazione potrebbe aprire la possibilità di attuare modifiche che potrebbero danneggiare Bitcoin.

Ad esempio, ONE dei motivi per cui agli sviluppatori inizialmente piaceva BIP 9 è che la soglia del 95 percento poteva fornire una sorta di rete di sicurezza. Se un problema veniva alla luce mentre i pool di mining stavano lavorando per aggiornare il loro software, allora i pool potevano fermare il cambiamento. È più difficile fermare un'attivazione UASF una volta avviata.

Ecco perché Corallo ha riproposto una vecchia idea, una specie di mix tra BIP 8 e BIP 9. Il soft fork inizierebbe con BIP 9. Poi, se fallisse nel corso di un anno a causa di "obiezioni irragionevoli", gli utenti potrebbero discutere e riorganizzarsi nel corso di un periodo di sei mesi. Dopodiché, se il cambiamento è sicuramente qualcosa che la comunità desidera, potrebbero provare BIP 8 nel corso di un altro anno.

Alcuni sviluppatori potrebbero sostenere che questo periodo di tempo è troppo lungo per un cambiamento senza "obiezioni irragionevoli". Ma Corallo ha esortato alla pazienza.

Scoprire se le obiezioni sono davvero "irragionevoli" potrebbe richiedere del tempo. "Nel caso in cui fallisse, il processo BIP 9, di fatto, offre una buona opportunità di apprendimento per quanto riguarda il livello di prontezza della comunità e il desiderio per un dato cambiamento", ha affermato.

"Sviluppare Bitcoin non è una gara. Se dobbiamo farlo, aspettare 42 mesi assicura che non stiamo creando un precedente negativo di cui ci pentiremo man mano che Bitcoin continua a crescere", ha affermato. I lettori possono leggere il ragionamento completo di Corallo e molte delle risposte sfumate degli sviluppatori Qui.

E mentre Russell sembrava piuttosto contrario al BIP 9 nel 2017, ha dichiarato a CoinDesk di essere ora d'accordo con questo approccio ibrido.

"Dato che il tentativo dei minatori di bloccare i cambiamenti T ha funzionato e T abbiamo sofferto molto per il ritardo, T mi dispiace l'attivazione del BIP-9", ha detto. Ma ha proposto una tempistica più breve di Corallo.

"Forse il timeout BIP-9 di un anno è troppo lungo e una scadenza di sei mesi sarebbe preferibile. In questo modo, gli utenti possono organizzare un UASF se l'attivazione BIP-9 fallisce e ritengono che sia dovuto all'ostruzionismo dei miner", ha affermato Russell.

Gli ingegneri stanno esaminando attentamente il codice Taproot/Schnorr proposto per risolvere eventuali problemi persistenti. Quindi c'è ancora tempo per gli sviluppatori per discutere le opzioni di attivazione. Ma la comunità dovrà decidere qualcosa prima che la modifica possa essere aggiunta a Bitcoin, creando più Privacy nella rete.