Scaling Blockchains With Off-chain Data

Taasavaldanud Platon

järgijaid: 0

Kui räsi on miljoni sõna väärt

Nüüdseks on selge, et paljudel plokiahelate kasutamise juhtumitel pole pistmist finantstehingutega. Selle asemel on keti eesmärk detsentraliseeritud liitmine, tellimine, ajatemplid ja arhiveerimine mistahes teabe liik, sealhulgas struktureeritud andmed, kirjavahetus või dokumentatsioon. Blokiahela põhiväärtus võimaldab selle osalejatel tõestatult ja jäädavalt kokku leppida, millised andmed täpselt, millal ja kelle poolt sisestati, usaldamata usaldusväärsele vahendajale. Näiteks hiljuti käivitati SAP blockchain platvorm, mis toetab MultiChaini ja Hyperledger Fabricit, on suunatud laiale tarneahela ja muude mitterahaliste rakenduste valikule.

Lihtsaim viis plokiahela kasutamiseks andmete salvestamisel on iga andmeosa kinnistamine otse tehingu sisse. Igale plokiahelatehingule kirjutab üks või mitu osapoolt digitaalselt alla, see kopeeritakse igasse sõlme, ahela konsensusalgoritmi järgi tellitakse ja ajatempliga ning hoitakse püsivalt võltsimiskindlal viisil. Tehingus olevad kõik andmed salvestatakse seega iga sõlme identselt, kuid sõltumatult koos tõendiga selle kohta, kes ja millal need kirjutas. Keti kasutajad saavad selle teabe igal ajal uuesti kätte saada.

Näiteks lubas MultiChain 1.0 plokiahelal luua ühe või mitu nimega “voogu” ning seejärel kasutada neid algandmete salvestamiseks ja hankimiseks. Igal vool on oma kirjutamisõiguste komplekt ja iga sõlm saab vabalt valida, milliseid vooge tellida. Kui voog on tellitud sõlme, indekseerib see selle voo sisu reaalajas, võimaldades üksusi kiiresti hankida nii nende järjestuse, ajatempli, ploki numbri või avaldaja aadressi alusel kui ka „võtme” (või sildi) abil. mille järgi saab üksusi märgistada. MultiChain 2.0 (alates alfa 1) laiendas vooge, et toetada Unicode'i teksti või JSON-andmeid, samuti mitu võtit üksuse kohta ja mitu üksust tehingu kohta. Samuti lisati kokkuvõtte funktsioonid, näiteks „JSON-i ühendamine”, mis ühendab üksuse sama võtme või avaldajaga kasulikul viisil.

Konfidentsiaalsus ja mastaapsus

Kuigi andmete otse salvestusahelasse salvestamine töötab hästi, on sellel kaks peamist puudust - konfidentsiaalsus ja mastaapsus. Konfidentsiaalsusega alustades on iga voo üksuse sisu nähtav ahela igale sõlmele ja see pole tingimata soovitav tulemus. Paljudel juhtudel peaks mõni andmestik olema nähtav ainult kindlale sõlmede alamhulgale, isegi kui selle tellimisel, ajatempeldamisel ja notariaalselt tõestamisel on vaja teisi sõlme.

Konfidentsiaalsus on suhteliselt lihtne probleem lahendada, krüpteerides teabe enne selle kinnistamist tehingusse. Iga andmete dekrüpteerimisvõtit jagatakse ainult neile osalejatele, kellele see on mõeldud. Võtme kohaletoimetamise saab teostada ahelas, kasutades asümmeetrilist krüptograafiat (nt siin kirjeldatud) või mõne ahelavälise mehhanismi kaudu, nagu eelistatakse. Kõik sõlmed, millel puudub üksuse dekrüpteerimise võti, ei näe muud kui binaarset hiilgust.

