Hur man upptäcker en halvbakt blockchain

När kedjor och block tjänar inget användbart syfte

Cirka 18 månader har gått sedan finanssektorn vaknade i massa till möjligheterna till tillåtna blockchains eller att använda den mer allmänna termen, ”distribuerade bokar”. Under denna tid har en tsunami av verksamhet, inklusive forskningsrapporter, strategiska investeringar, pilotprojekt och bildandet av många konsortier. Ingen kan anklaga bankvärlden för att inte ta denna teknik potential på allvar.

Naturligtvis har den explosiva tillväxten i blockchainprojekt drivit utvecklingen av tillåtna blockchainplattformar, på vilka dessa projekt är byggda. Till exempel vår produkt MultiKedja har tredubblats i användningen det senaste året, oavsett om vi mäter webbtrafik, nedladdningar per månad eller kommersiella förfrågningar. Och naturligtvis finns det många andra plattformar, t.ex. BigChainDB, Kedja, Corda, krediter, Elements, Eris, Tyg, Ethereum (distribueras i ett stängt nätverk), HydraChain och Öppen kedja. För att inte nämna ännu fler startups som har utvecklat någon form av blockchain-plattform men inte har gjort den tillgänglig för allmänheten.

För företag som vill utforska och förstå en ny teknik är ett överflöd av val i allmänhet bra. Men när det gäller blockchains, som fortfarande förblir löst definierade och dåligt förstått, kommer detta cornucopia med en betydande nackdel: många av de tillgängliga "blockchain" -plattformarna adresserar inte det kärnproblem som de är tänkta att lösa. Och vad är det problemet? Låt mig citera det kortfattade videodefinition av Richard Gendal Brown, CTO för R3, till fullo:

En distribuerad huvudbok är ett system som låter parter som inte helt litar på varandra komma överens om existensen, naturen och utvecklingen av en uppsättning delade fakta utan att behöva lita på en helt betrodd centraliserad tredje part.

För att ta ett extremt exempel bör du tänka på ett gäng Lego-tegelstenar som är bundna med strängen. Om vi ​​använder termen "block chain" för att beskriva detta modevarum, vem ska vi säga att vi inte beskriver det exakt? Och ändå kommer den specifika blockkedjan inte att hjälpa flera parter att säkert och direkt dela en databas utan en central mellanhand. På liknande sätt gör många “blockchain” -plattformar något relaterat till kedjor av block, men saknar också nödvändiga egenskaper för att tjäna som bas för en peer-to-peer-databas.

En annan blockkedja som inte hjälper till med databasdelning - källa.

Minsta möjliga blockchain

För att förstå de grundläggande kraven i en distribuerad huvudbok, hjälper det att klargöra hur dessa system skiljer sig från vanliga databaser, som kontrolleras av en enda enhet. Låt oss till exempel överväga ett enkelt system för att spåra vem som äger ett visst företags aktier. Ledningen, såsom implementerad i en databas, har en rad för varje ägare som innehåller två kolumner: ägarens identifierare, till exempel deras namn, och motsvarande mängd aktier.

Här är sex avgörande sätt på vilka detta system kan misslyckas med sina användare:

• Förfalskning: Överföra aktier från en person till en annan utan avsändarens tillstånd.
• Censur: Vägrar att uppfylla någons begäran om att överföra vissa aktier någon annanstans.
• Omkastning: Ångra en överföring som ägde rum någon gång i det förflutna.
• OLAGLIGHET: Ändra den totala mängden aktier i systemet utan motsvarande åtgärd från emittenten.
• Inkonsekvens: Ge olika svar på förfrågningar från olika användare.
• Downtime: Inte svarar på inkommande förfrågningar om information alls.

På grund av alla dessa möjligheter måste aktieägarna upprätthålla ett stort förtroende för den som förvaltar denna huvudbok på deras vägnar. Att bygga och driva en organisation som är värd det förtroendet kommer med stora besvär och kostnader.

