MultiChain 1.0 beta 2 och 2.0 färdplan

Var vi är idag och vart vi går i morgon

Idag är vi glada över att släppa den andra betaen i MultiChain 1.0 för Linux, Windows och Mac (för nu kräver Mac-versionen sammanställning). Detta avslutar den planerade utvecklingen av MultiChain 1.0 - med undantag för eventuella buggfixar kommer den slutliga utgåvan av MultiChain 1.0 under sommaren att vara oförändrad.

Den här månaden är också två år sedan den första alpha-utgivningen av MultiChain i juni 2015. Som med alla nya produkter var vi inte säkra på hur marknaden skulle reagera och visste att det bara fanns ett sätt att ta reda på - släpp en minsta möjliga produkt, vilket innebär en initial version som ger betydande värde men är preliminär av design. Tack och lov, till skillnad från vår första produkt CoinSpark, MultiChain fick ett starkt och omedelbart positivt svar. Detta åtföljdes av en tsunami av förnuftiga funktionsbegäranden, av vilka många nu har genomförts. Parallellt med produktens utveckling har användningen också vuxit anmärkningsvärt av alla mått. Exempelvis fick MultiChain-webbplatsen under 3,000 2015 besökare i juli XNUMX och tar nu in tio gånger så många gånger varje månad.

MultiChain-prestanda

Under de senaste två åren har vi satsat mycket på att optimera MultiChain, som gick från Bitcoin Core, referensimplementeringen för det offentliga bitcoin-nätverket. Nedan är en jämförelse av transaktionsgenomströmning för en installation med en nod med fem versioner av produkten:

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

Totala transaktioner	1.0 alfa 3	1.0 alfa 21	1.0 alfa 22	1.0 1 beta	1.0 2 beta
100	6.5 ton	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

Genomsnittliga transaktioner per sekund, inklusive API-omkostnader och byggande, signering, gruvdrift och verifiering av transaktioner och block.
Tester utförda med ab HTTP-server benchmarkingverktyg som skickar två samtidiga förfrågningar till sendtoaddress API.
Server specifikationer: Intel Core i7-4770, 4 kärnor @ 3.4 MHz, 32 GB RAM, Seagate 2 TB 7200 RPM SATA, CentOS 6.4.

Naturligtvis kom det största hoppet i alpha 22 när vi transitioned till en databasdriven plånbok. Men sedan utgivningen har vi nästan fördubblat MultiChains hastighet igen. Vi hoppas att vi har visat att bitcoin-gränsen på 4 transaktioner per sekund beror på dess specifika nätverksparametrar och inte har någon relation till blockchains i allmänhet.

Naturligtvis är prestationsoptimering en oändlig uppgift, och det finns ingen anledning till att MultiChain inte kan nå 10,000 XNUMX tx / sek på en 16-kärnig processor med lämpliga arkitektoniska förändringar. Baserat på samtal med våra användare och partners verkar det dock som om få förväntar sig att behöva mer än 1,000 2.0 tx / sek under de närmaste åren. Så vi fokuserar igenom våra utvecklingsinsatser på nya funktioner, vilket ger oss fint till ämnet MultiChain XNUMX.

MultiChain 2.0-översikt

Version 2.0 av MultiChain kommer att vara den första som kommer i två utgåvor - Community (open source) och Enterprise (kommersiell). Jag kommer att fokusera här på den kostnadsfria gemenskapsutgåvan, eftersom vi bara diskuterar informationen om MultiChain Enterprise med våra partners. I vilket fall som helst kommer gemenskaps- och Enterprise-utgåvorna att vara mycket kompatibla, eftersom: (a) applikationer byggda på Community-upplagan kommer att köras utan modifiering på MultiChain Enterprise, och (b) båda utgåvorna kommer att kunna ansluta och handla med varandra på samma kedja.

De tre nyckelområdena med förbättrad funktionalitet i båda versionerna av MultiChain 2.0 kommer att vara:

• Rikare datamodell för strömmar, inklusive JSON-dokument.
• Anpassade programmerbara transaktionsfilter för validering på kedjan.
• Sömlös uppdatering av blockchains protokoll och parametrar.

