Skalering af blockchains med off-chain data

Genudgivet af Platon

Abonnenter: 0

Når en hash er en million ord værd

På nuværende tidspunkt er det klart, at mange blockchain-brugssager ikke har noget at gøre med finansielle transaktioner. I stedet er kædens formål at muliggøre decentral aggregering, bestilling, tidsstempling og arkivering af enhver type information, herunder strukturerede data, korrespondance eller dokumentation. Blockchains kerneværdi er at gøre det muligt for dens deltagere beviseligt og permanent at blive enige om præcis, hvilke data der blev indtastet, hvornår og af hvem, uden at være afhængig af en betroet mellemmand. For eksempel er SAP for nylig lanceret blockchain platform, som understøtter MultiChain og Hyperledger Fabric, retter sig mod en bred vifte af forsyningskæder og andre ikke-finansielle applikationer.

Den enkleste måde at bruge en blockchain til at registrere data på er at indlejre hvert stykke data direkte i en transaktion. Hver blockchain-transaktion er digitalt underskrevet af en eller flere parter, replikeret til hver knude, ordnet og tidsstemplet af kædens konsensusalgoritme og lagret permanent på en manipulationssikker måde. Alle data i transaktionen vil derfor blive lagret identisk, men uafhængigt af hver node, sammen med et bevis på, hvem der har skrevet det og hvornår. Kædens brugere er i stand til at hente disse oplysninger til enhver tid fremover.

For eksempel tillod MultiChain 1.0, at en eller flere navngivne "streams" blev oprettet på en blockchain og derefter brugt til at gemme og hente rådata. Hver stream har sit eget sæt skrivetilladelser, og hver node kan frit vælge, hvilke streams de vil abonnere på. Hvis en node abonnerer på en stream, indekserer den streamens indhold i realtid, hvilket gør det muligt at hente varer hurtigt baseret på deres bestilling, tidsstempel, bloknummer eller udgiveradresse samt via en "nøgle" (eller etiket) som varer kan mærkes efter. MultiChain 2.0 (siden alpha 1) udvidede streams til at understøtte Unicode-tekst eller JSON-data, samt flere nøgler pr. vare og flere elementer pr. transaktion. Det tilføjede også opsummeringsfunktioner såsom "JSON merge", som kombinerer elementer med den samme nøgle eller udgiver på en nyttig måde.

Fortrolighed og skalerbarhed

Mens lagring af data direkte på en blockchain fungerer godt, lider den af to vigtige mangler - fortrolighed og skalerbarhed. Til at begynde med fortrolighed er indholdet af hvert stream-element synligt for hver node i kæden, og dette er ikke nødvendigvis et ønskeligt resultat. I mange tilfælde bør et stykke data kun være synligt for et bestemt undersæt af noder, selvom andre noder er nødvendige for at hjælpe med dets bestilling, tidsstempling og notarisering.

Fortrolighed er et relativt nemt problem at løse, ved at kryptere information, før den indlejres i en transaktion. Dekrypteringsnøglen for hvert stykke data deles kun med de deltagere, der er beregnet til at se det. Nøglelevering kan udføres på kæden ved hjælp af asymmetrisk kryptografi (som beskrevet her) eller via en eller anden off-chain mekanisme, som det foretrækkes. Enhver node, der mangler nøglen til at dekryptere et element, vil ikke se andet end binært volapyk.

Skalerbarhed er på den anden side en mere væsentlig udfordring. Lad os sige, at enhver anstændig blockchain-platform skal understøtte en netværksgennemstrømning på 500 transaktioner i sekundet. Hvis formålet med kæden er informationslagring, så vil størrelsen af hver transaktion primært afhænge af, hvor meget data den indeholder. Hver transaktion vil også have brug for (mindst) 100 bytes overhead til at gemme afsenderens adresse, digitale signatur og et par andre bits og stykker.

