Hvordan få øye på en halvbakt blockchain

Når kjeder og blokker ikke tjener noe nyttig formål

Cirka 18 måneder har gått siden finanssektoren, massevis, våknet av mulighetene for tillatte blokkjeder, eller for å bruke det mer generelle begrepet "distribuerte hovedbøker". Perioden siden har sett en tsunami av aktivitet, inkludert forskningsrapporter, strategiske investeringer, pilotprosjekter og dannelsen av mange konsortier. Ingen kan beskylde bankverdenen for ikke å ta potensialet i denne teknologien på alvor.

Naturligvis har den eksplosive veksten i blockchain-prosjekter drevet utviklingen av tillatte blockchain-plattformer, som disse prosjektene er bygget på. For eksempel vårt produkt multikate har tredoblet seg i løpet av det siste året, enten vi måler nettrafikk, månedlige nedlastinger eller kommersielle henvendelser. Og selvfølgelig er det mange andre plattformer, for eksempel BigChainDB, Kjede, Corda, studiepoeng, Elements, Eris, Stoff, Ethereum (distribuert i et lukket nettverk), Hydrakjede og Åpen kjede. For ikke å nevne flere startups som har utviklet en slags blockchain-plattform, men som ikke har gjort den offentlig tilgjengelig.

For selskaper som ønsker å utforske og forstå en ny teknologi, er et stort utvalg av valg generelt en god ting. Imidlertid, når det gjelder blokkjeder, som fremdeles forblir løst definert og dårlig forstått, kommer denne overflødighetshornet med en betydelig ulempe: mange av de tilgjengelige "blockchain" -plattformene adresserer faktisk ikke kjerneproblemet de er ment å løse. Og hva er det problemet? Tillat meg å sitere det kortfattede videodefinisjon av Richard Gendal Brown, CTO for R3, i sin helhet:

En distribuert hovedbok er et system som gjør det mulig for partier som ikke helt stoler på hverandre å komme til enighet om eksistensen, naturen og utviklingen av et sett med delte fakta uten å måtte stole på en fullt pålitelig sentralisert tredjepart.

For å ta et ekstremt eksempel, bør du vurdere en haug med legoklosser bundet sammen med snor. Hvis vi bruker begrepet "blokkjede" for å beskrive dette moteproduktet, hvem skal da si at vi ikke beskriver det nøyaktig? Og likevel, den spesielle kjeden av blokker vil ikke hjelpe flere parter med å trygt og direkte dele en database uten en sentral formidler. På samme måte gjør mange "blockchain" -plattformer noe relatert til kjeder av blokker, men mangler også de nødvendige egenskapene for å tjene som grunnlag for en peer-to-peer-database.

En annen kjede av blokker som ikke hjelper med databasedeling - kilde.

Minimum levedyktig blockchain

For å forstå de grunnleggende kravene til en distribuert hovedbok, hjelper det å avklare hvordan disse systemene skiller seg fra vanlige databaser, som styres av en enkelt enhet. La oss for eksempel vurdere et enkelt system for sporing av hvem som eier et bestemt selskaps aksjer. Hovedboka, som implementert i en database, har en rad for hver eier som inneholder to kolonner: eierens identifikator, for eksempel navnet, og den tilsvarende mengden aksjer.

Her er seks viktige måter som dette systemet kan mislykkes på brukerne:

• Falskneri: Overføring av aksjer fra en person til en annen uten avsenderens tillatelse.
• Sensur: Nekter å oppfylle noens forespørsel om å overføre noen aksjer andre steder.
• tilbakeføring: Angre en overføring som fant sted på et tidspunkt tidligere.
• Ulovlighet: Endring av det totale antall aksjer i systemet uten en tilsvarende handling fra utstederen.
• inkonsekvens: Gi forskjellige svar på henvendelser fra forskjellige brukere.
• Nedetid: Svarer ikke på innkommende forespørsler om informasjon i det hele tatt.

På grunn av alle disse mulighetene, må aksjonærene opprettholde et høyt nivå av tillit til den som administrerer denne hovedboken på deres vegne. Å bygge og drive en organisasjon som er verdig den tilliten, medfører betydelig bry og kostnader.

