Harmonys netværkshistorie

Hos Harmony ser vi ikke bare på, hvad der er nødvendigt for at få gjort jobbet i dag - vi vil bygge noget, der får jobbet gjort endnu flere år fra nu. Dette gælder for alle lag i vores teknologibunke, ikke kun for de højere lag tættere på vores centrale leverancer - såsom smarte kontrakter og konsensus - men også på lavere niveau, "verdslige" områder som systemer og netværk, som andre har tendens til at tage for givet .

Vi gør dette, fordi vi har en stærk overbevisning om, at nøgleattributterne i vores protokol og implementering ikke kun drives af nøglekomponenter, men hele den vertikale stak af teknologier, der integreres sammen for at muliggøre, at nøglen leveres på forskellige niveauer. Hvis noget teknologilag overlader meget at ønske, lider det samlede resultat deraf. Desuden er det lavere niveau, hvor en suboptimal komponent befinder sig, jo bredere dens eksplosionsradius er, jo større bliver tilbagefaldet, og desto vanskeligere er det at omgå eller maske fejlen.

I dette indlæg skal vi tale om en sådan lav, men kritisk komponent: Netværk. Vi vil prøve at holde tingene enkle og mere tilgængelige, så hvis du allerede er en erfaren netværksekspert, skal du bære med vores netværk-101-stil forklaringer.

Bemærk: Dette er vores nuværende bedste tilgange, men som med enhver teknologisk front, kan det, vi ender med at frigive eller implementere i produktionen, afvige væsentligt fra det, vi skal diskutere her.

Foretrukket ende-til-ende-kommunikation

Harmony bygger på ende-til-ende-princippet, der anbefaler, at så meget af nøglelogikken i en applikationsprotokol skubbes mod slutknudepunkterne, der taler med hinanden. Noder er selvstændige og bruger ikke mellembokse til at kommunikere meddelelser til andre noder, undtagen i nogle få tilfælde. Specifikt sender en node ikke en unicast-meddelelse til en anden knude over en multi-hop-sti på et overlaynetværk af andre noder.

Hvorfor? Fordi vi antager, at knudepunkter kan være korrupte med en relativt høj sandsynlighed: I blockchain-rummet taler vi rutinemæssigt om så få som 67% eller endda 50% af knudepunkterne er ærlige! Lad os kalde denne sandsynlighed s. Hvis en besked derefter sendes til en anden knude, hopes væk, er den generelle sandsynlighed, at unicast-meddelelsen når en ærlig modtager p ^ h. For en-hop-direkte ende-til-ende transmission er sandsynligheden for, at en knude når den ærlige knude 67% eller 50%; for to humle, 44% eller 25%; til tre humle; 30% eller 12,5%. Sandsynligheden mindskes eksponentielt!

Unicast-meddelelser over multi-hop P2P-overlay med modstandere

Undtagelserne fra dette princip inkluderer:

  • Når man finder andre knudepunkter;
  • Ved multicasting af en meddelelse; og
  • Når begrænsningen i netværkstopologien forbyder direkte kommunikation mellem afsenderen og modtageren, f.eks. på grund af netværksadresseoversættere (NAT) eller netværks firewalls.

HIPv2: Id / Loc, Opdagelse, Mobilitet, Multi-homing, NAT Traversal

Under ende-til-ende-model skal et stort problem løses: Hvis knudepunkt A skal tale direkte til en anden knude B uden at have en standard gå-knude, hvordan kan A opdage B og finde ud af, hvor B bor? Lad os undersøge dette problem dybere og se, hvordan vi løser det.

Hver netværksenhed, såsom en vært eller en node, har to slags oplysninger, der er knyttet til den:

  • En identifikator er et unikt stykke information, der adskiller den tilknyttede enhed fra andre enheder på netværket;
  • En lokalisering er et stykke information, som netværket kan bruge til at dirigere trafik til den tilknyttede enhed.

