Blokkláncok méretezése láncon kívüli adatokkal

Újra kiadta Platón

Követő: 0

Amikor egy hash millió szót ér

Mára már világos, hogy sok blokklánc-használati esetnek semmi köze a pénzügyi tranzakciókhoz. Ehelyett a lánc célja, hogy lehetővé tegye a decentralizált összesítést, rendezést, időbélyegzést és archiválást. bármilyen információ típusa, beleértve a strukturált adatokat, levelezést vagy dokumentációt. A blokklánc alapvető értéke, hogy a résztvevők bizonyíthatóan és tartósan megállapodjanak abban, hogy pontosan milyen adatokat, mikor és ki vitt be, anélkül, hogy megbízható közvetítőre támaszkodna. Például az SAP nemrégiben indult blokklánc platform, amely támogatja a MultiChaint és a Hyperledger Fabric-et, az ellátási lánc és egyéb nem pénzügyi alkalmazások széles körét célozza meg.

A blokklánc használatának legegyszerűbb módja az adatok rögzítésére, ha minden adatot közvetlenül beágyaz egy tranzakcióba. Minden blokklánc-tranzakciót egy vagy több fél digitálisan aláír, minden csomópontra replikál, a lánc konszenzusos algoritmusa rendezi és időbélyegzi, és véglegesen, hamisításbiztos módon tárolja. A tranzakción belüli adatokat ezért minden csomópont azonosan, de függetlenül tárolja, és igazolja, hogy ki és mikor írta. A lánc felhasználói a jövőben bármikor lekérhetik ezeket az információkat.

Például a MultiChain 1.0 lehetővé tette egy vagy több elnevezett „folyam” létrehozását a blokkláncon, majd a nyers adatok tárolására és visszanyerésére. Minden adatfolyamnak saját írási engedélyei vannak, és minden csomópont szabadon választhat, hogy melyik adatfolyamra szeretne előfizetni. Ha egy csomópont előfizetett egy adatfolyamra, akkor valós időben indexeli az adatfolyam tartalmát, lehetővé téve az elemek gyors lekérését rendelésük, időbélyegzőjük, blokkszámuk vagy kiadói címük alapján, valamint egy „kulcson” (vagy címkén) keresztül. amellyel az elemeket meg lehet jelölni. A MultiChain 2.0 (az alfa 1 óta) kiterjesztett adatfolyamok a Unicode-szöveg- vagy JSON-adatok támogatására, valamint tételenként több kulcs és tranzakciónként több elem támogatására. Ezenkívül olyan összegző funkciókat is hozzáadott, mint például a „JSON-egyesítés”, amelyek hasznos módon kombinálják az azonos kulccsal vagy kiadóval rendelkező elemeket.

Bizalmasság és méretezhetőség

Míg az adatok közvetlen blokkláncon történő tárolása jól működik, két fő hiányossága van: a bizalmasság és a méretezhetőség. Először is a titoktartással, minden adatfolyam-elem tartalma látható a lánc minden csomópontja számára, és ez nem feltétlenül kívánatos eredmény. Sok esetben egy adatnak csak a csomópontok egy bizonyos részhalmaza számára kell láthatónak lennie, még akkor is, ha más csomópontokra van szükség a rendezéshez, időbélyegzéshez és közjegyzői hitelesítéshez.

A bizalmas kezelés viszonylag könnyen megoldható probléma, mivel titkosítják az információkat, mielőtt azok egy tranzakcióba ágyaznának. Az egyes adatok visszafejtési kulcsát csak azokkal a résztvevőkkel osztják meg, akiknek látniuk kell. A kulcsok kézbesítése aszimmetrikus kriptográfiával (pl itt ismertetjük) vagy valamilyen láncon kívüli mechanizmuson keresztül, ahogy az előnyös. Bármely csomópont, amelynek nincs kulcsa egy elem visszafejtéséhez, nem fog mást látni, mint bináris halandzsát.

