Dies ist eine Übersetzung des Original-Artikel geschrieben von @blocktrades zur Arbeit an der Hive Software: https://peakd.com/hive-139531/@blocktrades/8th-update-of-2021-on-blocktrades-work-on-hive-software
Nachfolgend eine Auflistung einiger Hive-bezogener Programmierprobleme, an denen das BlockTrades-Team in den letzten Wochen gearbeitet hat:
Hived Work (Blockchain Node Software)
Codebereinigung und Untersuchung der Unterstützung für Ubuntu 20
Unabhängig von unseren Hardfork-25-Änderungen haben wir einige allgemeine Codebereinigungen vorgenommen, um den Code wartbarer zu machen, und wir haben auch eine Aufgabe gestartet, um den Code dazu zu bringen, unter Ubuntu 20 sauber zu kompilieren, ohne dass man mit dem Build-Prozess "herumfummeln" muss.
HF25-Änderungen (diese sind in unserem Beitrag zur Hive-Roadmap ausführlich beschrieben)
Verfall von alten Governance-Abstimmungen
Wir haben alle Änderungen, die sich auf den Umgang mit dem Verfall von Governance-Abstimmungen (Abstimmungen für Witness und Hive-Fund-Vorschläge) beziehen, fertiggestellt und Tests dafür geschrieben.
Änderungen bei der Berechnung von Kurationsbelohnungen
Wir haben die Analyse und Implementierung der Änderungen an der Kuration des Abstimmungsfensters für HF25 abgeschlossen. Wir schreiben auch einige Tests für die Kurationsberechnung, da wir festgestellt haben, dass die aktuellen Tests unzureichend sind (unsere Änderungen lösten nur ein Fehlschlagen der bestehenden Tests aus).
Während des Prozesses entdeckten wir auch einen Fehler in der Implementierung der Quadratwurzelfunktion, die vom aktuellen Kurationsalgorithmus für unsignierte 128-Bit-Ganzzahlen verwendet wird. Wir entfernen die Verwendung dieser Quadratwurzelfunktion in der neuen Kurationsberechnung als Teil unserer Entfernung des konvergent-linearen Kurven-Codes (dies ist der Code, der kleine Stimmen schwächte).
Der neue Kuratierungs-Belohnungsalgorithmus funktioniert wie folgt:
- erster Tag (24 Stunden) lineare Rewards (gleiches Gewicht für alle Wähler in diesem Fenster)
- zweites Fenster (24 Stunden bis 72 Stunden/3 Tage) mit Reward-Gewichtung/2
- verbleibende Stimmen im 3. Fenster mit Reward-Gewichtung/8
Nach dem neuen Algorithmus erhält jeder, der in den ersten 24 Stunden abstimmt, die gleichen proportionalen Belohnungen. Mit anderen Worten, für eine gegebene Abstimmungsstärke erhält der Wähler den gleichen prozentualen Return-on-Investment wie jeder andere Wähler in diesem Zeitraum.
Wähler, die während des zweiten und dritten Fensters abstimmen, erhalten eine kleinere proportionale Belohnung (und Wähler, die während des ersten 24-Stunden-Zeitraums abgestimmt haben, erhalten etwas mehr Belohnung, als wenn sie während des zweiten oder dritten Fensters abstimmen). Beachten Sie, dass, wenn niemand während des ersten Fensters abstimmt, die Wähler des zweiten Fensters die gleiche Menge an Kuration erhalten, als wenn sie während des ersten Fensters abgestimmt hätten.
Die Grundidee hinter dem neuen Algorithmus ist es, die Wähler zu ermutigen, gute Inhalte zu finden, sie aber mit den Voting-Bots gleichzustellen. Unter dem aktuellen Algorithmus, den wir ersetzen, haben Voting-Bots einen Vorteil, weil es ein kurzes Zeitfenster gibt, um eine Stimme abzugeben, um eine optimale Kurationsbelohnung zu erhalten.
Beachten Sie, dass die Belohnungen für Autoren von dieser Änderung nicht betroffen sind: Diese Änderung wirkt sich nur darauf aus, wie Kurationsbelohnungen unter den Wählern verteilt werden.
Operation zur Konvertierung von Hive nach HBD
Der einzige Code, an dem wir in hived für hardfork 25 noch arbeiten, ist die neue Operation, die es Benutzern erlaubt, liquid Hive in HBD zu konvertieren. Wir untersuchen noch einige Probleme im Zusammenhang mit dem bestehenden Code, der den Medianpreis für Hive berechnet, aber wir erwarten, dass der Konvertierungscode diese Woche fertiggestellt und getestet wird.
Hardfork-Code-Freeze in der Mitte dieses Monats
Wir erwarten, dass wir am 15.4. (Mitte dieses Monats) einen Code-Freeze durchführen, damit die Witness ein Testnetzwerk starten und mit der Evaluierung und dem Testen der Code-Änderungen für Hardfork 25 beginnen kann.
Das Testnetz wird mindestens einen Monat lang betrieben
Wenn keine Probleme auftreten, erwarten wir, dass das Testnetz mindestens einen Monat lang in Betrieb ist, bevor wir mit den letzten Vorbereitungen für HF25 beginnen.
Dies wird den Hive-API-Bibliotheken und Frontend-Websites Zeit geben, Änderungen vorzunehmen, um Benachrichtigungen in Bezug auf den Ablauf von Abstimmungen bereitzustellen und die Verwendung der neuen Hive→HBD-Konvertierungsoperation sowie die von @howo implementierten Funktionen für wiederkehrende Zahlungen und rc-Delegation zu ermöglichen. Aber genau genommen können die meisten dieser Frontend-Funktionen nach der Ausführung der Hardfork implementiert werden, ohne Probleme zu verursachen. Der Hauptgrund für dieses Zeitintervall ist also, das Testen und Bewerten der Leistung der neuen Algorithmen und Funktionen zu ermöglichen.
Modulares hivemind (Anwendungs-Framework für 2nd-Layer-Apps)
Synchronisierung des modularen hivemind aus dem SQL-Kontoverlauf-Plugin
Wir konnten eine Hivemind-Instanz erfolgreich mit den Daten synchronisieren, die vom SQL-Kontoverlaufs-Plugin injiziert wurden (wobei die Synchronisierung stattfand, während die SQL-Daten vom Plugin injiziert wurden), aber wir sind am Ende auf ein Problem gestoßen, als einige der Indizes von Hivemind neu erstellt wurden, als Hivemind den vollständigen Synchronisierungsmodus verließ und in den Live-Synchronisierungsmodus wechselte. Wir untersuchen dieses Problem jetzt und erwarten eine Lösung in den nächsten Tagen.
Leistungsmessungen für die hivemind-Synchronisierung mit dem SQL-Kontoverlauf-Plugin
Trotz des Problems beim Verlassen des vollen Sync-Modus konnten wir einige nützliche Leistungsmessungen sammeln.
Bei der regulären Version der hivemind-Synchronisierung, bei der wir zuerst eine hived-Wiederholung durchführen, um die hivemind-Datenbank zu füllen, und bei der wir dann eine hivemind-Synchronisierung durchführen, bei der Indizes und Fremdschlüssel automatisch gelöscht und am Ende neu erstellt werden), dauerte der hivemind-Synchronisierungsprozess 50983s (hivemind-Synchronisierung) + 4047s (Indexerstellung) + 1998s (Fremdschlüsselerstellung) = 57028s
Bei der modifizierten Version von hivemind sync, bei der Indizes vor Beginn der Synchronisierung erstellt werden, dauerte die hivemind sync 67947s (die reguläre Version war 10918s schneller).
Trotz der erhöhten Zeit für die modifizierte Version (10918s/3600s = 3,03 Stunden) kann die Zeit für die vollständige Synchronisierung der Hivemind-Node mit dem SQL-Kontoverlaufs-Plugin insgesamt verringert werden, da dies bedeutet, dass die Hivemind-Synchronisierung gestartet werden kann, während die Hived-Node erneut abgespielt wird, um die Datenbank von Hivemind zu füllen.
Bei der "normalen Methode" wäre die Gesamtzeit hived sync (~8 Stunden) + hivemind full sync time (15,84 Stunden) = 23,84 Stunden. Mit der modifizierten Methode sieht es so aus, als ob wir diese Zeit auf die modifizierte hivemind-Synchronisationszeit (18,87 Stunden) reduzieren können.
Beachten Sie, dass all diese Zeiten letztlich mit der bestehenden Zeit für eine Hivemind-Synchronisierung ohne das SQL-Kontoverlaufs-Plugin (~90+ Stunden) verglichen werden sollten. Es scheint also möglich, dass die Zeit für eine vollständige Hivemind-Synchronisierung einer neuen Node mit dem SQL-Kontoverlaufs-Plugin um das Vierfache oder mehr beschleunigt werden könnte, wenn ich mich nicht irgendwo in meinen Annahmen vertan habe (ich wollte diesen Bericht nicht länger hinauszögern, daher wurde er nicht "peer-reviewed").
Hivemind (Middleware für soziale Medien)
Erheblich reduzierte Speichernutzung durch den hivemind-Prozess
Wir haben ein Problem in hivemind behoben, bei dem ein Wörterbuch als Cache für Post-Ids verwendet wurde und dieses Wörterbuch mit zunehmender Größe der Blockchain immer mehr Speicher verbrauchte. Wir entdeckten dieses Problem während einiger unserer Leistungstests der Hivemind-Synchronisierung unter Verwendung der Daten, die vom neuen SQL-Kontoverlaufs-Plugin bereitgestellt werden (das Problem besteht jedoch bei allen bestehenden Hivemind-Implementierungen).
Leider hatten wir noch keine Gelegenheit, die genauen Speichereinsparungen für den Fix zu messen, da wir uns auf andere Aufgaben konzentriert haben, aber ich sollte diese Zahlen für unseren nächsten Bericht haben.
Testen der Hivemind-Synchronisation auf einem Low-End-Server
Wir haben einen Low-End-Rechner eingerichtet (8 GB RAM und nur eine herkömmliche Festplatte, kein SSD-Laufwerk), um zu sehen, was die Mindestanforderungen für eine vollständige Hivemind-Node sind und ob wir diese Anforderungen senken können. In unseren Tests schaffte es der Hivemind-Prozess zwar, den vollständigen Synchronisierungsprozess zu beenden, aber er hatte einige Probleme bei der Erstellung von Indizes, daher werden wir dieses Problem in der kommenden Woche weiter untersuchen.
Testen der Leistung von hivemind mit Postgres 13
Derzeit ist Postgres Version 10 die empfohlene Version der Datenbank für die Verwendung mit hivemind, aber wir haben diese Woche einige Tests durchgeführt, um zu prüfen, ob hivemind mit der neuesten Version von Postgres (Version 13) kompatibel ist und um die relative Performance zu messen.
Die gute Nachricht: Es waren keine Code-Änderungen erforderlich, um Postgres 13 zu unterstützen, und als zusätzlichen Bonus sahen wir in unserem Test einen Geschwindigkeitszuwachs von 5% bei der vollständigen Synchronisationszeit. Wir haben noch keine umfassenden Tests der API-Antwortzeit in Bezug auf die SQL-Abfragegeschwindigkeit durchgeführt, aber die Zeichen stehen gut, dass wir nur Leistungsverbesserungen und keine Rückschritte erwarten können.
Verschiedene hivemind-Fehlerbehebungen und Dokumentation
Wir haben ein paar kleine Fehler behoben, die von Benutzern und Frontend-Entwicklern gemeldet wurden, wie z.B. ein Paginierungsproblem mit einem Community-bezogenen API-Aufruf und ein Problem mit der Validierung von Community-Namen:
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/488
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/489
Und wir haben eine offene Merge-Anfrage für den Code zur Generierung von Openapi-Dokumentation für die verschiedenen hivemind-API-Methoden: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/486
Demnächst ein weiteres Fortschrittsupdate
Ich werde wahrscheinlich Anfang nächster Woche ein weiteres Fortschritts-Update herausgeben, nachdem wir mehr Leistungszahlen haben. Ich habe dieses Update immer wieder verschoben, in der Hoffnung, diese Zahlen mit einzubeziehen, aber wir waren mit zu vielen Aufgaben beschäftigt und kleine Probleme haben einige unserer Messversuche zunichte gemacht, und dann kamen die Osterferien.
[EDIT] Einige Leute haben die Funktion der Gewichtung im neuen Algorithmus falsch interpretiert, und das hat zu einem Missverständnis über die Belohnungen für späte Wähler geführt. Die Gewichtung wird verwendet, um die Belohnungen zwischen den Kuratoren aufzuteilen. Wenn es also wenige starke Wähler in der ersten Periode und die meisten in einer späteren Periode gibt, erhalten die späten Wähler ungefähr die gleichen Belohnungen, als wenn sie in der frühen Periode gewählt hätten.
Der Gesamtbetrag der Beitrags-Belohnungen (Autor + Kuratoren-Belohnungen) wird mit dem neuen Algorithmus auf Basis der Gesamtanteile berechnet, nicht auf Basis der Gewichtung. In so ziemlich jedem Fall ist dieser neue Algorithmus so ausgelegt, dass er für Spätwähler MEHR Vorteile bringt als der aktuelle Algorithmus. Wenn dies also dazu führt, dass Leute nur in den ersten 24 Stunden abstimmen, liegt das nur an einer Fehlinformation. Wir werden später weitere Daten präsentieren, um zu erklären, wie der neue Algorithmus die Belohnungen für die Kuration verteilt.
