Hoe een halfbakken blockchain te herkennen

Wanneer kettingen en blokken geen nuttig doel hebben

Ongeveer 18 maanden zijn verstreken sinds de financiële sector massaal wakker werd door de mogelijkheden van toegestane blockchains, of om de meer algemene term "gedistribueerde grootboeken" te gebruiken. Sindsdien is er een tsunami van activiteiten geweest, waaronder onderzoeksrapporten, strategische investeringen, proefprojecten en de vorming van vele consortia. Niemand kan de bankwereld beschuldigen het potentieel van deze technologie niet serieus te nemen.

Natuurlijk heeft de explosieve groei in blockchain-projecten de ontwikkeling van toegestane blockchain-platforms gestimuleerd, waarop die projecten zijn gebouwd. Ons product bijvoorbeeld MultiChain is het gebruik in het afgelopen jaar verdrievoudigd, of we nu webverkeer, maandelijkse downloads of commerciële vragen meten. En natuurlijk zijn er veel andere platforms, zoals BigChainDB, Keten, Corda, credits, Elementen, Eris, Stof, Ethereum (ingezet in een gesloten netwerk), HydraChain en Open keten. Om nog maar te zwijgen van nog meer startups die een soort blockchain-platform hebben ontwikkeld maar het niet publiekelijk beschikbaar hebben gemaakt.

Voor bedrijven die een nieuwe technologie willen verkennen en begrijpen, is een overvloed aan keuze over het algemeen een goede zaak. Echter, in het geval van blockchains, die nog steeds losjes gedefinieerd en slecht begrepen blijven, heeft deze hoorn des overvloeds een aanzienlijk nadeel: veel van de beschikbare "blockchain" -platforms pakken niet echt het kernprobleem aan dat ze moeten oplossen. En wat is dat probleem? Staat u mij toe het beknopte te citeren video definitie door Richard Gendal Brown, CTO van R3, volledig:

Een gedistribueerd grootboek is een systeem waarmee partijen die elkaar niet volledig vertrouwen, tot een consensus kunnen komen over het bestaan, de aard en de evolutie van een reeks gedeelde feiten zonder afhankelijk te zijn van een volledig vertrouwde gecentraliseerde derde partij.

Om een ​​extreem voorbeeld te nemen, overweeg een stel legoblokjes die aan elkaar zijn vastgebonden met een touwtje. Als we de term 'blockchain' gebruiken om dit mode-item te beschrijven, wie zegt dan dat we het niet nauwkeurig beschrijven? En toch zal die bepaalde blokketen niet meerdere partijen helpen om een ​​database veilig en direct te delen zonder een centrale tussenpersoon. Evenzo doen veel "blockchain" -platforms iets dat verband houdt met blokkenketens, maar missen ook de noodzakelijke eigenschappen om als basis te dienen voor een peer-to-peer-database.

Een andere reeks blokken die niet helpt bij het delen van databases - (bron).

Minimaal haalbare blockchain

Om de basisvereisten van een gedistribueerd grootboek te begrijpen, helpt het om te verduidelijken hoe deze systemen verschillen van reguliere databases, die worden beheerd door een enkele entiteit. Laten we bijvoorbeeld eens kijken naar een eenvoudig systeem om bij te houden wie de aandelen van een bepaald bedrijf bezit. Het grootboek, zoals geïmplementeerd in een database, heeft voor elke eigenaar één rij met twee kolommen: de identificatie van de eigenaar, zoals hun naam, en het overeenkomstige aantal aandelen.

Hier zijn zes cruciale manieren waarop dit systeem zijn gebruikers zou kunnen teleurstellen:

• Namaak: Overdracht van aandelen van de ene persoon naar de andere zonder toestemming van de afzender.
• Censuur: Weigeren om te voldoen aan iemands verzoek om bepaalde aandelen elders over te dragen.
• Omkering: Een overdracht ongedaan maken die ergens in het verleden heeft plaatsgevonden.
• Onwettigheid: Het wijzigen van de totale hoeveelheid aandelen in het systeem zonder een overeenkomstige actie van de uitgevende instelling.
• tegenstrijdigheid: Verschillende antwoorden geven op vragen van verschillende gebruikers.
• Uitvaltijd: Helemaal niet reageren op inkomende verzoeken om informatie.

Vanwege al deze mogelijkheden moeten de aandeelhouders een hoog niveau van vertrouwen behouden in degene die dit grootboek namens hen beheert. Het opbouwen en runnen van een organisatie die dat vertrouwen waard is, brengt veel gedoe en kosten met zich mee.

