Avslutter debatten om bitcoin vs blockchain

Er det noen verdi i en blockchain uten cryptocurrency?

Debatten har pågått en stund, men den siste måneden har det vært en alvorlig uptick. Spørsmålet som stilles er:

Er det noen verdi i en blockchain uten cryptocurrency? Og kan disse “tokenless shared ledger” i det hele tatt kalles blockchains?

Så jeg har lest Baileys artikkel, så på Tims video, les dette Nasdaq-innlegget, fulgte Richard hver ord, og hadde til og med min egen god humør debatt (se kommentarer) med Counterparty-stiftelsens Chris DeRose. Så mye varm luft.

Én ting Chris gjør godt er å koke det ned til spørsmålet: er blockchain en økonomisk eller en datavitenskapelig innovasjon? Betydningen er at hvis blockchains er en rent økonomisk innovasjon, er det ikke noe poeng å blockchains uten cryptocururrency. Så la meg oppgi min stilling i starten:

Bitcoin-blockchainen var begge en økonomisk og en datavitenskapelig innovasjon.

Jeg lar "innovasjon" her inkludere en ny kombinasjon av eksisterende teknikker, snarere enn noe som ikke har noe presedens overhodet. Denne definisjonen gjør at internett kan betraktes som en innovasjon, selv om det ikke gjorde mer enn å kombinere hypertekst med en vri på noen eksisterende internettprotokoller. Hvis du vil ta i bruk en strengere definisjon av innovasjon, vær min gjest, men du vil bli overrasket over hvor få ekte "innovasjoner" som er igjen. Å omskrive Læreren, det er lite nytt under solen.

For å være presis, påstår jeg det blockchains uten et symbol tjener et formål, men det er en ulikt formål sammenlignet med den opprinnelige bitcoin blockchain. Kryptohoder ler av symbolfrie blockchains fordi de ikke kan gi sensurmotstand og desentralisert sikkerhet gjennom proof-of-work. Fintech-hoder ler av offentlige blockchains fordi de er trege, dyre og uegnet for tradisjonell finans. Vel, fortsett å le alle sammen, for jeg tror dere har begge rett.

Jeg skal argumentere for at tokenfrie blokkeringer er nyttige for å holde desentraliserte databaser synkronisert, selv i en enkelt organisasjon der det er full tillit. Og så får vi se hvilke andre funksjoner blokkeringer tilbyr, noe som gjør dem egnet for å skape konsensus for spesifikke typer transaksjoner mellom organisasjoner, der det bare er begrenset og ufullkommen tillit.

Dessverre, for å følge argumentet, må du geek ut med meg på bitcoin transaksjonsmodellen, database multiversion concurrency control (MVCC) og problemet med konfliktløsning i multimaster databasereplikasjon. Jeg skal gjøre mitt beste for å holde meg til engelsk, men likevel, dette er tekniske ting, og det unngår det ikke.

Bitcoin sin transaksjonsmodell

Transaksjonsmodellen bitcoin er enkel, men kraftig. Hver bitcoin-transaksjon har et sett med innganger og et sett med utganger. Hver inngang "bruker" en utgang fra en tidligere transaksjon. Alle bitcoin i en transaksjons innganger strømmer inn i den transaksjonen og distribueres over dens utganger i henhold til mengdene som er skrevet innenfor. På denne måten danner transaksjoner en flerveis tilkoblet kjede som avsluttes ved "Coinbase" -transaksjoner der nye bitcoins opprettes.

Bitcoin har en rekke tilleggsregler som håndheves av hver node i nettverket:

• Hver inngang i en transaksjon må bevise at den har rett til å bruke den tidligere utgangen den er koblet til. Denne retten er begrenset av forhold kodet i forrige produksjon.
• En transaksjon må ha tilstrekkelig total bitcoin i sine innspill til å dekke det totale som er skrevet i sine utganger. De eneste unntakene er Coinbase-transaksjoner som skaper nye valutaenheter.
• Hver utgang kan bare brukes én gang, med andre ord, den kan bare kobles til en inngang i en påfølgende transaksjon.

