Blokirne verige s podatki o verigi

Ko je hash vreden milijon besed

Do zdaj je že jasno, da veliko primerov uporabe blockchaina nima nobene zveze s finančnimi transakcijami. Namesto tega je namen verige omogočiti decentralizirano združevanje, urejanje, časovno označevanje in arhiviranje kaj vrsto informacij, vključno s strukturiranimi podatki, dopisovanjem ali dokumentacijo. Osnovna vrednost blockchaina omogoča udeležencem, da se dokazilo in trajno dogovorijo o tem, kaj natančno so bili vneseni, kdaj in kdo, ne da bi se zanašali na zaupanja vrednega posrednika. Na primer, nedavno predstavljeni SAP blockchain platforma, ki podpira tkanine MultiChain in Hyperledger, je namenjen širokemu razponu dobavne verige in drugim nefinančnim aplikacijam.

Najpreprostejši način uporabe blokovne verige za snemanje podatkov je vstavljanje vsakega kosa podatkov neposredno v transakcijo. Vsako transakcijo blockchain digitalno podpiše ena ali več strank, podvoji na vsako vozlišče, jo naroči in časovno omeji algoritem soglasja verige in jo trajno shrani na varen način. Vsi podatki v transakciji bodo torej shranjeni enako, a neodvisno v vsakem vozlišču, skupaj z dokazilom o tem, kdo jih je napisal in kdaj. Uporabniki verige lahko te podatke pridobijo v vsakem prihodnjem času.

Na primer, MultiChain 1.0 je omogočil ustvarjanje enega ali več imenovanih "tokov" v verigi blokov in jih nato uporabil za shranjevanje in pridobivanje neobdelanih podatkov. Vsak tok ima svoj nabor dovoljenj za pisanje in vsako vozlišče lahko prosto izbere, na katere tokove se naročite. Če je vozlišče naročeno na tok, indeksira njegovo vsebino v realnem času, kar omogoča hitro iskanje predmetov glede na njihovo naročilo, časovni žig, številko bloka ali naslov izdajatelja, pa tudi prek "ključa" (ali nalepke) s katerimi lahko predmete označite. MultiChain 2.0 (od alfa 1) razširjen tok za podporo besedila Unicode ali podatkov JSON, pa tudi več tipk na element in več elementov na transakcijo. Prav tako je dodal funkcije povzetka, kot je "združitev JSON", ki na uporaben način združujejo predmete z istim ključem ali založnikom.

Zaupnost in razširljivost

Čeprav shranjevanje podatkov neposredno na blockchain deluje dobro, imata dve ključni pomanjkljivosti - zaupnost in razširljivost. Za začetek zaupnosti je vsebina vsakega tokovnega elementa vidna na vsakem vozlišču v verigi in to ni nujno zaželen rezultat. V mnogih primerih mora biti podatek viden samo za določeno podmnožico vozlišč, tudi če so potrebna druga vozlišča za pomoč pri njegovem naročanju, časovnem žigosanju in notarizaciji.

Zaupnost je razmeroma enostavno rešiti s šifriranjem informacij, preden so vdelane v transakcijo. Dešifrirni ključ za vsak podatek se deli samo s tistimi udeleženci, ki naj bi ga videli. Dobavo ključev lahko izvajamo na verigi z asimetrično kriptografijo (kot opisano tukaj) ali preko mehanizma zunaj verige, kot je prednostno. Vsako vozlišče, ki nima ključa za dešifriranje elementa, ne bo imelo nič drugega kot binarno gibanje.

Na drugi strani je razširljivost pomembnejši izziv. Recimo, da bi morala vsaka spodobna platforma blockchain podpirati omrežni pretok 500 transakcij na sekundo. Če je namen verige shranjevanje informacij, je velikost vsake transakcije odvisna predvsem od tega, koliko podatkov vsebuje. Vsaka transakcija bo za shranjevanje pošiljateljevega naslova, digitalnega podpisa in nekaj drugih bitov in kosov potrebovala (vsaj) 100 bajtov režijskih stroškov.

