Hogyan lehet észlelni egy félig sült blokkláncot

Amikor a láncok és a blokkok nem szolgálnak hasznos célt

Körülbelül 18 hónap telt el azóta, hogy a pénzügyi szektor tömegesen ébredt rá az engedélyezett blokkláncok, vagy az általánosabb kifejezéssel, az „elosztott főkönyvek” lehetőségeire. Az azóta eltelt időszakban a tevékenység cunamija zajlott, beleértve a kutatási jelentéseket, a stratégiai befektetéseket, a kísérleti projekteket és számos konzorcium megalakulását. Senki sem vádolhatja a bankvilágot azzal, hogy nem veszi komolyan a technológiában rejlő lehetőségeket.

Természetesen a blokklánc projektek robbanásszerű növekedése ösztönözte az engedélyezett blokklánc platformok fejlesztését, amelyekre ezek a projektek épülnek. Például a mi termékünk MultiChain az elmúlt évben megháromszorozódott a használat, akár a webes forgalmat, akár a havi letöltéseket, akár a kereskedelmi megkereséseket mérjük. És persze sok más platform is létezik, mint pl BigChainDB, Lánc, Corda, Credits, Elemek, Eris, Szövet, Ethereum (zárt hálózatban telepítve), HydraChain és a Openchain. Nem beszélve még több startupról, akik kifejlesztettek valamilyen blokklánc platformot, de nem tették nyilvánosan elérhetővé.

Azon vállalatok számára, amelyek egy új technológiát szeretnének felfedezni és megérteni, általában jó dolog a választék bősége. A blokkláncok esetében azonban, amelyek továbbra is lazán definiálhatók és rosszul értelmezhetők, ennek a bőségszarunak van egy jelentős hátulütője is: a rendelkezésre álló „blokklánc” platformok közül sok valójában nem foglalkozik azzal az alapvető problémával, amelyet meg kell oldani. És mi ez a probléma? Engedjék meg, hogy röviden idézzem videó definíció Richard Gendal Brown, műszaki igazgató R3, teljesen:

Az elosztott főkönyv olyan rendszer, amely lehetővé teszi az egymásban nem teljesen megbízó felek számára, hogy konszenzusra jussanak a közös tények létezéséről, természetéről és alakulásáról anélkül, hogy egy teljesen megbízható központosított harmadik félre kellene hagyatkozniuk.

Hogy egy extrém példát vegyünk, vegyünk egy csomó Lego kockát zsinórral összekötve. Ha a „blokklánc” kifejezést használjuk ennek a divatcikknek a leírására, ki mondja azt, hogy nem írjuk le pontosan? Mégis, az adott blokklánc nem segít több felet abban, hogy biztonságosan és közvetlenül megosszák az adatbázist központi közvetítő nélkül. Hasonlóképpen sok „blokklánc” platform tesz valamit a blokkláncokkal kapcsolatban, de nem rendelkeznek a szükséges tulajdonságokkal ahhoz, hogy egy peer-to-peer adatbázis alapjául szolgáljanak.

Egy másik blokklánc, amely nem segít az adatbázis-megosztásban - forrás.

Minimálisan életképes blokklánc

Az elosztott főkönyv alapvető követelményeinek megértéséhez segít tisztázni, hogy ezek a rendszerek miben különböznek a hagyományos adatbázisoktól, amelyeket egyetlen entitás vezérel. Vegyünk például egy egyszerű rendszert annak nyomon követésére, hogy ki birtokolja egy adott cég részvényeit. Az adatbázisban megvalósított főkönyvben minden tulajdonoshoz egy sor tartozik, amely két oszlopot tartalmaz: a tulajdonos azonosítóját, például a nevét, és a megosztások megfelelő mennyiségét.

Íme hat kulcsfontosságú mód, amellyel ez a rendszer tönkreteheti a felhasználókat:

• Hamisítvány: Megosztások átvitele egyik személyről a másikra a feladó engedélye nélkül.
• Cenzúra: Megtagadása annak a kérésének, hogy egyes részvényeket máshová helyezzen át.
• megfordítás: A múltban valamikor megtörtént átvitel visszavonása.
• Törvénytelenség: A rendszerben lévő részvények teljes mennyiségének módosítása a kibocsátó megfelelő intézkedése nélkül.
• Következetlenség: Különböző válaszok adása a különböző felhasználóktól érkező megkeresésekre.
• Állásidő: Egyáltalán nem válaszol a beérkező információkérésekre.

Mindezen lehetőségek miatt a részvényeseknek magas szintű bizalmat kell fenntartaniuk abban, aki ezt a főkönyvet a nevükben kezeli. A bizalomra méltó szervezet felépítése és működtetése jelentős gondokkal és költségekkel jár.

A blokkláncok vagy az elosztott főkönyvek szükségtelenné teszik ezt a fajta központi adatbázis-üzemeltetőt, mivel lehetővé teszik az adatbázis felhasználóinak, hogy közvetlenül, peer-to-peer alapon kommunikáljanak egymással. Példánkban a részvényesek biztonságosan tarthatják részvényeiket egy blokkláncon, amelyet közösen kezelnek, és ezen a láncon keresztül azonnal átutalhatnak egymásnak. (A hátránya a bizalmasság jelentős elvesztése a lánc felhasználói között, amire itt nem térünk ki, de már korábban hosszan megvitatták.)

Mindez visszavezet minket a blokklánc platformok kérdéséhez. Annak érdekében, hogy életképes alapként szolgálhasson a peer-to-peer adatbázis-megosztáshoz, a blokkláncnak meg kell védenie résztvevőit mind a hat típusú adatbázis-meghibásodás ellen – hamisítás, cenzúra, visszavonás, illegitim tranzakciók, következetlenségek és leállások. Míg a piacon lévő termékek közül sok megfelel ezeknek a követelményeknek, ezek közül jó néhány nem teljesíti. Ezeket a blokkláncokat „félkésznek” nevezem, mert megszólíthatnak néhány ezek közül a kockázatok közül, de nem minden. Legalább bizonyos tekintetben az adatbázis felhasználói továbbra is egy-egy résztvevő jó viselkedésétől függenek, és éppen ezt a forgatókönyvet szeretnénk elkerülni.

Ezek a félkész blokkláncok tetszőleges számú változatban kaphatók, de három archetípus tűnik ki a leggyakoribb vagy legnyilvánvalóbbnak. Nem fogok megnevezni az egyes termékeket, mert nem akarom megbántani. A blokklánc startup közössége elég kicsi ahhoz, hogy a legtöbben konferenciákon és egyéb találkozókon keresztül ismerjük egymást, és az interakciók általában pozitívak. Mindazonáltal, ha a blokkláncok (a hasznos peer-to-peer adatbázisok értelmében) egy koherens termékkategóriaként fognak megjelenni, fontos különbséget tenni a félkész és a valódi megoldások között.

Az egy validátor blokklánc

Az egyik minta, amelyet néhányszor láttunk, egy blokklánc, amelyben csak egy résztvevő tudja előállítani azokat a blokkokat, amelyekben a tranzakciókat megerősítik. A tranzakciókat erre az egy csomópontra küldik, ahelyett, hogy a hálózat egészére sugároznák, így elfogadásuk inkább ennek a félnek a szeszélyétől függ, mint valamiféle többségi konszenzustól. Mégis, ha ez a központi fél felépített egy blokkot, azt a hálózat többi csomópontja felé sugározza, akik önállóan megerősíthetik a tranzakciók érvényességét, és az új blokkot helyben és tartósan rögzíthetik.

Visszatérve az adatbázis-hibák hat formájához, ez a típusú blokklánc korántsem haszontalan. A tranzakciókat annak a jogalanynak kell digitálisan aláírnia, amelynek pénzeszközeit mozgatják, így azokat a központi fél nem hamisíthatja. Ezeket nem lehet megfordítani, mert minden csomópont fenntartja a saját másolatát a láncról. A tranzakciók pedig nem hajthatnak végre olyan illegális műveleteket, mint például az eszközök légből kapott létrehozása, mivel minden csomópont függetlenül ellenőrzi az egyes tranzakciók helyességét. Végül minden csomópont fenntartja az adatbázis saját példányát, így annak tartalma mindig olvasható.

