Plokiahelad vs tsentraliseeritud andmebaasid

Neli peamist erinevust plokiahelate ja tavaliste andmebaaside vahel

Kui olete lugenud minu eelmisi postitusi, teate juba praegu, et plokiahelad on lihtsalt a uut tüüpi andmebaasid. See tähendab, et andmebaas, mida saab kirjalikus mõttes otseselt jagada mitteusaldusväärsete osapoolte grupiga ilma keskhaldurit nõudmata. See on vastuolus traditsiooniliste (SQL või NoSQL) andmebaasidega, mida haldab üksus, isegi kui selle seintes kasutatakse mingisugust hajutatud arhitektuuri.

Andsin hiljuti jutt infot plokkkettide kohta infoturbe seisukohast, milles järeldasin, et plokiahelad on mõnes mõttes turvalisemad kui tavalised andmebaasid ja teistes vähem turvalised. Arvestades juhtiv roll et tsentraliseeritud andmebaasid mängivad tänases tehnoloogiakogus, pani see mind mõtlema laiemalt nende kahe tehnoloogia vahelistele kompromissidele. Tõepoolest, alati, kui keegi minult küsib, kas MultiCin saab kasutada konkreetsel eesmärgil, on minu esimene vastus alati: "Kas saaksite seda teha tavalise andmebaasiga?" Enamal juhul, kui võite arvata, on vastus jah, järgmisel lihtsal põhjusel:

Kui usaldus ja vastupidavus pole probleem, ei saa blokeerimisahel midagi teha, mida tavaline andmebaas ei saa.

See on põhipunkt, milles on nii palju arusaamatusi. Salvestatavate andmetüüpide ja nende andmetega tehtavate tehingute osas ei tee plokiahelad midagi uut. Ja lihtsalt selguse huvides laieneb see tähelepanek vaatamata nende seksikale nimele ja kuvandile ka "nutikatele lepingutele". Nutikas leping pole midagi muud kui tükk arvutikoodi, mis töötab plokiahela igas sõlmes - aastakümneid vana tehnoloogia nimega salvestatud protseduurid teeb sama ka tsentraliseeritud andmebaaside puhul. (Samuti ei saa te kasutada plokiahelat, kui see kood seda vajab algatama interaktsioonid välismaailmaga.)

Tõde plokiahelate kohta on see, et kuigi neil on mõningaid eeliseid, on neil ka oma varjuküljed. Teisisõnu, nagu enamik tehnoloogiaotsuseid, langeb valik plokiahela ja tavalise andmebaasi vahel mitme kompromissini. Kui teid hoiab pimestus ja müra kurdiks, ei tee te tõenäoliselt seda valikut objektiivselt. Nii et ma loodan, et järgmine juhend võib aidata.

Disintermediatsioon: eelis plokiahelad

Plokiahela põhiväärtus võimaldab andmebaasi otse jagada üle usalduse piiride, ilma et oleks vaja keskadministraatorit. See on võimalik, kuna plokiahelatehingud sisaldavad nende endi kehtivuse tõendeid ja volituste tõendeid, selle asemel, et nende piirangute jõustamiseks nõuda mingit tsentraliseeritud rakendusloogikat. Seepärast saab tehinguid kontrollida ja töödelda iseseisvalt mitme „sõlme” abil, kusjuures plokiahel toimib konsensusmehhanismina, et tagada nende sõlmede sünkroonimine.

Miks on sellel eristamisel väärtus? Sest isegi kui andmebaas on vaid bitti ja baiti, see on ka käegakatsutav asi. Andmebaasi sisu salvestatakse konkreetse arvutisüsteemi mällu ja kettale ning igaüks, kellel on sellele süsteemile piisav juurdepääs, võib selles olevad andmed hävitada või rikkuda. Selle tulemusel muutuvad teie andmed sõltuvaks ka andmebaasist, kui usaldate oma andmed tavalisse andmebaasi inim- organisatsioon, kus see andmebaas asub.

Nüüd on maailm täidetud selle usalduse pälvinud organisatsioonidega - valitsused ja pangad (enamasti), ülikoolid, ametiühingud ja isegi eraettevõtted nagu Google ja Facebook. Enamasti, eriti arenenud maailmas, toimivad need ülihästi. Usun, et minu häält on alati loetud, ükski pank pole kunagi minu raha varastanud ja ma pean veel leidma viisi, kuidas paremate hinnete eest maksta. Milles siis probleem on? Kui organisatsioon kontrollib olulist andmebaasi, vajab see ka hulga inimesi ja protsesse, et vältida selle andmebaasi rikkumist. Inimesed vajavad palkamist, protsessid tuleb välja töötada ja see kõik võtab palju aega ja raha.

Nii pakuvad plokiahelad võimalust asendada need organisatsioonid hajutatud andmebaasiga, mis on lukustatud nutika krüptograafia abil. Nagu nii palju, mis on varem tulnud, kasutavad nad arvutisüsteemide üha suurenevat võimekust, et pakkuda uut viisi inimeste asendamiseks koodidega. Ja kui see on kirjutatud ja silutud, kipub kood olema kohutavalt palju odavam.

