Scaling Blockchains With Off-chain Data

Återutgiven av Platon

anhängare: 0

När en hash är värd en miljon ord

Just nu är det uppenbart att många fall av blockchain-användning inte har något att göra med finansiella transaktioner. Istället är kedjans syfte att möjliggöra en decentraliserad aggregering, beställning, tidsstämpling och arkivering av vilken som helst typ av information, inklusive strukturerad data, korrespondens eller dokumentation. Blockchains kärnvärde gör det möjligt för sina deltagare att på ett bevisligt och permanent sätt komma överens om exakt vilken information som lagts in, när och av vem, utan att förlita sig på en betrodd mellanhand. Till exempel har SAP nyligen lanserats blockchain-plattform, som stöder MultiChain och Hyperledger Fabric, riktar sig till ett brett sortiment av leveranskedjor och andra icke-finansiella applikationer.

Det enklaste sättet att använda en blockchain för att spela in data är att bädda in varje databit direkt i en transaktion. Varje blockchain-transaktion undertecknas digitalt av en eller flera parter, replikeras till varje nod, beställs och tidsstämmas av kedjans konsensusalgoritm och lagras permanent på ett manipuleringssäkert sätt. All information inom transaktionen kommer därför att lagras identiskt men oberoende av varje nod, tillsammans med ett bevis på vem som skrev den och när. Kedjans användare kan hämta denna information när som helst.

Till exempel tillät MultiChain 1.0 att en eller flera namngivna “strömmar” skapades på en blockchain och sedan användas för att lagra och hämta rå data. Varje ström har sin egen uppsättning skrivrättigheter, och varje nod kan fritt välja vilka strömmar att prenumerera på. Om en nod prenumereras på en ström, indexeras den strömmens innehåll i realtid, vilket gör att artiklar snabbt kan hämtas baserat på deras beställning, tidsstämpel, blocknummer eller utgivaradress samt via en "nyckel" (eller etikett) med vilka objekt kan taggas. MultiChain 2.0 (sedan alfa 1) utökade strömmar för att stödja Unicode-text eller JSON-data, såväl som flera tangenter per artikel och flera objekt per transaktion. Den har också lagt till sammanfattningsfunktioner som ”JSON-sammanslagning” som kombinerar objekt med samma nyckel eller utgivare på ett användbart sätt.

Sekretess och skalbarhet

Medan lagring av data direkt på en blockchain fungerar bra, lider det av två viktiga brister - sekretess och skalbarhet. Till att börja med konfidentialitet är innehållet i varje strömobjekt synligt för varje nod i kedjan, och detta är inte nödvändigtvis ett önskvärt resultat. I många fall borde en del data endast vara synlig för en viss deluppsättning av noder, även om andra noder behövs för att hjälpa till med dess beställning, tidsstämpel och notarisering.

Sekretess är ett relativt enkelt problem att lösa genom att kryptera information innan den är inbäddad i en transaktion. Avkrypteringsnyckeln för varje data delas bara med de deltagare som är tänkta att se den. Nyckelleverans kan utföras på kedjan med hjälp av asymmetrisk kryptografi (som beskrivs här) eller via någon mekanism utanför kedjan, som föredras. Varje nod som saknar nyckeln till att dekryptera ett objekt ser inget annat än binärt gibberish.

Skalbarhet är å andra sidan en mer betydande utmaning. Låt oss säga att alla anständiga blockchain-plattformar bör stödja en nätverksström på 500 transaktioner per sekund. Om syftet med kedjan är informationslagring beror storleken på varje transaktion främst på hur mycket data den innehåller. Varje transaktion behöver också (minst) 100 byte omkostnader för att lagra avsändarens adress, digital signatur och några andra bitar och bitar.

Om vi tar ett enkelt fall, där varje artikel är en liten JSON-struktur på 100 byte, skulle den totala datamängden vara 100 kilobyte per sekund, beräknad från 500 × (100 + 100). Detta innebär mindre än 1 megabit / sekund av bandbredd, vilket är bekvämt inom alla moderna internetanslutningar. Data skulle samlas med en hastighet av cirka 3 terabyte per år, vilket inte är en liten mängd. Men med 12 terabyte hårddiskar nu allmänt tillgängligoch RAID styrenheter som kombinerar flera fysiska enheter till en enda logisk enhet, vi kan enkelt lagra 10-20 års data på varje nod utan för mycket krångel eller kostnad.

