Note su HyperChain Streams

Per database di valori-chiave e serie temporali immutabili condivisi

Oggi siamo orgogliosi di rilasciare l’ultima versione di Hyperchain, che implementa una nuova serie cruciale di funzionalità chiamata “stream”. Gli stream forniscono un’astrazione naturale per i casi d’uso della blockchain che si concentrano sul recupero generale dei dati, il timestamp e l’archiviazione, piuttosto che sul trasferimento di risorse tra i partecipanti. Gli stream possono essere utilizzati per implementare tre diversi tipi di database su una catena:

Un database di valori-chiave o archivio documenti, nello stile di NoSQL.
Un database di serie temporali, che si concentra sull’ordinamento delle voci.
Un database basato sull’identità in cui le voci sono classificate in base al loro autore.

Questi possono essere considerati come “cosa”, “quando” e “chi” di un database condiviso.

Nozioni di base sui flussi

Qualsiasi numero di flussi può essere creato in una blockchain Hyperchain e ogni flusso agisce come una raccolta indipendente di soli articoli di appendice. Ogni elemento in uno stream ha le seguenti caratteristiche:

Uno o più editori che hanno firmato digitalmente quell’elemento.
Una chiave opzionale per un comodo recupero successivo.
Alcuni dati che possono variare da un piccolo pezzo di testo a molti megabyte di file binario non elaborato.
Un timestamp , che viene preso dall’intestazione del blocco in cui l’elemento è confermato.

Dietro le quinte, ogni elemento in uno stream è rappresentato da una transazione blockchain, ma gli sviluppatori possono leggere e scrivere flussi senza consapevolezza di questo meccanismo sottostante. (Gli utenti più esperti possono utilizzare le transazioni non elaborate per scrivere su più flussi, emettere o trasferire risorse e / o assegnare autorizzazioni in una singola transazione atomica.)

Gli stream si integrano con il sistema di autorizzazioni di Hyperchain in vari modi. In primo luogo, i flussi possono essere creati solo da coloro che hanno il permesso di farlo, allo stesso modo in cui i beni possono essere emessi solo da determinati indirizzi. Quando viene creato uno stream, questo è aperto o chiuso. I flussi aperti sono scrivibili da chiunque abbia il permesso di inviare una transazione blockchain, mentre i flussi chiusi sono limitati a un elenco modificabile di indirizzi consentiti. In quest’ultimo caso, ogni flusso ha uno o più amministratori che possono modificare tali autorizzazioni di scrittura nel tempo.

Ogni blockchain ha un flusso ‘root’ opzionale, che è definito nei suoi parametri ed esiste dal momento in cui viene creata la catena. Ciò consente di utilizzare immediatamente una blockchain per l’archiviazione e il recupero dei dati, senza attendere la creazione esplicita di un flusso.

Come ho discusso, la riservatezza è la più grande sfida in un gran numero di casi d’uso di blockchain. Questo perché ogni nodo in una blockchain vede una copia completa del contenuto dell’intera catena. Gli stream forniscono un modo naturale per supportare i dati crittografati su una blockchain, come segue:

Uno stream viene utilizzato dai partecipanti per distribuire le loro chiavi pubbliche per qualsiasi schema di crittografia a chiave pubblica.
Un secondo flusso viene utilizzato per pubblicare dati, in cui ogni parte di dati viene crittografata utilizzando la crittografia simmetrica con una chiave univoca.
Un terzo flusso fornisce l’accesso ai dati. Per ogni partecipante che dovrebbe visualizzare una parte di dati, viene creata una voce di flusso che contiene la chiave segreta di tali dati, crittografata utilizzando la chiave pubblica di quel partecipante.

Ciò fornisce un modo efficiente per archiviare i dati su una blockchain, rendendoli visibili solo a determinati partecipanti.

Recupero da flussi

Il valore fondamentale degli stream è nell’indicizzazione e nel recupero. Ogni nodo può scegliere a quali flussi iscriversi, con la blockchain che garantisce che tutti i nodi che si iscrivono a un determinato flusso vedranno gli stessi elementi all’interno. (Un nodo può anche essere configurato per iscriversi automaticamente a ogni nuovo flusso creato.)

Se un nodo è abbonato a un flusso, le informazioni possono essere recuperate da quel flusso in vari modi:

Recupero di elementi dallo stream in ordine.
Recupero di elementi con una chiave particolare.
Recupero di elementi firmati da un determinato editore.
Elenco delle chiavi utilizzate in uno stream, con conteggi degli elementi per ciascuna chiave.
Elenco dei publisher in uno stream, con conteggi degli articoli.

Come accennato all’inizio, questi metodi di recupero consentono flussi da utilizzare per i database chiave-valore, basi di dati di serie temporali e database identity-driven. Tutte le API di recupero offrono parametri di avvio e conteggio, consentendo di recuperare in modo efficiente le sottosezioni di lunghi elenchi (come una clausola LIMIT in SQL). I valori negativi per l’avvio consentono di recuperare gli elementi più recenti.

Gli stream possono contenere più elementi con la stessa chiave e questo risolve naturalmente la tensione tra l’immutabilità della blockchain e la necessità di aggiornare un database. A ogni ‘voce’ del database efficace deve essere assegnata una chiave univoca nella propria applicazione, con ogni aggiornamento di quella voce rappresentato da un nuovo elemento di flusso con la sua chiave. Le API di recupero stream di Hyperchain possono quindi essere utilizzate per: (a) recuperare la prima o l’ultima versione di una determinata voce, (b) recuperare una cronologia completa delle versioni per una voce, (c) recuperare informazioni su più voci, tra cui la prima e l’ultima versioni di ciascuno.

