Kuidas märgata poolküpsetatud klotsiketti

Kui ketid ja klotsid ei täida kasulikku eesmärki

Umbes 18 kuud on möödas ajast, kui finantssektor ärkas massiliselt lubatud plokiahelate ehk üldisemalt terminit "hajutatud pearaamatute" võimalustele. Pärast seda on toimunud tsunami tegevus, sealhulgas uurimisaruanded, strateegilised investeeringud, pilootprojektid ja paljude konsortsiumide moodustamine. Keegi ei saa süüdistada pangandusmaailma, et see ei võta selle tehnoloogia potentsiaali tõsiselt.

Loomulikult on plokiahelaprojektide plahvatuslik kasv ajendanud plokiahela platvormide väljatöötamist, millele need projektid on üles ehitatud. Näiteks meie toode MultiCin on viimase aasta jooksul kolmekordistunud, olenemata sellest, kas mõõdame veebiliiklust, igakuist allalaadimist või ärilisi päringuid. Ja loomulikult on palju muid platvorme, nt BigChainDB, kett, Corda, Autorid, Elements, Eris, Kangas, Ethereum (kasutatakse suletud võrgus), HydraChain ja Openchain. Rääkimata veel rohkematest idufirmadest, kes on välja töötanud mingisuguse plokiahela platvormi, kuid pole seda avalikult kättesaadavaks teinud.

Ettevõtetele, kes soovivad uut tehnoloogiat uurida ja mõista, on valiku rohkus üldiselt hea. Kuid plokiahelate puhul, mis on endiselt lõdvalt määratletud ja halvasti mõistetavad, on sellel küllusesarvel märkimisväärne varjukülg: paljud saadaolevad plokiahela platvormid ei tegele tegelikult põhiprobleemiga, mille lahendamiseks need on mõeldud. Ja mis see probleem on? Lubage mul lühidalt tsiteerida video määratlus autor Richard Gendal Brown, tehnikadirektor R3, täielikult:

Jaotatud pearaamat on süsteem, mis võimaldab osapooltel, kes üksteist täielikult ei usalda, jõuda üksmeelele ühiste faktide olemasolu, olemuse ja arengu osas, ilma et nad peaksid tuginema täielikult usaldusväärsele tsentraliseeritud kolmandale osapoolele.

Äärmusliku näitena kaaluge nööriga kokku seotud legoklotse. Kui me kasutame selle moeeseme kirjeldamiseks terminit "plokk kett", siis kes ütleb, et me ei kirjelda seda täpselt? Ja veel, see konkreetne plokkide ahel ei aita mitmel osapoolel andmebaasi turvaliselt ja vahetult ilma keskse vahendajata jagada. Samamoodi teevad paljud "plokiahela" platvormid midagi, mis on seotud plokkide ahelatega, kuid neil puuduvad ka vajalikud omadused, mis oleksid peer-to-peer andmebaasi aluseks.

Veel üks plokkide ahel, mis andmebaasi jagamisel ei aita - allikas.

Minimaalne elujõuline plokiahel

Hajutatud pearaamatu põhinõuete mõistmiseks aitab see selgitada, mille poolest need süsteemid erinevad tavalistest andmebaasidest, mida juhib üks olem. Näiteks vaatleme lihtsat süsteemi, mille abil saab jälgida, kellele konkreetse ettevõtte aktsiad kuuluvad. Pearaamatus, nagu see on andmebaasis rakendatud, on iga omaniku jaoks üks rida, mis sisaldab kahte veergu: omaniku identifikaator, näiteks tema nimi, ja vastav osade kogus.

Siin on kuus otsustavat viisi, kuidas see süsteem võib oma kasutajaid ebaõnnestuda:

• Võltsimine: aktsiate ülekandmine ühelt isikult teisele ilma saatja loata.
• tsensuur: Keeldumine täitmast kellegi taotlust osa aktsiaid mujale võõrandada.
• Ümberpööramine: mingil hetkel minevikus toimunud ülekande tagasivõtmine.
• Ebaseaduslikkus: Aktsiate koguhulga muutmine süsteemis ilma emitendi vastava tegevuseta.
• Vasturääkivus: erinevate kasutajate päringutele erinevate vastuste andmine.
• Seisuaeg: ei vasta üldse sissetulevatele teabepäringutele.

Kõigi nende võimaluste tõttu peavad aktsionärid säilitama kõrge usalduse selle vastu, kes nende nimel seda pearaamatut haldab. Seda usaldust vääriva organisatsiooni loomine ja juhtimine toob kaasa märkimisväärseid probleeme ja kulusid.