Men saker ser mycket annorlunda ut om vi lagrar större information, till exempel skannad dokumentation. En JPEG-skanning av rimlig kvalitet på ett A4-pappersark kan vara 500 kilobyte i storlek. Multiplicera detta med 500 transaktioner per sekund, och vi tittar på en produktion på 250 megabyte per sekund. Detta innebär två gigabit / sekund av bandbredd, vilket är snabbare än de flesta lokala nätverk, än mindre anslutningar till Internet. På Amazon Web Services billigaste publicerat pris på 0.05 $ per gigabyte, betyder det en årlig bandbreddskostnad på $ 400,000 8000 per nod. Och var kommer varje nod att lagra XNUMX terabyte ny data som genereras årligen?

Det är tydligt att för blockchain-applikationer som lagrar många stora datamängder är enkel lagring i kedjan inte ett praktiskt val. För att ge förolämpning mot skada, om data är krypterade för att lösa problemet med konfidentialitet, ombeds noder att lagra en enorm mängd information som de inte ens kan läsa. Detta är inte ett attraktivt förslag för nätverkets deltagare.

Hasningslösningen

Så hur löser vi problemet med skalbarhet? Hur kan vi dra fördel av blockchains decentraliserade notarisering av data utan att replikera dessa data till varje nod i kedjan?

Svaret är med en smart teknik som kallas ”hash”. En hash är ett långt tal (tänk 256 bitar, eller cirka 80 decimaler) som identifierar en datamängd unikt. Hash beräknas utifrån data med hjälp av a envägsfunktion som har en viktig kryptografisk egenskap: Med tanke på vilken information som helst är det enkelt och snabbt att beräkna dess hash. Men med tanke på en viss hash är det beräkningsmässigt omöjligt att hitta en bit data som skulle generera denna hash. Och när vi säger "beräkningsmässigt omöjligt", menar vi fler beräkningar än det finns atomer i det kända universum.

Hashes spelar en avgörande roll i alla blockchains genom att identifiera transaktioner och block på ett unikt sätt. De ligger också bakom den beräknade utmaningen i proof-of-work-system som bitcoin. Många olika hash-funktioner har utvecklats, med gobbledygook-namn som BLAKE2, MD5 och RIPEMD160. Men för att någon hashfunktion ska kunna lita på måste den tåla omfattande akademisk granskning och testning. Dessa tester kommer i form av attacker försök, till exempel "preimage" (hitta en insats med den givna hashen), "second preimage" (hitta en andra input med samma hash som den givna inputen) och "kollision" (hitta någon två olika ingångar med samma hash). Att överleva denna klänning är långt ifrån lätt, med en lång och tragisk historia med trasiga hashfunktioner som bevisar den berömda maximalen: "Rulla inte din egen krypto."

För att gå tillbaka till vårt ursprungliga problem, kan vi lösa dataskalbarhet i blockchains genom att bädda in hasherna för stora datamängder i transaktioner, istället för själva uppgifterna. Varje hash fungerar som ett ”åtagande” till sina inmatningsdata, där själva uppgifterna lagras utanför blockchainen eller ”off-chain”. Till exempel, med den populära SHA256-hashfunktionen, kan en 500 kilobyte JPEG-bild representeras av ett 32-byte-tal, en reduktion på över 15,000 500 ×. Även med en hastighet av XNUMX bilder per sekund sätter detta oss bekvämt tillbaka i territoriet med möjlig bandbredd och lagringsbehov, vad gäller data lagrade i själva kedjan.

Naturligtvis kan alla blockchain-deltagare som behöver en bild utanför kedjan reproducera den från sin hash. Men om bilden kan hämtas på något annat sätt tjänar hash-kedjan för att bekräfta vem som skapade den och när. Precis som vanliga data på kedjan är hash inbäddat i en digitalt signerad transaktion, som ingick i kedjan av konsensus. Om en bildfil faller ut ur himlen, och hash för den bilden matchar en hash i blockchain, bekräftas bildens ursprung och tidsstämpel. Så blockchain ger exakt samma värde när det gäller notarisering som om bilden inbäddades direkt i kedjan.

En fråga om leverans

Än så länge är allt bra. Genom att bädda in hascher i en blockchain istället för originaldata har vi en enkel lösning på problemet med skalbarhet. Ändå återstår en avgörande fråga:

Hur levererar vi det ursprungliga innehållet utanför kedjan till de noder som behöver det, om inte genom själva kedjan?

