Privata blockchains är mer än "bara" delade databaser

Varför blockchain-detractors saknar poängen

Och så fortsätter det. Från populära inlägg till föraktliga tweets till förutsägelser om framtiden, världen och dess mor ställer sig upp för att kasta tomater på privata blockchains, innan till och med förstå vad de är.

Att säga att en privat blockchain bara är en delad databas är som att säga att HTML och HTTP är "bara" distribuerad hypertext. Det är fel på två sätt. Först den semantiska: privata blockchains är en teknik som möjliggör delade databaser, som pennor, möjliggör skrivning och HTML / HTTP möjliggör distribuerad hypertext. Bitcoin-blockchainen och dess primära applikation kan inte meningsfullt separeras, eftersom den ena inte kunde existera utan den andra. Men denna ekvivalens gäller inte alls för privata blockchains.

Det andra misstaget är användningen av ordet ”bara”. Bara? Var HTML och HTTP bara ett sätt att göra distribuerad hypertext? Hypertext var uppfann årtionden tidigare, så är dessa tekniker en mindre fotnot i datorhistoriken? Åh men låt mig räkna de sätt på vilka de tjänade sin plats: (a) en enkel markeringsspråk att varje lekperson kan lära sig, (b) a hierarkiskt adresseringsschema som fungerar både med TCP / IP och vår konceptuella platsmodell, (c) a enkelt protokoll för tillståndsfri hämtning av innehåll och (d) båda klient och server programvara som väckte hela saken. Vi kan lika gärna säga att Newton bara var en forskare och Dostojevskij bara en författare.

Så låt oss göra detta helt klart: Ja, privata blockchains är bara ett sätt att dela en databas. Men de möjliggör en ny typ av delad databas, med enorma konsekvenser för finansvärlden och därefter. Och om du är villig att läsa vidare ska jag berätta exakt varför.

Vad är en databas?

En databas är ett förvar med strukturerad information, organiserad i tabeller. Du kan tänka på det som en samling av ett eller flera Excel-kalkylark, som valfritt kan kopplas ihop. Varje tabell innehåller information om en uppsättning enheter av en viss typ, med en enhet per rad. Varje tabell har också en eller flera kolumner som beskriver olika aspekter av dessa enheter. Till exempel kan tabellen för WidgetCos interna personalkatalog ha kolumner för anställds ID, förnamn, efternamn, avdelning, internt telefonnummer och rumsnummer.

Ett av de viktiga sätten på vilka databaser går utöver kalkylblad är att de innehåller regler om de data som lagras inom. Dessa regler hjälper till att säkerställa att informationen förblir förnuftig och konsekvent till gagn för hela organisationen. I dagens mest populära databaser, reglerna har ett antal vanliga former:

• Smakämnen databas schema definierar vilken typ av information som är tillåten i varje kolumn. Telefonnumret måste till exempel innehålla fyra siffror och kan inte lämnas tomt (“null”).
• Unika nycklar som anger att en viss kolumn (t.ex. anställd-ID) måste ha ett annat värde i varje rad.
• Kontrollera begränsningar som verkställer relationer mellan kolumnvärdena i varje rad. Till exempel, om avdelningen är "Upphandling" måste rumsnumret börja med en 3 eller 4.
• Utländska nycklar som upprätthåller relationer mellan tabeller. Om till exempel databasen innehåller en annan tabell som används för lönelista kan det finnas en regel att varje anställds ID i lönstabellen också måste finnas i personalkatalogen.

En transaktion är en samling ändringar i en databas som accepteras eller avvisas i sin helhet. Varje gång en transaktion ändrar databasen ser programvaran till att databasens regler följs. Om någon del av en transaktion bryter mot en av dessa regler avvisas hela transaktionen med ett motsvarande fel.

Det finns andra mer esoteriska regeltyper som jag kunde lista, men de har alla en sak gemensamt. De svarar på frågan: Är databasen i giltigt tillstånd? Med andra ord fungerar de som en begränsning för databasens innehåll när den ses på en enda tidpunkt. Och detta fungerar bra för en databas som sitter i en enda organisation, för det huvudsakliga jobbet med begränsningarna är att förhindra programmeringsfel. Om en av WidgetCos interna applikationer försökte sätta in ett 3-siffrigt telefonnummer i katalogen skulle detta inte bero på ondska, utan snarare ett fel i utvecklarens tänkande eller kod. En databas förmåga att fånga dessa misstag är utan tvekan praktisk och hjälper till att förhindra dålig information som sprids i en organisation, men det löser inte problem med förtroende. (Begränsningar kan också hjälpa till att förenkla applikationslogiken, till exempel via utländsk nyckelkaskad or klausuler på duplikat, men det är fortfarande bara sätt att hjälpa utvecklare.)

