Afslutter debatten om bitcoin vs blockchain

Er der nogen værdi i en blockchain uden en kryptovaluta?

Debatten har kørt i et stykke tid, men den seneste måned har der været en alvorlig stigning. Spørgsmålet der stilles er:

Er der nogen værdi i en blockchain uden en kryptovaluta? Og kan disse "tegnløse delte hovedbøger" overhovedet kaldes blockchains?

Så jeg har læst Baileys artikel, så Tims video, Læs dette Nasdaq-indlæg, fulgte Richards hver ord, og havde endda min egen godmodig debat (se kommentarer) med Modpartsfondens Chris DeRose. Så meget varm luft.

En ting, Chris gør godt, er at koge det ned til spørgsmålet: er blockchain en økonomisk eller en computervidenskabelig innovation? Implikationen er, at hvis blockchains er en ren økonomisk innovation, er der ingen mening med blockchains uden kryptovalutaer. Så lad mig sige min holdning i starten:

Bitcoin blockchain var både en økonomisk , en datalogisk innovation.

Jeg tillader "innovation" her at inkludere en ny kombination af eksisterende teknikker, snarere end noget, der ikke har nogen fortilfælde overhovedet. Denne definition gør det muligt for world wide web at blive betragtet som en innovation, selvom det ikke gjorde andet end at kombinere hypertekst med et twist på nogle eksisterende internetprotokoller. Hvis du ønsker at vedtage en strengere definition af innovation, så vær min gæst, men du vil blive overrasket over, hvor få sande "innovationer" der er tilbage. For at parafrasere The Teacher, der er lidt nyt under solen.

For at være præcis, så påstår jeg det blockchains uden token tjener et formål, men det er en forskellige formål sammenlignet med den originale bitcoin blockchain. Krypto-hoveder griner af token-fri blockchains, fordi de ikke kan give censurmodstand og decentraliseret sikkerhed gennem proof-of-work. Fintech-hoveder griner af offentlige blockchains, fordi de er langsomme, dyre og uegnede til traditionel finansiering. Nå, bliv ved med at grine alle sammen, for jeg tror, ​​at I begge har ret.

Jeg vil argumentere for, at token-fri blockchains er nyttige til at holde decentraliserede databaser synkroniseret, selv i en enkelt organisation, hvor der er fuldkommen tillid. Og så vil vi se, hvilke andre funktioner blockchains tilbyder, som gør dem egnede til at skabe konsensus om specifikke typer transaktioner mellem organisationer, hvor der kun er begrænset og ufuldkommen tillid.

Desværre, for at følge argumentet, bliver du nødt til at nørde med mig om bitcoin-transaktionsmodellen, database multiversion concurrency control (MVCC) og problemet med konfliktløsning i multi-master database replikering. Jeg vil gøre mit bedste for at holde mig til engelsk, men alligevel er dette tekniske ting, og det er ikke til at undgå det.

Bitcoins transaktionsmodel

Bitcoin transaktionsmodellen er enkel, men kraftfuld. Hver bitcoin-transaktion har et sæt input og et sæt output. Hvert input "bruger" et output fra en tidligere transaktion. Alle bitcoin i en transaktions input flyder ind i den pågældende transaktion og fordeles på tværs af dens output i overensstemmelse med mængderne skrevet indeni. På denne måde danner transaktioner en multi-vejs forbundet kæde, som ender ved "coinbase" transaktioner, hvor nye bitcoins oprettes.

Bitcoin har en masse yderligere regler, som håndhæves af hver node i netværket:

• Ethvert input i en transaktion skal bevise, at det har ret til at bruge det tidligere output, som det er forbundet med. Denne ret er begrænset af betingelser, der er kodet i det tidligere output.
• En transaktion skal have tilstrækkelig total bitcoin i sine inputs til at dække det samlede beløb, der er skrevet i dens output. De eneste undtagelser er møntbase-transaktioner, som skaber nye enheder af valutaen.
• Hver udgang kan kun bruges én gang, med andre ord kan den kun tilsluttes én indgang i en efterfølgende transaktion.