A skálázhatóság ezzel szemben jelentősebb kihívás. Tegyük fel, hogy minden tisztességes blokklánc-platformnak támogatnia kell a másodpercenkénti 500 tranzakciós hálózati átvitelt. Ha a lánc célja információtárolás, akkor az egyes tranzakciók mérete elsősorban attól függ, hogy mennyi adatot tartalmaznak. Minden tranzakcióhoz (legalább) 100 bájt többletterhelés szükséges a feladó címének, digitális aláírásának és néhány egyéb bitnek és darabnak a tárolásához.

Ha egy egyszerű esetet veszünk, ahol minden elem egy kis, 100 bájtos JSON-struktúra, akkor a teljes adatátviteli sebesség 100 kilobájt/másodperc lenne, 500 × (100+100) értékből számítva. Ez 1 megabit/másodperc alatti sávszélességet jelent, ami kényelmesen belefér bármely modern internetkapcsolat kapacitásába. Évente körülbelül 3 terabájtnyi adathalmozódna fel, ami nem kevés. De most 12 terabájtos merevlemezekkel széles körben elérhetőés RAID A több fizikai meghajtót egyetlen logikai meghajtóba egyesítő vezérlők segítségével könnyedén tárolhatunk 10-20 év adatát minden csomóponton anélkül, hogy túl sok gond és költség lenne.

A dolgok azonban egészen másképp néznek ki, ha nagyobb információkat tárolunk, például beszkennelt dokumentumokat. Egy A4-es papír ésszerű minőségű JPEG szkennelése 500 kilobájt méretű lehet. Ezt megszorozzuk 500 tranzakcióval másodpercenként, és 250-es átviteli sebességet kapunk. megabájt másodpercenként. Ez 2 gigabit/másodperc sávszélességet jelent, ami gyorsabb, mint a legtöbb helyi hálózat, nem is beszélve az internetkapcsolatokról. Az Amazon Web Services legolcsóbb kínálatában közzétett ár 0.05 dollár gigabájtonként, ez csomópontonként 400,000 8000 dollár éves sávszélesség-számlát jelent. És hol tárolják az egyes csomópontok az évente generált XNUMX terabájtnyi új adatot?

Nyilvánvaló, hogy a sok nagy adatot tároló blokklánc-alkalmazások esetében az egyszerű láncon belüli tárolás nem praktikus választás. A sérülések további sértése érdekében, ha az adatokat titkosítják a titoktartási probléma megoldása érdekében, a csomópontokat arra kérik, hogy tároljanak hatalmas mennyiségű információt, amelyet el sem tudnak olvasni. Ez nem vonzó ajánlat a hálózat résztvevői számára.

A hash megoldás

Tehát hogyan oldjuk meg az adatok skálázhatóságának problémáját? Hogyan használhatjuk ki a blokklánc decentralizált közjegyzői hitelesítését anélkül, hogy ezeket az adatokat a lánc minden csomópontjára replikálnánk?

A válasz egy okos technológia, az úgynevezett „hash”. A hash egy hosszú szám (gondoljunk csak 256 bitre, vagy körülbelül 80 decimális számjegyre), amely egyedileg azonosít egy adatot. A hash kiszámítása az adatokból a segítségével történik egyirányú funkció amelynek van egy fontos kriptográfiai tulajdonsága: Bármilyen adat esetén könnyen és gyorsan kiszámítható a hash. Egy adott kivonat alapján azonban számítási szempontból lehetetlen olyan adatot találni, amely ezt a hash-t generálná. És amikor azt mondjuk, hogy „számításilag kivitelezhetetlen”, több számításra gondolunk, mint ahány atom van az ismert univerzumban.

A hash-ek minden blokkláncban kulcsfontosságú szerepet játszanak a tranzakciók és blokkok egyedi azonosításával. Ezek a számítási kihívások hátterében is állnak az olyan munkabizonyítási rendszerekben, mint a bitcoin. Számos különböző hash-függvényt fejlesztettek ki, olyan gobbledygook-nevekkel, mint a BLAKE2, MD5 és RIPEMD160. De ahhoz, hogy bármely hash-függvény megbízható legyen, kiterjedt tudományos felülvizsgálatot és tesztelést kell kiállnia. Ezek a tesztek támadási kísérletek formájában jelennek meg, például „preimage” (bemenet keresése az adott hash-sel), „második preimage” (második bemenet keresése az adott bemenettel azonos hash-sel) és „ütközés” (bármelyik bemenet megtalálása). két különböző bemenet azonos hash-sel). Ennek a kesztyűnek a túlélése korántsem könnyű, a törött hash-függvények hosszú és tragikus története bizonyítja a híres főtételt: „Ne dobd fel a saját kriptokártyádat.”