Databasdelning

Låt oss nu tänka på hur WidgetCos interna personalkatalog kan delas med omvärlden. I många fall finns det inga problem att tillhandahålla delad läsning tillgång. Katalogen kan exporteras till en textfil och e-postas till kunder och leverantörer. Det kan publiceras på Internet, precis som denna. Det kan till och med ges ett API för att tillåta sökning med extern kod. Delad läsning är en teknisk doddle, en fråga om att avgöra vem som kan se vad.

Men saker börjar bli klibbigare när vi tänker på delad skrivning. Vad händer om WidgetCo vill att en extern enhet ska göra det modifiera dess databas? Kanske ersätts telefonerna av PhoneCo, som sedan kommer att uppdatera telefonnumren i personalkatalogen. I det här fallet skulle WidgetCo skapa ett nytt "konto" som PhoneCo kan använda. Till skillnad från konton för WidgetCos interna användning är PhoneCos konto endast tillåtet att ändra telefonnummerkolumnen och aldrig lägga till eller ta bort rader. Alla PhoneCos transaktioner behandlas av WidgetCos databassystem, som nu tillämpar två typer av begränsningar:

• Globala regler som gäller för alla databasanvändare. Till exempel kan inte telefonföretaget ändra ett nummer för att bara innehålla tre siffror, och inte heller någon annan.
• Regler per konto som begränsar vad PhoneCo är tillåtet att göra, i det här fallet ändrar endast telefonnummerkolumnen för befintliga rader.

Än så länge är allt bra. Vi har en delad skrivdatabas. Det fungerar eftersom WidgetCo ansvarar för databasen och telefonföretaget får åtkomst genom WidgetCos goda nåd. Om PhoneCo började ställa in telefonnummer slumpmässigt kan WidgetCo stänga av deras åtkomst, säga upp avtalet och återställa gamla data från en säkerhetskopia. Och om WidgetCo började inte fungera, säg genom att vända de nya telefonnumren som anges av PhoneCo, det skulle vara helt meningslöst, eftersom det skulle bara skada WidgetCo själva. Telefonföretaget skulle anse WidgetCo som en speciell kund men inte särskilt vård, så länge de betalade sin faktura i tid.

Men nu ska vi se vad som händer om två eller flera parter vill dela en databas som (a) ingen av parterna kontrollerar, (b) kan skrivas till av någon part, och (c) kan lita på av alla. För att göra saken värre, låt oss säga att dessa parter har olika incitament, inte litar på varandra och kan till och med vara hårda konkurrenter. I detta fall har lösningen alltid varit densamma: introducera en betrodd mellanhand. Denna mellanhand hanterar en databas centralt, tillhandahåller konton till alla parter och ser till att alla operationer är tillåtna enligt en känd uppsättning regler. I många fall, särskilt ekonomiskt, behåller alla partier fortfarande sin egen kopia av uppgifterna, så alla spenderar mycket tid på att kontrollera att deras databaser är överens.

Allt blir ganska rörigt och klumpigt. Men om vi pratar om a delad skrivdatabas i en miljö med begränsat förtroende, det finns för närvarande inget alternativ. Det är en av de främsta orsakerna till att finansiella transaktioner går igenom centrala clearinghus, varför du använder Google Kalender till och med i en liten arbetsgrupp, och varför det publikundraserade undrar det är wikipedia spends miljoner dollar på värd. Även som användargränssnitt på webben flyttar sig till klientsidan, centraliserade servrar fortsätter att lagra de data som dessa gränssnitt förlitar sig på.

Riktigt delat skriv

Så låt oss säga att vi ville låta en databas delas, i skrivbar mening, utan en central myndighet. Till exempel vill flera konkurrerande företag upprätthålla en gemensam personalkatalog till förmån för deras ömsesidiga kunder. Hur kan det verkligen se ut? Det skulle behöva ett antal saker:

• Ett robust peer-to-peer-nätverk som gör det möjligt att skapa transaktioner av alla parter och snabbt spridas till alla anslutna noder.
• Ett sätt att identifiera konflikter mellan transaktioner och lösa dem automatiskt.
• En synkroniseringsteknik som säkerställer att alla kamrater konvergerar på en identisk kopia av databasen.
• En metod för att märka olika informationsdelar som tillhör olika deltagare och säkerställa denna form av dataägande utan en central myndighet.
• Ett paradigm för att uttrycka begränsningar för vilka verksamheter som är tillåtna, t.ex. för att förhindra att ett företag blåser upp katalogen med fiktiva poster.

Puh. Det är en tuff lista just där, och den stöds helt enkelt inte av dagens databaser. Nuvarande peer-to-peer replikationsteknik är klumpig och har en komplex inställning till konfliktlösning. De databaser som stöder radbaserad säkerhet kräver fortfarande en central myndighet för att verkställa den. Och standardbegränsningar på databasnivå som unika nycklar och kontrollbegränsningar kan inte skydda en databas mot skadliga modifieringar. Den sista raden är detta:

Vi behöver en hel massa nya saker för att delade skrivdatabaser ska fungera, och det händer bara så att blockchains ger dem.

Jag kommer inte gå in på för mycket detaljer om hur blockchains gör dessa saker, för det har jag gjort täckte mycket av det tidigare. Vissa viktiga element inkluderar vanliga peer-to-peer tekniker, gruppering transaktioner i block, Enkel kryptografiska hashfunktioner, ett flerparti konsensusalgoritm, distribuerad multiversion samtidighetskontroll och per-rad behörigheter baserat på public key kryptografi. En lång lista med gamla idéer kombinerade på ett nytt sätt. HTML / HTTP, om du vill.

Utöver alla dessa kräver delade skrivdatabaser en helt ny typ av regel, till begränsa de transformationer som en transaktion kan utföra. Det här är en absolut nyckel och gör skillnaden om vi delar en databas mellan icke-förtroendeenheter. Dessa typer av regler kan uttryckas som transaktionsbegränsningar i bitcoin-stil eller genom att Ethereum-stil verkställs Lagrade procedurer (”Smarta kontrakt”), som alla har fördelar och nackdelar. Kanske finns det andra bättre sätt som väntar på att upptäckas. Men de delar alla egenskapen att knyta samman databasens tillstånd före och efter en transaktion äger rum. Med andra ord svarar de på frågan: Var det en giltig transaktion? Detta skiljer sig i grunden från att fråga om databasen är giltig vid en enda tidpunkt.

Om du undrar om den här typen av databaser har användbara applikationer i verkligheten, det är väl en rättvis fråga. Men du kan notera det intensiva intresset för privata blockchains från åtminstone en sektor, på grund av deras potential att förenkla processer och minska kostnader och förseningar. Finansinstitut är tunga användare av dagens databasplattformar, och dessa plattformar möjliggör inte ett delat skrivscenario. Det här är vad bankerna letar efter.

Detta problem och dess lösning har absolut ingenting att göra med bitcoin och idén om censurfria pengar. Faktum är att den enda anslutningen till bitcoin är teknisk likheten mellan bitcoin blockchain och hur några av dessa privata blockchains är implementeras idag. En viktig skillnad är att privata blockchains inte behöver bevis på arbetet gruvdrift, eftersom block skapas av en sluten uppsättning identifierade deltagare. Med tiden kan de två världarna väl avvika ytterligare, eftersom deras krav är helt olika. Oavsett om du gillar finansiell reglering eller inte, är det enkla faktumet att privata blockchains är potentiellt användbara i en reglerad värld, medan för närvarande åtminstone, offentliga blockchains är det inte.

Om jag kan avsluta med en analogi, FN Förklaring om principerna för internationell rätt säger inte länderna att de kan hålla något territorium de vill, så länge det är omgivet av ett tydligt markerat staket. Den säger snarare att "Inget territoriellt förvärv som härrör från hot eller användning av våld ska erkännas som lagligt". Med andra ord, det är en regel när det gäller legitimitet förändringar, inte bara av situationer. Och FN-förklaringen, som verkar så uppenbar för oss nu, var en fullständig revolution i internationell rätt. Det innebar en värld som inte längre bygger på ensidig makt och auktoritet, men en där skillnader kan lösas genom ömsesidigt samförstånd.

När det gäller delade databaser gör privata blockchains exakt samma sak.