Denna fråga har flera möjliga svar, och vi känner till MultiChain-användare som använder dem alla. Ett grundläggande tillvägagångssätt är att inrätta ett centraliserat arkiv vid någon betrodd part, där all off-chain data laddas upp och därefter hämtas. Detta system kan naturligtvis använda "innehållsadressering", vilket innebär att hashen för varje databitar fungerar direkt som dess identifierare för hämtning. Men medan denna inställning kan fungera för ett bevis-av-koncept, är det inte meningsfullt för produktion, eftersom hela poängen med en blockchain är att ta bort betrodda mellanhänder. Även om hash på nätet förhindrar att mellanhanden förfalskar data, kan det fortfarande ta bort data eller misslyckas med att leverera dem till vissa deltagare, på grund av ett tekniskt fel eller handlingar från en skurk anställd.

En mer lovande möjlighet är punkt-till-punkt-kommunikation, där den nod som kräver vissa data utanför kedjan begär det direkt från noden som publicerade den. Detta undviker att förlita sig på en betrodd mellanhand, men lider av tre alternativa brister:

Det kräver en karta över blockchain-adresser till IP-adresser för att göra det möjligt för konsumenten av vissa data att kommunicera direkt med sin utgivare. Blockchains kan i allmänhet undvika denna typ av statisk nätverkskonfiguration, vilket kan vara ett problem när det gäller failover och integritet.
Om den ursprungliga utgivarnoden har lämnat nätverket eller tillfälligt är ur drift kan data inte hämtas av någon annan.
Om ett stort antal noder är intresserade av vissa data, kommer utgivaren att bli överväldigad av förfrågningar. Detta kan skapa allvarlig nätstockning, bromsa utgivarens system och leda till långa förseningar för dem som försöker hämta den informationen.

För att undvika dessa problem skulle vi helst använda någon form av decentraliserad leveransmekanism. Noder ska kunna hämta de data de behöver utan att förlita sig på något enskilt system - vare sig det är ett centraliserat arkiv eller dataens ursprungliga utgivare. Om flera parter har en datainformation, bör de dela bördan med att leverera den till någon annan som vill ha den. Ingen behöver lita på en enskild datakälla, eftersom hash på nätet kan bevisa att data inte har manipulerats. Om en skadlig nod levererar fel data för en hash kan jag helt enkelt kassera den informationen och försöka fråga någon annan.

För dig som har erfarenhet av peer-to-peer-fildelning protokoll som Napster, Gnutella eller BitTorrent, detta låter allt mycket bekant. Faktum är att många av de grundläggande principerna är desamma, men det finns två viktiga skillnader. Först, förutsatt att vi använder vår blockchain i ett företagssammanhang, körs systemet inom en sluten grupp deltagare, snarare än Internet som helhet. För det andra lägger blockchain till en decentraliserad beställning, tidsstämpling och notariseringskelett, vilket gör det möjligt för alla användare att upprätthålla en provbart konsekvent och manipuleringsbeständig bild av exakt vad som hände, när och av vem.

Hur kan en blockchain-applikationsutvecklare uppnå denna decentraliserade leverans av innehåll utanför kedjan? Ett vanligt val är att ta en befintlig peer-to-peer fildelningsplattform, till exempel den underhållande namngivna InterPlanetärt filsystem (IPFS), och använd den tillsammans med blockchain. Varje deltagare kör både en blockchain-nod och en IPFS-nod, med viss mellanprogramvara mellan de två. När du publicerar data utanför kedjan lagrar denna mellanprogramvara originaldata i IPFS och skapar sedan en blockchain-transaktion som innehåller datahasjen. För att hämta data utanför kedjan extraherar mellanprogrammet hash från blockchain och använder sedan denna hash för att hämta innehållet från IPFS. Den lokala IPFS-noden verifierar automatiskt det hämtade innehållet mot hash för att säkerställa att det inte har ändrats.

Även om denna lösning är möjlig är det allt ganska klumpigt och obekvämt. Först måste varje deltagare installera, underhålla och uppdatera tre separata programvarudelar (blockchain-nod, IPFS-nod och mellanprogram), som var och en lagrar sina data på en separat plats. För det andra kommer det att finnas två separata peer-to-peer-nätverk, var och en med sin egen konfiguration, nätverksportar, identitetssystem och tillstånd (även om det bör noteras att IPFS ännu inte stöder stängda nätverk). Slutligen skulle tätt koppling av IPFS och blockchainen göra mellanvaran alltmer komplex. Om vi till exempel vill att data utanför kedjan som hänvisas till av några blockchain-transaktioner omedelbart ska hämtas (med automatiska försök på nytt), skulle mellanprogrammet behöva vara igång kontinuerligt och behålla sitt eget komplexa tillstånd. Skulle det inte vara trevligt om blockchain-noden gjorde allt detta för oss?

