Scaling Blockchains With Off-chain Data

Publisert av Platon

Følgere: 0

Når en hash er verdt en million ord

Nå er det klart at mange blockchain-brukstilfeller ikke har noe å gjøre med økonomiske transaksjoner. I stedet er kjedens formål å muliggjøre desentralisert aggregering, bestilling, tidsstempling og arkivering av noen type informasjon, inkludert strukturerte data, korrespondanse eller dokumentasjon. Blockchainens kjerneverdi gjør det mulig for deltakerne å beviselig og permanent bli enige om nøyaktig hvilke data som ble skrevet inn, når og av hvem, uten å stole på en pålitelig formidler. For eksempel er SAP nylig lansert blockchain-plattform, som støtter MultiChain og Hyperledger Fabric, retter seg mot et bredt spekter av forsyningskjeder og andre ikke-økonomiske applikasjoner.

Den enkleste måten å bruke en blockchain for å registrere data er å legge inn hvert stykke data direkte i en transaksjon. Hver blockchain-transaksjon er digitalt signert av en eller flere parter, replikert til hver node, bestilt og tidsstemplet av kjedens konsensusalgoritme og lagret permanent på en manipulasjonssikker måte. Alle data i transaksjonen vil derfor bli lagret identisk, men uavhengig av hver node, sammen med et bevis på hvem som skrev det og når. Kjedens brukere er i stand til å hente denne informasjonen når som helst.

For eksempel tillot MultiChain 1.0 at en eller flere navngitte "strømmer" ble opprettet på en blockchain og deretter brukt til lagring og henting av rådata. Hver strøm har sitt eget sett med skrivetillatelser, og hver node kan fritt velge hvilke strømmer du vil abonnere på. Hvis en node abonnerer på en strøm, indekserer den strømens innhold i sanntid, slik at elementene raskt kan hentes ut basert på bestilling, tidsstempel, blokknummer eller utgiveradresse, samt via en "nøkkel" (eller etikett) som elementer kan merkes med. MultiChain 2.0 (siden alfa 1) utvidet strømmer for å støtte Unicode-tekst eller JSON-data, samt flere nøkler per vare og flere elementer per transaksjon. Det la også til oppsummeringsfunksjoner som "JSON merge" som kombinerer elementer med samme nøkkel eller utgiver på en nyttig måte.

Konfidensialitet og skalerbarhet

Mens lagring av data direkte på en blockchain fungerer bra, lider det av to viktige mangler - konfidensialitet og skalerbarhet. Til å begynne med konfidensialitet er innholdet i hvert strømelement synlig for hver node i kjeden, og dette er ikke nødvendigvis et ønskelig resultat. I mange tilfeller skal et stykke data bare være synlig for en bestemt delmengde av noder, selv om det er behov for andre noder for å hjelpe med bestilling, tidsstempel og notarisering.

Konfidensialitet er et relativt enkelt problem å løse, ved å kryptere informasjon før den er innebygd i en transaksjon. Krypteringsnøkkelen for hvert stykke data deles bare med deltakerne som er ment å se det. Nøkkeloverføring kan utføres on-chain ved bruk av asymmetrisk kryptografi (som beskrevet her) eller via en off-chain mekanisme, slik det er foretrukket. Enhver node som mangler nøkkelen til å dekryptere et element, vil ikke se noe annet enn binær gibberish.

Skalerbarhet er derimot en mer betydelig utfordring. La oss si at enhver anstendig blockchain-plattform skal støtte en nettverksgjennomstrømning på 500 transaksjoner per sekund. Hvis formålet med kjeden er informasjonslagring, vil størrelsen på hver transaksjon først og fremst avhenge av hvor mye data den inneholder. Hver transaksjon vil også trenge (minst) 100 byte overhead for å lagre avsenderens adresse, digital signatur og noen få andre biter.

