Lohkoketjujen skaalaus ketjun ulkopuolisilla tiedoilla

Julkaissut Platon

seuraajia: 0

Kun hash on miljoonan sanan arvoinen

Tähän mennessä on selvää, että monilla blockchain-käyttötapauksilla ei ole mitään tekemistä finanssitransaktioiden kanssa. Sen sijaan ketjun tarkoituksena on mahdollistaa hajautettu yhdistäminen, tilaus, aikaleima ja arkistointi Kaikki tietojen tyyppi, mukaan lukien jäsennelty tieto, kirjeenvaihto tai asiakirjat. Lohkoketjun ydinarvo antaa sen osallistujille mahdollisuuden todistettavasti ja pysyvästi sopia tarkalleen, mitä tietoja syötettiin, milloin ja kuka, luottamatta luotettuun välittäjään. Esimerkiksi SAP on äskettäin lanseerattu Blockchain-alusta, joka tukee MultiChain- ja Hyperledger Fabric -tuotteita, kohdistuu laajaan valikoimaan toimitusketjuja ja muita ei-taloudellisia sovelluksia.

Yksinkertaisin tapa käyttää lohkoketjua tietojen tallentamiseen on upottaa jokainen tieto suoraan tapahtumaan. Jokainen lohkoketjutapahtuma allekirjoitetaan digitaalisesti yhden tai useamman osapuolen toimesta, replikoidaan jokaiselle solmulle, tilataan ja leimataan ketjun konsensusalgoritmilla ja tallennetaan pysyvästi väärinkäytön estävällä tavalla. Siksi kaikki solmut tallentavat tapahtuman kaikki tiedot identtisesti, mutta itsenäisesti, sekä todisteet siitä, kuka ne kirjoitti ja milloin. Ketjun käyttäjät voivat hakea nämä tiedot milloin tahansa myöhemmin.

Esimerkiksi MultiChain 1.0 salli yhden tai useamman nimetyn “virran” luomisen lohkoketjuun ja sen jälkeen raakadatan tallentamiseen ja noutamiseen. Jokaisella virralla on omat kirjoitusoikeudet, ja kukin solmu voi vapaasti valita, mitkä virrat tilataan. Jos solmu on tilattu virtaan, se indeksoi suoratoiston sisällön reaaliajassa, jolloin kohteet voidaan hakea nopeasti niiden järjestyksen, aikaleiman, lohkon numeron tai julkaisijan osoitteen perusteella sekä "avaimen" (tai tunnisteen) avulla. jonka avulla kohteet voidaan merkitä. MultiChain 2.0 (alfa 1: stä lähtien) laajensi virtoja tukemaan Unicode-teksti- tai JSON-tietoja sekä useita avaimia per kohde ja useita kohteita tapahtumaa kohti. Se lisäsi myös yhteenvetotoimintoja, kuten "JSON-yhdistäminen", jotka yhdistävät kohteet samalla avaimella tai julkaisijalla hyödyllisellä tavalla.

Luottamuksellisuus ja skaalautuvuus

Vaikka tietojen tallentaminen suoraan lohkoketjuun toimii hyvin, sillä on kaksi keskeistä puutetta - luottamuksellisuus ja skaalautuvuus. Aluksi luottamuksellisuudesta jokaisen virtakohteen sisältö näkyy ketjun jokaiselle solmulle, eikä tämä ole välttämättä toivottavaa lopputulosta. Monissa tapauksissa tietopalan pitäisi olla näkyvissä vain tietylle solmujen alaryhmälle, vaikka muita solmuja tarvitaan sen järjestämisen, aikaleimojen ja notaarin vahvistamiseen.

Luottamuksellisuus on suhteellisen helppo ratkaista ongelma salaamalla tiedot ennen niiden upottamista tapahtumaan. Kunkin tiedon salauksenpurkuavain jaetaan vain niiden osallistujien kanssa, joiden on tarkoitus nähdä se. Avaimen toimitus voidaan suorittaa ketjussa käyttämällä epäsymmetristä salausta (kuten kuvattu tässä) tai jonkin ketjun ulkopuolisen mekanismin kautta, kuten on edullista. Kaikki solmut, joilla ei ole avainta kohteen salauksen purkamiseen, eivät näe muuta kuin binääristä hämmennystä.

