Blockchains vs sentraliserte databaser

Fire viktige forskjeller mellom blokkjeder og vanlige databaser

Hvis du har lest mine tidligere innlegg, vil du vite nå at blokkjeder bare er en ny type database. Det vil si en database som kan deles direkte, i skrivemessig forstand, av en gruppe ikke-tillitsfulle parter uten å kreve en sentral administrator. Dette står i kontrast til tradisjonelle (SQL eller NoSQL) databaser som styres av en enkelt enhet, selv om det brukes en slags distribuert arkitektur innenfor veggene.

Jeg ga det nylig en prat om blokkeringer fra perspektivet til informasjonssikkerhet, der jeg konkluderte med at blokkeringer er sikrere enn vanlige databaser på noen måter, og mindre sikre på andre. Vurderer hovedrolle at sentraliserte databaser spiller i dagens teknologibunke, fikk dette meg til å tenke bredere på kompromissene mellom disse to teknologiene. Faktisk, når noen spør meg om multikate kan brukes til et bestemt formål, er mitt første svar alltid: "Kan du gjøre det med en vanlig database?" I flere tilfeller enn du kanskje tror, ​​er svaret ja av følgende enkle grunn:

Hvis tillit og robusthet ikke er et problem, er det ingenting en blockchain kan gjøre som en vanlig database ikke kan.

Dette er et sentralt punkt som det er så mye misforståelse på. Når det gjelder typer data som kan lagres, og transaksjonene som kan utføres på disse dataene, gjør ikke blokkjeder noe nytt. Og bare for å være klar, strekker denne observasjonen seg også til "smarte kontrakter", til tross for deres sexy navn og image. En smart kontrakt er ikke noe annet enn et stykke datakode som kjører på hver node i en blockchain - en tiår gammel teknologi kalt lagrede prosedyrer gjør det samme for sentraliserte databaser. (Du kan heller ikke bruke en blockchain hvis denne koden trenger det initiere interaksjoner med omverdenen.)

Sannheten om blokkjeder er at selv om de har noen fordeler, har de også sine ulemper. Med andre ord, som de fleste teknologibeslutninger, kommer valget mellom en blockchain og en vanlig database ned til en rekke avveininger. Hvis du blir blindet av sprøytenarkomanen og døvet av støyen, er det lite sannsynlig at du tar det valget objektivt. Så jeg håper følgende guide kan hjelpe.

Disintermediation: fordel blokkeringer

Kjerneverdien til en blockchain er at en database kan deles direkte på tvers av tillitsgrenser, uten at det kreves en sentral administrator. Dette er mulig fordi blockchain-transaksjoner inneholder sitt eget bevis på gyldighet og eget bevis for autorisasjon, i stedet for å kreve noe sentralisert applikasjonslogikk for å håndheve disse begrensningene. Transaksjoner kan derfor verifiseres og behandles uavhengig av flere “noder”, med blockchain som en konsensusmekanisme for å sikre at disse noder holder seg synkroniserte.

Hvorfor er det verdi i denne disintermediasjonen? For selv om en database bare er bit og byte, det er også en håndgripelig ting. Innholdet i en database er lagret i minnet og disken til et bestemt datasystem, og alle som har tilstrekkelig tilgang til systemet kan ødelegge eller ødelegge dataene i det. Som et resultat, i det øyeblikket du overlater dataene dine til en vanlig database, blir du også avhengig av menneskelig organisasjon der databasen ligger.

Nå er verden fylt med organisasjoner som har fått denne tilliten - regjeringer og banker (for det meste), universiteter, bransjeforeninger og til og med private selskaper som Google og Facebook. I de fleste tilfeller, spesielt i den utviklede verden, fungerer disse ekstremt bra. Jeg tror min stemme alltid har blitt talt, ingen bank har noen gang stjålet pengene mine, og jeg har ennå ikke funnet en måte å betale for bedre karakterer. Så hva er problemet? Hvis en organisasjon kontrollerer en viktig database, trenger den også en haug med mennesker og prosesser på plass for å forhindre at databasen blir manipulert. Folk trenger ansettelse, prosesser må utformes, og alt dette tar mye tid og penger.

