Harmony's Networking Story

Harmonyssa emme katso vain sitä, mitä tarvitaan, jotta työ saadaan tänään aikaan - haluamme rakentaa jotain, joka saa työnsä tekemään jopa vuosien päästä. Tämä koskee kaikkia tekniikkapinojemme tasoja, ei vain korkeampia kerroksia, jotka ovat lähempänä tärkeimpiä toimituksiamme - kuten älykkäitä sopimuksia ja konsensusta -, mutta myös alemman tason, "arkipäivää", kuten järjestelmiä ja verkottumista, joita muut yleensä pitävät itsestään selvinä. .

Teemme tämän, koska olemme vahvasti vakuuttuneita siitä, että protokollamme ja toteutuksen keskeiset ominaisuudet eivät johdu pelkästään avainkomponenteista, vaan koko vertikaalisesta teknologiasta, joka integroituu yhteen avaimen toimittamisen mahdollistamiseksi eri tasoilla. Jos jokin teknologiakerros jättää paljon toivomisen varaa, kokonaistulos kärsii siitä. Lisäksi mitä alempi taso suboptimaalinen komponentti on, sitä leveämpi on sen räjähdyssäde, sitä suurempi on sen takaisku ja sitä vaikeampaa on kiertää ympäri tai peittää vika.

Tässä viestissä aiomme puhua yhdestä niin matalasta, mutta kriittisestä osasta: Verkottumisesta. Yritämme pitää asiat yksinkertaisina ja lähestyttävinä, joten jos olet jo kokeneempi verkostoitumisen asiantuntija, ota huomioon verkko-101-tyyliset selityksemme.

Huomaa: Nämä ovat nykyiset parhaat lähestymistapamme, mutta kuten minkä tahansa huipputeknologian edessä, tuotannon lopullinen vapauttaminen tai käyttöönotto saattaa poiketa merkittävästi siitä, mistä keskustelemme.

Suositus päästä päähän -yhteyteen

Harmonia rakentuu päästä päähän -periaatteeseen, joka suosittelee, että mahdollisimman suuri osa sovellusprotokollan avainlogiikasta työnnetään kohti loppusolmuja, jotka puhuvat keskenään. Solmut ovat itsenäisiä eivätkä käytä keskikoteloja viestien välittämiseen muille solmuille, lukuun ottamatta muutamaa tapausta. Erityisesti solmu ei lähetä yksilähetysviestiä toiselle solmulle monen hypyn reitin yli muiden solmujen overlay-verkossa.

Miksi? Koska oletamme, että solmut voivat olla vioittuneita suhteellisen suurella todennäköisyydellä: blockchain-tilassa puhumme rutiininomaisesti jopa 67%: sta tai jopa 50%: sta solmuista rehellisyydestä! Kutsutaan tätä todennäköisyyttä p. Sitten, jos viesti lähetetään toiselle solmulle h, se hyppää pois, kokonaistodennäköisyys, että unicast-viesti saavuttaa rehellisen vastaanottajan p ^ h. Yhden hypyn suoralla päästä päähän -lähetyksellä solmun todennäköisyys saavuttaa rehellinen solmu on 67% tai 50%; kahdelle humalalle, 44% tai 25%; kolmelle humalalle; 30% tai 12,5%. Todennäköisyys pienenee eksponentiaalisesti!

Yksinlähetysviestit multi-hop P2P -peittokerralla vastustajien kanssa

Poikkeuksia tähän periaatteeseen sisältyy:

  • Kun etsit muita solmuja;
  • Kun monilähetys viesti; ja
  • Kun verkkotopologian rajoitus estää suoran viestinnän lähettäjän ja vastaanottajan välillä, esim. johtuen verkkoosoitekääntäjistä (NAT) tai verkon palomuureista.

HIPv2: Id / Loc, etsintä, liikkuvuus, monisäätö, NAT-läpikulku

Päästä päähän -mallin alla on ratkaistava yksi suuri ongelma: Jos solmun A on puhuttava suoraan toiselle solmulle B ilman oletusarvon mukaista solmua, miten A voi löytää B: n ja selvittää missä B asuu? Tarkastellaan tätä ongelmaa syvemmin ja selvitetään, kuinka se ratkaistaan.

