Introductie van MultiChain Streams

Bronknooppunt: 1213525

Voor gedeelde onveranderlijke sleutel / waarde- en tijdreeksdatabases

Vandaag zijn we er trots op dat we de nieuwste versie van MultiChain kunnen uitbrengen, die een cruciale nieuwe set functionaliteit genaamd "streams" implementeert. Streams bieden een natuurlijke abstractie voor blockchain-gebruikssituaties die zich richten op het algemeen ophalen van gegevens, tijdstempels en archivering, in plaats van de overdracht van activa tussen deelnemers. Streams kunnen worden gebruikt om drie verschillende soorten databases in een keten te implementeren:

  1. Een key-value database of document store, in de stijl van NoSQL.
  2. Een tijdreeksdatabase, die zich richt op het ordenen van items.
  3. Een identiteitsgestuurde database waarin items worden geclassificeerd op basis van hun auteur.

Deze kunnen worden beschouwd als het 'wat', 'wanneer' en 'wie' van een gedeelde database.

Basisprincipes van Streams

Er kan een onbeperkt aantal streams worden gemaakt in een MultiChain-blockchain en elke stream fungeert als een onafhankelijke, alleen bijgevoegde verzameling items. Elk item in een stream heeft de volgende kenmerken:

  • Een of meer uitgevers die dat item digitaal hebben ondertekend.
  • een optionele sleutel voor gemakkelijk later terugvinden.
  • sommige gegevens, die kan variรซren van een klein stukje tekst tot vele megabytes onbewerkt binair.
  • A tijdstempel, die is overgenomen uit de koptekst van het blok waarin het item is bevestigd.

Achter de schermen wordt elk item in een stream weergegeven door een blockchain-transactie, maar ontwikkelaars kunnen streams lezen en schrijven zonder zich bewust te zijn van dit onderliggende mechanisme. (Meer gevorderde gebruikers kunnen gebruiken ruwe transacties om naar meerdere streams te schrijven, activa uit te geven of over te dragen en / of machtigingen toe te wijzen in รฉรฉn atomaire transactie.)

Streams kunnen op verschillende manieren worden geรฏntegreerd met het machtigingensysteem van MultiChain. Ten eerste kunnen streams alleen worden gemaakt door degenen die daarvoor toestemming hebben, op dezelfde manier dat activa alleen kunnen worden uitgegeven door bepaalde adressen. Wanneer een stream wordt gemaakt, is deze open of gesloten. Open streams zijn schrijfbaar voor iedereen die toestemming heeft om een โ€‹โ€‹blockchain-transactie te verzenden, terwijl gesloten streams beperkt zijn tot een veranderlijke lijst met toegestane adressen. In het laatste geval heeft elke stream een โ€‹โ€‹of meer beheerders die deze schrijfrechten na verloop van tijd kunnen wijzigen.

Elke blockchain heeft een optionele 'root'-stream, die is gedefinieerd in zijn parameters en bestaat vanaf het moment dat de ketting is gemaakt. Hierdoor kan een blockchain direct worden gebruikt voor het opslaan en ophalen van data, zonder te wachten tot er expliciet een stream wordt aangemaakt.

Zoals ik heb gedaan eerder besprokenis vertrouwelijkheid de grootste uitdaging in een groot aantal blockchain-use cases. Dit komt omdat elk knooppunt in een blockchain een volledige kopie van de inhoud van de hele keten ziet. Streams bieden een natuurlijke manier om versleutelde gegevens op een blockchain te ondersteunen, als volgt:

  1. Eรฉn stream wordt door deelnemers gebruikt om hun openbare sleutels te distribueren voor elk public-key cryptografieschema.
  2. Een tweede stream wordt gebruikt om gegevens te publiceren, waarbij elk stuk gegevens wordt versleuteld met symmetrische cryptografie met een unieke sleutel.
  3. Een derde stream biedt gegevenstoegang. Voor elke deelnemer die een stuk gegevens zou moeten zien, wordt er een streamingang gemaakt die de geheime sleutel van die gegevens bevat, versleuteld met de openbare sleutel van die deelnemer.

Dit biedt een efficiรซnte manier om gegevens op een blockchain te archiveren, terwijl het alleen zichtbaar is voor bepaalde deelnemers.

Ophalen uit streams

De kernwaarde van streams ligt in indexeren en ophalen. Elk knooppunt kan kiezen op welke streams hij zich wil abonneren, waarbij de blockchain garandeert dat alle nodes die zich op een bepaalde stream abonneren dezelfde items zullen zien. (Een knooppunt kan ook worden geconfigureerd om zich automatisch te abonneren op elke nieuwe stream die wordt gemaakt.)