Skaalautuvuus on toisaalta merkittävämpi haaste. Sanotaan, että minkä tahansa kunnollisen blockchain-alustan tulisi tukea 500 tapahtuman sekunnissa tapahtuvaa verkon läpimenoa. Jos ketjun tarkoitus on tietojen tallennus, kunkin tapahtuman koko riippuu ensisijaisesti siitä, kuinka paljon tietoa se sisältää. Jokainen tapahtuma tarvitsee myös (vähintään) 100 tavua yleiskustannuksia lähettäjän osoitteen, digitaalisen allekirjoituksen ja muutaman muun palan tallentamiseen.

Jos otamme helpon tapauksen, jossa jokainen kohde on pieni 100 tavun JSON-rakenne, tiedonsiirtonopeus olisi 100 kilotavua sekunnissa, laskettuna 500 × (100 + 100). Tämä tarkoittaa alle 1 megabittiä / sekunti kaistanleveyttä, mikä on mukavasti minkä tahansa modernin Internet-yhteyden kapasiteetissa. Tiedot kerääntyisivät noin 3 teratavua vuodessa, mikä ei ole pieni määrä. Mutta nyt 12 teratavun kiintolevyillä laajasti saatavillaja RAID Ohjaimet, jotka yhdistävät useita fyysisiä asemia yhdeksi loogiseksi, voimme helposti tallentaa 10-20 vuoden datan jokaiseen solmuun ilman liikaa vaivaa tai kustannuksia.

Asiat näyttävät kuitenkin hyvin erilaisilta, jos tallennamme suurempia tietoja, kuten skannattua dokumentaatiota. Kohtuullisen laadukas A4-arkin JPEG-skannaus voi olla 500 kilotavua. Kerro tämä 500 tapahtumalla sekunnissa, ja katsomme 250: n läpimenoa megatavua sekunnissa. Tämä tarkoittaa 2 gigabittiä sekunnissa kaistanleveyttä, joka on nopeampi kuin useimmat paikalliset verkot, puhumattakaan Internet-yhteyksistä. Amazon Web Services -sivustolla halvin julkaistu hinta 0.05 dollaria per gigatavu, se tarkoittaa vuotuista kaistanleveyslaskua, joka on 400,000 8000 dollaria solmua kohden. Ja mihin kukin solmu tallentaa XNUMX teratavua uutta tietoa, joka syntyy vuosittain?

On selvää, että yksinkertainen ketjutallennus ei ole käytännöllinen valinta blockchain-sovelluksille, jotka tallentavat monia suuria tietoja. Loukkaantumisen lisäämiseksi, jos tietoja salataan luottamuksellisuusongelman ratkaisemiseksi, solmuja pyydetään tallentamaan valtava määrä tietoa, jota ne eivät edes osaa lukea. Tämä ei ole houkutteleva ehdotus verkon osallistujille.

Hajautusliuos

Joten miten voimme ratkaista tietojen skaalautuvuuden ongelman? Kuinka voimme hyödyntää lohkoketjun hajautettua tietojen notaariota toistamatta näitä tietoja ketjun jokaiselle solmulle?

Vastaus on älykäs tekniikka, jota kutsutaan "hashiksi". Hajautusmerkki on pitkä luku (ajatellaan 256 bittiä tai noin 80 desimaalin tarkkuudella), joka yksilöi tietopalan. Hajautusarvo lasketaan tiedoista käyttäen a yksisuuntainen toiminto jolla on tärkeä salausominaisuus: Kun otetaan huomioon mikä tahansa tieto, sen hash on helppo ja nopea laskea. Mutta tietyn hash-arvon perusteella on laskennallisesti mahdotonta löytää tietopala, joka tuottaisi kyseisen hash-koodin. Ja kun sanomme "laskennallisesti mahdoton", tarkoitamme enemmän laskelmia kuin tunnetussa universumissa on atomeja.

Hashilla on ratkaiseva rooli kaikissa lohkoketjuissa tunnistamalla yksilöllisesti tapahtumat ja estot. He myös perustavat laskennallisen haasteen työtodistusjärjestelmissä, kuten bitcoin. Monia erilaisia hajautusfunktioita on kehitetty, gobbledygook-nimillä, kuten BLAKE2, MD5 ja RIPEMD160. Mutta jotta hajautusfunktioita voidaan luottaa, sen on kestettävä laaja akateeminen tarkastelu ja testaus. Nämä testit tapahtuvat hyökkäysyrityksinä, kuten "preimage" (syötteen löytäminen annetulla hashilla), "second preimage" (toisen syötteen löytäminen samalla hashilla kuin annetulla syötöllä) ja "törmäys" (löytää kaikki mahdolliset kaksi erilaista tuloa samalla hashilla). Tästä selviytymisestä selviäminen ei ole läheskään helppoa, sillä rikkoutuneiden hash-toimintojen pitkä ja traaginen historia todistaa kuuluisan maksimin: "Älä käännä omaa salaustasi".

