A Bitcoin vs blokklánc vita befejezése

Van-e értéke egy blokkláncnak kriptovaluta nélkül?

A vita egy ideje tart, de az elmúlt hónapban komoly fellendülés történt. A feltett kérdés a következő:

Van-e értéke egy blokkláncnak kriptovaluta nélkül? És egyáltalán nevezhetők-e blokkláncoknak ezek a „tokennélküli megosztott főkönyvek”?

Szóval olvastam Bailey cikke, figyelt Tim videója, olvas ez a Nasdaq bejegyzés, követte Richardét minden szó, és még a sajátom is volt jó hangulatú vita (lásd a megjegyzéseket) a Counterparty alapítvány Chris DeRose-jával. Annyi forró levegő.

Egy dolog, amit Chris jól csinál, az, hogy levezeti a kérdést: a blokklánc gazdasági vagy számítástechnikai innováció? Ebből az következik, hogy ha a blokkláncok pusztán gazdasági innováció, akkor nincs értelme a blokkláncoknak kriptovaluták nélkül. Tehát hadd mondjam el az álláspontomat az elején:

A bitcoin blokklánc egyaránt gazdasági jellegű volt és a számítástechnikai innováció.

Megengedem, hogy az „innováció” ide tartozik a meglévő technikák új kombinációja, semmint olyasmire, aminek semmi előzménye nincs. Ez a meghatározás lehetővé teszi, hogy a világhálót innovációnak tekintsék, annak ellenére, hogy nem tett többet, mint egyesítette a hipertextet néhány létező internetes protokoll csavarjával. Ha az innováció szigorúbb meghatározását szeretné elfogadni, legyen a vendégem, de meg fog lepődni, hogy milyen kevés igazi „újítás” maradt. Átfogalmazva A tanár, kevés új van a nap alatt.

Hogy pontos legyek, én azt állítom a token nélküli blokkláncok célt szolgálnak, de ez a más célú az eredeti bitcoin blokklánchoz képest. A kriptofejek nevetnek a token nélküli blokkláncokon, mert nem tudnak cenzúra-ellenállást és decentralizált biztonságot nyújtani a munka igazolásával. A fintech fejek nevetnek a nyilvános blokkláncokon, mert lassúak, drágák és nem alkalmasak a hagyományos pénzügyekre. Nos, nevessen mindenki, mert azt hiszem, mindkettőtöknek igaza van.

Azzal fogok érvelni, hogy a token nélküli blokkláncok hasznosak a decentralizált adatbázisok szinkronban tartásához, akár egyetlen szervezetben is, amelyben tökéletes a bizalom. Aztán meglátjuk, milyen egyéb funkciókat kínálnak a blokkláncok, amelyek alkalmassá teszik őket a konszenzus kialakítására meghatározott típusú tranzakciók szervezetek között, ahol csak korlátozott és tökéletlen a bizalom.

Sajnos az érvelés követéséhez ki kell találkoznod velem a bitcoin tranzakciós modellel, az adatbázis többverziós párhuzamosság-vezérlésével (MVCC) és a konfliktusfeloldás problémájával a több főadatbázis-replikációban. Minden tőlem telhetőt megteszek, hogy ragaszkodjak az angolhoz, de ez technikai dolog, és nem lehet elkerülni.

A Bitcoin tranzakciós modellje

A bitcoin tranzakciós modell egyszerű, de hatékony. Minden bitcoin-tranzakciónak bemenetei és kimenetei vannak. Minden bemenet egy korábbi tranzakció egy kimenetét „költi el”. A tranzakcióban lévő összes bitcoin beáramlik az adott tranzakcióba, és eloszlik a kimenetei között a benne írt mennyiségek szerint. Ily módon a tranzakciók többirányú összekapcsolt láncot alkotnak, amely azoknál a „coinbase” tranzakcióknál ér véget, amelyekben új bitcoinokat hoznak létre.

A Bitcoinnak számos további szabálya van, amelyeket a hálózat minden csomópontja betart:

• Egy tranzakcióban minden bemenetnek bizonyítania kell, hogy jogosult a korábbi kimenet elköltésére, amelyhez kapcsolódik. Ezt a jogot az előző kimenetben kódolt feltételek korlátozzák.
• Egy tranzakciónak elegendő teljes bitcoinnal kell rendelkeznie a bemeneteiben, hogy fedezze a kimenetekben írt teljes összeget. Az egyetlen kivételt az érmebázis tranzakciók jelentik, amelyek új pénzegységeket hoznak létre.
• Minden kimenet csak egyszer költhető el, vagyis egy következő tranzakció során csak egy bemenethez köthető.

Ez utóbbi szabály miatt a hálózatnak olyan mechanizmusra van szüksége, amellyel konszenzusra juthat arról, hogy mely tranzakciók érvényesek, és ezt teszi a blokklánc. Kimondottan:

Ha két tranzakció megpróbálja elkölteni ugyanazt a kimenetet, akkor a tranzakciók közül végül csak az egyiket fogadják el. A blokklánc egységes mechanizmusként működik ezen konfliktusok észlelésére és megelőzésére a hálózaton keresztül.

A blokklánc felépítése összekapcsolt blokkok sorozata, amelyben minden blokk egy sor tranzakciót tartalmaz, amelyek nem ütköznek sem egymással, sem a korábbi blokkokkal, kezdve a 2009-ben létrehozott első blokktól. Elméletileg a lánc tartalmazhat egy egyedi tranzakciók sorozata, de a tranzakciók blokkokba csoportosításával számos olyan hatékonyságot érünk el, amelyek praktikusabbá teszik a sémát.

Mi tehát a kriptovaluta célja ebben az egészben? Az a kérdés, hogy ki dönti el a láncot alkotó blokkokat. A Bitcoin decentralizált, és nincs olyan felhatalmazása, amely meghozhatná ezt a döntést, ezért valami más módot kell találnia a konszenzus elérésére.

Esetleg demokratikus megközelítést alkalmazhatunk, amelyben a hálózat csomópontjai a blokkokra szavaznak, és a többség nyer. Sajnos, amint azt bármely internetes közvélemény-kutatás bizonyítja, a képviseleti demokrácia nem lehetséges online, a megszemélyesítés problémája miatt (más néven Sybil támadás). Egy személy több millió számítógépet átvehet, és eldöntheti, hogyan szavaz, így átveheti az irányítást a hálózati konszenzus felett. Senki más nem fogja tudni, hogy ez megtörtént.

Ennek megoldására a bitcoin szándékosan megnehezíti egy blokk hozzáadását a lánchoz a „bányászat” nevű folyamaton keresztül. Egy blokk létrehozásához meg kell oldania egy nehéz, de értelmetlen matematikai feladatot, amely sok számítást (és ezért áramot és pénzt) igényel. Szerencsére is szüksége van, mivel sok más blokkbányászsal versenyez a világ minden táján. Erősebb bányászati ​​számítógép vásárlásával nem lehet sokáig előrébb jutni, mert a hálózat rendszeresen úgy állítja be a probléma nehézségi fokát, hogy a 10 percenkénti egy blokk állandó globális sebességét tartsa.

Ha ilyen nehéz és költséges egy blokkot létrehozni, miért zavarná bárki? A válasz a blokk jutalomban van. Egy blokk sikeres bányásza irányítja a coinbase tranzakciót, amely 25 bitcoint juttat nekik (ez az összeg négyévente felére csökken). Eladhatják ezeket a bitcoinokat a nyílt piacon 7,000 dollárért (mai árfolyamon), kifizethetik villanyszámlájukat, és remélhetőleg zsebre tehetnek némi hasznot. A bányászok a tranzakciókhoz kapcsolódó díjakból is beszednek egy kis pluszt, bár ezek a díjak egyelőre csekély szerepet játszanak.

