MultiChain 1.0 béta 2 és 2.0 ütemterv

Hol tartunk ma és hová megyünk holnap

Ma nagy örömünkre kiadjuk a MultiChain 1.0 második bétaverzióját Linuxra, Windowsra és Macre (egyelőre a Mac verzióhoz fordítás szükséges). Ezzel lezárult a MultiChain 1.0 tervezett fejlesztése – az esetleges hibajavítások kivételével a MultiChain 1.0 végleges, nyári kiadása változatlan marad.

Ebben a hónapban lesz két éve a MultiChain első alfa kiadása óta, 2015 júniusában. Mint minden új termék esetében, most sem voltunk biztosak abban, hogyan reagál a piac, és tudtuk, hogy ezt csak egy módon lehet megtudni: ki kell adni egy minimális életképes termék, azaz egy kezdeti változat, amely jelentős értéket biztosít, de tervezési szempontból előzetes. Szerencsére az első termékünkkel ellentétben CoinSpark, a MultiChain erőteljes és azonnali pozitív választ kapott. Ezt az értelmes funkciókérések szökőárja kísérte, amelyek közül sokat már megvalósítottunk. A termék fejlesztésével párhuzamosan a felhasználás is minden tekintetben látványosan nőtt. A MultiChain webhely például 3,000 júliusában kevesebb mint 2015 látogatót fogadott, és ma már havonta ennek a tízszeresét hozza.

MultiChain teljesítmény

Az elmúlt két évben sok erőfeszítést fektettünk a MultiChain optimalizálásába, amelyből kiindult Bitcoin Core, a nyilvános bitcoin hálózat referencia megvalósítása. Az alábbiakban a tranzakció átviteli sebességének összehasonlítása látható egy egycsomópontos beállítás esetén a termék öt verzióját használva:

.throughput td,.throughput th {text-align:right;}

Összes tranzakció	1.0 alfa 3	1.0 alfa 21	1.0 alfa 22	1.0 1 béta	1.0 2 béta
100	6.5 tps	7.8	541.7	830.6	1465.7
1,000	7.0	7.6	583.9	889.4	1199.6
10,000	4.1	6.4	566.9	746.6	1071.2
100,000	-	6.6	558.0	771.9	1034.2
1,000,000	-	-	548.6	773.6	1055.4

Átlagos tranzakciók másodpercenként, beleértve az API többletköltséget és felépítést, a tranzakciók és blokkok aláírását, bányászását és ellenőrzését.
segítségével végzett tesztek ab HTTP szerver benchmarking eszköz, amely két egyidejű kérést küld a sendtoaddress API.
Szerver specifikációi: Intel Core i7-4770, 4 mag @ 3.4 MHz, 32 GB RAM, Seagate 2 TB 7200 RPM SATA, CentOS 6.4.

Természetesen a legnagyobb ugrás az alfa 22-ben történt, amikor mi átállított adatbázis-vezérelt pénztárcához. A kiadás óta azonban ismét majdnem megdupláztuk a MultiChain sebességét. Reméljük, bebizonyítottuk, hogy a bitcoin másodpercenkénti 4 tranzakciós korlátja sajátos hálózati paramétereinek köszönhető, és nincs összefüggésben a blokkláncokkal általában.

Természetesen a teljesítmény optimalizálása véget nem érő feladat, és nincs oka annak, hogy a MultiChain ne érné el a 10,000 XNUMX tx/sec sebességet 16 magos processzor a megfelelő építészeti változtatásokkal. A felhasználóinkkal és partnereinkkel folytatott beszélgetések alapján azonban úgy tűnik, hogy kevesen számítanak arra, hogy a következő években több mint 1,000 tx/s-ra lesz szükségük. Ezért a fejlesztési erőfeszítéseinket új funkciókra összpontosítjuk, ami szépen elvezet minket a MultiChain 2.0 témájához.

A MultiChain 2.0 áttekintése