Hvis vi tar en enkel sak, hvor hvert element er en liten JSON-struktur på 100 byte, vil den totale datakapasiteten være 100 kilobyte per sekund, beregnet fra 500 × (100 + 100). Dette tilsvarer under 1 megabit / sekund båndbredde, noe som er komfortabelt innenfor kapasiteten til enhver moderne internettforbindelse. Data vil akkumuleres med en hastighet på rundt 3 terabyte per år, noe som ikke er så lite. Men med 12 terabyte harddisker nå allment tilgjengeligog RAID kontrollere som kombinerer flere fysiske stasjoner til en enkelt logisk, kan vi enkelt lagre 10-20 år med data på hver node uten for mye bry eller utgifter.

Ting ser imidlertid veldig annerledes ut hvis vi lagrer større informasjon, for eksempel skannet dokumentasjon. En JPEG-skanning av rimelig kvalitet av et A4-ark kan være 500 kilobyte i størrelse. Multipliser dette med 500 transaksjoner per sekund, og vi ser på en gjennomstrømning på 250 megabyte per sekund. Dette oversettes til 2 gigabit / sekund båndbredde, noe som er raskere enn de fleste lokale nettverk, enn si forbindelser til Internett. På Amazon Web Services 'billigste publisert pris på $ 0.05 per gigabyte, betyr det en årlig båndbreddefaktura på $ 400,000 8000 per node. Og hvor vil hver node lagre XNUMX terabyte med nye data som genereres årlig?

Det er klart at, for blockchain-applikasjoner som lagrer mange store deler av data, er ikke enkel lagring i kjeden et praktisk valg. Hvis data blir kryptert for å løse konfidensialitetsproblemet, blir noder bedt om å lagre en enorm mengde informasjon som de ikke en gang kan lese. Dette er ikke et attraktivt tilbud for nettverkets deltakere.

Hash-løsningen

Så hvordan løser vi problemet med dataskalerbarhet? Hvordan kan vi dra nytte av blockchainens desentraliserte notarisering av data uten å replikere dataene til hver node i kjeden?

Svaret er med et smart stykke teknologi som kalles "hash". En hash er et langt tall (tenk 256 bits, eller rundt 80 desimaltegn) som unikt identifiserer et stykke data. Hashet beregnes ut fra dataene ved hjelp av a enveisfunksjon som har en viktig kryptografisk eiendom: Gitt alle data, er det enkelt og raskt å beregne hash. Men gitt en bestemt hash, er det beregningsmessig umulig å finne et stykke data som vil generere den hashen. Og når vi sier ”beregningsmessig umulig”, mener vi flere beregninger enn det er atomer i det kjente universet.

Hashes spiller en avgjørende rolle i alle blockchains, ved å identifisere transaksjoner og blokker. De ligger også til grunn for beregningsutfordringen i proof-of-work-systemer som bitcoin. Mange forskjellige hashfunksjoner er utviklet, med gobbledygook-navn som BLAKE2, MD5 og RIPEMD160. Men for at en hvilken som helst hashfunksjon skal stole på, må den tåle omfattende akademisk gjennomgang og testing. Disse testene kommer i form av forsøk på angrep, for eksempel “preimage” (finne en inngang med gitt hash), “second preimage” (finne en andre inngang med samme hash som den gitte inputen) og “kollisjon” (finne noen to forskjellige innganger med samme hash). Å overleve denne hansken er langt fra lett, med en lang og tragisk historie med ødelagte hash-funksjoner som viser den berømte maksimen: "Ikke rull din egen krypto."

For å gå tilbake til vårt opprinnelige problem, kan vi løse dataskalerbarhet i blokkjeder ved å legge inn hasjene til store deler av data i transaksjoner, i stedet for selve dataene. Hver hash fungerer som en "forpliktelse" til sine inngangsdata, med selve dataene lagret utenfor blockchain eller "off-chain". For eksempel, ved å bruke den populære SHA256-hashfunksjonen, kan et JPEG-bilde på 500 kilobyte bli representert med et 32-byte tall, en reduksjon på over 15,000 500 ×. Selv med en hastighet på XNUMX bilder per sekund, setter dette oss komfortabelt tilbake på territoriet med mulige båndbredde- og lagringskrav, når det gjelder data lagret i selve kjeden.

