Unngå det meningsløse blockchain-prosjektet

Hvordan finne ut om du har funnet en ekte blockchain-brukstilfelle

Blokkjeder er overhypet. Der sa jeg det. Fra SIBOS til Penger20 / 20 for å dekke historier om The Economist og Euromoney, alle ser ut til å klatre ombord blockchain-vognen. Og uten tvil, som andre i rommet, ser vi et raskt økende antall selskaper som bygger konseptbevis på plattformen vår og / eller ber om hjelp.

Som en ung oppstarts skulle du tro at vi ville være over månen. Nå er det sikkert tid for å skaffe massevis av penger og bygge den høye ytelsen neste generasjons blockchain-plattform vi allerede har designet. Hva i all verden venter vi på?

Jeg skal fortelle deg hva. Vi venter på å få en klarere forståelse av hvor blokkjeder genuint legge til verdi i bedriftens IT. Du skjønner, en stor andel av disse innkommende prosjektene har ingenting å gjøre med blokkjeder i det hele tatt. Slik spiller det ut. Stort selskap hører at blokkjeder er den neste store tingen. Stort selskap finner noen mennesker internt som er interessert i faget. Stort selskap gir dem et budsjett og ber dem om å gjøre noe blockchainy. Snart kommer de bankende på døren vår, vinker med dollarsedler og spør us for å hjelpe dem tenk opp en brukssak. Si hva nå?

Hva er problemet for de som har et prosjekt i tankene? I mange tilfeller kan prosjektet gjennomføres perfekt ved hjelp av en vanlig relasjonsdatabase. Du vet, store jernjern som Oracle og SQL Server, eller for de mer fordomsfri, MySQL og postgres. Så la meg starte med å sette ting i orden:

Hvis kravene dine blir oppfylt av dagens relasjonsdatabaser, vil du være gal i å bruke en blockchain.

Hvorfor? Fordi produkter som Oracle og MySQL har flere tiår med utvikling bak seg. De har blitt distribuert på millioner av servere som kjører billioner av spørsmål. De inneholder noen av de mest grundig testede, feilsøkte og optimaliserte kodene på planeten, og behandler tusenvis av transaksjoner per sekund uten å svette.

Og hva med blokkjeder? Vi vil, vårt produkt var en av de første som markedsførte, og har vært tilgjengelig i nøyaktig 5 måneder, med noen få tusen nedlastinger. Egentlig er den ekstremt stabil, fordi vi bygde den av Bitcoin Core, programvaren som driver bitcoin. Men allikevel hele denne produktkategorien er fortsatt i bleiene.

Så jeg sier at blokkjeder er ubrukelige? Absolutt ikke. Men før du begynner på det skinnende blockchain-prosjektet, må du ha en veldig klar ide om hvorfor du bruker en blockchain. Det er en rekke betingelser som må oppfylles. Og hvis de ikke er det, bør du gå tilbake til tegnebrettet. Kanskje du kan definere prosjektet bedre. Eller kanskje du kan spare alle tid og penger, for du trenger ikke en blockchain i det hele tatt.

1. Databasen

Her er den første regelen. Blockchains er en teknologi for delte databaser. Så du må starte med å vite hvorfor du bruker en database, som jeg mener et strukturert lager med informasjon. Dette kan være tradisjonelt relasjonsdatabase, som inneholder ett eller flere regnearklignende tabeller. Eller det kan være mer trendy NoSQL variasjon, som fungerer mer som et filsystem eller ordbok. (På teoretisk nivå er NoSQL-databaser uansett bare en delmengde av relasjonsdatabaser.)

En hovedbok for finansielle eiendeler kan naturlig uttrykkes som en databasetabell der hver rad representerer en aktivatype som eies av en bestemt enhet. Hver rad har tre kolonner som inneholder: (a) eierens identifikator, for eksempel et kontonummer, (b) en identifikator for aktivatypen, for eksempel "USD" eller "AAPL", og (c) mengden av eiendelen som den inneholder Eieren.

Databaser endres via "transaksjoner" som representerer et sett med endringer i databasen som må aksepteres eller avvises som en helhet. For eksempel, når det gjelder en eiendelsboks, representeres en betaling fra en bruker til en annen av en transaksjon som trekker riktig mengde fra en rad, og legger den til en annen.

2. Flere forfattere