På grund af denne sidste regel kræver netværket en mekanisme til at opnå konsensus om, hvilke transaktioner der er gyldige, og det er hvad blockchain gør. Specifikt:

Hvis to transaktioner forsøger at bruge det samme output, vil kun én af disse transaktioner i sidste ende blive accepteret. En blockchain fungerer som en samlet mekanisme til at opdage og forhindre disse konflikter på tværs af netværket.

Blockchain er struktureret som en serie af sammenkædede blokke, hvor hver blok indeholder et sæt transaktioner, der ikke er i konflikt med hinanden eller med tidligere blokke, startende fra den første blok oprettet i 2009. I teorien kunne kæden indeholde en række af individuelle transaktioner, men ved at samle transaktioner i blokke opnår vi en række effektiviseringer, der gør ordningen mere praktisk.

Så hvad er formålet med en kryptovaluta i alt dette? Det kommer ned til spørgsmålet om, hvem der bestemmer over de blokke, der udgør kæden. Bitcoin er decentraliseret og har ingen autoritet, der kan træffe denne beslutning, så den er nødt til at finde en anden måde at nå konsensus på.

Vi kunne godt tænke os at bruge en demokratisk tilgang, hvor noder i netværket stemmer om blokke, og flertallet vinder. Desværre, som enhver internetundersøgelse kan vise, er repræsentativt demokrati ikke muligt online på grund af problemet med personefterligning (også kendt som en Sybil angreb). Én person kan overtage en million computere og bestemme, hvordan de stemmer, og dermed tage kontrol over netværkets konsensus. Ingen andre vil selv vide, at dette er sket.

For at løse dette gør bitcoin det bevidst svært at tilføje en blok til kæden, via en proces kaldet "mining". For at skabe en blok skal du løse et vanskeligt, men meningsløst matematisk problem, der kræver en masse beregning (og derfor elektricitet og penge). Du har også brug for lidt held, da du konkurrerer med mange andre blokminearbejdere rundt om i verden. Du kan ikke komme videre i lang tid ved at købe en mere kraftfuld minecomputer, fordi netværket jævnligt justerer problemets sværhedsgrad for at holde en stabil global rate på én blok pr. 10 minutter.

Hvis det er så svært og dyrt at oprette en blok, hvorfor skulle nogen så gide det? Svaret er i blokbelønningen. Den succesrige minearbejder i en blok kontrollerer møntbase-transaktionen, der tildeler dem 25 bitcoins (denne sum halveres hvert fjerde år). De kan sælge disse bitcoins på det åbne marked for 7,000 dollars (med dagens kurs), betale deres elregning og forhåbentlig have lidt fortjeneste. Minearbejdere indsamler også lidt ekstra fra gebyrer, der er knyttet til transaktioner, selvom disse gebyrer indtil videre spiller en mindre rolle.

Så bitcoin genererer konsensus via proof-of-work, og kernen i bitcoin-hovedernes argument er dette: Uden en kryptovaluta er der ingen måde at tilskynde til decentraliseret minedrift af blokke. Derfor er der ingen måde at sikre en åben blockchain mod efterligningsangreb. Derfor kan enhver monopolisere netværkskonsensus og gøre det hele ubrugeligt. Jeg vil ikke argumentere med noget af det.

Multiversion samtidighedskontrol

I mellemtiden vil jeg gerne tale om noget, der kan virke fuldstændig uafhængigt.

En database er et lager af struktureret information, grupperet i regnearkslignende enheder kaldet tabeller. Et simpelt eksempel på en sådan tabel er en liste over bankkonti, hvor hver række indeholder et kontonummer sammen med saldoen på den pågældende konto. Lad os sige, at din konto starter dagen med en saldo på 900 USD. I dag er der planlagt en automatisk realkreditbetaling på $750, og du skal også hæve $400 fra en hæveautomat. Desværre har du ikke en kassekredit, så en af ​​disse operationer er sat op til at mislykkes.