Blockchains of gedistribueerde grootboeken elimineren de behoefte aan dit soort centrale database-exploitanten, doordat de gebruikers van een database rechtstreeks met elkaar kunnen communiceren op een peer-to-peer-basis. In ons voorbeeld konden de aandeelhouders hun aandelen veilig houden op een blockchain die ze gezamenlijk beheren, en direct over die keten naar elkaar overboeken. (Het nadeel is een aanzienlijk verlies van vertrouwelijkheid tussen de gebruikers van de keten, die we hier niet zullen behandelen, maar ik heb eerder uitvoerig besproken.)

Dit alles brengt ons terug bij de kwestie van blockchain-platforms. Om een ​​levensvatbare basis te zijn voor peer-to-peer delen van databases, moet een blockchain zijn deelnemers beschermen tegen alle zes soorten databasefalen: vervalsing, censuur, omkering, onwettige transacties, inconsistentie en downtime. Hoewel veel producten op de markt aan deze vereisten voldoen, komen er nogal wat tekort. Ik noem deze blockchains 'halfbakken' omdat ze kunnen adresseren sommige van deze risico's, maar niet allemaal. In sommige opzichten blijven de gebruikers van de database afhankelijk van het goede gedrag van een enkele deelnemer, en dat is precies het scenario dat we willen vermijden.

Deze halfbakken blockchains zijn er in een groot aantal varianten, maar drie archetypen vallen op als de meest voorkomende of voor de hand liggende. Ik noem geen individuele producten omdat, nou, ik wil niet beledigen. De blockchain-opstartgemeenschap is klein genoeg dat de meesten van ons elkaar kennen via conferenties en andere vergaderingen, en de interacties zijn meestal positief. Maar als blockchains (in de zin van bruikbare peer-to-peer databases) ooit zullen verschijnen als een samenhangende productcategorie, is het belangrijk om onderscheid te maken tussen halfbakken en echte oplossingen.

De enige validator-blockchain

Een patroon dat we een paar keer hebben gezien, is een blockchain waarin slechts één deelnemer de blokken kan genereren waarin transacties worden bevestigd. Transacties worden naar dit ene knooppunt gestuurd in plaats van naar het netwerk als geheel te worden uitgezonden, dus hun acceptatie is afhankelijk van de grillen van deze partij in plaats van een soort meerderheidsconsensus. Maar als een centrale partij eenmaal een blok heeft gebouwd, wordt het uitgezonden naar de andere knooppunten in het netwerk, die onafhankelijk de geldigheid van de transacties binnenin kunnen bevestigen en het nieuwe blok lokaal en permanent kunnen registreren.

Om terug te keren naar onze zes vormen van database-storing, is dit type blockchain verre van nutteloos. Transacties moeten digitaal worden ondertekend door de entiteit waarvan ze het geld verplaatsen, zodat ze niet kunnen worden vervalst door de centrale partij. Ze kunnen niet worden teruggedraaid omdat elk knooppunt zijn eigen kopie van de ketting behoudt. En transacties kunnen geen illegale operaties uitvoeren, zoals het creëren van activa uit het niets, omdat elk knooppunt elke transactie onafhankelijk valideert op juistheid. Ten slotte houdt elk knooppunt zijn eigen kopie van de database bij, zodat de inhoud altijd beschikbaar is om te lezen.

Vier op de zes is helaas niet genoeg. Het validerende knooppunt kan individuele transacties gemakkelijk censureren door te weigeren deze op te nemen in de blokken die het creëert. Zelfs als de operators van dit knooppunt eerlijk zijn, kan een systeem- of communicatiefout het onbeschikbaar maken, waardoor alle transactieverwerking wordt stopgezet. Bovendien kan het validerende knooppunt, afhankelijk van de configuratie, mogelijk verschillende versies van de blockchain naar verschillende deelnemers verzenden. In termen van censuur en consistentie bevat de database nog steeds één enkel storingspunt, waarop alle andere knooppunten vertrouwen.

Eén platform biedt een draai aan dit schema, waarbij blokken centraal worden gegenereerd door een enkel knooppunt, maar een quorum van andere aangewezen knooppunten ondertekent ze om consensus aan te geven. In termen van het risico op inconsistentie helpt dit zeker. De knooppunten in het quorum zullen hun handtekening slechts uitlenen aan een enkele versie van de blockchain, die daarom als gezaghebbend kan worden beschouwd. Desalniettemin kunnen de quorumknooppunten niet helpen als de blokgenerator transacties censureert of de verbinding met het internet verliest. Uiteindelijk gebruikt dit type blockchain nog steeds een hub-and-spoke-architectuur, in plaats van een peer-to-peer-netwerk.

De gedeelde staat-blockchain

