Grundlæggende udfordringer med offentlige blockchains

Kilde: http://www.englishblog.com/2012/02/cartoon-murdoch-walking-on-thin-ice.html#.Wi17n7A-d24

Der er ingen tvivl om, at blockchain-teknologi har et enormt potentiale.

Decentraliserede udvekslinger, forudsigelsesmarkeder og kapitalforvaltningsplatforme er blot et par af de spændende applikationer, der udforskes af blockchain-udviklere.

Faktisk spændende nok til at rejse over milliarder i ICO'er og køre massive prisstigninger gennem hele 2017. Hype'en er ægte.

Misforstå mig ikke. Jeg elsker det faktum, at blockchain "hype" hjælper med at popularisere det hos mainstream-brugere. Endelig får jeg ikke blanke stirrer fra folk, når jeg siger “Bitcoin” eller “Ethereum”.

Der er dog en flipside til denne historie, der ikke får tilstrækkelig opmærksomhed: blockchains har adskillige tekniske tekniske barrierer, der gør dem upraktiske til mainstream-brug i dag.

Jeg tror, ​​at vi kommer dertil, men vi er nødt til at være realistiske som udviklere og investorer. Og virkeligheden er, at det kan vare mange år, før tillidsløse systemer er klar til mainstream-brug i skala.

Nogle af disse tekniske barrierer inkluderer:

  1. Begrænset skalerbarhed
  2. Begrænset privatliv
  3. Manglende formel kontraktverifikation
  4. Opbevaringsbegrænsninger
  5. Uholdbare konsensusmekanismer
  6. Mangel på regeringsførelse og standarder
  7. Utilstrækkelig værktøj
  8. Kvanteberegningstrussel
  9. … og mere.

I dette indlæg går jeg gennem disse tekniske barrierer og deler eksempler på løsninger til at overvinde dem.

Som udviklere mener jeg det er kritisk, at vi flytter noget af vores fokus væk fra skinnende nye ICO'er til de virkelige teknologiske udfordringer, der står i vores måde.

BEMÆRK: Der er ingen måde, jeg kan dække ethvert problem og enhver løsning derude, men jeg dækkede dem, jeg er mest bekendt med. Undlad venligst at for kritisere mig for ikke at medtage noget. Jeg ville elske, at du poster noget, jeg har savnet i kommentarerne, og jeg vil tilføje det, hvis jeg finder det passende :) ... Og hvis jeg har begået nogen fejl eller forkerte påstande, så fortæl mig det!

1. Begrænset skalerbarhed

I øjeblikket har alle offentlige blockchain-konsensusprotokoller en udfordrende begrænsning: hver fuldt deltagende knude i netværket skal behandle hver transaktion.

Hvorfor? Husk, at blockchains grundlæggende er "decentraliseret" - hvilket betyder, at ingen central parti er ansvarlig for at sikre og vedligeholde systemet. I stedet er hver enkelt knude på netværket ansvarlig for at sikre systemet ved at behandle hver transaktion og vedligeholde en kopi af hele staten.

Mens en decentraliserings-konsensusmekanisme giver os de vigtigste fordele ved blockchain, som vi alle er interesseret i - sikkerhedsgarantier, politisk neutralitet, censurmodstand osv. - kommer det på bekostning af skalerbarhed, da decentralisering pr. Definition begrænser antallet af transaktioner, som blockchain kan proces til begrænsningerne af en enkelt fuldt deltagende node i netværket.

To praktiske implikationer her:

  1. Lav gennemstrømning: Blockchains kan kun behandle et begrænset antal transaktioner
  2. Langsom transaktionstider: Den tid, der kræves til at behandle en blok transaktioner, er langsom. For eksempel er Bitcoin-blokeringstider 10 minutter, mens Ethereum-blokeringstider er omkring 14 sekunder. Disse tider er endnu længere i spidsbelagte øjeblikke. Sammenlign det med de næsten øjeblikkelige bekræftelser, du får, når du bruger tjenester som Square eller Visa.

Som et resultat er offentlige blockchains tvunget til at udveksle mellem lav transaktionstrøm og høj grad af centralisering.

Med andre ord, når størrelsen på blockchain vokser, øges også kravene til opbevaring, båndbredde og beregningskraft, der kræves af fuldt deltagende noder i netværket. På et tidspunkt bliver det uhåndterligt nok, at det kun er muligt for de få knudepunkter, der har råd til ressourcerne til at behandle blokke - hvilket fører til risikoen for centralisering.

På det tidspunkt har vi gjort en fuld 360-graders drejning og vendt tilbage til et centraliseret system, der kræver tillid til et par store spillere, mens det, vi ønsker, er et system, der håndterer tusinder af transaktioner i sekundet med de samme niveauer af decentralisering som cryptocurrency oprindeligt lovede at tilbyde.

Skalerbarhedsløsninger

Ideelt set ønsker vi et blockchain-design, der har lignende eller bedre sikkerhedsegenskaber som Bitcoin og Ethereum, samtidig med at vi er i stand til at fungere uden at hver enkelt knude behøver at behandle mere end en bestemt procentdel af de samlede transaktioner i netværket. Med andre ord har vi brug for en mekanisme til at begrænse antallet af noder, der skal validere hver transaktion, uden at miste netværkets tillid til, at hver transaktion er gyldig og autentisk. Det lyder muligvis enkelt med ord, men er teknologisk meget vanskeligt.

Skalerbarhed er en stor spærring for platformens fremtidige succes. Der er et par foreslåede løsninger, som i øjeblikket arbejdes på af forskellige udviklingshold i økosystemet. Jeg har skrevet meget om dette emne i et tidligere indlæg, som jeg anbefaler, at du læser, hvis du er interesseret. For en kort oversigt over nogle af de nuværende løsninger, se nedenfor:

Off-chain betalingskanaler

Tanken bag et mikropayment-netværk er at holde de fleste transaktioner væk fra blockchain. Det er i det væsentlige en mekanisme, ved hjælp af hvilken blockchain-interaktioner, der normalt opstår på blockchain i stedet, udføres fra blockchain. Blockchain bruges udelukkende som et afviklingslag til at behandle den endelige transaktion af en række interaktioner til den endelige afvikling, hvilket hjælper med at løfte byrden fra det underliggende blockchain.

Dette løser gennemstrømningsproblemet, som vi diskuterede ovenfor, fordi blockchain nu kan skaleres til størrelser af større transaktionsvolumener. Fordi en transaktion sker, så snart betalingskanalen behandler den, og ikke når en blok bliver bekræftet, løser mikropaymentkanaler transaktionshastighedsproblemet og eliminerer den typiske latenstid.

