Roadmap di MultiChain 1.0 beta 2 e 2.0

Dove siamo oggi e dove andremo domani

Oggi siamo lieti di rilasciare la seconda beta di MultiChain 1.0 per Linux, Windows e Mac (per ora la versione per Mac richiede la compilazione). Questo conclude lo sviluppo pianificato di MultiChain 1.0: ad eccezione di eventuali correzioni di bug, la versione finale di MultiChain 1.0 durante l'estate rimarrà invariata.

Questo mese segna anche due anni dalla prima versione alpha di MultiChain nel giugno 2015. Come per qualsiasi nuovo prodotto, non eravamo sicuri di come avrebbe reagito il mercato e sapevamo che c'era solo un modo per scoprirlo: rilasciare un prodotto minimo vitale, che significa una versione iniziale che fornisce un valore significativo ma è preliminare per progettazione. Per fortuna, a differenza del nostro primo prodotto CoinSpark, MultiChain ha ricevuto una risposta positiva forte e immediata. Ciò è stato accompagnato da uno tsunami di richieste di funzionalità ragionevoli, molte delle quali ora abbiamo implementato. Parallelamente allo sviluppo del prodotto, anche l'utilizzo è cresciuto notevolmente in ogni misura. Ad esempio, il sito Web MultiChain ha ricevuto meno di 3,000 visitatori a luglio 2015 e ora porta ogni mese dieci volte quel numero.

Prestazioni MultiChain

Negli ultimi due anni abbiamo investito molto nell'ottimizzazione di MultiChain, da cui è stato eseguito il fork Bitcoin Core, l'implementazione di riferimento per la rete pubblica di bitcoin. Di seguito è riportato un confronto del throughput delle transazioni per una configurazione a nodo singolo utilizzando cinque versioni del prodotto:

.throughput td,.throughput th {text-align:right;}

Transazioni totali	1.0 alfa 3	1.0 alfa 21	1.0 alfa 22	1.0 1 beta	1.0 2 beta
100	6.5 tps	7.8	541.7	830.6	1465.7
1,000	7.0	7.6	583.9	889.4	1199.6
10,000	4.1	6.4	566.9	746.6	1071.2
100,000	-	6.6	558.0	771.9	1034.2
1,000,000	-	-	548.6	773.6	1055.4

Transazioni medie al secondo, inclusi overhead API e creazione, firma, mining e verifica di transazioni e blocchi.
Test eseguiti utilizzando il ab Strumento di benchmarking del server HTTP che invia due richieste simultanee al file sendtoaddress API.
Specifiche del server: Intel Core i7-4770, 4 core a 3.4 MHz, 32 GB di RAM, Seagate 2 TB 7200 RPM SATA, CentOS 6.4.

Naturalmente, il salto più grande è avvenuto in alpha 22 quando noi transizione a un portafoglio basato su database. Ma da quella versione, abbiamo quasi raddoppiato di nuovo la velocità di MultiChain. Speriamo di aver dimostrato che il limite di 4 transazioni al secondo di bitcoin è dovuto ai suoi parametri di rete particolari e non ha alcuna relazione con le blockchain in generale.

Ovviamente, l'ottimizzazione delle prestazioni è un'attività senza fine e non c'è motivo per cui MultiChain non possa raggiungere 10,000 tx / sec su un Processore a 16 core con le opportune modifiche architettoniche. Tuttavia, sulla base delle conversazioni con i nostri utenti e partner, sembra che pochi si aspettino di aver bisogno di più di 1,000 tx / sec per i prossimi anni. Quindi stiamo riorientando i nostri sforzi di sviluppo su nuove funzionalità, il che ci porta piacevolmente sull'argomento di MultiChain 2.0.

Panoramica di MultiChain 2.0

La versione 2.0 di MultiChain sarà la prima ad arrivare in due edizioni: Community (open source) ed Enterprise (commerciale). Mi concentrerò qui sull'edizione Community gratuita, poiché stiamo solo discutendo i dettagli di MultiChain Enterprise con i nostri partner. In ogni caso, le edizioni Community ed Enterprise saranno altamente compatibili, in quanto: (a) le applicazioni costruite sull'edizione Community funzioneranno senza modifiche su MultiChain Enterprise, e (b) entrambe le edizioni potranno connettersi ed effettuare transazioni tra loro sulla stessa catena.

Le tre aree chiave di funzionalità avanzate in entrambe le edizioni di MultiChain 2.0 saranno:

• Modello di dati più completo per i flussi, inclusi i documenti JSON.
• Filtri di transazione programmabili personalizzati per la convalida in catena.
• Aggiornamento continuo del protocollo e dei parametri di una blockchain.

Passiamo a discutere ciascuno di questi in dettaglio.

Modello di dati più completo per i flussi

I flussi MultiChain sono stati introdotti a settembre 2016 e si sono dimostrati estremamente popolari. Come descritto in questo post, i flussi forniscono un'astrazione semplice e naturale per l'archiviazione, l'indicizzazione e il recupero dei dati di uso generale su una blockchain. Una blockchain MultiChain può contenere un numero qualsiasi di flussi denominati, ognuno dei quali può essere aperto a tutti per la scrittura o scrivibile solo da determinati indirizzi.

In MultiChain 1.0, ogni elemento del flusso ha uno o più editori (che lo firmano), una chiave opzionale, un payload di dati binari fino a 64 MB di dimensione e un timestamp (derivato dal blocco in cui è incorporato). Ogni nodo può decidere liberamente a quali stream iscriversi o può iscriversi automaticamente a tutti gli stream. Se un nodo è iscritto a uno stream, indicizza il contenuto di quello stream in tempo reale, consentendo un recupero efficiente per editore, chiave, blocco, timestamp o posizione.

MultiChain 2.0 arricchirà questa funzionalità di streaming in diversi modi:

• Articoli JSON. Oltre ai dati binari, gli elementi del flusso supporteranno oggetti JSON strutturati, archiviati sulla blockchain in un formato di serializzazione efficiente come UBJSON. Poiché l'API MultiChain utilizza già JSON in tutto, questi oggetti JSON saranno scrivibili e leggibili in modo naturale e ovvio.
• Chiavi multiple. Gli elementi del flusso supporteranno più chiavi, consentendo l'indicizzazione di un singolo pezzo di dati in più modi per il recupero utilizzando liststreamkeyitems. Stiamo valutando costantemente la quantità di funzionalità del database da includere in MultiChain e non ci aspettiamo di supportare l'indicizzazione dei sottoelementi all'interno degli elementi del flusso JSON nella versione 2.0. Consentire più chiavi per elemento del flusso fornisce una soluzione ragionevole.
• Atomic scrive di più elementi. MultiChain 1.0 consente a una singola transazione di scrivere su più flussi, ma non di scrivere più elementi sullo stesso flusso. MultiChain 2.0 rimuoverà questa restrizione.
• Unione JSON. Qualsiasi elenco ordinato di oggetti JSON può essere naturalmente appiattito o riepilogato per creare un oggetto "unito". L'oggetto unito contiene tutte le chiavi che compaiono nei singoli oggetti, dove il valore corrispondente a ciascuna chiave è preso dall'ultimo oggetto in cui compare quella chiave. Se lo desideri, l'oggetto unito è lo stato finale di una riga del database, le cui colonne sono definite dal primo oggetto ed estese o aggiornate dagli oggetti successivi. MultiChain 2.0 aggiungerà API per recuperare facilmente e rapidamente l'oggetto unito per gli elementi JSON in uno stream con una particolare chiave o editore.

Queste funzionalità derivano dai modi comuni in cui gli sviluppatori utilizzano attualmente i flussi. In altre parole, stiamo osservando ciò che molte persone stanno costruendo su MultiChain a livello di applicazione e stiamo portando quella funzionalità in MultiChain stesso, un modello che intendiamo continuare ad applicare. Ora che gli elementi del flusso includeranno informazioni sul tipo, possono essere facilmente estesi in futuro per supportare altri formati di dati come XML, HDF5 ed MIMOcontenuto identificato. Per non parlare delle possibilità di compressione e crittografia on-chain trasparenti.

MultiChain 2.0 supporterà anche oggetti JSON per i metadati delle transazioni non elaborate (cioè non gli elementi del flusso) così come i metadati per l'emissione di risorse e gli eventi di creazione del flusso, invece delle coppie chiave / valore di solo testo implementate in MultiChain 1.0. Il listassets L'API offrirà l'unione JSON tra tutti gli eventi di emissione di una risorsa, in modo che i metadati di ciascuna emissione possano aggiornare efficacemente la descrizione finale della risorsa.

Filtri di transazione personalizzati

