Scaling Blockchains With Off-chain Data

Republicat de Platon

Urmaritori: 0

Când un hash valorează un milion de cuvinte

Până acum, este clar că multe cazuri de utilizare blockchain nu au nimic de-a face cu tranzacțiile financiare. În schimb, scopul lanțului este de a permite agregarea descentralizată, ordonarea, marcarea temporală și arhivarea Orice tip de informații, inclusiv date structurate, corespondență sau documentație. Valoarea de bază a blockchain-ului permite participanților săi să convină în mod dovedit și permanent asupra exact ce date au fost introduse, când și de către cine, fără a se baza pe un intermediar de încredere. De exemplu, SAP a fost lansat recent platforma blockchain, care acceptă MultiChain și Hyperledger Fabric, vizează o gamă largă de lanțuri de aprovizionare și alte aplicații non-financiare.

Cea mai simplă modalitate de a utiliza un blockchain pentru înregistrarea datelor este de a încorpora fiecare bucată de date direct într-o tranzacție. Fiecare tranzacție blockchain este semnată digital de una sau mai multe părți, replicată la fiecare nod, ordonată și marcată de timp de algoritmul de consens al lanțului și stocată permanent într-un mod inviolabil. Prin urmare, orice date din tranzacție vor fi stocate identic, dar independent de fiecare nod, împreună cu o dovadă a cine a scris-o și când. Utilizatorii lanțului pot prelua aceste informații în orice moment viitor.

De exemplu, MultiChain 1.0 a permis ca unul sau mai multe „fluxuri” numite să fie create pe un blockchain și apoi utilizate pentru stocarea și preluarea datelor brute. Fiecare flux are propriul set de permisiuni de scriere și fiecare nod poate alege liber la ce fluxuri să se aboneze. Dacă un nod este abonat la un flux, acesta indexează conținutul acelui flux în timp real, permițând recuperarea rapidă a articolelor pe baza ordinii, marcajului de timp, numărului blocului sau adresei editorului, precum și printr-o „cheie” (sau etichetă) prin care articolele pot fi etichetate. MultiChain 2.0 (din alpha 1) a extins fluxurile pentru a accepta text Unicode sau date JSON, precum și mai multe chei per articol și mai multe articole per tranzacție. De asemenea, a adăugat funcții de rezumat, cum ar fi „Imbinare JSON”, care combină articole cu aceeași cheie sau editor într-un mod util.

Confidențialitate și scalabilitate

Deși stocarea datelor direct pe un blockchain funcționează bine, aceasta suferă de două deficiențe cheie – confidențialitatea și scalabilitatea. Pentru a începe cu confidențialitatea, conținutul fiecărui element de flux este vizibil pentru fiecare nod din lanț și acesta nu este neapărat un rezultat dezirabil. În multe cazuri, o bucată de date ar trebui să fie vizibilă doar pentru un anumit subset de noduri, chiar dacă sunt necesare alte noduri pentru a ajuta la ordonarea, marcarea temporală și notarizarea acesteia.

Confidențialitatea este o problemă relativ ușor de rezolvat, prin criptarea informațiilor înainte ca acestea să fie încorporate într-o tranzacție. Cheia de decriptare pentru fiecare bucată de date este partajată doar cu participanții care sunt menționați să o vadă. Livrarea cheilor poate fi efectuată în lanț folosind criptografia asimetrică (cum ar fi descrise aici) sau printr-un mecanism în afara lanțului, după cum este de preferat. Orice nod căruia îi lipsește cheia pentru a decripta un articol nu va vedea nimic mai mult decât galimă binară.

Scalabilitatea, pe de altă parte, este o provocare mai semnificativă. Să presupunem că orice platformă blockchain decentă ar trebui să suporte un flux de rețea de 500 de tranzacții pe secundă. Dacă scopul lanțului este stocarea informațiilor, atunci dimensiunea fiecărei tranzacții va depinde în primul rând de câte date conține. Fiecare tranzacție va avea nevoie, de asemenea, de (cel puțin) 100 de octeți de supraîncărcare pentru a stoca adresa expeditorului, semnătura digitală și alte câteva biți și bucăți.

