MultiChain 1.0 beta 2 og 2.0 veikart

Hvor vi er i dag og hvor vi skal i morgen

I dag er vi glade for å gi ut den andre betaversjonen av MultiChain 1.0 for Linux, Windows og Mac (for nå krever Mac-versjonen kompilering). Dette avslutter den planlagte utviklingen av MultiChain 1.0 - med unntak av eventuelle feilrettinger, vil den endelige utgivelsen av MultiChain 1.0 i løpet av sommeren være uendret.

Denne måneden er det også to år siden den første alfa-utgivelsen av MultiChain i juni 2015. Som med ethvert nytt produkt, var vi ikke sikre på hvordan markedet ville reagere, og visste at det bare var en måte å finne ut av - slipp en minimum levedyktig produkt, som betyr en innledende versjon som gir betydelig verdi, men som er foreløpig av design. Heldigvis, i motsetning til vårt første produkt CoinSpark, Mottok MultiChain en sterk og umiddelbar positiv respons. Dette ble ledsaget av en tsunami av fornuftige funksjonsforespørsler, hvorav mange vi nå har implementert. Parallelt med produktets utvikling har bruken også vokst bemerkelsesverdig i alle mål. For eksempel mottok MultiChain-nettstedet under 3,000 besøkende i juli 2015, og bringer nå inn ti ganger det antallet månedlig.

MultiChain ytelse

I løpet av de siste to årene har vi investert mye krefter i å optimalisere MultiChain, som ble gitt fra Bitcoin Core, referanseimplementeringen for det offentlige bitcoin-nettverket. Nedenfor er en sammenligning av transaksjonsgjennomstrømning for et enkeltnodsoppsett ved bruk av fem versjoner av produktet:

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

Totalt antall transaksjoner	1.0 alfa 3	1.0 alfa 21	1.0 alfa 22	1.0 1 beta	1.0 2 beta
100	6.5 ts	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

Gjennomsnittlige transaksjoner per sekund, inkludert API-overhead og bygning, signering, gruvedrift og verifisering av transaksjoner og blokkeringer.
Test utført med ab HTTP-server benchmarking verktøy som sender to samtidige forespørsler til sendtoaddress API.
Serverspesifikasjoner: Intel Core i7-4770, 4 kjerner @ 3.4 MHz, 32 GB RAM, Seagate 2 TB 7200 RPM SATA, CentOS 6.4.

Naturligvis kom det største hoppet i alfa 22 da vi overført til en databasedrevet lommebok. Men siden utgivelsen har vi nesten doblet MultiChains hastighet igjen. Vi håper vi har demonstrert at bitcoins grense på 4 transaksjoner per sekund skyldes de spesifikke nettverksparametrene, og har ingen sammenheng med blokkjeder generelt.

Selvfølgelig er ytelsesoptimalisering en uendelig oppgave, og det er ingen grunn til at MultiChain ikke kan nå 10,000 tx / sek på en 16-kjerners prosessor med de aktuelle arkitektoniske endringene. Basert på samtaler med våre brukere og partnere ser det ut til at få forventer å trenge mer enn 1,000 tx / sek de neste årene. Så vi fokuserer utviklingsarbeidet vårt på nye funksjoner, noe som bringer oss pent inn i emnet MultiChain 2.0.

MultiChain 2.0 oversikt

Versjon 2.0 av MultiChain vil være den første som kommer i to utgaver - Community (open source) og Enterprise (kommersiell). Jeg kommer til å fokusere her på den gratis Community-utgaven, siden vi bare diskuterer detaljene i MultiChain Enterprise med våre partnere. Under alle omstendigheter vil Community- og Enterprise-utgavene være svært kompatible, ved at: (a) applikasjoner bygget på Community-utgaven vil kjøre uten endring på MultiChain Enterprise, og (b) begge utgavene vil være i stand til å koble til og handle med hverandre på samme kjede.

De tre viktigste områdene med forbedret funksjonalitet i begge utgavene av MultiChain 2.0 vil være:

• Rikere datamodell for strømmer, inkludert JSON-dokumenter.
• Egendefinerte programmerbare transaksjonsfiltre for validering i kjeden.
• Sømløs oppdatering av blockchain-protokollen og parametrene.

La oss snu for å diskutere hver av disse i detalj.

