Wenn es für einen Knoten wirklich „weh tut“, liegt das meist nicht daran, dass ein Block plötzlich größer wird, sondern dass das Netzwerk anfängt, „nicht mehr mitzuspielen“.
Diesmal habe ich mir die Verbreitungsebene von <a>#dusk </a> angesehen und blieb an einem Detail hängen: Es versteht die Netzwerkeffizienz nicht einfach nur so, dass „mehr Bandbreite immer besser“ ist, sondern versucht, direkt bei der Frage anzusetzen, wie Nachrichten ihren Weg finden.
@Dusk verwendet bei seinem Kadcast eine zielgerichtete Weiterleitungslogik auf Basis der Knotendistanz. Ein Knoten verteilt eine Nachricht nicht gedankenlos an alle Nachbarn, sondern wählt anhand der Routing-Beziehungen den nächsten Hop, damit die Nachricht über klarere Pfade weitergegeben wird. Das wirkt vielleicht nicht so „sexy“, ist für eine Public Chain aber entscheidend.
Denn das größte Problem von Gossip ist nicht „langsam“, sondern „wiederholt“.
Wenn dieselbe Transaktion von unterschiedlichen Knoten einmal im Kreis läuft und zurückkommt, muss das Netzwerk weiterleiten, verifizieren und cachen. Sobald die Anzahl der Knoten steigt, wird die Nachrichtenredundanz schnell dazu, dass Bandbreite und CPU gemeinsam aufgefressen werden. Das Ziel von Kadcast ist im Kern, diese unwirksame Verbreitung zu reduzieren—damit Netzressourcen möglichst für genau die Nachrichten genutzt werden, die wirklich zugestellt werden müssen.
Aber ich nicke nicht einfach ab, nur weil irgendwo „Bandbreitenverbrauch senken“ steht.
Am meisten Angst haben solche Designs gerade vor realen Netzwerken: Wenn Knoten plötzlich ausfallen, die Latenz stark ansteigt oder Nachbarn in der Routing-Tabelle nicht mehr erreichbar sind, kann der theoretisch kürzeste Pfad im Handumdrehen zu einer Sackgasse werden. Um sicherzustellen, dass die Nachrichten am Ende ankommen, muss das System daher Ersatzpfade und Mechanismen für erneutes Routing bereitstellen. Je komplexer die Ausweichmechanismen sind, desto deutlicher wird das Ringen zwischen höherer Übertragungseffizienz und höheren Wartungskosten.
Und außerdem sind Public-Chain-Knoten keine festen Server im Labor.
Ich finde vielmehr, genau das ist der Punkt, den die Verbreitungsebene von <a>$DUSK </a> weiterhin wert ist zu beobachten.
Wenn Kadcast auch in Szenarien mit großem Zu- und Abgang von Knoten, länder- bzw. regionsübergreifender Latenz und Netzwerkausschnitten (Partitionen) stabil bleibt, löst es nicht nur das Problem, Bandbreite zu sparen, sondern macht es für normale Knoten auch einfacher, sich am Netzwerk zu beteiligen.
Wenn es dagegen bei Routing-Ausfällen zu häufig zurückweicht, verlieren die zuvor so beeindruckend klingenden theoretischen Effizienzen schnell an Bedeutung.
Am Ende entscheidet bei einer Public Chain nicht, welche Kurve im Whitepaper schöner aussieht, sondern ob die Knoten um drei Uhr morgens, wenn das Netzwerk Probleme macht, ihre Route selbst wiederfinden können. Glaubt ihr, solche Änderungen in der Verbreitungsebene bringen der Public Chain langfristig mehr Vorteile in Richtung Dezentralisierung—oder schieben sie die Systemkomplexität eher nach oben?
Diesmal habe ich mir die Verbreitungsebene von <a>#dusk </a> angesehen und blieb an einem Detail hängen: Es versteht die Netzwerkeffizienz nicht einfach nur so, dass „mehr Bandbreite immer besser“ ist, sondern versucht, direkt bei der Frage anzusetzen, wie Nachrichten ihren Weg finden.
@Dusk verwendet bei seinem Kadcast eine zielgerichtete Weiterleitungslogik auf Basis der Knotendistanz. Ein Knoten verteilt eine Nachricht nicht gedankenlos an alle Nachbarn, sondern wählt anhand der Routing-Beziehungen den nächsten Hop, damit die Nachricht über klarere Pfade weitergegeben wird. Das wirkt vielleicht nicht so „sexy“, ist für eine Public Chain aber entscheidend.
Denn das größte Problem von Gossip ist nicht „langsam“, sondern „wiederholt“.
Wenn dieselbe Transaktion von unterschiedlichen Knoten einmal im Kreis läuft und zurückkommt, muss das Netzwerk weiterleiten, verifizieren und cachen. Sobald die Anzahl der Knoten steigt, wird die Nachrichtenredundanz schnell dazu, dass Bandbreite und CPU gemeinsam aufgefressen werden. Das Ziel von Kadcast ist im Kern, diese unwirksame Verbreitung zu reduzieren—damit Netzressourcen möglichst für genau die Nachrichten genutzt werden, die wirklich zugestellt werden müssen.
Aber ich nicke nicht einfach ab, nur weil irgendwo „Bandbreitenverbrauch senken“ steht.
Am meisten Angst haben solche Designs gerade vor realen Netzwerken: Wenn Knoten plötzlich ausfallen, die Latenz stark ansteigt oder Nachbarn in der Routing-Tabelle nicht mehr erreichbar sind, kann der theoretisch kürzeste Pfad im Handumdrehen zu einer Sackgasse werden. Um sicherzustellen, dass die Nachrichten am Ende ankommen, muss das System daher Ersatzpfade und Mechanismen für erneutes Routing bereitstellen. Je komplexer die Ausweichmechanismen sind, desto deutlicher wird das Ringen zwischen höherer Übertragungseffizienz und höheren Wartungskosten.
Und außerdem sind Public-Chain-Knoten keine festen Server im Labor.
Ich finde vielmehr, genau das ist der Punkt, den die Verbreitungsebene von <a>$DUSK </a> weiterhin wert ist zu beobachten.
Wenn Kadcast auch in Szenarien mit großem Zu- und Abgang von Knoten, länder- bzw. regionsübergreifender Latenz und Netzwerkausschnitten (Partitionen) stabil bleibt, löst es nicht nur das Problem, Bandbreite zu sparen, sondern macht es für normale Knoten auch einfacher, sich am Netzwerk zu beteiligen.
Wenn es dagegen bei Routing-Ausfällen zu häufig zurückweicht, verlieren die zuvor so beeindruckend klingenden theoretischen Effizienzen schnell an Bedeutung.
Am Ende entscheidet bei einer Public Chain nicht, welche Kurve im Whitepaper schöner aussieht, sondern ob die Knoten um drei Uhr morgens, wenn das Netzwerk Probleme macht, ihre Route selbst wiederfinden können. Glaubt ihr, solche Änderungen in der Verbreitungsebene bringen der Public Chain langfristig mehr Vorteile in Richtung Dezentralisierung—oder schieben sie die Systemkomplexität eher nach oben?