Kunne SPV understøtte en milliard Bitcoin-brugere? Opdeling af en skaleringskrav | DK.democraziakmzero.org

Kunne SPV understøtte en milliard Bitcoin-brugere? Opdeling af en skaleringskrav

Kunne SPV understøtte en milliard Bitcoin-brugere? Opdeling af en skaleringskrav

Jameson LOPP er en software ingeniør på BitGo, skaberen af ​​statoshi.info og grundlægger af bitcoinsig.com.

I denne udtalelse stykke, LOPP tager et dybt dyk i påstande om, at det er sikkert at fjerne Bitcoin grænse blok størrelse og i stedet satse på eksisterende "forenklet verifikationsinstrument" (SPV) metoder.

Et nyt krav er ved at blive foreviget i Bitcoin skalering debat.

Vi hører, at det er sikkert at fjerne grænsen blokken størrelse, fordi Bitcoin nemt kan skaleres til enorme blokstørrelser, der ville understøtte milliarder af brugere via eksisterende "forenklet betaling verifikation" (SPV) metoder. Angiveligt, SPV er meget skalerbar på grund af den lille mængde data det kræver en SPV klient til at gemme, sende og modtage.

Lad os grave i denne påstand, og undersøge det fra flere perspektiver.

Hvor SPV værker

Satoshidescribed på højt niveau design til SPV i Bitcoin hvidt papir, selvom det ikke blev gennemført indtil to år senere, da Mike Hearn skabte BitcoinJ.


Tidlige SPV implementeringer var ganske naiv - de hentede hele blockchain, som ikke er mere effektiv var end en fuld knude i form af båndbredde.

Ved at smide væk transaktioner, der ikke var relevante for SPV kundens tegnebog, det var i stand til at opnå betydelige diskforbrug besparelser. Det tog yderligere 18 måneder for BIP 37to offentliggøres, hvilket giver en specifikation for Bloom filtrering af transaktioner, således at forlade sig på blokhovedet s Merkle rod at bevise optagelse af en transaktion i en blok som Satoshi havde beskrevet. Dette gav stærkt reduceret båndbredde.

Når en SPV klient synkroniserer med Bitcoin netværk, der oprettes forbindelse til en eller flere fuldt validering Bitcoin noder, bestemmer den nyeste blok på spidsen af ​​kæden, så anmoder alle de blok overskrifter med en "GetHeaders" kommando til blokke fra den sidste blokere det synkroniseret op til kæden spids.

Hvis SPV-klienten er kun interesseret i specifikke transaktioner, der svarer til en tegnebog, vil det konstruere et Bloom filter baseret på alle de adresser, som sin tegnebog ejer private nøgler og sende en kommando "filterload" til den fulde node (r), således at de kender til kun returnere transaktioner matcher filteret.

Efter synkronisering blok overskrifter og muligvis indlæse en Bloom-filter, SPV-klienten sender en kommando "getdata" til anmodning hver enkelt (eventuelt filtreret) blok, de gik glip af at se siden sidste gang de var sidste nettet, sekventielt.

Når kunden er i sync, hvis det forbliver forbundet til den fulde node peer (er) det vil kun modtage "inv" opgørelse meddelelser for transaktioner, der matcher den indlæste Bloom-filter.

SPV-klient skalering

Fra en kundes synspunkt Bloom filtrering er et meget effektivt middel til at finde relevante transaktioner i blockchain, mens du bruger minimal CPU-ressourcer, båndbredde og diskplads.

Hver Bitcoin blok header er blot 80 bytes, så i skrivende stund er det kun 38 megabyte data for hele otte-plus årige historie af blockchain. Hvert år (ca. 52.560 blokke), tilføjer kun 4,2 megabyte, uanset størrelsen af ​​blokke i blockchain.

Den Merkle træ, der bruges til at bevise inklusion af en transaktion i en blok skalerer også ekstremt godt. Fordi hver ny "lag", der bliver føjet til træet fordobler det samlede antal "blade" det kan repræsentere, behøver du ikke en meget dyb træ for at kompakt bevise inddragelse af en transaktion, selv blandt en blok med millioner af transaktioner.

Via Mastering Bitcoin