Rikere datamodell for strømmer

MultiChain-strømmer ble introdusert i september 2016 og har vist seg å være ekstremt populære. Som beskrevet i dette innlegget, streams gir en enkel og naturlig abstraksjon for generell datalagring, indeksering og henting på en blockchain. En MultiChain-blokkjede kan inneholde et hvilket som helst antall navngitte strømmer, som hver kan være åpne for alle for skriving, eller bare skrivbare fra bestemte adresser.

I MultiChain 1.0 har hvert strømelement en eller flere utgivere (som signerer det), en valgfri nøkkel, en binær data-nyttelast opptil 64 MB i størrelse og et tidsstempel (avledet fra blokken der det er innebygd). Hver node kan fritt bestemme hvilke strømmer de vil abonnere på, eller kan abonnere på alle strømmer automatisk. Hvis en node abonnerer på en strøm, indekserer den strømens innhold i sanntid, noe som tillater effektiv gjenfinning av utgiver, nøkkel, blokk, tidsstempel eller posisjon.

MultiChain 2.0 vil berike denne strømmen funksjonalitet på en rekke måter:

• JSON-varer. I tillegg til binære data, vil strømelementer støtte strukturerte JSON-objekter, lagret på blockchain i et effektivt serialiseringsformat som UBJSON. Siden MultiChain API allerede bruker JSON overalt, vil disse JSON-objektene være skrivbare og lesbare på en naturlig og åpenbar måte.
• Flere taster. Stream-elementer støtter flere taster, slik at et enkelt stykke data kan indekseres på flere måter for henting ved hjelp av liststreamkeyitems. Vi evaluerer kontinuerlig hvor mye databasefunksjonalitet som skal inkluderes i MultiChain, og forventer ikke å støtte indeksering av underelementene i JSON-strømelementer i versjon 2.0. Å tillate flere nøkler per strømelement gir en rimelig løsning.
• Atomic skriver om flere gjenstander. MultiChain 1.0 tillater at en enkelt transaksjon kan skrive til flere strømmer, men ikke å skrive flere elementer til samme strøm. MultiChain 2.0 vil fjerne denne begrensningen.
• JSON fusjonerer. Enhver bestilt liste over JSON-objekter kan naturlig flates eller oppsummeres for å lage et "sammenslått" objekt. Det sammenslåtte objektet inneholder alle nøklene som vises i de enkelte objektene, hvor verdien som tilsvarer hver nøkkel er hentet fra det siste objektet der nøkkelen vises. Hvis du vil, er det sammenslåtte objektet den endelige tilstanden til en databaserad, hvis kolonner er definert av det første objektet og utvidet eller oppdatert av senere objekter. MultiChain 2.0 vil legge til API-er for å enkelt og raskt hente det sammenslåtte objektet for JSON-elementene i en strøm med en bestemt nøkkel eller utgiver.

Disse funksjonene er hentet fra vanlige måter som utviklere for tiden bruker strømmer på. Med andre ord observerer vi hva mange mennesker bygger på toppen av MultiChain på applikasjonsnivå, og bringer den funksjonaliteten inn i MultiChain selv - et mønster som vi har tenkt å fortsette å bruke. Nå som strømelementer vil inneholde typeinformasjon, kan de enkelt utvides i fremtiden for å støtte andre dataformater som XML, HDF5 og MIME-identifisert innhold. For ikke å nevne mulighetene for gjennomsiktig kompresjon og kryptering på kjeden.

MultiChain 2.0 støtter også JSON-objekter for rå transaksjonsmetadata (dvs. ikke stream-elementer), samt metadata for aktivautstedelse og streamopprettingshendelser, i stedet for de eneste tekstnøkkelen / verdiparene implementert i MultiChain 1.0. De listassets API vil tilby JSON-sammenslåing på tvers av alle aktivaets utstedelseshendelser, slik at metadata for hver utstedelse effektivt kan oppdatere eiendelens endelige beskrivelse.

Egendefinerte transaksjonsfiltre