Hvis vi tager et let tilfælde, hvor hvert element er en lille JSON-struktur på 100 bytes, ville den samlede datagennemstrømning være 100 kilobyte pr. sekund, beregnet ud fra 500 × (100+100). Dette svarer til under 1 megabit/sekund båndbredde, hvilket er komfortabelt inden for kapaciteten af enhver moderne internetforbindelse. Data ville akkumuleres med en hastighed på omkring 3 terabyte om året, hvilket ikke er en lille mængde. Men med 12 terabyte harddiske nu til at få fat på overaltog RAID controllere, der kombinerer flere fysiske drev til et enkelt logisk, kunne vi nemt lagre 10-20 års data på hver node uden for meget besvær eller udgifter.

Men tingene ser meget anderledes ud, hvis vi gemmer større stykker information, såsom scannet dokumentation. En JPEG-scanning af rimelig kvalitet af et A4-ark kan være 500 kilobyte stor. Gang dette med 500 transaktioner i sekundet, og vi ser på en gennemstrømning på 250 megabyte i sekundet. Dette svarer til 2 gigabit/sekund båndbredde, hvilket er hurtigere end de fleste lokale netværk, endsige forbindelser til internettet. Hos Amazon Web Services' billigste offentliggjort pris på $0.05 pr. gigabyte, betyder det en årlig båndbredderegning på $400,000 pr. node. Og hvor vil hver node gemme de 8000 terabyte nye data, der genereres årligt?

Det er klart, at for blockchain-applikationer, der lagrer mange store stykker data, er ligetil on-chain storage ikke et praktisk valg. For at føje spot til skade, hvis data er krypteret for at løse problemet med fortrolighed, bliver noder bedt om at gemme en enorm mængde information, som de ikke engang kan læse. Dette er ikke et attraktivt forslag for netværkets deltagere.

Hashing-løsningen

Så hvordan løser vi problemet med dataskalerbarhed? Hvordan kan vi drage fordel af blockchains decentraliserede notarisering af data uden at replikere disse data til hver node i kæden?

Svaret er med et smart stykke teknologi kaldet en "hash". En hash er et langt tal (tænk 256 bit, eller omkring 80 decimale cifre), som entydigt identificerer et stykke data. Hash-værdien beregnes ud fra dataene ved hjælp af en envejs funktion som har en vigtig kryptografisk egenskab: Givet ethvert stykke data, er det nemt og hurtigt at beregne dens hash. Men givet en bestemt hash, er det beregningsmæssigt umuligt at finde et stykke data, der ville generere denne hash. Og når vi siger "beregningsmæssigt umuligt", mener vi flere beregninger, end der er atomer i det kendte univers.

Hashes spiller en afgørende rolle i alle blockchains ved unikt at identificere transaktioner og blokke. De ligger også til grund for den beregningsmæssige udfordring i proof-of-work-systemer som bitcoin. Mange forskellige hash-funktioner er blevet udviklet med gobbledygook-navne som BLAKE2, MD5 og RIPEMD160. Men for at enhver hashfunktion kan være tillid til, skal den tåle omfattende akademisk gennemgang og test. Disse tests kommer i form af forsøg på angreb, såsom "preimage" (finde et input med den givne hash), "second preimage" (finde et andet input med samme hash som det givne input) og "collision" (finde evt. to forskellige input med samme hash). At overleve denne kappe er langt fra let, med en lang og tragisk historie med ødelagte hash-funktioner, der beviser den berømte maksime: "Rul ikke din egen krypto."

For at gå tilbage til vores oprindelige problem, kan vi løse dataskalerbarhed i blockchains ved at indlejre hashen af store stykker data i transaktioner i stedet for selve dataene. Hver hash fungerer som en "forpligtelse" til dens inputdata, hvor selve dataene gemmes uden for blockchain eller "off-chain". For eksempel, ved at bruge den populære SHA256 hash-funktion, kan et 500 kilobyte JPEG-billede repræsenteres af et 32-byte tal, en reduktion på over 15,000×. Selv med en hastighed på 500 billeder i sekundet bringer dette os komfortabelt tilbage på området med mulige båndbredde- og lagerkrav, hvad angår de data, der er lagret i selve kæden.

