Proposta di ridimensionamento "Segwit2x" di Bitcoin: gli sviluppatori CORE assumono una posizione critica

A pochi giorni dalla presentazione di una proposta ampiamente supportata ma controversa per aumentare la capacità di transazione di Bitcoin, stanno venendo alla luce i dettagli tecnici del piano.

Potrebbe non sorprendere particolarmente se si ha molta familiarità con il dibattito di lunga data sulla dimensione dei blocchi di Bitcoin, ma il codice provvisorio per quello che è oraconosciuto come 'Segwitx2'T è stato accolto particolarmente bene dalla comunità degli sviluppatori open source del progetto.

ONE cosiddetto Request di pulldal co-fondatore di Bloq Jeff Garzik, ad esempio, è stato accolto da un coro di commenti scettici. La maggior parte erano piuttosto tecnici, provenienti da alcuni sviluppatori che hanno lavorato a lungo su Bitcoin , ma la risposta sembrava ridursi a: "Perché il gruppo T sta usando un metodo più sicuro, ONE che molti di noi hanno suggerito in precedenza?"

Alcuni commenti sembravano avere un tono beffardo. "Questa Request di pull è piuttosto strana", ha affermato Udi Wertheimer, responsabile della ricerca blockchain di Colu, nella sua risposta.

"Non ci sono ancora test", ha affermato semplicemente un altro sviluppatore.

Tuttavia, Garzik, un ex sviluppatore Bitcoin CORE impiegato dal processore Bitcoin BitPay, ha accolto con favore il feedback e più tardi nel corso della giornata ha risposto su Medio"Questo è stato unpunto di partenza," ha affermato, sottolineando che la sua posizione è che l'attuale implementazione su GitHub è destinata a essere un work in progress.

Garzik ha aggiunto di essere d'accordo con il feedback ricevuto e sostiene l'apporto di modifiche che consentano al codice di essere compatibile con la versione esistente di Segregated Witness (o SegWit), un piano per scalare la blockchainproposto dai Collaboratori di Bitcoin COREnel 2015.

"Se il risultato massimizza ancora di più la compatibilità, riutilizza ancora di più i test esistenti, allora è una WIN. Un progresso in avanti", ha scritto Garzik.

Paura della forchetta

Eppure, nonostante tutta la derisione implicita, questo dibattito tra sviluppatori potrebbe essere visto come un esempio di "collaborazione" e revisione tra pari.

Probabilmente vale la pena notare che nessuno degli sviluppatori volontari dietro Bitcoin CORE ha firmato il 'accordo' sulla proposta, annunciata per la prima volta dalla società di investimenti DCG la scorsa settimana. Come accennato nelle preoccupazioni di cui sopra, ciò è avvenuto in parte a causa di preoccupazioni tecniche e in parte perché alcuni T credono che un hard fork sia necessario in questo momento.

Alcuni sostengono che gli incrementi di capacità oltre SegWit possono essere ottenuti in altri modi retrocompatibili che T comportano il rischio di espellere dal sistema alcuni partecipanti alla rete.

Una volta pubblicata la proposta, e anche molto prima, gli sviluppatori avevano fornito un feedback tecnico sucome distribuire al meglio un hard fork, il che potrebbe spiegare un pizzico di amarezza da parte degli sviluppatori nelle recenti discussioni.

Tuttavia, anche se molti di loro T sono entusiasti dei dettagli della proposta, finora ciò T ha impedito agli sviluppatori di provare a migliorarne l'implementazione.

"Ho scritto BIP91 per provare a rendere la proposta più sensata", ha affermato lo sviluppatore Bitcoin James Hilliard, aggiungendo che, ai suoi occhi, l'attuale tempistica dell'hard fork è "completamente irrealistica".

Altri danno più peso alla proposta, che ha il sostegno di oltre 60 aziende e di oltre l'80% degli operatori e delle aziende di mining pool di Bitcoin.

"Penso che dovremmo cercare di costruire sulla base della proposta e migliorarla", ha affermato Adam Back, CEO di Blockstream. Nel complesso, Back è emerso come forse ONE delle voci più positive, con commenti che suggeriscono che la resistenza degli sviluppatori potrebbe creare problemi di percezione.

