Das Steem Whitepaper - Teil 31 Bandwidth ​​Instead ​​of ​​Micropayment​​ Channels

Wie immer findet ihr das orginal White Paper hier und allgemeine Informationen zu dieser Reihe hier.

Bandwidth ​​Instead ​​of ​​Micropayment​​ Channels

Die Lösung der Probleme mit Micropayments liegt in der Implementierung dynamischer Teilreserven. Bei diesem Modell passt die Blockchain das Reserveverhältnis für das Netz in Zeiten von Überlastungen automatisch an. Die Blockchain wird eine Zielauslastung festlegen, die genügend Spielraum für kurzfristige Nachfrageschübe lässt. Jedes Mal, wenn die Überlastungen aufrechterhalten werden, reduziert die Blockkette die maximale Bandbreite pro Share. Wenn ein Anstieg vorbei ist und es einen Kapazitätsüberschuss gibt, kann die Blockchain die Bandbreite pro Share langsam erhöhen.

Die von einem einzelnen Benutzer genutzte Bandbreite sollte über einen angemessen langen Zeitraum gemessen werden, um diesem Benutzer eine zeitliche Verschiebung seiner Nutzung zu ermöglichen. Benutzer neigen dazu, sich anzumelden, viele Dinge auf einmal zu tun und sich dann wieder abzumelden. Das bedeutet, dass ihre Bandbreite über einen kurzen Zeitraum viel höher erscheinen kann, als wenn sie über einen längeren Zeitraum betrachtet werden. Wenn das Zeitfenster zu weit ausgedehnt wird, passt sich die Serverkapatität nicht schnell genug an, um auf kurzfristige Überspannungen zu reagieren; ist das Fenster zu kurz, hat die Cluster-Nutzung zu große Auswirkungen auf normale Benutzer.

Nach unserer Einschätzung sollte es ausreichen, die durchschnittliche wöchentliche Bandbreitennutzung der Benutzer zu messen. Jedes Mal, wenn ein Benutzer eine Transaktion unterzeichnet, wird diese Transaktion in seinen eigenen individuellen gleitenden Durchschnitt einbezogen. Jedes Mal, wenn der gleitende Durchschnitt eines Benutzers das aktuelle Netzwerklimit überschreitet, wird die Transaktion verzögert, bis der Durchschnitt unter das Limit fällt.

Anmerkung

Vereinfach lässt es sich so sagen, es wird ermittelt wie viel der Kapazitäten gebraucht werden. Anschließend wird eine gewisse Reserve mit eingeplant und anschließend werden hieraus durchschnittliche Kosten berechnet. Wenn jetzt auf einmal wieder mehr Aktivität herrscht, werden die Kosten angepasst und nach oben geschraubt. Wenn dies jedoch nicht schnell genug passiert. Wenn jetzt ein Nutzer mehr Kosten verursacht, als er Anteile am Netzwerk besitzt, kann er nicht mehr handeln. Er muss warten, bis er wieder näher an der Durchschnittsnutzung ist.

Vereinfach gesagt. Je mehr los ist, desto mehr RC kosten Aktionen und je weniger los ist, desto weniger. Es gibt einen Puffer um zu verhindern, dass die Blöcke zu voll werden und Nutzer nichts mehr eintragen können, was zu Verzögerungen führen würde. Will man die Blockgröße erhöhen, um mehr Aktionen zu ermöglichen, müssen entweder die Steempreise langfristig höher sein oder mehr vom Reward Pool an die Witnesses gehen, um das Netzwerk zu tragen.