Jokaisessa verkkoyhteisössä, kuten isäntä tai solmu, on siihen liittyvä kahden tyyppinen tieto:

  • Tunniste on ainutlaatuinen tieto, joka erottaa assosioituneen yksikön muista verkon yksiköistä;
  • Paikannin on tieto, jota verkko voi käyttää ohjaamaan liikennettä liittyvään kokonaisuuteen.

Varhainen Internet koostui suhteellisen vakaista, pitkäaikaisista isäntäkohdista, joilla kullakin oli yksi staattisesti määritetty IP-osoite, joka toimi sekä isäntän tunnisteena että paikannimena, ja monet sovellusprotokollat ​​rakennettiin tämän olettamuksen mukaan yksi-yhteen kartoittamiseen. isäntien ja IP-osoitteiden välillä. Mobiili- ja monikotiverkkojen muodostuminen sekä IPv4-osoitealueen tyhjeneminen ja siitä johtuva tarve allokoida IP-osoite dynaamisesti rikkoivat tämän yksi-yhteen-oletuksen maailmanlaajuisessa Internetissä ja toivat esiin tunnisteiden erottamisen paikannimista. ja protokollalle, joka hallitsee näiden kahden välistä kartoitusta.

Päästä päähän -periaate vaatii erottamisen siitä, kuka lähettäjä / vastaanottaja ovat verrattuna mihin he ovat tavoitettavissa.

Internet Engineering Task Force -ryhmässä (IETF) on ehdotettu protokollia, kuten HIPv2, ILNP ja LISP - ei, ei toiminnallista ohjelmointikieltä - erottamaan tunniste ja paikannustila, jokaisella ehdotuksella on erilaiset ominaisuudet ja käyttötapaukset. Näistä HIPv2, tai Host Identity Protocol Version 2, on lähinnä kryptografisten julkisen ja yksityisen avainparien tunnistamien loppusolmujen käyttötapausta, joka sopii suoraan suurimman osan blockchain-tekniikoiden, mukaan lukien Harmony, solmumalliin.

Tunnistimen / paikannimen erotteluprotokollana HIPv2 tarjoaa myös tukea liikkuvuudelle ja monisijoitukselle. Liikkuvuustuki mahdollistaa olemassa olevan viestintäkanavan sitomisen ylläpitämisen kahden solmun välillä huolimatta IP-osoitteen muutoksista toisella tai molemmilla puolilla, mikä tapahtuu usein mobiilisolmuille, jotka voivat hypätä usein WiFi: n ja solutiedon välillä. Monisäätötuki mahdollistaa solmun saavuttamisen ja käytön useammassa kuin yhdessä IP-osoitteessa, mikä voi auttaa IPv4 / IPv6-kaksipinoista käyttöönottoa.

HIPv2 tarjoaa myös laajennuksen NAT-perustasolle, joka perustuu toiseen standardiraitatekniikkaan, nimeltään Interactive Connectivity Establishment, jotta useimmat NAT: n takana piilotetut solmut pystyisivät muodostamaan viestintäkanavia toisiinsa tukeen edelleen päästä päähän -periaatetta.

Harmony käyttää HIPv2: ta id / loc-, etsintä-, liikkuvuus-, monitoiminto- ja NAT-läpikulkuihin.

HIPv2 toimii kerros-3.5-protokollana ja esittelee kuljetuskerroksen pseudo-IP-osoitteilla nimeltään Host Identity Tag (HIT). Sovellukset käyttävät HIT-viestejä kommunikoidakseen keskenään, sitten HIPv2 käsittelee käännöksiä HIT: ien ja niiden taustalla olevien IP-osoitteiden välillä käyttämällä DNS- ja tapaamismekanismeja. Olemme myös kehittämässä DHT-pohjaista etsintämekanismia HIPv2: n päälle, jota käytetään pääasiassa sellaisten solmujen paikantamiseen, joita ei ole julkaistu ja jotka eivät luota mihinkään kohtaamismekanismeihin.

Isäntätunnisteet (HIT) vastaan ​​IP-osoitteet, HIPv2

