Avsluta debatten om bitcoin vs blockchain

Finns det något värde i en blockchain utan kryptovaluta?

Debatten har pågått ett tag men den senaste månaden har sett en allvarlig uppgång. Frågan som ställs är:

Finns det något värde i en blockchain utan kryptovaluta? Och kan dessa ”tokenless shared reskontrar” alls kallas blockchains?

Så jag har läst Bailey's artikel, betraktade Tims video, läs detta Nasdaq-inlägg, följde Richard varje ordoch hade till och med min egen glada debatt (se kommentarer) med Counterparty-stiftelsens Chris DeRose. Så mycket varm luft.

En sak som Chris gör bra är att koka ner det till frågan: är blockchain en ekonomisk eller datavetenskaplig innovation? Implikationen är att om blockkedjor är en rent ekonomisk innovation, finns det ingen anledning att blockkedjor utan kryptovalutor. Så låt mig ange min position i början:

Bitcoin blockchain var både ekonomiskt och en datavetenskaplig innovation.

Jag tillåter "innovation" här att inkludera en ny kombination av befintliga tekniker, snarare än något som inte har något prejudikat alls. Denna definition gör att internet kan betraktas som en innovation, även om det gjorde lite mer än att kombinera hypertext med en twist på vissa befintliga internetprotokoll. Om du vill anta en strängare definition av innovation, var min gäst, men du kommer att bli förvånad över hur få riktiga ”innovationer” som finns kvar. Att parafrasera Läraren, det finns lite nytt under solen.

För att vara exakt gör jag påståendet att blockkedjor utan token tjänar ett syfte, men det är en olika syften jämfört med den ursprungliga bitcoin-blockkedjan. Crypto-huvuden skrattar åt tokenfria blockkedjor eftersom de inte kan ge censurmotstånd och decentraliserad säkerhet genom bevis på arbetet. Fintech-huvuden skrattar åt offentliga blockchains eftersom de är långsamma, dyra och olämpliga för traditionell ekonomi. Fortsätt skratta alla, för jag tror att ni båda har rätt.

Jag kommer att argumentera för att tokenfria blockkedjor är användbara för att hålla decentraliserade databaser synkroniserade, även i en enda organisation där det finns fullkomligt förtroende. Och sedan får vi se vilka andra funktioner blockchains erbjuder, vilket gör dem lämpliga för att skapa enighet för specifika typer av transaktioner mellan organisationer, där det bara finns begränsat och ofullkomligt förtroende.

Tyvärr, för att följa argumentet, måste du geek ut med mig om bitcoin-transaktionsmodellen, databas multiversion concurrency control (MVCC) och problemet med konfliktlösning i multimaster databasreplikering. Jag ska göra mitt bästa för att hålla mig till engelska, men det här är tekniska grejer, och det går inte att undvika det.

Bitcoins transaktionsmodell

Transaktionsmodellen för bitcoin är enkel men kraftfull. Varje bitcoin-transaktion har en uppsättning ingångar och en uppsättning utgångar. Varje ingång “spenderar” en utgång från en tidigare transaktion. Allt bitcoin i transaktionens ingångar flödar in i den transaktionen och distribueras över dess utgångar enligt de kvantiteter som är skrivna inom. På detta sätt bildar transaktioner en flervägsansluten kedja som slutar vid "myntbas" -transaktionerna där nya bitcoins skapas.

Bitcoin har en massa ytterligare regler som tillämpas av varje nod i nätverket:

• Varje input i en transaktion måste bevisa att den har rätt att spendera den tidigare output som den är ansluten till. Denna rättighet är begränsad av villkor som kodats i den tidigare produktionen.
• En transaktion måste ha tillräckligt med totalt bitcoin i sina ingångar för att täcka det totala antalet skrivna i sina utdata. De enda undantagen är myntbastransaktioner som skapar nya enheter i valutan.
• Varje utgång kan bara spenderas en gång, med andra ord kan den bara anslutas till en ingång i en efterföljande transaktion.