Selvfølgelig kan enhver blockchain-deltaker som trenger et off-chain-bilde, ikke reprodusere det fra hash. Men hvis bildet kan hentes på en annen måte, tjener kjeden hash for å bekrefte hvem som opprettet det og når. Akkurat som vanlige data på kjeden er hasjen innebygd i en digitalt signert transaksjon, som ble inkludert i kjeden ved enighet. Hvis en bildefil faller ut av himmelen, og hashen for det bildet samsvarer med en hash i blokkjeden, bekreftes opprinnelsen og tidsstempelet til det bildet. Så blockchain gir nøyaktig samme verdi når det gjelder notarisering som om bildet var innebygd i kjeden direkte.

Et spørsmål om levering

Så langt så bra. Ved å legge inn hasjer i en blockchain i stedet for de originale dataene, har vi en enkel løsning på problemet med skalerbarhet. Likevel gjenstår et avgjørende spørsmål:

Hvordan leverer vi det opprinnelige off-chain innholdet til de nodene som trenger det, om ikke gjennom selve kjeden?

Dette spørsmålet har flere mulige svar, og vi vet om MultiChain-brukere som bruker dem alle. En grunnleggende tilnærming er å sette opp et sentralisert lager på en eller annen klarert fest, der alle off-chain data blir lastet opp og deretter hentet. Dette systemet kan naturligvis bruke "innholdsadressering", noe som betyr at hashen til hvert stykke data tjener direkte som identifikator for henting. Imidlertid, selv om dette oppsettet kan fungere for et proof-of-concept, gir det ikke mening for produksjonen, fordi hele poenget med en blockchain er å fjerne pålitelige mellomledd. Selv om hasj i kjeden hindrer mellomledd i å forfalske data, kan det likevel slette data eller unnlate å levere dem til noen deltakere på grunn av en teknisk feil eller handlinger fra en useriøs ansatt.

En mer lovende mulighet er punkt-til-punkt kommunikasjon, der noden som krever noen off-chain data ber om den direkte fra noden som publiserte den. Dette unngår å stole på en pålitelig mellommann, men lider av tre alternative mangler:

Det krever et kart over blockchain-adresser til IP-adresser, slik at forbrukeren av noen data kan kommunisere direkte med utgiveren. Blockchains kan vanligvis unngå denne typen statiske nettverkskonfigurasjoner, noe som kan være et problem når det gjelder failover og personvern.
Hvis den opprinnelige utgivernoden har forlatt nettverket, eller midlertidig er ute av drift, kan ikke dataene hentes av noen andre.
Hvis et stort antall noder er interessert i noen data, vil utgiveren bli overveldet av forespørsler. Dette kan skape alvorlig nettverksbelastning, redusere utgiverens system og føre til lange forsinkelser for de som prøver å hente ut dataene.

For å unngå disse problemene, vil vi ideelt sett bruke en slags desentralisert leveringsmekanisme. Noder skal være i stand til å hente dataene de trenger uten å stole på noe enkelt system - det være seg et sentralisert arkiv eller datas opprinnelige utgiver. Hvis flere parter har et stykke data, bør de dele byrden ved å levere det til alle andre som ønsker det. Ingen trenger å stole på en individuell datakilde, fordi hasj i kjeden kan bevise at det ikke er blitt manipulert med data. Hvis en ondsinnet node gir meg feil data for en hash, kan jeg bare forkaste disse dataene og prøve å spørre noen andre.

For de som har erfaring med peer-to-peer fildeling protokoller som Napster, Gnutella eller BitTorrent, dette høres veldig kjent ut. Faktisk er mange av de grunnleggende prinsippene de samme, men det er to viktige forskjeller. For det første, forutsatt at vi bruker blockchain i bedriftskontekst, kjører systemet i en lukket gruppe deltakere, i stedet for Internett som helhet. For det andre legger blockchain til en desentralisert ryggrad for bestilling, tidsstempling og notarisering, slik at alle brukere kan opprettholde et beviselig konsistent og manipuleringsbestandig syn på nøyaktig hva som skjedde, når og av hvem.