HIPv2: n käyttö pitää Harmony-protokollan vähäisenä, välttäen solmun tunnisteen (julkisen avaimen) ratkaisemisen IP-osoitteiksi.

RaptorQ: Luotettava, tehokas multicast / Unicast

Nyt kun olemme ratkaisseet kuka ja missä kommunikaation ongelmat, siirrymme keskustelumme siihen ongelmaan - viesteihin itse. Tarkastellaan erityisesti näitä kahta todellista ongelmaa:

  • Kuinka torjutaan pakettipudotuksia ja korruptioita viestin toimittamiseksi luotettavasti?
  • Kuinka toimitamme luotettavasti monen vastaanottajan viestin sen N vastaanottajalle ilman, että lähettäjämme vastaa kustannuksista, jotka aiheutuvat viestien lähettämisestä N kertaa?

Ensimmäinen ongelma ratkaistaan ​​tyypillisesti sisällyttämällä protokollaan NAK-signaalit (negatiiviset kuittaukset tai ”en saanut sitä, sanoko taas?” -Signaalit). Tällä mallilla on kaksi kysymystä: 1) Tällaiset NAK: t ja tuloksena olevat uudelleenlähetykset lisäävät viiveitä lähettäjän ja vastaanottajan välisissä edestakaisissa kulkuaikoissa (RTT) ja 2) se ei ole helposti skaalattavissa, kun kyseessä on henkilöstä toiseen. monia viestejä.

Toinen ongelma ratkaistaan ​​tyypillisesti juoruttamalla: lähettämättä kullekin vastaanottajalle koko viestiä, mutta sen osaa, ja edellyttämällä, että vastaanottaja välittää kappaleen kaikille muille vastaanottajille. Tällä tavoin tällaisen viestin jakamisen kokonaiskustannukset jakautuvat tasaisesti lähettäjän ja kaikkien vastaanottajien kesken.

Koska juorumusmalli poikkeaa päästä päähän -periaatteesta, syntyy uusi ongelma: Entä jos jotkut vastaanottajat voisivat olla viallisia? Entä jos ne eivät toimi yhteistyössä ja pitävät sen sijaan vastaanotetun palat itselleen? RapidChain ehdottaa aiemman tutkimuksen innoittamana tiedon hajaantumisalgoritmia (IDA). Se käyttää Reed-Solomon-virheenkorjauksen ja Merkle-puiden yhdistelmää toteuttaakseen suuren viestin turvallisen, luotettavan monilähetyksen ainakin kaikkien yhteistyötovereiden, ellei kaikkien vertaisten keskuudessa.

Virhekorjauskoodit ovat hyödyllisiä paitsi toisessa ryhmälähetysongelmassa myös ensimmäisessä viallisessa polkuongelmassa, kuten verkkokerrosvikojen torjumisessa, kuten pakettihäviöt.

Virhekorjauskoodit voivat torjua sekä paketin menetysongelmia että kuormitetun monilähetysongelmia.

Reed-Solomon-koodilla on kuitenkin kiinteä koodinopeus, mikä vaikeuttaa satunnaisten pakettipudotusten käyttöä. Tämä tarkoittaa, että jos viestin fragmentti katoaa, lähettäjällä ei ole mitään keinoa tietää, mikä hävisi, ellei vastaanottaja kerro lähettäjälle. Jälleen sellaiset vastaanottajan ja lähettäjän väliset NAK: t ja uudelleenlähetyspyynnöt hidastavat protokollaa, etenkin korkean viiveen, matalan kaistanleveyden yhteydellä (kuten solukkoverkossa), jossa pakettipudotukset näkyvät useammin.