Den Merkle trædatastruktur er så effektiv, at det kan repræsentere 16 millioner transaktioner med en dybde på kun 24 - dette er tilstrækkeligt til at repræsentere en 8GB blok. Endnu, Merkle træet bevis for en sådan transaktion forbliver under 1KB i størrelse!

via Mastering Bitcoin

Det er helt klart, at ud fra et SPV klient perspektiv, kunne det Bitcoin netværket skaleres til flere gigabyte blokke og SPV kunder ville have lidt problemer med at behandle de små mængder data, der kræves - selv på en mobiltelefon med en 3G-forbindelse.

Men ak, skalering af Bitcoin-netværket er ikke nær så simpelt.

SPV-server skalering

Mens SPV er utrolig effektiv til kunder, er det samme ikke gælde for serveren - det vil sige, den fulde node (r), som SPV klienter fremsætte anmodninger. Denne metode udviser dårlig skalerbarhed for en række årsager.

Nodes i netværket er nødt til at behandle en ekstremt stor mængde data til at returnere resultaterne for blot en enkelt peer, og de skal gentage dette arbejde på hver blok for hver peer, der anmoder herom. Disk I / O bliver hurtigt en flaskehals.

Hver SPV klienten skal synkronisere hele blockchain fra sidste gang, det havde kontakt med netværket, eller, hvis den mener, at det savnede transaktioner, det vil være nødvendigt at scanne hele blockchain siden tegnebogen oprettelsesdato. I værste fald, i skrivende stund, det er ca 150GB. Den fulde knude skal indlæse hver enkelt blok fra disk, filtrere det til kundens specifikationer og returnere resultatet.

Da blockchains er en form for append-kun hovedbog, vil dette beløb aldrig stoppe voksende. Uden omfattende protokolændringer, blockchain beskæring er uforenelig med BIP 37 - det forventer, at alle blokke for at være tilgængelige på alle fulde knuder, der reklamerer NODE_BLOOM.

BIP 37 SPV klienter kan være løj ved undladelse. For at bekæmpe dette, SPV klienter forbinde til flere noder (normalt fire) selvom det er stadig ikke en garanti - SPV kunder kan partitioneres ud for den vigtigste netværk ved en Sybil angreb. Dette øger belastningen på nettet af fuld knuder med en faktor fire.

For hver tilsluttet SPV klient, der er blevet synkroniseret til spidsen af ​​blockchain skal hver indkommende blok og transaktion individuelt filtreres. Dette indebærer en ikke ubetydelig mængde CPU-tid og skal gøres separat for hver tilsluttet SPV klient.

Crunching tallene

På skrivende stund er der cirka 8300 fulde noder kører der accepterer indgående forbindelser; omkring 8000 af dem annoncere NODE_BLOOM og skulle således være i stand til at tjene anmodninger fra SPV klienter. Men, hvor mange SPV kunder kan det nuværende antal lytter fulde knuder rimelighed støtte?

Hvad kræves, for at netværket skal bestå af fuld knuder, der kan understøtte både en milliard daglige brugere og blokerer store nok til at rumme deres transaktioner?

Via Bitnodes

Bitcoin Core standard maksimalt 117 indgående forbindelser, der ville skabe en øvre grænse på 936.000 ledige stik på netværket. Imidlertid er de fleste af disse stik allerede forbrugt i dag.

Hver fuld knude forbinder til otte andre fulde knuder som standard. Bitcoin Core udvikler Luke-Jr s (meget groft) node countestimates 100.000 samlede knuder på i skrivende stund; 92.000, hvoraf ikke gør stikkontakter til rådighed for SPV klienter. Dette æder 800.000 ledige sokler bare for fuld noder, så kun 136.000 stikkontakter til rådighed for SPV klienter.

Dette fører mig til at konkludere, at omkring 85 procent af tilgængelige stikkontakter forbruges af netværket maskestørrelse på fuld noder. (Det er værd at bemærke, at Luke-Jr estimationsmetode ikke kan afgøre, hvor meget tid der ikke lytter noder tilbringer online, sikkert i det mindste nogle af dem afbryde og genoprette forbindelsen med jævne mellemrum.)