Blockchains eller distribuerade bokar tar bort behovet av denna typ av central databasoperatör, genom att låta användare av en databas interagera direkt med varandra på peer-to-peer-basis. I vårt exempel kan aktieägarna säkert hålla sina aktier på en blockchain som de kollektivt hanterar och direkt överföra till varandra över den kedjan. (Nackdelen är en betydande förlust av konfidentialitet mellan kedjans användare, som vi inte kommer att ta upp här men jag har tidigare diskuteras långt.)

Allt detta leder oss tillbaka till frågan om blockchain-plattformar. För att tjäna som en livskraftig bas för delning av peer-to-peer-databas måste en blockchain skydda sina deltagare mot alla sex typer av databasfel - förfalskning, censur, reversering, illegitima transaktioner, inkonsekvens och driftstopp. Även om många produkter på marknaden uppfyller dessa krav, kommer en hel del av dem på kort. Jag kallar dessa blockchains "halvbakade" eftersom de kan adressera några av dessa risker, men inte alla. Åtminstone i vissa avseenden förblir databasens användare beroende av en enskild deltagares goda beteende, vilket är just det scenario vi vill undvika.

Dessa halvbakade blockchains finns i valfritt antal sorter, men tre arketyper sticker ut som de vanligaste eller uppenbara. Jag kommer inte att namnge enskilda produkter för, ja, jag vill inte förolämpa. Blockchain-startgruppen är tillräckligt liten för att de flesta av oss känner varandra genom konferenser och andra möten, och interaktionerna tenderar att vara positiva. Ändå, om blockchains (i betydelsen användbara peer-to-peer-databaser) någonsin kommer att dyka upp som en sammanhängande produktkategori, är det viktigt att skilja mellan halvbakade och verkliga lösningar.

Den ena validatorn blockchain

Ett mönster som vi har sett några gånger är en blockchain där endast en deltagare kan generera de block där transaktioner bekräftas. Transaktioner skickas till denna enda nod istället för att sändas till nätverket som helhet, så deras acceptans är föremål för detta partis nycklar snarare än någon form av majoritetssamförstånd. Fortfarande, när ett block har byggts av detta centralparti sänds det till de andra noderna i nätverket, som oberoende kan bekräfta giltigheten av transaktionerna inom, och spela in det nya blocket lokalt och permanent.

För att återgå till våra sex former av databasfel är denna typ av blockchain långt ifrån värdelös. Transaktioner måste undertecknas digitalt av den enhet vars medel de flyttar så att de inte kan smiddas av det centrala partiet. De kan inte vändas eftersom varje nod behåller sin egen kopia av kedjan. Och transaktioner kan inte utföra olagliga operationer som att skapa tillgångar ur luften, eftersom varje nod oberoende validerar varje transaktion för korrekthet. Slutligen behåller varje nod sin egen kopia av databasen, så dess innehåll är alltid tillgängligt för läsning.

Tyvärr räcker inte fyra av sex. Valideringsnoden kan enkelt censurera enskilda transaktioner genom att vägra att inkludera dem i blocken den skapar. Även om operatörerna för denna nod är ärliga, kan ett system- eller kommunikationsfel göra det inte tillgängligt, vilket gör att all transaktionsbehandling stoppas. Beroende på installationen kan valideringsnoden dessutom kunna överföra olika versioner av blockchain till olika deltagare. När det gäller censur och konsistens innehåller databasen fortfarande en enda punkt för misslyckande, som alla andra noder bygger på.

En plattform erbjuder en vridning av detta schema, i vilket block genereras centralt av en enda nod, men ett kvorum av andra utsedda noder undertecknar dem för att indikera konsensus. När det gäller risken för inkonsekvens hjälper detta verkligen. Noderna i kvorumet ger bara sina signaturer till en enda version av blockchain, som därför kan betraktas som auktoritativ. Quorumnoderna kan dock inte hjälpa om blockgeneratorn censurerar transaktioner eller förlorar sin anslutning till Internet. I slutändan använder denna typ av blockchain fortfarande en nav-och-tal-arkitektur snarare än ett peer-to-peer-nätverk.

Det delade tillståndet blockchain

