MultiChain 1.0 beta 2 en 2.0 roadmap

Waar we vandaag zijn en waar we morgen heen gaan

Vandaag zijn we verheugd om de tweede bèta van MultiChain 1.0 voor Linux, Windows en Mac uit te brengen (voorlopig vereist de Mac-versie compilatie). Hiermee is de geplande ontwikkeling van MultiChain 1.0 afgerond - met uitzondering van eventuele bugfixes, zal de definitieve release van MultiChain 1.0 in de zomer ongewijzigd blijven.

Deze maand markeert ook twee jaar sinds de eerste alpha-release van MultiChain in juni 2015. Zoals bij elk nieuw product wisten we niet zeker hoe de markt zou reageren, en wisten we dat er maar één manier was om erachter te komen - release a minimaal levensvatbaar product, wat betekent dat een initiële versie van grote waarde is maar voorlopig van opzet is. Gelukkig, in tegenstelling tot ons eerste product Muntvonk, MultiChain kreeg een sterke en onmiddellijke positieve respons. Dit ging gepaard met een tsunami van zinvolle functieverzoeken, waarvan we er nu vele hebben geïmplementeerd. Parallel aan de ontwikkeling van het product is ook het gebruik door elke maatregel opmerkelijk toegenomen. Zo ontving de MultiChain-website in juli 3,000 minder dan 2015 bezoekers en brengt nu maandelijks tien keer zoveel op.

MultiChain-prestaties

In de afgelopen twee jaar hebben we veel energie gestoken in het optimaliseren van MultiChain, dat is afgebroken Bitcoin Core, de referentie-implementatie voor het openbare bitcoin-netwerk. Hieronder vindt u een vergelijking van de transactiedoorvoer voor een installatie met één knooppunt met behulp van vijf versies van het product:

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

Totaal transacties	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

Gemiddelde transacties per seconde, inclusief API-overhead en bouwen, ondertekenen, minen en verifiëren van transacties en blokken.
Tests uitgevoerd met de ab Tool voor benchmarking van HTTP-server die twee gelijktijdige verzoeken naar de sendtoaddress API.
Serverspecificaties: Intel Core i7-4770, 4 cores @ 3.4 MHz, 32 GB RAM, Seagate 2 TB 7200 RPM SATA, CentOS 6.4.

Natuurlijk kwam de grootste sprong in alpha 22 toen we overgegaan naar een database-gestuurde portemonnee. Maar sinds die release hebben we de snelheid van MultiChain bijna verdubbeld. We hopen dat we hebben aangetoond dat de limiet van bitcoin van 4 transacties per seconde te wijten is aan zijn specifieke netwerkparameters en geen verband houdt met blockchains in het algemeen.

Prestatieoptimalisatie is natuurlijk een nooit eindigende taak en er is geen reden waarom MultiChain niet 10,000 tx / sec kan bereiken op een 16-coreprocessor met de juiste architectonische veranderingen. Echter, op basis van gesprekken met onze gebruikers en partners, lijken er maar weinigen te verwachten dat ze de komende jaren meer dan 1,000 tx / sec nodig zullen hebben. Daarom richten we onze ontwikkelingsinspanningen opnieuw op nieuwe functies, wat ons mooi op het onderwerp MultiChain 2.0 brengt.

Overzicht van MultiChain 2.0

Versie 2.0 van MultiChain komt als eerste in twee edities: Community (open source) en Enterprise (commercieel). Ik ga me hier concentreren op de gratis Community-editie, omdat we alleen de details van MultiChain Enterprise bespreken onze partners. In ieder geval zullen de Community- en Enterprise-edities zeer compatibel zijn, in die zin dat: (a) applicaties die op de Community-editie zijn gebouwd, zonder wijziging op MultiChain Enterprise zullen worden uitgevoerd, en (b) beide edities met elkaar kunnen verbinden en transacties met elkaar kunnen uitvoeren op dezelfde ketting.

De drie belangrijkste gebieden van verbeterde functionaliteit in beide edities van MultiChain 2.0 zijn:

• Uitgebreid gegevensmodel voor streams, inclusief JSON-documenten.
• Op maat programmeerbare transactiefilters voor on-chain validatie.
• Naadloze update van het protocol en de parameters van een blockchain.

Laten we eens kijken om elk van deze in detail te bespreken.

Uitgebreid gegevensmodel voor streams