Skaalautuvus on seevastu olulisem väljakutse. Oletame, et iga korralik plokiahela platvorm peaks toetama võrgu läbilaskevõimet 500 tehingut sekundis. Kui keti eesmärk on teabe salvestamine, siis iga tehingu suurus sõltub peamiselt sellest, kui palju andmeid see sisaldab. Iga tehing vajab ka (vähemalt) 100 baiti üldkulusid, et salvestada saatja aadress, digitaalallkiri ja veel mõned killud.

Kui võtta lihtne juhtum, kus iga üksus on väike JSON-i struktuur 100 baiti, oleks andmete üldine läbilaskevõime 100 kilobaiti sekundis, arvutatuna 500 × (100 + 100). See tähendab ribalaiust alla 1 megabiti sekundis, mis mahub mugavalt iga kaasaegse Interneti-ühenduse võimsuse piiridesse. Andmeid koguneb umbes 3 terabaiti aastas, mis pole sugugi vähe. Kuid nüüd 12 terabaidise kõvakettaga laialdaselt saadavalja RAID kontrollerid, mis ühendavad mitu füüsilist draivi üheks loogiliseks, saaksime hõlpsalt 10-20-aastaseid andmeid salvestada iga sõlme jaoks ilma liigsete vaevade ja kulutusteta.

Kuid asjad näevad välja hoopis teistsugused, kui salvestame suuremaid andmeid, näiteks skannitud dokumente. A4-lehe mõistliku kvaliteediga JPEG-skannimine võib olla 500 kilobaiti. Korrutage see 500 tehinguga sekundis ja vaatame 250 läbilaskevõimet megabaiti sekundis. See tähendab 2 gigabitti sekundis ribalaiust, mis on kiirem kui enamik kohalikke võrke, rääkimata Interneti-ühendustest. Amazoni veebiteenuste kõige odavam avaldatud hind 0.05 dollarit gigabaidi kohta tähendab see aastas ribalaiuse arvet 400,000 8000 dollarit sõlme kohta. Ja kuhu hoiab iga sõlm XNUMX terabaiti uusi andmeid, mis genereeritakse aastas?

On selge, et plokiahelarakenduste jaoks, mis salvestavad palju suuri andmeid, ei ole sirgjooneline ahelas hoidmine praktiline valik. Vigastuste solvanguks lisamiseks palutakse sõlmedel säilitada konfidentsiaalsuse probleemi lahendamiseks krüptitud andmed tohutul hulgal teavet, mida nad isegi ei suuda lugeda. See ei ole võrgu osalejate jaoks atraktiivne ettepanek.

Räsimislahendus

Niisiis, kuidas me lahendame andmete mastaapsuse probleemi? Kuidas saaksime ära kasutada plokiahela detsentraliseeritud andmete notariaalset kinnitamist, ilma et neid andmeid kordataks ahela igas sõlmes?

Vastus on nutika tehnoloogiaga, mida nimetatakse “hashiks”. Räsi on pikk arv (arvame, et 256 bitti ehk umbes 80 kümnendkohalist numbrit), mis identifitseerib andmekogumi ainulaadselt. Räsi arvutatakse andmete põhjal, kasutades a ühesuunaline funktsioon millel on oluline krüptograafiline omadus: Arvestades mis tahes andmeid, on nende räsi arvutamine lihtne ja kiire. Kuid arvestades konkreetset räsi, on arvutuslikult teostamatu leida tükike andmeid, mis selle räsi genereeriks. Ja kui ütleme "arvutuslikult teostamatu", siis mõtleme rohkem arvutusi, kui teadaolevas universumis on aatomeid.