Nogle eksempler på mikropayment-netværk i økosystemet inkluderer Raiden Network og Lightning Network.

sharding

Konceptet bag afskærmning er, at den samlede tilstand af blockchain er opdelt i forskellige "skår", og hver del af staten gemmes og behandles af forskellige noder i netværket. Hver afskærmning behandler kun en lille del af staten og gør det parallelt. Blockchain-afskærmning svarer til afskærmning i den traditionelle databaseverden, bortset fra med den ekstra hårde udfordring at skulle opretholde sikkerhed og ægthed blandt et decentraliseret sæt noder.

Off-chain beregninger

Dette ligner statskanaler med undtagelse af større omfang. Tanken er at udføre beregninger (og ikke kun tokenoverførsler) off-chain, som ellers ville være uoverkommeligt dyrt at udføre on-chain på en måde, der er sikker og verificerbar. At flytte beregningerne og verificeringsprocessen fra blockchain til en separat protokol kan opnå høj transaktionstrøm. Et eksempel på dette for Ethereum er TrueBit.

DAG'er

En "DAG", der er forkortet med Directed Acyclic Graph, er en grafdatastruktur, der har vertices og kanter. (Et toppunkt er et punkt på grafen, og en kant er stien fra det ene toppunkt til det andet.) DAG-garanti, at der ikke er nogen måde at starte på noget toppunkt og følge en række af kanter, der til sidst løber tilbage til det toppunkt igen ( dvs. ingen sløjfer). Dette tillader os at have en sekvens af knuder (eller vertikater) i topologisk rækkefølge.

DAG

Den forudsætning bag DAG-baserede protokoller, som f.eks. IOTA's Tangle, er at grøfte den globale lineære blockchain helt og i stedet bruge DAG-datastrukturer til at opretholde systemets tilstand. For at sikre netværket er disse protokoller afhængige af deres egne nye tilgange, som ikke kræver enhver knude til at behandle hver transaktion på en lineær måde.

En anden DAG-baseret tilgang, SPECTER-protokol, bruger f.eks. Direct Acyclic Graph (DAG) af blokke og miner DAG-blokke parallelt for at muliggøre mere gennemstrømning og højere transaktionstider.

Jeg håber at skrive mere om DAG-baseret tilgang i fremtidige stillinger; virkeligheden er, at disse protokoller, stadig i meget tidlige dage, endnu ikke er implementeret og brugt i skala. Helt ærligt har de nogle grundlæggende begrænsninger / svagheder, som endnu ikke skal behandles for at betragtes som levedygtige skalerbare løsninger.

For en mere detaljeret oversigt over disse skalerbarhedsløsninger såvel som et par andre, foreslår jeg, at du læser det indlæg, jeg skrev før, om skalerbarhed.

2. Begrænset privatliv

I betragtning af at blockchain-transaktioner ikke er bundet direkte til din identitet, kan de forekomme mere private. Enhver i verden kan oprette en ny tegnebog anonymt og handle med den.

Dog er det ikke så enkelt.

På den ene side er det bestemt rigtigt, at det store løfte om denne teknologi er pseudonymitet: transaktioner registreres og gemmes i en offentlig hovedbog, men de er knyttet til en kontoadresse, der udelukkende består af tal og bogstaver. Uden identitet i den virkelige verden knyttet til denne adresse synes transaktionens ophavsmand umulig at spore.

Imidlertid er dette udseende af total sikkerhed vildledende. Det er sandt, at en person kan bevare sit privatliv, så længe pseudonymet ikke er knyttet til personen, men så snart nogen opretter forbindelse, afsløres hemmeligheden. Et eksempel på en sådan begivenhed blev afsløret, da de retshåndhævende myndigheder indrømmede, at de var i stand til at identificere specifikke Bitcoin-brugere under undersøgelser, således at 'deanonymisere' dem og bryde med den overordnede forudsætning for en blockchains samlede transaktionsmæssige usynlighed.

Hvordan blev dette opnået?

Websporere og cookies på købmandswebsteder gør det utroligt nemt at lække oplysninger om en transaktion på Internettet, hvor enhver, inklusive regeringer, retshåndhævelsesbureauer og ondsindede brugere let kan bruge disse oplysninger.

Desuden interagerer brugerne med en blockchain-platform som Ethereum med smarte kontrakter, der håndterer mere end blot enkle værdioverførsler. Alle detaljer om disse smarte kontrakter er offentlige på Ethereum blockchain, herunder afsendere og modtagere, selve transaktionsdata, den udførte kode og den tilstand, der er gemt i kontrakten.

Upload af kritiske forretningsdata til en blockchain, hvor hackere, konkurrenter eller andre uautoriserede parter kan se oplysningerne, er simpelthen ikke en mulighed for de fleste virksomheder. Overveje:

  • Elektroniske medicinske poster, som er ekstremt private og følsomme oplysninger. Det er uacceptabelt at nogensinde have disse oplysninger offentligt synlige på offentlige blockchains og derved bringe patienternes fortrolighed i fare.
  • Data til identitetsbekræftelse, såsom sociale sikkerhedsnumre, kan ikke åbnes direkte i en offentlig smart kontrakt.
  • Tilladelsesstyring såsom adgangskoder og nøgler har ingen plads i en åben, i sidste ende usikret smart kontrakt.
  • Finansielle dokumenter såsom e-aktiveringsborde eller lønninger til medarbejdere skal aldrig være offentligt tilknyttet adresser, der let kan spores.
  • Listen fortsætter.

Privatliv er fortsat en grundlæggende hindring for enkeltpersoner, organisationer og brancher, der er interesseret i privatlivets fred og individuelle suverænitet. Mange af os, der er besat af blockchain og cryptocurrency, har en samordnet interesseret i at muliggøre et tillidsløst og censurbestandigt system, der bringer økonomisk styrkelse til den enkelte. Paradoksalt nok bruger vi en offentlig, let sporbar hovedbog til at gøre det. (Får hovedet til at gå sidelæns, når jeg tænker over det!)

Privatlivsløsninger

Her er et par eksempler på løsninger, som forskellige udviklingshold har arbejdet med.

Elliptisk kurve Diffie-Hellman-Merkle (ECDHM) adresser

For at forstå ECDHM-adresser skal du forstå Diffie-Hellman Key Exchange. Ideen bag en Diffie-Hellman Key Exchange er, at det skaber en delt hemmelighed mellem to parter. Dette kan derefter bruges til at udveksle beskeder privat via et offentligt netværk.