Visszatérve az eredeti problémánkhoz, meg tudjuk oldani az adatok méretezhetőségét a blokkláncokban úgy, hogy a tranzakciókba beágyazzuk a nagy adatrészek hash-eit, nem pedig maguk az adatok. Mindegyik hash „elkötelezettségként” működik a bemeneti adataihoz, és magát az adatot a blokkláncon kívül vagy „láncon kívül” tárolják. Például a népszerű SHA256 hash funkcióval egy 500 kilobájtos JPEG kép 32 bájtos számmal ábrázolható, ami több mint 15,000 500×-es csökkentést jelent. Ez még XNUMX kép/másodperc sebesség mellett is kényelmesen visszahelyez minket a megvalósítható sávszélesség- és tárolási követelmények tartományába magán a láncon tárolt adatok tekintetében.

Természetesen bármely blokklánc-résztvevő, akinek szüksége van egy láncon kívüli képre, nem tudja reprodukálni azt a hash-ből. De ha a kép más módon is visszakereshető, akkor a láncon belüli hash megerősíti, hogy ki és mikor készítette. Csakúgy, mint a hagyományos on-chain adatok, a hash egy digitálisan aláírt tranzakcióba van beágyazva, amely konszenzussal került be a láncba. Ha egy képfájl kiesik az égből, és a képhez tartozó hash megegyezik a blokkláncban található hash-sel, akkor a kép eredete és időbélyegzője megerősítésre kerül. Tehát a blokklánc pontosan ugyanazt az értéket nyújtja a közjegyzői hitelesítés szempontjából, mintha a kép közvetlenül a láncba lenne beágyazva.

Szállítás kérdése

Eddig jó. Ha az eredeti adatok helyett kivonatokat ágyazunk be egy blokkláncba, egyszerű megoldást kínálunk a skálázhatóság problémájára. Mindazonáltal egy kulcsfontosságú kérdés marad:

Hogyan juttathatjuk el az eredeti láncon kívüli tartalmat azoknak a csomópontoknak, amelyeknek szükségük van rá, ha nem magán a láncon keresztül?

Erre a kérdésre több lehetséges válasz is van, és tudunk olyan MultiChain felhasználókról, akik mindegyiket alkalmazzák. Az egyik alapvető megközelítés egy központosított adattár létrehozása egy megbízható félnél, ahol az összes láncon kívüli adatot feltöltik, majd visszakeresik. Ez a rendszer természetesen használhat „tartalomcímzést”, ami azt jelenti, hogy az egyes adatok hash-je közvetlenül a visszakeresés azonosítójaként szolgál. Azonban bár ez a beállítás működhet a koncepció bizonyítására, nincs értelme a termelésben, mert a blokklánc lényege a megbízható közvetítők eltávolítása. Még ha a láncon belüli hashek megakadályozzák is a közvetítőt az adatok meghamisításában, akkor is törölheti az adatokat, vagy egyes résztvevőknek meghiúsíthatja azokat technikai hiba vagy egy szélhámos alkalmazott intézkedése miatt.

Ígéretesebb lehetőség a pont-pont kommunikáció, amelyben a láncon kívüli adatot igénylő csomópont közvetlenül az azt közzétevő csomóponttól kéri le. Ezzel elkerülhető, hogy megbízható közvetítőre hagyatkozzunk, de három alternatív hiányosságtól szenved:

A blokklánc-címek és az IP-címek térképére van szükség ahhoz, hogy bizonyos adatok fogyasztója közvetlenül kommunikálhasson a kiadójával. A blokkláncok általában elkerülhetik az ilyen típusú statikus hálózati konfigurációt, ami problémát jelenthet a feladatátvétel és az adatvédelem szempontjából.
Ha az eredeti közzétevő csomópont elhagyta a hálózatot, vagy ideiglenesen nem működik, akkor az adatokat senki más nem tudja lekérni.
Ha nagyszámú csomópont érdeklődik egyes adatok iránt, akkor a kiadót túlterhelik a kérések. Ez súlyos hálózati torlódást okozhat, lelassíthatja a kiadó rendszerét, és hosszú késéseket okozhat az adatok lekérésében.