Blokkjeder eller distribuerte hovedbøker fjerner behovet for denne typen sentrale databaseoperatør, ved å la brukerne av en database samhandle direkte med hverandre på en peer-to-peer-basis. I vårt eksempel kunne aksjeeierne trygt holde aksjene sine i en blockchain som de samlet administrerer, og foreta overføringer til hverandre umiddelbart over den kjeden. (Ulempen er et betydelig tap av konfidensialitet mellom kjedens brukere, som vi ikke tar opp her, men jeg har tidligere diskutert i lengden.)

Alt dette bringer oss tilbake til spørsmålet om blockchain-plattformer. For å tjene som et levedyktig grunnlag for deling av peer-to-peer-database, må en blockchain beskytte deltakerne mot alle seks typer databasefeil - forfalskning, sensur, reversering, ulovlige transaksjoner, inkonsekvens og nedetid. Mens mange produkter i markedet oppfyller disse kravene, kommer ganske mange av dem til kort. Jeg kaller disse blokkjedene for "halvbakt" fordi de kan adressere noen av disse risikoene, men ikke alle. I noen henseender er databasens brukere i det minste avhengige av den gode oppførselen til en enkelt deltaker, som nettopp er det scenariet vi ønsker å unngå.

Disse halvbakede blokkjedene kommer i et hvilket som helst antall varianter, men tre arketyper skiller seg ut som de vanligste eller mest åpenbare. Jeg skal ikke nevne individuelle produkter fordi jeg ikke vil fornærme. Blockchain-oppstartssamfunnet er lite nok til at de fleste av oss kjenner hverandre gjennom konferanser og andre møter, og interaksjonene pleier å være positive. Likevel, hvis blokkjeder (i betydningen nyttige peer-to-peer-databaser) noen gang kommer til å dukke opp som en sammenhengende produktkategori, er det viktig å skille mellom halvbakte og virkelige løsninger.

Den ene validator blockchain

Et mønster vi har sett noen ganger er en blockchain der bare en deltaker kan generere blokkene der transaksjoner blir bekreftet. Transaksjoner sendes til denne ene noden i stedet for å sendes til nettverket som helhet, så deres aksept er underlagt dette partiets innfall i stedet for en slags flertallskonsensus. Når en sentral part først har bygget en blokk, sendes den til de andre nodene i nettverket, som uavhengig kan bekrefte gyldigheten av transaksjonene innen, og registrere den nye blokken lokalt og permanent.

For å gå tilbake til våre seks former for databasefeil, er denne typen blockchain langt fra ubrukelig. Transaksjoner må signeres digitalt av enheten hvis midler de flytter, slik at de ikke kan forfalskes av den sentrale parten. De kan ikke reverseres fordi hver node opprettholder sin egen kopi av kjeden. Og transaksjoner kan ikke utføre ulovlige operasjoner som å opprette eiendeler utenom luft, fordi hver node uavhengig validerer hver transaksjon for korrekthet. Til slutt opprettholder hver node sin egen kopi av databasen, slik at innholdet alltid er tilgjengelig for lesing.

Dessverre er ikke fire av seks nok. Valideringsnoden kan enkelt sensurere individuelle transaksjoner ved å nekte å inkludere dem i blokkene den oppretter. Selv om operatørene av denne noden er ærlige, kan et system- eller kommunikasjonsfeil gjøre det utilgjengelig, og føre til at all transaksjonsbehandling stopper opp. I tillegg, avhengig av oppsett, kan valideringsnoden være i stand til å overføre forskjellige versjoner av blockchain til forskjellige deltakere. Når det gjelder sensur og konsistens, inneholder databasen fortsatt et enkelt feilpunkt, som alle de andre nodene er avhengige av.

En plattform tilbyr en vri på denne ordningen, der blokker genereres sentralt av en enkelt node, men et antall andre angitte noder signerer dem for å indikere konsensus. Når det gjelder risikoen for inkonsekvens, hjelper dette absolutt. Nodene i quorumet vil bare låne ut signaturene til en enkelt versjon av blockchain, som derfor kan betraktes som autoritativ. Ikke desto mindre kan ikke quorumskodene hjelpe hvis blokkgeneratoren sensurerer transaksjoner, eller mister forbindelsen til Internett. Til slutt bruker denne typen blockchain fremdeles en hub-and-spoke-arkitektur, i stedet for et peer-to-peer-nettverk.

Den delte statlige blockchain