Processerne for betaling af realkreditlån og hævninger i hæveautomater kører på separate systemer, som begge har adgang til denne enkelt kontodatabase. Lad os sige, at hver proces fungerer ved at læse din kontos saldo, kontrollere, at den er tilstrækkelig til operationen, starte den handling, bekræfte, at operationen er fuldført, beregne den nye saldo og så til sidst skrive den ind i databasen.

Så længe din betaling af realkreditlån og hævning af pengeautomater ikke overlapper hinanden, vil denne logik fungere fint. Den første operation udføres med succes, og den anden vil afbryde, fordi din konto ikke har tilstrækkelige midler. Afhængigt af ordren får du et vredt telefonopkald fra banken eller en uhøflig besked på ATM-skærmen.

Men hvad sker der, hvis de to processer tilfældigvis starter på samme tid? I dette tilfælde vil hver enkelt læse din kontos saldo og vurdere, at den er tilstrækkelig til at fortsætte. Når realkreditlånet er gennemført, vil din nye saldo blive beregnet til $150 og skrevet til databasen. Når hævningen i hæveautomaten er fuldført, vil din nye saldo på $500 på samme måde blive skrevet. En af disse skriveoperationer kommer til at tilsidesætte den anden, og afhængigt af dit held vil du modtage en $750 eller $400 bonus fra din bank. Uden tvivl vil du snart lære at time dine ATM-besøg til realkreditdagen.

Selvfølgelig sker dette ikke i virkeligheden, på grund af en databaseteknologi kaldet samtidighedskontrol. Samtidighedskontrol holder vores data (især økonomiske) sunde og sikre, og det kommer i mange former. Men alle deler princippet om, at databaseoperationer er grupperet i "transaktioner", som behandles atomisk, hvilket betyder, at de lykkes eller mislykkes som helhed. Samtidighed bevarer konsistensen ved at låse eller fryse dele af en database, mens de er i brug af én transaktion, for at forhindre andre transaktioner i at fungere på den samme information på en modstridende måde.

Hvis vi ikke behøvede at køre transaktioner parallelt, kunne vi låse hele databasen i hele varigheden af ​​hver enkelt transaktion. Dette er dog ikke praktisk i de fleste applikationer i den virkelige verden. En god samtidighedskontrol tillader parallelle operationer ved at låse så lidt data som muligt i så kort tid som muligt. I eksemplet ovenfor vil kun databaserækken, der svarer til din konto, være låst, og kun i det splitsekund, hvor en sidste kontrol og fradrag fandt sted. En modstridende transaktion, der opererer parallelt, ville simpelthen skulle vente, indtil denne lås udløses.

En populær teknik til samtidighedskontrol kaldes multiversion samtidighedskontroleller MVCC for kort. I MVCC ser hver transaktion et ensartet øjebliksbillede af dataene på et bestemt tidspunkt, selvom en del af disse data er i færd med at blive opdateret af en anden samtidig transaktion. Dette snapshot isolation ejendom sikrer fx, at en opgørelse, der viser vores samlede saldo på tværs af flere konti, altid vil være korrekt, selvom nogle midler er i gang med at flytte fra en konto til en anden. En transaktion vil kun påvirke de data, der ses af en anden transaktion, hvis den anden begynder, efter at alle den førstes ændringer er blevet anvendt.

Bag kulisserne fungerer MVCC ved at tillade, at flere versioner af en række vedligeholdes samtidigt, sammen med et tidsstempel, der repræsenterer hver versions dato for sidste ændring. Ændring af en databaserække i MVCC markerer den aktuelle version af denne række til sletning, mens ændringen anvendes på en kopi af den række med et opdateret tidsstempel. Fra perspektivet af databasens lagerlag er der ikke sådan noget som at ændre en række på plads. Hver transaktion ved præcis, hvornår den startede, og ser kun versioner af rækker, hvis tidsstempling er før det tidspunkt. Gamle versioner af rækker kan fjernes fra lageret, når der ikke er nogen igangværende transaktioner, som muligvis skal have adgang til dem.

Afgørende for vores formål her forhindrer MVCC konflikter mellem skriveoperationer. Specifikt:

Hvis to transaktioner forsøger at slette den samme rækkeversion, vil kun én af disse transaktioner i sidste ende blive accepteret. Multiversion samtidighedskontrol fungerer som en samlet mekanisme til at opdage og forhindre disse konflikter i en database.

Ringe nogen klokker? Der er endnu et stykke baggrund, vi skal diskutere.

Multi-master database replikering

Lad os nu tale om databasereplikering, hvor en database eksisterer i flere kopier. Der er en række gode grunde til at replikere en database, såsom:

• For at øge pålideligheden, så hvis en kopi af databasen går tabt (f.eks. på grund af en diskfejl), kan vi øjeblikkeligt skifte til en anden kopi.
• For at øge gennemløbet, hvis mængden af ​​operationer overstiger kapaciteten af ​​en enkelt databaseserver.
• For at reducere latens, så processer, der kører på Singapore-kontoret, ikke behøver at vente på svar fra en database i Toronto.

Når det kommer til læsning data fra databaser, er replikering en ideel teknik, fordi alle replikaerne indeholder den samme information. Men tingene bliver mere klistrede, når det kommer til skriveoperationer, fordi vi skal beslutte, hvor disse skriveoperationer udføres, og hvordan de overføres til andre kopier af databasen.

Det mest almindelige svar er at bruge master-slave-replikering, hvor en enkelt database ("masteren") betragtes som autoritativ. Eventuelle ændringer af dataene udføres udelukkende på masteren og sives derefter ned til alle de andre "slave"-databaser via en transaktionslog. Dette holder alle databasekopier (mere eller mindre) øjeblikkeligt synkroniseret.

Desværre, hvis skriveoperationer er hyppige, bringer master-slave-replikering os lige tilbage til det problem, som replikering var designet til at løse. Masterdatabasen bliver en flaskehals med hensyn til pålidelighed, gennemløb og latens, da hver skriveoperation udføres på den alene.

En mere kompleks strategi kaldes multi-master-replikering, hvor skrivning kan udføres på enhver af databasekopierne i stedet for på en enkelt master. I dette tilfælde deler kopierne opdateringer med hinanden på en peer-to-peer-måde for at forblive synkroniseret.

Dette lyder simpelt i teorien, men multi-master replikering introducerer et nyt problem, fordi der kan opstå konflikter. Hvad hvis to kopier af en database opdaterer den samme række på samme tid og derefter forsøger at udveksle disse opdateringer med hinanden? Begge databaser vil bemærke, at en modstridende opdatering har fundet sted, og er nødt til at anvende en aftalt strategi for at løse disse konflikter. Og her kommer tingene ret komplekst – se dokumenterne for MySQL, SQL Server or Oracle for nogle eksempler på konfliktløsningsstrategier. (Jeg ignorerer synkron eller såkaldt "ivrig" multi-master replikering, hvor alle replikaer skal forpligte sig til en skriveoperation, før den kan finde sted, fordi det bliver hver kopi af databasen til en flaskehals.)

Så her er hvor al denne baggrund fører:

Ville det ikke være rart, hvis vi kunne have distribueret multiversion samtidighedskontrol, for at forhindre konflikter, der opstår i multi-master replikering?

Nå, ja, jeg forestiller mig, at det ville være meget rart. Og jeg tror på, at det er præcis, hvad blockchains gør.

Blockchains som distribueret MVCC

Lad os kopiere et par sætninger ned, som jeg skrev med fed skrift ovenfor:

Hvis to transaktioner forsøger at tilbringe det samme output, så vil kun én af disse transaktioner i sidste ende blive accepteret. En blockchain fungerer som en samlet mekanisme til at opdage og forhindre disse konflikter på tværs af netværket.

Hvis to transaktioner forsøger at slette det samme række version, så vil kun én af disse transaktioner i sidste ende blive accepteret. Multiversion samtidighedskontrol fungerer som en samlet mekanisme til at opdage og forhindre disse konflikter i en database.

Disse sætninger er identiske med undtagelse af de fede udtryk. Så her er hvad jeg vil påstå:

En blockchain giver distribueret MVCC (med et par ekstra klokker og fløjter).