Hvordan?

Afsender og modtager kan dele ECDHM-adresser offentligt og derefter bruge deres delte hemmelighed til at udlede anonyme Bitcoin-adresser. Disse Bitcoin-adresser kan kun afsløres af dem, der er i besiddelse af hemmeligheden. Det eneste, der er offentligt synligt, er de genanvendelige ECDHM-adresser. Derfor behøver en bruger ikke at bekymre sig om transaktioner, der spores.

Konceptuelt diagram, der illustrerer den generelle idé om nøgleudvekslingen ved hjælp af farver i stedet for meget store tal (Kilde: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)

Nogle eksempler på ECDHM-adresseskemaer inkluderer Stealth-adresser af Peter Todd, BIP47-genanvendelige betalingskoder af Justus Ranvier, BIP75 Bortadresseudveksling af Justin Newton og andre. Arbejdsmæssige implementeringer og faktisk brug af disse sådanne ordninger er dog knap.

Blandere

Tanken bag en mixer er, at en gruppe mennesker kan kombinere deres betalinger i en pulje og holde styr på gæld i en privat hovedbok. Når midler fra poolen bruges, skjules oprindelsen af ​​hver betaling. Enhver, der observerer blockchain, kan se de betalte beløb sammen med modtagerne, men teoretisk set kan den person, der specifikt har godkendt betalingen, ikke spores. Et eksempel på en blandingstjeneste er CoinJoin.

Kilde: https://en.wikipedia.org/wiki/CoinJoin

Desværre har blandere vist sig at være en upålidelig løsning. For eksempel kunne forskere let identificere CoinJoin-transaktioner og beviste, at en angriber ved at bruge bare $ 32.000 kan unanonymisere transaktioner med 90% succes. Desuden beviste forskere også, at mixere giver lidt beskyttelse mod Sybil-angreb og Denial-of-Service-angreb.

Endnu mere foruroligende er det faktum, at et mixers påstås private hovedbog skal styres af en eller anden central enhed, hvilket betyder, at det kræver en betroet tredjepart at "blande" transaktioner.

Da CoinJoin er en løsning, som brugerne vælger at bruge snarere end en standardmetodologi, har meget få mennesker historisk set været involveret i disse typer blandebasere, hvilket gør anonymiteten sat for lille. Derfor er det let at identificere, om en bestemt output stammer fra en af ​​de få mennesker.

Et andet eksempel på en blandingsløsning er CoinShuffle, som er en decentral blandingsprotokol udviklet af en gruppe forskere ved Saarland Universitet i Tyskland. CoinShuffle forsøgte at forbedre CoinJoin ved ikke at kræve en betroet tredjepart til at samle mixetransaktionerne.

Monero

En anden måde at tackle privatlivets fred er at oprette et cryptocurrency, der som standard er privat, såsom Monero. I modsætning til mange altcoins er Monero ikke en gaffel med Bitcoin. I stedet er Monero baseret på en alternativ protokol, CryptoNote.

Den primære funktion, som Monero tilbyder, er et alternativt "ringsignatur" -skema.

Ringsignaturer er en type gruppesignatur, og hver underskriver i gruppen har en hemmelig og offentlig nøgle. I modsætning til traditionelle kryptografiske underskrifter, der beviser, at en transaktion blev "godkendt" af en enkelt underskriver ved hjælp af en nævnt privat nøgle, beviser en gruppesignatur, at en underskriver fra en fast gruppe godkendte en transaktion uden at afsløre, hvem.

Nul-viden bevis

Et bevis på nul-viden er, når en prover overbeviser en verifikator om, at de har en vis hemmelig viden, uden at afsløre viden direkte. Med andre ord kan et program have hemmelige input, og prover afslører intet for verifikatoren. Nul-viden bevis giver grundlæggende primitiver, der kan bruges til at opbygge mekanismer til bevarelse af privatlivets fred. Eksempler inkluderer:

Eksempel 1: Udfordrings- / responsspil

Inden for computersikkerhed er autentificering af udfordring-svar en familie af protokoller, hvor den ene part stiller et spørgsmål (“udfordring”), og en anden part skal give et gyldigt svar (“svar”), der skal godkendes. Dette "spil" kan bruges på blockchainen til at verificere transaktioner. Hvis en bestemt transaktion er ugyldig, kan en anden knude vælge at "ringe opmærksomhed" til ugyldigheden. Dette kræver derefter, at der leveres et verificerbart bevis, der bekræfter, at en transaktion er ugyldig. I modsat fald produceres der en "udfordring", der kræver, at transaktionens ophavsmand producerer et "svar", der viser, at transaktionen er gyldig.

Lad os se på et eksempel: Sig "Bob" har enestående adgang til en eller anden ressource (f.eks. Hans bil). Alice ønsker nu også adgang til det, så hun kan bruge det til at gå til købmanden. Bob udsender en udfordring, måske "52w72y." Alice skal svare med den ene streng med karakterer, der passer til den udfordring, Bob udstedte. Den eneste måde at finde svaret på er ved hjælp af en algoritme, der kun er kendt af Bob og Alice. Desuden udsender Bob en anden udfordring hver gang. At kende et tidligere korrekt svar giver derfor ikke Alice nogen fordel.

Udfordrings- / responsspil er allerede i brug i blockchains som Ethereum. Vi har dog brug for biblioteker og værktøjer til at gøre disse typer godkendelsesordninger meget, meget lettere at bruge.

Eksempel 2: zkSNARKs

Hvad er nøjagtigt zkSNARKs? Lad os fordele definitionen:

  • zk = nul-viden. Kræver ikke viden om oplysningerne for at bevise, at informationen findes
  • SNARK: Succinct Ikke-interaktivt adaptivt ARGUMENT for viden.
  • “Succinct” betyder et kortfattet bevis, der hurtigt kan verificeres.
  • "Ikke-interaktiv" betyder ikke, at verifikatoren skal interagere med prover. I stedet kan prover offentliggøre deres bevis på forhånd, og en verifikator kan sikre sig, at det er korrekt.
  • "Adaptivt argument for viden" betyder et bevis på viden om nogen beregning.