Teknisk sett er det mange likheter mellom blokkjeder og mer tradisjonelle distribuerte databaser som Cassandra og MongoDB. I begge tilfeller kan transaksjoner initieres av en hvilken som helst node i nettverket, og må nå alle de andre nodene som en del av enighet om databasens utviklingstilstand. Både blokkjeder og distribuerte databaser må takle ventetid (kommunikasjonsforsinkelser som stammer fra avstanden mellom noder) og muligheten for at noen noder og / eller kommunikasjonskoblinger periodevis mislykkes.

Distribuerte databaser har eksistert en stund, så enhver blockchain-plattformutvikler vil gjøre det bra å forstå deres konsensusalgoritmer og strategiene de bruker for å globalt bestille transaksjoner og løse konflikter. Likevel er det viktig å ikke ta sammenligningen for langt, fordi blokkjeder må kjempe med en viktig ekstra utfordring - fravær av stole på mellom databasens noder. Mens distribuerte databaser fokuserer på å gi skalerbarhet, robusthet og høy ytelse innenfor en enkelt organisasjons grenser, må blokkjedene redesignes for å kunne traversere disse grensene.

For å gå tilbake til våre seks typer databaserisiko, trenger en node i en distribuert database bare bekymre seg for nedetid, dvs. muligheten for at andre noder blir utilgjengelige. Noder kan trygt anta at hver transaksjon og melding i nettverket er gyldig, og ikke er opptatt av forfalskning, sensur, reversering, illegitimitet eller inkonsekvens. Deres verste problem er å håndtere to samtidige, men gyldige transaksjoner, initiert på forskjellige noder, som påvirker samme data. Å løse disse konfliktene er på ingen måte trivielt, men det er fortsatt mye enklere enn å bekymre seg for “Bysantinske feil“, Der noen noder bevisst handler for å forstyrre andres funksjon.

En database kan bare deles trygt tvers stole på grenser hvis noder behandler all aktivitet på nettverket med en viss grad av mistenksomhet. For eksempel må hver transaksjon som endrer databasen signeres digitalt digitalt siden det i en peer-to-peer-arkitektur ikke er noen annen måte å kjenne dens sanne utgangspunkt. Tilsvarende må hver innkommende melding, som kunngjøringen av en ny blokk, vurderes kritisk for innholdet og konteksten. I motsetning til i distribuerte databaser, må noder ikke være i stand til å endre tilstanden til en annen node umiddelbart og direkte.

Noen "blockchain" -plattformer er utviklet ved å starte med en distribuert database, og dryss noen funksjoner på toppen for å gjøre dem mer blockchainy. For eksempel, ved å gruppere transaksjoner i blokker og lagre hashes (digitale fingeravtrykk) av disse blokkene i databasen, tar de sikte på å legge til en form for uforanderlighet. Men med mindre hver node kan være sikker på at listen over hashes ikke kan endres av en annen node, blir denne typen uforanderlighet lett spilt. Standardresponsen på denne kritikken er at ethvert sikkerhetsproblem kan løses med tilstrekkelig tid og koding. Men dette er som å holde noen fanger i et åpent felt, og prøve å stoppe dem med å rømme med tripwires og grøfter. Det er langt tryggere å bruke en spesialbygd betongkonstruksjon, hvis dører er låst og hvis vinduer er sperret.

Den ene skyblokkjeden

Det desidert merkeligste fenomenet jeg har sett er blockchain-plattformer som bare er tilgjengelige via utviklerens skybaserte plattform-som-en-tjeneste. For å være tydelig snakker vi ikke om noen av blockchain-deltakerne velge for å være vert for nodene sine hos deres valgte skyleverandør, for eksempel Microsoft Azure or Amazon Web Services. Snarere er dette en blockchain som kan bare være tilgjengelig via API-er eksponert av serverne til et selskap som "hoster" det.

La oss gi, for argumentets skyld, at en sentralisert blockchain-leverandør virkelig har en gruppe noder som kjører under sin kontroll. Hvilken forskjell gjør dette for brukerne av systemet som sender API-forespørsler og mottar svar? Deltakerne har ingen måte å vurdere om alles transaksjoner er behandlet uten utelatelse eller feil. Kanskje fungerer den sentrale tjenesten ikke, eller kanskje sensurerer eller reverserer den bevisst noen transaksjoner. Og hvis du mener at blockchain-leverandøren ikke har noen grunn til å gjøre dette, hvorfor ikke bruke dem til å være vert for en vanlig sentralisert database i stedet? Du får et mer modent produkt med bedre ytelse og lider ingen av risikoen ved å jobbe med ny teknologi. Kort sagt, sentraliserte blokkjeder er omtrent like nyttige som Lego på en streng.

