A MultiChain Streams bemutatása

Újra kiadta Platón

Követő: 0

Megosztott megváltoztathatatlan kulcsérték és idősor adatbázisokhoz

Ma büszkék vagyunk rá, hogy kiadjuk a MultiChain legújabb verzióját, amely a „streamek” nevű, kulcsfontosságú új funkciókészletet valósítja meg. Az adatfolyamok természetes absztrakciót biztosítanak a blokklánc-használati eseteknél, amelyek az általános adatlekérésre, időbélyegzésre és archiválásra összpontosítanak, nem pedig az eszközök résztvevők közötti átvitelére. Az adatfolyamok három különböző típusú adatbázis megvalósítására használhatók egy láncon:

Kulcsérték adatbázis vagy dokumentumtár a NoSQL stílusában.
Idősoros adatbázis, amely a bejegyzések sorrendjére fókuszál.
Identitásvezérelt adatbázis, ahol a bejegyzések a szerzőjük szerint vannak osztályozva.

Ezek tekinthetők egy megosztott adatbázis „mit”, „mikor” és „ki”-nek.

Streamek alapjai

Egy MultiChain blokkláncban tetszőleges számú adatfolyam hozható létre, és mindegyik adatfolyam független, csak hozzáfűzhető elemgyűjteményként működik. Egy adatfolyam minden eleme a következő jellemzőkkel rendelkezik:

Egy vagy több kiadók akik digitálisan aláírták azt a tételt.
Opcionális kulcs a későbbi kényelmes visszakeresés érdekében.
Néhány dátum, amely egy kis szövegrésztől a sok megabájt nyers binárisig terjedhet.
A időbélyeg, amely annak a blokknak a fejlécéből származik, amelyben az elem megerősítésre került.

A színfalak mögött egy adatfolyam minden elemét egy blokklánc-tranzakció képviseli, de a fejlesztők úgy is olvashatnak és írhatnak adatfolyamokat, hogy nem ismerik ezt a mögöttes mechanizmust. (A haladóbb felhasználók használhatják nyers tranzakciók több adatfolyamba való íráshoz, eszközök kiadásához vagy átviteléhez és/vagy engedélyek hozzárendeléséhez egyetlen atomtranzakcióban.)

A streamek számos módon integrálhatók a MultiChain engedélyrendszerébe. Először is, streamet csak azok hozhatnak létre, akik rendelkeznek erre engedéllyel, ugyanúgy, ahogyan eszközöket csak bizonyos címek adhatnak ki. Amikor létrehoz egy adatfolyamot, az nyitva vagy zárva van. A nyílt adatfolyamokat bárki írhatja, akinek engedélye van blokklánc-tranzakció küldésére, míg a zárt adatfolyamok az engedélyezett címek megváltoztatható listájára korlátozódnak. Az utóbbi esetben minden adatfolyamnak egy vagy több rendszergazdája van, akik idővel módosíthatják ezeket az írási engedélyeket.

Minden blokkláncnak van egy opcionális "gyökér" adatfolyama, amely a láncban van meghatározva paraméterek és a lánc létrehozásának pillanatától létezik. Ez lehetővé teszi a blokklánc azonnali használatát az adatok tárolására és visszanyerésére, anélkül, hogy meg kellene várni egy adatfolyam kifejezett létrehozását.

Ahogy én korábban tárgyalták, a titoktartás jelenti a legnagyobb kihívást számos blokklánc-használati esetben. Ennek az az oka, hogy a blokklánc minden csomópontja látja a teljes lánc tartalmának teljes másolatát. A streamek természetes módot biztosítanak a titkosított adatok blokkláncon való támogatására, az alábbiak szerint:

A résztvevők egy adatfolyamot használnak nyilvános kulcsaik elosztására bármely nyilvános kulcsú titkosítási sémához.
Egy második adatfolyamot használnak az adatok közzétételére, ahol minden adatot szimmetrikus titkosítással titkosítanak, egyedi kulccsal.
A harmadik adatfolyam adathozzáférést biztosít. Minden egyes résztvevő számára, akinek látnia kell egy adatot, létrejön egy adatfolyam-bejegyzés, amely tartalmazza az adatok titkos kulcsát, titkosítva a résztvevő nyilvános kulcsával.

Ez hatékony módszert biztosít az adatok blokkláncon való archiválására, miközben azokat csak bizonyos résztvevők láthatják.

Visszakeresés a patakokból

Az adatfolyamok alapvető értéke az indexelésben és a visszakeresésben rejlik. Minden csomópont kiválaszthatja, hogy melyik adatfolyamra szeretne feliratkozni, és a blokklánc garantálja, hogy minden csomópont, amely egy adott adatfolyamra feliratkozik, ugyanazokat az elemeket fogja látni. (Egy csomópont úgy is konfigurálható, hogy minden létrehozott új adatfolyamra automatikusan feliratkozzon.)

Ha egy csomópont előfizetett egy adatfolyamra, az információ többféle módon is lekérhető az adatfolyamról:

Elemek lekérése a streamről sorrendben.
Elemek lekérése egy adott kulccsal.
Egy adott kiadó által aláírt elemek lekérése.
Az adatfolyamban használt kulcsok felsorolása az egyes kulcsokhoz tartozó tételszámokkal.
A kiadók felsorolása egy adatfolyamban, cikkszámmal.

Amint az elején említettük, ezek a visszakeresési módszerek lehetővé teszik az adatfolyamok használatát kulcsérték adatbázisok, idősoros adatbázisok és identitásvezérelt adatbázisok. Minden visszakereső API kínál kezdet és a számít paramétereket, lehetővé téve a hosszú listák alszakaszainak hatékony lekérését (mint az SQL LIMIT záradéka). Negatív értékek ehhez kezdet lehetővé teszi a legutóbbi elemek lekérését.

A streamek több elemet is tartalmazhatnak ugyanazzal a kulccsal, és ez természetesen feloldja a feszültséget a blokklánc megváltoztathatatlansága és az adatbázis frissítésének szükségessége között. Minden hatékony adatbázis-bejegyzéshez egyedi kulcsot kell rendelni az alkalmazásban, és az adott bejegyzés minden frissítését egy új adatfolyam-elem képviseli a kulcsával. A MultiChain adatfolyam-visszakereső API-i ezután felhasználhatók: (a) egy adott bejegyzés első vagy utolsó verziójának lekérésére, (b) egy bejegyzés teljes verzióelőzményének lekérésére, (c) több bejegyzés információinak lekérésére, beleértve az első és az utolsó bejegyzést is. mindegyik verziója.

Vegye figyelembe, hogy a blokklánc peer-to-peer architektúrája miatt az adatfolyamban lévő elemek különböző sorrendben érkezhetnek különböző csomópontokhoz, és a MultiChain lehetővé teszi az elemek visszakeresését, mielőtt azokat egy blokkban „megerősítenék”. Ennek eredményeként minden lekérési API választási lehetőséget kínál a globális (alapértelmezett) vagy a helyi rendezés között. A globális rendezés garantálja, hogy amint a lánc konszenzusra jutott, minden csomópont ugyanazokat az API-hívásokat kapja. A helyi rendezés garantálja, hogy egy adott csomópont esetében az adatfolyam elemeinek sorrendje soha nem változik az API-hívások között. Minden alkalmazás kiválaszthatja az igényeinek megfelelőt.

Streams és a MultiChain ütemterv

Az adatfolyamok megjelenésével befejeztük a MultiChain 1.0 utolsó nagy munkáját, és most már határozottan a béta útján haladunk. Várhatóan a következő néhány hónapot belső tesztcsomagunk bővítésével töltjük (már elég nagy!), befejezzük a Windows és Mac portokat, hozzáadunk néhány hasznos API-t, frissítjük a Felfedező adatfolyamokhoz, a konszenzusos mechanizmus szempontjainak módosítása, webes bemutatónk kiadása, valamint általában a kód és a súgóüzenetek rendbetétele. A legfontosabb, hogy a hibákat amint felfedezik, azonnal kijavítjuk, hogy hibáink ne zavarják meg munkáját.

Hosszabb távon hol illeszkednek a streamek a MultiChain ütemtervbe? Egy lépést hátralépve a MultiChain most három magas szintű funkcionalitási területet kínál:

Engedélyek annak szabályozására, hogy ki csatlakozhat, köthet tranzakciókat, hozhat létre eszközöket/folyamokat, bányászhat/ellenőrizhet és adminisztrálhat.
Eszközök ideértve a kibocsátást, az újrakibocsátást, az átruházást, az atomcserét, a letétet és a megsemmisítést.
Streams API-kkal adatfolyamok létrehozásához, íráshoz, előfizetéshez, indexeléshez és visszakereséshez.

A MultiChain 1.0 (és egy prémium verzió) megjelenése után mi következik ezen a listán? Ha megnézed a API parancs amelyet folyamok létrehozására használnak, észre fog venni egy látszólag felesleges paramétert, amelynek fix értéke stream. Ez a paraméter lehetővé teszi, hogy a MultiChain a jövőben más típusú magas szintű entitásokat támogasson.

A paraméter lehetséges jövőbeli értékei közé tartozik evm (egy Ethereum-kompatibilis virtuális gép), sql (SQL-stílusú adatbázishoz) vagy akár wiki (a közösen szerkesztett szöveghez). Minden olyan megosztott entitás, amelynek állapotát a változások rendezett sorozata határozza meg, potenciális jelölt. Minden ilyen entitásnak szüksége lesz: (a) API-kra, amelyek megfelelő absztrakciót biztosítanak állapotának frissítéséhez, (b) megfelelő mechanizmusokra az előfizetett csomópontok számára az állapot követéséhez, és (c) API-kra az állapot egy részének vagy egészének hatékony lekéréséhez. Arra várunk, hogy megtudjuk, mely más magas szintű entitások lennének a leghasznosabbak, amelyeket mi magunk vagy harmadik felek implementálnak egy plug-in architektúrán keresztül.