Als een knooppunt is geabonneerd op een stream, kan informatie op een aantal manieren uit die stream worden opgehaald:

  • Items op volgorde ophalen uit de stream.
  • Items ophalen met een bepaalde sleutel.
  • Items ophalen die zijn ondertekend door een bepaalde uitgever.
  • Lijst van de sleutels die in een stream worden gebruikt, met itemaantallen voor elke sleutel.
  • De uitgevers in een stream vermelden, met aantal items.

Zoals aan het begin vermeld, maken deze ophaalmethoden het mogelijk om streams te gebruiken sleutelwaardedatabases, tijdreeks databases en identiteitsgestuurde databases. Alle retrieval API's bieden begin en tellen parameters, waardoor subsecties van lange lijsten efficiรซnt kunnen worden opgehaald (zoals een LIMIT-clausule in SQL). Negatieve waarden voor begin toestaan โ€‹โ€‹dat de meest recente items worden opgehaald.

Streams kunnen meerdere items bevatten met dezelfde sleutel, en dit lost natuurlijk de spanning op tussen onveranderlijkheid van blockchain en de noodzaak om een โ€‹โ€‹database bij te werken. Aan elk effectief database-item moet een unieke sleutel in uw toepassing worden toegewezen, waarbij elke update van dat item wordt weergegeven door een nieuw stream-item met de bijbehorende sleutel. De API's voor het ophalen van streams van MultiChain kunnen vervolgens worden gebruikt om: (a) de eerste of laatste versie van een bepaald item op te halen, (b) een volledige versiegeschiedenis voor een item op te halen, (c) informatie over meerdere items op te halen, inclusief de eerste en laatste versies van elk.

Merk op dat vanwege de peer-to-peer-architectuur van een blockchain items in een stream op verschillende knooppunten in verschillende volgorde kunnen aankomen, en MultiChain staat toe dat items worden opgehaald voordat ze in een blok worden 'bevestigd'. Als gevolg hiervan bieden alle retrieval-API's de keuze tussen globale (de standaard) of lokale ordening. Globale ordening garandeert dat, zodra de keten consensus heeft bereikt, alle knooppunten dezelfde reacties ontvangen van dezelfde API-aanroepen. Lokale ordening garandeert dat voor een bepaald knooppunt de volgorde van de items van een stream nooit zal veranderen tussen API-aanroepen. Elke applicatie kan de juiste keuze maken voor zijn behoeften.

Streams en de MultiChain-roadmap

Met de release van streams hebben we het laatste grote werk voor MultiChain 1.0 voltooid en zijn we nu stevig op weg naar bรจta. We verwachten de komende maanden te besteden aan het uitbreiden van onze interne testsuite (al behoorlijk groot!), Het voltooien van de Windows- en Mac-poorten, het toevoegen van nog meer nuttige API's en het updaten van de Ontdekker voor streams, het aanpassen van aspecten van het consensusmechanisme, het vrijgeven van onze webdemo en het opruimen van code en helpberichten. Het belangrijkste is dat we bugs blijven oplossen zodra ze worden ontdekt, zodat onze fouten uw werk niet onderbreken.

Waar passen streams op langere termijn in de MultiChain roadmap? MultiChain neemt een stap terug en biedt nu drie gebieden met functionaliteit op hoog niveau:

  • machtigingen om te bepalen wie verbinding kan maken, transacties kan uitvoeren, activa / streams kan creรซren, mijnen / valideren en beheren.
  • Activa inclusief uitgifte, heruitgifte, overdracht, atoomuitwisseling, escrow en vernietiging.
  • Streams met API's voor het maken van streams, schrijven, abonneren, indexeren en ophalen.

Wat staat er na deze release van MultiChain 1.0 (en een premium-versie) in deze lijst? Als je kijkt naar de API-opdracht die wordt gebruikt om streams te maken, zult u een ogenschijnlijk overbodige parameter opmerken, met een vaste waarde van stream. Met deze parameter kan MultiChain in de toekomst andere soorten entiteiten op hoog niveau ondersteunen.

Mogelijke toekomstige waarden voor de parameter omvatten evm (voor een Ethereumcompatibele virtuele machine), sql (voor een SQL-achtige database) of zelfs wiki (voor gezamenlijk bewerkte tekst). Elke gedeelde entiteit waarvan de toestand wordt bepaald door een geordende reeks wijzigingen is een potentiรซle kandidaat. Elke dergelijke entiteit heeft nodig: (a) API's die de juiste abstractie bieden voor het bijwerken van de status ervan, (b) geschikte mechanismen voor geabonneerde knooppunten om die status te volgen, en (c) API's voor het efficiรซnt ophalen van een deel of de volledige staat. We wachten om erachter te komen welke andere entiteiten op hoog niveau het nuttigst zijn, door ons of door derden te worden geรฏmplementeerd via een plug-in-architectuur.