Vi har tenkt mye på hvordan vi kan legge til egendefinerte programmerbare regler til MultiChain. Selv om Ethereums "smarte kontrakt" -paradigme er populært, har det en rekke viktige mangler for tillatte blokkjeder med høy gjennomstrømning. For det første introduserer smarte kontrakter en global avhengighet over hele blockchain-staten, noe som drastisk svekker samtidighet og ytelse. For det andre kan ikke smarte kontrakter hindre at uriktige transaksjoner blir innebygd i en blockchain, men bare forhindre at disse transaksjonene oppdaterer blockchain-databasens tilstand. Mens vi på lang sikt forventer at en Ethereum-kompatibel virtuell maskin skal tilbys som en abstraksjon på høyt nivå innen MultiChain, tror vi ikke det er den rette løsningen for validering på lavt nivå.

MultiChain 2.0 vil introdusere et annet paradigme kalt transaksjonsfiltre, som validerer individuelle transaksjoner uten referanse til noen global stat. Vi forventer at filtre skal skrives i Javascript og kjøres i en innebygd kjøretidsmotor som f.eks v8, som brukes i Googles Chrome nettleser og node.js plattform. Selvfølgelig må vi sørge for at filterkoden kjører identisk på hver node i en blockchain, og blokkerer hvilken som helst kilder til ikke-determinisme som å lese tiden, bruke tilfeldige tall, få tilgang til nettverk eller disk, eller utføre matematiske operasjoner som avhenger av vertsservers arkitektur. Å lage et deterministisk Javascript runtime-miljø er en utfordring, men (uten å gi for mye bort) tror vi det vil være nyttig for flere andre MultiChain-funksjoner i fremtiden.

Filtrene vil bli sendt et JSON-objekt som beskriver en individuell transaksjon, strukturert som utdataene fra decoderawtransaction men med ekstra felt. For eksempel vil hver transaksjonsinngang i JSON inneholde en struktur som beskriver den forrige transaksjonsutgangen den bruker, og hver adresse vil bli ledsaget av en liste over tillatelser som den adressen for øyeblikket har. Et filters jobb er å returnere en boolsk verdi som indikerer om transaksjonen er akseptabel, og hvis ikke, gi en tekstfeil som forklarer hvorfor. MultiChains API vil inneholde kommandoer for å lage filtre, teste dem på tidligere eller nye transaksjoner, og aktivere dem med forbehold om administratorkonsensus.

I motsetning til smarte kontrakter, hvis en feil blir oppdaget i koden for et filter, kan den enkelt erstattes av en ny versjon. Likevel, som alle Turing-komplette koder, risikerer filtre fortsatt å gå inn i en uendelig løkke. Dette problemet vil avbøtes på to måter:

• Filtre kan bare installeres og aktiveres av kjedens administratorer, med forbehold om konsensus. Dette gir hver administrator mulighet til å undersøke koden til et filter i dybden før han stemmer på at det skal aktiveres.
• Alle veloppførte noder vil validere nye transaksjoner ved hjelp av de aktive filtrene før de videresendes til deres node-noder. Som et resultat, hvis en transaksjon sender et filter til en uendelig sløyfe, bør ikke transaksjonen spre seg utover noden som opprettet den.

Vi forventer at en populær applikasjon for filtre skal validere strømelementer. For eksempel kan et filter sikre at visse felt i JSON-elementene til en strøm inneholder tall i et bestemt område. I MultiChain 1.0 må denne typen validering gjøres på applikasjonsnivå, enten når du skriver strømelementer (hvis kilden er klarert) eller når du leser dem. Derimot vil MultiChain 2.0 muliggjøre at disse reglene blir innebygd i selve blockchain, snarere som sjekk begrensninger i en relasjonsdatabase.

MultiChain 2.0 vil inneholde to tilleggsfunksjoner for å gjøre filtre enda kraftigere. Først vil den introdusere brukerdefinerte tillatelser, som eksisterer ved siden av de åtte tillatelsene som er definert av MultiChain. Som med vanlige tillatelser, vil disse bli gitt til bestemte adresser av administratorer (og i noen tilfeller av brukere med activate privilegier) og inkludert ved siden av adresser i JSON-objektet sendt til et filter. For eksempel kan et filter sørge for at bare adresser med en bestemt brukerdefinert tillatelse kan skrive bestemte typer data til en strøm, eller gjøre transaksjoner i en bestemt ressurs over en viss terskel.

