Načrt načrta MultiChain 1.0 beta 2 in 2.0

Kje smo danes in kam gremo jutri

Danes z veseljem izdamo drugo različico beta MultiChain 1.0 za Linux, Windows in Mac (zaenkrat različica za Mac zahteva prevajanje). S tem se zaključuje načrtovani razvoj MultiChain 1.0 – z izjemo morebitnih popravkov napak bo končna izdaja MultiChain 1.0 čez poletje nespremenjena.

Ta mesec prav tako zaznamujeta dve leti od prve alfa izdaje MultiChaina junija 2015. Kot pri vsakem novem izdelku nismo bili prepričani, kako se bo trg odzval, in vedeli smo, da obstaja samo en način, da to ugotovimo – izdati minimalni donosni izdelek, kar pomeni začetno različico, ki zagotavlja pomembno vrednost, vendar je po zasnovi preliminarna. Na srečo, za razliko od našega prvega izdelka CoinSpark, je MultiChain prejel močan in takojšen pozitiven odziv. To je spremljal cunami zahtev po razumnih funkcijah, od katerih smo mnoge zdaj uvedli. Vzporedno z razvojem izdelka je uporaba izjemno narasla v vseh merilih. Na primer, spletno mesto MultiChain je julija 3,000 prejelo manj kot 2015 obiskovalcev, zdaj pa mesečno prinese desetkrat več obiskovalcev.

Zmogljivost MultiChain

V zadnjih dveh letih smo vložili veliko truda v optimizacijo MultiChaina, ki je bil razcepljen Bitcoin Core, referenčna izvedba za javno omrežje bitcoin. Spodaj je primerjava prepustnosti transakcij za nastavitev z enim vozliščem z uporabo petih različic izdelka:

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

Skupno število transakcij	1.0 alfa 3	1.0 alfa 21	1.0 alfa 22	1.0 1 beta	1.0 2 beta
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

Povprečne transakcije na sekundo, vključno s stroški API-ja ter transakcijami in bloki za gradnjo, podpisovanje, rudarjenje in preverjanje.
Preizkusi, izvedeni z uporabo ab Orodje za primerjalno analizo strežnika HTTP, ki pošilja dve sočasni zahtevi na sendtoaddress API.
Specifikacije strežnika: Intel Core i7-4770, 4 jedra @ 3.4 MHz, 32 GB RAM, Seagate 2 TB 7200 RPM SATA, CentOS 6.4.

Seveda se je največji skok zgodil v alfi 22, ko smo prehod v denarnico, ki temelji na bazi podatkov. Toda od te izdaje smo spet skoraj podvojili hitrost MultiChaina. Upamo, da smo dokazali, da je omejitev bitcoina na 4 transakcije na sekundo posledica njegovih posebnih omrežnih parametrov in nima nobene zveze z verigami blokov na splošno.

Seveda je optimizacija zmogljivosti naloga, ki se nikoli ne konča, in ni razloga, zakaj MultiChain ne bi dosegel 10,000 tx/s na 16-jedrni procesor z ustreznimi arhitekturnimi spremembami. Vendar se na podlagi pogovorov z našimi uporabniki in partnerji zdi, da malokdo pričakuje, da bo v naslednjih nekaj letih potreboval več kot 1,000 tx/s. Zato svoja razvojna prizadevanja preusmerjamo na nove funkcije, kar nas lepo pripelje do teme MultiChain 2.0.

Pregled MultiChain 2.0

Različica 2.0 MultiChain bo prva na voljo v dveh izdajah – Community (odprtokodna) in Enterprise (komercialna). Tukaj se bom osredotočil na brezplačno izdajo skupnosti, saj se o podrobnostih MultiChain Enterprise pogovarjamo le z naših partnerjev. V vsakem primeru bosta izdaji Skupnosti in Enterprise zelo združljivi, saj: (a) se bodo aplikacije, zgrajene na izdaji Skupnosti, izvajale brez sprememb v MultiChain Enterprise in (b) se bosta obe izdaji lahko povezovali in opravljali transakcije med seboj. na isti verigi.

Tri ključna področja izboljšane funkcionalnosti v obeh izdajah MultiChain 2.0 bodo:

• Bogatejši podatkovni model za tokove, vključno z dokumenti JSON.
• Programirljivi transakcijski filtri po meri za preverjanje v verigi.
• Brezhibno posodabljanje protokola in parametrov verige blokov.

Obrnemo se k podrobni razpravi o vsakem od teh.

Bogatejši podatkovni model za tokove