Off-chain data i MultiChain 2.0

Idag är vi glada över att släppa tredje förhandsvisningsversionen (alfa 3) av MultiChain 2.0, med en helt integrerad och sömlös lösning för data utanför kedjan. Varje information som publiceras i en ström kan vara on-chain eller off-chain efter önskemål, och MultiChain tar hand om allt annat.

Nej, egentligen menar vi allt. Som utvecklare som bygger på MultiChain behöver du inte oroa dig för hash, lokal lagring, upptäckt av innehåll, decentraliserad leverans eller dataregistrering. Här är vad som händer bakom kulisserna:

Den publicerande MultiChain-noden skriver de nya uppgifterna i sin lokala lagring och skär stora föremål i bitar för enkel matsmältning och leverans.
Transaktionen för publicering av strömföremål utanför kedjan byggs automatiskt, innehållande bunkens hash (er) och storlek (er) i byte.
Denna transaktion undertecknas och sänds till nätverket, sprider sig mellan noder och går in i blockchain på vanligt sätt.
När en nod som prenumererar på en ström ser en referens till vissa data utanför kedjan, lägger den till biten hash för den informationen i dess hämtningskö. (När du prenumererar på en gammal ström står en nod i kö för alla tidigare publicerade off-chain-objekt för hämtning.)
Som bakgrundsprocess, om det finns bitar i en nods hämtningskö, skickas frågor till nätverket för att lokalisera dessa bitar, som identifieras av deras hash.
Dessa delfrågor sprids till andra noder i nätverket på peer-to-peer-sätt (begränsat till två humle för tillfället - se tekniska detaljer nedan).
Varje nod som har data för en bit kan svara, och detta svar vidarebefordras till abonnenten tillbaka längs samma bana som frågan.
Om ingen nod svarar på frågan om chunkten, återgår biten tillbaka till kön för senare försök igen.
Annars väljer abonnenten den mest lovande källan för en bit (baserat på humle och responstid) och skickar den en begäran om den bitens data, igen längs samma peer-to-peer-bana som föregående svar.
Källnoden levererar de begärda uppgifterna med samma sökväg igen.
Abonnenten verifierar datans storlek och hash mot den ursprungliga begäran.
Om allt checkar ut, skriver abonnenten informationen till sin lokala lagring, vilket gör dem omedelbart tillgängliga för hämtning via stream-API: erna.
Om det begärda innehållet inte anlände, eller inte matchar önskad hash eller storlek, återförs stycket tillbaka till kön för framtida hämtning från en annan källa.

Det viktigaste är att allt detta händer extremt snabbt. I nätverk med låg latens kommer små bitar av off-chain data att ankomma abonnenter inom en del av sekundet av transaktionen som refererar till dem. Och för applikationer med hög belastning visar våra tester att MultiChain 2.0 alpha 3 kan upprätthålla en hastighet på över 1000 off-chain-artiklar eller 25 MB off-chain-data som hämtas per sekund, på en mellanliggande server (Core i7) med en anständig Internet anslutning. Allt fungerar bra med objekt utanför kedjan upp till 1 GB i storlek, långt över 64 MB-gränsen för kedjedata. Naturligtvis hoppas vi kunna förbättra dessa siffror ytterligare när vi spenderar tid på att optimera MultiChain 2.0 under betafasen.

När du använder off-chain snarare än on-chain data i strömmar måste MultiChain-applikationsutvecklare göra exakt två saker:

Vid publicering av data, skicka en "offchain" -flagga till lämpliga API: er.
När du använder API: er för strömfrågor, överväg möjligheten att vissa off-chain data kanske ännu inte är tillgängliga, som rapporterats av flaggan “tillgängligt”. Även om denna situation kommer att vara sällsynt under normala omständigheter, är det viktigt för applikationsutvecklare att hantera det på lämpligt sätt.

För att förhindra varje nod från att hämta varje off-chain objekt bör naturligtvis objekt grupperas i strömmar på ett lämpligt sätt, med varje nod som prenumererar på de intressanta strömmarna.

Objekt på kedja och utanför kedjan kan användas inom samma ström, och de olika strömfrågor och sammanfattningsfunktioner relaterar till båda typerna av data identiskt. Detta gör det möjligt för utgivare att göra rätt val för varje objekt i en ström utan att påverka resten av en applikation. Till exempel kan en ström av JSON-artiklar om människors aktiviteter använda off-chain-uppgifter för personligt identifierande information och on-chain-data för resten. Prenumeranter kan använda MultiChains JSON-sammanslagning för att kombinera båda typerna av information till en enda JSON för läsning.