På grunn av denne siste regelen krever nettverket en mekanisme for å oppnå enighet om hvilke transaksjoner som er gyldige, og dette gjør blockchain. Nærmere bestemt:

Hvis to transaksjoner prøver å bruke samme produksjon, vil bare en av disse transaksjonene til slutt aksepteres. En blockchain fungerer som en samlet mekanisme for å oppdage og forhindre disse konfliktene på tvers av nettverket.

Blockchain er strukturert som en serie koblede blokker, der hver blokk inneholder et sett av transaksjoner som ikke er i konflikt med hverandre eller med tidligere blokker, fra den første blokken som ble opprettet i 2009. I teorien kan kjeden inneholde en serie med individuelle transaksjoner, men ved å gruppere transaksjoner i blokker, får vi en rekke effektiviteter som gjør ordningen mer praktisk.

Så hva er hensikten med et cryptocurrency i alt dette? Det kommer til spørsmålet om hvem som bestemmer over blokkene som danner kjeden. Bitcoin er desentralisert og har ingen autoritet som kan ta denne beslutningen, så den trenger å finne en annen måte å nå enighet om.

Vi vil gjerne bruke en demokratisk tilnærming, der noder i nettverket stemmer om blokker, og flertallet vinner. Dessverre, som enhver avstemning på Internett kan demonstrere, er ikke representativt demokrati mulig på nettet på grunn av problemet med etterligning (også kjent som en Sybil angrep). En person kan ta over en million datamaskiner og bestemme hvordan de stemmer, og dermed ta kontroll over nettverkskonsensusen. Ingen andre vil engang vite at dette har skjedd.

For å løse dette gjør bitcoin det bevisst vanskelig å legge til en blokk i kjeden, via en prosess som kalles "gruvedrift". For å lage en blokk må du løse et vanskelig, men meningsløst matematisk problem som krever mye beregning (og derfor strøm og penger). Du trenger også litt hell, siden du er i konkurranse med mange andre gruvearbeidere rundt om i verden. Du kan ikke komme deg for lenge ved å kjøpe en kraftigere gruvedrift, fordi nettverket regelmessig justerer problemets vanskeligheter for å holde en jevn global hastighet på en blokk per 10 minutter.

Hvis det er så vanskelig og kostbart å lage en blokk, hvorfor skulle noen bry seg? Svaret er i blokkbelønningen. Den vellykkede gruvearbeideren til en blokk kontrollerer myntbasetransaksjonen som tildeler dem 25 bitcoins (denne summen halveres hvert fjerde år). De kan selge disse bitcoinsene på det åpne markedet for $ 7,000 (til dagens pris), betale strømregningen og forhåpentligvis få litt fortjeneste. Gruvearbeidere samler også inn litt ekstra fra avgifter som er knyttet til transaksjoner, men foreløpig spiller disse avgiftene en mindre rolle.

Så bitcoin genererer konsensus via bevis på arbeid, og kjernen i bitcoin-heads-argumentet er dette: Uten cryptocurrency er det ingen måte å incentivere desentralisert gruvedrift av blokker. Derfor er det ingen måte å sikre en åpen blockchain mot etterligningsangrep. Derfor kan hvem som helst monopolisere nettverkets enighet og gjøre det hele ubrukelig. Jeg vil ikke krangle med noe av det.

Multiversion samtidighetskontroll

I mellomtiden vil jeg snakke om noe som kan virke helt uten tilknytning.

En database er et lager med strukturert informasjon, gruppert i regnearklignende enheter som kalles tabeller. Et enkelt eksempel på en slik tabell er en liste over bankkontoer, der hver rad inneholder et kontonummer sammen med saldoen på den kontoen. La oss si at kontoen din starter dagen med en saldo på $ 900. I dag er en automatisk pantelån på $ 750 planlagt, og du må også ta ut $ 400 fra en minibank. Dessverre har du ikke kassekreditt, så en av disse operasjonene er satt opp til å mislykkes.

