Shimmer

MODUL 4.1

Das Shimmer-Voting-System ist nach einem außergewöhnlichen Verhalten in der Natur benannt. Bienen “synchronisieren” ihre Bewegung, um sich gegen Raubtiere zu wehren. Sie tun dies ohne jede zentralisierte Einheit und wissen nur, wann sie ihren Zustand “ändern” müssen, indem sie das Verhalten ihrer Artgenossen in unmittelbarer Nähe beobachten.

Einzelne autonome Agenten, die nach vordefinierten Regeln handeln, finden sich in vielen Systemen der Natur, beispielsweise bei Bienen, Ameisen, Fischschwärme und sogar in einigen Bereichen der Physik. Sehr einfache Regeln können unglaublich komplexe Funktionen erzeugen, die sich im Laufe der Zeit als sich entwickelnde Eigenschaften eines Systems manifestieren. Der Schimmer-Konsensmechanismus funktioniert auf die gleiche Weise. Anstatt zu versuchen, die Meinung jedes anderen Nodes zu rekonstruieren, kümmern wir uns nur um die Meinung einer sehr kleinen Teilmenge von Nodes und lassen den Konsens organisch als eine aufkommende Eigenschaft des Netzwerks entstehen.

Wenn unter Shimmer ein Konflikt entsteht, tauschen die Nodes wiederholt ihre Meinungen darüber aus, welche der konfliktträchtigen Transaktionen sie bevorzugen, bis schließlich ein Konsens erzielt wird. Die Nodes erhalten eine globale Sicht auf den bevorzugten Teil des Tangle, was von entscheidender Bedeutung für die Gewährleistung des Konsenses ist. An einem bestimmten Punkt kann ein Node weiterhin entscheiden, seine Entscheidung als abgeschlossen zu markieren. Das bedeutet, dass sie ihre Beteiligung am Abstimmungsprozess einstellt und nie wieder von dieser Meinung abweichen wird, auch nicht im Falle eines überwältigenden Meinungswechsels (aufgrund eines Angriffs).

Da Shimmer für den Konsens im Tangle verwendet wird, hat das “mögen” oder “nicht mögen” einer Transaktion weitere Konsequenzen. Wenn eine Transaktion von einem Node “gemocht” wird, dann muss sie auch “wie” alle anderen Transaktionen sein, die direkt oder indirekt referenziert werden. Umgekehrt, wenn eine Transaktion “nicht gemocht” wird, dann kann keine Transaktion, die auf diese Transaktion verweist, “gemocht” werden.

Es ist wichtig zu beachten, dass es nicht notwendig ist, über jede Transaktion abzustimmen. Transaktionen, die keine Konflikte mit einer anderen Transaktion aufweisen, können allein aufgrund lokaler Modifikatoren (d.h. nach Ablauf einer bestimmten Zeit) als “gemocht” angesehen werden. Abstimmungen sind nur erforderlich, um Konflikte zu lösen und Fälle zu klären.

Nodes lehnen Stimmen ab, die zwei widersprüchliche Subtangles gleichzeitig “bevorzugen”. Dies zwingt die Nodes, sich für einen einzigen Überlebenden zu entscheiden. Nodes, die gegen diese Regel verstoßen, können ignoriert und dauerhaft als Nachbarn abgelehnt werden. Beachten Sie auch, dass es keinen Grund gibt, warum ehrliche Nodes für zwei widersprüchliche Subtangles stimmen wollen, da es keine Mining-Belohnung gibt, die sie dazu anregen würde.

Wir untersuchen zwei verschiedene Ansätze, wie die Abstimmung durchgeführt und gesichert wird. Das sind:

  • Cellular Consensus (dt. Zellulärer Konsens)
  • Fast Probabilistic Consensus (dt. Schneller wahrscheinlichkeitsbezogener Konsens)

Diese haben unterschiedliche Eigenschaften, zeigen aber beide gleich vielversprechende frühe Ergebnisse und werden in Kürze in einem öffentlichen Testnetz untersucht. Glücklicherweise macht es die Modularität des Protokolls sehr einfach, beide parallel zu testen.

Quellen

https://coordicide.iota.org/module4.1