MultiChain-streams zijn geïntroduceerd in september 2016 en zijn enorm populair gebleken. Zoals beschreven in dit bericht, streams bieden een eenvoudige en natuurlijke abstractie voor algemene gegevensopslag, indexering en retrieval op een blockchain. Een MultiChain-blockchain kan een onbeperkt aantal benoemde streams bevatten, die elk voor iedereen open kunnen staan ​​om te schrijven of alleen vanaf bepaalde adressen kunnen worden geschreven.

In MultiChain 1.0 heeft elk stream-item een ​​of meer uitgevers (die het ondertekenen), een optionele sleutel, een binaire gegevensbelasting tot 64 MB groot en een tijdstempel (afgeleid van het blok waarin het is ingesloten). Elk knooppunt kan vrij beslissen op welke streams hij zich wil abonneren, of kan zich automatisch op alle streams abonneren. Als een knooppunt is geabonneerd op een stream, wordt de inhoud van die stream in realtime geïndexeerd, waardoor efficiënt ophalen per uitgever, sleutel, blok, tijdstempel of positie mogelijk is.

MultiChain 2.0 zal deze streams-functionaliteit op een aantal manieren verrijken:

• JSON-items. Naast binaire gegevens ondersteunen stream-items gestructureerde JSON-objecten, die op de blockchain zijn opgeslagen in een efficiënt serialisatie-formaat zoals UBJSON. Omdat de MultiChain API al JSON overal gebruikt, zullen deze JSON-objecten op een natuurlijke en voor de hand liggende manier schrijfbaar en leesbaar zijn.
• Meerdere sleutels. Stream-items ondersteunen meerdere sleutels, waardoor een enkel stuk gegevens op meerdere manieren kan worden geïndexeerd om op te halen met liststreamkeyitems. We evalueren voortdurend hoeveel databasefunctionaliteit moet worden opgenomen in MultiChain en verwachten niet dat indexering van de subelementen in JSON-streamitems in versie 2.0 wordt ondersteund. Het toestaan ​​van meerdere sleutels per stream-item biedt een redelijke oplossing.
• Atomic schrijft over meerdere items. Met MultiChain 1.0 kan een enkele transactie naar meerdere streams schrijven, maar niet om meerdere items naar dezelfde stream te schrijven. MultiChain 2.0 verwijdert deze beperking.
• JSON samenvoegen. Elke geordende lijst met JSON-objecten kan op natuurlijke wijze worden afgevlakt of samengevat om een ​​"samengevoegd" object te maken. Het samengevoegde object bevat alle sleutels die in de afzonderlijke objecten voorkomen, waarbij de waarde die overeenkomt met elke sleutel wordt overgenomen van het laatste object waarin die sleutel voorkomt. Als u wilt, is het samengevoegde object de laatste staat van een database-rij, waarvan de kolommen worden gedefinieerd door het eerste object en uitgebreid of bijgewerkt door latere objecten. MultiChain 2.0 voegt API's toe om het samengevoegde object voor de JSON-items in een stream met een bepaalde sleutel of uitgever gemakkelijk en snel op te halen.

Deze functies zijn afgeleid van veelvoorkomende manieren waarop ontwikkelaars momenteel streams gebruiken. Met andere woorden, we observeren wat veel mensen bouwen bovenop MultiChain op applicatieniveau en brengen die functionaliteit in MultiChain zelf - een patroon dat we willen blijven toepassen. Nu stream-items type-informatie zullen bevatten, kunnen ze in de toekomst gemakkelijk worden uitgebreid om andere gegevensformaten zoals XML te ondersteunen, HDF5 en MIME-geïdentificeerde inhoud. Om nog maar te zwijgen van de mogelijkheden van transparante on-chain compressie en encryptie.

MultiChain 2.0 ondersteunt ook JSON-objecten voor metagegevens van onbewerkte transacties (dwz geen stream-items) en de metadata voor uitgifte van activa en gebeurtenissen voor het maken van streams, in plaats van de alleen-tekst sleutel / waarde-paren geïmplementeerd in MultiChain 1.0. De listassets API biedt JSON-samenvoeging over alle uitgiftegebeurtenissen van een activum, zodat de metagegevens van elke uitgifte de uiteindelijke beschrijving van het activum effectief kunnen bijwerken.

Aangepaste transactiefilters

We hebben veel nagedacht over het toevoegen van aangepaste programmeerbare regels aan MultiChain. Hoewel het 'smart contract'-paradigma van Ethereum populair is, heeft het een aantal belangrijke tekortkomingen voor blockchains met een hoge verwerkingscapaciteit. Ten eerste introduceren slimme contracten een wereldwijde afhankelijkheid in de hele staat van de blockchain, wat de gelijktijdigheid en prestaties drastisch schaadt. Ten tweede kunnen slimme contracten niet voorkomen dat onjuiste transacties worden ingesloten in een blockchain, maar alleen voorkomen dat die transacties de status van de blockchain-database bijwerken. Hoewel we op lange termijn verwachten dat een Ethereum-compatibele virtuele machine wordt aangeboden als een abstractie op hoog niveau binnen MultiChain, denken we niet dat dit de juiste oplossing is voor validatie op laag niveau.