Hoe zit het met slimme contracten?

In algemene zin kiest MultiChain voor de aanpak waarin gegevens is onveranderlijk ingebed in een blockchain, maar de code voor het interpreteren van die gegevens in de knoop of toepassingslaag. Dit is opzettelijk anders dan het 'slimme contracten'-paradigma, zoals geรฏllustreerd door Ethereum, waarin code is ingebed in de blockchain en in een virtuele machine draait. In theorie omdat slimme contracten dat zijn Turing compleet, ze kunnen het gedrag van MultiChain of een ander blockchain-platform reproduceren. In de praktijk hebben slimme contracten in Ethereum-stijl echter veel pijnlijke tekortkomingen:

  • Elk knooppunt moet elke berekening uitvoeren, of het nu interessant is of niet. In MultiChain daarentegen bepaalt elk knooppunt op welke streams hij zich wil abonneren en kan hij de gegevens van anderen negeren.
  • De virtuele machine die wordt gebruikt voor slimme contracten heeft drastisch slechtere prestaties dan code die standaard is samengesteld voor een bepaalde computerarchitectuur.
  • Slimme contractcode is onveranderlijk ingebed in een keten, waardoor wordt voorkomen dat functies worden toegevoegd en bugs worden opgelost. Dit werd krachtig aangetoond in de ondergang van de DAO.
  • Transacties verzonden naar een slim contract kan niet updaten de status van een blockchain totdat hun definitieve volgorde bekend is, vanwege de aard van algemene berekening. Dit leidt tot vertragingen (totdat een transactie in een blok wordt bevestigd) en mogelijke omkeringen (in het geval van een splitsing in de keten). MultiChain kan daarentegen elk type onbevestigde transactie op de juiste manier behandelen: (a) inkomende activa werken onmiddellijk het onbevestigde saldo van een knooppunt bij, (b) inkomende stroomitems zijn onmiddellijk beschikbaar, met hun wereldwijde volgorde vervolgens afgerond, (c) wijzigingen in rechten worden onmiddellijk toegepast en vervolgens opnieuw afgespeeld in inkomende blokken.

Niettemin, zoals ik eerder gezegd, we sluiten slimme contracten zeker niet uit als een nuttig paradigma voor blockchain-applicaties, als en wanneer we sterke use-cases zien. In MultiChain zouden slimme contracten echter worden geรฏmplementeerd in een stream-achtige laag bovenop de blockchain, in plaats van op het laagste transactieniveau. Dit behoudt de superieure prestaties van MultiChain voor eenvoudigere blockchain-entiteiten zoals activa en streams, en biedt langzamere on-chain-berekening waar dat echt nodig is. Maar er zijn minder van zulke gevallen dan u misschien denkt.

 

Plaats eventuele opmerkingen op LinkedIn.

 

Technisch addendum

Alle opdrachten met betrekking tot streams worden volledig gedocumenteerd in de MultiChain API-pagina, maar hier is een korte samenvatting:

  • Maak een stream met create stream or createfrom ... stream
  • Voeg een item toe aan een stream met publish or publishfrom
  • Haal een lijst met streams op met liststreams
  • Start of stop het volgen van een stream met subscribe en unsubscribe
  • Haal stream-items op met liststreamitems, liststreamkeyitems en liststreampublisheritems
  • Maak een lijst van streamsleutels en uitgevers met liststreamkeys en liststreampublishers
  • Voor grote stream-items haalt u de volledige gegevens op met gettxoutdata (Zie maxshowndata hieronder)
  • Beheer de rechten per stream met oproepen zoals grant [address] stream1.write
  • Bekijk de rechten van een stream met listpermissions stream1.*

Enkele andere opmerkingen voor ontwikkelaars met betrekking tot streams:

  • De create toestemming staat een adres toe om streams te maken.
  • Relevante rechten per stream zijn write, admin en activate
  • New blockchain-parameters: root-stream-name (leeg laten voor niemand), root-stream-open, anyone-can-create, admin-consensus-create, max-std-op-returns-count
  • New runtime-parameters: autosubscribe automatisch abonneren op nieuwe streams die zijn gemaakt en maxshowndata om de hoeveelheid gegevens in API-reacties te beperken (zie gettxoutdata bovenstaande).
  • De maximale grootte van de gegevens van een streamitem wordt bepaald door de max-std-op-return-size blockchain-parameter, evenals de kleinste van de maximum-block-size en max-std-tx-size waarden min een paar honderd bytes.
  • Knooppunten die de oude portefeuille-indeling gebruiken, kunnen zich niet abonneren op streams, en moet worden opgewaardeerd.

 

Tijdstempel:

Meer van Multichain