På grund av denna sista regel kräver nätverket en mekanism för att nå enighet om vilka transaktioner som är giltiga, och det är vad blockchain gör. Specifikt:

Om två transaktioner försöker spendera samma produktion kommer endast en av dessa transaktioner i slutändan att accepteras. En blockchain fungerar som en enhetlig mekanism för att upptäcka och förhindra dessa konflikter över nätverket.

Blockkedjan är strukturerad som en serie länkade block, där varje block innehåller en uppsättning transaktioner som inte strider mot varandra eller med tidigare block, med början från det första blocket som skapades 2009. I teorin kan kedjan innehålla en serie enskilda transaktioner, men genom att gruppera transaktioner i block får vi ett antal effektivitetsvinster som gör systemet mer praktiskt.

Så vad är syftet med en kryptovaluta i allt detta? Det handlar om frågan vem som bestämmer vilka block som bildar kedjan. Bitcoin är decentraliserat och har ingen auktoritet som kan fatta detta beslut, så det måste hitta något annat sätt att nå enighet.

Vi kanske vill använda en demokratisk strategi där noder i nätverket röstar på block och majoriteten vinner. Tyvärr är representativ demokrati inte möjligt online, vilket alla Internet-enkäter kan visa, på grund av problemet med efterliknande (även känt som en Sybil-attack). En person kan ta över en miljon datorer och bestämma hur de röstar och därmed ta kontroll över nätverkets konsensus. Ingen annan kommer ens att veta att detta har hänt.

För att lösa detta gör bitcoin det medvetet svårt att lägga till ett block i kedjan via en process som kallas "mining". För att skapa ett block måste du lösa ett svårt men meningslöst matematiskt problem som kräver mycket beräkning (och därmed el och pengar). Du behöver också lite tur, eftersom du konkurrerar med många andra blockgruvarbetare runt om i världen. Du kan inte komma fram länge genom att köpa en kraftfullare gruvdator, eftersom nätverket regelbundet justerar problemets svårighet för att hålla en stabil global hastighet på ett block per 10 minuter.

Om det är så svårt och dyrt att skapa ett block, varför skulle någon bry sig? Svaret är i blockbelöningen. Den framgångsrika gruvarbetaren i ett block kontrollerar myntbastransaktionen som tilldelar dem 25 bitcoins (denna summa halveras vart fjärde år). De kan sälja dessa bitcoins på den öppna marknaden för 7,000 XNUMX $ (i dagens takt), betala av sina elräkningar och förhoppningsvis få lite vinst. Gruvearbetare samlar också in lite extra från avgifter som är kopplade till transaktioner, men för närvarande spelar dessa avgifter en mindre roll.

Så bitcoin genererar konsensus via bevis på arbetet och kärnan i bitcoin-heads-argumentet är detta: Utan en kryptovaluta finns det inget sätt att stimulera decentraliserad brytning av block. Därför finns det inget sätt att säkra en öppen blockchain mot efterliknande attacker. Därför kan vem som helst monopolisera nätverkets konsensus och göra det hela värdelöst. Jag kommer inte att argumentera med något av det.

Multiversion samtidighetskontroll

Under tiden vill jag prata om något som kan verka helt orelaterat.

En databas är en databas med strukturerad information, grupperad i kalkylbladliknande enheter som kallas tabeller. Ett enkelt exempel på en sådan tabell är en lista med bankkonton, där varje rad innehåller ett kontonummer tillsammans med saldot på det kontot. Låt oss säga att ditt konto börjar dagen med ett saldo på $ 900. Idag är en automatisk inteckning på $ 750 planerad och du måste också ta ut $ 400 från en bankomat. Tyvärr har du inte en checkräkningskredit så att en av dessa operationer är inställd på att misslyckas.

