Scaling Blockchains With Off-chain Data

Ripubblicato da Platone

Seguaci: 0

Quando un hash vale un milione di parole

Ormai è chiaro che molti casi d'uso della blockchain non hanno nulla a che fare con le transazioni finanziarie. Lo scopo della catena è invece quello di abilitare l'aggregazione decentralizzata, l'ordinamento, la marcatura temporale e l'archiviazione di in qualsiasi tipo di informazioni, inclusi dati strutturati, corrispondenza o documentazione. Il valore fondamentale della blockchain è consentire ai suoi partecipanti di concordare in modo dimostrabile e permanente esattamente quali dati sono stati inseriti, quando e da chi, senza fare affidamento su un intermediario di fiducia. Ad esempio, SAP è stato lanciato di recente piattaforma blockchain, che supporta MultiChain e Hyperledger Fabric, si rivolge a un'ampia gamma di supply chain e altre applicazioni non finanziarie.

Il modo più semplice per utilizzare una blockchain per la registrazione dei dati è incorporare ogni dato direttamente all'interno di una transazione. Ogni transazione blockchain viene firmata digitalmente da una o più parti, replicata su ogni nodo, ordinata e timestampata dall'algoritmo di consenso della catena e memorizzata in modo permanente a prova di manomissione. Qualsiasi dato all'interno della transazione verrà quindi archiviato in modo identico ma indipendente da ogni nodo, insieme a una prova di chi lo ha scritto e quando. Gli utenti della catena potranno recuperare queste informazioni in qualsiasi momento futuro.

Ad esempio, MultiChain 1.0 ha consentito la creazione di uno o più "flussi" denominati su una blockchain e quindi utilizzati per l'archiviazione e il recupero di dati grezzi. Ogni stream ha il proprio set di permessi di scrittura e ogni nodo può scegliere liberamente a quali stream iscriversi. Se un nodo è iscritto a uno stream, indicizza il contenuto dello stream in tempo reale, consentendo agli elementi di essere recuperati rapidamente in base al loro ordine, timestamp, numero di blocco o indirizzo dell'editore, nonché tramite una "chiave" (o etichetta) con cui gli elementi possono essere etichettati. MultiChain 2.0 (dalla versione alpha 1) ha esteso i flussi per supportare testo Unicode o dati JSON, oltre a più chiavi per articolo e più articoli per transazione. Ha anche aggiunto funzioni di riepilogo come "unione JSON" che combinano elementi con la stessa chiave o editore in modo utile.

Riservatezza e scalabilità

Sebbene l'archiviazione dei dati direttamente su una blockchain funzioni bene, soffre di due principali carenze: riservatezza e scalabilità. Per cominciare con la riservatezza, il contenuto di ogni elemento del flusso è visibile a ogni nodo della catena e questo non è necessariamente un risultato desiderabile. In molti casi un dato dovrebbe essere visibile solo a un certo sottoinsieme di nodi, anche se sono necessari altri nodi per aiutarne l'ordinamento, la marcatura temporale e l'autenticazione.

La riservatezza è un problema relativamente facile da risolvere, crittografando le informazioni prima che vengano incorporate in una transazione. La chiave di decrittografia per ogni pezzo di dati viene condivisa solo con quei partecipanti che dovrebbero vederlo. La consegna delle chiavi può essere eseguita on-chain utilizzando la crittografia asimmetrica (come descritto qui) o tramite un meccanismo fuori catena, come si preferisce. Qualsiasi nodo privo della chiave per decrittografare un elemento non vedrà altro che binari incomprensibili.

La scalabilità, d'altra parte, è una sfida più significativa. Diciamo che qualsiasi piattaforma blockchain decente dovrebbe supportare un throughput di rete di 500 transazioni al secondo. Se lo scopo della catena è l'archiviazione delle informazioni, la dimensione di ciascuna transazione dipenderà principalmente dalla quantità di dati che contiene. Ogni transazione richiederà anche (almeno) 100 byte di overhead per memorizzare l'indirizzo del mittente, la firma digitale e pochi altri bit e pezzi.

