Sådan finder du en halvbagt blockchain

Når kæder og blokke ikke tjener noget nyttigt formål

Cirka 18 måneder er gået, siden finanssektoren masser af vågnede til mulighederne for tilladte blockchains eller til at bruge det mere generelle udtryk "distribuerede hovedbøger". Perioden siden har oplevet en tsunami af aktivitet, herunder forskningsrapporter, strategiske investeringer, pilotprojekter og dannelsen af ​​mange konsortier. Ingen kan beskylde bankverdenen for ikke at tage potentialet i denne teknologi alvorligt.

Naturligvis har den eksplosive vækst i blockchain-projekter drevet udviklingen af ​​tilladte blockchain-platforme, som disse projekter er bygget på. For eksempel vores produkt multikæde har tredoblet brug i det forløbne år, uanset om vi måler webtrafik, månedlige downloads eller kommercielle forespørgsler. Og selvfølgelig er der mange andre platforme, f.eks BigChainDB, Kæde, corda, Medvirkende, Elements, Eris, Stof, Ethereum (implementeret i et lukket netværk), HydraChain , Åben kæde. For ikke at nævne endnu flere startups, der har udviklet en slags blockchain-platform, men ikke har gjort den offentligt tilgængelig.

For virksomheder, der ønsker at udforske og forstå en ny teknologi, er et væld af valg generelt en god ting. I tilfælde af blockchains, der stadig er løst defineret og dårligt forstået, kommer denne overflødighedshorn med en betydelig ulempe: mange af de tilgængelige "blockchain" -platforme adresserer faktisk ikke det kerneproblem, de er beregnet til at løse. Og hvad er det problem? Tillad mig at citere det kortfattede videodefinition af Richard Gendal Brown, CTO for R3, fuldt ud:

En distribueret hovedbog er et system, der gør det muligt for parter, der ikke fuldt ud stoler på hinanden, at blive enige om eksistensen, naturen og udviklingen af ​​et sæt delte fakta uden at skulle stole på en fuldt betroet centraliseret tredjepart.

For at tage et ekstremt eksempel, overvej en flok Lego-klodser bundet sammen med snor. Hvis vi bruger udtrykket "block chain" til at beskrive denne modeartikel, hvem skal da sige, at vi ikke beskriver det præcist? Og alligevel hjælper den særlige kæde af blokke ikke flere parter med at dele en database sikkert og direkte uden en central formidler. Tilsvarende gør mange "blockchain" -platforme noget relateret til kæder af blokke, men mangler også de nødvendige egenskaber til at tjene som grundlag for en peer-to-peer-database.

En anden kæde af blokke, der ikke hjælper med databasedeling - kilde.

Minimum levedygtig blockchain

For at forstå de basale krav til en distribueret hovedbog hjælper det med at afklare, hvordan disse systemer adskiller sig fra almindelige databaser, der styres af en enkelt enhed. Lad os for eksempel overveje et simpelt system til sporing af, hvem der ejer et bestemt selskabs aktier. Hovedbogen, som implementeret i en database, har en række for hver ejer, der indeholder to kolonner: ejerens identifikator, såsom deres navn, og den tilsvarende mængde aktier.

Her er seks vigtige måder, hvorpå dette system kan svigte sine brugere:

• Forfalskning: Overførsel af aktier fra en person til en anden uden afsenderens tilladelse.
• Censur: Nægter at opfylde nogens anmodning om at overføre nogle aktier andre steder.
• Tilbageførsel: Fortrydning af en overførsel, der fandt sted på et tidspunkt i fortiden.
• illegitimitet: Ændring af den samlede mængde aktier i systemet uden en tilsvarende handling fra udstederen.
• uoverensstemmelse: Giv forskellige svar på forespørgsler fra forskellige brugere.
• Nedetid: Svarer ikke over for indgående anmodninger om information.

På grund af alle disse muligheder skal aktionærerne opretholde en høj grad af tillid til den, der administrerer denne hovedbok på deres vegne. Opbygning og drift af en organisation, der er værdig for denne tillid, kommer med betydelige besvær og omkostninger.