Palataksemme takaisin alkuperäiseen ongelmaan voimme ratkaista tietojen skaalautuvuuden lohkoketjuissa upottamalla tapahtumiin suurten tietojätteiden hajautuksen itse datan sijaan. Jokainen hajautus toimii "sitoutumisena" syötetietoihinsa, ja data itse tallennetaan lohkoketjun tai "ketjun ulkopuolisen" ulkopuolelle. Esimerkiksi suosittua SHA256-hash-toimintoa käyttämällä 500 kilotavun JPEG-kuva voidaan esittää 32 tavun lukumäärällä, pienennys on yli 15,000 500 ×. Jopa XNUMX kuvaa sekunnissa nopeudella tämä vie meidät mukavasti takaisin toteutettavien kaistanleveys- ja tallennustarpeiden alueelle itse ketjuun tallennettujen tietojen suhteen.

Tietenkään kukaan estoketjun osallistuja, joka tarvitsee ketjun ulkopuolisen kuvan, ei voi toistaa sitä hashistaan. Mutta jos kuva voidaan hakea jollakin muulla tavalla, ketjussa oleva hajautus vahvistaa sen, kuka sen loi ja milloin. Aivan kuten tavalliset ketjutiedot, hash upotetaan digitaalisesti allekirjoitettuun tapahtumaan, joka sisällytettiin ketjuun yksimielisesti. Jos kuvatiedosto putoaa taivaalta ja kuvan hajautus vastaa lohkoketjussa olevaa hashia, kuvan alkuperä ja aikaleima vahvistetaan. Joten lohkoketju tarjoaa notaarin suhteen täsmälleen saman arvon kuin jos kuva upotettaisiin suoraan ketjuun.

Kysymys toimituksesta

Toistaiseksi niin hyvä. Upottamalla hajautukset lohkoketjuun alkuperäisten tietojen sijaan meillä on helppo ratkaisu skaalautuvuusongelmaan. Siitä huolimatta yksi keskeinen kysymys on edelleen:

Kuinka toimitamme alkuperäisen ketjun ulkopuolisen sisällön niille solmuille, jotka sitä tarvitsevat, ellei itse ketjun kautta?

Tähän kysymykseen on useita mahdollisia vastauksia, ja tiedämme, että MultiChain-käyttäjät käyttävät niitä kaikkia. Yksi peruslähestymistapa on perustaa keskitetty tietovarasto johonkin luotettuun osapuoleen, johon kaikki ketjun ulkopuoliset tiedot ladataan ja sitten haetaan. Tämä järjestelmä voisi luonnollisesti käyttää "sisältöosoitetta", mikä tarkoittaa, että jokaisen datan hajautusarvo toimii suoraan sen tunnisteena haettaessa. Vaikka tämä kokoonpano saattaa toimia todistuskonseptin kannalta, sillä ei ole järkeä tuotannolle, koska lohkoketjun koko tarkoitus on poistaa luotettavat välittäjät. Vaikka ketjussa olevat hajautukset estävät välittäjää väärentämästä tietoja, se voi silti poistaa tietoja tai jättää toimittamatta niitä joillekin osallistujille teknisen vian tai roistotyöntekijän toiminnan vuoksi.

Lupaavampi mahdollisuus on pisteestä pisteeseen -viestintä, jossa solmu, joka vaatii ketjun ulkopuolista dataa, pyytää sitä suoraan sen julkaisevalta solmulta. Näin vältetään luottamus luotettuun välittäjään, mutta sillä on kolme vaihtoehtoista puutetta:

Se vaatii lohkoketjuosoitteiden kartan IP-osoitteisiin, jotta joidenkin tietojen kuluttaja voi kommunikoida suoraan julkaisijansa kanssa. Lohkoketjut voivat yleensä välttää tämän tyyppisen staattisen verkkokokoonpanon, mikä voi olla ongelma vikasietoisuuden ja yksityisyyden kannalta.
Jos alkuperäinen julkaisijasolmu on poistunut verkosta tai on väliaikaisesti poissa käytöstä, kukaan muu ei voi hakea tietoja.
Jos jotkut tiedot ovat kiinnostuneita suuresta joukosta solmuja, julkaisijat ovat ylivoimaisia pyynnöistä. Tämä voi aiheuttaa vakavia verkon ruuhkia, hidastaa julkaisijan järjestelmää ja johtaa pitkiin viiveisiin niille, jotka yrittävät noutaa kyseisiä tietoja.

Näiden ongelmien välttämiseksi käytämme mieluiten jonkinlaista hajautettua toimitusmekanismia. Solmujen tulisi pystyä hakemaan tarvitsemansa tiedot luottamatta mihinkään yksittäiseen järjestelmään - olipa se sitten keskitetty arkisto tai tietojen alkuperäinen julkaisija. Jos useammalla osapuolella on osa tietoa, heidän on jaettava taakka toimittaa tiedot kenellekään muulle, joka haluaa sen. Kenenkään ei tarvitse luottaa yksittäiseen tietolähteeseen, koska ketjun hajautus voi todistaa, että tietoja ei ole peukaloitu. Jos haitallinen solmu toimittaa minulle väärät tiedot hashille, voin yksinkertaisesti hylätä nämä tiedot ja yrittää kysyä joku muu.

Niille, joilla on kokemusta vertaisverkkojen tiedostojen jakaminen kuten Napster, Gnutella tai BitTorrent, tämä kaikki kuulostaa hyvin tutulta. Monet perusperiaatteet ovatkin samat, mutta siinä on kaksi keskeistä eroa. Ensinnäkin, olettaen, että käytämme lohkoketjuamme yrityskontekstissa, järjestelmä toimii suljetussa osallistujaryhmässä, ei koko Internetissä. Toiseksi lohkoketju lisää hajautetun tilauksen, aikaleimojen ja notaarin vahvistamisen selkärangan, jonka avulla kaikki käyttäjät voivat ylläpitää todistettavasti yhdenmukaisen ja väärinkäytön kestävän kuvan siitä, mitä tapahtui, milloin ja kuka.

Kuinka blockchain-sovelluskehittäjä voi saavuttaa tämän ketjun ulkopuolisen sisällön hajautetun toimituksen? Yksi yleinen valinta on ottaa olemassa oleva peer-to-peer-tiedostojen jakamisalusta, kuten huvittavasti nimetty Planeettienvälinen tiedostojärjestelmä (IPFS), ja käytä sitä yhdessä lohkoketjun kanssa. Jokainen osallistuja käyttää sekä lohkoketjun että IPFS-solmua, joidenkin välillä on väliohjelmia. Kun julkaistaan ketjun ulkopuolista dataa, tämä väliohjelmisto tallentaa alkuperäiset tiedot IPFS: ään ja luo sitten lohkoketjutapahtuman, joka sisältää kyseisen datan hashin. Jos haluat hakea ketjun ulkopuolista dataa, väliohjelmisto poimii hashin lohkoketjusta ja noutaa sitten tämän hash -sisällön IPFS: stä. Paikallinen IPFS-solmu tarkistaa haetun sisällön automaattisesti hashista varmistaakseen, että sitä ei ole muutettu.

Vaikka tämä ratkaisu on mahdollinen, se on kaikki melko kömpelö ja hankala. Ensinnäkin jokaisen osallistujan on asennettava, ylläpidettävä ja päivitettävä kolme erillistä ohjelmistoa (lohkoketjusolmu, IPFS-solmu ja väliohjelmisto), joista kukin tallentaa tietonsa erilliseen paikkaan. Toiseksi tulee olemaan kaksi erillistä vertaisverkkoa, joilla kullakin on oma kokoonpano, verkkoportit, identiteettijärjestelmä ja käyttöoikeudet (vaikka on huomattava, että IPFS ei vielä tue suljettuja verkkoja). Lopuksi, IPFS: n ja lohkoketjun tiukka yhdistäminen tekisi väliohjelmasta yhä monimutkaisemman. Esimerkiksi, jos haluamme, että ketjujen ulkopuoliset tiedot, joihin jotkut estoketjutapahtumat viittaavat, haetaan heti (automaattisten uudelleenkäynnistysten avulla), väliohjelmiston on oltava jatkuvasti käynnissä ja ylläpidettävä omaa monimutkaista tilaansa. Eikö olisikaan hienoa, jos blockchain-solmu tekisi kaiken tämän puolestamme?