E problémák elkerülése érdekében ideális esetben valamilyen decentralizált kézbesítési mechanizmust alkalmaznánk. A csomópontoknak képesnek kell lenniük a szükséges adatok lekérésére anélkül, hogy bármilyen egyedi rendszerre támaszkodnának – legyen az központi adattár vagy az adatok eredeti közzétevője. Ha több fél rendelkezik egy adatdarabbal, meg kell osztaniuk az adatszolgáltatás terhét bárki mással, aki szeretné. Senkinek sem kell megbíznia az egyes adatforrásokban, mert a láncon belüli hash-ek bizonyítják, hogy az adatokat nem manipulálták. Ha egy rosszindulatú csomópont rossz adatokat küld nekem egy hash-hez, egyszerűen eldobhatom az adatokat, és megpróbálhatok valakit megkérdezni.

Azoknak, akiknek van tapasztalatuk peer-to-peer fájlmegosztás protokollok, mint a Napster, Gnutella vagy BitTorrent, ez mind nagyon ismerősen hangzik. Valójában sok alapelv ugyanaz, de van két alapvető különbség. Először is, ha feltételezzük, hogy a blokkláncunkat vállalati környezetben használjuk, a rendszer a résztvevők zárt csoportján belül fut, nem pedig az internet egészén. Másodszor, a blokklánc hozzáad egy decentralizált rendelési, időbélyegzési és közjegyzői gerincet, amely lehetővé teszi minden felhasználó számára, hogy bizonyíthatóan konzisztens és manipulációbiztos képet kapjon arról, hogy pontosan mi, mikor és ki történt.

Hogyan érheti el egy blokklánc-alkalmazás-fejlesztő a láncon kívüli tartalom decentralizált szállítását? Az egyik gyakori választás egy meglévő peer-to-peer fájlmegosztó platform, például a mulatságos nevű Bolygóközi fájlrendszer (IPFS), és használja a blokklánccal együtt. Mindegyik résztvevő egy blokklánc-csomópontot és egy IPFS-csomópontot is futtat, a kettő között valamilyen köztes szoftverrel. A láncon kívüli adatok közzétételekor ez a köztes szoftver az eredeti adatokat az IPFS-ben tárolja, majd létrehoz egy blokklánc-tranzakciót, amely tartalmazza az adatok kivonatát. A láncon kívüli adatok lekéréséhez a köztes szoftver kivonja a hash-t a blokkláncból, majd ezt a hash-t használja a tartalom lekérésére az IPFS-ből. A helyi IPFS-csomópont automatikusan ellenőrzi a lekért tartalmat a hash alapján, hogy megbizonyosodjon arról, hogy nem módosult.

Bár ez a megoldás lehetséges, mindez meglehetősen ügyetlen és kényelmetlen. Először is, minden résztvevőnek három külön szoftvert kell telepítenie, karbantartania és frissítenie (blokklánc csomópont, IPFS csomópont és köztes szoftver), amelyek mindegyike külön helyen tárolja adatait. Másodszor, két külön peer-to-peer hálózat lesz, mindegyik saját konfigurációval, hálózati portokkal, identitásrendszerrel és jogosultságokkal (bár meg kell jegyezni, hogy az IPFS még nem támogatja a zárt hálózatokat). Végül az IPFS és a blokklánc szoros összekapcsolása a köztes szoftvert egyre bonyolultabbá tenné. Például, ha azt szeretnénk, hogy a láncon kívüli adatok, amelyekre egyes blokklánc-tranzakciók hivatkoznak, azonnal lekérhetők legyenek (automatikus újrapróbálkozásokkal), akkor a köztes szoftvernek folyamatosan üzemben kell lennie, és fenn kell tartania saját összetett állapotát. Nem lenne jó, ha a blokklánc csomópont mindezt megtenné helyettünk?