Dacă luăm un caz ușor, în care fiecare articol este o structură JSON mică de 100 de octeți, debitul total de date ar fi de 100 de kiloocteți pe secundă, calculat de la 500 × (100+100). Acest lucru se traduce printr-o lățime de bandă sub 1 megabit/secundă, ceea ce este confortabil în capacitatea oricărei conexiuni moderne la internet. Datele s-ar acumula cu o rată de aproximativ 3 terabytes pe an, ceea ce nu este o cantitate mică. Dar cu hard disk-uri de 12 terabyte acum disponibil pe scară largă, și RAID controlere care combină mai multe unități fizice într-una singură logică, am putea stoca cu ușurință 10-20 de ani de date pe fiecare nod, fără prea multe bătăi de cap sau cheltuieli.

Cu toate acestea, lucrurile arată foarte diferit dacă stocăm informații mai mari, cum ar fi documentația scanată. O scanare JPEG de calitate rezonabilă a unei coli de hârtie A4 poate avea o dimensiune de 500 kiloocteți. Înmulțiți acest lucru cu 500 de tranzacții pe secundă și ne uităm la un debit de 250 megaocteți pe secunda. Acest lucru se traduce în 2 gigabiți/secundă de lățime de bandă, care este mai rapidă decât majoritatea rețelelor locale, cu atât mai puțin conexiunile la Internet. La cele mai ieftine servicii Amazon Web preț publicat de 0.05 USD per gigaoctet, înseamnă o factură anuală de lățime de bandă de 400,000 USD per nod. Și unde va stoca fiecare nod cei 8000 de terabytes de date noi generate anual?

Este clar că, pentru aplicațiile blockchain care stochează multe bucăți mari de date, stocarea simplă în lanț nu este o alegere practică. Pentru a adăuga insulte, dacă datele sunt criptate pentru a rezolva problema confidențialității, nodurilor li se cere să stocheze o cantitate imensă de informații pe care nici măcar nu le pot citi. Aceasta nu este o propunere atractivă pentru participanții rețelei.

Soluția de hashing

Deci, cum rezolvăm problema scalabilității datelor? Cum putem profita de notarizarea descentralizată a datelor a blockchain-ului, fără a replica acele date în fiecare nod al lanțului?

Răspunsul este cu o tehnologie inteligentă numită „hash”. Un hash este un număr lung (gândiți-vă la 256 de biți sau aproximativ 80 de cifre zecimale) care identifică în mod unic o bucată de date. Hash-ul este calculat din date folosind a funcție unidirecțională care are o proprietate criptografică importantă: Având în vedere orice date, este ușor și rapid să-și calculeze hash-ul. Dar, având în vedere un anumit hash, este imposibil din punct de vedere computațional să găsești o bucată de date care să genereze acel hash. Și când spunem „infezabil din punct de vedere computațional”, ne referim la mai multe calcule decât există atomi în universul cunoscut.

Hashe-urile joacă un rol crucial în toate blockchain-urile, prin identificarea unică a tranzacțiilor și a blocurilor. Ele stau, de asemenea, la baza provocării de calcul în sistemele de dovadă a lucrului precum bitcoin. Au fost dezvoltate multe funcții hash diferite, cu nume gobbledygook precum BLAKE2, MD5 și RIPEMD160. Dar, pentru ca orice funcție hash să fie de încredere, trebuie să suporte revizuiri și teste academice extinse. Aceste teste vin sub forma unor tentative de atac, cum ar fi „preimage” (găsirea unei intrări cu hash-ul dat), „a doua preimagine” (găsirea unei a doua intrări cu același hash ca și intrarea dată) și „coliziune” (găsirea oricărei două intrări diferite cu același hash). Supraviețuirea acestei mănuși este departe de a fi ușoară, cu o istorie lungă și tragică a funcțiilor hash rupte care demonstrează celebra maximă: „Nu-ți face propria criptomonedă”.

Pentru a reveni la problema noastră inițială, putem rezolva scalabilitatea datelor în blockchain-uri prin încorporarea hash-urilor de bucăți mari de date în tranzacții, în locul datelor în sine. Fiecare hash acționează ca un „angajament” față de datele sale de intrare, datele în sine fiind stocate în afara blockchain-ului sau „în afara lanțului”. De exemplu, folosind populara funcție hash SHA256, o imagine JPEG de 500 de kiloocteți poate fi reprezentată printr-un număr de 32 de octeți, o reducere de peste 15,000×. Chiar și la o rată de 500 de imagini pe secundă, acest lucru ne readuce confortabil pe teritoriul cerințelor fezabile de lățime de bandă și stocare, în ceea ce privește datele stocate pe lanțul în sine.

