Scaling Blockchains With Off-chain Data

Heruitgegeven door Plato

volgers: 0

Als een hash een miljoen woorden waard is

Het is inmiddels duidelijk dat veel blockchain-use-cases niets te maken hebben met financiële transacties. In plaats daarvan is het doel van de keten om de gedecentraliseerde aggregatie, ordening, tijdstempels en archivering van elke soort informatie, inclusief gestructureerde gegevens, correspondentie of documentatie. De kernwaarde van de blockchain is dat de deelnemers aantoonbaar en permanent overeenstemming kunnen bereiken over welke gegevens wanneer en door wie precies zijn ingevoerd, zonder te vertrouwen op een vertrouwde tussenpersoon. Zo zijn onlangs SAP's gelanceerd blockchain platform, dat MultiChain en Hyperledger Fabric ondersteunt, richt zich op een breed scala aan supply chain en andere niet-financiële toepassingen.

De eenvoudigste manier om een blockchain te gebruiken voor het vastleggen van gegevens, is door elk stukje gegevens rechtstreeks in een transactie in te bedden. Elke blockchain-transactie wordt digitaal ondertekend door een of meer partijen, gerepliceerd naar elk knooppunt, geordend en van tijdstempel voorzien door het consensusalgoritme van de keten, en permanent opgeslagen op een fraudebestendige manier. Alle gegevens binnen de transactie worden daarom door elk knooppunt identiek maar onafhankelijk opgeslagen, samen met een bewijs van wie het heeft geschreven en wanneer. De gebruikers van de keten kunnen deze informatie op elk moment in de toekomst opvragen.

Met MultiChain 1.0 konden bijvoorbeeld een of meer 'streams' met de naam worden gemaakt op een blockchain en vervolgens worden gebruikt voor het opslaan en ophalen van onbewerkte gegevens. Elke stream heeft zijn eigen set schrijfrechten en elk knooppunt kan vrij kiezen op welke streams hij zich abonneert. Als een knooppunt is geabonneerd op een stream, indexeert het de inhoud van die stream in realtime, waardoor items snel kunnen worden opgehaald op basis van hun volgorde, tijdstempel, bloknummer of uitgeversadres, evenals via een 'sleutel' (of label) waarmee items kunnen worden getagd. MultiChain 2.0 (sinds alpha 1) uitgebreide streams om Unicode-tekst of JSON-gegevens te ondersteunen, evenals meerdere sleutels per item en meerdere items per transactie. Het voegde ook samenvattingsfuncties toe zoals "JSON merge", die items met dezelfde sleutel of uitgever op een handige manier combineren.

Vertrouwelijkheid en schaalbaarheid

Hoewel het goed werkt om gegevens rechtstreeks op een blockchain op te slaan, heeft het twee belangrijke tekortkomingen: vertrouwelijkheid en schaalbaarheid. Om te beginnen met vertrouwelijkheid: de inhoud van elk streamitem is zichtbaar voor elk knooppunt in de keten, en dit is niet noodzakelijk een wenselijk resultaat. In veel gevallen zou een stuk gegevens alleen zichtbaar moeten zijn voor een bepaalde subset van knooppunten, zelfs als er andere knooppunten nodig zijn om te helpen bij de ordening, tijdstempels en notarisering.

Vertrouwelijkheid is een relatief eenvoudig probleem om op te lossen door informatie te versleutelen voordat deze in een transactie wordt ingebed. De decoderingssleutel voor elk gegeven wordt alleen gedeeld met de deelnemers die het moeten zien. Sleuteloverdracht kan on-chain worden uitgevoerd met behulp van asymmetrische cryptografie (zoals hier beschreven) of via een of ander off-chain mechanisme, zoals de voorkeur heeft. Elk knooppunt zonder de sleutel om een item te decoderen, zal niets meer zien dan binair gebrabbel.

