Introduktion af MultiChain-streams

Til delte uforanderlige nøgleværdi- og tidsseriedatabaser

I dag er vi stolte af at frigive den seneste version af MultiChain, som implementerer et afgørende nyt sæt funktionalitet kaldet "streams". Strømme giver en naturlig abstraktion for blockchain-brugssager, der fokuserer på generel datahentning, tidsstempling og arkivering snarere end overførsel af aktiver mellem deltagere. Strømme kan bruges til at implementere tre forskellige typer databaser på en kæde:

1. En nøgleværdidatabase eller dokumentlager i stil med NoSQL.
2. En tidsseriedatabase, som fokuserer på rækkefølgen af ​​posteringer.
3. En identitetsdrevet database, hvor poster klassificeres efter deres forfatter.

Disse kan betragtes som 'hvad', 'hvornår' og 'hvem' i en delt database.

Grundlæggende om streams

Et hvilket som helst antal streams kan oprettes i en MultiChain blockchain, og hver stream fungerer som en uafhængig samling af elementer, der kun kan tilføjes. Hvert element i en strøm har følgende egenskaber:

• En eller flere udgivere som har underskrevet den vare digitalt.
• En valgfri nøgle til praktisk senere hentning.
• Nogle data, som kan variere fra et lille stykke tekst til mange megabyte rå binær.
• A tidsstempel, som er taget fra overskriften på den blok, hvor varen er bekræftet.

Bag kulisserne er hvert element i en strøm repræsenteret af en blockchain-transaktion, men udviklere kan læse og skrive strømme uden bevidsthed om denne underliggende mekanisme. (Mere avancerede brugere kan bruge rå transaktioner at skrive til flere strømme, udstede eller overføre aktiver og/eller tildele tilladelser i en enkelt atomtransaktion.)

Streams integreres med MultiChains tilladelsessystem på en række måder. For det første kan streams kun oprettes af dem, der har tilladelse til det, på samme måde som aktiver kun kan udstedes af bestemte adresser. Når en strøm oprettes, er den åben eller lukket. Åbne streams kan skrives af alle, der har tilladelse til at sende en blockchain-transaktion, mens lukkede streams er begrænset til en udskiftelig liste over tilladte adresser. I sidstnævnte tilfælde har hver stream en eller flere administratorer, som kan ændre disse skrivetilladelser over tid.

Hver blockchain har en valgfri 'root'-strøm, som er defineret i dens parametre og eksisterer fra det øjeblik, kæden er oprettet. Dette gør det muligt at bruge en blockchain med det samme til at gemme og hente data uden at vente på, at en stream eksplicit oprettes.

Som jeg har diskuteret tidligere, fortrolighed er den største udfordring i et stort antal blockchain-brugssager. Dette skyldes, at hver node i en blockchain ser en fuld kopi af hele kædens indhold. Streams giver en naturlig måde at understøtte krypterede data på en blockchain, som følger:

1. Én strøm bruges af deltagere til at distribuere deres offentlige nøgler til et hvilket som helst kryptografiskema med offentlig nøgle.
2. En anden strøm bruges til at publicere data, hvor hvert stykke data krypteres ved hjælp af symmetrisk kryptografi med en unik nøgle.
3. En tredje strøm giver dataadgang. For hver deltager, der skal se et stykke data, oprettes en stream-indgang, som indeholder den pågældende datas hemmelige nøgle, krypteret ved hjælp af den pågældende deltagers offentlige nøgle.

Dette giver en effektiv måde at arkivere data på en blockchain, samtidig med at det kun er synligt for visse deltagere.

Henter fra streams

Kerneværdien af ​​streams ligger i indeksering og genfinding. Hver node kan vælge, hvilke streams de vil abonnere på, hvor blockchainen garanterer, at alle noder, der abonnerer på en bestemt stream, vil se de samme elementer indeni. (En node kan også konfigureres til automatisk at abonnere på hver ny oprettet stream.)

Hvis en node abonnerer på en strøm, kan information hentes fra den strøm på en række måder:

• Henter elementer fra strømmen i rækkefølge.
• Henter elementer med en bestemt nøgle.
• Henter elementer, der er signeret af en bestemt udgiver.
• Liste over de nøgler, der bruges i en strøm, med vareantal for hver nøgle.
• Liste over udgiverne i en strøm med vareantal.