Plokiahelad või hajutatud pearaamatud eemaldavad vajaduse seda tüüpi keskandmebaasi operaatori järele, võimaldades andmebaasi kasutajatel üksteisega otse suhelda. Meie näites võivad aktsionärid oma aktsiaid turvaliselt hoida plokiahelas, mida nad ühiselt haldavad, ja teha üksteisele selle ahela kaudu koheselt ülekandeid. (Miinuseks on konfidentsiaalsuse märkimisväärne kaotus keti kasutajate vahel, mida me siin ei käsitle, kuid ma olen seda varem käsitlenud arutati pikalt.)

Kõik see toob meid tagasi plokiahela platvormide küsimuse juurde. Selleks, et olla võrdväärsete andmebaaside jagamise elujõuline alus, peab plokiahel kaitsma oma osalejaid kõigi kuue tüüpi andmebaasitõrgete eest – võltsimine, tsensuur, tühistamine, ebaseaduslikud tehingud, ebajärjekindlus ja seisakud. Kuigi paljud turul olevad tooted vastavad neile nõuetele, on üsna paljud neist puudulikud. Ma nimetan neid plokiahelaid "poolküpseks", sest need võivad adresseerida mõned riskidest, kuid mitte kõigist. Vähemalt mõnes mõttes jäävad andmebaasi kasutajad sõltuma üksiku osaleja heast käitumisest, mis on just see stsenaarium, mida me tahame vältida.

Neid poolküpseid plokiahelaid on palju erinevaid, kuid kolm arhetüüpi paistavad silma kui kõige levinumad või ilmsemad. Ma ei hakka üksikuid tooteid nimetama, sest noh, ma ei taha solvata. Plokiahela idufirmade kogukond on piisavalt väike, et enamik meist tunneb üksteist konverentside ja muude koosolekute kaudu ning suhtlus kipub olema positiivne. Sellegipoolest, kui plokiahelad (kasulike peer-to-peer andmebaaside tähenduses) hakkavad kunagi esile kerkima ühtse tootekategooriana, on oluline teha vahet poolikutel ja reaalsetel lahendustel.

Üks validaator blockchain

Üks muster, mida oleme paar korda näinud, on plokiahel, milles ainult üks osaleja saab genereerida plokke, milles tehingud kinnitatakse. Tehingud saadetakse sellesse ühte sõlme, selle asemel, et neid edastada kogu võrku, nii et nende vastuvõtmine sõltub pigem selle osapoole kapriisidest kui mingist enamuse konsensusest. Siiski, kui see keskne osapool on ploki üles ehitanud, edastatakse see teistele võrgu sõlmedele, kes saavad iseseisvalt kontrollida siseste tehingute kehtivust ja salvestada uue ploki lokaalselt ja püsivalt.

Meie kuue andmebaasi tõrgete vormi juurde naasmiseks pole seda tüüpi plokiahel kaugeltki kasutu. Tehingud peab olema digitaalselt allkirjastatud isik, kelle vahendeid need liiguvad, nii et keskerakond ei saa neid võltsida. Neid ei saa tagasi pöörata, kuna iga sõlm säilitab oma ahela koopia. Ja tehingud ei saa teha ebaseaduslikke toiminguid, nagu varade loomine tühjast ilmast, sest iga sõlm kontrollib iseseisvalt iga tehingu õigsust. Lõpuks säilitab iga sõlm andmebaasist oma koopia, nii et selle sisu on alati lugemiseks saadaval.

Kahjuks neljast kuuest ei piisa. Valideerimissõlm saab üksikuid tehinguid kergesti tsenseerida, keeldudes neid enda loodud plokkidesse kaasamast. Isegi kui selle sõlme operaatorid on ausad, võib süsteemi- või sidetõrge muuta selle kättesaamatuks, mistõttu kogu tehingute töötlemine peatub. Lisaks võib valideeriv sõlm sõltuvalt seadistusest olla võimeline edastama plokiahela erinevaid versioone erinevatele osalejatele. Tsensuuri ja järjepidevuse mõttes sisaldab andmebaas endiselt ühte tõrkepunkti, millele kõik teised sõlmed toetuvad.

Üks platvorm pakub selle skeemi keerdumist, kus plokid genereerib tsentraalselt üks sõlm, kuid teiste määratud sõlmede kvoorum allkirjastab need konsensuse näitamiseks. Ebajärjekindluse ohu osas aitab see kindlasti kaasa. Kvoorumis olevad sõlmed annavad oma allkirjad ainult ühele plokiahela versioonile, mida võib seetõttu pidada autoriteetseks. Sellegipoolest ei saa kvoorumi sõlmed aidata, kui plokigeneraator tehinguid tsenseerib või Interneti-ühenduse katkeb. Lõppkokkuvõttes kasutab seda tüüpi plokiahel ikka jaoturi ja kodara arhitektuuri, mitte peer-to-peer võrku.

Jagatud oleku plokiahel