A MultiChain 2.0-s verziója lesz az első, amely két kiadásban – Community (nyílt forráskódú) és Enterprise (kereskedelmi) jelenik meg. Itt az ingyenes közösségi kiadásra fogok összpontosítani, mivel csak a MultiChain Enterprise részleteiről beszélünk partnereink. Mindenesetre a Community és Enterprise kiadások nagymértékben kompatibilisek lesznek, amennyiben: (a) a közösségi kiadásra épített alkalmazások módosítás nélkül futnak a MultiChain Enterprise rendszeren, és (b) mindkét kiadás képes lesz kapcsolódni és tranzakciókat folytatni egymással. ugyanazon a láncon.

A továbbfejlesztett funkciók három kulcsfontosságú területe a MultiChain 2.0 mindkét kiadásában:

• Gazdagabb adatmodell az adatfolyamokhoz, beleértve a JSON-dokumentumokat is.
• Egyedi programozható tranzakciószűrők a láncon belüli érvényesítéshez.
• A blokklánc protokolljának és paramétereinek zökkenőmentes frissítése.

Vegyük sorra ezek mindegyikét részletesen.

Gazdagabb adatmodell a streamekhez

A MultiChain streameket 2016 szeptemberében vezették be, és rendkívül népszerűnek bizonyultak. pontban leírtak szerint ezt a hozzászólást, a streamek egyszerű és természetes absztrakciót biztosítanak az általános célú adattároláshoz, indexeléshez és visszakereséshez egy blokkláncon. A MultiChain blokklánc tetszőleges számú elnevezett folyamot tartalmazhat, amelyek mindegyike vagy mindenki számára nyitva állhat írásra, vagy csak bizonyos címekről írható.

A MultiChain 1.0-ban minden adatfolyam-elemhez tartozik egy vagy több kiadó (akik aláírják), egy opcionális kulcs, egy legfeljebb 64 MB méretű bináris adathordozó és egy időbélyeg (amely abból a blokkból származik, amelybe be van ágyazva). Minden csomópont szabadon dönthet arról, hogy mely streamekre iratkozzon fel, vagy automatikusan előfizethet az összes adatfolyamra. Ha egy csomópont előfizetett egy adatfolyamra, akkor valós időben indexeli az adatfolyam tartalmát, lehetővé téve a hatékony visszakeresést kiadó, kulcs, blokk, időbélyeg vagy pozíció szerint.

A MultiChain 2.0 számos módon gazdagítja ezt a streamelési funkciót:

• JSON-elemek. A bináris adatok mellett a streamelemek támogatják a strukturált JSON-objektumokat is, amelyeket a blokkláncon tárolnak hatékony szerializációs formátumban, mint pl. UBJSON. Mivel a MultiChain API már végig JSON-t használ, ezek a JSON-objektumok természetes és nyilvánvaló módon írhatók és olvashatók lesznek.
• Több gomb. Az adatfolyam-elemek több kulcsot támogatnak, lehetővé téve egyetlen adat többszöri indexelését a visszakereséshez liststreamkeyitems. Folyamatosan értékeljük, hogy a MultiChain mennyi adatbázis-funkciót tartalmazzon, és nem számítunk arra, hogy a 2.0-s verzióban támogatjuk az alelemek indexelését a JSON-adatfolyamelemeken belül. Több kulcs engedélyezése adatfolyam-elemenként ésszerű megoldást jelent.
• Több elem atomikus írása. A MultiChain 1.0 lehetővé teszi, hogy egyetlen tranzakció több adatfolyamba írjon, de nem írjon több elemet ugyanabba a folyamba. A MultiChain 2.0 megszünteti ezt a korlátozást.
• JSON összevonás. A JSON-objektumok bármely rendezett listája természetesen összelapítható vagy összegezhető „egyesített” objektum létrehozásához. Az egyesített objektum tartalmazza az egyes objektumokban megjelenő összes kulcsot, ahol az egyes kulcsokhoz tartozó értékeket az utolsó objektumtól veszik, amelyben az adott kulcs szerepel. Ha úgy tetszik, az egyesített objektum egy adatbázissor végső állapota, amelynek oszlopait az első objektum határozza meg, és a későbbi objektumok bővítik vagy frissítik. A MultiChain 2.0 API-kat ad hozzá, hogy könnyen és gyorsan lekérhesse az egyesített objektumokat a JSON-elemekhez egy adatfolyamban egy adott kulccsal vagy kiadóval.