Selvfølgelig kan enhver blockchain-deltager, der har brug for et off-chain-billede, ikke gengive det fra sin hash. Men hvis billedet kan hentes på en anden måde, tjener kædens hash til at bekræfte, hvem der har oprettet det og hvornår. Ligesom almindelige on-chain-data er hashen indlejret i en digitalt signeret transaktion, som blev inkluderet i kæden ved konsensus. Hvis en billedfil falder ud af himlen, og hashen for det billede matcher en hash i blockchainen, så bekræftes oprindelsen og tidsstemplet for det billede. Så blockchain giver nøjagtig den samme værdi med hensyn til notarisering, som hvis billedet var indlejret i kæden direkte.

Et spørgsmål om levering

Så langt så godt. Ved at indlejre hashes i en blockchain i stedet for de originale data, har vi en nem løsning på problemet med skalerbarhed. Ikke desto mindre er der et afgørende spørgsmål tilbage:

Hvordan leverer vi det originale off-chain-indhold til de noder, der har brug for det, hvis ikke gennem selve kæden?

Dette spørgsmål har flere mulige svar, og vi kender til MultiChain-brugere, der anvender dem alle. En grundlæggende tilgang er at oprette et centraliseret lager hos en betroet part, hvor alle off-chain-data uploades og derefter hentes. Dette system kunne naturligvis bruge "indholdsadressering", hvilket betyder, at hashen af hvert stykke data tjener direkte som dets identifikator til hentning. Men selvom denne opsætning måske fungerer som et proof-of-concept, giver det ikke mening for produktion, fordi hele pointen med en blockchain er at fjerne betroede mellemmænd. Selvom on-chain hashes forhindrer mellemmanden i at forfalske data, kan den stadig slette data eller undlade at levere dem til nogle deltagere på grund af en teknisk fejl eller handlinger fra en useriøs medarbejder.

En mere lovende mulighed er punkt-til-punkt-kommunikation, hvor den node, der kræver nogle off-chain-data, anmoder om det direkte fra den node, der udgav dem. Dette undgår at stole på en betroet mellemmand, men lider af tre alternative mangler:

Det kræver et kort over blockchain-adresser til IP-adresser, for at gøre det muligt for forbrugeren af nogle data at kommunikere direkte med sin udgiver. Blockchains kan generelt undgå denne type statisk netværkskonfiguration, hvilket kan være et problem i forhold til failover og privatliv.
Hvis den oprindelige udgivernode har forladt netværket, eller er midlertidigt ude af drift, kan dataene ikke hentes af andre.
Hvis et stort antal noder er interesseret i nogle data, vil udgiveren blive overvældet af anmodninger. Dette kan skabe alvorlig overbelastning af netværket, bremse udgiverens system ned og føre til lange forsinkelser for dem, der forsøger at hente disse data.

For at undgå disse problemer ville vi ideelt set bruge en form for decentral leveringsmekanisme. Noder bør være i stand til at hente de data, de har brug for, uden at være afhængige af noget individuelt system – det være sig et centraliseret lager eller dataens oprindelige udgiver. Hvis flere parter har et stykke data, bør de dele byrden med at levere det til alle andre, der ønsker det. Ingen behøver at stole på en individuel datakilde, fordi hash i kæden kan bevise, at der ikke er blevet manipuleret med data. Hvis en ondsindet node leverer mig de forkerte data til en hash, kan jeg simpelthen kassere disse data og prøve at spørge en anden.

Til dem der har erfaring med peer-to-peer fildeling protokoller som Napster, Gnutella eller BitTorrent, vil det hele lyde meget bekendt. Faktisk er mange af de grundlæggende principper de samme, men der er to vigtige forskelle. For det første, forudsat at vi bruger vores blockchain i en virksomhedskontekst, kører systemet inden for en lukket gruppe af deltagere, snarere end internettet som helhed. For det andet tilføjer blockchain en decentraliseret bestilling, tidsstempling og notariseringsrygrad, der gør det muligt for alle brugere at opretholde et beviseligt konsistent og manipulationssikkert overblik over præcis, hvad der skete, hvornår og af hvem.