Mens jeg håber, at jeg en dag kan dække zkSNARKs i et indlæg, vil jeg springe over de tekniske detaljer her. zkSNARKs er en spændende og lovende privatbygningsblok med et par advarsler:

  1. SNARK'er er ressourceintensive.
  2. SNARKs tillader en bruger at bevise, at de har adgang til en hemmelighed, men brugeren holdes ansvarlig for at bevare hemmeligheden og have den tilgængelig, når det er nødvendigt.
  3. SNARKs har en installationsfase, hvor kredsløbet eller beregningen, du vil bevise, er fast. Denne fase skal ske på forhånd blandt en privat betroet gruppe af mennesker. Dette kræver ikke kun, at du har tillid til de mennesker, der forbereder opsætningen, men betyder også, at SNARK'er ikke passer godt til at køre vilkårlige beregninger, da der altid kræves en forberedelsesfase.

Eksempel 3: zkSNARKs + Zcash

Zcash er et beskyttelse af privatlivets fred cryptocurrency baseret på zk-SNARKs. Zcash har det, der kaldes ”afskærmede transaktioner”, hvor der er et anonymitetssæt, der spænder over hver brugte mønt. Afskærmede transaktioner bruger "afskærmede adresser", som kræver, at afsenderen eller modtageren genererer et nul-viden-bevis, der giver andre mulighed for at verificere en transaktions krypterede data uden at de bliver afsløret.

Zcash transaktionsdiagram

Zcash er bestemt et interessant projekt, som det er værd at holde øje med.

Eksempel 4: zkSNARKs + Ethereum

I Ethereums næste protokolopgradering, Metropolis, har udviklere mulighed for effektivt at verificere zk-SNARK'er på kæden.

Hvad kan vi gøre med et SNARK-aktiveret Ethereum? Visse kontraktvariabler kan effektivt gøres private. I stedet for at gemme de hemmelige oplysninger på kæden, kan de gemmes hos brugere, der beviser, at de overholder reglerne i kontrakten ved hjælp af SNARKs. Hver af disse brugere kræver deres egen betroede opsætning, hvilket tilføjer en smule forberedelsesomkostninger. Men når et kredsløb eksisterer, kan det bruges til så mange transaktioner, som det er nødvendigt.

Hvad du ikke kan opnå med SNARKs på Ethereum, er imidlertid autonomt privatliv, adskilt fra en bruger. Da SNARKs på Ethereum er afhængige af at en bruger opretholder den hemmelige off-chain uden den bruger, er der ingen steder at holde styr på hemmeligheden.

Eksempel 5: zkSTARK

ZK-SNARKs har en nyere, lysere fætter: ZK-STARKs, hvor 'T' står for "gennemsigtig." ZK-STARKs løser en af ​​de primære svagheder ved Zk-SNARKs: dens afhængighed af et pålideligt setup. De er også enklere, fordi de kun er afhængige af hash og informationsteori og er mere sikre mod kvantecomputere, da de ikke bruger elliptiske kurver eller eksponent for eksponent antagelser.

På trods af de fantastiske fremskridt, vi har gjort på privatlivets fred med nogle af de nul-viden-bevisbaserede tilgange, der er nævnt ovenfor, er der stadig en masse arbejde at gøre. Nul-viden bevis biblioteker skal undersøges væsentligt, kamp-testet og modnes. zkSNARK og zkSTARK skal eksperimenteres med forskellige offentlige blockchains. Zcash er nødt til at bevise anvendelsessager i skala i virkelighedsscenarier. Vi er stadig et stykke væk fra alt det.

Kode tilsløring

En anden fortrolighedsmekanisme er kodebemuskelse. Målet er at finde en måde at tilsløre et program P på, således at obfuscatoren kan producere et andet program O (P) = Q, således at P og Q returnerer den samme output, hvis de får den samme input, MEN Q afslører ingen information om internals i P. Dette giver os mulighed for at gemme private data i Q, såsom adgangskoder, personnummer osv., men stadig bruge dem inden for programmer.

Mens forskere hævder, at total obstruktion af sorte kasser er umulig, er der en svagere opfattelse af obfuscation, kendt som obskillelse obskillbarhed, som forskere siger, at det er muligt. Definitionen på en objektiv obfuscator O er at hvis du tager to ækvivalente programmer A og B (dvs. samme input til enten A eller B producerer de samme output) og beregner O (A) = P og O (B) = Q, så er der er ingen beregningsmæssig gennemførlig måde for nogen, der ikke har adgang til A eller B, til at fortælle, om P kom fra A eller B.

For nylig har forskerne Craig Gentry, Amit Sahai, et al. var i stand til at opnå utskillelig kodebemuskelse. Algoritmen leveres dog med høj beregningsmæssig overhead.

Hvis denne konstruktion kan forbedres, er de potentielle fordele enorme. Den mest interessante mulighed i verden af ​​cryptocurrency er tanken om en on-blockchain-kontrakt, der indeholder private oplysninger.

Vi kan for eksempel forestille os en Ethereum-kontrakt, der indeholder en brugers adgangskode til Coinbase. Så kan vi skrive et program sådan, at hvis visse betingelser i kontrakten er opfyldt, vil kontrakten starte en HTTPS-session med Coinbase ved hjælp af en eller anden mellemliggende knude, logge ind med brugerens adgangskode og foretage en handel. Da oplysningerne i kontrakten bliver tilsløret, er der ingen måde for mellemledsnoden eller nogen anden spiller i blockchain at ændre anmodningen under transit eller bestemme brugerens adgangskode.

orakler

I blockchain-rummet er en oracle en part, der videresender information mellem smarte kontrakter og eksterne datakilder. Det fungerer i det væsentlige som en databærer mellem smarte kontrakter på blockchain og eksterne datakilder fra blockchain. Så en tilgang til at holde information “privat” er simpelthen at bruge orkler til at hente private oplysninger fra en ekstern datakilde.

Pålidelige henrettelsesmiljøer

Trusted Execution Environment (TEE) er et sikkert område af hovedprocessoren. Det garanterer, at kode og data, der indlæses inde, er beskyttet med hensyn til fortrolighed og integritet. Dette pålidelige miljø kører parallelt med det brugervendte operativsystem, men er beregnet til at være mere privat og sikkert end det brugervendte operativsystem.

Kilde: https://www.slideshare.net/JavierGonzlez49/operating-system-support-for-runtime-security-with-a-trusted-execution-en miljø-phd-thesis

Der foregår tidligt forskning og udvikling i TEEs for at bestemme, hvordan de kan bruges til at aktivere privatlivets fred på blockchain. Jeg er personligt meget begejstret for flere sikkerhedseksperter til at tackle disse løsninger. Vi har bestemt brug for flere eksperter, der undersøger dette.

3. Manglende formel kontraktverifikation