Ezek a funkciók a fejlesztők jelenlegi adatfolyam-használati szokásaiból származnak. Más szóval, megfigyeljük, hogy az alkalmazás szintjén sokan mit építenek a MultiChainre, és ezt a funkcionalitást magába a MultiChainbe hozzuk – ezt a mintát továbbra is alkalmazni kívánjuk. Most, hogy a streamelemek típusinformációkat is tartalmaznak majd, a jövőben könnyen kibővíthetők más adatformátumok, például XML, HDF5 és a PANTOMIM-azonosított tartalom. Nem beszélve az átlátható on-chain tömörítés és titkosítás lehetőségeiről.

A MultiChain 2.0 is támogatja a JSON-objektumokat a nyers tranzakciós metaadatokhoz (azaz nem a streamelemekhez), valamint az eszközkiadási és adatfolyam-létrehozási események metaadatait a MultiChain 1.0-ban megvalósított csak szöveges kulcs/érték párok helyett. Az listassets Az API JSON-egyesítést kínál a tartalom összes kibocsátási eseményénél, így az egyes kiadások metaadatai hatékonyan frissíthetik az eszköz végső leírását.

Egyedi tranzakciószűrők

Sokat gondolkodtunk azon, hogyan adjunk egyéni programozható szabályokat a MultiChainhez. Míg az Ethereum „intelligens szerződés” paradigmája népszerű, számos kulcsfontosságú hiányossága van a nagy áteresztőképességű, engedélyezett blokkláncoknál. Először is, az intelligens szerződések globális függőséget vezetnek be a blokklánc teljes állapotában, ami drasztikusan rontja a párhuzamosságot és a teljesítményt. Másodszor, az intelligens szerződések nem akadályozhatják meg a helytelen tranzakciók blokkláncba való beágyazását, hanem csak megakadályozzák, hogy ezek a tranzakciók frissítsék a blokklánc-adatbázis állapotát. Míg hosszú távon azt várjuk, hogy egy Ethereum-kompatibilis virtuális gépet magas szintű absztrakcióként kínáljanak fel a MultiChain-en belül, nem gondoljuk, hogy ez a megfelelő megoldás az alacsony szintű érvényesítéshez.

A MultiChain 2.0 egy másik paradigmát vezet be, úgynevezett tranzakciószűrőket, amelyek az egyedi tranzakciókat minden globális állapotra való hivatkozás nélkül érvényesítik. Azt várjuk, hogy a szűrőket Javascriptben írják, és egy beágyazott futásidejű motoron belül hajtsák végre, mint pl v8, amelyet a Google használ króm böngésző és a node.js felület. Természetesen gondoskodnunk kell arról, hogy a szűrőkód a blokklánc minden csomópontján azonos módon fusson, blokkolva minden a non-determinizmus forrásai például az idő leolvasása, véletlen számok használata, hálózat vagy lemez elérése, vagy matematikai műveletek végrehajtása, amelyek a gazdagép architektúrájától függenek. Egy determinisztikus Javascript futtatókörnyezet létrehozása kihívást jelent, de (anélkül, hogy túl sokat adnánk) úgy gondoljuk, hogy a jövőben számos más MultiChain szolgáltatás számára hasznos lesz.

