A privát blokkláncok nem csupán „csak” megosztott adatbázisok

Miért hiányzik a blokklánc-elvetők a lényeg?

És így megy tovább. Tól től Népszerű Bejegyzések nak nek lenéző tweeteket nak nek előrejelzések a jövőről, a világ és az anyja sorakoznak, hogy paradicsomot dobjanak a privát blokkláncokra, korábban még azt is, hogy megértsék, mik azok.

Azt mondani, hogy egy privát blokklánc csak egy megosztott adatbázis, olyan, mintha azt mondanánk, hogy a HTML és a HTTP „csak” elosztott hipertext. Két szempontból is rossz. Először is a szemantikai: a privát blokkláncok olyan technológia, amely lehetővé teszi a megosztott adatbázisok, például a tollak lehetővé teszik az írást, a HTML/HTTP pedig az elosztott hipertextet. A bitcoin blokkláncot és annak elsődleges alkalmazását nem lehet értelmesen elválasztani egymástól, mert az egyik nem létezhetne a másik nélkül. De ez az egyenértékűség egyáltalán nem vonatkozik a privát blokkláncokra.

A második hiba az „csak” szó használata. Éppen? HTML és HTTP volt éppen az elosztott hipertext elkészítésének módja? A hipertext volt évtizedekkel korábban találták ki, szóval ezek a technológiák kisebb lábjegyzetek a számítógéptörténetben? Ó, de hadd számoljam össze, hogy miként érdemelték ki helyüket: (a) egy egyszerű jelölőnyelv hogy bármely laikus megtanulhatná, (b) a hierarchikus címzési séma amely a TCP/IP-vel és a mi koncepcionális helymodellünkkel is működik, (c) a egyszerű protokoll a tartalom állapotmentes visszakereséséhez, és (d) mindkettő vásárló és a szerver szoftver, amely életre keltette az egészet. Azt is mondhatnánk, hogy Newton csak tudós volt, Dosztojevszkij pedig csak író.

Tehát tegyük ezt teljesen világossá: Igen, a privát blokkláncok csak az adatbázis megosztásának egyik módja. De lehetővé teszik egy új típusú megosztott adatbázis létrehozását, amely óriási hatással van a pénzügyi világra és azon túl is. És ha hajlandó vagy tovább olvasni, akkor elmondom, hogy miért.

Mi az adatbázis?

Az adatbázis strukturált információk tárháza, táblázatokba rendezve. Úgy is felfoghatja, mint egy vagy több Excel-táblázat gyűjteményét, amelyek opcionálisan összekapcsolhatók. Minden tábla egy adott típusú entitáshalmazról tartalmaz információkat, soronként egy entitással. Minden táblázatnak van egy vagy több oszlopa is, amelyek az entitások különböző aspektusait írják le. Például a WidgetCo belső személyzeti címtárának táblázata tartalmazhat oszlopokat az alkalmazotti azonosítóhoz, keresztnévhez, vezetéknévhez, osztályhoz, belső telefonszámhoz és szobaszámhoz.

Az egyik fontos módja annak, hogy az adatbázisok túlmutatjanak a táblázatokon, hogy szabályokat tartalmaznak a bennük tárolt adatokra vonatkozóan. Ezek a szabályok segítenek annak biztosításában, hogy az információk észszerűek és következetesek maradjanak az egész szervezet javára. A maiban legnépszerűbb adatbázisok, a szabályoknak számos általános formája van:

• A adatbázis séma meghatározza, hogy az egyes oszlopokban milyen információk szerepelhetnek. Például a telefonszámnak 4 számjegyből kell állnia, és nem lehet üresen („null”).
• Egyedi kulcsok amelyek kimondják, hogy egy adott oszlopnak (pl. alkalmazotti azonosítónak) minden sorban más értékkel kell rendelkeznie.
• Ellenőrizze a megszorításokat amelyek az egyes sorok oszlopértékei közötti kapcsolatokat érvényesítik. Például, ha az osztály „Beszerzés”, akkor a helyiség számának 3-mal vagy 4-gyel kell kezdődnie.
• Külföldi kulcsok amelyek a táblák közötti kapcsolatokat érvényesítik. Például, ha az adatbázis egy másik, bérszámfejtésre használt táblát tartalmaz, előfordulhat, hogy egy olyan szabály létezik, amely szerint a bértáblázatban szereplő minden alkalmazotti azonosítónak a személyzeti címtárban is szerepelnie kell.