MultiChain 2.0 introduceert een ander paradigma, transactiefilters genaamd, die individuele transacties valideren zonder verwijzing naar een globale staat. We verwachten dat filters in Javascript worden geschreven en worden uitgevoerd in een ingebouwde runtime-engine zoals v8, die wordt gebruikt in Google's Chrome browser en de Node.js platform. Natuurlijk moeten we ervoor zorgen dat filtercode identiek wordt uitgevoerd op elk knooppunt in een blockchain, waardoor elke code wordt geblokkeerd bronnen van niet-determinisme zoals het lezen van de tijd, het gebruik van willekeurige getallen, toegang tot het netwerk of de schijf of het uitvoeren van wiskundige bewerkingen die afhankelijk zijn van de architectuur van de hostserver. Het creëren van een deterministische Javascript-runtime-omgeving is een uitdaging, maar (zonder teveel weg te geven) denken we dat het in de toekomst nuttig zal zijn voor verschillende andere MultiChain-functies.

Filters worden doorgegeven aan een JSON-object dat een individuele transactie beschrijft, gestructureerd zoals de uitvoer van decoderawtransaction maar met extra velden. Elke transactie-invoer in de JSON zal bijvoorbeeld een structuur bevatten die de eerdere transactie-uitvoer beschrijft die hij uitgeeft, en elk adres zal vergezeld gaan van een lijst met toestemmingen die momenteel door dat adres worden beheerd. Het is de taak van een filter om een ​​Booleaanse waarde te retourneren die aangeeft of de transactie acceptabel is en zo niet, geef dan een tekstfout waarin wordt uitgelegd waarom. De API van MultiChain bevat opdrachten voor het maken van filters, het testen ervan op eerdere of nieuwe transacties en het activeren ervan, onder voorbehoud van consensus van de beheerder.

In tegenstelling tot slimme contracten kan een bug die wordt ontdekt in de code voor een filter, gemakkelijk worden vervangen door een nieuwe versie. Niettemin lopen filters, net als alle Turing-complete code, nog steeds het risico een oneindige lus binnen te gaan. Dit probleem wordt op twee manieren verholpen:

• Filters kunnen alleen worden geïnstalleerd en geactiveerd door de beheerders van de keten, onder voorbehoud van consensus. Dit geeft elke beheerder de mogelijkheid om de code van een filter grondig te onderzoeken voordat hij stemt om te worden geactiveerd.
• Alle goed gedragen knooppunten valideren nieuwe transacties met behulp van de actieve filters voordat ze worden doorgestuurd naar hun peerknooppunten. Als gevolg hiervan, als een transactie een filter naar een oneindige lus stuurt, mag de transactie niet verder gaan dan het knooppunt dat het heeft gecreëerd.

We verwachten dat een populaire toepassing voor filters streamitems valideert. Een filter kan er bijvoorbeeld voor zorgen dat bepaalde velden in de JSON-items van een stream nummers in een specifiek bereik bevatten. In MultiChain 1.0 moet dit type validatie worden uitgevoerd op applicatieniveau, ofwel bij het schrijven van stream-items (als de bron vertrouwd is) of bij het lezen ervan. Met MultiChain 2.0 kunnen deze regels daarentegen worden ingebed in de blockchain zelf, net zoals controleer beperkingen in een relationele database.

MultiChain 2.0 zal twee extra functies bevatten om filters nog krachtiger te maken. Ten eerste zal het door de gebruiker gedefinieerde rechten introduceren, die naast de acht door MultiChain gedefinieerde rechten bestaan. Net als bij reguliere machtigingen, worden deze door beheerders (en in sommige gevallen door gebruikers met) aan specifieke adressen verleend activate privileges) en opgenomen naast adressen in het JSON-object dat aan een filter is doorgegeven. Een filter kan er bijvoorbeeld voor zorgen dat alleen adressen met een bepaalde door de gebruiker gedefinieerde toestemming bepaalde soorten gegevens naar een stream kunnen schrijven of transacties kunnen uitvoeren in een bepaald activum boven een bepaalde drempel.