Formel verifikation af smarte kontrakter forbliver et kæmpe uløst problem. Lad os først forstå, hvad det endda betyder at "formelt verificere" en kontrakt ved at forstå, hvad et "formelt bevis" er. Et "formelt bevis" i matematik betyder et matematisk bevis, der er blevet kontrolleret af en computer ved hjælp af grundlæggende aksiomer i matematik og primitive inferensregler.

Mere bredt er formel verifikation i relation til et softwareprogram en metode til at bestemme, om programmet opfører sig i henhold til en specifikation. Generelt gøres dette med et konkret specifikationssprog, der bruges til at beskrive, hvordan input og output af funktioner skal forholde sig. Med andre ord angiver vi først en invariant om programmet, og så er vi forpligtet til at bevise denne erklæring.

Et eksempel på et specifikationssprog er Isabelle, som er en generisk bevisassistent, der tillader, at matematiske formler udtrykkes på et formelt sprog og giver værktøjer til at bevise disse formler i en logisk beregning. Et andet specifikationssprog er Coq, som er et formelt sprog til at skrive matematiske definitioner, eksekverbare algoritmer og teoremer.

Så hvorfor er det vigtigt at foretage formel verifikation af programmer, der er kodet inden for smarte kontrakter?

For det første er smarte kontrakter uforanderlige, hvilket betyder, at du ikke kan opdatere eller rette dem, når de er blevet implementeret på det vigtigste Ethereum-netværk. Så det betyder, at vi er nødt til at få alt lige til tee, før vi kan implementere og bruge disse kontrakter i virkelige applikationer. Desuden er smarte kontrakter offentligt tilgængelige, og alt, der er gemt i smarte kontrakter, er åbent for enhver at se; enhver kan også indkalde de offentlige metoder til smarte kontrakter. Selvom dette giver åbenhed og gennemsigtighed, gør det også smarte kontrakter til meget attraktive mål for hackere.

Realiteten er, at det er vanskeligt at skrive pålidelige, smarte kontrakter, der er bugfri, uanset hvor meget forsigtighed du tager. Desuden er det med Ethereum for eksempel utroligt vanskeligt at bekræfte EVM-kode på grund af den måde EVM-instruktionerne er designet. Dette gør det endnu vanskeligere at opbygge formelle verifikationsløsninger for Ethereum. Uanset hvad, formel verifikation er en stærk tilgang til at reducere risikoen for fejl og angreb. De giver en højere garanti for rigtighed end traditionelle tilgange (f.eks. Test, peer reviews osv.), Og vi har desperat brug for bedre løsninger.

Formelle verifikationsløsninger

Jeg ville ønske, at jeg havde mere offentligt tilgængelige løsninger til at vise sig i dette afsnit, men desværre er der ikke mange. Et meget tidligt sæt eksempler, jeg fandt, blev udført af Yoichi Hirai, som er en formel verifikationsingeniør for Ethereum-stiftelsen. Han var i stand til at producere tidlige resultater til verificering af flere smarte kontrakter, herunder en lille "gerning" kontrakt. Selvom det er meget lille, er dette den første "rigtige" kontrakt, som jeg har set analyseret i et teorem, der beviser miljø.

Som Yoichi selv siger ...

”Verificeringsresultatet er langt fra perfekt. Jeg finder stadig flere problemer i verifikationsopsætningen end i de verificerede kontrakter. Implementeringen af ​​EVM (Ethereum Virtual Machine) testes ikke mod andre! Jeg offentliggør denne allerede, fordi dette projekt er et godt eksempel på mængden af ​​arbejde (og detaljeringsniveauet), der kræves for at verificere en smart kontrakt ved hjælp af den maskinassisterede logiske inferens. Hvis jeg på nuværende tidspunkt skulle implementere en smart kontrakt, der har mere end 100.000 dollars, og hvis jeg har ansvaret for tidsplanen, ville jeg overveje denne form for udvikling (den anden mulighed er at prøve kontrakten med mindre værdier først ).”

Der er andre hold som Tezos, som fuldstændigt fortæller om at bruge Solidity som sproget og EVM som VM, og i stedet bygger deres eget smarte kontraktprogrammeringssprog og VM, der letter formel verifikation.

Uanset den rigtige tilgang, hvad enten det drejer sig om at revidere EVM for at gøre det lettere at formelt verificere eller opbygge et helt nyt sprog, der i sagens natur er lettere at verificere, har vi brug for mere arbejde i denne indsats. Vi har brug for flere forskere og udviklere, der arbejder med formel verifikation. Vi har brug for formelle verifikationsbiblioteker og standarder på alle mulige programmeringssprog.

4. Opbevaringsbegrænsninger

De fleste applikationer, der bygger på en offentlig blockchain, kræver en slags opbevaringsløsning. (Brugeridentiteter, økonomiske oplysninger osv.).

Opbevaring af oplysninger i en offentlig blockchain-database betyder dog, at dataene er:

  1. Gemt af hver fuld nod i netværket.
  2. Gemt på ubestemt tid, da blockchain-databasen kun er tilføjet og uforanderlig.

Derfor medfører datalagring en enorm omkostning for et decentraliseret netværk, hvor hver fuld knudepunkt skal gemme flere og flere data i uendeligt. Som et resultat forbliver opbevaring en enorm hindring for enhver realistisk applikation, der bliver bygget på blockchain.

Opbevaringsløsninger

Der er flere tidlige projekter, der bruger forskellige strategier til opdeling af data i skår og opbevaring af dem på en distribueret måde på tværs af deltagende noder (dvs. distribueret lagring). Den grundlæggende forudsætning her er, at i stedet for at hver knude gemmer alt, er der et sæt noder, der deler eller "distribuerer" dataene imellem. Et par eksempler på projekter inkluderer:

  • Swarm: Swarm er en peer-to-peer-fildelingsprotokol til Ethereum, der giver dig mulighed for at gemme applikationskode og data fra hoved blockchain i sværmknudepunkter, der er forbundet til Ethereum blockchain. Du kan senere udveksle disse data på blockchain.
  • Storj: En løsning, hvor filer og data først shardes, krypteres og derefter distribueres til flere noder, således at hver node kun gemmer en lille del af dataene: "distribueret lagring." Så bruges Storj Coin (SCJX) til at betale til opbevaring og fungerer som et incitament til noder, der gemmer en del af brugerens filer eller data.
  • IPFS: En alternativ p2p-hypermedia-protokol, der giver en høj kapacitet, indholdsadresseret blokopbevaringsmodel med indholdsadresserede hyperlinks. I det væsentlige tillader det, at filer gemmes på en permanent og decentral måde, samtidig med at den giver historisk versionering af filer og fjerner duplikater.
  • Anstændigt: Anstændigt er en decentraliseret indholdsdelingsplatform, der giver brugerne mulighed for at uploade og tjene penge / dele deres arbejde (videoer, musik, ebøger osv.) Uden at stole på en centraliseret tredjepart. Brugere kan få adgang til indhold på en mere overkommelig måde ved at springe over disse mellemmænd, mens de noder, der er vært for indholdet, belønnes med gebyrer.
  • … og mere.