Så blockchains tilbyr en måte å erstatte disse organisasjonene med en distribuert database, låst av smart kryptografi. Som så mye som har kommet før, utnytter de den stadig økende kapasiteten til datasystemer for å gi en ny måte å erstatte mennesker med kode. Og når den først er skrevet og feilsøkt, har kode en tendens til å være veldig billigere.

Konfidensialitet: fordel sentraliserte databaser

Som jeg nevnte, verifiserer og behandler hver node i en blockchain uavhengig hver transaksjon. En node kan gjøre dette fordi den har full synlighet i: (a) databasens nåværende tilstand, (b) modifikasjonen som en transaksjon krever, og (c) en digital signatur som beviser transaksjonens opprinnelse. Dette er utvilsomt en smart ny måte å lage en database på, og det fungerer virkelig. Så hvor er fangsten? For mange applikasjoner, spesielt økonomiske, er den fullstendige gjennomsiktigheten som hver node nyter en absolutt avdrepende.

Hvordan unngår systemer bygget på vanlige databaser dette problemet? Akkurat som blokkjeder, begrenser de transaksjonene som bestemte brukere kan utføre, men disse begrensningene er pålagt en sentral beliggenhet. Som et resultat trenger hele databaseinnholdet bare være synlig på det stedet, i stedet for i flere noder. Forespørsler om å lese data går også gjennom denne sentrale autoriteten, som kan godta eller avvise disse forespørslene etter eget ønske. Med andre ord, hvis en vanlig database er lesekontrollert og skrivekontrollert, kan en blokkjede kun være skrivekontrollert.

For å være rettferdig er det mange strategier tilgjengelig for å redusere dette problemet. Disse spenner fra enkle ideer som å handle under flere blockchain-adresser, til avanserte kryptografiske teknikker som konfidensielle transaksjoner og bevis på null kunnskap (utvikles nå). Ikke desto mindre, jo mer informasjon du vil skjule i en blockchain, jo tyngre beregningsbyrde betaler du for å generere og verifisere transaksjoner. Og uansett hvordan disse teknikkene utvikler seg, vil de aldri slå den enkle og greie metoden for å skjule data fullstendig.

Robusthet: fordelblokkeringer

En annen fordel med blockchain-drevne databaser er ekstrem feiltoleranse, som stammer fra deres innebygde redundans. Hver node behandler hver transaksjon, så ingen individuell node er avgjørende for databasen som helhet. På samme måte kobler noder seg til hverandre på en tett peer-to-peer-måte, så mange kommunikasjonskoblinger kan mislykkes før ting maler til stopp. Blockchain sørger for at noder som gikk ned alltid kan innhente transaksjoner de savnet.

Så selv om det er sant at vanlige databaser tilbyr mange teknikker for replikering, blockchains tar dette til et helt nytt nivå. For en start er ingen konfigurasjon nødvendig - bare koble noen blockchain-noder sammen, og de holder seg automatisk synkronisert. I tillegg kan noder legges til eller fjernes fritt fra et nettverk, uten forberedelser eller konsekvenser. Til slutt kan eksterne brukere sende transaksjonene sine til en hvilken som helst node eller til flere noder samtidig, og disse transaksjonene overføres automatisk og sømløst til alle andre.

Denne robustheten forvandler økonomien til databasetilgjengelighet. Med vanlige databaser oppnås høy tilgjengelighet gjennom en kombinasjon av dyr infrastruktur og katastrofegjenoppretting. En primær database kjører på avansert maskinvare som overvåkes nøye for problemer, med transaksjoner replikert til et backupsystem et annet fysisk sted. Hvis den primære databasen mislykkes (f.eks. På grunn av strømbrudd eller katastrofal maskinvarefeil), flyttes aktiviteten automatisk til sikkerhetskopien, som blir den nye primæren. Når det mislykkede systemet er løst, står det i kø for å fungere som den nye sikkerhetskopien hvis og når det er nødvendig. Selv om alt dette er gjennomførbart, er det dyrt og notorisk vanskelig å få rett.