Dette er enkelt. Blockchains er en teknologi for databaser med flere forfattere. Med andre ord må det være mer enn én enhet som genererer transaksjonene som endrer databasen. Vet du hvem disse forfatterne er?

I de fleste tilfeller vil forfatterne også kjøre "noder" som har en kopi av databasen og videreformidle transaksjoner til andre noder i en peer-to-peer mote. Imidlertid kan transaksjoner også opprettes av brukere som ikke kjører en node selv. Tenk for eksempel på et betalingssystem som vedlikeholdes kollektivt av en liten gruppe banker, men som har millioner av sluttbrukere på mobile enheter, kun kommuniserer med sin egen banks systemer.

3. Fravær av tillit

Og nå for den tredje regelen. Hvis flere enheter skriver til databasen, må det også være en viss grad av mistillit mellom disse enhetene. Med andre ord, blokkeringer er en teknologi for databaser med flere ikke-tillitsfulle forfattere.

Du tror kanskje at mistillit bare oppstår mellom separate organisasjoner, for eksempel bankene som handler på en markedsplass eller selskapene som er involvert i en forsyningskjede. Men det kan også eksistere innenfor en enkelt stor organisasjon, for eksempel mellom avdelinger eller operasjoner i forskjellige land.

Hva mener jeg konkret med mistillit? Jeg mener at en bruker ikke er villig til å la en annen endre databaseoppføringer som den "eier". På samme måte, når det gjelder å lese databasens innhold, vil en bruker ikke akseptere "sannheten" som evangelium som rapportert av en annen bruker, fordi hver bruker har forskjellige økonomiske eller politiske insentiver.

4. Disintermediation

Så problemet, som definert så langt, er å aktivere en database med flere ikke-tillitsfulle forfattere. Og det er allerede en kjent løsning på dette problemet: den pålitelige mellomleddet. Det vil si noen som alle forfatterne stoler på, selv om de ikke stoler fullt på hverandre. Faktisk er verden fylt med databaser av denne karakteren, for eksempel hovedbok for kontoer i en bank. Banken din kontrollerer databasen og sørger for at hver transaksjon er gyldig og autorisert av kunden hvis midler den beveger seg. Uansett hvor høflig du spør, vil banken din aldri la deg endre databasen deres direkte.

Blokkjeder fjerner behovet for pålitelige mellomledd ved å aktivere databaser med flere ikke-tillitsfulle forfattere som skal endres direkte. Ingen sentral gatekeeper er nødvendig for å verifisere transaksjoner og autentisere kilden. I stedet utvides definisjonen av en transaksjon til å omfatte et bevis på autorisasjon og et bevis på gyldighet. Transaksjoner kan derfor være uavhengig verifisert og behandlet av hver node som vedlikeholder en kopi av databasen.

Men spørsmålet du må stille er: Vil du eller trenger du denne disintermediasjonen? Gitt din brukstilfelle, er det noe galt med å ha en sentral part som vedlikeholder en autoritær database og fungerer som transaksjonsportvakt? Gode ​​grunner til å foretrekke en blokkjedebasert database fremfor en klarert mellommann, kan omfatte lavere kostnader, raskere transaksjoner, automatiske avstemming, ny regulering eller en enkel manglende evne til å finne et passende mellomledd.

5. Transaksjonsinteraksjon

Så blokkeringer gir mening for databaser som deles av flere forfattere som ikke helt stoler på hverandre, og som endrer databasen direkte. Men det er fortsatt ikke nok. Blokkjeder skinner virkelig der det er noen samhandling mellom transaksjonene skapt av disse forfatterne.

Hva mener jeg med interaksjon? I full forstand betyr dette at transaksjoner opprettet av forskjellige forfattere ofte er avhengige av hverandre. La oss for eksempel si at Alice sender penger til Bob, og så sender Bob penger videre til Charlie. I dette tilfellet er Bobs transaksjon avhengig av Alice, og det er ingen måte å verifisere Bobs transaksjon uten å sjekke Alice's første. På grunn av denne avhengigheten hører transaksjonene naturlig sammen i en enkelt delt database.

Tar dette videre, er en fin funksjon av blockchains at transaksjoner kan opprettes samarbeid av flere forfattere, uten at noen av partene utsetter seg for risiko. Dette er det som tillater det levering kontra betaling oppgjør som skal utføres trygt over en blockchain uten å kreve en pålitelig mellommann.