Tehát a bitcoin a munka bizonyítása révén konszenzust generál, és a bitcoin-fejek érvelésének lényege a következő: Kriptovaluta nélkül nincs mód a blokkok decentralizált bányászatának ösztönzésére. Ezért nincs mód a nyílt blokklánc védelmére a megszemélyesítési támadások ellen. Ezért bárki monopolizálhatja a hálózati konszenzust, és használhatatlanná teheti az egészet. Nem fogok vitatkozni ezekkel.

Többváltozatú konkurenciavezérlés

Addig is szeretnék beszélni valamiről, ami úgy tűnik, teljesen független.

Az adatbázis strukturált információk tárháza, amelyet táblázatoknak nevezett entitásokba csoportosítanak. Egy ilyen táblázat egyszerű példája a bankszámlák listája, amelyben minden sor egy számlaszámot és az adott számla egyenlegét tartalmazza. Tegyük fel, hogy fiókja 900 USD egyenleggel kezdi a napot. Ma 750 dolláros automatikus jelzáloghitel-fizetés van ütemezve, és 400 dollárt kell felvennie egy ATM-ből. Sajnos Önnek nincs folyószámlahitelje, ezért a műveletek egyike meghiúsul.

A jelzáloghitel-fizetés és az ATM-kivonás folyamatai különálló rendszereken futnak, mindkettő ehhez az egyetlen számlaadatbázishoz fér hozzá. Tegyük fel, hogy minden folyamat úgy működik, hogy beolvassa a számla egyenlegét, leellenőrzi, hogy elegendő-e a művelethez, elindítja a műveletet, ellenőrzi a művelet befejezését, kiszámítja az új egyenleget, majd végül beírja az adatbázisba.

Mindaddig, amíg a jelzáloghitel-fizetés és az ATM-kivonás nem fedi egymást, ez a logika jól működik. Az első művelet sikeresen végrehajtódik, a második pedig megszakad, mert fiókjában nincs elegendő fedezet. Megrendeléstől függően dühös telefonhívást kap a banktól, vagy durva üzenetet az ATM képernyőjén.

De mi történik, ha a két folyamat egyszerre indul el? Ebben az esetben mindegyik leolvassa a fiók egyenlegét, és elegendőnek ítéli a folytatáshoz. Amikor a jelzáloghitel kifizetése befejeződik, az új egyenlegét 150 USD-ben számítják ki, és beírják az adatbázisba. Amikor az ATM-kivonás befejeződik, az új, 500 dolláros egyenleged is hasonlóképpen meg lesz írva. Az egyik írási művelet felülírja a másikat, és szerencsédtől függően 750 vagy 400 dollár bónuszt kapsz a bankodtól. Nem kétséges, hogy hamarosan megtanulja időzíteni az ATM-látogatásokat a jelzáloghitel napjára.

Ez persze a valóságban nem történik meg, az úgynevezett adatbázis-technológia miatt párhuzamosság ellenőrzése. A párhuzamosság-ellenőrzés megőrzi adatainkat (különösen a pénzügyi) ésszerű és biztonságos, és ennek számos formája van. De mindannyian osztják azt az elvet, hogy az adatbázis-műveletek „tranzakciókba” vannak csoportosítva, amelyeket atomosan kezelnek, vagyis összességében sikeresek vagy kudarcot vallanak. A párhuzamosság megőrzi a konzisztenciát azáltal, hogy zárolja vagy lefagyasztja az adatbázis egyes részeit, miközben azokat egy tranzakció használja, hogy megakadályozza, hogy más tranzakciók ugyanazon az információn ütköző módon működjenek.

Ha nem lenne szükség a tranzakciók párhuzamos futtatására, akkor a teljes adatbázist zárolhatnánk minden egyes tranzakció teljes időtartamára. Ez azonban nem praktikus a legtöbb valós alkalmazásban. Egy jó párhuzamosság-vezérlési séma lehetővé teszi a párhuzamos műveleteket azáltal, hogy a lehető legkevesebb adatot a lehető legrövidebb időre zárolja. A fenti példában csak a fiókjának megfelelő adatbázissor kerül zárolásra, és csak arra a másodperc töredékére, amelyben az utolsó ellenőrzés és levonás megtörtént. Egy párhuzamosan működő, ütköző tranzakciónak egyszerűen meg kell várnia, amíg ez a zárolás feloldódik.