Če vzamemo preprost primer, kjer je vsak element majhna JSON struktura 100 bajtov, bi skupni pretok podatkov znašal 100 kilobajtov na sekundo, računano od 500 × (100 + 100). To pomeni manj kot 1 megabit / sekundo pasovne širine, kar je udobno v zmogljivosti katere koli sodobne internetne povezave. Podatki bi se kopičili s hitrostjo približno 3 terabajte na leto, kar ni majhen znesek. Toda z 12 terabajtskimi trdi diski zdaj široko dostopnain RAID krmilniki, ki združujejo več fizičnih pogonov v en sam logičen, bi lahko brez težav in 10 stroškov shranili 20-XNUMX let podatkov na vsako vozlišče.

Vendar pa so stvari videti zelo drugače, če hranimo večje podatke, kot je skenirana dokumentacija. Primerno kakovostno JPEG skeniranje papirja A4 formata je lahko velikosti 500 kilobajtov. Pomnožite to s 500 transakcijami na sekundo in gledamo na 250 pretokov megabajtov na sekundo To pomeni 2 gigabita / sekundo pasovne širine, kar je hitrejše kot večina lokalnih omrežij, kaj šele povezave z internetom. Pri najcenejših spletnih storitvah Amazon objavljena cena 0.05 USD na gigabajt, pomeni letni račun pasovne širine v višini 400,000 8000 USD na vozlišče. In kam bo vsako vozlišče shranilo XNUMX terabajtov novih podatkov, ustvarjenih letno?

Jasno je, da za blockchain aplikacije, ki shranjujejo veliko velikih kosov podatkov, preprosto shranjevanje v verigi ni praktična izbira. Če želite dodati škodo poškodbam, če so podatki šifrirani za rešitev težave z zaupnostjo, vozlišča prosijo, da shranijo ogromno informacij, ki jih sploh ne morejo prebrati. Za udeležence omrežja to ni privlačen predlog.

Raztopina ostrenja

Kako torej rešimo problem razširljivosti podatkov? Kako lahko izkoristimo decentralizirano notarsko overitev podatkov blockchaina, ne da bi te podatke posnemali na vsako vozlišče v verigi?

Odgovor je s pametnim koščkom tehnologije, imenovanim "hash". Hash je dolgo število (pomislite na 256 bitov ali približno 80 decimalnih števk), ki enolično identificira del podatkov. Hash se izračuna iz podatkov s pomočjo enosmerna funkcija ki ima pomembno kriptografsko lastnost: Glede na kateri koli podatek je enostavno in hitro izračunati njegov hash. A glede na določen hash je računsko neizvedljivo najti delček podatkov, ki bi ustvaril ta hash. In ko rečemo "računalniško neizvedljivo", mislimo na več izračunov, kot je atomov v znanem vesolju.

Hashe igrajo ključno vlogo v vseh verigah blokov z enotnim prepoznavanjem transakcij in blokov. Prav tako so podvrženi računskemu izzivu v sistemih za preverjanje dela, kot je bitcoin. Različnih hash funkcij je bilo razvitih z imeni gobbledygook, kot so BLAKE2, MD5 in RIPEMD160. Da pa je kateri koli funkciji hash zaupanja vreden, mora prestati obsežen akademski pregled in testiranje. Ti testi so v obliki poskusov napadov, kot so "preimage" (iskanje vnosa s danim hash-om), "second preimage" (iskanje drugega vhoda z enakim hash-om kot dani vhod) in "trk" (iskanje katerega koli dva različna vhoda z istim hash-om). Preživeti v tej obleki še zdaleč ni enostavno, z dolgo in tragično zgodovino pokvarjenih hash funkcij, ki dokazujejo glavno maksimo: "Ne zvrtaj svoje kriptovalute."

Če se vrnemo k svoji izvirni težavi, lahko razrešimo razširljivost podatkov v blockchainsu tako, da namesto samih podatkov vstavimo mešanice velikih delov podatkov v transakcije. Vsak hash deluje kot "zaveza" za svoje vhodne podatke, pri čemer se sami podatki shranjujejo zunaj verige blokov ali izven verige. Na primer, s pomočjo priljubljene hash funkcije SHA256 lahko sliko v velikosti 500 kilobajtov JPEG predstavite z 32-bajtnim številom, kar je več kot 15,000 ×. Tudi s hitrostjo 500 slik na sekundo nas to udobno vrača na območje izvedljive pasovne širine in zahtev za shranjevanje, kar zadeva podatke, shranjene v sami verigi.