Tekniskt sett finns det många likheter mellan blockchains och mer traditionella distribuerade databaser som Cassandra och MongoDB. I båda fallen kan transaktioner initieras av vilken nod som helst i nätverket och måste nå alla andra noder som en del av enighet om databasens utvecklingsstat. Både blockchains och distribuerade databaser måste hantera latens (kommunikationsförseningar som härrör från avståndet mellan noder) och möjligheten att vissa noder och / eller kommunikationslänkar intermittent misslyckas.

Distribuerade databaser har funnits ett tag, så alla blockchain-plattformsutvecklare skulle göra det bra att förstå deras konsensusalgoritmer och strategierna de använder för att globalt beställa transaktioner och lösa konflikter. Det är ändå viktigt att inte ta jämförelsen för långt, eftersom blockchains måste kämpa med en avgörande ytterligare utmaning - frånvaro av litar mellan databasens noder. Medan distribuerade databaser fokuserar på att tillhandahålla skalbarhet, robusthet och hög prestanda inom en enda organisations gränser, måste blockchains ändras om för att säkert korsa de gränserna.

För att återgå till våra sex typer av databaserisker behöver en nod i en distribuerad databas bara oroa sig för driftsstopp, dvs möjligheten att andra noder blir otillgängliga. Noder kan på ett säkert sätt anta att alla transaktioner och meddelanden i nätverket är giltiga och inte handlar om förfalskning, censur, vändning, illegitimitet eller inkonsekvens. Deras värsta problem är att hantera två samtidiga men giltiga transaktioner, initierade på olika noder, som påverkar samma data. Att lösa dessa konflikter är inte något trivialt, men det är fortfarande mycket lättare än att oroa dig för "Bizantinfel”, Där vissa noder medvetet agerar för att störa andras funktion.

En databas kan bara delas säkert tvärs lita gränser om noder behandlar all aktivitet i nätverket med en viss grad av misstank. Till exempel måste varje transaktion som modifierar databasen signeras individuellt digitalt eftersom det i en peer-to-peer-arkitektur inte finns något annat sätt att veta dess verkliga ursprungspunkt. På samma sätt måste varje inkommande meddelande, till exempel tillkännagivandet av ett nytt block, utvärderas kritiskt med avseende på innehåll och sammanhang. Till skillnad från i distribuerade databaser får noder inte kunna omedelbart och direkt ändra en annan nods tillstånd.

Vissa “blockchain” -plattformar har utvecklats genom att börja med en distribuerad databas och spruta några funktioner ovanpå för att göra dem mer blockchainy. Till exempel, genom att gruppera transaktioner i block och lagra hash (digitala fingeravtryck) av dessa block i databasen, syftar de till att lägga till en form av immutability. Men såvida inte varje nod kan vara säker på att dess lista över hascher inte kan modifieras av en annan nod, spelas denna typ av immutability lätt. Det vanliga svaret på denna kritik är att alla säkerhetsproblem kan lösas med tillräcklig tid och kodning. Men detta är snarare som att hålla några fångar i ett öppet fält och försöka hindra dem att rymma med tripwires och dike. Det är mycket säkrare att använda en specialbyggd betongkonstruktion, vars dörrar är låsta och vars fönster är spärrade.

Den enda moln blockchain

Det absolut märkligaste fenomenet jag har sett är blockchain-plattformar som bara kan nås via deras utvecklare molnbaserade plattform-som-en-tjänst. För att vara tydlig talar vi inte om några av blockchains deltagare välja att vara värd för sina noder på sin valfria molnleverantör, t.ex. Microsoft Azure or Amazon Web Services. Snarare är detta en blockchain som kan endast nås via API: er som exponeras av servrarna hos ett företag som ”värdar” det.