Blockchains eller distribuerede ledgers fjerner behovet for denne form for central databaseoperatør ved at lade brugerne af en database interagere direkte med hinanden på peer-to-peer-basis. I vores eksempel kunne aktionærerne sikkert holde deres aktier i en blockchain, som de kollektivt administrerer, og foretage overførsler til hinanden med det samme over denne kæde. (Ulempen er et betydeligt tab af fortrolighed mellem kædens brugere, som vi ikke behandler her, men jeg har tidligere diskuteret i længden.)

Alt dette bringer os tilbage til spørgsmålet om blockchain-platforme. For at tjene som et levedygtigt grundlag for peer-to-peer-database-deling skal en blockchain beskytte sine deltagere mod alle seks typer databasefejl - forfalskning, censur, tilbageførsel, ulovlige transaktioner, inkonsekvens og nedetid. Mens mange produkter på markedet opfylder disse krav, kommer en hel del af dem kort. Jeg kalder disse blockchains "halvbagt", fordi de måske adresserer nogle af disse risici, men ikke alle. I det mindste i nogle henseender forbliver databasens brugere afhængige af den enkelte deltagers gode opførsel, hvilket netop er det scenarie, vi vil undgå.

Disse halvbagte blockchains kommer i et vilkårligt antal varianter, men tre arketyper skiller sig ud som de mest almindelige eller indlysende. Jeg vil ikke navngive individuelle produkter, fordi jeg ikke vil fornærme. Blockchain-startfællesskabet er lille nok til, at de fleste af os kender hinanden gennem konferencer og andre møder, og interaktionerne har tendens til at være positive. Ikke desto mindre, hvis blockchains (i betydningen nyttige peer-to-peer-databaser) nogensinde kommer til at dukke op som en sammenhængende produktkategori, er det vigtigt at skelne mellem halvbagte og reelle løsninger.

Den ene validator-blockchain

Et mønster, vi har set et par gange, er en blockchain, hvor kun en deltager kan generere de blokke, hvor transaktioner bekræftes. Transaktioner sendes til denne ene knude i stedet for at blive sendt til netværket som helhed, så deres accept er underlagt dette partis luner snarere end en form for flertallighedskonsensus. Når der først er bygget en blok af denne centrale part, sendes den til de andre knudepunkter i netværket, der uafhængigt kan bekræfte gyldigheden af ​​transaktionerne inden for og registrere den nye blok lokalt og permanent.

For at vende tilbage til vores seks former for fejl i databasen er denne type blockchain langt fra ubrugelig. Transaktioner skal underskrives digitalt af den enhed, hvis midler de flytter, så de ikke kan smedes af den centrale part. De kan ikke vendes, fordi hver knude opretholder sin egen kopi af kæden. Og transaktioner kan ikke udføre ulovlige handlinger som at oprette aktiver udefra, fordi hver knude uafhængigt validerer hver transaktion for korrekthed. Endelig opretholder hver knude sin egen kopi af databasen, så dens indhold er altid tilgængeligt til læsning.

Desværre er fire ud af seks ikke nok. Den validerende node kan let censurere individuelle transaktioner ved at nægte at medtage dem i de blokke, den opretter. Selv hvis operatørerne af denne node er ærlige, kan et system- eller kommunikationsfejl gøre det utilgængeligt, hvilket får al transaktionsbehandling til at stoppe. Afhængigt af opsætningen kan valideringsnoden desuden være i stand til at overføre forskellige versioner af blockchain til forskellige deltagere. Med hensyn til censur og konsistens indeholder databasen stadig et enkelt mislykkelsespunkt, som alle andre noder er afhængige af.

En platform tilbyder en vri på dette skema, hvor blokke genereres centralt af en enkelt knude, men et kvorum af andre udpegede knudepunkter signerer dem for at indikere konsensus. Med hensyn til risikoen for inkonsekvens hjælper dette bestemt. Knuderne i quorumet giver kun deres underskrifter til en enkelt version af blockchain, som derfor kan betragtes som autoritativ. Ikke desto mindre kan kvorumnoderne ikke hjælpe, hvis blokgeneratoren censurerer transaktioner eller mister sin forbindelse til Internettet. I sidste ende bruger denne type blockchain stadig en hub-and-speak-arkitektur snarere end et peer-to-peer-netværk.

Den delte tilstand blockchain

