Introduktion av MultiChain-strömmar

För delade immutable databaser för nyckelvärde och tidsserier

Idag är vi stolta över att släppa den senaste versionen av MultiChain, som implementerar en avgörande ny uppsättning funktioner som kallas ”strömmar”. Strömmar ger en naturlig abstraktion för fall av blockchainanvändning som fokuserar på allmän datainsamling, tidsstämpel och arkivering, snarare än överföring av tillgångar mellan deltagare. Strömmar kan användas för att implementera tre olika typer av databaser i en kedja:

1. En nyckelvärdesdatabas eller dokumentlagring, i stil med NoSQL.
2. En tidsseriedatabas som fokuserar på beställning av poster.
3. En identitetsdriven databas där poster klassificeras enligt författaren.

Dessa kan betraktas som 'vad', 'när' och 'vem' i en delad databas.

Grunderna för strömmar

Vilket antal strömmar som helst kan skapas i en MultiChain blockchain, och varje ström fungerar som en oberoende samling av artiklar som bara är tillägg. Varje objekt i en ström har följande egenskaper:

• En eller flera förlag som har signerat denna artikel digitalt.
• Ett valfritt nyckel för bekväm senare hämtning.
• Några datum, som kan sträcka sig från en liten textbit till många megabyte rå binär.
• A tidsstämpel, som tas från rubriken på blocket där objektet bekräftas.

Bakom kulisserna representeras varje objekt i en ström av en blockchain-transaktion, men utvecklare kan läsa och skriva strömmar utan medvetenhet om denna underliggande mekanism. (Mer avancerade användare kan använda råa transaktioner att skriva till flera strömmar, utfärda eller överföra tillgångar och / eller tilldela behörigheter i en enda atomtransaktion.)

Strömmar integreras med MultiChains behörighetssystem på flera sätt. För det första kan strömmar endast skapas av dem som har tillstånd att göra det, på samma sätt som tillgångar endast kan utfärdas av vissa adresser. När en ström skapas är den öppen eller stängd. Öppna strömmar kan skrivas av vem som helst som har tillåtelse att skicka en blockchain-transaktion, medan stängda strömmar är begränsade till en utbytbar lista över tillåtna adresser. I det senare fallet har varje ström en eller flera administratörer som kan ändra dessa skrivbehörigheter över tid.

Varje blockchain har en valfri "root" -ström som definieras i sin parametrar och existerar från det ögonblick kedjan skapas. Detta gör att en blockchain kan användas omedelbart för att lagra och hämta data, utan att vänta på att en ström uttryckligen skapas.

Som jag har diskuterade tidigare, sekretess är den största utmaningen i ett stort antal blockchain-fall. Detta beror på att varje nod i en blockchain ser en fullständig kopia av hela kedjans innehåll. Strömmar är ett naturligt sätt att stödja krypterad data på en blockchain enligt följande:

1. En ström används av deltagarna för att distribuera sina offentliga nycklar för alla krypteringsscheman med nyckel.
2. En andra ström används för att publicera data, där varje databit krypteras med symmetrisk kryptering med en unik nyckel.
3. En tredje ström ger tillgång till data. För varje deltagare som ska se en datainformation skapas en strömpost som innehåller den datans hemliga nyckeln, krypterad med deltagarens offentliga nyckel.

Detta tillhandahåller ett effektivt sätt att arkivera data på en blockchain, samtidigt som den blir synlig endast för vissa deltagare.

Hämtar från strömmar

Kärnvärdet för strömmar är i indexering och hämtning. Varje nod kan välja vilka strömmar att prenumerera på, med blockchain som garanterar att alla noder som prenumererar på en viss ström kommer att se samma objekt inom. (En nod kan också konfigureras för att automatiskt prenumerera på varje ny ström som skapats.)

Om en nod prenumereras på en ström kan information hämtas från den strömmen på ett antal sätt:

• Hämtar objekt från strömmen i ordning.
• Hämtar objekt med en viss nyckel.
• Hämtar objekt undertecknade av en viss utgivare.
• Lista tangenterna som används i en ström, med objekträkningar för varje tangent.
• Lista utgivarna i en ström med objekträkningar.