Min knude, der står bag statoshi.infoaverages 100 fuld knude (otte udgående, 92 indgående) jævnaldrende og 25 SPV klienter. Det er 80 procent af de tilgængelige stikkontakter, som forbruges af fuld noder.

Hvis vi ønsker endda 1 milliard SPV kunder til at være i stand til at bruge et sådant system, vil der være behov for tilstrækkelige fuld node ressourcer til rådighed til at servicere dem - netværkssockets, CPU-cyklusser, disk I / O, og så videre. Kan vi gøre det math træne?

For at give SPV skalering hævder gavn for tvivl, vil jeg bruge nogle konservative forudsætninger, som hver af de milliard SPV-brugere:

- Send og modtag en transaktion per dag.

- Synkroniser deres tegnebog til spidsen af ​​blockchain gang om dagen.

- Query fire forskellige knuder ved synkronisering for at mindske risikoen for at blive løjet for af udeladelse.

En milliard transaktioner per dag, hvis jævnt fordelt (som de sikkert ikke ville være) ville resultere i omkring 7 millioner transaktioner pr blok. På grund af den store skalerbarhed af Merkle træer, ville det kun kræve 23 hashes at bevise inddragelse af en transaktion i et sådant blok: 736 byte data plus gennemsnitligt 500 bytes for transaktionen.

Tilføj en 12KB værd af blok overskrifter om dagen og en SPV klient ville stadig kun bruge omkring 20KB værd af data om dagen.

Men 1 milliarder transaktioner per dag genererer 500GB værd af blockchain data for fuld noder til lagring og behandling. Og hver gang en SPV klient forbinder og anmoder om at finde nogen transaktioner for sin tegnebog i fortiden dag, skal fire fulde knuder læse og filtrere 500 GB data hver.

Husk på, at der i øjeblikket er omkring 136.000 stikkontakter til rådighed for SPV klienter på netværket af 8.000 SPV-betjener fuld noder. Hvis hver SPV klient bruger fire sokler, så kun 34.000 kunder kan være at synkronisere med netværket på et givet tidspunkt. Hvis der var flere mennesker online på en gang end det, andre brugere forsøger at åbne deres tegnebog ville få forbindelses fejl, når de forsøger at synkronisere til spidsen af ​​blockchain.

Således, for det aktuelle netværk til at understøtte 1 milliard SPV brugere at synkronisere en gang om dagen, mens kun 34.000 kan synkronisere på et givent tidspunkt, det er 29.400 "grupper" af brugere, der skal forbinde, sync, og afbryde: hver bruger ville skal være i stand til at synkronisere den foregående dag data i mindre end tre sekunder.

Dette udgør lidt af en gåde, fordi det ville kræve, at hver fuld knude at være i stand til at læse og filtrere 167GB af data per sekund per SPV klient kontinuerligt. Ved 20 SPV klienter pr fuld knude, der er 3,333GB per sekund. Jeg er bekendt med nogen lagringsenheder i stand til sådan gennemløb. Det bør være muligt at skabe et kæmpe RAID 0-array af high-end solid state disksthat kan opnå omkring 600 MB / s hver.

Du vil brug for 5.555 drev med henblik på at nå målet gennemløb. Den linkede eksempel disk koster $ 400 i skrivende stund og har ca. 1 TB kapacitet - nok til at gemme to days'-værdi af blokke i denne teoretiske netværk. Således ville du brug for en ny række af diske hver to dage, hvilket ville koste dig over 2,2 $ millioner - det beløber sig til mere end $ 400 millioner til at lagre en årets-værdi af blokke, mens du stadig møde den krævede læst gennemløb.

Selvfølgelig kan vi lege med disse antagelser og nappe forskellige numre. Kan vi producerer et scenarie, hvor noden omkostningerne er mere rimeligt?

Lad os prøve:

Hvad hvis vi havde 100.000 fulde noder alle kørende billigere, høj kapacitet roterende diske, og vi på en måde overbeviste dem alle til at acceptere SPV klientforbindelser? Hvad hvis vi også formået at ændre den fulde node software til at understøtte 1000 tilsluttede SPV kunder?