Desigur, orice participant blockchain care are nevoie de o imagine în afara lanțului nu o poate reproduce din hash-ul său. Dar dacă imaginea poate fi preluată într-un alt mod, atunci hash-ul în lanț servește pentru a confirma cine a creat-o și când. La fel ca datele obișnuite din lanț, hash-ul este încorporat într-o tranzacție semnată digital, care a fost inclusă în lanț prin consens. Dacă un fișier imagine cade din cer, iar hash-ul pentru imaginea respectivă se potrivește cu un hash din blockchain, atunci originea și marcajul de timp al acelei imagini sunt confirmate. Deci, blockchain-ul oferă exact aceeași valoare în ceea ce privește notarizarea ca și cum imaginea ar fi încorporată direct în lanț.

O chestiune de livrare

Până acum, bine. Prin încorporarea hashurilor într-un blockchain în locul datelor originale, avem o soluție ușoară la problema scalabilității. Cu toate acestea, rămâne o întrebare crucială:

Cum livrăm conținutul original off-chain acelor noduri care au nevoie de el, dacă nu prin lanțul în sine?

Această întrebare are mai multe răspunsuri posibile și știm că utilizatorii MultiChain le aplică pe toate. O abordare de bază este crearea unui depozit centralizat la o parte de încredere, unde toate datele din afara lanțului sunt încărcate și apoi recuperate. Acest sistem ar putea folosi în mod natural „adresarea conținutului”, ceea ce înseamnă că hash-ul fiecărei date servește direct ca identificator pentru regăsire. Cu toate acestea, deși această configurație ar putea funcționa pentru o dovadă de concept, nu are sens pentru producție, deoarece scopul unui blockchain este să elimine intermediarii de încredere. Chiar dacă hashurile în lanț împiedică intermediarul să falsifice datele, acesta ar putea totuși să ștergă datele sau să nu le livreze unor participanți, din cauza unei defecțiuni tehnice sau a acțiunilor unui angajat necinstit.

O posibilitate mai promițătoare este comunicarea punct la punct, în care nodul care necesită niște date în afara lanțului le solicită direct de la nodul care a publicat-o. Acest lucru evită să se bazeze pe un intermediar de încredere, dar suferă de trei deficiențe alternative:

Este nevoie de o hartă a adreselor blockchain la adresele IP, pentru a permite consumatorului unor date să comunice direct cu editorul său. Blockchain-urile pot evita în general acest tip de configurație statică a rețelei, care poate fi o problemă în ceea ce privește failoverul și confidențialitatea.
Dacă nodul original al editorului a părăsit rețeaua sau este temporar ieșit din funcțiune, atunci datele nu pot fi preluate de nimeni altcineva.
Dacă un număr mare de noduri sunt interesate de unele date, atunci editorul va fi copleșit de solicitări. Acest lucru poate crea congestionare severă a rețelei, poate încetini sistemul editorului și poate duce la întârzieri mari pentru cei care încearcă să recupereze acele date.

Pentru a evita aceste probleme, în mod ideal am folosi un fel de mecanism de livrare descentralizat. Nodurile ar trebui să poată prelua datele de care au nevoie fără să se bazeze pe niciun sistem individual – fie că este vorba de un depozit centralizat sau de editorul original al datelor. Dacă mai multe părți au o bucată de date, acestea ar trebui să împartă sarcina de a le livra oricui altcineva dorește. Nimeni nu trebuie să aibă încredere într-o sursă de date individuală, deoarece hashurile în lanț pot dovedi că datele nu au fost modificate. Dacă un nod rău intenționat îmi furnizează date greșite pentru un hash, pot pur și simplu să renunț la acele date și să încerc să întreb pe altcineva.