Prosessene for pantelån og uttak av minibank kjører på separate systemer, som begge får tilgang til denne kontodatabasen. La oss si at hver prosess fungerer ved å lese saldoen på kontoen din, kontrollere at den er tilstrekkelig for operasjonen, starte denne operasjonen, bekrefte at operasjonen er fullført, beregne den nye saldoen og deretter til slutt skrive den inn i databasen.

Så lenge pantebetalingen og utbetaling av minibank ikke overlapper hverandre, fungerer denne logikken bra. Den første operasjonen utføres vellykket, og den andre avbrytes fordi kontoen din ikke har nok penger. Avhengig av ordren, får du en sint telefonsamtale fra banken eller en uhøflig melding på minibankskjermen.

Men hva skjer hvis de to prosessene begynner å starte samtidig? I dette tilfellet vil hver lese kontoens saldo og anser det som tilstrekkelig til å fortsette. Når pantebetalingen er fullført, beregnes den nye saldoen til $ 150 og skrives til databasen. Når minibankuttaket er fullført, vil den nye saldoen din på $ 500 bli skrevet på lignende måte. En av disse skriveoperasjonene kommer til å overstyre den andre, og avhengig av lykken, vil du motta en bonus på $ 750 eller $ 400 fra banken din. Ingen tvil om at du snart vil lære deg å stille inn minibankbesøk for pantedag.

Dette skjer selvfølgelig ikke i virkeligheten, på grunn av en databaseteknologi som heter samtidig kontroll. Samtidig kontroll holder dataene våre (spesielt økonomiske) tilregnelige og sikre, og de kommer i mange former. Men alle deler prinsippet om at databaseoperasjoner er gruppert i “transaksjoner”, som behandles atomisk, noe som betyr at de lykkes eller mislykkes som en helhet. Samtidig bevarer konsistensen ved å låse eller fryse deler av en database mens de er i bruk av en transaksjon, for å forhindre at andre transaksjoner fungerer på samme informasjon på en motstridende måte.

Hvis vi ikke trengte å kjøre transaksjoner parallelt, kunne vi låse hele databasen for hele varigheten av hver enkelt transaksjon. Dette er imidlertid ikke praktisk i de fleste virkelige applikasjoner. En god ordning for samtidig kontroll tillater parallelle operasjoner ved å låse så lite data som mulig i så kort tid som mulig. I eksemplet ovenfor vil bare databaseraden som tilsvarer kontoen din bli låst, og bare for det brutt sekundet der en siste kontroll og fradrag fant sted. En motstridende transaksjon som opererer parallelt, må ganske enkelt vente til denne låsen frigjøres.

En populær teknikk for samtidighetskontroll kalles multiversjon samtidighetskontrolleller kort sagt MVCC. I MVCC ser hver transaksjon et konsekvent øyeblikksbilde av dataene på et bestemt tidspunkt, selv om en del av disse dataene er i ferd med å bli oppdatert av en andre samtidig transaksjon. Dette øyeblikksbildeisolasjon eiendom sikrer for eksempel at en uttalelse som viser vår totale saldo på tvers av flere kontoer alltid vil være riktig, selv om noen midler er i ferd med å flytte fra en konto til en annen. En transaksjon vil bare påvirke dataene som blir sett av en annen transaksjon hvis den andre begynner etter at alle den første endringene er blitt brukt.

Bak kulissene fungerer MVCC ved å la flere versjoner av en rad opprettholdes samtidig, sammen med en tidsstempel som representerer hver versjons dato for siste endring. Endring av en databaserad i MVCC markerer den gjeldende versjonen av den raden for sletting, mens modifikasjonen brukes på en kopi av den raden med et oppdatert tidsstempel. Fra perspektivet til databasens lagringslag er det ingen ting som endrer en rad på plass. Hver transaksjon vet nøyaktig når den startet, og ser bare versjoner av rader hvis tidsstempel er forut for den tiden. Gamle versjoner av rader kan fjernes fra lagring når det ikke er noen pågående transaksjoner som kan trenge tilgang til dem.

Avgjørende for våre formål her forhindrer MVCC konflikter mellom skriveoperasjoner. Nærmere bestemt:

Hvis to transaksjoner prøver å slette den samme radversjonen, vil bare en av disse transaksjonene til slutt aksepteres. Multiversion samtidighetskontroll fungerer som en enhetlig mekanisme for å oppdage og forhindre disse konfliktene i en database.

Ring noen bjeller? Det er enda et stykke bakgrunn vi trenger å diskutere.

Replikering av flere master databaser

La oss nå snakke om databasereplikasjon, der en database finnes i flere eksemplarer. Det er en rekke gode grunner til å gjenskape en database, for eksempel:

• For å øke påliteligheten, slik at hvis en kopi av databasen går tapt (f.eks. På grunn av en diskfeil), kan vi øyeblikkelig bytte til en andre kopi.
• For å øke gjennomstrømningen, hvis volumet av operasjoner går utover kapasiteten til en enkelt databaseserver.
• For å redusere forsinkelsen, slik at prosesser som kjører på Singapore-kontoret ikke trenger å vente på svar fra en database som sitter i Toronto.

Når det kommer til lesing data fra databaser, er replikering en ideell teknikk, fordi alle kopiene inneholder den samme informasjonen. Imidlertid blir ting klistrende når det gjelder skriveoperasjoner, fordi vi må bestemme hvor disse skriveoperasjonene skal utføres, og hvordan de blir overført til andre kopier av databasen.

Det vanligste svaret er å bruke master-slave-replikering, der en enkelt database ("master") blir ansett som autoritativ. Eventuelle endringer i dataene utføres utelukkende på masteren og sildrer deretter ned til alle de andre "slave" -databasene via en transaksjonslogg. Dette holder alle databaskopiene (mer eller mindre) synkroniserte umiddelbart.

Dessverre, hvis skriveoperasjoner er hyppige, fører master-slave-replikering oss tilbake til problemet som replikering ble designet for å løse. Masterdatabasen blir en flaskehals når det gjelder pålitelighet, gjennomstrømning og ventetid, siden hver skriveoperasjon utføres på den alene.

En mer kompleks strategi kalles multi-master replikering, der skriving kan utføres på hvilken som helst av databaskopiene, i stedet for på en enkelt master. I dette tilfellet deler kopiene oppdateringer med hverandre på en peer-to-peer-måte for å forbli synkronisert.

Dette høres enkelt ut i teorien, men multimasterreplikasjon introduserer et nytt problem fordi konflikter kan oppstå. Hva hvis to eksemplarer av en database oppdaterer den samme raden samtidig, og prøver å utveksle disse oppdateringene med hverandre? Begge databasene vil merke at en motstridende oppdatering har funnet sted, og må bruke en viss avtalt strategi for å løse disse konfliktene. Og her blir ting ganske sammensatt - se dokumentene for MySQL, SQL Server or Oracle for noen eksempler på konfliktløsningsstrategier. (Jeg ignorerer synkron eller såkalt “ivrig” multimasterreplikasjon, der alle replikker må forplikte seg til en skriveoperasjon før den kan finne sted, fordi det snur hver kopi av databasen til en flaskehals.)

Så her er all denne bakgrunnen som fører:

Ville det ikke vært fint om vi kunne ha distribuert multiversion samtidighetskontroll, for å forhindre konflikter som forekommer i multi-master replikering?

Vel, ja, jeg forestiller meg at det ville være veldig hyggelig. Og jeg tror at det er nettopp dette blockchains gjør.

Blockchains som distribuert MVCC

La oss kopiere et par setninger som jeg skrev med fet skrift ovenfor:

Hvis to transaksjoner prøver å bruke det samme produksjon, så vil bare en av disse transaksjonene til slutt aksepteres. En blokkjede fungerer som en enhetlig mekanisme for å oppdage og forhindre disse konfliktene på tvers av nettverket.

Hvis to transaksjoner prøver å slette det samme radversjon, vil bare en av disse transaksjonene til slutt aksepteres. Multiversion samtidighetskontroll fungerer som en enhetlig mekanisme for å oppdage og forhindre disse konfliktene i en database.