Konfidentsiaalsus: eelistada tsentraliseeritud andmebaase

Nagu mainisin, kontrollib ja töötleb plokiahela iga sõlme iseseisvalt iga tehingut. Sõlm saab seda teha, kuna tal on täielik nähtavus: (a) andmebaasi praeguses olekus, (b) tehinguga taotletud muutmises ja (c) digitaalses allkirjas, mis tõendab tehingu päritolu. See on kahtlemata nutikas uus viis andmebaasi ülesehitamiseks ja see tõesti töötab. Kus siis saak on? Paljude rakenduste jaoks, eriti rahaliste vahendite jaoks, on kõigi sõlmede täielik läbipaistvus absoluutne tehingute tapja.

Kuidas väldivad tavalistele andmebaasidele üles ehitatud süsteemid seda probleemi? Nii nagu plokiahelad, piiravad nad ka tehinguid, mida konkreetsed kasutajad saavad teha, kuid need piirangud kehtestatakse üks keskne asukoht. Selle tulemusel peab andmebaasi täielik sisu olema nähtav ainult selles asukohas, mitte mitmes sõlmes. Andmete lugemise taotlused läbivad ka selle keskasutuse, kes võib need taotlused vastavalt vajadusele heaks kiita või tagasi lükata. Teisisõnu, kui tavalist andmebaasi kontrollitakse ja kirjutuskontrollitav, plokiahelat saab juhtida ainult kirjutamise kaudu.

Ausalt öeldes on selle probleemi leevendamiseks saadaval palju strateegiaid. Need ulatuvad lihtsatest ideedest, nagu näiteks tehingute tegemine mitme ahelaga aadressil, kuni keerukate krüptograafiatehnikateni, näiteks konfidentsiaalsed tehingud ja null teadmiste tõestusmaterjalid (praegu arendamisel). Sellest hoolimata, mida rohkem teavet soovite ahelas peita, seda suuremat arvutuslikku koormust maksate tehingute genereerimiseks ja kontrollimiseks. Ja hoolimata sellest, kuidas need tehnikad arenevad, ei peksa nad kunagi andmete peitmise lihtsat ja arusaadavat meetodit.

Vastupidavus: eelised ahelate ees

Plokiahelaga töötavate andmebaaside teine ​​eelis on äärmine rikketolerants, mis tuleneb nende sisseehitatud koondamisest. Iga sõlm töötleb iga tehingut, seega pole ükski üksik sõlme andmebaasi kui terviku jaoks ülioluline. Sarnaselt ühenduvad sõlmed üksteisega tihedalt üksteisega, nii et paljud sideühendused võivad ebaõnnestuda enne, kui asjad seisavad. Plokiahel tagab, et alla läinud sõlmed saavad alati järelejäänud tehingutest järele jõuda.

Nii et kuigi on tõsi, et tavalised andmebaasid pakuvad selleks palju tehnikaid replikatsioon, viivad plokiahelad selle täiesti uuele tasemele. Alustuseks pole konfigureerimist vaja - lihtsalt ühendage mõned plokiahela sõlmed omavahel ja need hoiavad end automaatselt sünkroonis. Lisaks saab sõlme vabalt võrku lisada või eemaldada, ilma et neid ette valmistataks ja tagajärgi oleks. Lõpuks saavad välised kasutajad oma tehinguid saata ükskõik millisesse sõlme või korraga mitmesse sõlme ning need tehingud levivad automaatselt ja sujuvalt kõigile teistele.

See vastupidavus muudab andmebaaside kättesaadavuse ökonoomsust. Regulaarsete andmebaaside abil saavutatakse kõrge kättesaadavus kalli infrastruktuuri ja katastroofiabi. Esmane andmebaas töötab tipptasemel riistvaral, mida hoolikalt jälgitakse probleemide osas, kusjuures tehingud kopeeritakse varundussüsteemi, mis asub teises füüsilises asukohas. Kui esmane andmebaas ebaõnnestub (nt elektrikatkestuse või katastroofilise riistvararikke tõttu), viiakse tegevus automaatselt varukoopiale, mis saab uueks primaarseks. Kui ebaõnnestunud süsteem on fikseeritud, on see järjestatud, et vajaduse korral toimida uue varukoopiana. Kuigi see kõik on teostatav, on selle kalliks saamine kulukas ja teadaolevalt keeruline.