A tranzakció egy adatbázis módosításainak gyűjteménye, amelyet egészében elfogadnak vagy elutasítanak. Minden alkalommal, amikor egy tranzakció módosítja az adatbázist, a szoftver biztosítja az adatbázis szabályainak betartását. Ha a tranzakció bármely része megsérti e szabályok valamelyikét, a teljes tranzakciót a rendszer a megfelelő hibával elutasítja.

Vannak még ezoterikusabb szabálytípusok, amelyeket fel tudnék sorolni, de mindegyikben van egy közös vonás. A kérdésre válaszolnak: Érvényes állapotban van az adatbázis? Más szóval, az adatbázis tartalmát korlátozzák ha egyetlen időpontban nézzük. És ez tökéletesen működik egy olyan adatbázisnál, amely egyetlen szervezeten belül található, mert a megszorítások fő feladata a programozói hiba megelőzése. Ha a WidgetCo valamelyik belső alkalmazása megpróbálna beszúrni egy 3 számjegyű telefonszámot a telefonkönyvbe, az nem rosszindulatból, hanem a fejlesztő gondolkodásában vagy kódjában fellépő hibáról lenne szó. Az adatbázis azon képessége, hogy felfogja ezeket a hibákat, kétségtelenül hasznos, és segít megelőzni a rossz információk szervezeten belüli terjedését, de nem oldja meg a bizalmi problémákat. (A megszorítások segíthetnek az alkalmazáslogika egyszerűsítésében is, például a következőn keresztül idegen kulcs lépcsőzetes or duplikált záradékok, de ezek még mindig csak a fejlesztők segítésének módjai.)

Adatbázis megosztás

Most pedig gondoljuk át, hogyan lehet megosztani a WidgetCo belső személyzeti címtárát a külvilággal. Sok esetben nincs probléma az ellátással közös olvasmány hozzáférés. A címtár szöveges fájlba exportálható, és e-mailben elküldhető az ügyfeleknek és a beszállítóknak. Feltehető az internetre, akárcsak ezt. Akár egy API-t is kaphat, amely lehetővé teszi a külső kód alapján történő keresést. A megosztott olvasás technikai fejtörés, annak eldöntése kérdése, hogy ki mit láthat.

De a dolgok kezdenek ragadósabbá válni, ha belegondolunk megosztott írás. Mi van akkor, ha a WidgetCo külső entitást szeretne módosítása az adatbázisa? Talán a telefonokat lecseréli a PhoneCo, aki majd frissíti a telefonszámokat a személyzeti telefonkönyvben. Ebben az esetben a WidgetCo új „fiókot” hoz létre a PhoneCo számára. A WidgetCo belső használatára szolgáló fiókokkal ellentétben a PhoneCo fiókja csak a telefonszám oszlop módosítására engedélyezett, és soha nem adhat hozzá vagy törölhet sorokat. A PhoneCo összes tranzakcióját a WidgetCo adatbázis-rendszere dolgozza fel, amely most kétféle korlátozást alkalmaz:

• Globális szabályok, amelyek minden adatbázis-felhasználóra vonatkoznak. Például a telefontársaság nem változtathatja meg a számot úgy, hogy az csak 3 számjegyből álljon, és senki más sem.
• Fiókonkénti szabályok korlátozzák, hogy a PhoneCo mit tehet, ebben az esetben csak a meglévő sorok telefonszám oszlopát módosítja.