Ketjun ulkopuoliset tiedot MultiChain 2.0: ssa

Tänään olemme iloisia voidessamme vapauttaa kolmas esikatseluversio (alfa 3) of MultiChain 2.0, täysin integroidulla ja saumattomalla ratkaisulla ketjun ulkopuoliseen dataan. Jokainen streamiin julkaistu tieto voi olla ketjussa tai ketjun ulkopuolella haluttaessa, ja MultiChain hoitaa kaiken muun.

Ei oikeastaan, tarkoitamme kaikki. MultiChain-kehittäjänä kehittäjänä sinun ei tarvitse huolehtia hajautuksista, paikallisesta tallennustilasta, sisällön löytämisestä, hajautetusta toimituksesta tai tietojen vahvistamisesta. Tässä tapahtuu kulissien takana:

Julkaistava MultiChain-solmu kirjoittaa uudet tiedot paikalliseen tallennustilaansa ja leikkaa suuret tuotteet paloiksi, jotta ne on helppo pilkkoa ja toimittaa.
Ketjun ulkopuolisten suoratoistokohteiden julkaisutapahtuma rakennetaan automaattisesti, ja se sisältää kappaleen hash (t) ja koon tavuina.
Tämä tapahtuma allekirjoitetaan ja lähetetään verkkoon etenemällä solmujen välillä ja siirtymällä lohkoketjuun tavalliseen tapaan.
Kun virtaan tilattu solmu näkee viitteen joihinkin ketjun ulkopuolisiin tietoihin, se lisää kyseisten tietojen osien hajautusarvot noutojonoonsa. (Kun tilaat vanhan virran, solmu jonottaa myös kaikki aiemmin julkaistut ketjun ulkopuoliset kohteet noudettavaksi.)
Taustaprosessina, jos solmun hakujärjestyksessä on palasia, verkkoon lähetetään kyselyjä näiden palojen löytämiseksi niiden hashien perusteella.
Nämä kappalekyselyt levitetään verkon muihin solmuihin peer-to-peer -muodolla (rajoitettu kahteen humalaan toistaiseksi - katso tekniset yksityiskohdat alla).
Mikä tahansa solmu, jolla on palan tiedot, voi vastata, ja tämä vastaus välitetään tilaajalle takaisin samalla polulla kuin kysely.
Jos mikään solmu ei vastaa palakyselyyn, pala palataan takaisin jonoon myöhempää yrittämistä varten.
Muussa tapauksessa tilaaja valitsee lupaavimman lähteen kappaleelle (humalan ja vasteajan perusteella) ja lähettää sille pyynnön kyseisen palan tiedoista jälleen samalla vertaisverkolla kuin edellinen vastaus.
Lähdesolmu toimittaa pyydetyt tiedot käyttämällä samaa polkua uudelleen.
Tilaaja tarkistaa tietojen koon ja hajautuksen alkuperäiseen pyyntöön nähden.
Jos kaikki onnistuu, tilaaja kirjoittaa tiedot paikalliselle tallennustilalleen, jolloin ne ovat heti saatavissa virran sovellusliittymien kautta.
Jos pyydetty sisältö ei saapunut tai ei vastannut haluttua tiivistettä tai kokoa, pala palataan takaisin jonoon tulevaa hakua varten toisesta lähteestä.

Mikä tärkeintä, kaikki tämä tapahtuu erittäin nopeasti. Pienissä viiveissä olevissa verkoissa pienet osat ketjun ulkopuolisista tiedoista saapuvat tilaajille sekunnin sekunnin kuluessa tapahtumasta, joka viittaa heihin. Ja korkean kuormituksen sovelluksissa testauksemme osoittaa, että MultiChain 2.0 alpha 3 pystyy ylläpitämään yli 1000 ketjun ulkopuolista tuotetta tai 25 Mt ketjun ulkopuolista dataa sekunnissa, keskitason palvelimella (Core i7) kunnollisella tavalla Internet-yhteys. Kaikki toimii hyvin ketjun ulkopuolisilla, enintään 1 Gt: n kokoisilla tuotteilla, jotka ylittävät ketjussa olevan datan 64 Mt: n rajan. Toivomme tietysti parantavan näitä lukuja edelleen, kun vietämme aikaa MultiChain 2.0: n optimointiin sen beeta-vaiheen aikana.