Az egyik népszerű párhuzamosság-szabályozási technika az ún többverziós párhuzamosság vezérlés, vagy röviden MVCC. Az MVCC-ben minden tranzakció konzisztens pillanatképet lát az adatokról egy adott időpontban, még akkor is, ha az adatok egy része egy második, egyidejű tranzakcióval frissítés alatt áll. Ez pillanatfelvétel izolálása Az ingatlan például biztosítja, hogy a több számla teljes egyenlegét bemutató kimutatás mindig helyes legyen, még akkor is, ha egyes pénzeszközök egyik számláról a másikra költöznek. Egy tranzakció csak akkor lesz hatással a második tranzakció által látott adatokra, ha a második az első módosításának sikeres alkalmazása után kezdődik.

A színfalak mögött az MVCC úgy működik, hogy lehetővé teszi egy sor több verziójának egyidejű karbantartását, egy időbélyeg mellett, amely az egyes verziók utolsó módosításának dátumát jelzi. Egy adatbázis-sor módosítása az MVCC-ben a sor aktuális verzióját jelöli meg törlésre, miközben a módosítást egy annak a sornak a másolata frissített időbélyeggel. Az adatbázis tárolórétege szempontjából nem létezik olyan, hogy egy sor helyben történő módosítása. Minden tranzakció pontosan tudja, hogy mikor kezdődött, és csak azoknak a soroknak a verzióit látja, amelyek időbélyege az adott időpont előtti. A sorok régi verziói eltávolíthatók a tárhelyről, ha már nincsenek folyamatban lévő tranzakciók, amelyek elérhetik őket.

Célunk szempontjából alapvetően fontos, hogy az MVCC megakadályozza az írási műveletek közötti ütközéseket. Kimondottan:

Ha két tranzakció megpróbálja törölni ugyanazt a sorverziót, akkor ezek közül a tranzakciók közül végül csak az egyiket fogadjuk el. A többverziós párhuzamosság-vezérlés egységes mechanizmusként működik az adatbázison belüli ütközések észlelésére és megelőzésére.

Csengessen valami csengőt? Van még egy háttérrészlet, amit meg kell beszélnünk.

Több főadatbázis-replikáció

Most beszéljünk az adatbázis-replikációról, amelyben egy adatbázis több példányban is létezik. Számos jó ok van az adatbázis replikálására, például:

• A megbízhatóság növelése érdekében, hogy ha az adatbázis egy példánya elveszne (pl. lemezhiba miatt), azonnal át tudjunk váltani egy második példányra.
• Az átviteli sebesség növelése, ha a műveletek mennyisége meghaladja egyetlen adatbázis-kiszolgáló kapacitását.
• A késleltetés csökkentése érdekében, hogy a szingapúri irodában futó folyamatoknak ne kelljen várniuk a Torontóban található adatbázis válaszaira.

Mikor jön a olvasás adatbázisokból származó adatok, a replikáció ideális technika, mivel az összes replika ugyanazt az információt tartalmazza. A dolgok azonban egyre ragadósabbak az írási műveleteknél, mert el kell döntenünk, hogy ezeket az írási műveleteket hol hajtsák végre, és hogyan kerüljenek át az adatbázis más másolataiba.

A leggyakoribb válasz a master-slave replikáció használata, amelyben egyetlen adatbázis (a „mester”) tekintendő mérvadónak. Az adatok bármilyen módosítása kizárólag a mesteren történik, majd a tranzakciónaplón keresztül az összes többi „szolga” adatbázisba csorog le. Ez az adatbázis-példányokat (többé-kevésbé) azonnali szinkronban tartja.

Sajnos, ha az írási műveletek gyakoriak, a mester-szolga replikáció azonnal visszavezet ahhoz a problémához, amelynek megoldására a replikációt tervezték. A főadatbázis szűk keresztmetszetté válik a megbízhatóság, az átviteli sebesség és a késleltetés szempontjából, mivel minden írási műveletet egyedül hajtanak végre rajta.