Som nämnts i början tillåter dessa metoder för hämtning strömmar att användas till nyckelvärdesdatabaser, tidsseriedatabaser och identitetsdrivna databaser. Alla hämtnings-API: er erbjuder starta och räkna parametrar, vilket gör att underavsnitt av långa listor kan hämtas effektivt (som en LIMIT-klausul i SQL). Negativa värden för starta låt de senaste artiklarna hämtas.

Strömmar kan innehålla flera objekt med samma nyckel, och detta löser naturligtvis spänningen mellan blockchainimmutabilitet och behovet av att uppdatera en databas. Varje effektiv databasinmatning bör tilldelas en unik nyckel i din applikation, med varje uppdatering till den posten representerad av ett nytt strömobjekt med dess nyckel. MultiChains API för strömhämtning kan sedan användas för att: (a) hämta den första eller sista versionen av en given post, (b) hämta en fullversionshistorik för en post, (c) hämta information om flera poster, inklusive den första och sista versioner av var och en.

Observera att på grund av en blockchains peer-to-peer-arkitektur kan objekt i en ström komma till olika noder i olika ordningar, och MultiChain tillåter att objekt kan hämtas innan de "bekräftas" i ett block. Som ett resultat erbjuder alla hämtnings-API: er ett val mellan global (standard) eller lokal beställning. Global ordering garanterar att när kedjan har nått enighet, alla noder får samma svar från samma API-samtal. Lokal beställning garanterar att beställningen av strömmen för en viss nod aldrig kommer att ändras mellan API-samtal. Varje applikation kan göra lämpligt val för sina behov.

Strömmar och MultiChain-färdplanen

Med utgivningen av strömmar har vi slutfört det sista stora arbetet för MultiChain 1.0 och är nu på väg till beta. Vi räknar med att spendera de närmaste månaderna på att utöka vår interna testsvit (redan ganska stor!), Avsluta Windows- och Mac-portarna, lägga till några mer användbara API: er, uppdatera explorer för strömmar, finjustera aspekter av konsensusmekanismen, släppa vår webbdemo och generellt rensa upp kod och hjälpmeddelanden. Det viktigaste är att vi fortsätter att fixa eventuella buggar så snart de upptäcks, så att våra misstag inte avbryter ditt arbete.

På längre sikt, var passar strömmar in i MultiChain-färdplanen? Med ett steg tillbaka erbjuder MultiChain nu tre områden med hög funktionalitet:

• behörigheter för att kontrollera vem som kan ansluta, transaktioner, skapa tillgångar / strömmar, gruva / validera och administrera.
• Tillgångar inklusive emission, återutgivning, överföring, atomutbyte, escrow och förstörelse.
• Streams med API: er för att skapa strömmar, skriva, prenumerera, indexera och hämta.

Vad är nästa på listan efter lanseringen av MultiChain 1.0 (och en premiumversion)? Om du tittar på API-kommando som används för att skapa strömmar, kommer du att märka en uppenbarligen överflödig parameter med ett fast värde på stream. Denna parameter gör det möjligt för MultiChain att stödja andra typer av enheter på hög nivå i framtiden.

Möjliga framtida värden för parametern inkluderar evm (för en Ethereum-kompatibel virtuell maskin), sql (för en SQL-databas) eller till och med wiki (för samarbete redigerad text). Alla delade enheter vars tillstånd bestäms av en ordnad serie förändringar är en potentiell kandidat. Varje sådan enhet kommer att behöva: (a) API: er som ger rätt abstraktion för att uppdatera dess tillstånd, (b) lämpliga mekanismer för prenumererade noder för att spåra det tillståndet, och (c) API: er för att effektivt hämta del av eller hela staten. Vi väntar på att lära oss vilka andra enheter på hög nivå som skulle vara mest användbara, att implementeras av oss eller av tredje parter via en plugin-arkitektur.

Vad sägs om smarta kontrakt?