Om du vill prova off-chain-strömförsök följer du bara MultiChains regelbundna Komma igång handledning, och se till att inte hoppa över avsnitt 5.

Så vad är nästa?

Med sömlöst stöd för data utanför kedjan, kommer MultiChain 2.0 att erbjuda ett stort steg framåt för blockchain-applikationer fokuserade på storskalig datatidsstämpling och notarisering. På längre sikt överväger vi redan massor av möjliga framtida förbättringar av denna funktion för gemenskaps- och / eller Enterprise-utgåvor av MultiChain:

Implementeringsström läsa behörigheter med hjälp av en kombination av objekt utan kedja, saltad hash, signerade chunkfrågor och krypterad leverans.
Tillåter att data utanför kedjan uttryckligen "glömts", både frivilligt av enskilda noder eller av alla noder som svar på ett meddelande på kedjan.
Selektiv strömabonnemang, där noder bara hämtar data för objekt utanför kedjan med särskilda utgivare eller nycklar.
Använda märle träd för att möjliggöra en enda hash-kedja för att representera ett obegränsat antal objekt utanför kedjan, vilket ger ytterligare ett stort hopp när det gäller skalbarhet.
Pluggbara lagringsmotorer som gör att data utanför kedjan kan förvaras i databaser eller externa filsystem snarare än lokal disk.
Noder lär sig över tid där varje typ av off-chain data vanligtvis finns tillgängligt i ett nätverk och fokuserar sina chunkfrågor på lämpligt sätt.

Vi skulle gärna vilja hör din feedback på listan ovan såväl som föremål utanför kedjan i allmänhet. Med MultiChain 2.0 fortfarande officiellt i alfa finns det gott om tid att förbättra den här funktionen innan den slutligen släpps.

Under tiden har vi redan börjat arbeta med "Smart Filters", den sista huvudfunktionen som planeras för MultiChain 2.0 Community. Ett smart filter är ett kodstycke som är inbäddat i blockchain som implementerar anpassade regler för validering av data eller transaktioner. Smarta filter har vissa likheter med ”smarta kontrakt” och kan göra många av samma saker, men har viktiga skillnader vad gäller säkerhet och prestanda. Vi ser fram emot att berätta mer i tid.

Skicka eventuella kommentarer på Link.

Tekniska detaljer

Även om objekt utanför kedjan i MultiChain 2.0 är enkla att använda, innehåller de många designbeslut och ytterligare funktioner som kan vara av intresse. Listan nedan är huvudsakligen relevant för utvecklare som bygger blockchain-applikationer och kan hoppas över av mindre tekniska typer:

Per-stream policyer. När en MultiChain-ström skapas kan den valfritt begränsas till att endast tillåta data från kedjan eller utanför kedjan. Det finns flera möjliga skäl för att göra detta, snarare än att låta varje utgivare bestämma själv. Exempelvis erbjuder artiklar på kedjan en garanti för tillgänglighet av järnklädnad, medan gamla off-chain-artiklar kan bli oåterkalleliga om deras utgivare och andra abonnenter släpper av nätverket. På baksidan kan objekt på kedjan inte "glömmas" utan att ändra blockchain, medan objekt utanför kedjan är mer flexibla. Detta kan vara viktigt när det gäller reglerna om integritetsskydd, till exempel Europas nya GDPR-förordningar.
Metadata på kedjan. För objekt utanför kedjan innehåller transaktionen på kedjan fortfarande artikelns utgivare, nycklar, format (JSON, text eller binär) och total storlek. Allt detta tar mycket lite utrymme och hjälper applikationsutvecklare att avgöra om en tillgänglighet av en post utanför kedjan är oroande för en viss strömfråga.
Två hop-gräns. När du vidarebefordrar chunkfrågor över peer-to-peer-nätverket finns det en avvägning mellan nåbarhet och prestanda. Även om det vore trevligt för varje fråga att spridas längs varje enskild väg, kan detta täppa till nätverket med onödig "skrav". Så nu är chunkfrågor begränsade till två humle, vilket innebär att en nod kan hämta data utanför kedjan från alla kamrater. I de mindre nätverk på under 1000 noder som tenderar att känneteckna företagets blockchains tror vi att detta fungerar bra, men det är lätt för oss att justera denna begränsning (eller erbjuda den som en parameter) om vi visar oss vara fel.
Lokalt utrymme. Varje MultiChain-nod lagrar data utanför kedjan i katalogen "bitar" i sin vanliga blockchain-katalog med ett effektivt binärt format och LevelDB-index. En separat underkatalog används för artiklarna i var och en av de prenumererade strömmarna, liksom de som publiceras av själva noden. Inom var och en av dessa underkataloger lagras dubbla bitar (med samma hash) bara en gång. När en nod avslutar abonnemanget från en ström kan den välja om den rensade off-chain-datan för den strömmen ska renas eller inte.
Binär cache. När du publicerar stora bitar av binära data, oavsett om det är kedja eller utanför kedjan, kanske det inte är praktiskt för applikationsutvecklare att skicka den informationen till MultiChains API i en enda JSON-RPC-begäran. Så MultiChain 2.0 implementerar en binär cache, som gör att stora data kan byggas upp över flera API-samtal och sedan publiceras i ett kort sista steg. Varje objekt i den binära cachen lagras som en enkel fil i undermappen "cache" i blockchain-katalogen, vilket gör att gigabyte data också kan skjutas direkt via filsystemet.
Övervakning API: er. MultiChain 2.0 alpha 3 lägger till två nya API: er för övervakning av asynkron hämtning av data utanför kedjan. Det första API: n beskriver det aktuella tillståndet i kön, visar hur många bitar (och hur mycket data) som väntar eller fråges eller hämtas. Det andra API: n ger aggregerad statistik för alla chunkfrågor och förfrågningar som skickats sedan noden startades, inklusive räkningar av olika typer av fel.
Spola på publicera. Vid publicering av en off-chain-artikel ser MultiChain till att dess lokala kopia av data är fullständigt skriven (eller "spolad") till den fysiska hårddisken före transaktionen som hänvisar till att data sänds till nätverket. Annars, om noden var otur nog att förlora makten omedelbart efter sändningen av transaktionen, kan off-chain-data förloras permanent. Detta är inte en fråga för MultiChain själv, eftersom förseningarna mellan en bitars återhämtningsförsök växer automatiskt över tid. Men det kan orsaka problem på applikationsnivå, där alla vet om det finns vissa data men ingen kan hitta dem.
Publiceringsföreställning. Genom att spola data utanför kedjan till disken på detta sätt kan MultiChain åstadkomma en prestationsstraff, eftersom fysiska diskar är långsamma. Exempelvis kan en hårddisk på mellan 7200 varv / minut bara utföra cirka 100 slumpmässiga dataskrivningar per sekund, vilket i sin tur begränsar hastigheten vid vilken en enskild nod kan publicera objekt utanför kedjan. Det finns tre möjliga lösningar för detta problem. Först och enklast kan noder använda en SSD-enhet (Solid State Device) istället för en vanlig hårddisk, som stöder 10,000 XNUMX s slumpmässiga skrivoperationer per sekund. För det andra kan flera off-chain-artiklar publiceras i en enda transaktion med hjälp av API: n "cesserawsendfrom". I det här fallet skriver MultiChain all off-chain-data som en transaktion hänvisar till i en enda diskoperation. Slutligen kan MultiChain konfigureras för att inte spola off-chain-data till disken innan sändningen av transaktionen som refererar till den. Använd detta alternativ med försiktighet.
Integrering av infödda valutor. För användningsfall som kräver det har MultiChain alltid erbjudit möjligheten att använda en inhemsk valuta på en blockchain för att förhindra transaktionsskräppost och / eller stimulera blockvalidatorer ("gruvarbetare"). I dessa fall måste transaktioner erbjuda gruvarbetare en minimiavgift som är proportionell mot deras storlek i byte för att kunna vidarebefordras och bekräftas på kedjan. Denna mekanism har utökats för att möjliggöra förhindrande av skräppost utanför kedjan genom att kräva en lägsta tilläggsavgift per kilobyte utanför kedjedata som hänvisas till i en transaktion.
Arkivera noder. Om en nod vill prenumerera på varje ström, och därför hämta och lagra alla publicerade poster utanför kedjan, kan den konfigureras för att göra det med hjälp av "autosubscribe" runtime-parametern. Alla sådana noder fungerar som en säkerhetskopia för hela nätverket och garanterar att objekt utanför kedjan inte går förlorade eller inte finns, oavsett vilka andra noder som försvinner. Man kan föreställa sig tredjepartsföretag som erbjuder detta som en kommersiell tjänst.