Sajnos hatból négy nem elég. Az érvényesítő csomópont könnyen cenzúrázhatja az egyes tranzakciókat azáltal, hogy megtagadja azokat az általa létrehozott blokkokba. Még ha a csomópont üzemeltetői becsületesek is, egy rendszer- vagy kommunikációs hiba elérhetetlenné teheti azt, és minden tranzakciófeldolgozás leáll. Ezenkívül a beállítástól függően az érvényesítő csomópont képes lehet a blokklánc különböző verzióit továbbítani a különböző résztvevőknek. A cenzúra és a következetesség szempontjából az adatbázis még mindig egyetlen hibapontot tartalmaz, amelyre az összes többi csomópont támaszkodik.

Az egyik platform egy csavart kínál erre a sémára, amelyben a blokkokat egyetlen csomópont központilag generálja, de a többi kijelölt csomópont kvóruma aláírja őket, jelezve a konszenzust. Az inkonzisztencia kockázata szempontjából ez minden bizonnyal segít. A határozatképességben lévő csomópontok csak a blokklánc egyetlen verziójához adják aláírásaikat, amely ezért mérvadónak tekinthető. Mindazonáltal a kvórum csomópontok nem tudnak segíteni, ha a blokkgenerátor cenzúrázza a tranzakciókat, vagy megszakad az internetkapcsolat. Végső soron az ilyen típusú blokklánc továbbra is hub-and-spoke architektúrát használ, nem pedig peer-to-peer hálózatot.

A megosztott állapotú blokklánc

Technikailag sok hasonlóság van a blokkláncok és a hagyományosabb elosztott adatbázisok, például a Cassandra és a MongoDB között. Mindkét esetben a tranzakciókat a hálózat bármely csomópontja kezdeményezheti, és az adatbázis fejlesztési állapotával kapcsolatos konszenzus részeként el kell érnie az összes többi csomópontot. Mind a blokkláncoknak, mind az elosztott adatbázisoknak meg kell birkózni a késleltetéssel (a csomópontok közötti távolságból eredő kommunikációs késleltetésekkel), valamint annak lehetőségével, hogy egyes csomópontok és/vagy kommunikációs kapcsolatok időszakosan meghibásodnak.

Az elosztott adatbázisok már egy ideje léteznek, így minden blokklánc-platform fejlesztője jól teszi, ha megérti konszenzusos algoritmusait és azokat a stratégiákat, amelyeket a tranzakciók globális megrendelésére és a konfliktusok megoldására használnak. Mindazonáltal fontos, hogy ne vigyük túl messzire az összehasonlítást, mert a blokkláncoknak egy döntő további kihívással kell megküzdeniük – a bízik az adatbázis csomópontjai között. Míg az elosztott adatbázisok a méretezhetőség, a robusztusság és a nagy teljesítmény egyetlen szervezet határain belül történő biztosítására összpontosítanak, a blokkláncokat újra kell tervezni a biztonságos működés érdekében. áthalad azokat a határokat.

Ha vissza akarunk térni a hatféle adatbázis-kockázathoz, az elosztott adatbázisban lévő csomópontoknak csak az állásidő miatt kell aggódniuk, vagyis attól, hogy más csomópontok elérhetetlenné válhatnak. A csomópontok nyugodtan feltételezhetik, hogy a hálózaton minden tranzakció és üzenet érvényes, és nem foglalkoznak hamisítással, cenzúrával, visszavonással, illegitimitással vagy inkonzisztenciával. Legrosszabb problémájuk két egyidejű, de érvényes, különböző csomópontokon kezdeményezett tranzakció kezelése, amelyek ugyanazt az adatot érintik. Ezeknek a konfliktusoknak a megoldása semmiképpen sem triviális, de még mindig sokkal könnyebb, mint azon aggódni,Bizánci hibák“, amelyben egyes csomópontok szándékosan megzavarják mások működését.