Hvordan kan en blockchain-applikationsudvikler opnå denne decentraliserede levering af off-chain indhold? Et almindeligt valg er at tage en eksisterende peer-to-peer fildelingsplatform, såsom den underholdende navngivne InterPlanetary filsystem (IPFS), og brug det sammen med blockchain. Hver deltager kører både en blockchain-knude og en IPFS-knude, med noget middleware, der koordinerer mellem de to. Når du udgiver off-chain data, gemmer denne middleware de originale data i IPFS og opretter derefter en blockchain-transaktion, der indeholder disse datas hash. For at hente nogle off-chain data udtrækker middlewaren hashen fra blockchain og bruger derefter denne hash til at hente indholdet fra IPFS. Den lokale IPFS-node verificerer automatisk det hentede indhold mod hashen for at sikre, at det ikke er blevet ændret.

Selvom denne løsning er mulig, er det hele ret klodset og ubelejligt. For det første skal hver deltager installere, vedligeholde og opdatere tre separate stykker software (blockchain node, IPFS node og middleware), som hver lagrer sine data på et separat sted. For det andet vil der være to separate peer-to-peer-netværk, hver med sin egen konfiguration, netværksporte, identitetssystem og tilladelser (selvom det skal bemærkes, at IPFS endnu ikke understøtter lukkede netværk). Endelig vil en tæt kobling af IPFS og blockchain sammen gøre middlewaren stadig mere kompleks. For eksempel, hvis vi ønsker, at de off-chain-data, der refereres til af nogle blockchain-transaktioner, skal hentes øjeblikkeligt (med automatiske genforsøg), skal middlewaren konstant være oppe og køre og bevare sin egen komplekse tilstand. Ville det ikke være rart, hvis blockchain-knuden gjorde alt dette for os?

Off-chain data i MultiChain 2.0

I dag er vi glade for at frigive tredje preview-version (alfa 3) af MultiChain 2.0, med en fuldt integreret og sømløs løsning til off-chain data. Hvert stykke information, der offentliggøres til en stream, kan være on-chain eller off-chain efter ønske, og MultiChain tager sig af alt andet.

Nej virkelig, mener vi at alt. Som udvikler, der bygger på MultiChain, behøver du ikke bekymre dig om hashes, lokal lagring, indholdsopdagelse, decentral levering eller databekræftelse. Her er hvad der sker bag kulisserne:

Den publicerende MultiChain-knude skriver de nye data i sit lokale lager og skærer store emner i bidder for nem fordøjelse og levering.
Transaktionen for udgivelse af off-chain stream-elementer bygges automatisk og indeholder chunk-hash(erne) og størrelse(r) i bytes.
Denne transaktion signeres og udsendes til netværket, forplanter sig mellem noder og går ind i blockchain på den sædvanlige måde.
Når en node, der abonnerer på en stream, ser en reference til nogle off-chain-data, tilføjer den chunk-hasherne for disse data til sin genfindingskø. (Når du abonnerer på en gammel stream, sætter en node også alle tidligere offentliggjorte artikler uden for kæden i kø til hentning.)
Som en baggrundsproces, hvis der er bidder i en nodes hentningskø, sendes forespørgsler ud til netværket for at lokalisere disse bidder, som identificeret af deres hashes.
Disse chunk-forespørgsler spredes til andre noder i netværket på en peer-to-peer-måde (begrænset til to hop indtil videre - se tekniske detaljer nedenfor).
Enhver knude, som har dataene for en chunk, kan svare, og dette svar videresendes til abonnenten tilbage ad samme vej som forespørgslen.
Hvis ingen node besvarer chunk-forespørgslen, returneres chunken tilbage til køen for senere at prøve igen.
Ellers vælger abonnenten den mest lovende kilde for en chunk (baseret på hop og responstid), og sender den en anmodning om den chunks data, igen langs den samme peer-to-peer-sti som det forrige svar.
Kildeknuden leverer de anmodede data ved at bruge den samme sti igen.
Abonnenten verificerer datastørrelsen og hash i forhold til den oprindelige anmodning.
Hvis alt tjekker ud, skriver abonnenten dataene til sit lokale lager, hvilket gør det umiddelbart tilgængeligt til hentning via stream-API'erne.
Hvis det ønskede indhold ikke ankom, eller ikke matchede den ønskede hash eller størrelse, returneres chunken tilbage til køen for fremtidig hentning fra en anden kilde.