Egy összetettebb stratégiát több főkiszolgálós replikációnak neveznek, amelyben az írások bármelyik adatbázispéldányon végrehajthatók, nem pedig egyetlen mesterre. Ebben az esetben a másolatok peer-to-peer módon osztják meg egymással a frissítéseket, hogy szinkronban maradjanak.

Ez elméletben egyszerűen hangzik, de a több főkiszolgálós replikáció új problémát vet fel, mivel konfliktusok léphetnek fel. Mi van akkor, ha egy adatbázis két példánya egyszerre frissíti ugyanazt a sort, majd megpróbálja kicserélni ezeket a frissítéseket egymással? Mindkét adatbázis észreveszi, hogy ütköző frissítés történt, és valamilyen egyeztetett stratégiát kell alkalmazniuk az ütközések feloldására. És itt jönnek a dolgok elég összetett – lásd a dokumentumokat MySQL, SQL Server or Jóslat néhány példát a konfliktusmegoldási stratégiákra. (Figyelmen kívül hagyom a szinkron vagy úgynevezett „buzgó” több főkiszolgálós replikációt, amelyben minden replikának végre kell hajtania egy írási műveletet, mert az megfordul minden az adatbázis másolata szűk keresztmetszetbe.)

Tehát hová vezet ez a háttér:

Nem lenne jó, ha elosztott többverziós párhuzamosság-vezérlést tudtunk volna elvégezni, hogy megakadályozzuk a konfliktusokat a több főkiszolgálós replikációban?

Nos, igen, azt hiszem, ez nagyon szép lenne. És úgy gondolom, hogy a blokkláncok pontosan ezt teszik.

Blokkláncok elosztott MVCC-ként

Másoljunk le pár mondatot, amit fentebb félkövérrel írtam:

Ha két tranzakció megkísérli költ ugyanaz teljesítmény, akkor végül csak az egyik tranzakciót fogadjuk el. Egy blokklánc egységes mechanizmusként működik ezen konfliktusok észlelésére és megelőzésére a hálózaton keresztül.

Ha két tranzakció megkísérli töröl ugyanaz soros változat, akkor ezek közül a tranzakciók közül végül csak egyet fogadunk el. Többváltozatú konkurenciavezérlés egységes mechanizmusként működik ezen konfliktusok észlelésére és megelőzésére egy adatbázison belül.

Ezek a mondatok a félkövér kifejezések kivételével azonosak. Tehát a következőt fogom állítani:

A blokklánc elosztott MVCC-t biztosít (néhány extra csengővel és síppal).

Pontosítsuk egy kicsit tovább az összehasonlítást. A blokklánc csomópont szemszögéből nézve az el nem költött bitcoin tranzakciós kimenetek aktuális halmaza egy adatbázist alkot, amelyben minden sor egyetlen el nem költött kimenet. Ez hasonló az általunk korábban ismertetett bankszámla-adatbázishoz, azzal a kisebb eltéréssel, hogy az egyes számlák egyenlege több sorra bontható, amelyek mindegyike azonos számlaszámmal van megjelölve.

Egy bitcoin-tranzakció egy vagy több ilyen kimenetet elkölt, és ennek eredményeként egy vagy több új kimenetet hoz létre. Ez pontosan olyan, mint egy adatbázis-tranzakció, amely törli egy vagy több sorverziót, és ennek eredményeként egy vagy több új sort hoz létre (emlékezzünk arra, hogy az MVCC-ben nincs szó egy sor helyben történő módosításáról). A bitcoin blokklánc biztosítja, hogy egyetlen kimenet ne költhető el több tranzakcióra. Ez egyenértékű annak biztosításával, hogy egyetlen soros verziót ne törölhessen egynél több adatbázistranzakció.

Mielőtt elragadnánk, nem állítom, hogy a blokkláncok nagyszerű általános célú technológia az elosztott adatbázis-szinkronizáláshoz egy teljesen megbízható környezetben. Rengeteg más technológia is létezik, mint pl Paxos, Tutaj és a Kétfázisú véglegesítés amelyek nagyon szépen végzik a munkát. De úgy gondolom, hogy a blokkláncoknak van egy édes pontja, amely olyan alkalmazásokként jellemezhető, ahol:

• Elfogadhatunk egy rövid késést a tranzakció valószínű elfogadása és a határozott elfogadás között. (Ez a késleltetés lehet másodpercek kérdése, nem pedig 10 perc, mint a bitcoin esetében.)
• Soha nem történhetnek ütköző tranzakciók, ha mindenki őszinte, és rendszerei megfelelően működnek.
• Minden tranzakció egyszerre csak néhány sort módosít (ellenkező esetben a blokklánc-tranzakcióinknak nehézkes számú bemenete lesz).
• Az egyes adatbázissorok mérete meglehetősen kicsi (ismét, hogy megakadályozzuk a blokklánc-tranzakcióink méretének növekedését).

Mindezen kritériumoknak megfelelnek a pénzügyi pályázatok. A pénzvilág már megszokta a (akár 3 napos!) késéseket a tranzakció lebonyolítása és a végső elszámolás között. A konfliktusok megelőzése szempontjából szerződései és szabályzatai vannak a csalások felderítésére, és a következmények súlyosak lehetnek. És az egyes tranzakciókban szereplő adatok mennyisége meglehetősen kicsi – gondoljon a fenti bankszámla példára.

Eddig csak azt mutattam be, hogy a blokkláncok egy újabb szinkronizálási mechanizmus az elosztott adatbázisokhoz. Nagy wow. A dolgok csak akkor válnak igazán érdekessé, ha figyelembe vesszük a blokkláncok által biztosított további funkciókat.

Az MVCC-n túli blokkláncok

A bitcoin-tranzakció sokkal többet tesz, mint csupán néhány korábbi tranzakciós kimenetre mutat, és helyettük újakat hoz létre. Még a legegyszerűbb bitcoin tranzakció is két további célt szolgál.

Először is, az érvényes tranzakciókra vonatkozó szabályok tartalmazzák a számlaadatbázisunk alkalmazási logikáját. Emlékezzünk vissza, hogy a tranzakció bemeneteiben lévő bitcoin teljes mennyiségének le kell fednie a kimenetek teljes mennyiségét. Adatbázis-alkalmazási logikára lefordítva ez egy olyan szabály, amely kimondja, hogy az adatbázis-tranzakciók (a coinbázisok kivételével) nem növelhetik az adatbázisban lévő bitcoin teljes mennyiségét. Ez a fajta megszorítás túlmutat a szokásos adatbázisokon tárolt eljárások mert azt semmilyen körülmények között nem lehet megkerülni.

Másodszor, ne feledjük, hogy minden bitcoin tranzakció kimenet kódolja azokat a feltételeket, amelyek mellett elkölthető. A szokásos bitcoin kimeneteknél ez a feltétel nyilvános kulcsú titkosításon alapul. A nyilvános cím be van ágyazva a kimeneti „script”-be, így azt csak az adott nyilvános címnek megfelelő privát kulcs használatával lehet elkölteni. Ha ezt a kimenetet adatbázissornak tekintjük, akkor egy soronkénti engedélyekkel rendelkező adatbázisunk van, amelyek nyilvános kulcsú titkosításon alapulnak. Továbbá minden tranzakció nyilvánosan auditálható bizonyítékot mutat arra vonatkozóan, hogy a létrehozó(k)nak joga volt törölni/módosítani korábbi sorait. Ez (úgy gondolom) egy igazi újdonság az adatbázis-technológiában.

És megint csak úgy történik, hogy mindkét funkció hihetetlenül hasznos a pénzügyi alkalmazásokhoz. Szeretjük, hogy adatbázisunk a lehető legalacsonyabb szinten biztosítja, hogy ne légből kapott pénz keletkezzen. És szeretjük a megdönthetetlen ellenőrzési nyomvonalat, amely megmutatja, hogy minden tranzakciót az áthelyezett alapok tulajdonosa engedélyezett. Mint itt részletesen tárgyaljuk, az is előfordulhat, hogy szeretünk biztonságos atomi peer-to-peer cseretranzakciókat végrehajtani (szállítás-fizetés fizetéssel a pénzügyi beszélgetésben), anélkül, hogy még a partnerünk kilétét is tudnánk.