Lad os uddybe sammenligningen lidt nærmere. Fra perspektivet af en blockchain-knude danner det aktuelle sæt af ubrugte bitcoin-transaktionsoutput en database, hvor hver række er et enkelt ubrugt output. Dette svarer til databasen over bankkonti, vi beskrev tidligere, med den mindre forskel, at saldoen på hver konto kan opdeles på tværs af flere rækker, som hver er markeret med det samme kontonummer.

En bitcoin-transaktion bruger et eller flere af disse output og skaber et eller flere nye output som et resultat. Dette er præcis som en databasetransaktion, der sletter en eller flere rækkeversioner og opretter en eller flere nye rækker som et resultat (husk på, at der i MVCC ikke er sådan noget som at ændre en række på plads). Bitcoin blockchain sikrer, at et enkelt output ikke kan bruges af mere end én transaktion. Dette svarer til at sikre, at en enkelt række version ikke kan slettes af mere end én databasetransaktion.

Nu, før vi bliver revet med, påstår jeg ikke, at blockchains er en fantastisk teknologi til generelle formål til distribueret databasesynkronisering i et fuldt betroet miljø. Der er masser af andre teknologier som f.eks Paxos, Raft , To-faset forpligtelse som udfører arbejdet meget flot. Men jeg tror på, at blockchains har et sweet spot, som kan karakteriseres som applikationer, hvor:

• Vi kan acceptere en kort forsinkelse mellem, hvornår en transaktion sandsynligvis er accepteret, og hvornår den definitivt er accepteret. (Denne forsinkelse kan være et spørgsmål om sekunder i stedet for 10 minutter som i bitcoin.)
• Modstridende transaktioner bør aldrig ske, hvis alle er ærlige, og deres systemer fungerer korrekt.
• Hver transaktion ændrer kun nogle få rækker samtidigt (ellers vil vores blockchain-transaktioner have et uhåndterligt antal input).
• Størrelsen af ​​hver databaserække er ret lille (igen for at forhindre, at vores blockchain-transaktioner springer i størrelse).

Alle disse kriterier er opfyldt af økonomiske ansøgninger. Den finansielle verden er allerede vant til forsinkelser (på op til 3 dage!) mellem gennemførelsen af ​​en transaktion og dens endelige afvikling. Med hensyn til at forebygge konflikter har den kontrakter og regler på plads for at opdage svindel, og konsekvenserne kan være alvorlige. Og mængden af ​​data involveret i hver transaktion er ret lille - tænk på bankkontoeksemplet ovenfor.

Indtil videre har jeg kun demonstreret, at blockchains er endnu en synkroniseringsmekanisme for distribuerede databaser. Stort wow. Ting bliver først virkelig interessante, når vi overvejer de ekstra funktioner, som blockchains tilbyder.

Blockchains ud over MVCC

En bitcoin-transaktion gør meget mere end blot at pege på nogle tidligere transaktionsoutput og skabe nogle nye i deres sted. Selv den enkleste bitcoin-transaktion tjener to yderligere formål.

For det første indeholder reglerne vedrørende gyldige transaktioner noget af applikationslogikken for vores kontodatabase. Husk, at den samlede mængde bitcoin i en transaktions input skal dække den samlede mængde i output. Oversat til databaseapplikationslogik er dette en regel, der siger, at databasetransaktioner (med undtagelse af møntbaser) ikke er tilladt at øge den samlede mængde bitcoin i databasen. Denne form for begrænsning går ud over almindelig database lagrede procedurer fordi det under ingen omstændigheder kan omgås.

For det andet skal du huske, at hver bitcoin-transaktionsoutput koder for betingelserne, hvorunder den kan bruges. For almindelige bitcoin-output er denne betingelse baseret på offentlig nøglekryptering. En offentlig adresse er indlejret i output-"scriptet", så den kun kan bruges ved at bruge den private nøgle, der svarer til den offentlige adresse. Hvis vi anser dette output for at være en databaserække, er det, vi har, en database med per-række-tilladelser, som er baseret på offentlig nøglekryptering. Desuden præsenterer hver transaktion et offentligt revideret bevis på, at dens skaber(e) havde ret til at slette/ændre sine tidligere rækker. Dette (tror jeg) er en ægte nyhed inden for databaseteknologi.