Disse setningene er identiske bortsett fra de dristige ordene. Så her er hva jeg skal påstå:

En blockchain gir distribuert MVCC (med noen få ekstra bjeller og fløyter).

La oss konkretisere sammenligningen litt lenger. Fra perspektivet til en blockchain-node danner det nåværende settet med ubrukte bitcoin-transaksjonsutganger en database der hver rad er en enkelt ubrukt utgang. Dette ligner databasen over bankkontoer vi beskrev tidligere, med den mindre forskjellen at saldoen på hver konto kan deles over flere rader, som hver er merket med samme kontonummer.

En bitcoin-transaksjon bruker en eller flere av disse utgangene og skaper en eller flere nye utganger som et resultat. Dette er akkurat som en databasetransaksjon som sletter en eller flere radversjoner, og skaper en eller flere nye rader som et resultat (husk at i MVCC at det ikke er noe som endrer en rad på plass). Bitcoin blockchain sørger for at en enkelt produksjon ikke kan brukes av mer enn en transaksjon. Dette tilsvarer å sikre at en enkeltradversjon ikke kan slettes av mer enn én databasetransaksjon.

Nå før vi blir ført bort, hevder jeg ikke at blockchains er en god teknologi til generell bruk for distribuert databasesynkronisering i et fullt pålitelig miljø. Det er mange andre teknologier som Paxos, Raft og To-fase begå som utfører jobben veldig pent. Men jeg tror at blokkjeder har et søtt sted, som kan karakteriseres som applikasjoner der:

• Vi kan akseptere en kort forsinkelse mellom når en transaksjon sannsynligvis blir akseptert og når den definitivt er akseptert. (Denne forsinkelsen kan være noen sekunder snarere enn 10 minutter som i bitcoin.)
• Motstridende transaksjoner skal aldri skje hvis alle er ærlige og systemene deres fungerer som de skal.
• Hver transaksjon endrer bare noen få rader samtidig (ellers vil blockchain-transaksjonene ha et lite antall innganger).
• Størrelsen på hver databaserad er ganske liten (igjen, for å forhindre at våre blockchain-transaksjoner balloner i størrelse).

Alle disse kriteriene oppfylles av økonomiske søknader. Finansverdenen er allerede vant til forsinkelser (opptil 3 dager!) Mellom gjennomføring av en transaksjon og endelig oppgjør. Når det gjelder å forhindre konflikter, har det kontrakter og forskrifter på plass for å oppdage svindel, og konsekvensene kan være alvorlige. Og mengden data involvert i hver transaksjon er ganske liten - tenk på bankkontoeksemplet ovenfor.

Så langt er alt jeg har demonstrert at blokkjeder er enda en synkroniseringsmekanisme for distribuerte databaser. Stor wow. Ting blir bare veldig interessante når vi vurderer tilleggsfunksjonene som blokkeringer gir.

Blockchains utover MVCC

En bitcoin-transaksjon gjør mye mer enn bare å peke på noen tidligere transaksjonsutganger og skape noen nye i stedet. Selv den enkleste bitcoin-transaksjonen tjener to ekstra formål.

For det første inneholder reglene om gyldige transaksjoner noe av applikasjonslogikken for kontodatabasen vår. Husk at den totale mengden bitcoin i inngangen til en transaksjon må dekke den totale mengden i utgangene. Oversatt til databaseapplikasjonslogikk, er dette en regel som sier at databasetransaksjoner (med unntak av myntbaser) ikke har lov til å øke den totale mengden bitcoin i databasen. Denne typen begrensninger går utover vanlig database lagrede prosedyrer fordi det ikke kan omgås under noen omstendigheter.

For det andre, husk at hver bitcoin-transaksjonsutgang koder for forholdene den kan brukes under. For vanlige bitcoin-utganger er denne tilstanden basert på offentlig nøkkelkryptografi. En offentlig adresse er innebygd i utskriften "skript" slik at den bare kan brukes med den private nøkkelen som tilsvarer den offentlige adressen. Hvis vi anser denne utgangen for å være en databaserad, er det vi har en database med tillatelser per rad som er basert på offentlig nøkkelkryptografi. Videre presenterer hver transaksjon et offentlig revidert bevis på at skaperen (e) hadde rett til å slette / endre sine tidligere rader. Dette (tror jeg) er en ekte nyhet innen databaseteknologi.