Hashid mängivad otsustavat rolli kõigis plokiahelates, tehingute ja plokkide ainulaadse tuvastamise kaudu. Nad on aluseks ka töökindlate süsteemide, näiteks bitcoini, arvutuslikule väljakutsele. Välja on töötatud palju erinevaid räsifunktsioone koos rippnimekirjadega nimedega BLAKE2, MD5 ja RIPEMD160. Kuid selleks, et mõnda räsifunktsiooni saaks usaldada, peab see taluma ulatuslikku akadeemilist ülevaatust ja testimist. Need testid esinevad rünnakukatsetena, näiteks „preimage” (sisendi leidmine antud räsi abil), „second preimage” (teise sisendi leidmine sama sisendiga kui antud sisend) ja „collision” (mis tahes kaks erinevat sisendit sama räsi abil). Sellest kindast ellu jäämine pole kaugeltki lihtne, kuna pika ja traagilise ajalooga katkised räsifunktsioonid tõestavad kuulsat maksiimi: "Ärge veeretage oma krüptot."

Oma algse probleemi juurde naasmiseks saame plokiahelates andmete mastaapsuse lahendada, sisestades tehingute sisse suurte andmemahtude räsid, mitte andmete enda. Iga räsi toimib kui "kohustus" oma sisendandmete suhtes, kusjuures andmeid ise hoitakse väljaspool plokiahelat või "ketivälist". Näiteks populaarse räsifunktsiooni SHA256 abil saab 500-kilobaidist JPEG-pilti kujutada 32-baidise numbriga, vähendades üle 15,000 500 ×. Isegi kiirusega XNUMX pilti sekundis paneb see meid ahelasse salvestatud andmete osas mugavalt tagasi teostatavate ribalaiuse ja salvestusnõuete territooriumile.

Muidugi, ükski plokiahelas osaleja, kes vajab ahelavälist pilti, ei saa seda oma räsist reprodutseerida. Kuid kui pilti on võimalik muul viisil hankida, siis on keti räsi selle kinnitamiseks, kes ja millal selle lõi. Nii nagu tavalised ahela andmed, on ka räsi manustatud digitaalselt allkirjastatud tehingusse, mis lisati ahelasse konsensuse alusel. Kui pildifail kukub taevast välja ja selle pildi räsi vastab ründeahelas olevale räsile, siis kinnitatakse selle pildi päritolu ja ajatempel. Nii et plokiahel pakub notariaalselt täpselt sama väärtust, kui pilt oleks otse ahelasse manustatud.

Kohaletoimetamise küsimus

Siiamaani on kõik korras. Manustades räsivõtted algsete andmete asemel plokiahelasse, on meil lihtne lahendus mastaapsuse probleemile. Sellegipoolest jääb üks ülioluline küsimus:

Kuidas tarnida algset ahelavälist sisu neile sõlmedele, kus seda vaja on, kui mitte läbi ahela enda?

Sellele küsimusele on mitu võimalikku vastust ja me teame, et MultiChaini kasutajad rakendavad neid kõiki. Üheks põhiliseks lähenemisviisiks on tsentraliseeritud hoidla loomine mõne usaldusväärse osapoole juurde, kuhu kõik ahelavälised andmed üles laaditakse ja seejärel uuesti üles laaditakse. See süsteem võiks loomulikult kasutada „sisuaadressi”, mis tähendab, et iga andmeosa räsi toimib otsingu identifikaatorina. Kuigi see seadistus võib toimida kontseptsiooni tõestamise jaoks, pole tootmisel mõtet, sest plokiahela mõte on usaldusväärsete vahendajate eemaldamine. Isegi kui ahelas olevad räsid takistavad vahendajat andmete võltsimisest, võib see tehnilise rikke või petturitest töötaja tegevuse tõttu andmed siiski kustutada või mõnele osalejale edastada.

Lootustandvam võimalus on punktist punkti edastamine, mille korral teatud ahelaväliseid andmeid vajav sõlm nõuab seda otse sõlmelt, kes selle avaldas. See väldib usaldusväärse vahendaja lootmist, kuid sellel on kolm alternatiivset puudust:

Selleks, et võimaldada mõne teabe tarbijal otse avaldajaga suhelda, on vaja plokiahelate aadresside kaarti IP-aadressideks. Plokiahelate abil saab seda tüüpi staatilist võrgu konfiguratsiooni üldiselt vältida, mis võib probleemideks osutuda tõrkeid ja privaatsust silmas pidades.
Kui algsed väljaandja sõlmed on võrgust lahkunud või on ajutiselt teeninduses, siis ei saa keegi teine andmeid hankida.
Kui mõned andmed on huvitatud suurest osast sõlmedest, on avaldajad taotlustest üle pakutud. See võib tekitada tõsiseid võrgukoormusi, aeglustada kirjastaja süsteemi töötujumist ja põhjustada pikki viivitusi neile, kes üritavad neid andmeid hankida.

Nende probleemide vältimiseks kasutaksime ideaalselt mingit detsentraliseeritud edastamismehhanismi. Sõlmed peaksid saama vajalikke andmeid kätte saada, tuginedes ühele üksikule süsteemile - olgu see siis tsentraliseeritud hoidla või andmete algne avaldaja. Kui mitmel osapoolel on andmeid, peaksid nad jagama selle edastamise koormust kõigile teistele, kes seda soovivad. Keegi ei pea individuaalset andmeallikat usaldama, sest ahelas olevad räsid võivad tõestada, et andmeid pole muudetud. Kui pahatahtlik sõlm edastab mulle räsi jaoks valed andmed, võin need andmed lihtsalt ära visata ja proovida kelleltki teiselt küsida.

Neile, kellel on kogemusi peer-to-peer failide jagamine nagu Napster, Gnutella või BitTorrent, kõlab see kõik väga tuttavalt. Tõepoolest, paljud põhiprintsiibid on samad, kuid on kaks peamist erinevust. Esiteks, eeldades, et kasutame oma plokiahelat ettevõtte kontekstis, töötab süsteem pigem suletud osalejate rühmas kui Internetis tervikuna. Teiseks lisab plokiahel detsentraliseeritud tellimise, ajatemplite ja notariaalselt kinnitatud selgroo, võimaldades kõigil kasutajatel säilitada tõestatult järjepidev ja võltsimiskindel ülevaade sellest, mis täpselt juhtus, millal ja kelle poolt.

Kuidas võiks blockchaini rakenduste arendaja saavutada selle ahelavälise sisu detsentraliseeritud edastamise? Üks levinud valik on võtta olemasolev võrdõiguslike failide jagamise platvorm, näiteks lõbusalt nimetatud Planetidevaheline failisüsteem (IPFS) ja kasutage seda koos plokiahelaga. Iga osaleja käitab nii plokiahelasõlme kui ka IPFS-sõlme, nende vahel koordineerib mõni vahevara. Ahelaväliste andmete avaldamisel salvestab see vahevara algandmed IPFS-i, seejärel loob plokiahelatehingu, mis sisaldab nende andmete räsi. Mõnede ahelaväliste andmete hankimiseks eraldab vahevara plokiahelast räsi, seejärel kasutab seda räsi sisu IPFS-ist toomiseks. Kohalik IPFS-sõlm kontrollib allalaaditud sisu automaatselt räsiga ja veendub, et seda pole muudetud.

Kuigi see lahendus on võimalik, on see kõik üsna kohmakas ja ebamugav. Esiteks peab iga osaleja installima, hooldama ja värskendama kolme eraldi tarkvara (plokiahelasõlm, IPFS-sõlm ja vahevara), millest igaüks salvestab oma andmed eraldi kohta. Teiseks saab olema kaks eraldi peer-to-peer võrku, millel mõlemal on oma konfiguratsioon, võrgupordid, identiteedisüsteem ja load (kuigi tuleb märkida, et IPFS ei toeta veel suletud võrke). Lõpuks muudaks IPFS-i ja plokiahela tihedalt ühendamine vahevara üha keerukamaks. Näiteks kui me tahame, et mõne plokiahelatehinguga viidatud ahelavälised andmed saaksid koheselt kätte (koos automaatsete uuesti proovimistega), peaks vahevara olema pidevalt töökorras, säilitades oma keerulise oleku. Kas poleks tore, kui plokiahela sõlm seda kõike meie eest teeks?