Technisch gezien zijn er veel overeenkomsten tussen blockchains en meer traditionele gedistribueerde databases zoals Cassandra en MongoDB. In beide gevallen kunnen transacties door elk knooppunt in het netwerk worden geïnitieerd en moeten ze alle andere knooppunten bereiken als onderdeel van een consensus over de ontwikkelingsstatus van de database. Zowel blockchains als gedistribueerde databases hebben te maken met latentie (communicatievertragingen die voortkomen uit de afstand tussen knooppunten) en de mogelijkheid dat sommige knooppunten en / of communicatieverbindingen af ​​en toe uitvallen.

Gedistribueerde databases bestaan ​​al een tijdje, dus elke ontwikkelaar van een blockchainplatform zou er goed aan doen om hun consensusalgoritmen en de strategieën die ze gebruiken om transacties wereldwijd te ordenen en conflicten op te lossen, te begrijpen. Desalniettemin is het belangrijk om niet te ver te gaan met de vergelijking, omdat blockchains te maken hebben met een cruciale extra uitdaging - het ontbreken van vertrouwen tussen de knooppunten van de database. Terwijl gedistribueerde databases zich richten op het bieden van schaalbaarheid, robuustheid en hoge prestaties binnen de grenzen van één organisatie, moeten blockchains opnieuw worden ontworpen om veilig te kunnen traverse die grenzen.

Om terug te keren naar onze zes soorten databaserisico, hoeft een knooppunt in een gedistribueerde database zich alleen zorgen te maken over downtime, dat wil zeggen de mogelijkheid dat andere knooppunten niet meer beschikbaar zijn. Knooppunten kunnen er veilig van uitgaan dat elke transactie en elk bericht op het netwerk geldig is en niet betrekking heeft op vervalsing, censuur, omkering, onrechtmatigheid of inconsistentie. Hun grootste probleem is het omgaan met twee gelijktijdige maar geldige transacties, geïnitieerd op verschillende knooppunten, die hetzelfde stuk gegevens beïnvloeden. Het oplossen van deze conflicten is zeker niet triviaal, maar het is nog steeds een stuk eenvoudiger dan je zorgen te maken over "Byzantijnse fouten“, Waarbij sommige knooppunten opzettelijk het functioneren van anderen verstoren.

Een database kan alleen veilig worden gedeeld over vertrouw grenzen als knooppunten alle activiteiten op het netwerk met een zekere mate van wantrouwen behandelen. Elke transactie die de database wijzigt, moet bijvoorbeeld individueel digitaal worden ondertekend, omdat er in een peer-to-peer-architectuur geen andere manier is om het ware oorsprongspunt te kennen. Evenzo moet elk binnenkomend bericht, zoals de aankondiging van een nieuw blok, kritisch worden beoordeeld op inhoud en context. Anders dan in gedistribueerde databases, mogen knooppunten de status van een ander knooppunt niet onmiddellijk en rechtstreeks kunnen wijzigen.

Sommige "blockchain" -platforms zijn ontwikkeld door te beginnen met een gedistribueerde database en enkele functies bovenop te strooien om ze meer blockchainy te maken. Door transacties bijvoorbeeld in blokken te groeperen en hashes (digitale vingerafdrukken) van die blokken in de database op te slaan, willen ze een vorm van onveranderlijkheid toevoegen. Maar tenzij elk knooppunt er zeker van kan zijn dat de lijst met hashes niet kan worden gewijzigd door een ander knooppunt, is dit type onveranderlijkheid gemakkelijk te spelen. De standaardreactie op deze kritiek is dat elk beveiligingsprobleem met voldoende tijd en codering kan worden opgelost. Maar dit is vergelijkbaar met het vasthouden van enkele gevangenen in een open veld en proberen te voorkomen dat ze ontsnappen met struikeldraden en greppels. Het is veel veiliger om een ​​speciaal gebouwde betonconstructie te gebruiken, waarvan de deuren zijn vergrendeld en waarvan de ramen zijn geblokkeerd.

De ene cloud-blockchain

Veruit het vreemdste fenomeen dat ik heb gezien, zijn blockchain-platforms die alleen toegankelijk zijn via het cloudgebaseerde platform-as-a-service van hun ontwikkelaar. Voor alle duidelijkheid, we hebben het niet over enkele deelnemers aan een blockchain het kiezen van om hun knooppunten te hosten op hun favoriete cloudprovider, zoals Microsoft Azure or Amazon Web Services. Dit is eerder een blockchain die dat kan Slechts toegankelijk zijn via API's die worden weergegeven door de servers van een bedrijf dat het host.