Si noti che a causa dell’architettura peer-to-peer di una blockchain, gli elementi in uno stream possono arrivare a nodi diversi in ordini diversi e Hyperchain consente di recuperare gli elementi prima che vengano “confermati” in un blocco. Di conseguenza,

tutte le API di recupero offrono una scelta tra ordinamento globale (predefinito) o locale. L’ordinamento globale garantisce che, una volta che la catena ha raggiunto il consenso, tutti i nodi ricevono le stesse risposte dalle stesse chiamate API. L’ordinamento locale garantisce che, per qualsiasi nodo particolare, l’ordinamento degli articoli di uno stream non cambierà mai tra le chiamate API. Ogni applicazione può fare la scelta appropriata per le sue esigenze.

Stream e la roadmap di Hyperchain

Con il rilascio di stream, abbiamo completato l’ultimo importante lavoro per Hyperchain 2.0 e ora siamo fermamente sulla strada per la beta. Ci aspettiamo di dedicare i prossimi mesi all’espansione della nostra suite di test interni (già abbastanza grande!), Al completamento delle porte Windows e Mac, all’aggiunta di alcune API più utili, all’aggiornamento di Explorer per flussi, all’ottimizzazione degli aspetti del meccanismo di consenso, alla pubblicazione della demo Web e in generale riordinando il codice e i messaggi di aiuto. Soprattutto, continueremo a correggere eventuali bug non appena vengono scoperti, in modo che i nostri errori non interrompano il tuo lavoro.

A più lungo termine, dove si inseriscono i flussi nella roadmap di Hyperchain? Facendo un passo indietro, Hyperchain offre ora tre aree di funzionalità di alto livello:

Autorizzazioni per controllare chi può connettersi, effettuare transazioni, creare risorse / flussi, estrarre / convalidare e amministrare.
Attività comprese l’emissione, la riemissione, il trasferimento, lo scambio atomico, l’impegno e la distruzione.
Streaming con API per la creazione di stream, scrittura, iscrizione, indicizzazione e recupero.

Dopo il rilascio di Hyperchain 2.0 , quali sono le novità in questo elenco? Se guardi il comando API che viene utilizzato per creare flussi, noterai un parametro apparentemente superfluo, con un valore fisso di stream. Questo parametro consentirà a Hyperchain di supportare altri tipi di entità di alto livello in futuro.

I possibili valori futuri per il parametro includono evm(per una macchina virtuale compatibile con Ethereum ), sql(per un database in stile SQL) o anche wiki(per testo modificato in collaborazione). Qualsiasi entità condivisa il cui stato è determinato da una serie ordinata di modifiche è un potenziale candidato. Ciascuna di tali entità avrà bisogno di: (a) API che forniscano la giusta astrazione per aggiornare il proprio stato, (b) meccanismi appropriati per i nodi sottoscritti per tracciare tale stato e (c) API per recuperare in modo efficiente parte o tutto lo stato. Stiamo aspettando di scoprire quali altre entità di alto livello sarebbero più utili, da implementare da noi o da terze parti tramite un’architettura plug-in.

E i contratti intelligenti?

In senso generale, Hyperchain adotta l’approccio in cui i dati sono incorporati immutabilmente in una blockchain, ma il codice per interpretare tali dati si trova nel nodo o nel livello dell’applicazione. Questo è deliberatamente diverso dal paradigma dei “contratti intelligenti”, come esemplificato da Ethereum, in cui il codice è incorporato nella blockchain e viene eseguito in una macchina virtuale. In teoria, poiché i contratti intelligenti sono completi di Turing , possono riprodurre il comportamento di Hyperchain o di qualsiasi altra piattaforma blockchain. In pratica, tuttavia, i contratti intelligenti in stile Ethereum presentano molte dolorose carenze:

Ogni nodo deve eseguire ogni calcolo, che sia di interesse o meno. Al contrario, in Hyperchain ogni nodo decide a quali flussi iscriversi e può ignorare i dati contenuti da altri.
La macchina virtuale utilizzata per i contratti intelligenti ha prestazioni notevolmente peggiori rispetto al codice che è stato compilato in modo nativo per una determinata architettura di computer.
Il codice del contratto intelligente è immutabilmente incorporato in una catena, impedendo l’aggiunta di funzionalità e la correzione di bug. Ciò è stato dimostrato con forza nella fine di The DAO .
Le transazioni inviate a un contratto intelligente non possono aggiornare lo stato di una blockchain fino a quando non si conosce il loro ordine finale, a causa della natura del calcolo per scopi generali.

Ciò comporta ritardi (fino a quando una transazione non viene confermata in un blocco) nonché possibili inversioni (nel caso di un fork nella catena). Al contrario, Hyperchain può trattare ogni tipo di transazione non confermata nel modo appropriato: (a) gli asset in entrata aggiornano immediatamente il saldo non confermato di un nodo, (b) gli elementi del flusso in entrata sono immediatamente disponibili, con il loro ordinamento globale successivamente finalizzato, (c) le modifiche delle autorizzazioni vengono applicati immediatamente e quindi riprodotti nei blocchi in arrivo.

Tuttavia, come ho detto prima , non escludiamo certamente i contratti intelligenti come un paradigma utile per le applicazioni blockchain, se e quando vediamo casi d’uso forti. Tuttavia, in Hyperchain i contratti intelligenti verrebbero implementati in uno strato simile a stream in cima alla blockchain, piuttosto che al livello di transazione più basso. Ciò preserverà le prestazioni superiori di Hyperchain per entità blockchain più semplici come asset e flussi, offrendo al contempo un calcolo su catena più lento dove è realmente necessario. Ma ci sono meno casi del genere di quanto tu possa pensare.