For det andre vil MultiChain 2.0 støtte egendefinerte (binære eller JSON) metadata innenfor vanlige transaksjonsutganger. Dette vil gjøre det mulig for enhver utgang å fungere som en generell databaserad, "eid" av adressen i. Filtre vil se alle metadata i en transaksjons brukte og opprettede utdata som en del av JSON-beskrivelsen. Som et resultat vil MultiChain bli en universell delt databasemotor, der en transaksjonens gyldighet bestemmes av en tilpassbar funksjon av radene den oppretter og sletter. (Hvis dette høres litt abstrakt ut, vil vi være sikre på å gi noen konkrete eksempler.)

Blockchain oppdatering

Siden blokkjeder er designet for å kjøre i mange år, kan det hende at deres egenskaper må endres over tid. Den nåværende versjonen av MultiChain gir allerede en god grad av fleksibilitet, slik at tillatelsesendringer (inkludert administratorer og gruvearbeidere etter konsensus), nye eiendeler og strømmer kan opprettes, og noder kan legges til eller fjernes sømløst fra nettverket. Ikke desto mindre er en blockchain grunnleggende i MultiChain 1.0 parametere, slik som maksimal blokkstørrelse og målbekreftelsestid, er løst når kjeden opprettes og kan ikke endres senere.

MultiChain 2.0 vil legge til muligheten til å oppdatere en blockchain, slik at mange (men ikke alle) parametere kan endres mens kjeden fortsetter å kjøre. Som andre viktige operasjoner, vil oppdatering av en blockchain kreve et tilpassbart nivå av administratorkonsensus, hvor dette nivået i seg selv er en parameter som kan endres. Oppdateringer trer i kraft fra en bestemt blokk, og gjelder deretter for hver påfølgende blokk til neste oppdatering.

Blockchain-parametere som kan oppdateres inkluderer:

• Protokollversjon. Dette vil gjøre det mulig å oppgradere en blockchain opprettet med en versjon av MultiChain for å støtte funksjonene i en ny versjon, for eksempel JSON-strømelementer eller transaksjonsfiltre. Faktisk protokollversjonen 10008 introdusert i MultiChain 1.0 alpha 29 (og brukt i beta) har allerede blitt fremtidssikret med papirløs støtte for denne typen oppgradering. Når en MultiChain 1.0 blockchain er oppgradert til 2.0-protokollen, vil den også få tilgang til de andre parameterendringene som er beskrevet her.
• Blockchain-skalering. Blokkjeder som blir populære, kan vokse ut de opprinnelige verdiene som er angitt for deres målbekreftelsestid eller maksimale transaksjons- og blokkstørrelser. MultiChain 2.0 vil tillate at disse verdiene økes eller reduseres etter behov.
• Tillatelsesmodell. MultiChain 2.0 vil tillate oppdatering av mange parametere knyttet til tillatelse og styring, inkludert: (a) anyone-can-* parametere som styrer måter en blockchain er åpen eller lukket, (b) admin-consensus-* parametere som bestemmer nivået av administratorkonsensus som kreves for visse operasjoner, og (c) mining-diversity parameter som kontrollerer strengheten til round-robin konsensusalgoritmen.

Når denne oppdateringsfunksjonaliteten er implementert, bør det ikke være noen grunn til at en blockchain opprettet i MultiChain ikke kan kjøre i mange tiår eller mer.

Ser framover

Vi har allerede startet arbeidet med MultiChain 2.0, og ser frem til å levere på denne veikartet. Utvilsomt vil også andre forbedringer være inkludert. Som med MultiChain 1.0, har vi alfa-utgivelser underveis, slik at utviklere kan bruke og lære nye funksjoner når de implementeres (og selvfølgelig rapportere eventuelle problemer eller mangler). Naturligvis vil vi fortsette å vedlikeholde versjon 1.0 gjennom hele denne perioden, og fikse eventuelle feil som vises.

Jeg vil avslutte med å takke vårt utviklingsteam, ledet av Dr Michael Rozantsev, for deres fortsatte fortreffelighet og harde arbeid. Vi ser på MultiChain som et enkelt programvareingeniørprosjekt der kodekvalitet og testing teller fremfor alt. Det er mitt privilegium å jobbe med mennesker som kan gjøre en kompleks produktvisjon til stabil arbeidsprogramvare med så bemerkelsesverdig effektivitet og hastighet.

Legg inn kommentarer på Linkedin.