Mi a helyzet az intelligens szerződésekkel?

Általános értelemben a MultiChain azt a megközelítést alkalmazza, amelyben dátum megváltoztathatatlanul be van ágyazva egy blokkláncba, de a kód annak értelmezéséhez, hogy az adatok a csomópontban vagy az alkalmazási rétegben vannak. Ez szándékosan különbözik az „intelligens szerződések” paradigmától, amint azt az Ethereum példája, amelyben a kód a blokkláncba van beágyazva, és egy virtuális gépen fut. Elméletileg, mert az okos szerződések azok Turing teljes, képesek reprodukálni a MultiChain vagy bármely más blokklánc platform viselkedését. A gyakorlatban azonban az Ethereum-stílusú intelligens szerződéseknek számos fájdalmas hiányossága van:

Minden csomópontnak el kell végeznie minden számítást, akár érdekes, akár nem. Ezzel szemben a MultiChainben minden csomópont eldönti, hogy melyik adatfolyamra szeretne előfizetni, és figyelmen kívül hagyhatja a mások által tárolt adatokat.
Az intelligens szerződésekhez használt virtuális gép drasztikusan rosszabb teljesítményt nyújt, mint az adott számítógép-architektúrához natívan lefordított kód.
Az intelligens szerződéskód megváltoztathatatlanul egy láncba van ágyazva, megakadályozva a funkciók hozzáadását és a hibák javítását. Ezt erőteljesen demonstrálták a A DAO megszűnése.
Intelligens szerződésbe küldött tranzakciók nem frissíthető a blokklánc állapota mindaddig, amíg a végső sorrend nem ismert, az általános célú számítások természete miatt. Ez késésekhez vezet (amíg egy tranzakciót blokkban meg nem erősítenek), valamint lehetséges visszavonásokat (elágazás esetén a láncban). Ezzel szemben a MultiChain a meg nem erősített tranzakciók mindegyik típusát a megfelelő módon tudja kezelni: (a) a beérkező eszközök azonnal frissítik a csomópont meg nem erősített egyenlegét, (b) a bejövő adatfolyamelemek azonnal elérhetőek, és a globális rendezésük ezt követően véglegesíthető, (c) az engedélyek megváltoznak. azonnal alkalmazzák, majd újrajátsszák a bejövő blokkokban.

Ennek ellenére, ahogy én is mondta korábban, természetesen nem zárjuk ki az intelligens szerződéseket, mint a blokklánc-alkalmazások hasznos paradigmáját, ha és amikor erős felhasználási eseteket látunk. A MultiChainben azonban az intelligens szerződéseket a blokklánc tetején lévő folyamszerű rétegben valósítanák meg, nem pedig a legalacsonyabb tranzakciós szinten. Ez megőrzi a MultiChain kiváló teljesítményét az egyszerűbb blokklánc-entitások, például az eszközök és adatfolyamok esetében, miközben lassabb láncon belüli számítást kínál ott, ahol valóban szükség van rá. De kevesebb ilyen eset van, mint gondolnád.

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

Műszaki kiegészítés

Az adatfolyamokhoz kapcsolódó összes parancs teljes körűen dokumentálva van a MultiChain API oldal, de íme egy rövid összefoglaló:

Hozzon létre egy adatfolyamot a segítségével create stream or createfrom ... stream
Elem hozzáadása egy adatfolyamhoz a következővel: publish or publishfrom
Az adatfolyamok listájának lekérése a használatával liststreams
Az adatfolyam követésének elindítása vagy leállítása a következővel: subscribe és a unsubscribe
A streamelemek lekérése a használatával liststreamitems, liststreamkeyitems és a liststreampublisheritems
A streamelési kulcsok és a megjelenítők listája ezzel liststreamkeys és a liststreampublishers
Nagy adatfolyam-elemek esetén kérje le a teljes adatot a használatával gettxoutdata (Lásd: maxshowndata alább)
Az adatfolyamonkénti engedélyek szabályozása olyan hívásokkal, mint a grant [address] stream1.write
Egy adatfolyam engedélyeinek megtekintése a használatával listpermissions stream1.*

Néhány további fejlesztői megjegyzés a streamekkel kapcsolatban:

A create Az engedély lehetővé teszi egy cím számára folyamok létrehozását.
A vonatkozó adatfolyamonkénti engedélyek write, admin és a activate
Új blokklánc paraméterei: root-stream-name (egyikért sem hagyja üresen), root-stream-open, anyone-can-create, admin-consensus-create, max-std-op-returns-count
Új futásidejű paraméterek: autosubscribe hogy automatikusan feliratkozzon a létrehozott új streamekre és maxshowndata az API-válaszokban lévő adatok mennyiségének korlátozása (lásd gettxoutdata felett).
A streamelem adatainak maximális méretét a max-std-op-return-size blokklánc paraméter, valamint a kisebbik közül maximum-block-size és a max-std-tx-size értékek mínusz néhány száz bájt.
A régi pénztárca formátumot használó csomópontok nem tudnak előfizetni az adatfolyamokra, és frissíteni kell.