Låt oss vända oss för att diskutera var och en av dessa i detalj.

Rikare datamodell för strömmar

MultiChain-strömmar introducerades i september 2016 och har visat sig vara mycket populära. Som beskrivs i detta inlägg, strömmar ger en enkel och naturlig abstraktion för datalagring, indexering och hämtning av allmänna ändamål på en blockchain. En MultiChain-blockchain kan innehålla valfritt antal namngivna strömmar, var och en kan antingen vara öppen för alla för att skriva, eller endast skrivbar från vissa adresser.

I MultiChain 1.0 har varje strömobjekt en eller flera utgivare (som undertecknar det), en valfri nyckel, en binär data nyttolast upp till 64 MB i storlek och en tidsstämpel (härledd från blocket där det är inbäddat). Varje nod kan fritt bestämma vilka strömmar att prenumerera på, eller kan prenumerera på alla strömmar automatiskt. Om en nod prenumereras på en ström, indexeras den strömmens innehåll i realtid, vilket möjliggör effektiv återhämtning av utgivare, nyckel, block, tidsstämpel eller position.

MultiChain 2.0 kommer att berika denna strömningsfunktionalitet på flera sätt:

• JSON artiklar. Förutom binära data, kommer strömföremål att stödja strukturerade JSON-objekt, lagrade på blockchainen i ett effektivt serialiseringsformat, t.ex. UBJSON. Eftersom MultiChain API redan använder JSON genomgående kommer dessa JSON-objekt att vara skrivbara och läsbara på ett naturligt och uppenbart sätt.
• Flera tangenter. Strömobjekt stöder flera nycklar, vilket gör att en enskild data kan indexeras på flera sätt för hämtning med liststreamkeyitems. Vi utvärderar ständigt hur mycket databasfunktionalitet som ska inkluderas i MultiChain och förväntar oss inte att stödja indexering av delelementen i JSON-strömobjekt i version 2.0. Att tillåta flera nycklar per strömobjekt ger en rimlig lösning.
• Atomic skriver om flera artiklar. MultiChain 1.0 tillåter en enda transaktion att skriva till flera strömmar, men inte att skriva flera objekt till samma ström. MultiChain 2.0 tar bort denna begränsning.
• JSON sammanslagning. Alla ordnade listor med JSON-objekt kan naturligt plattas eller sammanfattas för att skapa ett "sammanslaget" objekt. Det sammanslagna objektet innehåller alla nycklar som visas i de enskilda objekten, där värdet som motsvarar varje nyckel tas från det sista objektet där den nyckeln visas. Om du vill är det sammanslagna objektet det slutliga läget för en databasrad, vars kolumner definieras av det första objektet och utökas eller uppdateras av senare objekt. MultiChain 2.0 lägger till API: er för att enkelt och snabbt hämta det sammanslagna objektet för JSON-objekt i en ström med en viss nyckel eller utgivare.

Dessa funktioner kommer från vanliga sätt på vilka utvecklare för närvarande använder strömmar. Med andra ord, vi observerar vad många bygger ovanpå MultiChain på applikationsnivå och tar med den funktionen i MultiChain själv - ett mönster som vi tänker fortsätta att använda. Nu när strömobjekt innehåller typinformation kan de lätt utökas i framtiden för att stödja andra dataformat som XML, hdf5 och MIMA-identifierat innehåll. För att inte nämna möjligheterna till transparent komprimering och kryptering på kedjan.

MultiChain 2.0 kommer också att stödja JSON-objekt för rå transaktionsmetadata (dvs inte strömobjekt) samt metadata för tillgångsutgivning och strömskapande händelser, istället för text-endast nyckel- / värdepar som implementerats i MultiChain 1.0. De listassets API kommer att erbjuda JSON sammanslagning mellan alla tillgångarnas emissioner, så att varje utgivares metadata effektivt kan uppdatera tillgångens slutliga beskrivning.

Anpassade transaktionsfilter