IP-lähetystoimiala tunnusti tämän ongelman jo varhain. Itse asiassa joissain tapauksissa käänteiskanava NAK-lähetystä varten ei ehkä ole edes käytettävissä, tai jos se on, se voi olla paljon hitaampi, esimerkiksi satelliittilähetysten yhteydessä. Joten he kiinnittivät huomionsa strategiaan, jossa yhdistettiin eteenpäin tapahtuva virheenkorjaus ja verrattomat poistotunnukset. Toisin kuin kiinteän verkon koodi, jossa virheiden palautuslohkoja voi olla vain rajallinen määrä, verrattoman poiston koodi antaa lähettäjälle mahdollisuuden luoda ääretön määrä virheen palautuslohkoja. (Tämä loputon palautuslohkojen sukupolvi antaa myös verrattomalle pyyhkimiskoodille toisen nimen: ”Fountain-koodi”.) Tämän vuoksi, kun viestin lähettäjällä ei ole vahvistusta siitä, että kaikki tarvittavat vastaanottajat - kuten yksimielisyys koorumi - vastaanottivat ja käsittelivät Viestin, sen ei tarvitse huolehtia siitä, mitkä lähettämistä paketeista menetettiin: Se voi yksinkertaisesti luoda lisää palautuslohkoja suihkulähteestä ja lähettää sen, kunnes se saa tarvittavan vahvistuksen (tai kunnes se saavuttaa protokollan aikakatkaisun, synkronisen protokollan tapauksessa).

Suihkulähdekoodi: Äärimmäisen monta kyyhkykynttiä, jotka syntyvät

Saatuaan riittävästi virheettömiä palautuslohkoja, jotka on koodattu verrattomalla pyyhkäisykoodilla, riippumatta siitä, mitkä lohkot ne ovat, vastaanottaja voi rekonstruoida alkuperäisen viestin erittäin suurella todennäköisyydellä. Rateleton pyyhintäkoodi voidaan rakentaa sanomien lukumäärän erityisellä tavoitekynnyksellä. Hyvillä rateleless-poistokoodeilla on myös ilmiö, jota kutsutaan kalliotehosteeksi, mikä tekee todennäköisyydestä palauttaa alkuperäinen viesti lähelle yhtä, kun vastaanottaja vastaanottaa virheenpalautuslohkojen tavoitekynnyksen.

Useimmat verrattomat pyyhkäisykoodit - kuten tämä, tämä, tämä ja tämä - ovat samanlaisia ​​luottaessaan koodaukseen XOR-pohjaisella kaksipuolisella kuvaajalla ja uskomuksen etenemisdekoodauksella, ja saavuttavat lähes optimaalisen koodaustehokkuuden. Näistä Harmony käyttää uusinta RaptorQ-koodia. Tämän IETF-standardoidun koodin ovat kirjoittaneet tunnetut insinöörit yrityksistä, kuten Qualcomm (hi wireless) ja Netflix (hi IPTV), mikä todistaa sen käytännöllisyyden.

Harmony käyttää RaptorQ -suihkulähdekoodia luotettavan ja kuorma-tasapainoisen viestin kuljettamiseen.

Koska n kokonaiskohtosolmua, joista k voi olla vioittunut, rakennetaan tavoitetason koodi siten, että sanoman n - k - Cp koodattujen lohkojen vastaanottaminen riittää alkuperäisen viestin palauttamiseen. (Puhumme jäljempänä Cp: stä.) Sitten lähetämme n koodattua lohkoa tämän koodin avulla, jokainen lohko jokaiselle n ikäiselle. Vertaiset haastavat koodatun lohkon, jonka he saavat muille vertaisille, samoin kuin RapidChain IDA: ssa. Olettaen, että k-solmut eivät ole yhteistyökykyisiä eivätkä juoruta niiden palautuslohkoja muille vertaisille, rehelliset solmut saavat silti n-k palautuslohkot, jotka riittävät alkuperäisen viestin rekonstruoimiseksi.

Lähetettyään n koodatun lohkon ensimmäisen purskeen lähettäjä luo satunnaisesti ylimääräisiä koodattuja lohkoja ja jakaa ne satunnaisiin vertaisiin. Suositeltava viive on puolet keskimääräisestä solmukohtaisesta edestakaisesta ajasta (RTT), joka voidaan konfiguroida joko staattisesti tai mitata dynaamisesti eksponentiaalisella taaksepäin alhaisella pohjalla. Lähettäjä voi lopettaa lisälohkojen generoinnin ja lähettämisen, kun se on vahvistanut, että kaikki tarvittavat vastaanottajat (esim. N-k: n koorumi) ovat rekonstruoineet ja käsitteelleet alkuperäisen viestin.

