Ich weiß es auch nicht. Aber ich könnte mir vorstellen, dass Satoshi den Code möglichst einfach und Rechnungen möglichst exakt halten wollte.
Bei feiner abgestuften exponentiellen Änderungen denkt man z.B. erst einmal an e-Funktionen, die mit Gleitkommazahlen rechnen (Typen: float, double).
Im Bitcoin Code wird aber zwecks Genauigkeit bei Bitcoin-Beträgen durchgängig in Festkomma-Arithmetik gerechnet. D.h. im Prinzip wird nur mit ganzen Zahlen in der Einheit Satoshi gerechnet. Entsprechend finden diesbezüglich nur zu 100% exakte Berechnungen mit ganzen Zahlen statt (Typ: integer).
Würde man mit Gleitkommazahlen arbeiten (z.B. e-Funktion), käme es bei Rechnungen zu Rundungsfehlern, die auch noch Compiler- bzw. Plattform-abhängig sind. Man möchte aber nicht, dass die Nodes bei der Validierung von Blöcken zu unterschiedlichen Ergebnissen kommen. Es wäre z.B. blöd, wenn sich die berechnete Subsidy von Rechner zu Rechner unterscheidet und deshalb Blöcke nur von manchen Nodes akzeptiert werden.
Eine Halbierung der Subsidy über einen Bitshift, wie sie aktuell im Code implementiert ist, ist hingegen eine ganz einfache plattform-unabhängige Integer-Operation.
Die Ursprungs-Subsidy (50 BTC) in Satoshis und Binärdarstellung wird einfach um die Anzahl der Halvings in Richtung des kleinstwertigen Bits verschoben. Die vorherige 1-er Stelle wird also bei jedem Shift verworfen. Hierbei kann es zu keinen Abweichungen zwischen den Nodes kommen.
CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
// Force block reward to zero when right shift is undefined.
if (halvings >= 64)
return 0;
CAmount nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
nSubsidy >>= halvings;
return nSubsidy;
}
Statt der Zeile nSubsidy >>= halvings;
könnte man natürlich auch aufwendigere Lösungen implementieren, die nur mit Integer-Operationen auskommen und die Subsidy in kürzeren Intervallen um einen konstanten Faktor (exponentiell) verringern.
Diese Implementierung würde die Subsidy z.B. jede Woche grob mit dem Faktor 255/256 verkleinern:
int nBlock = nHeight;
while(nBlock > 0) {
if (nBlock-- % 1008 == 0) {
nSubsidy -= nSubsidy >> 8;
}
}
Das wäre halt wie man sieht schon um einiges komplexer und rechenaufwendiger als die einfache und elegante aktuelle Lösung. Man könnte auch nicht mehr ohne weiteres auf die Schnelle berechnen, wo wir gerade stehen.
Wahrscheinlich hat Satoshi einfach keinen Grund gesehen, das an dieser Stelle komplexer zu machen. Dass die Halving-Events damit zu großen Ereignissen werden, hat er aber sicher schon geahnt.