MultiChain tokovi so bili predstavljeni septembra 2016 in so se izkazali za izjemno priljubljene. Kot je opisano v to delovno mesto, tokovi zagotavljajo preprosto in naravno abstrakcijo za splošno shranjevanje podatkov, indeksiranje in iskanje v verigi blokov. Blokovna veriga MultiChain lahko vsebuje poljubno število imenovanih tokov, od katerih je vsak lahko odprt vsem za pisanje ali zapisljiv samo z določenih naslovov.

V MultiChain 1.0 ima vsak element toka enega ali več izdajateljev (ki ga podpišejo), izbirni ključ, binarni podatkovni tovor velikosti do 64 MB in časovni žig (izpeljan iz bloka, v katerega je vdelan). Vsako vozlišče se lahko prosto odloči, na katere tokove se bo naročilo, ali pa se lahko samodejno naroči na vse tokove. Če je vozlišče naročeno na tok, indeksira vsebino tega toka v realnem času, kar omogoča učinkovito iskanje po založniku, ključu, bloku, časovnem žigu ali položaju.

MultiChain 2.0 bo obogatil funkcionalnost tega toka na več načinov:

• Artikli JSON. Poleg binarnih podatkov bodo elementi toka podpirali strukturirane objekte JSON, shranjene v verigi blokov v učinkovitem serializacijskem formatu, kot je npr. UBJSON. Ker MultiChain API povsod že uporablja JSON, bodo ti objekti JSON zapisljivi in ​​berljivi na naraven in očiten način.
• Več tipk. Elementi toka bodo podpirali več ključev, kar bo omogočilo indeksiranje posameznega podatka na več načinov za iskanje z liststreamkeyitems. Nenehno ocenjujemo, koliko funkcionalnosti baze podatkov naj vključimo v MultiChain, in ne pričakujte, da bomo v različici 2.0 podpirali indeksiranje podelementov znotraj elementov toka JSON. Dovolitev več ključev na element toka zagotavlja razumno rešitev.
• Atomic piše več elementov. MultiChain 1.0 dovoljuje, da ena transakcija zapisuje v več tokov, ne pa tudi za pisanje več elementov v isti tok. MultiChain 2.0 bo odstranil to omejitev.
• Združitev JSON. Vsak urejen seznam objektov JSON je mogoče naravno sploščiti ali povzeti, da ustvarite »združeni« objekt. Združeni objekt vsebuje vse ključe, ki se pojavljajo v posameznih objektih, pri čemer je vrednost, ki ustreza vsakemu ključu, vzeta iz zadnjega predmeta, v katerem se ta ključ pojavi. Če želite, je spojeni objekt končno stanje vrstice zbirke podatkov, katere stolpce definira prvi objekt in razširijo ali posodobijo kasnejši objekti. MultiChain 2.0 bo dodal API-je za preprosto in hitro pridobivanje združenega predmeta za elemente JSON v toku z določenim ključem ali založnikom.

Te funkcije izhajajo iz običajnih načinov, na katere razvijalci trenutno uporabljajo tokove. Z drugimi besedami, opazujemo, kaj mnogi ljudje gradijo na vrhu MultiChaina na ravni aplikacije in to funkcionalnost prenašajo v sam MultiChain – vzorec, ki ga nameravamo uporabljati še naprej. Zdaj, ko bodo elementi toka vključevali informacije o vrsti, jih je mogoče v prihodnosti preprosto razširiti, da bodo podpirali druge formate podatkov, kot so XML, HDF5 in Mime- identificirane vsebine. Da ne omenjam možnosti preglednega stiskanja in šifriranja v verigi.

MultiChain 2.0 bo podpiral tudi objekte JSON za neobdelane transakcijske metapodatke (tj. ne elemente toka) kot tudi metapodatke za izdajo sredstev in dogodke ustvarjanja toka, namesto samo besedilnih parov ključ/vrednost, implementiranih v MultiChain 1.0. The listassets API bo ponudil združevanje JSON v vseh dogodkih izdaje sredstva, tako da lahko metapodatki vsake izdaje učinkovito posodobijo končni opis sredstva.

Transakcijski filtri po meri

Veliko smo razmišljali o tem, kako v MultiChain dodati programabilna pravila po meri. Čeprav je Ethereumova paradigma »pametne pogodbe« priljubljena, ima številne ključne pomanjkljivosti za dovoljene verige blokov z visoko prepustnostjo. Prvič, pametne pogodbe uvajajo globalno odvisnost v celotnem stanju verige blokov, kar drastično poslabša sočasnost in zmogljivost. Drugič, pametne pogodbe ne morejo preprečiti vdelave nepravilnih transakcij v verigo blokov, ampak le preprečijo, da bi te transakcije posodabljale stanje baze podatkov verige blokov. Medtem ko dolgoročno pričakujemo, da bo navidezni stroj, združljiv z Ethereumom, ponujen kot visokonivojska abstrakcija znotraj MultiChaina, menimo, da to ni prava rešitev za validacijo na nizki ravni.