Teknisk set er der mange ligheder mellem blockchains og mere traditionelle distribuerede databaser som Cassandra og MongoDB. I begge tilfælde kan transaktioner initieres af en hvilken som helst node i netværket og skal nå alle de andre noder som en del af en konsensus om databasens udviklingsstat. Både blockchains og distribuerede databaser skal klare latens (kommunikationsforsinkelser, der stammer fra afstanden mellem noder) og muligheden for, at nogle noder og / eller kommunikationslinks intermitterende fejler.

Distribuerede databaser har eksisteret i et stykke tid, så enhver blockchain-platformudvikler ville gøre det godt at forstå deres konsensusalgoritmer og de strategier, de bruger til globalt at bestille transaktioner og løse konflikter. Ikke desto mindre er det vigtigt ikke at tage sammenligningen for langt, fordi blockchains skal kæmpe med en afgørende ekstra udfordring - fravær af tillid mellem databasens noder. Mens distribuerede databaser fokuserer på at give skalerbarhed, robusthed og høj ydeevne inden for en enkelt organisations grænser, skal blockchains redesignes for at kunne krydse disse grænser.

For at vende tilbage til vores seks typer databaserisiko behøver en node i en distribueret database kun bekymre sig om nedetid, dvs. muligheden for, at andre noder ikke bliver tilgængelige. Noder kan med sikkerhed antage, at enhver transaktion og besked på netværket er gyldig og ikke vedrører forfalskning, censur, tilbageførsel, ulovlighed eller inkonsekvens. Deres værste problem er at håndtere to samtidige, men gyldige transaktioner, initieret på forskellige noder, som påvirker det samme stykke data. Det er på ingen måde trivielt at løse disse konflikter, men det er stadig meget lettere end at bekymre sig om “Byzantinske fejl“, Hvor nogle noder bevidst handler for at forstyrre andres funktion.

En database kan kun deles sikkert tværs tillidsgrænser, hvis noder behandler al aktivitet på netværket med en vis grad af mistanke. For eksempel skal enhver transaktion, der ændrer databasen, være individuelt signeret digitalt, da der i en peer-to-peer-arkitektur ikke er nogen anden måde at kende dens sande oprindelsessted. Tilsvarende skal enhver indgående besked, såsom annoncering af en ny blok, vurderes kritisk for dets indhold og kontekst. I modsætning til i distribuerede databaser skal noder ikke være i stand til straks og direkte at ændre en anden nodes tilstand.

Nogle "blockchain" -platforme er blevet udviklet ved at starte med en distribueret database og drysse nogle funktioner ovenpå for at gøre dem mere blockchainy. For eksempel ved at gruppere transaktioner i blokke og gemme hashes (digitale fingeraftryk) af disse blokke i databasen sigter de mod at tilføje en form for uforanderlighed. Men medmindre hver node kan være sikker på, at dens liste over hashes ikke kan ændres af en anden node, er denne type uforanderlighed let at spille. Standardresponset på denne kritik er, at ethvert sikkerhedsproblem kan løses med tilstrækkelig tid og kodning. Men det er snarere som at holde nogle fanger i et åbent felt og prøve at stoppe dem med at flygte med tripwires og grøfter. Det er langt sikrere at bruge en specialbygget betonstruktur, hvis døre er låst, og hvis vinduer er spærrede.

Den ene sky-blockchain

Langt det mærkeligste fænomen, jeg har set, er blockchain-platforme, som kun kan tilgås via deres udviklers skybaserede platform-as-a-service. For at være klar taler vi ikke om nogle af en blockchains deltagere vælge at være vært for deres noder på deres valgte cloud-udbyder, f.eks Microsoft Azure or Amazon Web Services. Det er snarere en blockchain, der kan kun få adgang til API'er, der er eksponeret af serverne i et firma, der "hoster" det.

Lad os af argumentets skyld give, at en centraliseret blockchain-udbyder virkelig har en gruppe noder, der kører under dens kontrol. Hvilken forskel gør det for brugerne af systemet, der sender API-anmodninger og modtager svar? Deltagerne har ingen måde at vurdere, om alles transaktioner er blevet behandlet uden undladelse eller fejl. Måske fungerer den centrale tjeneste ikke, eller måske censurerer den eller vender nogle transaktioner bevidst. Og hvis du mener, at blockchain-udbyderen ikke har nogen grund til at gøre dette, hvorfor ikke bruge dem til at være vært for en regelmæssig centraliseret database i stedet? Du får et mere modent produkt med bedre ydeevne og lider ingen af ​​risikoen ved at arbejde med nye teknologier. Kort sagt er centraliserede blockchains omtrent lige så nyttige som Lego på en streng.