A szűrők egy JSON-objektumot adnak át, amely leír egy egyedi tranzakciót, a strukturált módon, mint a kimenete decoderawtransaction de extra mezőkkel. Például a JSON minden tranzakciós bemenete tartalmazni fog egy struktúrát, amely leírja az általa elköltött előző tranzakciós kimenetet, és minden címhez az adott címhez jelenleg tartozó engedélyek listája tartozik. A szűrő feladata, hogy egy logikai értéket adjon vissza, jelezve, hogy a tranzakció elfogadható-e, és ha nem, akkor szöveges hibát adjon meg, amely megmagyarázza, miért. A MultiChain API-ja parancsokat tartalmaz majd a szűrők létrehozására, a korábbi vagy új tranzakciókon való tesztelésre, valamint a rendszergazdai konszenzus függvényében történő aktiválásra.

Az intelligens szerződésekkel ellentétben, ha hibát fedeznek fel a szűrő kódjában, az könnyen helyettesíthető egy új verzióval. Mindazonáltal, mint minden Turing-teljes kód, a szűrők továbbra is fennáll annak a veszélye, hogy végtelen ciklusba lépnek. Ezt a problémát kétféleképpen lehet enyhíteni:

• A szűrőket csak a lánc adminisztrátorai telepíthetik és aktiválhatják, konszenzus alapján. Ez lehetőséget ad minden adminisztrátornak, hogy alaposan megvizsgálja a szűrő kódját, mielőtt az aktiválásra szavazna.
• Minden jól viselkedő csomópont érvényesíti az új tranzakciókat az aktív szűrők használatával, mielőtt továbbítaná azokat a társcsomópontjainak. Ennek eredményeként, ha egy tranzakció szűrőt küld egy végtelen hurokba, a tranzakció nem terjedhet túl azon a csomóponton, amelyik létrehozta.

Várakozásaink szerint az egyik népszerű szűrőalkalmazás az adatfolyam-elemek érvényesítését végzi. Egy szűrő például biztosíthatja, hogy egy adatfolyam JSON-elemeinek bizonyos mezői egy adott tartományba eső számokat tartalmazzanak. A MultiChain 1.0-ban ezt a fajta érvényesítést az alkalmazás szintjén kell elvégezni, akár adatfolyamelemek írásakor (ha a forrás megbízható), akár olvasáskor. Ezzel szemben a MultiChain 2.0 lehetővé teszi ezeknek a szabályoknak a blokkláncba való beágyazását, mint pl. ellenőrizze a megszorításokat relációs adatbázisban.

A MultiChain 2.0 két további funkciót is tartalmaz majd, amelyek még erősebbé teszik a szűrőket. Először is bevezeti a felhasználó által definiált engedélyeket, amelyek a MultiChain által meghatározott nyolc jogosultság mellett léteznek. A szokásos engedélyekhez hasonlóan ezeket is meghatározott címekre adják meg a rendszergazdák (és bizonyos esetekben a felhasználók activate jogosultságok), és a címek mellett szerepelnek a szűrőnek átadott JSON-objektumban. Például egy szűrő biztosíthatja, hogy csak egy adott felhasználó által meghatározott engedéllyel rendelkező címek írhassanak bizonyos típusú adatokat egy adatfolyamba, vagy tranzakciókat hajtsanak végre egy adott eszközzel egy bizonyos küszöbérték felett.

Másodszor, a MultiChain 2.0 támogatja az egyéni (bináris vagy JSON) metaadatokat a szokásos tranzakciós kimeneteken belül. Ez lehetővé teszi, hogy bármely kimenet általános adatbázis-sorként működjön, a benne lévő cím „tulajdonában”. A szűrők minden metaadatot látni fognak a tranzakció elköltött és létrehozott kimenetein belül a JSON-leírás részeként. Ennek eredményeként a MultiChain univerzális megosztott adatbázismotor lesz, ahol a tranzakció érvényességét az általa létrehozott és törölt sorok testreszabható függvénye határozza meg. (Ha ez kissé elvontnak hangzik, biztosan hozunk néhány konkrét példát.)

Blockchain frissítés