Ahelavälised andmed MultiChain 2.0-s

Täna on meil hea meel kolmas eelvaate versioon MultiChain 3 (alfa 2.0) koos täielikult integreeritud ja sujuva lahendusega ahelaväliste andmete jaoks. Iga vooges avaldatud teave võib vastavalt soovile olla ahelas või ahelas ning MultiChain hoolitseb kõige muu eest.

Ei, tegelikult peame silmas kõik. MultiChaini arendajana ei pea te muretsema räsi, kohaliku salvestusruumi, sisu avastamise, detsentraliseeritud edastamise ega andmete kontrollimise pärast. Lava taga toimub nii:

Väljaandev MultiChaini sõlm kirjutab uued andmed oma kohalikku mäluseadmesse, viilutades suured üksused tükkideks, et neid oleks kerge seedida ja tarnida.
Ahelaväliste voo üksuste avaldamise tehing luuakse automaatselt, sisaldades tüki räsi (id) ja suurust (baidides) baitides.
See tehing allkirjastatakse ja edastatakse võrku, levib sõlmede vahel ja siseneb plokiahelasse tavapärasel viisil.
Kui voo tellitud sõlm näeb viidet mõnele ahelavälisele andmetele, lisab ta selle teabe tükk-räsi oma väljastusjärjekorda. (Kui tellite vana voo, seab sõlmimisjärjekorda ka kõik varem avaldatud ahelavälised üksused.)
Kui sõlme otsingujärjekorras on tükke, siis taustprotsessina saadetakse võrgule päringud nende tükkide leidmiseks, mis on tuvastatud nende räsi järgi.
Neid tükkpäringuid levitatakse võrgus teistele sõlmedele võrdõiguslikkuse põhimõttel (praegu piirdub see kahe humalaga - vaata tehnilisi üksikasju allpool).
Vastama saab iga sõlm, millel on andmeid tüki kohta, ja see vastus edastatakse abonendile päringuga sama rada pidi.
Kui ükski sõlm ei vasta tüki päringule, tagastatakse tükk tagasi järjekorda hilisemaks uuesti proovimiseks.
Vastasel juhul valib abonent jupi jaoks kõige lootustandvama allika (lähtuvalt humalast ja reageerimisajast) ning saadab talle päringu selle tüki andmete järele, jällegi eelmise vastusega sama peer-to-peer teed pidi.
Algsõlm edastab nõutud andmed, kasutades sama rada uuesti.
Tellija kontrollib andmete suurust ja räsi algse päringu alusel.
Kui kõik saab teada, kirjutab abonent andmed oma kohalikku salvestusruumi, muutes need voo API-de kaudu koheselt kättesaadavaks.
Kui taotletud sisu ei saabunud või ei vastanud soovitud räsi või suurusele, tagastatakse jupp tagasi teisest allikast tulevase otsimise järjekorda.

Mis kõige tähtsam - kõik see juhtub äärmiselt kiiresti. Madala latentsusajaga võrkudes jõuavad abonentideni väikese viite ahelavälised andmed sekundi jooksul pärast neid viitavat tehingut. Ja suure koormusega rakenduste jaoks näitab meie testimine, et MultiChain 2.0 alfa-3 suudab korraliku keskklassi serveris (Core i1000) säilitada üle 25 ahelavälise üksuse või 7 MB ahelavälist teavet sekundis. Internetiühendus. Ahelaväliste üksustega, mille suurus on kuni 1 GB, töötab kõik hästi, mis ületab ahelate andmete 64 MB limiiti. Muidugi loodame neid numbreid veelgi parandada, kui kulutame aega MultiChain 2.0 optimeerimisele beetafaasis.