Det tidlige Internet bestod af relativt stabile, langkørende værter, der hver havde en statisk tildelt IP-adresse, der fungerede både som identifikator og som vært for lokaliseringen af ​​værten, og mange applikationsprotokoller blev bygget på denne antagelse af en-til-en-kortlægning mellem værter og IP-adresser. Imidlertid bragte mobil- og flerhjemmet netværk såvel som udmattelsen af ​​IPv4-adresserum og det deraf følgende behov for at allokere IP-adresse dynamisk denne en-til-en antagelse på det globale internet og bragte behovet for adskillelse af identifikatorer fra locatorerne og til en protokol, der administrerer kortlægningen mellem de to.

Ende-til-ende-princippet kræver adskillelse af, hvem afsenderen / modtageren er kontra hvor de kan nås.

I Internet Engineering Task Force (IETF) er protokoller som HIPv2, ILNP og LISP — nej, ikke det funktionelle programmeringssprog — blevet foreslået til at adskille identifikator og lokaliseringsrum, hvert forslag med forskellige egenskaber og brugssager. Af disse kommer HIPv2 eller Host Identity Protocol version 2 det tætteste på brugen af ​​endeknudepunkter, der er identificeret af kryptografiske offentlige-private nøglepar, der direkte passer til nodemodellen for langt de fleste blockchain-teknologier, herunder Harmony.

Som en identifikator / lokaliseringsseparationsprotokol yder HIPv2 også støtte til mobilitet og multi-homing. Mobilitetssupport gør det muligt at opretholde en eksisterende kommunikationskanalbinding mellem to noder til trods for ændringer af IP-adresse på den ene eller begge sider, hvilket ofte sker for mobile noder, der ofte kan hoppe mellem WiFi og cellulære data. Multi-homing support gør det muligt for en node at være tilgængelig på og bruge mere end en IP-adresse, hvilket kan hjælpe IPv4 / IPv6 dobbeltstablet installation.

HIPv2 giver også en udvidelse til grundlæggende NAT-gennemgang, baseret på en anden standardsporsteknologi, der kaldes Interactive Connectivity Establishment, for at gøre det muligt for de fleste noder, der er skjult bag NAT, at etablere kommunikationskanaler til hinanden, hvilket yderligere understøtter vores ende til ende-princip.

Harmony bruger HIPv2 til id / loc, opdagelse, mobilitet, multihoming og NAT-gennemgang.