5. Uholdbare konsensusmekanismer

Blockchains er "tillidsløse". Brugere behøver ikke at stole på nogen anden med deres transaktioner. At ikke have tillid til nogen anden giver brugerne attraktive egenskaber som autonomi, censurmodstand, autenticitet og tilladelsesløs innovation.

Mekanismen, der bruges over tid for at aktivere en tillidsfri blockchain, der ikke let er undergravet af angribere, kaldes en "konsensusprotokol." Konsensusprotokoller er ikke nye for Bitcoin og andre blockchains. For eksempel skabte Dwork og Naor i 1992 et af de første "proof-of-work" -systemer, hvor man kunne generere kryptografisk bevis for beregningsudgifter for at få adgang til en ressource uden at skulle stole på tillid. Dette system blev brugt til at bekæmpe junk mail. Adam Back oprettede senere et lignende system kaldet Hashcash i 1997. Derefter i 2003, Vishnumurthy et al. brugte proof-of-work til at sikre en valuta for første gang, undtagen i dette tilfælde blev token ikke brugt som en generel valuta, men til at opretholde et peer-to-peer-filhandelssystem.

Fem år senere kom Nakamoto ud med proof-of-work som en mekanisme til at sikre et værditegn, Bitcoin. Denne underliggende konsensusmekanisme gjorde det muligt for Bitcoin at blive den første bredt vedtagne globale decentrale transaktionsbok.

Konsensus om arbejde

Proof-of-work er et skema, der består af at løse problemer, der er vanskelige at løse, men let at verificere. Gruvearbejdere foretager beregningsmæssigt dyre beregninger ved hjælp af deres beregningskraft, og Bitcoin-systemet belønner minearbejdere, der præsenterer sådanne løsninger med nye Bitcoins og transaktionsgebyrer. Jo mere computerkraft en miner har, jo mere "vægt" har de til at beslutte om konsensus.

Proof of work-work konsensus gjorde det muligt for Bitcoin at blive den første virkelig vidt udbredte form for decentral digital valuta. Det løste “dobbeltforbrugsproblemet” uden at kræve nogen tillid tredjepart. Proef-of-work er imidlertid ikke perfekt, og der er stadig meget forskning og udvikling, der kræves for at opbygge en mere levedygtig konsensusmekanisme.

Hvad er problemerne med proof-of-work?

1. Specialiseret hardware har en fordel