Hvordan kan en blockchain applikasjonsutvikler oppnå denne desentraliserte leveransen av off-chain innhold? Et vanlig valg er å ta en eksisterende peer-to-peer fildelingsplattform, for eksempel den morsomt kalt InterPlanetary filsystem (IPFS), og bruk den sammen med blockchain. Hver deltaker kjører både en blockchain-node og en IPFS-node, med noe mellomvare som koordinerer mellom de to. Når du publiserer data utenfor kjeden, lagrer denne mellomvaren de originale dataene i IPFS, og lager deretter en blockchain-transaksjon som inneholder datahash. For å hente noen off-chain-data, trekker mellomvaren hash fra blockchain, og bruker deretter denne hash for å hente innholdet fra IPFS. Den lokale IPFS-noden verifiserer automatisk hentet innhold mot hashen for å sikre at det ikke er endret.

Selv om denne løsningen er mulig, er det ganske klønete og upraktisk. Først må hver deltaker installere, vedlikeholde og oppdatere tre separate programvarestykker (blockchain node, IPFS node og middleware), som hver lagrer dataene sine på et eget sted. For det andre vil det være to separate peer-to-peer-nettverk, hver med sin egen konfigurasjon, nettverksporter, identitetssystem og tillatelse (selv om det skal bemerkes at IPFS ennå ikke støtter lukkede nettverk). Til slutt, tett å koble IPFS og blockchain sammen, ville gjøre mellomvaren stadig mer kompleks. For eksempel, hvis vi vil at off-chain-data som er referert til av noen blockchain-transaksjoner, skal hentes øyeblikkelig (med automatiske forsøk), må mellomvaren stadig være i gang og opprettholde sin egen komplekse tilstand. Ville det ikke vært fint om blockchain-noden gjorde alt dette for oss?

Off-chain data i MultiChain 2.0

I dag gleder vi oss over å frigjøre tredje forhåndsvisning versjon (alfa 3) av MultiChain 2.0, med en fullintegrert og sømløs løsning for off-chain data. Hver informasjon publisert i en strøm kan være on-chain eller off-chain etter ønske, og MultiChain tar seg av alt annet.

Nei egentlig, mener vi alt. Som utvikler som bygger på MultiChain, trenger du ikke å bekymre deg for hashes, lokal lagring, innholdsoppdagelse, desentralisert levering eller dataverifisering. Her er hva som skjer bak kulissene:

Den publiserende MultiChain-noden skriver de nye dataene i sin lokale lagring, og skjærer store gjenstander i biter for enkel fordøyelse og levering.
Transaksjonen for publisering av strømforsyningselementer utenfor kjeden bygges automatisk, og inneholder mengden hash (er) og størrelse (r) i byte.
Denne transaksjonen signeres og sendes til nettverket, og forplanter seg mellom noder og går inn i blockchain på vanlig måte.
Når en node som er abonnert på en strøm, ser en referanse til noen off-chain-data, legger den til hash-hashene for disse dataene i hentekøen. (Når du abonnerer på en gammel strøm, køer også en node eventuelle tidligere publiserte varer utenfor kjeden for henting.)
Som en bakgrunnsprosess, hvis det er biter i en nodes hentekø, sendes forespørsler ut til nettverket for å finne disse biter, som identifisert av deres hashes.
Disse klossespørsmålene overføres til andre noder i nettverket på en peer-to-peer-måte (begrenset til to humle for nå - se tekniske detaljer nedenfor).
Enhver node som har dataene for en del kan svare, og dette svaret videreføres til abonnenten tilbake på samme bane som spørringen.
Hvis ingen noder svarer på klumpespørringen, returneres klumpen tilbake til køen for senere forsøk.
Ellers velger abonnenten den mest lovende kilden for en del (basert på humle og responstid), og sender den en forespørsel om dataene til den delen, igjen langs samme peer-to-peer-bane som forrige svar.
Kildenoden leverer de forespurte dataene ved å bruke den samme banen igjen.
Abonnenten verifiserer datastørrelsen og hashen i forhold til den opprinnelige forespørselen.
Hvis alt sjekker ut, skriver abonnenten dataene til sin lokale lagring, og gjør den umiddelbart tilgjengelig for henting via stream-API-ene.
Hvis det forespurte innholdet ikke kom, eller ikke samsvarte med ønsket hash eller størrelse, returneres klumpen tilbake til køen for fremtidig henting fra en annen kilde.