Pentru cei care au experienta cu partajarea de fișiere peer-to-peer protocoale precum Napster, Gnutella sau BitTorrent, toate acestea vor suna foarte familiare. Într-adevăr, multe dintre principiile de bază sunt aceleași, dar există două diferențe cheie. În primul rând, presupunând că ne folosim blockchain-ul într-un context de întreprindere, sistemul rulează într-un grup închis de participanți, mai degrabă decât Internetul în ansamblu. În al doilea rând, blockchain-ul adaugă o coloană descentralizată de comandă, marcare temporală și notarizare, permițând tuturor utilizatorilor să mențină o viziune consistentă și rezistentă la falsificare a exact ceea ce sa întâmplat, când și de către cine.

Cum ar putea un dezvoltator de aplicații blockchain să realizeze această livrare descentralizată a conținutului în afara lanțului? O alegere obișnuită este să luați o platformă de partajare de fișiere peer-to-peer existentă, cum ar fi cea denumită amuzant Sistem interplanetar de fișiere (IPFS) și folosiți-l împreună cu blockchain-ul. Fiecare participant rulează atât un nod blockchain, cât și un nod IPFS, cu unele middleware coordonând între cele două. Când publică date în afara lanțului, acest middleware stochează datele originale în IPFS, apoi creează o tranzacție blockchain care conține hash-ul datelor respective. Pentru a prelua unele date din afara lanțului, middleware-ul extrage hash-ul din blockchain, apoi folosește acest hash pentru a prelua conținutul din IPFS. Nodul local IPFS verifică automat conținutul preluat în raport cu hash-ul pentru a se asigura că nu a fost modificat.

Deși această soluție este posibilă, totul este destul de stângaci și incomod. În primul rând, fiecare participant trebuie să instaleze, să întrețină și să actualizeze trei componente software separate (nodul blockchain, nodul IPFS și middleware), fiecare dintre acestea stochând datele într-un loc separat. În al doilea rând, vor exista două rețele peer-to-peer separate, fiecare cu propria configurație, porturi de rețea, sistem de identitate și permisiuni (deși trebuie remarcat că IPFS nu acceptă încă rețele închise). În cele din urmă, cuplarea strânsă a IPFS și a blockchain-ului ar face middleware-ul din ce în ce mai complex. De exemplu, dacă dorim ca datele din afara lanțului la care se face referire de unele tranzacții blockchain să fie recuperate instantaneu (cu reîncercări automate), middleware-ul ar trebui să fie în mod constant în funcțiune, menținându-și propria stare complexă. Nu ar fi frumos dacă nodul blockchain ar face toate acestea pentru noi?

Date în afara lanțului în MultiChain 2.0

Astăzi suntem încântați să lansăm a treia versiune de previzualizare (alfa 3) a MultiChain 2.0, cu o soluție complet integrată și perfectă pentru date în afara lanțului. Fiecare informație publicată într-un flux poate fi în lanț sau în afara lanțului, după cum doriți, iar MultiChain se ocupă de orice altceva.

Nu chiar, vrem să spunem tot. În calitate de dezvoltator bazat pe MultiChain, nu va trebui să vă faceți griji cu privire la hashuri, stocarea locală, descoperirea conținutului, livrarea descentralizată sau verificarea datelor. Iată ce se întâmplă în culise:

Nodul MultiChain de publicare scrie noile date în stocarea locală, tăind articole mari în bucăți pentru digestie și livrare ușoară.
Tranzacția de publicare a elementelor din fluxul în afara lanțului este construită automat, conținând hash-urile și dimensiunea (e) în octeți.
Această tranzacție este semnată și difuzată în rețea, propagăndu-se între noduri și intrând în blockchain în mod obișnuit.
Când un nod abonat la un flux vede o referință la unele date din afara lanțului, adaugă hash-urile chunk pentru acele date la coada sa de recuperare. (Când vă abonați la un flux vechi, un nod pune, de asemenea, în coadă toate articolele în afara lanțului publicate anterior pentru a fi recuperate.)
Ca proces de fundal, dacă există bucăți în coada de recuperare a unui nod, interogările sunt trimise în rețea pentru a localiza acele bucăți, așa cum sunt identificate de hashurile lor.
Aceste interogări de bucăți sunt propagate către alte noduri din rețea într-un mod peer-to-peer (limitat la două hopuri pentru moment - consultați detaliile tehnice de mai jos).
Orice nod care are datele pentru o bucată poate răspunde, iar acest răspuns este transmis către abonat înapoi pe aceeași cale ca și interogarea.
Dacă niciun nod nu răspunde la interogarea bucată, fragmentul este returnat înapoi la coadă pentru reîncercarea ulterioară.
În caz contrar, abonatul alege cea mai promițătoare sursă pentru o bucată (pe baza hopurilor și a timpului de răspuns) și îi trimite o solicitare pentru datele acelei bucăți, din nou pe aceeași cale peer-to-peer ca răspunsul anterior.
Nodul sursă livrează datele solicitate, folosind din nou aceeași cale.
Abonatul verifică dimensiunea datelor și hash-ul față de cererea inițială.
Dacă totul se verifică, abonatul scrie datele în stocarea locală, făcându-le imediat disponibile pentru preluare prin intermediul API-urilor de flux.
Dacă conținutul solicitat nu a sosit sau nu se potrivește cu hash-ul sau dimensiunea dorită, fragmentul este returnat înapoi la coadă pentru extragere ulterioară dintr-o altă sursă.