Vi har funderat mycket på hur man lägger till anpassade programmerbara regler till MultiChain. Även om Ethereums “smart contract” -paradigm är populärt, har det ett antal viktiga brister för tillåtna blockchains med hög kapacitet. För det första introducerar smarta kontrakt ett globalt beroende i hela blockchains hela tillstånd, vilket drastiskt försämrar samtidighet och prestanda. För det andra kan smarta kontrakt inte hindra felaktiga transaktioner från att inbäddas i en blockchain, utan endast hindra dessa transaktioner från att uppdatera blockchain-databasens status. Även om vi på lång sikt förväntar oss att en Ethereum-kompatibel virtuell maskin kommer att erbjudas som en abstraktion på hög nivå inom MultiChain, tror vi inte att det är rätt lösning för validering på låg nivå.

MultiChain 2.0 kommer att införa ett annat paradigm som kallas transaktionsfilter, som validerar enskilda transaktioner utan hänvisning till något globalt tillstånd. Vi förväntar oss att filter ska skrivas i Javascript och köras i en inbäddad körmotor som v8, som används i Googles krom webbläsare och node.js plattform. Naturligtvis måste vi se till att filterkoden körs identiskt på varje nod i en blockchain, vilket blockerar någon källor till icke-determinism till exempel att läsa tiden, använda slumpmässiga nummer, komma åt nätverk eller disk eller utföra matematiska operationer som är beroende av värdserverns arkitektur. Att skapa en deterministisk Javascript runtime-miljö är en utmaning, men (utan att ge för mycket bort) tror vi att det kommer att vara användbart för flera andra MultiChain-funktioner i framtiden.

Filter kommer att passera ett JSON-objekt som beskriver en enskild transaktion, strukturerad som utgången från decoderawtransaction men med extra fält. Till exempel kommer varje transaktionsinmatning i JSON att inkludera en struktur som beskriver den tidigare transaktionsutgången den tillbringar, och varje adress kommer att åtföljas av en lista med behörigheter som för närvarande innehas av den adressen. Ett filters jobb är att returnera ett booleskt värde som anger om transaktionen är acceptabel och om inte, ge ett textfel som förklarar varför. MultiChains API kommer att inkludera kommandon för att skapa filter, testa dem på tidigare eller nya transaktioner och aktivera dem med förbehåll för administratörens konsensus.

Till skillnad från smarta kontrakt, om ett fel upptäcks i koden för ett filter, kan det enkelt ersättas av en ny version. Men liksom alla Turing-kompletta koder riskerar filter fortfarande att komma in i en oändlig slinga. Detta problem kommer att mildras på två sätt:

• Filter kan bara installeras och aktiveras av kedjans administratörer, med förbehåll för konsensus. Detta ger varje administratör möjlighet att undersöka ett filters kod djup innan de röstar för att det ska aktiveras.
• Alla välskötta noder validerar nya transaktioner med de aktiva filtren innan de vidarebefordras till sina peer-noder. Som ett resultat, om en transaktion skickar ett filter till en oändlig slinga, bör transaktionen inte spridas utöver den nod som skapade den.

Vi förväntar oss att en populär applikation för filter validerar strömföremål. Till exempel kan ett filter säkerställa att vissa fält i en strömmen JSON-objekt innehåller nummer i ett specifikt intervall. I MultiChain 1.0 måste denna typ av validering göras på applikationsnivå, antingen när du skriver strömobjekt (om källan är betrodd) eller när du läser dem. Däremot kommer MultiChain 2.0 att göra det möjligt att integrera dessa regler i blockchainen, snarare som kontrollera begränsningar i en relationsdatabas.

MultiChain 2.0 kommer att innehålla ytterligare två funktioner för att göra filter ännu kraftfullare. Först kommer det att introducera användardefinierade behörigheter, som finns bredvid de åtta behörigheter som definierats av MultiChain. Som med vanliga behörigheter, kommer dessa att beviljas till specifika adresser av administratörer (och i vissa fall av användare med activate privilegier) och ingår tillsammans med adresser i JSON-objektet som skickas till ett filter. Till exempel kan ett filter säkerställa att endast adresser med en viss användardefinierad behörighet kan skriva vissa typer av data till en ström eller transaktera i en viss tillgång över en viss tröskel.