Schaalbaarheid is daarentegen een grotere uitdaging. Laten we zeggen dat elk fatsoenlijk blockchain-platform een netwerkdoorvoer van 500 transacties per seconde moet ondersteunen. Als het doel van de keten informatieopslag is, hangt de grootte van elke transactie voornamelijk af van de hoeveelheid gegevens die deze bevat. Elke transactie heeft ook (minimaal) 100 bytes overhead nodig om het adres van de afzender, de digitale handtekening en enkele andere stukjes en beetjes op te slaan.

Als we een eenvoudig geval nemen, waarbij elk item een kleine JSON-structuur van 100 bytes is, zou de totale gegevensdoorvoer 100 kilobytes per seconde zijn, berekend op basis van 500 × (100 + 100). Dit vertaalt zich naar minder dan 1 megabit / seconde aan bandbreedte, wat comfortabel binnen de capaciteit van elke moderne internetverbinding valt. De gegevens zouden zich ophopen met een snelheid van ongeveer 3 terabyte per jaar, wat niet gering is. Maar nu met 12 terabyte harde schijven ruim beschikbaar en RAID controllers die meerdere fysieke schijven combineren in één logische schijf, kunnen we gemakkelijk 10-20 jaar aan gegevens op elk knooppunt opslaan zonder al te veel gedoe of kosten.

De zaken zien er echter heel anders uit als we grotere stukjes informatie opslaan, zoals gescande documentatie. Een JPEG-scan van een redelijke kwaliteit van een vel A4-papier kan 500 kilobytes groot zijn. Vermenigvuldig dit met 500 transacties per seconde, en we kijken naar een doorvoer van 250 megabytes per seconde. Dit vertaalt zich naar 2 gigabit / seconde aan bandbreedte, wat sneller is dan de meeste lokale netwerken, laat staan verbindingen met internet. Bij Amazon Web Services 'goedkoopste gepubliceerde prijs van $ 0.05 per gigabyte, betekent dit een jaarlijkse bandbreedtefactuur van $ 400,000 per node. En waar slaat elk knooppunt de 8000 terabyte aan nieuwe data op die jaarlijks wordt gegenereerd?

Het is duidelijk dat voor blockchaintoepassingen die veel grote hoeveelheden gegevens opslaan, ongecompliceerde on-chain opslag geen praktische keuze is. Om het nog erger te maken: als gegevens worden versleuteld om het vertrouwelijkheidsprobleem op te lossen, wordt aan knooppunten gevraagd om een enorme hoeveelheid informatie op te slaan die ze niet eens kunnen lezen. Voor de deelnemers aan het netwerk is dit geen aantrekkelijk voorstel.

De hashing-oplossing

Dus hoe lossen we het probleem van gegevensschaalbaarheid op? Hoe kunnen we profiteren van de gedecentraliseerde notarisatie van gegevens door de blockchain, zonder die gegevens naar elk knooppunt in de keten te repliceren?

Het antwoord is met een slim stukje technologie dat een "hash" wordt genoemd. Een hash is een lang getal (denk aan 256 bits, of ongeveer 80 decimalen) dat een uniek gegeven identificeert. De hash wordt berekend op basis van de gegevens met behulp van een eenrichtingsfunctie die een belangrijke cryptografische eigenschap heeft: gegeven elk gegeven, is het gemakkelijk en snel om de hash ervan te berekenen. Maar gezien een bepaalde hash, is het rekenkundig niet haalbaar om een stukje gegevens te vinden dat die hash zou genereren. En als we zeggen "rekenkundig onhaalbaar", bedoelen we meer berekeningen dan er atomen zijn in het bekende universum.