Processerna för inteckning och uttag av uttagsautomater körs på separata system, som båda har åtkomst till den här enskilda kontodatabasen. Låt oss säga att varje process fungerar genom att läsa ditt kontos saldo, kontrollera att det räcker för operationen, initiera den operationen, verifiera att operationen är klar, beräkna den nya saldot och sedan slutligen skriva in den i databasen.

Så länge din inteckning och uttagsautomat inte överlappar varandra, fungerar den här logiken bra. Den första åtgärden kommer att genomföras framgångsrikt och den andra avbryts eftersom ditt konto inte har tillräckligt med pengar. Beroende på beställning får du ett arg telefonsamtal från banken eller ett oförskämt meddelande på bankomatskärmen.

Men vad händer om de två processerna råkar starta samtidigt? I det här fallet kommer var och en att läsa ditt kontos saldo och anser att det är tillräckligt för att fortsätta. När betalningen av hypotekslån är klar beräknas ditt nya saldo till $ 150 och skrivs till databasen. När uttaget på uttagsautomaten är klar kommer ditt nya saldo på 500 dollar på samma sätt att skrivas. En av dessa skrivåtgärder kommer att åsidosätta den andra, och beroende på din tur får du en $ 750 eller $ 400 bonus från din bank. Utan tvekan kommer du snart att lära dig att boka dina bankomater för inteckning.

Naturligtvis händer detta inte i verkligheten på grund av en databassteknik som kallas samtidighetskontroll. Samtidighetskontroll håller våra uppgifter (särskilt ekonomiska) tillförlitliga och säkra, och de finns i många former. Men alla delar principen att databasåtgärder grupperas i "transaktioner", som behandlas atomärt, vilket innebär att de lyckas eller misslyckas som en helhet. Samtidighet bevarar konsekvens genom att låsa eller frysa delar av en databas medan de används av en transaktion för att förhindra att andra transaktioner fungerar på samma information på ett motstridigt sätt.

Om vi ​​inte behövde köra transaktioner parallellt, kunde vi låsa hela databasen under hela varaktigheten för varje enskild transaktion. Detta är dock inte praktiskt i de flesta verkliga applikationer. Ett bra system för samtidig valutakontroll möjliggör parallella operationer genom att låsa så lite data som möjligt så kort tid som möjligt. I exemplet ovan skulle endast databasraden som motsvarar ditt konto vara låst och endast för den sekund som en sista kontroll och avdrag ägde rum. En motstridig transaktion som fungerar parallellt måste helt enkelt vänta tills detta lås släpps.

En populär samtidighetskontrollteknik kallas multiversion samtidighetskontrolleller kort sagt MVCC. I MVCC ser varje transaktion en konsekvent ögonblicksbild av data vid en viss tidpunkt, även om en del av dessa data håller på att uppdateras av en andra samtidig transaktion. Detta ögonblicksbildisolering egendom säkerställer till exempel att ett uttalande som visar vårt totala saldo över flera konton alltid kommer att vara korrekt, även om vissa medel håller på att flyttas från ett konto till ett annat. En transaktion kommer endast att påverka data som ses av en andra transaktion om den andra börjar efter att alla de första ändringarna har tillämpats.

Bakom kulisserna fungerar MVCC genom att flera versioner av en rad kan upprätthållas samtidigt, tillsammans med en tidsstämpel som representerar varje versions datum för senaste ändring. Ändring av en databaserad i MVCC markerar den aktuella versionen av den raden för radering, medan ändringen tillämpas på en kopia av den raden med en uppdaterad tidsstämpel. Ur databasens lagringsskikt syns det inte att ändra en rad på plats. Varje transaktion vet exakt när den startade och ser bara versioner av rader vars tidsstämpel föregår den tiden. Gamla versioner av rader kan tas bort från lagring när det inte finns några pågående transaktioner som kan behöva komma åt dem.

Avgörande för våra syften här förhindrar MVCC konflikter mellan skrivoperationer. Specifikt:

Om två transaktioner försöker ta bort samma radversion accepteras endast en av dessa transaktioner i slutändan. Multiversion samtidighetskontroll fungerar som en enhetlig mekanism för att upptäcka och förhindra dessa konflikter i en databas.

Ringa några klockor? Det finns ytterligare en bakgrund som vi behöver diskutera.

Multi-master databasreplikering

Låt oss nu prata om databasreplikering, där en databas finns i flera kopior. Det finns ett antal bra skäl att replikera en databas, till exempel:

• För att öka tillförlitligheten, så att om en kopia av databasen går förlorad (t.ex. på grund av ett diskfel) kan vi omedelbart byta till en andra kopia.
• För att öka genomströmningen, om volymen för operationer överskrider kapaciteten för en enda databasserver.
• För att minska latensen så att processer som körs på kontoret i Singapore inte behöver vänta på svar från en databas som sitter i Toronto.

När det gäller att läsning data från databaser är replikering en idealisk teknik, eftersom alla replikerna innehåller samma information. Men saker blir klistrigare när det gäller skrivoperationer, för vi måste bestämma var dessa skrivoperationer utförs och hur de överförs till andra kopior av databasen.

Det vanligaste svaret är att använda master-slave-replikering, där en enda databas ("master") anses vara auktoritär. Alla ändringar av data utförs uteslutande på mastern och sipprar sedan ner till alla andra "slav" -databaser via en transaktionslogg. Detta håller alla databaskopior (mer eller mindre) synkroniserade direkt.

Tyvärr, om skrivoperationer är frekventa, kommer master-slave-replikering oss tillbaka till det problem som replikering var utformad för att lösa. Huvuddatabasen blir en flaskhals när det gäller tillförlitlighet, genomströmning och latens, eftersom varje skrivoperation utförs enbart på den.

En mer komplex strategi kallas multi-master-replikering, där skrivningar kan utföras på någon av databaskopiorna snarare än på en enda master. I det här fallet delar kopiorna uppdateringar med varandra på ett peer-to-peer-sätt för att förbli synkroniserade.

Detta låter enkelt i teorin, men multimasterreplikering introducerar ett nytt problem eftersom konflikter kan uppstå. Vad händer om två kopior av en databas uppdaterar samma rad samtidigt och sedan försöker utbyta dessa uppdateringar med varandra? Båda databaserna märker att en motstridig uppdatering har ägt rum och måste tillämpa någon överenskommen strategi för att lösa dessa konflikter. Och här blir saker och ting ganska komplex - se dokumenten för MySQL, SQL Server or Oracle för några exempel på konfliktlösningsstrategier. (Jag ignorerar synkron eller så kallad "ivrig" multimasterreplikering, där alla repliker måste förbinda sig till en skrivoperation innan den kan ske, för det blir varje kopia av databasen till en flaskhals.)

Så här leder all denna bakgrund:

Skulle det inte vara trevligt om vi kunde ha distribuerat multiversion-samtidighetskontroll för att förhindra konflikter som inträffar vid multipelreplikering?

Tja, ja, jag antar att det skulle vara väldigt trevligt. Och jag tror att detta är precis vad blockkedjor gör.

Blockkedjor som distribuerad MVCC

Låt oss kopiera ner ett par meningar som jag skrev i fetstil ovan:

Om två transaktioner försöker spendera det samma produktion, då kommer endast en av dessa transaktioner i slutändan att accepteras. En blockchain fungerar som en enhetlig mekanism för att upptäcka och förhindra dessa konflikter över nätverket.

Om två transaktioner försöker radera det samma radversion, då accepteras endast en av dessa transaktioner i slutändan. Multiversion samtidighetskontroll fungerar som en enhetlig mekanism för att upptäcka och förhindra dessa konflikter inom en databas.

Dessa meningar är identiska förutom de djärva termerna. Så här är vad jag ska hävda:

En blockchain tillhandahåller distribuerad MVCC (med några extra klockor och visselpipor).