Laten we, omwille van het argument, toegeven dat een gecentraliseerde blockchain-provider echt een groep knooppunten onder zijn controle heeft. Welk verschil maakt dit voor de gebruikers van het systeem die API-verzoeken verzenden en reacties ontvangen? De deelnemers kunnen niet beoordelen of de transacties van iedereen zonder omissie of fouten zijn verwerkt. Misschien functioneert de centrale dienst niet goed, of censureert of keert ze bepaalde transacties opzettelijk terug. En als u denkt dat de blockchain-provider hier geen reden voor heeft, waarom zou u ze dan niet gebruiken om in plaats daarvan een reguliere gecentraliseerde database te hosten? U krijgt een volwassener product met betere prestaties en loopt geen enkel risico op het werken met nieuwe technologieën. Kortom, gecentraliseerde blockchains zijn ongeveer net zo handig als Lego aan een touwtje.

Het mysterie oplossen

We hebben nu drie soorten platforms gezien die zichzelf op de markt brengen als "blockchains" en inderdaad gebruik maken van een ketting van blokken, maar die het fundamentele probleem waarvoor deze systemen zijn ontworpen niet oplost. Samenvattend, dit is om het mogelijk te maken dat één enkele database veilig en direct gedeeld kan worden over de grenzen van vertrouwen heen, zonder een centrale tussenpersoon.

Afgezien van het wijzen op dit bijzondere fenomeen, denk ik dat het leerzaam is om te overwegen wat er aan ten grondslag zou kunnen liggen. Waarom bouwen zoveel blockchain-startups producten die niet aan de belofte van deze technologie voldoen en bereiken ze vaak niet meer dan traditionele gecentraliseerde of gedistribueerde databases? Waarom verspillen zoveel getalenteerde mensen zoveel van hun tijd?

Ik kan twee hoofdklassen van uitleg zien - technisch en commercieel. Om te beginnen met het technische, is het nogal lastig om gedistribueerde consensussystemen te creëren die tolereren dat een of meer knooppunten zich op onvoorspelbare manieren kwaadwillend gedragen. In het geval van MultiChain speelden we een beetje vals, door de door strijd geharde referentie-implementatie van bitcoin als uitgangspunt te gebruiken en vervolgens het bewijs van werk te vervangen door een structureel vergelijkbaar consensusalgoritme genaamd "mining diversiteit". Teams die vanaf nul een blockchain-knooppunt ontwikkelen, moeten diep nadenken over asynchrone en vijandige processen - een combinatie waar maar weinig programmeurs ervaring mee hebben. Ik kan zeker de verleiding begrijpen om een ​​snelkoppeling te nemen, zoals het gebruik van een enkel knooppunt om blokken te genereren, of meeliften op een bestaande gedistribueerde database, of alleen het uitvoeren van knooppunten in een vertrouwde omgeving. Als u een van deze kiest, wordt het leven voor ontwikkelaars ongetwijfeld gemakkelijker, ook al ondermijnt dit het hele punt.

Wat commerciële redenen betreft, lijkt elke startup de blockchain-mogelijkheid vanuit een andere hoek te benaderen. Hier bij Coin Sciences zijn we gefocust op het worden van een (database) softwareleverancier, dus we distribueren MultiChain gratis terwijl we een premium knooppunt ontwikkelen met extra functies. Andere startups willen abonnementsdiensten verkopen, dus bouwen ze natuurlijk een platform dat klanten niet zelf kunnen hosten. Sommigen hopen een blockchain centraal te besturen of hun partners daarbij te helpen (een vreemde ambitie voor een technologie voor desintermediatie!) En voelen zich natuurlijk aangetrokken tot consensusalgoritmen die afhankelijk zijn van een enkel knooppunt. En tot slot zijn er bedrijven die als voornaamste doel hebben om adviesdiensten te verkopen, in welk geval hun platform helemaal niet hoeft te functioneren, zolang de website enkele grote klanten oplevert.

Misschien is een ander probleem dat sommige blockchain-bedrijven worden geleid door mensen die ongetwijfeld barsten van talent, maar geen diepgaande kennis van de technologie zelf hebben. Bij startups die een nieuw veld uitbouwen, is het waarschijnlijk van vitaal belang dat strategische beslissingen worden genomen door mensen die de aard van dat veld begrijpen en hoe het verschilt van wat er eerder was. Niet veel blockchain-startups lijken zichzelf in een hoek te hebben gezet door een productvisie na te streven die aantrekkelijk is voor hun klanten, maar niet echt kan worden gebouwd.

Hoe kunt u als gebruiker van blockchains voorkomen dat u door deze drogredenen wordt betrapt? Vraag bij het evalueren van een bepaald blockchain-platform of het voldoet aan de zes vereisten van veilig peer-to-peer delen van databases: voorkomen van downtime en inconsistentie, evenals vervalsing van transacties, censuur, omkering en onwettigheid. En pas op voor verklaringen die bestaan ​​uit te veel mompelen of met de hand zwaaien - ze betekenen waarschijnlijk dat het antwoord nee is.

Plaats eventuele opmerkingen op LinkedIn.

Bron: https://www.multichain.com/blog/2016/12/spot-half-baked-blockchain/