Vigtigst af alt sker alt dette ekstremt hurtigt. I netværk med lav latenstid vil små stykker off-chain data ankomme til abonnenter inden for et splitsekund efter den transaktion, der refererer til dem. Og til højbelastningsapplikationer viser vores test, at MultiChain 2.0 alpha 3 kan opretholde en hastighed på over 1000 off-chain-elementer eller 25 MB off-chain-data hentet pr. sekund på en mellemklasseserver (Core i7) med en anstændig Internetforbindelse. Alt fungerer fint med varer uden for kæden op til 1 GB i størrelse, langt ud over grænsen på 64 MB for on-chain data. Vi håber selvfølgelig at forbedre disse tal yderligere, efterhånden som vi bruger tid på at optimere MultiChain 2.0 i betafasen.

Når du bruger off-chain i stedet for on-chain data i streams, skal MultiChain applikationsudviklere gøre præcis to ting:

Når du udgiver data, skal du videregive et "offchain"-flag til de relevante API'er.
Når du bruger strømforespørgsels-API'er, skal du overveje muligheden for, at nogle off-chain-data muligvis endnu ikke er tilgængelige, som rapporteret af "tilgængelig"-flaget. Selvom denne situation vil være sjælden under normale omstændigheder, er det vigtigt for applikationsudviklere at håndtere det korrekt.

For selvfølgelig at forhindre, at hver node henter alle varer uden for kæden, bør varer grupperes sammen i strømme på en passende måde, hvor hver node abonnerer på disse interessestrømme.

On-chain og off-chain elementer kan bruges inden for den samme stream, og de forskellige stream-forespørgsels- og opsummeringsfunktioner relaterer til begge typer data identisk. Dette giver udgivere mulighed for at træffe det passende valg for hvert element i en strøm uden at påvirke resten af en applikation. For eksempel kan en strøm af JSON-elementer om folks aktiviteter bruge off-chain-data til personligt identificerende oplysninger og on-chain-data for resten. Abonnenter kan bruge MultiChains JSON-fusion til at kombinere begge typer information til en enkelt JSON til læsning.

Hvis du vil give off-chain stream-varer en chance, skal du bare følge MultiChains almindelige Kom godt i gang tutorial, og sørg for ikke at springe afsnit 5 over.

Så hvad er det næste?

Med problemfri understøttelse af off-chain-data vil MultiChain 2.0 tilbyde et stort skridt fremad for blockchain-applikationer med fokus på storskala datatidsstempling og notarisering. På længere sigt tænker vi allerede på et væld af mulige fremtidige forbedringer af denne funktion til Community- og/eller Enterprise-udgaverne af MultiChain:

Implementering af strøm læse tilladelser ved hjælp af en kombination af varer uden for kæden, saltede hashes, signerede chunk-forespørgsler og krypteret levering.
Tillader eksplicit at "glemme" data uden for kæden, både frivilligt af individuelle noder eller af alle noder som svar på en on-chain besked.
Selektive stream-abonnementer, hvor noder kun henter data for varer uden for kæden med bestemte udgivere eller nøgler.
Ved brug af merkle træer at gøre det muligt for en enkelt on-chain hash at repræsentere et ubegrænset antal off-chain elementer, hvilket giver endnu et stort spring med hensyn til skalerbarhed.
Pluggbare lagringsmotorer, der gør det muligt at opbevare data uden for kæden i databaser eller eksterne filsystemer i stedet for lokal disk.
Noder lærer over tid, hvor hver type off-chain-data normalt er tilgængelig i et netværk, og fokuserer deres chunk-forespørgsler korrekt.