Egy adatbázist csak biztonságosan lehet megosztani át bizalmi határok, ha a csomópontok bizonyos fokú gyanakvással kezelik a hálózat összes tevékenységét. Például minden tranzakciót, amely módosítja az adatbázist, egyedileg digitálisan alá kell írni, mivel egy peer-to-peer architektúrában nincs más mód a valódi eredetpont megismerésére. Hasonlóképpen, minden bejövő üzenetet, például egy új blokk bejelentését, kritikusan meg kell vizsgálni tartalmát és kontextusát illetően. Az elosztott adatbázisokkal ellentétben a csomópontok nem képesek azonnal és közvetlenül módosítani egy másik csomópont állapotát.

Néhány „blokklánc” platformot úgy fejlesztettek ki, hogy egy elosztott adatbázisból indulnak ki, és néhány funkciót a tetejére szórtak, hogy blokkláncosabbá tegyék őket. Például azáltal, hogy a tranzakciókat blokkokba csoportosítják, és e blokkok hash-eit (digitális ujjlenyomatait) tárolják az adatbázisban, a változatlanság egy formáját kívánják hozzáadni. De hacsak az egyes csomópontok nem biztosak abban, hogy a hash-listáját egy másik csomópont nem tudja módosítani, ez a fajta megváltoztathatatlanság könnyen játszható. A szokásos válasz ezekre a kritikákra az, hogy minden biztonsági probléma megfelelő idővel és kódolással megoldható. De ez inkább olyan, mintha néhány foglyot egy nyílt terepen tartanánk, és elhárítódrótokkal és árkokkal próbálnák megakadályozni a szökést. Sokkal biztonságosabb olyan speciálisan épített betonszerkezetet használni, amelynek ajtói zárva vannak, ablakai pedig rácsosak.

Az egyetlen felhő blokklánc

Messze a legfurcsább jelenség, amit láttam, azok a blokklánc-platformok, amelyek csak a fejlesztőjük felhőalapú platformján keresztül érhetők el szolgáltatásként. Az egyértelműség kedvéért nem a blokklánc egyes résztvevőiről beszélünk választja hogy csomópontjaikat a választott felhőszolgáltatójukon tárolják, például Microsoft Azure or Az Amazon Web Services. Inkább ez egy blokklánc, amely képes csak az azt „hosztoló” vállalat szerverei által közzétett API-kon keresztül érhető el.

Az érvelés kedvéért engedjük meg, hogy egy központosított blokklánc-szolgáltatónak valóban van egy csomópontcsoportja, amely az irányítása alatt fut. Milyen különbséget jelent ez a rendszer felhasználói számára, akik API kéréseket küldenek és válaszokat kapnak? A résztvevőknek nincs módjuk felmérni, hogy mindenki tranzakciója mulasztás vagy hiba nélkül történt-e. Lehet, hogy a központi szolgáltatás hibásan működik, esetleg szándékosan cenzúráz, vagy visszafordít bizonyos tranzakciókat. És ha úgy gondolja, hogy a blokklánc-szolgáltatónak nincs oka erre, miért ne használja őket egy szokásos központi adatbázis tárolására? Érettebb terméket kap, jobb teljesítménnyel, és nem éri el az új technológiákkal való munkavégzés kockázatait. Röviden, a központosított blokkláncok körülbelül olyan hasznosak, mint a Lego egy zsinóron.

A rejtély megfejtése

Jelenleg három platformtípust láttunk, amelyek „blokkláncként” forgalmazzák magukat, és valóban használnak egy blokkláncot, de nem oldják meg azt az alapvető problémát, amelyre ezeket a rendszereket tervezték. Összefoglalva, ez lehetővé teszi egyetlen adatbázis biztonságos és közvetlen megosztását a bizalom határain keresztül, központi közvetítő nélkül.