Viktigst, alt dette skjer ekstremt raskt. I nettverk med lav ventetid vil små biter av off-chain-data komme til abonnenter innen et brutt sekund av transaksjonen som refererer til dem. Og for applikasjoner med høy belastning viser testingen vår at MultiChain 2.0 alpha 3 kan opprettholde en hastighet på over 1000 off-chain-elementer eller 25 MB off-chain-data hentet per sekund, på en mellomstore server (Core i7) med en anstendig Internett-tilkobling. Alt fungerer bra med varer utenfor kjeden opptil 1 GB i størrelse, langt over 64 MB grensen for data i kjeden. Selvfølgelig håper vi å forbedre disse tallene ytterligere når vi bruker tid på å optimalisere MultiChain 2.0 i løpet av beta-fasen.

Når du bruker off-chain i stedet for on-chain-data i strømmer, må MultiChain applikasjonsutviklere gjøre nøyaktig to ting:

Når du publiserer data, send et "offchain" -flagg til de aktuelle API-ene.
Når du bruker strømspørrings-API-ene, bør du vurdere muligheten for at noen off-chain-data ennå ikke er tilgjengelige, som rapportert av "tilgjengelig" -flagget. Selv om denne situasjonen vil være sjelden under normale omstendigheter, er det viktig for applikasjonsutviklere å håndtere den riktig.

Selvfølgelig, for å forhindre at hver node henter hvert element utenfor kjeden, bør elementene grupperes sammen i strømmer på en passende måte, med hver node som abonnerer på de interessestrømmene.

Artikler i kjeden og utenfor kjeden kan brukes i samme strøm, og de forskjellige strømspørrings- og oppsummeringsfunksjonene er knyttet til begge typer data identisk. Dette gjør at utgivere kan ta det riktige valget for hvert element i en strøm, uten å påvirke resten av applikasjonen. For eksempel kan en strøm av JSON-artikler om folks aktiviteter bruke off-chain data for personlig identifisering av informasjon, og on-chain data for resten. Abonnenter kan bruke MultiChains JSON-sammenslåing for å kombinere begge typer informasjon til en enkelt JSON for lesing.

Hvis du vil prøve strømforsyninger utenfor kjeden, er det bare å følge MultiChains vanlige Komme i gang veiledning, og pass på at du ikke hopper over avsnitt 5.

Så hva er det neste?

Med sømløs støtte for off-chain data, vil MultiChain 2.0 tilby et stort skritt fremover for blockchain-applikasjoner som er fokusert på tidsstempel og notarisering i stor skala. På lengre sikt tenker vi allerede på massevis av mulige fremtidige forbedringer av denne funksjonen for fellesskaps- og / eller Enterprise-utgavene av MultiChain:

Implementering av strøm lese tillatelser ved hjelp av en kombinasjon av varer utenfor kjeden, saltede hashes, signerte klossespørsmål og kryptert levering.
Tillat at off-chain data eksplisitt "glemmes", både frivillig av individuelle noder, eller av alle noder som svar på en melding i kjeden.
Selektive strømabonnement, der noder bare henter data for off-chain-varer med bestemte utgivere eller nøkler.
Ved hjelp av merkle trær for å gjøre det mulig for en enkelt hasj på kjeden å representere et ubegrenset antall varer utenfor kjeden, noe som gir et stort hopp når det gjelder skalerbarhet.
Pluggbare lagringsmotorer, slik at data utenfor kjeden kan oppbevares i databaser eller eksterne filsystemer i stedet for lokal disk.
Noder som lærer over tid der hver type off-chain data vanligvis er tilgjengelig i et nettverk, og fokuserer klumpespørringene sine riktig.

