Undgå det meningsløse blockchain-projekt

Sådan afgør du, om du har fundet en rigtig blockchain-brugssag

Blockchains er overhypede. Der sagde jeg det. Fra SIBOS til Money20 / 20 at dække historier om The Economist , Euromoney, synes alle at klatre ombord på blockchain-vognen. Og uden tvivl, ligesom andre i rummet, ser vi et hurtigt stigende antal virksomheder, der bygger proof of concept på vores platform og/eller beder om vores hjælp.

Som ung startup skulle man tro, at vi ville være over månen. Nu er det bestemt tid til at rejse et væld af penge og bygge den højtydende næste generation af blockchain-platform, vi allerede har designet. Hvad i alverden venter vi på?

Jeg skal fortælle dig hvad. Vi venter på at få en klarere forståelse af, hvor blockchains virkelig tilføre værdi i virksomhedens IT. Ser du, en stor del af disse indkommende projekter har intet at gøre med blockchains overhovedet. Her er, hvordan det udspiller sig. Stor virksomhed hører, at blockchains er den næste store ting. Stor virksomhed finder internt nogle personer, der interesserer sig for emnet. Stor virksomhed giver dem et budget og fortæller dem, at de skal lave noget blockchainy. Snart nok kommer de og banker på vores dør, vifter med dollarsedler og spørger us at hjælpe dem udtænke en use case. Sig hvad nu?

Hvad er problemet for dem, der har et projekt i tankerne? I mange tilfælde kan projektet gennemføres udmærket ved hjælp af en almindelig relationsdatabase. Du ved, store jern giganter kan lide Oracle , SQL Servereller for de mere åbensindede, MySQL , PostgreSQL. Så lad mig starte med at rette tingene op:

Hvis dine krav er opfyldt af nutidens relationelle databaser, ville du være sindssyg at bruge en blockchain.

Hvorfor? Fordi produkter som Oracle og MySQL har årtiers udvikling bag sig. De er blevet installeret på millioner af servere, der kører billioner af forespørgsler. De indeholder noget af det mest gennemtestede, fejlrettede og optimerede kode på planeten, der behandler tusindvis af transaktioner i sekundet uden at svede.

Og hvad med blockchains? Godt, vores produkt var en af ​​de første på markedet og har været tilgængelig i præcis 5 måneder med et par tusinde downloads. Faktisk er det ekstremt stabilt, fordi vi byggede det af Bitcoin Core, softwaren, der driver bitcoin. Men alligevel, Hele denne produktkategori er stadig i sine bleer.

Så siger jeg, at blockchains er ubrugelige? Absolut ikke. Men før du går i gang med det skinnende blockchain-projekt, skal du have en meget klar idé om hvorfor du bruger en blockchain. Der er en masse betingelser, der skal opfyldes. Og hvis de ikke er det, skal du gå tilbage til tegnebrættet. Måske kan du definere projektet bedre. Eller måske kan du spare alle en masse tid og penge, fordi du slet ikke har brug for en blockchain.

1. Databasen

Her er den første regel. Blockchains er en teknologi til delte databaser. Så du skal starte med at vide, hvorfor du bruger en database, hvorved jeg mener et struktureret lager af information. Dette kan være en traditionel relationelle database, som indeholder en eller flere regnearkslignende tabeller. Eller det kan være mere trendy NoSQL sort, som fungerer mere som et filsystem eller en ordbog. (På et teoretisk niveau er NoSQL-databaser alligevel bare en undergruppe af relationelle databaser.)

En hovedbog for finansielle aktiver kan naturligt udtrykkes som en databasetabel, hvor hver række repræsenterer en aktivtype, der ejes af en bestemt enhed. Hver række har tre kolonner, der indeholder: (a) ejerens identifikator, såsom et kontonummer, (b) en identifikator for aktivtypen, såsom "USD" eller "AAPL", og (c) mængden af ​​det aktiv, som den pågældende ejer ejer.

Databaser modificeres via "transaktioner", som repræsenterer et sæt ændringer af databasen, som skal accepteres eller afvises som helhed. For eksempel, i tilfælde af en finansbog, er en betaling fra én bruger til en anden repræsenteret af en transaktion, der trækker den passende mængde fra én række og tilføjer den til en anden.

2. Flere forfattere