HIPv2 fungerer som en lag-3.5-protokol og præsenterer transportlaget med pseudo-IP-adresser kaldet Host Identity Tags (HIT'er). Programmer bruger HIT'er til at kommunikere med hinanden, derefter håndterer HIPv2 oversættelse mellem HIT'er og deres underliggende IP-adresser ved hjælp af DNS og rendezvous mekanismer. Vi udvikler også en DHT-baseret opdagelsesmekanisme øverst på HIPv2, som primært vil blive brugt til at lokalisere noder, der ikke er offentliggjort, og som ikke har tillid til nogen møtemekanismer.

Host Identity Tags (HIT'er) kontra IP-adresser, i HIPv2

Brug af HIPv2 holder Harmony-protokollen smal og undgår behovet for at løse node-id (offentlig nøgle) til IP-adresser.

RaptorQ: Pålidelig, effektiv multicast / unicast

Nu hvor vi har løst hvem og hvor problemer med kommunikation, flytter vi vores diskussion til hvad problemet - selve meddelelserne. Lad os undersøge disse to virkelige problemer:

  • Hvordan bekæmper vi pakkedråber og korruption for at kunne levere en meddelelse pålideligt?
  • Hvordan leverer vi pålideligt en meddelelse med flere modtagere til dens N-modtagere uden at dens afsender bærer omkostningerne ved at sende meddelelser N gange?

Det første problem løses typisk ved at inkorporere NAK'er (negative kvitteringer, eller "det fik jeg ikke, siger det igen?" -Signaler) i protokollen. Denne model har to problemer: 1) Sådanne NAK'er og resulterende videresendelser indfører yderligere forsinkelser i rækkefølgen af ​​rundtider (RTT) mellem afsenderen og modtageren, og 2) den er ikke let skalerbar i tilfælde af en-til- mange beskeder.

Det andet problem løses typisk ved at sladre: Sende ikke hele beskeden, men en del af den til hver modtager, og kræver, at modtageren videresender chunk til alle de andre modtagere. På denne måde fordeles de samlede omkostninger ved at ”dele” en sådan meddelelse jævnt mellem afsenderen og alle modtagere.

Da sladdermodellen afviger fra ende til ende-princippet, opstår et nyt problem: Hvad hvis nogle af modtagerne kunne være defekte? Hvad hvis de ikke samarbejder og i stedet holder den modtagne del til sig selv? RapidChain foreslår en informationsspredningsalgoritme (IDA) inspireret af tidligere forskning. Den bruger en kombination af Reed-Solomon fejlkorrektion og Merkle-træer til at implementere sikker, pålidelig multicasting af et stort budskab blandt mindst alle andelsselskaber, hvis ikke alle jævnaldrende.

Fejlkorrektionskoder er nyttige ikke kun til det andet multicast-problem, men også til det første defekte sti-problem, såsom at bekæmpe netværkslagsfejl som pakketab.

Fejlkorrektionskoder kan bekæmpe både problemer med pakttab og belastningsbalanceret multicast.

Reed-Solomon-koden har dog en fast kodefrekvens, hvilket gør det sværere at bruge til tilfældige pakningsdråber. Dette betyder, at hvis et beskedfragment går tabt, har afsenderen ingen måde at vide, hvilken der mistede, medmindre modtageren fortæller afsenderen. Igen bremser sådanne NAK'er fra modtager-til-afsender og videresendelse af anmodninger protokollen, især i forbindelse med en høj latensforbindelse med lav båndbredde (f.eks. På et mobilnetværk), hvor pakkedråber oftere ses.

IP-radiobranchen anerkendte dette problem fra tidligt. Faktisk er det i nogle tilfælde, at den omvendte kanal til NAK-transmission muligvis ikke engang er tilgængelig, eller hvis den er, kan den være meget langsommere, i tilfælde som satellitudsendelse. Så de vendte deres opmærksomhed mod en strategi, der kombinerer fremadrettet fejlkorrektion med rateless sletningskoder. I modsætning til en fast-rate-kode, hvor der kun kan være et begrænset antal fejlgendannelsesblokke, giver en ratløs sletningskode det muligt for afsenderen at generere et uendeligt antal fejlgendannelsesblokke. (Denne uendelige generation af gendannelsesblokke giver også rateless sletningskode et andet navn: "Springvandskode.") På grund af dette, når afsenderen af ​​en meddelelse ikke har bekræftelse af, at alle nødvendige modtagere - såsom et konsensus-quorum - modtog og behandlede besked, behøver det ikke at bekymre sig om, hvilken af ​​de pakker, den har sendt, gik tabt: Den kan simpelthen generere flere gendannelsesblokke fra springvand og sende den ud, indtil den modtager den nødvendige bekræftelse (eller indtil den rammer en timeout for en protokol, i tilfælde af en synkron protokol).

Springvandskode: Uendeligt mange bæreduer født ud af en

Efter at have modtaget nok fejlgendannelsesblokke, der er kodet ved hjælp af en ratløs sletningskode, uanset hvilke blokke de er, kan modtageren rekonstruere den originale meddelelse med meget stor sandsynlighed. En rateless sletningskode kan konstrueres med en specifik målgrænse for antallet af meddelelser. Gode ​​ratløse sletningskoder udviser også et fænomen kaldet klippeeffekt, hvilket gør sandsynligheden for at gendanne den originale meddelelse tæt på 1, når modtageren modtager over målgrænsen for fejlgendannelsesblokke.

De fleste rostløse sletningskoder - som dette, dette, dette og dette - ligner hinanden ved at stole på kodning ved hjælp af en XOR-baseret bipartitgrafik og afkodning af troformidling og opnå næsten optimal kodningseffektivitet. Af disse bruger Harmony den avancerede RaptorQ-kode. Denne IETF-standardiserede kode er forfatter af fremtrædende ingeniører fra virksomheder som Qualcomm (hi wireless) og Netflix (hi IPTV), som attesterer dets praktiske karakter.

Harmony bruger RaptorQ-fontænekoden til pålidelig og belastningsbalanceret meddelelsesafvikling.

I betragtning af n overordnede destinationsnoder, hvoraf k kan være korrupte, konstruerer vi en kode for en målrate, således at modtagelse af n - k - Cp kodede blokke i meddelelsen er tilstrækkelige til at gendanne den originale meddelelse. (Vi taler om Cp nedenfor.) Derefter sender vi n kodede blokke ved hjælp af denne kode, hver blok til hver af n peers. Peers sladrer den kodede blok, som de modtager til andre jævnaldrende, det samme som i RapidChain IDA. Forudsat at k-noder er usamarbejde og ikke sladder deres gendannelsesblokke til andre kammerater, vil ærlige knudepunkter stadig modtage n-k gendannelsesblokke, som er tilstrækkelige til at rekonstruere den originale meddelelse.

Efter at have sendt den indledende burst af n-kodede blokke, genererer afsenderen sporadisk yderligere kodede blokke og distribuerer dem til tilfældige peers. Den anbefalede forsinkelse er halvdelen af ​​den gennemsnitlige tur-retur tid blandt knudepunkter (RTT), som enten kan konfigureres statisk eller måles dynamisk med eksponentiel backoff med en lav base. Afsenderen kan stoppe med at generere og sende yderligere blokke, når den bekræfter, at alle de nødvendige modtagere (f.eks. N-k's quorum) har rekonstrueret og behandlet den originale meddelelse.

Pessimistkonstanten Cp, et lille positivt heltal, beskæftiger sig med den lille, men ikke-nul-sandsynlighed for, at modtagere, efter at have modtaget det nøjagtige tærskelantal kodede blokke, stadig ikke kan rekonstruere den originale meddelelse. Det kan også redegøre for det grundlæggende pakketab.

Afsenderen underskriver de kodede blokke, den genererer og sender. Dette bruges i stedet for et Merkle-træ, så en modtager kan validere blokken, inden han sladrer til andre kammerater. Vi bruger ikke et Merkle-træ her, fordi det er svært at bruge til et potentielt ubundet antal knudepunkter - kodede blokke ud af "springvandet" - i træet uden at ofre dets sikkerhedsegenskaber.

Unicast-sagen ligner multicast undtagen:

  • Antallet af kodede blokke og målkodefrekvensen styres ikke af konsensusparameteren, men kun af den forventede pakketabshastighed;
  • Alle kodede blokke sendes direkte til modtageren;
  • Kodede blokke behøver ikke underskrives af afsenderen, fordi ESP-transporten, der anvendes i det underliggende HIPv2-lag, allerede tilbyder integritetsbeskyttelse af ende-til-ende-unicast mellem afsenderen og modtageren, og den modtagne meddelelse, der er en unicast-meddelelse, gør behøver ikke videresendes til andre jævnaldrende.

UDP-transport, med DCCP / QUIC-inspireret overbelastningskontrol

Mange, hvis ikke de fleste, blockchain-protokoller bruger TCP som deres transport. Imidlertid lider TCP's fuldt serialiserede, byteorienterede karakter af hoved-på-linje-blokeringsproblemer og andre uønskede ulemper ved ydeevnen. Derudover indser vi en masse fordele, som TCP tilbyder på andre måder:

  • Fremadrettet korrektion af RaptorQ giver allerede et middel til pålidelig transmission med lidt latenstidsjitter.
  • Ombestilling af fejlkorrektionsblok er et ikke-problem i rateless sletningskoder.
  • Protokollemeddelelser om konsensuslag indeholder allerede generationsmarkører, såsom bloknumre, så ombestilling af protokolmeddelelser kan detekteres og håndteres af konsensuslaget. ESP-dataplan, der er indlejret i HIPv2-laget, håndterer pakkekorruption af HMAC.

Tilsammen undgår disse for det meste behovet for TCP. Derfor afviger Harmony fra at bruge TCP og bruger almindelig UDP som basistransport oven på HIPv2 og ESP.

Harmony bruger UDP som basistransport.

Brug af almindeligt datagram, såsom UDP, efterlader et emne stadig åben: Trængselskontrol. Internettet er en delt ressource, og vores trafik er multiplekset med utallige andre netværksstrømme på det samme link. Hvis afsenderen kan opdage, at stien til destinationen er overbelastet (og pakker bliver faldet), ville afsenderen bedre slået fra og bremse transmissionshastigheden for at opnå en god gennemsnitsøkonomi. Med andre ord skal forholdet mellem effektiv båndbredde og den faktiske transmissionshastighed være tæt på 1.

Overbelastningskontrol er også vigtig for at garantere en fair brug af et delt link. Faktisk kræver IETF FEC Building Block-standarden, der ligger til grund for RaptorQ, at en protokol, der bruger en FEC-byggesten, anvender en overbelastningskontrolmekanisme, så indholdsfordelingsprotokollen, der bruger FEC-byggesten, kan forblive en god borger ved ikke at spam delt link med et unødvendigt stort antal kodede blokke.

Der har været flere forsøg på at implementere overbelastningskontrol over almindelige datagram-protokoller såsom UDP. Datagram Congestion Control Protocol (DCCP), en lang tid IETF foreslået standard, tilbyder et middel til overbelastningskontrol. Det har et par tilstande, navngivet TCP-lignende og TCP-venlige, med forskellige backoff-egenskaber. Det implementeres i både Linux og FreeBSD.

QUIC, en anden transportprotokol baseret på UDP udviklet af Google og implementeret i Chrome, tager også overbelastningskontrol i egne hænder og implementerer en moderne overbelastningskontrol. Det tilbyder meget bedre tolerance over for tabte pakker med hensyn til båndbredde, men har en tendens til at forringe ("sulte") TCP-sessioner på det samme link.

Vi evaluerer aktivt disse forskellige fremgangsmåder med kontrol med overbelastning og vil sandsynligvis bruge en af ​​dem i Harmony-baseprotokollen.

Harmony implementerer DCCP eller QUIC overbelastningskontrol.

Konklusion

Dette afslutter en kort rundtur rundt om netværksteknologierne, som vi baserer vores Harmony-protokol på. Mange af jer ville i øjeblikket have bemærket, at denne oversigt ikke præsenterer en ny, seks siders opfindelse komplet med dekorativ matematisk formel eller dybdegående resonnement, men snarere er en kombination af eksisterende teknologier, hvoraf nogle endda et årti eller mere gamle . Ikke så spændende, kan man sige.

Det er en korrekt observation, og faktisk er der en grund: Her i Harmony tror vi på pragmatisme. Vi tror på at stå på giganters skuldre, ligesom de fleste andre i verden af ​​blockchain- og konsensusprotokoller gør. Den mest praktiske løsning behøver ikke være den mest nye. Faktisk er det helt modsat.

Hos Harmony tror vi på pragmatisme og fortidens visdom.

Tag Googles datacenter-netværksstof som eksempel. Det er en ny anvendelse af denne ting, der kaldes Clos-netværk, hvis rod strækker sig helt tilbage til de dage, hvor telefonnetværket bestod af en tværgående jungel af klodsede elektromekaniske kontakter. Da disse gigantiske monstrositeter faldt ud af fordel, gjorde Clos netværk også. Google genopdagede imidlertid Clos-netværket, da det ledte efter et levedygtigt datacenter-netværksdesign for at håndtere en enorm mængde øst-vest-netværkstrafik; se og se, Clos-netværket lever igen, denne gang inden for moderne, pakkekoblede netværk.

Internettet er heller ikke ligefrem en "ny ting". Siden starten i midten af ​​70'erne har der været en masse forskning og udvikling til det for at gøre det til en af ​​de mest succesrige innovationer i de sidste 50 år. Ikke alle disse F & U-resultater oplevede deres storhedstid. Nogle kunne ikke få meningsfuld fart eller trækkraft; andre havde deres anvendelse begrænset til et temmelig smalt felt. På trods af disse resultater er der dog fortsat glæde, nyhed og elegance ved disse ældre opfindelser, og venter på at blive opdaget af mennesker med matchende behov.

Hos Harmony tror vi også på dette og sigter mod at finde lovende byggeklodser - ikke kun i nutiden, men også i det historiske arkiv for internetteknologier, ligesom Google opdagede denne franske telefoningeniør og hans 70-årige opfindelse .