Se prendiamo un caso semplice, in cui ogni elemento è una piccola struttura JSON di 100 byte, il throughput complessivo dei dati sarebbe di 100 kilobyte al secondo, calcolato da 500 × (100 + 100). Ciò si traduce in meno di 1 megabit / secondo di larghezza di banda, che è comodamente nella capacità di qualsiasi connessione Internet moderna. I dati si accumulerebbero a una velocità di circa 3 terabyte all'anno, che non è una piccola quantità. Ma con dischi rigidi da 12 terabyte ora ampiamente disponibilee RAID controller che combinano più unità fisiche in una singola logica, potremmo facilmente memorizzare 10-20 anni di dati su ogni nodo senza troppi problemi o spese.

Tuttavia, le cose sembrano molto diverse se memorizziamo informazioni più grandi, come la documentazione scansionata. Una scansione JPEG di qualità ragionevole di un foglio di carta A4 potrebbe avere una dimensione di 500 kilobyte. Moltiplicalo per 500 transazioni al secondo e stiamo guardando un throughput di 250 megabyte al secondo. Ciò si traduce in 2 gigabit / secondo di larghezza di banda, che è più veloce della maggior parte delle reti locali, per non parlare delle connessioni a Internet. Al più economico di Amazon Web Services prezzo pubblicato di $ 0.05 per gigabyte, significa un conto annuale della larghezza di banda di $ 400,000 per nodo. E dove ogni nodo memorizzerà gli 8000 terabyte di nuovi dati generati ogni anno?

È chiaro che, per le applicazioni blockchain che memorizzano molti grandi pezzi di dati, l'archiviazione su catena semplice non è una scelta pratica. Per aggiungere la beffa al danno, se i dati vengono crittografati per risolvere il problema della riservatezza, ai nodi viene chiesto di memorizzare un'enorme quantità di informazioni che non possono nemmeno leggere. Questa non è una proposta attraente per i partecipanti alla rete.

La soluzione di hashing

Allora come risolviamo il problema della scalabilità dei dati? Come possiamo trarre vantaggio dalla notarizzazione decentralizzata dei dati della blockchain, senza replicare quei dati su ogni nodo della catena?

La risposta è con un pezzo di tecnologia intelligente chiamato "hash". Un hash è un numero lungo (pensa a 256 bit o circa 80 cifre decimali) che identifica in modo univoco un dato. L'hash viene calcolato dai dati utilizzando un file funzione a senso unico che ha un'importante proprietà crittografica: dato qualsiasi dato, è facile e veloce calcolarne l'hash. Ma dato un particolare hash, è impossibile dal punto di vista computazionale trovare un pezzo di dati che genererebbe quell'hash. E quando diciamo "computazionalmente non fattibile", intendiamo più calcoli di quanti siano gli atomi nell'universo conosciuto.