Eltekintve attól, hogy rámutatunk erre a különös jelenségre, azt hiszem, tanulságos átgondolni, mi állhat ennek hátterében. Miért olyan sok blokklánc startup épít olyan termékeket, amelyek nem teljesítik ennek a technológiának az ígéretét, és gyakran nem érnek el többet a hagyományos központosított vagy elosztott adatbázisoknál? Miért vesztegeti az idejét annyi tehetséges ember?

A magyarázatnak két fő osztályát látom: műszaki és kereskedelmi. Kezdjük a technikaival, meglehetősen bonyolult olyan elosztott konszenzusos rendszereket létrehozni, amelyek elviselik egy vagy több csomópont előre nem látható módon rosszindulatú viselkedését. A MultiChain esetében némileg csaltunk, amikor a bitcoin harcedzett referencia implementációját használtuk kiindulópontnak, majd a munka bizonyítását egy szerkezetileg hasonló konszenzusos algoritmussal, a „bányászati ​​diverzitás”-val helyettesítettük. A blokklánc csomópontot a semmiből fejlesztő csapatoknak mélyen át kell gondolniuk az aszinkron és a kontradiktórius folyamatokat – ez a kombináció, amelyről kevés programozónak van tapasztalata. Határozottan meg tudom érteni azt a kísértést, hogy parancsikonokat használjunk, például egyetlen csomópontot használjunk blokkok generálására, vagy egy meglévő elosztott adatbázison való visszahelyezést, vagy csak a csomópontok futtatását megbízható környezetben. Ezek bármelyikének kiválasztása kétségtelenül megkönnyíti a fejlesztők életét, még akkor is, ha ez aláássa a lényeget.

Ami a kereskedelmi okokat illeti, úgy tűnik, hogy minden startup más szemszögből közelíti meg a blokklánc-lehetőséget. Itt, a Coin Sciencesnél arra koncentrálunk, hogy (adatbázis)szoftver-szállítóvá váljunk, ezért ingyenesen terjesztjük a MultiChaint, miközben egy prémium csomópontot fejlesztünk további funkciókkal. Más startupok előfizetéses szolgáltatásokat akarnak eladni, így természetesen olyan platformot fognak kiépíteni, amelyet az ügyfelek maguk nem tudnak üzemeltetni. Vannak, akik abban reménykednek, hogy központilag irányíthatnak egy blokkláncot, vagy segíthetnek partnereiknek ebben (furcsa ambíció a közvetítő technológiát illetően!), és természetesen vonzódnak a konszenzusos algoritmusokhoz, amelyek egyetlen csomópontra támaszkodnak. És végül vannak olyan cégek, amelyek elsődleges célja a tanácsadási szolgáltatások értékesítése, ilyenkor a platformjuknak egyáltalán nem kell működnie, amíg a weboldaluk behoz néhány nagy ügyfelet.

Talán egy másik probléma, hogy egyes blokklánc-cégeket olyan emberek irányítanak, akik kétségtelenül tele vannak tehetségekkel, de nem ismerik mélyen magát a technológiát. Az új területet kivívó startup vállalkozásoknál valószínűleg létfontosságú, hogy a stratégiai döntéseket olyan emberek hozzák meg, akik megértik az adott terület természetét, és azt, hogy miben különbözik a korábbiaktól. Nem kevés blokklánc startup úgy tűnik, hogy a sarokba festette magát azzal, hogy olyan terméklátást követett, amely vonzó az ügyfelek számára, de valójában nem építhető meg.

Blokkláncok felhasználójaként hogyan kerülheti el, hogy elkapjanak ezek a tévedések? Egy adott blokklánc-platform értékelésekor feltétlenül kérdezze meg, hogy az megfelel-e a biztonságos peer-to-peer adatbázis-megosztás hat követelményének: az állásidő és az inkonzisztencia megelőzése, valamint a tranzakció-hamisítás, a cenzúra, a visszavonás és az illegitimitás. És óvakodj azoktól a magyarázatoktól, amelyek túl sok motyogást vagy kézlengetést tartalmaznak – valószínűleg azt jelenti, hogy a válasz nem.

Kérjük, tegye meg észrevételeit a LinkedIn.

Forrás: https://www.multichain.com/blog/2016/12/spot-half-baked-blockchain/