MultiChain 2.0 bo uvedel drugačno paradigmo, imenovano transakcijski filtri, ki preverjajo posamezne transakcije brez sklicevanja na katero koli globalno stanje. Pričakujemo, da bodo filtri napisani v Javascriptu in izvedeni znotraj vdelanega izvajalnega mehanizma, kot je npr v8, ki se uporablja v Googlu Krom brskalnik in Node.js platforma. Seveda bomo morali zagotoviti, da se koda filtra izvaja enako na vsakem vozlišču v verigi blokov in tako blokira vse viri nedeterminizma kot je branje časa, uporaba naključnih števil, dostopanje do omrežja ali diska ali izvajanje matematičnih operacij, ki so odvisne od arhitekture gostiteljskega strežnika. Ustvarjanje determinističnega izvajalnega okolja Javascript je izziv, vendar (ne da bi preveč izdali) verjamemo, da bo uporabno za več drugih funkcij MultiChain v prihodnosti.

Filtri bodo prejeli objekt JSON, ki opisuje posamezno transakcijo, strukturiran kot rezultat decoderawtransaction vendar z dodatnimi polji. Na primer, vsak vnos transakcije v JSON bo vključeval strukturo, ki opisuje prejšnji izhod transakcije, ki jo porabi, in vsak naslov bo spremljal seznam dovoljenj, ki jih trenutno ima ta naslov. Naloga filtra je, da vrne logično vrednost, ki označuje, ali je transakcija sprejemljiva, in če ni, posreduje besedilno napako, ki pojasnjuje, zakaj. MultiChain API bo vključeval ukaze za ustvarjanje filtrov, njihovo preizkušanje na prejšnjih ali novih transakcijah in njihovo aktiviranje v skladu s soglasjem skrbnika.

Za razliko od pametnih pogodb, če je v kodi za filter odkrita napaka, jo je mogoče enostavno nadomestiti z novo različico. Kljub temu, tako kot vsa Turingova popolna koda, tudi pri filtrih še vedno obstaja tveganje vstopa v neskončno zanko. To težavo bomo rešili na dva načina:

• Filtre lahko namestijo in aktivirajo samo skrbniki verige ob soglasju. To daje vsakemu administratorju možnost, da podrobno preuči kodo filtra, preden glasuje za njegovo aktivacijo.
• Vsa vozlišča, ki se dobro obnašajo, bodo potrdila nove transakcije z uporabo aktivnih filtrov, preden jih posredujejo svojim enakovrednim vozliščem. Posledično, če transakcija pošlje filter v neskončno zanko, se transakcija ne bi smela širiti onkraj vozlišča, ki jo je ustvarilo.

Pričakujemo, da bo ena priljubljena aplikacija za filtre preverjala elemente toka. Filter bi lahko na primer zagotovil, da nekatera polja v elementih JSON toka vsebujejo številke v določenem obsegu. V MultiChain 1.0 je treba to vrsto preverjanja opraviti na ravni aplikacije, bodisi pri pisanju elementov toka (če je vir zaupanja vreden) ali pri njihovem branju. Nasprotno pa bo MultiChain 2.0 omogočil vdelavo teh pravil v samo verigo blokov, podobno kot preverite omejitve v relacijski bazi podatkov.

MultiChain 2.0 bo vključeval dve dodatni funkciji, da bodo filtri še močnejši. Prvič, uvedel bo uporabniško definirana dovoljenja, ki obstajajo poleg osmih dovoljenj, ki jih definira MultiChain. Tako kot pri običajnih dovoljenjih bodo ta določenim naslovom dodelili skrbniki (in v nekaterih primerih uporabniki z activate privilegiji) in vključeni poleg naslovov v objekt JSON, posredovan filtru. Na primer, filter bi lahko zagotovil, da lahko samo naslovi z določenim uporabniško določenim dovoljenjem zapišejo določene vrste podatkov v tok ali izvedejo transakcijo v določenem sredstvu nad določenim pragom.