Låt oss, för argumentets skull, tillåta att en centraliserad blockchain-leverantör verkligen har en grupp noder som är under sin kontroll. Vilken skillnad gör detta för användare av systemet som skickar API-förfrågningar och får svar? Deltagarna har inget sätt att bedöma om allas transaktioner har behandlats utan utelämnande eller fel. Kanske fungerar den centrala tjänsten inte, eller kanske censurerar eller reverserar man vissa transaktioner medvetet. Och om du tror att blockchain-leverantören inte har någon anledning att göra detta, varför inte använda dem för att vara värd för en vanlig centraliserad databas istället? Du får en mogenare produkt med bättre prestanda och lider ingen av riskerna med att arbeta med ny teknik. Kort sagt är centraliserade blockchains ungefär lika användbara som Lego på en sträng.

Lösa mysteriet

Vi har nu sett tre typer av plattformar som marknadsför sig själva som ”blockchains” och verkligen använder en kedja av block, men som inte löser det grundläggande problemet som dessa system är utformade för. För att sammanfatta är detta att möjliggöra att en enda databas kan delas säkert och direkt över förtroendegränser, utan en central mellanhand.

Förutom att peka på detta märkliga fenomen, tror jag att det är lärorikt att överväga vad som kan ligga till grund för det. Varför bygger så många blockchain-startups produkter som inte uppfyller löften om denna teknik, som ofta inte uppnår mer än traditionella centraliserade eller distribuerade databaser? Varför slösar så många begåvade människor så mycket av sin tid?

Jag kan se två huvudklasser av förklaring - tekniska och kommersiella. Till att börja med det tekniska är det ganska knepigt att skapa distribuerade konsensussystem som kan tolerera en eller flera noder som uppträder skadligt på oförutsägbara sätt. När det gäller MultiChain lurade vi något, genom att använda bitcoin's stridshärdade referensimplementering som utgångspunkt, och sedan ersätta bevis på arbete med en strukturellt liknande konsensusalgoritm som kallas "gruvdiversitet". Team som utvecklar en blockchain-nod från grunden måste tänka djupt på asynkrona och motsatta processer - en kombination som få programmerare har erfarenhet av. Jag kan säkert förstå frestelsen att ta en genväg, till exempel att använda en enda nod för att generera block, eller piggybacking på en befintlig distribuerad databas, eller bara köra noder i en betrodd miljö. Att välja något av dessa gör utan tvekan livet lättare för utvecklare, även om detta undergräver hela poängen.

När det gäller kommersiella skäl verkar varje start närma sig blockchainmöjligheten från en annan vinkel. Här på Coin Sciences fokuserar vi på att bli en (databas) mjukvaruförsäljare, så vi distribuerar MultiChain gratis medan vi utvecklar en premiumnod med ytterligare funktioner. Andra nystartade företag vill sälja prenumerationstjänster, så de kommer naturligtvis att bygga en plattform som kunder inte kan vara värd för. Vissa hoppas kunna centralt kontrollera en blockchain eller hjälpa sina partners att göra det (en udda ambition för en disintermedieringsteknik!) Och dras naturligtvis till konsensusalgoritmer som förlitar sig på en enda nod. Och slutligen finns det företag vars primära mål är att sälja konsulttjänster, i vilket fall deras plattform inte behöver fungera alls, så länge webbplatsen får in några stora kunder.

En annan fråga är kanske att vissa blockchainföretag drivs av människor som utan tvekan spricker av talang, men saknar en djup förståelse för själva tekniken. I nystartade företag som utarbetar ett nytt fält är det förmodligen viktigt att strategiska beslut fattas av människor som förstår arten av det fältet och hur det skiljer sig från det som kom tidigare. Inte ett fåtal blockchain-startups verkar ha målade sig in i ett hörn genom att sträva efter en produktvision som är attraktiv för sina kunder, men inte kan byggas.

Hur kan du undvika att bli fångad av dessa missförstånd som användare av blockchains? När du utvärderar en viss blockchain-plattform ska du fråga om den uppfyller de sex kraven för säker delning av peer-to-peer-databas: förebyggande av stillestånd och inkonsekvens samt transaktionsförfalskning, censur, reversering och illegitimitet. Och se upp för förklaringar som består av för mycket mumling eller viftning med handen - de betyder förmodligen att svaret är nej.

Skicka eventuella kommentarer på Link.

Källa: https://www.multichain.com/blog/2016/12/spot-half-baked-blockchain/