{"id":37335,"date":"2019-10-31T22:17:01","date_gmt":"2019-10-31T19:17:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kot-shryodingera-bez-korobki-problema-konsensusa-v-raspredelyonnyh-sistemah\/"},"modified":"2019-10-31T22:17:01","modified_gmt":"2019-10-31T19:17:01","slug":"kot-shryodingera-bez-korobki-problema-konsensusa-v-raspredelyonnyh-sistemah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kot-shryodingera-bez-korobki-problema-konsensusa-v-raspredelyonnyh-sistemah","title":{"rendered":"De kat van Schr\u00f6dinger zonder doos: het consensusprobleem in gedistribueerde systemen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Stel je voor: in een kamer zitten 5 katten opgesloten, en om hun eigenaar wakker te maken, moeten ze het samen eens worden, want de deur kunnen ze alleen openen als ze met z'n vijven erop springen. Maar als een van de katten Schr\u00f6dingers kat is, en de andere katten weten niet van zijn besluit, dan rijst de vraag: \"Hoe kunnen ze dit doen?\" <\/p>\n

In dit artikel leg ik in eenvoudige bewoordingen uit wat de theoretische basis is van gedistribueerde systemen en hoe ze werken. Ik zal ook oppervlakkig de hoofdgedachte bespreken die ten grondslag ligt aan Paxos. <\/p>\n

\"De
\n<\/a><\/noindex>
\nWanneer ontwikkelaars gebruik maken van cloudinfrastructuren, verschillende databases en werken in clusters van veel knooppunten, zijn ze ervan overtuigd dat de gegevens intact, veilig en altijd beschikbaar zullen zijn. Maar waar komen die garanties vandaan?<\/p>\n

In wezen zijn de garanties die we hebben de garanties van de leverancier. Deze worden in de documentatie als volgt beschreven: \"Deze service is betrouwbaar genoeg, hij heeft een bepaalde SLA, maak je geen zorgen, alles werkt gedistribueerd zoals je verwacht.\" <\/p>\n

We zijn geneigd het beste te geloven, want slimme mannen van grote bedrijven hebben ons verzekerd dat alles goed zal komen. We stellen ons niet de vraag: waarom zou dit eigenlijk kunnen werken? Is er een formele rechtvaardiging voor de correctheid van zulke systemen?<\/p>\n

Onlangs heb ik een bezoek gebracht aan een school voor gedistribueerde berekeningen<\/a><\/noindex> , en ik raakte sterk ge\u00efnspireerd door dit onderwerp. De lezingen op de school leken meer op lessen wiskundige analyse dan op iets wat met computersystemen te maken heeft. Maar zo werden vroeger de belangrijkste algoritmes bewezen die we elke dag gebruiken, vaak zonder het zelf te beseffen. <\/p>\n

In de meeste moderne gedistribueerde systemen wordt het consensusalgoritme Paxos en zijn verschillende modificaties gebruikt. Het meest interessante is dat de geldigheid en zelfs de mogelijkheid van dit algoritme eenvoudig met pen en papier kan worden bewezen. In de praktijk wordt het algoritme toegepast in grote systemen die draaien op een enorm aantal knooppunten in de cloud. <\/p>\n

Een lichte illustratie van waar het verder over zal gaan: het probleem van twee generaals<\/b>Laten we voor de warming-up het probleem van twee generaals bespreken<\/a><\/noindex>. <\/p>\n

We hebben twee legers - een rode en een witte. De witte troepen zijn gelegerd in de belegerde stad. De rode troepen onder leiding van de generaals A1 en A2 bevinden zich aan weerszijden van de stad. De taak van de roden is om de witte stad aan te vallen en te overwinnen. Echter, het leger van elke rode generaal is afzonderlijk kleiner dan het leger van de witte.<\/p>\n

\"De
\n
\nDe voorwaarden voor overwinning voor de roden: beide generaals moeten tegelijkertijd aanvallen om een numeriek voordeel tegenover de witte te hebben. Hiervoor moeten generaal A1 en A2 met elkaar afspreken. Als elke generaal afzonderlijk aanvalt, zullen de roden verliezen. <\/p>\n

Om te overleggen kunnen generaals A1 en A2 boodschappen naar elkaar sturen via het gebied van de witte stad. Een boodschapper kan succesvol de bondgenootgeneraal bereiken, of kan door de tegenstander worden onderschept. De vraag is: is er een zodanige volgorde van communicatie tussen de rode generaals (de volgorde van het verzenden van boodschappers van A1 naar A2 en vice versa van A2 naar A1), waarbij ze gegarandeerd overeenkomen over een aanval op tijdstip X. Hierbij betekent 'gegarandeerd' dat beide generaals ondubbelzinnig bevestiging hebben dat de bondgenoot (de andere generaal) exact op tijdstip X zal aanvallen.<\/p>\n

Stel je voor dat A1 een boodschapper naar A2 stuurt met de boodschap: 'Laten we vandaag om middernacht aanvallen!'. Generaal A1 kan niet aanvallen zonder bevestiging van generaal A2. Als de boodschapper van A1 is aangekomen, stuurt generaal A2 een bevestiging met de boodschap: 'Ja, laten we vandaag de witte verslaan'. Maar nu weet generaal A2 niet of zijn boodschapper is aangekomen of niet, hij heeft geen garanties dat de aanval gelijktijdig zal zijn. Nu heeft generaal A2 weer een bevestiging nodig.<\/p>\n

Als we hun communicatie verder uiteenzetten, blijkt het volgende: hoe vaak ze ook berichten uitwisselen, er is geen manier om beide generaals gegarandeerd te informeren dat hun berichten zijn ontvangen (ervan uitgaande dat elke boodschapper kan worden onderschept).<\/p>\n

De taak van de twee generaals is een uitstekende illustratie van een zeer eenvoudig gedistribueerd systeem, waar twee knooppunten zijn met onbetrouwbare communicatie. Dat betekent dat we geen 100% garantie hebben dat ze zich zullen synchroniseren. Over dit soort problemen in een groter formaat wordt verderop in het artikel gesproken.<\/p>\n

We introduceren het concept van gedistribueerde systemen<\/h2>\n

\nEen gedistribueerd systeem is een groep computers (hierna knooppunten genoemd) die met elkaar kunnen communiceren. Elk afzonderlijk knooppunt is een autonome entiteit. Een knooppunt kan taken zelfstandig verwerken, maar om met andere knooppunten te communiceren, moet het berichten verzenden en ontvangen. <\/p>\n

Hoe berichten precies zijn ge\u00efmplementeerd en welke protocollen worden gebruikt, is in deze context niet relevant. Belangrijk is dat knooppunten in een gedistribueerd systeem gegevens kunnen uitwisselen door berichten te verzenden.<\/p>\n

De definitie lijkt niet zo ingewikkeld, maar we moeten rekening houden met een aantal kenmerken van een gedistribueerd systeem die belangrijk voor ons zullen zijn.<\/p>\n

Kenmerken van gedistribueerde systemen<\/h4>\n

<\/p>\n

    \n
  1. Gelijktijdigheid<\/b> \u2013 de mogelijkheid van gelijktijdige of concurrerende gebeurtenissen in het systeem. Bovendien beschouwen we gebeurtenissen die op twee verschillende knooppunten plaatsvinden als potentieel concurrerend, totdat we een duidelijke volgorde van deze gebeurtenissen hebben. En over het algemeen hebben we die niet.<\/li>\n
  2. Het ontbreken van globale klokken<\/b>. We hebben geen duidelijke volgorde van gebeurtenissen vanwege het ontbreken van globale klokken. In de gewone mensenwereld zijn we eraan gewend dat we klokken en een absolute tijd hebben. Alles verandert wanneer we het over gedistribueerde systemen hebben. Zelfs de meest nauwkeurige atoomklokken hebben drift, en er kunnen situaties zijn waarin we niet kunnen zeggen welk van de twee gebeurtenissen eerder heeft plaatsgevonden. Daarom kunnen we ook niet op de tijd vertrouwen.<\/li>\n
  3. Onafhankelijke storingen van de knooppunten van het systeem<\/b>. Er is nog een probleem: er kan iets misgaan eenvoudigweg omdat onze knooppunten niet eeuwig meegaan. Een harde schijf kan falen, een virtuele machine in de cloud kan opnieuw opstarten, het netwerk kan even uitvallen en berichten kunnen verloren gaan. Bovendien zijn er situaties waarin knooppunten functioneren, maar tegelijk tegen het systeem werken. Deze laatste klasse van problemen heeft zelfs een aparte naam gekregen: het probleem van de Byzantijnse generaals<\/a><\/noindex>. Het meest populaire voorbeeld van een gedistribueerd systeem met dit probleem is Blockchain. Maar vandaag zullen we deze specifieke klasse van problemen niet bespreken. We zijn ge\u00efnteresseerd in situaties waarin simpelweg \u00e9\u00e9n of meerdere knooppunten kunnen falen.<\/li>\n
  4. Communicatiemodellen (berichtenuitwisselingsmodellen) tussen knooppunten<\/b>We have already established that nodes communicate by exchanging messages. There are two known message exchange models: synchronous and asynchronous.<\/li>\n<\/ol>\n

    <\/p>\n

    Communication models between nodes in distributed systems<\/h4>\n

    \nSynchronous model<\/b> \u2013 we know for certain that there is a finite known delta time during which a message is guaranteed to reach from one node to another. If this time expires and the message has not arrived, we can confidently say that the node has failed. In this model, we have a predictable waiting time. <\/p>\n

    Asynchronous model<\/b> \u2013 in asynchronous models, we assume that the waiting time is finite, but there is no delta time after which we can guarantee that the node has failed. That is, the waiting time for a message from a node can be arbitrarily long. This is an important definition, and we will discuss it further. <\/p>\n

    The concept of consensus in distributed systems<\/h2>\n

    \nBefore we formally define the concept of consensus, let\u2019s consider an example of a situation where it is needed, namely \u2013 State Machine Replication<\/b>. <\/p>\n

    We have a certain distributed log. We would like it to be consistent and contain identical data on all nodes of the distributed system. When one of the nodes learns a new value that it intends to write to the log, its task becomes to propose this value to all other nodes so that the log is updated on all nodes and the system transitions to a new consistent state. It is important that the nodes agree with each other: all nodes must agree that the proposed new value is correct, all nodes accept this value, and only then can everyone write the new value to the log. <\/p>\n

    In other words: none of the nodes objected that they have more up-to-date information, and that the proposed value is incorrect. The agreement between the nodes and the consensus on a single correct accepted value is what consensus in a distributed system is all about. We will further discuss algorithms that allow a distributed system to reliably achieve consensus.
    \n\"De
    \nFormeel kunnen we een consensusalgoritme (of simpelweg een consensusalgoritme) defini\u00ebren als een functie die een gedistribueerd systeem van toestand A naar toestand B omzet. Deze toestand wordt aanvaard door alle knooppunten, en alle knooppunten kunnen deze bevestigen. Het blijkt dat deze taak helemaal niet zo triviaal is als het op het eerste gezicht lijkt.<\/p>\n

    Eigenschappen van het consensusalgoritme<\/h4>\n

    \nEen consensusalgoritme moet over drie eigenschappen beschikken, zodat het systeem blijft bestaan en vooruitgang boekt bij de overgang van de ene toestand naar de andere:<\/p>\n

      \n
    1. Overeenstemming <\/b> \u2013 alle correct werkende knooppunten moeten dezelfde waarde accepteren (in artikelen wordt deze eigenschap ook als veiligheidskenmerk aangeduid). Alle knooppunten die momenteel functioneren (niet zijn uitgevallen en geen verbinding hebben verloren met anderen) moeten overeenstemming bereiken en een bepaalde definitieve gemeenschappelijke waarde accepteren.\n

      Hier is het belangrijk te begrijpen dat de knooppunten in het gedistribueerde systeem dat we beschouwen willen overeenkomen. Met andere woorden, we hebben het over systemen waarin iets kan falen (bijvoorbeeld kan een knooppunt falen), maar in dit systeem zijn er zeker geen knooppunten die opzettelijk tegen anderen werken (het probleem van de Byzantijnse generaals). Dankzij deze eigenschap blijft het systeem consistent.<\/li>\n

    2. Integriteit <\/b> \u2014 als alle correct werkende knooppunten dezelfde waarde voorstellen v<\/b>, dan moet elk correct werkend knooppunt deze waarde accepteren v<\/b>. <\/li>\n
    3. Be\u00ebindiging <\/b>\u2013 alle correct werkende knooppunten moeten uiteindelijk een bepaalde waarde accepteren (levendigheidseigenschap), wat het algoritme in staat stelt vooruitgang te boeken in het systeem. Elk afzonderlijk correct werkend knooppunt moet vroeg of laat de definitieve waarde accepteren en bevestigen: 'Voor mij is deze waarde waar, ik ben het eens met het hele systeem.'<\/li>\n<\/ol>\n

      <\/p>\n

      Voorbeeld van het consensusalgoritme<\/h4>\n

      \nTerwijl de eigenschappen van het algoritme mogelijk nog niet helemaal duidelijk zijn, zullen we een eenvoudig voorbeeld geven van de stadia die het eenvoudigste consensusalgoritme doorloopt in een systeem met een synchrone berichtenuitwisselingsmodel, waarbij alle knooppunten correct functioneren, berichten niet verloren gaan en er niets stuk is (gebeurt dat echt?).<\/p>\n

        \n
      1. Alles begint met een voorstel van de hand en het hart (Propose). Stel je voor dat een klant is aangesloten op de node genaamd 'Node 1' en een transactie begint door een nieuwe waarde door te geven - O. Vanaf dat moment zullen we 'Node 1' noemen voorsteller<\/b>. Als voorsteller moet 'Node 1' nu het hele systeem informeren dat hij verse data heeft, en hij stuurt berichten naar alle andere nodes: 'Kijk! Ik heb de waarde 'O' gekregen en ik wil deze opslaan! Bevestig alstublieft dat jullie ook 'O' in jullie logboek willen opslaan.'\n

        \"De<\/li>\n

      2. De volgende fase is de stemming over de voorgestelde waarde (Voting). Wat is het doel hiervan? Het kan voorkomen dat andere nodes recentere informatie hebben ontvangen, en dat zij gegevens hebben over dezelfde transactie.\n

        \"De
        \n
        \nWanneer node 'Node 1' zijn voorstel verzendt, controleren de andere nodes de gegevens over dit evenement in hun logboeken. Als er geen tegenstrijdigheden zijn, verklaren de nodes: 'Ja, ik heb geen andere gegevens over dit evenement. De waarde 'O' is de meest recente informatie die we hebben verkregen.' <\/p>\n

        In elk ander geval kunnen de nodes 'Node 1' antwoorden: 'Luister! Ik heb recentere gegevens over deze transactie. Niet 'O', maar iets beters.'<\/p>\n

        In de stemfase komen de nodes tot een beslissing: ofwel accepteren ze allemaal dezelfde waarde, ofwel stemt iemand tegen en geeft aan dat hij recentere gegevens heeft. <\/li>\n

      3. Als de stemronde succesvol is verlopen en iedereen 'voor' heeft gestemd, gaat het systeem naar de volgende fase - het accepteren van de waarde (Accept). 'Node 1' verzamelt alle antwoorden van de andere nodes en kondigt aan: 'Iedereen heeft ermee ingestemd dat de waarde 'O' is! Nu verklaar ik officieel dat 'O' onze nieuwe waarde is, de enige voor iedereen! Noteer het in je logboek, vergeet het niet. Noteer het in je log!'\n

        \"De<\/li>\n

      4. De andere nodes sturen een bevestiging (Accepted) dat ze de waarde 'O' hebben opgeslagen, omdat er in die tussentijd niets nieuws is binnengekomen (soort van tweefasige commit). Na dit belangrijke evenement beschouwen we de gedistribueerde transactie als uitgevoerd.
        \n \"De <\/li>\n<\/ol>\n

        \nDus bestaat het consensusalgoritme in de eenvoudigste vorm uit vier stappen: voorstel, stemming (voting), acceptatie (accept), bevestiging van acceptatie (accepted).<\/p>\n

        Als we op enig moment niet tot overeenstemming konden komen, gaat het algoritme opnieuw van start, rekening houdend met de informatie die de nodes zullen verstrekken die weigerden de voorgestelde waarde te bevestigen.<\/p>\n

        Consensus algoritme in een asynchroon systeem<\/h2>\n

        \nTot nu toe ging alles goed, want we spraken over een synchrone model van berichtuitwisseling. Maar we weten dat we in de moderne wereld alles gewend zijn om asynchroon te doen. Hoe werkt een dergelijk algoritme in een systeem met een asynchroon model van berichtuitwisseling, waar we aannemen dat de wachttijd voor een antwoord van een knooppunt onbeperkt kan zijn (terwijl we het eruit vallen van een knooppunt ook als een voorbeeld kunnen beschouwen waarbij een knooppunt zo lang kan antwoorden als het wil). <\/p>\n

        Nu we weten hoe het consensus algoritme in principe werkt, is er een vraag voor nieuwsgierige lezers die dit punt hebben bereikt: hoeveel knooppunten in een systeem van N knooppunten met een asynchroon model van berichtenuitwisseling kunnen er uitvallen, zodat het systeem nog steeds consensus kan bereiken?<\/p><\/blockquote>\n

        \nHet juiste antwoord en de onderbouwing zijn in de spoiler.<\/b>Het juiste antwoord: 0<\/b>. Als er zelfs maar \u00e9\u00e9n knooppunt in een asynchroon systeem uitvalt, kan het systeem geen consensus bereiken. Deze uitspraak is bewezen in de bekende FLP-theorema (1985, Fischer, Lynch, Paterson, verwijzing naar het origineel aan het einde van het artikel): 'Onmogelijk om een gedistribueerde consensus te bereiken bij het uitvallen van zelfs maar \u00e9\u00e9n knooppunt.'
        \n\"De
        \nJongens, dan hebben we een probleem, we zijn immers gewend dat alles asynchroon is. En nu dit. Hoe verder te leven? <\/p>\n

        We spraken nu over theorie, over wiskunde. Wat betekent 'consensus kan niet worden bereikt', vertaald van de wiskundige taal naar onze - technische? Het betekent dat 'het niet altijd kan worden bereikt', dat wil zeggen dat er een situatie bestaat waarin consensus niet haalbaar is. Maar wat is dat voor geval? <\/p>\n

        Dit is precies de schending van de liveness property, zoals hierboven beschreven. We hebben geen algemene overeenstemming en het systeem kan geen voortgang maken (kan niet binnen een eindige tijd worden voltooid) in het geval dat we geen antwoord van alle knooppunten hebben. Omdat we in een asynchroon systeem geen voorspelbare responstijd hebben en we niet kunnen weten of een knooppunt is uitgevallen of gewoon langzaam reageert.<\/p>\n

        Maar in de praktijk kunnen we een oplossing vinden. Laat ons algoritme een lange tijd kunnen draaien in het geval van uitval (kan potentieel oneindig blijven werken). Maar in de meeste situaties, wanneer de meeste knooppunten correct functioneren, zullen we voortgang in het systeem hebben. <\/p>\n

        In de praktijk hebben we te maken met gedeeltelijk synchrone communicatiemodellen. Gedeeltelijke synchroniteit wordt als volgt begrepen: in het algemeen hebben we een asynchrone model, maar formeel wordt er een begrip 'global stabilization time' van een bepaald moment in de tijd ge\u00efntroduceerd. <\/p>\n

        Dit moment in de tijd kan onbeperkt lang uitblijven, maar op een gegeven moment moet het komen. Een virtuele wekker gaat af en vanaf dat moment kunnen we de tijdsdelta voorspellen waarbinnen berichten aankomen. Vanaf dat moment verandert het systeem van asynchroon naar synchroon. In de praktijk hebben we te maken met dergelijke systemen. <\/p>\n

        Het Paxos-algoritme lost consensusproblemen op<\/h2>\n

        \nPaxos <\/a><\/noindex> is een familie van algoritmen die het consensusprobleem oplossen voor gedeeltelijk synchrone systemen, op voorwaarde dat sommige knooppunten kunnen falen. De auteur van Paxos is Leslie Lamport<\/a><\/noindex>. Hij stelde in 1989 een formeel bewijs voor van het bestaan en de juistheid van het algoritme voor. <\/p>\n

        Maar het bewijs bleek allesbehalve eenvoudig te zijn. De eerste publicatie verscheen pas in 1998 (33 pagina's) met een beschrijving van het algoritme. Het bleek extreem moeilijk te begrijpen, en in 2001 werd een toelichting op het artikel gepubliceerd die 14 pagina's besloeg. De omvang van de publicaties is genoemd om aan te tonen dat het consensusprobleem in werkelijkheid helemaal niet eenvoudig is, en er achter dergelijke algoritmen een enorme inspanning van de slimste mensen schuilgaat.<\/p>\n

        Het is interessant dat Leslie Lamport zelf opmerkte in zijn lezing dat er in het tweede toelichtende artikel \u00e9\u00e9n bewering, \u00e9\u00e9n regel (zonder opgave van welke), is die op verschillende manieren kan worden ge\u00efnterpreteerd. En daardoor werken veel moderne implementaties van Paxos niet helemaal correct. <\/p><\/blockquote>\n

        \nEen gedetailleerde uitleg van de werking van Paxos beslaat meer dan \u00e9\u00e9n artikel, dus ik zal proberen de kern van het algoritme heel kort over te brengen. In de linkjes aan het einde van mijn artikel vindt u materialen voor verdere verdieping in dit onderwerp.<\/p>\n

        Rollen in Paxos<\/h4>\n

        \nIn het Paxos-algoritme zijn er het begrip rollen. Laten we drie belangrijke bekijken (er zijn modificaties met extra rollen):<\/p>\n

          \n
        1. Proposers (ook de termen: leiders of co\u00f6rdinatoren kunnen worden gebruikt)<\/b>. Dit zijn de jongens die nieuwe waarden van de gebruiker leren en de rol van leider op zich nemen. Hun taak is om een ronde voor te stellen voor de nieuwe waarde en de verdere acties van de knooppunten te co\u00f6rdineren. bovendien staat Paxos in bepaalde situaties meerdere leiders toe.<\/li>\n
        2. Accepters (Stemgerechtigden)<\/b>. Dit zijn knooppunten die stemmen voor de acceptatie of afwijzing van een bepaalde waarde. Hun rol is cruciaal, omdat het juist van hen afhangt welk staatssysteem volgt na de volgende fase van het consensusalgoritme.<\/li>\n
        3. Leraren<\/b>. Knooppunten die gewoon de nieuwe geaccepteerde waarde aannemen en opschrijven wanneer de staat van het systeem verandert. Ze nemen geen beslissingen, maar ontvangen gegevens en kunnen deze aan de eindgebruiker doorgeven. <\/li>\n<\/ol>\n

          \nEen knooppunt kan verschillende rollen combineren in verschillende situaties. <\/p>\n

          Het concept van quorum<\/h4>\n

          \nWe gaan ervan uit dat we een systeem van N<\/b> knooppunten hebben. En daarvan kunnen maximaal F<\/b> knooppunten uitvallen. Als F knooppunten uitvallen, betekent dit dat er in de cluster minstens 2F + 1<\/b> acceptorknooppunten. <\/p>\n

          Dit is nodig zodat we altijd, zelfs in de slechtste situatie, 'goede', correct werkende knooppunten een meerderheid hebben. Dus F + 1<\/b> 'goede' knooppunten die het ermee eens zijn, en de finale waarde zal worden geaccepteerd. In het andere geval kan er een situatie ontstaan waarin verschillende lokale groepen verschillende waarden accepteren en niet met elkaar kunnen overleggen. Daarom hebben we een absolute meerderheid nodig om te winnen in de stemming.<\/p>\n

          Het algemene idee van het consensusalgoritme Paxos<\/h4>\n

          \nHet Paxos-algoritme omvat twee grote fasen, die op hun beurt in twee stappen zijn verdeeld:<\/p>\n

            \n
          1. Fase 1a: Voorbereiden<\/b>. In de voorbereidingsfase meldt de leider (proposer) aan alle knooppunten: \u201cWe beginnen een nieuwe stemronde. We hebben een nieuwe ronde. Het nummer van deze ronde is n. We gaan nu stemmen.\u201d Tot nu toe meldt hij alleen het begin van een nieuwe cyclus, maar geeft geen nieuwe waarde door. De taak van deze fase is om een nieuwe ronde te initi\u00ebren en iedereen zijn unieke nummer te laten weten. Het rondenummer is belangrijk, het moet een waarde zijn die groter is dan alle voorgaande stemnummers van alle eerdere leiders. Want dankzij het rondenummer zullen andere knooppunten in het systeem begrijpen hoe vers de gegevens van de leider zijn. Het is waarschijnlijk dat andere knooppunten al stemresultaten hebben van veel latere rondes en ze zullen de leider gewoon vertellen dat hij achterloopt.<\/li>\n
          2. Fase 1b: Belofte<\/b>. Wanneer de acceptorknooppunten een nieuw stemronde nummer hebben ontvangen, zijn er twee mogelijke uitkomsten: \n