Det ville give os 100 millioner stikkontakter til rådighed for SPV klienter, som kunne understøtte 25 millioner samtidige SPV klienter på netværket. Således hver SPV klient ville have 2.160 sekunder om dagen for at synkronisere med netværket. For en fuld knude til at holde trit med efterspørgslen det vil være nødvendigt at fastholde en konsekvent læsehastighed på 231MB / s pr SPV-klient, som ville resultere i 231GB / s antager 1.000 tilsluttede SPV klienter.

En 7200 RPM harddisk kan læse om 220MB / s, så man kunne opnå dette læst gennemløb med en RAID 0-array af lidt mere end 1.000 drev.

På skrivende stund kan du købe en 10 TB-drev til $ 400, altså en $ 400.000 RAID-array af disse drev vil gøre dig i stand til at gemme 20 days'-værdi af blokke - svarer det til en langt mere overskueligt 7,2 mio $ til at gemme en årets-værdi af blokke, mens du stadig opnå den disk læse throughput krav.

Du skal tilføje mindst 2 af disse hver dag!

Det er værd at bemærke, at ingen i deres rette sind ville køre et RAID 0 array med dette mange drev, fordi et enkelt drev fiasko vil ødelægge hele systemet af diske. Således et RAID-array med fejltolerance ville være endnu dyrere og mindre ydedygtige. Det synes også utroligt optimistisk, at 100.000 organisationer ville være villig til at pony op millioner af dollars om året for at køre en fuld knude.

Et andet punkt at bemærke er, at disse konservative skøn også antage, at SPV klienter eller anden måde ville koordinere at distribuere deres synkronisering gange jævnt hver dag. I virkeligheden ville der være daglige og ugentlige cykliske toppe og dale aktivitetsområder - netværket vil være nødvendigt at have en rimelig højere kapacitet end anslået ovenfor, for at imødekomme spidsbelastninger.

Ellers ville mange SPV kunder undlader at synkronisere under spidsbelastning brug timer.

Interessant, det viser sig, at ændre antallet af stikkontakter pr node ikke påvirker den samlede belastning på en given fuld knude - det stadig ender behov for at behandle den samme mængde data. Det, der virkelig betyder noget i denne ligning er forholdet mellem fuld noder til SPV kunder. Og, selvfølgelig, størrelsen af ​​blokkene i kæden, at de fulde noder har brug for at behandle.

Slutresultatet synes uundgåelig: omkostningerne ved at drive en fuld knude i stand til at servicere SPV efterspørgsel af en milliard daglig on-kæde transaktionsparter ville være astronomiske.

Søger en mellemvej

På dette punkt, er det helt klart, at en milliard transaktioner per dag sætter omkostningerne ved at drive en fuldt validering knude uden for rækkevidde af alle, men de rigeste enheder.

Men, hvad nu hvis vi vende denne beregning på hovedet og i stedet forsøge at finde en formel til bestemmelse af omkostninger ved at tilføje belastning på netværket ved at øge on-kæde transaktion gennemløb?

For at Bitcoin netværk til støtte et mål antal transaktioner per sekund (tilføjelse kapacitet til 86400 netto nye daglige brugere), kan vi beregne pr-node disk gennemløb krav:

Det giver os den mindste disk læse gennemløb per sekund for en fuld node til tjeneste efterspørgsel fra SPV klienter. Med de eksisterende karakteristika af netværket og tilgængelig teknologi, kan vi ekstrapolere en anslået udgift på node operation ved at bruge disk gennemløb som antaget flaskehals. Bemærk, at der er helt sikkert andre ressourcemæssige begrænsninger, der ville komme i spil, hvilket øger omkostningerne ved fuld node operation.

For de følgende beregninger, jeg brugte disse antagelser:

- Gennemsnitlig transaktion størrelse i byte = 500 byte baseret på statoshi.info.

- Samlet antal SPV brugere = én per transaktion per dag.

- Sockets forbruges af en SPV klient = standard på fire.

- Antallet af stikkontakter til rådighed for SPV klienter på hver fulde node = forudgående beregnede antal på 20.

- I alt netværkssockets rådighed for SPV klienter = forudgående beregnede antal 136.000.

- Udgifter til harddisken gennemløb og rum = $ 400 10TB 7.200 RPM drev i RAID 0-konfiguration.