Den her er nem. Blockchains er en teknologi til databaser med flere forfattere. Med andre ord skal der være mere end én enhed, der genererer de transaktioner, der ændrer databasen. Ved du, hvem disse forfattere er?

I de fleste tilfælde vil forfatterne også køre "knudepunkter", som har en kopi af databasen og videresender transaktioner til andre knudepunkter i en peer-to-peer mode. Imidlertid kan transaktioner også oprettes af brugere, der ikke selv kører en node. Overvej for eksempel et betalingssystem, som i fællesskab vedligeholdes af en lille gruppe banker, men som har millioner af slutbrugere på mobile enheder, der kun kommunikerer med deres egen banks systemer.

3. Fravær af tillid

Og nu til den tredje regel. Hvis flere enheder skriver til databasen, skal der også være en vis grad af mistro mellem disse enheder. Blockchains er med andre ord en teknologi til databaser med flere ikke-tillidsfulde skribenter.

Du tror måske, at mistillid kun opstår mellem separate organisationer, såsom banker, der handler på en markedsplads, eller virksomheder, der er involveret i en forsyningskæde. Men det kan også eksistere inden for en enkelt stor organisation, for eksempel mellem afdelinger eller operationerne i forskellige lande.

Hvad mener jeg specifikt med mistillid? Jeg mener, at en bruger ikke er villig til at lade en anden ændre databaseposter, som den "ejer". På samme måde, når det kommer til at læse databasens indhold, vil en bruger ikke acceptere "sandheden" som evangelium, som rapporteret af en anden bruger, fordi hver bruger har forskellige økonomiske eller politiske incitamenter.

4. Disintermediation

Så problemet, som defineret indtil videre, er at aktivere en database med flere ikke-tillidsfulde skribenter. Og der er allerede en velkendt løsning på dette problem: den betroede mellemmand. Altså nogen, som alle forfatterne har tillid til, selvom de ikke stoler fuldt ud på hinanden. Faktisk er verden fyldt med databaser af denne art, såsom hovedbogen over konti i en bank. Din bank styrer databasen og sikrer, at hver transaktion er gyldig og godkendt af den kunde, hvis midler den flytter. Uanset hvor høfligt du spørger, vil din bank aldrig lade dig ændre deres database direkte.

Blockchains fjerner behovet for betroede formidlere ved at aktivere databaser med flere ikke-tillidsfulde skribenter, der skal ændres direkte. Der kræves ingen central gatekeeper for at verificere transaktioner og autentificere deres kilde. I stedet udvides definitionen af ​​en transaktion til at omfatte et bevis for autorisation og et bevis for gyldighed. Transaktioner kan derfor være uafhængigt verificeret og behandlet af hver node som vedligeholder en kopi af databasen.

Men spørgsmålet du skal stille er: Ønsker du eller har du brug for denne disintermediation? I betragtning af din use case, er der så noget galt i at have en central part, der vedligeholder en autoritativ database og fungerer som transaktionens gatekeeper? Gode ​​grunde til at foretrække en blockchain-baseret database frem for en betroet mellemmand kan omfatte lavere omkostninger, hurtigere transaktioner, automatisk forsoning, ny regulering eller en simpel manglende evne til at finde en passende mellemmand.

5. Transaktionsinteraktion

Så blockchains giver mening for databaser, der deles af flere forfattere, som ikke helt stoler på hinanden, og som ændrer databasen direkte. Men det er stadig ikke nok. Blockchains skinner virkelig, hvor der er nogle interaktion mellem transaktionerne skabt af disse forfattere.

Hvad mener jeg med interaktion? I fuld forstand betyder det, at transaktioner skabt af forskellige forfattere ofte afhænger af hinanden. Lad os f.eks. sige, at Alice sender nogle penge til Bob, og så sender Bob nogle videre til Charlie. I dette tilfælde er Bobs transaktion afhængig af Alices transaktion, og der er ingen måde at bekræfte Bobs transaktion uden at tjekke Alices først. På grund af denne afhængighed hører transaktionerne naturligt sammen i en enkelt delt database.

Hvis vi tager dette videre, er en god funktion ved blockchains, at transaktioner kan oprettes i samarbejde med flere forfattereuden at nogen af ​​parterne udsætter sig selv for risiko. Det er det, der tillader levering kontra betaling afvikling skal udføres sikkert over en blockchain uden at kræve en betroet mellemmand.

