Vi introduserer MultiChain Streams

Publisert av Platon

Følgere: 0

For delte uforanderlige nøkkelverdi- og tidsseriedatabaser

I dag er vi stolte over å slippe den nyeste versjonen av MultiChain, som implementerer et viktig nytt sett med funksjonalitet kalt "strømmer". Strømmer gir en naturlig abstraksjon for blockchain-brukstilfeller som fokuserer på generell datainnhenting, tidsstempling og arkivering, snarere enn overføring av eiendeler mellom deltakere. Strømmer kan brukes til å implementere tre forskjellige typer databaser på en kjede:

En nøkkelverdidatabase eller dokumentlager, i stil med NoSQL.
En tidsseriedatabase, som fokuserer på rekkefølgen av oppføringer.
En identitetsdrevet database der oppføringer er klassifisert etter forfatter.

Disse kan betraktes som "hva", "når" og "hvem" til en delt database.

Grunnleggende om strømmer

Et hvilket som helst antall strømmer kan opprettes i en MultiChain-blokkjede, og hver strøm fungerer som en uavhengig samling av elementer som kun kan legges til. Hvert element i en strøm har følgende egenskaper:

En eller fler utgivere som har signert varen digitalt.
Et valgfritt nøkkel for praktisk senere henting.
Litt dato, som kan variere fra et lite stykke tekst til mange megabyte med rå binær.
A tidsstempel, som er hentet fra overskriften til blokken der varen er bekreftet.

Bak kulissene er hvert element i en strøm representert av en blokkjedetransaksjon, men utviklere kan lese og skrive strømmer uten bevissthet om denne underliggende mekanismen. (Mer avanserte brukere kan bruke råtransaksjoner å skrive til flere strømmer, utstede eller overføre eiendeler og/eller tildele tillatelser i en enkelt atomtransaksjon.)

Strømmer integreres med MultiChains tillatelsessystem på en rekke måter. For det første kan strømmer bare opprettes av de som har tillatelse til det, på samme måte som eiendeler kun kan utstedes av bestemte adresser. Når en strøm opprettes, er den åpen eller lukket. Åpne strømmer kan skrives av alle som har tillatelse til å sende en blokkjedetransaksjon, mens lukkede strømmer er begrenset til en utskiftbar liste over tillatte adresser. I sistnevnte tilfelle har hver strøm en eller flere administratorer som kan endre disse skrivetillatelsene over tid.

Hver blokkjede har en valgfri "root"-strøm, som er definert i sin parametere og eksisterer fra det øyeblikket kjeden er opprettet. Dette gjør at en blokkjede kan brukes umiddelbart for å lagre og hente data, uten å vente på at en strøm eksplisitt opprettes.

Som jeg har diskutert tidligere, er konfidensialitet den største utfordringen i et stort antall blokkjedebrukssaker. Dette er fordi hver node i en blokkjede ser en fullstendig kopi av hele kjedens innhold. Strømmer gir en naturlig måte å støtte krypterte data på en blokkjede, som følger:

Én strøm brukes av deltakerne til å distribuere sine offentlige nøkler for et hvilket som helst offentlig nøkkelkrypteringsskjema.
En andre strøm brukes til å publisere data, hvor hver del av data er kryptert ved hjelp av symmetrisk kryptografi med en unik nøkkel.
En tredje strøm gir datatilgang. For hver deltaker som skal se et stykke data, opprettes det en strømoppføring som inneholder dataens hemmelige nøkkel, kryptert med deltakerens offentlige nøkkel.

Dette gir en effektiv måte å arkivere data på en blokkjede, samtidig som den bare er synlig for enkelte deltakere.

Henter fra strømmer

Kjerneverdien til strømmer ligger i indeksering og gjenfinning. Hver node kan velge hvilke strømmer de skal abonnere på, med blokkjeden som garanterer at alle noder som abonnerer på en bestemt strøm vil se de samme elementene innenfor. (En node kan også konfigureres til automatisk å abonnere på hver ny strøm som opprettes.)

Hvis en node abonnerer på en strøm, kan informasjon hentes fra den strømmen på en rekke måter:

Henter elementer fra strømmen i rekkefølge.
Henter elementer med en bestemt nøkkel.
Henter elementer signert av en bestemt utgiver.
Liste over nøklene som brukes i en strøm, med vareteller for hver nøkkel.
Oppføring av utgivere i en strøm, med antall varer.