Kui kasutate voogudes andmete asemel ahelavälist teavet, peavad MultiChaini rakenduste arendajad tegema täpselt kahte asja:

Andmete avaldamisel edastage „offchain” lipp vastavatele API-dele.
Voo päringu API-de kasutamisel kaaluge võimalust, et osa ahelavälistest andmetest ei pruugi veel saadaval olla, nagu teatas lipp „saadaval”. Ehkki selline olukord on tavapärastes olukordades haruldane, on rakenduste arendajatel oluline sellega nõuetekohaselt hakkama saada.

Muidugi, vältimaks iga sõlme iga ahelavälise üksuse toomist, tuleks üksused rühmitada sobival viisil voogudeks, kusjuures iga sõlm tellib neid huvipakkuvaid vooge.

Ahelas olevaid ja ahelaväliseid üksusi saab kasutada samas voos ning erinevad voo päringu ja kokkuvõtte funktsioonid seonduvad mõlemat tüüpi andmetega identselt. See võimaldab väljaandjatel teha voo iga üksuse jaoks sobiv valik, mõjutamata ülejäänud rakendust. Näiteks võib JSON-i üksuste voog inimeste tegevuste kohta kasutada teabe tuvastamiseks ahelaväliseid andmeid ja ülejäänud osa ahelas olevaid andmeid. Tellijad saavad kasutada MultiChaini JSON-i liitmist, et ühendada mõlemat tüüpi teave lugemiseks ühtseks JSON-ks.

Kui soovite proovida ahelaväliseid voogesitusi, järgige lihtsalt MultiChaini tavapäraseid juhiseid Alustamine juhendaja ja ärge jätke 5. jaotist vahele.

Mis siis edasi saab?

Mis tagab ahelaväliste andmete sujuva toetuse, pakub MultiChain 2.0 suurt sammu plokiahelarakenduste jaoks, mis keskenduvad suuremahulisele andmete ajatemplile ja notariaalsele kinnitamisele. Pikemas perspektiivis mõtleme juba mitmele võimalikule selle funktsiooni edasiarendusele MultiChaini kogukonna ja / või ettevõtte väljaannetes:

Rakendusvoog lugenud ahelaväliste üksuste, soolatud räsi, allkirjastatud osapakkumiste ja krüptitud kohaletoimetamise kombinatsiooni õigused.
Võimaldades ahelaväliseid andmeid sõnaselgelt "unustada", nii üksikute sõlmede vabatahtlikult kui ka kõigi sõlmede vastusena ahelasisesele sõnumile.
Valikulised vootellimused, mille korral sõlmed hangivad andmeid ainult konkreetsete väljaandjate või võtmetega ahelaväliste üksuste kohta.
Kasutamine merkle puud võimaldada ühel ahelas oleval räsil esindada piiramatul arvul ahelaväliseid üksusi, andes veel ühe tohutu hüppe mastaapsuse osas.
Ühendatavad salvestusmootorid, mis võimaldavad ahelaväliseid andmeid hoida kohaliku andmebaasi asemel andmebaasides või välistes failisüsteemides.
Sõlmed, mis on aja jooksul õppimas, kus igat tüüpi ahelavälised andmed on tavaliselt võrgus saadaval, ja keskenduvad oma tüvi päringutele vastavalt.

Meile meeldiks kuulda teie tagasisidet ülaltoodud loendis, samuti üldiselt ahelavälised üksused. Kuna MultiChain 2.0 on endiselt ametlikult alfa versioonis, on enne selle lõplikku väljaandmist palju aega selle funktsiooni täiustamiseks.

