Er et flerlags konsensussystem i stand til å gi nettverksresiliens til 51 prosent angrep opptil 90 prosent?

HodlX gjestepost  Send inn innlegget ditt

Nylig har vi sett flere og flere blockchain-nettverk bli offer for 51 prosent angrep. Dette angrepet er mulig fordi terskler kan være ganske lave og utgjøre litt mer enn 50 prosent av hashrate. Når en angriper overtar et nettverk, er det mange måter det kan misbrukes på. For eksempel kan angriperen utføre et dobbeltforbruk. Imidlertid er det viktigere at mens nettverket kontrolleres av ondsinnede brukere, kan ikke dets operasjoner betraktes som normale. I hovedsak gjør slike angrep blockchain inoperativ.

Dette forklarer hvorfor det er en veldig betimelig oppgave å utvikle en ny konsensus med høy motstandskraft mot 51 prosent angrep. I sin ferske artikkel, En guide til 99% feiltolerant konsensus, Vitalik Buterin foreslår en måte å øke terskelen til 51 prosent angrep fra 51 prosent av eierandelen eller hashrate til 99 prosent. Nøkkelen er introduksjonen av flere validatorer, kalt observatører, som ikke deltar i blokkgenerering. Observatører utfører ettervalidering av blockchain og kan varsle nettverket hvis det blir funnet kompromitterte blokker. For postvalidering foreslår Vitalik at 512 noder velges tilfeldig hvert 4096 sekund av den latensavhengige algoritmen.

Selv om denne tilnærmingen definitivt forbedrer nettverksbeskyttelsen, har den betydelige feil. De mest kritiske svakhetene er avhengighet av tid som kreves for konsensus, avhengighet av nettverksgjennomstrømning og tidssynkronisering mellom observatører.

Her er minimumsintervallet til D en empirisk verdi, gjennom hvilken observatører kan utveksle data riktig. Beregning av D tar høyde for dårlig internettforbindelse og prosessorkraft for observatører. Blokker betraktes som gyldige bare hvis bekreftelsestidsintervallet delt på D ikke er mindre enn antall observatører som signerte denne blokken.

Siden D-verdien er minimum av alle mulige, er det en potensiell situasjon når en blokk blir bekreftet av bare en observatør under D-intervallet. Så tid som kreves for konsensus er lineært avhengig av antall observatører. Dette setter betydelige begrensninger på skalerbarhet og desentralisering av nettverket.

Når det gjelder et begrenset antall observatører (Buterin foreslår at du bare bruker 512 observatører), er validering bare pseudo-desentralisert. Betydelige eller ubegrensede økninger i antall observatører kan føre til betydelig høyere D-tid. I så fall vil validering ta mye lengre tid eller til og med bli meningsløs.

Moderne båndbredde for kommunikasjonskanaler er fortsatt begrenset, noe som hindrer ettervalidering av store blokker. Forutsatt at transaksjonsstørrelsen er 200 byte, noe som faktisk er ganske liten og bare mulig i finansielle transaksjoner uten smarte kontrakter, og at det er 50 000 transaksjoner i en blokk (moderne blokkjeder prøver aktivt å nå det nivået), er blokkstørrelsen 10 MB. Overføring av denne datamengden i løpet av et sekund krever en 100 Mbps kanal. Trunk-kanaler er definitivt i stand til å garantere dette gjennomstrømningsnivået, men regionale forbindelser vil være mye tregere. Dette vil gjøre validering enten umulig på grunn av kravet om å få signaturer innen en angitt tidsperiode, eller pseudo-desentralisert der bare observatører med de beste koffertkanalene er valgt.

En annen svakhet er obligatorisk synkronisering av tid mellom observatører, noe som øker sårbarheten i nettverket for potensielle angrep, da ingen blockchain-nettverk bruker sikre protokoller for tidssynkronisering (for eksempel SNTP). Arbeid med usikret NTP skaper flere muligheter for usynkronisering av observatørbassenger, som senere kan sabotere validering fullstendig.

I et forsøk på å eliminere problemene som er beskrevet ovenfor og forbedre motstandsdyktigheten i nettverket fra 51 prosent angrep til 90 prosent, kan en tilnærming som benytter flere roller, gi en løsning for nettverkskonsensus. Alternativt til løsningen beskrevet av Vitalik Buterin, i dette tilfellet vil et nettverk kreve fem roller som er dynamisk tildelt noder.

På grunn av dette oppsettet krever løsning av det bysantinske feiltoleransen (BFT) problemet med å få 67 prosent eierandel på flere lag å ha kontroll over 90 prosent av eierandelen. Dessuten er motstandsdyktigheten så høy at det tar mer enn 53 prosent av eierandelen for at ondsinnede transaksjoner til og med vises.

Selv med den usannsynlige fremveksten av nettverket med 90 prosent av den eide aksjen, vil klientene begynne å avvise blokkene med tilbakevirkende kraft og slutte å stole på det kompromitterte nettverket, og effektivt splitte nettverket i to. Siden klienter som bruker nettverket er den mest verdifulle delen, har 90 prosent kontroll over innsatsen bare kontroll over det døde nettverket uten klienter, mens de resterende 10 prosent vil bli 100 prosent av myntholderne i det nye nettverket.

Nettverket bruker asynkron blokkvalidering for å eliminere avhengigheten av konsensus tid på antall validatorer. Den neste blokken begynner å genereres så snart den nåværende er generert og har fullført grunnleggende ettervalidering. Full validering skjer på forskjellige lag sammen (av verifikator, torrent, peer og klientroller). Hver gang en ondsinnet blokk identifiseres, rulles blockchain tilbake til den siste bekreftede tilstanden og gjenoppbygges fra rå transaksjoner.

Spørsmålet om potensielt dårlige internettforbindelser dempes ved å bruke BitTorrent-lignende teknologi. Data overføres over nettverket i fragmenter, noe som sikrer raskere valutakurser i regioner med lav båndbredde. Dette muliggjør datalevering til og med kunstig isolerte regioner.

Oppløsningen for tidssynkroniseringsutfordringen er todelt: intern prosesstid (i flått) brukes hvor det er mulig, og tidssynkronisering gjøres via beskyttet proprietær SNTP-protokoll.

Avslutningsvis, å presentere forskjellige roller i konsensus, som beskrevet ovenfor, er sannsynligvis den mest perspektiviske tilnærmingen i dag, og kan forhåpentligvis forbedre sikkerheten i blockchain betydelig..

Gleb Nikitin

Gleb Nikitin, teknisk leder og medstifter av #MetaHash