Eddig jó. Van egy közös írási adatbázisunk. Ez azért működik, mert a WidgetCo felelős az adatbázisért, és a telefontársaság a WidgetCo jóindulatának köszönhetően hozzáfér. Ha a PhoneCo véletlenszerűen elkezdte beállítani a telefonszámokat, a WidgetCo leállíthatja a hozzáférést, felmondhatja a szerződést, és visszaállíthat néhány régi adatot egy biztonsági másolatból. És ha a WidgetCo rosszul kezdene viselkedni, mondjuk a PhoneCo által beírt új telefonszámok megfordításával, az teljesen értelmetlen lenne, mivel csak maguknak ártana a WidgetCo. A telefontársaság különös ügyfélnek tartaná a WidgetCo-t, de nem különösebben törődik vele, amennyiben időben fizetik a számlát.

De most nézzük meg, mi történik, ha két vagy több fél meg akar osztani egy olyan adatbázist, amelyet (a) egyik fél sem irányít, (b) amelybe bármelyik fél írhat, és (c) amelyre mindenki támaszkodhat. Tovább rontja a helyzetet, hogy ezek a felek különböző ösztönzőkkel bírnak, nem bíznak egymásban, és akár ádáz versenytársak is lehetnek. Ebben az esetben a megoldás mindig ugyanaz volt: bevezetni egy megbízható közvetítőt. Ez a közvetítő központilag kezel egy adatbázist, fiókokat biztosít az összes fél számára, és biztosítja, hogy minden művelet engedélyezett szabályrendszer szerint. Sok esetben, különösen pénzügyi, minden fél továbbra is fenntartja az adatok saját másolatát, így mindenki sok időt tölt azzal, hogy ellenőrizze, adatbázisaik egyetértenek.

Az egész meglehetősen zavaros és nehézkes lesz. De ha már a megosztott írási adatbázis egy korlátozott bizalom környezetben, jelenleg nincs alternatíva. Ez az egyik fő oka annak, hogy a pénzügyi tranzakciók átmennek központi elszámolóházak, miért használja Google Calendar még egy kis munkacsoportban is, és miért van ez a tömegből származó csoda Wikipedia költ millió dollár a hostingról. Akár a web felhasználói felületeként is ügyféloldalra költözik, a központosított szerverek továbbra is tárolják azokat az adatokat, amelyekre ezek az interfészek támaszkodnak.

Igazi megosztott írás

Tegyük fel, hogy engedélyezni akartuk egy adatbázis megosztását, írási értelemben, központi hatóság nélkül. Például több versengő vállalat közös munkatársi névjegyzéket szeretne fenntartani közös ügyfelei érdekében. Hogy nézhet ki ez valójában? Nos, ehhez több dolog is kell:

• Robusztus peer-to-peer hálózat, amely lehetővé teszi, hogy bármely fél tranzakciókat hozzon létre, és gyorsan eljuttasson az összes csatlakoztatott csomóponthoz.
• A tranzakciók közötti konfliktusok azonosításának és automatikus megoldásának módja.
• Egy szinkronizálási technológia, amely biztosítja, hogy az összes társ az adatbázis azonos példányán konvergáljon.
• Módszer különböző információk különböző résztvevőkhöz tartozóként való megcímkézésére, és az adattulajdonlás ezen formájának központi hatóság nélküli érvényesítésére.
• Paradigma az engedélyezett műveletekre vonatkozó korlátozások kifejezésére, például annak megakadályozására, hogy egy vállalat felfújja a címtárat fiktív bejegyzésekkel.

Tyűha. Ez egy nehéz lista, és a mai kész adatbázisok egyszerűen nem támogatják. Jelenlegi peer-to-peer replikációs technológia ügyetlen és komplex módon közelíti meg a konfliktusok megoldását. Azok az adatbázisok, amelyek támogatják sor alapú biztonság továbbra is központi hatóságra van szükség annak végrehajtásához. A szabványos adatbázis-szintű korlátozások, például az egyedi kulcsok és az ellenőrzési megszorítások pedig nem védik meg az adatbázist a rosszindulatú módosításoktól. A lényeg a következő:

Egy csomó új dologra van szükségünk a megosztott írási adatbázisok működéséhez, és véletlenül a blokkláncok biztosítják ezeket.

