Undvika det meningslösa blockchainprojektet

Hur man avgör om du har hittat ett riktigt blockchain-användningsfall

Blockkedjor är överhypade. Där sa jag det. Från SIBOS till Pengar20 / 20 för att täcka berättelser om The Economist och Euromoney, alla verkar klättra ombord på blockchain-vagnen. Och utan tvekan ser vi som andra i rymden ett snabbt ökande antal företag som bygger bevis på konceptet vår plattform och / eller ber om vår hjälp.

Som en ung start skulle du tro att vi skulle vara över månen. Det är säkert dags att samla in massor av pengar och bygga den högpresterande nästa generations blockchain-plattformen vi redan har designat. Vad i hela världen väntar vi på?

Jag ska säga dig. Vi väntar på att få en tydligare förståelse för var blockkedjor genuint tillföra värde i företagets IT. Du förstår, en stor del av dessa inkommande projekt har ingenting att göra med blockchains alls. Så här spelar det ut. Stort företag hör att blockchains är nästa stora sak. Stort företag hittar några människor internt som är intresserade av ämnet. Stort företag ger dem en budget och ber dem att göra något blockchainy. Snart kommer de knackar på vår dörr och vinkar med dollarsedlar och frågar us att hjälpa dem tänka upp ett användningsfall. Säg vad nu?

Vad gäller de som har ett projekt i åtanke, vad är problemet? I många fall kan projektet genomföras perfekt använder en vanlig relationsdatabas. Du vet, stora järnkroppar liknar Oracle och SQL Server, eller för de mer öppensinnade, MySQL och postgres. Så låt mig börja med att ställa in saker och ting:

Om dina krav uppfylls av dagens relationsdatabaser, skulle du vara galen att använda en blockchain.

Varför? Eftersom produkter som Oracle och MySQL har decennier av utveckling bakom sig. De har distribuerats på miljontals servrar som kör biljoner frågor. De innehåller några av de mest noggrant testade, felsökta och optimerade koderna på planeten, som behandlar tusentals transaktioner per sekund utan att svettas.

Och hur är det med blockkedjor? Väl, vår produkt var en av de första på marknaden och har funnits i exakt 5 månader med några tusen nedladdningar. Egentligen är den extremt stabil eftersom vi byggde upp den Bitcoin Core, programvaran som driver bitcoin. Men även så, hela denna produktkategori finns fortfarande i blöjorna.

Så säger jag att blockchains är värdelösa? Absolut inte. Men innan du börjar med det glänsande blockchain-projektet måste du ha en mycket tydlig uppfattning om varför du använder en blockchain. Det finns en massa villkor som måste uppfyllas. Och om de inte är det bör du gå tillbaka till ritbordet. Du kanske kan definiera projektet bättre. Eller kanske kan du spara alla mycket tid och pengar, för du behöver inte en blockchain alls.

1. Databasen

Här är den första regeln. Blockchains är en teknik för delade databaser. Så du måste börja med att veta varför du använder en databas, med vilken jag menar ett strukturerat databas. Detta kan vara traditionellt relationsdatabas, som innehåller en eller flera kalkylbladliknande tabeller. Eller så kan det vara trendigare NoSQL variation, som fungerar mer som ett filsystem eller ordlista. (På teoretisk nivå är NoSQL-databaser ändå bara en delmängd av relationsdatabaser.)

En huvudbok för finansiella tillgångar kan naturligtvis uttryckas som en databastabell där varje rad representerar en tillgångstyp som ägs av en viss enhet. Varje rad har tre kolumner som innehåller: (a) ägarens identifierare såsom ett kontonummer, (b) en identifierare för tillgångstypen som "USD" eller "AAPL", och (c) kvantiteten av den tillgången som innehas av den ägare.

Databaser ändras via "transaktioner" som representerar en uppsättning ändringar i databasen som måste accepteras eller avvisas som helhet. Till exempel, när det gäller en tillgångsbok, representeras en betalning från en användare till en annan av en transaktion som drar av lämplig mängd från en rad och lägger till den till en annan.

2. Flera författare

