Kunngjøring av den nye MultiChain-lommeboken

Et viktig skritt fremover for ytelse og skalerbarhet

Etter to måneder med intensiv utvikling og testing er vi stolte over å slippe den nyeste alfaen til MultiChain, med en fullstendig omskrevet lommebok i node. Denne nye lommeboken transformerer ytelsen og skalerbarheten ved å opprette, motta og lagre transaksjoner i MultiChain.

Før vi går inn på detaljene, la meg gi litt kontekst. Da vi begynte å utvikle MultiChain, tok vi beslutningen om å bruke Bitcoin Core, standardnoden for det offentlige bitcoin-nettverket, som utgangspunkt. I programmeringstermer betyr dette at MultiChain er en "gaffel" av bitcoin-programvaren. Vårt primære resonnement var at bitcoin var (og fortsetter å være) det høyest verdsatte og mest kamptestede kryptovaluta-økosystemet på en eller annen måte.

På plussiden hjalp denne avgjørelsen oss raskt på markedet, sammenlignet med å kode opp en blockchain-node fra bunnen av. Til tross for de mange forskjellene mellom offentlige og private blokkjeder, deler de en stor mengde teknisk felles grunnlag, inkludert peer-to-peer-protokollen, transaksjons- og blokkstruktur, opprettelse og verifisering av digital signatur, konsensusregler, nøkkelhåndtering og behovet for et node-API. Forking fra Bitcoin Core tillot oss å utnytte dens modenhet og fokusere på hva MultiChain legger til blokkjeder – konfigurerbarhet, tillatelse og støtte for innfødt aktiva. Som et resultat kunne vi slippe den første alfaen i juni 2015, bare 6 måneder etter utviklingsstart.

Men ved siden av disse fordelene, måtte vi også akseptere det faktum at noen aspekter av Bitcoin Core er dårlig utformet. Mens de fungerer helt fint i små skalaer, reduseres ytelsen deres dramatisk etter hvert som bruken øker. Med det offentlige bitcoin-nettverket fortsatt begrenset til noen få transaksjoner per sekund, vil dette ikke være et problem for de fleste Bitcoin Core-brukere på lenge. Men med private blokkjeder som sikter mot hundrevis eller tusenvis av transaksjoner per sekund, visste vi at før eller siden måtte disse flaskehalsene fjernes.

Bitcoin Cores lommebok

"Lommeboken" i Bitcoin Core var alltid den mest avgjørende av disse smertepunktene. Dens jobb er å lagre transaksjonene som er av spesiell relevans for noden, fordi de involverer en blokkjedeadresse som den eier eller en "bare se" adresse hvis aktivitet den sporer. For eksempel må hver transaksjon som sender midler til eller fra en node lagres i nodens lommebok. Og hver gang en node oppretter en transaksjon, må den søke etter en eller flere "ubrukte utganger" av tidligere lommeboktransaksjoner som den nye transaksjonen vil bruke.

Så hva er galt med lommeboken vi arvet fra Bitcoin Core? Egentlig tre ting:

• Alle lommeboktransaksjoner lagres i minnet. Dette forårsaker langsomme oppstartstider og raskt økende minnebruk.
• Mange operasjoner utfører en ineffektiv "full skanning" av hver transaksjon i lommeboken, enten gammel eller ny.
• Hver transaksjon i lommeboken lagres i sin helhet, inkludert eventuelle vilkårlige "metadata" som ikke har noen betydning fra nodens perspektiv og som allerede er lagret i blokkjeden på disken. Dette er veldig bortkastet.

Konsekvensen er at, med rundt 20,000 200,000 lagrede transaksjoner, bremser Bitcoin Core sin lommebok betydelig. Etter 8 80 eller så stopper det nesten opp. Enda verre, siden en MultiChain-blokkjede tillater opptil XNUMX MB metadata per transaksjon (sammenlignet med bitcoins XNUMX byte), kan lommebokens minnekrav bli raskere selv med et lite antall transaksjoner.

Det er viktig å presisere at disse manglene bare gjelder for Bitcoin Core lommebok, snarere enn dens generelle transaksjonsbehandlingskapasitet. Med andre ord kan den enkelt behandle og lagre millioner (eller til og med milliarder) av transaksjoner som ikke er relatert til dens egne adresser, siden disse holdes på disk i stedet for i minnet. For eksempel bruker mange populære bitcoin-børser og lommebøker Bitcoin Core som de er, men lagrer sine egne transaksjoner eksternt i stedet for inne i noden.

MultiChains nye lommebok

Vi kunne ha stilt samme krav til MultiChain-brukere, å lagre sine egne transaksjoner utenfor noden. Dette føltes imidlertid ikke som den riktige løsningen fordi det ville komplisere oppsettet og vedlikeholdet for hver av deltakerne i en kjede. Så i stedet bet vi i kulen og skrev om lommeboken fra grunnen av.

Hvordan skiller den nye lommeboken seg? Hvis du har noen erfaring med databaser, kan svarene være åpenbare:

• I stedet for å holde lommeboktransaksjonene i minnet, lagres de på disk i et passende format, med transaksjoner av interesse hentet når det er nødvendig.
• I stedet for å utføre full lommebokskanning, blir transaksjonene "indeksert" på forskjellige måter for å gjøre det mulig raskt å finne de som oppfyller bestemte kriterier.
• Ethvert stykke transaksjonsmetadata som er større enn 256 byte lagres ikke i lommeboken. I stedet inneholder lommeboken en peker til metadataens posisjon i selve blokkjeden.

Med andre ord, vi har gjenoppbygd in-node-lommeboken for å være riktig databasedrevet (ved hjelp av NivåDB), i stedet for å stole på en naiv struktur i minnet som ikke kan søkes effektivt. Ikke overraskende er forskjellen (målt på en 3.4 GHz Intel Core i7) ganske dramatisk:

Grafene viser at når den gamle lommeboken inneholder 250,000 3 transaksjoner, synker sendehastigheten til 600 tx/sek og den legger til 100 MB til nodens minnebruk. Derimot holder den nye lommeboken over 90 tx/sek og legger bare til 6 MB. Vi sluttet å teste den gamle lommeboken på dette tidspunktet, men selv med 8-100 millioner lagrede transaksjoner, fortsetter den nye lommeboken å sende over 250 tx/sek, og den topper på rundt XNUMX MB RAM brukt (på grunn av databasebufring).

Disse testene ble utført under realistiske forhold, med flere adresser og eiendeler (og derfor mange ubrukte transaksjonsutganger) i nodens lommebok. I et idealisert scenario (én adresse, ett aktivum, få UTXO-er), var den vedvarende sendehastigheten over 400 tx/s. Uansett, som en del av denne omskrivingen, har vi også abstrahert all lommebokens funksjonalitet bak et rent internt grensesnitt. Dette vil gjøre det enkelt å støtte andre databasemotorer i fremtiden, for enda større robusthet og hastighet.

For å gjenta, refererer alle disse tallene til hastigheten som en node kan opprette, sende og lagre transaksjoner med i sin lokale lommebok, snarere enn dens gjennomstrømning når det gjelder behandling av transaksjoner opprettet av andre. For generell nettverksgjennomstrømning kan MultiChain for øyeblikket behandle 200 til 800 tx/sek, avhengig av maskinvaren den kjører på. (Vær skeptisk til blockchain-programvare som lover tall som 100,000 XNUMX tx/sek på vanlig maskinvare, fordi flaskehalsen er verifisering av digital signatur, som tar sanntid å utføre. Hvis noder ikke verifiserer individuelle transaksjonssignaturer, kan en blokkjede umulig brukes på tvers av tillit. grenser, noe som gjør den ikke bedre enn en vanlig distribuert database.)

Til slutt vil jeg nevne den neste store funksjonen som kommer til MultiChain, som krevde omskriving av denne lommeboken. Denne funksjonen, kalt strømmer, gir en abstraksjon på høyt nivå og API for generell datalagring på en blokkjede. Du kan tenke på en strøm som en tidsserie- eller nøkkelverdidatabase, med de ekstra blokkjederelaterte fordelene med desentralisering, digitale signaturer, tidsstempling og uforanderlighet. Vi vet om mange blockchain-brukstilfeller som kan bruke denne funksjonaliteten, og vi jobber allerede hardt med å bygge den. Se denne plassen.

Legg inn kommentarer på Linkedin.

Teknisk tillegg

Fra MultiChain alpha 22 kan du bekrefte hvilken versjon av lommeboken som kjører for øyeblikket ved å undersøke walletdbversion felt av getinfo or getwalletinfo API-kall. En verdi på 1 betyr den originale Bitcoin Core-lommeboken, og 2 betyr den nye MultiChain-lommeboken.

Hvis du kjører den nye versjonen av MultiChain på en eksisterende kjede, vil den ikke umiddelbart bytte til den nye lommeboken. Du kan oppgradere lommeboken ved å stoppe noden og deretter kjøre den på nytt multichaind med parametrene -walletdbversion=2 –rescan. Du kan nedgradere på samme måte ved å bruke –walletdbversion=1 –rescan.

Som standard, når du starter en node på en ny kjede, vil den automatisk bruke den nye lommeboken. Du kan endre dette ved å kjøre multichaind for første gang med parameteren –walletdbversion=1.

Med den nye lommeboken, alt sammen MultiChain APIer fungerer nøyaktig på samme måte som før, med unntak av de gamle transaksjonsspørrings-APIene getreceivedbyaddress, listreceivedbyaddress og listtransactions (bruk listwallettransactions or listaddresstransactions i stedet). I tillegg støtter ikke den nye lommeboken API-anrop og parametere knyttet til Bitcoin Cores dårlig implementerte og snart avviklede «kontoer»-mekanisme, som aldri ble riktig støttet av MultiChain. Disse samtalene er trygt deaktivert med en feilmelding.

Kilde: https://www.multichain.com/blog/2016/07/announcing-the-new-multichain-wallet/