Vahepeal oleme juba alustanud tööd nutikatest filtritest, mis on viimane peamine funktsioon, mis on plaanitud MultiChain 2.0 kogukonda. Nutikas filter on plokiahelasse põimitud koodijupp, mis rakendab andmete või tehingute kinnitamiseks kohandatud reegleid. Nutikatel filtritel on mõningaid sarnasusi nutikate lepingutega ja nad saavad teha paljusid samu asju, kuid neil on ohutuse ja jõudluse osas peamised erinevused. Ootame, et saaksime teile õigel ajal rohkem teada anda.

Palun postitage kõik kommentaarid LinkedIn.

Tehnilised detailid

Ehkki MultiChain 2.0 ahelasiseste voogude üksusi on lihtne kasutada, sisaldavad need palju kujundusotsuseid ja lisafunktsioone, mis võivad huvi pakkuda. Allpool olev nimekiri on asjakohane peamiselt arendajate jaoks, kes ehitavad plokiahela rakendusi, ja selle võib vähem tehniliste tüüpide korral vahele jätta:

Voogesituse põhimõtted. Kui luuakse mitme ahela voog, saab seda valikuliselt piirata, lubades ainult ahelas olevaid või ketiväliseid andmeid. Selle tegemiseks on mitu võimalikku põhjust, selle asemel et lubada igal väljaandjal ise otsustada. Näiteks pakuvad ketis olevad üksused raudset kättesaadavuse garantiid, samas kui vanad ketivälised üksused võivad muutuda pöördumatuks, kui nende kirjastaja ja teised tellijad loobuvad võrgust. Tagaküljel ei saa ketis olevaid esemeid "unustada" ilma plokiahelat muutmata, samas kui ketivälised esemed on paindlikumad. See võib olla oluline andmete privaatsuseeskirjade osas, näiteks Euroopa uued GDPR-i määrused.
Ahelas olevad metaandmed. Ahelaväliste üksuste puhul sisaldab ketisisene tehing endiselt üksuse väljaandjat (ed), võtit (võtmeid), vormingut (JSON, tekst või binaar) ja kogu suurust. Kõik see võtab väga vähe ruumi ja aitab rakenduste arendajatel kindlaks teha, kas ahelavälise üksuse kättesaamatus on konkreetse voo päringu jaoks murettekitav.
Kahe hüppe piir. Paljude päringute edastamisel üle peer-to-peer võrgus on kompromiss kättesaadavuse ja jõudluse vahel. Kuigi oleks tore, kui iga päringut levitataks igal üksikul rajal, võib see võrgu ummistada tarbetu „lobisemisega”. Niisiis piirduvad tükipäringud praegu kahe hüppega, mis tähendab, et sõlm võib hankida ahelaväliseid andmeid kõigilt oma eakaaslastelt. Väiksemates alla 1000 sõlme võrkudes, mis kipuvad ettevõtte plokiahelaid iseloomustama, usume, et see töötab suurepäraselt, kuid meil on seda piirangut lihtne kohandada (või pakkuda parameetrina), kui osutume valeks.
Kohalik ladustamine. Iga MultiChaini sõlm salvestab ahelavälised andmed oma tavalise plokiahelate kataloogi "tükkide" kataloogis, kasutades tõhusat binaarset vormingut ja LevelDB indeksit. Igas tellitud voos olevate üksuste jaoks ning eraldi sõlme enda avaldatud üksuste jaoks kasutatakse eraldi alamkataloogi. Kõigis nendes alamkataloogides salvestatakse eksemplarid (sama räsi) ainult üks kord. Kui sõlm tühistab voo tellimuse, saab ta valida, kas selle voo jaoks hangitud ketivälised andmed puhastada.
Binaarne vahemälu. Suurte binaarsete andmete avaldamisel, olenemata sellest, kas need on ahelas või mitte, ei pruugi rakenduste arendajatel olla otstarbekas neid andmeid MultiChaini API-le saata ühe JSON-RPC päringuna. Niisiis rakendab MultiChain 2.0 binaarse vahemälu, mis võimaldab mitme API-kõne kaudu luua suuri andmeid ja seejärel lühikese viimase sammuna avaldada. Iga binaarse vahemälu üksus salvestatakse lihtsa failina plokiahela kataloogi "vahemälu" alamkataloogis, võimaldades ka gigabaidiseid andmeid otse failisüsteemi kaudu lükata.
API-de jälgimine. MultiChain 2.0 alfa 3 lisab kaks uut API-d ahelaväliste andmete asünkroonse hankimise jälgimiseks. Esimene API kirjeldab järjekorra hetkeseisu, näidates, mitu tükki (ja kui palju andmeid) ootab või on päringuid otsimas või hangitud. Teine API pakub koondstatistikat kõigi sõlmpunkti loomisest alates saadetud tükkpäringute ja taotluste kohta, sealhulgas eri tüüpi rikete arvu.
Lõpetage avaldamine. Ahelavälise üksuse avaldamisel tagab MultiChain, et selle kohalik koopia andmetest on enne füüsilise kettaseadme täielikku kirjutamist (või „läbipesemist“) enne, kui viidatakse andmetele võrku edastamisele. Vastasel juhul, kui sõlmel ei olnud piisavalt õnne, et kohe pärast tehingu edastamist toite kaotada, võivad ketivälised andmed jäädavalt kaduda. See ei ole probleem MultiChaini enda jaoks, sest viivitused jupi hankimiskatsete vahel kasvavad aja jooksul automaatselt. Kuid see võib põhjustada probleeme rakenduse tasemel, kus kõik teavad mõningate andmete olemasolu, kuid keegi ei suuda neid leida.
Avaldamise etendus. Sel viisil kettaheite andmete kettale viimisega võib MultiChain'ile määrata jõudluskaristuse, kuna füüsilised kettad on aeglased. Näiteks saab keskmise vahemikuga 7200 p / min kõvaketas sooritada ainult umbes 100 juhuslikku andmete kirjutamist sekundis, piirates omakorda kiirust, millega üksik sõlm võib avaldada ketiväliseid üksusi. Selle probleemi jaoks on kolm võimalikku lahendust. Esiteks ja kõige lihtsamalt võivad sõlmed tavalise kõvaketta asemel kasutada tahkiseadme (SSD) draivi, mis toetab 10,000 XNUMX juhuslikku kirjutamistoimingut sekundis. Teiseks saab ühe tehinguga avaldada mitu ahelavälist üksust, kasutades API-t „createrawsendfrom”. Sellisel juhul kirjutab MultiChain kõik kettaga seotud andmed, millele tehing viitab, ühe kettaga. Lõpuks saab MultiChaini konfigureerida nii, et see ei viiks ketiväliseid andmeid kettale enne sellele viitava tehingu edastamist. Kasutage seda võimalust ettevaatlikult.
Omavääringus integreerimine. Kasutusjuhtudel, mis seda nõuavad, on MultiChain alati pakkunud võimalust kasutada emakeelset valuutat plokiahelas, et vältida tehingute rämpsposti ja / või motiveerida plokkide valideerijaid (kaevurite). Sellistel juhtudel peavad tehingud pakkuma kaevuritele miinimumtasu, mis on proportsionaalne nende suurusega baitides, et neid kettis edastada ja kinnitada. Seda mehhanismi on laiendatud, et vältida ahelavälist rämpsposti, nõudes minimaalset lisatasu tehingus viidatud kilobaiti ahelaväliste andmete kohta.
Arhiivisõlmed. Kui sõlm soovib tellida igat voogu ning hankida ja salvestada kõik avaldatud ahelavälised üksused, saab selle konfigureerida käituse parameetri „Autosubscribe” abil. Iga selline sõlm toimib kogu võrgu varukoopiana, tagades, et ahelavälised üksused ei kaoks ega oleks saadaval, hoolimata sellest, millised muud sõlmed kaovad. Võib ette kujutada, et kolmanda osapoole ettevõtted pakuvad seda kommertsteenusena.