Den här är lätt. Blockchains är en teknik för databaser med flera författare. Med andra ord måste det finnas mer än en enhet som genererar de transaktioner som ändrar databasen. Vet du vem dessa författare är?

I de flesta fall kommer författarna också att köra "noder" som innehåller en kopia av databasen och vidarebefordra transaktioner till andra noder i en peer-to-peer mode. Transaktioner kan dock också skapas av användare som inte själva kör en nod. Tänk till exempel på ett betalningssystem som kollektivt underhålls av en liten grupp banker men som har miljontals slutanvändare på mobila enheter, som endast kommunicerar med sin egen banks system.

3. Frånvaro av förtroende

Och nu för den tredje regeln. Om flera enheter skriver till databasen måste det också finnas en viss grad av misstro mellan dessa enheter. Med andra ord är blockchains en teknik för databaser med flera icke-förtroende författare.

Du kanske tror att misstro bara uppstår mellan separata organisationer, såsom bankerna som handlar på en marknadsplats eller de företag som är inblandade i en leveranskedja. Men det kan också finnas inom en enda stor organisation, till exempel mellan avdelningar eller verksamheten i olika länder.

Vad menar jag specifikt med misstro? Jag menar att en användare inte är villig att låta en annan ändra databasposter som den "äger". På samma sätt, när det gäller att läsa databasens innehåll, kommer en användare inte att acceptera "sanningen" som evangelium som rapporterats av en annan användare, eftersom var och en har olika ekonomiska eller politiska incitament.

4. Disintermediation

Så problemet, som hittills definierats, är att möjliggöra en databas med flera icke-förtroende författare. Och det finns redan en välkänd lösning på detta problem: den betrodda förmedlaren. Det vill säga någon som alla författare litar på, även om de inte helt litar på varandra. Faktum är att världen är fylld med databaser av denna art, till exempel konton i en bank. Din bank styr databasen och ser till att varje transaktion är giltig och auktoriserad av kunden vars medel den flyttar. Oavsett hur artigt du frågar kommer din bank aldrig att låta dig ändra deras databas direkt.

Blockchains tar bort behovet av betrodda mellanhänder genom att aktivera databaser med flera icke-förtroende författare som ska modifieras direkt. Ingen central portvakt krävs för att verifiera transaktioner och autentisera källan. Istället utvidgas definitionen av en transaktion till att omfatta ett bevis på auktorisering och ett giltighetsbevis. Transaktioner kan därför vara oberoende verifieras och bearbetas av varje nod som underhåller en kopia av databasen.

Men frågan du behöver ställa är: Vill du eller behöver du denna distansförmedling? Med tanke på ditt användningsfall, är det något fel med att ha en central part som underhåller en auktoritär databas och fungerar som transaktionsportvakt? Bra skäl att föredra en blockchain-baserad databas framför en betrodd mellanhand kan innehålla lägre kostnader, snabbare transaktioner, automatiska avstämning, ny reglering eller en enkel oförmåga att hitta en lämplig mellanhand.

5. Transaktionsinteraktion

Så blockkedjor är vettiga för databaser som delas av flera författare som inte helt litar på varandra och som ändrar databasen direkt. Men det är fortfarande inte tillräckligt. Blockkedjor lyser verkligen där det finns några interaktion mellan transaktionerna skapad av dessa författare.

Vad menar jag med interaktion? I sin fulla mening betyder detta att transaktioner som skapats av olika författare ofta är beroende av varandra. Låt oss till exempel säga att Alice skickar några medel till Bob och sedan skickar Bob några vidare till Charlie. I det här fallet är Bobs transaktion beroende av Alice, och det finns inget sätt att verifiera Bobs transaktion utan att kontrollera Alice först. På grund av detta beroende beror transaktionerna naturligtvis samman i a en delad databas.

Att ta detta vidare är en trevlig egenskap hos blockchains att transaktioner kan skapas tillsammans av flera författare, utan att någon av parterna utsätter sig för risker. Detta är vad som tillåter leverans kontra betalning avveckling som ska utföras säkert över en blockchain utan att en pålitlig mellanhand kräver.