Cel mai important, toate acestea se întâmplă extrem de rapid. În rețelele cu latență scăzută, bucăți mici de date în afara lanțului vor ajunge la abonați într-o fracțiune de secundă de la tranzacția care le face referire. Iar pentru aplicațiile cu încărcare mare, testele noastre arată că MultiChain 2.0 alpha 3 poate susține o rată de peste 1000 de articole în afara lanțului sau 25 MB de date în afara lanțului recuperate pe secundă, pe un server de gamă medie (Core i7) cu un server decent. Conexiune internet. Totul funcționează bine cu articolele în afara lanțului de până la 1 GB, cu mult peste limita de 64 MB pentru datele în lanț. Desigur, sperăm să îmbunătățim aceste cifre în continuare pe măsură ce petrecem timp optimizând MultiChain 2.0 în faza sa beta.

Când folosesc date în afara lanțului, mai degrabă decât în lanț, dezvoltatorii de aplicații MultiChain trebuie să facă exact două lucruri:

Când publicați date, transmiteți un semnalizator „offchain” către API-urile corespunzătoare.
Când utilizați API-urile de interogare a fluxului, luați în considerare posibilitatea ca unele date în afara lanțului să nu fie încă disponibile, așa cum este raportat de indicatorul „disponibil”. Deși această situație va fi rară în circumstanțe normale, este important ca dezvoltatorii de aplicații să o gestioneze în mod corespunzător.

Desigur, pentru a preveni ca fiecare nod să recupereze fiecare element din afara lanțului, articolele ar trebui grupate în fluxuri într-un mod adecvat, fiecare nod abonându-se la acele fluxuri de interes.

Elementele din lanț și din afara lanțului pot fi utilizate în cadrul aceluiași flux, iar diferitele funcții de interogare și rezumare a fluxului se referă la ambele tipuri de date în mod identic. Acest lucru le permite editorilor să facă alegerea potrivită pentru fiecare articol dintr-un flux, fără a afecta restul unei aplicații. De exemplu, un flux de articole JSON despre activitățile oamenilor ar putea folosi date din afara lanțului pentru informații de identificare personală și date din lanț pentru restul. Abonații pot folosi fuziunea JSON MultiChain pentru a combina ambele tipuri de informații într-un singur JSON pentru citire.

Dacă doriți să încercați articolele din fluxul off-chain, trebuie doar să urmați regula MultiChain Noțiuni de bază tutorial și asigurați-vă că nu omiteți secțiunea 5.

Deci ce urmeaza?

Cu suport fără întreruperi pentru datele în afara lanțului, MultiChain 2.0 va oferi un mare pas înainte pentru aplicațiile blockchain axate pe marcarea temporală și notarizarea datelor la scară largă. Pe termen lung, ne gândim deja la o mulțime de posibile îmbunătățiri viitoare ale acestei funcții pentru edițiile MultiChain pentru Comunitate și/sau Enterprise:

Flux de implementare citit permisiuni folosind o combinație de articole în afara lanțului, hash-uri sărate, interogări de fragmente semnate și livrare criptată.
Permiterea explicit a datelor din afara lanțului să fie „uitate”, atât în mod voluntar de către nodurile individuale, fie de către toate nodurile ca răspuns la un mesaj în lanț.
Abonamentele de flux selectiv, în care nodurile preiau numai datele pentru articolele în afara lanțului cu anumiți editori sau chei.
Utilizarea copaci merkle pentru a permite unui singur hash în lanț să reprezinte un număr nelimitat de articole în afara lanțului, oferind un alt salt uriaș în ceea ce privește scalabilitatea.
Motoare de stocare conectabile, permițând păstrarea datelor în afara lanțului în baze de date sau sisteme de fișiere externe, mai degrabă decât pe discul local.
Nodurile învață de-a lungul timpului unde fiecare tip de date în afara lanțului este de obicei disponibil într-o rețea și își concentrează în mod corespunzător interogările pe fragmente.

Ne-ar plăcea auzi feedback-ul tău pe lista de mai sus, precum și articolele în afara lanțului în general. Cu MultiChain 2.0 încă oficial în alfa, există suficient timp pentru a îmbunătăți această caracteristică înainte de lansarea sa finală.

Între timp, am început deja lucrul la „Filtre inteligente”, ultima caracteristică majoră planificată pentru Comunitatea MultiChain 2.0. Un filtru inteligent este o bucată de cod încorporată în blockchain care implementează reguli personalizate pentru validarea datelor sau tranzacțiilor. Filtrele inteligente au unele asemănări cu „contractele inteligente” și pot face multe dintre aceleași lucruri, dar au diferențe cheie în ceea ce privește siguranța și performanța. Așteptăm cu nerăbdare să vă spunem mai multe în timp util.

Vă rugăm să postați comentarii pe LinkedIn.

Detalii tehnice

În timp ce elementele de flux în afara lanțului din MultiChain 2.0 sunt simplu de utilizat, ele conțin multe decizii de proiectare și caracteristici suplimentare care pot fi de interes. Lista de mai jos va fi relevantă în principal pentru dezvoltatorii care construiesc aplicații blockchain și poate fi omisă de tipurile mai puțin tehnice:

Politici per-stream. Când este creat un flux MultiChain, acesta poate fi opțional restricționat pentru a permite numai date în lanț sau în afara lanțului. Există mai multe motive posibile pentru a face acest lucru, mai degrabă decât a permite fiecărui editor să decidă singur. De exemplu, articolele din lanț oferă o garanție absolută a disponibilității, în timp ce articolele vechi în afara lanțului pot deveni irecuperabile dacă editorul și alți abonați renunță la rețea. Pe de altă parte, articolele din lanț nu pot fi „uitate” fără modificarea blockchain-ului, în timp ce articolele din afara lanțului sunt mai flexibile. Acest lucru poate fi important în ceea ce privește regulile de confidențialitate a datelor, cum ar fi noile reglementări GDPR din Europa.
Metadate în lanț. Pentru articolele în afara lanțului, tranzacția în lanț conține în continuare editorii articolului, cheile, formatul (JSON, text sau binar) și dimensiunea totală. Toate acestea ocupă foarte puțin spațiu și îi ajută pe dezvoltatorii de aplicații să stabilească dacă indisponibilitatea unui articol în afara lanțului este un motiv de îngrijorare pentru o anumită interogare de flux.
Limită de două sărituri. Atunci când retransmiți interogări pe blocuri în rețeaua peer-to-peer, există un compromis între accesibilitate și performanță. Deși ar fi bine ca fiecare interogare să fie propagată de-a lungul fiecărei căi, acest lucru poate înfunda rețeaua cu „chatter” inutile. Deci, deocamdată, interogările în bucăți sunt limitate la două hopuri, ceea ce înseamnă că un nod poate prelua date în afara lanțului de la orice peer al colegilor săi. În rețelele mai mici, de sub 1000 de noduri, care tind să caracterizeze blockchain-urile de întreprindere, credem că acest lucru va funcționa bine, dar este ușor pentru noi să ajustam această constrângere (sau să o oferim ca parametru) dacă se dovedește a greși.
Stocare locală. Fiecare nod MultiChain stochează date în afara lanțului în directorul „bucăți” al directorului său obișnuit blockchain, folosind un format binar eficient și un index LevelDB. Un subdirector separat este utilizat pentru articolele din fiecare dintre fluxurile abonate, precum și pentru cele publicate de nodul însuși. În fiecare dintre aceste subdirectoare, bucățile duplicate (cu același hash) sunt stocate o singură dată. Când un nod se dezabonează de la un flux, acesta poate alege dacă să curețe sau nu datele din afara lanțului preluate pentru acel flux.
Cache binar. Când se publică date binare mari, fie în lanț sau în afara lanțului, poate să nu fie practic pentru dezvoltatorii de aplicații să trimită acele date către API-ul MultiChain într-o singură solicitare JSON-RPC. Deci, MultiChain 2.0 implementează un cache binar, care permite ca bucăți mari de date să fie construite pe mai multe apeluri API și apoi publicate într-un scurt pas final. Fiecare element din cache-ul binar este stocat ca un simplu fișier în subdirectorul „cache” al directorului blockchain, permițând de asemenea împingeți gigaocteți de date direct prin sistemul de fișiere.
Monitorizarea API-urilor. MultiChain 2.0 alpha 3 adaugă două noi API-uri pentru monitorizarea preluării asincrone a datelor în afara lanțului. Primul API descrie starea curentă a cozii, arătând câte bucăți (și câte date) așteaptă sau sunt interogate sau preluate. Al doilea API furnizează statistici agregate pentru toate interogările și cererile pe blocuri trimise de la pornirea nodului, inclusiv numărătoarea diferitelor tipuri de defecțiuni.
Flush la publicare. Atunci când publică un articol în afara lanțului, MultiChain se asigură că copia sa locală a datelor este complet scrisă (sau „ștersă”) pe unitatea de disc fizică înainte de tranzacția care face referire la datele respective să fie difuzate în rețea. În caz contrar, dacă nodul a avut ghinionul să piardă puterea imediat după difuzarea tranzacției, datele din afara lanțului ar putea fi pierdute definitiv. Aceasta nu este o problemă pentru MultiChain în sine, deoarece întârzierile dintre încercările de recuperare a unei bucăți cresc automat în timp. Dar ar putea cauza probleme la nivelul aplicației, unde toată lumea știe de existența unor date, dar nimeni nu este capabil să le găsească.
Performanță publicistică. Prin eliminarea datelor din lanț pe disc în acest fel, MultiChain poate suferi o penalizare de performanță, deoarece discurile fizice sunt lente. De exemplu, un hard disk de 7200 rpm de rpm poate efectua doar aproximativ 100 de scrieri aleatorii de date pe secundă, limitând, la rândul său, rata la care un nod individual poate publica articole în afara lanțului. Există trei soluții posibile pentru această problemă. În primul rând și cel mai simplu, nodurile pot folosi o unitate SSD în loc de un hard disk obișnuit, care acceptă 10,000 de operații de scriere aleatoare pe secundă. În al doilea rând, mai multe articole în afara lanțului pot fi publicate într-o singură tranzacție folosind API-ul „createrawsendfrom”. În acest caz, MultiChain scrie toate datele în afara lanțului la care face referire o tranzacție într-o singură operație de disc. În cele din urmă, MultiChain poate fi configurat pentru a nu șterge datele în afara lanțului pe disc înainte de a difuza tranzacția care face referire la aceasta. Utilizați această opțiune cu grijă.
Integrarea monedei native. Pentru cazurile de utilizare care necesită acest lucru, MultiChain a oferit întotdeauna opțiunea de a folosi o monedă nativă pe un blockchain pentru a preveni spam-ul tranzacțiilor și/sau a stimula validatorii de bloc („minerii”). În aceste cazuri, tranzacțiile trebuie să ofere minerilor o taxă minimă proporțională cu dimensiunea lor în octeți, pentru a fi transmise și confirmate în lanț. Acest mecanism a fost extins pentru a permite prevenirea spam-ului în afara lanțului, prin solicitarea unei taxe suplimentare minime pe kilobyte de date în afara lanțului la care se face referire într-o tranzacție.
Nodurile de arhivare. Dacă un nod dorește să se aboneze la fiecare flux și, prin urmare, să preia și să stocheze fiecare articol publicat în afara lanțului, poate fi configurat să facă acest lucru utilizând parametrul de rulare „autosubscribe”. Orice astfel de nod va acționa ca o rezervă pentru întreaga rețea, garantând că elementele din afara lanțului nu vor fi pierdute sau indisponibile, indiferent de ce alte noduri dispar. Ne putem imagina companii terțe care oferă acest lucru ca un serviciu comercial.