In particolare, sta cercando di indirizzare l'interesse verso una proposta chiamata "spoonnet", un ramo diricerca hard fork dal collaboratore di Bitcoin CORE Johnson Lau.

Eric Lombrozo, collaboratore Bitcoin CORE , che ha lavorato sul codice SegWit, ha avuto un'opinione simile in termini di collaborazione. "Lavorerò sodo con [il fondatore e CEO di DCG Barry Silbert] per fare in modo che questo sia un successo", ha detto. ha scrittosui social media, anche se non senza qualche avvertenza.

Troppo, troppo presto?

La conclusione, però, è che molti sviluppatori T ritengono che la proposta sia ONE.

Bryan Bishop, collaboratore Bitcoin CORE, ha riassunto le preoccupazioni in modo più succinto:

"Penso che alla fine l'hard-fork [DCG] non riuscirà a effettuare la transizione sicura dell'intera rete. Non c'è protezione da replay. È una tempistica irragionevolmente breve. T sfrutta i precedenti sforzi di ricerca sull'hard-fork."

"Penso che l'intero settore debba svegliarsi e rendersi conto di quanto tempo richiedono queste cose", ha aggiunto, sostenendo che la revisione paritaria e i test richiedono molto tempo. (Anche altri sviluppatori e utenti Bitcoin hanno messo in dubbio la tempistica di sei mesi.)

Forse la domanda più importante è: se il gruppo affrontasse queste problematiche tecniche, più sviluppatori lo supporterebbero?

La risposta, come al solito, è stata complicata e contrastante: alcuni hanno espresso il desiderio di prendere in considerazione tutti i compromessi.

"C'è un sentimento generale tra gli sviluppatori di Bitcoin CORE che un'enorme quantità di capacità può essere ottenuta da soft fork e aggiornamenti retrocompatibili. T penso che gli sviluppatori di Bitcoin CORE si Rally attorno a un hard fork nel NEAR futuro, specialmente non ONE dettato da un incontro Secret a porte chiuse", ha detto Bishop.

Lo sviluppatore Jonas Schnelli, noto per la libreria libbtc, ha affermato che potrebbe eventualmente approvare un hard fork per un aumento delle dimensioni dei blocchi se gli venisse concesso più tempo.

"Sono contento di SegWit2x se potesse ridursi all'80% senza essere incompatibile con l'implementazione [SegWit] esistente", ha detto Schnelli. "E fare [l'hard fork] più tardi".

Altri semplicemente T pensano che funzionerà, trattandolo apparentemente con lo stesso interesse con cui lo hanno trattato loro. Bitcoin -XTP o Bitcoin Classic: altre proposte di hard fork fallite (anche se questo nuovo sforzo ha ottenuto più supporto).

Altre opzioni

Molti sviluppatori hanno espresso il sentimento che la capacità di transazione potrebbe essere aumentata in altri modi, forse più sicuri. Per ONE, alcuni tendono a pensare che SegWit sia una soluzione migliore da sola, senza l'hard fork di accompagnamento, che potrebbe portare a una divisione della rete.

"Su SegWit2x, non c'è alcuna ragione tecnica per accoppiare [Segwit] con un [hard fork]. Solo politica. E Bitcoin è stato creato per stare lontano dalla politica... ecco perché principalmente [non] lo supporto", ha detto Schnelli.

Luke Dashjr, collaboratore di Bitcoin CORE , si è mostrato aperto ad un'altra proposta recente, chiamata COOPERATIVA, che combina un mucchio di ricerche hard-fork in ONE proposta di miglioramento Bitcoin (BIP), per un'implementazione più sicura. Ma aveva delle riserve sull'aumentare la dimensione del blocco così rapidamente.

Dashjr ha promosso attivamente BIP148, un controverso meccanismo retrocompatibile che è statoprendendo slancioe anche questo ha una scadenza per l'attivazione, anche se alcuni temono che anche questo potrebbe causare una divisione della catena.

Ha concluso:

"In ogni caso, il BIP148 inizierà ad agosto."

Dichiarazione informativa: CoinDesk è una sussidiaria di Digital Currency Group (DCG).

Uomo sulla scala da cantiereimmagine tramite Shutterstock