Tehniliselt öeldes on plokiahelate ja traditsioonilisemate hajutatud andmebaaside, nagu Cassandra ja MongoDB, vahel palju sarnasusi. Mõlemal juhul saab tehinguid algatada võrgu mis tahes sõlm ja need peavad jõudma kõigi teiste sõlmedeni osana konsensusest andmebaasi arendusoleku kohta. Nii plokiahelad kui ka hajutatud andmebaasid peavad toime tulema latentsusega (sideviivitused, mis tulenevad sõlmedevahelisest kaugusest) ja võimalusega, et mõned sõlmed ja/või sideühendused katkevad.

Hajutatud andmebaasid on olnud juba mõnda aega, nii et igal plokiahela platvormi arendajal oleks hea mõista oma konsensusalgoritme ja strateegiaid, mida nad kasutavad tehingute globaalseks tellimiseks ja konfliktide lahendamiseks. Sellegipoolest on oluline võrdlust mitte liiga kaugele viia, sest plokiahelad peavad võitlema olulise lisaväljakutsega – usaldada andmebaasi sõlmede vahel. Kui hajutatud andmebaasid keskenduvad mastaapsuse, töökindluse ja suure jõudluse pakkumisele ühe organisatsiooni piires, tuleb plokiahelad ohutuks kasutamiseks ümber kujundada. traavers need piirid.

Meie kuue andmebaasiriski tüübi juurde naasmiseks peab hajutatud andmebaasi sõlm muretsema vaid seisaku pärast, st võimaluse pärast, et teised sõlmed muutuvad kättesaamatuks. Sõlmed võivad julgelt eeldada, et kõik võrgus olevad tehingud ja sõnumid on kehtivad ega ole seotud võltsimise, tsensuuri, tühistamise, ebaseaduslikkuse või ebajärjekindlusega. Nende halvim probleem on tegeleda kahe samaaegse, kuid kehtiva tehinguga, mis on algatatud erinevates sõlmedes ja mis mõjutavad samu andmeid. Nende konfliktide lahendamine pole sugugi triviaalne, kuid see on siiski palju lihtsam kui muretsemine "Bütsantsi vead“, kus mõned sõlmed tegutsevad tahtlikult, et häirida teiste toimimist.

Andmebaasi saab jagada ainult turvaliselt üle usalduspiirid, kui sõlmed suhtuvad kogu võrgus toimuvasse tegevusse teatud kahtlusega. Näiteks iga tehing, mis muudab andmebaasi, peab olema individuaalselt digitaalselt allkirjastatud, kuna peer-to-peer-arhitektuuris pole muud võimalust selle tegelikku päritolu teada saada. Samamoodi tuleb iga sissetulevat sõnumit, näiteks uue ploki väljakuulutamist, sisu ja konteksti kriitiliselt hinnata. Erinevalt hajutatud andmebaasidest ei tohi sõlmed koheselt ja vahetult muuta teise sõlme olekut.

Mõned "plokiahela" platvormid on välja töötatud, alustades hajutatud andmebaasist ja lisades sellele mõned funktsioonid, et muuta need plokiahelalisemaks. Näiteks rühmitades tehingud plokkideks ja salvestades nende plokkide räsi (digitaalsed sõrmejäljed) andmebaasi, on nende eesmärk lisada muutumatuse vorm. Kuid kui iga sõlm ei saa olla kindel, et selle räsiloendit ei saa teine ​​sõlm muuta, on seda tüüpi muutumatust lihtne mängida. Tavaline vastus sellele kriitikale on see, et iga turvaprobleemi saab lahendada piisava aja ja kodeerimisega. Kuid see on pigem nagu mõne vangi lagedal väljal kinnihoidmine ja nende põgenemine juhtmete ja kraavide abil. Palju turvalisem on kasutada spetsiaalselt ehitatud betoonkonstruktsioone, mille uksed on lukus ja aknad trellitatud.

Üks pilve plokiahel

Kõige kummalisem nähtus, mida ma näinud olen, on plokiahela platvormid, millele pääseb juurde ainult nende arendaja pilvepõhise platvormi kui teenuse kaudu. Et olla selge, me ei räägi mõnest plokiahelas osalejast valimine oma sõlmede majutamiseks valitud pilveteenuse pakkujal, näiteks Microsoft Azure or Amazon Web Services. Pigem on see plokiahel, mis suudab ainult pääseda juurde API-de kaudu, mida paljastavad seda "hostiva" ettevõtte serverid.