Vi kan se, at med hensyn til disk gennemløb det forbliver nogenlunde rimelig, indtil vi overgå 100 transaktioner i sekundet. På det tidspunkt du begynder at skulle købe flere diske og stripe dem i en RAID-array med henblik på at opnå de krav til ydeevne.

Desværre disk gennemløb krav og dermed koste at drive en fuld knude stigning kvadratisk i forhold til antallet af transaktioner i sekundet. Omkostningerne hurtigt blive uholdbar for de fleste enheder.

For reference, minde om, at Visa behandler omkring 2.000 transaktioner i sekundet. På Bitcoin dette ville kræve næsten $ 200.000 værd af diske bare for at holde trit med SPV efterspørgsel. Et punkt værd at bemærke er, at disse diagrammer holde antallet af fulde knuder konstant ved 8.000 - i virkeligheden, ville de sandsynligvis falde som omkostningerne gik op, og dermed hæve throughput krav og omkostninger til drift af de resterende knuder at stige endnu hurtigere.

Dette synes at være en blanding kraft knude centralisering.

Som jeg konkluderede i "Hvordan at spare Bitcoin s Node Network Fra Centralisering", en af ​​de grundlæggende spørgsmål om påstand omkring øge blokken størrelse er omkostningerne ved node operation. Ovenstående beregninger giver os et glimt af kompleksiteten i beregningen af ​​omkostningerne ved node operation, fordi der er så mange variabler involveret - disse beregninger var at holde de fleste af de variabler konstant og kun at fokusere på disk-I / O-omkostninger.

De (uvidenskabelige) meningsmålinger Jeg kørte et år tidligere viste, at 98% af node operatører ikke ville betale mere end $ 100 per måned at køre en knude, selv om de var stærkt investeret i Bitcoin. Jeg ville være villig til at vædde på, at stigende Bitcoin s on-kæde transaktioner ved en størrelsesorden ville resultere i tab af et flertal af fulde knuder, mens en stigning på to størrelsesordener ville resultere i et tab på 90% eller flere noder.

Jeg tror, ​​det er sikkert at antage, at meget få enheder ville være villig til at gå til den ulejlighed at bygningen RAID for at køre en fuld knude. Hvis dette er tilfældet, er det uholdbart at påstå, at sådanne forhøjelser vil være fint for den gennemsnitlige bruger, fordi der ikke ville være nær nok fuld knude disk gennemløb eller stikkontakter til rådighed til at servicere SPV efterspørgsel.

Andre SPV svagheder

SPV er fantastisk til slutbrugere, der ikke kræver sikkerhed eller privatlivets fred for en fuldt validering knude. Men der er masser af grunde, der kunne betragtes showstoppers for en overvejende-SPV Bitcoin netværk, uanset dens skalerbarhed.

SPV gør væsentlige forudsætninger, der resulterer i det at have svagere sikkerhed og privatlivets fred end et fuldt validering node:

  1. SPV kunder har tillid til minearbejdere til at validere og håndhæve reglerne for Bitcoin korrekt; de antager, at blockchain med den største kumulative proof-of-arbejde er også et gyldigt kæde. Du kan lære om forskellen mellem SPV og fuld knude sikkerhedsmodeller i denne artikel.
  2. SPV kunder antager, at fulde knuder ikke vil lyve for dem ved undladelse. En fuld knude kan ikke lyve og sige, at eksisterede en transaktion i en blok, når det faktisk ikke eksisterer, men det kan ligge ved at sige, at en transaktion, der findes i en blok ikke skete.
  3. Fordi SPV klienter stræbe efter effektivitet, de kun anmode om data for transaktioner, der tilhører dem. Dette resulterer i et massivt tab af privatlivets fred.

Interessant, medforfatter af BIP 37, Matt Corallo, beklager at skabe det:

"En stort problem i dag for privatlivets fred for brugerne i systemet er BIP37 SPV blomstrer filtre. Undskyld, jeg skrev det."

BIP 37 Bloom-filtrerede SPV klienter har dybest set ingen privatliv, selv når du bruger urimeligt høje falsk-positive rater. Jonas Nick [en sikkerhed ingeniør på Blockstream] fandt, at givet en enkelt offentlig nøgle, kunne han så bestemme 70% af de øvrige adresser, der tilhører en given tegnebog.