En ulempe med beviset for arbejde er brugen af ​​specialiseret hardware. I 2013 blev enheder kaldet ”applikationsspecifikke integrerede kredsløb” (ASIC'er) udelukkende designet med henblik på minedrift af Bitcoin, hvilket giver en stigning i effektiviteten på 10-50 gange. Lige siden er minedrift med en almindelig computers CPU og GPU blevet fuldstændig ulønnsom, og den eneste måde at miner på er med ASIC'er, som du fremstiller selv eller køber fra en ASIC-producent. Dette er langt fra den "decentrale" karakter af blockchain, hvor alle har mulighed for at bidrage til netværkets sikkerhed.

For at afhjælpe dette problem har Ethereum valgt at gøre sin PoW-algoritme (Ethhash) sekventielt hukommelseshård. Dette betyder, at algoritmen er konstrueret, så beregningen af ​​nonce kræver en masse hukommelse OG båndbredde. De store krav til hukommelse og høje båndbreddekrav gør det vanskeligt for endda en superhurtig computer at opdage flere mangler samtidig. Dette reducerer risikoen for centralisering og skaber et mere ensartet vilkår for de knudepunkter, der udfører verificeringen.

Selvfølgelig er det ikke at sige, at der aldrig nogensinde har været en ASIC for Ethereum i fremtiden. Specialiseret hardware er fortsat en enorm risiko for PoW-algoritmer.

2. Centraliseringen af ​​minepool

Konceptet bag en minepool er, at i stedet for at hver bruger udvindes alene og har en lille chance for at tjene blokbelønningen, mines de for en pulje. Puljen sender dem derefter en forholdsmæssig, konsekvent udbetaling. Problemet med minepooler er, at da de har mere "vægt" i netværket, har store minepooler mindre varians i afkastet end en enkelt bruger. Over tid begynder nogle få puljer at kontrollere størstedelen af ​​netværket, og det koncentrerede sæt puljer fortsætter med at få mere magt over tid. Lige nu ejer f.eks. De fem bedste minepooler næsten 70% af det samlede hashrat. Scary, for at sige det mildt.

3. Energiaffald

Minearbejdere bruger enorme mængder computerkraft til at køre de beregninger, der løser proof-of-work-algoritmen, men desværre har alt dette beregningsarbejde ingen værdi for samfundet. I henhold til Digiconomists Bitcoin Energy Consumption Index udgør Bitcoin's nuværende estimerede årlige elforbrug 29.05TWh, hvilket udgør 0,13% af det samlede globale elforbrug. For at give dig kontekst om, hvor meget det virkelig er, bruger Bitcoin mining nu (læse: spilder) mere elektricitet end 159 individuelle lande.

Efterhånden som offentlige blockchains som Bitcoin, der anvender proof-of-work-konsensus, fortsætter med at skalere, bliver mere energi spildt i stigende grad. Hvis målet er, at den offentlige blockchain skaleres til millioner af brugere og transaktioner, er de ikke-bæredygtige spildte energi- og beregningsomkostninger ved proof-of-work ikke befordrende for dette resultat.

Konsensusløsninger

Nyttigt bevis-of-work

En måde at løse energispildproblemet på er at få proof-of-work-funktionen til at løse noget, der samtidig er nyttigt. Forestil dig for eksempel et scenarie, hvor minearbejdere bruger deres computerkraft til at løse vanskelige AI-algoritmer i stedet for at løse et tilfældigt SHA256-problem, der kræves af proof-of-work.

Proof-of-indsats

En fremgangsmåde til løsning af mineralsentraliseringsproblemet er at afskaffe minedrift fuldstændigt og flytte til en anden mekanisme til at tælle vægten af ​​hver knude i konsensus. Det er hvad bevis-of-stake sigter mod at gøre.

I stedet for at minearbejdere sætter computeren i magt, sætter de en "indsats" (dvs. penge). Som Vitalik bemærker, bliver det i stedet for "en enhed CPU-strøm, en stemme" "en valutaenhed, en stemme."

Bevis for indsats eliminerer behovet for hardware og er derfor immun over for de hårdhedscentraliseringsproblemer, der er omtalt ovenfor. Eftersom minearbejdere ikke er nødvendigt at bruge enorme mængder energi til at beregne løsninger til proof-of-work-algoritmer, er proof-of-stake i sig selv mere energieffektiv.

Som med enhver teknologi er der dog ingen gratis frokost. Proof-of-stake-algoritmer har deres egne grundlæggende udfordringer. Mere specifikt inkluderer disse:

  1. Intet-at-stake-problem: Med proof-of-stake, når der er en gaffel i kæden, uanset om gaffelen er utilsigtet eller ondsindet, er den bedste strategi for enhver knude, der validerer en transaktion, at "mine" på hver kæde . De kan gøre dette, da de ikke bruger fysisk beregningsindsats og kun stemmer med deres dollars. Dette betyder, at gruvearbejdere, der er i proof-of-stake, vil blive belønnet uanset hvilken kæde, der vinder (dvs. "intet står på spil" for at forhindre dem i at udvindes i hver kæde).
  2. Angreb med lang rækkevidde: Når der er en gaffel i proof-of-work-kæder, starter en minearbejder en gaffel et par blokke bag det aktuelle hoved af hovedkæden. Jo længere tilbage en miner kommer i kæden, desto vanskeligere bliver det at indhente hovedkæden, da det kræver computerkraft på over halvdelen af ​​netværket for at gøre det. Imidlertid kan en deltager med proof-of-stake starte en gaffel tusinder eller millioner af blokke tilbage, da det eneste, der kræves, er indsats eller penge. Dette betyder, at en deltager kan prøve at få nøglerne til tidligere deltagere og derefter generere millioner af blokke til en ny kæde, hvilket gør det vanskeligt for brugerne at vide, hvilken blockchain der er den “rigtige”.
  3. Karteldannelse: I et decentraliseret system, der styres af økonomiske incitamenter, er en meget reel risiko dannelse af koordineret indsats og oligopolier. Som Vlad Zamfir, en Ethereum-forsker, bemærker, ”Cryptocurrency er utroligt koncentreret. Det samme er minedrift. Oligopolistisk konkurrence er normen på mange 'virkelige' markeder. Koordinering mellem et lille antal relativt velhavende validatorer er meget lettere end koordinering mellem et stort antal relativt dårlige validatorer. Karteldannelse forventes fuldstændigt i vores sammenhæng. ”

For levedygtigt at erstatte proof-of-work med en ny konsensusmekanisme som proof-of-stake, har vi brug for en algoritme, der løser intet på spil-problemet og angrebsproblemer med lang rækkevidde uden at indføre nye samhandlingsrisici.

En god mængde fremskridt med at løse dette problem er gjort af hold som Tendermint og Ethereum. Tendermint var en af ​​de første til at tilpasse traditionel BFT-forskning til blockchains ved at opbygge en levedygtig proof-of-stake konsensusmotor til blockchains. Tendermint har imidlertid sine egne ulemper (et emne for et andet indlæg). Tilsvarende har Ethereum gjort store fremskridt med deres implementeringer af proof-of-stake, men virkeligheden er, at der ikke er noget, der kører på et live netværk i skala i dag.

I modsætning til proof-of-work er proof-of-stake uprovokeret og langt mindre forstået. At forstå de forskellige kompromisser med forskellige designs kræver yderligere forskning og eksperimentering. Som sådan er der et stærkt behov for at samarbejde om at skabe et mere effektive, hurtige og sikre konsensussystemer baseret på disse tidlige værker.

6. Manglende regeringsførelse og standarder

Det siger sig selv, at en offentlig, decentraliseret blockchain ikke har nogen central myndighed eller organisation, der træffer beslutninger. På den ene side giver dette os den drøm, vi alle er efter - et helt tillidsløst, åbent og tilladelsesløst system - på den anden side er der bogstaveligt talt ingen sikker opgraderingssti til protokollen, og ingen er ansvarlige for at indstille og opretholde standarder .

Selvom vi bestemt ønsker at holde udviklingen af ​​blockchain-teknologi så decentral som muligt, har vi stadig brug for en vis organisation blandt udviklere og andre i økosystemet for at blive enige om nye standarder, funktioner og opgraderinger. Det er uklart, hvordan du opnår dette uden at føre til mindst en vis centralisering (f.eks. Ethereum Foundation).

Den aktuelle status quo i Ethereum, for eksempel, er, at der typisk er en eller to udviklere, der leder anstrengelsen på specifikke standarder eller funktioner. Selvom dette fungerer indtil videre, har denne model mangler. For det første er det ikke effektivt - hvis udvikleren (e), der leder anstrengelsen, bliver travlt, eller glemmer at svare i et par dage eller uger, skrider fremskridtene på standarden bare uanset hvor vigtig standarden er for alle, der bygger på den offentlige blockchain. At definere en standard uden klar ledelse er kaos og gør det umuligt hurtigt at nå til enighed om rettidige spørgsmål, især når samfundet bliver større.

En anden tilgang er at lade det være helt åbent og decentraliseret. Dette har dog vist sig at være ineffektivt, hvilket fører til flere års debakler.

Der skal være en bedre måde.

Tezos er et eksempel på en offentlig blockchain, der sigter mod at skabe muligheden for at opgradere protokollen inden for protokollen ved hjælp af on-chain-regeringsførelse, selvom det stadig meget er en idé og ikke lever eller bevist.

Samlet set er Blockchain-styring et utroligt vanskeligt problem, og at finde en balance mellem centraliseret og distribueret kontrol vil være nøglen til at holde udviklingen på den rigtige vej.

7. Utilstrækkelig værktøj

Tilstrækkelig værktøj er vigtig for udviklernes job, især hvis sagde udviklere ønsker at gøre deres arbejde effektivt og effektivt. Forfærdelige værktøjer avler rædselshistorier.

Det siger sig selv, at udviklingsværktøjet, der i øjeblikket er tilgængeligt for blockchain-økosystemet, er uacceptabelt. Udvikling af en funktionel protokol eller decentral applikation på blockchain er en skræmmende opgave selv for dagens mest erfarne udviklere.

Som udvikler af soliditet og blockchain er det her, jeg personligt har fundet mangler i værktøjets økosystem:

  • En IDE, der har gode linters og alle de nødvendige plug-ins til effektiv smart kontraktudvikling og blockchain-analyse.
  • Et build-værktøj og en compiler, der er veldokumenteret og let at bruge.
  • Et installationsværktøj, der ikke sutter.
  • Teknisk dokumentation, der faktisk eksisterer eller ikke er forældet for forskellige API'er og rammer.
  • Test af rammer, der ikke er glatte. Der er et par værktøjer til Ethereum som trøffel, som er acceptabel, men flere muligheder og eksperimentering omkring testning af rammer er hårdt brug for. Jeg har set for mange smarte kontrakter gå helt uprøvede ud i naturen, mens jeg flytter millioner af dollars. Manglende test er under ingen omstændigheder acceptabel, men især ikke når der er så store mængder af penge involveret. For eksempel har de smarte BAT-token-salgskontrakter ingen testsuite, alligevel blev disse kontrakter brugt til at indsamle $ 36 millioner på 24 sekunder. Ethvert rationelt menneske ved, at hvis en kontrakt kan flytte så mange penge rundt, er den genstand for angreb.
  • Fejlsøgningsværktøjer. Hold da op. Fejlsøgning af soliditetskode er som at søge efter guld i en mørk tunnel med en blindfold på. I min forrige arbejdslinje var jeg i webudvikling, og at være i stand til at gå gennem kode linje for linje ved hjælp af en debugger var virkelig en livredder. At ikke have et sådant værktøj, eller endda et, der kommer fjernt tæt, er utroligt frustrerende og uproduktivt, når man udvikler sig i soliditet. Vi har desperat brug for værktøjer, der gør det lettere at isolere og diagnosticere problemer.
  • Logningsværktøjer. Samme som ovenfor.
  • Sikkerhedsrevision. Dette er en stor. Der er kun en bemærkelsesværdig sikkerhedsrevisionstjeneste for Ethereum, som jeg har hørt om, Open Zepplin. Mens de gør et stort arbejde for økosystemet med deres revisionstjeneste, har en branche, der samler milliarder af dollars ved hjælp af smarte kontrakter, brug for mere end en enkelt opstart. Virksomheder og ingeniører er nødt til at oprette mere avancerede værktøjer og tjenester, og flere sikkerhedseksperter er nødvendige for at hjælpe grundigt med at revidere smarte kontrakter. Den eneste gang der er nogen mærkbar opmærksomhed mod smart kontraktsikkerhed er det faktum, når angreb som de to Parity-hacks eller DAO-hack forekommer. Derefter lægges selvfølgelig skylden på de udviklere, der skrev de smarte kontrakter, eller endnu værre, på det centrale Ethereum-team. Det synes jeg er uretfærdigt. Udviklere skal ikke være ansvarlige for at vide, hvordan de udfører sikkerhedsrevisioner for deres egen kode. Det er som at bede Stephen Curry om at gøre sit eget regnskab. Det fungerer ikke sådan. Vi har desperat brug for hjælp og ekspertise fra sikkerhedsingeniører og forskere. Vi har brug for investorer for at lægge deres mund, hvor deres penge er, og finansiere bestræbelser på at gøre smarte kontrakter og blockchains mere sikre.
  • Bloker opdagelsesrejsende og analyse. For Ethereum har vi en blokfinder, der hedder Etherscan. For Bitcoin har vi opdagelsesrejsende som Blockchain.info, Blockexplorer eller Blockcypher. Disse er alle store samfundsindsats. Faktisk bruger jeg Etherscan meget. Men for at udføre enhver form for seriøs kædeanalyse er det intetsteds nær nok. Der er alle mulige interessante data, som vi kunne og bør analysere om offentlige blockchains.

8. Trussel mod databehandling

En af de truende trusler mod cryptocurrency og kryptografi er spørgsmålet om kvantecomputere.

Selvom kvantecomputere i dag stadig er lidt begrænset i, hvilke typer problemer de kan løse, vil det ikke altid være sådan. Den skræmmende sandhed er, at de mest populære algoritmer med offentlig nøgle effektivt kan brydes af en tilstrækkelig stor kvantecomputer.

Det er vigtigt, at når vi designer og bygger blockchain og den kryptografi, der ligger til grund for det, er vi nødt til at overveje, hvordan vi kan gøre disse egenskaber kvantebestandige.

Kvantesikre løsninger

Selvom jeg på ingen måde er ekspert på dette, er min meget begrænsede forståelse, at efter-kvantet kryptografiforskning i øjeblikket er fokuseret på seks forskellige tilgange: Gitterbaseret kryptografi, Multivariat kryptografi, Hash-baseret kryptografi, Kodebaseret kryptografi, Supersingular elliptic kurve isogen kryptografi og symmetriske nøglekvante resistenssystemer som AES og SNOW 3G.

Uanset den endelige løsning er opbygning af kryptografiske løsninger, der er kvantebestandige, noget, der skal være øverste af sindet.

Diverse udfordringer at huske på

  • Vi har brug for mere robuste løsninger, der er i stand til inter-blockchain-kommunikation, så flere kæder (f.eks. Bitcoin, Ethereum, Litecoin osv.) Kan kommunikere og handle med hinanden problemfrit.
  • Vi har brug for bedre nøglestyringssystemer indbygget i blockchain-værktøjet af hensyn til applikationer, der er bygget ovenpå.
  • Vi har brug for mere effektive signaturordninger og andre kryptografiske systemer, som enheder med lav ressource kan håndtere uden at ofre sikkerheden.
  • … og mere.

Konklusion

Det er uheldigt, at så meget af mindshare og finansiering omkring blockchain skubbes ind i ICO'er. I mellemtiden er nogle få forskere og udviklere desperate efter at løse disse problemer, men sultes af tilstrækkelige ressourcer.

Desværre er mange økonomisk incitamenteret til at ignorere problemerne - inklusive nogle af de mest indflydelsesrige udviklere og ledere i rummet.

Mit mål for det kommende år er at fortsætte med at:

  1. Øg opmærksomheden omkring disse spørgsmål
  2. Hæld så meget af min tid på at bidrage til disse løsninger
  3. Hjælp med at styrke andre forskere og udviklere til at gøre det samme

Uanset om det nuværende investeringsklima viser sig at være en boble eller ej, tror jeg på, at blockchain er her for at blive. Vi er bare nødt til at lægge noget albue fedt som udviklere for at slå barriererne ud, der holder det tilbage fra mainstream-brug. Og vi har brug for investorer til at søge og finansiere denne indsats.