Nem részletezem túlságosan hogyan a blokkláncok megteszik ezeket a dolgokat, mert én nagy részét korábban lefedte. Néhány kulcsfontosságú elem közé tartozik a rendszeres peer-to-peer technikák, csoportosítás tranzakciókat blokkokra, egyirányú kriptográfiai hash funkciók, többpárti konszenzus algoritmus, terjesztett többverziós párhuzamosság vezérlés és soronkénti engedélyek alapján nyilvános kulcsú kriptográfia. A régi ötletek hosszú listája új módon kombinálva. HTML/HTTP, ha úgy tetszik.

Mindezek mellett a megosztott írási adatbázisok egy teljesen új típusú szabályt igényelnek, a to korlátozza a tranzakciók által végrehajtható átalakításokat. Ez egy abszolút kulcsfontosságú újítás, és minden különbséget jelent, ha egy adatbázist nem megbízható entitások között osztunk meg. Az ilyen típusú szabályok kifejezhetők bitcoin-stílusú tranzakciós megszorításokként vagy Ethereum-stílusú kényszerként. tárolt eljárások („intelligens szerződések”), amelyek mindegyike rendelkezik előnyök és hátrányok. Talán vannak más jobb módszerek is, amelyek felfedezésre várnak. De mindannyian osztoznak abban a tulajdonságban, hogy összekapcsolják az adatbázis állapotát a tranzakció előtt és után. Más szóval a következő kérdésre válaszolnak: Ez érvényes tranzakció volt? Ez alapvetően különbözik attól a kérdéstől, hogy az adatbázis egy adott időpontban érvényes-e.

Ha arra kíváncsi, hogy az ilyen típusú adatbázisban vannak-e hasznos valós alkalmazások, ez jogos kérdés. De észreveheti a privát blokkláncok iránti intenzív érdeklődést legalább egy szektort, mivel lehetőségük van a folyamatok egyszerűsítésére, valamint a költségek és a késések csökkentésére. A pénzintézetek nagy igénybevevői a mai adatbázis-platformoknak, és ezek a platformok nem teszik lehetővé a megosztott írási forgatókönyvet. Ezt keresik a bankok.

Ennek a problémának és megoldásának semmi köze a bitcoinhoz és a cenzúramentes pénz gondolatához. Valójában az egyetlen kapcsolat a bitcoinnal az műszaki hasonlóság a bitcoin blokklánc és egyes privát blokkláncok között ma valósul meg. Az egyik legfontosabb különbség az, hogy nincs szükség privát blokkláncokra a munka igazolása bányászat, mivel a blokkokat azonosított résztvevők zárt halmaza hozza létre. Idővel a két világ még jobban eltérhet egymástól, mert a követelmények teljesen eltérőek. Akár tetszik a pénzügyi szabályozás, akár nem, az egyszerű tény az, hogy a privát blokkláncok potenciálisan hasznosak lehetnek egy szabályozott világban, miközben legalábbis egyelőre nyilvános blokkláncok nem.

Ha szabad egy hasonlattal befejeznem, az ENSZ Nyilatkozat a nemzetközi jog elveiről nem mondja el az országoknak, hogy bármilyen területet birtokolhatnak, amit csak akarnak, feltéve, hogy azt világosan megjelölt kerítés veszi körül. Ehelyett kimondja, hogy „Semmilyen erővel való fenyegetésből vagy erőszak alkalmazásából eredő területszerzés nem ismerhető el jogszerűnek”. Más szóval, ez egy szabály a legitimitását illetően változások, nem csak az helyzetek. Az ENSZ-nyilatkozat pedig, amely most olyan nyilvánvalónak tűnik számunkra, teljes forradalom volt a nemzetközi jogban. Ez egy olyan világot jelentett, amely már nem egyoldalú hatalomra és tekintélyre épül, hanem olyan világot, ahol a nézeteltéréseket kölcsönös konszenzussal lehet feloldani.

Amikor a megosztott adatbázisokról van szó, a privát blokkláncok pontosan ugyanezt teszik.