Låt oss jämföra jämförelsen lite längre. Ur perspektivet för en blockchain-nod bildar den nuvarande uppsättningen outnyttjade bitcoin-transaktionsutgångar en databas där varje rad är en enda outnyttjad utgång. Detta liknar databasen över bankkonton som vi beskrev tidigare, med den mindre skillnaden att saldot på varje konto kan delas över flera rader, som alla är markerade med samma kontonummer.

En bitcoin-transaktion spenderar en eller flera av dessa utdata och skapar en eller flera nya utgångar som ett resultat. Det här är precis som en databastransaktion som raderar en eller flera radversioner och skapar en eller flera nya rader som ett resultat (kom ihåg att det i MVCC inte finns något som ändrar en rad på plats). Bitcoin blockchain säkerställer att en enda produktion inte kan spenderas av mer än en transaktion. Detta motsvarar att säkerställa att en radversion inte kan raderas av mer än en databastransaktion.

Nu innan vi blir lurade hävdar jag inte att blockchains är en utmärkt teknik för allmänt ändamål för distribuerad databassynkronisering i en helt pålitlig miljö. Det finns gott om andra tekniker som Paxos, Raft och Tvåfasförpliktelse som utför jobbet mycket snyggt. Men jag tror att blockchains har en sweet spot, som kan karakteriseras som applikationer där:

• Vi kan acceptera en kort försening mellan när en transaktion antagligen accepteras och när den definitivt accepteras. (Denna fördröjning kan vara några sekunder snarare än 10 minuter som i bitcoin.)
• Motstridiga transaktioner ska aldrig ske om alla är ärliga och deras system fungerar som de ska.
• Varje transaktion modifierar bara några rader samtidigt (annars kommer våra blockchain-transaktioner att ha ett besvärligt antal ingångar).
• Storleken på varje databaserad är ganska liten (återigen, för att förhindra att våra blockchain-transaktioner ballonerar i storlek).

Alla dessa kriterier uppfylls av ekonomiska ansökningar. Finansvärlden är redan van vid förseningar (upp till 3 dagar!) Mellan att genomföra en transaktion och dess slutliga avveckling. När det gäller att förhindra konflikter har det kontrakt och regler för att upptäcka bedrägerier, och konsekvenserna kan vara allvarliga. Och mängden data involverad i varje transaktion är ganska liten - tänk på bankkontoexemplet ovan.

Hittills är allt jag har visat att blockchains är ännu en synkroniseringsmekanism för distribuerade databaser. Stor wow. Saker blir bara riktigt intressanta när vi överväger de ytterligare funktioner som blockchains erbjuder.

Blockkedjor bortom MVCC

En bitcoin-transaktion gör mycket mer än bara att peka på några tidigare transaktionsoutput och skapa några nya i stället. Även den enklaste bitcoin-transaktionen tjänar ytterligare två syften.

För det första innehåller reglerna för giltiga transaktioner en del av applikationslogiken för vår kontodatabas. Kom ihåg att den totala mängden bitcoin i en transaktions ingångar måste täcka den totala kvantiteten i utgångarna. Översatt till databasapplikationslogik är detta en regel som anger att databastransaktioner (med undantag för myntbaser) inte är tillåtna att öka den totala mängden bitcoin i databasen. Denna typ av begränsning går utöver vanlig databas Lagrade procedurer eftersom det under inga omständigheter kan kringgås.

För det andra, kom ihåg att varje bitcoin-transaktionsutdata kodar under vilka villkor den kan spenderas. För vanliga bitcoinutgångar är detta villkor baserat på kryptografi med offentlig nyckel. En allmän adress är inbäddad i utskriften "skript" så att den bara kan användas med den privata nyckel som motsvarar den offentliga adressen. Om vi ​​anser att denna utdata är en databasrad, har vi en databas med per-rad behörigheter som baseras på kryptografi för offentlig nyckel. Vidare presenterar varje transaktion ett offentligt granskbart bevis på att dess skapare hade rätt att radera / ändra sina tidigare rader. Detta (tror jag) är en äkta nyhet inom databasteknik.