Som nævnt i starten tillader disse genfindingsmetoder at bruge vandløb til nøgleværdidatabaser, tidsseriedatabaser og identitetsdrevne databaser. Alle genfindings-API'er tilbyder starte , tælle parametre, hvilket gør det muligt at hente underafsnit af lange lister effektivt (som en LIMIT-sætning i SQL). Negative værdier for starte tillade, at de seneste elementer kan hentes.

Streams kan indeholde flere elementer med den samme nøgle, og dette løser naturligvis spændingen mellem blockchain-uforanderlighed og behovet for at opdatere en database. Hver effektiv databasepost bør tildeles en unik nøgle i din applikation, hvor hver opdatering af denne post repræsenteres af et nyt streamelement med dets nøgle. MultiChains stream hentning API'er kan derefter bruges til at: (a) hente den første eller sidste version af en given post, (b) hente en fuld versionshistorik for en post, (c) hente information om flere poster, inklusive den første og sidste versioner af hver.

Bemærk, at på grund af en blockchains peer-to-peer-arkitektur kan elementer i en strøm ankomme til forskellige noder i forskellige rækkefølger, og MultiChain tillader, at elementer kan hentes, før de 'bekræftes' i en blok. Som et resultat giver alle genfindings-API'er et valg mellem global (standard) eller lokal bestilling. Global bestilling garanterer, at når kæden har nået konsensus, modtager alle noder de samme svar fra de samme API-kald. Lokal bestilling garanterer, at rækkefølgen af ​​en streams elementer for enhver bestemt node aldrig vil ændre sig mellem API-kald. Hver applikation kan træffe det passende valg til dens behov.

Streams og MultiChain køreplanen

Med udgivelsen af ​​streams har vi afsluttet det sidste store stykke arbejde for MultiChain 1.0 og er nu solidt på vej mod beta. Vi forventer at bruge de næste par måneder på at udvide vores interne testsuite (allerede ret stor!), færdiggøre Windows- og Mac-portene, tilføje nogle flere nyttige API'er, opdatere Explorer til streams, justering af aspekter af konsensusmekanismen, frigivelse af vores webdemo og generelt oprydning af kode og hjælpemeddelelser. Vigtigst af alt, vil vi fortsætte med at rette eventuelle fejl, så snart de er opdaget, så vores fejl ikke afbryder dit arbejde.

På længere sigt, hvor passer streams ind i MultiChain-køreplanen? For at tage et skridt tilbage tilbyder MultiChain nu tre områder med funktionalitet på højt niveau:

• Tilladelser at kontrollere, hvem der kan forbinde, handle, oprette aktiver/streams, mine/validere og administrere.
• Aktiver herunder udstedelse, genudstedelse, overførsel, atomudveksling, deponering og destruktion.
• Vandløb med API'er til at oprette streams, skrive, abonnere, indeksere og hente.

Efter udgivelsen af ​​MultiChain 1.0 (og en premium-version), hvad er det næste på denne liste? Hvis du ser på API kommando som bruges til at skabe streams, vil du bemærke en tilsyneladende overflødig parameter med en fast værdi på stream. Denne parameter vil gøre det muligt for MultiChain at understøtte andre typer enheder på højt niveau i fremtiden.

Mulige fremtidige værdier for parameteren inkluderer evm (til en Ethereum-kompatibel virtuel maskine), sql (til en database i SQL-stil) eller endda wiki (til samarbejdet redigeret tekst). Enhver delt enhed, hvis tilstand er bestemt af en ordnet række af ændringer, er en potentiel kandidat. Hver sådan enhed vil have brug for: (a) API'er, der giver den rette abstraktion til opdatering af dens tilstand, (b) passende mekanismer for abonnerede noder til at spore denne tilstand, og (c) API'er til effektivt at hente en del af eller hele tilstanden. Vi venter på at finde ud af, hvilke andre entiteter på højt niveau, der ville være mest nyttige, til at blive implementeret af os eller af tredjeparter via en plug-in-arkitektur.

Hvad med smarte kontrakter?