Kun käytät ketjun ulkopuolista dataa pikaviesteissä, MultiChain-sovelluskehittäjien on tehtävä täsmälleen kaksi asiaa:

Kun julkaiset tietoja, välitä ”offchain” -lippu asianomaisille sovellusliittymille.
Kun käytät suorakyselyä käyttäviä sovellusliittymiä, harkitse mahdollisuutta, että jotkin ketjun ulkopuoliset tiedot eivät ehkä ole vielä saatavilla, kuten "käytettävissä" -lippu ilmoittaa. Vaikka tämä tilanne on harvinainen normaaleissa olosuhteissa, on tärkeää, että sovelluskehittäjät käsittelevät tilanteen asianmukaisesti.

Tietenkin, jotta estetään jokaisen solmun hakemasta kaikkia ketjun ulkopuolisia kohteita, kohteet tulisi ryhmitellä yhteen virtoiksi sopivalla tavalla, kunkin solmun tilattaessa kiinnostavat virrat.

Ketjun sisäisiä ja ketjun ulkopuolisia kohteita voidaan käyttää samassa virrassa, ja erilaiset virtauksen kysely- ja yhteenvetotoiminnot liittyvät molempiin tietoihin identtisesti. Tämän avulla julkaisijat voivat tehdä oikean valinnan jokaiselle streamin kohteelle vaikuttamatta sovelluksen muuhun osaan. Esimerkiksi ihmisten toimintaa koskevissa JSON-kohteissa voi käyttää ketjun ulkopuolista tietoa henkilökohtaiseen tunnistamiseen ja ketjussa olevaa tietoa muuhun. Tilaajat voivat käyttää MultiChainin JSON-yhdistämistä yhdistääkseen molemmat tiedot yhdeksi JSON-tiedostoksi lukemista varten.

Jos haluat kokeilla ketjun ulkopuolisia suoratoistokohteita, noudata vain MultiChainin säännöksiä Päästä alkuun ja älä ohita osaa 5.

Mitä seuraavaksi?

Saumattomalla ketjun ulkopuolisen datan tuella MultiChain 2.0 tarjoaa suuren askeleen eteenpäin blockchain-sovelluksille, jotka keskittyvät laajamittaisiin tietojen aikaleimoihin ja notaareihin. Pidemmällä aikavälillä ajattelemme jo useita mahdollisia parannuksia tähän ominaisuuteen MultiChain-yhteisö- ja / tai yritysversioissa:

Suoratoisto toteutetaan luettu käyttöoikeudet, jotka sisältävät ketjun ulkopuolisten kohteiden, suolattujen hashien, allekirjoitettujen palakyselyjen ja salatun toimituksen yhdistelmän.
Antaa ketjun ulkopuolisen datan nimenomaisesti "unohtaa", joko yksittäisten solmujen vapaaehtoisesti tai kaikkien solmujen vastauksena ketjun sisäiseen viestiin.
Valikoivat stream-tilaukset, joissa solmut hakevat vain ketjun ulkopuolisten kohteiden tiedot tietyillä julkaisijoilla tai avaimilla.
Käyttäminen merkle-puita jotta yksi ketjun hash voi edustaa rajoittamatonta määrää ketjun ulkopuolisia kohteita, mikä antaa uuden valtavan hyppyn skaalautuvuuden kannalta.
Liitettävät tallennusmoottorit, jotka mahdollistavat ketjun ulkopuolisen datan säilyttämisen tietokannoissa tai ulkoisissa tiedostojärjestelmissä paikallisen levyn sijaan.
Solmut, jotka oppivat ajan myötä, missä kutakin ketjun ulkopuolista dataa on yleensä saatavana verkossa, ja kohdentavat osamääränsä asianmukaisesti.

Haluaisimme kuule palautetta luettelossa sekä ketjun ulkopuoliset tuotteet yleensä. Kun MultiChain 2.0 on edelleen virallisesti alfa-versiossa, on paljon aikaa parantaa tätä ominaisuutta ennen sen lopullista julkaisua.

Sillä välin olemme jo aloittaneet "Smart Filters" -työkalun, joka on viimeinen tärkeä ominaisuus, joka on suunniteltu MultiChain 2.0 -yhteisöön. Älykäs suodatin on lohkoketjuun upotettu koodikappale, joka toteuttaa mukautettuja sääntöjä tietojen tai tapahtumien vahvistamiseksi. Älykkäillä suodattimilla on joitain yhtäläisyyksiä "älykkäiden sopimusten" kanssa, ja ne voivat tehdä monia samoja asioita, mutta niillä on keskeisiä eroja turvallisuuden ja suorituskyvyn suhteen. Odotamme kertoa sinulle lisää aikanaan.