I stedet, hva om vi hadde 10 blockchain-noder som kjører i forskjellige deler av verden, alt på råvaremaskinvare? Disse nodene ville være tett koblet til hverandre, dele transaksjoner på en peer-to-peer-basis og bruke en blockchain for å sikre konsensus. Sluttbrukere som genererer transaksjonene, kobler seg til (si) 5 av disse nodene, så det spiller ingen rolle om noen få kommunikasjonskoblinger går ned. Og hvis en eller to noder feiler fullstendig på en gitt dag, føler ingen noe, for det er fortsatt mer enn nok kopier til å gå rundt. Når det skjer, er denne kombinasjonen av rimelige systemer og høy redundans nøyaktig hvordan Google bygde søkemotoren sin så billig. Blokkjeder kan gjøre det samme for databaser.

Ytelse: fordel sentraliserte databaser

Blokkjeder vil alltid være tregere enn sentraliserte databaser. Det er ikke bare det dagens blockchains er treg fordi teknologien er ny og ikke optimalisert, men det er et resultat av natur av selve blokkjedene. Du ser, når en behandling av transaksjoner må en blockchain gjøre de samme tingene som en vanlig database, men den bærer ytterligere tre byrder:

1. Bekreftelse av signatur. Hver blockchain-transaksjon må signeres digitalt ved hjelp av en offentlig-privat kryptografisk ordning som f.eks ECDSA. Dette er nødvendig fordi transaksjoner sprer seg mellom noder på en peer-to-peer-måte, slik at kilden ikke ellers kan bevises. Generering og verifisering av disse signaturene er beregningsmessig komplisert og utgjør den primære flaskehalsen i produkter som våre. I sentraliserte databaser er det derimot ikke nødvendig å verifisere hver forespørsel som kommer over den, når en forbindelse er opprettet.
2. Konsensusmekanismer. I en distribuert database, for eksempel en blockchain, må innsatsen brukes for å sikre at noder i nettverket når konsensus. Avhengig av konsensusmekanismen som brukes, kan dette innebære betydelig frem-og-tilbake-kommunikasjon og / eller håndtering av gafler og deres påfølgende tilbakeslag. Selv om det er sant at sentraliserte databaser også må kjempe med motstridende og avbrutte transaksjoner, er disse langt mindre sannsynlige der transaksjoner står i kø og behandles på ett sted.
3. Overflødighet. Dette handler ikke om ytelsen til en individuell node, men den totale mengden beregning som en blockchain krever. Mens sentraliserte databaser behandler transaksjoner en gang (eller to ganger), i en blokkjede må de behandles uavhengig av hver node i nettverket. Så det blir gjort mye mer arbeid for det samme sluttresultatet.

Den nederste linjen

Naturligvis er det andre måter blokkeringer og vanlige databaser kan sammenlignes på. Vi kunne snakke om modebasert modenhet, attraktivitet hos utviklere, økosystembredde og mer. Men ingen av disse problemene er det iboende til selve teknologien. Så når det gjelder en langsiktig beslutning om å bruke en blockchain, er spørsmålet å stille dette: Hva er viktigere for brukssaken min? Forvirring og robusthet? Eller konfidensialitet og ytelse?

Når det blir undersøkt i dette enkle lyset, er mange av brukssakene som for tiden er under diskusjon gir ikke mening. Det største problemet pleier å være konfidensialitet. Deltakerne på et sterkt konkurransedyktig marked vil naturlig nok foretrekke privatlivet til en sentralisert database, i stedet for å avsløre sine aktiviteter for hverandre. Dette gjelder spesielt hvis en klarert sentral part allerede eksisterer og kan tilby det nøytrale territoriet der databasen kan ligge. Selv om det kan være noen kostnader forbundet med denne sentrale leverandøren, er dette mer enn berettiget av verdien av personvernet. Den eneste motivasjonen for et skifte til blockchains ville være aggressiv ny regulering.

Ikke desto mindre har blokkjeder sterke brukstilfeller, hvor uformidling og robusthet er viktigere enn konfidensialitet og ytelse. Jeg skriver mer om disse i et senere innlegg, men de mest lovende områdene vi har sett så langt er: (a) revisjonsspor mellom selskaper, (b) herkomstsporing, og (c) lettvekt finansielle systemer. I alle tre tilfeller har vi funnet folk som bygger på MultiChain med et klart syn på distribusjon, i stedet for bare nysgjerrighet og eksperimentering. Så hvis du leter etter måter blokkeringer kan gi virksomheten virkelig verdi på, kan de være et godt sted å starte.

Legg inn kommentarer på Linkedin.