Seveda vsak udeleženec blockchaina, ki potrebuje zunanjo verigo slike, ne more reproducirati iz svojega hash-a. Če pa je sliko mogoče pridobiti na kakšen drug način, potem verižni hash služi za potrditev, kdo jo je ustvaril in kdaj. Tako kot običajni podatki o verigi je tudi hash vgrajen v digitalno podpisano transakcijo, ki jo je v verigo vključil soglasno. Če slikovna datoteka pade z neba in se hash za to sliko ujema s hash-om v blockchainu, se potrdi izvor in časovni žig te slike. Torej blockchain zagotavlja notarsko overitev popolnoma enake vrednosti, kot če bi bila slika vgrajena neposredno v verigo.

Vprašanje dostave

Zaenkrat tako dobro. Z vdelavo hash-ov v blockchain namesto v izvirne podatke imamo enostavno rešitev težave z razširljivostjo. Kljub temu ostaja eno ključno vprašanje:

Kako dostavimo izvirno vsebino zunaj verige tistim vozliščem, ki jo potrebujejo, če ne prek same verige?

Na to vprašanje obstaja več možnih odgovorov in vemo, da uporabniki MultiChaina uporabljajo vse. Osnovni pristop je vzpostavitev centraliziranega skladišča pri neki zaupanja vredni stranki, kamor se naložijo vsi zunaj verižni podatki in nato pozneje pridobijo. Ta sistem bi seveda lahko uporabil "naslavljanje vsebine", kar pomeni, da se hash vsakega dela podatkov neposredno uporablja kot identifikator za iskanje. Kljub temu, da bi ta nastavitev morda delovala za zanesljiv koncept, za proizvodnjo to nima smisla, saj je bistvo blok verige odstranitev zaupanja vrednih posrednikov. Čeprav posredniki v verigi preprečujejo, da bi posrednik ponarejal podatke, lahko še vedno izbriše podatke ali jih ne pošlje nekaterim udeležencem zaradi tehnične okvare ali dejanj lojalnega delavca.

Obetavnejša možnost je komunikacija od točke do točke, v kateri vozlišče, ki zahteva nekaj zunaj verižnih podatkov, zahteva neposredno od vozlišča, ki ga je objavilo. Tako se izognemo zanašanju na zaupanja vrednega posrednika, vendar ima tri alternativne pomanjkljivosti:

• Zahteva zemljevid naslovov blockchain na naslove IP, s katerimi lahko potrošnik nekaterih podatkov neposredno komunicira s svojim založnikom. Blockchains se na splošno lahko izognejo tej vrsti statične konfiguracije omrežja, kar je lahko težava v smislu preklopa in zasebnosti.
• Če je prvotno vozlišče izdajatelja zapustilo omrežje ali začasno ni v uporabi, podatkov ne bo mogel pridobiti nihče drug.
• Če je veliko število vozlišč zainteresiranih za nekatere podatke, bo založnik preplavljen nad zahtevami. To lahko ustvari hudo preobremenjenost omrežja, upočasni sistem založnika in povzroči dolge zamude za tiste, ki poskušajo pridobiti te podatke.

Da bi se izognili tem težavam, bi v idealnem primeru uporabili neke vrste decentraliziran mehanizem dostave. Vozlišča bi morala imeti možnost, da pridobijo podatke, ki jih potrebujejo, ne da bi se zanašali na noben posamezen sistem - naj bo to centralno skladišče ali prvotni založnik podatkov. Če ima več strank na voljo podatke, bi jih morale deliti breme, da jih posredujejo vsem drugim, ki to želijo. Nikomur ni treba zaupati posameznega vira podatkov, ker lahko verižne razpršitve dokažejo, da podatki niso bili posegi. Če mi zlonamerno vozlišče posreduje napačne podatke za hash, jih lahko preprosto zavržem in poskusim vprašati koga drugega.

Za tiste, ki imajo izkušnje z skupna raba datotek protokolov, kot so Napster, Gnutella ali BitTorrent, vse to bo zveni zelo znano. Dejansko je veliko osnovnih načel enako, vendar obstajata dve ključni razliki. Prvič, ob predpostavki, da uporabljamo naš blockchain v poslovnem kontekstu, sistem deluje znotraj zaprte skupine udeležencev, ne pa kot internet kot celota. Drugič, blockchain doda decentralizirano hrbtenico za naročanje, časovno žigosanje in notarizacijo, kar vsem uporabnikom omogoča, da ohranijo očitno dosleden in varen odpor do tega, kaj točno se je zgodilo, kdaj in kdo.