Mivel a blokkláncokat úgy tervezték, hogy évekig működjenek, előfordulhat, hogy idővel változtatni kell a jellemzőiken. A MultiChain jelenlegi verziója már megfelelő fokú rugalmasságot biztosít, lehetővé téve az engedélyek módosítását (beleértve az adminisztrátorokat és a bányászokat konszenzus alapján), új eszközök és adatfolyamok létrehozását, valamint csomópontok zökkenőmentes hozzáadását vagy eltávolítását a hálózatról. Ennek ellenére a MultiChain 1.0-ban a blokklánc alapja paraméterek, mint például a maximális blokkméret és a cél megerősítési ideje, a lánc létrehozásakor rögzítésre kerülnek, és utólag nem módosíthatók.

A MultiChain 2.0 hozzáadja a blokklánc frissítésének lehetőségét, lehetővé téve sok (de nem az összes) paraméter módosítását, miközben a lánc tovább fut. Más fontos műveletekhez hasonlóan a blokklánc frissítéséhez is testreszabható szintű rendszergazdai konszenzusra van szükség, ahol ez a szint maga egy megváltoztatható paraméter. A frissítések egy bizonyos blokktól lépnek életbe, és ezt követően minden következő blokkra érvényesek a következő frissítésig.

A blokklánc frissíthető paraméterei a következők:

• Protokoll verzió. Ez lehetővé teszi a MultiChain egyik verziójával létrehozott blokklánc frissítését, hogy támogassa az új verzió funkcióit, például a JSON-adatfolyamelemeket vagy a tranzakciószűrőket. Valóban, a protokoll verzió 10008 A MultiChain 1.0 alpha 29-ben bevezetett (és a bétaverzióban használt) már jövőre is alkalmassá vált az ilyen típusú frissítések dokumentálatlan támogatásával. Miután a MultiChain 1.0 blokkláncot frissítették a 2.0 protokollra, hozzáférhet az itt leírt egyéb paraméterváltozásokhoz is.
• Blockchain skálázás. A népszerűvé váló blokkláncok túlnőhetnek a megerősítési célidőhöz vagy a maximális tranzakció- és blokkmérethez beállított kezdeti értékeken. A MultiChain 2.0 lehetővé teszi ezen értékek szükség szerint növelését vagy csökkentését.
• Engedélyezési modell. A MultiChain 2.0 lehetővé teszi számos engedélyezési és irányítási paraméter frissítését, beleértve: (a) anyone-can-* paraméterek, amelyek szabályozzák a blokklánc megnyitásának vagy zárásának módjait, (b) admin-consensus-* paraméterek, amelyek meghatározzák az egyes műveletekhez szükséges rendszergazdai konszenzus szintjeit, és (c) a mining-diversity paraméter, amely a kör-robin konszenzus algoritmus szigorúságát szabályozza.

Ha ezt a frissítési funkciót bevezették, semmi oka nem lehet annak, hogy a MultiChainben létrehozott blokklánc ne tudna futni évtizedekig vagy még tovább.

Előretekintés

Már elkezdtük a munkát a MultiChain 2.0-n, és alig várjuk, hogy megvalósíthassuk ezt az ütemtervet. Kétségtelenül más fejlesztések is szerepelni fognak benne. A MultiChain 1.0-hoz hasonlóan alfa-kiadásokkal is készülünk, így a fejlesztők használhatják és megtanulhatják az új funkciókat a megvalósítás során (és természetesen jelenthetnek minden problémát vagy hiányosságot). Természetesen ezen időszak alatt is fenntartjuk az 1.0-s verziót, és kijavítjuk a megjelenő hibákat.

Befejezésül szeretném megköszönni fejlesztőcsapatunknak, Dr. Michael Rozantsev vezetésével folyamatos kiválóságukat és kemény munkáját. A MultiChaint egy egyszerű szoftverfejlesztési projektnek tekintjük, amelyben mindenekelőtt a kódminőség és a tesztelés számít. Megtiszteltetés számomra, hogy olyan emberekkel dolgozhatok, akik egy összetett terméklátást ilyen figyelemre méltó hatékonysággal és gyorsasággal stabilan működő szoftverré alakítanak.

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