Løs mysteriet

Vi har nu set tre typer platforme, der markedsfører sig selv som "blockchains", og som faktisk gør brug af en kæde af blokke, men som ikke løser det grundlæggende problem, som disse systemer er designet til. For at opsummere er dette for at muliggøre, at en enkelt database kan deles sikkert og direkte på tværs af tillidsgrænser uden en central formidler.

Bortset fra at pege på dette ejendommelige fænomen, tror jeg, det er lærerigt at overveje, hvad der kan ligge til grund for det. Hvorfor bygger så mange blockchain startups produkter, der ikke opfylder løftet om denne teknologi og ofte ikke opnår mere end traditionelle centraliserede eller distribuerede databaser? Hvorfor spilder så mange talentfulde mennesker så meget af deres tid?

Jeg kan se to hovedklasser af forklaring - teknisk og kommerciel. Til at begynde med det tekniske er det ret vanskeligt at oprette distribuerede konsensus-systemer, der kan tolerere en eller flere noder, der opfører sig ondsindet på uforudsigelige måder. I tilfælde af MultiChain snydte vi noget ved at bruge bitcoins kamphærdede referenceimplementering som udgangspunkt og derefter erstatte bevis for arbejde med en strukturelt lignende konsensusalgoritme kaldet "mining diversitet". Hold, der udvikler en blockchain-knude fra bunden, skal tænke dybt over asynkrone og kontradiktoriske processer - en kombination, som få programmerere har erfaring med. Jeg kan helt sikkert forstå fristelsen til at tage en genvej, som f.eks. At bruge en enkelt knude til at generere blokke eller piggybacking på en eksisterende distribueret database eller kun køre noder i et betroet miljø. At vælge en af ​​disse gør utvivlsomt livet lettere for udviklere, selvom dette undergraver hele pointen.

Af kommercielle grunde synes enhver opstart at nærme sig blockchain-muligheden fra en anden vinkel. Her på Coin Sciences fokuserer vi på at blive en (database) softwareleverandør, så vi distribuerer MultiChain gratis, mens vi udvikler en premium-node med yderligere funktioner. Andre startups ønsker at sælge abonnementstjenester, så de vil naturligvis opbygge en platform, som kunderne ikke selv kan være vært for. Nogle håber på centralt at kontrollere en blockchain eller hjælpe deres partnere til at gøre det (en underlig ambition om en disintermediation-teknologi!) Og er naturligvis tiltrukket af konsensusalgoritmer, der er afhængige af en enkelt node. Og endelig er der virksomheder, hvis primære mål er at sælge konsulenttjenester, i hvilket tilfælde deres platform slet ikke behøver at fungere, så længe webstedet bringer nogle store kunder.

Måske er et andet problem, at nogle blockchain-virksomheder drives af mennesker, der utvivlsomt sprænger med talent, men mangler en dyb forståelse af selve teknologien. I startups, der udskærer et nyt felt, er det sandsynligvis vigtigt, at strategiske beslutninger træffes af folk, der forstår arten af ​​dette felt, og hvordan det adskiller sig fra det, der kom før. Ikke få blockchain-startups ser ud til at have malet sig ind i et hjørne ved at forfølge en produktvision, der er attraktiv for deres kunder, men som faktisk ikke kan bygges.

Hvordan kan du som bruger af blockchains undgå at blive fanget af disse fejl? Når du vurderer en bestemt blockchain-platform, skal du sørge for at spørge, om den opfylder de seks krav til sikker peer-to-peer-database-deling: forebyggelse af nedetid og inkonsekvens samt transaktionsforfalskning, censur, vending og illegitimitet. Og pas på forklaringer, der består af for meget mumling eller håndsvingning - de betyder sandsynligvis, at svaret er nej.

Skriv eventuelle kommentarer på LinkedIn.

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