Es gab eine Zeit, in der ich den Knoten laufen ließ, um Kaffee zu holen, wieder zurückkam und sah, dass die Logs weiterhin gleichmäßig weiterflossen … da begann ich darüber nachzudenken, dass die stabilste Verfügbarkeit auch das Leichteste ist, worüber man sich bequem macht.
Ich habe in config.rs geschaut: proposal = 1 credit, validation = 64, ratification = 64, quorum = 33.
Wenn genug Stake das Einzige wäre, was nötig ist – wofür gäbe es dann all diese Parameter?
Ich bin zu sortition.rs gewechselt: score = hash mod total_staking_weight.
mit zunehmendem Stake-Gewicht kann die Auswahlwahrscheinlichkeit steigen, aber Wahrscheinlichkeit ist keine Anspruchsberechtigung.
Dann bin ich in core/src/stake.rs gegangen, Zeile 46: DEFAULT_MINIMUM_STAKE = 1000.
Ganz ehrlich: Ich habe Minimum Stake früher als die Ziellinie gesehen, dabei ist es eher eine Initialisierungsbedingung als ein garantierter Zustand.
1500 DUSK staken bedeutet, das Minimum um 500 DUSK zu überschreiten.
aber verpasste Abstimmungen bringen eine weiche Strafe, eine Aussetzung der Berechtigung, und sobald ein Teil des Stakes in gesperrten Zustand übergeht, sieht diese Zahl nicht mehr so gut aus.
Nachstockung funktioniert genauso: 90% sofort aktiv, 10% gesperrt.
500 DUSK bedeutet 450 DUSK aktiv, 50 DUSK gesperrt … es klingt klein, aber die Konsequenzen sind es nicht.
Seitdem prüfe ich bei jeder Protokollauditsierung den Datentyp, die Implementierung, den Zustandsübergang, die Teilnahme an der Abstimmung, die Laufzeitbedingungen, die Maschinenverfügbarkeit und die vollständige Unstaking.
quorum = 33.
aber sind das 33 Stimmen oder 33%?
Ohne den Datentyp zu prüfen zu einer Schlussfolgerung zu kommen, ist sicherlich schnell – aber die schnellste Antwort kann manchmal auch die falschste sein.
score, hash, committee, gesperrter Zustand, validation, ratification … je weiter ich ihnen nachspüre, desto mehr sehe ich: Ein Validator ist nicht einfach ein Haufen Stake, der stillsitzt, sondern ein System, das kontinuierlich am Leben bleiben muss.
Für mich ist ein vertrauenswürdiger Validator nicht der Knoten mit dem größten Stake, sondern der Knoten mit der stärksten betrieblichen Disziplin, wenn niemand daneben steht und ihn daran erinnert, abzustimmen.
Wenn du zwischen einer Erhöhung des Stake-Gewichts um 20% und der Reduzierung verpasster Abstimmungen, Ausfallzeiten und der Strafe im realen Betrieb wählen müsstest – für welche Seite würdest du dich entscheiden?#dusk $DUSK @Dusk
Ich habe in config.rs geschaut: proposal = 1 credit, validation = 64, ratification = 64, quorum = 33.
Wenn genug Stake das Einzige wäre, was nötig ist – wofür gäbe es dann all diese Parameter?
Ich bin zu sortition.rs gewechselt: score = hash mod total_staking_weight.
mit zunehmendem Stake-Gewicht kann die Auswahlwahrscheinlichkeit steigen, aber Wahrscheinlichkeit ist keine Anspruchsberechtigung.
Dann bin ich in core/src/stake.rs gegangen, Zeile 46: DEFAULT_MINIMUM_STAKE = 1000.
Ganz ehrlich: Ich habe Minimum Stake früher als die Ziellinie gesehen, dabei ist es eher eine Initialisierungsbedingung als ein garantierter Zustand.
1500 DUSK staken bedeutet, das Minimum um 500 DUSK zu überschreiten.
aber verpasste Abstimmungen bringen eine weiche Strafe, eine Aussetzung der Berechtigung, und sobald ein Teil des Stakes in gesperrten Zustand übergeht, sieht diese Zahl nicht mehr so gut aus.
Nachstockung funktioniert genauso: 90% sofort aktiv, 10% gesperrt.
500 DUSK bedeutet 450 DUSK aktiv, 50 DUSK gesperrt … es klingt klein, aber die Konsequenzen sind es nicht.
Seitdem prüfe ich bei jeder Protokollauditsierung den Datentyp, die Implementierung, den Zustandsübergang, die Teilnahme an der Abstimmung, die Laufzeitbedingungen, die Maschinenverfügbarkeit und die vollständige Unstaking.
quorum = 33.
aber sind das 33 Stimmen oder 33%?
Ohne den Datentyp zu prüfen zu einer Schlussfolgerung zu kommen, ist sicherlich schnell – aber die schnellste Antwort kann manchmal auch die falschste sein.
score, hash, committee, gesperrter Zustand, validation, ratification … je weiter ich ihnen nachspüre, desto mehr sehe ich: Ein Validator ist nicht einfach ein Haufen Stake, der stillsitzt, sondern ein System, das kontinuierlich am Leben bleiben muss.
Für mich ist ein vertrauenswürdiger Validator nicht der Knoten mit dem größten Stake, sondern der Knoten mit der stärksten betrieblichen Disziplin, wenn niemand daneben steht und ihn daran erinnert, abzustimmen.
Wenn du zwischen einer Erhöhung des Stake-Gewichts um 20% und der Reduzierung verpasster Abstimmungen, Ausfallzeiten und der Strafe im realen Betrieb wählen müsstest – für welche Seite würdest du dich entscheiden?#dusk $DUSK @Dusk