I en generel forstand tager MultiChain den tilgang, hvor data er indlejret uforanderligt i en blockchain, men den kode til fortolkning af, at data er i noden eller applikationslaget. Dette er bevidst forskelligt fra "smart contracts"-paradigmet, som eksemplificeret af Ethereum, hvor kode er indlejret i blockchain og kører i en virtuel maskine. I teorien, fordi smarte kontrakter er Turing komplet, kan de gengive adfærden hos MultiChain eller enhver anden blockchain-platform. I praksis har Ethereum-stil smarte kontrakter dog mange smertefulde mangler:

• Hver knude skal udføre enhver beregning, uanset om den er af interesse eller ej. I MultiChain bestemmer hver node derimod, hvilke streams der skal abonneres på, og kan ignorere de data, som andre indeholder.
• Den virtuelle maskine, der bruges til smarte kontrakter, har drastisk dårligere ydeevne end kode, som er blevet kompileret til en given computerarkitektur.
• Smart kontraktkode er uforanderligt indlejret i en kæde, hvilket forhindrer funktioner i at blive tilføjet og fejl i at blive rettet. Dette blev kraftigt demonstreret i DAO's død.
• Transaktioner sendt til en smart kontrakt kan ikke opdatere en blockchains tilstand, indtil deres endelige rækkefølge er kendt, på grund af karakteren af ​​generel beregning. Dette fører til forsinkelser (indtil en transaktion er bekræftet i en blok) samt mulige tilbageførsler (i tilfælde af en gaffel i kæden). I modsætning hertil kan MultiChain behandle hver type ubekræftet transaktion på den passende måde: (a) indgående aktiver opdaterer straks en nodes ubekræftede saldo, (b) indgående strømposter er øjeblikkeligt tilgængelige, med deres globale bestilling efterfølgende afsluttet, (c) ændringer i tilladelser anvendes med det samme og afspilles derefter i indgående blokke.

Ikke desto mindre, som jeg har sagde før, vi udelukker bestemt ikke smarte kontrakter som et nyttigt paradigme for blockchain-applikationer, hvis og når vi ser stærke use cases. Men i MultiChain ville smarte kontrakter blive implementeret i et stream-lignende lag oven på blockchain, snarere end det laveste transaktionsniveau. Dette vil bevare MultiChains overlegne ydeevne for enklere blockchain-enheder som aktiver og streams, samtidig med at det tilbyder langsommere on-chain-beregning, hvor det virkelig er nødvendigt. Men der er færre sådanne tilfælde, end du måske tror.

 

Skriv eventuelle kommentarer på LinkedIn.

 

Teknisk tillæg

Alle kommandoer relateret til streams er dokumenteret fuldt ud i MultiChain API-side, men her er en kort oversigt:

• Opret en stream ved hjælp af create stream or createfrom ... stream
• Tilføj et element til en strøm med publish or publishfrom
• Hent en liste over streams vha liststreams
• Start eller stop med at spore en stream med subscribe , unsubscribe
• Hent stream elementer vha liststreamitems, liststreamkeyitems , liststreampublisheritems
• Liste streamnøgler og udgivere med liststreamkeys , liststreampublishers
• For store stream-elementer skal du hente de fulde data vha gettxoutdata (Se maxshowndata nedenfor)
• Styr per-stream-tilladelser med opkald som f.eks grant [address] stream1.write
• Se en streams tilladelser vha listpermissions stream1.*

Nogle andre udviklerbemærkninger vedrørende streams:

• create tilladelse tillader en adresse at oprette streams.
• Relevante per-stream-tilladelser er write, admin , activate
• Ny blockchain-parametre: root-stream-name (lad stå tomt for ingen), root-stream-open, anyone-can-create, admin-consensus-create, max-std-op-returns-count
• Ny runtime parametre: autosubscribe for automatisk at abonnere på nye oprettede streams og maxshowndata for at begrænse mængden af ​​data i API-svar (se gettxoutdata over).
• Den maksimale størrelse af et strømelements data er fastsat af max-std-op-return-size blockchain-parameter, såvel som den mindste af maximum-block-size , max-std-tx-size værdier minus et par hundrede bytes.
• Noder, der bruger det gamle tegnebogsformat, kan ikke abonnere på streams, og bør opgraderes.

 

• Coinsmart. Europas bedste Bitcoin og Crypto Exchange.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. FRI ADGANG.
• CryptoHawk. Altcoin radar. Gratis prøveversion.
• Kilde: https://www.multichain.com/blog/2016/09/introducing-multichain-streams/