Å løse mysteriet

Vi har nå sett tre typer plattformer som markedsfører seg selv som "blockchains", og som faktisk bruker litt av en kjede av blokker, men som ikke løser det grunnleggende problemet som disse systemene er designet for. For å oppsummere er dette for å muliggjøre at en enkelt database kan deles trygt og direkte på tvers av tillitsgrenser, uten sentral formidler.

Bortsett fra å peke på dette særegne fenomenet, tror jeg det er lærerikt å vurdere hva som kan ligge til grunn for det. Hvorfor bygger så mange blockchain startups produkter som ikke oppfyller løftet om denne teknologien, og som ofte ikke oppnår mer enn tradisjonelle sentraliserte eller distribuerte databaser? Hvorfor kaster så mange talentfulle mennesker bort så mye tid?

Jeg kan se to hovedklasser av forklaring - teknisk og kommersiell. Til å begynne med det tekniske er det ganske vanskelig å lage distribuerte konsensus-systemer som tåler at en eller flere noder oppfører seg ondsinnet på uforutsigbare måter. Når det gjelder MultiChain, lurte vi noe ved å bruke bitcoins kamphærde referanseimplementering som utgangspunkt, og deretter erstatte bevis på arbeid med en strukturelt lik konsensusalgoritme kalt “mining diversity”. Team som utvikler en blockchain-node fra bunnen av, må tenke dypt om asynkrone og kontroversielle prosesser - en kombinasjon som få programmerere har erfaring med. Jeg kan absolutt forstå fristelsen til å ta en snarvei, for eksempel å bruke en enkelt node for å generere blokker, eller piggybacking på en eksisterende distribuert database, eller bare kjøre noder i et pålitelig miljø. Å velge noen av disse utvilsomt gjør livet lettere for utviklere, selv om dette undergraver hele poenget.

Av kommersielle årsaker ser det ut til at hver oppstart nærmer seg blockchain-muligheten fra en annen vinkel. Her på Coin Sciences fokuserer vi på å bli en (database) programvareleverandør, så vi distribuerer MultiChain gratis mens vi utvikler en premiumnode med tilleggsfunksjoner. Andre nystartede selskaper vil selge abonnementstjenester, så de vil naturlig bygge en plattform som kundene ikke kan være vertskap for. Noen håper å kontrollere en blockchain sentralt eller hjelpe partnerne til å gjøre det (en merkelig ambisjon om en distribusjonsteknologi!) Og trekkes naturlig nok til konsensusalgoritmer som er avhengige av en enkelt node. Og til slutt er det selskaper som har som hovedmål å selge konsulenttjenester, i så fall trenger ikke plattformen deres å fungere i det hele tatt, så lenge nettstedet bringer inn noen store kunder.

Kanskje et annet problem er at noen blockchain-selskaper drives av folk som utvilsomt sprenger av talent, men som ikke har en dyp forståelse av selve teknologien. I nyetablerere som tegner ut et nytt felt, er det sannsynligvis viktig at strategiske beslutninger tas av folk som forstår arten av dette feltet og hvordan det skiller seg fra det som kom før. Ikke få blockchain-oppstart synes å ha malt seg inn i et hjørne ved å forfølge en produktvisjon som er attraktiv for kundene, men som faktisk ikke kan bygges.

Som bruker av blokkjeder, hvordan kan du unngå å bli fanget av disse feilslutningene? Når du vurderer en bestemt blockchain-plattform, må du spørre om den oppfyller de seks kravene til sikker peer-to-peer database-deling: forebygging av nedetid og inkonsekvens, samt transaksjonsforfalskning, sensur, reversering og illegitimitet. Og pass på forklaringer som består av for mye mumling eller håndvinking - de betyr sannsynligvis at svaret er nei.

Legg inn kommentarer på Linkedin.

Kilde: https://www.multichain.com/blog/2016/12/spot-half-baked-blockchain/