Tõestame argumendi huvides, et tsentraliseeritud plokiahela pakkujal on tõesti rühm sõlme, mis töötavad tema kontrolli all. Mis vahe on sellel süsteemi kasutajatele, kes saadavad API päringuid ja saavad vastuseid? Osalejad ei saa kuidagi hinnata, kas kõigi tehingud on tehtud ilma tegematajätmiste või vigadeta. Võib-olla töötab keskteenus tõrkeid või võib-olla tsenseerib või tühistab see teatud tehinguid teadlikult. Ja kui arvate, et plokiahela pakkujal pole põhjust seda teha, siis miks mitte kasutada neid hoopis tavalise tsentraliseeritud andmebaasi majutamiseks? Saate küpsema ja parema jõudlusega toote ja te ei pea kannatama uute tehnoloogiatega töötamise riskidest. Lühidalt, tsentraliseeritud plokiahelad on umbes sama kasulikud kui Lego nööril.

Müsteeriumi lahendamine

Oleme nüüd näinud kolme tüüpi platvorme, mis turustavad end "plokiahelatena" ja kasutavad tõepoolest teatud määral plokkide ahelat, kuid mis ei lahenda põhiprobleemi, mille jaoks need süsteemid on loodud. Kokkuvõtteks – see võimaldab ühtainsat andmebaasi turvaliselt ja vahetult jagada üle usalduspiiride ilma keskse vahendajata.

Lisaks sellele omapärasele nähtusele osutamisele on minu arvates õpetlik mõelda, mis selle aluseks võib olla. Miks ehitavad nii paljud plokiahela idufirmad tooteid, mis ei täida selle tehnoloogia lubadusi, saavutades sageli ainult traditsioonilised tsentraliseeritud või hajutatud andmebaasid? Miks raiskavad nii paljud andekad inimesed nii palju aega?

Ma näen kahte peamist selgituste klassi – tehnilist ja kaubanduslikku. Alustuseks tehnilistest aspektidest on üsna keeruline luua hajutatud konsensussüsteeme, mis taluvad ühe või mitme sõlme ettearvamatul viisil pahatahtlikku käitumist. MultiChaini puhul tegime mõningase pettuse, kasutades lähtepunktina bitcoini lahingukindlat viiterakendust ja asendades seejärel töötõenduse struktuuriliselt sarnase konsensusalgoritmiga, mida nimetatakse "kaevandamise mitmekesisuseks". Meeskonnad, kes arendavad plokiahela sõlme nullist, peavad sügavalt mõtlema asünkroonsetele ja võistlevatele protsessidele – kombinatsioonile, milles vähestel programmeerijatel on kogemusi. Ma mõistan kindlasti kiusatust kasutada otseteed, näiteks kasutada plokkide genereerimiseks ühte sõlme, kasutada olemasolevat hajutatud andmebaasi või käivitada ainult sõlmed usaldusväärses keskkonnas. Nende hulgast ühegi valimine muudab arendajate elu kahtlemata lihtsamaks, isegi kui see õõnestab kogu mõtet.

Mis puutub ärilistel põhjustel, siis tundub, et iga idufirma läheneb plokiahela võimalusele erineva nurga alt. Siin Coin Sciencesis keskendume (andmebaasi)tarkvara müüjaks saamisele, seega levitame MultiChaini tasuta, arendades samal ajal lisafunktsioonidega esmaklassilist sõlme. Teised idufirmad soovivad tellimisteenuseid müüa, seega loovad nad loomulikult platvormi, mida kliendid ise hostida ei saa. Mõned loodavad plokiahelat tsentraalselt juhtida või aidata oma partneritel seda teha (veider ambitsioon vahendustehnoloogia jaoks!) ja neid tõmbavad loomulikult konsensusalgoritmid, mis põhinevad ühel sõlmel. Ja lõpuks on ettevõtteid, kelle esmane eesmärk on müüa konsultatsiooniteenuseid, mille puhul nende platvorm ei pea üldse toimima, kuni nende veebisait toob mõne suurkliendi.

Võib-olla on teine ​​probleem see, et mõnda plokiahela ettevõtet juhivad inimesed, kes kahtlemata on talentidest pakatavad, kuid kellel puudub sügav arusaam tehnoloogiast endast. Uut valdkonda loovates idufirmades on ilmselt ülioluline, et strateegilisi otsuseid langetaks inimesed, kes mõistavad selle valdkonna olemust ja selle erinevust varasemast. Paistab, et mitte vähesed plokiahela idufirmad on end nurka maalinud, järgides tootevisiooni, mis on nende klientide jaoks atraktiivne, kuid mida ei saa tegelikult ehitada.

Kuidas vältida plokiahelate kasutajana neid eksitusi? Konkreetset plokiahela platvormi hinnates küsige kindlasti, kas see vastab kuuele turvalise peer-to-peer andmebaasi jagamise nõudele: seisakute ja ebakõlade vältimine, samuti tehingute võltsimine, tsensuur, tühistamine ja ebaseaduslikkus. Ja hoiduge selgitustest, mis koosnevad liigsest pomisemisest või kätega vehkimisest – need tähendavad ilmselt, et vastus on eitav.

Palun postitage kõik kommentaarid LinkedIn.

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