{"id":30047,"date":"2019-10-31T21:33:25","date_gmt":"2019-10-31T18:33:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/razbiraemsya-v-protokole-konsensusa-stellar\/"},"modified":"2019-10-31T21:33:25","modified_gmt":"2019-10-31T18:33:25","slug":"razbiraemsya-v-protokole-konsensusa-stellar","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/razbiraemsya-v-protokole-konsensusa-stellar","title":{"rendered":"Vi utforsker Stellar konsensusprotokoll","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Vi
\n
\nStellar konsensusprotokoll ble f\u00f8rst beskrevet i en vitenskapelig artikkel<\/a><\/noindex> av David Mazieres i 2015. Dette er et \u00abfederativt bysantinsk avtalesystem\u00bb som lar desentraliserte datanettverk uten ledere effektivt oppn\u00e5 konsensus om en bestemt avgj\u00f8relse. Stellar betalingsnettverk bruker Stellar Consensus Protocol (SCP) for \u00e5 opprettholde en enhetlig transaksjonshistorie som alle deltakere kan se.<\/p>\n

Det antas at konsensusprotokoller er vanskelige \u00e5 forst\u00e5. SCP er enklere enn de fleste, men har fortsatt et slikt rykte \u2013 delvis p\u00e5 grunn av misforst\u00e5elsen om at \u00abfederativ avstemming\u00bb, som er temaet for den f\u00f8rste delen av den vitenskapelige artikkelen, er SCP. Men det er ikke tilfelle! Det er bare en viktig byggestein som i den andre delen av artikkelen brukes til \u00e5 lage den faktiske<\/i> Stellar konsensusprotokollen.
\n<\/a><\/noindex>
\nI denne artikkelen gir vi en kort oversikt over hva et \u00abavtalesystem\u00bb er, hva som kan gj\u00f8re det \u00abbysantinsk\u00bb, og hvorfor man skal gj\u00f8re et bysantinsk system \u00abfederativt\u00bb. Deretter forklarer vi den federative avstemningsprosessen som er beskrevet i artikkelen om SCP, og til slutt forklarer vi selve SCP-protokollen.<\/p>\n

Avtalesystemer<\/h1>\n

\nEt avtalesystem lar en gruppe deltakere komme til enighet om et emne, for eksempel hva de skal bestille til lunsj.<\/p>\n

Vi i Interstellar har implementert v\u00e5rt eget system for lunsjavtale: vi bestiller det som v\u00e5r driftsleder John sier. Dette er et enkelt og effektivt avtalesystem. Vi har alle tillit til John og tror at han hver dag vil finne noe interessant og n\u00e6ringsrikt.<\/p>\n

Men hva om John misbruker v\u00e5r tillit? Han kan ensidig beslutte at vi alle m\u00e5 bli veganere. Om en uke eller to vil vi sannsynligvis avsette ham og gi makten til Elizabeth. Men hva om hun elsker avocado med ansjos og mener at alle m\u00e5 bli slik. Makten korrumperer. Derfor er det bedre \u00e5 finne en mer demokratisk metode: en m\u00e5te \u00e5 forsikre seg om at ulike preferanser blir hensyntatt, samtidig som man sikrer et tidsbestemt og entydig resultat, slik at det ikke skjer at ingen bestiller lunsj eller at fem personer legger inn forskjellige bestillinger, eller at diskusjonen drar ut til kvelden.<\/p>\n

Det virker som en enkel l\u00f8sning: \u00e5 holde en avstemning! Men dette er et villedende inntrykk. Hvem skal samle inn stemmesedlene og rapportere resultatene? Og hvorfor skal de andre tro p\u00e5 det han sier? Kanskje kan vi f\u00f8rst<\/i> stemme p\u00e5 en leder vi stoler p\u00e5 til \u00e5 lede avstemningen \u2014 men hvem skal lede denne f\u00f8rste<\/i> avstemningen? Hva om vi ikke klarer \u00e5 bli enige om en leder? Eller hvis vi blir enige, men denne lederen sitter fast i et m\u00f8te eller blir sykemeldt?<\/p>\n

Lignende problemer oppst\u00e5r i distribuerte datasystemer. Alle deltakere eller noder m\u00e5 bli enige om en l\u00f8sning, for eksempel hvem som har ansvaret for \u00e5 oppdatere den felles filen eller plukke opp en oppgave fra behandlingsk\u00f8en. I en kryptovalutanettverk m\u00e5 nodene gjentatte ganger velge hvordan den fullstendige historien ser ut, blant flere mulige versjoner, som noen ganger kan v\u00e6re i konflikt. Denne nettverksenigheten gir mottakeren garanti for at mynten er (a) gyldig (ikke falsk) og (b) enn\u00e5 ikke brukt et annet sted. Det garanterer ogs\u00e5 at han kan bruke myntene i fremtiden, fordi den nye mottakeren vil ha de samme garantiene av de samme grunnene.<\/p>\n

Ethvert konsensus-system i et distribuert datanettverk m\u00e5 v\u00e6re robust mot feil: det m\u00e5 gi konsekvente resultater til tross for feil som langsomme forbindelser, ikke-responderende noder og feil rekkef\u00f8lge p\u00e5 meldinger. Den bysantinske<\/i> konsensus-systemet er i tillegg motstandsdyktig mot \u00abbysantinske\u00bb feil: noder som gir falsk informasjon, enten det er p\u00e5 grunn av feil eller i et bevisst fors\u00f8k p\u00e5 \u00e5 undergrave systemet eller oppn\u00e5 en fordel. \u00abBysantinsk\u00bb feiltoleranse\u00a0\u2014 evnen til \u00e5 stole p\u00e5 gruppens avgj\u00f8relse, selv n\u00e5r enkelte medlemmer av gruppen kan lyve eller p\u00e5 annen m\u00e5te ikke f\u00f8lge beslutningsprosessen\u00a0\u2014 fikk sitt navn fra liknelsen om de bysantinske generalene<\/a><\/noindex>, som pr\u00f8vde \u00e5 koordinere et angrep. En god beskrivelse<\/a><\/noindex> finnes hos Anthony Stevens.<\/p>\n

La oss vurdere kryptovaluta-eieren Alice, som m\u00e5 velge mellom \u00e5 kj\u00f8pe deilig iskrem fra Bob og betale gjelden sin til Carol. Kanskje \u00f8nsker Alice \u00e5 betale begge med samme mynt samtidig, ved \u00e5 bruke den svindelaktig. For \u00e5 gj\u00f8re dette m\u00e5 hun overbevise Bobs datamaskin om at mynten aldri har blitt betalt til Carol, og overbevise Carols datamaskin om at mynten aldri har blitt betalt til Bob. Et bysantinsk avtalesystem gj\u00f8r dette praktisk talt umulig ved \u00e5 bruke en flertallsregel kalt kvotum<\/i>. En node i et slikt nettverk nekter \u00e5 g\u00e5 over til en bestemt versjon av historien, f\u00f8r den ser at et tilstrekkelig antall likestilte noder \u2013 kvotum \u2013 er enige om \u00e5 gj\u00f8re det. N\u00e5r dette skjer, vil de danne en stor nok valgblokk til \u00e5 f\u00e5 de resterende nodene i nettverket til \u00e5 godta avgj\u00f8relsen deres. Alice kan f\u00e5 noen noder til \u00e5 lyve p\u00e5 hennes vegne, men hvis nettverket er stort nok, vil fors\u00f8ket hennes bli overvunnet av stemmen til \u00e6rlige noder.<\/p>\n

Hvor mange noder kreves for kvotum? Som minimum, flertallet, mer spesifikt, et kvalifisert flertall for \u00e5 motst\u00e5 feil og svindel. Men for \u00e5 telle flertallet, m\u00e5 man vite det totale antallet deltakere. P\u00e5 Interstellar-kontoret eller ved lokale valg er disse tallene enkle \u00e5 finne. Men hvis gruppen din er et svakt definert nettverk, hvor noder kan komme og g\u00e5 etter eget \u00f8nske uten samtykke fra et senter, da er det n\u00f8dvendig med en f\u00f8derativ<\/i> bysantinsk avtalesystem som kan identifisere kvotum ikke fra en forh\u00e5ndsbestemt liste over noder, men dynamisk, fra et stadig skiftende og uunng\u00e5elig ufullstendig snapshot av noder p\u00e5 et bestemt tidspunkt.<\/p>\n

Det kan virke umulig \u00e5 skape et kvotum sett fra \u00e9n nodes perspektiv i et stort nettverk, men det er mulig. Et slikt kvotum kan til og med garantere resultater fra desentralisert stemming. Det tekniske dokumentet SCP viser hvordan dette kan gj\u00f8res ved hjelp av en prosedyre kalt f\u00f8derativ stemming<\/i>.<\/p>\n

For de ut\u00e5lmodige<\/h1>\n

\nResten av artikkelen beskriver mer detaljert den f\u00f8derative stemmingen og Stellar-konsensusprotokollen. Hvis du ikke er interessert i detaljene, her er en generell oversikt over prosessen.<\/p>\n

    \n
  1. Noderne holder runder med f\u00f8deral afstemning om \"nominaterne\". En runde af f\u00f8deral afstemning betyder:\n