Og igen er det bare sådan, at begge disse funktioner er utrolig nyttige til finansielle applikationer. Vi kan godt lide, at vores database sikrer på det lavest mulige niveau, at penge ikke kan skabes ud af den blå luft. Og vi kan godt lide at have et uomtvisteligt revisionsspor, der viser, at hver transaktion blev godkendt af indehaveren af ​​de midler, som den flyttede. Som diskuteret i detaljer her, kan vi også lide at udføre sikre atomære peer-to-peer-udvekslingstransaktioner (levering-versus-betaling i finans-snak), uden selv at kende identiteten på vores modpart.

Så hvor er tokenet?

Selvfølgelig er intet af dette en tilfældighed, for bitcoin i sig selv er en smuk peer-to-peer finansiel applikation. Alligevel er ingen af ​​de ovennævnte egenskaber ved en blockchain overhovedet afhængige af tokenet. Hvis vi ændrer vores "database"-skema, så hver række kan repræsentere flere aktiver i stedet for blockchains oprindelige valuta, så kan vi slippe helt for denne valuta. Dette efterlader os med en blockchain som en måde at opnå konsensus og sikkerhed i en peer-to-peer finansiel ansøgning for enhver aktivklasse.

Dog kun et lille spørgsmål: Hvem laver minedriften for at skabe denne konsensus? I bitcoin skal anonyme minearbejdere udføre dyre, ubrugelige beregninger, og de tilskyndes til at gøre det af blokbelønninger (og transaktionsgebyrer) angivet i blockchains oprindelige valuta eller token. Har vi andre muligheder?

Det viser sig, at vi gør. Vi kan have en lukket liste over tilladte minearbejdere, som identificerer sig selv ved at underskrive de blokke, de opretter. Regler om distribueret konsensus (eller "minediversitet", som vi kalder det multikæde) giver en anden måde at forhindre mindretalskontrol af blockchain, så længe du kan acceptere, at minearbejdere er forhåndsgodkendt. For bitcoin er dette selvfølgelig ikke acceptabelt, fordi en del af pointen er at tillade anonym minedrift, så der er ingen måde at censurere transaktioner centralt. Men hvis vi f.eks. havde et stærkt reguleret finansielt system, hvor bitcoins model var uanvendelig, kunne vi måske alligevel acceptere en forhåndsgodkendt liste over minearbejdere? Hvis vi fik nok af dem og spredte dem godt nok mellem institutionerne og havde juridiske kontrakter med dem alle, er det så sandsynligt, at de vil slå sig sammen og underminere det netværk, de er afhængige af, når det vil bringe dem i fængsel?

Epilog

Jeg håber, jeg har demonstreret, at blockchains uden tokens har nogle nyttige applikationer, selvom disse er meget forskellige fra bitcoin blockchain. Ikke desto mindre er der et spørgsmål tilbage:

Er disse tilladte, token-fri delte hovedbogssystemer virkelig værdige til navnet "blockchain"?

Det korte svar er: hvem bekymrer sig? Det er sjældent værd at skændes om ordenes betydning, for det er der intet rigtigt svar.

Men for at gå lidt dybere, lad os sige, at jeg accepterer præmissen om, at bitcoin blockchain er den arketypiske blockchain. I så fald bør vi i virkeligheden spørge:

Ligner disse delte hovedbøger nok til bitcoin til at fortjene navnet "blockchain"?

Min egen personlige opfattelse her er Ja. Fordi de deler et stort antal tekniske ligheder, selvom de adskiller sig i tilladelsesmodellen og økonomiske incitamenter. Og vigtigst af alt, fordi de begge genererer konsensus i en distribueret database via en kæde af blokke.

Tak for læsning.

Du kan følg mig på Twitter her. Se også: Levering versus betaling på en blockchain.

Her er et par andre stykker, der er værd at læse om dette emne Piotr Piasecki , Gravede Campbell.