Ole hyvä ja lähetä kommentit LinkedIn.

Tekniset yksityiskohdat

MultiChain 2.0: n ketjun ulkopuolisten suoratoistokohteiden käyttö on helppoa, mutta ne sisältävät monia suunnittelupäätöksiä ja lisäominaisuuksia, jotka saattavat kiinnostaa. Alla oleva luettelo on pääasiassa relevantti kehittäjille, jotka rakentavat blockchain-sovelluksia, ja se voidaan ohittaa vähemmän teknisillä tyypeillä:

Striimikohtaiset käytännöt. Kun luodaan MultiChain-virta, se voidaan valinnaisesti rajoittaa sallimaan vain ketjussa olevat tai ketjun ulkopuoliset tiedot. Tähän voi olla useita syitä sen sijaan, että jokainen julkaisija voisi päättää itse. Esimerkiksi ketjussa olevat tuotteet tarjoavat raudan saatavuustakuun, kun taas vanhat ketjun ulkopuoliset tuotteet voivat tulla peruuttamattomiksi, jos niiden julkaisija ja muut tilaajat luopuvat verkosta. Kääntöpuolella ketjussa olevia esineitä ei voi "unohtaa" muokkaamatta lohkoketjua, kun taas ketjun ulkopuoliset tuotteet ovat joustavampia. Tämä voi olla tärkeää tietosuojasääntöjen, kuten Euroopan uusien GDPR-asetusten, kannalta.
Ketjussa olevat metatiedot. Ketjun ulkopuolisissa tuotteissa ketjun tapahtuma sisältää edelleen kohteen julkaisijan (avaimet), avaimet (avaimet), muodon (JSON, teksti tai binaari) ja kokonaiskoon. Kaikki tämä vie hyvin vähän tilaa, ja auttaa sovelluskehittäjiä selvittämään, onko ketjun ulkopuolisen kohteen poissaolo tietyssä streamikyselyssä huolestuttavaa.
Kahden hypyn raja. Kun välität hakukyselyjä vertaisverkossa, saavutettavuuden ja suorituskyvyn välillä on kompromissi. Vaikka olisi hienoa, että jokainen kysely levitetään jokaista polkua pitkin, se voi tukkia verkon tarpeettomilla "chattereillä". Joten toistaiseksi kyselyt rajoittuvat kahteen humalaan, mikä tarkoittaa, että solmu voi noutaa ketjun ulkopuolisen datan mistä tahansa ikäisensä vertaisesta. Pienemmissä alle 1000 solmun verkoissa, joilla on taipumus luonnehtia yrityksen estoketjuja, uskomme, että tämä toimii hyvin, mutta meidän on helppo säätää tätä rajoitusta (tai tarjota sitä parametrina), jos osoitamme olevan väärä.
Paikallinen varasto. Jokainen MultiChain-solmu tallentaa ketjun ulkopuolisen datan tavallisen lohkoketjuhakemiston "paloiksi" -hakemistoon käyttäen tehokasta binaarimuotoa ja LevelDB-hakemistoa. Erillistä alihakemistoa käytetään jokaisen tilatun virran kohteisiin sekä solmun itse julkaisemiin kohteisiin. Kussakin näistä alihakemistoista kaksoiskappaleet (samalla hashilla) tallennetaan vain kerran. Kun solmu peruuttaa virran tilauksen, se voi valita, tyhjennetäänkö kyseiselle virralle haetut ketjun ulkopuoliset tiedot vai ei.
Binaarinen välimuisti. Kun julkaistaan suuria binaaritietoja, ketjussa tai ketjussa, sovelluskehittäjien ei ehkä ole käytännöllistä lähettää kyseisiä tietoja MultiChainin sovellusliittymään yhdessä JSON-RPC-pyynnössä. Joten MultiChain 2.0 ottaa käyttöön binäärisen välimuistin, jonka avulla voidaan rakentaa suuria tietomääriä useiden API-puheluiden yli ja julkaista sitten lyhyessä viimeisessä vaiheessa. Jokainen binaarisen välimuistin kohde on tallennettu yksinkertaisena tiedostona blockchain-hakemiston "cache" -hakemistoon, jolloin myös gigatavua tietoa voidaan siirtää suoraan tiedostojärjestelmän kautta.
Valvontasovellusliittymät. MultiChain 2.0 alpha 3 lisää kaksi uutta sovellusliittymää ketjun ulkopuolisen datan asynkronisen haun seuraamiseen. Ensimmäinen sovellusliittymä kuvaa jonon tämänhetkisen tilan ja näyttää kuinka monta palaa (ja kuinka paljon tietoa) odottaa tai kysytään tai haetaan. Toinen sovellusliittymä tarjoaa yhteenvetotilastot kaikista solmun käynnistämisen jälkeen lähetetyistä hakukyselyistä ja pyynnöistä, mukaan lukien erityyppisten vikojen määrät.
Huuhtele julkaisussa. Kun ketjun ulkopuolista kohdetta julkaistaan, MultiChain varmistaa, että sen paikallinen kopio tiedoista kirjoitetaan kokonaan (tai "huuhdellaan") fyysiselle levyasemalle ennen tapahtumaa, joka viittaa siihen, että tiedot lähetetään verkkoon. Muussa tapauksessa, jos solmu ei ollut niin onnekas, että se menetti virran heti tapahtuman lähettämisen jälkeen, ketjun ulkopuolinen data saattoi kadota pysyvästi. Tämä ei ole ongelma itse MultiChainille, koska viiveet palan noutoyritysten välillä kasvavat automaattisesti ajan myötä. Mutta se voi aiheuttaa ongelmia sovellustasolla, jossa kaikki tietävät joidenkin tietojen olemassaolosta, mutta kukaan ei löydä niitä.
Kustannustoiminta. Huuhtelemalla ketjun ulkopuoliset tiedot levylle tällä tavalla, MultiChain voi kärsiä suoritusrangaistuksesta, koska fyysiset levyt ovat hitaita. Esimerkiksi keskitason 7200 rpm: n kiintolevy pystyy suorittamaan vain noin 100 satunnaista tiedon kirjoittamista sekunnissa, mikä puolestaan rajoittaa nopeutta, jolla yksittäinen solmu voi julkaista ketjun ulkopuolisia kohteita. Tätä ongelmaa on kolme mahdollista kiertotapaa. Ensinnäkin, solmut voivat käyttää SSD-asemaa tavallisen kiintolevyn sijaan, joka tukee 10,000 XNUMX s satunnaisia kirjoitusoperaatioita sekunnissa. Toiseksi useita ketjun ulkopuolisia kohteita voidaan julkaista yhdellä tapahtumalla käyttämällä ”createrawsendfrom” -sovellusliittymää. Tässä tapauksessa MultiChain kirjoittaa kaikki ketjun ulkopuoliset tiedot, joihin tapahtuma viittaa, yhdellä levyllä. Lopuksi, MultiChain voidaan määrittää olemaan huuhtelematta ketjun ulkopuolista tietoa levylle ennen siihen viittaavan tapahtuman lähettämistä. Käytä tätä vaihtoehtoa varoen.
Alkuperäisen valuutan integrointi. MultiChain on aina tarjonnut sitä vaativissa käyttötapauksissa mahdollisuuden käyttää natiivivaluuttaa lohkoketjussa estääkseen tapahtumien roskapostin ja / tai kannustaakseen lohkojen validoijia ("kaivostyöläisiä"). Näissä tapauksissa liiketoimien on tarjottava kaivostyöläisille vähimmäismaksu, joka on suhteessa heidän kokoonsa tavuina, jotta heidät voidaan välittää ja vahvistaa ketjussa. Tätä mekanismia on laajennettu, jotta ketjun ulkopuoliset roskapostit voidaan estää, edellyttämällä vähimmäismaksua per kilotavun tapahtumassa viitattu ketjun ulkopuolinen data.
Arkistoi solmut. Jos solmu haluaa tilata jokaisen virran ja siksi hakea ja tallentaa kaikki julkaistut ketjun ulkopuoliset kohteet, se voidaan määrittää tekemään se ajonaikaisen parametrin "autosubscribe" avulla. Tällainen solmu toimii koko verkon varmuuskopiona, mikä takaa, että ketjun ulkopuoliset kohteet eivät häviä tai ole käytettävissä, riippumatta siitä, mitkä muut solmut katoavat. Voidaan kuvitella, että kolmannet osapuolet tarjoavat tätä kaupallisena palveluna.