Private blockchains er mere end “bare” delte databaser

Hvorfor blockchain-modstandere mangler pointen

Og sådan fortsætter det. Fra Populære opslag til foragtelige tweets til forudsigelser om fremtiden, verden og dens mor står i kø for at kaste tomater på private blockchains, før selv at forstå, hvad de er.

At sige, at en privat blockchain kun er en delt database, er som at sige, at HTML og HTTP "bare" er distribueret hypertekst. Det er forkert på to måder. For det første den semantiske: private blockchains er en teknologi, der muliggør delte databaser, som penne muliggør skrivning og HTML/HTTP aktiverer distribueret hypertekst. Bitcoin blockchain og dens primære anvendelse kan ikke meningsfuldt adskilles, fordi den ene ikke kunne eksistere uden den anden. Men denne ækvivalens gælder slet ikke for private blockchains.

Den anden fejl er brugen af ​​ordet "bare". Lige? Var HTML og HTTP lige en måde at lave distribueret hypertekst på? Hypertekst var opfundet årtier tidligere, så er disse teknologier en mindre fodnote i computerhistorien? Åh, men lad mig tælle de måder, hvorpå de fortjente deres plads: (a) en simpel markup sprog at enhver lægmand kunne lære, (b) a hierarkisk adresseringsskema der fungerer både med TCP/IP og vores konceptuelle model for sted, (c) a simpel protokol for statsfri hentning af indhold, og (d) begge dele kunde , server software, der bragte det hele til live. Vi kan lige så godt sige, at Newton kun var en videnskabsmand og Dostojevskij bare en forfatter.

Så lad os gøre dette helt klart: Ja, private blockchains er bare en måde at dele en database på. Men de muliggør en ny type delt database, med enorme konsekvenser for den finansielle verden og videre. Og hvis du er villig til at læse videre, vil jeg fortælle dig præcis hvorfor.

Hvad er en database?

En database er et lager af struktureret information, organiseret i tabeller. Du kan tænke på det som en samling af et eller flere Excel-regneark, som eventuelt kan linkes sammen. Hver tabel indeholder information om et sæt af enheder af en bestemt type, med en enhed pr. række. Hver tabel har også en eller flere kolonner, som beskriver forskellige aspekter af disse enheder. For eksempel kan tabellen for WidgetCo's interne personalekartotek have kolonner for medarbejder-id, fornavn, efternavn, afdeling, internt telefonnummer og værelsesnummer.

En af de vigtige måder, hvorpå databaser går ud over regneark, er, at de indeholder regler om de data, der er gemt indeni. Disse regler er med til at sikre, at oplysningerne forbliver fornuftige og konsistente til gavn for hele organisationen. I dagens mest populære databaser, har reglerne en række almindelige former:

• databaseskema definerer, hvilken slags information der er tilladt i hver kolonne. For eksempel skal telefonnummeret indeholde 4 cifre og må ikke stå tomt ("null").
• Unikke nøgler som angiver, at en bestemt kolonne (f.eks. medarbejder-id) skal have en forskellig værdi i hver række.
• Tjek begrænsninger som håndhæver relationer mellem kolonneværdierne i hver række. Hvis afdelingen for eksempel er "Indkøb", skal lokalenummeret starte med en 3 eller 4.
• Udenlandske nøgler som håndhæver relationer mellem tabeller. For eksempel, hvis databasen indeholder en anden tabel, der bruges til løn, kan der være en regel om, at hvert medarbejder-id i løntabellen også skal eksistere i personalekartoteket.

En transaktion er en samling af ændringer til en database, der accepteres eller afvises som helhed. Hver gang en transaktion ændrer databasen, sikrer softwaren, at databasens regler følges. Hvis en del af en transaktion overtræder en af ​​disse regler, vil hele transaktionen blive afvist med en tilsvarende fejl.

Der er andre mere esoteriske regeltyper, jeg kunne nævne, men de har alle én ting til fælles. De svarer på spørgsmålet: Er databasen i en gyldig tilstand? Med andre ord fungerer de som en begrænsning for databasens indhold når det ses på et enkelt tidspunkt. Og dette fungerer fint for en database, der sidder i en enkelt organisation, fordi begrænsningernes hovedopgave er at forhindre programmørfejl. Hvis en af ​​WidgetCo's interne applikationer forsøgte at indsætte et 3-cifret telefonnummer i biblioteket, ville det ikke være på grund af ondskab, men snarere en fejl i udviklerens tænkning eller kode. En databases evne til at fange disse fejl er uden tvivl praktisk og hjælper med at forhindre, at dårlig information udbredes inden for en organisation, men det løser ikke tillidsproblemer. (Begrænsninger kan også hjælpe med at forenkle applikationslogikken, for eksempel via udenlandsk nøgle kaskade or på-duplikerede klausuler, men disse er stadig kun måder at hjælpe udviklere på.)

