Wie reguliert der Kimoto Gravity Well die Schwierigkeit?

Die Erklärungen im Internet sind alle sehr vage und mystisch, vielleicht mit Absicht. Hier ist meine Meinung in einfachen Worten, indem ich einfach den Megacoin-Quellcode aus dem obigen Kommentar lese.

Das Ziel ist eine anpassungsfähigere Möglichkeit, die Schwierigkeit anzupassen, anstatt nur die letzten 2016-Blöcke wie Bitcoin zu mitteln. Dies ist erforderlich, da Multipools die Münze, die sie abbauen, wechseln könnten, und es kann zu einer plötzlichen Änderung der Hashrate kommen (sowohl steigend als auch fallend). Gerade wenn ein Multipool wegschaltet bleibt man zu lange bei einem zu hohen Schwierigkeitsgrad hängen.

Der Algorithmus durchläuft die Blöcke rückwärts, beginnend mit dem aktuellen. Das PastBlocksMassist nur die Anzahl der Blöcke, also beginnt es bei einem und erhöht sich in jeder Schleife.

In jeder Schleife wird ein Anpassungsfaktor berechnet, der die Zielblockzeit dividiert durch die tatsächliche Blockzeit auf kumulative Weise ist, sodass wir in Schleife 10 die Zielzeit von 25 Minuten dividiert durch die Zeit haben, die tatsächlich zur Berechnung der letzten benötigt wurde zehn Blöcke. Wenn die Hashrate steigt, erhalten wir kürzere Zeiten und einen Anpassungsfaktor größer als eins und umgekehrt.

Die Schleife endet immer dann, wenn der durchschnittliche Anpassungsfaktor größer kimoto-valueoder kleiner als ist 1/kimoto-value. Um dies zu verstehen, schauen Sie sich dieses Python-Skript und ein Beispieldiagramm an:

from pylab import *

one_day = 1440 / 2.5   # how many 2.5 min blocks per day

nmin = one_day / 4     # PastBlocksMin
nmax = one_day * 7     # PastBlocksMax
x = arange(nmin, nmax)   # PastBlocksMass

# start with 2.5 minute blocktime + some noise
t0 = 2.5 + randn(nmax) / 4
t1 = 2.5 + randn(nmax) / 4

# t0 has 20% more hashrate, so shorter blocktime in the beginning
t0[:one_day] = 2.5 / 1.2 + randn(one_day) / 4
# t1 has higher blocktime in the beginning
t1[:one_day] = 2.5 / 0.9 + randn(one_day) / 4

s = arange(nmax)

adjust0 = (arange(1, nmax + 1) * 2.5 ) / cumsum(t0)
adjust1 = (arange(1, nmax + 1) * 2.5 ) / cumsum(t1)

# the magic function
def kimoto(x):
    return  1 + (0.7084 * pow((double(x)/double(144)), -1.228));

plot(x/one_day, kimoto(x))
plot(x/one_day, 1/kimoto(x))
plot(s/one_day, adjust0)
plot(s/one_day, adjust1)
legend(["kimoto","1/kimoto", "20% increase in hashrate", "10% drop in hashrate"])
xlabel("days")
ylabel("adjustment factor (target/actual blocktime)")
show()

Das Skript erzeugt eine Figur wie diese .

Es zeigt zwei konstruierte Beispiele, wann die Hashrate für einen Tag steigt und wann sie fällt. Am besten ist es, eine Weile mit verschiedenen Einstellungen zu spielen, um ein Gefühl dafür zu bekommen, was vor sich geht.

Sie sehen, dass sich die Linien irgendwann durch die Kimoto-Formel kreuzen. Dies ist der Zeitpunkt, an dem der Algorithmus beendet wird und diesen Anpassungsfaktor verwendet, um ein neues Ziel/eine neue Schwierigkeit zu berechnen. Bei großen Anpassungsfaktoren geschieht dies früher als bei denen, die näher bei eins liegen. Dies soll eine schnelle Anpassung haben, wenn sich die Hashrate stark ändert, und eine langsamere, wenn nicht - dann wollen wir einen längeren Zeitraum, um einen besseren Durchschnitt zu erhalten. Die Parameter der Kimoto-Formel sind so eingestellt, dass man sich grob an einem Tag auf 10 % Veränderung und in sieben Tagen auf 1,2 % Veränderung einstellt. Mindestens 144 Blöcke bestimmen die neue Schwierigkeit und höchstens 4032 (0,25 Tage oder 7 Tage bei 2,5 Minuten Blockzeit).

Fazit: Der Kimoto Gravity Well Algo hat einen ausgefallenen Namen und bestimmt die Anzahl der Blöcke, die zur Bewertung der neuen Schwierigkeit beitragen. Es gibt weniger Blöcke für Änderungen mit hoher Hashrate und ist daher anpassungsfähiger.