Som nevnt innledningsvis, tillater disse gjenfinningsmetodene at strømmer kan brukes til nøkkelverdidatabaser, tidsseriedatabaser og identitetsdrevne databaser. Alle henting APIer tilbyr Begynn og telle parametere, slik at underseksjoner av lange lister kan hentes effektivt (som en LIMIT-klausul i SQL). Negative verdier for Begynn la de nyeste elementene hentes.

Strømmer kan inneholde flere elementer med samme nøkkel, og dette løser naturligvis spenningen mellom blokkjedens uforanderlighet og behovet for å oppdatere en database. Hver effektiv databaseoppføring bør tildeles en unik nøkkel i applikasjonen din, med hver oppdatering av denne oppføringen representert av et nytt strømelement med nøkkelen. MultiChain sine strømhentings-APIer kan deretter brukes til å: (a) hente den første eller siste versjonen av en gitt oppføring, (b) hente en fullstendig versjonshistorikk for en oppføring, (c) hente informasjon om flere oppføringer, inkludert den første og siste versjoner av hver.

Merk at på grunn av en blokkjedes peer-to-peer-arkitektur, kan elementer i en strøm komme til forskjellige noder i forskjellige rekkefølger, og MultiChain lar elementer hentes før de "bekreftes" i en blokk. Som et resultat tilbyr alle gjenfinnings-APIer et valg mellom global (standard) eller lokal bestilling. Global bestilling garanterer at når kjeden har nådd konsensus, mottar alle noder de samme svarene fra de samme API-kallene. Lokal bestilling garanterer at, for en bestemt node, vil bestillingen av en strøms elementer aldri endres mellom API-kall. Hver applikasjon kan gjøre det riktige valget for sine behov.

Strømmer og MultiChain veikart

Med utgivelsen av strømmer har vi fullført det siste store arbeidet for MultiChain 1.0, og er nå godt på vei til beta. Vi forventer å bruke de neste månedene på å utvide vår interne testsuite (allerede ganske stor!), fullføre Windows- og Mac-portene, legge til noen flere nyttige API-er, oppdatere Explorer for strømmer, finjustering av aspekter ved konsensusmekanismen, utgivelse av nettdemoen vår og generelt rydde opp i kode og hjelpemeldinger. Det viktigste er at vi fortsetter å fikse eventuelle feil så snart de blir oppdaget, slik at våre feil ikke forstyrrer arbeidet ditt.

På lengre sikt, hvor passer strømmer inn i MultiChain-veikartet? MultiChain tar et skritt tilbake og tilbyr nå tre områder med funksjonalitet på høyt nivå:

Tillatelser å kontrollere hvem som kan koble til, handle, opprette eiendeler/strømmer, mine/validere og administrere.
Eiendeler inkludert utstedelse, gjenutstedelse, overføring, atomutveksling, deponering og ødeleggelse.
strømmer med API-er for å lage strømmer, skrive, abonnere, indeksere og hente.

Etter utgivelsen av MultiChain 1.0 (og en premiumversjon), hva er neste på denne listen? Hvis du ser på API-kommando som brukes til å lage strømmer, vil du legge merke til en tilsynelatende overflødig parameter, med en fast verdi på stream. Denne parameteren vil tillate MultiChain å støtte andre typer enheter på høyt nivå i fremtiden.

Mulige fremtidige verdier for parameteren inkluderer evm (for en Ethereum-kompatibel virtuell maskin), sql (for en database i SQL-stil) eller til og med wiki (for samarbeidsredigert tekst). Enhver delt enhet hvis tilstand bestemmes av en ordnet rekke endringer, er en potensiell kandidat. Hver slik enhet vil trenge: (a) APIer som gir riktig abstraksjon for å oppdatere dens tilstand, (b) passende mekanismer for abonnerte noder for å spore den tilstanden, og (c) APIer for å effektivt hente deler av eller hele tilstanden. Vi venter på å finne ut hvilke andre enheter på høyt nivå som vil være mest nyttige, for å bli implementert av oss eller av tredjeparter via en plug-in-arkitektur.

Hva med smarte kontrakter?