Og igjen, det skjer slik at begge disse funksjonene er utrolig nyttige for økonomiske applikasjoner. Vi liker det faktum at databasen vår sørger for, på et lavest mulig nivå, at penger ikke kan opprettes ut av det fri. Og vi liker å ha en ubestridelig revisjonsspor som viser at hver transaksjon ble godkjent av innehaveren av midlene den flyttet. Som diskutert i detalj her, vi kan også like å utføre sikre atom-peer-to-peer-utvekslingstransaksjoner (levering mot betaling i økonomisnakk), uten å vite identiteten til motparten vår.

Så hvor er symbolet?

Selvfølgelig er ingenting av dette tilfeldig, fordi bitcoin i seg selv er en vakker finansiell applikasjon. Likevel er ingen av de ovennevnte egenskapene til en blockchain avhengig av symbolet i det hele tatt. Hvis vi endrer skjemaet vårt for "database" slik at hver rad kan representere flere eiendeler, i stedet for blockchainens opprinnelige valuta, så kan vi kvitte oss med den valutaen helt. Dette etterlater oss med en blockchain som en måte å oppnå konsensus og sikkerhet i en peer-to-peer økonomisk søknad om alle typer eiendeler.

Bare ett lite spørsmål: Hvem gjør gruvedriften for å generere denne konsensus? I bitcoin må anonyme gruvearbeidere utføre dyre ubrukelige beregninger, og blir tilskyndet til å gjøre det av blokkbelønningene (og transaksjonsgebyrene) pålydende i blockchainens opprinnelige valuta eller token. Har vi noen andre alternativer?

Det viser seg at vi gjør det. Vi kan ha en lukket liste over tillatte gruvearbeidere, som identifiserer seg ved å signere blokkene de oppretter. Regler om distribuert konsensus (eller "gruvediversitet" som vi kaller det multikate) gi en annen måte å forhindre minoritetskontroll av blockchain, så lenge du kan godta at gruvearbeidere er forhåndsgodkjent. Selvfølgelig for bitcoin er dette ikke akseptabelt, fordi en del av poenget er å tillate anonym gruvedrift, så det er ingen måte å sensurere transaksjoner sentralt. Men hvis vi for eksempel hadde et sterkt regulert finanssystem, hvor bitcoins modell ikke kunne brukes, kunne vi tross alt akseptere en forhåndsgodkjent liste over gruvearbeidere? Hvis vi hadde nok av dem, og spredte dem godt nok mellom institusjoner, og hadde juridiske kontrakter med dem alle, er de virkelig sannsynlig å samle seg og undergrave nettverket de er avhengige av, når de vil lande dem i fengsel?

Epilogue

Jeg håper jeg har demonstrert at blokkjeder uten tokens har noen nyttige applikasjoner, selv om disse er veldig forskjellige fra bitcoin blockchain. Likevel gjenstår ett spørsmål:

Er disse tillatte, symbolfrie delte storbokssystemene virkelig verdige navnet "blockchain"?

Det korte svaret er: hvem bryr seg? Det er sjelden verdt å krangle om betydningen av ord, fordi det er det ikke noe riktig svar.

Men for å gå litt dypere, la oss si at jeg aksepterer forutsetningen om at bitcoin blockchain er den arketypiske blockchain. I så fall er det vi virkelig bør spørre:

Er disse delte hovedbøker lik nok til bitcoin til å fortjene navnet “blockchain”?

Mitt eget personlige syn her er ja. Fordi de deler et stort antall tekniske likheter, selv om de er forskjellige i tillatelsesmodellen og økonomiske insentiver. Og viktigst av alt, fordi de begge genererer konsensus i en distribuert database via en kjede med blokker.

Takk for at du leser.

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

Her er et par andre stykker som er verdt å lese om dette emnet av Piotr Piasecki og Krøll Campbell.