En god sak kan også gjøres for situasjoner der transaksjoner fra forskjellige forfattere er krysskorrelert med hverandre, selv om de forblir uavhengige. Et eksempel kan være en delt identitetsdatabase der flere enheter validerer forskjellige aspekter av forbrukernes identitet. Selv om hver slik sertifisering står alene, gir blockchain en nyttig måte å bringe alt sammen på en enhetlig måte.

6. Sett reglene

Dette er egentlig ikke en tilstand, men heller en uunngåelig konsekvens av de tidligere punktene. Hvis vi har en database endret direkte av flere forfattere, og disse forfatterne ikke stoler fullt på hverandre, må databasen inneholde innebygde regler begrense utførte transaksjoner.

Disse reglene er fundamentalt forskjellige fra begrensninger som vises i tradisjonelle databaser, fordi de er relatert til legitimitet av transformasjoner i stedet for databasens tilstand på et bestemt tidspunkt. Hver transaksjon blir sjekket mot disse reglene av hver node i nettverket, og de som mislykkes blir avvist og ikke videreformidlet.

Eiendomsbokser inneholder et enkelt eksempel på denne typen regler, for å forhindre transaksjoner som skaper eiendeler utenom luften. Regelen sier at den totale mengden av hver eiendel i hovedboken må være den samme før og etter hver transaksjon.

7. Velg validatorene dine

Så langt har vi beskrevet en distribuert database der transaksjoner kan stamme mange steder, forplante seg mellom noder på en peer-to-peer-måte, og blir verifisert av hver node uavhengig. Så hvor kommer en "blockchain" inn? En blockchain-jobb er å være den autoritativ endelig transaksjonslogg, hvis innhold alle noder beviselig er enige om.

Hvorfor trenger vi denne loggen? For det første gjør det at noder som er lagt til, kan beregne innholdet i databasen fra bunnen av, uten å måtte stole på en annen node. For det andre adresserer det muligheten for at noen noder kan gå glipp av noen transaksjoner på grunn av nedetid i systemet eller en kommunikasjonsfeil. Uten en transaksjonslogg vil dette føre til at en nodes database avviker fra den andres, og undergraver målet med en delt database.

For det tredje er det mulig for to transaksjoner å være i konflikt, slik at bare en kan aksepteres. Et klassisk eksempel er en dobbeltbruk der den samme eiendelen sendes til to forskjellige mottakere. I en peer-to-peer-database uten sentral autoritet, kan noder ha forskjellige meninger om hvilken transaksjon de skal godta, fordi det er ikke noe objektivt riktig svar. Ved å kreve at transaksjoner "bekreftes" i en blockchain, sørger vi for at alle noder samles på samme avgjørelse.

Endelig i Ethereum-stil blokkeringer, den presise bestilling av transaksjoner spiller en avgjørende rolle, fordi hver transaksjon kan påvirke det som skjer i hver påfølgende. I dette tilfellet fungerer blockchain for å definere den autoritative kronologien, uten hvilken transaksjoner ikke kan behandles i det hele tatt.

En blokkjede er bokstavelig talt en kjede av blokker, der hver blokk inneholder et sett med transaksjoner som bekreftes som en gruppe. Men hvem er ansvarlig for å velge transaksjonene som går inn i hver blokk? I den typen "private blockchain" som er egnet for bedriftsapplikasjoner, er svaret en lukket gruppe validatorer ("gruvearbeidere") som digitalt signerer blokkene de lager. Denne hvitelisten er kombinert med en eller annen form for distribuert konsensusordning for å hindre et mindretall av validatorer fra å ta kontroll over kjeden. For eksempel bruker MultiChain en ordning som heter gruvedrift mangfold, der de tillatte gruvearbeiderne jobber i en round robin mote, med en viss grad av lindring for å tillate ikke-fungerende noder.

Uansett hvilken konsensusordning som brukes, har valideringsnodene langt mindre kraft enn eieren av en tradisjonell sentralisert database. Validatorer kan ikke forfalske transaksjoner eller endre databasen i strid med reglene. I en kapitalbok betyr det at de ikke kan bruke andres penger, eller endre den totale mengden eiendeler som er representert. Likevel er det fremdeles to måter som validatorer kan påvirke innholdet i databasen urimelig:

• Transaksjonssensur. Hvis nok av validatorene samarbeider ondsinnet, kan de forhindre at en bestemt transaksjon blir bekreftet i blockchain, og la den være permanent i limbo.
• Partisk konfliktløsning. Hvis to transaksjoner kommer i konflikt, bestemmer validatoren som oppretter neste blokk hvilken transaksjon som er bekreftet på blockchain, og får den andre til å bli avvist. Det rettferdige valget ville være transaksjonen som ble sett først, men validatorer kan velge basert på andre faktorer uten å avsløre dette.

På grunn av disse problemene, når du distribuerer en blockchain-basert database, må du ha en klar ide om hvem validatorene dine er og hvorfor du stoler på dem, samlet hvis ikke alene. Avhengig av brukssaken kan validatorene velges som: (a) en eller flere noder kontrollert av en enkelt organisasjon, (b) en kjernegruppe av organisasjoner som vedlikeholder kjeden, eller (c) hver node i nettverket.

8. Sett tilbake eiendelene dine

Hvis du har kommet så langt, har du kanskje lagt merke til at jeg pleier å referere til blokkjeder som delte databaser, snarere enn de vanligste “delte hovedbokene”. Hvorfor? Fordi blockchains som teknologi kan brukes på problemer langt utenfor sporing av eiendoms eierskap. Enhver database som har flere ikke-tillitsfulle forfattere kan implementeres over en blockchain uten å kreve en sentral formidler. Eksempler inkluderer delte kalendere, wiki-stil samarbeid og diskusjonsfora.

Når det er sagt, virker det for øyeblikket at blokkjeder hovedsakelig er av interesse for de som sporer bevegelse og utveksling av finansielle eiendeler. Jeg kan tenke på to grunner til dette: (a) finanssektoren reagerer på (i ettertid, liten) trussel om kryptovalutaer som bitcoin, og (b) en eiendelsbokholder er det mest enkle og naturlige eksemplet på en delt database med gjensidig avhengige transaksjoner opprettet av flere ikke-tillitsfulle enheter.

Hvis du ønsker å bruke en blockchain som en kapitalbok, må du svare på et ytterligere viktig spørsmål: Hva er arten av eiendelene som flyttes rundt? Med dette mener jeg ikke bare kontanter eller obligasjoner eller konneksjoner, selv om det selvfølgelig er viktig også. Spørsmålet er snarere: Hvem står bak eiendelene som er representert i blockchain? Hvis databasen sier at jeg eier 10 enheter av noe, hvem vil tillate meg å gjøre krav på de 10 enhetene i den virkelige verden? Hvem saksøker jeg hvis jeg ikke kan konvertere det som er skrevet i blockchain til tradisjonelle fysiske eiendeler? (Se dette eiendeleavtale for et eksempel.)

Svaret vil selvfølgelig variere etter brukssaken. For monetære eiendeler kan man forestille seg depotbanker som aksepterer kontanter i tradisjonell form, og deretter krediterer innskuddskontoer i en blockchain-drevet distribuert hovedbok. I handelsfinansiering vil kredittbrev og konnossement bli støttet av henholdsvis importørens bank og rederiet. Og videre i fremtiden kan vi forestille oss en tid da primærutstedelse av bedriftsobligasjoner foregår direkte på en blockchain av selskapet som søker å skaffe midler.

konklusjonen

Som jeg nevnte i innledningen, hvis prosjektet ditt ikke oppfyller hver eneste av disse forholdene, bør du ikke bruke en blockchain. I fravær av noen av de fem første, bør du vurdere en av: (a) vanlig fillagring, (b) en sentralisert database, (c) master-slave databasereplikasjon, eller (d) flere databaser som brukerne kan abonnere.

Og hvis du oppfyller de fem første, er det fortsatt arbeid å gjøre. Du må kunne uttrykke programmets regler når det gjelder transaksjonene som en database tillater. Du må være trygg på hvem du kan stole på som validatorer og hvordan du vil definere distribuert konsensus. Og til slutt, hvis du ser på å opprette en delt hovedbok, må du vite hvem som vil støtte eiendelene som hovedboken representerer.

Har du alle svarene? Gratulerer, du har en ekte blockchain-brukstilfelle. Og vi vil gjerne høre fra deg.

Legg inn kommentarer på Linkedin. Se også denne oppfølgingen: Fire ekte blockchain-brukssaker.