I en generell forstand tar MultiChain tilnærmingen der dato er innebygd uforanderlig i en blokkjede, men kode for å tolke at data er i noden eller applikasjonslaget. Dette er bevisst forskjellig fra "smarte kontrakter"-paradigmet, som eksemplifisert av Ethereum, der kode er innebygd i blokkjeden og kjører i en virtuell maskin. I teorien, fordi smarte kontrakter er Turing komplett, kan de reprodusere oppførselen til MultiChain eller en hvilken som helst annen blokkjedeplattform. I praksis har imidlertid smarte kontrakter i Ethereum-stil mange smertefulle mangler:

Hver node må utføre hver beregning, enten den er av interesse eller ikke. Derimot, i MultiChain bestemmer hver node hvilke strømmer de skal abonnere på, og kan ignorere dataene som finnes av andre.
Den virtuelle maskinen som brukes for smarte kontrakter har drastisk dårligere ytelse enn kode som har blitt kompilert for en gitt datamaskinarkitektur.
Smart kontraktskode er uforanderlig innebygd i en kjede, og forhindrer at funksjoner blir lagt til og at feil blir fikset. Dette ble demonstrert kraftig i bortgangen til DAO.
Transaksjoner sendt til en smart kontrakt kan ikke oppdatere en blokkjedes tilstand til deres endelige rekkefølge er kjent, på grunn av karakteren av generell beregning. Dette fører til forsinkelser (inntil en transaksjon er bekreftet i en blokk) samt mulige reverseringer (ved en gaffel i kjeden). Derimot kan MultiChain behandle hver type ubekreftede transaksjoner på riktig måte: (a) innkommende eiendeler umiddelbart oppdaterer en nodes ubekreftede saldo, (b) innkommende strømelementer er umiddelbart tilgjengelige, med deres globale bestilling avsluttet, (c) endringer i tillatelser brukes umiddelbart og spilles deretter av i innkommende blokker.

Likevel, som jeg har gjort sa før, utelukker vi absolutt ikke smarte kontrakter som et nyttig paradigme for blokkjedeapplikasjoner, hvis og når vi ser sterke brukstilfeller. Imidlertid vil smarte kontrakter i MultiChain bli implementert i et strømlignende lag på toppen av blokkjeden, i stedet for det laveste transaksjonsnivået. Dette vil bevare MultiChains overlegne ytelse for enklere blokkjede-enheter som eiendeler og strømmer, samtidig som det tilbys langsommere kjedeberegning der det virkelig er nødvendig. Men det er færre slike tilfeller enn du kanskje tror.

Legg inn kommentarer på Linkedin.

Teknisk tillegg

Alle kommandoer relatert til strømmer er dokumentert i sin helhet i MultiChain API-side, men her er en kort oppsummering:

Lag en strøm ved å bruke create stream or createfrom ... stream
Legg til et element i en strøm med publish or publishfrom
Hent en liste over strømmer ved hjelp av liststreams
Start eller slutt å spore en strøm med subscribe og unsubscribe
Hent strømelementer ved hjelp av liststreamitems, liststreamkeyitems og liststreampublisheritems
List strømnøkler og utgivere med liststreamkeys og liststreampublishers
For store strømmer henter du alle dataene ved å bruke gettxoutdata (Se maxshowndata nedenfor)
Kontroller per-stream-tillatelser med anrop som grant [address] stream1.write
Se en strøms tillatelser ved å bruke listpermissions stream1.*

Noen andre utviklernotater relatert til strømmer:

De create tillatelse tillater en adresse å opprette strømmer.
Relevante per-stream-tillatelser er write, admin og activate
Ny blokkjedeparametere: root-stream-name (la stå tomt for ingen), root-stream-open, anyone-can-create, admin-consensus-create, max-std-op-returns-count
Ny kjøretidsparametere: autosubscribe å automatisk abonnere på nye strømmer opprettet og maxshowndata for å begrense mengden data i API-svar (se gettxoutdata ovenfor).
Den maksimale størrelsen på dataene til et strømelement er fastsatt av max-std-op-return-size blockchain-parameter, så vel som den minste av maximum-block-size og max-std-tx-size verdier minus noen hundre byte.
Noder som bruker det gamle lommebokformatet kan ikke abonnere på strømmer, og bør oppgraderes.