Det ville vi gerne hør din feedback på listen ovenfor samt varer uden for kæden generelt. Med MultiChain 2.0 stadig officielt i alfa, er der masser af tid til at forbedre denne funktion før dens endelige udgivelse.

I mellemtiden har vi allerede påbegyndt arbejdet med "Smart Filters", den sidste store funktion, der er planlagt til MultiChain 2.0 Community. Et smart filter er et stykke kode, der er indlejret i blockchain, som implementerer tilpassede regler for validering af data eller transaktioner. Smarte filtre har nogle ligheder med "smarte kontrakter", og kan mange af de samme ting, men har væsentlige forskelle med hensyn til sikkerhed og ydeevne. Vi glæder os til at fortælle dig mere til sin tid.

Skriv eventuelle kommentarer på LinkedIn.

Tekniske detaljer

Mens off-chain stream elementer i MultiChain 2.0 er enkle at bruge, indeholder de mange designbeslutninger og yderligere funktioner, der kan være af interesse. Listen nedenfor vil primært være relevant for udviklere, der bygger blockchain-applikationer, og kan springes over af mindre tekniske typer:

Per-stream politikker. Når en MultiChain-stream oprettes, kan den valgfrit begrænses til kun at tillade on-chain eller off-chain data. Der er flere mulige årsager til at gøre dette, i stedet for at lade hver enkelt udgiver bestemme selv. For eksempel tilbyder on-chain-varer en jernbeklædt tilgængelighedsgaranti, hvorimod gamle off-chain-varer kan blive uigenkaldelige, hvis deres udgiver og andre abonnenter dropper netværket. På bagsiden kan varer i kæden ikke "glemmes" uden at ændre blockchainen, mens varer uden for kæden er mere fleksible. Dette kan være vigtigt i forhold til databeskyttelsesregler, såsom Europas nye GDPR-regler.
On-chain metadata. For varer uden for kæden, indeholder on-chain-transaktionen stadig varens udgiver(e), nøgle(r), format (JSON, tekst eller binær) og samlede størrelse. Alt dette fylder meget lidt og hjælper applikationsudviklere med at afgøre, om utilgængeligheden af et element uden for kæden er af betydning for en bestemt stream-forespørgsel.
To-hop grænse. Når du videresender chunk-forespørgsler på tværs af peer-to-peer-netværket, er der en afvejning mellem tilgængelighed og ydeevne. Selvom det ville være rart for hver forespørgsel at blive spredt langs hver enkelt vej, kan dette tilstoppe netværket med unødvendig "snak". Så foreløbig er chunk-forespørgsler begrænset til to hop, hvilket betyder, at en node kan hente off-chain-data fra enhver peer af sine peers. I de mindre netværk på under 1000 noder, der har tendens til at karakterisere enterprise blockchains, tror vi, at dette vil fungere fint, men det er nemt for os at justere denne begrænsning (eller tilbyde det som en parameter), hvis vi viser sig at tage fejl.
Lokal opbevaring. Hver MultiChain-node gemmer off-chain-data i "chunks"-mappen i dens almindelige blockchain-mappe ved hjælp af et effektivt binært format og LevelDB-indeks. En separat undermappe bruges til elementerne i hver af de abonnerede streams, såvel som dem, der udgives af selve noden. Inden for hver af disse undermapper gemmes duplikerede bidder (med samme hash) kun én gang. Når en node afmelder sig fra en strøm, kan den vælge, om den skal slette de off-chain-data, der er hentet for den strøm.
Binær cache. Når du udgiver store stykker binære data, uanset om det er on-chain eller off-chain, er det muligvis ikke praktisk for applikationsudviklere at sende disse data til MultiChain's API i en enkelt JSON-RPC-anmodning. Så MultiChain 2.0 implementerer en binær cache, som gør det muligt at bygge store stykker data op over flere API-kald og derefter publiceres i et kort sidste trin. Hvert element i den binære cache er gemt som en simpel fil i "cache"-undermappen i blockchain-biblioteket, hvilket tillader, at gigabyte data også kan skubbes direkte via filsystemet.
Overvågning af API'er. MultiChain 2.0 alpha 3 tilføjer to nye API'er til overvågning af asynkron hentning af off-chain data. Den første API beskriver køens aktuelle tilstand og viser, hvor mange bidder (og hvor mange data), der venter eller bliver forespurgt eller hentet. Den anden API giver aggregerede statistikker for alle chunk-forespørgsler og -anmodninger sendt siden noden startede op, inklusive tællinger af forskellige typer fejl.
Skyl ved udgivelse. Når du publicerer en vare uden for kæden, sikrer MultiChain, at dens lokale kopi af dataene er fuldstændig skrevet (eller "skyllet") til det fysiske diskdrev, før transaktionen, der refererer til, at data udsendes til netværket. Ellers, hvis noden var uheldig nok til at miste strøm umiddelbart efter udsendelse af transaktionen, kunne off-chain-data gå tabt permanent. Dette er ikke et problem for MultiChain selv, da forsinkelserne mellem en chunks hentningsforsøg vokser automatisk over tid. Men det kan forårsage problemer på applikationsniveau, hvor alle kender til eksistensen af nogle data, men ingen er i stand til at finde dem.
Udgivelsesydelse. Ved at skylle off-chain data til disken på denne måde, kan MultiChain pådrage sig en ydeevnestraf, da fysiske diske er langsomme. For eksempel kan en mellemklasse 7200 rpm harddisk kun udføre omkring 100 tilfældige dataskrivninger i sekundet, hvilket igen begrænser den hastighed, hvormed en individuel node kan publicere off-chain elementer. Der er tre mulige løsninger på dette problem. For det første og mest enkelt kan noder bruge et solid state device (SSD)-drev i stedet for en almindelig harddisk, som understøtter 10,000vis af tilfældige skriveoperationer pr. sekund. For det andet kan flere off-chain-elementer publiceres i en enkelt transaktion ved hjælp af "createrawsendfrom" API. I dette tilfælde skriver MultiChain alle off-chain data, der refereres til af en transaktion i en enkelt disk operation. Endelig kan MultiChain konfigureres til ikke at skylle off-chain data til disken, før den udsendes transaktionen, der refererer til den. Brug denne mulighed med omhu.
Indfødt valutaintegration. For brugssager, der kræver det, har MultiChain altid tilbudt muligheden for at bruge en indfødt valuta på en blockchain for at forhindre transaktionsspam og/eller tilskynde blokvalidatorer ("minere"). I disse tilfælde skal transaktioner tilbyde minearbejdere et minimumsgebyr, der er proportionalt med deres størrelse i bytes, for at blive videregivet og bekræftet i kæden. Denne mekanisme er blevet udvidet for at gøre det muligt at forhindre spam uden for kæden ved at kræve et minimumsgebyr pr. kilobyte af data uden for kæden, der refereres til i en transaktion.
Arkivknudepunkter. Hvis en node ønsker at abonnere på hver stream og derfor hente og gemme alle off-chain-elementer, der er offentliggjort, kan den konfigureres til at gøre det ved at bruge "autosubscribe" runtime-parameteren. Enhver sådan node vil fungere som backup for hele netværket, hvilket garanterer, at varer uden for kæden ikke vil gå tabt eller utilgængelige, uanset hvilke andre noder der forsvinder. Man kan forestille sig tredjepartsvirksomheder, der tilbyder dette som en kommerciel service.