Szóval hol a token?

Természetesen mindez nem véletlen, mert a bitcoin maga egy gyönyörű peer-to-peer pénzügyi alkalmazás. Ennek ellenére a blokklánc fenti jellemzői közül egyik sem függ a tokentől. Ha úgy módosítjuk az „adatbázis” sémánkat, hogy minden sor több eszközt ábrázoljon, ne pedig a blokklánc natív pénzneme, akkor teljesen megszabadulhatunk ettől a pénznemtől. Ez egy blokkláncot hagy számunkra, amellyel konszenzust és biztonságot érhetünk el egy peer-to-peer pénzügyi alkalmazásban. bármely eszközosztály.

De csak egy apró kérdés: Ki végzi a bányászatot, hogy megteremtse ezt a konszenzust? A bitcoinban az anonim bányászoknak drága, haszontalan számításokat kell végezniük, és erre ösztönzik őket a blokklánc natív pénznemében vagy tokenjében meghatározott blokkjutalom (és tranzakciós díj). Van más lehetőségünk?

Kiderült, hogy igen. Lehet zárt listánk az engedélyezett bányászokról, akik az általuk létrehozott blokkok aláírásával azonosítják magukat. Szabályok az elosztott konszenzusról (vagy „bányászati ​​sokféleségről”, ahogy mi nevezzük MultiChain) más módot biztosítanak a blokklánc kisebbségi ellenőrzésének megakadályozására, mindaddig, amíg el tudja fogadni, hogy a bányászokat előzetesen jóváhagyják. Természetesen a bitcoin esetében ez nem elfogadható, mert a lényeg az anonim bányászat engedélyezése, így nincs mód a tranzakciók központi cenzúrázására. De ha mondjuk lenne egy erősen szabályozott pénzügyi rendszerünk, amelyben a bitcoin modellje nem alkalmazható, talán mégis elfogadhatnánk a bányászok előre jóváhagyott listáját? Ha elegünk van belőlük, és elég jól elosztjuk őket az intézmények között, és mindegyikkel jogi szerződést kötöttünk, akkor valóban valószínű, hogy összefognak és aláássák azt a hálózatot, amelytől függenek, és ha ezzel börtönbe kerülnek?

Epilógus

Remélem, bebizonyítottam, hogy a tokenek nélküli blokkláncoknak van néhány hasznos alkalmazása, még akkor is, ha ezek nagyon különböznek a bitcoin blokklánctól. Ennek ellenére egy kérdés marad:

Ezek az engedélyezett, token nélküli megosztott főkönyvi rendszerek valóban méltók a „blokklánc” névre?

A rövid válasz: kit érdekel? A szavak jelentéséről ritkán érdemes vitatkozni, mert van nincs helyes válasz.

De hogy egy kicsit mélyebbre menjek, tegyük fel, hogy elfogadom azt a feltevést, hogy a bitcoin blokklánc az archetipikus blokklánc. Ebben az esetben a következőt kell kérdeznünk:

Ezek a megosztott főkönyvek elég hasonlóak a bitcoinhoz, hogy kiérdemeljék a „blokklánc” nevet?

Az én személyes véleményem itt van Igen. Mert nagyszámú műszaki hasonlóság van bennük, még akkor is, ha az engedélyek modellje és a gazdasági ösztönzők különböznek egymástól. És ami a legfontosabb, mert mindkettő konszenzust generál egy elosztott adatbázisban a blokkok láncolata.

Köszönöm hogy elolvastad.

Tudod kövess a Twitteren itt. Lásd még: Szállítás a fizetés ellen egy blokkláncon.

Íme néhány további írás, amelyeket érdemes elolvasni ebben a témában Piotr Piasecki és a Ásták Campbellt.