Kako lahko razvijalec aplikacij blockchain doseže to decentralizirano pošiljanje zunaj verižnih vsebin? Ena pogosta izbira je uporaba obstoječe enakovredne platforme za izmenjavo datotek, kot je zabavno imenovana Medplanetarni datotečni sistem (IPFS) in ga uporabljajte skupaj z blockchainom. Vsak udeleženec vodi tako vozlišče blockchain kot IPFS vozlišče, z nekaj vmesne programske opreme, ki se usklajuje med obema. Ko objavlja podatke brez verige, ta vmesna programska oprema shrani izvirne podatke v IPFS, nato ustvari transakcijo blockchain, ki vsebuje hash teh podatkov. Za pridobivanje nekaterih podatkov, povezanih iz verige, vmesna programska oprema izvleče hash iz blockchain in nato uporabi ta hash za pridobivanje vsebine iz IPFS. Lokalno vozlišče IPFS samodejno preveri naloženo vsebino proti hashu in se prepriča, da ni bila spremenjena.

Ta rešitev je sicer mogoča, vendar je vse skupaj precej nerodno in neprijetno. Najprej mora vsak udeleženec namestiti, vzdrževati in posodabljati tri ločene dele programske opreme (blockchain vozlišče, IPFS vozlišče in vmesna programska oprema), od katerih vsak shranjuje svoje podatke na ločeno mesto. Drugič, na voljo bosta dve ločeni enakovredni mreži, vsako s svojo konfiguracijo, omrežnimi vrati, identitetnim sistemom in dovoljenji (čeprav je treba opozoriti, da IPFS še ne podpira zaprtih omrežij). Končno bi tesno povezovanje IPFS in blockchain skupaj postalo vmesno programsko opremo vse bolj zapleteno. Na primer, če želimo, da se podatki izven verige, na katere se nanašajo nekatere transakcije blokovne verige, takoj pridobijo (z avtomatskimi ponovnimi poskusi), bi bilo treba vmesno programsko opremo nenehno pripraviti in izvajati, pri tem pa ohraniti svoje zapleteno stanje. Ali ne bi bilo lepo, če bi vozlišče blockchain vse to storilo za nas?

Podatkovni niz v verigi MultiChain 2.0

Danes z veseljem objavljamo tretja predogledna različica (alfa 3) MultiChain 2.0, s popolnoma integrirano in brezhibno rešitev za podatke brez verige. Vsak podatek, objavljen v toku, je po želji lahko verižen ali izven verige, MultiChain pa skrbi za vse ostalo.

Res ne, mislimo vse. Kot razvijalec, ki gradi na MultiChainu, vam ne bo treba skrbeti glede hešev, lokalnega pomnilnika, odkrivanja vsebine, decentralizirane dostave ali preverjanja podatkov. Tukaj se dogaja zakulisje:

1. Izdajališče MultiChain vozlišče zapiše nove podatke v lokalno shrambo, tako da velike dele nareza na koščke za enostavno prebavo in dostavo.
2. Transakcija za objavo elementov pretočnega toka se samodejno oblikuje, vsebuje pahse (e) in velikost (-e) v bajtih.
3. Ta transakcija se podpiše in odda v omrežje, razmnožuje se med vozlišči in vstopi v blockchain na običajen način.
4. Ko vozlišče, ki je naročeno na tok, vidi sklicevanje na nekatere podatke zunaj verige, doda koščke za te podatke v čakalno vrsto za iskanje. (Ko naročite na stari tok, vozlišče postavi v čakanje tudi vse prej objavljene elemente brez verige za iskanje.)
5. Če obstajajo kosi v čakalni vrsti za iskanje vozlišč, se poizvedbe pošljejo v omrežje, da poiščejo te koščke, kot jih prepoznajo njihovi šifri.
6. Te poizvedbe se širijo na druga vozlišča v omrežju enakomerno (zaenkrat omejeno na dva skoka - glejte tehnične podrobnosti spodaj).
7. Vsako vozlišče, ki ima podatke za kos, se lahko odzove in ta odgovor se naročniku prenese po isti poti kot poizvedba.
8. Če nobeno vozlišče ne odgovori na poizvedbo, se kos vrne nazaj v čakalno vrsto za poznejšo ponovitev.
9. V nasprotnem primeru naročnik izbere najbolj obetaven vir za kos (na podlagi hmelja in odzivnega časa) in mu pošlje zahtevo za podatke tega kosa, spet po isti poti enakovrednosti kot prejšnji odgovor.
10. Izvorno vozlišče dostavi zahtevane podatke in znova uporabi isto pot.
11. Naročnik preveri velikost in hash podatkov v primerjavi s prvotno zahtevo.
12. Če se vse preveri, naročnik podatke zapiše v svoj lokalni pomnilnik, tako da je takoj na voljo za iskanje prek tokovnih API-jev.
13. Če zahtevana vsebina ni prispela ali se ne ujema z želenim hash-om ali velikostjo, se kos vrne nazaj v čakalno vrsto za nadaljnje iskanje iz drugega vira.