Hashes spelen een cruciale rol in alle blockchains, door transacties en blokkades uniek te identificeren. Ze liggen ook ten grondslag aan de computationele uitdaging in proof-of-work-systemen zoals bitcoin. Er zijn veel verschillende hash-functies ontwikkeld, met gobbledygook-namen zoals BLAKE2, MD5 en RIPEMD160. Maar om een hashfunctie te vertrouwen, moet deze uitgebreide academische beoordeling en testen ondergaan. Deze tests komen in de vorm van aanvalspogingen, zoals 'preimage' (het vinden van een invoer met de opgegeven hash), 'second preimage' (het vinden van een tweede invoer met dezelfde hash als de opgegeven invoer) en 'collision' (het vinden van een twee verschillende ingangen met dezelfde hash). Het overleven van deze handschoen is verre van eenvoudig, met een lange en tragische geschiedenis van gebroken hash-functies die de beroemde stelregel bewijzen: "Rol niet met je eigen crypto."

Om terug te gaan naar ons oorspronkelijke probleem, kunnen we de schaalbaarheid van gegevens in blockchains oplossen door de hashes van grote stukken gegevens in transacties in te bedden, in plaats van de gegevens zelf. Elke hash fungeert als een "commitment" aan zijn invoergegevens, waarbij de gegevens zelf buiten de blockchain of "off-chain" worden opgeslagen. Als u bijvoorbeeld de populaire SHA256-hashfunctie gebruikt, kan een JPEG-afbeelding van 500 kilobyte worden weergegeven door een getal van 32 bytes, een reductie van meer dan 15,000 ×. Zelfs met een snelheid van 500 afbeeldingen per seconde, plaatst dit ons comfortabel terug op het gebied van haalbare bandbreedte- en opslagvereisten, in termen van de gegevens die in de keten zelf zijn opgeslagen.

Natuurlijk kan elke blockchain-deelnemer die een off-chain image nodig heeft, deze niet reproduceren vanuit zijn hash. Maar als de afbeelding op een andere manier kan worden opgehaald, dient de on-chain hash om te bevestigen wie het heeft gemaakt en wanneer. Net als gewone on-chain data, is de hash ingebed in een digitaal ondertekende transactie, die bij consensus in de keten is opgenomen. Als een afbeeldingsbestand uit de lucht valt en de hash voor die afbeelding overeenkomt met een hash in de blockchain, dan worden de oorsprong en het tijdstempel van die afbeelding bevestigd. De blockchain biedt dus precies dezelfde waarde in termen van notarisering alsof het beeld rechtstreeks in de keten was ingebed.

Een kwestie van levering

Tot nu toe zo goed. Door hashes in een blockchain in te bedden in plaats van de originele data, hebben we een gemakkelijke oplossing voor het probleem van schaalbaarheid. Toch blijft er een cruciale vraag over:

Hoe leveren we de originele off-chain content aan die knooppunten die het nodig hebben, zo niet via de chain zelf?

Deze vraag heeft verschillende mogelijke antwoorden, en we weten dat MultiChain-gebruikers ze allemaal toepassen. Een basisbenadering is het opzetten van een gecentraliseerde repository bij een vertrouwde partij, waar alle off-chain data wordt geüpload en vervolgens opgehaald. Dit systeem zou natuurlijk "content adressering" kunnen gebruiken, wat betekent dat de hash van elk gegeven direct dient als identificatie voor het ophalen. Hoewel deze opzet kan werken voor een proof-of-concept, is het niet logisch voor productie, omdat het hele punt van een blockchain is om vertrouwde tussenpersonen te verwijderen. Zelfs als on-chain hashes voorkomen dat de tussenpersoon gegevens vervalst, kan deze toch gegevens verwijderen of niet aan sommige deelnemers leveren, vanwege een technische storing of de acties van een malafide medewerker.

Een meer veelbelovende mogelijkheid is point-to-point-communicatie, waarbij het knooppunt dat bepaalde off-chain data nodig heeft, dit rechtstreeks opvraagt bij het knooppunt dat het heeft gepubliceerd. Dit voorkomt het vertrouwen op een vertrouwde tussenpersoon, maar heeft drie alternatieve tekortkomingen:

Het vereist een kaart van blockchain-adressen naar IP-adressen, zodat de consument van sommige gegevens rechtstreeks met de uitgever kan communiceren. Blockchains kunnen dit soort statische netwerkconfiguraties over het algemeen vermijden, wat een probleem kan zijn in termen van failover en privacy.
Als het oorspronkelijke uitgeversknooppunt het netwerk heeft verlaten of tijdelijk buiten gebruik is, kunnen de gegevens door niemand anders worden opgehaald.
Als een groot aantal knooppunten geïnteresseerd is in bepaalde gegevens, wordt de uitgever overweldigd door verzoeken. Dit kan ernstige netwerkcongestie veroorzaken, het systeem van de uitgever vertragen en leiden tot grote vertragingen voor degenen die die gegevens proberen op te halen.

Om deze problemen te voorkomen, zouden we idealiter een soort gedecentraliseerd bezorgingsmechanisme gebruiken. Knooppunten moeten in staat zijn om de gegevens die ze nodig hebben op te halen zonder te vertrouwen op een individueel systeem - of het nu een gecentraliseerde opslagplaats is of de oorspronkelijke uitgever van de gegevens. Als meerdere partijen een stukje gegevens hebben, moeten ze de last van het bezorgen ervan delen aan iedereen die het wil. Niemand hoeft een individuele gegevensbron te vertrouwen, omdat hashes in de keten kunnen bewijzen dat er niet met de gegevens is geknoeid. Als een kwaadaardig knooppunt me de verkeerde gegevens voor een hash bezorgt, kan ik die gegevens gewoon weggooien en proberen iemand anders te vragen.

Voor wie ervaring heeft met peer-to-peer bestandsuitwisseling protocollen zoals Napster, Gnutella of BitTorrent, dit zal allemaal heel bekend in de oren klinken. Veel van de basisprincipes zijn inderdaad hetzelfde, maar er zijn twee belangrijke verschillen. Ten eerste, ervan uitgaande dat we onze blockchain in een bedrijfscontext gebruiken, draait het systeem binnen een gesloten groep deelnemers, in plaats van het internet als geheel. Ten tweede voegt de blockchain een gedecentraliseerde backbone voor ordening, tijdstempels en notarisatie toe, waardoor alle gebruikers een aantoonbaar consistent en fraudebestendig beeld kunnen behouden van wat er precies is gebeurd, wanneer en door wie.

Hoe kan een ontwikkelaar van blockchain-applicaties deze gedecentraliseerde levering van off-chain content bereiken? Een veel voorkomende keuze is om een bestaand peer-to-peer-platform voor het delen van bestanden te nemen, zoals het amusant genoemde InterPlanetary-bestandssysteem (IPFS), en gebruik het samen met de blockchain. Elke deelnemer voert zowel een blockchain-knooppunt als een IPFS-knooppunt uit, met enige middleware die tussen de twee coördineert. Bij het publiceren van off-chain data, slaat deze middleware de originele data op in IPFS en creëert vervolgens een blockchain-transactie met de hash van die data. Om wat off-chain data op te halen, haalt de middleware de hash uit de blockchain en gebruikt deze hash vervolgens om de content van IPFS op te halen. Het lokale IPFS-knooppunt verifieert automatisch de opgehaalde inhoud aan de hand van de hash om er zeker van te zijn dat deze niet is gewijzigd.

Hoewel deze oplossing mogelijk is, is het allemaal nogal onhandig en onhandig. Ten eerste moet elke deelnemer drie afzonderlijke stukken software installeren, onderhouden en updaten (blockchain-knooppunt, IPFS-knooppunt en middleware), die elk hun gegevens op een aparte plaats opslaan. Ten tweede zullen er twee afzonderlijke peer-to-peer-netwerken zijn, elk met zijn eigen configuratie, netwerkpoorten, identiteitssysteem en toestemming (hoewel opgemerkt moet worden dat IPFS nog geen gesloten netwerken ondersteunt). Ten slotte zou een nauwe koppeling van IPFS en de blockchain de middleware steeds complexer maken. Als we bijvoorbeeld willen dat de off-chain-gegevens waarnaar wordt verwezen door sommige blockchain-transacties onmiddellijk worden opgehaald (met automatische nieuwe pogingen), moet de middleware constant actief zijn en zijn eigen complexe status behouden. Zou het niet mooi zijn als de blockchain-node dit allemaal voor ons zou doen?