Láncon kívüli adatok a MultiChain 2.0-ban

Ma nagy örömünkre kiadjuk a harmadik előzetes verzió (alpha 3) a MultiChain 2.0-ból, teljesen integrált és zökkenőmentes megoldással a láncon kívüli adatokhoz. A folyamon közzétett minden információ igény szerint lehet láncon vagy off-chain, és a MultiChain gondoskodik minden másról.

Nem igazán, úgy értjük minden. A MultiChainre építő fejlesztőként nem kell aggódnia a hash-ek, a helyi tárolás, a tartalomfelderítés, a decentralizált kézbesítés vagy az adatok ellenőrzése miatt. Íme, mi történik a színfalak mögött:

A közzétevő MultiChain csomópont az új adatokat a helyi tárolójába írja, a nagy tételeket darabokra vágva a könnyebb emésztés és kézbesítés érdekében.
A láncon kívüli adatfolyam-elemek közzétételére vonatkozó tranzakció automatikusan létrejön, és tartalmazza a darab hash-ét és méretét bájtokban.
Ezt a tranzakciót aláírják és sugározzák a hálózatra, továbbítva a csomópontok között, és a szokásos módon belépve a blokkláncba.
Amikor egy adatfolyamra előfizetett csomópont hivatkozást lát néhány láncon kívüli adatra, hozzáadja az adott adathoz tartozó csonk-kivonatokat a visszakeresési sorához. (Amikor előfizet egy régi adatfolyamra, a csomópont a korábban közzétett, láncon kívüli elemeket is sorba állítja lekérésre.)
Háttérfolyamatként, ha egy csomópont visszakeresési sorában darabok vannak, a rendszer lekérdezéseket küld a hálózatnak, hogy megtalálja ezeket a darabokat, amint azt kivonataikkal azonosítják.
Ezeket a csonklekérdezéseket a hálózat más csomópontjaihoz peer-to-peer módon továbbítják (egyelőre két ugrásra korlátozódik – a technikai részleteket lásd alább).
Bármely csomópont, amely rendelkezik egy csonkhoz tartozó adatokkal, válaszolhat, és ez a válasz a lekérdezéssel megegyező útvonalon visszaküldésre kerül az előfizetőnek.
Ha egyik csomópont sem válaszol a csonk lekérdezésére, a csonk visszakerül a sorba későbbi újrapróbálkozás céljából.
Ellenkező esetben az előfizető kiválasztja a legígéretesebb forrást egy darabhoz (ugrás és válaszidő alapján), és kérést küld neki a csonk adataira vonatkozóan, ismét ugyanazon a peer-to-peer útvonalon, mint az előző válasz.
A forráscsomópont szállítja a kért adatokat, ismét ugyanazon az útvonalon.
Az előfizető ellenőrzi az adatok méretét és kivonatát az eredeti kéréssel szemben.
Ha minden rendben van, az előfizető a helyi tárhelyére írja az adatokat, így azonnal elérhetővé válik a stream API-kon keresztüli lekérdezésre.
Ha a kért tartalom nem érkezett meg, vagy nem felel meg a kívánt hash-nek vagy méretnek, akkor a darab visszakerül a sorba, hogy a jövőben más forrásból lehessen lekérni.

A legfontosabb, hogy mindez rendkívül gyorsan történik. Az alacsony késleltetésű hálózatokban a láncon kívüli adatok kis darabjai a rájuk hivatkozó tranzakció másodperc töredékén belül megérkeznek az előfizetőkhöz. A nagy terhelésű alkalmazások esetében pedig a tesztelésünk azt mutatja, hogy a MultiChain 2.0 alpha 3 másodpercenként több mint 1000 off-chain elemet vagy 25 MB off-chain adatot képes fenntartani egy középkategóriás szerveren (Core i7) megfelelő teljesítmény mellett. Internet kapcsolat. Minden jól működik a láncon kívüli, legfeljebb 1 GB méretű tételekkel, ami messze meghaladja a láncon belüli adatok 64 MB-os korlátját. Természetesen reméljük, hogy tovább javíthatjuk ezeket a számokat, mivel időt töltünk a MultiChain 2.0 optimalizálásával annak béta fázisában.

