Also habe ich neulich im Newton Exploerer herumgestöbert, und irgendwas hat sich komisch angefühlt. Ein Operator auf dem Board @NewtonProtocol zeigte gegen Mittag diese seltsame Ausdünnung in ihrer Arbeit – nicht komplett tot, nur leichter als zuvor. Keine Downtime-Warnung, kein Slashing-Event, nichts. Zuerst dachte ich mir: Okay, vielleicht hat ihre Hardware halt kurz gehustet.
Dann habe ich die Zeitpunkte genauer geprüft. Genau in diesem selben Fenster ist ein neuer Typ in Newtons aktiven Satz eingestiegen – mit einem viel größeren Einsatz.
Der erste Runner ist nicht einmal abgestürzt. Die Tasks sind einfach stillschweigend zu dem schwereren Spieler verschoben worden, weil Newtons Algorithmus stark auf Einsatzgewichtung setzt. Das ist kein Bug – so ist das Protokoll buchstäblich so designt: Natürlich wird begünstigt, wer mehr „Skin im Spiel“ hat.
Das hat mich darauf gebracht, wie groß die Lücke ist zwischen „nur einen Platz in Newton zu halten“ und „tatsächlich benutzt zu werden“. Selbst wenn ein Runner live bleibt, gebondet und perfekt synchronisiert ist, kann er trotzdem untätig herumliegen, wenn ein größerer Delegate ihm die ganze Arbeit wegzieht. Von oben sieht Newtons Tabelle voll und gesund aus. Aber darunter erzählt die echte Verteilung der Arbeit eine andere, leisere Geschichte.
Was ich ständig bedenke, ist, was passiert, wenn dieser Schwergewicht-Runner mitten im Zyklus wieder wegfällt. Wenn sich ein fetter Knoten plötzlich mid-epoch unbondet, bräuchte Newton Zeit, um den neuen aktiven Satz zu bilden, und bis dahin könnten Latenzspitzen entstehen oder Aufgaben durchrutschen. Spürt man den Druck dann sofort – oder erst, wenn die Reaktionsfähigkeit anfängt, auszudünnen?
Und außerdem gibt es noch einen weiteren beängstigenden Aspekt: Wenn große Delegates weiterhin die gesamte Durchsatzleistung abgreifen, werden kleinere Operatoren, die eigentlich perfekt live sind, irgendwann die Geduld verlieren und aussteigen. Dieses stille Zentralisierungsrisiko – die „thread“, die einfach nicht aus meinem Kopf will, eyaar.
#Newt
$NEWT
Dann habe ich die Zeitpunkte genauer geprüft. Genau in diesem selben Fenster ist ein neuer Typ in Newtons aktiven Satz eingestiegen – mit einem viel größeren Einsatz.
Der erste Runner ist nicht einmal abgestürzt. Die Tasks sind einfach stillschweigend zu dem schwereren Spieler verschoben worden, weil Newtons Algorithmus stark auf Einsatzgewichtung setzt. Das ist kein Bug – so ist das Protokoll buchstäblich so designt: Natürlich wird begünstigt, wer mehr „Skin im Spiel“ hat.
Das hat mich darauf gebracht, wie groß die Lücke ist zwischen „nur einen Platz in Newton zu halten“ und „tatsächlich benutzt zu werden“. Selbst wenn ein Runner live bleibt, gebondet und perfekt synchronisiert ist, kann er trotzdem untätig herumliegen, wenn ein größerer Delegate ihm die ganze Arbeit wegzieht. Von oben sieht Newtons Tabelle voll und gesund aus. Aber darunter erzählt die echte Verteilung der Arbeit eine andere, leisere Geschichte.
Was ich ständig bedenke, ist, was passiert, wenn dieser Schwergewicht-Runner mitten im Zyklus wieder wegfällt. Wenn sich ein fetter Knoten plötzlich mid-epoch unbondet, bräuchte Newton Zeit, um den neuen aktiven Satz zu bilden, und bis dahin könnten Latenzspitzen entstehen oder Aufgaben durchrutschen. Spürt man den Druck dann sofort – oder erst, wenn die Reaktionsfähigkeit anfängt, auszudünnen?
Und außerdem gibt es noch einen weiteren beängstigenden Aspekt: Wenn große Delegates weiterhin die gesamte Durchsatzleistung abgreifen, werden kleinere Operatoren, die eigentlich perfekt live sind, irgendwann die Geduld verlieren und aussteigen. Dieses stille Zentralisierungsrisiko – die „thread“, die einfach nicht aus meinem Kopf will, eyaar.
#Newt
$NEWT