Abbiamo pensato molto a come aggiungere regole programmabili personalizzate a MultiChain. Sebbene il paradigma del "contratto intelligente" di Ethereum sia popolare, presenta una serie di carenze chiave per le blockchain autorizzate ad alto rendimento. In primo luogo, i contratti intelligenti introducono una dipendenza globale nell'intero stato della blockchain, che altera drasticamente la concorrenza e le prestazioni. In secondo luogo, i contratti intelligenti non possono impedire alle transazioni errate di essere incorporate in una blockchain, ma solo impedire a tali transazioni di aggiornare lo stato del database blockchain. Mentre a lungo termine ci aspettiamo che una macchina virtuale compatibile con Ethereum venga offerta come astrazione di alto livello all'interno di MultiChain, non pensiamo che sia la soluzione giusta per la convalida di basso livello.

MultiChain 2.0 introdurrà un paradigma diverso chiamato filtri di transazione, che convalidano le singole transazioni senza riferimento a nessuno stato globale. Ci aspettiamo che i filtri vengano scritti in Javascript ed eseguiti all'interno di un motore di runtime incorporato come v8, che viene utilizzato in Google Chrome browser e Node.js piattaforma. Ovviamente, dovremo assicurarci che il codice del filtro venga eseguito in modo identico su ogni nodo in una blockchain, bloccandone qualsiasi fonti di non determinismo come leggere l'ora, utilizzare numeri casuali, accedere alla rete o al disco o eseguire operazioni matematiche che dipendono dall'architettura del server host. La creazione di un ambiente runtime Javascript deterministico è una sfida, ma (senza rivelare troppo) riteniamo che sarà utile per molte altre funzionalità MultiChain in futuro.

Ai filtri verrà passato un oggetto JSON che descrive una singola transazione, strutturata come l'output di decoderawtransaction ma con campi extra. Ad esempio, ogni input di transazione nel JSON includerà una struttura che descrive l'output di transazione precedente che spende e ogni indirizzo sarà accompagnato da un elenco di autorizzazioni attualmente detenute da quell'indirizzo. Il compito di un filtro è restituire un valore booleano che indica se la transazione è accettabile e, in caso contrario, fornire un errore testuale che ne spiega il motivo. L'API di MultiChain includerà comandi per creare filtri, testarli su transazioni precedenti o nuove e attivarli previo consenso dell'amministratore.

A differenza degli smart contract, se viene scoperto un bug nel codice di un filtro, può essere facilmente sostituito da una nuova versione. Tuttavia, come tutto il codice completo di Turing, i filtri corrono ancora il rischio di entrare in un ciclo infinito. Questo problema verrà mitigato in due modi:

• I filtri possono essere installati e attivati ​​solo dagli amministratori della catena, previo consenso. Ciò offre a ciascun amministratore l'opportunità di esaminare in profondità il codice di un filtro prima di votare per l'attivazione.
• Tutti i nodi ben comportati convalideranno le nuove transazioni utilizzando i filtri attivi prima di inoltrarle ai loro nodi peer. Di conseguenza, se una transazione invia un filtro in un ciclo infinito, la transazione non dovrebbe propagarsi oltre il nodo che l'ha creata.

Ci aspettiamo che un'applicazione popolare per i filtri convalidi gli elementi del flusso. Ad esempio, un filtro potrebbe garantire che determinati campi negli elementi JSON di un flusso contengano numeri in un intervallo specifico. In MultiChain 1.0 questo tipo di convalida deve essere eseguito a livello di applicazione, durante la scrittura di elementi del flusso (se la fonte è attendibile) o durante la lettura. Al contrario, MultiChain 2.0 consentirà a queste regole di essere incorporate all'interno della blockchain stessa, un po 'come controllare i vincoli in un database relazionale.

MultiChain 2.0 includerà due funzionalità aggiuntive per rendere i filtri ancora più potenti. Innanzitutto, introdurrà le autorizzazioni definite dall'utente, che esistono insieme alle otto autorizzazioni definite da MultiChain. Come con le normali autorizzazioni, queste verranno concesse a indirizzi specifici dagli amministratori (e in alcuni casi, dagli utenti con estensione activate privilegi) e inclusi insieme agli indirizzi nell'oggetto JSON passato a un filtro. Ad esempio, un filtro potrebbe garantire che solo gli indirizzi con una particolare autorizzazione definita dall'utente possano scrivere determinati tipi di dati in un flusso o effettuare transazioni in una determinata risorsa al di sopra di una determinata soglia.