Ha láncon kívüli, nem pedig láncon belüli adatokat használnak az adatfolyamokban, a MultiChain alkalmazásfejlesztőknek pontosan két dolgot kell tenniük:

Adatok közzétételekor adjon át egy „offchain” jelzőt a megfelelő API-knak.
Az adatfolyam-lekérdezési API-k használatakor vegye fontolóra annak lehetőségét, hogy egyes láncon kívüli adatok még nem állnak rendelkezésre, amint azt az „rendelkezésre álló” jelző jelzi. Bár ez a helyzet normál körülmények között ritka, fontos, hogy az alkalmazásfejlesztők megfelelően kezeljék.

Természetesen annak megakadályozása érdekében, hogy minden csomópont lekérjen minden láncon kívüli elemet, az elemeket megfelelő módon folyamokba kell csoportosítani, és minden csomópontnak elő kell fizetnie az érdeklődési folyamokra.

A láncon belüli és a láncon kívüli elemek használhatók egy adatfolyamon belül, és a különböző adatfolyam-lekérdezési és -összefoglaló funkciók azonosan kapcsolódnak mindkét adattípushoz. Ez lehetővé teszi a megjelenítők számára, hogy a megfelelő választást hozzák meg a stream minden eleméhez anélkül, hogy az alkalmazás többi részét érintené. Például az emberek tevékenységeiről szóló JSON-elemek adatfolyama a láncon kívüli adatokat használhatja a személyazonosításra, a többihez pedig a láncon belüli adatokat. Az előfizetők használhatják a MultiChain JSON-egyesítését, hogy mindkét típusú információt egyetlen JSON-ba egyesítsék olvasáshoz.

Ha szeretné kipróbálni a láncon kívüli streamelemeket, kövesse a MultiChain szokásos szabályait Elkezdeni útmutatót, és ügyeljen arra, hogy ne hagyja ki az 5. részt.

Szóval mi a következő?

A láncon kívüli adatok zökkenőmentes támogatásával a MultiChain 2.0 nagy előrelépést jelent a nagy léptékű adatok időbélyegzésére és közjegyzői hitelesítésére összpontosító blokklánc-alkalmazások számára. Hosszabb távon már rengeteg lehetséges jövőbeli fejlesztésen gondolkodunk ezen a funkción a MultiChain közösségi és/vagy vállalati kiadásaiban:

A folyam megvalósítása olvas engedélyek láncon kívüli tételek, sózott hash-ek, aláírt darablekérdezések és titkosított kézbesítés kombinációjával.
Lehetővé teszi, hogy a láncon kívüli adatokat kifejezetten „elfelejtse”, akár az egyes csomópontok önkéntesen, akár az összes csomópont egy láncon belüli üzenetre válaszul.
Szelektív adatfolyam-előfizetések, amelyekben a csomópontok csak bizonyos kiadókkal vagy kulcsokkal rendelkező, láncon kívüli tételek adatait kérik le.
<p></p> merkle fák hogy egyetlen láncon belüli hash korlátlan számú láncon kívüli elemet reprezentáljon, ami újabb hatalmas ugrást jelent a skálázhatóság terén.
Csatlakoztatható tárolómotorok, amelyek lehetővé teszik a láncon kívüli adatok adatbázisokban vagy külső fájlrendszerekben történő tárolását a helyi lemez helyett.
A csomópontok idővel tanulnak ott, ahol az egyes láncon kívüli adatok általában elérhetők a hálózatban, és megfelelően fókuszálják a lekérdezéseket.

Szeretnénk hallgassa meg visszajelzését a fenti listán, valamint általában a láncon kívüli termékek. Mivel a MultiChain 2.0 még hivatalosan alfában van, bőven van idő a funkció fejlesztésére a végső kiadás előtt.