Drugič, MultiChain 2.0 bo podpiral metapodatke po meri (binarne ali JSON) znotraj rednih izhodov transakcij. To bo omogočilo, da kateri koli izhod deluje kot splošna vrstica baze podatkov, ki je »v lasti« naslova znotraj. Filtri bodo videli vse metapodatke znotraj porabljenih in ustvarjenih rezultatov transakcije kot del opisa JSON. Posledično bo MultiChain postal univerzalni mehanizem skupne baze podatkov, kjer je veljavnost transakcije določena s prilagodljivo funkcijo vrstic, ki jih ustvari in izbriše. (Če se to sliši nekoliko abstraktno, bomo zagotovo zagotovili nekaj konkretnih primerov.)

Posodabljanje verige blokov

Ker so verige blokov zasnovane tako, da delujejo več let, bo morda treba njihove značilnosti sčasoma spremeniti. Trenutna različica MultiChain že zagotavlja precejšnjo stopnjo prilagodljivosti, saj omogoča spreminjanje dovoljenj (vključno s soglasjem skrbnikov in rudarjev), ustvarjanje novih sredstev in tokov ter nemoteno dodajanje ali odstranjevanje vozlišč iz omrežja. Kljub temu je v MultiChain 1.0 osnova blockchaina parametri, kot sta največja velikost bloka in ciljni čas potrditve, so določeni, ko je veriga ustvarjena in jih ni mogoče pozneje spremeniti.

MultiChain 2.0 bo dodal možnost posodobitve verige blokov, kar bo omogočilo spreminjanje številnih (vendar ne vseh) njenih parametrov, medtem ko veriga še naprej teče. Tako kot druge pomembne operacije bo posodabljanje verige blokov zahtevalo prilagodljivo raven skrbniškega soglasja, kjer je ta raven parameter, ki ga je mogoče spremeniti. Posodobitve bodo začele veljati od določenega bloka in nato veljale za vsak naslednji blok do naslednje posodobitve.

Parametri verige blokov, ki jih je mogoče posodobiti, bodo vključevali:

• Različica protokola. To bo omogočilo nadgradnjo verige blokov, ustvarjene z eno različico MultiChain, da bo podpirala funkcije v novi različici, kot so elementi toka JSON ali filtri transakcij. Dejansko različica protokola 10008 uveden v MultiChain 1.0 alpha 29 (in uporabljen v različici beta), je že pripravljen za prihodnost z nedokumentirano podporo za to vrsto nadgradnje. Ko je veriga blokov MultiChain 1.0 nadgrajena na protokol 2.0, bo dobila tudi dostop do drugih sprememb parametrov, opisanih tukaj.
• Skaliranje verige blokov. Verige blokov, ki postanejo priljubljene, lahko prerastejo začetne vrednosti, določene za njihov ciljni čas potrditve ali največje velikosti transakcij in blokov. MultiChain 2.0 bo omogočil povečanje ali zmanjšanje teh vrednosti po potrebi.
• Model dovoljenj. MultiChain 2.0 bo omogočil posodabljanje številnih parametrov v zvezi z dovoljenji in upravljanjem, vključno z: (a) anyone-can-* parametre, ki nadzorujejo načine, na katere je veriga blokov odprta ali zaprta, (b) admin-consensus-* parametre, ki določajo ravni skrbniškega soglasja, potrebnega za določene operacije, in (c) mining-diversity parameter, ki nadzoruje strogost soglasnega algoritma krožnega dela.

Ko je ta funkcija posodabljanja implementirana, ne bi smelo biti razloga, da veriga blokov, ustvarjena v MultiChain, ne bi delovala več desetletij ali več.

Pogled naprej

Delo na MultiChain 2.0 smo že začeli in se veselimo uresničitve tega načrta. Brez dvoma bodo vključene tudi druge izboljšave. Tako kot pri MultiChain 1.0 bomo imeli na poti alfa izdaje, tako da bodo razvijalci lahko uporabljali in se učili novih funkcij, ko bodo implementirane (in seveda poročali o morebitnih težavah ali pomanjkljivostih). Seveda bomo v tem obdobju še naprej vzdrževali različico 1.0 in popravljali morebitne napake, ki se pojavijo.

Na koncu bi se rad zahvalil naši razvojni ekipi, ki jo vodi dr. Michael Rozantsev, za njihovo nenehno odličnost in trdo delo. MultiChain vidimo kot preprost projekt programskega inženiringa, pri katerem štejeta predvsem kakovost kode in testiranje. V čast mi je delati z ljudmi, ki lahko kompleksno vizijo izdelka spremenijo v stabilno delujočo programsko opremo s tako izjemno učinkovitostjo in hitrostjo.

Prosimo, pošljite kakršne koli pripombe na LinkedIn.