Pessimistin vakio Cp, pieni positiivinen kokonaisluku, käsittelee pienen, mutta nollattoman todennäköisyyden, että vastaanotettuaan koodattujen lohkojen tarkan kynnysmäärän vastaanottajat eivät voi silti rekonstruoida alkuperäistä viestiä. Se voi myös ottaa huomioon lähtötason pakettihäviön.

Lähettäjä allekirjoittaa koodatut lohkot, jotka hän generoi ja lähettää. Tätä käytetään Merkle-puun sijasta, jotta vastaanottaja voi vahvistaa lohkon ennen kuin juoruta sitä muille ikäisille. Emme käytä täällä Merkle-puuta, koska sitä on vaikea käyttää mahdollisesti rajoittamattomalle määrälle solmuja - koodattuja lohkoja puun "lähteestä" - uhraamatta sen suojausominaisuuksia.

Unicast-tapaus on samanlainen kuin multicast, paitsi:

  • Koodattujen lohkojen lukumäärää ja tavoitekoodinopeutta ei säätele konsensusparametri, vaan vain ennakoitu pakettien menetyksen määrä;
  • Kaikki koodatut lohkot lähetetään suoraan vastaanottajalle;
  • Lähettäjän ei tarvitse allekirjoittaa koodattuja lohkoja, koska alla olevassa HIPv2-kerroksessa käytetty ESP-siirto tarjoaa jo lähettäjän ja vastaanottajan välisen yksipuolisen lähetyksen eheyden suojauksen ja vastaanotettu viesti, joka on yksilähetysviesti, ei ei tarvitse välittää muille ikäisille.

UDP-kuljetus, DCCP / QUIC-innoittaman ruuhkanhallinnan avulla

Monet, elleivät useimmat, blockchain-protokollat ​​käyttävät TCP: tä kuljetukseensa. TCP: n täysin sarjoitettu, tavukeskeinen luonne kärsii kuitenkin rivin estämisongelmista ja muista ei-toivotuista suorituskyvyn haitoista. Lisäksi ymmärrämme paljon TCP: n tarjoamia etuja muilla tavoin:

  • RaptorQ: n välittämä virheenkorjaus tarjoaa jo keinon luotettavalle lähetykselle pienellä viiveellä.
  • Virheenkorjauksen lohkon uudelleenjärjestely ei ole kysymys verrattomista pyyhintäkoodeista.
  • Konsensuskerroksen protokollaviestit sisältävät jo sukupolvien merkintöjä, kuten lohkonumeroita, joten konsensuskerros voi havaita ja käsitellä protokollaviestien uudelleenjärjestelyt. HIPv2-kerrokseen upotettu ESP-datataso käsittelee HMAC: n suorittamat pakettivirheet.

Yhdessä nämä poistavat useimmiten TCP: n tarpeen. Siksi Harmony poistuu TCP: n käytöstä ja käyttää tavallista UDP: tä peruskuljetuksena HIPv2: n ja ESP: n päällä.

Harmony käyttää UDP: tä peruskuljetuksena.

Tavallisen datagrammin, kuten UDP: n käyttö jättää yhden kysymyksen edelleen avoimeksi: ruuhkien hallinta. Internet on jaettu resurssi, ja liikenteemme on multipleksoitu lukemattomien muiden verkkovirran kanssa samassa linkissä. Jos lähettäjä havaitsee, että polku määränpäähän on ruuhkainen (ja paketit putoavat), lähettäjä palaa paremmin takaisin ja hidastaa lähetysnopeutta, jotta saavutetaan hyvä läpimenoaika. Toisin sanoen tehollisen kaistanleveyden suhteen todelliseen siirtonopeuteen tulisi olla lähellä yhtä.

Ruuhkien hallinta on tärkeää myös taattaessa jaettua linkkiä. Itse asiassa RaptorQ: n perustana oleva IETF FEC Building Block -standardi edellyttää, että FEC-rakennuslohkoa käyttävässä protokollassa on käytettävä ruuhkien hallintamekanismia, jotta FEC-rakennuspalikoita käyttävä sisällönjakeluprotokolla voi pysyä hyvänä kansalaisena jättämättä roskapostia jaettu linkki tarpeettoman suuren määrän koodattuja lohkoja varten.