Időközben már megkezdtük a munkát az „intelligens szűrők”-en, a MultiChain 2.0 Community utolsó főbb funkcióján. Az intelligens szűrő a blokkláncba ágyazott kódrészlet, amely egyéni szabályokat valósít meg az adatok vagy tranzakciók ellenőrzésére. Az intelligens szűrők némi hasonlóságot mutatnak az „intelligens szerződésekkel”, és sok hasonló dolgot képesek elvégezni, de alapvető különbségek vannak a biztonság és a teljesítmény tekintetében. Bízunk benne, hogy a későbbiekben többet is beszámolunk.

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

Műszaki információk

Míg a MultiChain 2.0 láncon kívüli streamelemei egyszerűen használhatók, számos tervezési döntést és további funkciót tartalmaznak, amelyek érdekesek lehetnek. Az alábbi lista elsősorban a blokklánc-alkalmazásokat fejlesztő fejlesztők számára lesz releváns, és kevésbé technikai típusok kihagyhatják:

Adatfolyamonkénti irányelvek. MultiChain adatfolyam létrehozásakor opcionálisan korlátozható, hogy csak a láncon belüli vagy a láncon kívüli adatokat engedélyezze. Ennek több oka is lehet, ahelyett, hogy minden kiadó maga dönthetne. Például a láncon belüli cikkek komoly rendelkezésre állási garanciát kínálnak, míg a láncon kívüli régi tételek visszahozhatatlanok lehetnek, ha kiadójuk és más előfizetőik kilépnek a hálózatból. A másik oldalon a láncon belüli elemeket nem lehet „elfelejteni” a blokklánc módosítása nélkül, míg a láncon kívüli elemek rugalmasabbak. Ez fontos lehet az adatvédelmi szabályok, például Európa új GDPR-szabályozása szempontjából.
Láncon belüli metaadatok. A láncon kívüli tételek esetében a láncon belüli tranzakció továbbra is tartalmazza a tétel megjelenítőjét, kulcsait, formátumát (JSON, szöveges vagy bináris) és teljes méretét. Mindez nagyon kevés helyet foglal el, és segít az alkalmazásfejlesztőknek eldönteni, hogy egy láncon kívüli elem elérhetetlensége aggodalomra ad okot egy adott adatfolyam-lekérdezésnél.
Két ugrás limit. Amikor a csonklekérdezéseket a peer-to-peer hálózaton keresztül továbbítja, kompromisszum van az elérhetőség és a teljesítmény között. Bár jó lenne, ha minden lekérdezés minden egyes útvonalon elterjedne, ez eltömítheti a hálózatot felesleges „csevegésekkel”. Tehát egyelőre a darablekérdezések két ugrásra korlátozódnak, ami azt jelenti, hogy egy csomópont lekérheti a láncon kívüli adatokat bármely társától. Az 1000 alatti csomópontból álló kisebb hálózatokban, amelyek általában a vállalati blokkláncokat jellemzik, úgy gondoljuk, hogy ez tökéletesen működik, de könnyen módosíthatjuk ezt a megszorítást (vagy paraméterként kínálhatjuk fel), ha tévedünk.
Helyi raktár. Minden MultiChain csomópont a láncon kívüli adatokat a szokásos blokklánc-könyvtárának „chunks” könyvtárában tárolja, hatékony bináris formátumot és LevelDB indexet használva. Külön alkönyvtárat használnak az egyes előfizetett adatfolyamok, valamint a csomópont által közzétett elemek számára. Ezen alkönyvtárak mindegyikén belül a duplikált darabok (ugyanolyan hash-sel) csak egyszer kerülnek tárolásra. Amikor egy csomópont leiratkozik egy adatfolyamról, eldöntheti, hogy törli-e az adott adatfolyamhoz lekért láncon kívüli adatokat.
Bináris gyorsítótár. Ha nagy mennyiségű bináris adatot tesznek közzé, akár láncon belüli, akár láncon kívüli adatokról van szó, előfordulhat, hogy az alkalmazásfejlesztők számára nem célszerű egyetlen JSON-RPC kérésben elküldeni ezeket az adatokat a MultiChain API-jának. A MultiChain 2.0 tehát egy bináris gyorsítótárat valósít meg, amely lehetővé teszi nagy adatok felépítését több API-híváson keresztül, majd egy rövid utolsó lépésben közzétételét. A bináris gyorsítótár minden eleme egyszerű fájlként van tárolva a blockchain könyvtár „cache” alkönyvtárában, ami lehetővé teszi, hogy gigabájtnyi adatot közvetlenül a fájlrendszeren keresztül továbbítsunk.
Monitoring API-k. A MultiChain 2.0 alpha 3 két új API-t ad a láncon kívüli adatok aszinkron lekérésének figyelésére. Az első API leírja a sor aktuális állapotát, megmutatva, hogy hány darab (és mennyi adat) várakozik, illetve lekérdezés vagy visszakeresés folyamatban van. A második API összesített statisztikát biztosít a csomópont indítása óta elküldött összes csonklekérdezésről és kérésről, beleértve a különböző típusú hibák számát.
Öblítse ki a közzétételkor. A láncon kívüli tétel közzétételekor a MultiChain gondoskodik arról, hogy az adatok helyi másolata teljesen ki legyen írva (vagy „kiürítve”) a fizikai lemezmeghajtóra, mielőtt az adatokra hivatkozó tranzakciót a hálózatra továbbítanák. Ellenkező esetben, ha a csomópont nem volt elég szerencsés ahhoz, hogy a tranzakció sugárzása után azonnal áramszünetet szenvedjen, a láncon kívüli adatok véglegesen elveszhetnek. Ez nem magának a MultiChainnek a problémája, mivel a csonk visszakeresési kísérletei közötti késések idővel automatikusan nőnek. De problémákat okozhat az alkalmazás szintjén, ahol mindenki tud bizonyos adatok létezéséről, de senki sem találja meg.
Kiadói teljesítmény. A láncon kívüli adatok lemezre öblítésével a MultiChain teljesítménybüntetést vonhat maga után, mivel a fizikai lemezek lassúak. Például egy középkategóriás, 7200 fordulat/perc sebességű merevlemez csak körülbelül 100 véletlenszerű adatírást tud végrehajtani másodpercenként, ami viszont korlátozza azt a sebességet, amellyel az egyes csomópontok láncon kívüli tételeket tehetnek közzé. Ennek a problémának három lehetséges megoldása van. Először is és a legegyszerűbben, a csomópontok használhatnak szilárdtestalapú eszköz (SSD) meghajtót a normál merevlemez helyett, amely másodpercenként 10,000 XNUMX véletlenszerű írási műveletet támogat. Másodszor, több láncon kívüli elem is közzétehető egyetlen tranzakcióban a „createrawsendfrom” API használatával. Ebben az esetben a MultiChain a tranzakció által hivatkozott összes láncon kívüli adatot egyetlen lemezműveletben írja ki. Végül a MultiChain beállítható úgy, hogy ne ürítse ki a láncon kívüli adatokat a lemezre az arra hivatkozó tranzakció sugárzása előtt. Óvatosan használja ezt a lehetőséget.
A natív valuta integrációja. Az ezt igénylő használati esetekben a MultiChain mindig felajánlotta a natív pénznem használatát a blokkláncon, hogy megakadályozza a tranzakciós spamet és/vagy ösztönözze a blokkellenőrzőket („bányászokat”). Ezekben az esetekben a tranzakcióknak minimális díjat kell ajánlaniuk a bányászoknak, amelyek arányosak a bájtokban kifejezett méretükkel, hogy a tranzakciókat továbbítsák és megerősítsék a láncon. Ezt a mechanizmust kibővítették, hogy megakadályozzák a láncon kívüli spameket, és minimális kiegészítő díjat írnak elő a tranzakcióban hivatkozott láncon kívüli adatok kilobájtja után.
Archív csomópontok. Ha egy csomópont szeretne előfizetni minden adatfolyamra, és ezért minden közzétett láncon kívüli elemet le kíván kérni és tárolni, akkor ezt az „autosubscribe” futásidejű paraméterrel konfigurálhatja. Bármely ilyen csomópont a teljes hálózat biztonsági mentéseként működik, garantálva, hogy a láncon kívüli elemek nem vesznek el vagy nem lesznek elérhetők, függetlenül attól, hogy melyik csomópont tűnik el. Elképzelhető, hogy harmadik fél cégek ezt kereskedelmi szolgáltatásként kínálják.