Off-chain gegevens in MultiChain 2.0

Vandaag zijn we verheugd om het derde preview-versie (alpha 3) van MultiChain 2.0, met een volledig geïntegreerde en naadloze oplossing voor off-chain data. Elk stukje informatie dat naar een stream wordt gepubliceerd, kan naar wens on-chain of off-chain zijn, en MultiChain zorgt voor al het andere.

Nee echt, we bedoelen alles. Als ontwikkelaar die op MultiChain bouwt, hoeft u zich geen zorgen te maken over hashes, lokale opslag, contentdetectie, gedecentraliseerde levering of gegevensverificatie. Dit is wat er achter de schermen gebeurt:

De uitgevende MultiChain-node schrijft de nieuwe gegevens in de lokale opslag, waarbij grote items in stukken worden gesneden voor een gemakkelijke vertering en levering.
De transactie voor het publiceren van off-chain stream-items wordt automatisch opgebouwd en bevat de chunk-hash ('s) en grootte (s) in bytes.
Deze transactie wordt ondertekend en verzonden naar het netwerk, verspreidt zich tussen knooppunten en komt op de gebruikelijke manier de blockchain binnen.
Wanneer een knooppunt dat is geabonneerd op een stream een verwijzing naar bepaalde gegevens buiten de keten ziet, voegt het de chunk-hashes voor die gegevens toe aan zijn ophaalwachtrij. (Wanneer u zich abonneert op een oude stream, zet een node ook eerder gepubliceerde off-chain items in de wachtrij om ze op te halen.)
Als een achtergrondproces, als er brokken in de ophaalwachtrij van een knooppunt staan, worden query's naar het netwerk gestuurd om die brokken te lokaliseren, zoals geïdentificeerd door hun hashes.
Deze chunkquery's worden op een peer-to-peer-manier naar andere knooppunten in het netwerk doorgegeven (voorlopig beperkt tot twee hops - zie technische details hieronder).
Elk knooppunt dat de gegevens voor een blok heeft, kan reageren, en dit antwoord wordt teruggestuurd naar de abonnee langs hetzelfde pad als de vraag.
Als geen knooppunt de chunk-vraag beantwoordt, wordt de chunk teruggebracht naar de wachtrij om later opnieuw te proberen.
Anders kiest de abonnee de meest veelbelovende bron voor een blok (op basis van hops en responstijd), en stuurt deze een verzoek om de gegevens van dat blok, opnieuw langs hetzelfde peer-to-peer-pad als het vorige antwoord.
Het bronknooppunt levert de gevraagde gegevens en gebruikt opnieuw hetzelfde pad.
De abonnee verifieert de grootte en hash van de gegevens aan de hand van het oorspronkelijke verzoek.
Als alles klopt, schrijft de abonnee de gegevens naar zijn lokale opslag, waardoor ze onmiddellijk beschikbaar zijn voor opvraging via de stream-API's.
Als de gevraagde inhoud niet is aangekomen, of niet overeenkomt met de gewenste hash of grootte, wordt de chunk teruggestuurd naar de wachtrij voor later ophalen uit een andere bron.

Het belangrijkste is dat dit allemaal extreem snel gebeurt. In netwerken met een lage latentie komen kleine stukjes off-chain data bij abonnees binnen een fractie van een seconde na de transactie die naar hen verwijst. En voor toepassingen met hoge belasting, tonen onze tests aan dat MultiChain 2.0 alpha 3 een snelheid van meer dan 1000 off-chain items of 25 MB off-chain data die per seconde wordt opgehaald, op een mid-range server (Core i7) met een fatsoenlijke Internetverbinding. Alles werkt prima met off-chain items tot 1 GB groot, veel meer dan de limiet van 64 MB voor on-chain data. We hopen deze cijfers natuurlijk verder te verbeteren, aangezien we tijd besteden aan het optimaliseren van MultiChain 2.0 tijdens de bètafase.

Bij het gebruik van off-chain in plaats van on-chain data in streams, moeten ontwikkelaars van MultiChain-applicaties precies twee dingen doen:

Geef bij het publiceren van gegevens een "offchain" -vlag door aan de juiste API's.
Houd bij het gebruik van de API's voor het opvragen van streams rekening met de mogelijkheid dat bepaalde gegevens buiten de keten nog niet beschikbaar zijn, zoals aangegeven door de vlag "beschikbaar". Hoewel deze situatie onder normale omstandigheden zeldzaam zal zijn, is het belangrijk dat applicatieontwikkelaars er op de juiste manier mee omgaan.

Om te voorkomen dat elk knooppunt elk item buiten de keten ophaalt, moeten items natuurlijk op een geschikte manier in streams worden gegroepeerd, waarbij elk knooppunt zich abonneert op die interessante streams.

On-chain en off-chain items kunnen binnen dezelfde stream worden gebruikt, en de verschillende stream-querying- en samenvattingsfuncties hebben identiek betrekking op beide soorten gegevens. Hierdoor kunnen publishers voor elk item in een stream de juiste keuze maken, zonder dat dit gevolgen heeft voor de rest van een applicatie. Een stroom JSON-items over de activiteiten van mensen kan bijvoorbeeld off-chain data gebruiken voor persoonlijk identificeerbare informatie, en on-chain data voor de rest. Abonnees kunnen de JSON-samenvoeging van MultiChain gebruiken om beide soorten informatie te combineren tot één JSON om te lezen.

Als je off-chain stream-items eens wilt proberen, volg dan gewoon de reguliere van MultiChain Ermee beginnen tutorial, en vergeet niet sectie 5 over te slaan.

Dus wat nu?

Met naadloze ondersteuning voor off-chain data, biedt MultiChain 2.0 een grote stap voorwaarts voor blockchain-applicaties gericht op grootschalige data timestamping en notarisatie. Op de langere termijn denken we al na over een heleboel mogelijke toekomstige verbeteringen van deze functie voor de Community- en / of Enterprise-edities van MultiChain:

Implementeren van stream dit artikel lezen machtigingen met behulp van een combinatie van off-chain items, salted hashes, ondertekende chunk queries en versleutelde levering.
Toestaan dat gegevens buiten de keten expliciet worden "vergeten", zowel vrijwillig door individuele knooppunten als door alle knooppunten als reactie op een bericht in de keten.
Selectieve streamabonnementen, waarbij knooppunten alleen de gegevens ophalen voor off-chain items met bepaalde uitgevers of sleutels.
gebruik merkle bomen om een enkele on-chain hash in staat te stellen een onbeperkt aantal off-chain items te vertegenwoordigen, wat weer een enorme sprong maakt in termen van schaalbaarheid.
Pluggable storage-engines, waardoor gegevens buiten de keten in databases of externe bestandssystemen kunnen worden bewaard in plaats van op de lokale schijf.
Knooppunten leren in de loop van de tijd waar elk type off-chain data meestal beschikbaar is in een netwerk, en richten hun brokquery's op de juiste manier.

We zouden graag hoor uw feedback op de bovenstaande lijst, evenals off-chain items in het algemeen. Met MultiChain 2.0 nog steeds officieel in alpha, is er voldoende tijd om deze functie te verbeteren voordat deze definitief wordt vrijgegeven.

In de tussentijd zijn we al begonnen met werken aan "Smart Filters", de laatste belangrijke feature die gepland staat voor de MultiChain 2.0 Community. Een Smart Filter is een stukje code dat is ingebed in de blockchain en die aangepaste regels implementeert voor het valideren van gegevens of transacties. Slimme filters hebben enkele overeenkomsten met "slimme contracten" en kunnen veel van dezelfde dingen doen, maar hebben belangrijke verschillen in termen van veiligheid en prestaties. We vertellen u er graag meer over.

Plaats eventuele opmerkingen op LinkedIn.

Technische details

Hoewel off-chain stream-items in MultiChain 2.0 eenvoudig te gebruiken zijn, bevatten ze veel ontwerpbeslissingen en aanvullende functies die van belang kunnen zijn. De onderstaande lijst is voornamelijk relevant voor ontwikkelaars die blockchain-applicaties bouwen en kan worden overgeslagen door minder technische typen:

Beleid per stream. Wanneer een MultiChain-stream wordt gemaakt, kan deze optioneel worden beperkt om alleen on-chain of off-chain data toe te staan. Er zijn verschillende mogelijke redenen om dit te doen, in plaats van elke uitgever zelf te laten beslissen. On-chain-items bieden bijvoorbeeld een ijzersterke beschikbaarheidsgarantie, terwijl oude off-chain-items onherstelbaar kunnen worden als hun uitgever en andere abonnees het netwerk verlaten. Aan de andere kant kunnen on-chain items niet worden "vergeten" zonder de blockchain te wijzigen, terwijl off-chain items flexibeler zijn. Dit kan belangrijk zijn in termen van gegevensprivacyregels, zoals Europa's nieuwe GDPR-regelgeving.
Metadata op de keten. Voor off-chain items bevat de on-chain transactie nog steeds de uitgever (s), sleutel (s), formaat (JSON, tekst of binair) en totale grootte van het item. Dit alles neemt heel weinig ruimte in beslag en helpt applicatieontwikkelaars te bepalen of de onbeschikbaarheid van een off-chain item van belang is voor een bepaalde streamquery.
Limiet van twee hops. Bij het doorgeven van blokquery's via het peer-to-peer-netwerk, is er een afweging tussen bereikbaarheid en prestaties. Hoewel het prettig zou zijn als elke query langs elk pad wordt verspreid, kan dit het netwerk verstoppen met onnodige "chatter". Dus voorlopig zijn chunk-queries beperkt tot twee hops, wat betekent dat een node off-chain data kan ophalen van elke peer van zijn peers. In de kleinere netwerken van minder dan 1000 knooppunten die de neiging hebben om enterprise blockchains te karakteriseren, denken we dat dit prima zal werken, maar het is gemakkelijk voor ons om deze beperking aan te passen (of aan te bieden als een parameter) als we het bij het verkeerde eind hebben.
Lokale opslag. Elk MultiChain-knooppunt slaat gegevens buiten de keten op in de "chunks" -directory van zijn reguliere blockchain-directory, met behulp van een efficiënt binair formaat en LevelDB-index. Er wordt een aparte submap gebruikt voor de items in elk van de streams waarop is geabonneerd, evenals voor de items die door het knooppunt zelf zijn gepubliceerd. Binnen elk van deze submappen worden dubbele brokken (met dezelfde hash) slechts één keer opgeslagen. Wanneer een knooppunt zich uitschrijft voor een stream, kan het ervoor kiezen om de off-chain data die voor die stream is opgehaald, al dan niet op te schonen.
Binaire cache. Bij het publiceren van grote stukken binaire data, zowel on-chain als off-chain, kan het voor applicatieontwikkelaars niet praktisch zijn om die data in een enkel JSON-RPC-verzoek naar de API van MultiChain te sturen. Dus MultiChain 2.0 implementeert een binaire cache, waarmee grote hoeveelheden gegevens kunnen worden opgebouwd over meerdere API-aanroepen en vervolgens in een korte laatste stap kunnen worden gepubliceerd. Elk item in de binaire cache wordt opgeslagen als een eenvoudig bestand in de "cache" -subdirectory van de blockchain-directory, waardoor gigabytes aan gegevens ook rechtstreeks via het bestandssysteem kunnen worden gepusht.
Monitoring API's. MultiChain 2.0 alpha 3 voegt twee nieuwe API's toe voor het monitoren van het asynchroon ophalen van off-chain data. De eerste API beschrijft de huidige status van de wachtrij en laat zien hoeveel chunks (en hoeveel gegevens) wachten, worden opgevraagd of opgehaald. De tweede API biedt geaggregeerde statistieken voor alle blokquery's en verzoeken die zijn verzonden sinds het opstarten van het knooppunt, inclusief het aantal verschillende soorten fouten.
Flush bij publiceren. Bij het publiceren van een off-chain item, zorgt MultiChain ervoor dat de lokale kopie van de gegevens volledig wordt geschreven (of "doorgespoeld") naar de fysieke schijf voordat de transactie die verwijst naar die gegevens, naar het netwerk wordt verzonden. Anders, als het knooppunt de pech had om onmiddellijk stroom te verliezen na het uitzenden van de transactie, zouden de off-chain data permanent verloren kunnen gaan. Dit is geen probleem voor MultiChain zelf, aangezien de vertragingen tussen de ophaalpogingen van een brok automatisch toenemen met de tijd. Maar het kan problemen veroorzaken op applicatieniveau, waar iedereen op de hoogte is van het bestaan van bepaalde gegevens, maar niemand deze kan vinden.
Publiceerprestaties. Door op deze manier off-chain data naar de schijf te wissen, kan MultiChain een prestatieverbinding oplopen, aangezien fysieke schijven traag zijn. Een harde schijf met een gemiddelde snelheid van 7200 rpm kan bijvoorbeeld slechts ongeveer 100 willekeurige gegevensschrijvingen per seconde uitvoeren, waardoor op zijn beurt de snelheid wordt beperkt waarmee een individuele node off-chain items kan publiceren. Er zijn drie mogelijke oplossingen voor dit probleem. Ten eerste kunnen knooppunten een solid-state device (SSD) -drive gebruiken in plaats van een gewone harde schijf, die 10,000 willekeurige schrijfbewerkingen per seconde ondersteunt. Ten tweede kunnen meerdere off-chain items in één transactie worden gepubliceerd met behulp van de “createrawsendfrom” API. In dit geval schrijft MultiChain alle gegevens buiten de keten waarnaar wordt verwezen door een transactie in een enkele schijfbewerking. Ten slotte kan MultiChain worden geconfigureerd om gegevens buiten de keten niet naar schijf te spoelen voordat de transactie wordt uitgezonden die ernaar verwijst. Gebruik deze optie met zorg.
Native valuta-integratie. Voor gebruikssituaties die dit vereisen, heeft MultiChain altijd de mogelijkheid geboden om een native valuta op een blockchain te gebruiken om transactiespam te voorkomen en / of blokvalidators ("miners") te stimuleren. In deze gevallen moeten transacties mijnwerkers een minimumvergoeding bieden die evenredig is met hun grootte in bytes, om te worden doorgegeven en bevestigd in de keten. Dit mechanisme is uitgebreid om spam buiten de keten te voorkomen, door een minimumtoeslag te eisen per kilobyte aan gegevens buiten de keten waarnaar in een transactie wordt verwezen.
Archiveer knooppunten. Als een knooppunt zich op elke stream wil abonneren en daarom elk gepubliceerde off-chain item wil ophalen en opslaan, kan het worden geconfigureerd om dit te doen met behulp van de runtime-parameter "autosubscribe". Elk van deze knooppunten fungeert als een back-up voor het hele netwerk en garandeert dat items buiten de keten niet verloren gaan of onbeschikbaar zijn, ongeacht welke andere knooppunten verdwijnen. Men kan zich voorstellen dat derde bedrijven dit aanbieden als een commerciële dienst.