Ylikuormituksen hallintaa on yritetty toteuttaa tavallisissa datagrammiprotokolloissa, kuten UDP. Datagram Congestion Control Protocol (DCCP), pitkäaikainen IETF: n ehdottama standardi, tarjoaa keinot ruuhkan hallintaan. Sillä on muutama tila, nimeltään TCP-tyyppinen ja TCP-ystävällinen, joilla on erilaiset backoff-ominaisuudet. Se on toteutettu sekä Linuxissa että FreeBSD: ssä.

Toinen Googlen kehittämään ja Chromessa käyttöön otettuun UDP: hen perustuva kuljetusprotokolla QUIC ottaa ruuhkienhallinnan myös omiin käsiinsä ja toteuttaa nykyaikaisen ruuhkanhallinnan. Se tarjoaa kaistanleveyden suhteen paljon paremman toleranssin kadonneita paketteja vastaan, mutta pyrkii haittaamaan ("nälkää") TCP-istuntoja samassa linkissä.

Arvioimme aktiivisesti näitä erilaisia ​​ruuhkien hallintamenetelmiä ja käytämme todennäköisesti yhtä niistä Harmony-perusprotokollassa.

Harmony toteuttaa DCCP- tai QUIC-ruuhkanhallinnan.

johtopäätös

Tämä päättää lyhyen kiertomatkan verkkoteknologioista, joihin me perustamme Harmony-protokollamme. Monet teistä olisivat huomanneet jo nyt, että tässä yleiskatsauksessa ei esitetä uutta, kuuden sivun keksintöä, jossa on täydellinen fyysinen matemaattinen kaava tai syvällisiä perusteluja, vaan se on pikemminkin yhdistelmä olemassa olevia tekniikoita, joista osa jopa vuosikymmenen tai sitä vanhempi . Ei niin jännittävää, voidaan sanoa.

Tämä on oikea havainto, ja siihen on oikeastaan ​​syy: Me täällä Harmonyssa uskomme pragmatismiin. Uskomme seisovan jättiläisten harteilla, aivan kuten useimmat muutkin blockchain- ja konsensuspöytäkirjojen maailmassa. Käytännöllisimmän ratkaisun ei tarvitse olla uusinta. Itse asiassa se on päinvastoin.

Harmonyssa uskomme pragmatismiin ja aikaisempaan viisauteen.

Ota esimerkki Googlen datakeskuksen verkostoitumisjärjestelmästä. Se on uudenlainen sovellus, nimeltään Clos-verkko, jonka juuri ulottuu aina takaisin päiviin, jolloin puhelinverkko koostui ristikkäin viidakosta, joka koostui hankalista sähkömekaanisista kytkimistä. Kun nuo jättiläiset hirviöt putosivat suosion ulkopuolelle, samoin Clos-verkosto. Google löysi kuitenkin Clos-verkon etsiessään toteuttamiskelpoista datakeskuksen verkon suunnittelua hallitakseen valtavaa määrää itä-länsi-verkkoliikennettä; Katso ja katso, Clos-verkko elää jälleen, tällä kertaa nykyaikaisten pakettikytkentäisten verkkojen kentällä.

Internet ei ole myöskään täysin uusi asia. Sen perustamisesta lähtien 70-luvun puolivälissä on tutkittu paljon tutkimusta ja kehitystä, jotta siitä tulisi yksi viimeisen 50 vuoden menestynein innovaatio. Kaikilla näillä T & K-tuloksilla ei ollut kukoista. Jotkut eivät saaneet merkityksellistä vauhtia tai pitoa; toisten soveltaminen rajoitettiin melko kapeaan alaan. Näistä tuloksista huolimatta näiden vanhempien keksintöjen loisto, uutuus ja tyylikkyys säilyvät kuitenkin edelleen, odottaen löytämistä ihmisille, joilla on vastaavat tarpeet.

Uskomme myös Harmonyssa tähän ja pyrimme löytämään lupaavia rakennuspalikoita paitsi nykypäivän lisäksi myös Internet-tekniikoiden historiallisessa arkistossa, aivan kuten Google löysi tämän ranskalaisen puhelininsinöörin ja hänen 70-vuotisen keksintönsä .