Najpomembneje je, da se vse to zgodi izjemno hitro. V omrežjih z nizko zakasnitvijo bodo majhni kosi zunaj verižnih podatkov do naročnikov prispeli v delni sekundi transakcije, na katero se sklicujejo. Pri aplikacijah z veliko obremenitvijo naše testiranje kaže, da MultiChain 2.0 alfa 3 lahko na strežniku srednjega obsega (Core i1000) na spodnjem strežniku (Core i25) z dostojno hitrostjo prenese več kot 7 izven verig ali 1 MB izven verige. Internetna povezava. Vse je v redu z zunanjimi verigami velikosti do 64 GB, kar presega omejitev 2.0 MB za podatke v verigi. Seveda upamo, da bomo te številke še izboljšali, saj porabimo čas za optimizacijo MultiChain XNUMX med njegovo fazo beta.

Ko v tokovih uporabljajo podatke, ki niso povezani z verigo, in ne na njih, morajo razvijalci aplikacij MultiChain narediti natanko dve stvari:

• Ko objavljate podatke, pošljite "offchain" zastavico ustreznim API-jem.
• Ko uporabljate API-je za poizvedovanje v toku, upoštevajte možnost, da nekateri zunaj verižni podatki morda še niso na voljo, o čemer poroča zastava "na voljo". Čeprav bodo takšne razmere v običajnih okoliščinah redke, je pomembno, da razvijalci aplikacij ustrezno ravnajo.

Seveda, da bi preprečili, da bi vsako vozlišče priklicalo vsak izven verige, bi bilo treba elemente na ustrezen način združiti v tokove, pri čemer se vsako vozlišče naroči na te tokove, ki vas zanimajo.

V istem toku je mogoče uporabiti elemente, povezane z verigo in zunaj verige, različne poizvedbe in povzemanje tokov pa se nanašajo na obe vrsti podatkov enako. To omogoča založnikom, da izberejo ustrezno izbiro za vsak element v toku, ne da bi to vplivalo na preostalo aplikacijo. Na primer, tok elementov JSON o dejavnostih ljudi lahko uporabi podatke brez verige za osebno identifikacijo informacij, podatke o verigi pa za ostale. Naročniki lahko z združevanjem JCON MultiChain združujejo obe vrsti informacij v en JSON za branje.

Če želite preizkusiti predmete, povezane z verigo, samo sledite pravilniku MultiChain Začetek vadnica in ne pozabite preskočiti 5. dela.

Kaj torej sledi?

S pomočjo brezšivne podpore za verižne podatke bo MultiChain 2.0 ponudil velik korak naprej za blockchain aplikacije, osredotočene na časovno žigosanje podatkov in notarizacijo velikega obsega. Dolgoročno gledano že razmišljamo o toni možnih prihodnjih izboljšav te funkcije za izdaje MultiChain v Skupnosti in / ali Enterprise:

• Izvedbeni tok preberite dovoljenja z uporabo kombinacije elementov zunaj verige, slanih heš, podpisanih poizvedb in šifrirane dostave.
• Dovoli, da se podatki izven verige izrecno »pozabijo«, tako prostovoljno posamezna vozlišča bodisi vsa vozlišča kot odgovor na sporočilo o verigi.
• Izbirne naročnine na tok, v katerih vozlišča pri določenih založnikih ali ključih pridobijo podatke samo za izdelke, povezane z verigo.
• Uporaba merkle drevesa da en sam verižni ovitek predstavlja neomejeno število izdelkov zunaj verige, kar še en velik skok v smislu razširljivosti.
• Vtični motorji za shranjevanje, ki omogočajo hranjenje podatkov brez verige v zbirkah podatkov ali zunanjih datotečnih sistemih in ne na lokalnem disku.
• Vozlišča se sčasoma učijo, kjer so ponavadi v omrežju na voljo vsaka vrsta podatkov o verigi, in svoje poizvedbe ustrezno osredotočijo.