Der kan også argumenteres for situationer, hvor transaktioner fra forskellige skribenter er krydskorrelerede med hinanden, selvom de forbliver uafhængige. Et eksempel kan være en delt identitetsdatabase, hvor flere enheder validerer forskellige aspekter af forbrugernes identiteter. Selvom hver sådan certificering står alene, giver blockchain en nyttig måde at bringe alt sammen på en samlet måde.

6. Indstil reglerne

Dette er egentlig ikke en betingelse, men snarere en uundgåelig konsekvens af de foregående punkter. Hvis vi har en database, der er ændret direkte af flere forfattere, og disse forfattere ikke stoler fuldt ud på hinanden, skal databasen indeholde indlejrede regler begrænse de udførte transaktioner.

Disse regler er fundamentalt forskellige fra begrænsninger der optræder i traditionelle databaser, fordi de relaterer til legitimiteten af ​​transformationer snarere end databasens tilstand på et bestemt tidspunkt. Hver transaktion kontrolleres mod disse regler af hver node i netværket, og de, der fejler, afvises og videresendes ikke.

Regnskabsbøger indeholder et simpelt eksempel på denne type regler for at forhindre transaktioner, der skaber aktiver ud af den blå luft. Reglen siger, at den samlede mængde af hvert aktiv i hovedbogen skal være den samme før og efter hver transaktion.

7. Vælg dine validatorer

Indtil videre har vi beskrevet en distribueret database, hvor transaktioner kan stamme fra mange steder, forplante sig mellem noder på en peer-to-peer måde og verificeres af hver node uafhængigt. Så hvor kommer en "blockchain" ind? Nå, en blockchains opgave er at være autoritativ endelig transaktionslog, hvis indhold alle noder beviseligt stemmer overens.

Hvorfor har vi brug for denne log? For det første gør det det muligt for nyligt tilføjede noder at beregne databasens indhold fra bunden uden at skulle stole på en anden node. For det andet adresserer det muligheden for, at nogle noder kan gå glip af nogle transaktioner på grund af nedetid i systemet eller en kommunikationsfejl. Uden en transaktionslog ville dette få en nodes database til at afvige fra de andres, hvilket underminerer målet med en delt database.

For det tredje er det muligt for to transaktioner at være i konflikt, så kun én kan accepteres. Et klassisk eksempel er en dobbeltforbrug hvor det samme aktiv sendes til to forskellige modtagere. I en peer-to-peer-database uden central autoritet kan noder have forskellige meninger om, hvilken transaktion der skal accepteres, fordi der er intet objektivt rigtigt svar. Ved at kræve, at transaktioner skal "bekræftes" i en blockchain, sikrer vi, at alle noder konvergerer om den samme beslutning.

Endelig i Ethereum-stil blockchains, den præcise bestilling af transaktioner spiller en afgørende rolle, fordi enhver transaktion kan påvirke, hvad der sker i hver efterfølgende. I dette tilfælde fungerer blockchain for at definere den autoritative kronologi, uden hvilken transaktioner slet ikke kan behandles.

En blockchain er bogstaveligt talt en kæde af blokke, hvor hver blok indeholder et sæt transaktioner, der bekræftes som en gruppe. Men hvem er ansvarlig for at vælge de transaktioner, der går ind i hver blok? I den slags "privat blockchain", som er velegnet til virksomhedsapplikationer, er svaret en lukket gruppe af validatorer ("minere"), som digitalt underskriver de blokke, de opretter. Denne hvidliste er kombineret med en form for distribueret konsensusordning for at forhindre et mindretal af validatorer i at overtage kontrollen over kæden. For eksempel bruger MultiChain et skema kaldet minedrift mangfoldighed, hvor de tilladte minearbejdere arbejder i en runde Robin mode, med en vis grad af mildhed for at give mulighed for ikke-fungerende noder.

Uanset hvilket konsensusskema der bruges, har de validerende noder langt mindre magt end ejeren af ​​en traditionel centraliseret database. Validatorer kan ikke forfalske transaktioner eller ændre databasen i strid med dens regler. I en hovedbog betyder det, at de ikke kan bruge andres penge eller ændre den samlede mængde repræsenterede aktiver. Ikke desto mindre er der stadig to måder, hvorpå validatorer kan uretmæssigt påvirke en databases indhold:

• Transaktionscensur. Hvis nok af validatorerne samarbejder ondsindet, kan de forhindre en bestemt transaktion i at blive bekræftet i blockchainen, hvilket efterlader den permanent i limbo.
• Fordomsfuld konfliktløsning. Hvis to transaktioner er i konflikt, beslutter validatoren, der opretter den næste blok, hvilken transaktion der bekræftes på blockchain, hvilket medfører, at den anden bliver afvist. Det rimelige valg ville være den transaktion, der blev set først, men validatorer kan vælge baseret på andre faktorer uden at afsløre dette.

På grund af disse problemer, når du implementerer en blockchain-baseret database, skal du have en klar idé om hvem dine validatorer er, og hvorfor du stoler på dem, kollektivt, hvis ikke alene. Afhængigt af use casen kan validatorerne vælges som: (a) en eller flere noder kontrolleret af en enkelt organisation, (b) en kernegruppe af organisationer, der vedligeholder kæden, eller (c) hver node på netværket.

8. Sikker på dine aktiver

Hvis du er nået så langt, har du måske bemærket, at jeg har en tendens til at henvise til blockchains som delte databaser, snarere end de mere almindelige "delte hovedbøger". Hvorfor? Fordi som teknologi kan blockchains anvendes på problemer langt ud over sporingen af ​​ejerskab af aktiver. Enhver database, som har flere ikke-tillidsfulde skribenter, kan implementeres over en blockchain uden at kræve en central mellemmand. Eksempler omfatter delte kalendere, samarbejde i wiki-stil og diskussionsfora.

Når det er sagt, ser det ud til, at blockchains hovedsageligt er af interesse for dem, der sporer bevægelse og udveksling af finansielle aktiver. Jeg kan komme i tanke om to grunde til dette: (a) finanssektoren reagerer på (i retrospekt, minimal) truslen fra kryptovalutaer som bitcoin, og (b) en reskontro er det mest enkle og naturlige eksempel på en delt database med indbyrdes afhængige transaktioner skabt af flere ikke-tillidsfulde enheder.

Hvis du ønsker at bruge en blockchain som en aktiv hovedbog, skal du besvare et yderligere afgørende spørgsmål: Hvad er arten af ​​aktiverne, der flyttes rundt? Med dette mener jeg ikke kun kontanter eller obligationer eller konnossementer, selvom det selvfølgelig også er vigtigt. Spørgsmålet er snarere: Hvem står bag aktiverne repræsenteret på blockchain? Hvis databasen siger, at jeg ejer 10 enheder af noget, hvem vil tillade mig at gøre krav på de 10 enheder i den virkelige verden? Hvem skal jeg sagsøge, hvis jeg ikke kan konvertere det, der er skrevet i blockchainen, til traditionelle fysiske aktiver? (Se dette aktivaftale for et eksempel.)

Svaret vil selvfølgelig variere afhængigt af brugssagen. For monetære aktiver kan man forestille sig, at depotbanker accepterer kontanter i traditionel form, og derefter krediterer indskydernes konti i en blockchain-drevet distribueret hovedbog. Inden for handelsfinansiering ville remburser og konnossementer være støttet af henholdsvis importørens bank og rederiet. Og længere ude i fremtiden kan vi forestille os en tid, hvor den primære udstedelse af virksomhedsobligationer foregår direkte på en blockchain ved, at virksomheden søger at rejse midler.

Konklusion

Som jeg nævnte i indledningen, hvis dit projekt ikke opfylder hver eneste af disse forhold, bør du ikke bruge en blockchain. I mangel af nogen af ​​de første fem, bør du overveje en af: (a) almindelig fillagring, (b) en centraliseret database, (c) master-slave database replikering, eller (d) flere databaser, som brugere kan Hold mig opdateret.

Og hvis du opfylder de første fem, er der stadig arbejde at gøre. Du skal kunne udtrykke reglerne for din ansøgning i forhold til de transaktioner, som en database tillader. Du skal være sikker på, hvem du kan stole på som validatorer, og hvordan du vil definere distribueret konsensus. Og endelig, hvis du kigger på at oprette en delt hovedbog, skal du vide, hvem der skal støtte de aktiver, som denne hovedbog repræsenterer.

Har du alle svarene? Tillykke, du har en rigtig blockchain use case. Og Vi vil meget gerne høre fra dig.

Skriv eventuelle kommentarer på LinkedIn. Se også denne opfølgning: Fire ægte blockchain-brugssager.