Gli hash svolgono un ruolo cruciale in tutte le blockchain, identificando in modo univoco transazioni e blocchi. Sono anche alla base della sfida computazionale nei sistemi proof-of-work come bitcoin. Sono state sviluppate molte funzioni hash differenti, con nomi incomprensibili come BLAKE2, MD5 e RIPEMD160. Ma affinché qualsiasi funzione di hash sia attendibile, deve sopportare un'ampia revisione e test accademici. Questi test si presentano sotto forma di tentativi di attacco, come "preimage" (trovare un input con l'hash dato), "second preimage" (trovare un secondo input con lo stesso hash dell'input fornito) e "collision" (trovare qualsiasi due diversi input con lo stesso hash). Sopravvivere a questo guanto di sfida è tutt'altro che facile, con una lunga e tragica storia di funzioni hash interrotte che dimostrano la famosa massima: "Non lanciare la tua crittografia".

Per tornare al nostro problema originale, possiamo risolvere la scalabilità dei dati nelle blockchain incorporando gli hash di grandi quantità di dati all'interno delle transazioni, invece dei dati stessi. Ogni hash agisce come un "impegno" per i suoi dati di input, con i dati stessi che vengono archiviati al di fuori della blockchain o "off-chain". Ad esempio, utilizzando la popolare funzione hash SHA256, un'immagine JPEG da 500 kilobyte può essere rappresentata da un numero di 32 byte, una riduzione di oltre 15,000 ×. Anche a una velocità di 500 immagini al secondo, questo ci riporta comodamente nel territorio dei requisiti di larghezza di banda e archiviazione fattibili, in termini di dati memorizzati sulla catena stessa.

Ovviamente, qualsiasi partecipante blockchain che abbia bisogno di un'immagine fuori catena non può riprodurla dal suo hash. Ma se l'immagine può essere recuperata in qualche altro modo, l'hash on-chain serve a confermare chi l'ha creata e quando. Proprio come i normali dati sulla catena, l'hash è incorporato in una transazione firmata digitalmente, che è stata inclusa nella catena per consenso. Se un file immagine cade dal cielo e l'hash per quell'immagine corrisponde a un hash nella blockchain, l'origine e il timestamp di quell'immagine sono confermati. Quindi la blockchain fornisce esattamente lo stesso valore in termini di autenticazione notarile come se l'immagine fosse incorporata direttamente nella catena.

Una questione di consegna

Fin qui tutto bene. Incorporando gli hash in una blockchain invece dei dati originali, abbiamo una facile soluzione al problema della scalabilità. Tuttavia, rimane una domanda cruciale:

Come forniamo il contenuto originale fuori catena a quei nodi che ne hanno bisogno, se non attraverso la catena stessa?

Questa domanda ha diverse possibili risposte e sappiamo che gli utenti MultiChain le applicano tutte. Un approccio di base consiste nell'impostare un archivio centralizzato presso una parte fidata, in cui tutti i dati fuori catena vengono caricati e successivamente recuperati. Questo sistema potrebbe naturalmente utilizzare l '"indirizzamento del contenuto", il che significa che l'hash di ogni pezzo di dati serve direttamente come identificatore per il recupero. Tuttavia, anche se questa configurazione potrebbe funzionare per un proof-of-concept, non ha senso per la produzione, perché il punto centrale di una blockchain è rimuovere intermediari fidati. Anche se gli hash on-chain impediscono all'intermediario di falsificare i dati, potrebbe comunque cancellare i dati o non fornirli ad alcuni partecipanti, a causa di un guasto tecnico o delle azioni di un dipendente disonesto.

Una possibilità più promettente è la comunicazione punto-punto, in cui il nodo che richiede alcuni dati fuori catena lo richiede direttamente dal nodo che lo ha pubblicato. Questo evita di fare affidamento su un intermediario fidato, ma soffre di tre carenze alternative:

Richiede una mappa degli indirizzi blockchain agli indirizzi IP, per consentire al consumatore di alcuni dati di comunicare direttamente con il suo editore. Le blockchain possono generalmente evitare questo tipo di configurazione di rete statica, che può essere un problema in termini di failover e privacy.
Se il nodo del publisher originale ha lasciato la rete o è temporaneamente fuori servizio, i dati non possono essere recuperati da nessun altro.
Se un numero elevato di nodi è interessato ad alcuni dati, l'editore sarà sopraffatto dalle richieste. Ciò può creare una grave congestione della rete, rallentare il sistema dell'editore e portare a lunghi ritardi per coloro che tentano di recuperare quei dati.

Per evitare questi problemi, utilizzeremmo idealmente una sorta di meccanismo di consegna decentralizzato. I nodi dovrebbero essere in grado di recuperare i dati di cui hanno bisogno senza fare affidamento su un singolo sistema, sia esso un repository centralizzato o l'editore originale dei dati. Se più parti dispongono di un dato, dovrebbero condividere l'onere di fornirlo a chiunque lo desideri. Nessuno deve fidarsi di una singola origine dati, perché gli hash on-chain possono dimostrare che i dati non sono stati manomessi. Se un nodo dannoso mi fornisce i dati sbagliati per un hash, posso semplicemente scartare quei dati e provare a chiedere a qualcun altro.

Per coloro che hanno esperienza con condivisione di file peer-to-peer protocolli come Napster, Gnutella o BitTorrent, suoneranno tutti molto familiari. In effetti, molti dei principi di base sono gli stessi, ma ci sono due differenze fondamentali. In primo luogo, supponendo di utilizzare la nostra blockchain in un contesto aziendale, il sistema funziona all'interno di un gruppo chiuso di partecipanti, piuttosto che su Internet nel suo insieme. In secondo luogo, la blockchain aggiunge una spina dorsale decentralizzata di ordinazione, marcatura temporale e autenticazione, consentendo a tutti gli utenti di mantenere una visione comprovabilmente coerente ea prova di manomissione di ciò che è successo esattamente, quando e da chi.

In che modo uno sviluppatore di applicazioni blockchain potrebbe ottenere questa consegna decentralizzata di contenuti fuori catena? Una scelta comune è quella di prendere una piattaforma di condivisione di file peer-to-peer esistente, come quella dal nome divertente File system interPlanetary (IPFS) e usalo insieme alla blockchain. Ogni partecipante esegue sia un nodo blockchain che un nodo IPFS, con un middleware coordinato tra i due. Quando si pubblicano dati fuori catena, questo middleware archivia i dati originali in IPFS, quindi crea una transazione blockchain contenente l'hash di quei dati. Per recuperare alcuni dati fuori catena, il middleware estrae l'hash dalla blockchain, quindi utilizza questo hash per recuperare il contenuto da IPFS. Il nodo IPFS locale verifica automaticamente il contenuto recuperato rispetto all'hash per assicurarsi che non sia stato modificato.

Sebbene questa soluzione sia possibile, è tutto piuttosto goffo e scomodo. Innanzitutto, ogni partecipante deve installare, mantenere e aggiornare tre parti separate di software (nodo blockchain, nodo IPFS e middleware), ciascuna delle quali memorizza i propri dati in un luogo separato. In secondo luogo, ci saranno due reti peer-to-peer separate, ciascuna con la propria configurazione, porte di rete, sistema di identità e autorizzazioni (anche se va notato che IPFS non supporta ancora le reti chiuse). Infine, unire insieme IPFS e blockchain renderebbe il middleware sempre più complesso. Ad esempio, se vogliamo che i dati off-chain a cui fanno riferimento alcune transazioni blockchain vengano recuperati immediatamente (con tentativi automatici), il middleware dovrebbe essere costantemente attivo e funzionante, mantenendo il proprio stato complesso. Non sarebbe bello se il nodo blockchain facesse tutto questo per noi?

Dati off-chain in MultiChain 2.0

Oggi siamo lieti di rilasciare il terza versione in anteprima (alpha 3) di MultiChain 2.0, con una soluzione completamente integrata e senza soluzione di continuità per i dati fuori catena. Ogni informazione pubblicata in un flusso può essere on-chain o off-chain, come desiderato e MultiChain si occupa di tutto il resto.

No davvero, intendiamo qualunque cosa. In qualità di sviluppatore basato su MultiChain, non dovrai preoccuparti di hash, archiviazione locale, scoperta di contenuti, consegna decentralizzata o verifica dei dati. Ecco cosa succede dietro le quinte:

Il nodo MultiChain di pubblicazione scrive i nuovi dati nella sua memoria locale, suddividendo elementi di grandi dimensioni in blocchi per una facile digestione e consegna.
La transazione per la pubblicazione di elementi del flusso fuori catena viene creata automaticamente, contenente gli hash dei blocchi e le dimensioni in byte.
Questa transazione viene firmata e trasmessa alla rete, propagandosi tra i nodi ed entrando nella blockchain nel solito modo.
Quando un nodo sottoscritto a un flusso vede un riferimento ad alcuni dati fuori catena, aggiunge gli hash del blocco per quei dati alla sua coda di recupero. (Quando ci si iscrive a un vecchio flusso, un nodo accoda anche tutti gli elementi fuori catena precedentemente pubblicati per il recupero.)
Come processo in background, se sono presenti blocchi nella coda di recupero di un nodo, le query vengono inviate alla rete per individuare quei blocchi, come identificato dai loro hash.
Queste query di blocchi vengono propagate ad altri nodi della rete in modo peer-to-peer (limitato a due hop per ora - vedere i dettagli tecnici di seguito).
Qualsiasi nodo che dispone dei dati per un blocco può rispondere e questa risposta viene ritrasmessa all'abbonato lungo lo stesso percorso della query.
Se nessun nodo risponde alla query del blocco, il blocco viene restituito alla coda per un successivo tentativo.
In caso contrario, l'abbonato sceglie la fonte più promettente per un blocco (in base ai salti e al tempo di risposta) e gli invia una richiesta per i dati di quel blocco, sempre lungo lo stesso percorso peer-to-peer della risposta precedente.
Il nodo di origine fornisce i dati richiesti, utilizzando di nuovo lo stesso percorso.
L'abbonato verifica la dimensione e l'hash dei dati rispetto alla richiesta originale.
Se tutto va a buon fine, l'abbonato scrive i dati nella sua memoria locale, rendendoli immediatamente disponibili per il recupero tramite le API del flusso.
Se il contenuto richiesto non è arrivato o non corrisponde all'hash o alla dimensione desiderati, il blocco viene restituito alla coda per il recupero futuro da un'origine diversa.

Soprattutto, tutto ciò avviene in modo estremamente rapido. Nelle reti a bassa latenza, piccoli pezzi di dati fuori catena arriveranno agli abbonati entro una frazione di secondo dalla transazione che fa riferimento a loro. E per le applicazioni ad alto carico, i nostri test mostrano che MultiChain 2.0 alpha 3 può sostenere un tasso di oltre 1000 elementi fuori catena o 25 MB di dati fuori catena recuperati al secondo, su un server di fascia media (Core i7) con un discreto Connessione internet. Tutto funziona bene con elementi off-chain fino a 1 GB di dimensione, ben oltre il limite di 64 MB per i dati on-chain. Ovviamente, speriamo di migliorare ulteriormente questi numeri mentre dedichiamo del tempo all'ottimizzazione di MultiChain 2.0 durante la sua fase beta.

Quando si utilizzano dati off-chain piuttosto che on-chain nei flussi, gli sviluppatori di applicazioni MultiChain devono fare esattamente due cose:

Quando si pubblicano dati, passare un flag "offchain" alle API appropriate.
Quando si utilizzano le API di query del flusso, considerare la possibilità che alcuni dati off-chain potrebbero non essere ancora disponibili, come riportato dal flag "available". Sebbene questa situazione sia rara in circostanze normali, è importante che gli sviluppatori di applicazioni la gestiscano in modo appropriato.

Ovviamente, per evitare che ogni nodo recuperi ogni elemento fuori catena, gli elementi dovrebbero essere raggruppati insieme in flussi in modo appropriato, con ogni nodo che si iscrive a quei flussi di interesse.

Gli elementi in catena e fuori catena possono essere utilizzati all'interno dello stesso flusso e le varie funzioni di query e riepilogo del flusso si riferiscono a entrambi i tipi di dati in modo identico. Ciò consente agli editori di fare la scelta appropriata per ogni elemento in un flusso, senza influire sul resto dell'applicazione. Ad esempio, un flusso di elementi JSON sulle attività delle persone potrebbe utilizzare dati off-chain per l'identificazione personale delle informazioni e dati on-chain per il resto. Gli abbonati possono utilizzare l'unione JSON di MultiChain per combinare entrambi i tipi di informazioni in un unico JSON per la lettura.

Se vuoi provare gli elementi del flusso fuori catena, segui il normale MultiChain Iniziamo tutorial e assicurati di non saltare la sezione 5.

Allora, qual è il prossimo?

Con il supporto senza soluzione di continuità per i dati fuori catena, MultiChain 2.0 offrirà un grande passo avanti per le applicazioni blockchain incentrate su timestamp e autenticazione dei dati su larga scala. A lungo termine, stiamo già pensando a un sacco di possibili miglioramenti futuri a questa funzione per le edizioni Community e / o Enterprise di MultiChain:

Implementazione del flusso read autorizzazioni utilizzando una combinazione di elementi off-chain, hash salati, query di blocchi firmati e consegna crittografata.
Consentire che i dati off-chain siano esplicitamente "dimenticati", sia volontariamente dai singoli nodi, sia da tutti i nodi in risposta a un messaggio on-chain.
Sottoscrizioni di flussi selettivi, in cui i nodi recuperano solo i dati per gli elementi fuori catena con particolari editori o chiavi.
utilizzando alberi di merkle consentire a un singolo hash on-chain di rappresentare un numero illimitato di elementi off-chain, dando un altro enorme salto in termini di scalabilità.
Motori di archiviazione collegabili, che consentono di conservare i dati fuori catena in database o file system esterni anziché su disco locale.
Nodi che apprendono nel tempo dove ogni tipo di dati fuori catena è solitamente disponibile in una rete e focalizzano adeguatamente le loro query di blocco.

Ci piacerebbe ascolta il tuo feedback nell'elenco sopra così come gli articoli fuori catena in generale. Con MultiChain 2.0 ancora ufficialmente in alpha, c'è tutto il tempo per migliorare questa funzione prima del suo rilascio finale.

Nel frattempo, abbiamo già iniziato a lavorare su "Filtri intelligenti", l'ultima grande funzionalità pianificata per la comunità MultiChain 2.0. Uno Smart Filter è un pezzo di codice incorporato nella blockchain che implementa regole personalizzate per la convalida di dati o transazioni. I filtri intelligenti hanno alcune somiglianze con i "contratti intelligenti" e possono fare molte delle stesse cose, ma presentano differenze fondamentali in termini di sicurezza e prestazioni. Non vediamo l'ora di dirti di più a tempo debito.

Si prega di inviare eventuali commenti LinkedIn.

Dettagli tecnici

Sebbene gli elementi del flusso fuori catena in MultiChain 2.0 siano semplici da usare, contengono molte decisioni di progettazione e funzionalità aggiuntive che potrebbero essere di interesse. L'elenco seguente sarà principalmente rilevante per gli sviluppatori che creano applicazioni blockchain e può essere ignorato da tipi meno tecnici:

Criteri per flusso. Quando viene creato un flusso MultiChain, può essere facoltativamente limitato per consentire solo dati in catena o fuori catena. Ci sono diverse possibili ragioni per farlo, piuttosto che consentire a ciascun editore di decidere autonomamente. Ad esempio, gli articoli in catena offrono una garanzia di disponibilità ferrea, mentre i vecchi articoli fuori catena potrebbero diventare irrecuperabili se il loro editore e altri abbonati abbandonano la rete. Il rovescio della medaglia, gli elementi in catena non possono essere "dimenticati" senza modificare la blockchain, mentre gli elementi fuori catena sono più flessibili. Questo può essere importante in termini di regole sulla privacy dei dati, come i nuovi regolamenti europei GDPR.
Metadati in catena. Per gli articoli fuori catena, la transazione in catena contiene ancora gli editori, le chiavi, il formato (JSON, testo o binario) e le dimensioni totali dell'articolo. Tutto ciò occupa pochissimo spazio e aiuta gli sviluppatori di applicazioni a determinare se l'indisponibilità di un elemento fuori catena è un problema per una particolare query di flusso.
Limite di due hop. Quando si inoltrano query di blocchi sulla rete peer-to-peer, esiste un compromesso tra raggiungibilità e prestazioni. Anche se sarebbe bello che ogni query fosse propagata lungo ogni singolo percorso, questo può intasare la rete con inutili "chiacchiere". Quindi per ora le query di blocco sono limitate a due hop, il che significa che un nodo può recuperare i dati fuori catena da qualsiasi peer dei suoi pari. Nelle reti più piccole con meno di 1000 nodi che tendono a caratterizzare le blockchain aziendali, riteniamo che funzionerà bene, ma è facile per noi regolare questo vincolo (o offrirlo come parametro) se ci riveliamo sbagliato.
Memoria locale. Ogni nodo MultiChain memorizza i dati fuori catena nella directory "chunks" della sua normale directory blockchain, utilizzando un formato binario efficiente e un indice LevelDB. Una sottodirectory separata viene utilizzata per gli elementi in ciascuno dei flussi sottoscritti, nonché per quelli pubblicati dal nodo stesso. All'interno di ciascuna di queste sottodirectory, i blocchi duplicati (con lo stesso hash) vengono archiviati solo una volta. Quando un nodo annulla l'iscrizione a un flusso, può scegliere se eliminare o meno i dati fuori catena recuperati per quel flusso.
Cache binaria. Quando si pubblicano grandi quantità di dati binari, sia on-chain che off-chain, potrebbe non essere pratico per gli sviluppatori di applicazioni inviare tali dati all'API di MultiChain in una singola richiesta JSON-RPC. Quindi MultiChain 2.0 implementa una cache binaria, che consente di creare grandi quantità di dati su più chiamate API e quindi di pubblicare in un breve passaggio finale. Ogni elemento nella cache binaria viene memorizzato come un semplice file nella sottodirectory "cache" della directory blockchain, consentendo anche il push di gigabyte di dati direttamente tramite il file system.
API di monitoraggio. MultiChain 2.0 alpha 3 aggiunge due nuove API per il monitoraggio del recupero asincrono dei dati fuori catena. La prima API descrive lo stato corrente della coda, mostrando quanti blocchi (e quanti dati) sono in attesa o vengono interrogati o recuperati. La seconda API fornisce statistiche aggregate per tutte le query di blocco e le richieste inviate dall'avvio del nodo, inclusi i conteggi dei diversi tipi di errore.
Flush in pubblicazione. Quando si pubblica un elemento fuori catena, MultiChain garantisce che la sua copia locale dei dati sia completamente scritta (o "scaricata") sull'unità disco fisica prima che la transazione che fa riferimento a quei dati venga trasmessa alla rete. Altrimenti, se il nodo è stato così sfortunato da perdere potenza immediatamente dopo aver trasmesso la transazione, i dati fuori catena potrebbero andare persi in modo permanente. Questo non è un problema per MultiChain stesso, poiché i ritardi tra i tentativi di recupero di un blocco crescono automaticamente nel tempo. Ma potrebbe causare problemi a livello applicativo, dove tutti sanno dell'esistenza di alcuni dati ma nessuno è in grado di trovarli.
Prestazioni editoriali. Svuotando i dati fuori catena su disco in questo modo, MultiChain può incorrere in una riduzione delle prestazioni, poiché i dischi fisici sono lenti. Ad esempio, un disco rigido di fascia media da 7200 rpm può eseguire solo circa 100 scritture di dati casuali al secondo, limitando a sua volta la velocità con cui un singolo nodo può pubblicare elementi fuori catena. Esistono tre possibili soluzioni per questo problema. Innanzitutto e più semplicemente, i nodi possono utilizzare un'unità SSD (Solid State Device) invece di un normale disco rigido, che supporta 10,000 operazioni di scrittura casuale al secondo. In secondo luogo, più articoli fuori catena possono essere pubblicati in una singola transazione utilizzando l'API "createrawsendfrom". In questo caso, MultiChain scrive tutti i dati fuori catena a cui fa riferimento una transazione in una singola operazione su disco. Infine, MultiChain può essere configurato per non scaricare i dati fuori catena su disco prima di trasmettere la transazione a cui fa riferimento. Usa questa opzione con attenzione.
Integrazione della valuta nativa. Per i casi d'uso che lo richiedono, MultiChain ha sempre offerto la possibilità di utilizzare una valuta nativa su una blockchain per prevenire lo spam delle transazioni e / o incentivare i validatori di blocchi ("minatori"). In questi casi, le transazioni devono offrire ai minatori una commissione minima proporzionale alla loro dimensione in byte, per essere inoltrate e confermate sulla catena. Questo meccanismo è stato esteso per consentire la prevenzione dello spam off-chain, richiedendo una tariffa aggiuntiva minima per kilobyte di dati off-chain a cui si fa riferimento in una transazione.
Nodi di archiviazione. Se un nodo desidera iscriversi a ogni flusso, e quindi recuperare e memorizzare ogni elemento fuori catena pubblicato, può essere configurato per farlo utilizzando il parametro di runtime "autosubscribe". Qualsiasi nodo di questo tipo fungerà da backup per l'intera rete, garantendo che gli elementi fuori catena non andranno persi o non saranno disponibili, indipendentemente dagli altri nodi che scompaiono. Si possono immaginare società di terze parti che lo offrono come servizio commerciale.