Och igen, så händer det bara att båda dessa funktioner är oerhört användbara för ekonomiska applikationer. Vi gillar det faktum att vår databas på lägsta möjliga nivå säkerställer att pengar inte kan skapas ur luften. Och vi gillar att ha ett obestridligt granskningsspår som visar att varje transaktion godkändes av innehavaren av de medel som den flyttade. Som diskuteras i detalj här, vi kanske också gillar att utföra säkra atom-peer-to-peer-växlingstransaktioner (leverans-kontra-betalning i finans-samtal), utan att ens veta identiteten på vår motpart.

Så var är symbolen?

Naturligtvis är inget av detta en slump, för bitcoin i sig är en vacker peer-to-peer ekonomisk applikation. Ändå är ingen av ovanstående egenskaper hos en blockkedja beroende av symbolen alls. Om vi ​​ändrar vårt "databas" -schema så att varje rad kan representera flera tillgångar, snarare än blockkedjans ursprungliga valuta, kan vi bli av med den valutan helt. Detta ger oss en blockchain som ett sätt att uppnå konsensus och säkerhet i en peer-to-peer-ekonomisk ansökan om valfri tillgångsslag.

Bara en liten fråga dock: Vem gör brytningen för att skapa detta samförstånd? I bitcoin måste anonyma gruvarbetare utföra dyra värdelösa beräkningar och uppmuntras att göra det av blockbelöningarna (och transaktionsavgifter) i blockkedjans ursprungliga valuta eller token. Har vi några andra alternativ?

Det visar sig att vi gör det. Vi kan ha en sluten lista över tillåtna gruvarbetare som identifierar sig genom att underteckna blocken som de skapar. Regler om distribuerat samförstånd (eller "gruvdiversitet" som vi kallar det MultiKedja) tillhandahålla ett annat sätt att förhindra minoritetskontroll av blockchain, så länge du kan acceptera att gruvarbetare är godkända på förhand. Naturligtvis för bitcoin är detta inte acceptabelt, för en del av poängen är att tillåta anonym gruvdrift, så det finns inget sätt att censurera transaktioner centralt. Men om vi, säg, hade ett starkt reglerat finansiellt system, där bitcoins modell inte var tillämplig, kanske vi trots allt kunde acceptera en förut godkänd lista över gruvarbetare? Om vi ​​hade tillräckligt med dem och sprider dem tillräckligt bra mellan institutioner och hade lagliga avtal med dem alla, är det verkligen sannolikt att de samlas och undergräver det nätverk de är beroende av, när de gör det kommer de att hamna i fängelse?

Epilog

Jag hoppas att jag har visat att blockchains utan tokens har några användbara applikationer, även om dessa skiljer sig mycket från bitcoin blockchain. Ändå kvarstår en fråga:

Är dessa tillåtna, tokenfria delade huvudbokssystem verkligen värda namnet "blockchain"?

Det korta svaret är: vem bryr sig? Det är sällan värt att argumentera om betydelsen av ord, för det finns det inget rätt svar.

Men för att gå lite djupare, låt oss säga att jag accepterar förutsättningen att bitcoin blockchain är den arketypiska blockchain. I det fallet bör vi verkligen fråga:

Är dessa delade huvudböcker tillräckligt lika med bitcoin för att förtjäna namnet "blockchain"?

Min egen personliga syn här är ja. Eftersom de delar ett stort antal tekniska likheter, även om de skiljer sig åt i behörighetsmodellen och ekonomiska incitament. Och viktigast av allt, eftersom de båda genererar enighet i en distribuerad databas via en kedja av block.

Tack för att du läste.

Du kan följ mig på Twitter här. Se även: Leverans kontra betalning på blockchain.

Här är ett par andra bitar värda att läsa om detta ämne av Piotr Piasecki och Grävde Campbell.