In secondo luogo, MultiChain 2.0 supporterà metadati personalizzati (binari o JSON) all'interno dei normali output delle transazioni. Ciò consentirà a qualsiasi output di agire come una riga di database generale, "di proprietà" dell'indirizzo all'interno. I filtri vedranno tutti i metadati all'interno degli output spesi e creati di una transazione come parte della sua descrizione JSON. Di conseguenza, MultiChain diventerà un motore di database condiviso universale, in cui la validità di una transazione è determinata da una funzione personalizzabile delle righe che crea ed elimina. (Se questo suona un po 'astratto, forniremo alcuni esempi concreti.)

Aggiornamento blockchain

Poiché le blockchain sono progettate per funzionare per molti anni, le loro caratteristiche potrebbero dover essere modificate nel tempo. L'attuale versione di MultiChain fornisce già un discreto grado di flessibilità, consentendo modifiche alle autorizzazioni (inclusi amministratori e minatori per consenso), la creazione di nuove risorse e flussi e l'aggiunta o la rimozione di nodi dalla rete. Tuttavia, in MultiChain 1.0 è fondamentale una blockchain parametri, come la dimensione massima del blocco e il tempo di conferma dell'obiettivo, vengono fissati al momento della creazione della catena e non possono essere modificati successivamente.

MultiChain 2.0 aggiungerà la possibilità di aggiornare una blockchain, consentendo la modifica di molti (ma non tutti) dei suoi parametri mentre la catena continua a funzionare. Come altre operazioni importanti, l'aggiornamento di una blockchain richiederà un livello personalizzabile di consenso dell'amministratore, dove questo stesso livello è un parametro che può essere modificato. Gli aggiornamenti entreranno in vigore da un determinato blocco e si applicheranno successivamente a ogni blocco successivo fino all'aggiornamento successivo.

I parametri blockchain che possono essere aggiornati includeranno:

• Versione del protocollo. Ciò consentirà di aggiornare una blockchain creata con una versione di MultiChain per supportare le funzionalità in una nuova versione, come elementi di flusso JSON o filtri di transazione. In effetti, la versione del protocollo 10008 introdotto in MultiChain 1.0 alpha 29 (e utilizzato nella beta) è già stato predisposto per il futuro con supporto non documentato per questo tipo di aggiornamento. Una volta che una blockchain MultiChain 1.0 è stata aggiornata al protocollo 2.0, avrà anche accesso alle altre modifiche ai parametri descritte qui.
• Ridimensionamento della blockchain. Le blockchain che diventano popolari possono superare i valori iniziali impostati per il tempo di conferma target o le dimensioni massime delle transazioni e dei blocchi. MultiChain 2.0 consentirà di aumentare o diminuire questi valori secondo necessità.
• Modello di autorizzazione. MultiChain 2.0 consentirà l'aggiornamento di molti parametri relativi all'autorizzazione e alla governance, tra cui: (a) anyone-can-* parametri che controllano i modi in cui una blockchain è aperta o chiusa, (b) admin-consensus-* parametri che determinano i livelli di consenso degli amministratori necessari per determinate operazioni e (c) il mining-diversity parametro che controlla la severità dell'algoritmo di consenso round-robin.

Una volta implementata questa funzionalità di aggiornamento, non dovrebbe esserci alcun motivo per cui una blockchain creata in MultiChain non possa funzionare per molti decenni o più.

Guardando al futuro

Abbiamo già iniziato a lavorare su MultiChain 2.0 e guardiamo avanti per realizzare questa roadmap. Senza dubbio saranno inclusi anche altri miglioramenti. Come con MultiChain 1.0, avremo versioni alpha lungo il percorso, in modo che gli sviluppatori possano utilizzare e apprendere nuove funzionalità non appena vengono implementate (e, naturalmente, segnalare eventuali problemi o carenze). Naturalmente, continueremo a mantenere la versione 1.0 per tutto questo periodo, correggendo eventuali bug che compaiono.

Vorrei concludere ringraziando il nostro team di sviluppo, guidato dal dott. Michael Rozantsev, per la loro continua eccellenza e il duro lavoro. Vediamo MultiChain come un semplice progetto di ingegneria del software, in cui la qualità del codice e il test contano soprattutto. È un mio privilegio lavorare con persone che possono trasformare una visione di prodotto complessa in un software funzionante stabile con un'efficienza e una velocità così notevoli.

Si prega di inviare eventuali commenti LinkedIn.