Database deling

Lad os nu tænke på, hvordan WidgetCos interne personalekartotek kan deles med omverdenen. I mange tilfælde er der ingen problemer med at yde delt læsning adgang. Biblioteket kan eksporteres til en tekstfil og e-mailes til kunder og leverandører. Det kan lægges på internettet, ligesom denne. Det kan endda få en API for at tillade søgning med ekstern kode. Delt læsning er en teknisk doddle, et spørgsmål om at beslutte, hvem der kan se hvad.

Men tingene begynder at blive mere klistrede, når vi tænker os om delt skriv. Hvad hvis WidgetCo vil have en ekstern enhed til ændre dens database? Måske bliver telefonerne erstattet af PhoneCo, som så opdaterer telefonnumrene i personalekartoteket. I dette tilfælde vil WidgetCo oprette en ny "konto", som PhoneCo kan bruge. I modsætning til konti til WidgetCo's interne brug, har PhoneCo's konto kun tilladelse til at ændre telefonnummerkolonnen og aldrig tilføje eller slette rækker. Alle PhoneCos transaktioner behandles af WidgetCos databasesystem, som nu anvender to typer begrænsninger:

• Globale regler, der gælder for alle databasebrugere. For eksempel kan telefonselskabet ikke ændre et nummer til kun at indeholde 3 cifre, og det kan ingen andre heller.
• Regler pr. konto, der begrænser, hvad PhoneCo har tilladelse til at gøre, og i dette tilfælde ændres kun telefonnummerkolonnen i eksisterende rækker.

Så langt så godt. Vi har en fælles skrivedatabase. Det virker, fordi WidgetCo står for databasen, og telefonselskabet får adgang i kraft af WidgetCos gode ynde. Hvis PhoneCo begyndte at indstille telefonnumre tilfældigt, kan WidgetCo lukke deres adgang, opsige deres kontrakt og gendanne nogle gamle data fra en sikkerhedskopi. Og hvis WidgetCo begyndte at opføre sig dårligt, f.eks. ved at vende de nye telefonnumre, som PhoneCo indtastede, ville det være fuldstændig meningsløst, da det ville kun skade WidgetCo selv. Telefonselskabet ville betragte WidgetCo for at være en ejendommelig kunde, men ikke særlig pleje, så længe de betalte deres regning til tiden.

Men lad os nu se, hvad der sker, hvis to eller flere parter ønsker at dele en database, som (a) ingen af ​​parterne kontrollerer, (b) kan skrives til af enhver part, og (c) kan stoles på af alle. For at gøre tingene værre, lad os sige, at disse parter har forskellige incitamenter, ikke stoler på hinanden og måske endda er hårde konkurrenter. I dette tilfælde har løsningen altid været den samme: indføre en betroet mellemmand. Denne mellemmand administrerer en database centralt, leverer konti til alle parter og sikrer, at alle operationer er tilladt i henhold til et kendt sæt regler. I mange tilfælde, især økonomiske, bevarer hver part stadig sin egen kopi af dataene, så alle bruger meget tid på at kontrollere det deres databaser er enige.

Det hele bliver ret rodet og besværligt. Men hvis vi taler om en delt skrivedatabase i et miljø med begrænset tillid, er der i øjeblikket ikke noget alternativ. Det er en af ​​hovedårsagerne til, at finansielle transaktioner går igennem centrale clearinghuse, hvorfor du bruger Google Kalender selv i en lille arbejdsgruppe, og hvorfor det crowd-sourcede vidunder det er Wikipedia tilbringer millioner af dollars på hosting. Selv som internettets brugergrænseflade flytter til klientsiden, fortsætter centraliserede servere med at gemme de data, som disse grænseflader er afhængige af.

Rigtig delt skriv

Så lad os sige, at vi ønskede at tillade en database at blive delt, i skrivende forstanduden en central myndighed. For eksempel ønsker flere konkurrerende virksomheder at opretholde en fælles personalekartotek til gavn for deres fælles kunder. Hvordan kan det egentlig se ud? Nå, det ville kræve en række ting:

• Et robust peer-to-peer-netværk, der tillader transaktioner at blive oprettet af enhver part og hurtigt udbredes til alle tilsluttede noder.
• En måde at identificere konflikter mellem transaktioner og løse dem automatisk.
• En synkroniseringsteknologi, der sikrer, at alle peers konvergerer på en identisk kopi af databasen.
• En metode til at mærke forskellige stykker information som tilhørende forskellige deltagere og håndhæve denne form for dataejerskab uden en central myndighed.
• Et paradigme til at udtrykke begrænsninger for, hvilke operationer der er tilladt, f.eks. for at forhindre én virksomhed i at puste telefonbogen op med fiktive poster.

Puha. Det er en svær liste lige der, og den understøttes simpelthen ikke af nutidens hyldedatabaser. Nuværende peer-to-peer replikeringsteknologi er klodset og har en kompleks tilgang til konfliktløsning. De databaser, der understøtter rækkebaseret sikkerhed stadig kræve en central myndighed til at håndhæve det. Og standardbegrænsninger på databaseniveau som unikke nøgler og kontrolbegrænsninger kan ikke beskytte en database mod ondsindede ændringer. Den nederste linje er denne:

Vi har brug for en hel masse nye ting, for at delte skrivedatabaser kan fungere, og det sker bare, at blockchains leverer dem.

Jeg vil ikke gå for meget i detaljer om hvordan blockchains gør disse ting, fordi jeg har dækket meget af det før. Nogle nøgleelementer omfatter regelmæssig peer-to-peer teknikker, gruppering transaktioner i blokke, en vej kryptografiske hash-funktioner, et flerparti konsensusalgoritme, fordelt multiversion samtidighedskontrol og tilladelser pr. række baseret på public key kryptografi. En lang liste af gamle ideer kombineret på en ny måde. HTML/HTTP, hvis du vil.

Ud over alle disse kræver delte skrivedatabaser en helt ny type regel, at begrænse de transformationer, som en transaktion kan udføre. Dette er en absolut nøgleinnovation og gør hele forskellen, hvis vi deler en database mellem ikke-tillidsfulde enheder. Disse typer regler kan udtrykkes som bitcoin-stil transaktionsbegrænsninger eller Ethereum-stil håndhævet lagrede procedurer ("smarte kontrakter"), som hver især har fordele og ulemper. Måske er der andre bedre måder, der venter på at blive opdaget. Men de deler alle egenskaben ved at binde sammen databasens tilstand før og efter en transaktion finder sted. Med andre ord svarer de på spørgsmålet: Var det en gyldig transaktion? Dette er fundamentalt anderledes end at spørge, om databasen er gyldig på et enkelt tidspunkt.

Hvis du spekulerer på, om denne type database har nyttige applikationer fra den virkelige verden, så er det et rimeligt spørgsmål. Men du kan måske bemærke den intense interesse for private blockchains fra mindst én sektor, på grund af deres potentiale for at forenkle processer og reducere omkostninger og forsinkelser. Finansielle institutioner er tunge brugere af nutidens databaseplatforme, og disse platforme muliggør ikke et delt skrivescenarie. Det er det, bankerne leder efter.

Dette problem og dets løsning har absolut intet at gøre med bitcoin og ideen om censurfri penge. Faktisk er den eneste forbindelse til bitcoin teknisk lighed mellem bitcoin blockchain og hvordan nogle af disse private blockchains er implementeret i dag. En vigtig forskel er, at private blockchains ikke behøver Bevis for arbejde minedrift, da blokke er skabt af et lukket sæt af identificerede deltagere. Over tid kan de to verdener meget vel adskille sig yderligere, fordi deres krav er helt forskellige. Uanset om du kan lide finansiel regulering eller ej, er den simple kendsgerning, at private blockchains potentielt er nyttige i en reguleret verden, hvorimod for nu i det mindste, offentlige blockchains er ikke.

Hvis jeg må slutte med en analogi, FN Erklæring om folkerettens principper fortæller ikke lande, at de kan holde et hvilket som helst territorium, de vil, så længe det er omgivet af et tydeligt markeret hegn. Snarere hedder det, at "Ingen territorial erhvervelse som følge af truslen eller brugen af ​​magt skal anerkendes som lovlig". Det er med andre ord en regel om legitimiteten af ændringer, ikke kun af situationer. Og FN-erklæringen, som forekommer os så indlysende nu, var en fuldstændig revolution i international ret. Det betød en verden, der ikke længere var baseret på ensidig magt og autoritet, men en, hvor forskelle kan løses ved gensidig konsensus.

Når det kommer til delte databaser, gør private blockchains nøjagtig det samme.