I allmän mening tar MultiChain den strategi där datum är inbäddat omöjligt i en blockchain, men koda för att tolka att data finns i noden eller applikationsskiktet. Detta skiljer sig medvetet från "smarta kontrakt" -paradigmet, vilket exemplifieras av Ethereum, där koden är inbäddad i blockchain och körs i en virtuell maskin. I teorin, för smarta kontrakt är det Turing komplett, kan de reproducera beteendet hos MultiChain eller någon annan blockchain-plattform. I praktiken har emellertid smarta kontrakt i Ethereum-stil många smärtsamma brister:

• Varje nod måste utföra varje beräkning, oavsett om det är av intresse eller inte. I MultiChain däremot bestämmer varje nod vilka strömmar att prenumerera på och kan ignorera informationen som andra innehåller.
• Den virtuella maskinen som används för smarta kontrakt har drastiskt sämre prestanda än kod som nativt har sammanställts för en given datorarkitektur.
• Smart kontraktskod är inbyggt inbäddad i en kedja, vilket förhindrar att funktioner läggs till och buggar fixas. Detta demonstrerades kraftfullt i DAO: s bortgång.
• Transaktioner skickas till ett smart kontrakt kan inte uppdatera en blockchains tillstånd tills deras slutliga beställning är känd på grund av arten av allmän beräkning. Detta leder till förseningar (tills en transaktion bekräftas i ett block) samt möjliga reverseringar (i händelse av en gaffel i kedjan). Däremot kan MultiChain behandla varje typ av obekräftad transaktion på lämpligt sätt: (a) inkommande tillgångar omedelbart uppdaterar en nods okonfirmerade saldo, (b) inkommande strömartiklar är direkt tillgängliga, med deras globala beställning därefter slutförd, (c) behörighetsändringar appliceras omedelbart och spelas sedan upp igen i inkommande block.

Men som jag har gjort sa tidigare, vi utesluter verkligen inte smarta kontrakt som ett användbart paradigm för blockchain-applikationer, om och när vi ser starka användningsfall. I MultiChain skulle smarta kontrakt emellertid implementeras i ett strömliknande lager ovanpå blockchain, snarare än den lägsta transaktionsnivån. Detta kommer att bevara MultiChains överlägsna prestanda för enklare blockchain-enheter som tillgångar och strömmar, samtidigt som det erbjuder långsammare beräkningar på kedjan där det verkligen behövs. Men det finns färre sådana fall än du kanske tror.

 

Skicka eventuella kommentarer på Link.

 

Tekniskt tillägg

Alla kommandon relaterade till strömmar dokumenteras i sin helhet i MultiChain API-sida, men här är en kort sammanfattning:

• Skapa en ström med create stream or createfrom ... stream
• Lägg till ett objekt i en ström med publish or publishfrom
• Hämta en lista över strömmar med liststreams
• Börja eller sluta spåra en ström med subscribe och unsubscribe
• Hämta strömföremål med liststreamitems, liststreamkeyitems och liststreampublisheritems
• Lista strömnycklar och utgivare med liststreamkeys och liststreampublishers
• För stora strömföremål, hämta fullständig data med gettxoutdata (Se maxshowndata nedan)
• Kontrollera behörigheter per ström med samtal som grant [address] stream1.write
• Visa behörighet för en ström med listpermissions stream1.*

Några andra utvecklaranteckningar som rör strömmar:

• Smakämnen create tillåtelse tillåter en adress att skapa strömmar.
• Relevanta per-stream-behörigheter är write, admin och activate
• Nya blockchain-parametrar: root-stream-name (lämna tomt för inget), root-stream-open, anyone-can-create, admin-consensus-create, max-std-op-returns-count
• Nya parametrar för runtime: autosubscribe för att automatiskt prenumerera på nya strömmar skapade och maxshowndata för att begränsa mängden data i API-svar (se gettxoutdata ovan).
• Den maximala storleken för data från ett strömobjekt fastställs av max-std-op-return-size blockchain-parameter, liksom den minsta av maximum-block-size och max-std-tx-size värden minus några hundra byte.
• Noder med det gamla plånbokformatet kan inte prenumerera på strömmar och bör uppgraderas.

 

• Myntsmart. Europas bästa bitcoin- och kryptobörs.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. FRI TILLGÅNG.
• CryptoHawk. Altcoin radar. Gratis provperiod.
• Källa: https://www.multichain.com/blog/2016/09/introducing-multichain-streams/