Ett bra fall kan också göras för situationer där transaktioner från olika författare är korskorrelerade med varandra, även om de förblir oberoende. Ett exempel kan vara en delad identitetsdatabas där flera enheter validerar olika aspekter av konsumenternas identitet. Även om varje sådan certifiering står ensam, är blockchain ett användbart sätt att föra samman allt på ett enhetligt sätt.

6. Ställ in reglerna

Detta är egentligen inte ett villkor utan snarare en oundviklig konsekvens av de tidigare punkterna. Om vi ​​har en databas modifierad direkt av flera författare och dessa författare inte helt litar på varandra, måste databasen innehålla inbäddade regler begränsar de utförda transaktionerna.

Dessa regler skiljer sig i grunden från begränsningar som visas i traditionella databaser, eftersom de relaterar till legitimitet för omvandlingar snarare än databasens tillstånd vid en viss tidpunkt. Varje transaktion kontrolleras mot dessa regler av varje nod i nätverket, och de som misslyckas avvisas och vidarebefordras inte.

Tillgångsreskontrar innehåller ett enkelt exempel på denna typ av regel för att förhindra transaktioner som skapar tillgångar ur luften. Regeln anger att den totala kvantiteten för varje tillgång i huvudboken måste vara densamma före och efter varje transaktion.

7. Välj dina validerare

Hittills har vi beskrivit en distribuerad databas där transaktioner kan ha sitt ursprung på många ställen, sprida sig mellan noder på ett peer-to-peer-sätt och verifieras av varje nod oberoende. Så var kommer en "blockchain" in? Tja, en blockchains jobb är att vara auktoritativ slutlig transaktionslogg, vars innehåll alla noder bevisligen överensstämmer med.

Varför behöver vi den här loggen? För det första gör det att nylagda noder kan beräkna databasens innehåll från grunden utan att behöva lita på en annan nod. För det andra tar det upp möjligheten att vissa noder kan missa vissa transaktioner på grund av systemstopp eller en kommunikationsfel. Utan en transaktionslogg skulle detta leda till att en nods databas avviker från andras, vilket undergräver målet för en delad databas.

För det tredje är det möjligt för två transaktioner att vara i konflikt, så att endast en kan accepteras. Ett klassiskt exempel är en dubbla spendera där samma tillgång skickas till två olika mottagare. I en peer-to-peer-databas utan central myndighet kan noder ha olika åsikter om vilken transaktion som ska accepteras, eftersom det finns inget objektivt rätt svar. Genom att kräva att transaktioner "bekräftas" i en blockchain säkerställer vi att alla noder konvergerar på samma beslut.

Slutligen, i Ethereum-stil blockkedjor, den exakta beställning av transaktioner spelar en avgörande roll, eftersom varje transaktion kan påverka vad som händer i varje efterföljande. I det här fallet agerar blockchain för att definiera den auktoritativa kronologin, utan vilken transaktioner inte kan behandlas alls.

En blockchain är bokstavligen en kedja av block, där varje block innehåller en uppsättning transaktioner som bekräftas som en grupp. Men vem är ansvarig för att välja de transaktioner som går in i varje block? I den typ av "privat blockchain" som är lämplig för företagsapplikationer är svaret en sluten grupp validerare ("gruvarbetare") som digitalt signerar blocken de skapar. Denna vitlistning kombineras med någon form av distribuerat konsensusschema för att förhindra att en minoritet validerare tar kontroll över kedjan. Till exempel använder MultiChain ett system som kallas gruvdiversitet, där de tillåtna gruvarbetarna arbetar i en round robin mode, med viss grad av smidighet för att möjliggöra icke-fungerande noder.

Oavsett vilket konsensusschema som används har valideringsnoderna mycket mindre effekt än ägaren av en traditionell centraliserad databas. Validerare kan inte fejka transaktioner eller ändra databasen i strid med dess regler. I en reskontra betyder det att de inte kan spendera andras pengar eller ändra den totala kvantiteten av tillgångar som representeras. Ändå finns det fortfarande två sätt på vilka validerare kan påverka onödigt en databas innehåll:

• Transaktionens censur. Om tillräckligt många validerare samarbetar skadligt kan de förhindra att en viss transaktion bekräftas i blockchain och lämnar den permanent i limbo.
• Partisk konfliktlösning. Om två transaktioner står i konflikt bestämmer valideraren som skapar nästa block vilken transaktion som bekräftas i blockchain, vilket får den andra att avvisas. Det rättvisa valet skulle vara den transaktion som sågs först, men validerare kan välja utifrån andra faktorer utan att avslöja detta.

På grund av dessa problem måste du ha en tydlig uppfattning om när du distribuerar en blockchain-baserad databas vilka dina validerare är och varför du litar på dem, kollektivt om inte ensam. Beroende på användningsfallet kan validerarna väljas som: (a) en eller flera noder som styrs av en enda organisation, (b) en kärngrupp av organisationer som underhåller kedjan, eller (c) varje nod i nätverket.

8. Säkerställ dina tillgångar

Om du har kommit så långt kanske du har märkt att jag brukar hänvisa till blockkedjor som delade databaser, snarare än de vanligaste ”delade huvudböckerna”. Varför? För som teknik kan blockkedjor tillämpas på problem långt bortom spårningen av tillgångsägande. Varje databas som har flera icke-förtroendeförfattare kan implementeras via en blockchain utan att det krävs en central mellanhand. Exempel är delade kalendrar, wiki-stil samarbete och diskussionsforum.

Med detta sagt verkar det för närvarande som blockchains främst är av intresse för dem som spårar rörelse och utbyte av finansiella tillgångar. Jag kan tänka på två skäl till detta: (a) finanssektorn svarar på (i efterhand minus) hot mot kryptovalutor som bitcoin, och (b) en tillgångsbok är det mest enkla och naturliga exemplet på en delad databas med ömsesidigt beroende transaktioner skapade av flera icke-förtroendefulla enheter.

Om du vill använda en blockchain som en reskontra måste du svara på ytterligare en avgörande fråga: Vilken typ av tillgångar flyttas? Med detta menar jag inte bara kontanter eller obligationer eller konossement, men det är naturligtvis viktigt också. Frågan är snarare: Vem står bakom tillgångarna i blockchain? Om databasen säger att jag äger tio enheter av något, vem tillåter mig att göra anspråk på de tio enheterna i den verkliga världen? Vem stämmer jag om jag inte kan konvertera det som står i blockchain till traditionella fysiska tillgångar? (Se detta tillgångsavtal för ett exempel.)

Svaret varierar naturligtvis beroende på användningsfallet. För monetära tillgångar kan man föreställa sig depåbanker som accepterar kontanter i traditionell form och sedan krediterar insättarnas konton i en blockchain-driven distribuerad huvudbok. När det gäller handelsfinansiering skulle kreditkort och fraktbrev backas upp av importörens bank respektive rederiet. Och vidare i framtiden kan vi föreställa oss en tid då primäremission av företagsobligationer sker direkt i en blockchain av företaget som försöker samla in pengar.

Slutsats

Som jag nämnde i inledningen, om ditt projekt inte uppfyller varenda en av dessa villkor, du borde inte använda en blockchain. I avsaknad av någon av de första fem bör du överväga en av: (a) vanlig fillagring, (b) en centraliserad databas, (c) master-slave databasreplikering, eller (d) flera databaser som användarna kan prenumerera.

Och om du uppfyller de första fem, finns det fortfarande arbete att göra. Du måste kunna uttrycka reglerna för din ansökan i termer av de transaktioner som en databas tillåter. Du måste vara säker på vem du kan lita på som validerare och hur du definierar distribuerad konsensus. Och slutligen, om du tittar på att skapa en delad huvudbok, måste du veta vem som kommer att stödja de tillgångar som huvudboken representerar.

Har du alla svar? Grattis, du har en riktig blockchain-användning. Och Vi skulle älska att höra från dig.

Skicka eventuella kommentarer på Link. Se även denna uppföljning: Fyra äkta blockchain-fall.