Du kunne arbejde omkring SPV fattige privatliv ved at opdele Bloom filtre blandt mange jævnaldrende, selv om dette ville gøre skalerbarhed af SPV endnu værre ved at placere mere belastning på flere fuldt noder.

BIP 37 er også sårbare over for trivielle denial-of-service-angreb. Demonstration kode er tilgængelig herethat er i stand til at lamme hele knuder ved at gøre mange hurtige opgørelse ansøgninger gennem specielt konstruerede filtre, der forårsager kontinuerlig disk søge og høj CPU-forbrug.

Forfatteren af ​​angrebet har proof-of-concept, Kerneudvikler Peter Todd, forklarer:

"Det grundlæggende problem er, at du kan forbruge en uforholdsmæssig stor del af disk-I / O-båndbredde med meget lidt båndbredde."

Selv den dag i dag, har de svindel advarsler, Satoshi beskrevet i hvidbogen ikke blevet gennemført. Faktisk har forskningsindsats på dette område vist kan det ikke engang være muligt at implementere letvægts svig indberetninger.

For eksempel kan en alarm bedrageri virker kun, hvis du kan faktisk få de data, der kræves for at bevise svindel - hvis en minearbejder ikke giver, at data, kan advarslen bedrageri ikke oprettes. Som sådan behøver SPV klienter ikke har det sikkerhedsniveau, som Satoshi forestillede de ville have.

Fra et meget højt niveau perspektiv, en verden, der består for det meste af SPV knuder gør konsensus ændringer såsom den samlede mønten hætte eller endda redigering af regnskabet meget lettere. Færre fuldt validering noder betyder mere centraliseret håndhævelse af konsensus regler og dermed mindre modstand mod skiftende konsensus regler. Nogle mennesker kan overveje at en funktion; mest sikkert overveje det en fejl.

Potentielle forbedringer

SPV sikkerhed & skalerbarhed potentielt kunne forbedres på en række måder via bedrageri beviser, hints svig, input beviser, spentness beviser, og så videre. Men så vidt jeg er klar ingen af ​​disse er forbi idéfasen, langt mindre klar til indsættelse produktion.

Bloom filter commitmentscould forbedre privatlivets fred, men der er en afvejning for nytten mellem størrelsen af ​​filteret og dens falsk positiv rate: for grove midler jævnaldrende downloade alt for mange falsk-positive blokke, for fin betyder filtrene vil være absolut gigantisk og upraktisk for nogen at hente med en SPV klient.

Det ville reducere belastningen på fuld node disk gennemløb, men afvejningen ville blive øget båndbredde af både SPV kunder og fuld knuder, fordi hele blokke vil skulle overføres på tværs af netværket.

Dette nyligt foreslået kompakte klientsiden filtrering eliminerer privatlivets fred, men det kræver hele blokke, der skal downloades, hvis der er en kamp mod filteret (dog ikke nødvendigvis via p2p netværk!).

UTXO commitmentscould sætte SPV klienter til at synkronisere deres nuværende UTXO sæt og dermed tegnebog balance uden at kræve den fulde node til at scanne hele blockchain. Tværtimod ville det give et bevis på de UTXOs eksisterende.

Det kan være muligt at sikre sig mod Bloom filtrere DoS-angreb ved at kræve SPV klienter til enten indsende proof-of-arbejde (uholdbar på en batteridrevet enhed som en telefon) eller kanal-baserede mikrobetalinger (umuligt at bootstrap hvis en klient ikke har modtaget penge endnu), men hverken giver en enkel løsning.

Disken læste krav til fulde knuder kunne sandsynligvis blive reduceret i en række måder via forbedret indeksering af data og afmålte behandling af anmodninger fra SPV klienter.

Ryan X Charles påpegede i kommentarerne nedenfor, at bruge BIP70 betaling protokol til direkte fortælle nogen det UTXO id for betaling, du sender dem ville fjerne behovet for dem at bruge bloom filtre på alle da de kunne anmode data direkte fra fuld knuder. Dette er utrolig effektiv, hvis du er villig til at acceptere privatliv studehandel.

Tilstrækkeligt til at sige, er der masser af plads til forbedring - mange udfordringer, der skal overvindes for at forbedre på-kæde skalerbarhed.