För det andra kommer MultiChain 2.0 att stödja anpassade (binära eller JSON) metadata inom vanliga transaktionsutgångar. Detta möjliggör för varje utgång att fungera som en allmän databasrad, "ägs" av adressen inom. Filter kommer att se alla metadata i en transaktions förbrukade och skapade utgångar som en del av dess JSON-beskrivning. Som ett resultat blir MultiChain en universell delad databasmotor, där en transaktions giltighet bestäms av en anpassningsbar funktion för de rader som den skapar och raderar. (Om detta låter lite abstrakt kommer vi att ge några konkreta exempel.)

Blockchain-uppdatering

Eftersom blockchains är utformade för att köras i många år kan deras egenskaper behöva ändras över tid. Den nuvarande versionen av MultiChain tillhandahåller redan en viss flexibilitet, vilket gör att behörighetsändringar (inklusive administratörer och gruvarbetare genom konsensus), nya tillgångar och strömmar kan skapas och noder enkelt kan läggas till eller tas bort från nätverket. I MultiChain 1.0 är dock blockchains grundläggande parametrar, såsom maximal blockstorlek och målbekräftelsetid, är fixade när kedjan skapas och inte kan ändras därefter.

MultiChain 2.0 kommer att lägga till möjligheten att uppdatera en blockchain, vilket gör att många (men inte alla) parametrar kan ändras medan kedjan fortsätter att köras. Liksom andra viktiga åtgärder kräver en uppdatering av en blockchain en anpassningsbar nivå för administratörskonsensus, där denna nivå i sig är en parameter som kan ändras. Uppdateringar träder i kraft från ett visst block och gäller därefter på varje efterföljande block fram till nästa uppdatering.

Blockchain-parametrar som kan uppdateras kommer att inkludera:

• Protokollversion. Detta gör att en blockchain som skapats med en version av MultiChain kan uppgraderas för att stödja funktionerna i en ny version, till exempel JSON-strömföremål eller transaktionsfilter. Faktum är att protokollversionen 10008 introducerad i MultiChain 1.0 alpha 29 (och används i beta) har redan blivit framtidssäkrat med odokumenterat stöd för den här typen av uppgradering. När en MultiChain 1.0-blockchain har uppgraderats till 2.0-protokollet kommer den också att få tillgång till de andra parameterändringarna som beskrivs här.
• Blockchain-skalning. Blockchains som blir populära kan växa ut de initiala värdena som ställts in för deras målbekräftelsestid eller maximal transaktion och blockstorlek. MultiChain 2.0 gör att dessa värden kan höjas eller sänkas vid behov.
• Tillståndsmodell. MultiChain 2.0 tillåter uppdatering av många parametrar som gäller tillstånd och styrning, inklusive: (a) anyone-can-* parametrar som styr sättet på vilket en blockchain är öppen eller stängd, (b) admin-consensus-* parametrar som bestämmer nivåerna för administratörens konsensus som krävs för vissa operationer, och (c) mining-diversity -parameter som styr striktheten för den runda robin-konsensusalgoritmen.

När denna uppdateringsfunktionalitet har implementerats bör det inte finnas någon anledning till att en blockchain skapad i MultiChain inte kan köras på många decennier eller mer.

Ser framåt

Vi har redan börjat arbeta med MultiChain 2.0 och ser fram emot att leverera på denna färdplan. Utan tvekan kommer även andra förbättringar att inkluderas. Liksom med MultiChain 1.0, kommer vi att ha alfabetigningar längs vägen, så att utvecklare kan använda och lära sig nya funktioner när de implementeras (och naturligtvis rapportera eventuella problem eller brister). Naturligtvis fortsätter vi att behålla version 1.0 under denna period och fixar eventuella fel som visas.

Jag vill avsluta med att tacka vårt utvecklingsteam, ledat av Dr Michael Rozantsev, för deras fortsatta excellens och hårda arbete. Vi ser MultiChain som ett okomplicerat programvaruteknikprojekt, där kodkvalitet och testning räknas framför allt. Det är mitt privilegium att arbeta med människor som kan förvandla en komplex produktvision till stabil arbetsprogramvara med så anmärkningsvärd effektivitet och snabbhet.

Skicka eventuella kommentarer på Link.