Selle asemel, mis oleks, kui meil oleks 10 plokiahela sõlme, mis töötaksid maailma erinevates osades, kõik kauba riistvaral? Need sõlmed oleksid tihedalt üksteisega ühendatud, jagades tehinguid vastastikuse eksperdi põhimõttel ja kasutades konsensuse tagamiseks plokiahelat. Tehinguid genereerivad lõppkasutajad ühendavad (ütleme) 5 neist sõlmedest, nii et pole vahet, kas mõni sideühendus kaob. Ja kui üks või kaks sõlme ühelgi päeval täielikult ebaõnnestub, ei tunne keegi midagi, sest eksemplare on ringi liikumiseks ikka rohkem kui piisavalt. Nagu juhtub, on see odavate süsteemide ja suure koondamise kombinatsioon just see, kuidas Google ehitas oma otsingumootori nii odavalt. Plokiahelad saavad sama teha ka andmebaaside puhul.

Toimivus: eelis tsentraliseeritud andmebaasid

Plokiahelad on alati tsentraliseeritud andmebaasidest aeglasemad. See pole mitte ainult see tänane plokiahelad on aeglased, kuna tehnoloogia on uus ja optimeerimata, kuid see on selle tulemus loodus plokkkettidest ise. Näete, et tehingute töötlemisel peab plokiahel tegema samu asju nagu tavaline andmebaas, kuid sellega kaasneb kolm lisakoormust:

1. Allkirja kontrollimine. Iga blockchain-tehing peab olema digitaalselt allkirjastatud, kasutades avaliku ja erasektori krüptograafiaskeemi nagu ECDSA. See on vajalik, kuna tehingud levivad sõlmede vahel üksteisega, seega ei saa nende allikat muul viisil tõestada. Nende allkirjade genereerimine ja kontrollimine on arvutuslikult keeruline ja moodustab meie toodete sarnaste toodete peamise kitsaskoha. Seevastu tsentraliseeritud andmebaasides, kui ühendus on loodud, ei ole vaja iga seda puudutavat päringut eraldi kontrollida.
2. Konsensuse mehhanismid. Hajutatud andmebaasis, näiteks plokiahelas, tuleb pingutada selle nimel, et võrgu sõlmed jõuaksid üksmeelele. Sõltuvalt kasutatavast konsensuse mehhanismist võib see hõlmata märkimisväärset edasi-tagasi suhtlemist ja / või kahvlite ja nende tagajärgedega tagasipöördumist. Kuigi on tõsi, et tsentraliseeritud andmebaasid peavad võitlema ka vastuoluliste ja katkestatud tehingutega, on need palju vähem tõenäolised, kui tehingud on järjekorras ja töödeldakse ühes kohas.
3. Koondatavus. See ei puuduta üksiku sõlme jõudlust, vaid kogu arvutust, mida plokiahel nõuab. Kui tsentraliseeritud andmebaasid töötlevad tehinguid üks (või kaks) korda, siis plokiahelas peab neid töötlema kõik võrgu sõlmed iseseisvalt. Nii et sama lõpptulemuse nimel tehakse palju rohkem tööd.

Alumine rida

Loomulikult on plokiahelate ja tavaliste andmebaaside võrdlemiseks ka muid viise. Võiksime rääkida koodubaasi küpsusest, arendaja atraktiivsusest, ökosüsteemi laiusest ja muust. Kuid ükski neist teemadest pole omane tehnoloogiale endale. Nii et kui tegemist on pikaajalise otsusega plokiahela kasutamise kohta, on küsimus järgmine: mis on minu kasutamisjuhtumi jaoks olulisem? Lahkumatus ja vastupidavus? Või konfidentsiaalsus ja toimivus?

Selles lihtsas valguses uurides on paljud arutusel olevad kasutusjuhud pole mõtet. Suurim probleem kipub olema konfidentsiaalsus. Ägedalt konkurentsitihedal turul osalejad eelistavad loomulikult tsentraliseeritud andmebaasi privaatsust, selle asemel, et üksteisele oma tegevust avaldada. See kehtib eriti juhul, kui usaldusväärne keskpartei on juba olemas ja suudab pakkuda neutraalset territooriumi, kus see andmebaas võib asuda. Ehkki selle keskse pakkujaga võib kaasneda teatavaid kulusid, on see enam kui õigustatud säilitatud privaatsuse väärtusega. Ainuke motivaator keti üleminekuks oleks agressiivne uus regulatsioon.

Sellegipoolest on plokiahelatel tugevad kasutusjuhtumid, kus lahusus ja usaldusväärsus on olulisemad kui konfidentsiaalsus ja toimivus. Kirjutan neist rohkem järgmises postituses, kuid kõige lootustandvamad valdkonnad, mida seni oleme näinud, on: (a) ettevõtete vahelised auditijäljed, (b) päritolu jälgimine ja (c) kerge finantssüsteemid. Kõigil kolmel juhul oleme leidnud inimesi, kes toetuvad MultiChainile ja millel on selge vaade juurutamisele, mitte ainult uudishimu ja katsetamine. Nii et kui otsite viise, kuidas plokiahelad saaksid teie ettevõttele tõelist lisaväärtust anda, võiksid need olla hea koht alustamiseks.

Palun postitage kõik kommentaarid LinkedIn.