Egnede skalering løsninger

Hvis vi ignorerer de mange diverse andre problemer med skalering til større blokstørrelser såsom blok formering latency, UTXO sæt skalering, indledende blockchain synkronisering tider og sikkerhed og privatlivets fred afvejninger, kan det være teknisk muligt at skalere Bitcoin til en milliard dagligt på kæden brugere, hvis der er enheder villige til at investere betydelige ressourcer til at udvikle software forbedringer, og at drive den nødvendige infrastruktur.

Det virker meget usandsynligt, at Bitcoin ville udvikle sig organisk i, at mode, men fordi der er langt mere effektive måder at skalere systemet. Den mest effektive er en form for skalering allerede anvendes: konsolidering omkring centraliserede API udbydere. Der en tendens til at være enorme tillid og privatlivets fred afvejninger, når ansætte disse metoder, men mange af disse interaktioner involverer aftaler, der mindsker nogle af de farer.

I form af skalering i en trustless måde, Layer 2 protokoller såsom Lightning tilbyder meget mere effektiv skalering fordi de store mængder data, der overføres kun sendes blandt det lille antal parter er direkte involveret i en given off-kæde transaktion. Du kan tænke på det som forskellen mellem en udsendelse-til-alle Ethernet kommunikation lag versus en dirigeres IP-laget - internettet ikke kunne skalere uden routing og hverken kan internet penge.

Mens denne tilgang til skalering er langt mere teknisk kompliceret end traditionel centraliseret skalering og vil kræve at overvinde nogle unikke udfordringer, vil det up-front investering af ressourcer til forskning og udvikling af disse routing protokoller betale enorme udbytte på lang sigt, da de reducerer belastning, der skal bæres af hele netværket ved størrelsesordener.

Der er også masser af muligheder i mellem, der kan udforskes:

- Centraliseret frihedsberøvende ordninger med perfekt privatliv, der bruger Chaum tokens såsom Hashcash.

- Centrale ikke-frihedsberøvende vidensløst bevis systemer såsom TumbleBit.

- Federated (semi-betroet multisignature) sidekæder.

- Miner-sikrede (semi-betroet) drivechains.

Jeg er stadig convincedthat på længere sigt vil Bitcoin brug for meget større blokke.

Men lad os være tålmodig og taktfuld ved at forsøge at skalere systemet så effektivt som muligt og samtidig bevare dens sikkerhed og privatlivets fred egenskaber.

En kontrollerbar, let decentraliseret PayPal ville sikkert have nytte, hvis det var funktionelle ud fra den gennemsnitlige bruger, men det ville ikke tilbyde den finansielle suverænitet som bitcoiners nyder i dag.

Takket være Matt Corallo, Mark Erhardt og Peter Todd til at gennemgå og give feedback til denne artikel

Relaterade nyheter


Post Valutaveksling

Coinbase Files 9 Patenter til Bitcoin Products

Post Valutaveksling

BTC-e muliggør udbetaling af fonde ved hjælp af MasterCard og Visa-kort

Post Valutaveksling

Spredninger udvides ved bitcoin-udvekslinger i kraft af Bitfinex-bankproblemer

Post Valutaveksling

Bitfinex til Hacker: Kan vi få vores Bitcoin tilbage?

Post Valutaveksling

Bitstamps Permanent Outage Echo gennem Bitcoin Economy

Post Valutaveksling

37Coins planlægger verdensomspændende Bitcoin Access med sms-baseret pung

Post Valutaveksling

Den 150 EUR ATM, Fordele ved risikable fremtidige og Bitcoins fælles Touch

Post Valutaveksling

En dommer har lige ryddet vejen for IRS til at søge Coinbase kundedata

Post Valutaveksling

Bitcoins kapacitetsproblemer Intet mareridt, men højere gebyrer kan være ny virkelighed

Post Valutaveksling

Bitfinex refunderer første Bitcoin Exchange Hack-ofre

Post Valutaveksling

Bitcoin Exchange Kraken hæver $ 5 millioner i Seneste funding runde

Post Valutaveksling

Coinkite Drops Consumer Wallet til Enterprise Bitcoin Hardware Pivot