Det vil vi gjerne hør din tilbakemelding på listen ovenfor, så vel som varer utenfor kjeden generelt. Med MultiChain 2.0 fortsatt offisielt i alfa, er det god tid til å forbedre denne funksjonen før den endelige utgivelsen.

I mellomtiden har vi allerede startet arbeidet med “Smart Filters”, den siste store funksjonen som er planlagt for MultiChain 2.0 Community. Et smart filter er et stykke kode innebygd i blockchain som implementerer tilpassede regler for validering av data eller transaksjoner. Smarte filtre har noen likheter med "smarte kontrakter", og kan gjøre mange av de samme tingene, men har viktige forskjeller når det gjelder sikkerhet og ytelse. Vi gleder oss til å fortelle deg mer etter hvert.

Legg inn kommentarer på Linkedin.

Tekniske detaljer

Selv om strømutstyr utenom kjeden i MultiChain 2.0 er enkle å bruke, inneholder de mange designbeslutninger og tilleggsfunksjoner som kan være av interesse. Listen nedenfor vil hovedsakelig være relevant for utviklere som bygger blockchain-applikasjoner, og kan hoppes over av mindre tekniske typer:

Retningslinjer per strøm. Når en MultiChain-strøm opprettes, kan den valgfritt begrenses til kun å tillate on-chain eller off-chain data. Det er flere mulige grunner til å gjøre dette, i stedet for å la hver utgiver bestemme selv. Eksempelvis tilbyr varer på kjeden en tilgjengelighetsgaranti, mens gamle varer utenom kjeden kan bli uopprettelig hvis utgiveren og andre abonnenter slipper nettverket. På baksiden kan ikke kjedeelementer "glemmes" uten å endre blockchain, mens varer utenfor kjeden er mer fleksible. Dette kan være viktig når det gjelder personvernregler, for eksempel Europas nye GDPR-regelverk.
Metadata i kjeden. For varer utenfor kjeden inneholder transaksjonen i kjeden fremdeles varens utgiver (er), nøkkel (r), format (JSON, tekst eller binær) og total størrelse. Alt dette tar veldig lite plass, og hjelper applikasjonsutviklere med å avgjøre om utilgjengeligheten til en off-chain-vare er bekymringsfull for et bestemt strømspørsmål.
Tohoppsgrense. Når du videresender klossespørsmål over peer-to-peer-nettverket, er det en avveining mellom tilgjengelighet og ytelse. Selv om det ville være fint for hvert spørsmål å forplante seg langs hver eneste bane, kan dette tette nettverket med unødvendig "prat". Så for øyeblikket er klumpespørringer begrenset til to humle, noe som betyr at en node kan hente data utenfor kjeden fra alle andre. I de mindre nettverkene med under 1000 noder som har en tendens til å karakterisere bedriftsblokkjeder, tror vi dette vil fungere bra, men det er lett for oss å justere denne begrensningen (eller tilby den som en parameter) hvis vi viser seg å være feil.
Lokal lagring. Hver MultiChain-node lagrer off-chain-data i "chunks" -katalogen i sin vanlige blockchain-katalog, ved hjelp av et effektivt binært format og LevelDB-indeks. En egen underkatalog brukes for elementene i hver av de streamede abonnementene, så vel som de som er publisert av selve noden. I hver av disse underkatalogene lagres duplikatbiter (med samme hash) bare en gang. Når en node avslutter abonnementet på en strøm, kan den velge om de data som ikke er hentet for den strømmen, skal renses eller ikke.
Binær cache. Når du publiserer store biter av binær data, enten det er on-chain eller off-chain, er det kanskje ikke praktisk for applikasjonsutviklere å sende disse dataene til MultiChains API i en enkelt JSON-RPC-forespørsel. Så MultiChain 2.0 implementerer en binær hurtigbuffer, som gjør det mulig å bygge opp store deler av data over flere API-samtaler, og deretter publisere i et kort siste trinn. Hvert element i den binære cachen er lagret som en enkel fil i "cache" -underkatalogen i blockchain-katalogen, slik at gigabyte data også kan skyves direkte via filsystemet.
Overvåking APIer. MultiChain 2.0 alpha 3 legger til to nye APIer for å overvåke asynkron henting av off-chain data. Den første API-en beskriver den nåværende tilstanden til køen, og viser hvor mange biter (og hvor mye data) som venter eller blir spurt eller hentet. Den andre API-en gir samlet statistikk for alle spørsmål og forespørsler som sendes siden noden startet, inkludert antall forskjellige typer feil.
Spyl på publiser. Når du publiserer en vare utenfor kjeden, sørger MultiChain for at den lokale kopien av dataene er fullstendig skrevet (eller "spylt") til den fysiske diskstasjonen før transaksjonen som refererer til at data sendes til nettverket. Ellers, hvis noden var uheldig nok til å miste strøm umiddelbart etter kringkasting av transaksjonen, kan dataene utenfor kjeden gå tapt permanent. Dette er ikke et problem for MultiChain selv, siden forsinkelsene mellom forsøk på å hente en del vokser automatisk over tid. Men det kan føre til problemer på applikasjonsnivå, der alle vet om eksistensen av noen data, men ingen kan finne dem.
Publiseringsytelse. Ved å skylle off-chain data til disk på denne måten, kan MultiChain pådra seg en ytelsesstraff, siden fysiske disker er treg. For eksempel kan en harddisk på mellom 7200 o / min bare utføre rundt 100 tilfeldige dataskrivninger per sekund, og i sin tur begrense hastigheten som en individuell node kan publisere varer utenfor kjeden. Det er tre mulige løsninger for dette problemet. Først og enklest kan noder bruke en SSD-stasjon (SSD) i stedet for en vanlig harddisk, som støtter 10,000 XNUMX sekunder med tilfeldige skriveoperasjoner per sekund. For det andre kan flere varer utenfor kjeden publiseres i en enkelt transaksjon ved bruk av "Createrawsendfrom" API. I dette tilfellet skriver MultiChain alle off-chain-data som det refereres til av en transaksjon i en enkelt diskoperasjon. Endelig kan MultiChain konfigureres til ikke å spyle off-chain data til disken før de kringkaster transaksjonen som refererer til den. Bruk dette alternativet med forsiktighet.
Innfødt valutaintegrasjon. For brukstilfeller som krever det, har MultiChain alltid tilbudt muligheten til å bruke en innfødt valuta i en blockchain for å forhindre transaksjons spam og / eller tilskynde blokkvalidatorer ("gruvearbeidere"). I disse tilfellene må transaksjoner tilby gruvearbeidere et minimumsgebyr som er proporsjonalt med størrelsen i byte, for å bli videreformidlet og bekreftet i kjeden. Denne mekanismen er utvidet for å forhindre spam utenfor kjeden, ved å kreve et minimum tilleggsgebyr per kilobyte off-chain-data som det henvises til i en transaksjon.
Arkiv noder. Hvis en node ønsker å abonnere på hver strøm, og derfor henter og lagrer hvert publiserte off-chain-element, kan det konfigureres til å gjøre det ved å bruke kjøretidsparameteren "autosubscribe". Enhver slik node vil fungere som en sikkerhetskopi for hele nettverket, og garantere at varer utenfor kjeden ikke vil gå tapt eller utilgjengelig, uansett hvilke andre noder som forsvinner. Man kan forestille seg tredjepartsbedrifter som tilbyr dette som en kommersiell tjeneste.