Ten tweede ondersteunt MultiChain 2.0 aangepaste (binaire of JSON) metadata binnen reguliere transactie-outputs. Hierdoor kan elke output fungeren als een algemene database-rij, 'eigendom' van het adres binnenin. Filters zien alle metadata binnen de bestede en gecreëerde output van een transactie als onderdeel van de JSON-beschrijving. Als gevolg hiervan wordt MultiChain een universele gedeelde database-engine, waarbij de geldigheid van een transactie wordt bepaald door een aanpasbare functie van de rijen die deze maakt en verwijdert. (Als dit een beetje abstract klinkt, zullen we zeker enkele concrete voorbeelden geven.)

Blockchain-update

Aangezien blockchains zijn ontworpen om vele jaren te werken, moeten hun kenmerken mogelijk in de loop van de tijd worden gewijzigd. De huidige versie van MultiChain biedt al een behoorlijke mate van flexibiliteit, waardoor toestemmingswijzigingen (inclusief van beheerders en mijnwerkers bij consensus), nieuwe activa en streams kunnen worden gemaakt en knooppunten naadloos kunnen worden toegevoegd aan of verwijderd uit het netwerk. Niettemin is in MultiChain 1.0 de basis van een blockchain parameters, zoals de maximale blokgrootte en doelbevestigingstijd, worden vastgezet wanneer de ketting wordt gemaakt en kunnen vervolgens niet worden gewijzigd.

MultiChain 2.0 voegt de mogelijkheid toe om een ​​blockchain bij te werken, waardoor veel (maar niet alle) parameters kunnen worden gewijzigd terwijl de ketting blijft lopen. Net als bij andere belangrijke bewerkingen, vereist het bijwerken van een blockchain een aanpasbaar niveau van consensus van de beheerder, waarbij dit niveau zelf een parameter is die kan worden gewijzigd. Updates worden van kracht vanaf een bepaald blok en zijn daarna van toepassing op elk volgend blok tot de volgende update.

Blockchain-parameters die kunnen worden bijgewerkt, zijn onder meer:

• Protocolversie. Hierdoor kan een blockchain die is gemaakt met één versie van MultiChain worden geüpgraded om de functies in een nieuwe versie te ondersteunen, zoals JSON-streamitems of transactiefilters. Inderdaad, de protocolversie 10008 geïntroduceerd in MultiChain 1.0 alpha 29 (en gebruikt in de bèta) is al toekomstbestendig met ongedocumenteerde ondersteuning voor dit type upgrade. Zodra een MultiChain 1.0-blockchain is geüpgraded naar het 2.0-protocol, krijgt deze ook toegang tot de andere hier beschreven parameterwijzigingen.
• Blockchain-schaling. Blockchains die populair worden, ontgroeien mogelijk de initiële waarden die zijn ingesteld voor hun beoogde bevestigingstijd of maximale transactie- en blokgroottes. Met MultiChain 2.0 kunnen deze waarden indien nodig worden verhoogd of verlaagd.
• Toestemmingsmodel. Met MultiChain 2.0 kunnen veel parameters met betrekking tot toestemming en beheer worden bijgewerkt, waaronder: anyone-can-* parameters die de manieren bepalen waarop een blockchain open of gesloten is, (b) admin-consensus-* parameters die het niveau van consensus van de beheerder bepalen dat vereist is voor bepaalde operaties, en (c) de mining-diversity parameter die de striktheid van het round-robin consensusalgoritme controleert.

Zodra deze updatefunctie is geïmplementeerd, zou er geen reden meer moeten zijn waarom een ​​in MultiChain gemaakte blockchain tientallen jaren of langer niet kan draaien.

De toekomst

We zijn al begonnen met werken aan MultiChain 2.0 en kijken ernaar uit om deze roadmap te realiseren. Er zullen ongetwijfeld ook andere verbeteringen worden opgenomen. Net als bij MultiChain 1.0, zullen we onderweg alpha-releases hebben, zodat ontwikkelaars nieuwe functies kunnen gebruiken en leren terwijl ze worden geïmplementeerd (en natuurlijk eventuele problemen of tekortkomingen melden). Uiteraard blijven we versie 1.0 gedurende deze periode onderhouden en eventuele bugs oplossen.

Ik wil eindigen met het bedanken van ons ontwikkelingsteam, geleid door Dr. Michael Rozantsev, voor hun voortdurende uitmuntendheid en harde werk. We zien MultiChain als een eenvoudig software engineering project, waarbij codekwaliteit en testen voorop staan. Het is mijn voorrecht om met mensen te werken die een complexe productvisie met zulke opmerkelijke efficiëntie en snelheid kunnen omzetten in stabiele werkende software.

Plaats eventuele opmerkingen op LinkedIn.