Mi bi radi slišijo vaše povratne informacije na zgornjem seznamu in na splošno izven verig. Ker je MultiChain 2.0 še vedno uradno alfa, je pred njegovo končno izdajo še veliko časa za izboljšanje te funkcije.

Medtem smo že začeli delati na "Pametnih filtrih", zadnjem pomembnem delu, ki je bil načrtovan za skupnost MultiChain 2.0. Pametni filter je del kode, vdelan v verigo blokov, ki izvaja pravila po meri za preverjanje podatkov ali transakcij. Pametni filtri imajo nekaj podobnosti s "pametnimi pogodbami" in lahko storijo veliko istih stvari, vendar imajo ključne razlike glede varnosti in učinkovitosti. Veselimo se, da vam bomo pravočasno povedali več.

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

Tehnične podrobnosti

Medtem ko so predmeti brez verige v MultiChain 2.0 enostavni za uporabo, vsebujejo veliko oblikovalskih odločitev in dodatnih funkcij, ki bi vas lahko zanimale. Spodnji seznam bo pomemben predvsem za razvijalce, ki gradijo blockchain aplikacije, preskočil pa jih bo manj tehničnih vrst:

• Pravila za tok Ko je ustvarjen tok MultiChain, ga lahko poljubno omejite tako, da dovoljuje samo podatke v verigi ali zunaj verige. Za to je več možnih razlogov, namesto da bi se vsak založnik odločil sam. Na primer, izdelki na verigi ponujajo garancijo razpoložljivosti železja, medtem ko lahko stari izdelki zunaj verige postanejo nepreklicni, če njihov založnik in drugi naročniki odpadejo iz omrežja. Na hrbtni strani elementov na verigi ni mogoče "pozabiti" brez spreminjanja blokovne verige, medtem ko so izdelki zunaj verige bolj prilagodljivi. To je lahko pomembno v zvezi s pravili o zasebnosti podatkov, kot so novi evropski predpisi GDPR.
• Metapodatki na verigi. Za izdelke, ki niso povezani z verigo, transakcija v verigi še vedno vsebuje založnika, ključe (-e), obliko (JSON, besedilo ali dvojiško datoteko) in skupno velikost. Vse to zavzema zelo malo prostora in razvijalcem aplikacij pomaga ugotoviti, ali nerazpoložljivost izdelka brez verige skrbi za določeno poizvedbo.
• Omejitev dveh skokov. Pri posredovanju poizvedb o delih po omrežju enakovrednih oseb je prišlo do kompromisa med dosegljivostjo in uspešnostjo. Čeprav bi bilo lepo, da se vsaka poizvedba razširi po vsaki posamezni poti, lahko to zamaši omrežje z nepotrebnim "klepetanjem". Zaenkrat so poizvedbe omejene na dva hmelja, kar pomeni, da lahko vozlišče pridobi podatke brez verige pri katerem koli od svojih vrstnikov. V manjših omrežjih z manj kot 1000 vozlišči, ki ponavadi označujejo poslovne blokade, verjamemo, da bo to delovalo v redu, vendar lahko preprosto omejimo to omejitev (ali jo ponudimo kot parameter), če se izkaže, da ni v redu.
• Lokalna shramba. Vsako vozlišče MultiChain shranjuje podatke brez verige v imenik "koščki" svojega običajnega imenika blockchain z uporabo učinkovitega binarnega zapisa in indeksa LevelDB. Za postavke v vsakem od naročenih tokov in tiste, ki jih objavi sam vozlišče, se uporablja ločen podimenik. V vsakem od teh poddirektorjev so podvojeni deli (z istim hash-om) shranjeni samo enkrat. Ko se vozlišče odjavi iz toka, lahko izbere, ali bo očistil verižne podatke, ki so bili pridobljeni za ta tok ali ne.
• Binarni predpomnilnik. Ko objavljate velike koščke binarnih podatkov, bodisi v verigi ali zunaj verige, razvijalci aplikacij morda ne bodo mogli poslati teh podatkov v MultiChain API v eni zahtevi JSON-RPC. Tako MultiChain 2.0 izvaja binarni predpomnilnik, ki omogoča, da se več kosov podatkov nabere v več klicev API-ja in nato objavi v kratkem zadnjem koraku. Vsak element v binarnem predpomnilniku je shranjen kot preprosta datoteka v poddirektorju »cache« v imeniku blockchain, ki omogoča, da se gigabajti podatkov tudi neposredno potisnejo prek datotečnega sistema.
• API-ji za spremljanje. MultiChain 2.0 alfa 3 dodaja dva nova API-ja za spremljanje asinhronega iskanja zunaj verižnih podatkov. Prvi API opisuje trenutno stanje čakalne vrste in prikazuje, koliko kosov (in koliko podatkov) čaka ali jih poizvedujejo ali pridobijo. Drugi API ponuja zbirno statistiko za vse poizvedbe in zahteve, poslane po zagonu vozlišča, vključno s štetji različnih vrst napak.
• Izpustite pri objavi. Ob objavi izdelka brez verige MultiChain poskrbi, da je njegova lokalna kopija podatkov v celoti zapisana (ali "spravljena") na fizični disk, preden se transakcija, ki se nanaša na podatke, oddaja v omrežje. V nasprotnem primeru, če vozlišče ni bilo dovolj srečno, da bi takoj po oddajanju transakcije izgubilo moč, bi se lahko podatki o verigi trajno izgubili. Za sam MultiChain to ni vprašanje, saj zamude med poskusi iskanja posameznega kosa sčasoma rastejo samodejno. Lahko pa povzroči težave na ravni aplikacije, kjer vsi vedo za obstoj nekaterih podatkov, vendar jih nihče ne more najti.
• Založniški performans. Če na ta način spustite podatke brez verige na disk, lahko MultiChain naloži kazen za delovanje, saj so fizični diski počasni. Na primer, trdi disk srednjega obsega 7200 vrt./min lahko izvede samo okoli 100 naključnih zapisov podatkov na sekundo, kar posledično omeji hitrost, s katero lahko posamezno vozlišče objavi zunaj verižne predmete. Za to težavo obstajajo trije možni rešitvi. Najprej in najpreprosteje, vozlišča lahko namesto običajnega trdega diska uporabljajo pogon SSD (SSD), ki podpira 10,000 operacij naključnega zapisovanja na sekundo. Drugič, v posamezni transakciji se lahko objavi več elementov zunaj verige z uporabo API-ja „createrawsendfrom“. V tem primeru MultiChain zapiše vse podatke o verigi, na katere se sklicuje transakcija v enem samem disku. Končno je MultiChain mogoče konfigurirati, da ne izplača podatkov o verigi na disk pred oddajo transakcije, na katero se sklicuje. To možnost uporabite previdno.
• Integracija nativne valute. Za primere uporabe, ki to zahtevajo, je MultiChain vedno ponujal možnost uporabe domače valute na blockchainu za preprečevanje neželene pošte in / ali spodbuditve preveriteljev blokov ("rudarji"). V teh primerih morajo transakcije rudarjem ponuditi minimalno pristojbino, ki je sorazmerna z njihovo velikostjo v bajtih, da bi jih lahko prenesli in potrdili v verigi. Ta mehanizem je bil razširjen, tako da je mogoče preprečiti zunaj verižno neželeno pošto, tako da zahteva minimalno dodatno pristojbino na kilobajt podatkov, povezanih izven verige, na katere se sklicuje transakcija.
• Arhivska vozlišča. Če se želi vozlišče naročiti na vsak tok in zato pridobiti in shraniti vse objavljene zunaj verige, ga lahko konfigurira s parametrom izvajanja »samodejno naroči«. Vsako takšno vozlišče bo delovalo kot varnostna kopija za celotno omrežje, kar jamči, da zunaj verižni elementi ne bodo izgubljeni ali nedosegljivi, ne glede na to, katera druga vozlišča izginejo. Lahko si predstavljamo podjetja, ki ponujajo to kot komercialno storitev.

Vse podrobnosti o vseh ustreznih klicih in parametrih API-ja najdete na strani Stran s predogledom MultiChain 2.0.